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都看完了再来重写总结好了。
1639
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
