TCP、UDP和流量控制、拥塞控制

素颜马尾好姑娘i 2022-02-21 14:23 397阅读 0赞

**1.TCP和UDP之间的区别**

1.TCP 是面向连接的传输层协议，应用程序在使用 TCP 协议之前，必须先建立 TCP 连接，传输数据完后，需要释放 TCP 连接。UDP 是无连接的，发送数据之前不需要建立连接，因此减少了开销和发送数据的时延。

2.每一条 TCP 连接只能有两个端点，所以 TCP 连接是点对点的。UDP 支持一对一，一对多，多对一和多对多的相互通信。

3.TCP 提供可靠交互的服务，通过 TCP 连接传送的数据，无差错，不丢失，不重复，按序到达。UDP 使用尽最大努力交付，即不保证交付可靠。

4.TCP 是面向字节流的，TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流，TCP 不关心把多长的报文发送到缓存中，而是根据对方给出的窗口和网络拥塞程度来决定一个报文段应包含多少个字节。UDP 是面向报文的，UDP 对应用层交下来的报文既不合并也不拆分，一次交付一个完整的报文。

5.TCP 有拥塞控制，UDP 没有拥塞控制，很多实时应用（IP电话，视频会议等），要求主机恒定速率发送数据，并且允许在拥塞的时候丢失数据，所以很适合 UDP。

6.UDP 首部开销小，只有8个字节。TCP 首部 20 个字节。

7.TCP 提供全双工通信，允许通信双方在任何时候发送数据，TCP 连接两端都有发送缓存和接收缓存。

**2.TCP的可靠传输的工作原理**

**a.停止等待协议/超时重传：**

停止等待就是每发完一个分组，就停止发送，等待对方的确认，在收到确认后再发送下一个分组。

如果超过一段时间没有收到确认，就认为刚才发送的分组丢失了，因而重传刚发发送的分组，这就叫做超时重传。

超时重传时间应当比数据在分组传输的平均往返时间更长一点。

使用停止等待协议的信道利用率很低。

上述这种可靠传输协议被称为自动重传请求 ARQ（Automatic Repeat-reQuest）。

ARQ协议，即自动重传请求（Automatic Repeat-reQuest），是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议，拥有错误检测（Error Detection）、正面确认（Positive Acknowledgment）、超时重传（Retransmission after Timeout）和 负面确认及重传（Negative Acknowledgment and Retransmission）等机制。

**b.流水线传输**

停止等待协议的优点是简单，但是信道利用率太低了。解决方法是采用连续ARQ协议，流水线传输使用的就是连续 ARQ 协议和滑动窗口协议。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70]

首先，位于发送窗口内的分组都可以连续的发送出去，而不需要等待对方的确认。当所有的分组都发送出去以后，根据连续 ARQ 协议规定，发送方每接收到一个确认，就可以把发送窗口向前移动一个分组的位置。

连续ARQ 协议：

我们先看一下停止等待协议的信道利用率：

![在这里插入图片描述][20190411092102598.png]

由于停止等待ARQ协议信道利用率太低，所以需要使用连续ARQ协议来进行改善。这个协议会连续发送一组数据包，然后再等待这些数据包的ACK。

发送方采用流水线传输。流水线传输就是发送方可以连续发送多个分组，不必每发完一个分组就停下来等待对方确认。如下图所示：

![在这里插入图片描述][2019041109214196.png]

连续ARQ协议通常是结合滑动窗口协议来使用的，发送方需要维持一个发送窗口，如下图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 1]  
图（a）是发送方维持的发送窗口，它的意义是：位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方的确认，这样就提高了信道利用率。

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。例如上面的图（b），当发送方收到第一个分组的确认，就把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，则现在可以发送窗口内的第6个分组。

接收方一般都是采用**累积确认**的方式。也就是说接收方不必对收到的分组逐个发送确认。而是在收到几个分组后，**对按序到达的最后一个分组发送确认**（前面的小组都要检查，但是只是对所有OK的分组中最后一个返回确认，这样就可以节省时间了）。如果收到了这个分组确认信息，则表示到这个分组为止的所有分组都已经正确接收到了。

累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是，不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。比如发送方发送了前5个分组，而中间的第3个分组丢失了，这时候接收方只能对前2个发出确认（他说的只对最后一个分组确认，是对所有分组都确认，但是只发送给对方最后一个分组的确认信息，其他的组还是要检查）。而不知道后面3个分组的下落，因此只能把后面的3个分组都重传一次，这种机制**叫Go-back-N（回退N）**，表示需要再退回来重传已发送过的N个分组。

滑动窗口协议

滑动窗口协议在在发送方和接收方之间各自维持一个滑动窗口，发送发是发送窗口，接收方是接收窗口，而且这个窗口是随着时间变化可以向前滑动的。它允许发送方发送多个分组而不需等待确认。TCP的滑动窗口是以字节为单位的。

如下图所示，发送窗口中有四个概念：：已发送并收到确认的数据（不在发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之内）、允许发送但尚未发送的数据（位于发送窗口之内）、发送窗口之外的缓冲区内暂时不允许发送的数据。

接收窗口中也有四个概念：已发送确认并交付主机的数据（不在接收窗口和接收缓冲区之内）、未按序收到的数据（位于接收窗口之内）、允许的数据（位于接收窗口之内）、不允许接收的数据（位于发送窗口之内）。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 2]

规则：

（1）凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用。

（2）只有当发送方A收到了接收方的确认报文段时，发送方窗口才可以向前滑动几个序号。

（3）当发送方A发送的数据经过一段时间没有收到确认（由超时计时器控制），就要使用回退N步协议，回到最后接收到确认号的地方，重新发送这部分数据。

**3.TCP的流量控制**

利用滑动窗口实现流量控制。

所谓流量控制就是让发送发送速率不要过快，让接收方来得及接收。利用滑动窗口机制就可以实施流量控制。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 3]

原理这就是运用TCP报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。

从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ，只有在ACK=1时确认号字段才有意义。

TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），那么收到这个报文段的一方就重新设置持续计时器。

**4.TCP的拥塞控制**

所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。

流量控制往往指的是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。

因特网建议标准RFC2581定义了进行拥塞控制的四种算法，即慢开始（Slow-start)，拥塞避免（Congestion Avoidance)，快重传（Fast Restrangsmit)和快回复（Fast Recovery）。

慢开始和拥塞避免

发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞。

发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。

**慢开始算法**：当主机开始发送数据时，如果立即所大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 4]

每经过一个传输轮次，拥塞窗口 cwnd 就加倍。

慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。

为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量（如何设置ssthresh）。慢开始门限ssthresh的用法如下：  
1.当 cwnd < ssthresh 时，使用上述的慢开始算法。  
2.当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。  
3.当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 5]

**快重传和快恢复**

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。(如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时)

采用快重传后可以使整个网络吞吐量提高约20%。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 6]

与快重传配合使用的还有快恢复算法，其过程有以下两个要点：

1.当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。请注意：接下去不执行慢开始算法。

2.由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 7]

区别：新的 TCP Reno 版本在快重传之后采用快恢复算法而不是采用慢开始算法。

参考文章：  
[https://shiningdan.github.io/2017/03/15/TCP-的流量控制与拥塞控制/][https_shiningdan.github.io_2017_03_15_TCP-]  
[https://blog.csdn.net/fangkailong/article/details/39098257][https_blog.csdn.net_fangkailong_article_details_39098257]  
[http://blog.chinaunix.net/uid-26275986-id-4109679.html][http_blog.chinaunix.net_uid-26275986-id-4109679.html]  
[https://blog.csdn.net/wbw1985/article/details/4879224][https_blog.csdn.net_wbw1985_article_details_4879224]  
[https://blog.csdn.net/guoweimelon/article/details/50879588][https_blog.csdn.net_guoweimelon_article_details_50879588]  
[https://blog.csdn.net/yechaodechuntian/article/details/25429143][https_blog.csdn.net_yechaodechuntian_article_details_25429143]  
[https://blog.csdn.net/chenchaofuck1/article/details/51995590][https_blog.csdn.net_chenchaofuck1_article_details_51995590]  
[https://blog.csdn.net/quitozang/article/details/80861376][https_blog.csdn.net_quitozang_article_details_80861376]

计算机网络面试总结：[https://blog.csdn.net/chenchaofuck1/article/details/51980794][https_blog.csdn.net_chenchaofuck1_article_details_51980794]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70]: /images/20220221/b37dd95333464d6e8412b8874e20e01d.png
[20190411092102598.png]: /images/20220221/2e758940e9f249338667e35741f27b2c.png
[2019041109214196.png]: /images/20220221/574b9601ff984e37a7c848f8add2634e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 1]: /images/20220221/f31b997812364886a4b9c128ec25609c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 2]: /images/20220221/d1e642bf78224eccb76dc5f6df67956b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 3]: /images/20220221/ee014e81c72b4654a6bdbb96bcad61fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 4]: /images/20220221/a4a424464f4a432bbffc4f54fb4574cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 5]: /images/20220221/ef88f9956601430e960ee774c4a07535.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 6]: /images/20220221/5ea42d1758f24963947da0ebb3890d36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 7]: /images/20220221/38a5bfa976674ae3ad35fc21d57f18fe.png
[https_shiningdan.github.io_2017_03_15_TCP-]: https://shiningdan.github.io/2017/03/15/TCP-%E7%9A%84%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6%E4%B8%8E%E6%8B%A5%E5%A1%9E%E6%8E%A7%E5%88%B6/
[https_blog.csdn.net_fangkailong_article_details_39098257]: https://blog.csdn.net/fangkailong/article/details/39098257
[http_blog.chinaunix.net_uid-26275986-id-4109679.html]: http://blog.chinaunix.net/uid-26275986-id-4109679.html
[https_blog.csdn.net_wbw1985_article_details_4879224]: https://blog.csdn.net/wbw1985/article/details/4879224
[https_blog.csdn.net_guoweimelon_article_details_50879588]: https://blog.csdn.net/guoweimelon/article/details/50879588
[https_blog.csdn.net_yechaodechuntian_article_details_25429143]: https://blog.csdn.net/yechaodechuntian/article/details/25429143
[https_blog.csdn.net_chenchaofuck1_article_details_51995590]: https://blog.csdn.net/chenchaofuck1/article/details/51995590
[https_blog.csdn.net_quitozang_article_details_80861376]: https://blog.csdn.net/quitozang/article/details/80861376
[https_blog.csdn.net_chenchaofuck1_article_details_51980794]: https://blog.csdn.net/chenchaofuck1/article/details/51980794