一、TCP协议介绍
1.1 介绍
传输控制协议 TCP(Transmission Control Protocol)提供一种面向连接的、可靠的字节流服务。
面向连接意味着两个使用TCP的应用（通常是一个客户端和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。
字节流服务表示双方发送数据之前双方约定一次发送多少字节（8 bit)的数据。
1.2 特征
全双工通信
数据可以在同一时间双向流动
传输确认
当TCP发出一个分段后，它会启动一个定时器（RTO），等待目的端确认收到这个报文段；如果不能及时收到一个确认，将重发这个报文段（超时重传）。
当TCP收到发自TCP连接另一端的数据，它将发送一个确认；这个确认不是立即发送，通常将推迟几分之一秒。如果数据包丢失则会启用重传机制
差错控制
TCP将保持它首部和数据的校验和
当TCP报文段到达后失序，TCP将对收到的数据进行重新排列，将收到的数据以正确的顺序交给应用层。
当IP数据报发生重复，TCP的接收端会丢弃重复的数据
流量控制
TCP连接的每一方都有一个固定大小的缓冲空间。
TCP的接受端只允许另一端发送接受端缓冲区所能接纳的数据，这将防止较快的主机致使较慢的主句的缓冲区溢出。
1.3 TCP头部
-
源端口号与目的端口号
每个TCP段都包含源端和目的端的端口号，用于寻找发送端和接收端的应用进程。通过四元组唯一确定一个TCP连接。
一个IP地址和一个端口号也称为一个插口（socket），插口对（socketpair）即四元组可唯一确定互联网中每一个TCP连接的双方。 -
序号
用来标识从TCP发送端向TCP接收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。如果将字节流看作在两个程序间的单向流动，则TCP用序号对每个字节进行计数。
序号是32bit的无符号数，序号到达2的32次方后又从0开始。 -
确认序号
是上次已成功接收到数据字节序号加1。只有ACK标志为1时确认序号字段才有效。
32bit的确认序号字段和ACK标志一样作为TCP首部的一部分，一旦TCP连接建立，这个字段总是被设置，ACK标志也被置为1。
TCP是一个全双协议，在每一个方向上都需要一个序列号来确认收到的数据，收到多少个字节则确认序列号就加多少。 -
首部长度
首部长度给出首部中32bit的数目。需要这个值是因为任选字段的长度可变。这个字段占4bit，因此TCP最多有60字节的首部。然而，没有任选字段，正常的长度是20字节。 -
标志位
在TCP首部中有6个标志比特，它们中的多个可同时被设置为1。- URG：紧急指针有效
- ACK：确认序号有效
- PSH：接收方应该尽快将这个报文段交给应用层。
- RST：重建连接。
- SYN：同步序号用来发起一个连接。
- FIN：发送端完成发送任务。
-
窗口大小
窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收到的字节。
窗口大小是一个16bit字段，因此窗口大小最大为65535字节（新的窗口刻度选项，允许这个值按比例变化以提供更大的窗口。 -
校验和
校验和覆盖了整个TCP报文段：TCP首部和TCP数据。
由发送端计算和存储，并由接收端进行验证。 -
紧急指针
只有当URG标志置1时紧急指针才有效。
紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。 -
选项
最常见的可选字段是最长报文大小，又称MSS。每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的报文段）中指明这个选项。它指明本端所能接收的最大长度的报文段。 -
数据
数据部分是可选的。在一个连接建立和一个连接终止时，双方的报文段仅有TCP首部。
如果一方没有数据要发送，也仅使用TCP首部来确认收到的数据。在处理超时等情况时也如此。
二、TCP连接
TCP是面向连接的传输，需要经历三个阶段：
- 第一步：连接建立
服务端在特定端口提供服务
监听特定TCP端口的数据
客户端发起连接请求
连接建立过程称为“三次握手” - 第二步：数据传输
- 第三步：连接终止
2.1 三次握手
三次握手的原因：
- 三次握手才可以阻止重复历史连接的初始化（主要原因）
- 三次握手才可以同步双方的初始序列号
- 三次握手才可以避免资源浪费
2.1.1 连接建立过程
-
客户端发送连接请求
由客户端发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且将报文中的SYN字段置为1，表示需要建立TCP连接。（SYN=1，seq=x，x为随机生成数值） -
服务器发送连接确认
由服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接。 -
客户端发送连接确认
客户端收到服务端发送的TCP建立验证请求后，会使自己的序列号加1表示，并且再次回复ACK验证请求，在服务端发过来的seq上加1进行回复。（SYN=1，ACK=y+1，seq=x+1）
2.1.2 抓包分析
下图为本地客户端访问百度服务器时TCP连接建立过程
-
查看客户端SYN包
SYN包
可以看到该数据包TCP首部中序列号为267456992（为绝对序列号），同时同步位SYN置1（因此据此可以初步判定该数据包为TCP连接的首包）。 -
查看服务器连接确认包
Server ACK
该数据包TCP首部中序列号为2909279490，确认号为267456993；同时确认位与同步位被置为1. -
查看客户端连接确认包
Client ACK
该数据包中TCP首部序列号为267456993，确认号为2909279491；仅确认位置1。
2.1.3 TCP连接建立失败的情况
-
TCP拒绝（被RST重置）
该情况为客户端发送SYN包后收到服务端的RST包，服务拒绝建立连接。
原因可能是：
1.服务器不提供客户端请求端口的服务。
2.服务器保持的TCP连接数达到极限，不能再接受客户端连接请求。
3.服务器上该指定服务宕机。
4.防火墙策略不允许，防火墙发送RST数据包中断连接。 -
客户端主动断开连接
客户端发起连接后得到服务端的确认后，客户端向服务器发送RST包，表示不想建立连接了。
可能原因：
1.客户端对服务器端口进行探测。
2.客户端主机故障。
3.客户端程序认为请求超时，程序设置了定时器在该时间内未收到确认。 -
TCP半连接
客户端在发送请求连接后，不再发送任何数据
可能原因：
1.客户端故障。
2.恶意端口扫描。
3.SYN攻击。 -
TCP连接无响应
客户端发出请求连接后得不到任何回应。
可能原因：
1.主机不在线。
2.网络不可达。
3.防火墙丢弃数据包。
2.2 四次挥手
由于TCP为全双工通信，需要双向断开连接
2.2.1 挥手过程
-
客户端断开连接
1、客户端发送断开TCP连接请求的报文，其中报文中包含seq序列号，是由发送端随机生成的，并且还将报文中的FIN字段置为1，表示需要断开TCP连接。（FIN=1，seq=x，x由客户端随机生成）
2、服务端会回复客户端发送的TCP断开请求报文，其包含seq序列号，是由回复端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。（FIN=1，ACK=x+1，seq=y，y由服务端随机生成） -
服务器端断开连接
3、服务端在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，所有传输到A的数据是否已经传输完毕，一旦确认传输数据完毕，就会将回复报文的FIN字段置1，并且产生随机seq序列号。（FIN=1，ACK=x+1，seq=z，z由服务端随机生成）
4、客户端收到服务端的TCP断开请求后，会回复服务端的断开请求，包含随机生成的seq字段和ACK字段，ACK字段会在服务端的TCP断开请求的seq基础上加1，从而完成服务端请求的验证回复。（FIN=1，ACK=z+1，seq=h，h为客户端随机生成）
2.2.2 TCP连接断开的特殊情况
1.TCP半关闭
当TCP会话的其中一方已经完成数据发送，发送FIN报文关闭会话；而收到FIN报文的一方如果仍然有数据需要发送，则可以不发送FIN报文完全关闭会话，而是利用这个会话继续向对方发送数据，直到应用层数据传送完毕再通知TCP层发送FIN报文彻底关闭会话。
2.TCP连接重置式关闭
有些应用程序如HTTP浏览器可能会在数据传输完成后采取直接发送“RST”数据包给服务器，同时自身直接关闭TCP连接，接收方接收到“RST”包后直接关闭TCP连接。当TCP连接传输数据异常时也可能采取此方式关闭TCP连接。
