文章目录[隐藏]

运输层

运输层

1. 概述

之前课程所介绍的计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信
但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程
如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议

进程之间的通信

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层
当网络边缘部分中的两个主机使用网络核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到三层（到网络层）的功能

“逻辑通信”是指运输层之间的通信好像是沿水平方向传送数据，但事实上，这两个运输层之间并没有一条水平方向的物理连接，要传送的数据是沿着图中上下多次的虚线方向传送的

进程 AP1 与 AP4 之间进行基于网络的通信，进程 AP2 与 AP3 之间进行基于网络的通信

在运输层使用不同的端口，来对应不同的应用进程，然后通过网络层及其下层来传输应用层报文，接收方的运输层通过不同的端口，将收到的应用层报文，交付给应用层中相应的应用进程

这里端口并不是指看得见、摸得着的物理端口，而是指用来区分不同应用进程的标识符

运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即 面向连接的TCP 和 无连接的UDP

2. 端口号、复用与分用

2.1 端口号

运行在计算机上的进程使用进程标识符PID来标志
因特网上的计算机并不是使用统一的操作系统，不同的操作系统（windows，Linux，Mac OS）又使用不同格式的进程标识符
为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对 TCP/IP 体系的应用进程进行标识
TCP/IP 体系的运输层使用端口号来区分应用层的不同应用进程
- 端口号使用16比特表示，取值范围 0~65535
- 熟知端口号：0~1023，IANA 把这些端口号指派给了 TCP/IP 体系中最重要的一些应用协议，例如：FTP使用21/20，HTTP使用80，DNS使用53
- 登记端口号：1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在 IANA 按照规定的手续登记，以防止重复。例如：Microsoft RDP 微软远程桌面使用的端口是3389
- 短暂端口号：49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用
- 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的

TCP/IP 体系的应用层常用协议所使用的运输层熟知端口号：

2.2 发送方的复用和接收方的分用

多个进程（这里一个端口表示一个进程）

利用一个运输层协议（或者称为运输层接口），发送数据称为复用

利用一个运输层协议（或者称为运输层接口），接收数据称为分用

2.3 网页请求和加载过程

在浏览器输入域名，回车浏览，然后用户 PC 中的 DNS 客户端进程会发送一个 DNS查询请求报文（DNS查询请求报文需要使用运输层的 UDP 协议）。首部中的源端口字段的值，在短暂端口号 49151~65535 中挑选一个未被占用的，用来表示 DNS 客户端进程；首部中的目的端口字段的值：53，是 DNS 服务器端进程所使用的熟知端口号

之后，将 UDP 用户数据报封装在 IP 数据报中，通过以太网发送给 DNS 服务器

DNS 服务器收到该 IP 数据报后，从中解析出 UDP 用户数据报

UDP 首部中的目的端口号为 53，这表明应将该 UDP 用户数据报的数据载荷部分，也就是 DNS查询请求报文，交付给本服务器中的 DNS 服务器端进程

DNS 服务器端进程解析 DNS查询请求报文的内容，然后按其要求查找对应的 IP 地址

之后，会给用户 PC 发送 DNS响应报文，DNS响应报文需要使用运输层的 UDP 协议封装成 UDP 用户数据报，其首部中的源端口字段的值设置为熟知端口号 53，表明这是 DNS 服务器端进程所发送的 UDP 用户数据报，目的端口的值设置为 49152，这是之前用户 PC 中发送 DNS 查询请求报文的 DNS 客户端进程所使用的短暂端口号

将 UDP 用户数据报封装在 IP 数据报中，通过以太网发送给用户 PC

用户 PC 收到该数据报后，从中解析出 UDP 用户数据报

UDP 首部中的目的端口号为49152，这表明应将该 UDP 用户数据报的数据载荷部分，也就是DNS响应报文，交付给用户 PC 中的 DNS 客户端进程

DNS 客户端进程解析 DNS 响应报文的内容，就可知道自己之前所请求的 Web 服务器的域名对应的 IP 地址

现在用户 PC 中的 HTTP 客户端进程可以向 Web 服务器发送 HTTP 请求报文（和 DNS 发送和接收流程差不多）

3. UDP 和 TCP 的对比

3.1 基本概述

UDP 和 TCP 是 TCP/IP 体系结构运输层中的两个重要协议
当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道
当运输层采用无连接的 UDP 协议时，这种逻辑通信信道是一条不可靠信道

可靠信道与不可靠信道
两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)
TCP 传送的数据单位协议是 TCP 报文段(segment)
UDP 传送的数据单位协议是 UDP 报文或用户数据报
- UDP 的通信是无连接的，不需要套接字（Socket）
- TCP 是面向连接的，TCP 之间的通信必须要在两个套接字（Socket）之间建立连接

3.2 用户数据报协议 UDP

（1）结构

（2）特点

可以发送广播
可以向某个多播组发送多播
还可以发送单播
- UDP 支持单播、多播以及广播。换句话说，UDP 支持一对一，一对多，以及一对全的通信

（3）运输过程

UDP 对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界。换句话说，UDP 是面向应用报文的

（4）向上层提供无连接不可靠传输服务

3.3 传输控制协议 TCP

（1）结构

（2）特点

使用 TCP 协议的通信双方，在进行数据传输之前，必须使用“三报文握手”建立 TCP 连接
TCP 连接建立成功后，通信双方之间就好像有一条可靠的通信信道，通信双方使用这条基于 TCP 连接的可靠信道进行通信
- 很显然，TCP 仅支持单播，也就是一对一的通信

（3）运输过程

发送方

TCP 会把应用进程交付下来的数据块看作是一连串无结构的字节流，TCP 并不知道这些待传送的字节流的含义

并将他们编号，并存储在自己发送缓存中

TCP 会根据发送策略，提取一定量的字节构建 TCP 报文并发送

接收方

一方面从所接收到的 TCP 报文段中，取出数据载荷部分并存储在接收缓存中；一方面将接收缓存中的一些字节交付给应用进程

TCP 不保证接收方应用进程所收到的数据块与发送方发送的数据块，具有对应大小的关系

例如，发送方应用进程交给发送方的 TCP 共 10 个数据块，但接收方的 TCP 可能只用了 4 个数据块，就把收到的字节流交付给了上层的应用进程，但接收方收到的字节流必须和发送方应用进程发出的字节流完全一样

接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据

TCP 是面向字节流的，这正是 TCP 实现可靠传输、流量控制、以及拥塞控制的基础

本图只画了一个方向的数据流，在实际网络中，基于 TCP 连接的两端，可以同时进行 TCP 报文段的发送和接收

（4）向上层提供面向连接的可靠传输服务

4. TCP 报文段的首部格式

4.1 基本概述

为了实现可靠传输，TCP 采用了面向字节流的方式
但 TCP 在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为 TCP报文段 后进行发送
- 一个 TCP 报文段由首部和数据载荷两部分构成
- TCP 的全部功能都体现在它首部中各字段的作用

4.1 各字段介绍

（1）源端口和目的端口

源端口：
- 占 16 比特，写入源端口号
- 用来标识发送该 TCP 报文段的应用进程
目的端口：
- 占 16 比特，写入目的端口号
- 用来标识接收该 TCP 报文段的应用进程

（2）序号、确认号和确认标志位

序号：
- 占 32 比特，取值范围 0~2^32-1。当序号增加到最后一个时，下一个序号又回到 0
- 用来指出本 TCP 报文段数据载荷的第一个字节的序号
确认号：
- 占 32 比特，取值范围 0~2^32-1。当确认号增加到最后一个时，下一个确认号又回到 0
- 用来指出期望收到对方下一个 TCP 报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认
若确认号 = n,则表明到序号 n-1 为止的所有数据都已正确接收，期望接收序号为 n 的数据
确认标志位 ACK：
- 只有当 ACK 取值为 1 时，确认号字段才有效。ACK 取值为 0 时，确认号字段无效
- TCP 规定：在 TCP 连接建立后，所有传送的 TCP 报文段都必须把 ACK 置 1

（3）数据偏移、保留、窗口和校验和

数据偏移：
- 占 4 比特，并以 4 字节为单位
- 用来指出 TCP 报文段的数据载荷部分的起始处距离 TCP 报文段的起始处有多远
- 这个字段实际上是指出了 TCP 报文段的首部长度
保留：占 6 比特，保留为今后使用，但目前应置为 0
窗口：
- 占 16 比特，取值范围 0~2^16-1。该字段的取值以字节为单位
- 指出发送本报文段的一方的接收窗口的大小，即接收缓存的可用空间大小，这用来表示接收方的接收能力
- 在计算机网络中，经常用接收方的接收能力的大小来控制发送方的数据发送量，这就是所谓的流量控制
检验和：
- 占 16 比特
- 用来检查整个 TCP 报文段在传输过程中是否出现了误码
- 在计算校验和时，要在 TCP 报文段的前面加上 12 字节的伪首部
发送方：

接收方：

（4）同步标志位、终止标志位、复位标志位、推送标志位、紧急标志位和紧急指针

同步标志位 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 报文段或拒绝打开一个 TCP 连接
推送标志位 PSH：
- 出于效率的考虑，TCP 的发送方可能会延迟发送数据，而 TCP 的接收方可能会延迟向应用进程交付数据。这样可以一次处理更多的数据
- 但是当两个应用进程进行交互式通信时，有时在端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，应用进程可以通知TCP 使用推送(PUSH)操作
- 发送方 TCP 把 PSH 置 1，并立即创建一个 TCP 报文段发送出去，而不需要积累到足够多的数据再发送
- 接收方 TCP 收到 PSH 为 1 的 TCP 报文段，就尽快地交付给应用进程而不再等到接收到足够多的数据才向上交付
紧急标志位 URG：
- 当 URG = 1 时，紧急指针字段有效
- 当 URG = 0 时，紧急指针字段无效
紧急指针：
- 占 16 比特，以字节为单位，用来指明紧急数据的长度
- 当发送方有紧急数据时，可将紧急数据“插队”到发送缓存的最前面，并立刻封装到一个 TCP 报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据
- 接收方收到紧急标志位为 1 的 TCP 报文段，会按照紧急指针字段的值从报文段数据载荷中取出紧急数据并直接上交应用进程，而不必在接收缓存中排队

（5）选项和填充

选项（长度可变，最大40字节）：
- 最大报文段长度 MSS 选项：指出 TCP 报文段数据载荷部分的最大长度，而不是整个 TCP 报文段的长度
- 窗口扩大选项：用来扩大窗口，提高吞吐率
- 时间戳选项：
- 用于计算往返时间 RTT
- 用于处理序号超范围的情况，又称为防止序号绕回 PAWS
- 选择确认选项：用来实现选择确认功能
填充：
- 若选项字段的长度加上 20 字节固定首部的长度不能被 4 字节整除时，需要填充相应数量的比特 0，以确保首部长度能被 4 字节整除
- 因为数据偏移字段，也就是首部长度字段，是以 4 字节为单位的

5. TCP 的连接建立

TCP 是面向连接的协议，它基于运输连接来传送 TCP 报文段
- TCP 运输连接的建立和释放，是每一次面向连接的通信中必不可少的过程
TCP 建立连接的过程叫做握手
握手需要在客户和服务器之间交换三个 TCP 报文段，称之为三报文握手
采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到服务端，因而产生错误
TCP 运输连接有以下三个阶段：
- 通过“三报文握手”来建立 TCP 连接
- 基于已建立的 TCP 连接进行可靠的数据传输
- 在数据传输结束后，还要通过“四报文挥手”来释放 TCP 连接
“三报文握手”建立 TCP 连接的目的在于解决以下三个主要问题：
- 使 TCP 双方能够确知对方的存在
- 使 TCP 双方能够协商一些参数（例如最大报文段长度、最大窗口大小、时间戳选项等）
- 使 TCP 双方能够对运输实体资源进行分配和初始化。运输实体资源包括缓存大小、各状态变量、连接表中的项目等

5.1 三报文握手

TCP 连接的建立采用客户服务器方式
主动发起连接建立的应用进程叫做 TCP 客户 （client）
被动等待连接建立的应用进程叫做 TCP 服务器 （server）

（1）详细过程

最初两端的 TCP 进程都处于关闭状态

一开始，TCP 服务器进程首先创建传输控制块，用来存储 TCP 连接中的一些重要信息

例如 TCP 连接表、指向发送和接收缓存的指针、指向重传队列的指针，当前的发送和接收序号等

之后，就准备接受 TCP 客户端进程的连接请求

此时，TCP 服务器进程就进入监听状态，等待 TCP 客户端进程的连接请求

TCP 服务器进程是被动等待来自 TCP 客户端进程的连接请求，因此成为被动打开连接

TCP 客户进程也是首先创建传输控制块

由于 TCP 连接建立是由 TCP 客户端主动发起的，因此称为主动打开连接

然后，在打算建立 TCP 连接时，向 TCP 服务器进程发送 TCP 连接请求报文段，并进入同步已发送状态

TCP 连接请求报文段首部中

同步位 SYN 被设置为 1，表明这是一个 TCP 连接请求报文段

序号字段 seq 被设置了一个初始值 x，作为 TCP 客户端进程所选择的初始序号

请注意：

TCP 规定 SYN 被设置为 1 的报文段不能携带数据，但要消耗掉一个序号

因此，TCP 客户进程下一次发送的 TCP 报文段的数据载荷的第一个字节的序号为 x+1

TCP 服务器进程收到 TCP 连接请求报文段后，如果同意建立连接，则向 TCP 客户进程发送 TCP 连接请求确认报文段，并进入同步已接收状态

TCP 连接请求确认报文段首部中

同步位 SYN 和确认标志位 ACK 都设置为 1，表明这是一个 TCP 连接请求确认报文段

序号字段 seq 被设置了一个初始值 y，这是 TCP 服务器进程所选择的初始序号

确认号字段 ack 的值被设置成了 x+1，这是对 TCP 客户进程所选择的初始序号（seq）的确认

请注意：

这个报文段也不能携带数据，因为它是 SYN 被设置为 1 的报文段，但同样要消耗掉一个序号

TCP 客户进程收到 TCP 连接请求确认报文段后，还要向 TCP 服务器进程发送一个普通的 TCP 确认报文段，并进入连接已连接状态

普通的 TCP 确认报文段首部中

确认标志位 ACK 被设置为 1，表明这是一个普通的 TCP 确认报文段

序号字段 seq 被设置为 x+1，这是因为 TCP 客户进程发送的第一个 TCP 报文段的序号为 x，所以 TCP 客户进程发送的第二个报文段的序号为 x+1

确认号字段 ack 被设置为 y+1，这是对 TCP 服务器进程所选择的初始序号 y 的确认

请注意：

TCP 规定普通的 TCP 确认报文段可以携带数据，但如果不携带数据，则不消耗序号

如果该报文段不携带数据，则 TCP 客户进程要发送的下一个数据报文段的序号仍为 x+1

TCP 服务器进程收到该确认报文段后也进入连接已建立状态

现在，TCP 双方都进入了连接已建立状态，它们可以基于已建立好的 TCP 连接，进行可靠的数据传输

（2）为什么是三报文而不是两报文

为什么 TCP 客户进程最后还要发送一个普通的 TCP 确认报文段？能否使用“两报文握手”建立连接？下图是“两报文握手”

为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误

这种情况是：

一端（client）A 发出去的第一个连接请求报文并没有丢失，而是因为某些未知的原因在某个网络节点上发生滞留，导致延迟到连接释放以后的某个时间才到达另一端（server）B

本来这是一个早已失效的报文段，但是 B 收到此失效的报文段之后，会误认为是 A 再次发出的一个新的连接请求，于是 B 就向 A 又发出确认报文段，表示同意建立连接

如果不采用“三次握手”，那么只要 B 端发出确认报文就会认为新的连接已经建立了，但是 A 端并没有发出建立连接的请求，因此不会去向 B 端发送数据，B 端没有收到数据就会一直等待，这样 B 端就会白白浪费掉很多资源

所以并不多余，这是为了防止已失效的连接请求报文段突然又传送到了 TCP 服务器，因而导致错误

5.2 四报文挥手

TCP 连接的建立采用客户服务器方式
主动发起连接建立的应用进程叫做 TCP 客户 （client）
被动等待连接建立的应用进程叫做 TCP 服务器 （server）
任何一方都可以在数据传送结束后发出连接释放的通知

（1）详细过程

现在 TCP 客户进程和 TCP 服务器进程都处于连接已建立状态

TCP 客户进程的应用进程通知其主动关闭 TCP 连接

TCP 客户进程会发送 TCP 连接释放报文段，并进入终止等待 1 状态

TCP 连接释放报文段首部中

终止位 FIN 和确认标志位 ACK 的值都被设置为 1，表明这是一个 TCP 连接释放报文段，同时也对之前收到的 TCP 报文段进行确认

序号 seq 字段的值设置为 u，它等于 TCP 客户进程之前已传送过的数据的最后一个字节的序号加 1

确认号 ack 字段的值设置为 v，它等于 TCP 客户进程之前已收到的数据的最后一个字节的序号加 1

请注意：

TCP 规定终止位 FIN 等于 1 的报文段即使不携带数据，也要消耗掉一个序号

TCP 服务器进程收到 TCP 连接释放报文段后，会发送一个普通的 TCP 确认报文段并进入关闭等待状态

普通的 TCP 确认报文段首部中

确认标志位 ACK 的值被设置为 1，表明这是一个普通的 TCP 确认报文段

序号 seq 字段的值设置为 v，它等于 TCP 服务器进程之前已传送过的数据的最后一个字节的序号加 1，这也与之前收到的 TCP 连接释放报文段中的确认号匹配

确认号 ack 字段的值设置为 u+1，这是对 TCP 连接释放报文段的确认

TCP 服务器进程应该通知高层应用进程，TCP 客户进程要断开与自己的 TCP 连接

此时，从 TCP 客户进程到 TCP 服务器进程这个方向的连接就释放了

这时的 TCP 连接属于半关闭状态

TCP 客户进程已经没有数据要发送了。但如果 TCP 服务器进程还有数据要发送，TCP 客户进程仍要接收，也就是说从 TCP 服务器进程到 TCP 客户进程这个方向的连接并未关闭

半关闭状态可能会持续一段时间

TCP 客户进程收到 TCP 确认报文段后就进入终止等待 2 状态，等待 TCP 服务器进程发出的 TCP 连接释放报文段

若使用 TCP 服务器进程的应用进程已经没有数据要发送了，应用进程就通知其 TCP 服务器进程释放连接

由于 TCP 连接释放是由 TCP 客户进程主动发起的，因此 TCP 服务器进程对 TCP 连接的释放称为被动关闭连接

TCP 服务器进程发送 TCP 连接释放报文段并进入最后确认状态

该报文段首部中

终止位 FIN 和确认标志位 ACK 的值都被设置为 1，表明这是一个 TCP 连接释放报文段，同时也对之前收到的 TCP 报文段进行确认

序号 seq 字段的值为 w，这是因为在半关闭状态下，TCP 服务器进程可能又发送了一些数据

确认号 ack 字段的值为 u+1，这是对之前收到的 TCP 连接释放报文段的重复确认

TCP 客户进程收到 TCP 连接释放报文段后，必须针对该报文段发送普通的 TCP 确认报文段，之后进入时间等待状态

该报文段首部中

确认标志位 ACK 的值被设置为 1，表明这是一个普通的 TCP 确认报文段

序号 seq 字段的值设置为 u+1，这是因为 TCP 客户进程之前发送的 TCP 连接释放报文段虽然不携带数据，但要消耗掉一个序号

确认号 ack 字段的值设置为 w+1，这是对所收到的 TCP 连接释放报文段的确认

TCP 服务器进程收到该报文段后就进入关闭状态，服务器进程撤销相应的传输控制块，而 TCP 客户进程还要进过 2MSL 后才能进入关闭状态

等待 2MSL，这完全是从工程上来考虑的。对于现在的网络，MSL 取为 2 分钟可能太长了，因此 TCP 允许不同的实现可根据具体情况使用更小的 MSL 值

经过 2MSL 时间后，客户进程撤销相应的传输控制块后，就结束了这次的 TCP 连接

（2）为什么要进入时间等待状态？

TCP 客户进程在发送完最后一个确认报文后，为什么不直接进入关闭状态？而是要进入时间等待状态？

假设：

TCP 服务器进程发送 TCP 连接释放报应段后，进入最后确认状态

TCP 客户进程收到该报文段后，发送普通的 TCP 确认报文段，并进入关闭状态而不是时间等待状态

然而该 TCP 确认报文段丢失了，这必然会造成 TCP 服务器进程对之前所发送的 TCP 连接释放报文段的超时重传，并仍处手最后确认状态

重传的 TCP 连接释放报文段到达 TCP 客户进程，由于 TCP 客户进程处于关闭状态

因此，不理睬该报文段，这必然会造成 TCP 服务器进程反复重传 TCP 连接释放报文段，并一直处于最后确认状态，而无法进入关闭状态

处于时间等待（TIME-WAIT）状态后要经过 2MSL 时长，可以确保 TCP 服务器进程能够收到最后一个 TCP 确认报文段而进入关闭（CLOSED）状态
另外，TCP 客户进程在发送完最后一个 TCP 确认报文段后，再经过 2MSL 时长，就可以使本次连接持续时间内所产生的的所有报文段都从网络中消失。这样就可以使下一个新的 TCP 连接中不会出现旧连接中的报文段

（3）TCP 保活计时器的作用

TCP 双方已经建立了连接，后来，TCP 客户进程所在的主机突然出现了故障

TCP 服务器进程以后就不能再收到 TCP 客户进程发来的数据

因此，应当有措施使 TCP 服务器进程不要再白白等待下去

TCP 服务器进程每收到一次 TCP 客户进程的数据，就重新设置并启动保活计时器，通常为 2 小时

若保活计时器定时周期内未收到 TCP 客户进程发来的数据，则当保活计时器到时后，TCP 服务器进程就向 TCP 客户进程发送一个探测报文段，以后则每隔 75 秒钟发送一次。若一连发送 10 个探测报文段后仍无 TCP 客户进程的响应，TCP 服务器进程就认为 TCP 客户进程所在主机出了故障，接着就关闭这个连接

6. TCP 的流量控制

6.1 基本概念

TCP 为应用程序提供了流量控制（Flow Control）机制，以解决因发送方发送数据太快而导致接收方来不及接收，造成接收方的接收缓存溢出的问题
流量控制的基本方法：接收方根据自己的接收能力（接收缓存的可用空间大小）控制发送方的发送速率

6.2 流量控制方法

（1）具体流程

上图主机 A 现在可将发送缓存中序号 1~200 的字节数据全部删除，因为已经收到了主机 B 对它们的累计确认

上图主机 A 现在可将发送缓存中序号 201~500 的字节数据全部删除，因为已经收到了主机 B 对它们的累计确认

上图主机 A 现在可将发送缓存中序号 501~600 的字节数据全部删除，因为已经收到了主机 B 对它们的累计确认

（2）持续计时器

（3）问题答疑

7. TCP 的拥塞控制

7.1 基本概念

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况就叫作拥塞（congestion）
- 计算机网络中的链路容量（带宽）、交换节点中的缓存和处理机等都是网络的资源
若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降

7.2 基本方法

（1）流量控制与拥塞控制的区别

（2）开环控制和闭环控制

（3）衡量网络拥塞的指标

（4）显式和隐式反馈算法

7.3 四种拥塞控制方法

（1）慢开始（slow start）

慢开始，是指一开始向网络注入的报文段少，并不是指拥塞窗口 cwnd 增长速度慢

传输轮次：

发送方给接收方发送数据报文段后，接收方给发送方发回相应的确认报文段

一个传输轮次所经历的时间其实就是往返时间 RTT，往返时间并非是恒定的数值

使用传输轮次是为了强调把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个报文段的确认

每经过一个传输轮次，拥塞窗口就加倍，窗口大小按指数增加，2 ^ n-1