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

女爷i 2024-03-24 09:05 15阅读 0赞

> 大家好 , 这篇文章继续给大家讲解 TCP 协议当中的一些操作 , 比如 : 滑动窗口、流量控制、拥塞控制、延时应答、捎带应答、面向字节流这几个提升 TCP 效率的操作 . 我们还会给大家分析 TCP 连接出现异常的时候 , 该如何处理 . 最后会将 TCP 和 UDP 进行比较  
> ![在这里插入图片描述][2c0c7e26d2ef4b6c85fc5ac053641aae.gif_pic_center]  
> [上一篇文章][Link 1]的链接也给大家贴在这里了  
> [文章专栏][Link 2]在此

#### 文章目录 ####

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

## TCP 协议 ##

### 滑动窗口 ###

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

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

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

### 流量控制 ###

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

### 拥塞控制 ###

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

--------------------

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

### 延时应答 ###

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

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

![image.png][]  
情况 1 : 感受不太明显  
![image.png][image.png 1]  
情况 2 :  
![image.png][image.png 2]

### 捎带应答 ###

捎带应答是基于延时应答的策略 , 也是为了提高传输效率的机制  
![image.png][image.png 3]  
四次挥手 , 在延时应答机制 + 捎带应答机制中 , 也有可能实现 三次挥手  
![image.png][image.png 4]

### 面向字节流 ###

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

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

1.  主机关机 (正常关机)

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

1.  程序崩溃

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

1.  主机掉电 (突然拔电源)

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

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

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

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

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

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

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

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

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

--------------------

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

--------------------

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

### TCP VS UDP ###

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

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

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

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

那也有很多场景 , 既需要速度快 , 又需要可靠性  
比如 : 对抗性网游 (LOL / 王者荣耀 …)  
像这种场景 , 还有一些以他的传输层协议 , 比如 : KCP  
![image.png][image.png 5]  
传输层协议有很多 , 并不是只有 TCP 和 UDP

--------------------

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

[2c0c7e26d2ef4b6c85fc5ac053641aae.gif_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/1fb7767263244572b3d646ce35a76d83.png
[Link 1]: https://blog.csdn.net/m0_53117341/article/details/129778252
[Link 2]: https://blog.csdn.net/m0_53117341/category_12186238.html?spm=1001.2014.3001.5482
[.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/965a823aab6b4530a646bda1495aea7e.png
[.png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a212d4bfd3cd4f3382059628e308c5fd.png
[.png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/461cd31531f7443d8f0b1a83fc941764.png
[image.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/e001965ef78d480cabb22174102e35ad.png
[image.png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/63ecf4671d02409d957cb2461bcb9fcb.png
[image.png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/056119e0b7dc4dbdadbfd04fa230a012.png
[image.png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/6063e663998743d98dd2cf2302f97ae2.png
[image.png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/831cb8fa4bc14670a7bbf14bc00c88a4.png
[.png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/454c83a94a254550ae85e03876ee25d5.png
[image.png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/0b34255aada842adbe3a529e143664c4.png
[2c5ef129beed440791fd3e6b07acfede.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/501bbf42020e42019276c394115a589e.png