计算机网络3

传输层

  1. 为运行在不同的端系统上的进程提供了一种逻辑通信机制(网络层提供主机之间的逻辑通信机制)

    • 位于网络层之上
    • 依赖于网络层
    • 对网络层功能进行加强
  2. 传输层提供的服务

    • 可靠的、按序的交付服务(TCP)
      • 流量控制
      • 拥塞控制
      • 连接建立
    • 不可靠的交付服务(UDP)
      • 复用/分用
      • 简单的错误校验
      • 尽力而为(best effort)
      • 不需要建立链接,延迟很小
      • 上层更好控制(不用顾及拥塞控制之类)
      • 经常用于流媒体、DNS、SNMP等
    • 不提供延迟、带宽等方面的服务
  3. 多路复用/分用

可靠数据传输

  1. 不错、不丢、不乱

  2. 可靠数据传输协议

  3. 需要双向的控制信息流实现,上层单向流动到可靠协议,由可靠协议负责和不可靠的UDP双向交互实现可靠传输

  4. 协议实现(数据错误,位错误)

    • 有限状态机来刻画传输协议
    • 确认机制(ACK: 确认; NAK:数据错误; 错误重传机制)— 接收方显式回传控制消息
      • 为ACK和NAK增加校验和
      • 添加额外的控制消息
      • NAK/ACK 坏掉重传(产生重复传送的问题)
      • 增加序列号进行NAK/ACK重传
    • 差错检测(校验和等)
    • 停-等协议(有限状态机)
    • NAK可以在ACK确认消息的时候加入序列号代替(确认最后一个分组)

    5 . 协议实现(丢失分组)

    • 等待合理的一段时间之后重传(需要定时器)
    • 停等引起效率低下
    • 采用流水线机制(连发多个分组再等待ACK)
    • 使用滑动窗口协议实现流水线

滑动窗口协议

GBN(Go-Back-N)协议:一组分组一组分组的滑动

  1. 发送方

    • 窗口尺寸为N,最多允许有N个分组未确认,分组头部包含K-bit序列号

    • 采用累积确认的方式

      1
      ACK(n)表示确认到n(包含n)的分组均被正确接收
    • 整个窗口设置一个计时器

    • 超时则重发序列号大于n还未收到ack的分组

  2. 接收方(没有缓存,没有接收方窗口)

    • 发送拥有最高序列号的、已被正确接收的分组的ACK
      • 可能产生重复的ACK
    • 乱序到达的分组直接丢弃,重新确认正确收到的最大的序列号

SR(selective repeat)协议:一个分组一个分组的滑动

  1. 接收方(设置缓冲机制,缓冲乱需到达的分组)
    1. 添加接收方窗口
    2. 对每个分组单独确认
  2. 发送方
    1. 为每个分组设置单独的计数器
  3. 窗口可以跳跃前移

TCP概述

  1. 点对点(一个发送方,一个接收方)

  2. 可靠的按序的字节流

  3. 流水线机制(拥塞控制,流量控制,窗口大小设置)

  4. 发送方/接收方缓存

  5. 全双工(同一连接中能传输双向数据流)

  6. 面向连接

    1. 通信双方在发送数据前必须建立连接
    2. 连接状态只在连接的两端维护,沿途 结点并不维护
    3. TCP连接包括:两台主机上的缓存,连接状态变量、socket等
  7. 流量控制机制

  8. 序列号是segment中第一个字节的编号,而不是segment的编号,建立TCP连接时双方随机选择序列号

  9. ACKS

    1. 累计确认机制:该序列号之前的所有字节已经被正确处理
    2. 返回是希望接收到的下一个字节的序列号
  10. 可靠数据传输

    1. TCP在IP层提供不可靠的服务基础上实现可靠数据传输服务
    2. 使用单一重传定时器
    3. 触发重传的事件(超时,收到重复ACK)
  11. 快速重传

    ​ 由于接受断发回的ACK是希望接收到的字节的序列号,当连续收到三个相同的ACK时就执行快速重传而不用等超时再传

  12. 流量控制(速度匹配机制)

    控制发送方发送速度不要过快以至于淹没接收方的buffer

    receiver 在segment头部告诉sender还有多少buffer

  13. 多媒体应用通常不使用TCP,以免被拥塞控制机制限制速率

连接管理

  1. 一般由TCP的发送端(客户机)请求建立连接,接收端等待客户连接请求
  2. 连接的三次握手
    1. 客户机向服务器发送一个SYN段(没有数据,包含客户端初始选择的序列号)
    2. 服务器答复SYNACK(选择服务器的初始序列号,分配客户机缓存)
    3. 客户机收到SYNACK,回复ACK(可以包含数据)
    4. 建立TCP连接两次握手不能确定具体是否成功,四次握手会有资源浪费
  3. 关闭的四次握手
    1. 客户机向服务器发送FIN报文段
    2. 服务器收到FIN,回复ACK,关闭连接,发送FIN
    3. 客户机收到FIN,回复ACK
      1. 进入等待状态,如果收到FIN,则重新发送ACK
    4. 服务器收到ACK,关闭链接

拥塞控制

  1. 表现

    1. 分组丢失
    2. 分组延迟越来越大

    拥塞控制方法

    • 端到端的拥塞控制(端系统通过观察loss(分组丢失)delay(分组延迟时间等来判断网络是否发生拥塞—-TCP采用这种方法)
    • 网络辅助的拥塞控制(路由器显式的向发送方反馈网络的用色信息,简单的拥塞指示(1 bit):指示发送方该采取何种速率—-ATM)

    拥塞控制的基本原理

    • 限制sender的发送速率

    • ConfgWin:(发送窗口的大小)

      • 动态调整以改变发送速率
      • 反映所感知到的网络拥塞
    • 网络拥塞的感知

      • LOSS事件==timeout或者连续3个重复的ACK
    • 合理调整发送速率

      • 加性增—乘性减(AIMD)

        谨慎的探测可用带宽,逐渐增加发送速率,直到发生loss事件(每个RTT将CongWin增大一个MSS); 发生loss之后已经拥塞,需要快速降低发送频率(将CongWin减半)

      • 慢启动(SS)

        当链接刚刚建立时(CongWin = 1, 初始速率20k),让CongWin指数增长; 每个RTT将CongWin翻倍–>快速攀升

      • 指数增长切换到加性增

        用一个变量Threshold, 设置为LOSS事件前congWin值的1/2.

        loss event

        • 收到3个重复的ACK(网络还能传输一些segment)

          将congWin切为一半,然后线性增长

        • Timeout事件(拥塞更严重)

          CongWin直接设为1,然后指数增长,达到threshold之后再线性增长