按关键词阅读： 网络 拥塞控制 Reno TCP BBR
文章插图
在涉及到网络知识的面试中 ， TCP 和 UDP 是经常被提及的两个概念 ， 它们是 OSI 模型中的运输层中的协议 ， 关于 TCP 和 UDP ， 以下有一些简要的介绍：
TCP 全称为传输控制协议 。 这种协议可以提供面向连接的、可靠的、点到点的通信 ， 所谓可靠 ， 在于 TCP 建立连接时双方需要互相确认 ， 类似打电话 ， 在专业术语中称为 3 次握手 。
UDP 全称为用户数据报协议 ， 它可以提供非连接的不可靠的点到多点的通信 ， 所谓不可靠 ， 在于 UDP 每一次发送数据需要绑定 IP 和端口号 ， 但是对于已经发送出去的数据来说并不去确认 ， 也不需要类似 TCP 的三次握手的过程 ， 由于没有了这个过程 ， 所以其传输效率较之 TCP 来说要高许多 。
对于这两者 ， 有一些简单且重要的区别 ， 在面试中也经常被问到：
文章插图
「TCP 3 次握手的过程」 ， 「TCP 4 次挥手的过程」等考点大家可能已经比较清楚了 ， 在此就不多做叙述 。 在字节跳动的面试中还问了这么一道题：
TCP 的拥塞控制原理是什么？UDP 有对应的拥塞控制功能嘛？
这个问题似乎看起来比较冷门 ， 前段时间「BBR」这个概念很火 ， 大家都给自己的服务器跟风加上了「BBR」并感受到了传输数据效率的提升 ， 但是也许并不是很清楚具体的原理 。 那么 ， TCP 的拥塞控制究竟是什么呢？
文章插图
什么是 TCP 拥塞控制TCP 拥塞控制的目标是最大化利用网络上瓶颈链路的带宽 。
简单来说是将网络链路比喻成一根水管 ， 如果我们希望尽可能地使用网络传输数据 ， 方法就是给水管注水 ， 就有如下公式：
水管内的水的数量 = 水管的容积 = 水管粗细 × 水管长度
对应的网络名词就是：
网络内尚未被确认收到的数据包数量 = 网络链路上能容纳的数据包数量 = 链路带宽 × 往返延迟
文章插图
为了保证水管不会爆管 ， TCP 维护一个拥塞窗口cwnd（congestion window） ， 用来估计在一段时间内这条链路（水管中）可以承载和运输的数据（水）的数量 ， 拥塞窗口的大小取决于网络的拥塞程度 ， 并且动态地在变化 ， 但是为了达到最大的传输效率 ， 我们该如何知道这条水管的运送效率是多少呢？
一个简单的方法就是不断增加传输的水量 ， 直到水管破裂为止（对应到网络上就是发生丢包） ， 用 TCP 的描述就是：
【网络|头条面试题 | TCP 的拥塞控制原理】只要网络中没有出现拥塞 ， 拥塞窗口的值就可以再增大一些 ， 以便把更多的数据包发送出去 ， 但只要网络出现拥塞 ， 拥塞窗口的值就应该减小一些 ， 以减少注入到网络中的数据包数 。
文章插图
常见的 TCP 拥塞控制算法本文将例举目前 Linux 内核默认的 Reno 算法和 Google 的 BBR 算法进行说明 ， 其中基于丢包的拥塞控制算法 Reno 由于非常著名 ， 所以常常作为教材的重点说明对象 。
Reno
Reno 被许多教材（例如：《计算机网络——自顶向下的方法》）所介绍 ， 适用于低延时、低带宽的网络 ， 它将拥塞控制的过程分为四个阶段：慢启动、拥塞避免、快重传和快恢复 ， 对应的状态如下所示：
文章插图
- 慢启动阶段思路是不要一开始就发送大量的数据 ， 先探测一下网络的拥塞程度 ， 也就是说由小到大逐渐增加拥塞窗口的大小 ， 在没有出现丢包时每收到一个 ACK 就将拥塞窗口大小加一（单位是 MSS ， 最大单个报文段长度） ， 每轮次发送窗口增加一倍 ， 呈指数增长 ， 若出现丢包 ， 则将拥塞窗口减半 ， 进入拥塞避免阶段；
- 当窗口达到慢启动阈值或出现丢包时 ， 进入拥塞避免阶段 ， 窗口每轮次加一 ， 呈线性增长；当收到对一个报文的三个重复的 ACK 时 ， 认为这个报文的下一个报文丢失了 ， 进入快重传阶段 ， 要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方 ， 可提高网络吞吐量约20%）而不要等到自己发送数据时捎带确认；
- 快重传完成后进入快恢复阶段 ， 将慢启动阈值修改为当前拥塞窗口值的一半 ， 同时拥塞窗口值等于慢启动阈值 ， 然后进入拥塞避免阶段 ， 重复上述过程 。
稿源：(未知)
【傻大方】网址：http://www.shadafang.com/c/111J311292020.html
标题：网络|头条面试题 | TCP 的拥塞控制原理