OSI和TCP的握手/挥手

引子

关于3次握手，4次回收，OSI七层模型以及各层的作用，较为深入的整理一下。

OSI七层模型

全称 open-system-interconnect 。由国际组织提出的一套关于全球范围的计算机可以开放式通信的规范。OSI参考模型包含7层,从上到下分别是

从请求的发出流程可以看到，OSI模型对请求进行逐层的封装处理。请求发起时，数据逐层封装；请求接收时，数据逐层解封装。（物理信号 - 字节流 - 数据帧 - 数据包 - 数据段 - 应用数据 - 解码等）

TCP 与 UDP

相同点是他们都是OSI模型中传输层的协议,不同点如下:

• TCP是提供可靠连接的通信协议（可靠体现在：确认机制、重传机制、流量控制）
• UDP则提供无连接的通信.(游戏丢帧,直播卡顿)
  • 不提供可靠传输,
  • 不保证数据一定被成功接收
  • 设计目的是提供简单高效的传输
  • 适用于实时性要求较高,快速且容忍少量丢失的应用

TCP 三次握手

• 建立连接时的三次握手过程中，客户端不关心第三次的ACK是否被接收，因此不需要对方的ACK。因为如果对方接收到这次ACK，那么连接建立完成，皆大欢喜。如果对方没有收到第三次ACK，客户端发送后续数据肯定也得不到ACK应答，客户端会重新发起建立连接的请求。
• 连接建立后，每一次传输都需要ACK确认，保证了数据的有序、不丢失。

思考：为什么不能是两次握手?

如果只有两次握手，可能会导致已失效的连接请求建立冗余连接。比如：

1. 客户端发送连接请求，但因为某些原因在网络中滞留，服务器没有收到。然后客户端再次发送连接请求，建立连接。

2. 这时第一个滞留的连接请求报文段仍可能在网络中传递，达到服务器后给出响应,导致建立连接.

3. 但客户端已经重新发起了连接请求,从而导致第一次请求产生冗余的连接。

三次握手就可以解决这种情况：在一定时间内，只有接收到第三次握手的ACK，服务端才认为这是一次有效的连接请求，才会建立连接。

四次挥手

过程描述:

1. 客户端请求断开连接：

        首先，客户端发送一个FIN（Finish）标志位给服务器，表示客户端不再发送数据。

2. 服务器确认客户端的断开请求：

        服务器收到FIN后，发送一个ACK（Acknowledgment）确认客户端的断开请求。此时，服务器进入半关闭状态，可以继续向客户端发送数据。

3. 服务器通知客户端可以断开连接：

        服务器发送一个FIN给客户端，表示服务器不再发送数据。

4. 客户端确认服务器的断开请求：

        客户端收到服务器的FIN后，发送一个ACK确认服务器的断开请求。此时，客户端进入TIME_WAIT状态，等待可能存在的延迟数据报文。

为什么需要四次挥手?

        通俗理解就是：断开的前提是双方都不再发送数据给对方，所以需要双方各自发起断开请求。

        客户端发起断开请求，仅表示自己不再发送数据，此时有可能服务端还会发送数据给客户端，所以此时客户端是等待关闭的状态。当服务端也发送了断开请求时，表示双方都同意关闭。每一个断开请求都对应一个ACK确认，所以是四次挥手。

思考：

如果A先发起断开请求，但没收到B的ACK，那么会不断重试发送断开请求，直到收到B的ACK。

第四次挥手完成，如果B没收到来自A的ACK，会怎样呢？

B肯定也是重试向A继续发送断开请求，此时A虽然完成了第四次挥手，但尚未关闭。在此期间，对于B的请求仍然能给出响应。A在多久之后真正关闭不再响应呢？2MSL

为什么主动断开连接的一方需要2MSL后自动关闭?

        MSL是TCP报文在传输中的最大生命周期。2MSL是被动方发出FIN报文和主动方发出ACK报文需要的最大时长。以A、B举例（A先发起断开请求）：

当A收到B的FIN断开信号后,会给出ACK确认.在2MSL时间内,如果B没收到ACK,一定会再次重试发断开信号,此时如果A收到断开信号,则回复ACK并重置2MSL。如果在2MSL时间内A都没有再收到B的断开信号，则说明B已经收到ACK且关闭了，那么A在2MSL时间后也自动关闭。