04-TCP/IP三次握手四次挥手

这个东西学了很久，学了忘，忘了学，今天特意学了下，个人感觉简单易记。

用打电话来形容三次握手，四次挥手。

我给张三打电话。

三次握手

我：喂，张三能听到吗？
张三：可以我听得到，你听得到吗？
我：我听得到

四次挥手

我：张三，我要挂了
张三：收到
张三：我也要挂了
我：收到

你可能会奇怪，挂电话为什么是四次，难道不能也是三次吗？就像下面这样

我：张三，我要挂了
张三：好了，那我也挂了
我：好嘞

答案是，不行，后面会有解释。

浏览器访问百度的流程

浏览器像操作系统请求访问百度，假设链接是，10.89.21.125: 80，而我这边浏览器对应的ip端口号则是18.147.35.69:33673。一般的，服务器的端口号都是固定的，而客户端的端口号则是随机的。

于是，操作系统操作网卡对百度服务器发起请求，经过三次握手以后，双方都觉得连接可靠，于是客户端和浏览器的操作系统各自创建了一个发送队列和接收队列，浏览器这边的发送队列发送的数据最终会放入服务器的接收队列中，而服务器那边的发送队列的数据最终会放入浏览器这边的接收队列。于是浏览器只需要往自己这边的内存中放数据和取数据，服务器那边同样如此。

也就是说我们说应用之间的通信倒不如说是网卡之间的通信，两边的应用只是在自己这边的内存中取数据。

建立连接如下图：

断开连接如下图：

完整的交互如下图：

为何是四次挥手？

请看上面的那幅图，经过一段时间的交互，客户端觉得该结束了，于是主动给服务器发送请求断开连接，等于告诉浏览器，我这里已经没有数据要发送了。浏览器收到以后发送一个确认已收到。这就是两次挥手了。

服务器这边数据也发送完毕了，而客户端也说了，断开连接，那就断开呗，于是服务器也给客户端发送一个断开连接，客户端感觉数据接收完了，于是给服务器发送一个收到。会话就这么结束了。

实盘验证

tcpdump -nn -i ens33 port 80这条命令可以抓取网卡ens33与服务器80端口号的交互记录

curl www.baidu.com:80这条命令可以模拟浏览器访问百度

先在一个窗口执行tcpdump -nn -i ens33 port 80监听网卡活动，在另一个窗口执行命令curl www.baidu.com:80请求百度服务器。

[root@master ~]# tcpdump -nn -i ens33 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
# 第一次客户端请求与服务器建立连接
18:00:52.886905 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [S], seq 2236384967, win 29200, options [mss 1460,sackOK,TS val 3615 ecr 0,nop,wscale 7], length 0
# 第二次，服务器表示收到了请求，返回了一个确认，小数点表示ack确认请求
18:00:53.221343 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [S.], seq 2516193507, ack 2236384968, win 8192, options [mss 1400,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0
# 第三次握手，客户端给浏览器发送一个确认收到服务器已经做好连接准备的消息。
18:00:53.221386 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [.], ack 1, win 229, length 0

# 这里是客户端真正的请求，表示我需要什么资源，这里的 length!=0
18:00:53.221575 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [P.], seq 1:78, ack 1, win 229, length 77: HTTP: GET / HTTP/1.1
# 服务器返回我知道了，只是单纯的确认返回，length都是0
18:00:53.556998 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [.], ack 78, win 776, length 0
# 浏览器返回数据
18:00:53.570395 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [P.], seq 1:2782, ack 78, win 776, length 2781: HTTP: HTTP/1.1 200 OK
# 客户端返回确认数据接收到了
18:00:53.570425 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [.], ack 2782, win 272, length 0

# 这中间许多的互相确认是因为网络问题，不算真正的断开连接
18:00:53.570797 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [F.], seq 78, ack 2782, win 272, length 0
18:00:53.771156 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [.], seq 1:1301, ack 78, win 776, length 1300: HTTP: HTTP/1.1 200 OK
18:00:53.771226 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [.], ack 2782, win 272, options [nop,nop,sack 1 {1:1301}], length 0
18:00:54.173484 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [.], seq 1:1301, ack 78, win 776, length 1300: HTTP: HTTP/1.1 200 OK
18:00:54.173530 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [.], ack 2782, win 272, options [nop,nop,sack 1 {1:1301}], length 0

# 客户端连续三次发送请求断开连接，服务器才收到
18:00:54.273901 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [F.], seq 78, ack 2782, win 272, length 0
18:00:55.280058 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [F.], seq 78, ack 2782, win 272, length 0
18:00:57.296353 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [F.], seq 78, ack 2782, win 272, length 0

# 服务器表示收到客户端想断开连接
18:00:57.629521 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [.], ack 79, win 776, length 0
# 服务器也想断开连接
18:00:57.629565 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [F.], seq 2782, ack 79, win 776, length 0
18:00:57.629583 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [.], ack 2783, win 272, length 0
# 这中间可能是网络问题，两边互相确认了好几遍
18:00:58.434519 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [F.], seq 2782, ack 79, win 776, length 0
18:00:58.434552 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [.], ack 2783, win 272, length 0
18:01:00.045603 IP 103.235.46.39.80 > 192.168.1.120.40344: Flags [F.], seq 2782, ack 79, win 776, length 0
18:01:00.045640 IP 192.168.1.120.40344 > 103.235.46.39.80: Flags [.], ack 2783, win 272, length 0