哪个网站可以接项目做安装wordpress出现乱码
一、三次握手
AB之间 都会发送一个syn - ack。
A 先发 syn ,B收到 。 A: 什么都不知道 B:知道A可以发送。
B发送syn-ack,A收到 。 A: 知道B可以收也可以发 , B知道A可以发送。
A发送ack，B收到。 A ： 知道B可以收也可以发 , B知道A可以发送和收。
举个实际场景：比如线上会议时，老板问你能听见吗？这就是A向B发送syn，此时你知道老板能发数据，老板什么都不知道；接着你要告诉老板你能听见，这就是B向A发送syn-ack，此时老板知道你可以收也可以发，但是你只知道老板能发，不知道他能不能收；最后老板说好的知道了，这就是A发送ack，此时你得知老板能收。
如果不进行第三次握手，拿上面例子来说，你不知道老板能否收到你发的数据，会产生怀疑，这显然是不能存在的。
二、四次挥手
四次挥手（Four-Way Handshake）是 TCP 连接终止的过程，用于在通信双方都完成数据传输后，安全地关闭连接。以下是对四次挥手过程的详细解释：
-
第一次挥手
- 主动方动作：当客户端（主动方）的数据传输完成，想要关闭连接时，它会向服务器端发送一个 FIN（Finish）报文段。这个 FIN 报文段的序列号是客户端之前已发送数据的最后一个字节的序号加 1。例如，如果客户端之前发送的数据的最后一个字节的序号是 1000，那么 FIN 报文段的序列号就是 1001。这表示客户端不再有数据要发送了，请求关闭连接。
- FIN 报文段：FIN 报文段除了包含序列号信息外，还设置了控制位中的 FIN 位为 1，其他位（如 ACK 位等）根据具体情况设置。FIN 位的设置是告诉服务器端，客户端想要终止连接。
-
第二次挥手
- 被动方动作：服务器端收到客户端的 FIN 报文段后，会返回一个 ACK（Acknowledgment）报文段作为应答。这个 ACK 报文段的序列号是客户端发送的 FIN 报文段的序列号加 1，即确认收到了客户端的关闭请求。例如，如果客户端的 FIN 报文段的序列号是 1001，那么服务器端返回的 ACK 报文段的序列号就是 1002。
- 确认关闭请求：服务器端此时可能还有数据没有发送完成，所以它不会立即关闭连接，而是先向客户端发送 ACK 报文段，告知客户端它已经收到了关闭请求。
-
第三次挥手
- 被动方动作：当服务器端的数据也发送完成后，它会向客户端发送一个 FIN 报文段，通知客户端它也没有数据要发送了，请求关闭连接。这个 FIN 报文段的序列号是服务器端之前已发送数据的最后一个字节的序号加 1。
- 发起关闭请求：这一步是服务器端主动发起的关闭请求，与客户端之前发起的关闭请求类似，只是角色互换了。服务器端发送的 FIN 报文段的 FIN 位也设置为 1，表示请求关闭连接。
-
第四次挥手
- 主动方动作：客户端收到服务器端的 FIN 报文段后，会返回一个 ACK 报文段作为应答。这个 ACK 报文段的序列号是服务器端发送的 FIN 报文段的序列号加 1，确认收到了服务器端的关闭请求。
- 连接关闭：客户端在发送完 ACK 报文段后，会等待一段时间（通常是 2 倍的最大段生存期，即 2MSL），以确保服务器端能够收到 ACK 报文段。如果在等待期间没有收到服务器端的重传请求，那么客户端就认为连接已经完全关闭，可以释放相关的资源。服务器端在收到客户端的 ACK 报文段后，也会释放连接相关的资源，至此，TCP 连接完全终止。
为什么挥手需要四次？
由于 TCP 的半关闭（half-close）特性，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
通俗的来说，两次挥手就可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次挥手。
举个例子：A 和 B 打电话，通话即将结束后，A 说 “我没啥要说的了”，B 回答 “我知道了”，于是 A 向 B 的连接释放了。但是 B 可能还会有要说的话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，于是 B 向 A 的连接释放了，这样整个通话就结束了。