TCP与UDP

TCP 是面向连接的、可靠的流协议，通过三次握手建立连接，通讯完成时要拆除连接。

UDP是面向无连接的通讯协议，UDP通讯时不需要接收方确认，属于不可靠的传输，可能会出现丢包现象

端口号：

端口号用来识别同一台计算机中进行通信的不同应用程序。因此，它也被称为程序地址

TCP得数据包

请求报文结构

请求报文的首部内容由以下数据组成：

请求行——包含用于请求的方法、请求 URI 和 HTTP 版本。

首部字段——包含表示请求的各种条件和属性的各类首部。（通用首部、请求首部、实体首部以及RFC里未定义的首部如 Cookie 等）

响应报文结构

状态行——包含表明响应结果的状态码、原因短语和 HTTP 版本。

首部字段——包含表示请求的各种条件和属性的各类首部。（通用首部、响应首部、实体首部以及RFC里未定义的首部如 Cookie 等）

请求状态码：

	类别	原因
1xx	Informational(信息性状态码)	接收的请求正在处理
2xx	Success(成功状态码)	请求正常处理完毕
3xx	Redirection(重定向状态码)	需要进行附加操作以完成请求
4xx	Client Error(客户端错误状态码)	服务器无法处理请求
5xx	Server Error(服务器错误状态码)	服务器处理请求出错

TCP得滑动窗口传输机制

TCP协议数据包传输时并不是每一个报文段都会回复ACK的，可能会对两个报文段发送一个ACK，也可能会对多个报文段发送1个ACK【累计ACK】，比如说发送方有1/2/3 3个报文段，先发送了2,3 两个报文段，但是接收方期望收到1报文段，这个时候2,3报文段就只能放在缓存中等待报文1的空洞被填上，如果报文1，一直不来，报文2/3也将被丢弃，如果报文1来了，那么会发送一个ACK对这3个报文进行一次确认。

例子：

假设32~45 这些数据，是上层Application发送给TCP的，TCP将其分成四个Segment来发往接收方

2. 数据包1 32~34 ，数据包3 35~36， 数据包3 37~41 ，数据包4 42~45 这四个片段，依次发送出去，此时假设接收端之接收到了数据包1 数据包2 数据包4

3. 此时接收端的行为是回复一个ACK包说明已经接收到了32~36的数据，并将seg4进行缓存（保证顺序，产生一个保存数据包3 的hole）

4. 发送端收到ACK之后，就会将32~36的数据包从发送并没有确认切到发送已经确认，提出窗口，这个时候窗口向右移动

5. 假设接收端通告的Window Size仍然不变，此时窗口右移，产生一些新的空位，这些是接收端允许发送的范畴

6. 对于丢失的seg3，如果超过一定时间，TCP就会重新传送（重传机制），重传成功会seg3 seg4一块被确认，不成功，seg4也将被丢弃

就是不断重复着上述的过程，随着窗口不断滑动，将真个数据流发送到接收端，实际上接收端的Window Size通告也是会变化的，接收端根据这个值来确定何时及发送多少数据，从对数据流进行流控。原理图如下图所示：

滑动窗口动态调整

主要是根据接收端的接收情况，动态去调整Window Size，然后来控制发送端的数据流量，当接收方再一定时间内数据读取达到上限了，则会动态得调整下次数据接收窗口大小，并通知给发送方，发送方收到接收方得窗口大小后会改变下次传输得数据包大小，保证数得传输不会因为接收方数据量过载导致的丢失，以此用来做拥塞控制提高传输安全性