当前位置：首页 > news >正文

Java Web 实战 17 - 计算机网络之传输层协议(2)

news 文章来源：https://blog.csdn.net/m0_53117341/article/details/129788100 2025/2/7 18:57:58

大家好 , 这篇文章继续给大家讲解 TCP 协议当中的一些操作 , 比如 : 滑动窗口、流量控制、拥塞控制、延时应答、捎带应答、面向字节流这几个提升 TCP 效率的操作 . 我们还会给大家分析 TCP 连接出现异常的时候 , 该如何处理 . 最后会将 TCP 和 UDP 进行比较

上一篇文章的链接也给大家贴在这里了
文章专栏在此

文章目录

TCP 协议
- 滑动窗口
- 流量控制
- 拥塞控制
- 延时应答
- 捎带应答
- 面向字节流
- TCP 连接出现异常的时候 , 如何处理
- TCP VS UDP

TCP 协议

滑动窗口

滑动窗口机制是用来提高传输效率的机制 , 本质就是把等待 ACK 的时间重叠起来 , 减少等待时间 , 就相当于提高了效率

比如说 : 发送了两次 SYN , 就需要返回两次 ACK , 滑动窗口就是一次性返回这两个 ACK

可靠性和效率是冲突的 , 如果要保证可靠性 , 就肯定会影响到效率的 .
TCP 选择了保证可靠性的前提下 , 尽可能的提高效率
无标题.png

流量控制

我们刚才介绍的滑动窗口 , 窗口大小越大 , 发送速率就越快 . 但是整体的传输效率 = 发送速率 & 接收速率 , 发送速率快但是接收速率跟不上也不行 .
如果发送速率 > 接收速率 , 这个时候继续提高发送速率 , 不能够提高整体的效率了 . 反而会因为接收方丢包 , 触发更多的重传 , 因此还降低了速率 .
流量控制 , 就是在针对发送速率进行制约 , 让发送速率和接收速率步调一致 ; 本质上就是对滑动窗口的制约
无标题.png

拥塞控制

流量控制 , 站在接收方的角度 , 来控制发送速率 .
但是整体的传输 , 其实不光有发送方和接收方 , 还有中间的一系列用来转发的设备 .
无标题.png

目前学到的这些机制 , 确认应答是保证可靠性的基石 , 超时重传是确认应答的重要补充 , 连接管理是确认应答和超时重传的前提条件 , 滑动窗口属于可靠性的基础上提高效率的方式 , 流量控制和拥塞控制又对滑动窗口进行制约

延时应答

延时应答也是用来提升效率的机制 , 延时应答则是想办法让滑动窗口大一些 , 实际上就是让流量控制别限制的太狠
在流量控制中 , 会通过 ACK 告知发送方 , 窗口大小是多少合适

窗口大小的衡量标准 : 接收缓冲区的剩余空间

情况 1 : 感受不太明显

情况 2 :

捎带应答

捎带应答是基于延时应答的策略 , 也是为了提高传输效率的机制

四次挥手 , 在延时应答机制 + 捎带应答机制中 , 也有可能实现三次挥手

面向字节流

面向字节流 , 指的是读写载荷数据的时候 , 是按照 “字节流” 的方式来读取的 .
TCP 数据报 , 本身仍然是一个一个 “数据报” 这样的方式来传输的 .
应用层这里是感知不到从哪里到哪里是一个数据报的
(参考 2.2.1 TCP 协议报头 + 确认应答)
无标题.png
粘包问题 , 根本原因 , 是 TCP 面向字节流的原因 .
但是却是影响的应用层的代码

TCP 连接出现异常的时候 , 如何处理

主机关机 (正常关机)

按照程序关机 , 会先杀死所有的用户进程 (也就包括咱们自己写的 TCP 程序)
杀死进程就会去释放进程 PCB , PCB 上面有一个文件描述符表 , 就会释放文件描述符表上对应的文件资源
(相当于调用 close)
这个时候就会触发 FIN , 开启四次挥手的流程
如果四次挥手已经挥完了 , 继续关机 (没啥特殊的)
如果还没挥完 , 就已经关机了 , 重传 FIN 若干次 , 没有响应 , 也就放弃了

程序崩溃

同上 .
程序无论是正常关闭 , 还是异常崩溃 , 都会释放 PCB , 都会释放文件描述符表 (相当于调用 close)
也还是会正常四次挥手
(虽然进程没了 , 但是本身 TCP 连接是内核负责 , 内核仍然会继续完成后续的挥手过程)

主机掉电 (突然拔电源)

主机立刻掉电 , 肯定是来不及挥手的

  1. 接收方掉电 : 发送方尝试发送数据 , 发现没有 ack , 就会尝试进行重传

重传几次 , 仍然没有 ack
发送方就会尝试重新建立连接
如果重新建立也不成功 , 就认为是当前网络上出现了严重问题 , 也就自然放弃了

  2. 发送方掉电 : 接收方就在等待发送方发送数据 . 由于发送方没了 , 这个数据显然发不过来了

接收方不知道是对方还没发呢 , 还是对方出问题了
接收方如果一段时间没有收到数据 , 就会定期的给发送方发送 “心跳包”

接收方 , 给发送方发一个特殊的报文 (ping) , 对方返回一个特殊的报文 (pong)
如果 ping pong 是互通的 , 就认为对方是正常的状态 . 如果 ping 没有对应的 pong , 就认为对方挂了

心跳包的特点 : 周期性的、判定对方是否存活

比如 : 打电话时候对方突然没声了 , 我们就试探性的问问你还在不

网线断开 (突然拔网线) : 和主机掉电相同

在 TCP 中 , 我们介绍了很多机制
保证可靠性的机制 : 超时重传、连接管理
提高效率的机制 : 滑动窗口
保证可靠性的机制 : 流量控制、拥塞控制
提高效率的机制 : 延时应答、捎带应答
其他方面 : 粘包问题、异常处理

面试题 : 如何使用 UDP 实现可靠传输 ?
在应用层代码里面 , 参考 TCP 的策略来实现 .

TCP VS UDP

如果需要关注可靠性传输 , 优先考虑 TCP
传输的单个数据报比较大(UDP 报文上限 : 64 KB) , 优先考虑 TCP
对于可靠性要求不高 , 但是对于性能要求很高 , 使用 UDP

一个机房之间内部的主机之间的通信可以使用 UDP
网络环境简单 , 带宽充裕 , 并且希望主机之间的通信足够快

如果需要进行广播 , 优先考虑 UDP

广播 : 一个发送方 , N 个接收方
TCP 想要实现广播 , 就需要在应用层代码去实现打开多个连接的方式

那也有很多场景 , 既需要速度快 , 又需要可靠性
比如 : 对抗性网游 (LOL / 王者荣耀 …)
像这种场景 , 还有一些以他的传输层协议 , 比如 : KCP

传输层协议有很多 , 并不是只有 TCP 和 UDP

到这里 , 这篇文章就结束了
如果对你有帮助的话 , 请一键三连嗷~
在这里插入图片描述