计算机网络基础：从输入网址到收到网页

先跟着一次请求走

打开一个网页时，浏览器需要知道服务器在哪里、怎样建立通信、发送什么请求，以及如何解释返回的数据。网络协议把这些工作拆开，方便不同设备和软件共同协作。

下面先假设缓存没有命中，浏览器使用 HTTPS 和 HTTP/1.1。真实浏览器还会使用连接复用、代理、缓存等机制，流程可能更短。

HTTP/3 使用 QUIC，底层基于 UDP，不能把上面的 TCP 流程套到所有 HTTP 请求上。HTTP 的方法、状态码和请求响应语义可参考 RFC 9110。

学习时可以先使用 TCP/IP 的四层模型。教材中的五层模型会把链路层再拆为数据链路层和物理层；OSI 则有七层，不需要强行把它们逐项对应。

发送数据时，各层逐步加上自己的控制信息；接收时再逐层解析。这样应用程序可以专注请求内容，而不用自己处理网卡上的每一个比特。

IP 地址用于网络层寻址。端口帮助操作系统区分传输层的通信端点，例如 HTTPS 通常使用 443。一个 TCP 连接通常用源 IP、源端口、目标 IP、目标端口来区分。

域名是便于人记忆的名称，DNS 提供名称查询。一个域名可以对应多个 IP，多个域名也可以指向同一个 IP；DNS 不是“每次打开网页都查一遍”，缓存会影响实际查询过程。

MAC 地址主要用于当前链路中的通信。访问远端服务器时，本机发送的以太网帧通常先交给网关；网关转发时会重新处理链路层信息。目标服务器的 MAC 地址不会作为统一标识一路穿过整个互联网。

TCP 提供可靠、有序的字节流，通过序号、确认和重传等机制处理丢失与乱序。字节流没有应用消息边界：两次 send 并不意味着对方恰好进行两次 recv。应用需要用长度、分隔符或协议格式划分消息。这一点在写网络程序时尤其容易踩坑。可参阅 TCP 规范 RFC 9293。

UDP 以数据报为单位发送数据，协议本身不保证交付、顺序或重传。它的额外机制较少，适合应用自行决定怎样应对丢包；但“使用 UDP 就一定更快”不是可靠结论。

建立 TCP 连接的基本过程是 SYN、SYN+ACK、ACK。双方交换初始序号并确认通信状态。正常关闭的两个方向可以分别结束，ACK 与 FIN 有时合并，因此不要把断开连接理解成任何情况下都必须出现四个独立报文。

流量控制关注接收方是否来得及处理；拥塞控制关注网络是否承受得住当前发送速度。这两个问题不能混在一起。

一个最小请求可以写成：

GET /archive/ HTTP/1.1
Host: yellowtt.cn
Accept: text/html

方法表达请求意图，路径定位资源，响应状态码描述处理结果。常见例子是 200 成功、301 永久重定向、404 资源不存在、500 服务器内部错误。

HTTP 的“无状态”指协议的请求语义不要求服务器记住前一个请求。登录状态仍然可以通过 Cookie、会话或令牌实现。HTTPS 在 HTTP 通信之外提供 TLS 保护，但不能自动修复业务逻辑漏洞。

# 查看域名解析结果；需要系统安装 dig
dig yellowtt.cn

# 查看响应头和连接过程
curl -I https://yellowtt.cn/
curl -v https://yellowtt.cn/

# Linux 上查看本机监听的 TCP 端口
ss -lnt

按“域名解析 → 网络与端口 → TLS → HTTP → 应用日志”的顺序观察，通常比直接重启服务更有信息。ping 使用 ICMP，失败不一定代表网站不可访问，成功也不能证明 443 端口或应用正常。

打开浏览器开发者工具的 Network 面板，比较页面文档和图片请求的状态码、协议版本、响应头与耗时。然后回答：域名和 IP 为什么不是一一对应？TCP 为什么需要应用层划分消息？返回 404 时，说明请求已经走到了哪一步？

可以继续读 DNS 的基本概念 RFC 1034，再学习子网划分、路由、HTTP 缓存和抓包分析。