个问题——网络为什么不通，来具体说明怎么将书本上的死知识真正变成我们解决问题的能力)
大学学到的基本概念
我相信你脑子里关于网络基础知识的概念都在下面这张图中。知识内容有点乱，感觉都认识，又都模模糊糊，更谈不上将内容转化成生产力或是用来解决实际问题了。这是因为知识没有贯通、没有实践、没有组织。
所以接下来我们将示范书本知识到实践的贯通过程，希望把网络概念之间的联系通过实践来组织起来。
还是从一个问题入手
最近的环境碰到一个网络 ping 不通的问题，当时的网络链路是（大概是这样，略有简化）：
现象
● 从容器 1 ping 物理机 2 不通；
● 从物理机 1 上的容器 2 ping 物理机 2 通；
● 同时发现即使是通的，有的容器 ping 物理机 1 只需要 0.1ms，有的容器需要200ms 以上（都在同一个物理机上），不合理；
● 所有容器 ping 其它外网 IP（比如百度）反而是通的。
这个问题扯了一周才解决是因为容器的网络是我们自己配置的，交换机我们没有权限接触，由客户配置。出问题的时候都会觉得自己没问题对方有问题，另外就是对网络基本知识认识不够，所以都觉得自己没问题而不去找证据。
这个问题的答案在大家看完本文的基础知识后会总结出来。
解决这个问题前大家先想想，假如有个面试题是：输入 ping IP 后敲回车，然后发生了什么？
回车后发生什么？
我们来思考一下 ping IP 到底发生了什么。
首 先 OS 的 协 议 栈 需 要 把 ping 命 令 封 成 一 个 icmp 包， 要 填 上 包 头（包 括src-IP、mac 地址），那么 OS 先根据目标 IP 和本机的 route 规则计算使用哪个interface( 网卡），确定了路由也就基本上知道发送包的 src-ip 和 src-mac 了。每条路由规则基本都包含目标 IP 范围、网关、MAC 地址、网卡这样几个基本元素。
如果目标 IP 和本机使用的 IP 在同一子网
如 果 目 标 IP 和 本 机 IP 是 同 一 个 子 网（根 据 本 机 ifconfig 上 的 每 个 网 卡 的netmask 来判断是否是同一个子网——知识点：子网掩码的作用），并且本机 arp 缓存没有这条 IP 对应的 mac 记录，那么给整个子网的所有机器广播发送一个 arp 查询，比如我 ping 1.1.3.42，然后 tcpdump 抓包首先看到的是一个 arp 请求：
上面就是本机发送广播消息，1.1.3.42 的 mac 地址是多少？很快 1.1.3.42 回复了自己的 mac 地址。 收到这个回复后，先缓存起来，下个 ping 包就不需要再次发 arp 广播了。 然后将这个 mac 地址填写到 ping 包的包头的目标 Mac（icmp 包），然后发出这个 icmp request 包，按照 mac 地址，正确到达目标机器，然后对方正确回复 icmp reply（对方回复也要查路由规则，arp 查发送方的 mac，这样回包才能正
确路由回来，略过）。
来看一次完整的 ping 1.1.3.43，tcpdump 抓包结果：
我换了个 IP 地址，接着再 ping 同一个 IP 地址，arp 有缓存了就看不到 arp 广播查询过程了。
总结
网络丢包、卡顿、抖动很容易做扛包侠，只有找到真正的原因解决问题才会更快，否则在错误的方向上怎么发力都不对。准确的方向要靠好的基础知识和正确的逻辑以及证据来支撑，而不是猜测。
● 基础知识是决定你能否干到退休的关键因素；
● 有了基础知识不代表你能真正转化成生产力；
● 越是基础，越是几十年不变的基础越是重要；
● 知识到灵活运用要靠实践，同时才能把知识之间的联系建立起来；
● 简而言之缺的是融会贯通和运用；
● 做一个有礼有节的甩包侠；
● 在别人不给证据愚昧甩包的情况下你的机会就来了。
留几个小问题：
- server 回复 client 的时候是如何确定回复包中的 src-ip 和 dest-mac 的？
一定是请求包中的 dest-ip 当成 src-ip 吗？ - 上面问题中如果是 TCP 或者 UDP 协议，他们回复包中的 src-ip 和 dest-mac 获取会不一样吗？
- 既然局域网中都是依赖 Mac 地址来定位，那么 IP 的作用又是什么呢？