实战 | 服务端开发与计算机网络结合的完美案例

╰+攻爆jí腚メ 2023-10-16 09:42 42阅读 0赞

#### 前言 ####

大家好，我是Martin

后端，可以说是仅次于算法岗之外竞争最为激烈的岗位，而其中的服务端开发也是很多人会选择在秋招中投递的一个岗位，我想对于很多人来说，走上服务端开发之路的起点就是一个回声服务器了。

今天带大家实战一把，真实体验服务端底层数据交换的点点滴滴，在这过程中可以让你看见 TCP 三次握手四次挥手的具体过程，**全程干货，不开玩笑。**

![图片][01c8cb73893e1b906ac2ca1f6043b811.gif]

#### 环境工具 ####

客户端：Ubuntu 16.04 ，IP：192.168.78.128 ，简称为客户端A

服务端：Ubuntu 16.04 ，IP：192.168.78.130，简称为服务端B

抓包利器-大白鲨 Wireshark 以及 Linux 下的抓包命令 tcpdump

GCC：5.4.0

> 因为 Wireshark 的图标就很像一条大鲨鱼的鱼鳍，所以又叫大白鲨，不信你看看
> 
> ![图片][8349279b557f4fbd914a883d142f8e1b.png]
> 
> 大白鲨

#### 三次握手与四次挥手 ####

这里简单介绍下 TCP 最经典的三次握手与四次挥手

![图片][34675c9dbd2fddfef7676a8ef3a2d908.jpeg]

三次握手四次挥手

##### 三次握手 #####

1.  第一次握手：建立连接。客户端发送连接请求报文段，将 SYN 位置为1，seq(Sequence Number) 为 x；然后，客户端进入 SYN\_SEND 状态，等待服务端的确认；
2.  第二次握手：服务端收到 SYN 报文段。服务端收到客户端的 SYN 报文段，需要对这个SYN 报文段进行确认，设置 ack(Acknowledgment Number) 为 x+1 (也就是 seq+1)；同时，自己还要发送 SYN 请求信息，将 SYN 位置为1，seq 为 y；服务端将上述所有信息放到一个报文段（即 SYN+ACK 报文段）中，一并发送给客户端，此时服务端进入 SYN\_RECV 的状态；
3.  第三次握手：客户端收到服务端的 SYN+ACK 报文段。然后将ack设置为y+1，向服务端发送ACK报文段，这个报文段发送完毕以后，客户端和服务端端都进入 ESTABLISHED 状态，完成TCP三次握手。

##### 数据交互 #####

成功建立连接后，客户端与服务端就开始进行数据交互。客户端发送数据，服务端回复收到该数据，然后交替进行下去。

##### 四次挥手 #####

当客户端和服务端通过三次握手建立 TCP 连接进行可靠数据传输后，当数据传送完毕，肯定是要断开TCP连接，这里就有了神秘的“四次挥手”。

1.  第一次挥手：客户端设置 seq和ack，向服务端发送一个FIN报文段；此时，客户端进入 FIN\_WAIT\_1 状态；这表示客户端没有数据要发送给服务端了；
2.  第二次挥手：服务端收到了客户端发送的FIN报文段，向客户端回一个 ACK 报文段，ack 为 seq+1；客户端进入 FIN\_WAIT\_2 状态；服务端告诉客户端，我“同意”你的关闭请求；
3.  第三次挥手：服务端向客户端发送 FIN 报文段，请求关闭连接，同时服务端进入 LAST\_ACK 状态；
4.  第四次挥手：客户端收到服务端发送的 FIN 报文段，向服务端发送 ACK 报文段，然后客户端进入 TIME\_WAIT状态；服务端收到客户端的 ACK 报文段以后，就关闭连接；此时，客户端等待 2MSL 后依然没有收到回复，则证明服务端已正常关闭，那好，客户端也可以关闭连接了。

#### 思路整理 ####

这里主要使用的是尹圣雨\[韩\]的著作《TCP/IP网络编程》第 4 章中的简易版回声服务器来进行实验。

> 所谓回声服务端，就像小时候在回声山谷中玩的游戏一样，你朝山谷中大吼一声“啊”，然后山谷也会给你一个“啊”。回声服务端就是你向服务端发送一个“hello world”，回声服务端也向你回复一个“hello world”。

1、将客户端程序 echo\_client.c 放在客户端 A 中，将服务端程序 echo\_server.c 放在服务端 B 中

2、在客户端 A 中开启一个命令行窗口，使用 tcpdump 命令监控 A、B 之间的网络通信，并将消息保存为 pacp 文件，方便后续进行抓包分析

3、在服务端 B 中编译程序 echo\_server.c，开启服务端程序 echo\_server，监听指定端口 2333

> 这里的端口号可以自己指定，在 1025-65535 之间都可以，主要是因为0-1024已经被系统占用了，比如http的80端口，ssh的22端口。而 Linux 下默认端口数在65535个，所以自己可以指定的端口号就在1025-65535之间。

4、在客户端 A 中编译程序 echo\_client.c，并且开启客户端程序 echo\_client，指定通话 IP 以及端口号，我在这里就是服务端 B 的IP：192.168.78.130以及 2333 端口号了

5、在客户端 A 中发送消息“hello”，然后按 Q 退出即可

6、通信完毕，将 2 中保存的文件转存到 Windows 环境下，使用大白鲨 Wireshark 进行网络数据包分析。

7、分析抓到的数据包文件

#### 开干 ####

说了那么多，终于可以开始开干了！

1、将echo\_client.c 、echo\_server.c分别放在客户端A:192.168.78.128 以及服务端B:192.168.78.130 中。

![图片][b3de1e51f7a5b0488c9bfae099b464b2.png]

客户端A

![图片][af63a0b0853bf57ae6966e33ebbef8b5.png]

服务端B

2、 在客户端A中新开一个命令行窗口，输入命令：sudo tcpdump -i any tcp and host 192.168.78.130 and port 2333 -w message.pcap

> 1、由于tcpdump命令需要管理员权限，所以需要加上sudo命令进而获取管理员权限。
> 
> 2、这段命令的大概含义就是监控客户端 A:192.168.78.128，和服务端 B:192.168.78.130 之间在端口号2333 上的基于TCP的数据交换，并且保存为 message.pcap 文件

![图片][b1eb8c9f72a96eb2905f53853b01860e.png]

tcpd数据包保存命令

可以看到，我们在输入该条命令后，需要首先输入 Linux 下的密码获取管理员权限，然后就开始监听客户端 A：192.168.78.128，与服务端 B：192.168.78.130之间在端口号2333上的TCP通信了。

3、接下来，我们进入含有 echo\_server.c的文件夹，将服务端B的程序进行编译，编译命令为 gcc echo\_server.c -o echo\_server，可以看到当前文件夹下出现了 echo\_server 程序

![图片][81417c1a1a8d852d6d6d4f394a6a6412.png]

编译服务器程序

接下来，开始监听我们预先设置好的端口号 2333，命令为：./echo\_server 2333，服务端开始正式监听。

![图片][66c4d25d2a130a1a9b2fa71495787396.png]

运行服务器程序

4、服务端 B 设置完毕，我们开始转战客户端 A ，在 2 中使用 tcpdump 命令监听的那个端口号不要关闭，千万不要关闭，我们在客户端 A 中另外新开一个命令行。

跟服务端 B 中类似，首先将客户端 A 中的程序echo\_client.c进行编译，编译命令：gcc echo\_client.c -o echo\_client

![图片][999dacf529ce8ac275b0038a2e681adf.png]

编译客户端程序

跟服务端 B 中类似，我们在客户端 A 中开启客户端程序echo\_client，指定通话IP :192.168.78.130及端口号 2333

命令为./echo\_client 192.168.78.130 2333

![图片][fc394ea540f1b72637f8dbd87d42fe9f.png]

运行客户端程序

可以看到出现 “Connected…..”字样，说明我们已经走完长征两万五千公里，成功会师啦！

客户端 A 与服务端 B 终于成功连接了，这个时候我们再转去看一下服务端 B 的状态。

![图片][710351781dcf876ea2a06d9bfb2ccc66.png]

服务器程序状态

在服务端 B 的监听窗口也出现了“Connect client 1”字样，换句话说，在服务端看来，有一个客户端与它成功建立连接了。

5、下一步就可以开始通信了，我们在客户端 A 中发送“hello”字样。

![图片][a776aa5bfc5fb0b38c8feabbd0af3524.png]

在客户端A发送消息

可以看到，我们在客户端 A 中发送了一条消息“hello”, 服务端 B 也给了我们一个消息“hello”，这也就是我们上文中提到的回声服务端了。

接下来，我们按照提示，输入“Q”结束本次通话。

![图片][f46072f4a0384d6c8cc7d37205fa5c93.png]

退出客户端A

至此，本次通话结束。

6、最后我们在 2 中开启 tcpdump 命令监控的界面中，按下 ctrl+ c ，结束监听。

![图片][93b030f517eca33b1fd7f78148a76451.png]

保存抓包文件

可以看到，提示我们一共成功捕获了10 个packets，没有数据包丢失。接下来，我们将捕获文件 message.pacp传输到 Windows 下开始进行抓包分析。

![图片][934b3ec226d3b023d8509fba177059ef.jpeg]

#### 抓包分析 ####

可以看出一共 10 个数据包，也对应了上文中我们在 Linux 下通过tcpdump命令抓到的数据包个数。其中序号 1-3 为三次握手的数据包，序号 4-7 为两次数据交换的数据包，8-10 为三次挥手的数据包。

![图片][a3923fa2743d376ec7ee1a6a47a3d303.png]

抓到的10个数据包

> 问题1：4-7 为什么是两次数据交换呢？
> 
> 回答1：我们的回声服务端就是你发送什么数据过去，服务端发送什么数据回来，所以第一次数据交换：客户端A发送数据”hello“到服务端B，B回复 确认收到。这也对应着4、5数据包；第二次数据交换：服务端B发送数据”hello“到客户端A，A回复 确认收到。这也对应着6、7数据包。
> 
> 问题2：说好的四次挥手呢？这里怎么只有三次了？
> 
> 回答2： 因为服务端收到客户端的 FIN 后，服务端也可以同时关闭连接，这样就可以把 ACK 和 FIN 两个包合并到一起发送，这样可以节省一个网络包，“四次挥手”变成了“三次挥手”。这样可以节省网络资源，省时又省力。而通常情况下，服务端收到客户端的 FIN 后，很可能还没发送完数据，所以就会先回复客户端一个ACK 包，完成所有数据包的发送后，才会发送 FIN 包，也就是“四次挥手“了。

![图片][b7f0b70f12094b81170ba2b963ba649f.jpeg]

###### 三次握手过程 ######

![图片][a049af52a67647181f84c4d0301cfdb1.png]

三次挥手过程

第一次握手，序号为1，客户端A：192.168.78.128 向服务端B：192.168.78.130 发送SYN请求包，seq为1796975076。

第二次握手，序号为2，服务端 B：192.168.78.130 向客户端A：192.168.78.128 发送 SYN、ACK 请求回复包，seq为1222412335，ack为1796975077，也就是第一次握手中的 seq+1。

第三次握手，序号为3，客户端A：192.168.78.128 向服务端B：192.168.78.130 发送 ACK 确认包，seq为1796975077，ack为为1222412336，也就是第二次握手中的 seq+1。

###### 两次数据交互过程 ######

第一次数据交互：

![图片][ca7540c0cce25839c819da749e7bca2f.png]

第一次数据交互

序号为4，客户端A：192.168.78.128 向服务端B：192.168.78.130 发送 push 消息包，可以看到下方的数据解析为“hello”，并且数据长度 len = 6。

> 可能有些小伙伴问“hello不是一共5个字符吗？长度应该为5啊。”len = 6是因为“hello“长度为5，再加上结尾的‘\\0’，加起来一共就是6了

序号为5，服务端B：192.168.78.130 向客户端A：192.168.78.128 发送 ACK 确认包，表示已经收到该消息。

第二次数据交互：

![图片][bbc52d505b051b2914b3479cb235cbe8.png]

第二次数据交互

序号为6，服务端B：192.168.78.130 客户端A：192.168.78.128发送push消息包，可以看到下方的数据解析为“hello”，并且 len = 6。

序号为7，客户端A：192.168.78.128 向服务端B：192.168.78.130 发送ACK确认包，表示已经收到该消息。

###### 三次挥手过程 ######

正式的四次挥手如下图所示：

![图片][4d48645d6712cd462d8d97c1c2b88bd3.jpeg]

标准的四次挥手

我们所抓到的三次挥手如下所示：

![图片][f69fff9fe1a365de8a38c930bda037bb.png]

我们抓包抓到的三次挥手

第一次挥手，序号为8：客户端A：192.168.78.128 向服务端B：192.168.78.130 发送 FIN 请求断开连接包，表示主动请求断开链接。

第二三次挥手，序号为9：服务端B：192.168.78.130 向 客户端A：192.168.78.128发送 FIN、ACK 确认并请求断开消息包，表示收到上次断开连接的请求，并请求断开服务端到客户端的链接。

可以看出，我们所抓的包中，将第二次挥手和第三次挥手合并为一个数据包了，也就是192.168.78.130->192.168.78.128的包中既有FIN也有ACK，所以这也是三次挥手而不是四次挥手的原因。

第四次挥手，序号为 10：客户端A：192.168.78.128 向服务端B：192.168.78.130 发送 ACK 确认包，表示收到服务端发送过来的请求断开连接消息，并给予回复。

#### 结语 ####

学会将自己所学的知识串联起来是你**迈向大佬的必经之路**

![图片][30747085d5035c81db99cf40b14df241.png]

。

## 授人以鱼不如授人以渔，本次实战的全部文件已经打包分享出来了，加我的QQ群在群文件查找就可以获取，你也可以自己动手实践一下。毕竟“**纸上得来终觉浅，绝知此事要躬行**“。   QQ群：876392689 ##

如果大家觉得这种实战类型的文章还可以的话，还请**留言**告诉我，以后我多为大家带来这种实战类型的文章。

![图片][ad1e9cfe34797a491d5c7fcdd888d3a3.jpeg]

巨人的肩膀

> https://my.oschina.net/u/658658/blog/417739
> 
> 《TCP/IP网络编程》- 尹圣雨\[韩\]
> 
> 《Wireshark网络分析就这么简单》- 林沛满
> 
> 《Wireshark网络分析的艺术》- 林沛满
> 
> 《计算机网络-自顶向下方法》- ames F. Kurose、Keith W. Ross
> 
> 《TCP/IP详解 卷1：协议》- kevin R.Fall W.Richard Stevens

— END —

[01c8cb73893e1b906ac2ca1f6043b811.gif]: https://img-blog.csdnimg.cn/img_convert/01c8cb73893e1b906ac2ca1f6043b811.gif
[8349279b557f4fbd914a883d142f8e1b.png]: https://img-blog.csdnimg.cn/img_convert/8349279b557f4fbd914a883d142f8e1b.png
[34675c9dbd2fddfef7676a8ef3a2d908.jpeg]: https://img-blog.csdnimg.cn/img_convert/34675c9dbd2fddfef7676a8ef3a2d908.jpeg
[b3de1e51f7a5b0488c9bfae099b464b2.png]: https://img-blog.csdnimg.cn/img_convert/b3de1e51f7a5b0488c9bfae099b464b2.png
[af63a0b0853bf57ae6966e33ebbef8b5.png]: https://img-blog.csdnimg.cn/img_convert/af63a0b0853bf57ae6966e33ebbef8b5.png
[b1eb8c9f72a96eb2905f53853b01860e.png]: https://img-blog.csdnimg.cn/img_convert/b1eb8c9f72a96eb2905f53853b01860e.png
[81417c1a1a8d852d6d6d4f394a6a6412.png]: https://img-blog.csdnimg.cn/img_convert/81417c1a1a8d852d6d6d4f394a6a6412.png
[66c4d25d2a130a1a9b2fa71495787396.png]: https://img-blog.csdnimg.cn/img_convert/66c4d25d2a130a1a9b2fa71495787396.png
[999dacf529ce8ac275b0038a2e681adf.png]: https://img-blog.csdnimg.cn/img_convert/999dacf529ce8ac275b0038a2e681adf.png
[fc394ea540f1b72637f8dbd87d42fe9f.png]: https://img-blog.csdnimg.cn/img_convert/fc394ea540f1b72637f8dbd87d42fe9f.png
[710351781dcf876ea2a06d9bfb2ccc66.png]: https://img-blog.csdnimg.cn/img_convert/710351781dcf876ea2a06d9bfb2ccc66.png
[a776aa5bfc5fb0b38c8feabbd0af3524.png]: https://img-blog.csdnimg.cn/img_convert/a776aa5bfc5fb0b38c8feabbd0af3524.png
[f46072f4a0384d6c8cc7d37205fa5c93.png]: https://img-blog.csdnimg.cn/img_convert/f46072f4a0384d6c8cc7d37205fa5c93.png
[93b030f517eca33b1fd7f78148a76451.png]: https://img-blog.csdnimg.cn/img_convert/93b030f517eca33b1fd7f78148a76451.png
[934b3ec226d3b023d8509fba177059ef.jpeg]: https://img-blog.csdnimg.cn/img_convert/934b3ec226d3b023d8509fba177059ef.jpeg
[a3923fa2743d376ec7ee1a6a47a3d303.png]: https://img-blog.csdnimg.cn/img_convert/a3923fa2743d376ec7ee1a6a47a3d303.png
[b7f0b70f12094b81170ba2b963ba649f.jpeg]: https://img-blog.csdnimg.cn/img_convert/b7f0b70f12094b81170ba2b963ba649f.jpeg
[a049af52a67647181f84c4d0301cfdb1.png]: https://img-blog.csdnimg.cn/img_convert/a049af52a67647181f84c4d0301cfdb1.png
[ca7540c0cce25839c819da749e7bca2f.png]: https://img-blog.csdnimg.cn/img_convert/ca7540c0cce25839c819da749e7bca2f.png
[bbc52d505b051b2914b3479cb235cbe8.png]: https://img-blog.csdnimg.cn/img_convert/bbc52d505b051b2914b3479cb235cbe8.png
[4d48645d6712cd462d8d97c1c2b88bd3.jpeg]: https://img-blog.csdnimg.cn/img_convert/4d48645d6712cd462d8d97c1c2b88bd3.jpeg
[f69fff9fe1a365de8a38c930bda037bb.png]: https://img-blog.csdnimg.cn/img_convert/f69fff9fe1a365de8a38c930bda037bb.png
[30747085d5035c81db99cf40b14df241.png]: https://img-blog.csdnimg.cn/img_convert/30747085d5035c81db99cf40b14df241.png
[ad1e9cfe34797a491d5c7fcdd888d3a3.jpeg]: https://img-blog.csdnimg.cn/img_convert/ad1e9cfe34797a491d5c7fcdd888d3a3.jpeg