运作方式

TCP连接包括三个状态：连接创建、数据传送和连接终止。操作系统将TCP连接抽象为套接字的编程接口给程序使用，并且要经历一系列的状态改变。

创建通路

TCP用三路握手（three-way handshake）过程创建一个连接。在连接创建过程中，很多参数要被初始化，例如序号被初始化以保证按序传输和连接的强壮性。

  TCP连接的正常创建

一对终端同时初始化一个它们之间的连接是可能的。但通常是由一端打开一个套接字（socket）然后监听来自另一方的连接，这就是通常所指的被动打开（passive open）。服务器端被被动打开以后，用户端就能开始创建主动打开（active open）。

客户端通过向服务器端发送一个SYN来创建一个主动打开，作为三路握手的一部分。客户端把这段连接的序号设定为随机数A。

服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK的确认码应为A+1，SYN/ACK包本身又有一个随机序号B。

最后，客户端再发送一个ACK。当服务端受到这个ACK的时候，就完成了三路握手，并进入了连接创建状态。此时包序号被设定为收到的确认号A+1，而响应则为B+1。

数据传输

在TCP的数据传送状态，很多重要的机制保证了TCP的可靠性和强壮性。它们包括：使用序号，对收到的TCP报文段进行排序以及检测重复的数据；使用校验和来检测报文段的错误；使用确认和计时器来检测和纠正丢包或延时。

序列号和确认

在TCP的连接创建状态，两个主机的TCP层间要交换初始序号（ISN：initial sequence number）。这些序号用于标识字节流中的数据，并且还是对应用层的数据字节进行记数的整数。通常在每个TCP报文段中都有一对序号和确认号。TCP报文发送者认为自己的字节编号为序号，而认为接收者的字节编号为确认号。TCP报文的接收者为了确保可靠性，在接收到一定数量的连续字节流后才发送确认。这是对TCP的一种扩展，通常称为选择确认（Selective Acknowledgement）。选择确认使得TCP接收者可以对乱序到达的数据块进行确认。每一个字节传输过后，ISN号都会递增1。

通过使用序号和确认号，TCP层可以把收到的报文段中的字节按正确的顺序交付给应用层。序号是32位的无符号数，在它增大到2-1时，便会回绕到0。对于ISN的选择是TCP中关键的一个操作，它可以确保强壮性和安全性。

数据传输举例

  TCP数据传输

发送方首先发送第一个包含序列号为1（可变化）和1460字节数据的TCP报文段给接收方。接收方以一个没有数据的TCP报文段来回复（只含报头），用确认号1461来表示已完全收到并请求下一个报文段。

发送方然后发送第二个包含序列号为1461和1460字节数据的TCP报文段给接收方。正常情况下，接收方以一个没有数据的TCP报文段来回复，用确认号2921（1461+1460）来表示已完全收到并请求下一个报文段。发送接收这样继续下去。

然而当这些数据包都是相连的情况下，接收方没有必要每一次都回应。比如，他收到第1到5条TCP报文段，只需回应第五条就行了。在例子中第3条TCP报文段被丢失了，所以尽管他收到了第4和5条，然而他只能回应第2条。

发送方在发送了第三条以后，没能收到回应，因此当时钟（timer）过时（expire）时，他重发第三条。（每次发送者发送一条TCP报文段后，都会再次启动一次时钟：RTT）。

这次第三条被成功接收，接收方可以直接确认第5条，因为4，5两条已收到。

校验和

TCP的16位的校验和（checksum）的计算和检验过程如下：发送者将TCP报文段的头部和数据部分的和计算出来，再对其求反码（一的补数），就得到了校验和，然后将结果装入报文中传输。（这里用反码和的原因是这种方法的循环进位使校验和可以在16位、32位、64位等情况下的计算结果再叠加后相同）接收者在收到报文后再按相同的算法计算一次校验和。这里使用的反码使得接收者不用再将校验和字段保存起来后清零，而可以直接将报文段连同校验加总。如果计算结果是全部为一，那么就表示了报文的完整性和正确性。

注意：TCP校验和也包括了96位的伪头部，其中有源地址、目的地址、协议以及TCP的长度。这可以避免报文被错误地路由。

按现在的标准，TCP的校验和是一个比较脆弱的校验。出错概率高的数据链路层需要更高的能力来探测和纠正连接错误。TCP如果是在今天设计的，它很可能有一个32位的CRC校验来纠错，而不是使用校验和。但是通过在第二层使用通常的CRC校验或更完全一点的校验可以部分地弥补这种脆弱的校验。第二层是在TCP层和IP层之下的，比如PPP或以太网，它们使用了这些校验。但是这也并不意味着TCP的16位校验和是冗余的，对于因特网传输的观察，表明在受CRC校验保护的各跳之间，软件和硬件的错误通常也会在报文中引入错误，而端到端的TCP校验能够捕捉到很多的这种错误。这就是应用中的端到端原则。

流量控制和阻塞管理

流量控制用来避免主机分组发送得过快而使接收方来不及完全收下。

TCP数据传输不同于UDP之处

有序数据传输

重发丢失的数据包

舍弃重复的数据包

无错误数据传输

阻塞/流量控制

面向连接（确认有创建三方交握，连接已创建才作传输。）

终结通路

  TCP连接的正常终止

连接终止使用了四路握手过程（four-way handshake），在这个过程中每个终端的连接都能独立地被终止。因此，一个典型的拆接过程需要每个终端都提供一对FIN和ACK。

状态编码

下表为TCP状态码列表，以S指代服务器，C指代客户端，S&C表示两者，S/C表示两者之一：

端口

TCP使用了端口号（Port number）的概念来标识发送方和接收方的应用层。对每个TCP连接的一端都有一个相关的16位的无符号端口号分配给它们。端口被分为三类：众所周知的、注册的和动态/私有的。众所周知的端口号是由因特网赋号管理局（IANA）来分配的，并且通常被用于系统一级或根进程。众所周知的应用程序作为服务器程序来运行，并被动地侦听经常使用这些端口的连接。例如：FTP、TELNET、SMTP、HTTP等。注册的端口号通常被用来作为终端用户连接服务器时短暂地使用的源端口号，但它们也可以用来标识已被第三方注册了的、被命名的服务。动态/私有的端口号在任何特定的TCP连接外不具有任何意义。可能的、被正式承认的端口号有65535个。

数据包结构

来源连接端口（16位长）－辨识发送连接端口

目的连接端口（16位长）－辨识接收连接端口

序列号（seq，32位长）

确认号（ack，32位长）—期望收到的数据的开始序列号。也即已经收到的数据的字节长度加1。

报头长度（4位长）—以4字节为单位计算出的数据段开始地址的偏移值。

保留—须置0

标志符

窗口（WIN，16位长）—表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。用于流量控制。

校验和（Checksum，16位长）—对整个的TCP报文段，包括TCP头部和TCP数据，以16位字进行计算所得。这是一个强制性的字段。

紧急指针（16位长）—本报文段中的紧急数据的最后一个字节的序号。

选项字段—最多40字节。每个选项的开始是1字节的kind字段，说明选项的类型。

发展过程

TCP是一个复杂的但同时又是在发展之中的协议。尽管许多重要的改进被提出和实施，发表于1981年的RFC793中说明的TCP（TCP-Tahoe）的许多基本操作还是未作多大改动。RFC1122：《因特网对主机的要求》阐明了许多TCP协议的实现要求。RFC2581：《TCP的拥塞控制》是一篇近年来关于TCP的很重要的RFC，描述了更新后的避免过度拥塞的算法。写于2001年的RFC3168描述了对明显拥塞的报告，这是一种拥塞避免的信号量机制。在21世纪早期，在所有因特网的数据包中，通常有大约95%的包使用了TCP协议。常见的使用TCP的应用层有HTTP/HTTPS（万维网协议），SMTP/POP3/IMAP（电子邮件协议）以及FTP（文件传输协议）。这些协议在今天被广泛地使用，这证明了它们的原作者的创造是卓越的。

最近，一个新协议已经被加州理工学院的科研人员开发出来，命名为FAST TCP（基于快速活动队列管理的规模可变的传输控制协议）。它使用排队延迟作为拥塞控制信号；但是因为端到端的延迟通常不仅仅包括排队延迟，所以FAST TCP（或更一般地，所有基于排队延迟的算法）在实际互联网中的能否工作仍然是一个没有解决的问题。

应用

TCP并不是对所有的应用都适合，一些新的带有一些内在的脆弱性的运输层协议也被设计出来。比如，实时应用并不需要甚至无法忍受TCP的可靠传输机制。在这种类型的应用中，通常允许一些丢包、出错或拥塞，而不是去校正它们。例如通常不使用TCP的应用有：实时流多媒体（如因特网广播）、实时多媒体播放器和游戏、IP电话（VoIP）等等。任何不是很需要可靠性或者是想将功能减到最少的应用可以避免使用TCP。在很多情况下，当只需要多路复用应用服务时，用户数据报协议（UDP）可以代替TCP为应用提供服务。

参考资料

Timothy S. Ramteke: Networks, Second Edition., Prentice-Hall 2001, ISBN 0-13-901265-6

Torsten Braun , Martina Zitterbart: Hochleistungskommunikation, Bd.2, Transportdienste und Transportprotokolle , Oldenbourg 1996, ISBN 978-3-486-23088-8

参见

TCP校验和卸载

TCP/UDP端口列表

SCTP

连接重置

拥塞控制

^RFC 793 Section 3.2

免责声明：以上内容版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。感谢每一位辛勤著写的作者，感谢每一位的分享。