TCP：传输控制协议
17.1 简介
本章我们将描述TCP提供给给应用层的服务。也会对TCP的 头域字段(header fields)进行考察。接下来的几章，我们将更细节地检查所有这些头域字段的使用。
我们从本章开始对TCP进行讨论，并延续到后面7章。第18章描述了TCP连接如何建立和终止，第19和20章考察了数据的正常传输，包括交互式使用（远程登录）和块数据（文件传输）。第21章提供了TCP超时和重传的一些细节，在接下来的第22和23章讨论了两个TCP计时器(timer)。最后在第24章了解一些TCP的新特征和TCP性能。
TCP最初的规范定义在RFC793[Postel 1981c]中，Host Requirements RFC对它的一些错误进行了修正。
17.2 TCP服务
尽管TCP和UDP使用相同的网络层（IP），但TCP为应用层提供了完全不同于UDP的服务。TCP提供的是 面向连接的（connection-oriended）、可靠的（reliable）、字节流（byte stream）服务。
术语面向连接意思是，使用TCP的两个应用程序（通常认为是一个client和一个server）在交换数据之前必须同对方建立一个TCP连接。这类似于拨打电话的过程：拨号——等待对方回应hello——然后开始通话。在第18章，我们将会看到如何建立一个连接、在一段时间后又如何断开连接。
在一个TCP连接中，只有两个终端在互相通信。我们在第12章讨论的 广播(broadcasting)和 多播(multicasting)两个概念对TCP不适用。
TCP通过下面几个方面来提供可靠性：
* 应用数据被分割成TCP所认为是最佳大小的数据块（chunks）来发送。这与UDP完全不同，应用程序的每次写操作产生一个UDP数据报，其大小不作调整。TCP和IP之间传递的信息单元叫做 报文段(segment)。在18.4我们将会看到TCP如何决定一个报文段的长度。
* TCP发送一个报文段时维护一个计时器（timer）,并等待另一端收到该报文段的确认。如果没有及时收到确认，相应的报文段将被重传。在第21章，我们将会看到TCP超时和重传策略。
* 当TCP从连接的另一端收到数据时，它发送一个确认。但确认并不是立即发出，通常延迟一丁点时间（a fraction of a second），这将在19.3讨论。
* TCP对它的头域和数据维护一个 校验和（checksum）。这个端到端（end-to-end）的校验和的目的是检查传输过程中数据是否被修改。如果收到一个报文段附带了不正确的校验和，那么TCP将丢弃该报文段，并且不会发送对它的确认。（它期待发送者超时并重传报文段。）
* 因为TCP 报文段封装在IP数据报传输，而IP数据报是无序的，因此TCP 报文段也是无序到达的。如果有必要，TCP接收端可以重排（resequence）数据，再以正确的顺序传递给应用程序。
* 因为IP数据报可能被复制，所以TCP接收端要丢弃重复的数据。
* TCP也提供了 流量控制(flow control)。TCP连接的每一端都有一个有限数量的缓冲空间。TCP接收端只允许另一端最多发送它缓冲空间一样大数据。这就防止了快速发送数据的主机填满低速主机的缓冲区。
在两个应用程序之间的TCP连接上，交换的是8位的字节流。TCP不会在字节流中自动插入记录标记（record marker）。这就是所谓的 字节流服务（byte stream service）。如果连接一端的应用程序先写了10个字节，再写了20个字节，然后写了50个字节，而连接另一端的应用程序却不知道对方每次写的数目。它可能分4次读取这80个字节，每次20字节。一端将字节流放置到TCP连接，相同的、一致的字节流出现在连接另一端。
而且，TCP根本不会去解释字节的内容。TCP不知道交换的数据是二进制数据，ASCII字符，EBCDIC字符，还是其他类型。对字节流的解释是连接两端应用程序的任务。
TCP之与字节流，犹如Unix操作系统之与文件。无论一个应用程序读或写什么字节，Unix内核都不会去解释，这是应用程序的任务。Unix内核看二进制文件和文本行文件没有什么区别。(在作者的另一著作APUE第四章对此也有叙述，它们都是regular files)。
17.3 TCP头域
TCP数据封装在 IP数据报(IP datagram)中，如图17.1所示
图17.2显示了TCP头域的格式。除非有 可选域（Options）出现，否则它的 通常大小是20字节。
每个TCP报文段都包含了源和目的端口号，用以识别发送和接收应用程序。这两个值，连同IP头域中的源和目的IP地址，唯一地标识了每个连接。
有时称IP地址和端口号的组合为一个 socket。这个术语出现在最初的TCP规范（RFC793）中，后来它也被用作由Berkeley派生出来的编程接口（Berkeley-derived programming interface）名。socket对（由client IP地址，client端口号，server IP地址，server端口号组成的4元组（4-tuple）），指定了连接的两个终端，正是由它唯一地标识了互联网上的每个TCP连接。
顺序号（the sequence number）标识了从TCP发送端到接收端的数据流，是该报文段中的第一个数据字节的序号。如果我们考虑两个应用程序之间单向的字节流，TCP将给每个字节标一个顺序号。顺序号是32位的无符号数，增加到2 32-1后又返回至0。
当一个新的连接被建立以后， SYN标志位打开。主机从 顺序号字段(sequence number field )中为连接选择 初始顺序号（initial sequence number,ISN）。由于SYN标志消费了一个顺序号，因此主机发送的 第一个数据字节的顺序号是 ISN+1。（我们将在下一章介绍如何建立和终止连接得更多细节，到时将会看到FIN标志也消费一个顺序号。）
交换的每个字节都有序号可循， 确认号（acknowledgment number）包含了确认发出者(即数据接收者)希望接收的下一个顺序号。因此，这个确认号是上次成功接收的数据字节的顺序号加1。只有在ACK标志打开时，此域才有效。
因为32位的确认号字段就像ACK标志一样，总是头域的一部分，因此发送一个ACK无任何代价。我们将会看到，一旦一个连接被建立，该域总是被置位，并且ACK标志也总是被打开。
TCP为应用层提供了 全双工（full-duplex）的服务。这就意味着数据能够互相独立地在各自方向传输。因此，连接的每一端都需要为每个方向的数据流维护一个顺序号。
TCP可以用 滑动窗口协议（sliding-window protocol）来描述，此时没有 选择确认（selective Acknowledge）和 否认（negative acknowledge）。（用作数据传输的滑动窗口协议在20.3描述。）我们说TCP缺少选择确认，是因为TCP头域的确认号表示确认发出者已经成功接收之前的数据，但不包括确认号所指字节。当前还没有办法对数据流中选定的部分进行确认。例如，如果字节1-1024成功接收，并且下一报文段包含字节2049-3072，那么接收者就不能确认该报文段。它只能发送一个确认号为1025的ACK。也没有方法对一个报文段进行否认。比如，包含字节1025-2048的报文段到达，但它的检验和错误，TCP接收端所能做的仅是发送一个确认号1025的ACK。在21.7我们将看到如何通过复制确认来帮助判断包的丢失。
头域长度（header length）给出了头域中32位字的数目。由于可选域的总长度可变，所以需要这个域。使用4位的字段，TCP头域限制在60字节。而无可选域时，正常大小是20字节。
TCP头域中有6个标志位。它们中的一个或多个可以被同时打开。这里我们主要关心它们的用途，后续章节讨论更多细节。
URG 紧急指针（urgent point）有效（20.8）
ACK 确认号有效
PSH 接收方应尽快将数据交给应用层（20.5）
RST 复位连接（18.7）
SYN 同步顺序号来初始化一个连接。（SYN和FIN在18章讨论）
FIN 发送端完成数据发送
TCP的流量控制由每一端通告的 窗口大小（window size）来提供。这是接收者期望接受的字节数，以确认号字段指定的序号起始(即接收者收到这些数目的数据后发送一个确认)。这是一个16位的字段，因此窗口最大是65535字节。在24.4，我们将会看到新的窗口缩放（scale）选项，允许窗口大小缩放，可以提供更大的窗口。
校验和的计算覆盖了整个TCP 报文段：TCP头域和TCP数据。这是一个强制（mandatory）字段，必须由发送者计算和存储，并由接收者验证(正确性)。TCP检验和的计算类似于UDP，使用了 伪头域（pseudo-header），在11.3中描述。
只有在URG标志置位时，紧急指针才有效。该指针是一个正的偏移量，它加到报文段的顺序号字段产生 紧急数据（urgent data）最后一个字节的顺序号(即它是紧急数据的长度)。TCP的紧急模式是发送者传送紧急数据到另一端的一种方法。我们在20.8将会看到这个特征。
最常用的可选字段是 最长报文段段（Maximum Segment Size），简称MSS。连接的每一端通常在交换的第一个报文段（建立连接时设置SYN标志的那个报文段）中指明这个选项。MSS指定了它的发送者希望接收的最大长度的报文段。我们在18.4描述了MSS选项的更多细节，其他的可选域出现在24章。
在图17.2中，我们注意到TCP报文段的数据部分是可选的。在第18章我们将会看到当连接建立和终止时，两端交换的报文段只包含TCP头域（里面是一些可能的选项）。不带数据的头域也可以用来确认收到的数据，前提是在确认发送方向没有数据传输（否则捎带确认）。在一些情况下，不带数据的报文段也用来处理超时。
17.4 小结（略）
17.1 简介
本章我们将描述TCP提供给给应用层的服务。也会对TCP的 头域字段(header fields)进行考察。接下来的几章，我们将更细节地检查所有这些头域字段的使用。
我们从本章开始对TCP进行讨论，并延续到后面7章。第18章描述了TCP连接如何建立和终止，第19和20章考察了数据的正常传输，包括交互式使用（远程登录）和块数据（文件传输）。第21章提供了TCP超时和重传的一些细节，在接下来的第22和23章讨论了两个TCP计时器(timer)。最后在第24章了解一些TCP的新特征和TCP性能。
TCP最初的规范定义在RFC793[Postel 1981c]中，Host Requirements RFC对它的一些错误进行了修正。
17.2 TCP服务
尽管TCP和UDP使用相同的网络层（IP），但TCP为应用层提供了完全不同于UDP的服务。TCP提供的是 面向连接的（connection-oriended）、可靠的（reliable）、字节流（byte stream）服务。
术语面向连接意思是，使用TCP的两个应用程序（通常认为是一个client和一个server）在交换数据之前必须同对方建立一个TCP连接。这类似于拨打电话的过程：拨号——等待对方回应hello——然后开始通话。在第18章，我们将会看到如何建立一个连接、在一段时间后又如何断开连接。
在一个TCP连接中，只有两个终端在互相通信。我们在第12章讨论的 广播(broadcasting)和 多播(multicasting)两个概念对TCP不适用。
TCP通过下面几个方面来提供可靠性：
* 应用数据被分割成TCP所认为是最佳大小的数据块（chunks）来发送。这与UDP完全不同，应用程序的每次写操作产生一个UDP数据报，其大小不作调整。TCP和IP之间传递的信息单元叫做 报文段(segment)。在18.4我们将会看到TCP如何决定一个报文段的长度。
* TCP发送一个报文段时维护一个计时器（timer）,并等待另一端收到该报文段的确认。如果没有及时收到确认，相应的报文段将被重传。在第21章，我们将会看到TCP超时和重传策略。
* 当TCP从连接的另一端收到数据时，它发送一个确认。但确认并不是立即发出，通常延迟一丁点时间（a fraction of a second），这将在19.3讨论。
* TCP对它的头域和数据维护一个 校验和（checksum）。这个端到端（end-to-end）的校验和的目的是检查传输过程中数据是否被修改。如果收到一个报文段附带了不正确的校验和，那么TCP将丢弃该报文段，并且不会发送对它的确认。（它期待发送者超时并重传报文段。）
* 因为TCP 报文段封装在IP数据报传输，而IP数据报是无序的，因此TCP 报文段也是无序到达的。如果有必要，TCP接收端可以重排（resequence）数据，再以正确的顺序传递给应用程序。
* 因为IP数据报可能被复制，所以TCP接收端要丢弃重复的数据。
* TCP也提供了 流量控制(flow control)。TCP连接的每一端都有一个有限数量的缓冲空间。TCP接收端只允许另一端最多发送它缓冲空间一样大数据。这就防止了快速发送数据的主机填满低速主机的缓冲区。
在两个应用程序之间的TCP连接上，交换的是8位的字节流。TCP不会在字节流中自动插入记录标记（record marker）。这就是所谓的 字节流服务（byte stream service）。如果连接一端的应用程序先写了10个字节，再写了20个字节，然后写了50个字节，而连接另一端的应用程序却不知道对方每次写的数目。它可能分4次读取这80个字节，每次20字节。一端将字节流放置到TCP连接，相同的、一致的字节流出现在连接另一端。
而且，TCP根本不会去解释字节的内容。TCP不知道交换的数据是二进制数据，ASCII字符，EBCDIC字符，还是其他类型。对字节流的解释是连接两端应用程序的任务。
TCP之与字节流，犹如Unix操作系统之与文件。无论一个应用程序读或写什么字节，Unix内核都不会去解释，这是应用程序的任务。Unix内核看二进制文件和文本行文件没有什么区别。(在作者的另一著作APUE第四章对此也有叙述，它们都是regular files)。
17.3 TCP头域
TCP数据封装在 IP数据报(IP datagram)中，如图17.1所示
图 17.1 TCP数据封装在IP数据报
图17.2显示了TCP头域的格式。除非有 可选域（Options）出现，否则它的 通常大小是20字节。
图 17.2 TCP头域
每个TCP报文段都包含了源和目的端口号，用以识别发送和接收应用程序。这两个值，连同IP头域中的源和目的IP地址，唯一地标识了每个连接。
有时称IP地址和端口号的组合为一个 socket。这个术语出现在最初的TCP规范（RFC793）中，后来它也被用作由Berkeley派生出来的编程接口（Berkeley-derived programming interface）名。socket对（由client IP地址，client端口号，server IP地址，server端口号组成的4元组（4-tuple）），指定了连接的两个终端，正是由它唯一地标识了互联网上的每个TCP连接。
顺序号（the sequence number）标识了从TCP发送端到接收端的数据流，是该报文段中的第一个数据字节的序号。如果我们考虑两个应用程序之间单向的字节流，TCP将给每个字节标一个顺序号。顺序号是32位的无符号数，增加到2 32-1后又返回至0。
当一个新的连接被建立以后， SYN标志位打开。主机从 顺序号字段(sequence number field )中为连接选择 初始顺序号（initial sequence number,ISN）。由于SYN标志消费了一个顺序号，因此主机发送的 第一个数据字节的顺序号是 ISN+1。（我们将在下一章介绍如何建立和终止连接得更多细节，到时将会看到FIN标志也消费一个顺序号。）
交换的每个字节都有序号可循， 确认号（acknowledgment number）包含了确认发出者(即数据接收者)希望接收的下一个顺序号。因此，这个确认号是上次成功接收的数据字节的顺序号加1。只有在ACK标志打开时，此域才有效。
因为32位的确认号字段就像ACK标志一样，总是头域的一部分，因此发送一个ACK无任何代价。我们将会看到，一旦一个连接被建立，该域总是被置位，并且ACK标志也总是被打开。
TCP为应用层提供了 全双工（full-duplex）的服务。这就意味着数据能够互相独立地在各自方向传输。因此，连接的每一端都需要为每个方向的数据流维护一个顺序号。
TCP可以用 滑动窗口协议（sliding-window protocol）来描述，此时没有 选择确认（selective Acknowledge）和 否认（negative acknowledge）。（用作数据传输的滑动窗口协议在20.3描述。）我们说TCP缺少选择确认，是因为TCP头域的确认号表示确认发出者已经成功接收之前的数据，但不包括确认号所指字节。当前还没有办法对数据流中选定的部分进行确认。例如，如果字节1-1024成功接收，并且下一报文段包含字节2049-3072，那么接收者就不能确认该报文段。它只能发送一个确认号为1025的ACK。也没有方法对一个报文段进行否认。比如，包含字节1025-2048的报文段到达，但它的检验和错误，TCP接收端所能做的仅是发送一个确认号1025的ACK。在21.7我们将看到如何通过复制确认来帮助判断包的丢失。
头域长度（header length）给出了头域中32位字的数目。由于可选域的总长度可变，所以需要这个域。使用4位的字段，TCP头域限制在60字节。而无可选域时，正常大小是20字节。
TCP头域中有6个标志位。它们中的一个或多个可以被同时打开。这里我们主要关心它们的用途，后续章节讨论更多细节。
URG 紧急指针（urgent point）有效（20.8）
ACK 确认号有效
PSH 接收方应尽快将数据交给应用层（20.5）
RST 复位连接（18.7）
SYN 同步顺序号来初始化一个连接。（SYN和FIN在18章讨论）
FIN 发送端完成数据发送
TCP的流量控制由每一端通告的 窗口大小（window size）来提供。这是接收者期望接受的字节数，以确认号字段指定的序号起始(即接收者收到这些数目的数据后发送一个确认)。这是一个16位的字段，因此窗口最大是65535字节。在24.4，我们将会看到新的窗口缩放（scale）选项，允许窗口大小缩放，可以提供更大的窗口。
校验和的计算覆盖了整个TCP 报文段：TCP头域和TCP数据。这是一个强制（mandatory）字段，必须由发送者计算和存储，并由接收者验证(正确性)。TCP检验和的计算类似于UDP，使用了 伪头域（pseudo-header），在11.3中描述。
只有在URG标志置位时，紧急指针才有效。该指针是一个正的偏移量，它加到报文段的顺序号字段产生 紧急数据（urgent data）最后一个字节的顺序号(即它是紧急数据的长度)。TCP的紧急模式是发送者传送紧急数据到另一端的一种方法。我们在20.8将会看到这个特征。
最常用的可选字段是 最长报文段段（Maximum Segment Size），简称MSS。连接的每一端通常在交换的第一个报文段（建立连接时设置SYN标志的那个报文段）中指明这个选项。MSS指定了它的发送者希望接收的最大长度的报文段。我们在18.4描述了MSS选项的更多细节，其他的可选域出现在24章。
在图17.2中，我们注意到TCP报文段的数据部分是可选的。在第18章我们将会看到当连接建立和终止时，两端交换的报文段只包含TCP头域（里面是一些可能的选项）。不带数据的头域也可以用来确认收到的数据，前提是在确认发送方向没有数据传输（否则捎带确认）。在一些情况下，不带数据的报文段也用来处理超时。
17.4 小结（略）
1869
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
