OSI和TCP的握手/挥手

最新推荐文章于 2024-10-12 15:37:23 发布

罗曼蒂克在消亡

最新推荐文章于 2024-10-12 15:37:23 发布

阅读量780

点赞数 30

分类专栏： BUG与面试题文章标签：网络协议网络

本文为博主原创文章，码字不易，未经博主允许不得转载。

本文链接：https://blog.csdn.net/wyy546792341/article/details/140999563

版权

BUG与面试题专栏收录该内容

9 篇文章 0 订阅

订阅专栏

引子

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

OSI七层模型

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

从上到下	作用	请求发出的流程	相关协议
应用层	给网络应用程序使用,执行用户活动	用户在浏览器应用中输入URL并回车。浏览器生成HTTP 请求	FTP-传输文件 HTTP/S-浏览网页 SMTP-邮件 Telnet-终端操作
表示层	转换压缩加密	在该层，请求数据会被处理
会话层	会话管理-建立和管理连接认证授权	在该层，请求数据被添加认证等信息
传输层	负责数据传输服务,保障通信的可靠性(分段,流量控制,差错控制)	在该层，请求数据被分段（TCP需要先建立连接）	TCP数据交付需要反馈,如万维网,电子邮件,FTP等,需要使用TCP协议 UDP数据交付无需反馈,更快
网络层	将数据包从A机传输到不同网络中的B机. 逻辑寻址-IP寻址路由路径确定	在该层，数据段封装成数据包，同时添加IP信息	IP-互联网协议 OSPF BGP-边界网关协议 IS-IS 中间系统到中间系统协议
数据链路层	物理寻址-在数据包中添加MAC地址,形成数据帧	在该层，数据包封装成数据帧，添加MAC地址信息	在局域网内，数据传输是基于MAC地址的，而不是IP地址
物理层	将二进制序列转换成信号通过物理硬件进行传输	在该层，数据帧被转为其他信号，然后传输

从请求的发出流程可以看到，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