网络概念与快递物流

网络世界承载着太多的期许和重任。整个计算机的发展，因为网络的实现而势不可挡地飞速前行。无数的东西，慢慢变成轻量化的服务，存在于网络的云端，而最让人炫目的黑客技术，也几乎特指网络中的自由驰骋。而：

网络究竟是一个什么样的东西？
网络和网页是什么关系？
与它交织的各类协议，又同它自身有什么关系？
那些类似于法律条文的协议，如何同丰富多彩的网络游戏联系起来？
为什么要掌握这些法律条文？
掌握了这些法律条文的protocols，就可以成为黑客了吗？如何去利用这些条文？
所谓的网络编程，就是Socket编程吗？为什么仅仅依靠这个就可以了？
为什么要做Socket编程？它到底处于网络世界的什么位置？
所谓黑客，到底是在什么位置上去破解你的信息和隐私？

这一系列扑朔迷离的故事，都让Networks披上了神秘的外衣。

就我自己的角度来讲：

网络的根本作用，就是完成信息的交流，也即是完成比特(bit)流0、1的数字交换。

这样来讲，似乎有些抽象，也有些莫名其妙。而要形象具体起来，就要用到“类比”这个工具。而关于网络的最直观的类比，无疑是如今发达的、支撑电商运作的“快递物流”。

只不过，物流公司运输的是实实在在的“物体”，而网络运载的是抽象的信息流，也即是那一堆0、1数字。

让我们先达成一个共识。在如今的数字时代，几乎所有的信息，都能够被转换为0、1数字流（也即是比特流）在计算机中存储、交换。所谓的信息化、数字化，也就是把各种形式的信息（文字、声音、图像等等），都转换成为数字流。

那么，对网络这个关于信息的物流行业来讲，如果实现了对0、1数字流的运输和物流，也就实现了对所有形式的、抽象的“信息”的物流。

如此，在开头对网络作用的定义就可以替换为：完成0、1数字流的运输物流。

那么，在这样的视角之下，很多看似不同的网络应用，其实都是一回事：

手机App里面发送微信和朋友圈，无非是把“文字”和“图片”的比特流和微信服务器端做交换。

网络游戏，无非是把自己游戏角色的当前属性、位置坐标，和服务器端做交换。

使用淘宝购物，无非是把自己选中的商品信息和淘宝的服务器端做交换。

发送email，无非是把email的文字、图片信息和收件人做交换。

观看直播、视频，无非是把图像、音频的信息，与服务器端做信息交换。

而物流这样的基础设施，其最基本的模型无非是：从A点通过一条路径，把货物（比特流）运输到B点。

也即是两个点A和B，以及连接它们的一条线。

那为什么又需要“网络分层”的概念呢？如果让我们继续考察现实生活中的物流，或许就能够很轻松地理解这个必要性了。

虽然我们都知道，运输我们要寄送的货物是需要落实到最后的“汽车运输、火车运输、轮船运输、飞机运输”这样一个终端环节。但如果我们每次寄送一件货物，都需要去关心这些终端运输环节，就太麻烦了。

那么实际的解决方案是什么呢？

网络应用层

现实生活中，与我们紧密相关的物流操作基本上就是：

给快递（例如，顺丰）小哥打一个电话，或者在手机上做在线下单，然后快递小哥就上门来取件。
而在接受端，待在家里或者公司的我们，并不需要走到屋外，快递小哥会把寄给我们的货物，呈送到我们门前。

在这样的视角下，似乎寄送东西这件事情，只需要有物流小哥就够了，别的什么飞机、货车、以及运输标签都是不需要的。物流小哥就像是一个空间传输的虫洞：扔给他一件物品，就能嗖地一下出现在接收端，把东西呈送给收件人。这一过程，可以对应到网络的应用层。

我们不用关心这个货物，是通过飞机寄送的、还是轮船寄送的，又或是在寄送的过程中经过了哪些省、又绕过了哪些市。我们统统不需要关心。我们有且只需要和物流小哥对接，其它的服务和琐碎的事情，就由快递小哥及他所在的物流公司代替我们去操心和完成。

网络的应用层也如是。我们不需要关心“按下的【下单】按钮”，是通过stream的方式发送的还是通过datagram的方式发送的，又或是“下单”这个指令绕过了多少路由器、走过了全世界多少个国家、穿越了多少个海底隧道，我统统不用关心，我只需要把我的需求告诉应用层，别的细节自有它对应的底层去关心和完成。

分层添加header封装

对我们一般用户来讲，关心应用层，也即是快递小哥，这个接口就够了。可如果想要操控更多的细节，例如程序员更精细地控制信息的发送与交换（对应到：协助一个公司，组织批量的货物寄送，这就需要更多地了解和谈判运送方式和时间限制），你就不得不深入直下，去探讨“快递”这一个过程更多的细节。

对于初次了解网络分层的人来讲，在每一层添加数据包的header，将上一层作为整体打包成为这一层数据的过程，会显得异常古怪。干嘛非要这么繁琐地做数据打包呢？它的好处又在哪里呢？

同样，要理解这个事情，我们只需要考察一下现实生活中的快递是如何被寄送出去的过程就行了。

例如，我们考虑将一个包裹，从“苏州”寄往“绵阳”，看看它会经历哪些过程。

一般来讲，快递都会经历一个聚合的过程（大家可以留意一下每次快递移动的地理位置记录）：先从一个省的某个城市汇集到这个省的省会城市。再从省会城市发往另外一个省会城市。再在另一个省会城市，发往相应的所在地。（这一默认规则，也就是网络中类似法律条文的protocol了）

那么，如果要从苏州发往绵阳，或许这个包裹经历的第一个过程就是要把整个包裹先贴上一个标签——“寄往成都”（这个标签其实就是header，而“被寄送的东西”连同最开始的标签“寄往绵阳”一起，被用作这一层的package内容去打包）。

为何要“添加寄往成都”这个标签？因为绵阳属于四川，而成都是四川的省会。按照上面这一段的规则（也即是按照protocol的规定）：要想成功寄送到绵阳，就必须先把货物送到四川的省会城市成都。

然后，这个从苏州发出的包裹，就会被派送到江苏的省会城市南京。到了南京后，又会被整个地封装成一个包裹，然后贴上“寄往四川”的标签（对应到header）。

而到了四川成都后，又会按照刚才的相反顺序，一层层地将“四川”“成都”的标签拿掉，最终寄送到目的地绵阳。

上述过程，也就是网络分层里面常常遇到的“打包添加header”和“拆包去掉header”的过程。从物理世界的物流管理来讲，其实很容易明白这套繁琐手续背后的动机和考虑。将各个不同的路径，以统一整合的方式去汇集和转送，能够极大地提高整体系统的运输效率。

每一个层次只需要负责一小段的点对点的发送，能够将任务均衡地分配给每一个小队，并且还能把“系统复杂度”独立地分摊到这些小队。而整体上，又能将这些分散的职能衔接起来，覆盖各式各样的复杂运输需求。

至于里面的细节，为什么要添加header，为什么要把整个上一层的“header+package内容”作为这一层的package内容？那只不过是现实世界的“套袋打包、再贴标签”的对应罢了。

梯子与墙

有了这样的“比特流的物流运输”模型，我们几乎可以理解网络世界的一切东西。例如，那个神秘而又深奥的“架设梯子”的原理，我们也可以做一番清晰的探讨。

按照物流运输模型，所谓的墙，无非就是当我想从所在的A国，同B国交换信息的时候，发现中间的道路被人为控制了。对应到的发送快递的例子是：当我想把“B国的东西”运送回“我所在的A国”时，却发现负责运输这个货物的货车，在过海关时被拦截下来了。因为A国的边境有一条规则，凡是从B国发出来的货物，均不允许通过。（而反过来从A国发往B国的货物，也不允许通过。）

那怎么办呢？

作为A国的海关边境，它应该存至少一个允许货物进入的国家，例如C国。也即是，凡是从C国运输过来的东西，我A国是允许进入的。（而A国的货物，也能够被发往C国。）

而这个时候，如果C国又恰好允许B国的货物进入它的国内。这时，从B国发出来的货物，就有办法被运送到我们自己的A国了。

如何操作呢？

那就很简单了：先让这个B国的货物发送到C国。然后，再以C国的名义发送到A国就好了。（而反过来，如果要把A国的东西运输出去，只需要先发送到C国，再从C国发送给B国就好了。）

那么，网络世界的梯子是怎么回事呢？就是把刚才那个运输过程的货物，换成比特流就好了。既然我A国的网络无法接收到B国的网络所发送出来的信息（0、1数字流），那么，我只需要在C国（能够同时允许与A国和B国做网络信息交换的国家），有一个中转的服务器就好了。

这时候，我把对B国的网络访问请求，直接先打包成发送给C国服务器的包裹，先寄送到C国的服务器里。再在C国的这个服务器里，拆开这层伪装包裹，把真正发往B国的请求通过C国的服务器发送到B国。

接到服务请求的B国，把相应的“响应信息”先打包成发送给C国的包裹做中转。C国的服务器依旧拆开这个伪装包裹，把里面的信息取出，再从C国服务器把相应的“响应信息”发送到A国。

如此，就成功绕过了A国到B国不允许通行的“墙”限制，实现了“架设梯子”的功能。

希望这个“比特流的物流运输”模型，能够帮助你更好地理解这个网络世界。

近期回顾

《精湛技艺的祭品》
《向南的高速公路》
《读《中国近代史》》