怎么在网站空间上传文件,改wordpress地址还是站点地址,WordPress启用插件,公司英文网站多少钱大家好 , 这篇文章继续给大家讲解 TCP 协议当中的一些操作 , 比如 : 滑动窗口、流量控制、拥塞控制、延时应答、捎带应答、面向字节流这几个提升 TCP 效率的操作 . 我们还会给大家分析 TCP 连接出现异常的时候 , 该如何处理 . 最后会将 TCP 和 UDP 进行比较 上一篇文章的链接也… 大家好 , 这篇文章继续给大家讲解 TCP 协议当中的一些操作 , 比如 : 滑动窗口、流量控制、拥塞控制、延时应答、捎带应答、面向字节流这几个提升 TCP 效率的操作 . 我们还会给大家分析 TCP 连接出现异常的时候 , 该如何处理 . 最后会将 TCP 和 UDP 进行比较 上一篇文章的链接也给大家贴在这里了 文章专栏在此 文章目录TCP 协议滑动窗口流量控制拥塞控制延时应答捎带应答面向字节流TCP 连接出现异常的时候 , 如何处理TCP VS UDPTCP 协议
滑动窗口
滑动窗口机制是用来提高传输效率的机制 , 本质就是把等待 ACK 的时间重叠起来 , 减少等待时间 , 就相当于提高了效率 比如说 : 发送了两次 SYN , 就需要返回两次 ACK , 滑动窗口就是一次性返回这两个 ACK 可靠性和效率是冲突的 , 如果要保证可靠性 , 就肯定会影响到效率的 . TCP 选择了保证可靠性的前提下 , 尽可能的提高效率
流量控制
我们刚才介绍的滑动窗口 , 窗口大小越大 , 发送速率就越快 . 但是整体的传输效率 发送速率 接收速率 , 发送速率快但是接收速率跟不上也不行 . 如果发送速率 接收速率 , 这个时候继续提高发送速率 , 不能够提高整体的效率了 . 反而会因为接收方丢包 , 触发更多的重传 , 因此还降低了速率 . 流量控制 , 就是在针对发送速率进行制约 , 让发送速率和接收速率步调一致 ; 本质上就是对滑动窗口的制约
拥塞控制
流量控制 , 站在接收方的角度 , 来控制发送速率 . 但是整体的传输 , 其实不光有发送方和接收方 , 还有中间的一系列用来转发的设备 . 目前学到的这些机制 , 确认应答是保证可靠性的基石 , 超时重传是确认应答的重要补充 , 连接管理是确认应答和超时重传的前提条件 , 滑动窗口属于可靠性的基础上提高效率的方式 , 流量控制和拥塞控制又对滑动窗口进行制约
延时应答
延时应答也是用来提升效率的机制 , 延时应答则是想办法让滑动窗口大一些 , 实际上就是让流量控制别限制的太狠 在流量控制中 , 会通过 ACK 告知发送方 , 窗口大小是多少合适 窗口大小的衡量标准 : 接收缓冲区的剩余空间 情况 1 : 感受不太明显 情况 2 :
捎带应答
捎带应答是基于延时应答的策略 , 也是为了提高传输效率的机制 四次挥手 , 在延时应答机制 捎带应答机制中 , 也有可能实现 三次挥手
面向字节流
面向字节流 , 指的是读写载荷数据的时候 , 是按照 “字节流” 的方式来读取的 . TCP 数据报 , 本身仍然是一个一个 “数据报” 这样的方式来传输的 . 应用层这里是感知不到从哪里到哪里是一个数据报的 (参考 2.2.1 TCP 协议报头 确认应答) 粘包问题 , 根本原因 , 是 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 到这里 , 这篇文章就结束了 如果对你有帮助的话 , 请一键三连嗷~
