# 第三章:传输层

# 1. 概述和传输层服务

# (1). 传输协议和服务

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

# (2). 传输层 VS 网络层

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

# (3). Internet 传输协议

  • 可靠的、保序的传输:TCP

    • 多路复用、解复用
    • 拥塞控制
    • 流量控制
    • 建立连接
  • 不可靠、不保序的传输:UDP

    • 多路复用、解复用

    • 没有为尽力而为的 IP 服务添加更多的其他额外服务

  • 都不提供的服务:

    • 延时保证
    • 带宽保证

# 2. 多路复用 / 解复用

  • 在发送方主机多路复用

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

  • 在接收方主机解复用

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

  • image-20220419141823311

# 3. 无连接传输 UDP

  • image-20220419143001305

  • image-20220419143333624

  • image-20220419143847516

  • image-20220419144458370

# 4. 可靠数据传输 (RDT) 的原理

# (1) 问题描述

  • image-20220419145440402

# (2)RDT

  • RDT 1.0** > image-20220419145959385

  • RDT 2.0 > image-20220419150123327

  • RDT 2.1 > image-20220419200802380

    image-20220419201147064

  • RDT 2.2 > image-20220419201737116

  • RDT 3.0 > image-20220419203025590

    image-20220419204200758

# (3). 流水协议

  • 流水线协议
    image-20220419205119533

  • 滑动窗口协议
    image-20220419205349368

    image-20220419210028291

    • image-20220419210126707

image-20220419210300325

  • image-20220419210609748

    image-20220419211136539

    • image-20220419211729788

image-20220419212606597

image-20220419212646137

image-20220419212806202

  • image-20220419213042447

  • image-20220419213559365

  • image-20220419213920016

image-20220419214050639

  • image-20220419214152849

# 5、面向连接的传输:TCP

# (1). TCP 概述

  • image-20220423155619410

# (2). TCP 报文结构

  • image-20220423155829103
    • image-20220423161536259

# (3). 往返时间的估计与超时

  • image-20220423162303614

  • image-20220423162953639

    image-20220423163025528

# (4). 可靠数据传输

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

    • 管道化的报文段
      • GBN or SR
    • 累积确认 (像 GBN)
    • 单个冲传定时器
    • 是否可以接收乱序的,没有规范
  • 通过以下时间出发重传

    • 超时 (只重发那个最早的未确认段:SR)
    • 重复的确认
      • 例子:收到了 ACK50,之后又收到 3 个 ACK50
  • 首先考虑简化的 TCP 发送方:

    • 忽略重复的确认
    • 忽略流量控制和拥塞控制
  • image-20220423164848094

  • image-20220423165414206

  • image-20220423165709674

# (5). 流量控制

  • image-20220426135711627

  • image-20220426135903078

# (6). 连接管理

  • image-20220426140218407

  • image-20220426142126406

# 6、拥塞控制原理

  • 拥塞:

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

    • 代价:1. 延迟大 2. 需要更大的输出速率 3. 在拥塞时,会重传许多不必要的分组,加速拥塞 4. 在拥塞时,有些分组上游的传输能力被浪费掉,无法进行传输

    • image-20220429135752212

    • image-20220429135827382

    • 死锁image-20220429140524096

  • 拥塞控制方法

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

    • image-20220429142719285

# 7、TCP 拥塞

  • image-20220429151155134

  • image-20220429153002979

    image-20220429153216660

  • image-20220429153325916

  • image-20220429153512487

    image-20220429153530821

    image-20220429154210009

  • image-20220429154259596

  • image-20220429154435255

    • image-20220429154752232

    • image-20220429154816391

      image-20220429155146589