[网络协议]计算机网络：传输层

采用《计算机网络 自顶向下方法》

传输层

目标

• 理解传输层的工作原理
• 学习Internet的传输层协议

传输服务和协议

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

传输层VS网络层

• 网络层服务：端到端的
• 传输层服务：进程到进程的

TCP：可靠的保序的传输，字节流

• 多路复用， 解复用
• 拥塞控制
• 流量控制
• 建立连接

UDP：不可靠的，不保序， 数据报

• 多路复用，解复用
• 没有尽力而为的IP服务添加更多的其他的额外服务

1、多路复用与解复用

• 在发送方主机多路复用

从多个陶杰子接收来自多个进程的报文，根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装（该头部信息用于以后的解复用）

• 在接收方主机多路解复用

并根据报文段的头部信息种的IP地址和都拗口号将接收的报文段给正确的套接字（对应的应用进程）

工作原理

解复用作用：TCP或者UDP实体采用哪些信息，将报文段数据部分交给正确的socket，从而交给正确的进程

主机受到IP数据段：

• 每个数据报有源IP地址和目标地址
• 每个数据报承载一个传输层报文段
• 每个报文段有一个源端口号和目标端口号（特定应用有著名的端口号）

主机联合使用IP地址和端口号将报文段发送给合适的套接字

2、无连接的传输 UDP(User Datagram Protocol)

• “no frills”"bare
• 尽力而为的服务，报文段可能丢失，乱序
• 无连接：没有握手，独立处理
• 用于流媒体 DNS SNMP
• UDP上实现可靠的传输
• • 在应用层增加可靠性
  • 应用特定的差错恢复

UDP报文段 头部 32bit

源端口号# 目标端口号#

长度 校验和（EDC）

应用程序数据（报文）

UDP校验和

发送方

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

接收方：

• 计算接收到的报文段的校验和
• 检查计算处的校验和校验和字段的内容是否相等
• • 不想等—————检测到错误
  • 相等-----没有检测到错误，但也有可能发生错误，残存错误

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

rdt在应用层、传输层和数据链路层都很重要

• 信道的不可靠特点决定了可靠数据传输协议（rdt）的复杂性

将

• 渐进式地开发可靠数据传输协议（rdt）的发送方和接收方
• 只考虑单向的数据传输
• 双向数据传输问题实际上是2个单向数据传输问题的综合
• 是哟个有限状态机（FSM）来描述发送方和接收方

rdt1.0 在可靠信道上的可靠数据传输

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

rdt2.0 具有bit差错的信息

下层信道可能会出错：将分组中

问题：怎样从差错中恢复？

• 确认（ack）：接收方显示地高速发送方分组已被正确接收
• 否定确认（nak）：接收方显示地告诉发送方分组发生了差错
• • 发送方受到nak后，发送方重传分组

rdt2.0中的新机制：采用差错控制编码进行差错检测

• 发送方差错控制编码，缓存
• 接收方使用编码检测
• 接收方反馈
• 发送方收到反馈，执行相应动作

rdt2.0致命错误 ------》rdt2.1

停滞等待协议

如果ACK/NAK出错？

• 发送方不知道接收方发生了什么事情
• 发送方如何做？
• 需要引入新的机制 序号

处理重复：

发送方在每个分组中加入序号

如果ACK/NAK出错，发送方重传当前分组

接收方丢弃（不发给上层）重复分组

等待协议

发送方发送一个分组，然后等待接收方的应答。

发送方：

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

接收方：

• 必须检测接收到的分组是否是重复的
• • 状态会知识希望接收到的分组序号是0还是1；
• 主义：接收方并不知道发送方是否正确接受放到了ACK/NAK
• • 没有安排确认的确认

rdt2.2： 无NAK的协议

功能同rdt2.1; 但只使用ACK

用前一个分组的正确确认代替当下的错误确认

为分组做编号

接收方是可以检测到重复的

rdt3.0：具有比特差错和分组丢失

超时重传机制

新的假设：下层信道可能会丢失分组（数据或者ack）

• 会死锁
• 机制还不能够处理这种状态
• • 检验和
  • 序列号
  • ACK
  • 重传

方法：发送方等待ACK一段合理的时间

• 发送方超时重传：如果到时没有收到ACK---->重传
• 问题：如果分组知识被延时了
• • 重传会导致重复，但是序列号已经可以处理这个问题
• 需要一个倒计数定时器

超时定时器设置的不合理

• 超时时间过短，会造成效率变低
• 会让分组重复发送

stop and wait 问题

效率比较低

流水线协议

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

• 必须增加序号的范围：用多个bit标示分组的序号
• 在发送方接收方要有缓冲区
• • 发送者缓冲：为得到确认，可能需要重传
  • 接收方缓存：上层用户取用数据的速率不等于接收到的数据速率；接收到的数据可能时乱序，排序交付（可靠）
• 两种通用的流水线协议：回退N步（GBN）和选择重传（SR）

滑动窗口协议（slide window)协议

发送缓冲区

• 形式：内存中的一个区域，落入缓冲区的分组可以发送
• 功能：用于存放已发送，但是没有得到确认的分组
• 必要性：需要重发时可用

发送缓冲区的大小：一次最多可以发送多少个未经确认的分组

• 停止等待协议= 1；
• 流水线协议>1,合理的值，不能很大，链路利用率不能超过100%

发送缓冲区的分组

• 未发送的：落入发送缓冲区的分组，可以连续发送出去
• 已经发送出去的、等待对方确认的分组：确认缓冲区的分组只有得到确认才能删除

发送窗口：已经发送出去的但是未经确认的序号构成的空间

发送窗口的最大值<=发送缓冲区的值

一开始：没有发送任何一个分组

后沿=前沿

之前为发送窗口的尺寸= 0

每发送一个分组，前沿前移一个单位

发送窗口后沿移动

• 条件：收到老分组的确认
• 结果：发送缓冲区罩住信道分组，来了分组可以发送
• 移动的计现：不能超过前沿

sw > 1 rw = 1 gbn

sw> 1 rw > 1 sr

接收窗口=接收缓冲区

• 接收窗口用于控制哪些分组可以接受
• • 只有收到的分组序号落去接收窗口内才能允许接收
  • 若序号在接收窗口之外， 则丢失
• 接收窗口尺寸Wr= 1;则只能顺序接收
• 接收窗口尺寸Wr>1;则可以乱序接收
• • 但提交给上层的分组，要按序

异常情况下GBN的窗口互动

发送窗口

• 新分组落入发送缓冲区范围，发送–》前沿移动 1
• 超时重发机制让发送端将发送窗口中的所有分组发出去 5
• 来了老分组的重复确认–》后沿不向前移动–》新的分组无法落入发送缓冲区的范围（此时如果发送缓冲区有新的分组可以发送） 4

接收窗口

• 收到乱序分组，没有落入到接收窗口范围内，抛弃 2
• （重复）发送老分组的确认，累计确认 3

异常请款下SR的窗口互动

发送窗口

• 新分组落入发送缓冲区范围,发送–》前沿移动 1
• 超时重发机制让发送端将发送窗口中的所有未确认分组发出去 5
• 来了乱序发分组的确认-》后沿不向前推进-》新的分组无法落入发送缓冲区范围（此时如果发送缓冲区有新的分组可以发送） 4

接收窗口

• 收到乱序分组，落入到接收窗口范围内，接收 2
• 发送该分组的确认，单独确认 3

相同之处

• 流水模式

不同之处

• GBN接收窗口=1
• SR接收窗口>1

对比GBN和SR

GBN优点

• 简单，所需要资源少

缺点

• 一旦出错，回退N步

SR优点

• 出错时，重传代价小

缺点

• 复杂，所需要资源多（接收方多个存储单元）

适用范围

• 出从率低：比较适合GBN，出错非常罕见，没必要用复杂的SR
• 链路容量大（延迟大，带宽大）：比较适合SR而不是GBN，一点出错代价太大

4、面向连接的传输 TCP

• 点到点
• 可靠的、按顺序的字节流
• 管道化
• 发送和接收缓存
• 全双工数据
• 面向连接
• 有流量控制

源端口号 目的端口号

? 序号

? 确认号

序号：报文段首字节的在字节流的编号

确认号：期望从另一方收到下一个字节的序号，积累确认

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

怎样设置TCP超时？

比RTT要长

• 但RTT是变化的

太短：太早超时

• 不必要的重传

太长：对报文段丢失反应太慢，消极

怎样估计RTT？

• SampleRTT：测量从报文段发出到接收到确认的时间
• • 如果有重传，忽略此次测量
• SampleRTT会变化，因此估计的RTT应该比较平滑
• • 对几个最近的测量值求平均，而不是仅用当前的SampleRTT

TCP在IP不可靠服务的基础上建立了rdt

• 管道话的报文段
• 累计确认
• 单个重传定时器
• 是否可以接收乱序，没有规范

通过一下时间触发重传

• 超时（只重发那个最早的未确认段：SR）
• 重复的确认
• • 收到了ACK50之后又收到了3个ACK50

首先考虑简化的TCP发送方：

• 忽略重复的确认呢
• 忽略流量控制和拥塞控制

快速重传

• 超时周期往往太长：
• • 在重传丢失报文段之前的延时太长
• 通过重复的ACK来检测报文段丢失
• • 发哦是那个安费诺更通畅连续发送大量报文段
  • 如果报文段丢失，通常会引起多个重复的ACK
• 如果发送方收到同一数据的3个冗余的ACK，重传最小序号的段
• • 块苏重传：在定时器过时之前重发报文段
  • 假设跟在被确认的数据后面的数据丢失了
  • • 第一个ACK是正常d
    • 收到第二个该段Ack标示接收方收到一个段后是乱序的
    • 收到3，4个该段的ACK，表示接收方收到该段之后的2个3个乱序，可能性非常大段丢失了

流量控制

TCP连接管理

在正式交换数据之前，发送方和接收方握手建立同i性能关系

• 同意建立连接（每一方都知道对方愿意建立连接）
• 同意连接参数

两次握手建立连接行不行？

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

两次连接失败场景：

服务器维护很多半连接，耗费很多资源。

老的数据被当成新的数据接收了。

三次握手解决

关闭连接

• 客户端，服务器分别关闭它自己这一侧的连接
• • 发送FIN bit = 1的TCP段
• 一旦接收到FIN， 用ACK回应
• • 街道FIN段，ACK可以和它自己发出的FIN段一起发送
• 可以处理同时的FIN交换

5、拥塞控制原理

拥塞：

非正式的定义：“太多的数据需要网络传输，超过了网络的处理能力”

拥塞的表现：

• 分组丢失
• 分组经历比较长的延时（在路由器的队列中排队）

网络中前10的问题

端到端拥塞控制：

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

网络辅助的拥塞控制：

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

网络交换节点负担比较重。

ATM ABR拥塞控制

ABR available bit rate:

• 弹性服务
• 如果发送端的路径“轻载”：发送饭更实用可用带宽
• 如果发送方路径拥塞了：发送方限制其发送的速度到一个最小保障速率上

RM (资源管理) 信源：

• 由发送端发送，在数据单元中间隔插入
• RM信元中的bit被交换机设置（”网络辅助“）
• • NT　bit ： no increase in rate (轻微拥塞) 速率不要增加了
  • CI bit: congestion indication 拥塞知识
• 发送端发送的RM信元被接收端返回，接收端不做任何改变

6、TCP拥塞控制（端到端的拥塞控制）

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

拥塞控制的几个问题

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

发送端如何探测到拥塞？

• 某个段超时了（丢失事件发生）：拥塞
• • 超时时间到，某个段的确认没有来
  • 愿意1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
  • 原因2：出错丢失了，概率小
  • 一旦超时，就被认为拥塞了，有一定误判，但时总体控制方向是对的
• 有关某个段的3次重复ACK：轻微拥塞
• • 段的第1个ACK，正常
  • 段的第2个重复ACK
  • 段的第2，3，4个重复ACK意味着收到了第234个段，乱序，同时有可能有丢失
  • 网络这是还能够进行一定程度的传输，拥塞但情况要比第一种好。

速率控制方法

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

• 维持一个拥塞窗口的值：CongWin
• 发送端限制已发送但是未确认的数据量（的上限）
• 从而粗略的控制发送方的往了网络重注入的速率

CongWin是动态的，是感知到的网络拥塞程度的函数

• 超过或者3个重复ACK，CongWin
• • 超时时：CongWin降为1MSS，进入ss阶段然后倍增到CongWin/2（每个RTT），从而进入CA阶段
  • 3个重复ACK：CongWin降为CongWin/2 , CA阶段
• 否则（正常收到Ack,没有发送以上情况），CongWin跃跃欲试
• • ss阶段：加倍增加（每个RTT）
  • ca阶段：线性增加（每个RTT)

拥塞控制和流量控制的联合动作

• 发送端控制发送但是未确认的量同时也不能够超过接收窗口，满足流量控制要求
• • SendWin = min(CongWin, RecvWin)
  • 同时满足拥塞控制和流量控制的要求

总结：TCP拥塞控制

当CongWin<Threadshold，发送端处于慢启动阶段（slow-start），窗口指数型增长

当CongWin>Threadshold，发送端处于拥塞避免阶段（congestion-avoidance），窗口线性增长。

当收到三个重复ACKS，Threadshold设置为CongWin/2.

CongWin = Thresshold + 3;

当超时时间发生时，Threashold = CongWin/2

CongWin = 1 Mss, 进入ss阶段。

公平性

公平习惯目标：如果K个TCP会话分享一个链路带宽为R的瓶颈，每一个会话的有效带宽为R/K

公平性和UDP

• 多媒体应用通常不是用TCP：应用发送的数据速率希望不受拥塞控制的节制
• 多媒体使用UDP

公平性和并行TCP连接

• 2个主机间可以打开多个并行TCP连接
• Web浏览器
• 例如：带宽为R的链路支持了9个连接
• • 乳沟新的应用要求建立1个TCP连接，获得带宽为R/10
  • 如果新的应用要求建立11个TCP,获得R/2;