sinEagle

bottlecode

0%

HIT-计算机网络(自顶向下方法)-传输层

发表于 更新于
本文字数： 5.4k 阅读时长 ≈ 5 分钟

传输层服务

传输层开篇

  • 理解传输层服务的基本理论与基本机制
    • 复用/分用
    • 可靠数据传输机制
    • 流量控制机制
    • 拥塞控制机制
  • 掌握Internet传输层协议
    • UDP : 无连接传输服务
    • TCP ：面向连接传输服务
    • TCP拥塞控制

传输层服务概述

传输层服务和协议

  • 传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制
  • 端系统运行传输层协议
    • 发送方： 将应用递交的消息分成一个或多个Segment， 并向下传给网络层
    • 接收方： 将接受到的segment组装成消息，并向上交给应用层
  • 传输层可以为应用提供多种协议
    • Internet 上的 TCP
    • Internet 上的 UDP

传输层 vs. 网络层

  • 网络层： 提供主机之间的逻辑通信机制
  • 传输层： 提供应用进程之间的逻辑通信机制
    • 位于网络层之上
    • 依赖于网络层服务
    • 对网络层服务进行（可能的）增强

Internet传输层协议

  • 可靠、按序的交付服务（TCP）
    • 拥塞控制
    • 流量控制
    • 连接建立
  • 不可靠的交付服务（UDP）
    • 基于 “尽力而为” 的网络层，没有做（可靠性方面的）扩展
  • 两种服务均不保证
    • 延迟
    • 带宽

多路复用和多路分用

多路复用/分用

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

分用如何工作

  • 主机接受到 IP 数据包（datagram）
    • 每个数据包携带源IP地址、目的IP地址
    • 每个数据包携带一个传输层的段（segment）
    • 每个段携带源端口号和目的端口号
  • 主机收到segment后， 传输层协议提取IP地址和端口号信息，将segment导向相应的Socket
    • TCP做更多处理

无连接分用

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

面向连接的分用

  • TCP的Socket 用四元组标识

    • 源IP地址
    • 源端口号
    • 目的IP地址
    • 目的端口号

  • 接受端利用所有的四个值将Segment导向合适的Socket

  • 服务器可能同时支持多个TCP Socket

    • 每个Socket用自己的四元组标识

  • Web服务器为每个客户端开不同的Socket

多线程Web服务器

无连接传输协议-UDP

UDP

  • 基于 Internet IP协议

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

  • “Best effort 服务” , UDP端可能

    • 丢失
    • 非按序到达

  • 无连接

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

UDP为什么存在？

  1. 无需建立连接（减少延迟）
  2. 实现简单，无需维护连接状态
  3. 头部开销少
  4. 没有拥塞控制；应用可更好地控制发送时间和速率
  • 常用用于流媒体应用
    • 容忍丢失
    • 速率敏感
  • UDP还用于
    • DNS
    • SNMP
  • 在UDP上实现可靠数据传输
    • 在应用层增加可靠机制
    • 应用特定的错误恢复机制

UDP检验和（checksum）

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

  • 发送方：
    • 将段的内容视为16-bit整数
    • 校验和计算：计算所有的整数的和，按位加在和的后面，得到的和按位取反，得到检验和
    • 发送方将检验和放入校验和字段
  • 接收方：
    • 计算所收到段的校验和
    • 将其与校验和字段进行对比
      • 不相等：检验出错误
      • 相等：没有检验出错误（但可能有错误）

可靠数据传输原理

可靠数据传输协议基本结构：接口

Rdt1.0: 可靠信道上的可靠传输

底层信道完全可靠

  • 不会丢弃分组
  • 不会发生错误

发送方和接收方 FSM 独立

Rdt2.0

Rdt2.0 产生位错误的信道

底层信道可能翻转分组中的位（bit）

  • 利用校验和检测位错误

如何从错误中恢复？

确认机制（Acknowledgements , ACK）: 接收方显示地告诉发送方分组已正确接受

NAK: 接收方显式地告诉发送方分组有错误

发送方收到 NAK 后，重传分组

基于这种重传机制的 rdt 协议称为 ARQ(Automatic Repeat reQuest) 协议

Rdt 2.0中引入的新机制

  • 差错控制
  • 接收方反馈控制消息： ACK / NAK
  • 重传

Rdt2.0 : FSM规约

Rdt2.0: 无错误场景

image-20220414200939088

Rdt2.0 : 有错误场景

Rdt2.1 和 Rdt2.2

Rdt2.0有什么缺陷

  • 如果 ACK/NAK消息发生错误/被破坏（conrrupted） 会怎样？

    为 ACK/NAK增加校验和，检错并纠错

    发送方接受到被破坏的ACK/NAK时不知道接收方发生了什么，增加额外的控制消息

    如果ACK/NAK坏掉，发送方重传

    不能简单的重传：产生重复分组

  • 如何解决重复分组的问题？

    序列号（Sequence number）: 发送方给每个分组增加序列号

    接收方丢弃重复分组

Rdt2.2: 无NAK消息协议

  • 与rdt 2.1功能相同，但是只使用ACK
  • 如何实现？
    • 接收方通过ACK告知最后一个被正确接受的分组
    • 在ACK消息中显式地加入被确认分组的序列号
  • 发送方收到重复的ACK后，采取与收到NAK消息相同的动作
    • 重传当前分组

Rdt3.0

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

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

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

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

Rdt3.0示例

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

滑动窗口协议

流水线机制：提高资源利用率

流水线协议

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

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

滑动窗口协议

滑动窗口协议：Sliding-window protocol

窗口

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

滑动窗口

  • 随着协议的运行，窗口在序列号空间内向前滑动

滑动窗口协议： GBN, SR

GBN协议（Go-Back-N 协议）

Go-Back-N(GBN)协议发送方

分组头部包含k-bit序列号

窗口尺寸为N, 最多允许N个分组未确定

ACK(n) : 确认收到序列号n(包含n)的分组均已被正确接受

  • 可能收到重复ACK

为空中的分组设置计时器(timer)

超时Timeout(n)事件：重传序列号大于等于n, 还未收到ACK的所有分组

GBN:发送方扩展FSM

GBN：接收方扩展FSM

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

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

乱序到达的分组：

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

GBN示例

Selective Repeat协议

Selective Repeat协议

  • 接收方对每个分组单独进行确认
    • 设置缓存机制，缓存乱序到达的分组
  • 发送方只重传那些没收到ACK的分组
    • 为每个分组设置定时器
  • 发送方窗口
    • N个连续的序列号
    • 限制已发送未确认的分组

Selective Repeat协议：发送方/接收方窗口

SR协议

SR协议示例

面向连接传输协议—TCP协议

TCP概述

TCP概述： RFCs793, 1122, 1323, 2018, 2581

  • 点对点

    • 一个发送方， 一个接收方

  • 可靠的、按序的字节流

  • 流水线机制

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

  • 发送方，接收方缓存

  • 全双工（full-duplex）

    • 同一连接中能够传输双向数据流

  • 面向连接

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

  • 流量控制机制

TCP段结构

TCP：序列号和ACK

序列号：

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

ACKs:

  • 希望接受到的下一个字节的序列号
  • 累计确认：该字节之前的所有字节均已被正确接受到

Q: 接收方如何处理乱序到达的Segment ?

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

TCP可靠数据传输

TCP可靠数据传输概述

  • TCP在IP层提供的不可靠服务基础上实现可靠数据传输服务
  • 流水线机制
  • 累积确认
  • TCP使用单一重传定时器
  • 触发重传的事件：
    • 超时
    • 收到重复ACK

TCP发送方事件

  • 从应用层收到数据
    • 创建Segment
    • 序列号是Segment第一个字节的编号
    • 开启计时器
    • 设置超时时间（TimeOutInterval）
  • 超时
    • 重传引起超时的Segment
    • 重启计时器
  • 收到ACK
    • 如果确认此前未确认的Segment
      • 更新SendBase
      • 如果窗口中还有未确认的分组，重新启动定时器

TCP重传示例

快速重传机制

  • TCP实现中，如果发生超时，超时的时间间隔将重新设置，即将超时时间间隔加倍，导致其很大
    • 重发丢失的分组之前要等待很长时间
  • 通过重复的ACK检测分组丢失
    • Sender会背靠背地发送多个分组
    • 如果某个分组丢失，可能会引发多个重复的ACK
  • 如果sender收到对同一数据的3个ACK, 则假定该数据之后的段已经丢失
    • 快速重传：在定时器超时之前即进行重传

TCP流量控制

TCP连接管理

TCP sender和receiver在传输数据前需要建立连接

  • 初始化TCP变量

    • Seq. #
    • Buffer和流量控制信息

  • Client: 连接发起者

    1
    Socket clientSocket = new Socket("hostname", "post number");

  • Server: 等待客户连接请求

    1
    Socket connectionSocket = welcomeSocket.accept();

Three way handshake：

Step1: client host sends TCP SYN segment to server.

  • specifies initial seq #
  • no data

Step2: server host receives SYN, replies with SYNACK segment

  • server allocates buffers
  • specifies server initial seq. #

Step3: client receives SYNACK, replies with ACK segment, with may contain data.s

TCP连接管理： 建立

TCP连接管理： 关闭

Closing a connection

client closes socket : clientSocket.close();

Step1: client 向 server 发送 TCP FIN控制segment

Step2: server 收到FIN, 回复ACK, 关闭连接，发送FIN

Step3: client 收到FIN, 回复ACK

  • 进入“等待” – 如果收到的FIN, 会重新发送ACK

Step4: server收到ACK ， 连接关闭

TCP lifecycle

TCP client lifecycle

TCP server lifecycle

拥塞控制原理

拥塞的成因和代价：场景1

  • 两个senders, 两个receivers
  • 一个路由器， 无限缓存
  • 没有重传

  • 拥塞时分组延迟太大
  • 达到最大throughput

拥塞的成因和代价：场景2

  • 一个路由器， 有限的buffers
  • Sender重传分组

拥塞的成因和代价：场景3

拥塞控制的方法

端到端的拥塞控制：

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

网络辅助的拥塞控制：

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

ATM ABR拥塞控制

  • ABR: available bit rate
    • 弹性服务
    • 如果发送方路径 “underloaded”,可以使用带宽
    • 如果发送方数据拥塞，将发送速率降到最低保障速率
  • RM(resource management cells)
    • 发送方发送
    • 交换机设置RM cell位（网络辅助）
      • NI bit: rate 不允许增长
      • CI bit: 拥塞提示
    • RM cell 由接收方返回给发送方

TCP性能分析

传输层总结

传输层服务的基本原理

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

Internet的传输层

  • UDP
  • TCP

拥塞控制

拥塞控制目的

  • 防止过多的数据注入到网络中
  • 避免网络中路由器或链路过载

拥塞控制是一种全局的过程

  • 涉及到所有的主机、路由器
  • 以及降低网络传输性能的所有因素
  • 相比而言，流量控制只是点对点通信的控制

概述

  • 慢开始（slow start)
  • 拥塞避免（congestion avoidance）
  • 快速重传（fast retransmit）
  • 快速恢复（fast recovery）

几个缩写：

  • MSS（Maximum Segment Size）：每个段最大的数据部分大小
    • 在连接建立时确定
  • cwnd（congestion window）：拥塞窗口
  • rwnd （receive window）: 接受窗口
  • swnd（send window）：发送窗口
    • swnd = min(cwnd, rwnd)

慢开始

拥塞避免

  • ssthres(slow start threshold) : 慢开始阈值， cwnd达到阈值，以线性方式增加
  • 拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞
  • 乘法减少：只要网络拥塞，把ssthres减半，与此同时，执行慢开始算法（cwnd又恢复到初始值）

快速重传

接收方：

  • 每收到一个失序的分组立即发出重复确认
  • 使发送方及时知道有分组没有到达
  • 而不要等待自己发送数据时才进行确认

发送方：

  • 只要连续收到三个重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段
  • 而不必继续等待重传计时器到期后再重传

快速恢复

  • 当发送方连续收到三个重复确认时，就执行”乘法减少”算法, 把ssthresh减半
  • 与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值
  • 而是把cwnd值设置成ssthresh减半后的数值
  • 然后开始执行拥塞避免算法（加法增大），使拥塞窗口缓慢地线性增大

建立连接

求大佬赏个饭