5.1 运输层协议概述
5.1.1 进程之间的通信
- 运输层向应用层提供通信服务，属于面向通信部分的最高层、用户功能中的最低层。当网络边缘部分中的两台主机使用网络核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时只用到下三层的功能。
- 进行通信的实体是主机中的进程，是主机中的一个进程和另一台主机中的一个进程交换数据。两台主机进行通信就是两台主机中的应用进程互相通信。IP 协议虽然能把分组送到目的主机，但是分组还停留在主机的网络层，没有交付主机中的应用进程。从运输层的角度看，通信的真正端点不是主机，而是主机中的进程。端到端的通信是应用进程之间的通信。
- 运输层有个重要功能：复用和分用。复用指在发送方不同的应用进程可以使用同一个运输层协议传送数据，分用指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
- 运输层提供应用进程间的逻辑通信。逻辑通信的意思是：从应用层来看，只要把应用层报文交给运输层，运输层就可以把这报文传送到对方的运输层，好像这种通信就是沿水平方向直接传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接。
- 网络层为主机之间提供逻辑通信，运输层为应用进程之间提供端到端的逻辑通信。
- 根据应用程序的不同需求，运输层有不同的运输协议，即面向连接的 TCP 和无连接的 UDP。
- 运输层向高层用户屏蔽了下面网络核心的细节，使应用进程看见的是，好像在两个运输层实体之间有一条端到端的逻辑通信信道。当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的，但这种逻辑通信信道就相当于一条全双工的可靠信道。当运输层采用无连接的 UDP 协议时，这种逻辑通信信道仍然是一条不可靠信道。
5.1.2 运输层的两个主要协议
- TCP/IP 运输层的两个主要协议即：
- 用户数据报协议 UDP
- 传输控制协议 TCP
- 图 5-3 给出了这两种协议在协议栈中的位置。
- 在 TCP/IP 体系中，根据所使用的协议是 TCP 或 UDP，分别称之为 TCP 报文段或 UDP 用户数据报
- UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到 UDP 报文后，不需要回复。即使不提供可靠交付，但在某些情况下 UDP 仍是一种有效的工作方式。
- TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的、面向连接的运输服务，因此增加许多开销。使得协议数据单元的首部增大很多，占用许多的处理机资源。
- 表 5-1 给出了一些应用和应用层协议主要使用的运输层协议 (UDP 或 TCP)。
5.1.3 运输层的端口
- 复用：应用层的应用进程数据可以通过运输层再传送到网络层 (IP 层)。分用：运输层从网络层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程。
- 进程的创建和撤销是动态的，通信的一方几乎无法识别对方机器上的进程。需要利用目的主机提供的功能来识别终点，而不需要知道实现这个功能的进程是哪一个。
- 通信的终点是应用进程，只要把需要传送的报文交到目的主机某个合适的目的端口，剩下的工作就由 TCP 或 UDP 来完成。
- 在协议栈层间的抽象的协议端口是软件端口。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。
- 当运输层收到 IP 层交上来的运输层报文时，能够根据首部中的目的端口号把数据交付应用层的目的应用进程。
- 端口号只具有本地意义，是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网不同计算机中，相同的端口号是没有关联的。
- 两个计算机中的进程要互相通信，不仅必须知道对方的 IP 地址 (为了找到对方的计算机)，而且要知道对方的端口号 (为了找到对方计算机中的应用进程)。
- 运输层的端口号分为下面的两大类：
- 服务器端使用的端口号
- 最重要的一类叫熟知端口号或系统端口号。IANA 把这些端口号指派给了 TCP/IP 最重要的一些应用程序，让所有的用户都知道。当一种新的应用程序出现后，IANA 必须为它指派一个熟知端口，否则互联网上的其他应用进程就无法和它进行通信；
- 另一类叫做登记端口号。这类端口号是为没有熟知端口号的应用程序使用的。使用这类端口号必须在 IANA 按照规定的手续登记，以防止重复。
- 客户端使用的端口号 这类端口号仅在客户进程运行时才动态选择，又叫短暂端口号。这类端口号留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的端口号，因而可以把数据发送给客户进程。通信结束后，刚才已使用过的客户端口号就不复存在，这个端口号就可以供其他客户进程使用。
- 服务器端使用的端口号
5.2 用户数据报协议 UDP
5.2.1 UDP 概述
- 用户数据报协议 UDP 在 IP 的数据报服务之上增加了复用、分用以及差错检测的功能。UDP 的主要特点是：
- UDP 是无连接的，即发送数据之前不需要建立连接，减少了开销和发送数据之前的时延。
- UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
- UDP 面向报文。发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文，如图 5-4 所示。在接收方的 UDP，对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程。UDP 一次交付一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长，UDP 把它交给 IP 层后，IP 层在传送时可能要进行分片，会降低 IP 层的效率。若报文太短，UDP 把它交给 IP 层后，会使 IP 数据报的首部的相对长度太大，降低了 IP 层的效率。
- UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。很多的实时应用 (如 IP 电话、实时视频会议等) 要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但不允许数据有太大的时延。
- UDP 支持一对一、一对多、多对一和多对多的交互通信。
- UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。
5.2.2 UDP 的首部格式
- 用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段很简单，只有 8 个字节 (图 5-5)，由四个字段组成，每个字段的长度都是两字节 。各字段意义如下：
- 源端口 源端口号。在需要对方回信时选用。不需要时可用全 0。
- 目的端口 目的端口号。这在终点交付报文时必须使用。
- 长度 UDP 用户数据报的长度，其最小值是 8 (仅有首部)。
- 检验和 检测 UDP 用户数据报在传输中是否有错。有错就丢弃。
- 当运输层从 IP 层收到 UDP 数据报时，根据首部中的目的端口，把 UDP 数据报通过相应的端口，上交最后的终点——应用进程。图 5-6 是 UDP 基于端口分用的示意图。
- 如果接收方 UDP 发现收到的报文中的目的端口号不正确，就丢弃该报文，并由网际控制报文协议 ICMP 发送“端口不可达”差错报文给发送方。
- 虽然在 UDP 之间的通信要用到端口号，但由于 UDP 的通信是无连接的，因此不需要使用套接字 (TCP 之间的通信必须要在两个套接字之间建立连接)。
- UDP 计算检验和的方法和计算 IP 数据报首部检验和的方法相似。但 IP 数据报的检验和只检验 IP 数据报的首部，UDP 的检验和是把首部和数据部分一起都检验。在发送方，首先把全零放入检验和字段。再把伪首部以及 UDP 用户数据报看成是由许多 16 位的字串接起来的。若 UDP 用户数据报的数据部分不是偶数个字节，则要填入一个全零字节 (但此字节不发送)。然后按二进制反码计算出这些 16 位字的和。将此和的二进制反码写入检验和字段后，就发送这样的 UDP 用户数据报。在接收方，把收到的 UDP 用户数据报连同伪首部 (以及可能的填充全零字节) 一起，按二进制反码求这些 16 位字的和。当无差错时其结果应为全 1。否则就表明有差错出现，接收方就应丢弃这个 UDP 用户数据报 (也可以上交给应用层，但附上出现了差错的警告)。图 5-7 给出了一个计算 UDP 检验和的例子。这里假定用户数据报的长度是 15 字节，因此要添加一个全 0 的字节。这种简单的差错检验方法的检错能力并不强，但它的好处是简单，处理起来较快。
5.3 传输控制协议 TCP 概述
5.3.1 TCP 最主要的特点
- TCP 的主要特点：
- TCP 是面向连接的运输层协议。应用程序在使用 TCP 协议之前，必须先建立 TCP 连接。在传送数据完毕后，必须释放已经建立的 TCP 连接。
- 每一条 TCP 连接只能有两个端点，只能是点对点的 (一对一)。
- TCP 提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复，并且按序到达。
- TCP 提供全双工通信。允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序只需要把数据传送给 TCP 的缓存，TCP 把数据发送出去。在接收时，TCP 把收到的数据放入缓存，上层的应用进程读取缓存中的数据。
- 面向字节流。TCP 中的“流”指的是流入到进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块 (大小不等)，但 TCP 把应用程序交下来的数据仅仅看成一连串的无结构的字节流。并不知道所传送的字节流的含义。TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。
- TCP 和 UDP 在发送报文时采用的方式不同。TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段包含多少个字节 (UDP 发送的报文长度是应用进程给出的)。如果应用进程传送到 TCP 缓存的数据块太长，TCP 就把它划分短一些再传送。如果应用进程一次只发来一个字节，TCP 也可以等待积累有足够多的字节后再构成报文段发送出去。
5.3.2 TCP 的连接
- TCP 连接的端点不是主机，不是主机的 IP 地址，不是应用进程，也不是运输层的协议端口，而是套接字或插口。
- 每一条 TCP 连接唯一地被通信两端的两个端点 (即两个套接字) 所确定。即：
- IP1 和 IP2 分别是两个端点主机的 IP 地址，而 port1 和 port2 分别是两个端点主机中的端口号。TCP 连接的两个套接字就是 socket1 和 socket2。
- TCP 连接的端点是个抽象的套接字，即 (IP地址：端口号 )。同一个 IP 地址可以有多个不同的 TCP 连接，同一个端口号也可以出现在多个不同的 TCP 连接中。
- socket 表示多种不同的意思。例如：
- 允许应用程序访问连网协议的应用编程接口 API，即运输层和应用层之间的一种接口，称为 socket API，并简称为 socket。
- 在 socket API 中使用的一个函数名也叫做 socket。
- 调用 socket 函数的端点称为 socket，如“创建一个数据报 socket”。
- 调用 socket 函数时，其返回值称为 socket 描述符，可简称为 socket。
- 在操作系统内核中连网协议的 Berkeley 实现，称为 socket 实现。
5.4 可靠传输的工作原理
- 理想的传输条件有以下特点：
- 传输信道不产生差错。
- 接收方总是来得及处理收到的数据。
5.4.1 停止等待协议
- 无差错情况
- 停止等待协议可用图 5-9 来说明。图 5-9(a) 是最简单的无差错情况。A 发送分组 M1 ，发完暂停，等待 B 确认。B 收到了 M1 就向 A 发送确认。A 在收到了对确认后，就再发送下一个分组 M2。同样，在收到 B 确认后，再发送M3。
- 停止等待协议可用图 5-9 来说明。图 5-9(a) 是最简单的无差错情况。A 发送分组 M1 ，发完暂停，等待 B 确认。B 收到了 M1 就向 A 发送确认。A 在收到了对确认后，就再发送下一个分组 M2。同样，在收到 B 确认后，再发送M3。
- 出现差错
- 图 5-9(b) 是分组在传输过程中出现差错的情况。B 接收 M1 时检测出了差错，丢弃 M1，其他什么也不做。这种情况下，B 不会发送任何信息。可靠传输协议是这样设计的：A 只要超过了一段时间没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。要实现超时重传，就要在每发送完一个分组时设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。
- 注意以下三点。
- A 在发送完一个分组后，必须保留已发送的分组的副本。只有在收到相应的确认后才能清除保留的分组副本。
- 分组和确认分组都必须进行**编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
- 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。图 5-9(b) 中的一段虚线表示如果 M1 正确到达 B 同时 A 也正确收到确认的过程。重传时间应设定为比平均往返时间更长一些。如果重传时间设定得很长，那么通信的效率会很低。但如果重传时间设定得太短，以致产生不必要的重传，就浪费了网络资源。然而，在运输层重传时间的准确设定是非常复杂的，这是因为已发送出的分组到底会经过哪些网络，以及这些网络将会产生多大的时延 (这取决于这些网络当时的拥塞情况)，这些都是不确定因素。
- 确认丢失和确认迟到
- 图 5-10(a) 说明的是另一种情况。B 所发送的对 M1 的确认丢失了。A 在设定的超时重传时间内没有收到确认，无法知道是自己发送的分组出错、丢失，或者是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。假定 B 又收到了重传的分组 M1
- 这时应采取两个行动：
- 丢弃这个重复的分组 M1，不向上层交付。
- 向 A 发送确认。不能认为已经发送过确认就不再发送，因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认。
- 图 5-10(b) 也是一种可能出现的情况。传输过程中没有出现差错，但 B 对分组 M1 的确认迟到了。A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B 仍然会收到重复的 M1 ，并且同样要丢弃重复的 M1，并重传确认分组。
- 图 5-10(a) 说明的是另一种情况。B 所发送的对 M1 的确认丢失了。A 在设定的超时重传时间内没有收到确认，无法知道是自己发送的分组出错、丢失，或者是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。假定 B 又收到了重传的分组 M1
- 信道利用率
- 停止等待协议的优点是简单，缺点是信道利用率太低。可以用图 5-11 来说明这个问题。
- 假定 A 发送分组需要的时间是 TD。TD 等于分组长度除以数据率。再假定分组正确到达 B 后，B 处理分组的时间忽略不计，同时立即发回确认。假定 B 发送确认分组需要时间 TA。如果 A 处理确认分组的时间也忽略不计，那么 A 在经过时间 (TD＋RTT＋TA) 后就可以再发送下一个分组，这里的 RTT 是往返时间。因为仅仅是在时间 TD 内才用来传送有用的数据 (包括分组的首部)，因此信道的利用率 U 可用下式计算：
- 为了提高传输效率，发送方不使用低效率的停止等待协议，采用流水线传输 (如图 5-12 所示)。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。这种传输方式可以获得很高的信道利用率。
- 停止等待协议的优点是简单，缺点是信道利用率太低。可以用图 5-11 来说明这个问题。
5.4.2 连续 ARQ 协议
- 图 5-13(a) 表示发送方维持的发送窗口，表示位于发送窗口内的 5 个分组可连续发送出去，不需要等待对方的确认。提高了信道利用率。
- 连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。图 5-13(b) 表示发送方收到了对第 1 个分组的确认，于是把发送窗口向前移动一个分组的位置。
- 接收方采用累积确认的方式，对按序到达的最后一个分组发送确认。
- 累积确认有优点也有缺点：
- 优点是容易实现，即使确认丢失也不必重传。
- 缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。
5.5 TCP 报文段的首部格式
- TCP 面向字节流，但 TCP 传送的数据单元却是报文段。
- 一个 TCP 报文段分为首部和数据两部分。
- TCP 报文段首部的前 20 个字节是固定的 (图 5-14)，后面有 4n 字节是根据需要而增加的选项。因此 TCP 首部的最小长度是 20 字节。
- 首部固定部分各字段的意义如下：
- 源端口和目的端口 各占 2 个字节，分别写入源端口号和目的端口号。
- 序号 占 4 字节。序号范围是［0，232–1］，共 232 (即4 294 967 296) 个序号。序号增加到 232–1 后，下一个序号就又回到 0。使用 mod 232 运算。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号在连接建立时设置。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号字段值是 301，而携带的数据共有 100 字节。这就表明：本报文段的数据的第一个字节的序号是 301，最后一个字节的序号是 400。字段的名称也叫做“报文段序号”。
- 确认号 占 4 字节，是期望收到对方下一个报文段的第一个数据字节的序号。例如，B 收到 A 发来的一个报文段，其序号字段值是 501，而数据长度是 200 字节 (序号 501～700)，这表明 B 收到到序号 700 为止的数据。因此，B 期望收到的下一个数据序号是 701，于是 B 在发送给 A 的确认报文段中把确认号置为 701。若确认号＝N，则表明：到序号 N–1 为止的所有数据都已正确收到。
- 数据偏移 占 4 位，指出 TCP 报文段的首部长度。“数据偏移”的单位是 4 字节 (即以 32 位字为计算单位)。由于 4 位二进制数能够表示的最大十进制数字是 15，因此数据偏移的最大值是 60 字节，这也是 TCP 首部的最大长度 (即选项长度不能超过 40 字节)。
- 保留 占 6 位，保留为今后使用，但目前应置为 0。
- 紧急 URG 当 URG＝1 时，紧急指针字段有效，发送应用进程告诉发送方的 TCP 有紧急数据要传送。于是发送方 TCP 把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。这时要与首部中紧急指针字段配合使用。
- 确认 ACK 当 ACK＝1 时确认号字段有效。当 ACK＝0 时，确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
- (x) 推送 PSH 当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，TCP 使用推送操作。这时，发送方 TCP 把 PSH 置 1，并立即创建一个报文段发送出去。接收方 TCP 收到 PSH＝1 的报文段，就尽快地交付接收应用进程，不再等到整个缓存都填满了后再向上交付。
- 复位 RST 当 RST＝1 时，表明 TCP 连接中出现严重差错，必须释放连接，然后再重新建立运输连接。RST 置 1 还用来拒绝一个非法的报文段或拒绝打开一个连接。RST 也可称为重建位或重置位。
- 同步 SYN 在连接建立时用来同步序号。当 SYN＝1 而 ACK＝0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN＝1 和 ACK＝1。因此，SYN 置为 1 就表示这是一个连接请求或连接接受报文。
- 终止 FIN 用来释放一个连接。当 FIN＝1 时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
- 窗口 占 2 字节。窗口值是［0，216–1］之间的整数。窗口指的是发送本报文段的一方的接收窗口。窗口值告诉对方 ：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量 (以字节为单位)。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。窗口值作为接收方让发送方设置其发送窗口的依据。窗口字段明确指出了现在允许对方发送的数据量，经常动态变化。
- (x) 检验和 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。和 UDP 用户数据报一样，在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。伪首部的格式与图 5-5 中 UDP 用户数据报的伪首部一样。但应把伪首部第 4 个字段中的17 改为 6（TCP 的协议号是 6），把第 5 字段中的 UDP 长度改为 TCP 长度。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。若使用 IPv6，则相应的伪首部也要改变。
- (x) 紧急指针 占 2 字节。紧急指针仅在 URG＝1 时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。因此，紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP 就告诉应用程序恢复到正常操作。值得注意的是，即使窗口为零时也可发送紧急数据。
- 选项 长度可变，最长可达 40 字节。
- TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 是每一个 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。所以 MSS 并不是整个 TCP 报文段的最大长度，而是“TCP 报文段长度减去 TCP 首部长度”。
- 随着互联网的发展，又增加了窗口扩大选项、时间戳选项、选择确认选项。
- 窗口扩大选项
- 窗口扩大选项是为了扩大窗口。TCP 首部中窗口字段长度是 16 位，因此最大的窗口大小为 64K 字节。
- 窗口扩大选项占 3 字节，其中有一个字节表示移位值 S。新的窗口值等于 TCP 首部中的窗口位数从 16 增大到 (16＋S) 。移位值允许使用的最大值是 14，相当于窗口最大值增大到 2(16+14)–1＝230 –1。
- 窗口扩大选项可以在双方初始建立 TCP 连接时进行协商。如果接的某一端实现了窗口扩大，当它不再需要扩大其窗口时，可发送 S＝0 的选项，使窗口大小回到 16。
- 时间戳选项
- 时间戳选项占 10 字节，最主要的字段是时间戳值字段 (4 字节) 和时间戳回送回答字段 (4 字节)。时间戳选项有以下两个功能：
- 用来计算往返时间 RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段值复制到时间戳回送回答字段。因此，发送方在收到确认报文后，可以准确地计算出 RTT 来。
- 用于处理 TCP 序号超过 232 的情况，又称防止序号绕回 PAWS。TCP 报文段的序号只有 32 位，而每增加 232 个序号就会重复使用原来用过的序号。当使用高速网络时，在一次 TCP 连接的数据传送中序号很可能会被重复使用。
- 时间戳选项占 10 字节，最主要的字段是时间戳值字段 (4 字节) 和时间戳回送回答字段 (4 字节)。时间戳选项有以下两个功能：
- 窗口扩大选项
5.6 TCP 可靠传输的实现
5.6.1 以字节为单位的滑动窗口
- TCP 的滑动窗口以字节为单位。假定 A 收到了 B 发来的确认报文段，其中窗口是 20 字节，而确认号是 31 (这表明 B 期望收到的下一个序号是 31，而序号 30 为止的数据已经收到了)。根据这两个数据，A 就构造出自己的发送窗口，如图 5-15 所示。
- A 发送窗口表示：在没有收到 B 的确认的情况下，A 可以把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
- 发送窗口里面的序号表示允许发送的序号。窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，获得更高的传输效率。接收方会把自己的接收窗口数值放在窗口字段中发送给对方，A 的发送窗口一定不能超过 B 的接收窗口数值。
- 发送窗口后沿的后面部分表示已发送且已收到了确认。这些数据不需要保留。而发送窗口前沿的前面部分表示不允许发送的，因为接收方没有为这部分数据保留临时存放的缓存空间。
- 发送窗口的位置由窗口前沿和后沿的位置共同确定。发送窗口后沿的变化情况有两种可能，即不动 (没有收到新的确认) 和前移 (收到了新的确认)。发送窗口后沿不可能向后移动，因为不能撤销掉已收到的确认。发送窗口前沿通常是不断向前移动，但也有可能不动。这对应于两种情况：一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。
- 发送窗口前沿也有可能向后收缩。这发生在接收方的接收窗口缩小了。但 TCP 的标准强烈不赞成这样做。因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在又要收缩窗口，不让发送这些数据，这样就会产生一些错误。
- 发送方的应用进程把字节流写入 TCP 的发送缓存，接收方的应用进程从 TCP 的接收缓存中读取字节流。图 5-19 画出了发送方维持的发送缓存和发送窗口，以及接收方维持的接收缓存和接收窗口。
- 图 5-19(a) 所示的发送方的情况，发送缓存用来暂时存放：
- 发送应用程序传送给发送方 TCP 准备发送的数据
- TCP 已发送出但尚未收到确认的数据
- 图 5-19(b) 所示的接收方的情况，接收缓存用来暂时存放：
- 按序到达的、但尚未被接收应用程序读取的数据
- 未按序到达的数据。
- 强调以下三点：
- 虽然 A 的发送窗口是根据 B 的接收窗口设置的，但在同一时刻，A 的发送窗口并不总是和 B 的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后。
- 对于不按序到达的数据如何处理，TCP 标准并无明确规定。如果接收方把不按序到达的数据丢弃，那么接收窗口的管理会比较简单，但这样做对网络资源的利用不利。因此 TCP 通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
- TCP 要求接收方必须有累积确认的功能，减小传输开销。接收方可以在合适时发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。注意两点。一是接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。TCP 标准规定，确认推迟的时间不应超过 0.5 秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认。二是捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
- TCP 的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。
5.6.2 超时重传时间的选择
- 由于 TCP 的下层是互联网环境，发送的报文段可能只经过一个高速率的局域网，也可能经过多个低速率的网络，并且每个 IP 数据报所选择的路由可能不同。如果把超时重传时间设置得太短，会引起很多报文段的不必要的重传，使网络负荷增大。但若把超时重传时间设置得过长，则使网络的空闲时间增大，降低了传输效率。
- TCP 采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。两个时间之差就是报文段的往返时间 RTT。TCP 保留了 RTT 的一个加权平均往返时间 RTTS (又称为平滑的往返时间，S 表示 Smoothed)。每当第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。但以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS：
- 在上式中，0≤α<1。若 α 很接近于零，表示新的 RTTS 值和旧的 RTTS 值相比变化不大，而对新的 RTT 样本影响不大 (RTT 值更新较慢)。若选择 α 接近于 1，则表示新的 RTTS 值受新的 RTT 样本的影响较大 (RTT 值更新较快)。
- 超时计时器设置的超时重传时间 RTO 应略大于上面得出的加权平均往返时间 RTTS 。RFC 6298 建议使用下式计算 RTO：
- RTTD 是 RTT 的偏差的加权平均值，它与 RTTS 和新的 RTT 样本之差有关。RFC 6298 建议这样计算 RTTD。当第一次测量时，RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTTD：
- 如图 5-20 所示，发送出一个报文段，设定的重传时间到了，还没有收到确认。于是重传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认。由于重传的报文段和原来的报文段完全一样，因此源主机在收到确认后，就无法做出正确的判断，而正确的判断对确定加权平均 RTTS 的值关系很大。
- 若收到的确认是对重传报文段的确认，却被源主机当成是对原来的报文段的确认，则这样计算出的 RTTS 和超时重传时间 RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间 RTO 就越来越长；同样，若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTS 和 RTO 都会偏小。这就必然导致报文段过多地重传使，RTO 越来越短。
- Karn 提出了一个算法：在计算加权平均 RTTS 时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均 RTTS 和 RTO 就较准确。
- 但是，这又引起新的问题：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据 Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。
- 因此要对 Karn 算法进行修正。方法是：报文段每重传一次，就把超时重传时间 RTO 增大一些。典型的做法是取新的重传时间为旧的重传时间的 2 倍。当不再发生报文段的重传时，才根据上面给出的 (5-5) 式计算超时重传时间。
- Karn 算法能够使运输层区分开有效的和无效的往返时间样本，从而改进了往返时间的估测，使计算结果更加合理。
5.6.3 选择确认 SACK
- 选择确认的工作原理。TCP 的接收方在接收对方发送过来的数据字节流的序号不连续时会形成一些不连续的字节块 (如图 5-21 所示)。序号 1～1000 收到了，但序号 1001～1500 没有收到。接下来的字节流又收到了，缺少了 3001～3500。再后面从序号 4501 起又没有收到。接收方收到了和前面的字节流不连续的两个字节块。如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。
- 从图 5-21 可看出，与前后字节不连续的每一个字节块都有两个边界：左边界和右边界。因此在图中用四个指针标记这些边界。第一个字节块的左边界 L1 ＝1501，右边界 R1 ＝3001 而不是 3000。左边界指出字节块的第一个字节的序号，但右边界减 1 才是字节块中的最后一个序号。同理，第二个字节块的左边界 L2 ＝3501，而右边界 R2 ＝4501。
5.7 TCP 的流量控制
5.7.1 利用滑动窗口实现流量控制
- 流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。
- 发送方的发送窗口不能超过接收方给出的接收窗口的数值。
- TCP 的窗口单位是字节，不是报文段。
- TCP 为每一个连接设有一个持续计时器。只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段，而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。
5.7.2 TCP 的传输效率
- 用不同的机制来控制 TCP 报文段的发送时机：
- TCP 维持一个等于最大报文段长度 MSS 的变量。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
- 由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送操作。
- 发送方的一个计时器期限到了时，就把当前已有的缓存数据装入报文段 (但长度不能超过MSS) 发送出去。
- 在 TCP 的实现中广泛使用 Nagle 算法。算法如下：
- 若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。
- 当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。
- 只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，可明显地减少所用的网络带宽。
- 当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段，可以有效地提高网络的吞吐量。
- 糊涂窗口综合征，有时会使 TCP 的性能变坏。当 TCP 接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取 1 个字节 (这样就使接收缓存空间仅腾出 1 个字节)，然后向发送方发送确认，并把窗口设置为 1 个字节 (但发送的数据报是 40 字节长)。接着，发送方又发来 1 个字节的数据 (请注意，发送方发送的 IP 数据报是 41 字节长)。接收方发回确认，仍然将窗口设置为 1 个字节。这样进行下去，使网络的效率很低。
- 解决糊涂窗口综合征需要让接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。
5.8 TCP 的拥塞控制
5.8.1 拥塞控制的一般原理
- 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。可以把出现网络拥塞的条件写成如下的关系式：
- 若网络中有许多资源同时呈现供应不足，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。
- 网络拥塞由许多因素引起：
- 当某个结点缓存的容量太小时，到达该结点的分组因无存储空间暂存而不得不被丢弃。
- 由于输出链路的容量和处理机的速度并未提高，因此在这队列中的绝大多数分组的排队等待时间将会大大增加，上层软件只能重传。
- 处理机处理的速率太慢可能引起网络的拥塞。
- 拥塞常常趋于恶化。如果一个路由器没有足够的缓存空间，就会丢弃一些新到的分组。但当分组被丢弃时，发送这一分组的源点就会重传这一分组，甚至可能还要重传多次，导致更多的分组流入网络和被网络中的路由器丢弃。
- 拥塞控制防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。拥塞控制要做的有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。但 TCP 连接的端点只要迟迟不能收到对方的确认信息，就猜想在当前网络中的某处很可能发生了拥塞，但无法知道拥塞到底发生在网络的何处，也无法知道发生拥塞的具体原因。
- 流量控制往往指点对点通信量的控制，是个端到端的问题 (接收端控制发送端)。流量控制所要做的就是抑制发送端发送数据的速率，使接收端来得及接收。
- 进行拥塞控制需要付出代价。首先需要获得网络内部流量分布的信息。在实施拥塞控制时，还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制，产生了额外开销。拥塞控制有时需要将一些资源 (如缓存、带宽等) 分配给个别用户单独使用，使得网络资源不能更好地实现共享。
- 拥塞控制所起的作用
- 在图 5-23 中的横坐标是提供的负载，代表单位时间内输入给网络的分组数目。因此提供的负载也称为输入负载或网络负载。纵坐标是吞吐量，代表单位时间内从网络输出的分组数目。
- 具有理想拥塞控制的网络，在吞吐量饱和之前，网络吞吐量应等于提供的负载，故吞吐量曲线是 45° 的斜线。但当提供的负载超过某一限度时，由于网络资源受限，吞吐量不再增长而保持为水平线，即吞吐量达到饱和。这就表明提供的负载中有一部分损失掉了。
- 实际网络的情况就很不相同了。从图 5-23 可看出，随着提供的负载的增大，网络吞吐量的增长速率逐渐减小。也就是说，在网络吞吐量还未达到饱和时，就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显地小于理想的吞吐量时，网络就进入了轻度拥塞的状态。更值得注意的是，当提供的负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这时网络就进入了拥塞状态。当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络已无法工作，这就是所谓的死锁。
- 从原理上讲，寻找拥塞控制的方案是寻找使不等式 (5-7) 不再成立的条件。或者是增大网络的某些可用资源，或减少一些用户对某些资源的需求。
- 开环控制是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。但一旦整个系统运行起来，就不再中途进行改正。
- 闭环控制是基于反馈环路的概念，主要有以下几种措施：
- 监测网络系统以便检测到拥塞在何时、何处发生。
- 把拥塞发生的信息传送到可采取行动的地方。
- 调整网络系统的运行以解决出现的问题。
- 过于频繁地采取行动以缓和网络的拥塞，会使系统产生不稳定的振荡。但过于迟缓地采取行动又不具有任何实用价值。
5.8.2 TCP 的拥塞控制方法
- TCP 进行拥塞控制的算法有四种，慢开始、拥塞避免、快重传和快恢复。
- 发送方维持一个叫拥塞窗口 cwnd 的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口等于拥塞窗口。
- 发送方控制拥塞窗口的原则：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。
- 慢开始算法的思路：当主机开始发送数据时，由于并不清楚网络的负荷情况，如果立即把大量数据字节注入到网络，可能引起网络发生拥塞。应该由小到大逐渐增大发送窗口，由小到大逐渐增大拥塞窗口数值。
- 旧的规定是这样的：在刚刚开始发送报文段时，先把初始拥塞窗口 cwnd 设置为 1 至 2 个发送方的最大报文段 SMSS 的数值，但新的 RFC 5681 把初始拥塞窗口 cwnd 设置为不超过 2 至 4 个 SMSS 的数值。具体的规定如下：
- 若 SMSS>2190 字节，则设置初始拥塞窗口 cwnd＝2×SMSS 字节，且不得超过 2 个报文段。
- 若 SMSS>1095 字节 且 SMSS≤2190 字节，则设置初始拥塞窗口 cwnd＝3×SMSS 字节，且不得超过 3 个报文段。
- 若 SMSS≤1095 字节，则设置初始拥塞窗口 cwnd＝4×SMSS 字节，且不得超过 4 个报文段。
- 慢开始规定，在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS 的数值。
- 其中 N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。
- 在一开始发送方先设置 cwnd＝1，发送第一个报文段 M1，接收方收到后确认 M1。发送方收到对 M1 的确认后，把 cwnd 从 1 增大到 2，于是发送方接着发送 M2 和 M3 两个报文段。接收方收到后发回对 M2 和 M3 的确认。发送方每收到一个对新报文段的确认就使发送方的拥塞窗口加 1，因此发送方在收到两个确认后，cwnd 就从 2 增大到 4，并可发送 M4～M7 共 4 个报文段 (见图 5-24)。因此使用慢开始算法后，每经过一个传输轮次，拥塞窗口 cwnd 就加倍。
- 传输轮次。从图 5-24 可以看出，一个传输轮次所经历的时间就是往返时间 RTT。使用“传输轮次”是强调：把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。例如，拥塞窗口 cwnd 的大小是 4 个报文段，那么这时的往返时间 RTT 就是发送方连续发送 4 个报文段，并收到这4个报文段的确认，总共经历的时间。
- 为了防止拥塞窗口 cwnd 增长过大引起网络拥塞，还需要设置一个慢开始门限 ssthresh 状态变量。慢开始门限 ssthresh 的用法如下：
- 当 cwnd<ssthresh 时，使用上述的慢开始算法。
- 当 cwnd>ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
- 当 cwnd=ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。
- 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有“加法增大”AI 的特点。这表明在拥塞避免阶段，拥塞窗口 cwnd 按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
- 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
- 快重传算法规定，发送方只要一连收到 3 个重复确认，就知道接收方确实没有收到报文段 M3，因而应当立即进行重传 (即“快重传”)，这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。使用快重传可以使整个网络的吞吐量提高约 20％。
- TCP 的拥塞控制可以归纳为图 5-27 的流程图。
- 接收方的缓存空间有限，根据自己的接收能力设定了接收方窗口 rwnd，并把这个窗口值写入 TCP 首部中的窗口字段，传送给发送方。因此，接收方窗口又称为通知窗口。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收方窗口值 rwnd。
- 如果把拥塞控制和接收方对发送方的流量控制一起考虑，那么发送方的窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个，也就是说：
- 当 rwnd<cwnd 时，是接收方的接收能力限制发送方窗口的最大值。
- 当 cwnd<rwnd 时，则是网络的拥塞程度限制发送方窗口的最大值。
- rwnd 和 cwnd 中数值较小的一个，控制了发送方发送数据的速率。
5.8.3 主动队列管理 AQM
- 网络层的策略对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略。在最简单的情况下，路由器的队列通常都是按照“先进先出” FIFO 的规则处理到来的分组。由于队列长度有限，因此当队列已满时，以后再到达的所有分组将都被丢弃，这叫尾部丢弃策略。
- 路由器的尾部丢弃会导致一连串分组的丢失，使发送方出现超时重传、TCP 进入拥塞控制的慢开始状态，使 TCP 连接的发送方突然把数据的发送速率降低到很小的数值。更为严重的是，在网络中通常有很多的 TCP 连接，这些连接中的报文段通常是复用在网络层的 IP 数据报中传送。在这种情况下，若发生了路由器中的尾部丢弃，可能会同时影响到很多条 TCP 连接，使许多 TCP 连接在同一时间突然都进入到慢开始状态。这在 TCP 的术语中称为全局同步。全局同步使得全网的通信量突然下降了很多，而在网络恢复正常后，其通信量又突然增大很多。
- 为了避免发生网络中的全局同步现象，提出了主动队列管理 AQM。所谓“主动”是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。应当在队列长度达到某个值得警惕的数值时 (即当网络拥塞有了某些拥塞征兆时)，就主动丢弃到达的分组。这样就提醒了发送方放慢发送的速率，可能使网络拥塞的程度减轻，甚至不出现网络拥塞。
- 实现随机早期检测 RED 时需要使路由器维持两个参数，即队列长度最小门限和最大门限。当每一个分组到达时，RED 就按照规定的算法先计算当前的平均队列长度。
- 若平均队列长度小于最小门限，则把新到达的分组放入队列进行排队。
- 若平均队列长度超过最大门限，则把新到达的分组丢弃。
- 若平均队列长度在最小门限和最大门限之间，则按照某一丢弃概率 p 把新到达的分组丢弃 (这就体现了丢弃分组的随机性)。
- RED 不是等到已经发生网络拥塞后才把所有在队列尾部的分组全部丢弃，而是在检测到网络拥塞的早期征兆时 (即路由器的平均队列长度达到一定数值时)，就以概率 p 丢弃个别的分组，让拥塞控制只在个别的 TCP 连接上进行，因而避免发生全局性的拥塞控制。
5.9 TCP 的运输连接管理
- TCP 是面向连接的协议。运输连接是用来传送 TCP 报文的。TCP 运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段，即：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。
- TCP 连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。
5.9.1 TCP 的连接建立
- TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段。图 5-28 画出了三报文握手建立 TCP 连接的过程。
- A 的 TCP 客户进程也是首先创建传输控制模块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN＝1，同时选择一个初始序号 seq＝x。TCP 规定，SYN 报文段(即 SYN＝1 的报文段) 不能携带数据，但要消耗掉一个序号。这时，TCP 客户进程进入 SYN-SENT (同步已发送) 状态。
- B 收到连接请求报文段后，如同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack＝x＋1，同时也为自己选择一个初始序号 seq＝y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时 TCP 服务器进程进入 SYN-RCVD (同步收到) 状态。
- TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack＝y＋1，而自己的序号 seq＝x＋1。TCP 的标准规定，ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq＝x＋1。这时，TCP 连接已经建立，A 进入 ESTABLISHED (已建立连接) 状态。
- 当 B 收到 A 的确认后，也进入 ESTABLISHED 状态。
5.9.2 TCP 的链接释放
- 数据传输结束后，通信的双方都可释放连接。现在 A 和 B 都处于 ESTABLISHED 状态 (图 5-29)。A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq＝u，它等于前面已传送过的数据的最后一个字节的序号加 1。这时 A 进入 FIN-WAIT-1 (终止等待 1)状态，等待 B 的确认。TCP 规定，FIN 报文段即使不携带数据，它也消耗掉一个序号。
图 5-29- B 收到连接释放报文段后即发出确认，确认号是 ack＝u＋1，而这个报文段自己的序号是 v，等于 B 前面已传送过的数据的最后一个字节的序号加 1。然后 B 就进入 CLOSE-WAIT (关闭等待) 状态。TCP 服务器进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。
- A 收到来自 B 的确认后，就进入 FIN-WAIT-2 (终止等待2) 状态，等待 B 发出的连接释放报文段。
- 若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN＝1。假定 B 的序号为 w (在半关闭状态 B 可能又发送了一些数据)。B 还必须重复上次已发送过的确认号 ack＝u＋1。这时 B 就进入 LAST-ACK (最后确认) 状态，等待 A 的确认。
- A 在收到 B 的连接释放报文段后，对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack＝w＋1，而自己的序号是 seq＝u＋1 (根据 TCP 标准，前面发送过的 FIN 报文段要消耗一个序号)。然后进入到 TIME-WAIT (时间等待) 状态。现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL 后，A 才进入到 CLOSED 状态。时间 MSL 叫做最长报文段寿命。从 A 进入到 TIME-WAIT 状态后，要经过 4 分钟才能进入到 CLOSED 状态，才能开始建立下一个新的连接。当 A 撤销相应的传输控制块 TCB 后，就结束了 TCP 连接。
5.9.3 TCP 的有限状态机
- 为了更清晰地看出 TCP 连接的各种状态之间的关系，图 5-30 给出了 TCP 的有限状态机。图中每一个方框即 TCP 可能具有的状态。每个方框中的大写英文字符串是 TCP 标准所使用的TCP 连接状态名。状态之间的箭头表示可能发生的状态变迁。箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作。图中有三种不同的箭头，粗实线箭头表示对客户进程的正常变迁，粗虚线箭头表示对服务器进程的正常变迁，另一种细线箭头表示异常变迁。
本章重要概念
运输层提供应用进程间的逻辑通信，运输层之间的通信并不是真正在两个运输层之间直接传送数据。运输层向应用层屏蔽了下面网络的细节 (如网络拓扑、所采用的路由选择协议等)，使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。
网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
运输层有两个主要的协议：TCP 和 UDP。它们都有复用和分用，以及检错的功能。当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的 (只提供尽最大努力服务)，但这种逻辑通信信道就相当于一条全双工通信的可靠信道。当运输层采用无连接的 UDP 协议时，这种逻辑通信信道仍然是一条不可靠信道。
运输层用一个 16 位端口号来标志一个端口。端口号只具有本地意义，它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网的不同计算机中，相同的端口号是没有关联的。
两台计算机中的进程要互相通信，不仅要知道对方的 IP 地址 (为了找到对方的计算机)，而且还要知道对方的端口号 (为了找到对方计算机中的应用进程)。
运输层的端口号分为服务器端使用的端口号 (0～1023 指派给熟知端口，1024～49151 是登记端口号) 和客户端暂时使用的端口号 (49152～65535)。
UDP 的主要特点是：
- 无连接；
- 尽最大努力交付；
- 面向报文；
- 无拥塞控制；
- 支持一对一、一对多、多对一和多对多的交互通信；
- 首部开销小 (只有四个字段：源端口、目的端口、长度、检验和)。
TCP 的主要特点是：
- 面向连接；
- 每一条 TCP 连接只能是点对点的 (一对一)；
- 提供可靠交付的服务；
- 提供全双工通信；
- 面向字节流。
TCP 用主机的 IP 地址加上主机上的端口号作为 TCP 连接的端点。这样的端点就叫做套接字 (socket) 或插口。套接字用 (IP地址：端口号) 来表示。
停止等待协议能够在不可靠的传输网络上实现可靠的通信。每发送完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组，分组需要进行编号。
超时重传指只要超过了一段时间仍然没有收到确认，就重传前面发送过的分组。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，同时还要发送确认。
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已正确收到了。
TCP 报文段首部的前 20 个字节是固定的，后面有 4N 字节是根据需要而增加的选项。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。
TCP 首部中的确认号是期望收到对方下一个报文段的第一个数据字节的序号。若确认号为 N，则表明：到序号 N-1 为止的所有数据都已正确收到。
TCP 首部中的窗口字段指出了现在允许对方发送的数据量。窗口值是经常在动态变化着的。
TCP 使用滑动窗口机制。发送窗口里面的序号表示允许发送的序号。发送窗口后沿的后面部分表示已发送且已收到了确认，而发送窗口前沿的前面部分表示不允许发送。发送窗口后沿的变化情况有两种可能，即不动 (没有收到新的确认) 和前移 (收到了新的确认)。发送窗口前沿通常是不断向前移动的。
流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。拥塞控制是防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。
流量控制是一个端到端的问题，是接收端抑制发送端发送数据的速率，以便使接收端来得及接收。拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
为了进行拥塞控制，TCP 的发送方要维持一个拥塞窗口 cwnd 的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接收窗口中较小的一个。
TCP 的拥塞控制采用了四种算法，即慢开始、拥塞避免、快重传和快恢复。在网络层，也可以使路由器采用适当的分组丢弃策略 (如主动队列管理 AQM)，以减少网络拥塞的发生。
运输连接有三个阶段，即连接建立、数据传送和连接释放。
主动发起 TCP 连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。TCP 的连接建立采用三报文握手机制。服务器要确认客户的连接请求，然后客户要对服务器的确认进行确认。
TCP 的连接释放采用四报文握手机制。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后就进入半关闭状态。当另一方也没有数据再发送时，则发送连接释放通知，对方确认后就完全关闭了 TCP 连接。
为什么说 UDP 面向报文，TCP 面向字节流？
发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文。在接收方的 UDP，对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程。也就是说，UDP 一次交付一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长，UDP 把它交给 IP 层后，IP 层在传送时可能要进行分片，这会降低 IP 层的效率。反之，若报文太短，UDP 把它交给 IP 层后，会使 IP 数据报的首部的相对长度太大，这也降低了 IP 层的效率。
(1) UDP 被称为”面向报文”的协议，因为它将数据视为独立的报文，而不是连续的字节流。每个UDP 报文都是一个独立的数据包，UDP 对报文的处理是原封不动地发送和接收，不保证它们的顺序，也不提供重传机制。每个 UDP 报文都是一个独立的实体，它们之间没有关联。
UDP 适用于一些实时性要求高、可以容忍一些数据丢失的应用场景，比如实时音视频传输、在线游戏等。
(2) TCP 则被称为”面向字节流”的协议，因为它将数据视为一个连续的字节流，而不是离散的报文。TCP 负责将应用层的数据划分为合适的数据块，然后将这些数据块封装为 TCP 报文段进行传输。在接收端，TCP 会负责重组这些字节流，确保按顺序交付给应用层。
TCP 提供了可靠的、面向连接的服务，通过序列号和确认机制保证数据的可靠传输，并能够处理数据的重传、流量控制和拥塞控制等问题。
TCP 适用于对数据可靠性和顺序性要求较高的应用，比如文件传输、网页访问等。为什么 UDP 首部中没有首部长度字段，而 TCP 首部中却有？
UDP 数据报首部长度是固定的，不需要这个字段。
TCP 报文段除了固定长度的首部之外，还有选项字段，因此 TCP 报文段的首部长度是可变的。(TCP 报文段的首部长度字段就是“数据偏移”)流量控制与拥塞控制的主要区别是什么？发送窗口的大小取决于流量控制还是拥塞控制
简单地说，流量控制是在一条 TCP 连接中的接收端采用的措施，用来限制对方 (发送端) 发送报文段的速率，以免在接收端来不及接收。流量控制只控制一个发送端。
拥塞控制是用来控制 TCP 连接中发送端发送报文段的速率，以免使互联网中的某处产生过载。拥寒控制可能会同时控制许多个发送端，限制它们的发送速率。不过每一个发送端只知道自己应当怎样调整发送速率，而不知道在互联网中还有哪些主机被限制了发送速率。
发送窗口的上限值是 Min[rwnd,cwnd]，即发送窗口的数值不能超过接收窗口和拥塞窗口中的较小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制，而拥寨窗口的大小则是整个互联网的负载情况对发送端施加的拥寒控制。因此，当接收窗口小于拥塞窗口时，发送窗口的大小取决于流量控制，即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时，则发送窗口的大小取决于拥塞控制，即取决于整个网络的拥塞状况。
