前言

最近服务端总是会出现一些CLOSE_WAIT的问题，因此抽时间了解并整理了TCP相关的知识点，说是详解其实也并不是， 仅仅把一些关键的东西列出来吧。

TCP详解

概述

TCP属于传输层的协议，提供面向连接的、端到端可靠的包传输。

三次握手

  • 客户端发送一个SYN（n）包到服务端，同时客户端进入SYN_SENT状态，等待服务端的应答
  • 服务端收到客户端的SYN包之后，必须确认ACK（n+1），并发出一个SYN（m）的包，此时服务器进入SYN_RECV状态
  • 客户端收到了服务器的SYN+ACK包之后，向服务发送确认报文ACK（m+1），此时客户端和服务端进入到ESTABLISHED的状态

四次挥手

  • 客户端发送释放连接的报文，并停止发送数据，此时客户端进入FIN_WAIT_1，等待服务端的确认
  • 服务端收到客户端的报文之后，会立即回复客户端收到报文了，同时进入CLOSE_WAIT的状态
  • 客户端收到服务端确认的报文之后，会立即进入FIN_WAIT_2的状态，由于服务端可能还有没有处理完的数据，因此客户端并不会立即回复客户端（这也是为什么需要4次挥手的原因）
  • 服务端将最后的数据处理并发送完之后，就会向客户端发送一个FIN包，此时服务端进入LAST_ACK的状态，同时客户端结束FIN_WAIT_2状态进入TIME_WAIT状态
  • 客户端在收到服务端的报文之后，会立即回一个ACK的报文，用于确定已经收到服务端要求结束的报文，同时进入TIME_WAIT状态
  • 服务端收到ACK的报文之后会立即终止，客户端在等待2MSL之后也会终止（之所以等待2MSL，是因为断开连接之后可能会收到迟到的报文）

拥塞避免

拥塞避免和流量控制是两种不同的语义，流量控制是点对点的，由接收方通过背压机制控制发送方的速率， 拥塞避免算法是考虑整个网络的承载能力，采用一定的机制防止向网络注入过多的流量。

TCP拥塞避免算法：

  • 慢开始：发送方拥塞窗口设置为1，每次收到确认报文之后将拥塞窗口提升为原来的2倍，直到拥塞窗口到达指定 的阈值，这个时候就进入了拥塞避免的阶段
  • 拥塞避免：该阶段是在拥塞窗口到达了指定的阈值之后，后续为避免网络拥塞将之前指数级别调整拥塞窗口的方式 调整为线性调整，每次只增大一个报文长度，这种阶段持续到无法接受到响应报文的出现，就会将阈值调整为当前拥塞 窗口的一般，并重新开始慢开始的流程
  • 快重传：接收方在接收到乱序报文之后，连续三次给发送方发送了同一个报文的确认报文，此时发送方不会等到重传 计时器超时而是直接再次给接收方发送下一个报文
  • 快恢复：这个过程是对慢开始的一种优化，在慢开始的流程中，确认报文在出现拥塞的时候流量是直接掉0，这里的 快恢复是流量在出现拥塞的时候将拥塞窗口降为原来的一半（此时阈值也是原来的一半），这样就直接进入了拥塞避免的 阶段，不再是慢开始阶段。

小结

上面的状态可以反过来进行记忆：SYN_SENT 可以极为SENT_SYN，CLOSE_WAIT可以记为WAIT_CLOSE等等，这样会比较方便