计算机网络自顶向下——传输层

第三章 传输层

目录：

• 目标：
  • 理解传输层的工作原理
    • 多路复用/解复用
    • 可靠数据传输
    • 流量控制
    • 拥塞控制
  • 学习Internet的传输层协议
    • UDP：无连接传输
    • TCP：面向连接的可靠传输
    • TCP的拥塞控制
• 提纲：
  • 概述和传输层服务
  • 多路复用与解复用
  • 无连接传输：UDP
  • 可靠数据传输的原理
  • 面向连接的传输：TCP
    • 段结构
    • 可靠数据传输
    • 流量控制
    • 连接管理
  • 拥塞控制原理
  • TCP 拥塞控制

1 概述和传输层服务

• 为运行在不同主机上的应用进程提供逻辑通信
• 传输协议运行在端系统
  • 发送方：将应用层的报文分成报文段，然后传递给网络层
  • 接收方：将报文段重组成报文，然后传递给应用层
• 有多个传输层协议可供应用选择
  • Internet: TCP和UDP

1.1 运输层和网络层的关系

• 网络层服务：主机间的逻辑通信
• 传输层服务：进程间的逻辑通信
  • 依赖于网络层的服务
    • 延时、带宽
  • 并对网络层的服务进行增强
    • 数据丢失、顺序混乱、加密

有些服务是可以加强的：不可靠-> 可靠；安全
但有些服务是不可以被加强的：带宽，延迟

1.2 Internet传输层协议

• 可靠的、保序的传输： TCP
  • 多路复用、解复用
  • 拥塞控制
  • 流量控制
  • 建立连接
• 不可靠、不保序的传输：UDP
  • 多路复用、解复用
  • 没有为尽力而为的IP服务添加更多的其它额外服务
• 都不提供的服务：
  • 延时保证
  • 带宽保证

2 多路复用/解复用

在发送方主机多路复用：从多个套接字接收来自多个进程的报文，根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装(该头部信息用于以后的解复用)

在接收方主机多路解复用：根据报文段的头部信息中的IP地址和端口号将接收到的报文段发给正确的套接字(和对应的应用进程)

2.1 多路解复用工作原理

1. 套接字有位移标识符
2. 每个报文段有特殊字段来指示报文段所要交付到的套接字

特殊字段是源端口号字段和目标端口号字段

3 无连接传输：UDP

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

3.1 UDP报文段(数据报)结构

3.2 UDP校验和

• 目标： 检测在被传输报文段中的差错(如比特反转)
• 发送方：
  • 将报文段的内容视为16比特的整数
  • 校验和：报文段的加法和（溢出回卷），并将结果取反码
  • 发送方将校验和放在UDP的校验和字段
• 接收方：
  • 计算接收到的报文段的校验和（数据+首部）
  • 检查计算出的校验和是否为全1（因为之前取反了所以如果正确一定为全1）

4 可靠数据传输的原理

4.1 Rdt1.0： 在可靠信道上的可靠数据传输

由于信道可靠所以只需要对数据进行封装和解封装

4.2 Rdt2.0：具有比特差错的信道

因为传输的数据可能会有错误故添加了确认和重传机制

确认(ACK)：接收方显式地告诉发送方分组已被正确接收
否定确认( NAK): 接收方显式地告诉发送方分组发生了差错，发送方收到NAK后，发送方重传分组

4.2.1 Rdt2.1：接收方处理出错的ACK/NAK

如果ACK/NAK出错可能会出错，此时发送方就永远接受不到确认信息，进入死锁。

解决方案：给报文段加上序号

只要接受到的不是ACK就重传，由于序号的存在接受方即使重复收到报文也能知道是否已接受这个报文，如果已接受就丢弃。

4.2.1 Rdt2.2：无NAK的协议

功能同rdt2.1

给确认报文ACK也加上序号，用前一个ACK来代替NAK，方便统一管理

4.3 Rdt3.0：具有比特差错和分组丢失的信道

发送过程中可能会发生数据报的丢失

解决方案：超时重传

发送方设计一个计时器，如果计时器变为0还未收到ACK则超时重传

4.4 流水线：提高链路利用率

由于等停协议的性能极低，故采用流水线的方式

流水线：允许发送方在未得到对方确认的情况下一次发送多个分组

两种通用的流水线协议：回退N步(GBN)和选择重传(SR)

4.4.0 滑动窗口

SW发送窗口	RW接收窗口	协议
SW=1	RW=1	S-W
SW>1	RW=1	GBN
SW>1	RW>1	SR

• 发送窗口：发送缓冲区内容的一个范围，那些已发送但是未经确认分组的序号构成的空间
• 接收窗口(receiving window)=接收缓冲区
  • 接收窗口用于控制哪些分组可以接收；
  • 接收窗口尺寸Wr=1，则只能顺序接收；
  • 接收窗口尺寸Wr>1 ，则可以乱序接收

最开始前沿和后沿重合，然后每发送一个报文前沿向前移动一位，最终不能超过发送缓存区。然后接收窗口接收到数据返回ACK发送窗口接收到对应ACK后后沿向前移动，但不能超过前沿。后沿移动后发送缓存区也向前移动。

• 发送窗口
  • 有新的分组落入发送缓冲区范围，发送->前沿滑动
  • 来了老的低序号分组的确认->后沿向前滑动->新的分组可以落入发送缓冲区的范围
• 接收窗口
  • 收到分组，落入到接收窗口范围内，接收
  • 是低序号，发送确认给对方

4.4.1 回退N步(GBN)

说白了其实就是SW=1的滑动窗口，只能接受一个分组，其他分组全部丢弃，发送窗口不断超时重传分组

• 发送端最多在流水线中有N个未确认的分组
• 接收端只是发送累计型确认cumulative ack
  • 接收端如果发现gap，不确认新到来的分组
• 发送端拥有对最老的未确认分组的定时器
  • 只需设置一个定时器
  • 当定时器到时时，重传所有未确认分组

4.4.2 选择重传(SR)

SW>1的滑动窗口，能接受多个分组，也能发送多个ACK，只需重传未接受的分组，但这相应实现也比较复杂，需要接收端也进行缓存。

• 发送端最多在流水线中有N个未确认的分组
• 接收方对每个到来的分组单独确认individual ack（非累计确认）
• 发送方为每个未确认的分组保持一个定时器
  • 当超时定时器到时，只是重发到时的未确认分组

4.4.3 GBN协议和SR协议的异同

• 相同之处
  • 发送窗口>1
  • 一次能够可发送多个未经确认的分组
• 不同之处
  • GBN :接收窗口尺寸=1
    • 接收端：只能顺序接收
    • 发送端：从表现来看，一旦一个分组没有发成功，如：0,1,2,3,4; 假如1未成功，234都发送出去了，要返回1再发送：GB1
  • SR: 接收窗口尺寸>1
    • 接收端：可以乱序接收
    • 发送端：发送0,1,2,3,4，一旦1未成功，2,3,4,已发送，无需重发，选择性发送1

	GBN	SR
优点	简单，所需资源少（接收方一个缓存单元）	出错时，重传一个代价小
缺点	一旦出错，回退N步代价	复杂，所需要资源多（接收方多个缓存单元）
适用范围	出错率低：比较适合GBN，出错非常罕见，没有必要用复杂的SR，为罕见的事件做日常的准备和复杂处理	链路容量大（延迟大、带宽大）：比较适合SR而不是GBN，一点出错代价太大

5 面向连接的传输：TCP

5.1 TCP：概述

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

5.2 TCP报文段结构

5.2.1 TCP 序号, 确认号

序号：报文段首字节的在字节流的编号
确认号:期望从另一方收到的下一个字节的序号；累积确认

接收方如何处理乱序的报文段没有规定

5.3 TCP往返延时（RTT）和超时

TimeoutInterval = EstimatedRTT + 4*DevRTT

EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT

DevRTT = (1-b)*DevRTT +b*|SampleRTT-EstimatedRTT|

• SampleRTT：测量从报文段发出到收到确认的时间
• EstimatedRTT：SampleRTT均值
• DevRTT：RTT偏差

5.4 TCP：可靠数据传输

TCP的滑动窗口是GBN和SR的结合

TCP是累计确认，只重传一个分组——GBN
但接收方能缓存提前到来的分组——SR

1. 缓存的两个分组(分组0和分组1)全到了发送期待发送分组2 ACK2
2. 分组1到了分组0等待500ms后还没到则立刻发送ACK0
3. 分组0到了期待分组1但分组2提前到了，立刻发送ACK1
4. 分组0和分组2到了后分组1也到了补上gap立刻发送ACK3

5.4.1 快速重传

发送方接收到三个冗余ACK后就会快速重传，不管是否超时

5.5 流量控制

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

使用捎带技术：接收方在其向发送方的TCP段头部的rwnd字段“通告”其空闲buffer大小

5.6 TCP连接管理

5.6.1 三次握手

两次握手可能出现的问题：

1. 半连接
2. 老的数据当初新的数据接收了

原因：客户端能够知道连接是否是同一个连接，比如888端口发出的连接只能有一个，但服务器不知道连接是否是同一个比如浏览网页所有连接都是默认80端口

3次握手解决：半连接和接收老数据问题

半连接通过三次握手解决，接收老数据问题通过附上一个随机序号解决

5.6.2 四次挥手

5.6 拥塞控制

拥塞:太多的数据需要网络传输，超过了网络的处理能力

拥塞的表现:
分组丢失(路由器缓冲区溢出)
分组经历比较长的延迟(在路由器的队列中排队)

情况1：两个发送方和一台具有无限大缓存的路由器

在这种极端理想化的情况中，分组到达速率解决链路容量是，分组进来巨大的排队延迟

情况2：两个发送方和一台有限缓存的路由器

发送方必须执行重传以补充因为缓存溢出而丢弃的分组

情况3：4个发送方和多台有限缓存的路由器一级多跳路径

当分组丢失时，任何“关于这个分组的上游传输能力”都被浪费了

拥塞控制方法

• 端到端拥塞控制:由端系统自己感知
  • 没有来自网络的显式反馈
  • 端系统根据延迟和丢失事件推断是否有拥塞
  • TCP采用的方法
• 网络辅助的拥塞控制:由网络反馈信息（准确但代价大）
  • 路由器提供给端系统以反馈信息
    • 单个bit置位，显示有拥塞(SNA, DECbit,TCP/IP ECN, ATM)
    • 显式提供发送端可以采用的速率

5.7 TCP拥塞控制

5.7.1 发送端如何探测到拥塞?

• 超时重传：拥塞
• 快速重传：轻微拥塞

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

• 慢启动：指数增加
• 拥塞避免：线性增加
• 超时事件后的保守策略：快速恢复

策略：

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

如果发生快重传则阈值减半，拥塞窗口变为阈值+3，状态为拥塞避免。

快速恢复
老版本：阈值减半，拥塞窗口变为1，状态为慢启动
新版本：阈值减半，拥塞窗口变为阈值+3，状态为拥塞避免

事件	状态	TCP 发送端行为	解释
以前没有收到ACK的数据被ACKed	慢启动(SS)	CongWin = CongWin * 2 (CongWin > Threshold) 状态变成拥塞避免“CA”	每一个RTT CongWin 拥塞窗口 加倍
以前没有收到ACK的数据被ACKed	拥塞避免(CA)	CongWin = CongWin + 1	加性增加, 每一个RTT对拥塞窗口加1MSS最大报文段长度
通过收到3个重复的ACK，发现丢失的事件	SS or CA	Threshold = CongWin/2 CongWin = Threshold+3,状态变成“CA”	快速重传, 实现乘性的减.CongWin 没有变成1MSS.
超时	SS or CA	Threshold = CongWin/2, CongWin = 1 MSS, 状态变成慢启动	进入慢启动
重复的ACK	SS or CA	对被ACKed 的segment， 增加重复ACK的计数	CongWin and Threshold不变

5.7.3 公平性

由于拥塞控制，那么一定会在y=-x左右反复横跳无线趋近
由于拥塞避免为每次加1，斜率为45度，由于每次都取中点，所以就会无限趋近于y=x
综上：TCP是公平的