TCP三次握手和四次挥手

TCP

三次握手和四次挥手

三次握手

序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序列号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号便是报文段携带数据的第一个字节的编号；而确认号指的是期望接受到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效。

同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在相应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建立连接时才会被置1，握手完成后SYN标志位被置0。

终止FIN：用来释放一个连接。FIN=1表示：次报文段的发送方数据已经发送完毕，并要求释放连接

第一次握手：建立连接时，客户端发送syn包(seq=x)到服务器，并进入SYN_SENT状态，等待服务器确认

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），此时自己也发送一个SYN包(seq=y)，即SYN+ACK包，此时服务器进入SYN_RECV状态

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=y+1，seq=x+1）,此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功），完成是那次握手

四次挥手

第一次挥手：客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个自己的序号+1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

第二次挥手1：服务器收到连接释放报文，ACK=1，ack=u+1,并且带上自己的序列号seq=v，此时，服务器就进入CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候出于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

第二次挥手2：客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2(终止等待2)状态，等待服务器发送连接释放报文（在这之前还需要接收服务器发送的最后的数据）

第三次挥手：服务器将最后的数据发送完毕后，就向客户端发送连接释放报文。FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，嘉定此时的序列号为w，此时服务器就进入LAST-ACK（最后确认）状态，等待客户端的确认。

第四次挥手1：客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号seq=u+1，此时客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL(最长报文段寿命)的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

第四次挥手2：服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次TCP连接。可以看到，服务器结束的TCP连接的时间要比客户端早一些。

常见面试题

Q：为什么连接的时候时三次握手，关闭的时候却是四次握手？

三次握手时，服务器同时把ACK和SYN放在一起发送到了客户端哪里
四次挥手时，服务器收到客户端FIN报文时，仅仅表示客户端不再发送数据了，但还能接收数据，而服务器可能还有数据没有发送完毕，故而先向客户端发送一个ACK，待数据发送完毕了，再向客户端发送FIN，客户端收到服务端的FIN后，再向服务端发送ACK确认关闭

Q：为什么TIME-WAIT状态需要经过2MSL（最大报文段生存时间）才能返回到CLOSED状态

客户端需要保证最后一次发送的ACK报文到服务器，如果服务器未收到，可以请求客户端重发，这样客户端还有时间再发，重启2MSL计时。
服务端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文。
如果客户端在2MSL内，再次收到了来自服务器的FIN报文，说明服务端由于各种原因没有接收到客户端发出的ACK确认报文，客户端再次向服务端发送出ACK确认报文，计时器重置，重新开启2MSL的计时。
否则客户端在2MSL内没有再次收到服务器的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成四次挥手

Q：为什么不能用两次握手进行连接？

三次握手最主要的目的就是双方确认自己与对方的发送和接受时正常的
第一次握手，客户端：什么都确认不了；服务端：对方发送正常，自己接收正常
第二次握手：客户端：对方发送，接收正常，自己发送正常，接收正常；服务端：对方发送正常，自己接收正常
第三次握手：客户端：对方发送，接收正常，自己发送正常，接收正常；服务端：对方发送正常，接收正常，自己发送正常，接收正常

三次握手才可以阻止重复历史连接的初始化

客户端连续发送多次 SYN 建立连接的报文，在网络拥堵等情况下
一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；
那么此时服务端就会回一个 SYN + ACK 报文给客户端；
客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。
如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）
准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接：
如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；
如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接；

四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。

而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。

避免资源浪费
如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

 

详解 TCP 连接的“ 三次握手 ”与“ 四次挥手 ”

TCP的三次握手与四次挥手理解

关于三次握手和四次挥手