Day7： TCP：拥塞控制原理、 TCP拥塞控制

Day7的第二篇Study blog。
偷博仔，day day up！
欣赏一下 《🔅小花的信念》

在山石组成的路上
浮起一片小花
它们用金黄的微笑
来回报石块的冷遇
它们相信
最后，石块也会发芽
也会粗糙地微笑
在阳光和树影间
露出善良的牙齿
———— 1981年4月

小花信念如此，吾辈岂能且过。（言重了，言重了）
正片开始

---

一、TCP：拥塞控制原理

拥塞没有一个Authoritative(权威的)定义。

---

拥塞: （congestion）

•  非正式的定义:“太多的数据需要网络传输，超过了网络的处理能力”

•  与流量控制不同

•  拥塞的表现:

  •  分组丢失 (路由器缓冲区溢出)
  •  分组经历比较长的延迟(在路由器的队列中排队)

•  网络中前10位的问题!

我又搜了一些网络拥塞的说法：

网络拥塞（congestion）
是指在分组交换网络中传送分组的数目太多时，
由于存储转发节点的资源有限而造成网络传输性能下降的情况。
`
当网络发生拥塞时，一般会出现数据丢失，时延增加，吞吐量下降，
严重时甚至会导致“拥塞崩溃”。
通常情况下，当网络中负载过度增加致使网络性能下降时，就会发生网络拥塞。

一篇知乎上的文章：通俗易懂跟你讲解什么是拥塞控制？
我CV了一小段过来：

为了方便，我们假设主机A给主机B传输数据。
我们知道，两台主机在传输数据包的时候，如果发送方迟迟没有收到接收方反馈的ACK，
那么发送方就会认为它发送的数据包丢失了，进而会重新传输这个丢失的数据包。
然而实际情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了，
而A发送的数据包被堵在了半路，迟迟没有到达B。
这个时候A误认为是发生了丢包情况，会重新传输这个数据包。
结果就是不仅浪费了信道资源，还会使网络更加拥塞。
因此，我们需要进行拥塞控制。

---

下面先通过一些场景，
说明网络拥塞的原因和代价，再来谈谈解决办法

---

1.拥塞的原因/代价:

1.1场景1

链路容量带宽是R （bps）,有两个发送端（连接）所以每个连接最大吞吐量为R/2.
所以从吞吐量的角度看，“灌入”多少“速率”就能“泵”出多少“速率”
However，
从Delay的perspective看，（角度看）
Delay激增
鱼与熊掌不可得兼

---

1.2场景2

•  一个路由器，有限的缓冲
•  分组丢失时，发送端重传
  • 应用层的输入=应用层输出: λ_in = λ_out
  •  传输层的输入包括重传: λ_in’’ >= λ_in
    

---

对于上述的场景2，有以下两个理想化Assumptions

理想化1:
发送端有完美的信息
发送端知道什么时候路由器的缓冲是可用的

输入/输出情况还是如图这样：但是
但是延迟情况没有改观。 哎呀，这不啥都没变嘛

---

---

理想化2: 掌握丢失信息
分组可以丢失，在路由器由于缓冲器满而被丢弃

•  如果知道分组丢失了，发送方重传分组