浏览器里输入网址后，并不是“直接调用服务器”。域名要先变成 IP，数据要找到下一跳，双方要建立连接并协商加密，HTTP 请求才会进入应用。 架构师首先需要一张端到端地图，因为“接口慢”可能发生在地图上的任何一段。
Table of contents
先运行旅程清单
下载请求旅程样例下载，在实验室运行：
mvn package
java -cp target/classes dev.elaine.network.HttpJourneySample输出的六层不是严格的数据包时序，而是排障时应该逐层询问的问题。
从名字找到目的地
**DNS（域名系统）**把 example.com 解析成 IP 地址。浏览器、操作系统和递归 DNS 都可能缓存结果。DNS 慢时，连接甚至还没开始；
DNS 配错则可能把一部分用户引向旧机房。
如果目标在同一二层网络，主机会用 ARP（IPv4）或邻居发现（IPv6）找到对方网卡地址；如果不在，就寻找默认网关的链路层地址。 交换机转发帧，路由器根据 IP 路由跨网络转发包。
从连接到加密请求
TCP 通过握手建立双向、可靠、有序的字节流。字节流没有“业务消息”边界，接收方必须依靠 HTTP 或自定义协议解析边界。 HTTPS 随后执行 TLS 握手：客户端验证证书中的身份，双方协商密码套件和会话密钥。复用连接和 TLS 会话能省去重复握手，但不能无限复用失效连接。
HTTP 最终发送方法、路径、请求头和正文。HTTP/1.1、HTTP/2、HTTP/3 的传输方式不同，但应用仍应围绕请求语义设计，而不是假设“一请求一连接”。
请求进入服务器后
生产流量通常先经过负载均衡器或反向代理，再进入 Tomcat、Netty 等服务器。请求会经历：
- 接受连接与读取字节；
- TLS 解密和 HTTP 解码；
- 排队等待应用执行资源；
- 执行业务并访问数据库、缓存或远程服务；
- 编码响应并写回网络。
每一层都要有统一的请求标识、截止时间和指标。只统计控制器方法耗时，会漏掉代理排队、连接等待和响应写回。
用分段证据定位故障
先问“时间花在哪一段”，再调参数：DNS 查询耗时、连接与 TLS 握手耗时、首字节时间、服务器排队、应用处理、下游调用和响应传输。 一次抓包只能看到网络事实，线程转储只能看到 JVM 瞬间；日志、指标、追踪和系统观测需要用同一个时间窗口相互印证。
下一步
阅读TCP、UDP、拥塞控制与连接故障，理解可靠字节流为什么仍会超时、重传和断连。