理解TCP/IP的三次握手和四次挥手（Linux Centos6.10 命令tcpdump）
TCP报头
三次握手
SYN：同步序列编号（Synchronize Sequence Numbers）
第一次握手：
建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；
第二次握手：
服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器由LISTEN进入SYN_RECV状态；
第三次握手：
客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
四次挥手
1、客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2、服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3、客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4、服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5、客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL(最大报文段生存时间)的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6、服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
SYN-SEND
LISTEN
SYN-RCVD
ACK
ESTABLISHED
FIN
FIN-WAIT-1
CLOSE-WAIT
FIN-WAIT-2
TIME-WAIT
CLOSED
CLOSED
LISTEN
SYN_RCVD
SYN_SENT
ESTABLISHED
FIN_WAIT_1
FIN_WAIT_2
TIME_WAIT
CLOSING
CLOSE_WAIT
LAST_ACK
1、建立TCP连接，请求百度首页，并返回结果定向到8
[root@nailwl ~]# mkdir -p /dev/tcp
[root@nailwl ~]# exec 8<> /dev/tcp/www.baidu.com/80
[root@nailwl ~]# echo -e "GET / HTTP/1.0\n" >& 8
2、查看百度首页内容，通过8
[root@nailwl ~]# cat <& 8
HTTP/1.0 200 OK
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 14615
Content-Type: text/html
Date: Sun, 12 Apr 2020 03:48:15 GMT
P3p: CP=" OTI DSP COR IVA OUR IND COM "
P3p: CP=" OTI DSP COR IVA OUR IND COM "
Pragma: no-cache
Server: BWS/1.1
Set-Cookie: BAIDUID=A8ECC288A119BAE5D9F74FA593C71186:FG=1; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BIDUPSID=A8ECC288A119BAE5D9F74FA593C71186; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: PSTM=1586663295; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BAIDUID=A8ECC288A119BAE52BAEAE342EFD9491:FG=1; max-age=31536000; expires=Mon, 12-Apr-21 03:48:15 GMT; domain=.baidu.com; path=/; version=1; comment=bd
Traceid: 1586663295266462081011483520753603889932
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1
百度一下，你就知道
[root@nailwl ~]# 
使用tcpdump开始抓吧，主要信息是arp和80端口的数据
[root@nailwl ~]# tcpdump -nn -i eth0 arp or port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:20:59.251675 ARP, Request who-has 192.168.47.2 tell 192.168.47.131, length 28
15:20:59.251907 ARP, Reply 192.168.47.2 is-at 00:50:56:f3:a6:79, length 46
15:20:59.254690 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [S], seq 1518759721, win 14600, options [mss 1460,sackOK,TS val 10827046 ecr 0,nop,wscale 7], length 0
15:20:59.269738 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [S.], seq 1285389172, ack 1518759722, win 64240, options [mss 1460], length 0
15:20:59.269780 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 1, win 14600, length 0
15:21:22.426456 ARP, Request who-has 192.168.47.131 (00:0c:29:a5:14:57) tell 192.168.47.1, length 46
15:21:22.426486 ARP, Reply 192.168.47.131 is-at 00:0c:29:a5:14:57, length 28
15:21:24.678084 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [P.], seq 1:16, ack 1, win 14600, length 15
15:21:24.678393 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], ack 16, win 64240, length 0
15:21:33.753830 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [P.], seq 16:17, ack 1, win 14600, length 1
15:21:33.754246 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], ack 17, win 64240, length 0
15:21:33.769824 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [P.], seq 1:1413, ack 17, win 64240, length 1412
15:21:33.769856 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 1413, win 16944, length 0
15:21:33.769893 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [P.], seq 1413:2825, ack 17, win 64240, length 1412
15:21:33.769903 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 2825, win 19768, length 0
15:21:33.770370 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], seq 2825:4285, ack 17, win 64240, length 1460
15:21:33.770386 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 4285, win 23360, length 0
15:21:33.770417 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], seq 4285:5745, ack 17, win 64240, length 1460
15:21:33.770426 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 5745, win 26280, length 0
15:21:33.770453 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], seq 5745:7205, ack 17, win 64240, length 1460
15:21:33.770465 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 7205, win 29200, length 0
15:21:33.770491 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], seq 7205:8665, ack 17, win 64240, length 1460
15:21:33.770500 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 8665, win 32120, length 0
15:21:33.770527 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], seq 8665:10125, ack 17, win 64240, length 1460
15:21:33.770585 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 10125, win 35040, length 0
15:21:33.770612 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], seq 10125:11585, ack 17, win 64240, length 1460
15:21:33.770622 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 11585, win 37960, length 0
15:21:33.770671 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], seq 11585:13045, ack 17, win 64240, length 1460
15:21:33.770681 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 13045, win 40880, length 0
15:21:33.770708 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], seq 13045:14505, ack 17, win 64240, length 1460
15:21:33.770718 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 14505, win 43800, length 0
15:21:33.770745 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [P.], seq 14505:15552, ack 17, win 64240, length 1047
15:21:33.770756 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [.], ack 15552, win 46720, length 0
15:21:33.771025 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [FP.], seq 15552, ack 17, win 64240, length 0
15:21:33.772709 IP 192.168.47.131.33336 > 220.181.38.149.80: Flags [F.], seq 17, ack 15553, win 46720, length 0
15:21:33.772953 IP 220.181.38.149.80 > 192.168.47.131.33336: Flags [.], ack 18, win 64239, length 0
15:21:42.103075 ARP, Request who-has 192.168.47.254 tell 192.168.47.131, length 28
15:21:42.103420 ARP, Reply 192.168.47.254 is-at 00:50:56:ec:7d:14, length 46
^C
38 packets captured
38 packets received by filter
0 packets dropped by kernel
[root@nailwl ~]#
其中flag[S]、[.]、[P]、[F]都是什么意思呢。
Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or `.' (ACK), or `none' if no flags are set.
Data-seqno describes the portion of sequence space covered by the data in this packet (see example below).
Ack is sequence number of the next data expected the other direction on this connection.
Window is the number of bytes of receive buffer space available the other direction on this connection.
Urg indicates there is `urgent' datain the packet.
Options are tcp options enclosed in angle brackets (e.g., ). 步骤：
1、清除arp并且nc请求www.baidu.com的80端口
2、指定请求方式为：GET，HTTP协议版本1.0
3、回车确认执行，将www.baidu.com:80的内容请求回来
[root@nailwl ~]# arp -d 192.168.47.2 && nc www.baidu.com 80
GET / HTTP/1.0
HTTP/1.0 200 OK
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 14615
Content-Type: text/html
Date: Sun, 12 Apr 2020 11:28:58 GMT
P3p: CP=" OTI DSP COR IVA OUR IND COM "
P3p: CP=" OTI DSP COR IVA OUR IND COM "
Pragma: no-cache
Server: BWS/1.1
Set-Cookie: BAIDUID=5346B30DBA001AAA55D3BC0E9B79C7C4:FG=1; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BIDUPSID=5346B30DBA001AAA55D3BC0E9B79C7C4; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: PSTM=1586690938; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BAIDUID=5346B30DBA001AAA96E1874275870C1E:FG=1; max-age=31536000; expires=Mon, 12-Apr-21 11:28:58 GMT; domain=.baidu.com; path=/; version=1; comment=bd
Traceid: 1586690938069814759410205312453771961280
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1
百度一下，你就知道
[root@nailwl ~]# tcpdump命令
命令及参数解释
[root@obj02 ~]# tcpdump -n -i ens160 -c 10 -q arp or port 80
-n 不把主机的网络地址转换成名字。
-i<网络界面> 使用指定的网络截面送出数据包。
-c<数据包数目> 收到指定的数据包数目后，就停止进行倾倒操作。
-t 在每列倾倒资料上不显示时间戳记。
-q 快速输出，仅列出少数的传输协议信息。
-v 详细显示指令执行过程。
-vv 更详细显示指令执行过程。
【FAQ1】为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
【FAQ2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
【FAQ3】为什么不能用两次握手进行连接？
答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
【FAQ4】如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
参考文档：
https://blog.csdn.net/qq_38950316/article/details/81087809
https://www.cnblogs.com/qingergege/p/6603488.html