一、传输层概述

1、基本概念

• 物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的的问题，实现了主机到主机的通信

• 实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程

• 为运行在不同主机上的应用进程提供直接的通信服务是传输层的任务

• 传输层协议又称端到端协议

2、传输层的功能

（1）应用进程之间的通信

（2）复用和分用

• 复用：发送方不同的应用进程都可以使用同一传输层协议传输数据

• 分用：接收方的传输层在剥去报文的首部之后能够把这些数据正确交付到目的应用进程

• 注意：
• 网络层的复用：发送方不同协议的数据都可被封装成 IP 数据报发送出去
• 网络层的分用：接收方的网络层在剥去首部后把数据交付给相应的协议

（3）差错检测

• 网络层只检查 IP 数据的首部，不检验数据部分

• 传输层对报文（首部和数据部分）进行差错检测

（4）提供面向连接和无连接的传输协议

• 面向连接的 TCP 协议：为其上层提供的是面向连接的可靠的数据传输服务

• 无连接的 UDP 协议：为其上层提供的是无连接的不可靠的数据传输服务

• 注意：
• 网络层无法同时实现两种协议，即要么只提供面向连接的服务【如虚电路】，要么只提供无连接服务【如数据报】，而不可能在网络层中同时存在这两种形式
• IP 数据报和 UDP 数据报的区别：
• IP 数据报在网络层要经过路由器的存储转发
• UDP 数据报在传输层的端到端的逻辑信道中传输，封装成 IP 数据报在网络层传输时，UDP数据报的信息对路由器是不可见的
• TCP 和网络层虚电路的区别：
• TCP 报文段在传输层抽象的逻辑信道中传输，对路由器不可见
• 虛电路所经过的交换结点都必须保存虚电路状态信息
• 在网络层若采用虚电路方式，则无法提供无连接服务
• 传输层采用 TCP 不影响网络层提供无连接服务

3、传输层的寻址与端口

（1）端口的作用

• 端口：
• 传输层服务访问点（TSAP）
• 能让应用层的各种进程将其数据通过端口向下交付给传输层
• 让传输层知道应当将其报文段的数据向上通过端口交付给应用层相应的进程

（2）端口号

• 运行在计算机上的进程是使用进程标识符 PID来标识的
• 因特网上的计算机并不是使用统一的操作系统，不同的操作系统使用不同格式的进程标识符
• 为了使运行不同操作系统的计算机的应用进程之间能进行网络通信，必须使用统一的方法对 TCP/IP 体系的应用进程进行标识，即端口号

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

• 在因特网中，不同计算机中的相同的端口号是没有联系的

• TCP 和 UDP 端口号之间也是没有关系的

• 端口号使用16 比特表示，取值范围 0~65535，根据端口号范围将端口分为两类：
1. 服务端使用端口号：
• 熟知端口号：0~1023，IANA 把这些端口号指派给了 TCP/IP 体系中最重要的一些应用协议，让所有用户都知道
• 登记端口号：1024~49151，为没有熟知端口号的应用程序使用，必须在 IANA 按照规定的手续登记，以防止重复【如 Microsoft RDP 微软远程桌面使用的端口是 3389 】

2. 客户端使用端口号：49152~65535
• 仅在客户进程运行时才动态地选择，又称短暂（临时）端口号
• 当服务器进程收到客户进程的报文时，就知道了客户进程所使用的的动态端口号
• 通信结束后，这个端口号可供其他客户进程以后使用

（3）套接字

• 套接字：
• 实际上是一个通信端点
• 唯一地标识网络中的一台主机上的一个应用进程

二、UDP 协议

1、UDP 数据报

（1）UDP 概述

• UDP 仅在 IP 的数据报服务之上增加了两个最基本的服务：复用和分用，差错检测

• 特点：
• 无须建立连接
• 无连接状态：当某些专用服务器使用 UDP 时，一般都能支持更多的活动客户机
• 首部开销小：仅有 8 B
• 没有拥塞控制，网络中的拥塞不会影响源主机的发送速率
• 支持单播、多播和广播
• 不保证可靠交付：可靠性由用户在应用层维护
• 面向应用报文：收到应用层报文后直接为报文添加 UDP 首部就进行发送

• 适用场景：
• 一次性传输较少数据的网络应用【DNS、SNMP 等】
• 多媒体应用【IP 电话、实时视频会议、流媒体等】

（2）UDP 首部格式

• UDP 数据报包含两部分：
• 首部：8 B
• 数据部分

• 源端口和目的端口：
• UDP 分用：基于目的端口
• UDP 复用：基于源端口
• 目的端口号不正确：丢弃报文，并有 ICMP 发送“端口不可达”差错报文给发送方

• 长度：包括首部和数据，最小是 8 【仅有首部】

• 校验和（可选）：
• 检测 UDP 数据报是否有错，有就丢弃
• 当源主机不想计算校验和时，令该字段为全 0

2、UDP 校验

• UDP 检验和提供差错检测功能

• 在计算校验和时，要在 UDP 用户数据报之前增加 12 B的伪首部【既不向下传送也不向上递交】

• 源 IP 地址和目的 IP 地址：和 IP 数据一样，各占 4 B

• 伪首部第 3 个字段是全 0

• 协议字段：值是 17

• UDP 长度：UDP 用户数据报长度【首部长度和数据部分长度之和】

• 校验过程：
• 将校验和字段置位 0
• 将伪首部和 UDP 用户数据报【首部和数据部分】看成是以 16 位为单位的二进制组成，依次进行二进制反码求和
• 将求和的结果的反码写入校验和字段

• 注意：
• 检验时，若 UDP 数据报部分的长度不是偶数个字节，则需填入一个全 0 字节【此字节和伪首部一样，是不发送的】
• 若 UDP 检验和检验出 UDP 数据报是错误的，则可以丢弃，也可以交付给上层，但是需要附上错误报告，即告诉上层这是错误的数据报
• 通过伪首部，不仅可以检查源端口号、目的端口号和 UDP 用户数据报的数据部分，还可以检查 IP 数据报的源 IP 地址和目的地址。

三、TCP 协议

1、TCP 协议的特点

• TCP 是在不可靠的 IP 层之上实现的可靠传输协议

• TCP 主要解决：传输的可靠、有序、无丢失和不重复问题

• 主要特点：
• 面向连接：发送数据前需要"三报文握手"建立连接，数据传输结束后需要"四报文挥手"释放连接
• 仅支持单播：每一条 TCP 连接是点对点（一对一）的
• 提供全双工通信：允许通信双方的应用进程在任何时候都能发送数据，为此TCP 连接的两端都设有发送缓存和接收缓存
• 发送缓存暂存：
• 发送应用程序传送给发送方 TCP 准备发送的数据
• TCP 已发送但尚未收到确认的数据
• 接收缓存暂存：
• 按序到达但尚未被接收应用程序读取的数据
• 不按序到达的数据
• 面向字节流：虽然实际上 TCP 的交互是数据块之间，但是 TCP 其将应用进程交付下来的数据块仅视为一连串无结构的字节流

2、TCP 报文段

• TCP 传送的数据单元称为报文段

• TCP 报文段既可以用来运载运载数据，又可以用来建立连接、释放连接和应答

• TCP 首部最短是 20B，后面有 4N 字节是可选的，长度是 4B 的整数倍

• 源端口：占 2B ，写入源端口号，用来标识发送该 TCP 报文段的应用进程

• 目的端口：占 2B ，写入目的端口号，用来标识接收该 TCP 报文段的应用进程

• 序号：占 4B ，取值范围 $[0,2^{32}-1]$
• 每个字节按顺序编号，序号增加到最后一个后，下一个序号就又回到 0
• 用于指出本 TCP 报文段数据载荷的第一个字节的序号

• 确认号：占 4B
• 是期望收到对方下一个报文段的第一个数据字节的序号
• 可理解为若确认号=n，则表明到序号 n-1 为止的所有数据都已正确接收，期望接收序号为 n 的数据

• 保留字段：占6 比特，保留为今后使用，但是目前应置为 0

• 数据偏移：占 4 比特，并以 4B 为单位
• 指出 TCP 报文段的数据载荷部分的起始处距离 TCP 报文段的起始处有多远
• 实际上是指出 TCP 报文段的首部长度
• 首部固定长度为 20 字节，因此数据偏移字段的最小值 0101
• 首部最大长度为 60 字节，因此数据偏移字段最大值为 1111

• 窗口：占 2B，取值范围 $[0,2^{16}-1]$， 以字节为单位
• 指出发送本报文段的一方的接收窗口的大小，即接收缓存的可用空间大小，这用来表征接收方的接收能力

• 检验和：占 2B
• 检测范围包括 TCP 报文段的首部和数据载荷两部分
• 在计算校验和时，要在 TCP 报文段的前面加上 12B 的伪首部

• 确认标志位 ACK：
• 取值为 1 时确认号字段才有效，为 0 时确认号字段无效
• TCP 规定：在 TCP 连接建立后，所有传送的 TCP 报文段都必须把 ACK 置 1

• 同步标志位 SYN：
• 在 TCP连接建立时用来同步序号
• 当SYN=1 且 ACK=0时，表明这是一个 TCP 连接请求报文段
• 对方若同意建立连接，则在响应的 TCP 报文段的首部中使SYN=1 且 ACK=1
• 综上，SYN=1 的 TCP 报文段要么是一个连接请求报文段，要么是一个连接响应报文段

• 终止标志位 FIN：
• 用来释放 TCP 连接
• 当 FIN=1 时，表明此 TCP 报文段的发送方已将全部数据发送完毕，现在要求释放 TCP 连接

• 复位标志位 RST：
• 用来复位 TCP 连接
• 当 RST=1 时，表明 TCP 连接出现了异常，必须释放连接，然后再重新建立连接
• RST 置 1 还用来拒绝一个非法的报文段或拒绝打开一个 TCP 连接

• 推送标志位 PSH：
• 接收方的 TCP 收到 PSH=1 的报文段会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付

• 紧急标志位 URG：
• 当 URG=1 时紧急指针字段有效，告诉系统此报文段中有紧急数据应尽快传送【高优先级，插入到报文段数据的最前面】
• 当 URG=0 时紧急指针字段无效

• 紧急指针：占 2B ，以字节为单位
• 指出本报文段中的紧急数据的字节数
• 窗口为 0 时也可以发送紧急数据

• 选项：以增加 TCP 的功能
• 最大报文段长度 MSS 选项：TCP 报文段数据载荷部分的最大长度
• 窗口扩大选项：为了扩大窗口 (提高吞吐率)
• 时间戳选项：
• 用来计算往返时间 RTT
• 用于处理序号超范围的情况，又称为防止序号绕回 PAWS
• 选择确认选项：实现选择确认功能

• 填充：由于选项长度可变，使首部长度是 4B 的整数倍

3、TCP 连接管理

• TCP 是面向连接的协议，它基于运输连接来传送 TCP 报文段

• TCP 运输连接的建立和释放，是每一次面向连接的通信中必不可少的过程

• TCP 运输连接有以下三个阶段：
1. 通过“三报文握手”来建立 TCP 连接
2. 基于已建立的 TCP连接进行可靠的数据传输
3. 在数据传输结束后，还要通过“四报文挥手”来释放 TCP连接

（1）TCP 连接建立（三次握手）

• 在 TCP 连接建立的过程中，要解决以下三个问题：
1. 使 TCP 双方能够确知对方的存在
2. 使 TCP 双方能够协商一些参数（例如最大报文段长度、最大窗口大小、时间戳选项等）
3. 使 TCP 双方能够对运输实体资源进行分配和初始化。运输实体资源包括缓存大小、各状态变量、连接表中的项目等

1. 第一次握手：
• 客户发送 TCP 连接请求报文段进入 SYN-SENT【同步已发送】状态
• 同步位 SYN=1，选择一个初始序号 seq=x
• SYN=1 的报文段不能携带数据，但消耗一个序号 x
• TCP 客户进程下一次发送的 TCP 报文段的数据载荷的第一个字节的序号为 x+1

2. 第二次握手：
• 服务器收到连接请求报文段，若同意建立连接，向客户返回 TCP 连接请求确认报文段，并为 TCP 连接分配缓存和变量
• 服务器进程进入 SYN-RCVD【同步已接收】状态
• 同步位 SYN=1，确认位 ACK=1，确认号 ack=x+1，为自己选择一个初始序号 seq=y
• SYN=1 的报文段不能携带数据，但消耗一个序号 y

3. 第三次握手：
• 客户端返回连接请求确认报文段的普通 TCP 确认报文段，并为 TCP 连接分配缓存和变量
• 客户端进入 ESTABLISHED【连接已建立】状态
• 确认位 ACK=1，确认号 ack=y+1，序号 seq=x+1
• 此时 TCP 连接已经建立，服务器收到客户端的确认后，进入 ESTABLISHED 状态
• 注意：
• 服务端的资源是完成第二次握手时分配的
• 客户端的资源是完成第三次握手时分配的
• 使用“三报文握手”而不是“两报文握手”的原因：为了防止已失效的 TCP 连接请求报文段突然又传送到了 TCP 服务器进程，因而导致错误

（2）TCP 连接释放（四次挥手）

1. 第一次挥手：
• 客户端向服务端发送 TCP 连接释放报文段，并停止发送数据，主动关闭连接
• 客户端进入 FIN-WAIT-1【终止等待 1 】状态
• 终止位 FIN=1，序号 seq=u【等于之前已传送的数据的最后一个字节的序号+1】
• 确认位 ACK=1，确认号 ack=v【等于之前已收到的数据的最后一个字节的序号+1】
• FIN=1 的报文段即使不携带数据，也要消耗掉一个序号 u

2. 第二次挥手：
• 服务器收到连接释放报文段后，发送 TCP 普通确认报文段
• 务器进入 CLOSE-WAIT【关闭等待】状态
• 确认位 ACK=1，确认号 ack=u+1，序号 seq=v【等于之前已传送过的数据最后一个字节的序号+1】
• 此时 TCP 连接处于半关闭状态：
• 从客户端到服务器方向的连接释放
• 服务器还可以向客户端发送文件，且客户端需接受
• 客服端收到服务器的确认，进入 FIN-WAIT-2【终止等待 2】状态，等待服务器发出的连接释放报文段

3. 第三次挥手：
• 服务器发送 TCP 连接释放报文段，进入 LAST-ACK【最后确认】状态，等待客户端的确认
• 终止位 FIN=1，序号 seq=w【在半关闭状态下服务器可能又发送了一些数据】
• 服务器重复发送上次已发送到确认号 ack=u+1

4. 第四次挥手：
• 客户端返回连接释放确认报文段的普通 TCP 确认报文段
• 客户端进入 TIME-WAIT【时间等待】状态
• 确认位 ACK =1，确认号 ack=w+1，序号 seq=u+1
• 服务器收到该报文段后进入 CLOSED【关闭】状态
• 在经过时间等待计时器设置的世界 2 MSL【最大报文段寿命】后，客户端进入 CLOSED 【关闭】状态
• 客户机还要要等到一段时间 2MSL 后完全关闭的原因：
• 处于 TIME-WAIT【时间等待】状态后要经过 2MSL 时长，可以确保 TCP 服务器进程能够收到最后一个 TCP 确认报文段而进入 CLOSED【关闭】状态
• TCP 客户进程在发送完最后一个 TCP 确认报文段后，再经过 2MSL 时长，就可以使本次连接持续时间内所产生的的所有报文段都从网络中消失，这样就可以使下一个新的 TCP 连接中不会出现旧连接中的报文段

• TCP 保活计时器的作用

4、TCP 可靠传输

• TCP 提供的可靠数据传输保证接收方进程从缓存区读出的字节流与发送方发出的字节流完全一样

• TCP 使用校验【与UDP一致】、序号、确认、重传来达到这个目的

（1）序号

• TCP 首部的序号字段用来保证数据能有序提交给应用层

• TCP 把数据视作一个无结构但有序的字节流

• 序号建立在传送的字节流之上，而不建立在报文段之上

• 序号字段的值是指本报文段所发送的数据的第一个字节的序号

• 注意：ackn 在选择重传协议与 TCP 协议中并不完全相同
• 在选择重传协议中， ackn 表明序号到 n 为止的数据已正确接收，现在期望收到序号为 n+1 的数据
• 在 TCP 协议中， ackn 表明序号到 n-1 为止的数据已正确接收，现在期望收到序号为 n 的数据

• 使用三个指针 P1、P2、P3 分别指向相应的字节序号：
• P1 指向发送窗口内已发送但还未收到确认的第一个数据的序号
• P2 指向发送窗口内还未发送的第一个数据的序号
• P3 指向发送窗口前沿外的第一个数据的序号

（2）确认

• TCP 首部的确认号是期望收到对方的下一个报文段的数据的第一个字节的序号

• TCP 默认使用累计确认，即 TCP 只确认数据流中至第一个丢失字节为止的字节

• TCP 可以使用选择确认【SACK】

（3）重传

1）超时

• 超时计时器设置的重传时间到期但还未收到确认时，就要重传这一报文段

• 报文段的往返时间 RTT：一个报文段发出时间和收到相应确认时间之差

• 加权平均往返时间 $RTT_S$：随新测量 RTT 样本值的变化而变化

• 超时重传时间 RTO：略大于 $RTT_S$【过大，报文段丢失时，不能立即重传，导致数据传输时延大】

• 往返时间测量问题：

2）冗余 ACK

• 再次确认某个报文段的 ACK，而发送方先前已经收到过该报文段的确认

• TCP 规定每当比期望序号大的失序报文到达时，就发送一个冗余 ACK，指明下一个期待字节的序号

• TCP 规定当发送方收到对同一个报文段的 3 个冗余 ACK 时，就可以认为跟在这个被确认报文段之后的报文段已经丢失

• 快速重传：只要某个报文段丢失，就立即重传

（4）检验

5、TCP 流量控制

（1）基本概念

• 流量控制：解决因发送方发送数据太快而导致接收方来不及接收，造成接收方的接收缓存溢出的问题

• 流量控制的基本方法：接收方根据自己的接收能力【接收缓存的可用空间大小】控制发送方的发送速率

• TCP 利用滑动窗口机制实现对发送方的流量控制

• TCP 的窗口单位是字节

• 发送窗口 swnd的上限值=min（rwnd, cwnd）

（2）TCP 的流量控制方法

• 发送方窗口随着接收方窗口变化而变化【通过确认报文将rwnd 告知发送方】

• 发送方发送完窗口内数据后需要等到确认报文才会滑动窗口并继续发送

• 若窗口内的某个值很久没有收到回答报文，则超时重传报文

• 持续计时器：只要 TCP 连接的一方收到对方的零窗口通知，就启动

• *若发送的零窗口探测报文也丢失了，是否会造成新死锁

不会，因为零窗口探测报文也有超时重传机制

6、TCP 拥塞控制

（1）基本概念

• 拥塞：在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏

• 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降

• 流量控制与拥塞控制的区别：
• 流量控制：
• 以接收方的接收能力控制发送方（源点）的发送速率
• 只与特定的点对点通信的发送方和接收方之间的流量有关
• 拥塞控制：
• 源点根据各方面因素，按拥塞控制算法自行控制发送速率
• 全局性问题，涉及网络中所有的主机、路由器等

（2）基本方法

1. 开环控制：
• 试图用良好的设计来解决问题
• 从一开始就保证问题不会发生
• 一旦系统启动并运行起来，就不需要中途修正
• 当网络的流量特征可以准确规定且性能要求可以事先获得时，适合使用开环控制

2. 闭环控制：
• 基于反馈的控制方法，包括以下三个部分
1. 监测网络拥塞在何时、何地发生
2. 把拥塞发生的相关信息传送到可以采取行动的地方
3. 调整网络的运行以解决拥塞问题
• 当网络的流量特征不能准确描述或者当网络不提供资源预留时，适合使用闭环控制
• 因特网采用的就是闭环控制方法

• 衡量网络拥塞的指标：

• 根据拥塞信息的反馈形式，可将闭环拥塞控制算法分为
1. 显示反馈算法：从拥塞节点【即路由器】向源点提供关于网络中拥塞状态的显式反馈信息
2. 隐式反馈算法：源点自身通过对网络行为的观察【例如超时重传或往返时间 RTT】来推断网络是否发生了拥塞，TCP 采用的就是隐式反馈算法

• 进行拥塞控制是需要付出代价的：
• 可能需要在节点之间交换信息和各种命令，以便选择拥塞控制的策略并实施控制，这样会产生额外开销
• 可能需要预留一些资源用于特殊用户或特殊情况，这样就降低了网络资源的共享程度

（3）TCP 的四种拥塞控制方法

1）慢开始和拥塞避免（TCP 连接建立和网络出现超时）

• 发送方维护一个叫做拥塞窗口 cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化

• 拥塞窗口 cwnd 的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些 【确认报文段窗口大小】，但只要网络出现拥塞，拥塞窗口就减少一些

• 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文 【发送超时重传】

• 不考虑流量控制时，发送方将拥塞窗口作为发送窗口 swnd，即 swnd = cwnd

• 维护一个慢开始门限 ssthresh状态变量：
• 当 cwnd < ssthresh 时，使用慢开始算法
• 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法
• 当 cwnd = ssthresh 时，既可使用慢开始算法，也可以使用拥塞避免算法

• 慢开始算法：
• 拥塞窗口从 1 开始，根据应答报文大小来扩大拥塞窗口【2 倍】
• 如发送方窗口 2，应答大小 2，则下次发送大小为 4
• 指一开始向网络注入的报文段少，而并不是指拥塞窗口 cwnd 的值增长速度慢

• 拥塞避免算法：
• 当窗口增加到一定大小，发送方发送的报文出现了超时重传，则判断网络可能出现了拥塞，此时将拥塞窗口初始化为 1
• 同时将慢开始门限 ssthresh 设置为发生拥塞时窗口大小的一半，拥塞窗口每次只扩大 1，而不是向慢开始那样根据发送方的返回窗口进行增加
• 并非指完全能够避免拥塞，而是指在拥塞避免阶段将 cwnd 值控制为按线性规律增长，使网络比较不容易出现拥塞

• 在慢开始和拥塞避免算法中使用了“乘法减小”和“加法增大”方法：
• 乘法减小：
• 指不论是在慢开始阶段还是在拥塞避免阶段，只要出现超时【即很可能出现了网络拥塞】，就把慢开始门限值 ssthresh 设置为当前拥塞窗口的一半，并执行慢开始算法
• 当网络频繁出现拥塞时，ssthresh 值就下降得很快，以大大减少注入网络的分组数
• 加法增大：
• 指执行拥塞避免算法后，在收到对所有报文段的确认后【即经过一个 RTT】，就把拥塞窗口 cwnd 增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞

2）快重传和快恢复（发送方接收到冗余 ACK）

• 快重传算法：使发送方尽快进行重传，而不是等重传计时器超时再重传
• 要求接收方不用等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
• 发送方一旦收到 3 个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传

• 快恢复算法：发送方一旦收到 3 个重复确认，就知道现在只是丢失了个别报文段，于是不启动慢开始算法，而执行快恢复算法
• 发送方将慢开始门限 ssthresh 值和拥塞窗口 cwnd 值调整为当前窗口的一半，开始执行拥塞避免算法
• 由于跳过了拥塞窗口 cwnd 从 1 起始的慢开始过程，所以被称为快恢复
• 也有的快恢复实现是把快恢复开始时的拥塞窗口 cwnd 值再增大一些【 cwnd=新 ssthresh+3 】：
• 既然发送方收到 3 个重复的确认，就表明有 3 个数据报文段已经离开了网络
• 这 3 个报文段不再消耗网络资源而是停留在接收方的接收缓存中
• 可见现在网络中不是堆积了报文段而是减少了 3 个报文段，因此可以适当把拥塞窗口扩大些

（4）例题