本文将通过蟹堡王的案例，简单地讲述下计算机网络的运行机制。
前言与课程介绍
课程目标
建立对计算机网络的整体认知，对计算机网络中的各种概念（网络分层、网络协议、网络应用等）有初步的理解，进而可以在后续的实际工作中能高效解决网络问题。
课程介绍
主要内容：
- 通过一个示例建立对计算机网络的整体认识
- 建立对网络协议分层的认知
- 分析HTTP1、2、3的关系
- 介绍CDN运行的基本原理
- 了解网络安全的最基本原则
由于是一门概论课，这节课并不会详细描述如何开发一个基于HTTP协议（或者其他协议）的网络应用，也不会深入介绍课程中所涉及协议的规范（Specification）内容和实现细节。
分析方法
课程会从两个方向进行分析：
自底向上：从简单开始，逐渐变复杂、将模块逐步拼凑成一个系统
自顶向下：从复杂开始，逐渐变简单、从复杂的系统问题入手，拆分为模块问题
蟹堡王帝国
为了建立一个蟹堡王帝国，老板制定了三步走战略
- 在比奇堡开通外卖
- 在北京和上海开分店
- 在全国开分店并开通外卖
在比奇堡开通外卖
案例一：
龙虾拉里想订外卖，但是打不通电话，因为每天打到蟹堡王订餐的电话实在是太多了。
但是仔细分析顾客的订餐内容，其实重复性很高，基本都是顾客描述订餐内容，然后餐厅服务员确认餐品内容。
可以对顾客点餐的主要内容进行整理优化，列成一个表格：
| 问题 | 信息 |
|---|---|
| 谁吃? | 派大星 |
| 吃什么? | 两个蟹黄堡和一个炸海草 |
| 送到哪? | 比奇堡石头屋 |
这样顾客就可以直接使用传真提交表格来点餐，而非再和前台表述一遍自己的需求了。
在北京和上海开分店
分店的名字就定为：北京方恒蟹堡王和上海科技绿洲蟹堡王。
开了分店之后，就得收集相关的数据，比如分店每天赚了多少钱，需要多少原料数量。对这些数据进行分析来决定是否需要开新分店，并且向新店发送最新的促销信息。
为了收集和分发这些数据，蟹堡王需要建立一个上海、北京、比奇堡的通信线路。这时候需要通信的节点并不多，直接建立简单的线路即可。
由于生意火爆，需要在北京多开几家分店（比如中航蟹堡王、紫金蟹堡王、大钟寺蟹堡王等等），那么应该如何设计新的通信线路呢？
由于这些分店和方恒蟹堡王一样都在北京，离得非常近，于是总部直接就与方恒蟹堡王进行通信，然后让方恒蟹堡王转发给在北京的其他蟹堡王，这样就实现了比奇堡蟹堡王与新分店的通信。
那么应该如何设计通信的表格呢，可以维护两个字段，一个是来着，一个是发往，这样做为中间节点的方恒蟹堡王就能够知道应该如何进行转发通信了。
下面是两个转发表格的案例：
| Header | 内容 |
|---|---|
| 来自 | 中航蟹堡王 |
| 发往 | 比奇堡蟹堡王 |
| 内容 | 今日销售数据：1000个蟹黄堡 |
| Header | 内容 |
|---|---|
| 来自 | 比奇堡蟹堡王 |
| 发往 | 中航蟹堡王 |
| 内容 | 明日促销信息：全场8折 |
如果中航蟹堡王是一家新店或者店铺进行了搬迁，那么方恒蟹堡王一开始不知道中航蟹堡王在哪，又只能回去联络比奇堡蟹堡王，得到新的地址。
这样在每次开新店或者店铺搬迁的时候，就都得去问一次比奇堡蟹堡王，为解决这样的重复的问题，可以在每次开新店或者店铺搬迁的时候，直接发送一份最新的店铺地址名单给所有的分店。
蟹堡王外卖
在比奇堡开放一段时间的外卖之后，发现了以下特点
- 比奇堡居民居住分散
- 城市中的小区密度较高
- 小区中每家都直连蟹堡王成本太高
那么就可以将每个小区做为一个转发节点，不同节点之间通过中间节点进行转发通信，也能节省非常多的重复路线。
在全国各省开新店的时候也可以用类似的方案，比如要在杭州开一个新店，可以直接使用上海的分店做为中间节点进行通信。
小结
课程的前两部分通过三个小节的情景案例，讲述了一个建立网络的案例：蟹堡王帝国。
讲述案例角色与实际设备的对应关系如下：
蟹堡王顾客：客户端
蟹堡王分店：服务端
小区转发点和蟹堡王城市转发分店：路由器
转发表格：网络协议
比奇堡和小区网络：本地网络
北京和上海分店+比奇堡：三个本地网络节点的网络
全国通信网络：本地网络的网络
