教程知识库【免费下载链接】tech-interview-for-developer 신입 개발자 전공 지식 기술 면접 백과사전 项目地址https://gitcode.com/GitHub_Trending/te/tech-interview-for-developer点击查看免费下载本篇技术指南聚焦于 TCP 在不可靠网络环境下保障可靠传输的两大核心机制——流量控制Flow Control / 흐름제어与拥塞控制Congestion Control / 혼잡제어。这是本仓库 Computer Science/Network 模块下最重要的网络面试考点之一也是区分背概念与真理解的关键分水岭。读完本文你将掌握从为什么 TCP 需要这两种控制到滑动窗口如何滑动、拥塞窗口如何增减、快速重传与快速恢复如何协同的完整原理链条并能直接用韩语/英语术语回答常见面试追问。一、背景为什么 TCP 要在 unreliable network 上构建 reliable network在阅读本篇之前建议先对照仓库中的 OSI 7 계층 理解 TCP 所处的层次传输层Transport Layer使用 TCP / UDP 协议激活通信而 TCP 的特点正是可靠、面向连接。同时可结合 UDP 一文对比理解UDP 仅提供 IP 层面的尽力而为传输错误、乱序、丢失都需要应用层自行处理而 TCP 则通过流量控制与拥塞控制等机制自动补正这些问题。1.1 TCP 通信的本质TCP 是网络通信中面向连接的可靠传输方式신뢰적인 연결방식。其核心设计目标是在本质上不可靠unreliable的网络之上通过协议自身的机制**保证可靠网络reliable network**的传输效果。TCP 采用network congestion avoidance algorithm网络拥塞避免算法并通过流量控制与拥塞控制两条路径共同保障稳定传输。1.2 unreliable network 环境下的四大问题在网络不可靠的环境下数据传输面临四类典型问题问题说明손실丢失数据包可能在传输途中被丢弃순서 바뀜乱序数据包的到达顺序可能发生颠倒Congestion拥塞网络路由器/链路出现拥堵吞吐量骤降Overload过载接收方receiver处理能力或缓冲空间不足而过载这四大问题正是流量控制与拥塞控制需要分别应对的前两者由可靠传输机制序号、确认、重传解决后两者则分别由流量控制解决接收方过载与拥塞控制解决网络拥塞解决。1.3 流量控制与拥塞控制的定义与区别维度流量控制Flow Control / 흐름제어拥塞控制Congestion Control / 혼잡제어控制范围端系统到端系统endsystem to endsystem包含主机与路由器在内的整个网络解决的问题发送方与接收方之间的数据处理速度差异发送方传输速度与网络数据处理速度的差异核心手段接收方将自身状态**反馈feedback**给发送方发送方主动调整发送速率避免网络拥塞关注对象接收方的**接收缓冲receive buffer**容量网络中的包数量是否过度膨胀简而言之流量控制是别把我接收方撑爆拥塞控制是别把网络路由器挤爆。二、流量控制Flow Control / 흐름제어详解2.1 为什么需要流量控制如果接收方的数据处理速度比发送方快通常没有问题但当发送方的发送速度明显快于接收方的处理速度时问题就会出现。接收方拥有有限的存储容量接收缓冲超过其容量后到达的数据会被丢弃。一旦数据丢失发送方会重传、接收方会重复应答导致无谓的应答与重传在收发双方之间频繁发生进一步浪费带宽。因此必须根据接收方的实际处理能力动态调节发送方的数据发送量——这就是流量控制。2.2 一次完整的数据传输过程接收窗口的由来本仓库文档给出了一条非常清晰的端到端数据流链路是理解窗口Window概念的必经之路发送方应用Application在应用层向**套接字Socket**写入数据数据进入传输层Transport Layer被切分为段Segment传输层将段交给**网络层Network Layer**向下传输数据到达接收方后先存入接收缓冲Receive Buffer接收方必须保证接收缓冲不被写满溢出overflow接收方把接收缓冲当前的剩余容量告知发送方这个数值就是수신 윈도우Receive Window接收窗口发送方根据接收窗口的大小发送数据确保不会超出接收缓冲容量由此避免传输过程中接收缓冲溢出保证稳定传输——即플로우 컨트롤Flow Control。一句话总结流量控制的本质就是通过接收窗口这个反馈信号防止接收缓冲在传输过程中溢出是稳定传输不可或缺的技术。2.3 流量控制的两类经典实现2.3.1 Stop and Wait停等式原理每发送一个数据包必须等到该包的确认应答ACK返回后才能发送下一个包。特点实现简单、可靠但链路利用率极低——每一轮都浪费了等待 RTT往返时间的时间吞吐量受限。适用场景吞吐量要求不高的场合或作为理解滑动窗口的入门模型。2.3.2 Sliding Window滑动窗口Go Back N ARQ滑动窗口是流量控制的核心机制也是面试中最常被追问的细节定义允许发送方在接收方设定的窗口大小范围内、无需等待逐一确认即可连续发送多个段的动态流量调节控制技术。目的用于追踪已发送但尚未收到 ACK 的字节数从而在不超过接收方能力的前提下持续发送。其核心约束条件为LastByteSent - LastByteAcked ReceiveWindowAdvertised即最后发送的字节 - 最后确认的字节接收方公布的剩余空间等价于当前在空中在途的数据包数量 滑动窗口大小。运作方式先将窗口内包含的所有数据包一次性发出当这些包的交付被逐一确认后窗口随之向前滑动从而释放新的可发送范围继续发送后续数据包。窗口每滑动一次就有一批新的字节进入可发送状态。2.4 Window窗口机制与 3-way handshake 的配合所有使用 TCP/IP 的主机都维护两个窗口发送窗口Send Window与接收窗口Receive Window。在真正传输业务数据之前双方通过3 way handshaking三次握手完成窗口大小的协商接收方告知自己的 receive window size发送方据此将自己的 send window size 与对方对齐。关于三次握手的完整细节SYN / ACK 交换与连接建立可进一步阅读仓库中的 TCP 3 way handshake 4 way handshake。2.5 滑动窗口的四个关键结构세부구조以字节序号 200~211为例完整拆解发送/接收两端的窗口状态① 송신 버퍼发送缓冲序号200 之前的字节已经发送且已收到确认ACK——可以安全丢弃序号200 ~ 202的字节已经发送但尚未收到确认——在途数据序号203 ~ 211的字节尚未发送——等待窗口滑动后发出。② 수신 윈도우接收窗口表示接收方接收缓冲中当前可用剩余的容量由接收方通过 ACK / 窗口通告字段反馈给发送方是发送方决定发送量的上限依据。③ 송신 윈도우发送窗口发送方实际用于约束在途数据的窗口。只要让发送窗口 接收窗口接收缓冲就不会溢出流量控制即可生效。因此发送窗口的实际大小 min(接收窗口通告值, 拥塞窗口)后者在第三章介绍。④ 송신 윈도우 이동发送窗口的滑动设发送窗口当前覆盖序号 203 ~ 209 附近。发送 203、204 两个字节后接收方收到并返回确认序号 203的 ACK发送方收到该 ACK 后窗口向前滑动Before → After窗口范围随之移动到 203 ~ 209 的新区间滑动之后205 ~ 209 变成新的可发送范围发送方得以继续连续发送从而保证链路始终处于流水线式的高效状态。⑤ Selected Repeat选择性重传作为滑动窗口的增强变体Selective Repeat ARQ它只重传真正丢失的那一个段而不是像 Go Back N 那样回退重传窗口内全部数据能够显著减少重传开销。TCP 的 SACKSelective Acknowledgment选项正是该思路的工程化实现。三、拥塞控制Congestion Control / 혼잡제어详解3.1 为什么需要拥塞控制发送方的数据要经由局域网或互联网等大型网络传递。当流量集中涌向某一个路由器时该路由器将无法处理全部到达的数据。此时各主机只会盲目重传丢失的数据反而加剧网络拥塞最终引发溢出overflow或数据丢失。因此发送方必须主动强制降低发送速率以避免拥塞——这一调节过程就是拥塞控制。术语上**혼잡拥塞**指网络中包数量过度激增的现象**혼잡제어拥塞控制**就是防止或消除该现象的功能。与流量控制的最大区别流量控制只关注收发两端的速率匹配拥塞控制则站在包含主机与路由器在内的全网视角处理传输问题。3.2 AIMDAdditive Increase / Multiplicative Decrease加性增乘性减基本思路开始时每次只发送 1 个包若包顺利到达则将窗口大小单位时间内发送的包数量线性 1继续发送一旦发送失败或超时则将发送速率减半。公平性多个主机共享同一网络时后进入的主机起初处于劣势但随着时间的推移会收敛到平衡状态各主机公平分享带宽。固有缺点初期无法充分利用网络的高带宽达到高吞吐需要较长时间无法提前预判网络即将拥塞只能等到拥塞发生后才降低带宽反应滞后。3.3 Slow Start慢启动动机AIMD 在网络容量附近效率尚可但从零开始慢慢提速耗时过长。原理与 AIMD 一样从 1 个包开始但每收到一个 ACK窗口大小就 1。由于 ACK 会随已发送包的数量呈指数增长因此每个 RTT 周期结束时窗口大小翻倍指数增长即1 → 2 → 4 → 8 → 16 ... 每个 RTT 翻倍与 AIMD 对比发送速率呈指数函数式增长远比 AIMD 的线性增长快。拥塞处理一旦发生拥塞窗口大小直接跌落回 1与 AIMD 的减半不同。关键洞察最初对网络容量毫无先验信息但经历过一次拥塞后就能估算出网络的容量水平。因此改进策略为在上次拥塞发生时窗口大小的一半即慢启动阈值 ssthresh之前继续以指数方式增长越过该阈值后转为线性 1 的温和增长进入拥塞避免阶段Congestion Avoidance。3.4 Fast Retransmit快速重传背景快速重传是追加在 TCP 拥塞控制之上的加速丢包恢复策略。原理接收方如果先到的包缺失、后续包反而先到依旧会发送 ACK但这个 ACK 携带的是按序正确到达的最后一个包的下一个序号即期望收到的序号因此当中间某个包丢失时发送方会收到多个序号重复duplicate的 ACK发送方一旦检测到重复 ACK就能立即重传丢失序号的包而不必等待超时RTO。触发条件收到3 个重复的 ACK即重复序号出现 3 次以上即触发重传。附带动作收到 3 个重复 ACK 说明网络已出现轻度拥塞因此发送方同时减小窗口大小进入拥塞应对状态。3.5 Fast Recovery快速恢复原理发生拥塞时不再把窗口降到 1而是减半后转入线性增长。效果一旦应用了快速恢复经历一次拥塞后系统就会切换到纯 AIMD 式的运行方式——既避免了慢启动从 1 重来的吞吐损失又能迅速进入稳定的线性增长阶段。快速重传 快速恢复组合起来构成了 TCP 在轻度丢包场景下的高效恢复路径。3.6 四种拥塞控制策略对比一览策略增长方式拥塞发生时核心目标AIMD线性 1速率减半公平收敛、避免过度激进Slow Start指数翻倍窗口降为 1快速探测网络容量Fast Retransmit—收到 3 个重复 ACK 即重传并降窗不等超时、快速补丢Fast Recovery减半后线性增长窗口减半而非归零避免吞吐骤降、平滑过渡补充说明从实现演进看这些算法共同构成了 **TCP 拥塞避免congestion avoidance**体系——慢启动负责快速探路拥塞避免阶段线性增长快速重传/快速恢复处理轻度拥塞超时则触发更保守的降窗。Linux 内核中的 TCP 实现如tcp_cong.c、tcp_input.c即是这套机制的具体工程落地。四、仓库佐证本主题在项目中的面试定位本仓库是面向新人开发者的技术面试百科README.md 中明确定位为 신입 개발자 전공 지식 기술 면접 백과사전该主题在面试清单中占据明确位置Interview/Interview List.md 中直接收录了相关考点TCP란?——明确要求回答 **흐름제어流量控制与 혼잡제어拥塞控制**的定义흐름제어 : 송신 측과 수신 측의 데이터 처리 속도 차이를 조절해주는 것调节收发双方数据处理速度差异혼잡 제어 : 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것防止网络内包数量过度膨胀并强调 TCP 正是通过流量控制与拥塞控制保证数据顺序与可靠性代价是传输速度较慢因此适用于 HTTP 通信、电子邮件、文件传输等对准确性要求高的场景。TCP 3 way handshake 4 way handshake 补充了窗口协商所依赖的连接建立/释放前置知识——连接建立3-way与数据可靠传输本主题共同构成 TCP 面试的完整知识闭环。与之对照的 UDP 则从反面印证UDP 不做流量/拥塞控制以牺牲可靠性换取速度主要用于实时广播、在线游戏与 DNS 查询等场景。五、高频面试追问与回答要点自查清单流量控制与拥塞控制的区别→ 作用域不同前者端到端、管接收方缓冲后者全网视角、管路由器/链路拥塞。接收窗口Receive Window是如何产生的→ 接收方将接收缓冲剩余容量通告给发送方发送方据此限制在途字节数LastByteSent - LastByteAcked ReceiveWindowAdvertised。滑动窗口如何工作→ 一次发送窗口内全部包确认后窗口前滑新范围变为可发送区窗口滑动是确认驱动的。慢启动为什么是指数增长→ 每收到一个 ACK 窗口 1RTT 内 ACK 随已发包数倍增故每 RTT 窗口翻倍。快速重传的触发条件→ 收到 3 个重复 ACK无需等待超时立即重传丢失序号并降低窗口。快速恢复与慢启动在拥塞后的差异→ 慢启动窗口归 1 重新指数爬升快速恢复窗口减半后线性增长之后按纯 AIMD 运行。六、延伸阅读仓库内相关资源TCP 3 way handshake 4 way handshake —— 连接建立与释放过程OSI 7 계층 —— TCP 在传输层中的位置与职责UDP —— 与 TCP 的可靠性对照Interview/Interview List.md —— 网络类面试题库与答题模板赞分享教程知识库【免费下载链接】tech-interview-for-developer 신입 개발자 전공 지식 기술 면접 백과사전 项目地址https://gitcode.com/GitHub_Trending/te/tech-interview-for-developer点击查看免费下载相关推荐Meteor 3 异步函数完全指南从回调到 Promise 的 API 迁移实战Meteor 3 异步函数完全指南从回调到 Promise 的 API 迁移实战 Meteor 3 将 Promise 作为所有异步操作的标准 API大量回文档教程知识库tech-interview-for-developer多线程编程面试-锁同步并发控制tech interview for developer多线程编程面试 锁同步并发控制 面试痛点为什么多线程编程总是让人头疼 还在为多线程面试问题感教程知识库QMUI Web桌面版使用教程可视化管理项目从未如此简单QMUI Web桌面版使用教程可视化管理项目从未如此简单 QMUI Web是一个专注Web UI开发的前端框架通过强大的SASS方法合集与内置工作流帮助开上一篇3个步骤快速搭建专业级IPTV播放源检测系统iptv-checker完整指南下一篇1.2B参数撬动边缘智能革命LG EXAONE 4.0重塑端侧AI格局创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 tech-interview-for-developer 网络面试专题：TCP 流量控制（흐름제어）与拥塞控制（혼잡제어）机制全解
教程知识库【免费下载链接】tech-interview-for-developer 신입 개발자 전공 지식 기술 면접 백과사전 项目地址https://gitcode.com/GitHub_Trending/te/tech-interview-for-developer点击查看免费下载本篇技术指南聚焦于 TCP 在不可靠网络环境下保障可靠传输的两大核心机制——流量控制Flow Control / 흐름제어与拥塞控制Congestion Control / 혼잡제어。这是本仓库 Computer Science/Network 模块下最重要的网络面试考点之一也是区分背概念与真理解的关键分水岭。读完本文你将掌握从为什么 TCP 需要这两种控制到滑动窗口如何滑动、拥塞窗口如何增减、快速重传与快速恢复如何协同的完整原理链条并能直接用韩语/英语术语回答常见面试追问。一、背景为什么 TCP 要在 unreliable network 上构建 reliable network在阅读本篇之前建议先对照仓库中的 OSI 7 계층 理解 TCP 所处的层次传输层Transport Layer使用 TCP / UDP 协议激活通信而 TCP 的特点正是可靠、面向连接。同时可结合 UDP 一文对比理解UDP 仅提供 IP 层面的尽力而为传输错误、乱序、丢失都需要应用层自行处理而 TCP 则通过流量控制与拥塞控制等机制自动补正这些问题。1.1 TCP 通信的本质TCP 是网络通信中面向连接的可靠传输方式신뢰적인 연결방식。其核心设计目标是在本质上不可靠unreliable的网络之上通过协议自身的机制**保证可靠网络reliable network**的传输效果。TCP 采用network congestion avoidance algorithm网络拥塞避免算法并通过流量控制与拥塞控制两条路径共同保障稳定传输。1.2 unreliable network 环境下的四大问题在网络不可靠的环境下数据传输面临四类典型问题问题说明손실丢失数据包可能在传输途中被丢弃순서 바뀜乱序数据包的到达顺序可能发生颠倒Congestion拥塞网络路由器/链路出现拥堵吞吐量骤降Overload过载接收方receiver处理能力或缓冲空间不足而过载这四大问题正是流量控制与拥塞控制需要分别应对的前两者由可靠传输机制序号、确认、重传解决后两者则分别由流量控制解决接收方过载与拥塞控制解决网络拥塞解决。1.3 流量控制与拥塞控制的定义与区别维度流量控制Flow Control / 흐름제어拥塞控制Congestion Control / 혼잡제어控制范围端系统到端系统endsystem to endsystem包含主机与路由器在内的整个网络解决的问题发送方与接收方之间的数据处理速度差异发送方传输速度与网络数据处理速度的差异核心手段接收方将自身状态**反馈feedback**给发送方发送方主动调整发送速率避免网络拥塞关注对象接收方的**接收缓冲receive buffer**容量网络中的包数量是否过度膨胀简而言之流量控制是别把我接收方撑爆拥塞控制是别把网络路由器挤爆。二、流量控制Flow Control / 흐름제어详解2.1 为什么需要流量控制如果接收方的数据处理速度比发送方快通常没有问题但当发送方的发送速度明显快于接收方的处理速度时问题就会出现。接收方拥有有限的存储容量接收缓冲超过其容量后到达的数据会被丢弃。一旦数据丢失发送方会重传、接收方会重复应答导致无谓的应答与重传在收发双方之间频繁发生进一步浪费带宽。因此必须根据接收方的实际处理能力动态调节发送方的数据发送量——这就是流量控制。2.2 一次完整的数据传输过程接收窗口的由来本仓库文档给出了一条非常清晰的端到端数据流链路是理解窗口Window概念的必经之路发送方应用Application在应用层向**套接字Socket**写入数据数据进入传输层Transport Layer被切分为段Segment传输层将段交给**网络层Network Layer**向下传输数据到达接收方后先存入接收缓冲Receive Buffer接收方必须保证接收缓冲不被写满溢出overflow接收方把接收缓冲当前的剩余容量告知发送方这个数值就是수신 윈도우Receive Window接收窗口发送方根据接收窗口的大小发送数据确保不会超出接收缓冲容量由此避免传输过程中接收缓冲溢出保证稳定传输——即플로우 컨트롤Flow Control。一句话总结流量控制的本质就是通过接收窗口这个反馈信号防止接收缓冲在传输过程中溢出是稳定传输不可或缺的技术。2.3 流量控制的两类经典实现2.3.1 Stop and Wait停等式原理每发送一个数据包必须等到该包的确认应答ACK返回后才能发送下一个包。特点实现简单、可靠但链路利用率极低——每一轮都浪费了等待 RTT往返时间的时间吞吐量受限。适用场景吞吐量要求不高的场合或作为理解滑动窗口的入门模型。2.3.2 Sliding Window滑动窗口Go Back N ARQ滑动窗口是流量控制的核心机制也是面试中最常被追问的细节定义允许发送方在接收方设定的窗口大小范围内、无需等待逐一确认即可连续发送多个段的动态流量调节控制技术。目的用于追踪已发送但尚未收到 ACK 的字节数从而在不超过接收方能力的前提下持续发送。其核心约束条件为LastByteSent - LastByteAcked ReceiveWindowAdvertised即最后发送的字节 - 最后确认的字节接收方公布的剩余空间等价于当前在空中在途的数据包数量 滑动窗口大小。运作方式先将窗口内包含的所有数据包一次性发出当这些包的交付被逐一确认后窗口随之向前滑动从而释放新的可发送范围继续发送后续数据包。窗口每滑动一次就有一批新的字节进入可发送状态。2.4 Window窗口机制与 3-way handshake 的配合所有使用 TCP/IP 的主机都维护两个窗口发送窗口Send Window与接收窗口Receive Window。在真正传输业务数据之前双方通过3 way handshaking三次握手完成窗口大小的协商接收方告知自己的 receive window size发送方据此将自己的 send window size 与对方对齐。关于三次握手的完整细节SYN / ACK 交换与连接建立可进一步阅读仓库中的 TCP 3 way handshake 4 way handshake。2.5 滑动窗口的四个关键结构세부구조以字节序号 200~211为例完整拆解发送/接收两端的窗口状态① 송신 버퍼发送缓冲序号200 之前的字节已经发送且已收到确认ACK——可以安全丢弃序号200 ~ 202的字节已经发送但尚未收到确认——在途数据序号203 ~ 211的字节尚未发送——等待窗口滑动后发出。② 수신 윈도우接收窗口表示接收方接收缓冲中当前可用剩余的容量由接收方通过 ACK / 窗口通告字段反馈给发送方是发送方决定发送量的上限依据。③ 송신 윈도우发送窗口发送方实际用于约束在途数据的窗口。只要让发送窗口 接收窗口接收缓冲就不会溢出流量控制即可生效。因此发送窗口的实际大小 min(接收窗口通告值, 拥塞窗口)后者在第三章介绍。④ 송신 윈도우 이동发送窗口的滑动设发送窗口当前覆盖序号 203 ~ 209 附近。发送 203、204 两个字节后接收方收到并返回确认序号 203的 ACK发送方收到该 ACK 后窗口向前滑动Before → After窗口范围随之移动到 203 ~ 209 的新区间滑动之后205 ~ 209 变成新的可发送范围发送方得以继续连续发送从而保证链路始终处于流水线式的高效状态。⑤ Selected Repeat选择性重传作为滑动窗口的增强变体Selective Repeat ARQ它只重传真正丢失的那一个段而不是像 Go Back N 那样回退重传窗口内全部数据能够显著减少重传开销。TCP 的 SACKSelective Acknowledgment选项正是该思路的工程化实现。三、拥塞控制Congestion Control / 혼잡제어详解3.1 为什么需要拥塞控制发送方的数据要经由局域网或互联网等大型网络传递。当流量集中涌向某一个路由器时该路由器将无法处理全部到达的数据。此时各主机只会盲目重传丢失的数据反而加剧网络拥塞最终引发溢出overflow或数据丢失。因此发送方必须主动强制降低发送速率以避免拥塞——这一调节过程就是拥塞控制。术语上**혼잡拥塞**指网络中包数量过度激增的现象**혼잡제어拥塞控制**就是防止或消除该现象的功能。与流量控制的最大区别流量控制只关注收发两端的速率匹配拥塞控制则站在包含主机与路由器在内的全网视角处理传输问题。3.2 AIMDAdditive Increase / Multiplicative Decrease加性增乘性减基本思路开始时每次只发送 1 个包若包顺利到达则将窗口大小单位时间内发送的包数量线性 1继续发送一旦发送失败或超时则将发送速率减半。公平性多个主机共享同一网络时后进入的主机起初处于劣势但随着时间的推移会收敛到平衡状态各主机公平分享带宽。固有缺点初期无法充分利用网络的高带宽达到高吞吐需要较长时间无法提前预判网络即将拥塞只能等到拥塞发生后才降低带宽反应滞后。3.3 Slow Start慢启动动机AIMD 在网络容量附近效率尚可但从零开始慢慢提速耗时过长。原理与 AIMD 一样从 1 个包开始但每收到一个 ACK窗口大小就 1。由于 ACK 会随已发送包的数量呈指数增长因此每个 RTT 周期结束时窗口大小翻倍指数增长即1 → 2 → 4 → 8 → 16 ... 每个 RTT 翻倍与 AIMD 对比发送速率呈指数函数式增长远比 AIMD 的线性增长快。拥塞处理一旦发生拥塞窗口大小直接跌落回 1与 AIMD 的减半不同。关键洞察最初对网络容量毫无先验信息但经历过一次拥塞后就能估算出网络的容量水平。因此改进策略为在上次拥塞发生时窗口大小的一半即慢启动阈值 ssthresh之前继续以指数方式增长越过该阈值后转为线性 1 的温和增长进入拥塞避免阶段Congestion Avoidance。3.4 Fast Retransmit快速重传背景快速重传是追加在 TCP 拥塞控制之上的加速丢包恢复策略。原理接收方如果先到的包缺失、后续包反而先到依旧会发送 ACK但这个 ACK 携带的是按序正确到达的最后一个包的下一个序号即期望收到的序号因此当中间某个包丢失时发送方会收到多个序号重复duplicate的 ACK发送方一旦检测到重复 ACK就能立即重传丢失序号的包而不必等待超时RTO。触发条件收到3 个重复的 ACK即重复序号出现 3 次以上即触发重传。附带动作收到 3 个重复 ACK 说明网络已出现轻度拥塞因此发送方同时减小窗口大小进入拥塞应对状态。3.5 Fast Recovery快速恢复原理发生拥塞时不再把窗口降到 1而是减半后转入线性增长。效果一旦应用了快速恢复经历一次拥塞后系统就会切换到纯 AIMD 式的运行方式——既避免了慢启动从 1 重来的吞吐损失又能迅速进入稳定的线性增长阶段。快速重传 快速恢复组合起来构成了 TCP 在轻度丢包场景下的高效恢复路径。3.6 四种拥塞控制策略对比一览策略增长方式拥塞发生时核心目标AIMD线性 1速率减半公平收敛、避免过度激进Slow Start指数翻倍窗口降为 1快速探测网络容量Fast Retransmit—收到 3 个重复 ACK 即重传并降窗不等超时、快速补丢Fast Recovery减半后线性增长窗口减半而非归零避免吞吐骤降、平滑过渡补充说明从实现演进看这些算法共同构成了 **TCP 拥塞避免congestion avoidance**体系——慢启动负责快速探路拥塞避免阶段线性增长快速重传/快速恢复处理轻度拥塞超时则触发更保守的降窗。Linux 内核中的 TCP 实现如tcp_cong.c、tcp_input.c即是这套机制的具体工程落地。四、仓库佐证本主题在项目中的面试定位本仓库是面向新人开发者的技术面试百科README.md 中明确定位为 신입 개발자 전공 지식 기술 면접 백과사전该主题在面试清单中占据明确位置Interview/Interview List.md 中直接收录了相关考点TCP란?——明确要求回答 **흐름제어流量控制与 혼잡제어拥塞控制**的定义흐름제어 : 송신 측과 수신 측의 데이터 처리 속도 차이를 조절해주는 것调节收发双方数据处理速度差异혼잡 제어 : 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것防止网络内包数量过度膨胀并强调 TCP 正是通过流量控制与拥塞控制保证数据顺序与可靠性代价是传输速度较慢因此适用于 HTTP 通信、电子邮件、文件传输等对准确性要求高的场景。TCP 3 way handshake 4 way handshake 补充了窗口协商所依赖的连接建立/释放前置知识——连接建立3-way与数据可靠传输本主题共同构成 TCP 面试的完整知识闭环。与之对照的 UDP 则从反面印证UDP 不做流量/拥塞控制以牺牲可靠性换取速度主要用于实时广播、在线游戏与 DNS 查询等场景。五、高频面试追问与回答要点自查清单流量控制与拥塞控制的区别→ 作用域不同前者端到端、管接收方缓冲后者全网视角、管路由器/链路拥塞。接收窗口Receive Window是如何产生的→ 接收方将接收缓冲剩余容量通告给发送方发送方据此限制在途字节数LastByteSent - LastByteAcked ReceiveWindowAdvertised。滑动窗口如何工作→ 一次发送窗口内全部包确认后窗口前滑新范围变为可发送区窗口滑动是确认驱动的。慢启动为什么是指数增长→ 每收到一个 ACK 窗口 1RTT 内 ACK 随已发包数倍增故每 RTT 窗口翻倍。快速重传的触发条件→ 收到 3 个重复 ACK无需等待超时立即重传丢失序号并降低窗口。快速恢复与慢启动在拥塞后的差异→ 慢启动窗口归 1 重新指数爬升快速恢复窗口减半后线性增长之后按纯 AIMD 运行。六、延伸阅读仓库内相关资源TCP 3 way handshake 4 way handshake —— 连接建立与释放过程OSI 7 계층 —— TCP 在传输层中的位置与职责UDP —— 与 TCP 的可靠性对照Interview/Interview List.md —— 网络类面试题库与答题模板赞分享教程知识库【免费下载链接】tech-interview-for-developer 신입 개발자 전공 지식 기술 면접 백과사전 项目地址https://gitcode.com/GitHub_Trending/te/tech-interview-for-developer点击查看免费下载相关推荐Meteor 3 异步函数完全指南从回调到 Promise 的 API 迁移实战Meteor 3 异步函数完全指南从回调到 Promise 的 API 迁移实战 Meteor 3 将 Promise 作为所有异步操作的标准 API大量回文档教程知识库tech-interview-for-developer多线程编程面试-锁同步并发控制tech interview for developer多线程编程面试 锁同步并发控制 面试痛点为什么多线程编程总是让人头疼 还在为多线程面试问题感教程知识库QMUI Web桌面版使用教程可视化管理项目从未如此简单QMUI Web桌面版使用教程可视化管理项目从未如此简单 QMUI Web是一个专注Web UI开发的前端框架通过强大的SASS方法合集与内置工作流帮助开上一篇3个步骤快速搭建专业级IPTV播放源检测系统iptv-checker完整指南下一篇1.2B参数撬动边缘智能革命LG EXAONE 4.0重塑端侧AI格局创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考