计算机网络 第五章

运输层

运输层协议概述

进程之间的通信

概念

运输层属于面向通信部分的最高层,也是用户功能中的最底层

网络层提供了主机间的逻辑通信,运输层为应用进程间提供了逻辑通信(端到端)

image-20210521100354334

作用

基于端口的复用分用

  • 复用 :发送方的不同应用进程使用同一个运输层协议
  • 分用 :接收方的运输层把数据正确交付给目的进程
image-20210521100912854 image-20210521101551553

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

可靠信道的含义:无差错、按序(接收和发送的顺序)、无丢失、无重复

不可靠的含义:不保证交付。接收时不按序、可能出现丢失和重复

运输层的两个主要协议

  • 用户数据报协议 UDP (User Datagram Protocol)
  • 传输控制协议 TCP (Transmission Control Protocol)

运输层的端口

为了使不同操作系统的进程能够相互通信,必须用统一的方法对应用进程进行标志

端口就是运输层服务访问点 TSAP,运输层的复用和分用功能依赖端口来完成。

端口号(Protocol port number):16 位二进制数,只具有本地意义

如何找进程?IP 地址 + 端口号

服务器端使用的端口号

  • 熟知端口:0-1023,所有用户进程都知道

  • 登记端口号:1024-49151,需要在 IANA 登记,以防重复

客户端使用的端口号

  • 短暂端口号:49152-65535,,留给客户进程选择暂时使用

常用的熟知端口

image-20210521104008609

用户数据报协议 UDP

概述

定义

UDP 只在 IP 的数据报服务之上增加了很少一点的功能

  • 复用和分用的功能
  • 差错检测的功能

主要特点

  • 无连接,发送数据之前不需要建立连接,因此减少了开销和发送数据之前的时延。
  • 尽最大努力交付, 即不保证可靠交付, 因此主机不需要维持复杂的连接状态表。
  • 面向报文。 UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。
  • 没有拥塞控制, 因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用 IP 电话、视频会议是很重要的。
  • 支持一对一、一对多、多对一和多对多的交互通信
  • 首部开销小, 只有 8 个字节,比 TCP 的 20 个字节的首部要短

首部格式

UDP 有两个字段 :数据字段和首部字段。首部字段很简单,只有 8 个字节

首部字段 4 个字段组成,每个字段都是 2 个字节:源端口、目的端口、长度、校验和

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

image-20210521110642286

校验和

IP 的校验和只校验了 IP 数据报的首部;

UDP 的校验和,检查了:

  • UDP 数据报的源端口、目的端口;
  • UDP 数据报的数据部分;
  • IP 数据报的源地址和目的地址。

校验方法:与伪首部、数据一起计算二进制反码校验和,循环进位,最后取反。(不要求)

队列工作原理

image-20210521112429224 image-20210521112442679

传输控制协议 TCP

最主要的特点

  • 面向连接
  • 每一条 TCP 连接只能有两个端点 (endpoint),每一条 TCP 连接只能是点对点的(一对一)。
  • 提供可靠交付的服务。数据无差错、不丢失、不重复,并且按序到达。
  • 全双工通信
  • 面向字节流
    • TCP 中的 “流 ”(stream)指的是流入或流出进程的字节序列。
    • “面向字节流” 的含义是:虽然应用程序和 TCP 的交互是一次一个数据块(大小不等),但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流
    • TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系 。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样

首部格式

见 5.5

连接

TCP 把连接作为最基本的抽象。每一条 TCP 连接有两个 点。

TCP 连接的端点不是主机,不是主机的 IP 地址,不是应用进程,也不是运输层的协议端口。

TCP 连接的端点叫做套接字 (socket) 或插口

端口号拼接到 (contatenated with) IP 地址即构成了套接字。

套接字

TCP 连接就是由协议软件所提供的一种抽象。

TCP 连接的端点是个很抽象的套接字,即( IP 地址:端口号)

同一个 IP 地址可以有多个不同的 TCP 连接

同一个端口号也可以出现在多个不同的 TCP 连接中

image-20210521113007056

可靠传输的工作原理

停止等待协议

发送完一个分组就停止发送等待确认,一旦出现传输差错(检测差错被丢弃或丢失),则超时重传

出现差错的情况

image-20210525080836574 image-20210525080903556

确认丢失、确认迟到

确认丢失:B 向 A 发送的确认丢失了

A (在超时计时器到期后)重传,B 丢弃这个重传的分组,并向 A 再次发送确认

确认迟到:B 向 A 发送的确认迟到了

A (在超时计时器到期后)重传后收到迟到的确认,将其丢弃,B 丢弃这个重传的分组,并再次确认

image-20210525081418702

注意

在发送完一个分组后,必须暂时保留已发送的分组的副本,以备重发。

分组和确认分组都必须进行编号。

超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

自动重传请求 ARQ

(Automatic Repeat reQuest)

重传的请求是自动进行的,接收方不需要请求发送方重传某个出错的分组

使用这样的确认和重传机制,就可以在不可靠的传输网络上实现可靠通信

信道利用率

image-20210525081826275

信道利用率 $U=\frac{T_D}{T_D+RTT+T_A}$

流水线运输

发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送

由于信道上一直有数据不间断地传送,这种传输方式可获得很高的信道利用率。

image-20210525081956712

连续 ARQ 协议

发送方维持一个发送窗口

  • 位于发送窗口内的分组都可连续发送出去,而不需要等待对方的确认。这样,信道利用率就提高了 。
  • 连续 ARQ 协议规定,发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置
image-20210525082113678 image-20210525082221129 image-20210525082659084

上图没有用到累计确认

累计确认

接收方一般采用累计确认的方式,即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,表示这个分组之前的所有分组都已正确收到了

  • 优点:容易实现,即使确认丢失也不必重传(因为后续确认已经发送)
  • 缺点:不能向发送方反映所有正确收到的分组(回退),序号位数多,重传代价高

Go back N (回退 N)

如果发送方发送了前 5 个分组,而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次。

这就是回退 N,表示需要再退回来重传已发送过的 N 个分组

可见当通信线路质量不好时,连续 ARQ 协议会带来负面的影响。

不缓存失序的分组

步骤

发送端:

  • 在发送完一个分组后,不是停下来等待确认分组,而是可以连续再发送若干个分组。
  • 如果这时收到了接收端发来的确认,那么还可以接着发送分组。
  • 如果在超时时间到时,仍然没有收到相应分组的确认,则重新从这个分组开始传起 (Go back N) 。

接收端:只按序接收分组

  • 当接收到一个有差错的分组时,丢弃该分组和它以后的所有分组,让它们在发送端超时,然后重复发送已发送过的最后一个确认分组。

发送窗口的最大值

当用 n 比特进行分组的编号时,接收窗口 W~R~ = 1;只有在发送窗口 $W_T \le 2^n - 1$ 时,连续 ARQ 协议才能正确运行

例:当 n = 3 时,发送窗口的最大值是 7 而不是 8

用反例证明:

若发送窗口大小为 8 ,则分组编号为 0 - 7

  • 状态 1: 所有确认分组都到达了发送端,此时发送端又发送 8 个新分组,编号为 0~7 ,接收端认为是新分组
  • 状态 2: 所有确认分组丢失,发送端超时后重发 0~7 号分组,接收端同样将其当作新分组接收(实际是重传的旧分组)。

小窗口 ARQ 信道利用率 $U=\frac{n\times T_D}{T_D+RTT+T_A}$ ,大窗口信道利用率为 1

通常连续 ARQ 的接收窗口大小 Wr 为 1

选择重传 ARQ 协议

连续 ARQ 协议的问题 :当线路的出错率高时,将出错帧之后的所有帧都丢弃掉,重传这些帧会带来效率上的大幅度降低。

加大接收窗口 ,使得 W~R~ > 1 。先收下发送序号不连续但仍处在接收窗口中的那些数据帧。等到所缺序号的数据帧收到后再一并送交主机。这就是选择重传 ARQ 协议 。

接收窗口的尺寸不能超过 2^n-1^ (即序号范围的 1/2 ),否则可能造成帧的重叠。发送窗口的尺寸一般和接收窗口的尺寸相同。

优点 :避免重复传送那些本来已经正确到达接收端的数据帧。

TCP 报文段的首部格式

前 20 位固定字节 + 4n 字节可选项

https://markdown-1303167219.cos.ap-shanghai.myqcloud.com/image-20210525093030395.png

  • 源端口和目的端口字段
    • 各占 2 字节。
    • 端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。
  • 序号字段 seq
    • 占 4 字节。
    • TCP 连接中传送的数据流中的每一个字节都编上一个序号。
    • 序号字段的值则指的是本报文段所发送的数据的第一个字节的序号
  • 确认号字段 ack
    • 占 4 字节
    • 是期望收到对方的下一个报文段的数据的第一个字节的序号。
    • 若确认号 = N,表明:到序号 N - 1 为止的所有数据都已正确收到
    • image-20210525093635796

以下字段了解即可

  • 数据偏移(即首部长度)
    • 占 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 个字节。”
  • 填充字段
    • 这是为了使整个首部长度是 4 字节的整数倍。

TCP 的运输连接管理

TCP 是面向连接的协议

运输连接有三个阶段

  • 连接建立
  • 数据传送
  • 连接释放

运输连接有三个问题

  • 每一方要能够确知对方存在
  • 允许协商参数
  • 能够对运输实体资源进行分配

采用方式:客户-服务器方式

运输连接的管理就是使运输连接的建立和释放都能正常地进行

TCP 连接的建立

三报文握手

image-20210528101829778
  • 客户:同步 SYN=1,seq=x
  • 服务器:SYN=1,ACK=1,seq=y,ack=x+1
  • 客户:ACK=1,seq=x+1,ack=y+1

作用:防止已经失效的连接请求报文突然又传送到了

TCP 的连接释放

四报文握手

image-20210528102538934
  • 客户:FIN=1,seq=u
  • 服务器:ACK=1,seq=v,ack=u+1

服务器单向数据传送

  • 服务器:FIN=1,ACK=1,seq=w,ack=u+1
  • 客户:ACK=1,seq=u+1,ack=w+1

TCP 连接必须经过两倍**最长报文段寿命(MSL)**后才真正释放

为了保证 A 的 ACK 报文到达 B,并防止已失效的连接请求已经消失

TCP 可靠传输的实现

TCP 在不可靠的 IP 服务上建立可靠的数据传输

接收方

  • 累计确认,仅在正确按序收到报文段后,跟新确认序号;其余情况,重复前一次的确认序号
  • 失序报文处理:缓存失序的报文段

发送方

  • 发送策略:流水线
  • 定时器:仅对最早那个未确认报文段使用重传计时器
  • 重发策略:仅在超时后重发最早未确认的报文段

以字节为单位的滑动窗口

步骤

image-20210528112528322 image-20210528112552091 image-20210528113009796 image-20210528113024551 image-20210528113035499

发送缓存与接收缓存的作用

发送缓存用来暂时存放:

  • 发送应用程序传送给发送方 TCP 准备发送的数据;
  • TCP 已发送出但尚未收到确认的数据。

接收缓存用来暂时存放:

  • 按序到达的、但尚未被接收应用程序读取的数据;
  • 不按序到达的数据。
image-20210528113050027 image-20210528113101178

超时重传时间的选择

不考

选择确认 SACK

不考

快速重传?

总结

GBN、SR、TCP 的区别

  • GBN:回退 N (go back N),如果某个报文段没有被正确的接收,那么从这个报文段到后面的报文段都要重新发送,返回的 ACK 采用剋及确认的机制,也就是说如果 GBN 返回的 ACK=3,也就是说 3 报文段和 3 之前的报文段都被正确地接收了

  • SR:接收方设置缓冲区,为每个报文段设置计时器,如果某个报文段没有被正确接收但是后面的报文段被正确接收了,那么就只需要重发这一个报文段,在接收方整理排序之后就?了,返回的 ACK 就是当前接收成功的报文段序号

  • TCP:和 SR 类似,但是 TCP 有快速重传机制,不需要等待某个报文段的计时器超时才能重传,返回的 ACK 编号是期待接收到的下一个报文的序号

TCP 的流量控制

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

接收方通过控制窗口大小来间接地控制发送速率

流量控制(flow control)就是让发送方的发送速率不要太快,既要让接收方来得及接收,也不要使网络发生拥塞

利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。

接收方动态地调整自己的窗口大小,通过 rwnd 字段通知发送方。

举例

https://markdown-1303167219.cos.ap-shanghai.myqcloud.com/image-20210601083459056.png

死锁

了解

B 向 A 发送了零窗口的报文段后不久, B 的接收缓存又有了一些存储空间 。于是 B 向 A 发送了 rwnd = 400 的 报文段 。

但这个报文段在传送过程中丢失了,A 一直等待收到 B 发送 的非零窗口的通知, 而 B 也一直等待 A 发送的数据

如果没有其他措施,这种互相等待的死锁局面将一直延续下去 。

为了解决这个问题, TCP 为每一个连接设有一个持续计时器(persistence)

TCP 的拥塞控制

拥塞控制的一般原理

在某段时间,若对网络中某资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种现象称为拥塞(congestion) 。

若网络中有许多资源同时产生拥塞,网络的性能就要明显变坏,整个网络的吞吐量将随输入负荷的增大而下降 。

出现拥塞的原因:∑ 对资源需求 > 可用资源

拥塞常常趋于恶化,并使网络性能变坏。

拥塞控制设计全部主机路由器,而流量控制只关注某一条链路

拥塞控制的常用方法

  • 网络辅助的拥塞控制
    • 路由器
  • 端到端拥塞控制
    • TCP 采用的方式,端系统自行推断拥塞的产生

TCP 的拥塞控制方法

发送方如何感知拥塞

拥塞造成丢包和分组延迟增大,发送方丢过丢包时间来判断拥塞

  1. 重传定时器超时
  2. 收到三个相同(重复)的 ACK

发送方采用什么机制限制发送速率?

发送方维持一个拥塞窗口 cwnd 来限制发送窗口,从而间接控制发送速度

拥塞窗口动态变化,取决于网络的拥塞程度

调节策略:AIMD 拥塞避免
  • 乘法减小
    • 发送包检测到丢包后,cwnd 大小减半
  • 加法增大
    • 若无丢包,每经过一个 RTT,将 cwnd 增大一个 MSS,直到检测到丢包
慢开始/慢启动

在新建连接上指数增大 cwnd,直到检测到丢包

设置慢开始门限状态变量 ssthresh

当 cwnd < ssthresh 时,使用慢开始算法。

当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。

当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法

当遇到丢包时,ssthresh 变为当前 cwnd 的一半

区分不同的丢包事件
  • 超时:网络交付能力差

    • cwnd 直接降到初始值,然后指数增大
  • 收到重复三个 ACK:网络仍有一定交付能力

    • cwnd 减半,然后加法增大,是为快重传、快恢复

https://markdown-1303167219.cos.ap-shanghai.myqcloud.com/image-20210601093117995.png