C1任务02 网络初窥之双任务的实现与分析
目录
一、工具准备
抓包工具charles,自行提取
链接:https://pan.baidu.com/s/18N9y2xIRH3twQm2kA5KCNw
提取码:qfv8
网络模拟器网址:https://studio.code.org/s/netsim
二、任务1-网络抓包并添加额外的字段
1、首先访问任务提供的网址:http://temp.blog8090.com/,提交手机号、姓名,在浏览器返回的信息中,得到下一步任务的【暗号】
👇下为浏览器返回的信息中
2、其次,通过抓包工具(这里我选用的是适合于新手的抓包工具charles)查看浏览器提交给服务器的字段和数据
我们找到自己的账户信息和暗号(如图所示,暗号为:今晚打老虎)
3、然后通过抓包工具新添加一个额外的字段,按照第一步的提示,输入暗号之后,连同之前的内容重新提交给服务器
添加新字段并输入暗号后,提交给服务器👇
可以看到返回了"Wow,nice!"即表示成功完成了任务!
三、任务2-在code.org上完成互联网模拟器的系列任务
2-1 点对点-在共享的线路上发送比特位
我在自己的账户上面,输入AB,每次发送只能发送(Set Wire to B)1比特位,同样接收方每次(Read Wire)也只能接收1比特位。
2-2 点对点-发送数字
此次我输入八比特的数字(01)为1100 0011,那么接收方便在Received Message log中接收到我发送给对方的八比特数字,以信息的形式展示。并且如果 你在自己的账号上实现此过程,你可以清楚地看到在发送方,这八比特数字仍然是一比特一比特的发送的,而接收方是以信息块的形式一下完全接收。
2-3 点对点-发送Ascii码
到这一步,首先我们便要了解什么是Ascll码了。
百度百科上是这样解释的:美国信息交换标准代码)是基于拉丁字母的一套电脑编码系统,主要用于显示现代英语和其他西欧语言。它是最通用的信息交换标准。
起初我在Ascll码该框内输入love,通过查Ascll码的表,我发现,l映射的十进制是108、o映射的十进制是111,v映射的十进制是118,e映射的十进制是101,与该模拟器上转换的十进制完全不同,我将其发送给另一方,其接收的数据只有十进制和二进制的转换数字,并没有发现发送的文本字符。
同时我发现,每一个Ascll码对应下方的二进制是4位,那么当该四位二进制均为最大值1时,也不过才15,那么该模拟器能映射的Ascll码只有0~15,我再次查Ascll码的表,在0~15的范围内并没有除空字符外,并没有其他可以映射的文本字符。
之后我将Instructions切换至My Device发现了该问题的原因所在,即Chunk size选择的是4 bits per chunk,因为Ascll码是使用指定的7 位或8 位二进制数组合来表示128 或256 种可能的字符,因此将其修改为8 bits per chunk即可正常发送文本字符。
经过修改后,Ascll码love字符映射的十进制和二进制显示正常,发送给对方,可以看到接收的Message已经可以显示love字符(值得注意的是要显示该字符,接收方也要修改位8 bits per chunk)。说到这里我已经想到了我们常用社交软件的聊天功能了,基于此原理,如果再使用UTF-8码,即可做到中文字符的发送与接收。
2-4 广播消息
这一次任务由于是广播消息,我们需要多个伙伴的加入来共同完成该任务,最终我们集合了五位小伙伴,由我来发送消息。基于上一次任务的经验,这一次我们将各位的Device的Encoding修改为不同的编码,我的账户xcc只保留Ascll编码、账户wnn与我保持相同配置,账户libai既选择Ascll编码也保留二进制Binary,账户hhhh只保留二进制Binary,账号safv和我保持相同的配置。
那么由我的账户发送文本字符"love",观察四位小伙伴接收的情况。
账号wnn:只显示了Ascll码对应的字符love
账号libai:既显示了Ascll码对应的字符,也显示了Ascll码映射的二进制数字
账号safv:只显示了Ascll码对应的字符
账号hhhh:只显示了Ascll码字符映射的二进制
由此我们可以得到结论,在该广播房间内的任意一个账户发送的消息,所有的账户都可以接收到,并且由不同的设备保留的Encoding的不同从而显示出不同的内容。这当然很自然的让我们联想到我们经常使用的qq群和微信群的交流方式了,就是基于此原理而发展出来的应用层。那么对于该系统我们面对着什么样的挑战呢?我想大概就是Encoding的统一的问题,他要求所有设备在该广播房间里共用一套字符编码格式,假使我们都使用UTF-8编码,那我和我的几个小伙伴那该是可以正常使用中文交流了。如此便又是书同文的现代应用,打破语言障碍,统一文字、编码、标准、规则是人类发展交流不可阻挡的趋势。
2-5 路由和地址
在这次任务中,每个人都连接到了一个路由器,并有特定的地址。要发送消息,需要将消息指定给特定接收者的地址,路由器会负责将消息传送给正确的计算机。
那么本账号xcc发送给账户wnn,文本字符"love",就需要在ASCLL的To中填写wnn账户的地址1.7。
xcc账户:
wnn账户:可以看到正常接收到了xcc账户发送的消息,并且有xcc账户的地址。
可以观察以下服务器的日志记录:
可以清楚的看到每条消息发送的时间,经过的路由器,状态,开始地址,结束地址,以及发送的Message内容。也就是说,每条消息都是途径路由器转发的,当然路由器也就会记录每一条消息发送的具体内容,在这里我想到了网络安全,假使有人从路由器上窃取了日志记录,那么我们日常生活中的消息就是赤裸裸展示在有心人面前了。
2-6 数据包和可靠性
互联网上的消息会通过许多路径到达目的地,有时候消息会被丢失。在此次任务的互联网模拟器中:
- 数据包有 10% 的概率会被丢失
- 多个数据包可能会经由不同的路径到达目的地
- 默认数据包的最大尺寸设为 6 个额外的字符
在账户地址为1.10xcc上我发送了几条消息分别发送给地址为1.6的wnn和地址为1.4的safv。
其路由器的日志记录如下:
可以清楚的看到,几次发送的数据既有成功发送的,也有发送失败的。既有消息不为空发送成功的,也有消息不为空发送失败的。既有消息为空发送成功的,也有消息失败发送失败的。我都怀疑它这个10%的丢包率有点低了。因此减少数据的丢包率也是网络建设的重点任务之一呀,试想一下要是告白的消息被丢失了怎么办/(ㄒoㄒ)/~~
2-7 手动域名解析服务器
在此次任务的模拟器中,不能看见其他学生的地址。学生中要有人作为名称服务,来帮助相互共享地址。在左边的域名服务器选项卡中,需要有人作为域名服务器。
此次我们连接三个用户,情况如下图,可以发现除了自己的地址是看不见其他伙伴的用户的,那么怎么发送消息呢?
根据提示我们中一个伙伴将其作为域名服务器,那么在DNS的My Network中就可以看见该伙伴地址了。
在To中填写该伙伴的地址,其接收到本账户发出的消息。
2-8 自动域名解析服务器节点
在此次任务的互联网模拟器中,将会为你提供一个域名系统(DNS)以及已连接的计算机的 IP 地址。你只能看到已连接的计算机的主机名称。
DNS 地址始终是 <yourRouterNumber>.15。使用协议 GET [hostname]
来发送信息,例如发送 GET Bob2
到 DNS 以获取另一名学生的 DNS 地址。你随时都可以在笔记区选择 DNS 标签来查看答复。
此次任务,我们依旧是接入了三台计算机账户,加上系统提供的一台DNS。
按照提示,假如我想给wnn3发送消息,但是我又无法获取wnn3的地址,此时我可以利用DNS的协议 GET [hostname]
来获取wnn3的地址。
收到DNS回复的消息,获得wnn3的地址为1.11,经过验证DNS解析完全正确。
自动域名解析比之上一个任务的手动域名解析,完全减轻了工作量,仅一个人通过 GET [hostname]协议获取想要查询的主机地址,即可完成后续的通信。
四、总结
通过这两个任务的完成,我对日常接触的网络其背后的逻辑层认知逐渐清晰下来。在做任务二时我联想到了许多,之前接触过的网路拓扑结构,原来消息是顺着每一条线路都可以传输。后面的DNS,起初我只知道其能解析域名,并不明白其能解析域名的原理。当然我现在也没有完全清楚所有的这些网络知识包括TCP/IP、HTTP,还没有去弄懂这些协议、服务器、主机背后的所有关联。现在脑子很混乱,感觉懂了,又感觉还没有把所有知识串联起来。这一部分总结思路可能有些混乱,等我把TCP/IP、HTTP都看完了再来重写总结好了。