TCP 协议 の 流量控制

简介

流量控制是一个 ** 速度匹配服务 ** (匹配发送方的发送速率与接收方的读取速率)，因为发送方发送数据的速率和接收方处理数据的速率不一定匹配，当发送方发送速率大于接收方的处理速率时，就有可能因接收方来不及接收数据而导致数据丢失。所以 ** 流量控制就是一种用于控制发送方的数据发送速率以使得接收方能够来得及接收数据的机制 ** 。

在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，这就是 ** 接收窗口 rwnd **，即调整 TCP 报文段首部中的“窗口”字段值，来限制发送方向网络注入报文的速率。同时，发送方会根据其对当前网络拥塞程度的估计而确定一个窗口值，称为 ** 拥塞窗口 cwnd ** ，其大小与网络的带宽和时延密切相关。最后实际在网络中传输的报文数应该rwnd 和 cwnd 中的较小者。

控制算法 -- 滑动窗口协议

TCP 报文头部有一个窗口字段，这个字段用于控制发送方能够发送的数据量。每发送一个TCP 报文段，发送方就能够通过这个字段就能够告诉对方当前我的接收窗口（rwnd）的大小（也就是我能够接收的最大字节数），然后接收方就应该调整自己的数据发送量不大于该值。
rwnd > 0：表示数据接收方所能够接收的 ** 字节数 ** ；
rwnd = 0：表示数据接收方的缓存区已满，不想接收数据了，此时发送方不应向网络中发送任何数据，直至接收方重新发送一个 rwnd > 0 的 TCP 报文告诉发送方可以接收数据为止。
** 互相等待的死锁局面 ** ：当接收方设置了一个 rwnd = 0 的窗口后，发送方会停止发送数据，等待接收方重新控制接收窗口的大小。然后接收方可以继续接收数据时，向发送方发送一个重新控制窗口的报文段，然后等待发送方继续发送数据。然而可能很不幸地丢失了这个重设窗口的报文，那么收发双方都将处于等待对方传送数据的状态，由此也就进入了收发双方相互等待的死锁局面。
** 解决策略 ** ：为了解决收发双方均可能出现相互等待的死锁局面的问题，TCP 为每一个连接均设有一个 ** 持续计时器 ** (persistence timer)。只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个 ** 零窗口探测报文段 ** （携 1 字节的数据），而对方就在确认这个探测报文段时给出当前的窗口值。若窗口仍然为 0，则收到该报文段的一方就重设持续计时器。若窗口不为0，则发送方就可以根据该窗口值继续发送报文。

TCP 报文发送时机

应用程序将数据发送到 TCP 的发送缓冲区后，剩下的发送过程就交给 TCP 来控制了，所以为了尽可能提高传输速率，就需要采用不同的发送机制来控制 TCP 报文的发送时机。

1. TCP 维持一个变量，该变量等于最大报文段长度 MSS。只要缓存中存放的数据达到MSS 字节，就组装成一个 TCP 报文段发送出去。
2. 由发送方的应用进程指明要求发送的报文段长度，即 TCP 支持的推送( push )操作。
3. 发送方设置一个计时器，当发送方的一个计时器期限到期时，就将已有的缓存数据装入报文段(但长度不能超过 MSS )发送出去。

*** Nagle 算法 ***
若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方接收对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段再发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。Nagle 算法还规定：当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。

*** 糊涂窗口综合证 ***
TCP 接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取 1 字节（这样就使接收缓存空间仅腾出 1 字节），然后向发送方发送确认，并把窗口设置为 1 个字节（但发送的数据报为 40 字节的的话）。接着，发送方又发来 1 个字节的数据（发送方的 IP 数据报是 41 字节，40 字节头部）。接收方发回确认，仍然将窗口设置为 1 个字节。这样，网络的效率很低。要解决这个问题，可让接收方等待一段时间，等到接收缓存有足够空间容纳一个最长的报文段，或等到接收方缓存已有一半空闲的空间时，接收方才发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小再发送。

上述两种算法可以配合使用，使得在发送方不发送很小的报文段的同时，接收方也不至于在接收缓存还不够大时就急忙通知发送方发送数据，从而尽可能提高网络带宽利用率和数据吞吐量。

滑动窗口协议与停止等待协议的区别

*** 停止等待协议 ***
发送方每发送完一个报文段后就停止发送，等待接收方的确认报文，在收到确认报文段后再继续发送数据。

*** 连续ARQ协议 ***
发送方维持一个发送窗口，位于发送窗口中的数据都可以连续发送出去，而无需等待对方的确认，以此提高信道利用率。每收到一个确认报文，发送方就将滑动窗口向前滑动一个分组长度。接收方则一般采用 ** 累计确认 ** 的方式，即接收方不必对收到的报文段逐个确认，而是在收到几个分组后，只对按序到达的最后一个分组发送确认报文，表明到该分组为止的所有报文均已正确收到。 ** 优点 ** ：实现简单，即便确认报文丢失也不必重传； ** 缺点 ** ：接收方无法向发送方全面反映自己已经接收到的正确报文情况。

滑动窗口协议与停止等待协议的区别：

1. 滑动窗口协议中，允许发送方发送多个分组(当有多个分组可用时)， 而不需等待确认，但它受限于在流水线中未确认的分组数不能超过某个最大允许数 N。
2. 滑动窗口协议是 TCP 使用的一种控制流量的方法，此协议能够加速数据的传输。 只有在接收窗口向前滑动时(与此同时也发送了确认)， 发送窗口才有可能向前滑动。收发两端的窗口按照以上规律不断地向前滑动，因此这种协议称为滑动窗口协议。
3. 当发送窗口和接收窗口的大小都等于 1 时，就是停止等待协议。