◆ 博主名称 小此方-CSDN博客大家好欢迎来到小此方的博客。⭐️网络系列个人专栏 【主题曲】计算机网络⭐️此方的GitHub github_此方⭐️我们思考 (Rethink) · 我们重建 (Rebuild) · 我们记录 (Record)文章目录概要序論一、拥塞控制1.1 为什么需要拥塞控制1.2 慢启动算法与拥塞窗口cwnd1.2.1 拥塞窗口cwnd与滑动窗口的最终计算1.3 拥塞控制的过程从慢启动到拥塞避免1.4 常见疑问与网络极限1. 拥塞窗口增加发送的数据量一定增加吗2. 在网络特别健康的情况下拥塞窗口会无限一直增大吗二、延迟应答2.1 延迟应答的核心逻辑2.2 延迟应答带来的直接效益三、TCP 总结3.1 可靠性与性能优化机制分类1. 保证可靠性的机制2. 提高性能的机制3. 其他关键支持机制3.2 纠偏思考UDP 一定比 TCP 效率高吗概要序論Hello大家好我是此方。在前面的讨论中我们主要关注的是客户端与服务端两端的问题例如通过滑动窗口进行流量控制。然而TCP 协议不仅考虑了传输两端主机的接收能力还必须考量中间网络环境本身的状况——拥塞控制。人们想到TCP一定是他的可靠性但是TCP也有效率的考量——本文将讲解延迟应答和捎带应答两种机制。好我们开始吧。一、拥塞控制1.1 为什么需要拥塞控制在网络传输过程中丢包少和丢包多所反映的本质问题是完全不同的发送 1000 次报文丢包 5 次属于正常现象偶尔的网络抖动会导致少数报文丢失。发送 10000 次报文丢包 500 次属于非常规现象说明当前网络链路存在异常。当出现大面积丢包时发送方会判定这是网络拥塞所导致的问题。此时如果盲目地立即重发数据不仅无法解决问题反而会进一步增加网络的负载导致网络更加拥塞。或许有人会产生疑问单个客户端发送 1000 个报文对于庞大的网络来说微不足道为什么不能立即重发因为网络是由成千上万个客户端和服务端共同共享的。如果每个主机都认为自己的数据量小而选择立即重发就会加速整个网络的瘫痪。因此我们需要拥塞控制机制。拥塞控制的作用在于统一管理和协调发送端的多个主机让所有主机在面对网络拥塞时都采用相同的策略以共同维护网络环境的稳定。1.2 慢启动算法与拥塞窗口cwnd既然在网络发生拥塞时不能立即重发大量报文TCP 采取的解决方案就是慢启动算法。慢启动的策略是先发少量的数据探探路摸清当前网络的拥塞程度然后再决定按照多大的速度发送数据。在网络拥塞时通过按指数级增加发送数据量每次翻倍如 1、2、4、8…使得前期大家发送都比较慢。所有主机都遵循这个共识使得网络有足够的时间恢复把积压的报文发送干净。在网络不拥塞后通过这种指数级增长的方式可以极快地恢复网络通信。1.2.1 拥塞窗口cwnd与滑动窗口的最终计算我们之前讲过发送方一次能发多少数据是由滑动窗口决定的而滑动窗口的大小取决于对方的接收能力。但这里就带来了一个问题慢启动算法的实现到底依靠的是什么为了支持慢启动算法TCP 引入了拥塞窗口cwndCongestion Window的概念。在当前计算机内部拥塞窗口就是用来衡量网络是否会拥塞的一个指标其本质就是一个整数临界值在拥塞窗口数值以内网络较大概率不拥塞超过这个数值网络就可能发生拥塞。动态更新很显然网络状况是随时变化的这就决定了拥塞窗口的值一定要进行更新变化。引入拥塞窗口后发送方实际的滑动窗口大小不再单单由对方决定而是进行了升级滑动窗口大小 min ( 对方的 win 大小 , 拥塞窗口大小 ) \text{滑动窗口大小} \min(\text{对方的 win 大小}, \text{拥塞窗口大小})滑动窗口大小min(对方的win大小,拥塞窗口大小)谁小谁就是主要问题、主要矛盾这样的机制既考虑了网络拥塞问题又考虑了对方接收能力的问题。1.3 拥塞控制的过程从慢启动到拥塞避免拥塞窗口不可能一直指数增长下去否则很快又会引发网络拥塞。TCP 的拥塞控制过程主要分为三个阶段前期慢启动阶段拥塞窗口初始值较小数据量按指数规律增长2 n 2^n2n目的是前期慢发、减少网络压力并快速探测网络状况。中期拥塞避免阶段为了防止拥塞窗口增长过快导致网络拥塞TCP 引入了一个阈值——慢启动阈值ssthresh。当拥塞窗口达到ssthresh之前采用指数增长。当拥塞窗口达到或超过ssthresh时不再按指数增长而是转变为线性增长每次增加 1这种方式被称为“加法增大”本质是为了探测网络的通畅程度。后期乘法减小与重新开始随着拥塞窗口持续线性增大当网络再次发生拥塞出现丢包时TCP 会采取“乘法减小”策略将新的ssthresh降低为当前拥塞窗口的一半。同时拥塞窗口cwnd会重新被置为初始值如 1重新开始慢启动过程以此来探测网络的健康状况。网络拥塞不是单台主机导致的而是由全网所有主机共同引起的。所有主机都在不断地探测网络的拥塞窗口这个过程会不断重复拥塞窗口与慢启动阈值ssthresh的值也会随之不断更新。1.4 常见疑问与网络极限在理解拥塞控制时有两个经常被提及的问题1. 拥塞窗口增加发送的数据量一定增加吗不一定因为实际发送的数据量滑动窗口取决于min{对方的 win 大小, 拥塞窗口大小}。即使拥塞窗口一直在增长如果对方的接收缓冲区满了win变小实际发送的数据量依然会受到限制。2. 在网络特别健康的情况下拥塞窗口会无限一直增大吗实际上不会逻辑上如果网络非常健康拥塞窗口似乎应该一直增大但单位时间内的物理带宽硬件阈值是限制拥塞窗口不可能无限增长的关键因素。当达到带宽上限时必然会导致数据延迟或丢包进而触发拥塞控制。总结来说最理想的网络传输状态是网络状态健康稳定传输过程完全以对方的接收能力限制为准。二、延迟应答在 TCP 传输过程中如果接收数据的主机立刻返回 ACK 应答这时候返回的通告窗口可能相对比较小。2.1 延迟应答的核心逻辑我们可以通过一个具体的场景来理解为什么需要延迟应答假设接收端缓冲区总大小为 1M一次收到了 500K 的数据。如果接收端立刻进行应答那么剩余的缓冲区空间就只有 500K此时返回的窗口大小就是 500K。但实际上上层应用处理数据的速度可能很快也许在 10ms 之内就把这 500K 数据从接收缓冲区中全部消费掉了通过read等系统调用将数据拷贝到了应用层。在这种情况下接收端的处理能力远还没有达到自身的极限即便窗口再放大一些接收端也完全能处理过来。如果接收端稍微等待一会儿再进行应答比如等待 200ms 再应答那么在这段时间内上层应用已经把数据消费完此时返回的通告窗口大小就是 1M一定要记得窗口越大网络吞吐量就越大传输效率就越高。我们的目标是在保证网络不拥塞的情况之下尽量提高传输效率。2.2 延迟应答带来的直接效益通过延迟应答机制TCP 能够实现以下两个维度的优化通告更大窗口给上层应用留出消费缓冲区数据的时间从而能够向发送端通告更大的接收窗口提高传输吞吐量。减少应答数量由于并不是所有的报文都需要发送应答接收端可以在收到多个报文后直接针对后续接收到的最新报文发送一次确认应答从而减少网络中 ACK 报文的数量节省网络带宽。三、TCP 总结为什么 TCP 协议这么复杂因为 TCP 既要保证数据的可靠性同时又要在保证可靠性的前提下尽可能地提高性能。3.1 可靠性与性能优化机制分类我们可以将 TCP 核心的技术机制划分为三大维度1. 保证可靠性的机制校验和序列号按序到达确认应答超时重发连接管理流量控制拥塞控制2. 提高性能的机制滑动窗口快速重传延迟应答捎带应答3. 其他关键支持机制定时器超时重传定时器、保活定时器、TIME_WAIT 定时器等3.2 纠偏思考UDP 一定比 TCP 效率高吗平时听别人说UDP比TCP效率高。我认为是错误的应该结合具体场景分析。TCP还有最后两个补充话题——异常、从源码看TCP我们下一期再介绍。好的本期内容就到这里如果对你有帮助还不要忘记点赞三联支持,如果有什么疑问可以再后台私信我。我是此方我们下期再见。bye! Linux网络（二十）：TCP拥塞控制与延迟应答详解：从拥塞窗口到TCP性能优化，理解TCP与UDP的效率差异
◆ 博主名称 小此方-CSDN博客大家好欢迎来到小此方的博客。⭐️网络系列个人专栏 【主题曲】计算机网络⭐️此方的GitHub github_此方⭐️我们思考 (Rethink) · 我们重建 (Rebuild) · 我们记录 (Record)文章目录概要序論一、拥塞控制1.1 为什么需要拥塞控制1.2 慢启动算法与拥塞窗口cwnd1.2.1 拥塞窗口cwnd与滑动窗口的最终计算1.3 拥塞控制的过程从慢启动到拥塞避免1.4 常见疑问与网络极限1. 拥塞窗口增加发送的数据量一定增加吗2. 在网络特别健康的情况下拥塞窗口会无限一直增大吗二、延迟应答2.1 延迟应答的核心逻辑2.2 延迟应答带来的直接效益三、TCP 总结3.1 可靠性与性能优化机制分类1. 保证可靠性的机制2. 提高性能的机制3. 其他关键支持机制3.2 纠偏思考UDP 一定比 TCP 效率高吗概要序論Hello大家好我是此方。在前面的讨论中我们主要关注的是客户端与服务端两端的问题例如通过滑动窗口进行流量控制。然而TCP 协议不仅考虑了传输两端主机的接收能力还必须考量中间网络环境本身的状况——拥塞控制。人们想到TCP一定是他的可靠性但是TCP也有效率的考量——本文将讲解延迟应答和捎带应答两种机制。好我们开始吧。一、拥塞控制1.1 为什么需要拥塞控制在网络传输过程中丢包少和丢包多所反映的本质问题是完全不同的发送 1000 次报文丢包 5 次属于正常现象偶尔的网络抖动会导致少数报文丢失。发送 10000 次报文丢包 500 次属于非常规现象说明当前网络链路存在异常。当出现大面积丢包时发送方会判定这是网络拥塞所导致的问题。此时如果盲目地立即重发数据不仅无法解决问题反而会进一步增加网络的负载导致网络更加拥塞。或许有人会产生疑问单个客户端发送 1000 个报文对于庞大的网络来说微不足道为什么不能立即重发因为网络是由成千上万个客户端和服务端共同共享的。如果每个主机都认为自己的数据量小而选择立即重发就会加速整个网络的瘫痪。因此我们需要拥塞控制机制。拥塞控制的作用在于统一管理和协调发送端的多个主机让所有主机在面对网络拥塞时都采用相同的策略以共同维护网络环境的稳定。1.2 慢启动算法与拥塞窗口cwnd既然在网络发生拥塞时不能立即重发大量报文TCP 采取的解决方案就是慢启动算法。慢启动的策略是先发少量的数据探探路摸清当前网络的拥塞程度然后再决定按照多大的速度发送数据。在网络拥塞时通过按指数级增加发送数据量每次翻倍如 1、2、4、8…使得前期大家发送都比较慢。所有主机都遵循这个共识使得网络有足够的时间恢复把积压的报文发送干净。在网络不拥塞后通过这种指数级增长的方式可以极快地恢复网络通信。1.2.1 拥塞窗口cwnd与滑动窗口的最终计算我们之前讲过发送方一次能发多少数据是由滑动窗口决定的而滑动窗口的大小取决于对方的接收能力。但这里就带来了一个问题慢启动算法的实现到底依靠的是什么为了支持慢启动算法TCP 引入了拥塞窗口cwndCongestion Window的概念。在当前计算机内部拥塞窗口就是用来衡量网络是否会拥塞的一个指标其本质就是一个整数临界值在拥塞窗口数值以内网络较大概率不拥塞超过这个数值网络就可能发生拥塞。动态更新很显然网络状况是随时变化的这就决定了拥塞窗口的值一定要进行更新变化。引入拥塞窗口后发送方实际的滑动窗口大小不再单单由对方决定而是进行了升级滑动窗口大小 min ( 对方的 win 大小 , 拥塞窗口大小 ) \text{滑动窗口大小} \min(\text{对方的 win 大小}, \text{拥塞窗口大小})滑动窗口大小min(对方的win大小,拥塞窗口大小)谁小谁就是主要问题、主要矛盾这样的机制既考虑了网络拥塞问题又考虑了对方接收能力的问题。1.3 拥塞控制的过程从慢启动到拥塞避免拥塞窗口不可能一直指数增长下去否则很快又会引发网络拥塞。TCP 的拥塞控制过程主要分为三个阶段前期慢启动阶段拥塞窗口初始值较小数据量按指数规律增长2 n 2^n2n目的是前期慢发、减少网络压力并快速探测网络状况。中期拥塞避免阶段为了防止拥塞窗口增长过快导致网络拥塞TCP 引入了一个阈值——慢启动阈值ssthresh。当拥塞窗口达到ssthresh之前采用指数增长。当拥塞窗口达到或超过ssthresh时不再按指数增长而是转变为线性增长每次增加 1这种方式被称为“加法增大”本质是为了探测网络的通畅程度。后期乘法减小与重新开始随着拥塞窗口持续线性增大当网络再次发生拥塞出现丢包时TCP 会采取“乘法减小”策略将新的ssthresh降低为当前拥塞窗口的一半。同时拥塞窗口cwnd会重新被置为初始值如 1重新开始慢启动过程以此来探测网络的健康状况。网络拥塞不是单台主机导致的而是由全网所有主机共同引起的。所有主机都在不断地探测网络的拥塞窗口这个过程会不断重复拥塞窗口与慢启动阈值ssthresh的值也会随之不断更新。1.4 常见疑问与网络极限在理解拥塞控制时有两个经常被提及的问题1. 拥塞窗口增加发送的数据量一定增加吗不一定因为实际发送的数据量滑动窗口取决于min{对方的 win 大小, 拥塞窗口大小}。即使拥塞窗口一直在增长如果对方的接收缓冲区满了win变小实际发送的数据量依然会受到限制。2. 在网络特别健康的情况下拥塞窗口会无限一直增大吗实际上不会逻辑上如果网络非常健康拥塞窗口似乎应该一直增大但单位时间内的物理带宽硬件阈值是限制拥塞窗口不可能无限增长的关键因素。当达到带宽上限时必然会导致数据延迟或丢包进而触发拥塞控制。总结来说最理想的网络传输状态是网络状态健康稳定传输过程完全以对方的接收能力限制为准。二、延迟应答在 TCP 传输过程中如果接收数据的主机立刻返回 ACK 应答这时候返回的通告窗口可能相对比较小。2.1 延迟应答的核心逻辑我们可以通过一个具体的场景来理解为什么需要延迟应答假设接收端缓冲区总大小为 1M一次收到了 500K 的数据。如果接收端立刻进行应答那么剩余的缓冲区空间就只有 500K此时返回的窗口大小就是 500K。但实际上上层应用处理数据的速度可能很快也许在 10ms 之内就把这 500K 数据从接收缓冲区中全部消费掉了通过read等系统调用将数据拷贝到了应用层。在这种情况下接收端的处理能力远还没有达到自身的极限即便窗口再放大一些接收端也完全能处理过来。如果接收端稍微等待一会儿再进行应答比如等待 200ms 再应答那么在这段时间内上层应用已经把数据消费完此时返回的通告窗口大小就是 1M一定要记得窗口越大网络吞吐量就越大传输效率就越高。我们的目标是在保证网络不拥塞的情况之下尽量提高传输效率。2.2 延迟应答带来的直接效益通过延迟应答机制TCP 能够实现以下两个维度的优化通告更大窗口给上层应用留出消费缓冲区数据的时间从而能够向发送端通告更大的接收窗口提高传输吞吐量。减少应答数量由于并不是所有的报文都需要发送应答接收端可以在收到多个报文后直接针对后续接收到的最新报文发送一次确认应答从而减少网络中 ACK 报文的数量节省网络带宽。三、TCP 总结为什么 TCP 协议这么复杂因为 TCP 既要保证数据的可靠性同时又要在保证可靠性的前提下尽可能地提高性能。3.1 可靠性与性能优化机制分类我们可以将 TCP 核心的技术机制划分为三大维度1. 保证可靠性的机制校验和序列号按序到达确认应答超时重发连接管理流量控制拥塞控制2. 提高性能的机制滑动窗口快速重传延迟应答捎带应答3. 其他关键支持机制定时器超时重传定时器、保活定时器、TIME_WAIT 定时器等3.2 纠偏思考UDP 一定比 TCP 效率高吗平时听别人说UDP比TCP效率高。我认为是错误的应该结合具体场景分析。TCP还有最后两个补充话题——异常、从源码看TCP我们下一期再介绍。好的本期内容就到这里如果对你有帮助还不要忘记点赞三联支持,如果有什么疑问可以再后台私信我。我是此方我们下期再见。bye!