尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
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!
RELATED

相关推荐

云服务器nacos搭建-单机

云服务器nacos搭建-单机

资源下载 https://github.com/alibaba/nacos/releases?page5#release-2.2.3https://github.com/alibaba/nacos/releases?page5#release-2.2.3 解压 tar -zxvf nacos-server-2.2.3.tar.gz 启动 # 默认:MODE"cluster"集群方式启动,如果单机启…

📅 2026/10/5 16:54:17
Cursor/VS Code 左侧资源管理器字体放大:TaoToken 场景下的界面可读性调优大纲

Cursor/VS Code 左侧资源管理器字体放大:TaoToken 场景下的界面可读性调优大纲

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📅 2026/10/5 16:54:17
macOS 下使用 Docker 部署运行 GameAISDK 与 SDKTool 完整指南(含 socat / XQuartz / adbkit 环境搭建)

macOS 下使用 Docker 部署运行 GameAISDK 与 SDKTool 完整指南(含 socat / XQuartz / adbkit 环境搭建)

人工智能强化学习计算机视觉游戏开发测试 【免费下载链接】GameAISDK 基于图像的游戏AI自动化框架 项目地址: https://gitcode.com/gh_mirrors/ga/GameAISDK 点击查看 免费下载 本篇技术指南聚焦于如何在 macOS 母机上,通过 Docker 容器方式运行基于图像…

📅 2026/10/5 16:49:17
MORE NEWS

更多资讯

📰

医疗IoT设备安全:MQTT协议漏洞与远程操作模型防护指南

医疗IoT设备控制基础:MQTT协议漏洞与远程操作模型医疗行业这几年联网设备的增长速度,说实话比我预想中快太多了。病房里心电监护、输液泵、血糖仪、智能床垫、中央监护大屏,背后基本都挂在一个统一的消息通道上。你去看这些设备底层的通信协议…

📰

Python回文串检测实战:从双指针到Manacher算法与踩坑总结

面试里几乎必考、实际工程项目里也经常绕不开的Python回文串检测,我在第三次被这道题“坑”了之后,终于决定把完整的思路、写法和踩坑记录整理出来。起因很简单:有一次笔试题目要求判断一个句子中每个单词是否构成回文串,我一开始…

📰

技术逆向英语:工程师从英文文档倒推输入的高效学习法

做技术这行十年下来,我见过太多人英文资料查得飞快、阅读量惊人,但一到开口讲技术方案、写英文邮件就卡壳。我自己也经历过这个阶段,从大学四级边缘水平的英语渣,到后来能用英文主持跨时区会议、技术方案被境外客户直接点名表扬&a…

📰

技术逆向英语:用工程师的逆向思维拆解英文技术文档

“技术逆向英语”这五个字,我第一次见到时,第一反应是“这又是什么新概念”。真正上手之后才明白,它并不是什么玄学,而是把工程师天生就有的那套逆向思维,搬到了英语学习上。简单来说,技术逆向英语就是&…

📰

Linux系统管理与内核实战:从命令行到架构全景指南

1. 先从系统管理和日常运维说起如果把一台 Linux 服务器比作一家公司,那么 root 用户就是总经理,普通用户是各部门员工,而系统里的各种配置文件就是公司的规章制度。我刚接触 Linux 的时候,最大的困惑不是命令记不住,而…

📰

UFS 3.1协议架构解析:从命令下发到闪存写入的完整链路

每次新手机发布会,“UFS 3.1”这个词几乎成了标配,跑分截图里那一串串破2000MB/s的顺序读写数字,看起来赏心悦目。但说句实话,很多搞嵌入式、搞驱动开发的朋友对UFS 3.1的了解,往往也停留在“快”这个层面。UFS 3.1的完…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬