一、三次握手

（1）第一次握手：Client进入SYN_SENT状态，发送一个SYN帧来主动打开传输通道，该帧的SYN标志位被设置为1，同时会带上Client分配好的SN序列号，该SN是根据时间产生的一个随机值，通常情况下每间隔4ms（毫秒）会加1。除此之外，SYN帧还会带一个MSS（最大报文段长度）可选项的值，表示客户端发送出去的最大数据块的长度。

（2）第二次握手：Server在收到SYN帧之后，会进入SYN_RCVD状态，同时返回SYN+ACK帧给Client，主要目的在于通知Client“Server已经收到SYN消息，现在需要进行确认”。Server发出的SYN+ACK帧的ACK标志位被设置为1，其确认序号AN（Acknowledgment Number）值被设置为Client的SN+1；SYN+ACK帧的SYN标志位被设置为1，SN值为Server生成的SN序号；SYN+ACK帧的MSS（最大报文段长度）表示的是Server的最大数据块长度。

（3）第三次握手：Client在收到Server的第二次握手SYN+ACK确认帧之后，首先将自己的状态从SYN_SENT变成ESTABLISHED，表示自己方向的连接通道已经建立成功，Client可以发送数据给Server了。然后，Client发ACK帧给Server，该ACK帧的ACK标志位被设置为1，其确认序号AN（Acknowledgment Number）值被设置为Server的SN+1。还有一种情况，Client可能会将ACK帧和第一帧要发送的数据合并到一起发送给Server。Server在收到Client的ACK帧之后会从SYN_RCVD状态进入ESTABLISHED状态。至此，Server方向的通道连接建立成功。Server可以发送数据给Client，TCP的全双工连接建立完成。三次握手的交互过程如图

Client和Server完成了三次握手后，双方就进入数据传输阶段。数据传输完成后，连接将断开。连接断开的过程需要经历四次挥手。

二、四次挥手

在TCP连接开始断开（或者拆接）的过程中，连接的每个端都能独立、主动地发起。四次挥手的具体过程如下：

（1）第一次挥手：主动断开方（可以是客户端，也可以是服务端），向对方发送一个FIN结束请求报文，此报文的FIN位被设置为1，并且正确设置Sequence Number（序列号）和AcknowledgmentNumber（确认号）。发送完成后，主动断开方进入FIN_WAIT_1状态，表示主动断开方没有业务数据要发送给对方，准备关闭Socket连接了。

（2）第二次挥手：正常情况下，在收到了主动断开方发送的FIN断开请求报文后，被动断开方会发送一个ACK响应报文，报文的Acknowledgment Number（确认号）值为断开请求报文的SequenceNumber（序列号）加1，该ACK确认报文的含义是：“我同意你的连接断开请求”。之后，被动断开方就进入了CLOSE-WAIT（关闭等待）状态，TCP服务会通知高层的应用进程，对方向本地方向的连接已经关闭，已经没有数据要发送了，若本地还要发送数据给对方，对方依然会接收。被动断开方的CLOSE-WAIT（关闭等待）还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。主动断开方在收到了ACK报文后，由FIN_WAIT_1转换成FIN_WAIT_2状态。

（3）第三次挥手：在发送完成ACK报文后，被动断开方还可以继续完成业务数据的发送，待剩余数据发送完成或者CLOSE-WAIT（关闭等待）截止后，被动断开方会向主动断开方发送一个FIN+ACK结束响应报文，表示被动断开方的数据都发送完了，然后被动断开方进入LAST_ACK状态。

（4）第四次挥手：主动断开方收到FIN+ACK断开响应报文后，还需要进行最后的确认，向被动断开方发送一个ACK确认报文，然后自己就进入TIME_WAIT状态，等待超时后最终关闭连接。处于TIME_WAIT状态的主动断开方在等待完成2MSL的时间后，如果期间没有收到其他报文，则证明对方已正常关闭，主动断开方的连接最终关闭。被动断开方在收到主动断开方的最后ACK报文以后，最终关闭连接，什么也不用管了。四次挥手的全部交互过程如图

处于TIME_WAIT状态的主动断开方在等待2MSL时间后才真正关闭连接通道。2MSL翻译过来就是两倍的MSL。MSL（Maximum Segment Lifetime）指的是一个TCP报文片段在网络中的最大存活时间，2MSL就是一次消息来回（一个发送和一个回复）所需的最大时间。如果直到2MSL主动断开方都没有再一次收到对方的报文（如FIN报文），则可以推断ACK已经被对方成功接收。此时，主动断开方将最终结束自己的TCP连接。所以，TCP的TIME_WAIT状态也称为2MSL等待状态。

有关MSL的具体时间长度，在RFC1122协议中推荐为2分钟，在SICS（瑞典计算机科学院）开发的一个小型开源的TCP/IP协议栈——LwIP开源协议栈中默认为1分钟，在源自Berkeley的TCP协议栈实现中默认为30秒。总体来说，TIME_WAIT（2MSL）等待状态的时间长度一般维持在1~4分钟。通过三次握手建立连接和四次挥手拆除连接，一次TCP的连接建立及拆除至少进行7次通信，可见其成本是很高的。

三、常见面试题

问题（1）：为什么关闭连接时需要四次挥手，而建立连接却只要三次握手？

关闭连接时，被动断开方在收到对方的FIN结束请求报文时很可能没有发送完业务数据，并不能立即关闭连接，被动方只能先回复一个ACK响应报文，告诉主动断开方：“你发的FIN报文我收到了，只有等到我所有的业务报文都发送完了，我才能真正结束，在结束之前，我会发给你FIN+ACK报文的，你先等着”。所以，被动断开方的确认报文需要拆成两步，故总共需要四次挥手。在建立连接场景中，Server的应答可以稍微简单一些。当Server收到Client的SYN连接请求报文后，其中ACK报文表示对请求报文的应答，SYN报文表示服务端的连接也已经同步开启了，而ACK报文和SYN报文之间不会有其他报文需要发送，故而可以合二为一，可以直接发送一个SYN+ACK报文。所以，在建立连接时，只需要三次握手即可。

问题（2）：为什么连接建立的时候是三次握手，可以改成两次握手吗？

三次握手完成两个重要的功能：一是双方都做好发送数据的准备工作，而且双方都知道对方已准备好；二是双方完成初始SN序列号的协商，双方的SN序列号在握手过程中被发送和确认。如果把三次握手改成两次握手，可能发生死锁。两次握手的话，缺失了Client的二次确认ACK帧，假想的TCP建立连接时的二次挥手可以如图所示。

在假想的TCP建立连接时的二次握手过程中，Client给Server发送一个SYN请求帧，Server收到后发送确认应答SYN+ACK帧。按照两次握手的协定，Server认为连接已经成功地建立，可以开始发送数据帧。在这个过程中，如果确认应答SYN+ACK帧在传输中被丢失，Client没有收到，Client将不知道Server是否已准备好，也不知道Server的SN序列号，Client认为连接还未建立成功，将忽略Server发来的任何数据分组，会一直等待Server的SYN+ACK确认应答帧。Server在发出的数据帧后，一直没有收到对应的ACK确认后就会产生超时，重复发送同样的数据帧。这样就形成了死锁。

问题（3）：为什么主动断开方在TIME-WAIT状态必须等待2MSL？

原因之一：主动断开方等待2MSL的时间是为了确保两端都能最终关闭。假设网络是不可靠的，被动断开方发送FIN+ACK报文后，其主动方的ACK响应报文有可能丢失，这时的被动断开方处于LAST-ACK状态，由于收不到ACK确认被动方一直不能正常地进入CLOSED状态。在这种场景下，被动断开方会超时重传FIN+ACK断开响应报文，如果主动断开方在2MSL时间内收到这个重传的FIN+ACK报文，就会重传一次ACK报文，然后再一次重新启动2MSL计时等待，这样就能确保被动断开方能收到ACK报文，从而能确保被动方顺利进入CLOSED状态。只有这样，双方才都能够确保关闭。反过来说，如果主动断开方在发送完ACK响应报文后不是进入TIME_WAIT状态去等待2MSL时间，而是立即释放连接，则将无法收到被动方重传的FIN+ACK报文，所以不会再发送一次ACK确认报文，此时处于LAST-ACK状态的被动断开方无法正常进入CLOSED状态。

原因之二：防止“旧连接已失效的数据报文”出现在新连接中。主动断开方在发送完最后一个ACK报文后再经过2MSL才能最终关闭和释放端口。这就意味着，相同端口的新TCP新连接需要在2MSL的时间之后才能够正常建立。2MSL这段时间内，旧连接所产生的所有数据报文都已经从网络中消失了，从而确保下一个新的连接中不会出现这种旧连接请求报文。

问题（4）：如果已经建立了连接，但是Client端突然出现故障了怎么办？

TCP还设有一个保活计时器，Client如果出现故障，Server不能一直等下去，这样会浪费系统资源。每收到一次Client的数据帧后，Server的保活计时器都会复位。计时器的超时时间通常设置为2小时，若2小时还没有收到Client的任何数据帧，Server就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没有反应，Server就认为Client出了故障，接着关闭连接。如果觉得保活计时器的两个多小时的间隔太长，可以自行调整TCP连接的保活参数。

从书上截取一段TCP三次握手和四次挥手相关推荐

TCP 三次握手和四次挥手
概述我们都知道 TCP 是可靠的数据传输协议,UDP是不可靠传输,那么TCP它是怎么保证可靠传输的呢?那我们就不得不提 TCP 的三次握手和四次挥手. 三次握手下图为三次握手的流程图下面通过我 ...
硬不硬你说了算！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题
来自:小林coding 每日一句英语学习,每天进步一点点: 前言不管面试 Java .C/C++.Python 等开发岗位, TCP 的知识点可以说是的必问的了. 任 TCP 虐我千百遍,我仍待 T ...
握手失败_拜托了，看完这篇别再问我什么是TCP三次握手和四次挥手
TCP三次握手和四次挥手的问题在面试中是最为常见的考点之一.很多读者都知道三次和四次,但是如果问深入一点,他们往往都无法作出准确回答. 三次握手如何建立连接? 三次握手建立链接从图中可以清楚的看到, ...
TCP三次握手、四次挥手、socket，tcp，http三者之间的区别和原理
接着上一篇文章叙述: TCP/IP连接(在互联网的通信中,永远是客户端主动连接到服务端): 手机能够使用联网功能是因为手机底层实现了TCP/IP协议,可以使手机终端通过无线网络建立TCP连接.TCP协 ...
脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手
转自即时通讯网:http://www.52im.net/ 1.引言网络编程中TCP协议的三次握手和四次挥手的问题,在面试中是最为常见的知识点之一.很多读者都知道"三次"和&quo ...
图解TCP三次握手和四次挥手！(简单易懂)
哈喽:亲爱的小伙伴,首先祝大家五一快乐~ 本来打算节日 happy 一下就不发文了,但想到有些小伙伴可能因为疫情的原因没出去玩,或者劳逸结合偶尔刷刷公众号,所以今天就诈尸更新一篇干货,给大家解解闷~ ...
40张图全面解析TCP 三次握手和四次挥手
每日一句英语学习,每天进步一点点: 前言不管面试 Java .C/C++.Python 哪种语言的开发岗位, TCP 的知识点可以说是的必问的了. 任 TCP 虐我千百遍,我仍待 TCP 如初恋. ...
跟着动画学习 TCP 三次握手和四次挥手
TCP三次握手和四次挥手的问题在面试中是最为常见的考点之一.很多读者都知道三次和四次,但是如果问深入一点,他们往往都无法作出准确回答. 本篇尝试使用动画来对这个知识点进行讲解,期望读者们可以更加简单地 ...
吊打面试官！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题
作者 | 小林coding 来源 | 小林coding(ID:CodingLin) 不管面试 Java .C/C++.Python 等开发岗位, TCP 的知识点可以说是的必问的了. 任 TCP 虐我 ...

从书上截取一段TCP三次握手和四次挥手

一、三次握手

二、四次挥手

三、常见面试题

从书上截取一段TCP三次握手和四次挥手相关推荐

最新文章

热门文章