计算机网络笔记（五）：传输层

前言

理解传输层服务的基本理论和基本机制

• 多路复用/分用
• 可靠数据传输机制
• 流量控制机制
• 拥塞控制机制

传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制。

端系统运行传输层协议

• 发送方：将应用递交的消息分成一个或多个的Segment，并向下传给网络层。
• 接受方：将接收到的Segment组装成消息，并向上交给应用层。

传输层与网络层

• 网络层：提供主机之间的逻辑通信机制
• 传输层：提供应用进程之间的逻辑通信机制

可靠的、按序的交付服务（TCP）

• 拥塞控制
• 流量控制
• 连接建立

不可靠的交付服务（UDP）

• 基于“尽力而为（Best-effort）”的网络层，没有做（可靠性方面的）扩展

两种服务均不保证延迟、带宽。

多路复用和多路分用

如果某层的一个协议对应直接上层的多个协议/实体，则需要复用/分用。

主机接收到IP数据报（datagram）

• 每个数据报携带源IP地址、目的IP地址
• 每个数据报携带一个传输层的端（segment）
• 每个段携带源端口号和目的端口号

主机收到Segment之后，传输层协议提供IP地址和端口号信息，讲Segment导向相应的Socket

• TCP做很多处理

无连接分用

1. 利用端口号创建Socket
2. UDP的Socket用二元组标识（目的IP地址，目的端口号）
3. 主机收到UDP段后
   • 检查段中的目的端口号
   • 将UDP段导向绑定在该端口号的Socket
4. 来自不同源IP地址和/或源端口号IP数据包被导向同一个Socket

面向连接的分用

1. TCP的Socket用四元组标识：源IP地址、源端口号、目的IP地址、目的端口号
2. 接收端利用所有的四个值将Segement导向合适的Socket
3. 服务器可能同时支持多个TCP Socket
   • 每个Socket用中间的四元组标识
4. Web服务器为每个客户端开不同的Socket

UDP（User Datagram Protocol [RFC 768]）

基于Internet IP协议，增加了：

• 复用 / 分用
• 简单的错误校验

“Best effort” 服务，UDP段可能：

• 丢失
• 非按序到达

无连接

• UDP发送发和接收方之间不需要握手
• 每个UDP段的处理独立于其他段

UDP为什么存在？

• 无需建立连接（减少延迟）
• 实现简单：无需维护连接状态
• 头部开销少
• 没有拥塞控制：应用可更好地控制发送时间和速率

应用

1. 常用于流媒体应用： 容忍丢失、速率敏感
2. UDP还用于：DNS、SNMP

在UDP上实现可靠数据传输？

• 在应用层增加可靠性机制
• 应用特定的错误恢复机制

UDP校验和（checksum）

目的：检测UDP段在传输中是否发生错误（如，位翻转）

发送方：

• 将段的内容视为16-bit整数
• 校验和计算：计算所有整数的和，进位加在和的后面，将得到的值按位求反，得到校验和
• 发送方将校验和放入检验和字段

接收方：

• 计算所收到段的检验和
• 将其与校验和字段进行对比：不相等则检测出错误，相等则没有检测出错误（但可能有错误）

可靠数据传输原理

什么是可靠：不错、不丢、不乱

可靠数据传输协议：

• 可靠数据传输对应用层、传输层、链路层都很重要
• 网络Top-10问题
• 信道的不可靠特性决定了可靠数据传输协议（rdt）的复杂性

可靠性数据传输协议

• 渐进地设计可靠数据传输协议的发送方和接收方
• 只考虑单项数据传输，但控制信息双向流动
• 利用状态机（Finite State Machine，FSM）刻画传输协议

Rdt 1.0 : 可靠信道上的可靠数据传输

• 底层信道完全可靠：不会发生错误（bit error），不会丢弃分组
• 发送方和接收方的FSM独立

Rdt 2.0：不可靠（例如，产生位错误，但是没有丢包）信道的可靠数据传输

• 底层信道可能翻转分组中的位（bit）
  • 利用 校验和 检测位错误
• 如何从错误中恢复？
  • 确认机制（Acknowledgments，ACK）：接收方显示地告知发送方分组已正确接收
  • NAK：接收方显示地告知发送方分组有错误
  • 发送方收到NAK后，重传分组
• 基于这种重传机制的rdt协议称为 ARQ（Automatic Repeat reQuest）协议
• Rdt 2.0中引入的新机制
  • 差错检测
  • 接收方反馈控制消息：ACK / NAK
  • 重传

Rdt 2.0 缺陷：

如果 ACK/NAK 消息发生错误/被破坏（corrupted）会怎么样？ 我们思考下面几种方案：

1. 为ACK / NAK 增加校验和，检错并纠错
2. 发送方收到被破坏ACK / NAK 时不知道接收方发生了什么，添加额外的控制消息
3. 如果ACK / NAK 坏掉，发送方重传
4. 重传，但不能简单的重传：产生重复分组

我们一般选择重传，但如何解决重复分组问题？

• 序列号（Sequence number）：发送方给每个分组增加序列号
• 接收方丢弃重复分组

Rdt 2.1 ： 针对ACK / NAK 破坏

发送方：

• 为每个分组增加序列号（0，1）
• 需校验ACK / NAK 消息是否发生错误
• 状态数量翻倍
  • 状态必须”记住“”当前“的分组序列号
    
    接收方
• 需判断分组是否重复
  • 当前所处状态提供了期望收到分组的序列号
• 注意：接收方无法知道ACK / NAK 是否被发送方正确收到
  
  我们真的需要两种确认消息（ACK+NAK） 吗？

Rdt 2.2：无NAK消息协议

• 接收方通过ACK告知最后一个被正确接收的分组
• 在ACK消息中显式的加入被确认分组的序列号
• 发送方收到重复ACK之后，采取与收到NAK消息相同的动作，重传当前分组

如果信道既可能发生错误，也可能丢失分组，怎么办？

• “校验和 + 序列号 + ACK + 重传” 够用吗？

方法：发送方等待“合理”时间

• 如果没有收到ACK，重传
• 如果分组或者ACK只是延时而不是丢了
  • 重传会产生重复，序列号机制能够处理
  • 接收方需要在ACK中显示告知所确认的分组
• 需要定时器

Rdt 3.0： 添加超时机制

计时器过短 / timeout 早熟 将造成大量出现重复包，如何合理设置计时器时间？

Rdt3.0 能够正确工作，但性能很差，因为其是停等协议，需要等待回复。

Rdt 3.0 虽然功能正确，但是其性能太过于糟糕，因为停等的操作，1G的链路上1秒钟才只能传输33KB的数据，于是流水线机制应运而生（在等待的情况下发送其他分组的数据）。

流水线机制与滑动窗口协议

允许发送方在收到ACK之前连续发送多个分组

• 更大的序列号范围
• 发送方 和/或 接收方需要更大的存储空间以缓存分组
  

滑动窗口协议 : Sliding - Window Protocol

窗口

• 允许使用的序列号范围
• 窗口尺寸为N：最多有N个等待确认的消息

滑动窗口：随着协议的允许，窗口在序列号空间内向前滑动

滑动窗口协议：GBN，SR

• 绿色：发送完已确认的数据
• 黄色：发送完待确认的数据
• 蓝色：还可以使用的序列号空间

Go - Back - N （GBN）协议

发送方

• 分组头部包含k-bit 序列号
• 窗口尺寸为N，最多允许N个分组未确认
  
• ACK(n) ：确认到序列号n（包含n）的分组均已被正确接收（可能收到重复ACK）
• 为空中的分组设置计时器
• 超时Timeout（n）事件：重传序列号大于等于n，还未收到ACK的所有分组

接收方

• ACK机制：发送拥有最高序列号的、已被正确接收的分组的ACK

  • 可能参产生重复ACK
  • 只需要记住唯一的expectedseqnum

• 乱序到达的分组

  • 直接丢弃 -> 接收方没有缓存
  • 重新确认序列号最大的、按序到达的分组
    
    GBN有什么缺陷？

• GBN在重传时会重传多个分组（例如：序列号N丢失之后，会重传N及以后没确认的分组）

• 网络中充斥着这些重传的分组，影响性能

怎么避免这些缺陷？

• 不适用累计确认机制，单个确认
• 不丢弃乱序的分组，缓存起来

Selective Repeat （SR）协议

接收方对每个分组单独确认

• 设置缓存机制，缓存乱序达到的分组

发送方只重传那些没收到ACK的分组

• 为每个分组设置单独定时器，该分组超时没有收到ACK时，进行重传

发送方窗口

• N个连续的序列号
• 限制已发送且未确认的分组
  
  
  
  
  
  

TCP 协议 (RFCs-793, 1122, 1323, 2018, 2581)

特点：

• 点对点：一个发送方，一个接收方

• 可靠的、按序的字节流

• 流水线机制：TCP拥塞控制和流量控制机制、设置窗口尺寸

• 发送方 / 接收方缓存

• 全双工（full-duplex）：同一连接中能够传输双向数据流

• 面向连接：1. 通信双方在发送数据之前必须建立连接。2. 连接状态只在连接的两端中维护，在沿途节点中并不维护状态。 3. TCP连接包括：两台主机上的缓存、连接状态变量、Socket等。

• 流量控制机制

序列号（sequence number）：

• 序列号指的是Segment中第一个字节的编号，而不是Segment的编号，该序列号被用来跟踪该端发送的数据量。
• 建立TCP连接时，双方随机选择序列号（不完全随机，而是随着时间流逝而线性增长，到了2^32尽头再回滚），为的就是让攻击者更难以猜测sequence number，因为伪造的sequence number不在合法范围内，而被接收方丢弃，增加安全性。

举例，随机序列号从0开始，有1K个字节的数据拆成两个segment，则第二的segment的编号是501。

Acks：

• 希望接收到的下一个字节的序列号，即上一个字节的序列号Seq加1
• 累计确认：该序列号之前的所有字节均已被正确接收到

问：接受方如何处理乱序到达的Segment?（GBN协议乱序到达直接丢弃，SR协议使用缓存机制）

• 答： TCP规范中没有规定，由TCP的实现者做出决策

TCP可靠数据传输

特点：

• IP层提供不可靠的数据传输，TCP在IP层提供的不可靠服务基础上实现可靠数据传输服务
• 流水线机制
• 累计确认
• TCP使用单一重传定时器
• 触发重传的事件：1. 超时 2. 收到重复ACK
• 渐进式：1. 暂不考虑重复ACK 2. 暂不考虑流量控制 3. 暂不考虑拥塞控制

问题： 如何设置定时器的超时时间？

• 大于RTT：但是RTT是变化的
• 过短：不必要的重传
• 过长：对段丢失时间反应慢

问题：如何评估RTT（Round-trip delay：来回通讯延时 ）？

• SampleRTT：测量从段发出去到收到ACK的时间（忽略重传）
• SampleRTT变化：测量多个SampleRTT，求平均值，形成RTT的估计值EstimatedRTT
  
  定时器超时时间的设置：
• EstimatedRTT + “安全边界”
• EstimatedRTT变化大 -》 较大的边界

TCP发送方事件：

1. 从应用层收到数据：创建Segment、序列号是Segment第一个字节的编号、开启定时器、设置超时事件TimeOutInterval
2. 超时：重传引起超时的Segment、重启定时器
3. 收到ACK：如果确认此前未确认的Segment，更新SendBase。如果窗口中还有未确认的分组，重新启动定时器。

TCP 接收方：ACK生成（RFC 1122，RFC 2581）

快速重传机制

TCP的实现中，如果发生超时，超时事件间隔将重新设置，即将超时事件间隔加倍，导致其很大，重发丢失的分组之前要等待很长事件。

• 通过重复ACK检测分组丢失：Sender会背靠背地发送多个分组，如果某个分组丢失，可能引发多个重复的ACK
• 如果Sender收到同一数据的3个ACK，则假定该数据之后的段已经丢失。
• 快速重传：在定时器超时之前即进行重传，而不必等待TimeOut。

TCP流量控制

接受方为TCP 连接分配 Buffer：

Flow Control 流量控制：发送方不会传输的太多、太快以至于淹没接收方（Buffer溢出）

• 速度匹配机制

TCP连接管理

TCP 发送方和接收方在传输数据前需要建立连接

1. 初始化TCP变量
   • Seq.#
   • Buffer 和 流量控制信息
2. Client：连接发起者
   • socket clientSocket = new Socket(“hostname”，“port number”)；
3. server：等待客户连接请求
   • socket connectionSocket = welcomeSocket.accept()；

Three way handshark：

1. Step1：客户端主机向服务器发送 TCP SYN segment (Synchronize Sequence Numbers，同步序列编号)
   • SYN序列号置一，表示需要建立连接
   • 特殊的客户端初始序列号 seq # （一般是随机数）
   • 不包含数据
2. Step2：服务端主机接收SYN，答复 SYNACK segment
   • 服务器分配缓存
   • 特殊的服务端初始序列号 seq #（一般是随机数）
3. Step3：客户端收到SYNACK，答复 ACK segment
   • SYN序列号不在置1，与服务器确认同一建立连接的报文段
   • 可以包含数据

是不是在三次握手的第二步服务器就会分配资源吗？ 假如说三次握手客户端向服务器的ACK没有发送过来，这时候服务器的资源会保留一段时间，直到超时确认连接不会建立，ACK将不会到来时释放资源。

假如大量客户端向服务器发起建立连接请求，当服务器返回SYNACK之后，客户端不回复ACK，这时候会怎么样？服务器的资源时候会耗尽？

Closing a connection：

• Step 1：client向Server发送TCP FIN 控制 segment
• Step 2：server收到FIN，回复ACK，关闭连接，发送FIN
• Step 3：Client收到FIN，回复ACK：进入“等待”，确保服务器关闭并释放资源。此时如果重复收到FIN，会重复发送ACK
• Step 4：server收到ACK，连接关闭

拥塞控制原理

对比：

1. 可靠数据传输针对端到端的，个体的利益传输的角度，采用确认、重传保证数据传输。
2. 流量控制是发送方不要发送太快以至于接收方处理不了。
3. 拥塞控制更像是群体利益考虑，个体之间做出一定的牺牲保证网络的负载，确保网络处理速度。

拥塞（Congestion）

• 非正式定义：太多发送主机发送了太多数据或者发送速度太快，以至于网络无法处理。
• 表现：分组丢失（路由器缓存溢出）、分组延时过大（在路由器缓存中排队）
• 拥塞控制 VS 流量控制
• A top-10 problem
• 当分组被drop时，任何用于该分组的“上游路由”传输能力全部被浪费掉
  

为什么拥塞控制需要在传输层来做？不是所有的传输层协议都需要拥塞控制，比如UDP。

拥塞控制的方法有哪些？

端到端拥塞控制

• 网络层不需要显示的提供支持
• 端系统通过观察Loss、delay等网络行为判断是否发送拥塞
• TCP采取这种方法

网络辅助的拥塞控制

• 路由器向发送方显示地反馈网络拥塞信息
• 简单的拥塞指示（1bit）： SNA，DECbit，TCP/IP ECN，ATM
• 指示发送方应该采取何种速率

案例：ATM ABR拥塞控制

ABR：available bit rate

• “弹性服务”
• 如果发送方路径“underloaded”，使用可用带宽（降低当前带宽）
• 如果发送方路径拥塞，将发送速率降低最低保障速率

RM（resource management）cells：穿插在Data cells之间

• 发送方发送
• 交换机设置RM cell位（网络辅助）
  • NI bit：rate不许增长
  • CI bit：拥塞指示
• RM cell 由接收方返回给发送方

TCP 拥塞控制

Sender限制发送速率：$$LastByteSent-LastByteAcked<=Congwin$$

$$rate\approx \frac{CongWin}{RTT}Bytes/sec$$

Congwin ：1. 动态调整以改变发送速率 2. 反映所感知到的网络拥塞

问题：如何感知网络拥塞？

• Loss事件 = TimeOut 或者 3个重复ACK
• 发生Loss事件后，发送方减低速率

如何合理地调整发送速率？

1. 慢启动：SS

   • TCP连接建立时，CongWin = 1。例如：MSS = 500 Byte，RTT = 200msec，初始速率 = 20k bps
   • 可用带宽可能远远高于初始速率：希望快速增长
   • 原理：当连接开始时，指数性增长，每个RTT将CongWin翻倍，收到每个ACK进行操作。

2. 加性增——乘性减： AIMD 拥塞避免

   • 原理：逐渐增加发送速率，谨慎探测可用带宽，直到发生Loss Event。
   • 方法：AIMD 1. Additive Increase，每个RTT将CongWin增大一个MSS（最大段长度），进行拥塞避免。 2. Multiplicative Decrease，发生Loss后将CongWin减半。

何时应该指数性增长切换为线性增长（拥塞避免）？Threshold变量：

• 当CongWin达到Loss事件前值的1/2时，Threshold被设为Loss事件前CongWin值得1/2。

Loss Event 的产生与处理

• 3个重复ACKs（表示网络还可以传输一些Segments）：CongWin切到一半，然后线性增长
• TimeOut Event（表明拥塞更加严重）：CongWin直接设为1个MSS，然后指数增长，达到threshold后，再线性增长。

TCP性能分析

TCP throughput：吞吐率

• 给定拥塞窗口大小和RTT，TCP的平均吞吐率是多少？忽略Slow Strat
• 假定发生超时的CongWin的大小为W，吞吐率是W / RTT
• 超时后，CongWin = W / 2，吞吐率是W / 2RTT
• 平均吞吐率为：0.75W / RTT

举例：每个Segement有1500 byte，RTT是100ms，希望获得10Gbps的吞吐率

• throuhput = W * MSS * 8 / (MSS * 8)
• W = throuhput * RTT / (MSS * 8)
• throuhput = 10 Gbps，则 W(窗口大小) = 83333

TCP 具有公平性

• 如果K个TCP Session共享相同的瓶颈带宽R，那么每个Session的平均速率为 R / K。