秋招进行时——TCP/IP的三次握手与四次挥手

最新推荐文章于 2024-08-30 09:43:19 发布

cjl10123

最新推荐文章于 2024-08-30 09:43:19 发布

阅读量160

点赞数

分类专栏：面试及算法

本文链接：https://blog.csdn.net/cjl10123/article/details/98063811

版权

面试及算法专栏收录该内容

4 篇文章 0 订阅

订阅专栏

秋招进行时——TCP/IP的三次握手与四次挥手

三次握手
四次挥手
超时重传
拥塞控制
滑动窗口
参考

三次握手

在这里插入图片描述
在TCP三次握手中，在TCP头部中，有几个字段会被用到，先来理解一下几个缩写的意思：

标志位：

SYN：同步标志位，大小为1位。是客户端与服务端建立连接的握手信号（表示发送同步请求，我偏向理解为发送链接请求）;
ACK：确认标志位，大小为1位。仅当ACK=1时，确认号ack字段才有效（也表示收到SYN同步请求）；ACK=0时，确认号ack字段无效;

确认号和序列号

seq：序列号，用来标记数据段的顺序，大小为4字节（32位)。 在网络中，如果一条数据很长，是不可能一次性发送完的，需要将数据切成好几段来发送。因为TCP具有有序性，因此，就需要给几段数据加上序号，来确保有序性。TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。
ack：确认号，用来表示已经收到报文段，并期待收到对方下一个报文段的第一个数据字节的序号,大小为4字节（32位)。序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

三次握手过程

客户端向服务器端发送同步请求报文，表示客户端向服务器端请求建立链接。该请求报文中SYN=1，seq=x；此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
服务器端收到请求报文后，向客户端发送确认报文。确认报文中：ACK=1,SYN=1,ack=x+1,seq=y。因为SYN报文段需要消耗一个序号，因此客户端下一个报文段的seq是x+1,也是因为SYN报文段不携带数据，当前报文段的最后一个序号也就是第一个序号x，根据ack的定义，可以得知ack=x+1。 此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。确认报文也不能携带数据，但是同样要消耗一个序号。
客户端收到确认报文后，向服务器端发送确认报文。确认报文中ACK=1，seq=x+1，ack=y+1。（此时已经不需要用到SYN，而其余字段取值类似与第二步服务器向客户端发送的确认报文）此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
服务器收到客户端的确认报文，也进入ESTABLISHED状态，此后双方就可以开始通信了。

三次握手面试题：

最常考的当然是三次握手的过程，只要看懂上面的图和过程即可
为什么不是两次握手而是三次握手? 三次握手主要是避免一种情况：当客户端向服务端发送请求报文。但是因为网络原因，这个报文滞留在了网络中。假设是两次握手，因为客户端迟迟没有收到服务器发来的确认报文，于是向服务器端重新发送请求报文。此时服务器收到客户端新发送的请求报文，两次握手成功，建立连接，传送数据，关闭连接。恰好这时网络通畅了，之前滞留的报文传送到了服务器，服务器再返回确认报文，又建立了连接，但这个滞留的报文应该是失效的。但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。而三次握手则不会出现这样的情况。
三次握手有什么隐患：因为服务器需要收到客户端的确认报文，也就是第三次握手，才能建立连接。有的黑客就会模拟客户端向服务器端发送请求报文，但不进行第三次握手，占用服务器的SYN队列，以此来攻击服务器，使服务器SYN队列被占满，拒绝提供服务。解决方法：当SYN队列满时，服务器收到新的请求报文，则会回发SYN-cookies，客户端收到后，回发的确认报文也会有相应的回复。此时服务器收到，即使SYN队列已满，也会建立连接。

四次挥手

在这里插入图片描述

标志位：

FIN：终止标志位。FIN=1表示此报文的发送方的数据已经发送完毕，并要求释放连接。

四次挥手过程：

四次挥手可以是客户端发起的，也可以是服务器端发起的

假设是客户端先发起的连接释放请求，则当客户端数据发送完毕后，客户端向服务器发送连接释放报文段，连接释放报文段中：FIN=1，seq=u; 客户端最新一次发给服务器的报文段数据的最后一个字节序号为u-1；此时，客户端进入FIN-WAIT-1（终止等待1）状态。
服务器收到后，发还确认报文，确认报文段中：ACK=1，ack=u+1，seq=v。此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。。此时服务器端tcp通知高层应用进程，客户端向服务器的方向就释放了。但因为服务器端的数据可能还没发送完，因此需等待。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文，并接收服务器仍未发完的数据。
服务器发送完数据后，向客户端发送连接释放报文段，连接释放报文段中：FIN=1，ACK=1，ack=u+1，seq=w。此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端接收到连接释放报文段后，向服务器发送确认报文段，确认报文段中：ACK=1，ack=w+1，seq=u+1。进入了TIME-WAIT（时间等待）状态，并在等待2*MSL时间后，进入CLOSED状态
服务器端收到客户端的确认报文段后，立即进入CLOSED状态。关闭连接。服务器端比客户端早一点关闭连接。

四次挥手常见面试题

为什么会有TIME_WAIT状态？为什么要等待2MSL时间后才关闭连接

(1).确保有足够的时间让对方收到ACK包，如果被动释放连接端(上图中就是服务器端)没有收到确认ACK，则服务器端会重新发送连接释放报文段，客户端可以重新发送ACK包。因为报文段在tcp网络中的最大存活时间为MSL，如果服务器端要确认自己没有接收到ACK包，那么需要等待MSL的时间，然后再重新发送FIN包。保守考虑，则取客户端的TIME_WAIT状态为2MSL
(2).确保本次连接中残留在网络中的所有报文段都能消逝，可以避免新旧连接报文混乱。假设在旧连接结束后，客户端与服务器端又一次建立了新连接，如果没有等待2MSL时间，那么网络中残留的报文段仍可以通过新连接传送至目的地，导致无法区分是旧连接数据还是新连接数据。如：三次握手中已经失效的连接请求报文段