Linux TCP协议——三次握手，四次挥手

一、TCP协议介绍

TCP协议是可靠的、面向连接的、基于字节流的传输层通信协议。

TCP的头部结构：

源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;（tcp是传输层的协议，端与端之间的数据传输，在TCP和UDP协议当中不会体现出IP）

32位序号：一次TCP通信（从TCP连接建立到断开）过程中某一个传输方向上的字节流的每个字节的编号。

32位确认号：对另一方发送来的TCP报文段的响应，即告知发送端期待发送的下一条序号。其值是收到的TCP报文段的序号值加1。

4位TCP报头长度：表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60

16位窗口大小：告诉发送方字节的接收能力

6位标志位：

16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分，简单来说就是检验TCP数据是否在传输过程中失真。

16位紧急指针: 标识哪部分数据是紧急数据。

二、三次握手

面向连接指TCP连接的本质是在建立三次握手时期，通信双方会协商很多连接当中的数据。对于TCP而言，如果通信双方不建立连接则不能进行通信。

在listen()方法中第二个参数就是指定已完成三次握手队列的长度。

TCP在建立连接的时候，客户端就会先给服务器端发送一个TCP报文段，然后服务器端再给客户端恢复一个TCP报文段，最后客户端再给服务器端回复，一共三次。

三次握手的具体过程是：

第一次握手：当客户端执行connet()这行代码的时候开始进行三次握手，此时客户端就会在传输层给服务端发送一个SYN报文，SYN报文中有一个序号，这个序号就是自己的序号（32位序号），假设这个序号为i。

第二次握手：服务器收到之后会给客户端一个回复，回复的是SYN报文，此报文中也有一个自己的序号，假设这个序号为j，还有ACK报文，是一个确认号，这个确认号就是对刚刚客户端发来的序号进行确认，由于客户端发来的序号值为i，则这个确认号就为i+1，服务器向客户端回复的时候序号和确认号可以写到一个报文中。

第三次握手：客户端收到服务器端的回复之后，再给客户端发送一个报文ACK进行确认，对刚刚服务器返回回来的序号进行确认，由于服务器回复到客户端的序号为j，所以确认的序号应该为j+1。

具体过程如下图所示：

注意：三次握手发生在建立连接的时候，connect开始执行发起连接三次握手开始，connect返回成功三次握手结束。但是连接发送的syn,syn+ack，ack用户都没有直接参与，换句话说，在发送这些数据包的时候，用户并没有给传输层的TCP协议提交任何数据。这里的syn,syn+ack，ack全部都是TCP协议报头的内容。

三、四次挥手

在客户端与服务器通信完毕过后，谁先调用close，开始进行四次挥手。一般来说，主动断开方都是客户端。

以断供开方为客户端为例：

第一次挥手：当客户端执行到close这行代码的时候就意味着要断开和客户端的连接了，此时开始进行四次挥手，客户端给服务器端发送一个FIN报文，假如它的序号值为n。

第二次挥手：服务器端接收到了客户端的FIN报文，马上给客户端发送一个确认信息，即ACK报文，确认号为n+1，确认已经收到客户端要断开的信息。

第三次挥手：服务器端给客户端发送了确认信息之后，也执行close，表示服务器端也要断开了，此时服务器端给客户端发送一个FIN报文，假如它的序号值为m。

第四次挥手：客户端接收到了服务器端的FIN报文，马上给服务器端发送一个确认信息，即ACK报文，确认号为m+1，确认已经收到服务器端要断开的信息。

具体过程如下图所示：

注意：四次挥手断开连接时发送的FIN，ACK用户都没有直接参与，是底层协议自己完成的，在代码层面只需要close。