TCP的特点：三次握手、四次挥手、可靠连接、丢包重传。所有的关键词都围绕着可靠传输。
实现可靠传输的核心机制：seq+ack。通过ack判断是否有丢包，是否需要重传。
三次握手
1）初始状态：client为CLOSED，server为LISTEN，此时client 发送 syn 到server ，client状态变为SYN_SENT；
2）server 收到 syn后回复syn+ack给client，client状态变为SYN_RCVD；
3）client 收到syn+ack后，回复ack向server表示收到了server的syn+ack（此时client连接状态已经是established），当Server收到ack后，状态变成established。
为什么要握手？
1）最重要的目的：告诉对方自己的seq，对方回复ack（收到的seq+包的大小），用于判断是否有丢包；
2）其他目的：协商信息，例如：MSS–最大传输包、SACK_PERM–是否支持Selective ack(用户优化重传效率）等。
四次挥手
1）client发送fin包给server，client连接状态变为FIN-WAIT-1；
2）server收到fin包后回复ack给client，表示server知道client要断开了，server连接状态变为CLOSE-WAIT；client收到ack后连接状态变为FIN-WAIT-2；
3）server发送fin包给client，表示server也可以断开了，server连接状态变为LAST-ACK；
4）client收到fin包后回复ack给server，此时client端连接状态先变为TIME-WAIT，等待一段时间后变为CLOSED状态；server收到ack后状态变为CLOSED。
为什么三次握手、四次挥手？
之所以绝大数时候我们看到的都是四次挥手，是因为收到fin后，知道对方要关闭了，然后OS通知应用层要关闭啥的，这里应用层可能需要做些准备工作，有一些延时，所以先回ack，准备好了再发fin 。 握手过程没有这个准备过程所以可以立即发送syn+ack。
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答用，而SYN起同步作用）在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可关闭,这里的ACK报文和FIN报文多数情况下都是分开发送的.
为什么是三次握手，而不是两次？
因为tcp是可靠传输协议，靠seq+ack实现，因此建立一个可靠的单向通道至少需要一次seq+ack；又因为tcp是双向通信协议，所以服务端也需要进行一次seq+ack；为了优化通信效率，服务端发送ack和seq消息合并，所以需要3次握手。
为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比STABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
怎么确定是否丢包？
ack总是等于seq+len，len为包的大小，（SYN、FIN、ACK包除外，len为0），发送方通过ack知晓接收方是否收到消息。ack表示这个数字前面的数据都收到了。
MSS
MTU（maximum transmission unit，最大传输单元），由硬件规定，如以太网的MTU为1500字节。
MSS（maximum segment size，最大分段大小），为TCP数据包每次传输的最大数据分段大小，一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header（20 Byte）和TCP header（20 Byte）得到。
SACK_PERM
SACK_PERM 用于丢包的话提升重传效率，比如client一次发了1、2、3、4、5 这5个包给server，实际server收到了 1、3、4、5这四个包，中间2丢掉了。这个时候server回复ack的时候，都只能回复2，表示2前面所有的包都收到了，给我发第二个包吧，如果server 收到3、4、5还是没有收到2的话，也是回复ack 2而不是回复ack 3、4、5、6的，表示快点发2过来。
但是这个时候client虽然知道2丢了，然后会重发2，但是不知道3、4、5有没有丢啊，实际3、4、5 server都收到了，如果支持sack，那么可以ack 2的时候同时告诉client 3、4、5都收到了，这样client重传的时候只重传2就可以，如果没有sack的话那么可能会重传2、3、4、5，这样效率就低了。
抓包实例验证
flags 标志由S(SYN), F(FIN), P(PUSH), R(RST),
在10.18.222.22上抓包
tcpdump -i eth0 -nn -S -vv host 10.18.222.22 and 10.18.101.91 and port 9188 and tcp
==1==客户端10.18.101.91向服务端10.18.222.22发送一个SYN消息，seq为3105852613。
08:02:13.454857 IP (tos 0x0, ttl 126, id 14184, offset 0, flags [DF], proto TCP (6), length 52)
10.18.101.91.63376 > 10.18.222.22.9188: Flags [S], cksum 0x9640 (correct), seq 3105852613, win 8192, options [mss 1428,nop,wscale 8,nop,nop,sackOK], length 0
==2==服务端向客户端发送确认消息，其中ack为上一行seq+1，ack 3105852614；同时向客户端发送SYN消息，seq 536849585。
08:02:13.454955 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
10.18.222.22.9188 > 10.18.101.91.63376: Flags [S.], cksum 0x57bc (incorrect -> 0xb057), seq 536849585, ack 3105852614, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
==3==客户端向服务端发送确认消息，ack为上一行seq+1，ack 536849586。到此三次握手结束，连接建立。
08:02:13.455633 IP (tos 0x0, ttl 126, id 14185, offset 0, flags [DF], proto TCP (6), length 40)
10.18.101.91.63376 > 10.18.222.22.9188: Flags [.], cksum 0x2932 (correct), seq 3105852614, ack 536849586, win 256, length 0
==4==客户端向服务端发送数据，长度为161字节，请求序号seq 3105852614:3105852735
08:02:13.488717 IP (tos 0x0, ttl 126, id 14191, offset 0, flags [DF], proto TCP (6), length 161)
10.18.101.91.63376 > 10.18.222.22.9188: Flags [P.], cksum 0x836f (correct), seq 3105852614:3105852735, ack 536849586, win 256, length 121
==5==服务端收到数据后向客户端发送确认ack 3105852735
08:02:13.488816 IP (tos 0x0, ttl 64, id 44515, offset 0, flags [DF], proto TCP (6), length 40)
10.18.222.22.9188 > 10.18.101.91.63376: Flags [.], cksum 0x57b0 (incorrect -> 0x2946), seq 536849586, ack 3105852735, win 115, length 0
==6==服务端向客户端发送数据
08:02:19.534769 IP (tos 0x0, ttl 64, id 44516, offset 0, flags [DF], proto TCP (6), length 130)
10.18.222.22.9188 > 10.18.101.91.63376: Flags [P.], cksum 0x580a (incorrect -> 0xd5db), seq 536849586:536849676, ack 3105852735, win 115, length 90
==7==客户端向服务端发FIN消息
08:02:19.660406 IP (tos 0x0, ttl 126, id 14360, offset 0, flags [DF], proto TCP (6), length 40)
10.18.101.91.63376 > 10.18.222.22.9188: Flags [F.], cksum 0x285e (correct), seq 3105852735, ack 536849676, win 256, length 0
==8==服务端向客户端发送确认，同时发送FIN消息
08:02:19.661757 IP (tos 0x0, ttl 64, id 44517, offset 0, flags [DF], proto TCP (6), length 40)
10.18.222.22.9188 > 10.18.101.91.63376: Flags [F.], cksum 0x57b0 (incorrect -> 0x28ea), seq 536849676, ack 3105852736, win 115, length 0
==9==客户端向服务端发送确认。
08:02:19.662960 IP (tos 0x0, ttl 126, id 14362, offset 0, flags [DF], proto TCP (6), length 40)
10.18.101.91.63376 > 10.18.222.22.9188: Flags [.], cksum 0x285d (correct), seq 3105852736, ack 536849677, win 256, length 0
1、2、3是TCP三次握手的过程
7、8、9是TCP四次挥手的过程
疑问：为什么TCP四次挥手只抓到3个包？
TCP总是尽可能的捎带需要回复给对方的数据
tcp连接状态转换图
附录：抓包工具----tcpdump
安装：yum install -y tcpdump
查看帮助：tcpdump --help
-i 指定监听的网络接口（网卡）。
-w 直接将分组写入文件中。
-vv 输出详细的报文信息。
-X，可以列出十六进制 (hex) 以及 ASCII 的数据包内容，对于监听数据包内容很有用。
-A，数据包的内容以 ASCII 显示，通常用来捉取 WWW 的网页数据包资料。
-nn 不进行端口名称的转换。
-D 打印出系统中所有可以用tcpdump截包的网络接口。
常用命令
1)我截取本机（192.168.31.147）和主机114.114.114.114之间的数据
tcpdump -n -i eth0 host 192.168.31.147 and 114.114.114.114
2)截取全部进入服务器的数据
tcpdump -n -i eth0 dst 192.168.31.147
服务器有多个IP 可以使用参数
tcpdump -n -i eth0 dst 192.168.31.147 or 192.168.31.157
3)抓取全部进入服务器的TCP数据包
tcpdump -n -i eth0 dst 192.168.31.147 and tcp
4)从本机出去的数据包
tcpdump -n -i eth0 src 192.168.31.147 or 192.168.31.157
5)从本机出去的数据包且端口不为22的tcp数据包
tcpdump -n -i eth0 src 192.168.31.147 or 192.168.31.157 and port ! 22 and tcp
参考资料：
原文地址：https://www.cnblogs.com/zaizhoumo/p/8888056.html