TCP三次握手、四次挥手总结：

一、前言：

我们都知道TCP是面向连接的，三次握手就是用来建立连接的，四次握手就是用来断开连接的。

二、三次握手

6c94103cc7a852fdaa4e13f09a778d1.png

1、三次握手（专业）

• 1、第一次握手：客户端给服务器发送一个 SYN 报文。
• 2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。
• 3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。
• 4、服务器收到 ACK 报文之后，三次握手建立完成。

2、这里我顺便解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不可以？

• 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

这样回答其实也是可以的，但我觉得，这个过程的我们应该要描述的更详细一点，因为三次握手的过程中，双方是由很多状态的改变的，而这些状态，也是面试官可能会问的点。所以我觉得在回答三次握手的时候，我们应该要描述的详细一点，而且描述的详细一点意味着可以扯久一点。加分的描述我觉得应该是这样：

刚开始客户端处于 closed 的状态，服务端处于 listen 状态。然后
1、第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN（c）。此时客户端处于 SYN_Send 状态。

2、第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

3、第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised 状态。

4、服务器收到 ACK 报文之后，也处于 establised 状态，此时，双方以建立起了链接。

解释：
(1)SYN=1 表示该报文不携带数据，但消耗一个序号 seq=x，seq=x是客户端的初始化序列号，因为tcp是面向字节流的
(2)SYN=1 表示该报文不携带数据，但消耗一个序号 seq=y，seq=y是服务器的初始化序列号，ACK=1是一个确认号
ack=x+1，表示服务器下次接收到的序号希望是x+1。然后服务器进入到SYN-RCVD等待的状态
(3)ACK=1是一个确认号，seq=x+1是上一次服务器回应的序号要求，ack=y+1表示客户下一次接收到的序号希望是y+1

3、 三次握手的作用

1、确认双方的接受能力、发送能力是否正常。
2、指定自己的初始化序列号，为后面的可靠传送做准备。
3、如果是 https 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成到。

4、（ISN）是固定的吗？

• 三次握手的一个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。
• 如果ISN是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

5、什么是半连接队列

• 服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
• 这里在补充一点关于SYN-ACK 重传次数的问题：　服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超 过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s, 2s, 4s, 8s, …

6、三次握手过程中可以携带数据吗

• 很多人可能会认为三次握手都不能携带数据，其实第三次握手的时候，是可以携带数据的。也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

为什么这样呢？大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。
而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据页没啥毛病

7、为什么要进行三次握手？

• 当进行第一次握手，网络不好可能会堵塞，所以连接的请求并没有到达服务器端；
• 但是tcp连接有超时重传的机制，所以再一次发送请求，这时候服务器端接收到了你的请求，他也会返回一个请求给你，这是第二次握手；
  但是这时候网络环境突然又好了起来，那个堵塞的请求到达了服务器端，服务器端又给你回了一个请求，但是你又不想给服务器发送请求，这时候服务器的资源会进行占用等待你的请求，为了不使服务器的资源继续占用，你又必须发送一个请求给服务器；
  所以要进行3次握手

三、四次挥手

943deabb4eccab44a2bbc12b0891956.png

1、四次挥手

• 1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
• 2、第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
• 3、第三次挥手：如果服务端处理完自己的任务，也想断开连接了，发送一个 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
• 4、第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
• 5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

注意：这里特别需要主要的就是TIME_WAIT这个状态了，这个是面试的高频考点，就是要理解，为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。这其中的原因就是，要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 ACK 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。 至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文，则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。

2、为什么挥手需要四次？

• 由于 TCP 的半关闭（half-close）特性，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
• 任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

通俗的来说，两次握手就可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次握手。

举个例子：A 和 B 打电话，通话即将结束后，A 说 “我没啥要说的了”，B 回答 “我知道了”，于是 A 向 B 的连接释放了。但是 B 可能还会有要说的话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，于是 B 向 A 的连接释放了，这样整个通话就结束了。

3、为什么需要TIME_WAIT状态

主要是两方面：

• 防止错误接收历史报文
• 保证双方能够正常关闭

**防止错误接收历史报文**

• 1、tcp序列号可能会发生绕回问题，这就意味着无法通过tcp序列号来判断是不是历史报文。(时间戳可以解决是不是历史报文问题，时间戳还可以精确计算RTT)
• 2、假设没有TIME_WAIT状态，那么在关闭连接前有个报文被延迟了。关闭后，又重新建立了相同四元组的连接，此时前一个被延迟的数据包到达了(没有到达最大生存时间)，并且正好在接收窗口内，那么服务端就会错误接收，使得数据混乱。
• 3、因此有了这个TIME_WAIT字段，可以保证两边的历史数据都被丢弃了，以后的数据包都是新建立连接的。

**保证双方能够正常关闭**

• 1、如果没有TIME_WAIT状态的话，客户端最后一次发送ack应答报文后就进入了close阶段。如果服务端没有收到ack报文的话，就会重传FIN报文，而此时客户端已经close了，就会返回一个RST错误报文。
• 2、而有了TIME_WAIT状态的话，客户端并不会着急关闭，而是等待了2MSL再关闭，这样的话就算重传的fin报文也能正确响应，保证了服务端的正确关闭
• 3、这里客户端重新接收到了重发的fin报文，time_wait就会重置（也是为了重复报文的消失，不然的话ack报文可能就会到下一次连接中了），相当于可以重传多次fin报文，直到fin报文上限

4、为什么TIME_WAIT等待时间是2MSL？

MSL是报文的最大生存时间,超过这个时间，报文就将丢弃。
因为tcp是基于ip协议的，ip头中有一个ttl字段，表示ip数据包可以经过的最大路由数。每经过一个节点时，就减一，减为0则丢弃报文。

MSL和TTL的区别：MSL的单位是时间，而TTL的单位则是路由跳数。所以MSL应该大于等于TTL的时间，确保报文已经消亡

TIME_WAIT比较合理的解释是：确保对方能够收到最后一个ack报文，如果服务端没有收到最后的ack报文，就会触发超时重传fin报文，从客户端发送ack报文到接到到服务端重传的fin报文，一去一来，最晚要2msl

为什么不是1MSL？？

• 因为1MSL可能导致历史数据还没有消亡，导致被后面相同的四元组接收。比如服务端重发的fin报文
• 客户端发送的ack报文不允许丢失，不然重发的fin报文不能抵达客户端，导致服务端RST关闭

为什么不是4MSL或8MSL

因为如果客户端发送的ack报文丢失，服务端重发的fin报文也丢失了，那么2MSL就不起作用了。那么需要给它设置更长时间？？我们设想在一个丢包率为1%的糟糕网络中，两次连续丢包的概率为万分之一，忽略它显然给解决它更具有实际意义

5、TIME_WAIT过多有什么危害？

1、服务端受内存资源占用

当服务端有过多的的TCP连接时，虽然理论上可以建立很多连接，因为一个服务端只监听一个端口，不会导致端口资源受限。但是tcp连接需要占用系统资源，比如cpu资源，文件描述符，线程资源等等

2、客户端受端口资源的占用

一个tcp占用一个发起连接方的一个本地端口，如果tcp连接过多，则会导致端口资源不足，无法建立新连接

6、如何优化TIME_WAIT？

• 打开net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_timestamps 选项
  net.ipv4.tcp_tw_reuse之只能用于客户端，当有连接时，客户端会随机找一个time_wait状态超过1s的连接给新连接复用。
  net.ipv4.tcp_timestamps开启时间戳，可以保证历史连接不会被下一个相同的四元组接收
• net.ipv4.tcp_max_tw_buckets
  这个值默认为18000，当系统处于time_wait状态的连接大于这个值时，后面的连接状态就会被重置，不会产生新的time_wait状态

• 程序中使用 SO_LINGER

  
  444e28ad87442536762db6ab13d2f71.png
  

  当l_onoff为非0，l_linger为0时，调用close关闭连接时就会直接发送RST报文，直接跳过四次挥手阶段

如果服务端要尽量避免TIME_WAIT状态的连接，就尽量不要让服务端来断开连接，承受time_wait状态，而是尽量让我们发布各地的客户端来断开连接

7、如果已经建立了连接，但是另一端突然出现故障，会发生什么？

• TCP有一个保活机制，当一端长时间没有相互发送数据时，就会触发保活机制。即每隔一段时间都发送一次报文给对方，如果几次都不回应的话，就会认为对方已经死亡了，那么就会断开连接。
  如果需要使用保活机制，那么需要在soket接口设置so_keeplive才能生效，如果没有设置，则不可以生效
  TCP的检测时间有点长，我们可以在应用层实现一个心跳机制。
  web服务一般都会提供time_keeplive参数，用来指定http长连接超时时间。

————————————————
链接：https://blog.csdn.net/small_engineer/article/details/124224532
链接：https://blog.csdn.net/weixin_52109884/article/details/119885387