拥塞控制

一、TCP的可靠传输如何保证？ 　　在TCP连接中，数据流必须以正确的顺序传送给对方。 TCP的可靠性是通过 顺序编号 和 确认（ACK） 实现的。 TCP在开始传送一个段时，为准备重传而首先将该段插入到发送队列中，同时启动时钟。然后，如果收到了接收端对该段的ACK信息，就将该段从队列中删去。如果在时钟规定的时间内，ACK未返回，那么就从发送队列中再次送出这个段。TCP在协议中就对数据可靠传输做了保障，握手与断开都需要通讯双方确认，数据传输也需要双方确认成功，在协议中还规定了：分包、重组、重传等规则；而UDP主要是面向不可靠连接的，不能保证数据正确到达目的地。 二、TCP还提供了以下方式保证可靠传输： 1.确认和重传： 接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。 　　 TCP是怎么保证错误重传的？ 　　　　1）接收方受到错误的分组，就直接丢弃，而不做任何操作； 　　　　2）发送方在规定的时间（比平均往返时延大一些）没有收到分组的确认分组，就会自动重传； 　　　　3）为了让对方知道哪个分组出现了问题，就为分组也编了序号。 2.数据校验 3.数据合理分片和排序 　　UDP：IP数据报大于1500字节，大于MTU。这个时候发送方IP层就需要分片（fragmentation）把数据报分成若干片，使每一片都小于MTU，而接受方IP层则需要进行数据报的重组

1.Linux TCP迄今为止的拥塞控制机制 我并不了解其它平台的TCP拥塞控制算法实现，但是我了解Linux的，迄今为止，在bbr刚刚被引入之后，Linux的拥塞控制算法分为两类： 保守模式 bbr之前以Reno为基础，包括Reno，NewReno，...原理几乎都不变，这些算法有两个特点： 1).反馈性差 以Reno为例，TCP发送端在拥塞避免阶段收到ACK后，无条件地将cwnd增加1/cwnd，在慢启动阶段收到ACK后cwnd增加1，这是毫无根据的，然而Reno并没有什么更好的做法，只能瞎猜！后来的Westwood，Vegas，BIC等算法，相对Reno/NewReno更加智能了一步，但还是傻瓜！再往后，CUBIC搞了一个高大上的以三次方程凸凹曲线来抉择的增窗机制，看似十分地“博士”，并且十分地“经理”，然而还是无法高效利用互联网的空闲带宽，相反在碰到异常现象，比如丢包，拥塞的时候，反应太过保守，在保守的路线上趋于激烈，即激烈地保守降低拥塞窗口，更加可悲的是，这个窗口下降的过程并不受这些算法所控制。 2).拥塞算法被接管 在TCP拥塞控制机制发现丢包时(即RTO或者N次重复的ACK等)，TCP会完全接管拥塞控制算法，自己控制拥塞窗口。然而问题是，这种所谓的丢包可能并不是真的丢包，这只是TCP认为丢包而已，这是30年前的丢包判断机制了...真的丢包了吗？不一定啊

本文在文章[1]的基础上，从源代码实现角度对WebRTC的GCC算法进行分析。主要内容包括： RTCP RR的数据源、报文构造和接收，接收端基于数据包到达延迟的码率估计，发送端码率的计算以及生效于目标模块。 拥塞控制是实时流媒体应用的重要服务质量保证。通过本文和文章[1][2]，从数学基础、算法步骤到实现细节，对WebRTC的拥塞控制GCC算法有一个全面深入的理解，为进一步学习WebRTC奠定良好基础。 1 GCC算法框架再学习 本节内容基本上是文章[1]第1节的复习，目的是再次复习GCC算法的主要框架，梳理其算法流程中的数据流和控制流，以此作为后续章节的行文提纲。GCC算法的数据流和控制流如图1所示。 图1 GCC算法数据流和控制流 对发送端来讲，GCC算法主要负责两件事：1)接收来自接收端的数据包信息反馈，包括来自RTCP RR报文的丢包率和来自RTCP REMB报文的接收端估计码率，综合本地的码率配置信息，计算得到目标码率A。2)把目标码率A生效于目标模块，包括PacedSender模块，RTPSender模块和ViEEncoder模块等。 对于接收端来讲，GCC算法主要负责两件事：1）统计RTP数据包的接收信息，包括丢包数、接收RTP数据包的最高序列号等，构造RTCP RR报文，发送回发送端。2）针对每一个到达的RTP数据包，执行基于到达时间延迟的码率估计算法

来自 http://blog.csdn.net/sicofield/article/details/9708383 1.引言 计算机网络中的带宽、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏。这种情况就叫做拥塞。 拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。 拥塞控制是一个全局性的过程，和流量控制不同，流量控制指点对点通信量的控制。 2.慢开始与拥塞避免 发送方维持一个叫做 拥塞窗口 cwnd （ congestion window ） 的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。 慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。 这里用报文段的个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。如下图： 为了防止 cwnd 增长过大引起网络拥塞，还需设置一个慢开始门限 ssthresh 状态变量。 ssthresh 的用法如下： 当 cwnd<ssthresh 时，使用慢开始算法。 当 cwnd>ssthresh 时，改用拥塞避免算法。 当 cwnd

1、TCP拥塞如何控制？ （1）滑动窗口：TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据 滑动窗口指出接收缓冲区中的可用空间，从而确保发送方发送的数据不会溢出缓冲区。 窗口时刻动态变化：当接收发送发数据时，窗口大小减小；当接收方从缓冲区中读取数据时，窗口大小增大。 TCP的接收缓冲区满，它必须等待应用程序从这个缓冲区读取数据后才能再接收发送方传来的数据。 UDP不提供流控制，按发送方的速率发送数据，不管接收方的缓冲区是否装得下。 ## 参考文献：《UNIX网络编程》 （2）TCP拥塞的原因：在早期的时候，通信的双方不知道网络的状况，所以过程中可能会出现中间节点阻塞丢包，所以就有了滑动窗口机制来解决这个问题。 （3）滑动窗口协议：用于网络数据传输时的流量控制，以避免拥塞的发生。如果过多的发送方同时以很快的速度发送大量的数据包，接收方有可能并没有那么高的接收数据能力，因此极易导致网络的拥塞（并发服务器）。 （4）滑动窗口的值：网络中没有出现拥塞，滑动窗口的值可以增大一些（以便把更多的数据包发送出去）；网络出现拥塞，滑动窗口的值应该减小一些（以减少注入到网络中的数据包数） （5）拥塞控制算法： 基于丢包的拥塞控制：将丢包视为出现拥塞，采取缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减小，如Reno、Cubic等。

一、综述 1、确认和重传：接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。 2、数据校验 3、数据合理分片和排序： 　　UDP：IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报. 　　tcp会按MTU合理分片，接收方会缓存未按序到达的数据，重新排序后再交给应用层。 4、流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。 5、拥塞控制：当网络拥塞时，减少数据的发送。 二、滑动窗口 　　上面笼统地说了tcp保证可靠传输的机制，下面说说如何用滑动窗口来实现。 为什么要使用滑动窗口 因为发送端希望在收到确认前，继续发送其它报文段。比如说在收到0号报文的确认前还发出了1-3号的报文，这样提高了信道的利用率。但可以想想，0-4发出去后可能要重传，所以需要一个缓冲区维护这些报文，所以就有了窗口。 　　RTT：往返时间。 窗口是什么 接收窗口： 　　 　　“接收窗口”大小取决于应用（比如说tomcat：8080端口的监听进程）、系统、硬件的限制。图中，接收窗口是31~50，大小为20。 　

TCP头部信息：每 个TCP报文段，用于指定通信的源端端口号，目的端端口号，管理TCP连接，控制两个方向的数据流 TCP状态转移图 TCP数据流 TCP数据流的控制 特点： 面向连接，可靠传输，数据流。 TCP协议的使用要求： 双方必须先建立连接，再开始数据的读写。 双方必须为该连接分配必要的内核资源，以管理连接的状态和连接上数据的传输。-》全双工，双方的数据读写可以通过一个连接进行，完成数据交换后，通信双方都必须断开连接以释放资源。连接为一对一，所以基于广播和多播的应用程序不能使用TCP服务。 数据流： 发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系。应用程序对数据的发送和接收没有边界限制。数据报：发送端应用程序每执行一次写操作，UDP模块就将其封装成一个UDP数据报发送，接收端必须及时针对每一个UDP数据报执行读操作，否则就会丢包，并且，没有指定足够的应用程序缓冲区来读取UDP数据，UDP数据将会被截断。 **可靠：**TCP采用发送应答机制，发送端发送的每个TCP报文段都必须得到接收方的应答，才认为这个TCP报文段传输成功。 TCP采用超时重传机制，发送端在发送出一个TCP报文段之后启动定时器，如果在定时事件内未收到应答，将重发报文段。 TCP的头部结构： 16位端口号：告知主机该报文段来自哪里以及传到哪个上层协议或者应用程序。（TCP通信时

TCP/IP协议模型 各层常见协议 1.链路层： ARP：地址解析协议，根据IP地址获取真实物理地址MAC地址的一种协议。当主机需要发送一个IP包时，会查本地高速缓存，若不存在，主机便会发送一个ARP包，从含有该IP映射的主机中获取相关的ARP包。解包后会更新本地ARP缓存。 RARP：与ARP协议相反。 2.网络层： IP协议：TCP/IP协议的核心，所有的传输层协议以及IP辅助协议都以IP数据格式传送。IP协议是不可靠的，TCP可靠的原因是加入了多种机制，保证可靠传输。换而言之，IP协议只负责IP数据传送，不保证安全性。 ICMP协议：IP辅助协议，全称网络控制报文协议。正如前文所述，IP协议是不可靠的传输。ICMP协议就是用来封装IP数据包传输错误时的信息（如主机不可达等），并将其传送回主机。 3.传输层： TCP协议：面向连接（客户端与服务端建立起端到端的全双工通信）的传输层协议，采用字节流方式，传输可靠，但速度慢。 UDP协议：无连接（广播式）的传输层协议，采用报文方式，传输不可靠可能丢包，但速度快。 4.应用层协议： Http协议：超文本传输协议，端口号80。默认采用TCP协议实现。所以Http的请求过程首先要建立TCP连接（三次握手），然后客户端发出Http请求，服务端处理请求并响应。 Https协议：Http协议基础上进行了加密，端口443。由于用来加密的原因

20170907_我是如何讲清楚TCP协议是如何保证可靠传输的 题外话： 1、UDP： （1） UDP ，user datagram protocol， 用户数据报协议 ，不提供复杂的控制机制， 利用IP提供面向无连接的通信服务，并且它是将应用程序发送过来的数据包在收到的那一刻，立即按照原样发送到上的一种机制。 （2）即使在网络拥堵的情况下，UDP也无法进行流量控制等避免网络拥塞的行为。此外，在传输过程中如果出现丢包，UDP也不负责重发，甚至当数据包的到达顺序乱掉之后也没有纠正顺序的功能。因此， 如果需要这些细节控制的话，就需要在采用UDP协议的应用层去作出处理。 （3）由于UDP面向无连接，所以它可以随时向对端发送数据包，再加上UDP本身的处理既简单右高效， 所以UDP经常用于如下几个方面： 数据包总量比较少的通信，比如DNS、SNMP。 视频、音频等对实时性要求比较高的多媒体通信。 广播通信、多播通信。 2、TCP： （1） TCP，控制传输协议 ，和UDP的差别很大， 它充分实现了数据传输时的各种控制功能 ： 针对发送端发出的数据包的确认应答信号ACK、、、针对数据包丢失或者出现定时器超时的重发机制、、、针对数据包到达接收端主机顺序乱掉的顺序控制、针对高效传输数据包的流动窗口控制、、、针对避免网络拥堵时候的流量控制、、

本文试图给出一些与BBR算法相关但却是其之外的东西。 1.TCP拥塞的本质 注意，我并没有把题目定义成网络拥塞的本质，不然又要扯泊松到达和排队论了。事实上，TCP拥塞的本质要好理解的多！TCP拥塞绝大部分是由于其”加性增，乘性减“的特性造成的！ 也就是说，是TCP自己造成了拥塞！TCP加性增乘性减的特性引发了丢包，而丢包的拥塞误判带来了巨大的代价，这在深队列+AQM情形下尤其明显。 我尽可能快的解释。争取用一个简单的数学推导过程和一张图搞定。 除非TCP端节点之间的网络带宽是均匀点对点的，否则就必然要存在第二类缓存。TCP并无法直接识别这种第二类缓存。正是这第二类缓存的存在导致了拥塞的代价特别严重。我依然用经典的图作为基准来解释： 第二类缓存的时间墙特征导致了排队的发生，而排队会导致一个TCP连接中数据包的RTT变大。为了讨论方便，我们假设TCP端节点之间管道最细处(即Bottleneke处)的带宽为B，那么正如上图所表明的，我把TCP端节点之间的网络中，凡是带宽比B大的网络均包含在第二类缓存中，也就是说，凡是会引起排队的路径，均是第二类缓存。 假设TCP端节点之间的BDP为C，那么： C = C1 + C2 (其中C1是网络本身的管道容量，而C2是节点缓存的容量) 由于路径中最小带宽为B，那么整个链路的带宽将由B决定，在排队未发生时(即没有发生拥塞时)，假设测量RTT为rtt0