计算机网络基础知识之运输层

目录

一、概述和运输层服务

1.运输层和网络层的关系

二、多路复用与多路分解

1）多路分解

2）多路复用

3）多路分解原理

4）无连接(UDP)多路解复用

5）面向连接(TCP)的多路解复用

三、无连接运输UDP

1.UDP特点

2.用户数据报协议 

3.UDP校验和

1）校验和的例子 

四、可靠数据传输（rdt）原理

1.rdt1.0版本

2.rdt2.0~2.2版本

1）2.0版本

2）2.1版本 

3）2.2版本 

3.rdt3.0版本

4.rdt3.0性能

5.流水线协议

1）流水线概述

2）回退N步协议（Go-Back-N）

3）选择重传（SR）

6.回退N步与选择重传补充说明

1）相同

2）不同

3）对比：

4）适用范围

五、面向连接运输TCP

1.TCP特点

2.TCP报文结构

3.可靠数据传输

4.快速重传

5.流量控制

6.连接管理

1）两次握手可行？

2）三次握手

3）四次挥手

六、拥塞控制

1.拥塞控制方法

1）方法1

2）方法2

七、TCP拥塞控制

1.拥塞遇到的问题

2.TCP拥塞感知

3. 速率控制方法

4. 拥塞缓解后的加速处理

1）慢起动

2）慢启动总结

3）AIMD

 5.拥塞控制总结

---

一、概述和运输层服务

        运输层协议为运行在不同主机上的应用进程之间提供逻辑通信（logic communication），运输层协议是在端系统中而不是在路由器中实现的。

        在发送端，运输层将从发送应用程序进程接收到的报文转换成运输层分组，就是 所谓的运输层报文段。实现的方法（可能）将应用报文划分为较小的块、并为每块运输层首部以生成运输层报文段，然后，在发送端系统中，运输层将这些报文段传递给网络层，网路层将其封装成网络层分组（即数据报）并向目的地发送。注意到下列的要的：网络路由器仅作用于该数据报的网络层字段；即它们不检査封装在该数握层报文段的字段。在接收端，网络层从数据报中提取运输层报文段，并将该报文端上交给运输层。运输层则处理接收到的报文段，使该报文段中的数据为接收应用进程
使用。

1.运输层和网络层的关系

        运输层协议（TCP和UDP）只工作在端系统中。在端系统中，运输层协议将来自应用进程的报文移动到网络边缘（网络层），反过来一样。运输层能够提供的服务常常受制于底层网络层协议的服务模型。如果网络层协议无法为主机之间发送的运输层报文段提供时延或带宽保证的话，运输层协议也就无法为进程之间发送的应用程序报文提供时延或带宽的保证。
        即使网络层不不可靠，运输层能够为应用程序提供可靠的数据传输服务。

二、多路复用与多路分解

        多路复用多路分解是将将由网络层提供的主机到主机交付服务延伸到为主机上的应用程序进程到进程的交付服务。

        一个进程有一个或多个套接字（socket），它相当于从网络向进程传递数据和从进程向网络传递数据的门户。

         如上图所示，在接收主机中的运输层实际上并没有直接将数据交付给进程，而是将数据交给一个中间的套接字。每个套接字有属于自己的标识符，标识符的格式取决于UDP还是TCP套接字。

1）多路分解

        根据报文段的头部信息中的IP地址和端口号将接收到的报文段发给正确的套接字：多路分解（demeltiplexing）。每个运输层报文段有几个字段，在接收端，运输层负责检查这些字段，标识出对应的套接字，将其上交到对应的套接字中。0

2）多路复用

        从多个套接字接收来自多个进程的报文，根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装称为： 多路复用

3）多路分解原理

TCP与UDP异同中的共同

1. 解复用作用：TCP或者UDP实体采用哪些信息，将报文段的数据部分 交给正确的socket，从而交给正确的进程
2. 主机收到IP数据报
   1. 每个数据报有源IP地址和目标地址
   2. 每个数据报承载一个传输层报文段
   3. 每个报文段有一个源端口号和目标端口号(特定应用有著名的端口号)
3. 主机联合使用IP地址和端口号将报文段发送给合适的套接字

4）无连接(UDP)多路解复用

1. 在接收端，UDP套接字用二元组标识 (目标IP地址、目标端口号)
2. 当主机收到UDP报文段：
   1. 检查报文段的目标端口号
   2. 用该端口号将报文段定位给套接字
3. 如果两个不同源IP地址/源端口号的数据报，但是有相同的目标IP地址和端口号，则被定位到相同的套接字

5）面向连接(TCP)的多路解复用

1. TCP套接字:四元组本地标识：
   1. 源IP地址
   2. 源端口号
   3. 目的IP地址
   4. 目的端口号
2. 解复用：接收主机用这四个值来将数据报定位到合适的套接字
3. 服务器能够在一个TCP端口上同时支持多个TCP套接字：
   1. 每个套接字由其四元组标识（有不同的源IP和源PORT）
4. Web服务器对每个连接客户端有不同的套接字
   1. 非持久对每个请求有不同的套接

三、无连接运输UDP

1.UDP特点

• “尽力而为”的服务，报文段可能
  • 丢失
  • 送到应用进程的报文段乱序
  • 网络层IP协议也是“尽力而为”协议，不可靠
• 无连接：
  • UDP发送端和接收端之间没有握手
  • 每个UDP报文段都被独立地处理
• UDP 被用于:
  • 流媒体（丢失不敏感，速率敏感、应用可控制传输速率）
  • DNS直接进行查询
  • SNMP
• 在UDP上可行可靠传输:
  • 在应用层增加可靠性
  • 应用特定的差错恢复

2.用户数据报协议 

为什么要有UDP?

• 不建立连接 （会增加延时）
• 简单：在发送端和接收端没 有连接状态
• 报文段的头部很小(开销小)
• 无拥塞控制和流量控制：
• UDP可以尽可能快的发送报文段
  • 应用->传输的速率= 主机->网络的速率

3.UDP校验和

 目标： 检测在被传输报文段中的差错 (如比特反转)

发送方：

• 将报文段的内容视为16比特的整数
• 校验和：报文段的加法和（1的补运算）
• 发送方将校验和放在UDP的校验和字段

接收方：

• 计算接收到的报文段的校验和检查计算出的校验和与校验
• 和字段的内容是否相等：
  • 不相等–--检测到差错
  • 相等–--没有检测到差错，但也许还是有差错
    • 残存错误

1）校验和的例子 

        使用报文段内的所有字段进行计算

四、可靠数据传输（rdt）原理

1.rdt1.0版本

        此版本为理想转态下的有限状态机（FSM）上进行。 

        该版本在可靠信道上的可靠数据传输，具有一下特点：

• 下层的信道是完全可靠的
  • 没有比特出错
  • 没有分组丢失
• 发送方和接收方的FSM
  • 发送方将数据发送到下层信道
  • 接收方从下层信道接收数据

2.rdt2.0~2.2版本

1）2.0版本

        基于1.0版本的理想状态下，推出对现实情况下问题的解决而诞生2.0版本 

• 下层信道可能会出错：将分组中的比特翻转
  • 用校验和来检测比特差错
• 问题：怎样从差错中恢复：
  • 确认(ACK)：接收方显式地告诉发送方分组已被正确接收
  • 否定确认( NAK): 接收方显式地告诉发送方分组发生了差错
    • 发送方收到NAK后，发送方重传分组
• rdt2.0中的新机制：采用差错控制编码进行差错检测
  • 发送方差错控制编码、缓存
  • 接收方使用编码检错
  • 接收方的反馈：控制报文（ACK，NAK）：接收方发送方
  • 发送方收到反馈相应的动作

2）2.1版本 

停等协议：发送方发送一个分组，然后等待接收方的应答

        2.0版本的缺陷问题与2.1的改进：

如果ACK/NAK出错？

        发送方不知道接收方发生了什么事情！ 发送方如何做？重传？可能重复。不重传？可能死锁(或出错) ，需要引入新的机制->序号

处理重复：

        发送方在每个分组中加入 序号， 如果ACK/NAK出错，发送方 重传 当前分组，接收方丢弃（不发给上层）重复分组

         2.1特点：

发送方：

• 在分组中加入序列号
• 两个序列号（0，1）就足够了
  • 一次只发送一个未经确认的分组
• 必须检测ACK/NAK是否出错（需要EDC ）
• 状态数变成了两倍
  • 必须记住当前分组的序列号为0还是1

接收方：

• 必须检测接收到的分组是否是重复的
• 状态会指示希望接收到的分组的序号为0还是1
          
  注意：接收方并不知道发送方是否正确收到了其ACK/NAK没有安排确认的确认

 

         对于接受方来说，它不知道发送方有没有收到确认，只能通过发送方的下一个报文来确定状况，接受方需要1，而发送方发来0，就说明出错，接收方需要丢弃冗余分组，然后再次发送确认报文。反之则正常接收和发送

3）2.2版本 

        2.2版本和2.1版本之间存在细微的变化

• 功能同rdt2.1，但只使用ACK(ack 要编号）
• 接收方对最后正确接收的分组发ACK，以替代NAK
  • 接收方必须显式地包含被正确接收分组的序号
• 当收到重复的ACK（如：再次收到ack0）时，发送方与收到NAK采取相同的动作：重传当前分组
• 为后面的一次发送多个数据单位做一个准备
  • 一次能够发送多个
  • 每一个的应答都有：ACK，NACK；麻烦
  • 使用对前一个数据单位的ACK，代替本数据单位的nak
  • 确认信息减少一半，协议处理简单

3.rdt3.0版本

        3.0在2.2基础上加载了一个定时重发机制

        发送方等待ACK一段 合理的时间： 链路层的timeout时间确定的，传输层timeout时间是适应式的

• 发送端超时重传：如果到时没有收到ACK->重传

问题：如果分组（或ACK ）只是被延迟了：

• 重传将会导致数据重复，但利用序列号已经可以处理这个问题
• 接收方必须指明被正确接收的序列号

需要一个倒计数定时器

 对于c和d情况，

• 过早超时（延迟的ACK）也能够正常工作；但是效率较低，一半的分组和确认是重复的；
• 设置一个合理的超时时间也是比较重要的；

4.rdt3.0性能

        rdt3.0可以工作，但链路容量比较大的情况下，性能很差，链路容量比较大，一次发一个PDU 的不能够充分利用链路的传输能力

        例：1 Gbps的链路，15 ms端-端传播延时，分组大小为1kB：

• U sender：利用率 – 忙于发送的时间比例
• 每30ms发送1KB的分组 270kbps=33.75kB/s 的吞吐量（在1Gbps 链路上）
• 瓶颈在于：网络协议限制了物理资源的利用！

5.流水线协议

1）流水线概述

• 流水线：允许发送方在未得到对方确认的情况下一次发送多个分组
  • 必须增加序号的范围:用多个bit表示分组的序号
• 在发送方/接收方要有缓冲区
  • 发送方缓冲：未得到确认，可能需要重传；
  • 接收方缓存：上层用户取用数据的速率≠接收到的数据速率；接收到的数据可能乱序，排序（可靠）
• 两种通用的流水线协议：回退N步(GBN)和选择重传(SR)

2）回退N步协议（Go-Back-N）

        回退N步协议也被称为滑动窗口协议（sliding-window protocol）

第一部分：发送缓存区

• 发送缓冲区
  • 形式：内存中的一个区域，落入缓冲区的分组可以发送
  • 功能：用于存放已发送，但是没有得到确认的分组
  • 必要性：需要重发时可用
• 发送缓冲区的大小：一次最多可以发送多少个未经确认的分组
  • 停止等待协议=1
  • 流水线协议>1，合理的值，不能很大，链路利用率不能够超100%
• 发送缓冲区中的分组
  • 未发送的：落入发送缓冲区的分组，可以连续发送出去；
  • 已经发送出去的、等待对方确认的分组：发送缓冲区的分组只有得到确认才能删除

第二部分： 发送窗口

• 发送窗口：发送缓冲区内容的一个范围
  • 那些已发送但是未经确认分组的序号构成的空间
• 发送窗口的最大值<=发送缓冲区的值
•  一开始：没有发送任何一个分组
  • 后沿=前沿
  • 之间为发送窗口的尺寸=0
• 每发送一个分组，前沿前移一个单位
  • 
    
  • 
    
  • 发送窗口前沿移动的极限：不能够超过发送缓冲区

• 发送窗口后沿移动
  • 条件：收到老分组的确认
  • 结果：发送缓冲区罩住新的分组，来了分组可以发送
  • 移动的极限：不能够超过前沿
  • 
    

第三部分：接收窗口

• 接收窗口 (receiving window)=接收缓冲区
  • 接收窗口用于控制哪些分组可以接收；
    • 只有收到的分组序号落入接收窗口内才允许接收
    • 若序号在接收窗口之外，则丢弃；
  • 接收窗口尺寸Wr=1，则只能顺序接收（回退N步协议）；
  • 接收窗口尺寸Wr>1 ，则可以乱序接收（选择重传协议）；
    • 但提交给上层的分组，要按序
  • 例子：Wr＝1，在0的位置；只有0号分组可以接收；
  • 向前滑动一个，罩在1的位置，如果来了第2号分组，则丢弃；
  • 
    
• 接收窗口的滑动和发送确认
  • 滑动：
    • 低序号的分组到来，接收窗口移动；
    • 高序号分组乱序到，缓存但不交付（因为要实现rdt，不允许失序），不滑动
  • 发送确认：
    • 接收窗口尺寸=1 ； 发送连续收到的最大的分组确认（累计确认）
    • 接收窗口尺寸>1 ； 收到分组，发送那个分组的确认（非累计确认）
    • 
      

第四部分：正常的发送—接收窗口互动

第五部分：异常的发送—接收窗口互动

 第六部分：运行中的GBN

        在接收端，乱序的不缓存，因此哪个n分组丢失了GB到那个分组n，即使n以后的分组传送都是正确的

3）选择重传（SR）

第一部分：选择重传特点

• 接收方对每个正确接收的分组，分别发送ACKn（非累积确认）
  • 接收窗口>1
    • 可以缓存乱序的分组
  • 最终将分组按顺序交付给上层
• 发送方只对那些没有收到ACK的分组进行重发-选择性重发
  • 发送方为每个未确认的分组设定一个定时器
• 发送窗口的最大值（发送缓冲区）限制发送
  • 未确认分组的个数 

第二部分：选择重传运行

第三部分：异常情况SR协议发送—接收窗口的互动

6.回退N步与选择重传补充说明

1）相同

发送窗口>1

一次能够可发送多个未经确认的分组

2）不同

• GBN :接收窗口尺寸=1
  • 接收端：只能顺序接收，提前到达的数据报会被丢弃
  • 发送端：从表现来看，一旦一个分组没有发成功，如：0,1,2,3,4  假如1未成功，234都发送出去了，要返回1再发送；GB1，然后重新发送234
• SR: 接收窗口尺寸>1
  • 接收端：可以乱序接收
  • 发送端：发送0,1,2,3,4，一旦1未成功，2,3,4,已发送，无需重发，选择性发送1

3）对比：

	GBN	SR
优点	简单，所需资源少（接收方一个缓存单元）	出错时，重传代价小
缺点	一旦出错，回退N步代价大	复杂，所需要资源多（接收方多个缓存节点）

4）适用范围

• 出错率低：比较适合GBN，出错非常罕见，没有必要用复杂的SR，为罕见的事件做日常的准备和复杂处理
• 链路容量大（延迟大、带宽大）：比较适合SR而不是GBN，一点出错代价太大

五、面向连接运输TCP

1.TCP特点

• 点对点：
  • 一个发送方，一个接收方
• 可靠的、按顺序的字节流：
  • 没有报文边界
• 管道化（流水线）：
  • TCP拥塞控制和流量控制设置窗口大小
• 发送和接收缓存
  • 
    
• 全双工数据：
  • 在同一连接中数据流双向流动
  • MSS：最大报文段大小
• 面向连接：
  • 在数据交换之前，通过握手（交换控制报文） 初始化发送方、接收方的状态变量
• 有流量控制：
  • 发送方不会淹没接收方

2.TCP报文结构

 

 

 

3.可靠数据传输

• TCP在IP不可靠服务的基础上建立了rdt
  • 管道化的报文段
  • 累积确认（像GBN）
  • 单个重传定时器（像GBN）
  • 是否可以接受乱序的—>没有规范
  • TCP接收报文像GBN，但是却会把失序提前到达的报文缓存起来
• 通过以下事件触发重传
  • 超时（只重发那个最早的未确认段：SR）
  • 重复的确认（快速重传）
    • 例子：收到了ACK50,之后又收到3个ACK50

4.快速重传

        触发超时重传存在的问题之一是超时周期可能相对比较长。当一个报文段丢失时，这种超长的周期迫使发送方延迟重传丢失的分组，从而增加了端到端时延。所以利用了冗余ACK来检测丢包问题。

        当TCP接收方收到一个具有这样的序号的报文段时，即序号大于下一个所期望的、按序的报文段，它检测到了数据流中有一个间隔，这就是说报文段丢失。这个间隔可能是由于网络中报文段丢失或重新排序造成的。出现这种情况后，接收机对已经接收到的最后一个按序字节数据进行重复确认（即产生一个冗余ACK）。

        快速重传就是利用了这个冗余ACK来进行提前预判超时或者丢失的。发送方经常一个接一个地发送大量的报文段，如果一个报文段丢失，就很可能引起一个接一个的冗余ACK。如果TCP发送方接收到对相同数据的3个冗余ACK，它把这种当成一个指示说明在这个已被确认过3个的报文段之后的报文段已经丢失。一旦收到3个冗余ACK，立即出发快速重传

5.流量控制

        接收方控制发送方，不让发送方发送的太多、太快以至于让接收方的缓冲区溢出

• 接收方在其向发送方的TCP段头部的rwnd字段“通告”其空闲buffer大小
  • RcvBuffer大小通过socket选项设置 (典型默认大小为4096 字节)
  • 很多操作系统自动调整RcvBuffer

• 发送方限制未确认(“in-flight”)字节的个数≤接收方发送过来的 rwnd 值
• 保证接收方不会被淹没

6.连接管理

• 在正式交换数据之前，发送方和接收方握手建立通信关系:
  • 同意建立连接（每一方都知道对方愿意建立连接）
  • 同意连接参数

1）两次握手可行？

在网络中，2次握手建立连接总是可行吗？  

• 变化的延迟（连接请求的
  段没有丢，但可能超时）
• 由于丢失造成的重传
• 报文乱序
• 相互看不到对方

两次握手失败场景

         当连接被服务器端接收，发出的同意连接延时，客户端在次发出连接请求，事实上，二者已经建立了连接。之后这种连接请求再次被接收，重新建立了连接，而上一个连接的报文已经在路上了，就变成老报文变成了新报文

2）三次握手

        第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

        第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

        第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

        由于3次握手连接不是像2次握手只有服务器维护连接那样，所以解决了半连接问题。 由于处在连接中，就算像2次握手发来新的连接请求（由于超时发送的请求）时，服务器也会发现这个连接序号不在当前连接范围中，直接抛弃掉，老数据也就不会被认为是新数据了

3）四次挥手

        第一次挥手：客户端向服务器发送FIN的关闭链接请求，序列号是sep = x，此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

        第二次挥手：服务器收到关闭请求，发出确认报文ACK =  x+1，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

        第三次挥手，由于中间可能服务器还在发送报文，所以得等服务器发送完后，再发送链接释放报文FIN = 1，序号为sep = y，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

        第四次挥手：客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=y+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

六、拥塞控制

• 非正式的定义: “太多的数据需要网络传输，超过了网络的处理能力”
• 与流量控制不同
• 拥塞的表现:
  • 分组丢失 (路由器缓冲区溢出)
  • 分组经历比较长的延迟(在路由器的队列中排队)

1.拥塞控制方法

1）方法1

端到端拥塞控制:

• 没有来自网络的显式反馈
• 端系统根据延迟和 丢失事件推断是否有拥塞
• TCP采用的方法

2）方法2

网络辅助的拥塞控制:

• 路由器提供给端系统以反馈信息
• 单个bit置位，显示有拥塞 (SNA, DECbit,TCP/IP ECN, ATM)
• 显式提供发送端可以采用的速率

七、TCP拥塞控制

端到端的拥塞控制机制

• 路由器不向主机有关拥塞的反馈信息
  • 路由器的负担较轻
    • 符合网络核心简单的
    • TCP/IP架构原则
• 端系统根据自身得到的信息，判断是否发生拥塞，从而采取动作

1.拥塞遇到的问题

拥塞控制的几个问题

1. 如何检测拥塞
   • 轻微拥塞
   • 拥塞
2. 控制策略
   1. 在拥塞发送时如何动作，降低速率
   2. 轻微拥塞，如何降低
   3. 拥塞时，如何降低
3. 在拥塞缓解时如何动作，增加速率

        下面解决这些问题 

2.TCP拥塞感知

发送端如何探测到拥塞?

• 某个段超时了（丢失事件 ）：拥塞
  • 超时时间到，某个段的确认没有来
  • 原因1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
  • 原因2：出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小
  • 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的
• 有关某个段的3次重复ACK：轻微拥塞
  • 段的第1个ack，正常，确认绿段，期待红段
  • 段的第2个重复ack，意味着红段的后一段收到了，蓝段乱序到达
  • 段的第2、3、4个ack重复，意味着红段的后第2、3、4个段收到了，橙段乱序到达，同时红段的可能性很大（后面3个段都到了，红段都没到）
  • 网络这时还能够进行一定程度的传输，拥塞但情况要比第一种好

3. 速率控制方法

 如何控制发送端发送的速率

• 维持一个拥塞窗口的值：CongWin
• 发送端限制已发送但是未确认的数据量（的上限）:
  • LastByteSent-LastByteAcked <=CongWin
• 从而粗略地控制发送方的往网络中注入的速率
• 
  
• CongWin是动态的，是感知到的网络拥塞程度的函数
  • 超时或者3个重复ack，CongWin↓
    • 超时时：CongWin降为1MSS,进入SS阶段然后再倍增到 CongWin/2（每个RTT），从而进入CA阶段
    • 3个重复ack ：CongWin降为CongWin/2,CA阶段
  • 否则（正常收到Ack，没有发送以上情况）：CongWin跃跃欲试↑
    • SS阶段：加倍增加(每个RTT)
    • CA阶段：线性增加(每个RTT)

4. 拥塞缓解后的加速处理

• 慢启动
• AIMD：线性增、乘性减少
• 超时事件后的保守策略

1）慢起动

• 连接刚建立, CongWin = 1 MSS
  • 如: MSS = 1460bytes &RTT = 200 msec
  • 初始速率 = 58.4kbps
• 可用带宽可能>> MSS/RTT
  • 应该尽快加速，到达希望的速率
• 当连接开始时，指数性增加发送速率，直到发生丢失的事件
  • 启动初值很低
  • 但是速度很快

实例：

• 当连接开始时，指数性增加（每个RTT）发送速率直到发生丢失事件
  • 每一个RTT， CongWin加倍
  • 每收到一个ACK时，CongWin加1（why）
  • 慢启动阶段：只要不超时或3个重复ack，一个RTT，CongWin加倍

2）慢启动总结

        初始速率很慢，但是加速却是指数性的指数增加，SS时间很短，长期来看可以忽略

3）AIMD

• 乘性减:
  • 丢失事件后将CongWin降为1，将CongWin/2作为阈值，进入慢启动阶段（倍增直到 CongWin/2）
• 加性增：
  • 当CongWin>阈值时，一个RTT如没有发生丢失事件将CongWin加1MSS: 探测+

  

• 当收到3个重复的ACKs:
  • CongWin 减半
  • 窗口（缓冲区大小）之后线性增长
• 当超时事件发生时:
  • CongWin被设置成 1MSS，进入SS阶段
  • 之后窗口指数增长
  • 增长到一个阈值（上次发生拥塞的窗口的一半）时，再线性增加
• 3个重复的ACK表示网络还有一定的段传输能力
• 超时之前的3个重复的ACK表示“警报”
• 改进：
  • 在超时之前，当 CongWin变成上 次发生超时的窗口的一半，将指数性增长变成线性？
  • 
    

 5.拥塞控制总结

Cngwin：拥塞控制变量
Threshold:阈值

• 当CongWin＜Threshold, 发送端处于慢启动阶段（slow-start）, 窗口指数性增长.
• 当CongWin〉Threshold, 发送端处于拥塞避免阶段（congestion-avoidance）, 窗口线性增长.
• 当收到三个重复的ACKs (triple duplicate ACK),Threshold设置成 CongWin/2， CongWin=Threshold+3.
• 当超时事件发生时timeout, Threshold=CongWin/2 ，CongWin=1 MSS，进入SS阶段

个人笔记使用