计算机网络原理第5章运输层（12.24完结）_计算机网络加权平均往返时间-优快云博客

本文深入探讨了运输层协议，重点讲解了TCP和UDP。TCP提供面向连接的、可靠的字节流服务，而UDP则是无连接的、不可靠的报文传输协议。内容涵盖TCP的端口、连接建立、流量控制和拥塞控制，以及UDP的首部格式和特点。此外，还详细阐述了TCP的可靠传输机制，包括滑动窗口、超时重传和选择确认等策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 端口号 (protocol port number)

4. 往返时间 (RTT) 的测量相当复杂

1. 逐个字符发送情况下TCP传送效率不高的问题

3. 主动队列管理--随机早期检测 RED

5.1 运输层协议概述

5.1.1 进程之间的通信

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。

当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都用到下三层功能。

1. 运输层的作用

TCP与UDP：根据应用程序的不同需求，运输层需要有两种不同的运输协议，即面向连接的 TCP 和无连接的 UDP 。

2. 网络层和运输层有明显的区别

3. 屏蔽作用

5.1.2 运输层的两个主要协议

1. TCP 与 UDP

2. 运输层的作用

基于端口的复用和分用功能

5.1.3 运输层的端口

需要解决的问题：由于进程的创建和撤销都是动态的，发送方几乎无法识别其他机器上的进程。有时我们会改换接收报文的进程，但并不需要通知所有发送方。我们往往需要利用目的主机提供的功能来识别终点，而不需要知道实现这个功能的进程。

1. 端口号 (protocol port number)

2. TCP/IP 运输层端口

端口用一个 16 位端口号进行标志。端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。在互联网中，不同计算机的相同端口号是没有联系的。

由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的 IP 地址（为了找到对方的计算机），而且还要知道对方的端口号（为了找到对方计算机中的应用进程）。

两大类端口：

5.2 用户数据报协议 UDP

5.2.1 UDP 概述

UDP 只在 IP 的数据报服务之上增加了很少一点的功能： 复用和分用的功能、差错检测的功能

虽然 UDP 用户数据报只能提供不可靠的交付，但 UDP 在某些方面有其特殊的优点。

1. UDP的主要特点

2. 面向报文的 UDP

应用程序必须选择合适大小的报文。

若报文太长 UDP 把它交给 IP 层后，IP 层在传送时可能要进行分片，这会降低 IP 层的效率。

若报文太短 UDP 把它交给 IP 层后，会使 IP 数据报的首部相对长度太大，这也降低了 IP 层的效率

5.2.2 UDP 的首部格式

在计算检验和时，临时把“伪首部”和 UDP 用户数据报连接在一起，伪首部是为了计算检验和。

1. 计算 UDP 检验和的例子

2. UDP 基于端口的分用

5.3 传输控制协议 TCP 概述

5.3.1 TCP 最主要的特点

1. TCP 面向流的概念

注意：TCP 连接是一条虚连接而不是一条真正的物理连接。 TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。 TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节

UDP是面向什么的？ UDP 发送的报文长度是应用进程给出的 TCP 可把太长的数据块划分短一些再传送。 TCP 也可等待积累有足够多的字节后再构成报文段发送出去。

5.3.2 TCP 的连接

1. TCP 连接，IP 地址，套接字

课程回顾：

网络层提供的是（主机）之间的通信，运输层提供的是（进程）什么之间的通信？

运输层的端口的作用是什么？（标识应用进程）多少位？（16）

UDP是面向（报文）的，TCP是面向（字节流）的

5.4 可靠传输的工作原理

从物理层和数据链路层考虑哪种情况会导致信道出现数据的丢失？

从网络层考虑哪种情况会导致信道出现数据的丢失？

5.4.1 停止等待协议

1. 无差错情况

2. 出现差错

如何保证 B 正确收到了 M1 呢？

解决方法：超时重传 A 为每一个已发送的分组都设置了一个超时计时器。 A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2 。

3. 确认丢失和确认迟到

4. 停止等待协议

5. 信道利用率

6. 例题

7. 流水线传输

5.4.2 连续 ARQ 协议

1. 累积确认

2. Go-back-N（回退 N）

3. 连续ARQ协议维持的帧序号变化情况

采用连续ARQ协议双向通信的每一端都必须设有两个窗口：一个发送窗口和一个接收窗口。这四个窗口经常处于动态变化之中。

帧序号：NS—发送序号、NR—确认号（接收序号）期望收到的对方发出的分组的发送序号

滑动窗口协议是计算机网络中最著名的算法。它有三个不同的功能。

5.5 TCP 报文段的首部格式

TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用。 TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。TCP 首部的最小长度是 20 字节。

源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。

序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。

确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。

数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。

保留字段——占 6 位，保留为今后使用，但目前应置为 0。

紧急 URG —— 当 URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。

确认 ACK —— 只有当 ACK  1 时确认号字段才有效。当 ACK  0 时，确认号无效。

推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。

复位 RST (ReSeT) —— 当 RST  1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。

同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。

终止 FIN (FINish) —— 用来释放一个连接。FIN  1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。

窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。

检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。

紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。

选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。” MSS (Maximum Segment Size) 是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。所以，MSS是“TCP 报文段长度减去 TCP 首部长度”。

其它选项

填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。

5.6 TCP 可靠传输的实现

5.6.1 以字节为单位的滑动窗口

1. 发送缓存

2. 接收缓存

3. 强调三点

4. TCP报文段的首部格式

5.6.2 超时重传时间的选择

1. TCP 超时重传时间设置

如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大。但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。 TCP 采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。

2. 加权平均往返时间

3. 超时重传时间 RTO

4. 往返时间 (RTT) 的测量相当复杂

5. Karn 算法

在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均往返时间 RTTS 和超时重传时间 RTO 就较准确。但是，这又引起新的问题。当报文段的时延突然增大了很多时，在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据 Karn 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

6. 修正的 Karn 算法

5.6.3 选择确认 SACK

问题：若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的。选择确认 SACK (Selective ACK) 就是一种可行的处理方法。

1. 接收到的字节流序号不连续

5.7 TCP 的流量控制

5.7.1 利用滑动窗口实现流量控制

一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。 流量控制 (flow control) 就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。

1. 利用可变窗口进行流量控制举例

2. 可能发生死锁

3. 持续计时器

TCP 为每一个连接设有一个持续计时器 。只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。若窗口不是零，则死锁的僵局就可以打破了。

5.7.2 TCP 的传输效率

1. 逐个字符发送情况下TCP传送效率不高的问题

2. 解决办法（Nagle算法）

若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。

对于实时性要求较高的应用不宜采用Nagle算法

3. 接收方糊涂窗口综合症

5.8 TCP 的拥塞控制

5.8.1 拥塞控制的一般原理

1. 拥塞常常趋于恶化

实践证明，拥塞控制是很难设计的，因为它是一个动态的（而不是静态的）问题。在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因。这点应特别引起重视。当前网络正朝着高速化的方向发展，这很容易出现缓存不够大而造成分组的丢失。分组的丢失是网络发生拥塞的征兆还是原因？

2. 拥塞控制与流量控制的区别

3. 拥塞控制方法

5.8.2 TCP 的拥塞控制方法

1. 控制拥塞窗口的原则

2. TCP拥塞控制算法

四种（ RFC 5681）：慢开始、拥塞避免、快重传、快恢复

发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。

快重传算法

5.8.3 主动队列管理 AQM

1. “先进先出”FIFO 处理规则

2. 全局同步

3. 主动队列管理--随机早期检测 RED

4. 瞬时队列长度和平均队列长度的区别

5. 随机早期检测 RED

多年的实践证明，RED 的使用效果并不太理想。 2015年公布的 RFC 7567 已经把 RFC 2309列为陈旧的，并且不再推荐使用 RED。对路由器进行主动队列管理 AQM 仍是必要的。 AQM 实际上就是对路由器中的分组排队进行智能管理，而不是简单地把队列的尾部丢弃。现在已经有几种不同的算法来代替旧的 RED，但都还在实验阶段。