TCP相关问题总结

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

慢启动（Slow Start）：
- 因为在网络初期，不了解接收端对网络数据的接收能力，一次性涌入大量数据可能会导致网络瘫痪，因此先发送少量数据，然后倍增，呈现指数上涨
- 过程：发送端初始设定一个拥塞窗口（cwnd），每经过一个往返时间（RTT），拥塞窗口大小加倍。随着时间的推移，数据发送速率逐渐增大，呈现指数增长。
拥塞避免（Congestion Avoidance）：
- 避免过度快速增大拥塞窗口，维持网络的稳定性。
- 过程：当慢启动阶段结束后，cwnd的增长方式从指数变为线性。在拥塞避免阶段，每当接收到一个新的ACK时，cwnd按比例增加
快速重传（Fast Retransmit）：
- 提高数据传输的可靠性，及时识别并快速补发 丢失的数据包，减少不必要的等待时间，防止发送方误以为网络瘫痪，将cwnd置为1，启动慢开始算法，从而提升整体传输效率
- 过程：当发送端收到三个相同的确认（Duplicate ACK）时，就认为有一个数据包丢失，立即重传该数据包而不等待超时。
快速恢复（Fast Recovery）：
- 在发生数据包丢失后，快速调整拥塞窗口以减小对网络的压力，同时尽快恢复数据传输，使网络能更快地回到稳定状态
- 过程：在快速重传后，拥塞窗口减半，然后进入拥塞避免阶段。

有关快速重传的不中补充

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

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

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