文章

计算机网络原理 精讲四 第三章 传输层

计算机网络原理 精讲四 第三章 传输层

计算机网络原理 精讲四 第三章 传输层 1

第一节 传输层的基本服务

1.1. 传输层功能

一、 传输层的核心任务:

应用进程

之间提供端到端的逻辑通信服务。

只有主机才有传输层; 网络核心中的中间系统(路由器/交换机/集线器 等) 只用到下三层的功能。

二、 传输层的功能: ( 吩咐刘墉寻差错-可靠)【选择、简答】

  1. 对应用层报文进行分段和重组;
  2. 面向应用层实现复用与分解
  3. 实现端到端的流量控制
  4. 拥塞控制

    ;

  5. 传输层寻址
  6. 对报文进行差错检测;
  7. 实现进程间的端到端可靠数据传输控制

1.2. 传输层寻址和端口

一、 寻址

单个计算机中, 不同应用进程用进程标识符( 进程 ID) 来区分。

在全网范围内利用“ IP地址+端口号” 唯一标识一个套接字(通信端点)。 应用层和传输层间抽象的协议端口是软件端口。

二、 传输层端口号为 16 位整数, 可以编号 65536 个( 2 的 16 次方)

0——1023熟知端口号 服务器端口号
1024——49151登记端口号 服务器端口号
49152——65535客户端口号,或短暂端口号
端口号描述
20、21FTP文件传输协议端口号
25SMTP简单邮件传输协议端口号
53DNS域名服务器端口号
80HTTP超文本传输协议端口号
110POP3第三版的邮局协议端口号
  1. 服务器端使用的端口号: 熟知端口号和登记端口号
  2. 客户端使用的端口号: 临时性, 在客户进程运行是由操作系统随机选取唯一未被使用的端口号。
  3. 端口号小于 256 的端口为 ***常用端口***

1.3. 无连接服务与面向连接服务 【选择】

无连接服务(UDP)面向连接服务(TCP)
数据传输之前:无需与对端进行任何信 息交换,直接构造传输层报文段并向接 收端发送。数据传输之前︰需要双方交换一些控制信 息,建立逻辑连接,然后再传输数据,传 输结束后还需要拆除连接
类似于 信件/广播 通信类似于 电话 通信

第二节 传输层的复用与分解

2.1. 多路复用与多路分解

支持众多应用进程共用同一个传输层协议, 并能够将接收到的数据准确交付给不同的应用进程, 是传输层需要实现的一项基本功能, 称为传输层的多路复用与多路分解(简称为复用与分解, 也称为为复用与分用)。

一、 多路复用:

在源主机, 传输层协议从不同的套接字收集应用进程发送的数据块, 并为每个数据块封装上首部信息( 包括用于分解的信息) 构成报文段, 然后将报文段传递给网络层。

二、 多路分解:

在接收端, 传输层协议读取报文段中的这些字段, 标识出接收套接字, 进而通过该套接字, 将传输层的报文段中的数据交付给正确的套接字。

2.2. 无连接的多路复用与多路分解

  1. 用户数据报协议(User Datagram Protocol, UDP) :Internet提供无连接服务的传输层协议。
  2. UDP套接字二元组:«font color=’red’ style=’background-color:’ size=’‘>目的IP地址,目的端口号</font>>

image-20230410155744964

2.3. 面向连接的多路复用与多路分解

  1. Internet 传 输 层 提 供 面 向 连 接 服 务 的 是 TCP 。 TCP(Transmission Control Protocol): 传输控制协议)
  2. TCP 套接字四元组: «font color=’red’ style=’background-color:’ size=’‘>源 IP 地址, 源端口号, 目的 IP 地址, 目的端口号</font>>

image-20230410163016522

第三节 停-等协议与滑动窗口协议

3.1. 不可靠传输信道在数据传输中可能发生的错误 【选择】

  1. 比特差错

    : 1001——1000

  2. 乱序

    : 1001——1010

  3. 数据丢失

    : 1001——? ? ? ?

3.2. 基于不可靠信道实现可靠数据传输采取的措施【选择】

  1. 差错检测

    : 利用差错编码实现数据包传输过程中的比特差错检测。

  2. 确认

    : 接收方向发送方反馈接收状态。 ACK( 肯定确认); NAK( 否定确认)

  3. 重传

    : 发送方重新发送接收方没有正确接收的数据。

  4. 序号

    : 确保数据按序提交。

  5. 计时器(超时器)

    : 解决数据丢失问题。

    发现在解决,主要是发现(超时器)

3.3. 停-等协议

一、 停-等协议工作原理图:

自动重传请求协议(Automatic Repeat reQuest,ARQ)

停-等协议工作流程

详细描述:【简答】

  1. 发送方发送经过差错编码和编号的报文段, 等待接收方的确认;
  2. 接收方差错检测无误且序号正确, 则接收报文段, 并向发送方发送 ACK;否则丢弃报文段,并向发送方发送 NAK;
  3. 发送方收到 ACK, 则继续发送后续报文段, 否则重发刚刚发送的报文段。

二、 信道利用率低

停-等协议综合应用了差错检测, 确认, 重传, 序号, 计时器等措施, 简单, 所需缓冲空间小。但是, 信道利用率低。

3.4. 流水线协议

为了解决信道利用率低这个问题, 一个简单的办法是不使用停等协议停止等待运行方式, 允许发送方在没有收到确认前连续发送多个分组, 这就是流水线协议(管道协议)。

发送窗口(W~s~):发送方 可以发送 未被确认分组的

最大数量接收窗口(W~r~):接收方可以缓存的 正确到达 的分组的最大数量

一、 流水线协议实现可靠数据传输需要:

  1. 必须增加分组序号;
  2. 协议的发送方和接收方必须缓存多个分组;

二、 典型的流水线协议: 滑动窗口协议(GBN 协议和 SR 协议 )【选择】

只用ACK

  1. 分组连续编号;
  2. 以流水线方式依次发送分组;
  3. 接收方接收分组, 按分组序号向上有序提交;
  4. 通过确认向发送方通告正确接收的分组序号;
  5. 发送方根据收到的 ACK 的序号以及计时器的, 重新发送或者继续发送新分组。

工作流程图 :

滑动窗口协议

发送方:

  1. 发送窗口 W~s~=5。
  2. 1、 2、 3、 4( 发送窗口左侧) 收到 ACK。
  3. 5、 6、 7、 8、 9( 发送窗口中) 当前可以发送的。
  4. 10、 11、 12( 发送窗口右侧) 当前不可以发送的。

发送窗口内,可能存在的3中状态∶

  1. 已用未被确认序号。
  2. 已用且已被确认序号。
  3. 可用但尚未使用序号。

接收方:

  1. 1、 2、 3、 4、 5、 6( 接收窗口左侧) 正确接收, 并提交给协议用户的序号。
  2. 7、 8、 9 期望接收但未收到的。
  3. 10、 11、 12 暂时不能接收的。

GBN 协议和 SR 协议:

滑动窗口协议根据采用的确认、 计时、 窗口大小等机制的不同, 可以设计不同的滑动窗口。

两种最具代表的滑动窗口协议:

  • 回退 N 步(Go-Back-N,GBN)协议
  • 选择重传(Selective Repeat,SR)协议
  1. 回退 N 步(Go-Back-N,GBN)协议

    【选择】

    image-20230410172651909

    • 发送方(W~s~≥1)缓存能力比较高, 可以在未接到确认前连续发送多个分组。
    • 接收方(W~r~=1)缓存能力很低, 只能接收一个按序到达的分组, 不能缓存未按序到达的分组。
    • 未按序到达的分组丢弃, 并让发送方重传。

    GBN协议:

    • 发送端缓存能力高,可以在没有得到确认前发送多个分组。
    • 接收端缓存能力很低,只能接收1个按序到达的分组,不能缓存未按序到达的分组。

    GBN 发送方必须响应 3 个事件:

    1. 上层调用

      ;

    2. 收到 ACK~n~ (采用累积确认方式)

      即发送方收到ACKn时,表明接收方正确接收序号n以及序号小于n的所有分组;

    3. 计时器超载 (窗口共用一个计时器)
  2. 选择重传(Selective Repeat,SR)协议

    【选择】

    image-20230410173235029

    • 发送方(W~s~≥1)可以在未接到确认前连续发送多个分组。
    • 接收方(W~r~≥1)对每个正确接收的分组进行逐个确认。 让发送方仅重传那些未被确认接收的分组。

    SR协议:

    • 发送端缓存能力高。
    • 接收端缓存能力高。

    SR 发送方主要响应 3 个事件:

    1. 上层调用

      ;

    2. 计时器超时 (每个分组一个计时器)

      ;

    3. 收到ACK~n~ (逐个分组确认)

image-20230410174826656

第四节 用户数据报协议( UDP)

4.1. UDP 特点:【简答】

一、 用户数据协议(User Datagram Protocol UDP):

Ineternet 传输层协议, 提供无连接、 不可靠、 数据报尽力传输服务。

  1. 应用进程更容易控制发送什么数据以及何时发送, 会出现分组的丢失和重复。
  2. 无需建立连接。
  3. 无连接状态。
  4. 首部开销小, 只有 8 个字节(Byte)。

4.2. UDP 数据报结构: 【选择、填空】

image-20230410175526429

  1. UDP 首部四个字段, 每个字段长度都是 2 个字节, 共 8 个字节。
  2. 源端口号和目的端口号

    : 用于 UDP 实现复用和分解

  3. 长度

    : 指示 UDP 报文段中的字节数( 首部和数据的总和)。

  4. 校验和

    : 接收方使用来检测报文段是否出现差错

4.3. UDP 校验和【选择、填空】

一、 UDP 校验和计算规则:

1、 所有参与运算的内容( 包括 UDP 报文段) 二进制按 16 位对齐求和。 2、 求和过程中遇到任何溢出( 即进位) 都被回卷( 即进位与和的最低为再加), 最后得到的和取反码, 就是 UDP 的校验和, 填入 UDP 数据报的校验和字段。 3、 UDP 在生成校验和时, 校验和字段全取 0。

二、 UDP 校验和计算的内容包括 3 部分: UDP 伪首部 (发送时没有,计算校验和才有)、 UDP 首部、 应用数据

  1. UDP 伪首部:

    源 IP 地址、 目的 IP 地址、 协议号: 均是封装对应 UDP 数据报的 IP 分组的对应字段。

    image-20230403193822558

  2. UDP 长度字段: 是该 UDP 数据报的字段, 该字段参与计算两次。

  3. UDP 协议号: 17。

第五节 传输控制协议( TCP)

5.1. 传输控制协议(Transmission Control Protocol ,TCP)

一、 Internet 传输层协议。

提供面向连接、 可靠、 有序、 字节流 传输服务。

  1. 应用进程好似在” 打电话“ 要先建立连接。

  2. 每一条 TCP 连接只有两个端点。

  3. 可靠交付

    : 无差错, 不丢失, 不重复, 按序到达

  4. 全双工通信

    。

    全双工:双向同时 e.g.:电话

    半双工:对讲机

    单工:广播

  5. 面向字节流。 流: 字节序列。 应用程序和 TCP 的交互是一个个数据块, TCP 把他们看做是无结构字节流。

5.2. TCP 报文段结构 【选择、填空】

image-20230411150034201

  1. 源端口号

    字段, 目的端口号字段分别占 16 位。 多路复用/分解来自或送到上层应用的数据。

  2. 序号字段

    、 确认序号字段分别占 32 位。

    • 序号

      字段: TCP 的序号是对每个应用层数据的每个字节进行编号,

    • 确认序号

      字段: 期望从对方接收数据的字节序号, 即该序号对应的字节尚未收到。用asc_seq表示。

  3. 首部长度

    字段占 4 位 (5-15)。 指出 TCP 段的首部长度, 以 ***4 字节*** 为计算单位。

    TCP首部 = 固定首部(20字节) + 选项(0~40字节)
  4. 保留字段

    占 6 位。 保留为今后使用, 目前值为 0。

  5. URG、 ACK、 PSH、 RST、 SYN、 FIN 各占 1 位。 为 *标志位* 字段;各占 1 位, 取值为 0 或 1;

    • 紧急 URG=1, 紧急指针字段有效, 优先传送。

    • 确认 ACK=1, 确认序号字段有效;

      ​ ACK=0 时, 确认序号字段无效。

    • 推送 PSH=1, 尽快将报文段中的数据交付接收应用进程, 不要等缓存满了再交付。

    • 复位 RST=1, TCP 连接出现严重差错, 释放连接, 再重新建立 TCP 连接。

    • 同步 SYN=1, 该 TCP 报文段是一个建立新连接请求控制段或者同意建立新连接的确认段。

    • 终止 FIN=1, TCP 报文段的发送端数据已经发送完毕, 请求释放连接。

  6. 接收窗口

    字段占 16 位。 向对方通告我方接收窗口的大小。实现TCP的流量控制。

  7. 校验和

    字段占 16 位。 校验和字段检验的范围类似于 UDP, 计算方法与 UDP 校验和的 计算方法相同。 TCP 协议号是 6。

  8. 紧急指针

    字段占 16 位。

    URG=1 时, 才有效。 指出在本 TCP 报文段中紧急数据共有多少个字节。

  9. 选项字段

    长度可变, 基本不用。 *最短为 0 字节, 最长为 40 字节*。

    例如: 发送方告诉接收方其缓存能够接收的数据段的最大长度是 MSS 个字节。 【 最大报文段长度( Maximum Segment Size, MSS): 报文段中封装的应用层数据的最大长度。】

  10. 填充字段

    , 取值全为 0, 目的是为了整个首部长度是 4 字节的整倍数。

5.3. TCP 连接管理

image-20230411210838454

一、 TCP 连接管理:

  • 连接建立( 三次握手)
  • 连接拆除( 四次挥手)

以客户端的一个应用进程与服务器上的一个应用进程建立一条 TCP 连接为例。

二、 连接建立: 【选择、填空】

image-20230411152658322

  1. 第一次握手:

    • 客户向服务器发送连接请求段: SYN 报文段: ( SYN=1,seq=x)
      • SYN=1: 建立连接请求控制段
      • seq=x: 表示传输的报文段的第 1 个数据字节的序列号是 x, 并以此序列号代表整个报文段的序号( 补充: sequence number, 序号的意思。)
    • 客户端进入 SYN_SEND( 同步发送)
  2. 第二次握手:

    • 服务器收到 TCP 连接请求段后, 如同意, 则发回确认报文段: ( SYN=1,ACK=1,seq=y, ack_seq=x+1)
      • SYN=1: 同意建立新连接的确认段
      • ACK=1:确认序号字段有效
      • ack_seq=x+1: 表示已经收到了序列号为 x 的报文段, 准备接收序列号为 x+1 的报文段。
      • seq=y: 服务器告诉客户确认报文段的第 1 个数据字节的序列号是 y。
    • 服务器由 LISTEN 进入 SYN_RCVD( 同步收到)
  3. 第三次握手:

    • 只有第三次握手可携带数据。
    • 客户对服务器的 同意连接报文段 进行确认:( ACK=1,seq=x+1,ack_seq=y+1)
      • ACK=1:确认序号字段有效
      • seq=x+1: 客户传输的报文段的第一个数据字节的序列号是 x+1
      • ack_seq=y+1: 客户期望接收服务器序列号为 y+1 的报文段。
    • 当客户发送 ACK 时, 客户端进入 ESTABLISHED 状态;
    • 当服务收到 ACK 后, 也进入 ESTABLISHED 状态;

Tips:tipping_hand_man:: 为什么需要三次握手?

第一次握手:客户发送请求,此时服务器知道客户能发。

第二次握手:服务器发送确认,此时客户知道服务器能发能收。

第三次握手:客户发送确认,此时服务器知道客户能收。

三、 连接拆除:【选择、填空】

image-20230411155020973

  1. 第一次挥手:
    • 客户向服务器发送释放连接报文段: ( FIN=1,seq=u)
      • 首部的 FIN=1: TCP 报文段的发送端数据发送完毕, 请求释放连接。
      • 序号 seq=u: 表示传输的第一个数据字节的序号是 u
    • 客户端状态由 ESTABLISHED 进入 FIN_WAIT_1( 终止等待 1 状态)
  2. 第二次挥手:
    • 服务器向客户发送确认段: ( ACK=1,seq=v,ack_seq=u+1)
      • ACK=1: 标识确认字号段有效。
      • 确认序号 ack_seq=u+1: 表示服务器期望接收客户数据包序号为 u+1 的包
      • 序号 seq=v: 表示服务器传输的第一个数据字节的序号是 v
    • 服务器状态由 ESTABLISHED 进入 CLOSE_WAIT( 关闭等待)
    • 客户端收到 ACK 段后, 由 FIN_WAIT_1 进入 FIN_WAIT_2
  3. 第三次挥手:

    • 服务器向客户发送释放连接报文段: ( FIN=1,ACK=1,seq=w,ack_seq=u+1)
      • FIN=1: 请求释放连接
      • ACK=1: 标识确认字号段有效。
      • 确认序号 ack_seq=u+1: 表示服务器期望接收客户数据包序号为 u+1 的包
      • 序号 seq=w: 表示自己传输的第一个数据字节的序号是 w(v→w表示二次挥手时后面携带数据)
    • 服务器状态由 CLOSE_WAIT 进入 LAST_ACK( 最后确认状态)
  4. 第四次挥手:

    • 客户向服务器发送确认段: ( ACK=1,seq=u+1,ack_seq=w+1)
      • ACK=1: 标识确认字号段有效。
      • 确认序号 ack_seq=w+1: 表示客户期望接收服务器数据包序号为 w+1 的包
      • 序号 seq=u+1: 表示客户传输的第一个数据字节的序号是 u+1
    • 客户端状态由 FIN_WAIT_2 进入 TIME_WAIT, 等待 2MSL 最大段寿命 (Maximum Segment Lifetime ,MSL) 时间, 进入 CLOSED 状态,释放连接
    • 服务器在收到最后一次 ACK 段后, 由 LAST_ACK 进入 CLOSED, 释放连接

5.4. TCP 可靠数据传输 【选择、填空】

可靠:

保证接收方应用进程从缓冲区读出的字节流与发送方发出的字节流是完全一样的。

一、 TCP 实现可靠数据传输服务的工作机制:

  1. 应用数据被分割成 TCP 认为最适合发送的数据块。

    最大报文段长度(Maximum Segment Size , MSS):报文段中封装的应用层数据的最大长度。

    image-20230411222948129

  2. 序号,发送方对发送的数据包进行编号,确保数据按序提交给接收方。

    序号:一个字节占用一个序号。序号字段指的就是一个报文段第一个字节的序号。

    image-20230411223122970

  3. 确认,接收方向发送方反馈接收状态,确认是否正确接收数据。TCP采取累计确认。

  4. 查错检测,利用差错编码实现数据包传输过程中的比特查错检测(甚至纠正)

  5. 重传,发送方重新发送接收方没有正确接收的数据。

  6. 计时器,在发送方引入计时器,解决数据丢失问题。

    计时器超时时间设置:TimeoutInerval=EstimatedRTT+4×DevRTT EstimatedRTT:抽样RTT的加权移动平均值。

    DevRTT:偏差RTT

二、 TCP 生成 ACK 的策略:

  1. 具有所期望序号的报文段按序到达, 所有在期望序号及以前的报文段都已被确认。 TCP延迟发送 ACK, 约 500ms。
  2. 具有所期望序号的报文段按序到达、 且另一个按序报文段在等待 ACK 传输, TCP 接收方立即发送单个累计 ACK, 确认以上两个按序到达报文段。
  3. 拥有序号大于期望序号的失序报文段到达, TCP 接收方立即发送重复 ACK, 只是下一个期望接收字节的序号。
  4. 收到一个报文段, 部分或完全填充接收数据间隔。

5.5. TCP 拥塞控制 【选择、综合 】

一、 拥塞控制:

网络拥塞:太多的主机以太快的速度向网络中发送太多的数据,超出了网络处理能力,导致大量数据分组拥挤在中间设备队列中等待转发,网络性能显著下降的现象。

拥塞控制:通过合理调度、 规范、 调整向网络中发送数据的主机数量、 发送速率、 数据量, 以避免拥塞或消除已发送的拥塞。

拥塞预防策略:预防拥塞发生。流量整形技术,规范主机向网络发送数据的流量。

拥塞消除策略:基于拥塞检测机制,调整主机向网络中发送数据的速率和数量,从而逐渐消除拥塞。

二、 TCP 拥塞控制的算法

image-20230411233326228

包括:

  • 慢启动;
  • 拥塞避免;
  • 快速重传; 快速恢复。

拥塞窗口(CongWin):连接开始,为1MSS 。1个最大报文段长度(Maximum Segment Size , MSS)

阈值(Threshold):临界值

image-20230411232336620

  1. 慢启动

    : 阈值之前的阶段称之为慢启动阶段

    • 慢启动算法:在TCP连接建立时,每经过1个RTT时间,拥塞窗口增大一倍。
  2. 拥塞避免

    : 阈值之后的阶段称之为拥塞避免阶段

    • 拥塞避免算法:当拥塞窗口大于等于阈值时,每经过1个RTT,拥塞窗口的值加1。
  3. 快速重传:

    接收端收到3次重复确认,则推断被重复确认的报文段已经丢失,于是立即发送被重复确认的报文段。

    快速恢复算法

    : 当发生快速重传时, 不再从慢启动阶段开始, 而是直接从新的阈值开始,直接进拥塞避免阶段。

    image-20230412232347375

    • 新阈值(12) = 当前窗口(24)的一半;
    • 新拥塞窗口 = 新阈值。
  4. 计时器超时

    : 可判定发生拥塞且拥塞严重

    • 新的阈值:为当前拥塞窗口的一半。 新的阈值 = 24MSS÷2=12MSS
    • 新的拥塞窗口:直接调整为 1MSS。 新的拥塞窗口=1MSS
    • 然后再从慢启动阶段、 拥塞避免阶段增加窗口数量。

三、 窗口调整的基本策略 AIMD (Additive Increase,Multiplicative Decrease,AIMD):

网络未发生拥塞时, 逐渐“ 加性” 增大窗口。

网络拥塞时“ 乘性” 快速减小窗口大小。

5.6. TCP 流量控制 【选择、填空】

一、 流量控制:

是协调发送方与接收方的数据发送与接收速度。

在通信过程中, 接收方设置报文段的接收窗口字段来将窗口大小通知给发送方。

image-20230411230039588

课后习题:

主机A向主机B连续发送了两个TCP报文段,其字节序号分别为50和80。假设此前发送的数据报已正确接收,请回答下列问题:

(1)第一个报文段携带了多少个字节的数据?

(2)主机B收到第一个报文段后发回的确认号是多少?

(3)如果主机B收到第二个报文段后发回的确认号是160,试问A发送的第二个报文段中的数据有多少字节?

(4)如果A发送的第一个报文段丢失,但第二个报文段到达了B。B在第二个报文段到达后向A发送确认。试问这个确认号应为多少?

答:

image-20230412180817264

(1)第一个报文段携带了30个字节的数据。

(2)主机B收到第一个报文段后发回的确认号是80。

(3)A发送的第二个报文段中的数据有80字节。

(4)向A发送的确认号为50。

image-20230411233101661

本文由作者按照 CC BY 4.0 进行授权