TCP相关问题总结

TCP连接建立过程

1. TCP三次握手

首先client端发出连接请求，并且请求同步位SYN置为1，表示连接建立请求。此外传递seq序号（假设初始值为500）

然后server端接收SYN后，发送ACK确认请求，seq=501，表示对client发送的SYN请求的确认；此外，server也需要发送SYN请求，seq=700（假设服务端初值为700）

最后client端接收请求，对server端的SYN进行确认，发送ACK请求，seq=701

至此，三次握手完成，连接建立

2. TCP四次挥手

首先，客户端发起断开客户端连接请求。客户端向服务端发送FIN请求

服务端接收请求，并告诉客户端已经接收到客户端发起的断开请求。此时客户端的消息发送通道断开

然后，服务端执行类似流程，关闭服务端发送消息到客户端的通道

3. TCP为什么是三次握手

假设TCP是两次握手，则可能会发生以下情况

客户端发起TCP握手，向服务器发送SYN，但该数据因网络波动滞留

此时触发超时重传，重新简历TCP连接

当新建立的连接断开后，之前在网络中滞留的SYN连接请求传递到服务端，服务端误以为客户端需要建立TCP连接，因此会发送SYN+ACK请求，并进入连接建立状态，但客户端并不需要建立连接，不会发送数据，因此会造成服务端资源的浪费

三次握手可以防止客户端无效连接信息再次到达服务器，导致重新连接

4. TCP为什么是四次挥手

之所以需要四次挥手，因为半关闭

tcp通道允许双方互相发送数据，数据是双向流动的。在关闭管道的时候，就需要关闭两次

一次是关闭 client --> server；另一次是关闭 client <-- server

每次关闭都需要执行两步操作：1.发出断开请求，2.确认断开请求

TCP流量控制

接收方通过窗口（Window）的大小来控制发送方的发送速率，防止发送方发送过多数据导致接收方无法处理

上图中，rwnd就是接收方对发送方数据发送窗口大小的控制

需要注意的是，如果接收方没有多余的空间接收数据，会控制发送方的发送窗口大小为0，此时发送方不会发送数据

当接收方缓存空间存在剩余，才会重新控制发送方的窗口大小，接收方发送窗口非零通知

但是，接收方的发送的非零通知在传输过程中丢失了，那么就会出现双方等待彼此发送数据，进而导致死锁现象发生

针对非零窗口通知丢失问题，数据发送方会开启计时器，如果在计时器内没有收到非零窗口通知，那么接收方会发送探测报文，查看接收方是否有剩余空间用于接收数据。

往复如是，直到发送方窗口大小设置非零

通过计时器的方式能够较好的解决非零通知数据传递丢失的问题

TCP拥塞控制

1. 为什么需要拥塞控制

简单来说，网络负载是优先的，如果短时间内涌入大量请求，远远超出了网络承受能力，网络可能会出现瘫痪

就像弹簧一样，一旦过度拉伸，弹簧就丧失了弹性

2. 控制手段

• 慢启动（Slow Start）：

  • 因为在网络初期，不了解接收端对网络数据的接收能力，一次性涌入大量数据可能会导致网络瘫痪，因此先发送少量数据，然后倍增，呈现指数上涨
  • 过程： 发送端初始设定一个拥塞窗口（cwnd），每经过一个往返时间（RTT），拥塞窗口大小加倍。随着时间的推移，数据发送速率逐渐增大，呈现指数增长。

• 拥塞避免（Congestion Avoidance）：

  • 避免过度快速增大拥塞窗口，维持网络的稳定性。
  • 过程： 当慢启动阶段结束后，cwnd的增长方式从指数变为线性。在拥塞避免阶段，每当接收到一个新的ACK时，cwnd按比例增加

• 快速重传（Fast Retransmit）：

  • 提高数据传输的可靠性，及时识别并快速补发丢失的数据包，减少不必要的等待时间，防止发送方误以为网络瘫痪，将cwnd置为1，启动慢开始算法，从而提升整体传输效率
  • 过程： 当发送端收到三个相同的确认（Duplicate ACK）时，就认为有一个数据包丢失，立即重传该数据包而不等待超时。

• 快速恢复（Fast Recovery）：

  • 在发生数据包丢失后，快速调整拥塞窗口以减小对网络的压力，同时尽快恢复数据传输，使网络能更快地回到稳定状态
  • 过程： 在快速重传后，拥塞窗口减半，然后进入拥塞避免阶段。

• 有关快速重传的不中补充

TCP连接建立过程中出现丢包

TCP连接过程，需要经历三次握手。此时如果出现丢包问题，数据发送方会等待对方的确认信息，如果超过预定时间还没有接收到信息，则会进行超时重传

如果是第一次、第二次握手，重传可以理解，因为这两次的握手都是建立在对方回应的基础上才能进行的。但如果是第三次握手信息丢包呢？客户端发送ACK确认信息给服务端，但该条信息丢失了，而第三次握手服务端无需确认，那客户端如何感知到呢？

如果ACK成功送达服务端，服务端会将TCP连接状态更改为ESTABLISHED，并准备接收客户端的数据。客户端可以通过尝试发送数据来检验连接是否已建立。如果服务端成功接收了数据且没有返回错误（如RST报文），则可以推断ACK报文已经成功发送；否则认为连接建立失败，重新发送ACK