TCP协议及TCP正常连接与断开

Posted 2020-08-24

一、TCP协议简介
TCP，全称Transfer Control Protocol，中文名为传输控制协议，它工作在OSI的传输层，提供面向连接的可靠传输服务。
TCP的工作主要是建立连接，然后从应用层程序中接收数据并进行传输。TCP采用虚电路连接方式进行工作，在发送数据前它需要在发送方和接收方建立一个连接，数据在发送出去后，发送方会等待接收方给出一个确认性的应答，否则发送方将认为此数据丢失，并重新发送此数据。
下面我们来介绍一下TCP的报头结构和相关工作原理：
1、TCP报头
TCP报头总长最小为20个字节，其报头结构如下图所示

比特0                                               比特15   比特16                           比特31

源端口（16）			目的端口（16）
序列号（32）
确认号（32）
TCP偏移量（4）	保留（6）	标志（6）	窗口（16）
校验和（16）			紧急（16）
选项（0或32）
数据（可变）

源端口：指定了发送端的端口号
目标端口：指定了接受端的端口号
序号：指明了段在即将传输的段序号中的位置
确认号：规定成功收到段的序列号，确认号包含发送确认的一端所期望收到的下一个序号
TCP偏移量：指定了段头的长度。段头的长度取决于段头选项字段中设置的选项
保留：指定了一个 保留字段，以备将来使用
标志：SYN、ACK、PSH、PST、URG、FIN
    SYN：表示同步
    ACK：表示确认
    PSH：表示尽快的将数据送往接收进程
    PST：表示复位连接
    URG：表示紧急指针
    FIN：表示发送方完成数据发送
    需要注意的是：
  （A）不要将确认序号ACK与标志位中的ACK搞混了。
  （B）确认方Ack=发起方Req+1，两端配对。
窗口：指定关于发送端能传输的下一段的大小的指令
校验和：校验和包含TCP段头和数据部分，用来校验段头和数据部分的可靠性
紧急：指明端中包含紧急信息，只有端URG标志位置为1时紧急指针才会有效
选项：指明了认得段大小，时间戳，选项字段的末端，以及指定了选项字段的边界选项
2、TCP工作原理
1）TCP连接建立：TCP的连接建立过程又称为TCP三次握手。首先发送方主机向接收方主机发起一个建立连接的同步（SYN）请求；接收方主机在收到这个请求后向送方主机回复一个同步/确认（SYN/ACK）应答；发送方主机收到此包后再向接收方主机发送一个确认（ACK），此时TCP连接成功建立；
2）TCP连接关闭：发送方主机和目的主机建立TCP连接并完成数据传输后，会发送一个将结束标记置1的数据包，以关闭这个TCP连接，并同时释放该连接占用的缓冲区空间；
3）TCP重置：TCP允许在传输的过程中突然中断连接，这称为TCP重置；
4）TCP数据排序和确认：TCP是一种可靠传输的协议，它在传输的过程中使用序列号和确认号来跟踪数据的接收情况；
5）TCP重传：在TCP的传输过程中，如果在重传超时时间内没有收到接收方主机对某数据包的确认回复，发送方主机就认为此数据包丢失，并再次发送这个数据包给接收方，这称为TCP重传；
6）TCP延迟确认：TCP并不总是在接收到数据后立即对其进行确认，它允许主机在接收数据的同时发送自己的确认信息给客户端。
7）TCP数据保护（校验和）：TCP是可靠传输的协议，它提供校验和计算来实现数据在传输过程中的完整性。

三、TCP的11种状态

CLOSED：表示初始状态。对服务端和C客户端双方都一样。
LISTEN：表示监听状态。服务端调用了listen函数，可以开始accept连接了。
SYN_SENT：表示客户端已经发送了SYN报文。当客户端调用connect函数发起连接时，首先发SYN给服务端，然后自己进入SYN_SENT状态，并等待服务端发送ACK+SYN。
SYN_RCVD：表示服务端收到客户端发送SYN报文。服务端收到这个报文后，进入SYN_RCVD状态，然后发送ACK+SYN给客户端。
ESTABLISHED：表示连接已经建立成功了。服务端发送完ACK+SYN后进入该状态，客户端收到ACK后也进入该状态。
FIN_WAIT_1：表示主动关闭连接。无论哪方调用close函数发送FIN报文都会进入这个这个状态。
FIN_WAIT_2：表示被动关闭方同意关闭连接。主动关闭连接方收到被动关闭方返回的ACK后，会进入该状态。
TIME_WAIT：表示收到对方的FIN报文并发送了ACK报文，就等2MSL后即可回到CLOSED状态了。如果FIN_WAIT_1状态下，收到对方同时带FIN标志和ACK标志的报文时，可以直接进入TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING：表示双方同时关闭连接。如果双方几乎同时调用close函数，那么会出现双方同时发送FIN报文的情况，此时就会出现CLOSING状态，表示双方都在关闭连接。
CLOSE_WAIT：表示被动关闭方等待关闭。当收到对方调用close函数发送的FIN报文时，回应对方ACK报文，此时进入CLOSE_WAIT状态。
LAST_ACK：表示被动关闭方发送FIN报文后，等待对方的ACK报文状态，当收到ACK后进入CLOSED状态。

介绍2MSL时间
2MSL时间，当客户端最后给服务端发送ACK后，不立即进入CLOSED状态，这2MSL时间是为了防止客户端发送的ACK包丢失而让服务端一直处于LAST_ACK状态，让服务端处于LAST_ACK超时重发FIN。

四、TCP三次握手及其状态转换

1、第一次握手
客户端从CLOSED状态主动打开向服务器端发送SYN报文，SYN报文中seq标志位置换为1，并随机生成序列号seq为x，同时客户端进入SYN_SENT状态。
2、第二次握手
服务器端从CLOSED状态别动打开进入LISTEN监听状态，当收到客户端发送的SYN报文后，发送SYN+ACK报文，报文中seq和ack标志位同时置换为1，并随机上次序列号seq为y，确认号ACK为客户端序列号x+1，同时服务器端进入SYN_RCVD状态。
3、第三次握手
客户端接收到服务器端发送的SYN+ACK报文后，发送ACK报文，ACK报文中ack标志位置换为1，序列号seq为x+1，确认号ACK为服务器端序列号y+1，同时进入ESTABLISHED状态。服务端收到客户端发送的ACK报文后，进入ESTABLISHED状态。到此TCP三次握手建立连接完成。

补充：
SYN攻击
在三次握手过程中，服务器端发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接（half-open connect），此时服务器端处于SYN_RCVD状态，当收到ACK后，服务器端转入ESTABLISHED状态。SYN攻击就是客户端在短时间内伪造大量不存在的IP地址，并向服务器端不断地发送SYN包，服务器端回复确认包，并等待客户端的确认，由于源地址是不存在的，因此，服务器端需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当服务器端上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：
#netstat -nap | grep SYN_RECV

五、TCP四次挥手及其状态转换

1、第一次挥手
1）客户端在ESTABLISHED状态，发送一个FIN报文，FIN报文中FIN标志位置换为1，序列号seq为上一次发送的序列号加1，这里我们使用n表示，同时进入FIN_WAIT_1状态。
2、第二次挥手
2）服务器端接收到客户端的FIN报文后，发送ACK报文，ACK报文中ack标志位置换为1，确认号ACK为n+1，同时进入CLOSE_WAIT状态，这时TCP处于半关闭状态。
3）客户端接收到服务器端发送的ACK报文后进入FIN_WAIT_2状态
3、第三次挥手
4）服务器端将数据传输完毕后，发送FIN报文，FIN报文中FIN标志位置换为1，序列号seq为上一次发送的序列号加1，这里我们使用m表示，同时进入LAST_ACK状态。
4、第四次挥手
5）客户端接收到服务器端发送的FIN报文后，发送ACK报文，ACK报文中ack标志位置换为1，序列号seq为n+1，确认号ACK为m+1，同时进入TIME_WAIT状态，并等待2MSL（60秒）时间，超时后进入CLOSED状态。
6）服务器端收到客户端的ACK报文后进入CLOSED状态

六、问题
1、为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
1）由于TCP连接为全双工
2）当服务器端端收到客户端端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务器端端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端端，"你发的FIN报文我收到了"。只有等到我服务器端端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

2、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间60s)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
1）实现TCP全双工的可靠的关闭
2）允许老的重复的报文消失

本文出自 “炫维” 博客，请务必保留此出处http://xuanwei.blog.51cto.com/11489734/1884213