详细了解TCP连接的“3次握手”和“4次挥手”前言TCP的3次握手(Three-Way Handshake )1. ) 3次握手)详情2.「3次握手”的易懂理解3 .为什么第3次握手TCP
前言
在客户端和服务器之间发送和接收数据的过程中，需要创建名为TCP连接的连接；
因为TCP不存在连接概念，而只存在请求和响应，所以所有请求和响应都是包，它们之间有通道，例如从TCP创建的客户端开始并由服务器接收的连接，http请求始终保持不变
一个TCP连接可以发送多个http请求。 这个模式因版本而异。
在HTTP/1.0中，此TCP连接在创建http请求时同步创建，http请求发送到服务器端，在服务器端做出响应后，此TCP连接将关闭。
在HTTP/1.1中，该连接一直被保持，并且可以用某种方式声明一个请求已经被传输，然后另一个请求正在被传输。 这种优势表明，在建立TCP连接的过程中需要“三次握手”的消费，“三次握手”有三次互联网传输。
如果保持TCP连接，则第二次请求发送没有这种“三次握手”的消耗。 HTTP/2还允许通过同一TCP连接同时传输http请求。 重要字段如下：
(1)序列号(Sequence number ) :标识seq序列号，占32位，从TCP源端发送到目的端的字节流，在启动器发送数据时将其标记。
)2)确认号)确认号):Ack号占32位，只有在Ack标志位为1时，确认号字段才有效，Ack=Seq 1。
)3)标志位(Flags )共计六个，即URG、ACK、PSH、RST、SYN、FIN等。 具体含义如下。
URG :“紧急指针”(urgent pointer )有效。 ACK :确保序列号有效。 PSH :接收方应该尽快将此消息传递给APP应用层。 RST :重置连接。 SYN :开始新连接。 FIN :释放连接。 需要注意的是：
请不要将确认编号Ack与标志位的Ack混淆。 确认侧Ack=启动器Seq 1，两端对。 TCP三次握手(Three-Way Handshake )1.“三次握手”的细节是所谓的三次握手，即建立TCP连接。 此连接必须一个主动打开，另一个被动打开。
以下是客户机主动开始连接的情况。
握手之前主动打开连接的客户端将退出关闭阶段，被动打开的服务器端也将退出关闭阶段，进入侦听阶段。 之后，开始了“三次握手”:
(1)首先，客户端向服务器端发送TCP消息，其中：
标记为SYN，表示“请求建立新连接”。 序列号为seq=x(x通常为1 )； 然后，客户端进入同步阶段。 )2)服务器端在接收到客户端的TCP消息后，结束侦听阶段。 返回TCP消息。 现在，如下所示。
标志为SYN和ACK，“确认客户端消息Seq序列号有效，服务器成功接收客户端发送的数据，并同意创建新连接”(即，确认服务器收到了您的数据) 序列号为Seq=y； 确认号为Ack=x 1，表示接收客户机序列号Seq，并将该值加1作为自己的确认号Ack的值，然后服务器端进入SYN-RCVD阶段。 )3)客户端从服务器端接收到确认接收数据的TCP消息后，表明客户端到服务器的数据传输正常，结束同步阶段。 返回最后一条TCP消息。 其中：
标志为ACK，表示“确认服务器端收到了同意连接的信号”。 (也就是说，告诉服务器，他知道他收到了你发送的数据。 ）
序列号为Seq=x 1，表示接收服务器端的确认编号Ack，并将该值作为自己的序列号值。确认编号为Ack=y 1，表示接收服务器端编号Seq，并将该值加1作为自己的确认编号Ack的值，然后单击Clara 服务器从客户端接收到“确认服务器数据接收”的TCP消息后，表明服务器向客户端的数据传输正常。 结束同步阶段，进入ESTABLISHED阶段。
在客户和服务器侧传输的TCP消息中，两个确认号码Ack和号码Seq的值基于相互的Ack和号码Seq的值来计算，确保TCP消息传输的一致性。 如果其中一条TCP消息丢失，则无法继续“握手”，从而保证“握手三次”的顺利完成。
然后，客户端和服务器端进行正常的数据传输。 这就是“三次握手”的过程。
2 .“三次握手”的通俗理解
举板栗，把客户端比喻成男孩，把服务器比喻成女孩。 在他们的交往中说明“三次握手”的过程：
)1)男孩喜欢女孩，给女孩写信，说：“我爱你。 请交往。 写信后，男孩焦急地等着。 因为我不知道信能不能很好地传达给女孩子。
)2)女孩收到男孩寄来的情书后，心情激动。 我们是两情相悦的。 于是给男孩写了回信。 我收到了你的情书。 我也理解你的心情。 其实，我也喜欢你。 我想和你交往！
>写完信之后，女孩也焦急地等待，因为不知道回信能否能顺利传达给男孩。（3）男孩收到回信之后很开心，因为发出的情书女孩收到了，并且从回信中知道了女孩喜欢自己，并且愿意和自己交往。然后男孩又写了一封信告诉女孩：你的心意和信我都收到了，谢谢你，还有我爱你！
女孩收到男孩的回信之后，也很开心，因为发出的情书男孩收到了。由此男孩女孩双方都知道了彼此的心意，之后就快乐地交流起来了~~
这就是通俗版的“三次握手”，期间一共往来了三封信也就是“三次握手”，以此确认两个方向上的数据传输通道是否正常。
3.为什么要进行第三次握手为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了SYN=1创建连接的请求(第一次握手)。
如果服务器端就直接创建了这个连接并返回包含SYN、ACK和Seq等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。
客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，
服务器端是不知道客户端有没有接收到服务器端返回的信息的。
这个过程可理解为：
这样没有给服务器端一个创建还是关闭连接端口的请求，服务器端的端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。那么服务器端上没有接收到请求数据的上一个端口就一直开着，长此以往，这样的端口多了，就会造成服务器端开销的严重浪费。
还有一种情况是已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误。
所以我们需要“第三次握手”来确认这个过程，让客户端和服务器端能够及时地察觉到因为网络等一些问题导致的连接创建失败，这样服务器端的端口就可以关闭了不用一直等待。
也可以这样理解：“第三次握手”是客户端向服务器端发送数据，这个数据就是要告诉服务器，客户端有没有收到服务器“第二次握手”时传过去的数据。若发送的这个数据是“收到了”的信息，接收后服务器就正常建立TCP连接，否则建立TCP连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。
TCP的四次挥手（Four-Way Wavehand） 1.“四次挥手”的详解挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”：
（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：
注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。
（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：
标记位为ACK，表示“接收到客户端发送的释放连接的请求”；序号为Seq=V；确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段
前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：
标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。序号为Seq=W；确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。
（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：
标记位为ACK，表示“接收到服务器准备好释放连接的信号”。序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。随后客户端开始在TIME-WAIT阶段等待2MSL 为什么要客户端要等待2MSL呢？见后文。服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。
客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。
后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。
2.“四次挥手”的通俗理解举个栗子：把客户端比作男孩，服务器比作女孩。通过他们的分手来说明“四次挥手”过程。
“第一次挥手”：日久见人心，男孩发现女孩变成了自己讨厌的样子，忍无可忍，于是决定分手，随即写了一封信告诉女孩。“第二次挥手”：女孩收到信之后，知道了男孩要和自己分手，怒火中烧，心中暗骂：你算什么东西，当初你可不是这个样子的！于是立马给男孩写了一封回信：分手就分手，给我点时间，我要把你的东西整理好，全部还给你！男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好。“第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，于是再次写信给男孩：你的东西我整理好了，快把它们拿走，从此你我恩断义绝！“第四次挥手”：男孩收到女孩第二封信之后，知道了女孩收拾好东西了，可以正式分手了，于是再次写信告诉女孩：我知道了，这就去拿回来！ 这里双方都有各自的坚持。女孩自发出第二封信开始，限定一天内收不到男孩回信，就会再发一封信催促男孩来取东西！男孩自发出第二封信开始，限定两天内没有再次收到女孩的信就认为，女孩收到了自己的第二封信；若两天内再次收到女孩的来信，就认为自己的第二封信女孩没收到，需要再写一封信，再等两天…..
倘若双方信都能正常收到，最少只用四封信就能彻底分手！这就是“四次挥手”。
为什么“握手”是三次，“挥手”却要四次？TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。
即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。
TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？
建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。所以是“三次握手”，“四次挥手”。
为什么客户端在TIME-WAIT阶段要等2MSL?为的是确认服务器端是否收到客户端发出的ACK确认报文
当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。