【计算机网络】第五章 运输层

第五层 网络层

5.1 运输层协议概述

5.1.1 进程之间的通信

端到端之间的通信----进程和进程之间的通信

运输层提供应用进程之间的逻辑通信

---

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

• 网络层是为主机之间提供逻辑通信

• 运输层是为应用进程之间提供端到端的逻辑通信

---

运输层的作用：

一台主机中的多个应用进程同时分别和另一台主机中多个应用进程通信

复用和分用：根据应用程序的不同需求，分为两种不同的运输协议：面向连接TCP和无连接的UDP

运输层向高层用户屏蔽了下面网络核心的细节，它使进程看到的好像是两个运输层实体之间有一条端到端的逻辑通信信道。

5.1.2 运输层的两个主要协议

面向连接的TCP协议：通信之前需要交流，判断是否可以通信，参数是否匹配，如果可以的话，就发送数据，相当于一条全双工的可靠信道

无连接的UDP协议：不可靠，效率快

---

UDP：一种无连接协议

• 无连接服务
• 传送数据之前不需要先建立连接
• 传送的数据单位协议是UDP报文或用户数据报
• 对方的运输层收到UDP报文后，不需要给出任何确认
• 不提供可靠交付，但再某些情况下UDP是一种最有用的工作方式

TCP：一种面向连接的协议

• 提供面向连接的服务
• 传送的数据单位协议是TCP报文段
• TCP不提供广播或多播服务
• TCP要提供可靠的、面向连接的运输服务，因不可避免地增加了许多的开销。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。

---

UDP用户数据报与IP数据报的区别

• IP数据报要经过互联网中许多路由器的转发
• UDP用户数据报是在运输层的端到端抽象的逻辑信道中传送的

TCP报文段是在运输层抽象的端到端信道中传送，这种信道是可靠的全双工信道，但这样的信道却不知到究竟经过了哪些路由器，而这些路由器也根本不知道上面的运输层是否建立了TCO连接

5.1.3 运输层的端口

端口号（16位）

端口号只有本地意义，即端口号只是为了标志本计算机应用层中各进程

IP地址去找其他主机，端口号是为了找到对应的应用进程

---

服务器端使用的端口号

• 熟知端口：0~1023（常规的应用协议）
• 登记端口：1024~49151（可能某个应用程序常用的应用协议，申请一个端口）

客户端使用的端口号

• 短暂端口号：49152~65535（要用就给，用完就收）

5.2 用户数据报协议UDP

5.2.1 UDP概述

5.2.2 UDP的首部格式

(1)源端口 源端口号。在需要对方回信时选用。不需要时可用全

(2) 目的端口 目的端口号。这在终点交付报文时必须使用。

(3) 长度 UDP 用户数据报的长度，其最小值是 仅有首部。

(4) 检验和 检测 UDP 用户数据报在传输中是否有错。有错就丢弃。

检验和找不到是谁发出来的 ，所以要带IP地址；

在计算校验和时，临时把“伪首部”和UDP用户数据报连接在一起，伪首部仅仅是为了计算校验和，用了就丢弃

计算略

5.3 传输控制协议TCP概述

5.3.1 TCP最主要的特点

• 面向连接的运输层协议

• 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的

• 提供可靠交付

• 提供全双工通信

• 面向字节流

  "流"指的是流入或流出进程的字节序列

  “面向字节流”：虽然应用程序和 TCP 的交互是一次一个数据块(大小不等)，但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

  TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系(例如，发送方应用程序交给发送方的 TCP 10 个数据块，但 接收方的 TCP 可能只用了 个数据块就把收到的字节流交付上层的应用程序)。但接收方应 用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。

  

  大小不同，顺序也会不同，但有序号，接收方TCP会将报文段排序后再发送给应用进程

---

• TCP连接是一条虚连接(也就是逻辑连接)，而不是一条真正的物理连接（除了物理层是真真的物理连接，其他都是逻辑连接）
• TCP 并不关心应用进程一次把多长的报文发送到 TCP 的缓存中
• TCP是根据对方给出的窗口值（接收方当前状态）和当前网络拥塞的程度来决定一个报文段应包含多少个字节 (UDP 发送的报文长度是应用进程给出的)
• TCP可把太长的数据块划分短一些再传送
• TCP 可以等待积累有足够多的宇节后再构成报文段发送出去

5.3.2 TCP的连接

TCP把连接作为最基本的抽象；后面所有的分析都是基于TCP已经连接的前提下。

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

TCP连接的端点叫做套接字scoket（端口号拼接到IP地址）或插口

套接字 scoket = （IP地址：端口号）

每一条TCP连接唯一地被通信两端的两个端点所确定：

TCP连接：：={scoket1，socket2} = ）= {（IP1：port1）,（IP2：port2）}

5.4 可靠传输的工作原理

理想的传输条件下有以下两个特点：

• 传输信道不产生差错
• 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据

5.4.1 停止等待协议

停等协议：每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

---

1 无差错情况

A是发送方，B是接收方

---

2 出现差错

在接受方出现以下两种情况：

• B接收M1时检测出了差错，就丢弃M1，其他啥也不做
• M1在传输过程中丢失了，这时B也啥都不知道，啥也不做

A的解决方法：超时重传

• A为每一个已发送的分组都设置一个超时计时器
• A只要在超时计时器到期之前收到相应的确认，就撤销该超时计时器，继续发送下一个分组M2

---

3 确认丢失和确认迟到

发送方和接收方对重复的信息都是丢弃的

注意：

• 发送往一个分组后，必须保留已发送的分组的副本，以备重发
• 分组和确认分组都必须进行编号
• 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一点（需要计算）

---

4 信道利用率

$$U=TD/(TD+RTT+TA)$$
流水线传输

出现问题：如果出现发送方的某个分组没有收到回复。

5.4.2 连续ARQ协议

发送方有个发送窗口，它的意义是:位于发送窗口内的 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。

接收方的接收窗口（通过将所有序号排好序后，一起发送给应用层）通过累积确认回应发送方，对按序排列的最后一个分组发送确认（表示到这个分组为止的所有分组都已经正确收到）

优点是：容易实现，即使确认丢失也不必重传。

缺点是：不能向发送方反映出接收方已经正确收到的所有分组的信息。

GO-back_N（回退N），表示需要再退回来重传已发送的N组（就是我收到分组中间的其中一个分组，就需要将该分组之后的所有分组重新发送一遍）

---

TCP的可靠传输机制用字节的序号进行控制

TCP所有的确认都是基于序号而不是基于报文段

TCP两端的四个窗口经常处于动态变化之中

TCP连接的往返时间RTT也不是固定不变的；需要使用特定的算法估算较为合理的重传时间

5.5. TCP报文段的首部格式

TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加 的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。

• 源端口和目的端口（各占2个字节）：端口是运输层于应用层服务接口；运输层的复用和分用功能都要通过端口才能实现。

• 序号（4字节）：（一开始所有数据都排好序的）本报文段数据的首序号

  前面报文段是（1-5）,该报文段是从（6-10）那么本报文段的序号是6

• 确认号（4字节）：是期望收到对方下一报文段的第一个数据字节的序号

  同一个报文中，序号和确认号是没有关系的

  A->B：（x->y）序号（x）；确认号（n）

  （回复）B->A：序号（n）；确认号（y + 1）

• 数据偏移（4位）：数据从哪（在TCP报文段的数据起始处）开始；

• 保留（4位）

• 标志位

• • URG：1-紧急指针有用；0-紧急指针没用
  • ACK：1-确认号有效；0-确认号无效（第一次发送数据，不需要确认）
  • PSH：1-将缓存中所有数据推给上层；0-需要等待整个缓存都填满了再交付
  • RST：1-连接中出现差错；必须要释放连接，然后重新建立运输连接
  • SYN：1-表示我正在请求连接（数据无意义）
  • FIN：1-表明词报文段的发送端数据已发送完毕，比要求释放运输连接

• 窗口（16位）：此刻接收窗口的大小（保证接收端可以完全收到数据）

• 检验和（16位）：加上12字节的伪首部（包括IP地址）

• 紧急指针（16位）：对应报文段中有紧急数据大小，应尽快传送（紧急数据放在本报文段数据的最前面）

• 选项（长度可变）：MSS 是每一个 TCP 报文段中的数据字段的最大长度。

• 填充：一定要保证4个字节为基本单位

5.6 TCP可靠传输的实现

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

假设A收到B发来的确认报文段，其中窗口是20字节，而确认号是31（表明B期望收到的下一个序号是31，而序号30为止的数据已经收到了）根据这两个数据，A构造出发送的数据

---

注意：TCP标准强烈不赞成发送窗口前沿向后收缩

• 已经发送的数据，只能在收到回复的时候才能移除窗口，反之必须留在窗口中
• 如果接受方没有收到32序号的数据，而且在A的重传时间已经过了，那么A中的数据就会重传到32再发送
• 如果A窗口中序号全部发送了但未收到回复，会停止发送，直到有数据出去，才会有数据进来，去发送
• 如果B窗口变大的，A窗口也会变大；如果B窗口变小，A窗口的右边缘不会后退，它的前边缘会根据回复，慢慢变小匹配相应的窗口大小

---

• A的窗口并不总是和B的接收窗口一样大（时间滞后）
• TCP标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付给上层的应用进层
• TCP要求接收方必须有累计确认的功能

---

接收方可以再合适的时候发送确认，也可以再自己有数据要发送的时候把确认信息顺便捎带上。

注意两点：

• 接受方不应过分推迟发送确认，否则会导致发送方不必要的重传
• 捎带确认实际上并不经常发生

5.6.2 超时重传时间的选择

TCP采用一种自适应算法；它记录一个报文段发出的时间，以及收到相应的确认的时间。

这两个时间差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTT_s（(这又称为平滑的往返时间， 表示 Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）

每当第一次测量到 RTT 样本时， RTT 值就取为所测量到的 RTT 样本值。但以后每测量到一个新的 RTT 样本，就按下式重新计算一次RTT_s：

新的 RTT_s = (1 - α) x (旧的 RTT_s+α × (新的 RTT 样本)

α->0：RTT值更新较慢；α->1：RTT更新很快。

标准的RFC6289推荐的α的值为0.125

RTO（超时重传时间）=RTT_s + 4 ×RTT_D（RTT的偏差的加权平均值）（在标准的RFC6289下）

RFC6298 建议这样计算 RTT_D。当第一次测量时 RTT_D值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTT_D：

新的 RTT_D= (1- β) x (旧的 RTT_D+ β x I|RTT_s 一新的 RTT 样本 |

推荐值是0.25

计算的算法（略）

5.6.3 选择确认SACK

选择确认：收到了那些数据就确认那些数据，发送方将缺失的数据再发一遍

使用这个功能需要两方有个沟通，表明使用这个协议

使用字节边界确认数据是否丢失；一般不使用，

5.7 TCP的流量控制

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

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

TCP 的窗口单位是字节，不是报文段。

问题：A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

为了解决这个问题，TCP为每一个连接设有一个持续计时器；

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

如果B刚好可以接收一个字节，那这样一个一个字节的传输效率太低了，我们一般也不会只发送一个字节；会发多个字节

TCP 规定，即使设置为零窗口，也必须接收以 几种报文段 零窗口探测报文段、确认报文段和携带紧急数据的报文段。

5.7.2 TCP的传输效率（略37开始）

使用不同机制来控制TCP报文段的发送时机：

• TCP维持一个变量，它等于最大报文段长度MSS；只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去
• 由发送方的应用进程指明要求发送报文段，即TCP支持的推送（push）操作
• 发送方的一个计时器期限到了，这时就把当前已有的缓冲数据装入报文段（但长度不能超过MSS）发送出去

---

发送方糊涂窗口综合症：一个字节效率太低；使用Nagle算法解决

5.8 TCP的拥塞控制

5.8.1 拥塞控制的一般原理

拥塞：在某段时间，若对网络中某资源的需求超过了该资源（带宽，交换结点中缓存和处理机等）所能提供的可用部分，网络的性能就要变坏，整个网络的吞吐量将随输入负荷的增大而下降。

出现拥塞的原因：对资源需求的总和大于可用资源

---

增加资源不能解决拥塞，而且可能使网络的性能更坏；因为网络拥塞是由许多因素引起的，例如：增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞，反而加剧了拥塞；提高处理机处理的速率会将瓶颈转移到其他地方等。要整体性提升资源，可能会改善网络拥塞。

---

拥塞控制就是防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。

拥塞控制所需要做的都有一个前提，就似乎网络能够承受现有的网络负荷。

流量控制是点对点通信量的控制，只是接收端和发送端之间；而拥塞控制是全局性的控制。

---

---

如果出现分组丢失，我们 就将其判定为网络发生拥塞的征兆而不是原因；

这样我们就可以尽早的做出反应，使其不会出现死锁的情况

---

检测网络拥塞的指标：

• 由于缺少缓存空间而被丢弃的分组的百分数
• 平均队长度
• 超时重传的分组数
• 平均分组时延
• 分组时延的标准差

这些指标的上升即拥塞的增长

5.8.2 TCP的拥塞控制方法（重点）

TCP采用基于窗口的方法进行拥塞控制,该方法属于闭环控制方法

TCP发送方维持一个拥塞窗口CWND：

• 拥塞窗口的大小取决于网络的拥塞程度，并动态变化
• 发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量
• 发送窗口大小不仅取决于接收方公告的接收窗口值，还取决于网络的拥塞状况

真正的发送窗口值=Min（公告窗口值，拥塞窗口值cwnd）

---

那么拥塞窗口值如何计算？

控制拥塞窗口的原则

• 只要网络没有出现拥塞，拥塞窗口就可以在增大一些，提高利用率
• 只要出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一点，以便缓解拥塞

---

拥塞的判断

• 重传定时器超时

  传输质量一般都很好，出现传输出差错而丢失分组的概率很小，所以只要出现超时，就猜测可能出现拥塞

• 收到三个同 时（重复）的ACK

  个别报文段会在网络中丢失，预示可能出现拥塞（实际为发生拥塞），因此可以尽快采取控制措施，避免拥塞。

  例：

  一个报文段，如果发送五个序列，接收方没有收到2，但其他都收到，后面3，4，5收到返回的都是2，这样收到三个重复的ack，就会判断是可能出现拥塞

---

TCP控制算法

四种：

• 慢开始（两个判断都有）：一开始cwmd=1，第一轮次就发送一个报文段
• 拥塞避免（两个判断都有）
• 快重传（只有2有）
• 快恢复（只有2有）

---

分析下面的图：

• 从1开始，每经过一个轮次就翻倍以此cwnd，直到ssthresh（慢开始门限）
• 接着使用拥塞避免算法，一个轮次增加一个cwnd，如果碰到超时，就会判断网络出现了拥塞，就把拥塞窗口调到cwnd=1，还会把ssthresh调整成 原cwnd/2；再接这使用慢开始算法
• 使用慢方法继续，接着转成拥塞避免算法，如果碰到3-ACK时，使用快恢复算法，并调整门限ssthresh=cwnd/2，并同时设置cwnd=ssthresh，开始拥塞避免算法

5.8.3 主动队列管理AQM

路由器的到达队列划分为三个区域

如果到达的分组速度太快了，那么路由器就会随机丢弃一些分组，

5.9 TCP的运输连接管理

运输连接的三个阶段：

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

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

5.9.1 TCP的连接建立

连接建立的过程中要解决的三个问题：

• 确认对方存在
• 双方协商一些参数（最大窗口值，是否使用窗口扩大选项和时间戳选项以及服务质量）
• 对运输实体资源进行分配（缓存大小、连接表中的项目等）

---

TCP建立连接的过程叫做握手

握手需要客户和服务器之间交换三个TCP报文段（三次握手）

采用三次握手的目的：防止已失效的连接请求报文段突然又传送到，因而产生错误

SYN建立连接信号，A发送建立连接信号，B回复并发送建立连接型号，A回复信号

5.9.2 TCP的连接释放

数据传输结束后，通信的双方都可以释放连接

TCP连接释放过程是报四文握手

如果最后一个回复丢失了，B是有超时计时器，未收到回复，就会重新发送关闭请求（FIN），A也会在发送回复后，设置一个2MSL时间的等待时间来接收请求。

5.9.3 TCP的有限状态机

有限状态机：有限个状态的机制

下面是一个闭环的系统

了解一下即可