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

简介: 笔记

前言


大家好,我是阿秀

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

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


环境工具


客户端: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 的图标就很像一条大鲨鱼的鱼鳍,所以又叫大白鲨,不信你看看

大白鲨


三次握手与四次挥手


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

三次握手四次挥手

三次握手
  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 中。

                                                      客户端A

                                                        服务端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 文件

                                               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 程序

                                                         编译服务器程序

接下来,开始监听我们预先设置好的端口号 2333,命令为:./echo_server 2333,服务端开始正式监听。

                                          运行服务器程序

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

跟服务端 B 中类似,首先将客户端 A 中的程序echo_client.c进行编译,编译命令:gcc echo_client.c -o echo_client

                                                  编译客户端程序

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

命令为./echo_client 192.168.78.130 2333

                                                              运行客户端程序

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

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

                                                      服务器程序状态

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

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

                                                        在客户端A发送消息

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

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

                                                         退出客户端A

至此,本次通话结束。

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

                                                           保存抓包文件

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

 


抓包分析


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

                                         抓到的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 包,也就是“四次挥手“了。

三次握手过程

三次挥手过程

第一次握手,序号为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。

两次数据交互过程

第一次数据交互:

序号为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 确认包,表示已经收到该消息。

第二次数据交互:

序号为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确认包,表示已经收到该消息。

三次挥手过程

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

标准的四次挥手

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

第一次挥手,序号为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 确认包,表示收到服务端发送过来的请求断开连接消息,并给予回复。


结语


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

授人以鱼不如授人以渔,本次实战的全部文件已经打包分享出来了,公众号后台回复【回声服务器】就可以获取,你也可以自己动手实践一下。毕竟“纸上得来终觉浅,绝知此事要躬行“。

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

对了欢迎抽奖,后台直接回复【抽奖】即可,公众号抽奖的人数不多,中奖概率还是挺大的,溜了溜了。

巨人的肩膀

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


往期推荐


双非渣硕的秋招之路总结(已拿抖音研发岗SP)

一份百投百中的计算机校招简历是如何迭代足足26版的?

个人C++学习路线大公开

— END —

Hi,小伙伴你好,我是阿秀,一枚从底层慢慢爬到互联网大厂的程序员,每一篇原创文章都是我精心创作、慢慢打磨出来的,如果你觉得本文对你有所帮助,麻烦点亮一下「」和「在看」,也可以「分享」给需要的小伙伴,阿秀真的很需要你的点亮,十分感谢!

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
9天前
|
监控 安全 物联网
网络安全与信息安全:防护之道与实战策略
【4月更文挑战第23天】在数字化时代,数据成为了新的货币,而网络安全则是保护这些“货币”的金库。本文将深入探讨网络安全漏洞的概念、加密技术的进展以及提升个人和企业的安全意识的重要性。通过分析当前的威胁景观,我们分享了一系列的防御措施和最佳实践,目的是为读者提供一套全面的信息安全防护框架。
|
1天前
|
安全 算法 网络安全
网络安全与信息安全:防护之道与实战策略
【5月更文挑战第1天】在数字化时代,网络安全和信息安全已成为个人和企业不可或缺的一环。本文将深入探讨网络安全漏洞的概念、加密技术的重要性以及提升安全意识的必要性。通过对常见网络威胁的分析,我们将了解如何识别潜在风险并采取有效措施以保护数据不受侵害。文章还将介绍最新的加密方法和安全实践,旨在为读者提供一套全面的网络安全自保策略。
|
1天前
|
安全 网络安全
网络安全攻防实战演练:技术探索与实践
【5月更文挑战第1天】网络安全攻防实战演练,通过模拟攻击与防御,提升组织应对网络安全威胁的能力。演练包括准备、攻击、防御和总结四个阶段,涉及环境搭建、攻击技术应用、防御措施执行及后期评估。此类演练有助于检验安全防护能力,提升应急响应速度,暴露系统隐患,加强团队协作,是保障网络安全的关键实践。
|
2天前
|
机器学习/深度学习 安全 网络安全
数字堡垒的构筑者:网络安全与信息安全的深层剖析构建高效微服务架构:后端开发的新趋势
【4月更文挑战第30天】在信息技术高速发展的今天,构建坚不可摧的数字堡垒已成为个人、企业乃至国家安全的重要组成部分。本文深入探讨网络安全漏洞的本质、加密技术的进展以及提升安全意识的必要性,旨在为读者提供全面的网络安全与信息安全知识框架。通过对网络攻防技术的解析和案例研究,我们揭示了防御策略的关键点,并强调了持续教育在塑造安全文化中的作用。
|
2天前
|
存储 XML 前端开发
【Flutter前端技术开发专栏】Flutter中的网络请求与数据处理
【4月更文挑战第30天】本文介绍了Flutter开发中的网络请求和数据处理。 Flutter开发者可选择http(官方库)或dio(功能更强大)进行网络请求。http库简单易用,dio支持更多功能如拦截器。数据处理涉及JSON和XML解析,数据存储可选SharedPreferences或Hive,数据传递推荐使用InheritedWidget或Provider状态管理库。了解这些知识点能提升Flutter开发效率。
【Flutter前端技术开发专栏】Flutter中的网络请求与数据处理
|
2天前
|
JSON 数据处理 Swift
【Swift 开发专栏】Swift 中的网络编程:URLSession 与 Alamofire
【4月更文挑战第30天】本文探讨了Swift中的网络编程,重点关注URLSession和Alamofire。URLSession是苹果提供的网络请求框架,允许底层控制和定制,适合需要高度灵活性的场景。Alamofire则是在URLSession基础上的第三方库,提供简洁接口和功能扩展,简化网络请求和错误处理。文中还介绍了两者在实际应用中的选择和使用场景,强调掌握网络编程基础的重要性。
|
3天前
|
存储 SQL 安全
网络安全与信息安全:防护之道与实战策略
【4月更文挑战第29天】 在数字化时代,数据成为了新的货币,而网络安全则是保护这些宝贵资产的保险箱。面对日益猖獗的网络攻击和安全威胁,仅有基础防御已远远不够。本文将深入探讨网络安全漏洞的形成机制与检测方法,加密技术的进展与应用,以及提升个人与企业的安全意识的有效途径。通过对当前网络环境的分析及最新技术的介绍,旨在为读者提供一系列切实可行的安全策略,以增强信息资产的防护力。
|
3天前
|
SQL 安全 物联网
网络安全与信息安全:防护之道与实战策略
【4月更文挑战第29天】在数字化时代,网络安全与信息安全已成为维护个人隐私、企业数据和国家安全的关键。本文深入探讨了网络安全漏洞的成因、加密技术的最新发展以及提升安全意识的重要性,旨在为读者提供一个全面的安全防护知识框架。通过对常见网络攻击手段的分析,我们展示了如何运用现代加密技术和多层防御策略来防范潜在威胁。同时,文章还强调了培养良好的安全习惯和持续教育的必要性,以构建更为坚固的网络安全防线。
|
3天前
|
安全 网络安全 数据安全/隐私保护
网络安全与信息安全:防护之道与实战策略
【4月更文挑战第29天】 在数字化时代,数据成为了新的货币,而网络空间则转变为了战场。本文章深入剖析了网络安全的核心问题——漏洞挖掘、防御机制以及加密技术,并结合当前的安全态势提出了一系列提升个人和企业安全意识的策略。通过分析最新的攻防案例,本文旨在为读者提供一个关于如何有效识别、防御和应对网络威胁的全景式指南。
|
4天前
|
机器学习/深度学习 算法 TensorFlow
TensorFlow 2keras开发深度学习模型实例:多层感知器(MLP),卷积神经网络(CNN)和递归神经网络(RNN)
TensorFlow 2keras开发深度学习模型实例:多层感知器(MLP),卷积神经网络(CNN)和递归神经网络(RNN)