TCP三次握手与四次挥手

最新推荐文章于 2021-07-19 10:43:12 发布

can_chen

最新推荐文章于 2021-07-19 10:43:12 发布

阅读量488

点赞数 4

CC 4.0 BY-SA版权

分类专栏：网络文章标签：网络协议网络 TCP 三次握手四次挥手

本文链接：https://blog.youkuaiyun.com/can_chen/article/details/106053881

网络专栏收录该内容

2 篇文章

订阅专栏

TCP属于传输层协议，是整个TCP/IP协议族中最重要的协议之一。它在IP提供的不可靠数据服务的基础上为应用程序提供了一个可靠的 、面向连接的 、全双工 的数据传输服务。

TCP报文格式

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hmQPuIZC-1589179010526)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20200511011051992.png)]$

序列号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表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

注意：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

三次握手

所谓三次握手，即建立TCP连接，需要客户端和服务端总共发送至少三个包确认连接的建立。

图解：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pjjfse2J-1589179010529)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20200511011505017.png)]$

第一次握手： 客户端将同步标志位SYN置为1，表示想与服务端建立连接，并随机产生一个序列号值seq为x的TCP数据包发送给服务端

第二次握手： 服务器端接收到来自客户端的TCP报文之后，将标志位SYN和ACK置为1，表示“确认客户端的报文seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”，并且向客户端发送一个确认号ack为x+1,序列号seq为随机产生的TCP数据包

第三次握手： 客户端接收到服务器端发送的SYN+ACK包，将标志位为ACK置为1，表示“确认收到服务器端同意连接的信号”，并向服务器发送一个确认号ack为y+1,序列号seqx+1的确认包，此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手

为什么是三次握手，四次握手可以吗？

第一次握手： 服务端可以确认客户端的发送能力正常

第二次握手： 客户端可以确认服务端的发送能力和接收能力正常

第三次握手： 服务端可以确认客户端的接收能力正常

也就是说，通过三次握手已经可以确认双方收发功能都正常，保证了TCP的可靠性，四次握手当然也可以只是是显得比较多余。

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

如果使用的是两次握手进行连接，那么客户端可以知道服务端具有发送和接收能力，但是服务端只能知道客户端具有发送能力，无法知道客户端是否具有接收能力；这样子一来，TCP就是不可靠的了。因此第三次握手并不是多余的，通过第三次握手，客户端给服务端发送一个回应，表示自己已经接收到服务端的确认了，这也证明了客户端是有接收能力的。
我们模拟这样一个场景：假设客户端第一次发送一个连接请求到服务端，但是在中途由于网络堵塞的原因，该请求并没有按时到达服务端，那么客户端在规定时间内还没有收到服务端的确认响应，就会认为此次连接失败，因此会重新发送一个连接请求至服务端（这就是“超时重传”机制，也是能保证TCP实现可靠性的一个重要原因），如果第二次请求按时到达服务端，服务端给客户端发送一个确认，至此二次握手连接完成。当客户端第一次连接请求在网络畅通后又会继续发送到服务端，服务端接收到这个“姗姗来迟”的请求就会误以为是客户端又发送一个新的连接请求来了，那么就会给客户端发送一个回应，但是客户端认为自己并没有发送给服务端新的连接请求，因此不会去理会服务端这个确认，如果是二次握手，那么服务端在发送给客户端一个确认之后，就会认为连接已经完成，因此就会给客户端发送数据，但是客户端是一直不理会这些数据的，服务端也会分配一些资源等待客户端发送数据过来，但是客户端却一直没有发送。因此会给服务端造成很大的资源浪费。如果使用的是三次握手，那么服务端在发送给客户端一个确认之后，还会等待客户端的回应之后才算连接建立完成。因此在这个场景中，如果使用的是三次握手，那么如果客户端不理会服务端的确认，服务端在等待一段时间就会放弃连接了，不会造成资源的浪费。

TCP的三次握手是否可以携带数据？

(以下摘抄自百度）

第一次和第二次是不可以携带数据的，但是第三次是可以携带数据的。

假如第一次握手可以携带数据的话，那对于服务器是不是太危险了，有人如果恶意攻击服务器，每次都在第一次握手中的SYN报文中放入大量数据。而且频繁重复发SYN报文，服务器会花费很多的时间和内存空间去接收这些报文。

第三次握手，此时客户端已经处于ESTABLISHED状态。对于客户端来说，他已经建立起连接了，并且已经知道服务器的接收和发送能力是正常的。所以也就可以携带数据了。

TCP协议运行时包含哪几个阶段

TCP协议运行时包含连接创建、数据传输、连接终止三个阶段

四次挥手

四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。

图解：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bsWZTBxa-1589179010531)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20200511135420700.png)]$

第一次挥手： 客户端将释放标志位FIN置为1，表示想与服务端释放连接，并向服务器端发送一段序列号值seq=u（随机）的TCP报文。随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。

第二次挥手： 服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，将确认标记位ACK置为1，表示“接收到客户端发送过来的释放连接请求”；并且向客户端发送一个确认号ack为u+1,序列号seq为随机产生的TCP数据包。随后服务器端开始准备释放服务器端到客户端方向上的连接。

客户端收到从服务器端发出的TCP报文之后，确认了服务器端收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段；前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

第三次挥手： 服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，将标记位FIN，ACK都置为1，表示“已经准备好释放连接了”。并再次向客户端发送一个确认号ack为u+1,序列号seq为随机产生的TCP数据包。注意：这里的ACK并不是确认收到服务器端报文的确认报文。 随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

第四次挥手： 客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，将确认标记位ACK置为1，表示“接收到服务器准备好释放连接的信号”。并且向服务端发送一个确认号ack为w+1,序列号seq为u+1为TCP数据包。随后客户端开始在TIME-WAIT阶段等待2MSL。服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。

后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。

为什么TIME-WAIT阶段要等待2MSL？

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

PS：在服务器发送了FIN-ACK之后，会立即启动超时重传计时器。客户端在发送最后一个ACK之后会立即启动时间等待计时器。

为什么“握手”（建立连接）是三次，“挥手”（释放连接）需要四次？

因为建立连接时，服务端接收到来自客户端的连接请求报文时，不需要做任何准备，就可以直接给客户端发送一个SYN建立连接报文与ACK确认接收报文，开始建立连接。而TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"挥手"传输的，之所以要分开传输是因为服务端突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

参考来源：https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc

（如果想看三次握手和四次挥手的通俗理解也可以参考该链接）