TCP三次握手与四次挥手的过程及原因

*本篇文章来彻彻底底的分析一下TCP三次握手与四次挥手的过程及原因。。。→_→*

1. TCP的连接建立——三次握手

   • 

   • 最初两端的TCP进程都处于CLOSED（关闭）状态。A主动打开连接，B被动打开连接

   • B的TCP**服务器进程创建传输控制块TCB（Transmission Control Block），然后处于LISTEN（收听）状态，准备接受客户端的连接请求**

   • A的TCP**客户端进程也创建传输控制块TCB，向B发出连接请求报文段，此报文段中同步位SYN=1，且选择一个初始序号seq=x**。TCP规定，SYN=1的报文段不能携带数据，但要消耗一个序号。此时A进入SYN-SENT（同步已发送）状态

   • B收到连接请求报文后，如果同意建立连接，则向A发送确认报文段，此报文段中SYN=1，确认位ACK=1，确认号为ack=x+1，同时选择一个初始序号seq=y。此报文段也不能携带数据，但同样要消耗一个序号。此时B进入SYN-RCVD（同步收到）状态

   • A收到B的确认报文段后，还要向B发送确认报文段。此报文段中ACK=1，ack=y+1，seq=x+1。TCP规定ACK报文段可以携带数据，但如果不携带数据则不消耗序号，所以下一个数据报文段的序号仍是seq=x+1。此时A进入ESTABLISHED（以建立连接）状态

   • 当B收到A的确认后，也进入ESTABLISHED（以建立连接）状态

2. TCP释放连接——四次挥手

   • 

   • A向B发送连接释放报文段并停止发送数据。此报文段中终止控制位FIN=1，seq=u（等于前面已传送过的数据的最后一个字节加1）。此时A进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据也要消耗一个序号

   • B收到连接释放报文段后就发出确认报文段。此报文段中确认号ack=u+1，seq=v（等于前面已传送过的数据的最后一个字节加1）。此时B进入CLOSE-WAIT（关闭等待）状态。TCP服务器进程通知应用进程，A到B的连接释放了，这时的TCP连接处于半关闭（half-close）状态，但B到A的连接并未关闭，此时B发数据，A仍要接收

   • A收到B的确认后，就进入FIN-WAIT2（终止等待2）状态，等待B发出的连接释放报文段

   • 如果B已没有要发送的数据，就发送连接释放报文段。此报文段中FIN=1，seq=w（在半关闭状态中B可能发送了数据），ack=u+1。此时B进入LAST-ACK（最后确认）状态

   • A收到了B的连接释放报文段后就发出确认报文段。此报文段中ACK=1，ack=w+1，seq=u+1。此时A进入TIME-WAIT（时间等待）状态

   • 此时TCP连接还没有释放掉，必须经过时间等待计时器（TIME-WAIT timer）设置的2倍的最长报文段寿命MSL（Maximum Segment Lifetime）后，A才进入到CLOSED状态。MSL建议设为2分钟。当A撤销相应的传输控制块TCB后，就结束了这次TCP连接

   • B收到A的确认报文，就进入CLOSEWD状态。B撤销相应的传输控制块TCB后，就结束了这次的TCP连接

3. 为什么要设置TIME-WAIT？

   • 原因一：保证A发送的最后一个ACK报文能够到达B。因为这个ACK报文有可能丢失，B收不到这个对FIN+ACK报文的确认，所以B就会超时重传这个FIN+ACK报文段，这样A就能在2MSL时间内收到重传的FIN+ACK，接着A再重传一次确认报文段，重新启动时间等待计时器

   • 原因二：A在发送完最后一个ACK报文段后，经过2MSL后，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失

4. 为什么是三次握手？

   • 为了防止已失效的连接请求报文段突然有送到了B，因而产生错误

   • 假设两次握手时，A发出的第一个请求连接报文段在某一网络节点长时间滞留，以致延误到连接释放后才到达B。B收到失效的连接请求报文段后，认为是A又发出一次新的连接请求。于是向A发送确认报文段，同意建立连接，此时在假定两次握手的前提下，连接建立成功。这样会导致B的资源白白浪费

   • 假设两次握手时，A发出一个请求报文段，但发送过后A就因为问题而导致下线。之后B收到了A发来的请求连接报文段，给A发送确认报文段，同意建立连接，此时在假定两次握手的前提下，连接建立成功。这样会导致B的资源白白浪费

5. 为什么是四次挥手？

   • TCP协议是全双工通信，这意味着客户端和服务器端都可以向彼此发送数据，所以关闭连接是双方都需要确认的共同行为

   • 假设是三次挥手时，首先释放了A到B方向的连接，此时TCP连接处于半关闭（Half-Close）状态，这时A不能向B发送数据，而B还是可以向A发送数据。如果此时A收到了B的确认报文段后，就立即发送一个确认报文段，这会导致B向A还在发送数据时连接就被关闭。这样会导致A没有完整收到B所发的报文段

6. 总结

   • 

   • 粗实线箭头表示客户端的正常变迁

   • 粗虚线箭头表示服务器的正常变迁

   • 细线箭头表示异常变迁