TCP的3次握手+4次挥手

TCP的3次握手

ACK :确认接受为1，等待连接为0
SYN：请求建立连接
seq：序列号，当发送一个数据时，数据是被拆成多个数据包来发送，序列号就是对每个数据包进行编号，这样接受方才能对数据包进行再次拼接。
ack：这个代表下一个数据包的编号，下一次请求时，ack是seq+1
FIN：请求断开连接
ACK与ack不一样

1客户端首先要SYN=1,表示要创建连接，
2.服务端接收到后，要告诉客户端：我接受到了！所以加个ACK=1，就变成了ACK=1,SYN=1
3.理论上这时就创建连接成功了，但是要防止一个意外，所以客户端要再发一个消息给服务端确认一下，这时只需要ACK=1就行了。
这个意外就是：客户端的连接可能因为网络的原因会产生延迟，若A,B都是请求建立连接，当A因为网络问题延迟后，B发送了过来，然后建立完成了连接。此时A也到达了，如果没有第3次的连接，A也会进行连接，耗费了资源。

TCP的4次挥手

1.首先客户端请求关闭客户端到服务端方向的连接，这时客户端就要发送一个FIN=1，表示要关闭一个方向的连接
2.服务端接收到后是需要确认一下的，所以返回了一个ACK=1
3.这时只关闭了一个方向，另一个方向也需要关闭，所以服务端也向客户端发了一个FIN=1 ACK=1
4.客户端接收到后发送ACK=1，表示接受成功
MSL原因：
 为何主机A在发送了最后的确认后没有进入CLOSED状态，反而进入了一个2MSL的TIME-WAIT。主要作用有两个：第一，确保主机A最后发送的确认能够到达主机B。如果处于LAST-ACK状态的主机B一直收不到来自主机A的确认，它会重传断开连接请求，然后主机A就可以有足够的时间去再次发送确认。但是这也只能尽最大力量来确保能够正常断开，如果主机A的确认总是在网络中滞留失效，从而超过了2MSL，最后也无法正常断开；第二，如果主机A在发送了确认之后立即进入CLOSED状态。假设之后主机A再次向主机B发送一条连接请求，而这条连接请求比之前的确认报文更早地到达主机B，则会使得主机B以为这条连接请求是在旧的连接中A发出的报文，并不看成是一条新的连接请求了，即使得这个连接请求失效了，增加2MSL的时间可以使得这个失效的连接请求报文作废，这样才不影响下次新的连接请求中出现失效的连接请求。

使用tcpdump对TCP的连接进行抓包查看

tcpdump常用参数：
-c         指定包个数
-n        IP，端口用数字方式显示
port   指定端口 
-I 指定的网卡设备
-S 查看绝对序号

思路：我们准备去抓包ssh远程连接产生的数据包，端口为22。我们使用2个机器.
尽量不要在xshell下进行连接，只需要在VMware中进行实验就行，因为xshell会产生许多消息，我们测试的思路是：在服务器端，想要远程连接客户端，然后在另一个窗口进行抓包。
服务端：192.168.1.63
客户端：192.168.1.64

客户端操作：保证开机就行，并且打开sshd服务

服务器端操作：
1在一个终端下进行抓包
tcpdump -n -c 6 port 22 -i ens33
2在另一个终端下进行远程连接,观察另一个终端的显示，可以看到包的信息
ssh root@192.168.1.64

1步结束

2步显示

包的信息：注意看3个加粗的信息，这个就是对应的ack和seq信息
[root@aaa du]# tcpdump -n -c 6 -S port 22 -i ens33
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
17:23:09.889821 IP 192.168.1.63.53198 > 192.168.1.64.ssh: Flags [S], seq 481914174, win 29200, options [mss 1460,sackOK,TS val 547753 ecr 0,nop,wscale 7], length 0
17:23:09.890237 IP 192.168.1.64.ssh > 192.168.1.63.53198: Flags [S.], seq 2737267460, ack 481914175, win 28960, options [mss 1460,sackOK,TS val 550574 ecr 547753,nop,wscale 7], length 0
17:23:09.890311 IP 192.168.1.63.53198 > 192.168.1.64.ssh: Flags [.], ack 2737267461, win 229, options [nop,nop,TS val 547755 ecr 550574], length 0
17:23:09.890647 IP 192.168.1.63.53198 > 192.168.1.64.ssh: Flags [P.], seq 481914175:481914196, ack 2737267461, win 229, options [nop,nop,TS val 547755 ecr 550574], length 21
17:23:09.890866 IP 192.168.1.64.ssh > 192.168.1.63.53198: Flags [.], ack 481914196, win 227, options [nop,nop,TS val 550575 ecr 547755], length 0
17:23:09.898857 IP 192.168.1.64.ssh > 192.168.1.63.53198: Flags [P.], seq 2737267461:2737267482, ack 481914196, win 227, options [nop,nop,TS val 550580 ecr 547755], length 21
6 packets captured
7 packets received by filter
0 packets dropped by kernel

使用tcpdump对TCP的断开进行抓包查看（如上）——只是将ssh连接上，然后断开，在断开的时候进行抓包查看。分析数据包

包的信息：注意看3个加粗的信息，这个就是对应的ack和seq信息
t@aaa du]# tcpdump -n -c 6 -S port 22 -i ens33
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
17:24:58.687067 IP 192.168.1.63.53198 > 192.168.1.64.ssh: Flags [P.], seq 481916768:481916836, ack 2737270434, win 311, options [nop,nop,TS val 656552 ecr 653660], length 68
17:24:58.687597 IP 192.168.1.64.ssh > 192.168.1.63.53198: Flags [P.], seq 2737270434:2737270494, ack 481916836, win 295, options [nop,nop,TS val 659373 ecr 656552], length 60
17:24:58.687629 IP 192.168.1.63.53198 > 192.168.1.64.ssh: Flags [.], ack 2737270494, win 311, options [nop,nop,TS val 656552 ecr 659373], length 0
17:24:58.688333 IP 192.168.1.63.53198 > 192.168.1.64.ssh: Flags [P.], seq 481916836:481916904, ack 2737270494, win 311, options [nop,nop,TS val 656553 ecr 659373], length 68
17:24:58.688861 IP 192.168.1.64.ssh > 192.168.1.63.53198: Flags [P.], seq 2737270494:2737270554, ack 481916904, win 295, options [nop,nop,TS val 659374 ecr 656553], length 60
17:24:58.728987 IP 192.168.1.63.53198 > 192.168.1.64.ssh: Flags [.], ack 2737270554, win 311, options [nop,nop,TS val 656594 ecr 659374], length 0
6 packets captured
6 packets received by filter
0 packets dropped by kernel