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。