网络与分布式系统：当“远处”变成一次系统调用
你在浏览器地址栏里输入一个网址，按下回车，页面通常很快就出现了。站在用户的角度，这只是一连串像素变化；站在操作系统的角度，事情要曲折得多：应用先把域名交给解析器，内核创建通信端点，数据被切成一段段字节，再套上不同层次的首部，经由无线网卡、家庭路由器、运营商网络和远端机房，最后抵达某个服务器进程。返回的数据还要沿着另一条未必相同的路径回来。
这个过程最有意思的地方，不是设备很多，而是每一层都在替上一层隐藏麻烦。应用不想知道无线电波如何编码，传输层不想为每一种网卡重新设计可靠性，路由器也不关心数据究竟是一张图片还是一次文件读取。分层让系统可以拆开演进，但也带来首部开销、排队延迟和跨层诊断的困难。
当一台机器变成许多台机器，问题还会再拐一个弯。内存不再共享，时钟也不能当成绝对一致；一台服务器沉默时，你甚至无法立刻判断它是崩溃了、网络断了，还是只是暂时很慢。分布式系统真正要处理的，正是这种“不确定但又必须做决定”的处境。
从一次网页访问看网络分工
先看一个很具体的场景。你在宿舍用笔记本访问在线课程，数据先通过 Wi-Fi 到达接入点。接入点和交换机负责把帧送到当前局域网中的正确位置，默认网关再把 IP 数据包送往其他网络。离开校园或家庭网络后，数据可能穿过多个运营商和自治网络，经过一跳又一跳的路由器，才抵达服务所在的数据中心。
“局域网”和“广域网”不只是按地图大小划分。局域网通常处于一个组织或家庭的管理边界内，链路短、带宽高，设备可以直接使用以太网或无线局域网技术通信。广域网要跨越不同管理者、不同链路和更长的物理距离，路由策略、费用、故障边界都会变复杂。局域网优化的是本地接入和交换，广域网更关心网络之间如何转发以及如何在策略约束下到达目的地。
一次网页访问会先离开家庭局域网，再由广域网中的路由器逐跳转发到服务器，响应则沿网络返回客户端。
交换与路由不是同一件事
在同一个二层网络中，交换机主要依据链路层地址转发帧。主机要把数据交给同网段的另一台主机时，需要先知道对方的链路层地址；在 IPv4 局域网里，这通常由 ARP 完成。如果目标 IP 不在本地网段，主机不会去寻找远端服务器的 MAC 地址，而是把帧交给默认网关。网关取出其中的 IP 数据包，查找路由表，再为下一段链路重新封装一个新的帧。
这意味着一个数据包每经过一台路由器，链路层首部通常都会换掉，端到端的 IP 源地址和目的地址则原则上保持不变。若路径上存在网络地址转换，中间设备还可能改写 IP 地址或端口，并维护一份映射状态。路由器选择下一跳时看的是网络前缀，匹配项不止一个就采用最长前缀匹配：更具体的路由优先于更宽泛的默认路由。
交换机解决“这个局域网里的帧交给谁”，路由器解决“这个 IP 数据包下一步进入哪个网络”。家用无线路由器常把接入点、交换机、路由器、NAT 和防火墙装在一个盒子里，所以外观上容易把这些职责混成一件事。
分组交换为什么能让许多人共用链路
如果每次通信都先独占一条从起点到终点的物理线路，大量间歇性网络请求会浪费容量。分组交换采用另一种办法：把数据拆成一个个分组，让许多通信流在同一条链路上交错前进。链路忙时，分组先进入队列；队列满了，分组就可能被丢弃。
一次网络传输的等待时间可以粗略拆成四类：设备处理首部需要处理时延；分组等待出口需要排队时延；把全部比特推上链路需要发送时延；信号在介质中传播需要传播时延。带宽提高会缩短发送时延，却不能消除跨洲光纤的传播时延。网络拥塞时，最先剧烈变化的往往是排队时延，因此“测速带宽很高”和“交互仍然卡顿”完全可能同时出现。
互动：让一个数据包走完整条路
下面的演示不依赖外部资源。选择不同网络场景、调整数据量，再逐跳观察链路变化。这里的数字是用于比较量级的简化模型，重点是看清发送、传播和排队三类成本如何叠加。
协议分层：每一层只承诺一部分事情
如果所有应用都自己处理网卡、路由、丢包和拥塞，软件几乎无法移植。TCP/IP 协议族把通信任务分层后，应用只需要选择合适的接口和语义。常用的理解方式是四层：链路层负责相邻节点或本地链路上的交付；网际层负责跨网络寻址与尽力转发；传输层把通信交给主机中的具体进程，并可提供可靠字节流或数据报；应用层定义 HTTP、DNS 等业务协议。
你也会见到七层的 OSI 参考模型。它把会话管理、数据表示等职责单独列出，很适合讨论“某项功能应该放在哪里”；互联网协议的实际实现却很少严格按七个独立模块运行，通常把会话、表示和具体业务都放进应用层。两套模型不是互相否定：一个更细地描述职责，另一个更接近常见协议栈的部署方式。排障时不要纠结背诵层号，先确定故障属于本地链路、跨网寻址、端到端传输还是应用语义。
发送时，应用数据逐层向下，每层加上本层需要的控制信息，这叫封装。接收时则逐层检查并移除首部。假设浏览器交给 TCP 一段 HTTP 数据，TCP 会加入端口、序列号等字段，IP 再加入源地址、目的地址和跳数限制，链路层最后把它放进帧。到达路由器时，路由器通常只处理到网际层：移除收到的链路层封装，减少跳数限制，查下一跳，再套上适合出口链路的新帧。
数据离开发送主机时逐层封装，路由器按网络层信息转发，并在每一跳重新进行链路层封装，接收端再逐层拆开。
这种边界不是绝对墙壁。操作系统会利用网卡的校验和卸载、分段卸载等能力减少 CPU 工作，防火墙也会同时查看地址、端口甚至应用信息。但分层仍然给了我们一条很好用的诊断顺序：链路是否连通，IP 是否有路由，传输连接是否建立，应用协议是否得到正确响应。
IP 只做尽力而为的转发
IP 的基本承诺很克制：给数据包标上源地址和目的地址，让路由器有机会把它转发到目标。它不保证一定送达，不保证只送一次，也不保证按顺序到达。一个包可能因为校验失败、队列溢出、跳数耗尽、路径 MTU 问题或路由变化而消失。
IPv4 地址有 32 位，IPv6 地址有 128 位。两者都使用网络前缀形成层次化路由，但首部设计和邻居发现等机制不同。IPv6 把分片责任放到源主机，路径中的路由器不再替数据包分片。无论使用哪一版 IP，应用通常不应假设“连接到一个名字”只会得到一个地址；一个域名可能同时有多条 IPv4、IPv6 或负载均衡记录。
路由表是一组带优先级的下一步
路由表记录“某个前缀该从哪个接口、经哪个下一跳出去”。它可以来自直连网络、静态配置，也可以由路由协议学习。一个园区内部可能使用链路状态协议计算拓扑中的路径，不同自治系统之间则需要交换可达前缀和策略信息。这里的“最佳”不一定等于物理距离最短，商业关系、安全策略和链路容量都会影响选择。
路由的代价也很明显。设备要维护状态并在拓扑变化时收敛；收敛期间可能暂时绕路或不可达。路径还可能是不对称的，请求和响应经过不同路由器。因此，抓到去程流量并不代表你已经看到了回程问题。
名字、地址与通信端点
我们习惯说“访问某个网站”，程序真正需要的却是一组更具体的信息。名字便于人记忆，也便于服务迁移；IP 地址告诉网络把包送到哪台主机或哪个网络接口；端口号让接收主机把数据交给正确的进程。把 IP 地址、传输协议和端口组合起来，才得到可用于通信的端点。
进程在操作系统中通过套接字使用这些端点。服务器通常先创建套接字，绑定本地地址和端口，再监听连接或等待数据报；客户端创建套接字后发起连接或直接发送。套接字文件描述符让网络 I/O 看起来和文件读写有些相似，但网络比磁盘多了对端、超时、半关闭、乱序和中途断开等状态，错误处理不能照搬本地文件逻辑。
DNS：先找到负责回答的人
域名系统把一个巨大的命名空间拆成层次化区域。应用先询问本机配置的递归解析器；解析器若没有可用缓存，会从更高层的名称服务器获得转介，逐步找到目标区域的权威服务器，再取得地址或其他记录。根服务器并不保存互联网上每台主机的地址，它主要告诉解析器下一层应该问谁。
缓存是 DNS 能扩展到全球规模的重要原因。每条记录都有可缓存时间，在有效期内，解析器可以直接复用结果，减少时延和权威服务器负载。代价是变更不会瞬间传遍所有缓存。记录刚修改时，有些用户可能拿到新值，有些用户仍使用旧值；不存在的名称也可能被短暂缓存，所以修正拼写后不一定立刻恢复。
一次解析还可能经过别名链。最终返回多个地址时，客户端会依据本机网络状况和地址选择策略尝试连接。解析成功只说明“名字得到了地址”，并不说明端口可达，更不说明应用服务正常。
缓存未命中时，递归解析器沿名称服务器层级寻找下一站线索并取得目标地址；缓存命中后可以直接返回。
UDP：保留消息边界的轻量数据报
UDP 提供端口复用和数据报传输，首部很小，不建立连接，也不替应用保证到达、顺序或去重。发送一次数据报，接收方要么得到一整个数据报，要么得不到；消息边界不会像 TCP 字节流那样消失。DNS 查询、实时媒体和游戏常使用 UDP，但“使用 UDP”不等于应用不需要可靠性。需要重传、拥塞控制或连接迁移时，应用协议必须自行设计，或者使用建立在 UDP 之上的成熟传输协议。
UDP 的低开销也有边界。数据报过大会遇到路径 MTU 和分片问题，丢失一个分片可能让整个数据报无法重组。无节制发送还会挤占网络队列，因此实时应用同样需要控制速率，并在“及时到达”和“完整到达”之间做取舍。
TCP：把不可靠的分组整理成可靠字节流
TCP 给应用的是一条有序、可靠的双向字节流。它不保留应用写入时的消息边界：发送方连续调用两次写入，接收方可能一次读完，也可能分多次读到。因此，应用协议必须用长度字段、分隔符或固定格式自己标出消息边界。
建立连接时，双方通过 SYN 与确认交换初始序列号，并确认两个方向都能通信。常说的“三次握手”并不是礼仪，而是在没有共享状态的两台机器之间建立一组可验证的连接状态。数据传输后，接收方用累计确认告诉发送方已经连续收到哪个位置；若某段丢失，发送方可以根据超时或重复确认重传。校验和用于发现传输中的损坏，序列号用于重排和识别重复数据。
关闭连接时，两个方向的字节流分别结束。一方发送 FIN 只表示“我没有更多数据要发”，另一方向仍可以继续传输，所以常见过程会看到两个 FIN 和各自的确认；某些报文可以合并，不能把所有关闭都机械理解成固定四个包。主动关闭方通常还会短暂保留连接状态，避免迟到的旧报文干扰后来复用同一四元组的新连接。
流量控制与拥塞控制管的是两件事
接收方缓冲区有限。如果应用读取很慢，发送方继续猛发会把接收缓冲区塞满。TCP 用接收窗口告诉发送方“我还能接多少”，这是流量控制。网络中的路由器队列同样有限，但接收方看不到整条路径的容量。发送方还要维护拥塞窗口，根据确认、时延和丢包等信号估计可以有多少未确认数据在网络中，这是拥塞控制。
真正允许在途的数据量受两扇窗口中较小的一扇限制。接收窗口很小，瓶颈在接收进程；拥塞窗口很小，瓶颈在网络路径。慢启动并不是速度一直很慢，而是在连接开始或恢复后逐步探测容量；一旦出现拥塞信号，发送方收缩窗口，再谨慎增长。这样做牺牲了短时间内的峰值速度，换来不同连接共同使用网络时不至于持续把队列压垮。
可靠传输靠确认与重传补齐丢失的数据，同时用接收窗口保护接收方、用拥塞窗口保护网络，实际发送量受较小窗口限制。
互动：谁限制了 TCP 的在途数据
调整接收窗口、拥塞窗口和往返时间，观察有效窗口与理论上限如何变化。演示把许多实现细节省略了，但能清楚区分“对端接不下”和“网络装不下”。
“TCP 可靠”只表示已建立连接中的字节会被校验、排序和重传，不表示一次业务操作必然只执行一次。服务器可能已经处理请求，但响应在途中丢失；客户端超时重试后，业务动作就可能执行两次。支付、创建订单等操作仍需幂等键或事务语义。
加密与身份认证不能靠 TCP 自动获得
TCP 能发现偶发比特损坏，却不负责抵抗窃听、篡改或冒充。TLS 通常位于应用协议与传输协议之间：握手阶段协商算法、验证服务端证书并建立会话密钥，随后用对称加密保护应用数据，同时用完整性校验发现恶意修改。HTTPS 就是 HTTP 在 TLS 保护下通信。
加密也有边界。TLS 保护连接中的内容，却不会隐藏所有元数据，观察者仍可能看到通信双方的网络地址、流量大小和时序；证书验证只确认名称与密钥的绑定，不替应用判断业务账号是否有权限。密钥协商和加解密还会消耗 CPU 与额外往返，虽然会话恢复和硬件加速能减轻成本。
如果希望在网络层为一组主机或整个站点建立受保护通道，可以使用 IPsec 等机制。它对上层应用更透明，适合虚拟专用网络和站点互联；但策略、密钥、路径 MTU 和故障诊断会更复杂。安全放在哪一层，取决于保护对象、部署边界和谁有权配置密钥。
分布式系统：困难来自无法共享确定性
把同一个程序复制到三台机器上，并不会自动得到可靠的分布式系统。只要节点要通过网络协作，就会遇到几件单机程序很少同时面对的事：消息可能延迟、丢失、重复或乱序；节点可能独立崩溃和恢复；本地时钟有偏差；某个节点看到的世界可能已经过时。最棘手的是部分失败——系统的一部分仍然正常，另一部分却无法确认。
想象一台服务端十秒没有回应。客户端能确定的事实只有“十秒内没收到回应”。原因可能是服务进程崩溃、机器掉电、交换机故障、链路拥塞、垃圾回收停顿，甚至响应已经发出但回程丢包。超时是一种做决定的阈值，不是证明对端死亡的法术。
客户端—服务器与点对点
客户端—服务器架构把职责集中到提供服务的一侧。浏览器请求 Web 服务、应用访问数据库、工作站挂载网络文件系统，都属于这种模式。集中管理让权限、版本和数据约束更容易统一，但热点和单点故障也会集中。工程上通常增加多个服务副本，再由负载均衡器分发请求；如果服务副本尽量无状态，扩容和故障替换会更简单。
点对点系统让节点同时扮演请求者和提供者。节点加入时能带来容量，数据也可以直接在节点之间传输，但节点发现、信任、数据放置和一致性会更难。很多实际系统是混合结构：中心服务负责身份、目录或协调，数据流则在多个对等节点之间传输。架构名称不是目的，关键是看控制信息和大块数据分别经过哪里，以及哪个组件一旦失效会让系统停下来。
RPC 看起来像函数，故障语义却完全不同
远程过程调用会把参数序列化成消息，发送到远端服务，再把结果还原给调用者。它让接口更易用，却容易制造“远程调用和本地调用差不多”的错觉。本地函数失败时，进程通常能得到明确异常；远程调用超时后，调用者不知道请求是否抵达，也不知道远端是否已经修改状态。
因此，设计 RPC 时要明确超时、重试、退避和幂等性。读取操作通常容易安全重试，扣库存这类写操作则需要请求标识，让服务器识别重复请求。所谓“至多一次”往往依赖去重记录的保存范围；记录过期、服务器换代或跨区域切换后，保证边界也会变化。接口文档如果只写参数和返回值，没有写重试语义，就还缺少最重要的一部分。
负载均衡不只是平均分请求
轮询适合成本相近、连接短的请求；最少连接能照顾长连接差异；一致性哈希有助于让相同键稳定落到少量节点。真正的负载还包括 CPU、内存、磁盘、下游依赖和热点数据，单看请求数可能误判。健康检查也只能说明探测路径上的某个请求成功，不代表整个业务链路都健康。
负载均衡器把故障节点摘除前要等待若干次检查失败，避免暂时抖动导致频繁切换；摘除太慢会继续把用户请求送给坏节点，太快又可能在系统繁忙时把尚能工作的节点集体判死。这里仍然是灵敏度和稳定性的取舍。
把任务拆开后，还要考虑数据在哪里
分布式计算能把大任务拆成许多子任务并行执行，但加速比不会凭空等于节点数量。如果子任务之间频繁交换结果，网络通信和同步会吞掉并行收益；某些阶段必须串行执行时，增加再多节点也绕不过那段串行路径。任务粒度太小，调度和序列化开销甚至会超过真正的计算时间。
数据密集型任务还要考虑数据本地性。与其把几百 GB 数据搬到空闲 CPU，很多系统更愿意把计算调度到持有数据副本的节点或同一机架。这样能减少核心网络流量，却使调度器同时面对 CPU、内存、数据位置与故障恢复多个约束。所谓资源共享也因此不是把所有硬件混成一个均匀水池，而是给计算、存储和专用加速器建立可发现、可授权、可调度的接口。
心跳、租约与故障切换
节点可以周期性发送心跳，让协调者知道它最近仍在运行。连续错过心跳后，协调者把节点标记为不可用，并在其他节点重建副本或接管服务。心跳间隔越短，检测越快，但额外流量和误判概率也越高。
租约把“在某段时间内拥有权利”写成明确规则。主节点只有在租约有效时才能写入；租约到期后，其他节点才有机会接管。这样能减少两个主节点同时写入的风险，但依赖合理的时间边界和隔离手段。旧主节点若与协调服务断开却仍能访问存储，需要使用任期号或隔离令牌，防止它带着过期身份继续修改数据。
副本提升可用性，也制造一致性问题
同一份数据保存多个副本后，一台机器坏了还可以从别处读取，读流量也能分散。但一次写入要怎样传播？同步复制等待足够多副本确认后再成功，能减少已确认数据丢失的概率，却把网络和慢副本时延放进用户请求；异步复制先由一个副本确认，响应更快，但主副本在传播前故障时可能丢掉最近的写入。
读请求同样要决定读谁。只读主副本容易获得清晰顺序，读副本能扩展吞吐，却可能看到旧值。法定人数方案通过读写副本数量的交集降低读到旧值的机会，但还需要版本号、冲突处理和故障恢复，不能只靠一个公式解决全部一致性问题。
网络分区时，CAP 的问题才真正出现
CAP 常被口号化成“一致性、可用性、分区容错性随便选两个”，这很容易误导。分区不是系统想不想要的功能，而是节点之间可能发生的通信故障。当分区真的出现，并且两边都收到涉及同一数据的请求时，系统必须做选择：要么拒绝或等待部分请求，避免双方产生互相矛盾的结果；要么让两边继续响应，接受短时间内状态分叉，等通信恢复后再合并或裁决。
这里的一致性指操作像在单个、最新的副本上按某个顺序发生，可用性指每个到达仍正常节点的请求最终都得到响应。实际系统还要考虑延迟上限、数据丢失窗口和业务冲突能否补偿。账户余额和社交动态可能采用完全不同的取舍，不能只贴一个“CP”或“AP”标签就结束设计。
多副本和心跳支持故障切换，但网络分区出现时仍必须在暂停部分写入与允许潜在冲突之间做选择，恢复后再处理差异。
互动：分区期间的一次写入该怎么办
下面有三个副本。先切断副本乙与其余节点的通信，再分别尝试“等待一致”和“保持响应”两种写入。恢复网络后，你会看到系统为什么还需要版本比较与冲突处理。
分布式文件系统：让远端数据看起来像本地文件
你在终端里对一个挂载目录执行 open、read、write，表面上仍是熟悉的文件接口，数据却可能位于另一台机器，甚至被切成块散落在整个集群。分布式文件系统试图提供访问透明和位置透明：应用不用为每个存储节点编写一套协议，管理员也可以在一定范围内迁移数据而不改路径。
这层透明不能消除物理事实。本地内存访问以纳秒计，网络往返通常要高出许多数量级；远端服务器可能重启，缓存可能过期，两位用户还可能同时修改同一文件。好的分布式文件系统不是假装这些问题不存在，而是在接口语义、缓存策略和故障恢复之间给出一套可预测的规则。
客户端、文件服务与缓存
经典客户端—服务器模型让服务器管理文件数据和元数据，客户端把路径查找、读写、属性查询等操作转成远程请求。客户端缓存能显著减少网络往返，但马上带来一个问题：另一个客户端修改文件后，本地缓存何时失效？每次读取都向服务器验证最稳妥，却会让缓存价值大幅下降；长时间不验证性能更好，却可能读到旧内容。
早期 NFS 版本强调服务器尽量少保留客户端会话状态，请求携带完成操作所需的信息，重复请求也尽可能可安全处理。这样服务器重启后的恢复较直接，但一致性和锁管理受到限制。NFSv4 把打开状态、字节范围锁、租约和委托纳入协议，服务器可以把某些缓存权利暂时委托给客户端；代价是双方必须处理租约续期、状态回收和崩溃后的宽限期。谈 NFS 时必须说明版本，不能一句“无状态”概括全部设计。
AFS 选择了更激进的客户端缓存思路，常按整个文件传输和缓存，并利用服务器的回调承诺通知客户端缓存失效。读多写少的共享文件因此能大幅减轻服务器压力，系统规模更容易扩大。代价是首次取大文件成本更高，多个客户端频繁写同一文件也不适合这种策略。它说明缓存粒度从来不是越小或越大越好，而要匹配工作负载。
元数据与文件数据为什么要分开走
当文件很大、客户端很多时，让一个文件服务器转发全部数据会很快成为瓶颈。集群文件系统常把控制路径和数据路径分开：元数据服务保存目录树、权限、文件到数据块的映射；数据节点保存真正的字节。客户端先向元数据服务询问“这个文件的块在哪里”，拿到位置后直接与数据节点传输。
这样做让元数据服务避免承受大块数据流，增加数据节点也能扩展容量和吞吐。不过，元数据仍可能成为集中热点。目录中存在海量小文件时，每个文件内容不大，元数据操作却很多，系统会先卡在命名空间和内存，而不是磁盘带宽。现代系统会使用元数据高可用、命名空间分片或联邦等办法扩大边界，但这也增加协调复杂度。
GFS 与 HDFS 的设计从工作负载出发
GFS 面向大量机器上的大文件和数据处理任务。它把文件切成较大的块，由主控节点维护元数据，数据块保存在多个块服务器上。客户端从主控节点取得块位置后直接访问块服务器。写入时，租约指定一个主副本协调顺序，多个副本按该顺序应用变更。硬件故障被当成日常事件，系统通过心跳、校验、重新复制和后台恢复维持副本数量。
HDFS 延续了相近的思路：NameNode 管理命名空间与文件到块的映射，DataNode 保存数据块并服务客户端读写。客户端写块时，数据可沿着一条 DataNode 流水线传递，每个节点落盘后再向后转发；读取时尽量选较近的副本，减少跨机架流量。DataNode 周期性发送心跳和块报告，NameNode 据此判断存活状态和安排补副本。
这种架构擅长大文件的流式吞吐，却不是低延迟小文件或任意位置频繁改写的万能答案。大块能减少元数据条目和寻址次数，也会增加小文件浪费和恢复时单块搬运量；多副本提升可靠性，却消耗更多存储与网络；把计算调度到数据附近可以减少搬运，但调度器必须同时考虑资源和数据位置。
元数据服务只提供数据块位置，文件内容由客户端直接与数据节点交换；多副本写入采用串联流水线，完成确认沿相反方向返回。
一次读取与一次写入实际经过哪里
读取文件时，客户端先解析路径并向元数据服务取得块列表和副本位置，然后选择合适的数据节点直接读取。若校验失败或节点超时，可以切换到另一个副本，并把坏副本信息反馈给协调组件。元数据服务负责“在哪里”，数据节点负责“给字节”，两个角色的容量规划也因此不同。
写入更复杂。客户端先申请新块及目标节点，随后把数据送入副本流水线。只有达到规定的确认条件，写操作才向上层报告成功。某个节点中途失败时，流水线要重组，已写部分要根据协议恢复。后台还会扫描副本不足、校验错误和节点退役造成的缺口，重新复制并平衡数据。
“保存了三份”也不等于绝对安全。如果三份都在同一台机器或同一个机架，一次电源或交换机故障就可能同时失去它们。副本放置要理解故障域，在本地读取、跨机架容灾和写入带宽之间折中。更高层仍需要备份与灾难恢复，因为副本会忠实复制误删除和应用写坏的数据。
副本解决硬件失效后的继续访问，备份解决误操作、逻辑损坏和需要回到历史版本的问题。把副本数设为三，不能替代离线备份、快照验证和恢复演练。
操作系统在网络路径上做了什么
网络课程常把协议画成整齐的层，操作系统真正执行时却是一条连续的数据路径。应用调用套接字接口后，内核维护连接状态、发送与接收缓冲区、计时器和路由缓存；协议栈生成首部并把数据交给网卡驱动；网卡通过 DMA 在内存与设备队列间搬运数据，再用中断或轮询提示 CPU 处理完成。接收方向则反过来，内核校验、重组、查找套接字，并唤醒等待数据的线程。
这条路径与前面学过的进程调度、虚拟内存、文件系统和 I/O 管理都连在一起。网络包到达会触发 CPU 工作，缓冲区占用内存，阻塞读会让线程睡眠，零拷贝和发送卸载试图减少数据搬运与上下文切换。连接数很高时，瓶颈可能是端口、文件描述符、队列、锁竞争或内存，而不一定是链路带宽。
用分层顺序定位故障
面对“网页打不开”，最省时间的做法不是立刻重装软件，而是沿着依赖关系缩小范围。
先检查本地链路和地址配置。无线是否已关联，网卡是否有正确地址、前缀和默认网关；同一网络中的其他设备是否也失败。
再区分名字问题和路径问题。域名能否得到预期地址，直接访问已知 IP 时是否仍失败；注意解析成功不代表目标端口可达。
检查传输层现象。连接是被明确拒绝、长时间超时，还是建立后立即重置；三种现象对应的排查方向不同。
最后检查应用协议和服务端依赖。HTTP 状态、TLS 握手、进程日志、线程池、数据库和下游服务都可能让“网络看起来正常但业务失败”。
这套顺序并不保证一次找到答案，却能避免把不同层的错误混为一谈。一个 DNS 缓存问题不该用扩大 TCP 接收窗口解决，服务线程耗尽也不该只靠增加带宽掩盖。
把本章的取舍串起来
网络与分布式系统没有消除资源限制，只是把限制从单机内部延伸到了链路、队列和多个故障域。分层协议用首部和处理开销换来模块化；分组交换用不确定的排队换来链路共享；TCP 用状态、确认和窗口换来可靠字节流；缓存用短暂陈旧换来更低时延；副本用一致性协调和额外存储换来容错；分布式文件系统用复杂的元数据与恢复机制换来统一命名空间和横向扩展。
以后再看到一个“像本地一样简单”的远程接口，可以先问四个问题：请求在网络中可能发生什么，对端执行到哪一步时调用方会超时，重复请求是否安全，系统在分区或副本落后时承诺什么。能回答这四个问题，才算真正理解这个抽象的边界。
章节自测
1
主机要把 IP 数据包发送到不同网段的服务器时，链路层帧的直接目的通常是谁？
2
关于 TCP 的说法，哪些是正确的？
3
CAP 的含义是：系统在任何时候都只能从一致性、可用性和分区容错性中任选两项。
4
在元数据与数据分离的分布式文件系统中，大文件内容通常怎样传输？
想一想：为什么超时不能证明服务器已经崩溃？