TCP三次握手和四次挥手

TCP数据包结构

• 源端口号（16位）
  标识源主机的一个应用进程（连同源主机的IP地址）
• 目的端口号（16位）
  标识目的主机的一个应用进程（连同目的主机IP地址）
  IP报头中的源主机IP地址、目的主机的IP地址、源端口、目的端口确定了唯一一条TCP连接。
• 顺序号seq（32位）
  标识TCP源端向TCP目的端发送的数据字节流，表示这个报文段中的第1个数据字节的顺序号。
  （1）如果把字节流看作在两个应用程序间的单项流动，则TCP用顺序号对每个字节进行技术。
  （2）在建立一个新的连接时，SYN标志变为1，顺序号字段包含由这个主机选择的该连接的初始顺序号ISN。
• 确认号ack（32位）
  存储发送确认的一端所期望收到的下一个顺序号。确认号是上次已成功收到的数据字节顺序号+1（ack = last seq + 1）。
  （1）只有ACK标志为1时确认序号字段才有效。
• TCP报头长度（4位）
  TCP最多有60字节的首部，正常长度是20字节。
• 保留位（6位）
  数据保留位，目前必须被设置为0
• 控制位（6位）
  在TCP报头中有6个标志比特，他们中多个可被同时设置为1
  （1）URG
  （2）ACK：为1时表示确认号有效。
  （3）PSH
  （4）RST
  （5）SYN：同步序号，为1时表示连接请求，用于建立连接，使顺序号同步
  （6）FIN：用于释放连接，为1时表示发送方已经没有数据要发送了

三次握手过程

• 客户端发送SYN(seq = x)报文给服务器端，进入SYN_SEND状态
• 服务器端收到SYN报文，回应一个SYN(seq = y)和ACK(ack = x + 1)报文，进入SYN_RECV状态。
• 客户端收到服务器端的SYN报文，回应一个ACK(ack = y + 1)报文，进入ESTABLISHED状态。

三次握手的原因

A→B

• 需要分别确认自己和对方的发送能力和接收能力正常。
  第一次握手A→B：B确认A的发送能力和B的接收能力
  第二次握手B→A：A确认B的发送能力和A的接收能力，并确认B确认了A的发送能力和B的接收能力
  第三次握手A→B：B确认A已经确认了能力。

• 报文生存时间往往会超过TCP请求的超时时间，A的某个超时连接请求报文可能会在双方释放连接后到达B，B误以为A创建了新的连接请求，发送确认报文创建连接。但由于A的状态不是SYN_SENT，将直接丢弃B的确认报文。如果是两次握手，连接建立，服务器资源被白白浪费；如果是三次握手，B由于长时间没有收到确认，最终超时导致连接失败，不会出现脏连接。

流量控制

如果应用程序读取速度较慢，而发送方发送太快，就会使接收缓存溢出，TCP通过流量控制解决该问题。
通过让发送方维护一个 接收窗口(rwnd) 的变量来提供流量控制。在返回的ACK中包含自己的接收窗口的大小，以此来控制发送方的数据发送。
接受窗口用于给发送方一个指示，该接收方还有多少可用的缓存空间。因为TCP是全双工通信，所以在连接两端的发送方都各自维护一个接收窗口。
当接收窗口=0时就不允许发送方发送数据。当接收方接收缓存有了存储空间，向发送方发送非零窗口通知报文，但该报文在传输中丢失。发送方一直等待通知，接收方一直等待数据，形成死锁。为解决该问题，TCP为每个连接设有持续计时器，只要TCP连接的一方接收到对方的零窗口通知，就启动该计时器，到时后发送一个零窗口探测报文，避免死锁。、
当接收方梳理数据很慢，应用进程间传送的有效数据很小，极端情况下，有效数据只有1Byte，传输开销却有40Byte（IP首部及TCP首部各20Byte），导致通信效率极低。为解决该问题，可以等到接收方有足够空间可以容纳一个最长报文段，或接收缓存已有一半空间再发送；发送方把数据积累成一个足够大的报文，或达到接收方缓存一半才发送。

拥塞控制

减少注入网络的数据，减轻路由器和链路负担，涉及网络中所有的路由器和主机。
TCP连接初始化，拥塞窗口cwnd设为1.

• 慢启动
  指数增长。cwnd按指数规律增长，直到cwnd==阈值，开始拥塞避免。
• 拥塞避免
  线性增长。cwnd按照线性规律增长。
• 快重传
  发生丢包，发送三个冗余ACK，拥塞窗口乘性减少。阈值更新为拥塞前的一半。
• 快恢复
  线性增长

四次挥手的原因

TCP在建立连接时要进行三次握手，断开时要进行四次挥手，这是由于TCP的半关闭状态造成的。因为TCP连接时全双工的，所以在进行关闭时对每个方向都要单独进行关闭。在一方完成他的数据发送任务时，就发送一个FIN来向另一方通告将要终止这个方向的连接。

四次挥手过程

• 客户端应用进程调用断开连接的请求，向服务器端发送一个终止标志位FIN = 1,seq = u的消息，表示在客户端关闭链路之前要发送的数据已经安全发送完毕，可以开始关闭链路操作，并请求服务器端确认关闭客户端到服务器的链路操作。此时客户端处于FIN-WAIT-1状态。
• 服务器收到这个FIN消息之后返回一个ACK=1，ack=u+1，seq=v的消息给客户端，表示接收到客户端断开链路的操作请求，这时TCP服务器端进程通知高层应用进程释放客户端到服务器端的链接，服务器处于CLOSE-WAIT状态，即半关闭状态。客户端收到消息之后处于FIN-WAIT-2状态。
• 服务器端将关闭链路前需要发送给客户端的消息发送给客户端，在等待该数据发送完成后，发送一个终止标志位FIN=1,ACK=1,seq=w,ack=u+1的消息给客户端，表示关闭链路前服务器需要向客户端发送的消息已经发送完毕，请求客户端确认关闭从服务器到客户端的链路操作，此时服务器端处于LAST-ACK状态，等待客户端最终断开链路。
• 客户端在接收到这个最终FIN消息后，发送一个ACK=1,seq=u+1,ack=w+1的消息给服务器端，表示接收到服务器端的断开连接请求并准备断开服务器端到客户端的连接。此时客户端处于TIME-WAIT状态，TCP连接还没有释放，然后经过**等待计时器(2MSL)**设置的时间后，客户端进入CLOSE状态。

四次挥手的原因

TCP是全双工通信，两个方向的连接需要单独断开。
我觉得还有原因是，客户端向服务端发送终止连接报文，但此时服务端还有数据没有发送完，因此不能立刻断开。

等待2MSL时间的原因

• 保证被动关闭方可以进入CLOSED状态。MSL是最大报文段寿命，等待2MSL可以保证主动关闭方发送的最后一个确认报文被被动关闭方接收，如果该报文丢失，被动关闭方会超时重传之间的FIN+ACK报文。如果主动关闭方在发送确认报文后立即释放连接，就无法收到被动关闭方可能超时重传的报文，也不会再次发送确认报文段，被动关闭方就无法正常进入CLOSED状态。
• 2MSL后，本连接中的所有报文就都会从网络中消失。之后的连接中不会出现过期报文。

TCP还设有一个保活计时器，用于解决客户端故障问题，服务器每收到一次数据，就会重新设置保活计时器，如果2小时内没收到数据，就间隔75秒发送一次探测报文，连续10次没有响应后关闭连接。

参考资料