TCP协议三次握手和四次挥手抓包分析
TCP协议在双方建立连接的时候需要三次握手，首先客户端发送SYN标志为1的TCP数据包，然后服务器端收到之后，也会发送一个SYN标志置位，并且带有ack应答的数据包，最后客户端再发送给服务端一个应答，这样就建立起了通信。
首先看TCP数据包头部各个字段：
在三次握手和四次挥手过程中，主要看UAPRSF6个标志和seq ack的变化。首先使用telnet程序测试，比如telnet 8.8.8.8 443，使用tcpdump -i enp0s3 -X -vv tcp -s0 命令看通信过程
192.168.0.10.53548 > 14.215.177.39.https 表示从192.168.0.10的53548端口发送到了14.215.177.39的https(443)端口，Flags [S]表示发送的SYN，也就是连接标志，seq 1436271743表示序号， win 29200表示窗口大小，options [mss 1460,sackOK,TS val 16451924 ecr 0,nop,wscale 7]是在正式建立连接前告诉对方自己的一些选项字段，比如mss表示自己的最大报文长度是1460，length：0表示数据字段部分为0，就是没有数据。
以太网帧完整数据：
0x0000: 4510 003c cd2b 4000 4006 eccf c0a8 000a E..<.+@.@....... 0x0010: 0ed7 b127 d12c 01bb 559b c47f 0000 0000 ...'.,..U....... 0x0020: a002 7210 80df 0000 0204 05b4 0402 080a ..r............. 0x0030: 00fb 0954 0000 0000 0103 0307 ...T........ 主要看TCP头部相关的内容和TCP头部图对比下，第二行的 0x559b c47f表示seq，0x0000 0000表示ack，第三行的0xa002表示TCP头部长度是10 * 4 = 40字节，并且SYN为1表示发起连接请求。
下面看服务器端的回复
14.215.177.39.https > 192.168.0.10.53548: Flags [S.], cksum 0x418e (correct), seq 2784679373, ack 1436271744, win 8192, options [mss 1440,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0 表示14.215.177.39的443端口发送给192.168.0.10的53548端口的SYN连接，seq是2784679373, ack就是客户端发去的seq +1，其中服务端的mss是1440
以太网帧如下：
0x0000: 4500 003c cd2b 4000 3806 f4df 0ed7 b127 E..<.+@.8......' 0x0010: c0a8 000a 01bb d12c a5fa d5cd 559b c480 .......,....U... 0x0020: a012 2000 418e 0000 0204 05a0 0402 0101 ....A........... 0x0030: 0101 0101 0101 0101 0103 0305 ............ 其中标志为变为了0x12，ACK和SYN都为1，表示发送的是带有ack回应的SYN连接。
看最后一次握手，客户端发送给服务器端的确认
192.168.0.10.53548 > 14.215.177.39.https: Flags [.], cksum 0x80cb (incorrect -> 0xc571), seq 1, ack 1, win 229, length 0，发现没了选项字段，说明在默认情况下，选项字段是在三次握手中前两次握手时确定了双方的各种属性。
以太网帧如下：
0x0000: 4510 0028 cd2c 4000 4006 ece2 c0a8 000a E..(.,@.@....... 0x0010: 0ed7 b127 d12c 01bb 559b c480 a5fa d5ce ...'.,..U....... 0x0020: 5010 00e5 80cb 0000 P.......
seq0x559b c480也就是服务端发来的ack字段，ack为服务端的seq + 1，标志变成了0x10只置位了ACK字段，说明这就是一个简单的确认报文。
三次握手过程如下图：
图中的UAPRSF表示TCP头部的标志位字段， 客户端会有两种状态：SYS_SENT, ESTABLISHED，我们使用netstat -npt命令可以看到这种状态的转换，比如telnet一个不存在的IP端口号，会看telnet一直处于SYS_SENT，直到进程退出，如果连接成功会变成ESTABLISHED， 服务端有三种状态LISTEN, SYS_RCVD, ESTABLISHED, LISTNE表示正在监听某一个端口，在接受到客户端发送的SYN时会变为SYS_RCVD,然后再发送一个SYN报文给客户端，客户端回复确认后，会从SYS_RCVD变为ESTABLISHED.也就是服务端和客户端已经连接成功。
再看四次挥手，四次挥手如果使用telnet 百度网站的话如果输入quit，是由服务端发起关闭连接的，如果直接关掉telnet程序的话，客户端会一直发送FIN报文，但是服务端不会响应了，所以这次自己写个socket服务端程序和客户端程序，先看具体报文
发现只有三段报文，书上说四次挥手，为啥不一样呢，怎么变成了三次，TCP/TP协议详解四次挥手过程是1.客户端发送FIN报文2.服务端响应发送ack 3.服务端发送FIN报文 4.客户端发送响应ack报文。而抓包结果是第二和第三也就是服务端发送的ack和FIN合并成了一个报文。先具体分下下各个报文
192.168.0.10.55728 > 192.168.0.10.8887: Flags [F.], cksum 0x818b (incorrect -> 0x07a3), seq 1, ack 1, win 342, options [nop,nop,TS val 17498958 ecr 17497745], length 0 客户端的55728发送给服务端的8887端口，FIN标志为1
以太网帧如下：
0x0000: 4500 0034 7214 4000 4006 474b c0a8 000a E..4r.@.@.GK.... 0x0010: c0a8 000a d9b0 22b7 eb37 8c84 f7c4 7c80 ......"..7....|. 0x0020: 8011 0156 818b 0000 0101 080a 010b 034e ...V...........N 0x0030: 010a fe91 .... 标志位为 0x11，ACK 和FIN为1，所以客户端发送的是关闭连接请求。
192.168.0.10.8887 > 192.168.0.10.55728: Flags [F.], cksum 0x818b (incorrect -> 0x02e5), seq 1, ack 2, win 342, options [nop,nop,TS val 17498958 ecr 17498958], length 0 服务端回复的也是FIN报文
以太网帧如下：
0x0000: 4500 0034 8211 4000 4006 374e c0a8 000a E..4..@.@.7N.... 0x0010: c0a8 000a 22b7 d9b0 f7c4 7c80 eb37 8c85 ....".....|..7.. 0x0020: 8011 0156 818b 0000 0101 080a 010b 034e ...V...........N 0x0030: 010b 034e ...N 标志位为0X11， ACK和FIN为1，如果按照书本上说的应该是0X10的，只发送ACK，不发送FIN，但是这里两个合并了。
192.168.0.10.55728 > 192.168.0.10.8887: Flags [.], cksum 0x818b (incorrect -> 0x02e5), seq 2, ack 2, win 342, options [nop,nop,TS val 17498958 ecr 17498958], length 0 服务端发送ack应答，断开连接完毕。
所以这里有个疑问点，为啥断开连接只交互了三次，而不是四次，因为我写的程序里客户端关闭连接后，服务端立马关闭连接，没有了任何数据传输，而且都是调用的close，所以服务端将第二次第三次合并成了一个报文，这样做就是捎带ACK，减少一次通信。服务端代码如下
package per.pzt.socket;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
public class Server {
private static final Integer PORT = 8888;
private Socket socket;
private ServerSocket serverSocket;
public Server(int port) {
try {
serverSocket = new ServerSocket(port);
} catch (IOException e) {
e.printStackTrace();
}
}
public static void main(String[] args) throws IOException {
Server server = new Server(PORT);
BufferedReader br = null;
PrintWriter pw=null;
while((server.socket = server.serverSocket.accept()) != null) {
br = new BufferedReader(new InputStreamReader(server.socket.getInputStream()));
pw = new PrintWriter(new OutputStreamWriter(server.socket.getOutputStream()));
String msg = null;
while((msg = br.readLine()) != null){
System.out.println("client:" + msg);
if(msg.equals("exit")){
break;
}
pw.println(msg);
pw.flush();
}
//server.closeSocket();
server.socket.shutdownInput();
pw.println("goodbye");
pw.flush();
server.socket.shutdownOutput();;
}
server.serverSocket.close();
}
}如果客户端和服务端采用半连接方式通信，也就是客户端关闭时先调用socket.shutdownOutput，对应的系统调用api是shutdown(fd,1)关闭输出通道，服务端关闭时先调用shutdownInput对应的系统调用api是shutdown(fd,0)，然后服务端发送最后的数据goodbye给客户端，然后服务端调用shutdownOutput彻底关闭双向通道，客户端接收后调用shutdownInput也关闭输入通道。此时的报文为
五段报文，1.客户端发送FIN。2.服务端回应FIN，并且携带数据goodbye。3.服务端发送FIN。4.客户端回应goodbye。5.客户端回应服务端FIN。看回应哪个报文就看seq和ack的对应值就可以了。所以除了回应goodbye的报文，确实是四次挥手。1，2，3，5构成了四次挥手。
接着改造把服务端和客户端都改为socket.close调用，也就是不用半关闭，直接全部关闭双向通道。但是在服务端close之前Thread.sleep(1)。服务端休眠1ms，得到的报文如下
这就是标准的4次挥手，可以得处一个结论，如果在客户端关闭后，服务端无任何操作也是直接关闭，则服务端会将四次挥手第二三次挥手合并为1个报文，也就是FIN+ACK，捎带ACK机制，如果是半连接状态，则会使用四次挥手，或者如果服务端没有立即关闭通道，而是做了其它的操作，再关闭，则也是四次挥手。看了LWIP的TCP/IP协议栈实现源码，确实是这样操作的，客户端有一种情况直接从FIN_WAIT_1到TIME_WAIT状态，服务端也有一种是从CLOSE_WAIT到LAST_ACK状态是在一个通信报文段实现的，也就是正常情况下CLOSE_WAIT到LAST_ACK需要发送两段报文，但是在三次挥手的情况下，只发送一段报文就可以了。所以在客户端关闭后，服务端无任何操作立即关闭的情况下，只需要三次挥手即可，减少一次通信。
看TCP断开连接图：
正常情况四次挥手。
双方都立即断开的情况下只需要三次挥手（捎带ACK），其中服务端CLOSE_WAIT 到LAST_ACK 我们使用netstat -npt看不到（除非debug调试），我看LWIP协议栈对这段处理，CLOSE_WAIT只作为了一个中间状态，在发送完FIN+ACK的报文后，直接变为了LAST_ACK。