一文搞懂传输层协议 TCP和UDP

1. TCP和UDP对比

• UDP：无连接的；支持一对一、一对多、多对多的通信；面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部）；提供不可靠的传输服务（尽最大努力交付，收到报文不需要给出确认）；首部小。
  适用于IP电话、视频会议等实时应用。
• TCP：面向连接的；仅支持一对一通信；面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块）；可靠传输，使用流量控制和拥塞控制；首部开销大。
  适用于要求可靠传输的应用，例如文件传输。

2. TCP流量控制

目的：让发送方发送的速率不要太快，要让接收方来得及接受。
TCP的流量控制是利用滑动窗口机制实现的，接收方在返回的确认报文中会包含自己的接收窗口的大小，以控制发送方的发送速率。
将窗口字段设置为 0，则发送方不能发送数据。

2.1 TCP 滑动窗口

窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的发送窗口大小。

发送端数据分为四类：已发送已收到ack；已发送未收到ack；未发送允许被发送；不允许被发送。其中 第二三类在发送窗口中。
接受端数据分为三类：已经ack的数据；已接受但还没有ack；没有接受。其中第二类在接受窗口内。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。
接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

2.2 零窗口

如果接收方没有能力接收数据，就会将接收窗口设置为0，这时发送方必须暂停发送数据，但是会启动一个持续计时器(persistence timer)，到期后发送一个大小为1字节的探测数据包，以查看接收窗口状态。如果接收方能够接收数据，就会在返回的报文中更新接收窗口大小，恢复数据传送。

3.TCP 拥塞控制

拥塞控制是为了防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。
这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。 发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。

3.1 慢开始与拥塞避免

发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …
注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。

3.2 快重传与快恢复

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M₁ 和 M₂，此时收到 M₄，应当发送对 M₂ 的确认。
在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即冲传对方尚未收到的报文段，而不继续等待设置的重传计时器时间到期。
在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。

4. TCP超时重传时间选择

如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。
一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT，超时时间 RTO 应该略大于 RTTs。

5. TCP的可靠传输

TCP的可靠传输通过滑动窗口来实现。

TCP如何保证传输的可靠性：
数据包校验
对失序数据包重新排序（TCP报文具有序列号）
丢弃重复数据
应答机制：接收方收到数据之后，会发送一个确认（通常延迟几分之一秒）；
超时重发：发送方发出数据之后，启动一个定时器，超时未收到接收方的确认，则重新发送这个数据；
流量控制：确保接收端能够接收发送方的数据而不会缓冲区溢出

6. TCP的三次握手

为什么要进行第三次握手：
如果只有两次握手，会出现：已失效的连接请求报文段又传到了服务器端。
如果不进行第三次握手，服务器在接受到请求后就会建立连接。 当主机发送的第一个请求报文在网络节点中滞留很久才到达服务器，服务器直接建立连接，由于现在 主机 并没有发出建立连接的请求，因此不会理睬 服务器 的确认，也不会向 服务器 发送数据。但 服务器 却以为新的运输连接已经建立，并一直等待 主机 发来数据。资源就白白浪费了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。

6. TCP的四次挥手

CLOSE_WAIT状态意义是什么？
服务器在收到主机断开请求时，可能还有一部分数据没有传完，传送完毕后，服务器会发送FIN报文。

TIME-WAIT的意义是什么？

1. 客户端发送的ack报文可能没有到达服务器，服务器会重传fin报文，等待的一段时间就是为了处理这种问题。
2. 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

7. TCP报文首部

URG：紧急标识位。取1时，紧急指针有效，紧急指针会指出报文段数据载荷中有多长的紧急数据。紧急数据可以插队到缓存的最前面。
ACK：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
PSH：推送标志位。该标志位为1的报文段会尽快交付。
RST：复位标志位。该为1时，必须释放连接，再重新建立。在四次挥手中，当TIME-WAIT过后，客户端收到了来自服务端的FIN请求（即客户端的FIN回复报文一直没有到达服务端），客户端会发送rst报文，让服务端释放连接。
SYN：同步标志位。TCP连接时用来同步序号。
FIN：终止标志位。TCP用来释放连接。