在计算机领域，数据的本质无非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协议传输数据的“发送方”。spa
目的端口：就是等待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）而没法正常服务。
同时打开和同时关闭
有时候TCP创建链接不必定必须是三次握手，有时可能会是4次。没错，当双发同时进行请求主动打开链接的时候就是4次，以下图所示。这个时候，并无谁是客户端谁是服务端之称，由于双方都有主动发送数据的权利。这种状况应该不多见，若是须要模拟仍是能够的，把双方的网速经过某些手段把它下降，那么就有可能演示。
学习总结
本次总结更可能是对TCP协议的一个基础了解，包括TCP创建链接的正常三次握手和十分罕见的同步创建链接的4次握手，以及关闭链接的正常4次握手和同步关闭链接致使双方都进入TIME_WAIT状态的4次握手。最后整体学习了TCP客户端以及服务端各类状态迁变的概要图，十分清晰地对TCP各类概况的描述，以及为何会有TIME_WAIT和2MSL的概念。