网络原理-TCP/IP(4)

梦里梦外; 2024-04-06 15:17 84阅读 0赞

## TCP原理 ##

### 滑动窗口 ###

之前我们讲过了确认应答策略,对发送的每一个数据段,都要给一个ACK确认应答,收到ACK后再发送下一个数据段. **确认应答,超时重传,连接管理这样的特性都是为了保证可靠运输,但就是付出了传输效率(单位时间能传输数据的多少)的代价**,因为确认应答机制导致了时间大量都花在ACK上.

![0e2152fd35cf4e33b2734ba458963138.png][]

既然这样一发一收的效率比较低,**那么我们一次发送多条数据,就可以大大提高性能**(其实是将多个等待的时间重叠在一起了). (**这是降低损失的策略而不是增加速率的策略**).

![6784ca15d44e4dba95eef2ff1570e8c7.png][]

由上图,这就是滑动窗口方法传递数据的原理,就是**把多次请求的等待时间使用同一份时间来等了,减少了总的等待时间**.

> 1.**窗口大小指的是无需等待确认应答而可以继续发送数据的最大值.上图的窗口大小就是4000个字节(4个段)**;
> 
> 2.发送前四个段时,不需要等待任何ACK,直接发送;
> 
> 3.收到第一个ACK时,滑动窗口向后移动,继续发送第五个段的数据;以此类推;
> 
> 4.操作系统内核为了维护这个滑动窗口,需要开辟**发送缓冲区**来记录当前还有哪些数据没有应答;只有确认过的数据,才能从缓冲区删掉;
> 
> 5.窗口越大,则网络的吞吐量越高;

![c96a14855a7b4453b0e643ca533f7f85.png][]

那么如果出现了丢包,如何进行重传?这里分两种情况讨论.

**情况一:**数据包已经到达,ACK被丢了.

![7ca063b99d074e21b790f44f6636174c.png][]

这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进行确认;(**注意理解:ACK应答报文中的确认序号的含义:eg:2001->2001之前的数据都接收到了**(就包含了1001确认序号的情况)).

**情况二:**数据包直接丢了.

![bf31229fa76b48af9a3f9fbf09c28e69.png][]

> 1.当某一段报文段丢失以后,发送端会一直收到1001这样的ACK,就像是在提醒发送端"我想要的是1001"一样.
> 
> 2.如果发送端主机连续三次收到了同样一个"1001"这样的应答,就会将对应的数据1001-2000重新发送;
> 
> 3.这个时候接收端收到1001之后,再次返回的ACK就是7001了(因为2001-7000)接收端其实之前就已经收到了,被放到了接收端操作系统内核的**接收缓冲区**中.

这种机制称为"高速重发控制"(也叫"快重传");

### 流量控制(流控) ###

我们知道,通过滑动窗口可以提高传输效率,窗口大小越大,更多数据复用同一块时间等待效率越高.但是窗口可以无限大吗?不能.**因为可靠传输的前提->任何提高效率的行为都不影响可靠性**.

**接收端处理数据的速度是有限的,如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包(因为接收端处理不过来了),继而引起丢包重传等一系列连锁反应.**

因此TCP支持**根据接收端的处理能力,来决定发送端的发送速度**.这个机制就叫做流量控制(Flow Control).

> 接收端将自己可以接收的缓冲区大小放入TCP首部中的"窗口大小"字段,通过ACK端通知发送端;
> 
> 窗口大小字段越大,说明网络的吞吐量越高;
> 
> 接收端一旦发现自己的缓冲区快满了,就将窗口大小设置成一个更小的值通知给发送端;
> 
> 发送端接受到这个窗口之后,就会减慢自己的发送速度;
> 
> 如果接收端缓冲区满了,就会把窗口设置为0;这时发送方不再发送数据,但需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端.

![01eb996bd5d44d59b7ce7b16a0124743.png][]

> 接收端如何把窗口大小告诉发送端呢?回忆我们的TCP首部中,有一个16位的窗口字段,就是为了存放窗口大小信息;
> 
> 那么问题来了,16位数字最大表示65535,那么TCP窗口最大就是65535字节吗?
> 
> 实际上,TCP首部40字节选项中还包含了一个窗口扩大因子M,实际窗口大小就是窗口字段的值左移M位.

### 拥塞控制 ###

之前讲到的流量控制是站在接收方的角度来制约发送速度的,虽然它能够高效可靠的发送大量数据,但是如果在开始阶段就发送大量的数据,仍然可能引发问题.

> **因为网络上有很多的计算机,可能当前网络状态就比较拥堵.在不清楚当前网络状态的情况下,贸然发送大量的数据,是很有可能雪上加霜的**.
> 
> TCP引入慢启动机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据.(**核心思路:把中间经过的所有的设备,视为整体,然后通过实验的方式找到合适的速率**).

![5540f3a143cf42d485a1b4bfa48119ce.png][]

> 1.此处引入一个概念为拥塞窗口.
> 
> 2.发送开始时,定义拥塞窗口为1;
> 
> 3.每收到一个ACK应答,拥塞窗口+1;
> 
> 4.每次发送数据包的时候,将拥塞窗口和接收端主机反馈做比较,取较小的值作为实际发送的窗口.
> 
> 5.**如按某窗口大小发送数据之后,出现丢包,就视为中间路径拥堵,就减小窗口大小.**

像上面这样的拥塞窗口的增长速度,是指数级别的,"慢启动"只是指初始时慢,但是增长速度非常快.

> 1.为了不增长的那么快,因此不能使拥塞窗口单纯的加倍.
> 
> 2.此处引入一个叫做慢启动的阈值.
> 
> 3.当拥塞窗口超过这个阈值的时候,不再按指数方式增长,而是按照线性方式增长.
> 
> 4.当TCP开始启动的时候,慢启动阈值等于窗口的最大值.
> 
> 5.在每次超时重发时,慢启动阈值会变为原来的一半,同时拥塞窗口置回1;(这个是旧版本了)
> 
> 少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络堵塞; **形成了一种动态平衡:拥塞窗口的大小始终在变,主要是因为拥塞情况在变**.
> 
> 当TCP通信开始时,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会立即下降.

![c2af8832d3ef4cf1b4a633e399d90ef5.png][]

拥塞控制,归根结底是TCP协议想尽可能快的把数据传给对方,但是又要避免给网络造成太大压力的折中方案.

TCP拥塞控制的这种过程,就像是**热恋的感觉.**

[0e2152fd35cf4e33b2734ba458963138.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/4a12295c4da749eeaa225c4e6249e7da.png
[6784ca15d44e4dba95eef2ff1570e8c7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/2213aac201434b44b9bf63b030c29c3b.png
[c96a14855a7b4453b0e643ca533f7f85.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/e33758dc9ed9485c946551ebbe674e70.png
[7ca063b99d074e21b790f44f6636174c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/a6033954b4e7415894deeda89c8c3cac.png
[bf31229fa76b48af9a3f9fbf09c28e69.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/8ad1105e0c104964aa09e35577b7b03a.png
[01eb996bd5d44d59b7ce7b16a0124743.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/09c1cb2b411c439f800ad65ca44f4c0a.png
[5540f3a143cf42d485a1b4bfa48119ce.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/5062e5f5c23947548fc669a0273a1dd1.png
[c2af8832d3ef4cf1b4a633e399d90ef5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/750f590e56ae44c48384da452b744c86.png