在计算机领域，数据的本质无非0和1，创造0和1的固然伟大，但真正百花齐放的还是基于0和1之上的各种层次之间的组合（数据结构）所带给我们人类各种各样的可能性。例如TCP协议，我们的生活无不无时无刻的站在TCP协议这个“巨人”的肩膀上，最简单的一个打开手机的动作。所以对TCP的认识和理解，可谓越来越常识化。
TCP/IP五层协议
虽然TCP是一种计算机网络协议，但本质还是人与人之间的一种约定，只不过由计算机去执行而已，把协议的细节与作用解耦，让我们人类只需专注于基于它的应用呈现之上即可。协议即“规则”，如果我们把光纤“横斜面”剖析，我们看到的就是数据的本质0和1，如下图所示：
0和1是点对点之间通信的信息“载体”，我们需要有一各规则去翻译这些“载体”，好比如小白和小黑之间的“敲声传话游戏”的约定，他们可以约定“敲一下”代表“是”，“敲两下”代表“不是”等。这些“敲声”跟光纤上的“0”和“1”都是承载着一样的任务——信息载体。
从整个网络层次来看，TCP/IP协议体系是网络的一个核心协议组，有一点需要知道的是TCP/IP协议体系并非只有TCP协议和IP协议，而是包含了物理层、链路层、网络层、运输层、应用层，而每一层次又有不同的协议，例如运输层协议除了TCP协议还有UDP协议。当然这里我只是为了接下来学习TCP协议的一个宏观认识。从上图可以看出，从0和1的基本信息单元到TCP协议的数据结构还要经过链路层和网络层的层层分解，换句话说，也就是TCP协议的数据以“段”单元，封装在链路层的IP协议上，IP协议的数据是以“数据报”为单元，它同样封装在链路层的以太网标准协议里面。本文的重点在TCP协议的学习，了解了TCP的原理，其他协议的数据结构和逻辑大同小异了。
TCP的首部
从“TCP/IP五层协议体系图”可以看出，每一个协议都会有个“头部”，TCP也不例外，其实这个“头部”就是该协议的数据结构以及规则的说明，但无论协议的玩法如何变化，它还是离不开0和1的信息载体。
源端口号：我们都知道IP是跟主机相关，而每台主机又可以有不同的应用进程在运行，所以端口更多可以指运行在主机上的应用进程，所以源端口号也就是基于TCP协议传输数据的“发送方”。
目的端口：就是等待TCP协议发送方数据的“接收方”，其实所谓的端口也就是应用进程与应用进程之间通信的监听出入口。
序列号：这个数字是用来表示通信双方“单向”数据量流动数量表示，上面所介绍的0和1是最小的数据传输单元，我们称为“比特（bit）”。而这个序列号记录的是以“字节”为单位的计数器（1字节=8比特）。例如A要传输给B的512字节数据，假设初始序列号为1024（注意：每次初始化序号都会不一样，TCP有一个比较复杂的初始化算法），那么他们传输过程的序列号为1536。这个序列号会随着双方“交流”而不断的增加，因为序列号一共32比特，所以最大值也就是2^32-1，到达最大值后重新从0开始。因为TCP是一个可靠的协议，序列号的存在是其可靠的关键因素之一。
确认序列号：既然每个传输的字节都被计数，确认序列号包含发送确认的一端所期望收到下一个序号。因此，确认序列号应当是上次已成功接收到数据字节序列号加1。只有ACK标识（下面会介绍）为1时确认序列号才生效。因为TCP为应用层提供双工服务，意味着数据能在两个方向上独立地进行传输，因此连接的每一端（客户端和服务端）必须保持每个方向上的传输序列号。例如A传送给B的序列号为1024（A维护），但B传送给A的有自己的序列号需要维护（B维护）。
首部长度：TCP首部的“选项”不启用，那么TCP的头部就是20字节，但因为存在“选项”的部分，所以头部可能存在大于20字节的可能性。因为“首部长度标识”有4位，所以最大值为2^4-1=15，而这个标识维护头部的长度是以32比特为单元，所以头部最大长度为15*32比特（4字节）=60字节。
标志：每个标志占1比特，它们中的多个可同时被设置为1，每个标志的用法如下：
URG：紧急指针（urgent pointer）有效；
ACK：确认序号有效；
PSH：接收方应该尽快将这个报文段交给应用层；
RST：重建连接；
SYN：同步序号用来发起一个连接；
FIN：发送端完成发送任务；
窗口大小：TCP的流量控制由连接的每一端通过声明的窗口大小来提供（以字节为单位），窗口大小是一个16比特字段，因而窗口最大为65535字节。换个说法，窗口好比如“缓冲区”，TCP是一个双工单向传送的通信协议，双方都需要有自己的窗口（缓冲区）大小相互告知，如果接收到的应用处理速度慢（从缓冲区消费数据慢），那么它的窗口很容易就满了，发送方就会停止发送，等到接受方的窗口有“空余”了才继续发送。
检验和：检验和（类数据签名）覆盖了整个的TCP报文段：TCP首部和TCP数据，因为TCP是一个可靠的协议，所以这是强制性的字段，由发送方计算和设置，并由接收方进行验证，这就是可靠性保证的重要手段。
紧急指针：只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个报文段。
选项：就是TCP头部的不是“必须”的选项，例如常见的可选字段是“最长报文大小”，又称为MSS（Maximun Segment Size），每个连接方通常都在通信的第一个报文段中指明这个选项。
数据：整个TCP报文段是又报文头部和报文数据组成的，除去了头部就是数据，但数据是可空的，例如创建连接（SYN）和结束传输（FIN）的TCP报文都是没有数据的。
TCP连接的建立和终止
TCP建立连接需要三次握手，分别如下：
1）、客户端（请求方）发送一个SYN段指明客户打算连接的服务器端口，以及把初始化序号x附上，这就是大名鼎鼎的SYN报文段，在介绍头部的时候已经提过，SYN报文段是没有数据的，因为连接都没正式连接，发送数据没意义。但也提到了客户端会附上它的最大报文段，也就是告诉接收方它最大的一个报文段能接受多少数据。
2）、服务端（处于监听状态）收到SYN请求后发回包含服务端的初始序号的SYN报文段作为应答（上文提到过客户端和服务端的初始序号都是各自维护的）。同时，将确认序号设置为客户的ISN加1（因为SYN将占用一个序号），以对客户的SYN报文段进行确认。在服务端想客户端响应SYN的时候同样可能会附上它接收的最大报文段，但记住，毕竟最大报文段是可选的，不一定会存在，不相互告知的话就会使用默认值。
3）、客户端必须将确认序号设置为服务器的ISN加1一对服务器的SYN报文段进行确认。
当以上三个报文段完成交互后就证明连接已经建立，这个过程也成为“三次握手”。接下来客户端就可以发送数据给服务端，服务端可以响应数据。其实很多时候，客户端在第三个报文段（也就是第三次握手）的时候就已经附带数据了。因为它已经不需要等待对方第四次握手的交互确认。正常连接的第四个报文段也是客户端发送数据的报文段，所以既然第三次和第四次都是客户端，为了省了一个交互，客户端可以直接从第三个报文段（应答服务端ack）附上数据。
建立一个连接需要三次握手，而终止一个连接需要经过4次握手，这是由于TCP的半关闭（half close）造成的。既然一个TCP连接是全双工的（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。当一端收到一个FIN，它必须通知应用层另一端已经终止了那个方向的数据传送。发送FIN通常是应用层进行关闭的结果。比较常见的还是客户端关闭，但服务端也可以设置主动关闭，例如Nginx相关策略配置。
TCP终止连接需要四次握手，分别如下：
1）、首先关闭的一方（即发送第一个FIN）将执行主动关闭，上图显示主动关闭的一方是客户端。
2）、当服务端收到这个FIN报文段时，它将发回一个ACK，确认序号为收到的序号加1，就像上图的ack=u+1，因为FIN跟SYN一样也占用一个序号。
3）、服务端把收到的FIN的消息告诉应用程序（传送一个文件结束符），接着这个应用程序就会关闭它的连接（以上提过，建立和关闭都是由应用主动发起的），导致服务端的TCP端发送一个FIN给客户端。需要注意的是，毕竟TCP是双工的，客户端关闭连接不代表服务端就可以立刻关闭，如果客户端发起关闭的时候，服务端还没有响应完数据给客户端，服务端还是需要把数据发完了再去关闭的，而客户端主动发起了闭关也不会立刻罢工，它还是会进入“FIN_WAIT2”状态进行数据接收，直到服务端发送完了并最后发送结束连接报文段（FIN），才进入TIME_WAIT状态。
4）、客户端收到服务端的FIN报文段时，它会立刻对此FIN进行ACK回复，服务端收到后就直接进入关闭状态（CLOSED）。
因为TCP是全双工的，双方都各种维护自己单向传送数据的连接，所以必然会存在双方同时主动关闭的情况，如下图所示：
当双方同时向对方发送FIN执行主动连接时，双方均从ESTABLISHED状态变为FIN_WAIT_1状态。双方都收到FIN后，状态由FIN_WAIT_1变迁至CLOSING，并发送最后的ACK。当收到ACK时，双方的状态变为TIME_WAIT。
TCP的状态迁变
通过以上建立和终止连接可以看到，无论客户端还是服务端，无论是连接方还是结束方都存在许多“状态”，每个状态随着各种条件不断变化，具体状态的迁变可以通过下图来进行总结。
2MSL等待状态
从上图迁变状态可以看到，TCP主动关闭的一方都会进入TIME_WAIT状态，也称为2MSL（最大报文段生存时间）等待状态。之所以要等待，是因为关闭方要确认处于“CLOSE_WAIT”状态的被关闭方收到它最后的ACK报文，报文的在网络上单向传送的最大时间叫做MSL，那么等待确认报文来回的时间就是2MSL，如果被关闭方在2MSL内都没有收到ACK，它会继续发送FIN报文，而如果关闭方在2MSL内没有收到对方的报文就默认对方已经收到。
报文在网络上的生存时间并不只有TCP决定的，在网络层的IP协议对数据报同样存在着网络单向传送的时间限制，这个限制的约定叫TTL（Time To Live）。TTL的时间单位并非时间单位，而是“跳数”，数据包每经过一个路由就叫“一跳”，不同系统对IP数据包的跳数初始值都不一样，例如有些Linux默认值是255。每经过一个路由，总生命跳数就减1，直到为0都还没有到达目的地就丢弃。255跳到底是多少秒呢？其实这都是一个不确定数字。如果一个数据包经过255个路由都还没到达目的地，我想目的地可能是“火星”。并TCP是“坐”在IP协议之上的，所以TCP的MSL肯定不能比TTL短，RFC793[Postel 1981c]指出MSL为2分钟。然而，实现中的常用值是30秒，1分钟或2分钟。要知道，0和1在光纤上传送的速度是“光速（约300000km/s）”，30秒的时间跑了不知道多少趟地球了，所以正常情况下都会大于TTL了（除非部分路由十分磨蹭）。如果做过一些高并发系统的同学，多少会遇到一些诸如time_wait过多的现象，例如WEB服务器配置主动关闭连接策略或连接有效时间短而主动关闭，大量的time_wait会占用文件描述符，而很容易导致耗光系统默认的1024个最大文件打开数（fs.file-max）而无法正常服务。
报文段复位
从以上状态图还可以看出一个比较特殊的标识，就是RST（复位）标识。无论何时一个报文段发往基准的连接（由目的IP地址和目的端口号以及源IP地址和源端口号指明的连接）出现错误，TCP都会发出一个复位段报文。说白了就是一个出错提示报文，通常会有两种情况会产生这种报文。
情况1：到不存在的端口的连接请求。也就是说，如果你去telnet一个不存在的端口，目的端口没有进程在听，对方主机TCP将会产生一个复位报文告诉连接拒绝。
情况2：异常终止一个连接。例如，当服务器在通信过程突然被重启了，而在重启后客户端还在发送信息给服务端，服务端就不会认为这是一个正常的连接而不接受这个报文段并向客户端发送一个RST复位报文。而客户端的TCP服务接收到RST后就会告诉应用而立刻断开连接停止发送信息。
从复位报文的效果可以看得出RST报文跟FIN报文同样可以终止一个连接，有时称为异常释放。异常但不代表只有缺点，存在即合理，它还有两个明显的优点：（1）丢弃任何待发送数据并立刻发送复位段报文。（2）RST的接收方会区分另一端执行的是异常关闭还是正常关闭。
同时打开和同时关闭
有时候TCP建立连接不一定必须是三次握手，有时可能会是4次。没错，当双发同时进行请求主动打开连接的时候就是4次，如下图所示。这个时候，并没有谁是客户端谁是服务端之称，因为双方都有主动发送数据的权利。这种情况应该很少见，如果需要模拟还是可以的，把双方的网速通过某些手段把它降低，那么就有可能演示。
学习总结
本次总结更多是对TCP协议的一个基础了解，包括TCP建立连接的正常三次握手和十分罕见的同步建立连接的4次握手，以及关闭连接的正常4次握手和同步关闭连接导致双方都进入TIME_WAIT状态的4次握手。最后总体学习了TCP客户端以及服务端各种状态迁变的概要图，十分清晰地对TCP各种概况的描述，以及为什么会有TIME_WAIT和2MSL的概念。
