I Bet Nobody Has Ever Explained the Networking Topics Like This Before

作者回忆初学分布式应用时的困惑：数据库在运行、凭据正确，应用却连不上，错误信息只显示连接超时，无法说明请求在哪一步消失。他认为网络难在开发者看不到底层发生了什么，而真正开窍的办法不是背二十个定义，而是跟随一次请求，理解每个网络概念为何存在。

以打车应用 RideNow 为主线：乘客输入目的地叫车，系统在后台找到附近司机并发送请求，司机接单后乘客能看到司机位置。用户只看到点按钮后几秒出现司机，背后网络上发生了很多事。

乘客手机要与另一台机器通信，网络需知道那台机器在哪。每台在 IP 网络上通信的设备都需要 IP 地址，可类比邮政地址。

IPv4 更早且仍极常见，使用 32 位地址空间，约四十亿个地址，逐渐耗尽，这也是引入 IPv6 的主要原因。IPv6 使用 128 位地址空间，地址数量极其庞大。关键差别是 IPv4 地址空间小得多，IPv6 为支持联网设备持续增长而设计得大得多。两者解决同一根本问题，即提供地址让设备在 IP 网络上通信。

IP 地址不一定是设备的永久身份，应理解为设备当前可达的位置。连家庭 Wi-Fi 时手机通常获得私有 IP，只在本地网络内有效；公网 IP 则可在互联网上被访问。构建 RideNow 时这一区分很重要，有些部分需接收互联网流量，数据库等应只能从私有环境内部访问。

乘客不知道也不应输入 RideNow 服务器的 IP，只需用名字打开应用，这就要靠 DNS。DNS 即域名系统，把主机名翻译成网络可用的 IP 地址，帮助应用发现后端可达位置。这种查询不一定每次都从头进行，DNS 响应可被缓存，缓存结果的有效期由 TTL 控制；一个主机名还可指向多个 IP 地址，这在应用需要跨多台机器处理流量时很有用。

一台机器可能同时运行 Web 应用、数据库等多个服务，网络需要知道要访问哪个应用，这就要靠端口。IP 地址标识机器，端口标识该机器上要通信的应用或服务。应用只监听 localhost 而不接受来自网络的连接，会导致另一台机器连不上，因此应用已启动与应用在网络中真正可达是两回事。

以太网和 Wi-Fi 等局域网通常用 MAC 地址标识链路上的接口。IP 地址用于跨网络寻址，链路层则需要确定当前链路上的下一跳接口。

在 IPv4 网络中，ARP 可查询本地链路上下一跳的 IPv4 地址对应的 MAC 地址，结果可以缓存。访问其他网络时，设备通常先解析本地网关；IPv6 则使用邻居发现协议。

RideNow不在乘客家中，请求要跨越多个网络，这靠路由完成。路由器查看目的地并决定流量下一步去向，手机无需知道完整路径，每台路由器逐跳转发。因此客户端与服务器之间可涉及多个网络，也解释了应用本身健康却仍出现延迟或丢包的原因。

在典型家庭 IPv4 网络中，NAT 把私有地址及端口转换为公网地址及端口，并记录连接，让响应回到对应设备。多台设备因此可以共享公网连接；云环境中的私有服务器也常用 NAT 获得出站访问。

RideNow成为正式生产系统后，不应让所有机器处于一个可互相通信的大网络，子网划分把大网络切成更小网段。可按需划分接收外部流量、应用服务、数据库等区域，目的不只是整齐，而是控制流量在系统各部分间如何移动，例如数据库只需接受应用服务流量。

新机器加入网络需知道用哪个IP、网关和DNS服务器，手动配置数百上千台不现实，DHCP让设备自动获得网络配置。连Wi-Fi时无需手动输入网络信息，就是DHCP在起作用；它可下发IP地址以及网络配置、网关和DNS服务器等信息。

能到达另一台机器还不够，乘客点击请求打车时，数据需可靠且按正确顺序到达，这靠TCP。TCP在两个端点间提供可靠有序通信，能检测丢失并安排重传，还处理流量控制与拥塞控制，避免发送方压垮接收方或网络。对打车请求这类重要数据，可靠性很关键。

TCP传输应用数据前需三次握手建立连接：客户端发起、服务器响应、客户端确认。建立连接有开销，应用常复用已有连接。

账户、位置乃至支付相关信息不能在网络上被直接读取，因此需要HTTPS与TLS。HTTPS通过TLS实现安全HTTP通信：加密使截获者无法读取，完整性可检测数据是否被修改，证书认证让客户端验证所连服务器。生产环境中TLS未必由应用直接处理，可由前置基础设施终止，必要时到内部服务前再加密。

连接安全后进入HTTP应用请求：乘客点击打车，应用向后端发送HTTP请求，后端验证乘客、检查行程、寻找司机并返回HTTP响应。这种请求响应模型正是开发者构建API和Web应用时使用的。

RideNow 走红后成千上万乘客同时请求，单台应用服务器不够用。做法是运行多台应用服务器并在前面放负载均衡器，由它接收流量并挑选健康的后端处理，乘客无需知道是哪台服务器。好处是可扩展，加机器即可扩容；也提升可用性，某台不健康就停止向它转发，其余继续服务。

负载均衡给出受控入口，但生产系统常希望入口做更多事：处理 TLS、按请求类型路由、缓存响应、压缩数据、隐藏内部服务结构。反向代理位于客户端与后端之间充当中介，乘客无需知道请求最终去乘客服务、司机服务还是行程服务，由它决定去向，并承担 TLS 终止、缓存、压缩、路由等职责，因此常与负载均衡搭配使用，职责依架构而重叠。

有通路不代表应放行所有流量，需要控制谁能与谁通信。防火墙决定哪些流量允许、哪些阻断：乘客可访问 RideNow 公开部分但不能直连数据库，应用服务可与数据库通信而公网直连被拒。云上可用安全组和网络访问规则实现，容器环境可用策略限制工作负载互通。排障时连接超时未必是应用代码问题，可能是中间某条网络规则在丢包。

司机接单后乘客要看位置在地图上移动，若手机每隔几秒轮询最新位置会产生大量无谓流量。WebSocket 在客户端与服务器间建立持久双向通道，连接建立后服务器无需等待请求即可推送更新，司机位置变化时 RideNow 直接把新位置推到乘客手机。选它不是因为流行，而是因为服务器需要持续向客户端发送更新。

UDP 本身不保证数据交付、顺序或去重，协议机制较少，常用于实时场景。需要可靠交付的应用可以自行实现相关机制；UDP 和 TCP 的选择取决于应用需求，不能保证使用 UDP 就一定更低延迟。

OSI 模型把网络分为从物理层到应用层的七层。其价值不在背层名，而在于定位问题出在哪一层，从而缩小范围。

一次 RideNow 请求逐层走完：DNS 解析、端口定位应用、路由与 NAT 送达、TCP 建连、TLS 加密、HTTP 承载请求，再经负载均衡与反向代理分发。司机接单后用 WebSocket 推送位置，低延迟优先时用 UDP。OSI 模型帮助分层排障。

总结指出网络并不是二十个互不相关的概念，而是一条请求穿过系统的旅程，每个概念沿途解决一个不同问题。只要能从手机上的 IP 地址一路跟到应用再返回，网络就会变得容易理解得多。