本节书摘来自异步社区《Wireshark数据包分析实战（第2版）》一书中的第6章6.3节传输控制协议，作者【美】Chris Sanders,更多章节内容可以访问云栖社区“异步社区”公众号查看。
6.3 传输控制协议
传输控制协议（Transmission Control Protocol, TCP）的最终目的是为数据提供可靠的端到端传输。TCP在RFC793中定义，在OSI模型中的第4层工作。它能够处理数据的顺序和错误恢复，并且最终保证数据能够到达其应到达的地方。很多普遍使用的应用层协议都依赖于TCP和IP将数据包传输到其最终目的地。
6.3.1 TCP头
TCP提供了许多功能，并且反映在了其头部的复杂性上面。如图6-16所示，以下是TCP头的域。
源端口（Source Port）：用来传输数据包的端口。
目的端口（Destination Port）：数据包将要被发送到的端口。
序号（Sequence Number）：这个数字用来表示一个TCP片段。这个域用来保证数据流中的部分没有缺失。
确认号（Acknowledgment Number）：这个数字是通信中希望从另一个设备得到的下一个数据包的序号。
标记（Flags）：URG、ACK、PSH、RST、SYN和FIN标记都是用来表示所传输的TCP数据包的类型。
窗口大小（Window Size）：TCP接收者缓冲的字节大小。
校验和（Checksum）：用来保证TCP头和数据的内容在抵达目的地时的完整性。
紧急指针（Urgent Pointer）：如果设置了URG位，这个域将被检查作为额外的指令，告诉CPU从数据包的哪里开始读取数据。
选项（Options）：各种可选的域，可以在TCP数据包中进行指定。
6.3.2 TCP端口
所有TCP通信都会使用源端口和目的端口，而这些可以在每个TCP头中找到。端口就像是老式电话总机上的插口。一个总机操作员会监视着一个面板上的指示灯和插头，当指示灯亮起的时候，他就会连接这个呼叫者，问她想要和谁通话，然后插一根电缆将她和她的目的位置连接起来。每次呼叫都需要有一个源端口（呼叫者）和一个目的端口（接收者）。TCP端口大概就是这样工作的。
为了能够将数据传输到远程服务器或设备的特定应用中去，TCP数据包必须知道远程服务所监听的端口。如果你想要试着连接一个不同于所设置的端口，那么这个通信就会失败。
这个序列中的源端口并不十分重要，所以可以随机选择。远程服务器也可以很简单地从发送过来的原始数据包中得到这个端口（如图6-17所示）。
在使用TCP进行通信的时候，我们有65535个端口可供使用，并通常将这些端口分成两个部分。
1～1023是标准端口组（忽略掉被预留的0），特定服务会用到这些通常位于标准端口分组中的标准端口。
1024～65535是临时端口组（尽管一些操作系统对此有着不同的定义），当一个服务想在任意时间使用端口进行通信的时候，现代操作系统都会随机地选择一个源端口，让这个通信使用唯一源端口。这些源端口通常就位于临时端口组。
让我们打开文件tcp_ports.pcap，看一些不同的TCP数据包，并识别出它们所使用的端口号。在这个文件中，我们会看到一个客户端在浏览两个网站时产生的HTTP通信。正如前面所提到的HTTP使用TCP进行通信，所以这将是一个非常典型的TCP流量案例。
在这个文件中的第一个数据包中（如图6-18所示），一开始的两个值代表着这个数据包的源端口和目的端口。这个数据包从172.16.16.128发往212.58.226.142，它的源端口是属于临时端口组的2826图标1（需要记住的是源端口是由操作系统随机选取的，尽管它们可能在随机选择的过程中会选择递增策略）。目的端口是一个标准端口，80端口。这个标准端口正是提供给使用HTTP的Web服务器的。
你可能会注意到Wireshark将这些端口打上了slc-systemlog（2826）和http（80）的标签。Wireshark会维护一个端口的列表，并记录它们最普遍的应用。尽管列表还是以标准端口为主，但很多临时端口也关联着常用的服务。这些端口的标签可能会让人迷惑，所以一般来说最好通过关闭传输名字解析来禁用它。选择Edit -> Preference -> Name Resolution，然后取消勾选Enable Transport Name Resolution就可以将其禁用了。如果你希望保留这个功能但希望改变Wireshark对每一个端口的识别，你可以通过改变Wireshark程序目录下的Services文件。这个文件是根据互联网数字分配机构（Internet Assigned Numbers Authority, IANA）的通用端口列表编写的。
第二个数据包是由212.58.226.142发往172.16.16.128的（如图6-19所示）。除了IP地址之外，源端口和目的端口也同样有所改变。
所有基于TCP的通信都以相同的方式工作：选择一个随机的源端口与一个已知的目的端口进行通信。在发出初始数据包之后，远程设备就会与源设备使用建立起的端口进行通信。
在这个捕获文件中还有另外一个通信流，你可以试着找出它通信时使用的端口。
注意
随着这本书的深入，你将会知道更多与通用协议和端口相关联的端口，并且最终可以通过端口来识别使用它们的服务和设备。如果希望查阅详细的通用端口列表，可以访问 http://www.iana.org/assignments/port-numbers/。
6.3.3 TCP的三次握手
所有基于TCP的通信都需要以两台主机的握手开始。这个握手过程主要希望能达到以下不同的目的。
保证源主机确定目的主机在线，并且可以进行通信。
让源主机检查它是否正在监听试图去连接的端口。
允许源主机向接收者发送它的起始序列号，使得两台主机可以将数据包流保持有序。
TCP握手分为3个步骤，如图6-20所示。在第一步中，主动发起通信的设备（主机A）向目标（主机B）发送了一个TCP数据包。这个初始数据包除了底层协议头之外不包含任何数据。这个数据包的TCP头设置了SYN标志，并包含了在通信过程中会用到的初始序列号和最大分段大小（MSS）。主机B对于这个数据包回复了一个类似于设置了SYN和ACK标志以及包含了它初始序列号的数据包。最后，主机A向主机B发送最后一个仅设置了ACK标志的数据包。在这个过程完成之后，双方设备应该已经具有了开始正常通信所需的信息。
注意
TCP数据包在称呼上通常会被其所设置的标志所代表。比如，对于设置了SYN标志的TCP数据包，我们将会简称其为SYN包。所以TCP握手过程中使用的数据包会被称为SYN包、SYN/ACK包和ACK包。
打开tcp_handshake.pcap，可以更实际地看到这个过程。Wireshark为了分析将简便，引入了一个特性，可以将TCP数据包的序列号替换为相对值。但在这里，我们将这个功能关闭，以便于能看到实际的序列号值。选择Edit -> Preferences，展开Protocols并选择TCP，然后取消勾选Relative Sequence Numbers and Window Scaling框，并单击OK就可以禁用了。
这个捕获中的第一个数据包是我们的初始SYN数据包（如图6-21所示）。这个数据包从172.16.16.128的2826端口发往212.58.226.142的80端口。我们可以看到这里传输的序列号是3691127924图标1。
握手中第二个数据包是从212.58.226.142发出的SYN/ACK响应（如图6-22所示）。这个数据包也包含着这台主机的初始序列号（233779340）图标1，以及一个确认号（2691127925）图标２。这个确认号比之前的那个数据包序列号大1，是因为这个域是用来表示主机所期望得到的下一个序列号的值。
最后的数据包是从172.16.16.128（如图6-23所示）发出的ACK数据包。这个数据包正如所期望的那样，包含着之前数据包确认号域所定义的序列号3691127925图标1。
握手伴随着每次TCP的通信序列。当在一个繁忙的捕获文件中搜索通信序列的开始时，SYN、SYN/ACK、ACK的序列是一个很好的标志。
6.3.4 TCP终止
所有的问候最终都会有一句再见，在TCP中，每次握手后也会有终止。TCP终止用来在两台设备完成通信后正常地结束连接。这个过程包含4个数据包，并且用一个FIN标志来表明连接的终结。
在一个终止序列中，主机A通过发送一个设置了FIN和ACK标志的TCP数据包，告诉主机B通信的完成。主机B以一个ACK数据包响应，并传输自己的FIN/ACK数据包。主机A响应一个ACK数据包，然后结束通信过程。这个过程如图6-24所示。
打开文件tcp_teardown.pcap可以在Wireshark中看到这个过程。在序列的第一个数据包（如图6-25所示），你可以看到位于67.228.110.120的设备通过发送有着FIN和ACK标志的数据包图标1来开始终止过程。
在这个数据包被发出去之后，172.16.16.128使用了一个ACK数据包进行响应来确认第一个数据包的接收，然后发送了一个FIN/ACK数据包。整个过程在67.228.110.120发送了最终的ACK之后结束。这时，这两个设备的通信便已经结束，如果想要再次开始通信就必须完成新的TCP握手。
6.3.5 TCP重置
在理想情况中，每一个连接都会以TCP终止来正常地结束。但在现实中，连接经常会突然断掉。举例来说，这可能由于一个潜在的攻击者正在进行端口扫描，或者仅仅是主机配置错误。在这些情况下，就需要使用设置了RST标志的TCP数据包。RST标志用来指出连接被异常中止或拒绝连接请求。
文件tcp_refuseconnection.pcap给出了一个包含有RST数据包网络流量的例子。这个文件中的第一个数据包发自192.168.100.138，其尝试与192.168.100.1的80端口进行通信。这个主机并不知道192.168.100.1并没有在监听80端口，因为那是一个思科路由器，并且没有配置Web接口，也就是说，并没有服务监听80端口的连接。为了响应这个连接请求，192.168.100.1向192.168.100.138发送了一个数据包，告诉它其对80端口的通信无效。图6-26中展示了在第二个数据包的TCP头中这个连接尝试突然终止的情况。RST数据包除了包含RST和ACK标志图标1外，没有任何其他的东西，之后也并没有额外的通信。
如本例所示，RST数据包可以在通信序列的开始或者在主机通信的过程中，终止通信。
