视频网站做漫画,wordpress设计博客,如何做ptp刷流量的网站,临时网站搭建目录
1、拥塞控制 2、延时应答
3、捎带应答
4、面向字节流
5、异常情况处理
5.1、其中一方出现了进程崩溃
5.2、其中一方出现关机#xff08;正常流程的关机#xff09;
5.3、其中一方出现断电#xff08;直接拔电源#xff0c;也是关机#xff0c;更突然的关机正常流程的关机
5.3、其中一方出现断电直接拔电源也是关机更突然的关机
5.4、网络断开 1、拥塞控制
和流量控制一样也是用来限制发送方的发送速率的。
如果当前接收方处理速度很快但是中间的通信路径出现问题某个地方出现了“堵车”现象此时发送的速度再快也没有反而发的越快丢包丢的越多。
将中间路径的所有设备视为一个整体如果按照某个窗口大小发送数据后出现了丢包就视为中间路径存在拥堵就减少窗口大小没有出现丢包就视为中间路径不存在拥堵就增加窗口大小。 拥塞控制的流程 慢启动。由于刚开始网络的拥塞情况未知如果一上来就搞很大可能就让原本不富裕的网络宽带雪上加霜因此此时刚启动的传输时速率比较小采用的窗口大小拥塞窗口也比较小。如果在慢启动环节没有出现丢包现象此时说明网络比较通畅就使用指数增大的方式逐步增大窗口大小。指数增长增长的速度非常快因此不会一直持续这里引入了一个“阈值”当拥塞窗口达到阈值之后此时指数增长就变成了“线性增长”。线性增长积累到一定时间后由于传输塑速率不断增大到达某一时刻时可能就会出现丢包一旦出现丢包就把拥塞窗口重置成较小的值。以前的做法是回到最初的“慢启动”过程然后重新开始。但是这个做法启动的起点太低了平均速率不快。现在的做法是启动“快恢复”设置一个新的“阈值”回到新的阈值然后再继续线性增长。 2、延时应答
也是基于滑动窗口是要尽可能的再提高一点效率。
结合滑动窗口以及流量控制通过延时应答 ack 的方式把返回的“窗口大小”的数值变大一些核心在于在允许的范围内让窗口尽可能的大。【通过修改窗口大小提升效率】
接收方收到数据之后不会立即返回 ack而是等待一定时间再返回 ack相当于给接收方的应用程序里腾出了更多的时间来消费这里的数据使接收缓冲区的空闲空间更大一些因为被消费掉了又由于流量控制中“接收方会按照自身接收缓冲区的剩余空间大小作为 ack 中窗口大小的数值发送方就能根据该数值调整窗口大小。”的机制此时返回的窗口大小就是一个相对大的值。 前面也讨论过滑动窗口下如果 ack 丢了不会有什么影响。而此处的“延时应答”也一样可以按照“ack 丢了”的方式来处理。正常每个数据都有 ack此时就可以每隔几个数据或每隔一定时间再返回一个 ack起到延时应答的效果减少了 ack 传输的数量起到了节省开销的效果 3、捎带应答
基于延时应答引入的机制能够提升传输效率。尽可能的把能合并的数据包进行合并从而提高效率。 本身 ack 也不携带载荷只要把报头中的 ack 标志位设为1并且设置确认序号以及窗口大小而这几个属性response 报文本身也用不到因此不会产生冲突。 在捎带应答的加持下后续的每次传输请求响应都可能触发捎带应答都可能把接下来要传输的业务数据和上次的 ack 合二为一。并不一定触发主要取决于下一个数据来的时间如果来的快就可能触发合并来的慢就无法触发
因为“延时应答”和“捎带应答”使四次挥手可能合并成“三次挥手”。 4、面向字节流
由于 TCP 面向字节流会引起“粘包问题”粘包就类似于一段文字里没有任何标点符号导致无法正确断句产生非常多的歧义包是“TCP载荷中的应用数据包”。
由于 TCP 连接中接收方整个读取过程非常灵活可能会使代码中无法区分出当前的数据从哪到哪是一个完整的应用数据包。TCP 本身不会解决“粘包问题”需要程序员在写应用层逻辑的时候自己去进行处理。 粘包问题不是 TCP 独有的问题只要面向字节流都会有粘包问题。 解决粘包问题的关键就是“明确包之间的边界” 1、通过特殊符号作为分隔符。 2、指定出包的长度。比如把包的开始位置加上一个长度表示数据长度。 5、异常情况处理
在网络连接的过程中接收方和发送方之间可能会因为某些原因出现严重的丢包甚至是网络直接出现故障的情况对于这些情况该如何处理
5.1、其中一方出现了进程崩溃
进程无论是正常结束还是异常崩溃都会触发“四次挥手”进行回收文件资源和关闭文件系统自动完成。
TCP 连接的生命周期可以比进程更长一些 这就使得进程虽然已经退出但是 TCP 连接还在仍然可以进行“四次挥手”。虽然说是异常崩溃实际上和正常的四次挥手结束流程没有什么区别进程不在了就通过系统中仍然持有的连接信息完成后续的挥手流程 5.2、其中一方出现关机正常流程的关机
当一个主机触发关机操作就会先强制终止所有的进程类似于上述的进程崩溃对进程进行强杀操作
那么根据 情况1 可以知道终止进程自然会触发“四次挥手”。
而与 情况1 不同的是虽然进程会自动触发“四次挥手”但是因为系统马上就关闭四次挥手不一定能挥完。如果挥得快能够顺利挥完此时本端和对端都能正常删除连接信息完成四次挥手如果挥得慢至少能把第一个 fin 发送到对端至少能告诉对方我这边要结束了对端收到 fin 之后就会进入释放连接的流程并返回 ack 和 fin而此时对端发送的 fin 不会得到 ack 回应因为本端关机了没有收到 ack势必会进行重传当重传时间达到阈值就会单方面释放连接信息。 5.3、其中一方出现断电直接拔电源也是关机更突然的关机
如果直接断电机器瞬间关机此时肯定来不及发送 fin 。突然断电的情况非常伤硬盘尤其机械硬盘。
a断电是接收方发送方就会突然发现没有 ack 返回了就进行重传几次重传后还是无回应就会尝试使用 TCP 中的“复位报文段”进行“复位”连接清楚原有 TCP 中的各种临时数据重新连接。 此时发送的 RST 也不会有 ack复位连接也不行就会单方面放弃连接。 b断电是发送方。由于接收方始终都是在阻塞等待发送方的消息此时就需要区分发送方是暂时没法消息还是挂了。因此 TCP 就引入了“心跳包”概念每隔一段时间询问对方状态当发现对方挂了没有心跳则按照流程执行复位连接并单方面释放连接。 5.4、网络断开
本质上就是 情况3 中的 a和 b的结合。 对 JVM 的类加载机制以及寻找字节码文件的“双亲委派模型”的理解-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136529700?spm1001.2014.3001.5501
JVM 的垃圾回收机制以及垃圾回收算法的详解-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136530845?spm1001.2014.3001.5501【网络编程】理解客户端和服务器并使用Java提供的api实现回显服务器-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136322678?spm1001.2014.3001.5501
如果觉得作者写的不错求给博主一个大大的点赞支持一下你们的支持是我更新的最大动力
如果觉得作者写的不错求给博主一个大大的点赞支持一下你们的支持是我更新的最大动力
如果觉得作者写的不错求给博主一个大大的点赞支持一下你们的支持是我更新的最大动力
