特性
TCP又名传输控制协议，属于TCP/IP协议中的传输层，与其下层网络层的最重要区别在于它提供了一种面向连接的和可靠的字节流服务。
面向连接
怎么理解面向连接呢，其实就类似于打电话，拨号然后响铃，直到接通后，双方就建立起了一个连接。
如何支撑起TCP的可靠性
首先应用数据被分割成TCP认为最适合发送的数据块，再传输给网络层，数据块被称为报文段或段。
当TCP发出一个段以后，它会启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到确认，那么将重发这个报文段。这基于它的超时重传策略。
当TCP收到来自TCP连接另一端的数据，它会发送一个确认报文，这个确认不是立即发送，通常都将推迟几分之一秒。
TCP将保持它的首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。一旦发现收到的段的检验和有差错，那么TCP将丢弃这个报文段和不会确认收到此报文段，等待重新发送。
TCP报文段是基于IP数据报进行传输，IP数据报不保证有序，因此TCP协议需要对数据进行重新排序，将收到的数据以正确的顺序交给应用层
IP数据报还会发生重复，因此TCP接收端必须有丢弃重复数据的能力。
TCP还提供流量控制，每一方都有固定大小的缓冲区，每次都会告知自己所能容纳的数据，防止缓冲区溢出。
TCP协议格式
TCP传输时是被包裹在IP数据报中的：
TCP协议格式
源和目的端口号都是16位，为了精准递给上层的应用层
序号：用来标识从TCP发送端发送的数据字节流，表示在这个报文段中的第一个数据字节。其对每个字节进行计数，序号是32位的无符号数，序号到达232-1又会从0开始。
新建立连接的时候，SYN标志标为1，序号字段包含由这个主机选择的该连接的初始序号 ISN。主机发送数据的第一个字节序为这个ISN 加1，因为SYN标志消耗了一个序号。
每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上次已成功收到数据字节序号加 1。只有ACK标志为1时 确认序号字段才有效。发送ACK无需任何代价，因为 32 位的确认序号字段和ACK标志一样，总是TCP首部的一 部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置， ACK标志也总是被设置为1。
4位首部长度给出首部以4字节（32位）为单位的个数，因此TCP首部最大可以达到 (24 -1 ) * 4 = 60字节。如没有可选字段，TCP首部长度为20字节。
首部中有 6个标志比特 ：
URG ：紧急指针
ACK ： 确认序号
PSH ： 接收方应该尽快将这个报文段交给应用层
RST ： 重建连接
SYN ： 同步序号用来发起一个连接
FIN ： 发端完成发送任务
16位的窗口用来实现流量控制，稍后我会详细讲解
检验和覆盖了整个TCP报文段：即TCP首部和TCP数据，这是一个强制性的字段，是由发端计算和存储，并由接收端进行验证
只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。
最常见的可选字段是最长报文大小，又称为 MSS (Maximum Segment Size)。每个连接方通常都在通信的第一个报文段（为建立连接而设置 SYN标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。
一个IP地址和一个端口号可以确定网络中某个主机的某个应用，也成为插口（Socket）,也作为伯克利版的编程接口。是包含 源IP 地址、源端口号、目的IP地址、目的端口号的四元组，可唯一确定互联网中每个TCP连接双方。
实践出真知
接下来的内容主要以理论加实践的方式，自己动手实践之后就更能够发现一些有趣的问题，同时也能够理解的更加深刻！下面由浅入深的来讲一讲。
TCP连接的建立（三次握手）
首先来看看经典的三次握手的过程：
很好理解，左侧是客户端，右侧是服务端，旁边标注的此时TCP的状态。
首先客户端发送一个SYN的包用于发起连接，此时的seq序列号由自己指定
服务端收到后从原来的监听（LISTEN）状态转换为SYN_RCVD状态
服务端向客户端发送一个SYN ， ACK标注的包，此时ACK为客户端发来的seq序号加1，seq则自己指定
客户端收到包后转为ESTABLISHED状态，并且向服务端发送一个包来确认，此时ACK确认序号为服务器发来的seq的值加1
最后服务器收到确认包之后将自己的状态转变为ESTABLISHED
到此双发已经建立好了连接，三次握手结束。下面来看看我实际的抓包
下面的抓包是我在服务器上用tcpdump抓到的，客户端是自己电脑上的telnet,服务器监听用的工具是nc
我已经很贴心的把选项表示的意思标注清楚了，如果有小伙伴想要我文章中的原图，可以从公众号加我的微信。
TCP连接的建立（四次挥手）
我依然画了一个图：
建立好连接之后，客户端先发送FIN数据包，并将TCP状态变为FIN_WAIT_1。
服务端收到FIN包，将自己的状态转换为CLOSE_WAIT,并发送ACK确认包
客户端接收到ACK包之后，将自己的状态变为FIN_WAIT_2,等待服务端发送FIN和ACK
服务端发送之后将自己的状态置为LAST_ACK
客户端收到包后将自己的状态转换为TIME_WAIT，等待2MSL（报文段的最大生存时间）
服务端收到ACK后将状态置为CLOSED，四次挥手结束
这里有很多值得说的点，但是篇幅有限，可能需要放在下一篇来讲
实践
仔细看会发现一个有趣的事情，如果你不动手亲自实验的话很难知道
注意，这里并不是发生了四次挥手，而是三次！！！为什么会出现这种情况呢？！ 我又试了不同的服务端和客户端，然后自己用C++代码写了客户端和服务端程序用来控制程序的断开和连接，我发现依然还是。
查阅后，原来是因为 TCP的延迟确认特性。因为中间服务端会先发一次ACK再发一次FIN+ACK。因此这种特性使这两个数据包合并成一个。
小结
这篇就到这儿吧，太长的话不利于阅读，等我把这个系列写完会出一篇方便进行收藏的整合文章，方便大家进行阅读、查阅和学习！文章来源于互联网:TCP/IP协议之四TCP协议（上）—理论+实践给你讲清楚
