计算机网络 - 传输层

一. 传输层提供的服务

1. 传输层的功能

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

传输层位于网络层之上，它为运行在不同主机上的进程之间提供了逻辑通信，而网络层提供主机之间的逻辑通信。显然，即使网络层协议不可靠（网络层协议使分组丢失、混乱或重复），传输层同样能为应用程序提供可靠的服务。

从图 5.1 可以看出，网络的边缘部分的两台主机使用网络核心部分的功能进行端到端（端口到端口）的通信时，只有主机的协议栈才有传输层和应用层，而路由器在转发分组时都只用到下三层的功能（即在通信子网中没有传输层，传输层只存在于通信子网以外的主机中）。传输层的功能如下∶

1）传输层提供应用进程之间的逻辑通信（即端到端的通信）。与网络层的区别是，网络层提供的是主机之间的逻辑通信。

从网络层来说，通信的双方是两台主机，IP 数据报的首部给出了这两台主机的IP地址。但"两台主机之间的通信"实际上是两台主机中的应用进程之间的通信，应用进程之间的通信又称端到端的逻辑通信。这里"逻辑通信"的意思是∶传输层之间的通信好像是沿水平方向传送数据，但事实上这两个传输层之间并没有一条水平方向的物理连接。

2）复用和分用。

复用是指：发送方不同的应用进程都可使用同一个传输层协议传送数据;

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

注意∶网络层也有复用分用的功能，但网络层的复用是指发送方不同协议的数据都可以封装成 IP数据报发送出去，分用是指接收方的网络层在剥去首部后把数据交付给相应的协议。

3）传输层还要对收到的报文进行差错检测（首部和数据部分）。而网络层只检查 IP 数据报的首部，不检验数据部分是否出错。

4）提供两种不同的传输协议，即面向连接的 TCP和无连接的 UDP。而网络层无法同时实现两种协议（即在网络层要么只提供面向连接的服务，如虚电路;要么只提供无连接服务，如数据报，而不可能在网络层同时存在这两种方式）。

传输层向高层用户屏蔽了低层网络核心的细节（如网络拓扑、路由协议等），它使应用进程看见的是好像在两个传输层实体之间有一条端到端的逻辑通信信道，这条逻辑通信信道对上层的表现却因传输层协议不同而有很大的差别。当传输层采用面向连接的 TCP时，尽管下面的网络是不可靠的（只提供尽最大努力的服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。但当传输层采用无连接的 UDP 时，这种逻辑通信信道仍然是一条不可靠信道。

2. 传输层的寻址与端口

1.端口的作用

端口能够让应用层的各种应用进程将其数据通过端口向下交付给传输层，以及让传输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。端口是传输层服务访问点（TSAP），它在传输层的作用类似于IP地址在网络层的作用或 MAC 地址在数据链路层的作用，只不过IP 地址和 MAC 地址标识的是主机，而端口标识的是主机中的应用进程。

数据链路层的 SAP是 MAC地址，网络层的SAP是IP地址，传输层的SAP是端口。

在协议栈层间的抽象的协议端口是软件端口，它与路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与传输实体进行层间交互的一种地址。传输层使用的是软件端口。

2.端口号

应用进程通过端口号进行标识，端口号长度为16bit，能够表示65536（216）个不同的端口号。端口号只具有本地意义，即端口号只标识本计算机应用层中的各进程，在因特网中不同计算机的相同端口号是没有联系的。根据端口号范围可将端口分为两类∶

1）服务器端使用的端口号。它又分为两类，最重要的一类是熟知端口号，数值为0～1023，IANA（互联网地址指派机构）把这些端口号指派给了 TCP/IP 最重要的一些应用程序，让所有的用户都知道。另一类称为登记端口号，数值为 1024～49151。它是供没有熟知端口号的应用程序使用的，使用这类端口号必须在 IANA 登记，以防止重复。一些常用的熟知端口号如下∶

注意：如TCP中端口号 80 标识 Web 服务器端的HTTP 进程，客户端访问 Web服务器的HTTP进程的端口号由客户端的操作系统动态分配。

2）客户端使用的端口号，数值为 49152～65535。由于这类端口号仅在客户进程运行时才动态地选择，因此又称短暂端口号（也称临时端口）。通信结束后，刚用过的客户端口号就不复存在，从而这个端口号就可供其他客户进程以后使用。

3.套接字

在网络中通过 IP 地址来标识和区别不同的主机，通过端口号来标识和区分一台主机中的不同应用进程，端口号拼接到IP地址即构成套接字Socket。在网络中采用发送方和接收方的套接字来识别端点。套接字，实际上是一个通信端点，即
套接字Socket =（IP地址∶端口号）

它唯一地标识网络中的一台主机和其上的一个应用（进程）。在网络通信中，主机 A 发给主机 B 的报文段包含目的端口号和源端口号，源端口号是"返回地址"的一部分，即当B需要发回一个报文段给A时，B到A的报文段中的目的端口号便是A到B 的报文段中的源端口号（完全的返回地址是A的IP 地址和源端口号）。

3. 无连接服务与面向连接服务

面向连接服务就是在通信双方进行通信之前，必须先建立连接，在通信过程中，整个连接的情况一直被实时地监控和管理。通信结束后，应该释放这个连接。

无连接服务是指两个实体之间的通信不需要先建立好连接，需要通信时，直接将信息发送到"网络"中，让该信息的传递在网上尽力而为地往目的地传送。

TCP/IP 协议族在IP层之上使用了两个传输协议∶一个是面向连接的传输控制协议（TCP），采用TCP时，传输层向上提供的是一条全双工的可靠逻辑信道;另一个是无连接的用户数据报协议（UDP），采用 UDP 时，传输层向上提供的是一条不可靠的逻辑信道。

TCP提供面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或组播服务。由于TCP 提供面向连接的可靠传输服务，因此不可避免地增加了许多开销，如确认、流量控制、计时器及连接管理等。这不仅使协议数据单元的头部增大很多，还要占用许多的处理机资源。因此TCP主要适用于可靠性更重要的场合，如文件传输协议（FTP:21）、超文本传输协议（HTTP:80）、远程登录（TELNET:23）等。

UDP是一个无连接的非可靠传输层协议。它在IP之上仅提供两个附加服务∶多路复用和对数据的错误检查。IP知道怎样把分组投递给一台主机，但不知道怎样把它们投递给主机上的具体应用。UDP在传送数据之前不需要先建立连接，远程主机的传输层收到 UDP报文后，不需要给出任何确认。由于UDP比较简单，因此执行速度比较快、实时性好。使用UDP的应用主要包括小文件传送协议（TFTP:69）、DNS:53、SNMP:161 和实时传输协议（RTP）。

注意∶

1）IP数据报和UDP数据报的区别∶ IP 数据报在网络层要经过路由的存储转发;而 UDP数据报在传输层的端到端的逻辑信道中传输，封装成IP 数据报在网络层传输时，UDP数据报的信息对路由是不可见的。

2）TCP和网络层虚电路的区别∶ TCP报文段在传输层抽象的逻辑信道中传输，对路由器不可见;虚电路所经过的交换结点都必须保存虚电路状态信息。在网络层若采用虚电路方式，则无法提供无连接服务; 而传输层采用 TCP 不影响网络层提供无连接服务。

二. UDP 协议

1. UDP 数据报

1.UDP 概述

UDP只是在IP的数据报服务之上增加了两个最基本的服务∶复用和分用以及差错检测。如果应用开发者选择 UDP而非TCP，那么应用程序几乎直接与IP打交道。为什么应用开发者宁愿在UDP之上构建应用，也不选择 TCP?

既然 TCP提供可靠的服务，而UDP不提供，那么TCP总是首选吗?

答案是否定的，因为有很多应用更适合用 UDP，主要因为 UDP具有如下优点∶

1）UDP无须建立连接。因此 UDP不会引入建立连接的时延。试想如果 DNS 运行在TCP而非 UDP上，那么DNS 的速度会慢很多。HTP使用 TCP而非UDP，是因为对于基于文本数据的 Web 网页来说，可靠性是至关重要的。

2）无连接状态。TCP 需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数和序号与确认号的参数。而 UDP不维护连接状态，也不跟踪这些参数。因此，某些专用应用服务器使用 UDP 时，一般都能支持更多的活动客户机。

3）分组首部开销小。TCP有 20B 的首部开销，而 UDP仅有8B 的开销。

4）应用层能更好地控制要发送的数据和发送时间。UDP 没有拥塞控制，因此网络中的拥塞不会影响主机的发送效率。某些实时应用要求以稳定的速度发送，能容忍一些数据的丢失，但不允许有较大的时延，而 UDP 正好满足这些应用的需求。

5）UDP 支持一对一、一对多、多对一和多对多的交互通信。UDP 常用于一次性传输较少数据的网络应用，如 DNS、SNMP 等，因为对于这些应用，若采用 TCP，则将为连接创建、维护和拆除带来不小的开销。UDP也常用于多媒体应用（如IP电话、实时视频会议、流媒体等），显然，可靠数据传输对这些应用来说并不是最重要的，但 TCP的拥塞控制会导致数据出现较大的延迟，这是它们不可容忍的。

UDP不保证可靠交付，但这并不意味着应用对数据的要求是不可靠的，所有维护可靠性的工作可由用户在应用层来完成。应用开发者可根据应用的需求来灵活设计自己的可靠性机制。

UDP是面向报文的。发送方UDP对应用层交下来的报文，在添加首部后就向下交付给IP层，一次发送一个报文，既不合并，也不拆分（在传输层上不进行拆分，但是再网络层中由于以太网1500B的限制，在该层可以拆分），而是保留这些报文的边界;接收方UDP对IP层交上来 UDP数据报，在去除首部后就原封不动地交付给上层应用进程，一次交付一个完整的报文。因此报文不可分割，是UDP数据报处理的最小单位。

因此，应用程序必须选择合适大小的报文，若报文太长，UDP把它交给 IP层后，可能会导致分片;若报文太短，UDP把它交给IP层后，会使 IP 数据报的首部的相对长度太大，两者都会降低 IP 层的效率。

2.UDP 的首部格式

UDP数据报包含两部分∶UDP首部和用户数据。UDP首部有8B，由4个字段组成，每个字段的长度都是2B，如图 5.2 所示。各字段意义如下∶

1）源端口。源端口号。在需要对方回信时选用，不需要时可用全 0。

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

3）长度。UDP 数据报的长度（包括首部和数据），其最小值是8（仅有首部）。

4）校验和。检测 UDP数据报在传输中是否有错。有错就丢弃。该字段是可选的，当源主机不想计算校验和时，则直接令该字段为全 0。

传输层从IP层收到UDP数据报时，就根据首部中的目的端口，把 UDP 数据报通过相应的端口上交给应用进程，如图 5.3 所示。

如果接收方 UDP发现收到的报文中的目的端口号不正确（即不存在对应于端口号的应用进程），那么就丢弃该报文，并由 ICMP发数据报到达送"端口不可达"差错报文给发送方。

2. UDP校验

在计算校验和时，要在UDP数据报之前增加 12B的伪首部（伪首部包括源IP和目的IP），伪首部并不是UDP的真正首部。只是在计算校验和时，临时添加在UDP数据报的前面，得到一个临时的UDP数据报。校验和就是按照这个临时的 UDP数据报来计算的。伪首部既不向下传送又不向上递交，而只是为了计算校验和。图 5.4 给出了 UDP 数据报的伪首部各字段的内容。

UDP校验和的计算方法和IP 数据报首部校验和的计算方法相似。但不同的是，IP数据报的校验和只检验 IP 数据报的首部，但 UDP 的校验和则检查首部和数据部分。

发送方首先把全零放入校验和字段并添加伪首部，然后把UDP 数据报视为许多 16 位的字串接起来。若UDP数据报的数据部分不是偶数个字节，则要在数据部分末尾填入一个全零字节（但此字节不发送）。然后按二进制反码计算出这些16位字的和，将此和的二进制反码写入校验和字段，并发送。接收方把收到的 UDP 数据报加上伪首部（如果不为偶数个字节，那么还需要补上全零字节）后，按二进制反码求这些16 位字的和。当无差错时其结果应为全1，否则就表明有差错出现，接收方就应该丢弃这个 UDP 数据报。

图 5.5 给出了一个计算 UDP校验和的例子。本例中，UDP数据报的长度是 15B（不含伪首部），因此需要添加一个全0 字节。

注意∶

1）校验时，若 UDP数据报部分的长度不是偶数个字节，则需填入一个全0字节，如图 5.5所示。但是此字节和伪首部一样，是不发送的。

2）如果 UDP校验和校验出 UDP数据报是错误的，那么可以丢弃，也可以交付给上层，但是需要附上错误报告，即告诉上层这是错误的数据报。

3）通过伪首部，不仅可以检查源端口号、目的端口号和UDP用户数据报的数据部分，还可以检查 IP 数据报的源IP 地址和目的地址。

这种简单的差错检验方法的检错能力并不强，但它的好处是简单、处理速度快。

三. TCP 协议

1. TCP协议的特点

TCP 是在不可靠的 IP 层之上实现的可靠的数据传输协议，它主要解决传输的可靠、有序、无丢失和不重复问题。TCP 是TCP/IP 体系中非常复杂的一个协议，主要特点如下∶

1）TCP是面向连接的传输层协议。
2）每条 TCP连接只能有两个端点，每条 TCP 连接只能是点对点的（一对一）。
3）TCP提供可靠的交付服务，保证传送的数据无差错、不丢失、不重复且有序。
4）TCP提供全双工通信，允许通信双方的应用进程在任何时候都能发送数据，为此 TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。

发送缓存用来暂时存放以下数据∶

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

接收缓存用来暂时存放以下数据∶

① 按序到达但尚未被接收应用程序读取的数据;

② 不按序到达的数据。

5）TCP 是面向字节流的（流----是指到进程或从进程流出的字节序列），虽然应用程序和 TCP的交互是一次一个数据块（大小不等），但TCP 把应用程序交下来的数据仅视为一连串的无结构的字节流。

TCP 和 UDP在发送报文时所采用的方式完全不同。UDP报文的长度由发送应用进程决定，而 TCP报文的长度则根据接收方给出的窗口值和当前网络拥塞程度来决定。如果应用进程传送到TCP 缓存的数据块太长，TCP就把它划分得短一些再传送;如果太短，TCP也可以等到积累足够多的字节后再组成报文段发送出去。关于TCP 报文的长度问题，后面还会详细讨论。

2. TCP 报文段

TCP

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

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

TCP

报文段分为首部和数据两部分，

整个 TCP报文段作为 IP数据报的数据部分封装在 IP数据报中，如图5.6 所示。

其首部的前 2OB 是固定的。TCP报文段的首部最短为 20B，后面有 4N字节是根据需要而增加的选项，通常长度为 4B 的整数倍。

TCP 的全部功能体现在其首部的各个字段中，各字段意义如下∶

1）源端口和目的端口。各占2B。端口是运输层与应用层的服务接口，运输层的复用和分用功能都要通过端口实现。

2）序号。占4B，范围为0～232-1，共2个序号。TCP是面向字节流的（即TCP传送时是逐个字节传送的），所以TCP连接传送的字节流中的每个字节都按顺序编号。序号字段的值指的是本报文段所发送的数据的第一个字节的序号。

例如，一报文段的序号字段值是 301，而携带的数据共有 100B，表明本报文段的数据的最后一个字节的序号是400，因此下一个报文段的数据序号应从 401 开始。

3）确认号。占4B，是期望收到对方下一个报文段的第一个数据字节的序号。 若确认号为N，则表明到序号N-1为止的所有数据都已正确收到。

例如，B正确收到了A发送过来的一个报文段，其序号字段是501，而数据长度是200B（序号501～700），这表明B正确收到了A发送的到序号700为止的数据。因此B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701。

4）数据偏移（即首部长度）。占4位，（数据从哪里开始）这里不是 IP 数据报分片的那个数据偏移，而是表示首部长度（首部中还有长度不确定的选项字段），它指出 TCP报文段的数据起始处距离TCP报文段的起始处有多远。"数据偏移"的单位是32位（以4B为计算单位）。因此当此字段的值为 15 时，达到 TCP 首部的最大长度 60B。

5）保留。占6 位，保留为今后使用，但目前应置为 0。

6）紧急位 URG。URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据）。但 URG 需要和紧急指针配合使用，即数据从第一个字节到紧急指针所指字节就是紧急数据。

7）确认位ACK（ACKnowledgment）。仅当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。

8）推送位PSH（Push）。接收方TCP收到PSH=1的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满后再向上交付。（默认为0，等到缓存满了，再向上交付）

9）复位位RST（Reset）。RST=1时，表明 TCP连接中出现严重差错（如主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。（重新连接一次）

10）同步位 SYN(Synchronizedization)。同步 SYN=1表示这是一个连接请求或连接接受报文。当 SYN=1，ACK=0时，表明这是一个连接请求报文，对方若同意建立连接，则应在响应报文中使用 SYN=1，ACK=1。（SYN=0表示已经建立连接，SYN=1表示重新正在链接。）

11）终止位 FIN（Finish）。用来释放一个连接。当 FIN = 1时，表明此报文段的发送方的数据已发送完毕，并要求释放传输连接。(FIN等于0表示还有数据要发送)

12）窗口。占2B，范围为0～216-1。它指出现在允许对方发送的数据量，接收方的数据缓存空间是有限的，因此用窗口值作为接收方让发送方设置其发送窗口的依据。（通过窗口字段明确指出现在允许对方发送的数据量。窗口值经常在动态变化着）

例如，设确认号是701，窗口字段是 1000。这表明，从701号算起，发送此报文段的一方还有接收 1000 字节数据（字节序号为 701～1700）的接收缓存空间。

13）校验和。占 2B。校验和字段检验的范围包括首部和数据两部分。在计算校验和时，和UDP一样，要在TCP报文段的前面加上12B的伪首部（只需将 UDP伪首部的第4个字段，即协议字段的17改成6，其他的和UDP一样）。

14）紧急指针。占2B。紧急指针仅在 URG=1时才有意义，它指出在本报文段中紧急数据共有多少字节（紧急数据在报文段数据的最前面，与紧急位配合使用）。

15）选项。长度可变，最长可达40B。TCP最初只规定了一种选项，即最大报文段长度（Maximum Segment Size，MSS）。MSS 是TCP报文段中的数据字段的最大长度（注意仅仅是数据字段）。

16）填充。这是为了使整个首部长度是 4B 的整数倍。

3. TCP 连接管理

TCP 是面向连接的协议，因此每个TCP连接都有三个阶段∶连接建立、数据传送和连接释放。TCP 连接的管理就是使运输连接的建立和释放都能正常进行。

在 TCP 连接建立的过程中，要解决以下三个问题∶

1）要使每一方能够确知对方的存在。

2）要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项、时间戳选项及服务质量等）

3）能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

TCP把连接作为最基本的抽象，每条 TCP连接有两个端点，TCP 连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是传输层的协议端口。TCP连接的端口即为套接字（socket）或插口，每条 TCP 连接唯一地被通信的两个端点（即两个套接字）确定。

TCP 连接的建立采用客户/服务器方式。主动发起连接建立的应用进程称为客户（Client），而被动等待连接建立的应用进程称为服务器（Server）。

1.TCP 连接的建立（三次（三报文）握手）

连接的建立经历以下3个步骤，通常称为三次握手，客户端主动打开，服务端被动打开。如图5.7所示

连接建立前，服务器进程处于LISTEN（收听）状态，等待客户的连接请求。

第一步∶客户机的TCP首先向服务器的 TCP发送连接请求报文段。这个特殊报文段的首部中的同步位SYN置1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。

第二步∶服务器的TCP 收到连接请求报文段后，如同意建立连接，则向客户机发回确认，并为该TCP连接分配缓存和变量。在确认报文段中，把SYN位和ACK 位都置1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y。注意，确认报文段不能携带数据，但也要消耗掉一个序号。这时，TCP 服务器进程进入 SYN-RCVD（同步收到）状态。

第三步∶当客户机收到确认报文段后，还要向服务器给出确认，并为该TCP连接分配缓存和变量。确认报文段的ACK 位置 1，确认号ack=y+1，序号seq=x+1。该报文段可以携带数据，若不携带数据则不消耗序号。这时，TCP客户进程进入ESTABLISHED（已建立连接）状态。

成功进行以上三步后，就建立了 TCP 连接，接下来就可以传送应用层数据。TCP提供的是全双工通信，因此通信双方的应用进程在任何时候都能发送数据。另外，值得注意的是，服务器端的资源是在完成第二次握手时分配的，而客户端的资源是在完成第三次握手时分配的，这就使得服务器易于受到 SYN 洪泛攻击.

如果按上图中的看服务端给客户端发送的报文拆成两段，可以先发一个ACK确认报文（ACK=1,ack =x+1），然后再发送一个同步报文（SYN=1,seq=y），这样的过程就变成了四报文握手（四次握手），但是效果是一样的。

I 为什么客户端最后还要发送一次确认呢？

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

所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况，客户端发出连接请求，但因连接请求报文丢失而未收到确认于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释了连接。客户端共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，没有“已失效的连接请求报文段”

现假定出现一种异常情况，即客户端发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达服务端。本来这是一个早已失效的报文段。但服务端收到此失效的连接请报文段后，就误认为是客户端又发出一次新的连接请求。于是就向客户端发出确认报文段，同意建立连接。假定不采用报文握手，那么只要服务端发出确认，新的连接就建立了。

由于现在客户端并没有发出建立连接的请求，因不会理睬服务端的确认，也不会向服务端发送数据。但服务端却以为新的运输连接已经建立了，并一直等待客户端发来数据。那么服务端的许多资源就这样白白浪费了。

2.TCP 连接的释放 (四次（四报文）挥手)

参与 TCP连接的两个进程中的任何一个都能提出释放连接的请求。

天下没有不散的筵席，TCP 同样如此。参与 TCP 连接的两个进程中的任何一个都能终止该连接。TCP 连接释放的过程通常称为四次握手，客户端主动关闭，服务端被动关闭。如图 5.8 所示。

第一步∶客户机打算关闭连接时，向其 TCP发送连接释放报文段，并停止发送数据，主动关闭TCP连接，该报文段的终止位FIN置1，序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1，FIN报文段即使不携带数据，也消耗掉一个序号。这时，TCP客户进程进入FIN-WAIT-1（终止等待1）状态。TCP是全双工的，即可以想象为一条TCP连接上有两条数据通路，发送FIN的一端不能再发送数据，即关闭了其中一条数据通路，但对方还可以发送数据。

第二步;服务器收到连接释放报文段后即发出确认，确认号ack=u+1，序号seq=w，等于它前面已传送过的数据的最后一个字节的序号加1。然后服务器进入CLOSE-WAT（关闭等待）。此时，从客户机到服务器这个方向的连接就释放了，TCP连接处于半关闭状态。但服务器若发送数据，客户机仍要接收，即从服务器到客户机这个方向的连接并未关闭。

第三步∶若服务器已没有要向客户机发送的数据，就通知 TCP释放连接，此时其发出 FIN=1的连接释放报文段。设该报文段的序号为w（在半关闭状态服务器可能又发送了一些数据），还须重复上次已发送的确认号 ack=u+1。这时服务器进入LAST-ACK（最后确认）状态。

第四步∶客户机收到连接释放报文段后，必须发出确认。把确认报文段中的确认位 ACK 置1，确认号ack=w+1，序号seq=u+1。此时TCP连接还未释放，必须经过时间等待计时器设置的时间2MSL（最长报文段寿命 Maximum Segment Lifetime）后，客户机才进入 CLOSED（连接关闭）状态。

I 为什么客户端在TIME-WAIT状态必须等待2MSL的时间呢？

\1. 为了保证客户端发送最后一个ACK报文段能够到达服务端。这个ACK报文段有可能由于网络跌宕丢失，处在LAST-ACK状态的服务端如果在2MSL计时器时间内收不到ACK确认，就会超时重传FIN+ACK报文段。如此反复，直到服务端收到ACK请求进入CLOSED状态，此时客户端经过2MSL时间后也进入CLOSED状态。

\2. 防止“已失效的连接请求报文段”出现在下一次连接中，客户端在发送完最后一个ACK报文段之后，再经过2MSL时间，就将本连接持续时间内所产生的所有报文段从网络中消失。使得下一个新的连接中不会出现这种旧的连接请求报文段。

对上述 TCP连接建立和释放的总结如下∶

1）连接建立。分为3步∶
① SYN=1,seq=x。
②SYN=1,ACK=1,seq=y,ack=x+1。
③ACK=1,seq=x+1,ack=y+1。
2）释放连接。分为 4步∶
①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。
选择题喜欢考查（关于连接和释放的题目，ACK、SYN、FIN一定等于1），请牢记。

SYN和FIN报文即使不携带数据，也要消耗一个序号，ACK报文不携带数据就不用消耗序号。

3.保活计时器（心跳机制）

设想，如果客户端已主动与服务端建立了连接，但客户端由于主机突然出现故障，显然，服务端以后就不能再收到客户端发来的数据，因此，应当有措施使得服务器不要再白白等待下去。

除了时间等待计时器外，TCP还设有一个保活计时器（keepalive timer），服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两小时。若两小时内没有收到客户的数据，服务器就发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文段后无客户的响应，服务端就让认为客户端除了故障，接着关闭这个连接。

4. TCP可靠传输（具体协议见3.4章）

TCP的任务是在 IP 层不可靠的、尽力而为服务的基础上建立一种可靠数据传输服务。TCP提供的可靠数据传输服务保证接收方进程从缓存区读出的字节流与发送方发出的字节流完全一样。TCP使用了校验、序号、确认和重传等机制来达到这一目的。其中，TCP的校验机制与UDP校验一样，这里不再赘述。

1.序号

TCP首部的序号字段用来保证数据能有序提交给应用层，TCP 把数据视为一个无结构但有序的字节流，序号建立在传送的字节流之上，而不建立在报文段之上。

TCP连接传送的数据流中的每个字节都编上一个序号。序号字段的值是指本报文段所发送的数据的第一个字节的序号。如图 5.9 所示，假设 A 和 B之间建立了一条 TCP连接，A 的发送缓存区中共有10B，序号从 0开始标号，第一个报文包含第0～2 个字节，则该 TCP 报文段的序号是0，第二个报文段的序号是3。

2.确认

TCP首部的确认号是期望收到对方的下一个报文段的数据的第一个字节的序号。在图 5.9 中，如果接收方 B已收到第一个报文段，此时B希望收到的下一个报文段的数据是从第3个字节开始的，那么B发送给A的报文中的确认号字段应为3。发送方缓存区会继续存储那些已发送但未收到确认的报文段，以便在需要时重传。

TCP默认使用累计确认，即 TCP 只确认数据流中至第一个丢失字节为止的字节。例如，在图5.8中，接收方B收到了A发送的包含字节0～2及字节6~7的报文段。由于某种原因，B还未收到字节3～5 的报文段，此时B仍在等待字节3（和其后面的字节），因此B到A的下一个报文段将确认号字段置为3。

注意：

\1. 虽然A的发送窗口是根据B的接收窗口所设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样大。这是因为网络传送窗口值需要经历一定的时间滞后（这个时间还是不确定的，发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值）

\2. TCP通常对于不按顺序到达的数据是先临时存放在接收窗口当中，等到字节流中所缺少的字节收到后，再按序交付给上层的应用进程。

\3. TCP要求接收方必须具有立即确认功能，这样可以减小传输开销。TCP通信是全双工的，每一方都有自己的发送窗口有和接收窗口。

3.重传

有两种事件会导致 TCP 对报文段进行重传∶超时和冗余ACK。

（1）超时

TCP每发送一个报文段，就对这个报文段设置一次计时器。计时器设置的重传时间到期但还未收到确认时，就要重传这一报文段。

这种重传的概念很简单，但重传时间的选择却是TCP最复杂的问题之一。如果把超时重传时间设置的太短，就会引起很多报文段的不必要重传，是网络负荷增大；如果把超时重传时间设置太长，则又使网络的空闲时间增大，降低了传输效率。

由于 TCP的下层是一个互联网环境，IP 数据报所选择的路由变化很大，因而传输层的往返时延的方差也很大。为了计算超时计时器的重传时间，TCP采用一种自适应算法，它记录一个报文段发出的时间，以及收到相应确认的时间，这两个时间之差称为报文段的往返时间（Round-TripTime，RTT）。TCP保留了RTT的一个加权平均往返时间RTTs，它会随新测量RTT 样本值的变化而变化。显然，超时计时器设置的超时重传时间（Retransmission Time-Ou，RTO）应略大于RTTs，但也不能大太多，否则当报文段丢失时，TCP不能很快重传，导致数据传输时延大。

算法思想：更多的考虑以往的数据，结合这次新的数据，综合判断下一次超时重传时间的设置。

（2）冗余ACK（冗余确认）

超时触发重传存在的一个问题是超时周期往往太长。所幸的是，发送方通常可在超时事件发生之前通过注意所谓的冗余 ACK 来较好地检测丢包情况。冗余 ACK 就是再次确认某个报文段的ACK，而发送方先前已经收到过该报文段的确认。

例如，发送方A发送了序号为1、2、3、4、5的TCP报文段，其中2号报文段在链路中丢失，它无法到达接收方B。因此3、4、5号报文段对于B来说就成了失序报文段。TCP规定每当比期望序号大的失序报文段到达时，就发送一个冗余ACK，指明下一个期待字节的序号。

在本例中，3、4、5号报文到达B，但它们不是B所期望收到的下一个报文，于是B就发送3个对1号报文段的冗余ACK，表示自己期望接收2号报文段。

TCP规定当发送方收到对同一个报文段的3个冗余 ACK 时，就可以认为跟在这个被确认报文段之后的报文段已经丢失。就前面的例子而言，当A收到对于1号报文段的3个冗余ACK时，它可以认为2号文段已经丢失，这时发送方A可以立即对2号报文执行重传，这种技术通常称为快速重传。当然，冗余 ACK 还被用在拥塞控制中，这将在后面的内容中讨论。

5. TCP流量控制（针对接收方和发送发）

TCP提供流量控制服务来消除发送方（发送速率太快）使接收方缓存区溢出的可能性，因此可以说流量控制是一个速度匹配服务（是发送方的发送速率不要太快，要让接受方来得及接受）。

TCP提供一种基于滑动窗口协议的流量控制机制，滑动窗口的基本原理已在第3章的数据链路层介绍过，这里要介绍的是 TCP 如何使用窗口机制来实现流量控制。

在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，这称为接收窗口rwnd，即调整 TCP 报文段首部中的"窗口"字段值，来限制发送方向网络注入报文的速率。同时，发送方根据其对当前网络拥塞程度的估计而确定的窗口值，这称为拥塞窗口cwnd（后面会讲到），其大小与网络的带宽和时延密切相关。

例如，在通信中，有效数据只从A发往 B，而B仅向 A发送确认报文，这时B可以通过设置确认报文段首部的窗口字段来将 rwnd通知给 A。rwnd即接收方允许连续接收的最大能力，单位是字节。发送方A总是根据最新收到的 rwnd 值来限制自己发送窗口的大小，从而将未确认的数据量控制在rwnd大小之内，保证A不会使B的接收缓存溢出。当然，A 的发送窗口的实际大小取 rwnd 和cwnd中的最小值。

图 5.10 中的例子说明了如何利用滑动窗口机制进行流量控制。设A向B发送数据，在连接建立时，B告诉A∶"我的接收窗口rwnd= 400（字节）"。接收方进行了三次流量控制，这三个报文段都设置了ACK=1，只有在ACK=1时确认号字段才有意义。第一次把窗口减小到 rwnd=300，第二次把窗口减小到rwnd=100，最后把窗口减小到 rwnd=0，即不允许发送方再发送数据。这使得发送方暂停发送的状态将持续到B重新发出一个新的窗口值为止。

I 在最后一步当中，A是如何知道B的接收窗口大小呢？A给B发送数据，B给A回复得知。但此时A知道B的接收窗口rwnd为0，如果不采取措施的话,A肯定不会再给B发送数据了，（不论B的接收窗口大小是否发生改变），那么就会产生互相等待的死锁局面。如何解决呢？

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

输层和数据链路层的流量控制的区别是∶传输层定义端到端用户之间的流量控制，数据链路层定义两个中间的相邻结点的流量控制。另外，数据链路层的滑动窗口协议的窗口大小不能动态变化，传输层的则可以动态变化。

6. TCP 拥塞控制（针对整个链路）

拥塞控制是指防止过多的数据注入网络，保证网络中的路由器或链路不致过载。出现拥塞时，端点并不了解拥塞发生的细节，对通信连接的端点来说，拥塞往往表现为通信时延的增加。

拥塞控制与流量控制的区别∶

拥塞控制是让网络能够承受现有的网络负荷，是一个全局性的过程，涉及所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

相反，流量控制往往是指点对点的通信量的控制，是个端到端的问题（接收端控制发送端），它所要做的是抑制发送端发送数据的速率，以便使接收端来得及接收。

当然，拥塞控制和流量控制也有相似的地方，即它们都通过控制发送方发送数据的速率来达到控制效果。

例如，某个链路的传输速率为10Gb/s，某大型机向一台PC以1Gb/s 的速率传送文件，显然网络的带宽是足够大的，因而不存在拥塞问题，但如此高的发送速率将导致PC可能来不及接收，因此必须进行流量控制。但若有 100万台 PC 在此链路上以1Mb/s的速率传送文件，则现在的问题就变为网络的负载是否超过了现有网络所能承受的范围。

因特网建议标准定义了进行拥塞控制的4种算法∶慢开始、拥塞避免、快重传和快恢复。发送方在确定发送报文段的速率时，既要根据接收方的接收能力，又要从全局考虑不要使网络发生拥塞。因此，TCP协议要求发送方维护以下两个窗口∶

1）接收窗口rwnd，接收方根据目前接收缓存大小所许诺的最新窗口值，反映接收方的容量。由接收方根据其放在 TCP 报文的首部的窗口字段通知发送方。

2）拥塞窗口cwnd，发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络的当前容量。只要网络未出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入网络的分组数。

发送窗口：的上限值应取接收窗口 rwnd和拥塞窗口 cwnd 中较小的一个，即发送窗口的上限值 = min【rwnd， cwnd】

接收窗口：的大小可根据 TCP 报文首部的窗口字段通知发送方。

I 而发送方如何维护拥塞窗口呢?这就是下面讲解的慢开始和拥塞避免算法。

注意∶这里假设接收方总是有足够大的缓存空间，因而发送窗口大小由网络的拥塞程度决定，也就是说，可以将发送窗口等同为拥塞窗口。

1.慢开始和拥塞避免

（1）慢开始算法

在 TCP 刚刚连接好并开始发送TCP报文段时，先令拥塞窗口cwnd=1，即一个最大报文段长度MSS。每收到一个对新报文段的确认后，将cwnd加1，即增大一个MSS。用这样的方法逐步增大发送方的 cwnd，可使分组注入网络的速率更加合理。

例如，A向B发送数据，发送方先置拥塞窗口cwnd=1，A发送第一个报文段，A收到B对第一个报文段的确认后，把cwnd从1增大到2;于是A接着发送两个报文段，A收到B对这两个报文段的确认后，把 cwnd从2 增大到4，下次就可一次发送4个报文段。

慢开始的"慢"并不是指拥塞窗口cwnd 的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd= 1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd，这对防止网络出现拥塞是一个非常有力的措施。使用慢开始算法后，每经过一个传输轮次（即往返时延 RTT，并不是恒定的数值），cwnd 就会加倍，即cwnd 的大小指数式增长。这样，慢开始一直把 cwnd增大到一个规定的慢开始门限 sstresh（阈值），然后改用拥塞避免算法。

（2）拥塞避免算法

拥塞避免算法的思路：是让拥塞窗口cwnd 缓慢增大，具体做法是∶每经过一个往返时延 RTT 就把发送方的拥塞窗口cwnd加1，而不是加倍，使拥塞窗口cwnd按线性规律缓慢增长（即加法增大），这比慢开始算法的拥塞窗口增长速率要缓慢得多，使得网络比较不容易出现拥塞。

根据 cwnd 的大小执行不同的算法，可归纳如下∶
● 当 cwnd ● 当cwnd>ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
● 当 cwnd= ssthresh 时，既可使用慢开始算法，又可使用拥塞避免算法（通常做法）。

（3）网络拥塞的处理

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（未按时收到确认），就要把慢开始门限ssthresh 设置为出现拥塞时的发送方的 cwnd值的一半（但不能小于2）。然后把拥塞窗口cwnd 重新设置为1，执行慢开始算法。这样做的目的是迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-
中积压的分组处理完。慢开始和拥塞避免算法的实现过程如图5.11 所示。

● 初始时，拥塞窗口置为1，即 cwnd=1，慢开始门限置为16，即 ssthresh=16。
● 慢开始阶段，cwnd的初值为1，以后发送方每收到一个确认ACK，cwnd值加1，也即经过每个传输轮次（RTT），cwnd 呈指数规律增长。当拥塞窗口 cwnd 增长到慢开始门限ssthresh 时（即当cwnd=16 时），就改用拥塞避免算法，cwnd 按线性规律增长。
● 假定 cwnd=24时网络出现超时，更新ssthresh 值为12（即变为超时时cwnd 值的一半）cwnd 重置为1，并执行慢开始算法，当 cwnd=12 时，改为执行拥塞避免算法。

注意∶在慢开始（指数级增长）阶段，若 2cwnd>sstresh，则下一个RTT后的cwnd等于ssthresh，而不等于2cwnd，即cwnd不能跃过ssthresh值。如图5.11所示，在第16个轮次时cwnd=8、ssthresh=12，在第 17个轮次时 cwnd= 12，而不等于16。

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

拥塞避免并不能完全避免拥塞。利用以上措施要完全避免网络拥塞是不可能的。拥塞避免是指在拥塞避免阶段

把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

已经应答结束，那么其收到下一次发送窗口大小就应该是9.

2.快重传和快恢复

快重传和快恢复算法是对慢开始和拥塞避免算法的改进。

1）快重传

在上一节介绍的TCP可靠传输机制中，快重传技术使用了冗余ACK来检测丢包的发生。同样，冗余ACK 也用于网络拥塞的检测（丢了包当然意味着网络可能出现了拥塞）。快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。

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

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

当发送方连续收到三个重复的 ACK 报文时，直接重传对方尚未收到的报文段，而不必等待那个报文段设置的重传计时器超时。

2）快恢复

快恢复算法的原理如下∶当发送方连续收到三个冗余 ACK（即重复确认）时，执行"乘法减小"算法，把慢开始门限ssthresh设置为此时发送方cwnd 的一半。这是为了预防网络发生拥塞。但发送方现在认为网络很可能没有发生（严重）拥塞，否则就不会有几个报文段连续到达接收方，也不会连续收到重复确认。因此与慢开始不同之处是它把cwnd 值设置为慢开始门限 ssthresh 改变后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

由于跳过了拥塞窗口cwnd 从1起始的慢开始过程，所以被称为快恢复。快恢复算法的实现过程如图 5.12 所示，作为对比，虚线为慢开始的处理过程。

流量控制中，发送方发送数据的量由接收方决定，而在拥塞控制中，则由发送方自己通过检测网络状况来决定。

实际上，慢开始、拥塞避免、快重传和快恢复几种算法是同时应用在拥塞控制机制中。

四种算法使用的总结∶在 TCP连接建立和网络出现超时时，采用慢开始和拥塞避免算法;当发送方接收到冗余 ACK 时，采用快重传和快恢复算法。

在本节的最后，再次提醒读者∶接收方的缓存空间总是有限的。因此，发送方发送窗口的实际大小由流量控制和拥塞控制共同决定。当题目中同时出现接收窗口（rwnd）和拥塞窗口（cwnd）时，发送方实际的发送窗口大小是 由 rwnd和 cwnd中较小的那一个确定的。