【面试必考】TCP协议“三次握手”与“四次挥手”

时间：2020-06-15 09:37:47

关键字： TCP

手机看文章

扫描二维码
随时随地手机看文章

[导读]引言从上一篇文章我们就知道TCP协议是提供面向连接的服务，无论哪一方向另一方发送数据之前，都必须先在双方之间建立连接，俗称“握手”，数据传送完成后要终止连接，俗称“挥手”。因此TCP是一种可靠的传输服务，但是正因为这样，也不可避免的增加了许多额

引言

从上一篇文章我们就知道TCP协议是提供面向连接的服务，无论哪一方向另一方发送数据之前，都必须先在双方之间建立连接，俗称“握手”，数据传送完成后要终止连接，俗称“挥手”。因此TCP是一种可靠的传输服务，但是正因为这样，也不可避免的增加了许多额外的开销，比如确认，流量控制等，那么我们今天就来说说它是怎么建立连接与终止连接的！

“三次握手”

首先建立连接的过程是由客户端发起，而服务器无时无刻都在等待着客户端的连接（服务器处于监听状态listen），TCP连接一般来说会经历以下过程，先来看个GIF图：

三次握手(图片来源网络)

第一步：客户端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段。该报文段中不包含任何应用层的数据，但是在报文段的首部中的SYN标志位会被置为1。因此，这个特殊报文段被称为SYN 报文段（握手请求报文）。另外，客户端会随机地选择一个初始序号（ISN，假设为 x，如动态图），并将此序号放置于该SYN报文段的序号字段 sqe中；但握手请求报文报文段中的ACK标志为0，所以此时它的确认序号 ack是无效的，是什么值我们也不用管。握手请求报文会被封装在一个IP数据报中，然后发送给服务器。此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号
第二步：服务器收到了客户端发出的SYN报文段，服务器便会从SYN报文段中提取对应的信息，为该TCP连接分配TCP缓存和变量来维护这个链接，（当然啦，这服务器必须得有内存来响应这个链接，很多时候服务器被攻击时就没空搭理这个链接了），并向该客户端返回一个允许连接的报文段（握手应答报文）。此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态，这个报文段同样也不包含任何应用层数据，但是，在报文段的首部却包含3个重要的信息。

SYN 与 ACK 标志都被置为 1。
将TCP报文段首部的确认序号 ack字段设置为 x+1，这个 x 是从握手请求报文中得到的。
服务器也会随机选择自己的初始序号ISN，注意此ISN是服务器端的ISN，假设为y，并将它放置到TCP报文段首部的序号字段中。

这个允许连接的报文段实际上表明了：“我收到了你发起建立连接的请求，初始序号为x，我同意建立该TCP连接，我自己的初始序号是y，确认序号是 x+1”。该允许连接的报文段有时会被称为SYN ACK报文段（SYN ACK segment），由于ACK标志位1，所以TCP报文段首部的窗口大小字段是有效的。TCP规定这个SYN ACK报文段也不能携带数据，但是同样要消耗一个序号。

第三步：当客户端收到服务器的握手应答报文后，还要给服务器返回一个应答报文 ，表示已经收到服务器的握手应答报文，应答报文中客户端会将ACK标志置1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态，而对于SYN标志，因为连接已经建立了，所以SYN标志会被置为0，同时客户端也要给该TCP连接分配缓存和变量来维护这个链接，将TCP报文段首部的确认序号字段设置为y+1，同时也将客户端自己的窗口大小告诉服务器。在握手的第三个阶段可以在报文段中携带数据，TCP规定，这个ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。

在完成握手后，客户端与服务器就建立了连接，同时双方都得到了彼此的窗口大小，序号等信息，然后客户端就可以和服务器开心地传输数据了，在链接过程中这些传输数据都是平等的，任何一方都可以随意传输数据到另一方，在传输TCP报文段的时候，每个TCP报文段首部的SYN标志都会被置0，因为它只用于发起连接，同步序号。

“四次挥手”

建立一个连接需要三次握手，而终止一个连接则需要经过 四次挥手，这由 TCP的特性造成的，因为 TCP协议可以提供全双工的传输服务，因此每个方向上的连接必须单独关闭。当客户端完成它的数据发送任务后就能发送一个 FIN报文段（终止连接请求报文段）来终止<客户端 -> 服务器>方向上的连接。当服务器收到一个 FIN报文段时，它必须通知应用层客户端已经终止了<客户端 -> 服务器>方向的连接，服务器一般也会选择关闭<服务器 -> 客户端>方向的连接。

一般来说，服务器是贪婪的，几乎不会主动断开<服务器 -> 客户端>方向的连接，所以很多时候都是客户端主动断开连接。客户端发送一个FIN报文段只意味着在这一<客户端 -> 服务器>方向上没有数据流动，而<服务器 -> 客户端>方向的连接仍是有效的，但是在实际应用中只有很少的 TCP应用程序才这样做。

四次挥手过程如下（有一个GIF上传不了，就算了）：

客户端发出一个FIN报文段主动进行关闭连接，此时报文段的FIN标志位为1，假设序号为u，一般来说ACK标志也会被置一，但此时确认序号字段是无效的（因为FIN标志位为1），此时，客户端进入FIN-WAIT-1（终止等待1）状态（关于TCP协议状态的内容到时候再慢慢讲吧，有点复杂）。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
当服务器收到这个 FIN报文段，它发回一个ACK报文段（此报文段是终止连接应答），确认序号为u+1，并且带上自己的序号v，和SYN一样，一个FIN将占用一个序号，此时已经断开<客户端 -> 服务器>的方向连接，但<服务器 -> 客户端>方向的连接仍然存在，并且服务器可以发送数据给客户端，客户端也必须接受这些数据，这时候服务器处于半关闭状态（CLOSE-WAIT），客户端收到服务器发送的ACK报文段后处于FIN-WAIT-2（终止等待2）状态。
一般来说服务器会向应用程序请求关闭与这个客户端的连接，接着服务器就会发送一个FIN报文段（这个报文段是服务器向客户端发出，请求终止连接），此时假设序号为w，ACK标志虽然也为1，但是确认序号字段也是无效的，此时，服务器则进入LAST_ACK状态（服务器等待对方接受关闭连接）。
客户端返回一个ACK报文段来确认终止（服务器的）连接的请求，ACK标志置一，并将确认序号设置为收到序号加1（w+1），此时断开<`服务器 -> 客户端 >方向上的连接。此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，才进入CLOSED状态。而服务器则在收到客户端的ACK报文段后立即进入CLOSED`状态。

四次挥手

补充

说明：至于为什么提及TCP状态，是为了结合图来写的（图片来源网络，我也没法改是不是），大家过一遍就好了，暂时也不用太深入了解，下一篇再写TCP状态转移~

提供点技术支持吧，不要纯理论分享了，为了更好的理解在整个TCP连接期间，TCP序列号和确认号是如何工作的，我们可以使用wireshark抓包工具内置的绘制流功能，先过滤IP地址，设置过滤规则为：ip.src == xxx.xxx.xxx.xxx or ip.dst == xxx.xxx.xxx.xxx，选择菜单栏中的 Statistics（统计） ->Flow Graph（流量图）绘制流功能，就能看到整个TCP协议连接的过程了（在第二张图的最右边是有注释的）。