传输层

2019-09-05

通过上图来说明运输层的作用，设局域网$LA{N}_1$上的主机$A$和局域网$LA{N}_2$上的主机$B$通过互连的广域网$WAN$进行通信。我们知道，$IP$协议能够把源主机$A$发送出的分组，按照首部中的目的地址，送交到目的主机$B$，那么，为什么还需要运输层呢？
从$IP$层来说，通信的两端是两台主机。$IP$数据报的首部明确地标志了这两台主机的$IP$地址。但“两台主机之间的通信”这种说法还不够清楚。这是因为，真正进行通信的实体是在主机中的进程，是这台主机中的一个进程和另一台主机中的一个进程在交换数据（即通信）。因此严格地讲，两台主机进行通信就是两台主机中的应用进程互相通信。$IP$协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信。
从这里可以看出网络层和运输层有明显的区别。网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。

运输层的两个主要协议

• 用户数据报协议UDP（User Datagram Protocol）：UDP在传送数据之前不需要先建立连接。远地主机的运输层在接收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP却是一种最有效的工作方式。
• 传输控制协议TCP（Transmission Control Protocol）：TCP则提供面向连接的服务。在传送数据之前要先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。

运输层的端口

我们知道，在单个计算机中的进程是用进程标识符来标志的。但是在互联网环境下，用计算机操作系统所指派的这种进程标识符来标志运行在应用层的各种应用进程则是不行的。这是因为在互联网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对TCP/IP体系的应用进程进行标志。
解决这个问题的方法就是在运输层使用协议端口号（protocol port number），或通常简称为端口（port）。TCP/IP运输层用一个$16$为端口号来标志一个端口。$16$位的端口号可允许有$65535$个不同的端口号。

• 服务器端使用的端口号
  1. 熟知端口号或系统端口号，数值为$0\sim 1023$

常用的熟知端口号

应用程序	熟知端口号
FTP	21
TELNET	23
SMTP	25
DNS	53
TFTP	69
HTTP	80
SNMP	161
SNMP（trap）	162
HTTPS	443

2. 登记端口号，数值为$1024\sim 49151$

• 客户端使用的端口号，数值为$49152\sim 65535$

TCP协议可靠传输的工作原理

1. 停止等待协议

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
可靠传输协议是这样设计的：发送方只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫超时重传。要实现超时重传，就要在每发送完一个分组时设置一个超时计时器。

• 发送方在发送完一个分组后，必须暂时保留已发送的分组的副本（在发生超时重传时使用）。只有在收到相应的确认后才能清除暂时保留的分组副本。
• 分组和确认分组都必须进行编号，这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没收到确认。
• 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。

自动重传请求ARQ（Automatic Repeat reQuest）：表示重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

连续ARQ协议

发送方维持一个发送窗口，它的意义是位于发送窗口内的分组都可连续发送出去，而不需要等待对方确认。
连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。

• 优点：容易实现，即使确认丢失也不必重传
• 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。

例如，如果发送方发送了前 5 个分组，而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。

TCP报文段首部格式

序号，占 4 个字节，共$2^{32}$个序号。序号使用 $\text{m}od{2}^{32}$运算。TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。

确认号，是期望收到对方下一个报文段的第一个数据字节的序号。即

若确认号 = N，则表明：到序号 N-1 为止的所有数据都已经正确收到。

首部有 6 个控制位，用来说明本报文段的性质。

• 紧急 URG（URGent），当URG = 1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据），而不要按原来的排队顺序来传送。如，用户从键盘发出中断命令（Cntrol + C）。如果不使用紧急数据，那么这两个字符将存储在接收 TCP 的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了许多时间。
  当 URG 置 1 时，发送应用进程就告诉发送方的 TCP 有紧急数据要传送。于是发送方就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。这时要与首部中**紧急指针（Urgent Pointer）**字段配合使用。

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

• 推送 PSH（PuSH） 当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下， TCP 就可以使用推送（push）操作。这时，发送方 TCP 把 PSH 置 1 ，并立即创建一个报文段发送出去。接收方 TCP 收到 PSH = 1 的报文段，就尽快地（即“推送”向前）交付应用进程，而不再等到整个缓存都填满了后再向上交付。
  虽然应用程序可以选择推送操作，但推送操作很少使用。

• 复位 RST（ReSeT） 当 RST = 1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。 RST 置 1 还用来拒绝一个非法的报文段或拒绝打开一个连接。RST 也可称为重建位或重置位。

一般出现RST的集中场景：

1. 访问不存在的端口连接请求；
   产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在监听。对于UDP，当一个数据报到达目的端口时，该端口没在使用，它将产生一个ICMP端口不可达的信息；而TCP则使用复位。
2. 异常终止一个连接；
   终止一个连接的正常方式是一方发送FIN，这也称为有序释放，因为在所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是FIN来中途释放一个连接，这也称为异常释放。异常终止一个连接对应用程序来说有两个优点：（1）丢弃任何待发数据并立即发送复位报文段；（2）RST的接收方会区分另一端执行的是异常关闭还是正常关闭。
3. 检测半关闭连接。
   如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的TCP连接称为半打开的。任何一端的主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据，仍处于连接状态的一方就不会检测另一方已经出现异常。下面介绍一种建立半打开连接的情形。在bsdi上运行Telnet客户程序，通过它和svr4上的丢弃服务器建立连接。接着断开服务器主机与以太网的电缆，并重启服务器主机。这可以模拟服务器主机出现异常（在重启服务器之前断开以太网电缆是为了防止它向打开的连接发送FIN，某些TCP在关机时会这么做）。服务器主机重启后，我们重新接上电缆，并从客户向服务器发送一行字符。由于服务器的TCP已经重新启动，它将丢失复位前连接的所有信息，因此它不知道数据报文段中提到的连接。TCP处理的原则是接收方以复位作为应答。

• 同步SYN（SYNchronization） 在建立连接时用来同步序号。当 SYN = 1而 ACK = 0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN =1 和 ACK = 1。因此， SYN 置为 1 就表示这是一个连接请求或连接接受报文。

• 终止 FIN（FINis） 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。

窗口 窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口）。窗口值告诉对方；从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量（以字节为单位）。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。

例如，发送了一个报文段，其确认号是 701，窗口字段是 1000。这就是告诉对方：“从 701 号算起，我（即发送此报文段的一方）的接收缓存空间还可接收 1000 个字节数据（字节序号是 701 ~ 1700），你在给我发送数据时，必须考虑到这一点。”
总之，应当记住：

窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化着。

TCP 可靠传输的实现

1. 以字节为单位的滑动窗口

2. 超时重传时间的选择

3. 选择确认 SACK（Selective ACK）

TCP 的流量控制

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

2. TCP 的传输效率

TCP 的拥塞控制

1. 慢开始（slow-start）

2. 拥塞避免（congestion avoidance）

3. 快重传（fast retransmit）

4. 快恢复（fast recovery）

TCP 的运输连接管理

1. TCP 的连接建立

TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段。下图为三次握手建立 TCP 连接的过程。

假定主机 A 运行的是 TCP 客户程序，而 B 运行 TCP 服务器程序。最初两端的 TCP 进程都处于 CLOSED（关闭）状态。一开始， B 的 TCP 服务器进程先创建传输控制块 TCB（Transmission Control Block，存储了每一个连接中的一些重要信息，如：TCP 连接表，指向发送和接收缓存的指针，指向重传队列的指针，当前的发送和接收序号，等等），准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN （收听）状态，等待客户的连接请求。如有，即作出响应。

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 状态。

上面给出的连接建立过程叫做三报文握手。请注意，在上图中 B 发送给 A 的报文段，也可拆成两个报文段。可以先发送一个确认报文段（ACK = 1，ack = x + 1），然后再发送一个同步报文段（SYN = 1，seq = y）。这样的过程就变成了四报文握手，但效果是一样的。

为什么 A 最后还要发送一次确认呢？ 这主要是为了防止已失效的连接请求报文段突然又传送到了 B，因而产生错误。

所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况，A 发出连接请求，但因连接请求报文丢失而未收到确认。于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B，没有“已失效的连接请求报文段”。
现假定出现一种异常情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。假定不采用报文握手，那么只要 B 发出确认，新的连接就建立了。
由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。
采用三报文握手的办法，可以防止上述现象的发生。例如在刚才的异常情况下，A 不会向 B 的确认发出确认。B 由于收不到确认，就知道 A 并没有要求建立连接。

2. TCP 的连接释放

数据传输结束后，通信的双方都可释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1 ，其序号 seq = u，它等于前面已传送过的数据的最后一个字节的序号加 1 。这时 A 进入 FIN-WAIT-1（终止等待 1）状态，等待 B 的确认。请注意，TCP 规定，FIN 报文段即使不携带数据，它也消耗掉一个序号。

B 收到连接释放报文段后即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v，等于 B 前面已传送过的数据的最后一个字节的序号加 1,。然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务器进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 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 连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间 2MSL 后，A 才进入到 CLOSED 状态。时间 MSL 叫做最长报文段寿命（Maximum Segment Lifetime），RFC 793建议设为 2 分钟。但这完全是从工程上来考虑的，对于现在的网络，MSL = 2 分钟可能太长了一些。

为什么 A 在 TIME-WAIT 状态必须等待 2MSL 的时间呢？这有两个理由。

第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对方已发送的 FIN + ACK 报文段的确认。B会超时重传这个 FIN +ACK 报文段，而 A 就能在 2MSL 时间内收到这个重传的 FIN + ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段。这样，B 就无法按照正常步骤进入 CLOSED 状态。
第二，防止上面提到的“已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL ，就可以使本连接持续到时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

B只要收到了 A 发出的确认，就进入 CLOSED 状态。同样，B 在撤销相应的传输控制块 TCB 后，就结束了这次的 TCP 连接。我们注意到，B 结束 TCP 连接的时间要比 A 早一些。

上述的 TCP 连接释放过程是四报文握手。

除时间等待计时器外，TCP 还设有一个保活计时器（keepalive timer）。设想有这样的情况：客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然出现故障。显然，服务器以后就不能再收到客户发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就是使用保活计时器。服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两小时。若两小时没有收到客户的数据，服务器就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若一连发送 10 个探测报文段后仍无客户的响应，服务器就认为客户端出了故障，接着就关闭这个连接。