# 概述和传输层服务

# 传输服务和协议

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

# 传输层和网络层

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

# Internet 传输层协议

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

# 多路复用 / 解复用

# 概述

# 在发送方主机多路复用

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

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

根据报文段的头部信息中的 IP 地址和端口号将接收到的报文段发给正确的套接字（和对应的应用进程）

# 多路解复用工作原理

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

# 无连接的多路解复用

• 创建套接字
  • 服务器端：serverSocket 和 Sad 指定的端口号捆绑
  • 客户端：没有 Bind，ClientSocket 和 OS 为之分配的某个端口号捆绑（客户端用什么端口号无所谓，客户端主动找服务器）
• 在接受端：UDP 套接字用二元组标识（目标 IP 地址，目标端口号）
• 当主机收到 UDP 报文段时：
  • 检查报文段的目标段号
  • 用该端口号将报文段发给套接字
• 如果两个不同源 IP 地址 / 源端口的数据报，但是有相同的目标 IP 和端口号，则被定位到相同的套接字

# 面向连接（TCP）的多路复用

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

# 无连接传输 UDP

# UDP：用户数据报协议

# 结构图

# UDP 特点

• 不建立连接（会增加延时）
• 简单：在发送端和接收端设有连接状态
• 报文段的头部很小（开销小）
• 无拥塞控制和流量控制，UDP 可以尽可能快的发送报文段

# UDP 校验和

# 目的

检测在被传输报文段中的差错

# 发送方

• 将报文段的内容视为 16bit 的整数
• 校验和：报文段的加法和
• 发送方将校验和放在 UDP 的校验和字段

# 接收方

• 计算机收到的报文段的校验和
• 交叉计算出的校验和与校验和字段的内容是否相等
  • 不相等：检测到差错
  • 相等：没有检测到差错，但也许还是有差错

# 可靠数据传输原理

# 可靠数据传输（rdt）的原理

• rdt 在应用层，传输层和数据链路层都很重要
• 信道的不可靠的特点决定了可靠数据传输协议（rdt）的复杂性

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

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

# rdt2.0：具有比特差错的信道

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

# rdt2.2：无 NAK 的协议

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

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

# 确认超时重传机制

• 发送端超时重传：如果没有收到 ACK，就重传
• 重传机制会导致数据重复，但利于序列号已经处理这个问题
• 接收方必须指明正确接收的序列号
• 需要一个倒计数定时器

# 流水线协议

# 流水线

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

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

# 滑动窗口协议（slide window）

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

# 发送窗口滑动过程

• 采取相对移动方式表示，分组不动
• 可缓冲范围移动，代表一段可以发送的权力

# 滑动窗口协议过程

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

# 滑动窗口协议 - 接收窗口

• 接收窗口 = 接收缓冲区

  • 接收窗口用于控制哪些分组可以接收
  • 接收窗口尺寸 = 1，则只能顺序接收
  • 接收窗口尺寸 > 1，则可以乱序接收

• 接收窗口的滑动和发送确认

  • 滑动：
    • 低序号的分组到来，接受窗口移动
    • 高序号的分组乱序到来，缓存但不交复
  • 发送确认
    • 接受敞开尺寸 = 1：发送连续收到的最大分组确认（累计确认）
    • 接收窗口尺寸 > 1：收到分组，发送哪个分组的确认（非累计确认）

# GBN 协议和 SR 协议

# 相同

• 发送窗口 > 2
• 一次能够可发送多个未经确认的分组

# 不同

• GBN：接收窗口尺寸 = 1
  • 接收端：只能顺序接收
  • 发送方：从表现来看，一旦一个分组没有发送成功，如果 0，1，2，3，假如 1 未成功，234 都发送出去了，要返回 1 再发送
• SR：接收窗口尺寸 > 1
  • 接收端：可以乱序接收
  • 发送端：发送 0，1，2，3，4，一旦 1 未成功，2，3，4 已发送，无需重发，选择性发 1

# 面向连接的传输（TCP）

# TCP 概述

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

# TCP 报文段结构

# TCP 序号，确认号

# 序号

• 报文段首字节在字节流中的编号

# 确认号

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

# 图解

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

# 设置 TCP 超时

• 比 RTT 要长
• 太短：太早超时
  • 不必要的重传
• 太长：对报文段丢失
  • 反应太慢，消极

# TCP 可靠数据连接

• TCP 在 IP 不可靠的服务基础上建立了 rdt
  • 管道化的报文段（GBN 和 SR）
  • 累积确认（GBN）
  • 单个重传定时器（GBN）
  • 是否可以接收乱序，没有规范
• 通过以下事件触发重传
  • 超时（只重传哪个最早的未确认的段：SR）
  • 重复的确认
• 简化 TCP 发送方
  • 忽略重复的确认
  • 胡亮流量控制和拥塞控制

# TCP 发送方事件

# 应用层接收数据

• 用 nextseq 创建报文段
• 序号 nextseq 为报文段首字节的字节流编号
• 如果还没有运行，启动定时器
  • 定时器与最早未确认的报文段关联

# 超时

• 重传后沿最老的报文段
• 重新启动定时器

# 收到确认

• 如果是对尚未确认的报文段确认
  • 更新已被确认的报文序号
  • 如果当前还有未被确认的报文段，重新启动定时器

# TCP 重传

# 快速重传

• 超时周期往往太长
  • 在重传丢失报文段之前的延时太长
• 通过重复的 ACK 来检测报文段的丢失
  • 发送方通常连续发送大量的报文段
  • 如果报文段丢失，通常会引起多个重复的 ACK
• 如果发送方收到同一数据的 3 个冗余 ACK，重传最小序号的段
  • 快速重传：在定时器过期之前重发报文段

# TCP 流量控制

• 接收方在其向发送方的 TCP 段头部的 rwnd 字段通告其空闲的 buffer 大小
• 发送方限制未确认字节的个数 <= 接收方发送过来的 rwnd 值
• 保证接收方不会被掩码

# TCP 连接与释放

# TCP 三次握手

# 两次握手失败场景

# 三次握手模型

# TCP 四次挥手（关闭连接）

# 步骤

• 客户端，服务器分别关闭它自己这一侧的连接
• 一旦受到 FIN，用 ACK 回应
• 可以处理同时的 FIN 交换

# 模型

# 拥塞控制

# 拥塞控制原理

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

# 拥塞控制的方法

# 端到端的拥塞控制

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

# 网络辅助的拥塞控制

• 路由器提供端系统以反馈信息
  • 单个 bit 置位，显示拥塞
  • 显示提供发送端可以采用的速率

# TCP 拥塞

# TCP 拥塞控制机制

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

# TCP 拥塞控制速率控制方法

# 控制发送端的发送速率

• 超时或者 3 个重发的 ack，CongWin
  • 超时时：CongWIn 降为 1MSS，进入 ss 阶段然后成倍增加到 CongWin/2，从而进入 CA 阶段
  • 3 个重复 ack：CongWin 降为 CongWIn/2，CA 阶段
• 否则（正常收到 ACK，但是没有发送以上的情况）
  • SS 阶段：加倍增加（每个 RTT）
  • CA 阶段：线性增加（每个 RTT）

# 拥塞控制策略

# TCP 慢启动

• 连接刚建立，CongWin=1MSS
• 可用带宽可能 >>MSS/RTT
  • 应该尽快加速，到达希望的速率
• 当连接开始时，指数性增加发送速率，直到发生丢失事件
  • 启动初值很低
  • 速度很快
• 当连接开始时，指数性增加（每个 RTT）发送速率丢失事件
  • 每一个 RTT，CongWin 加倍
  • 每收到一个 ACK 时，CongWin+1
  • 慢启动阶段：只要不超时或 3 个重复的 ACK，一个 RTT，CongWin 加倍

# AIMD

• 乘性减

  • 丢失事件后将 CongWin 降为 1，将 CongWin/2 作为阈值，进入慢启动阶段

• 加法乘

  • 当 CongWin > 阈值时，一个 RTT 如没有发生丢失事件，将 CongWin 加 1MSS，探测

• 当收到 3 个重复 ACK

  • CongWin 减半
  • 窗口（缓冲区大小）之后线性增长

• 当超时事件发生后

  • CongWin 被设置为 1MSS，进入 SS 阶段
  • 之后窗口指数增长
  • 增长到一个阈值（上次发生拥塞窗口的一半）时，再线性增加