网络安全 02：看懂一次网络与 HTTP 请求

遇到“接口不通”，不要立即归因于防火墙。先分清名字解析、连接建立、协议交互和应用处理。它们处在不同层次，留下的错误也不同。

本篇需要先按实验准备启动 security-up。所有请求都指向本机教学服务。

一、从一个 URL 拆出四层问题

以 http://127.0.0.1:18080/health 为例：

这里直接使用 IP，因此不需要 DNS 查询。Docker 把宿主 18080 转发到容器 8080，这两个端口不必相同。127.0.0.1 在宿主和容器里分别代表各自的回环接口；进入另一个容器以后，它不会自动指向宿主。

IP 负责网络寻址；TCP 提供有序可靠的字节流；HTTP 定义请求、响应及其语义。UDP 是数据报传输，不能简单理解成“没有可靠性的 HTTP”。现代 HTTP 也有基于 QUIC 的实现，因此不要把“HTTP 必然等于 TCP”作为永久规则。MDN HTTP 概览

curl -i http://127.0.0.1:18080/health

关注三部分：状态行中的 200、Content-Type: application/json 等响应头、末尾 JSON 响应体。这个教学服务器可能返回 HTTP/1.0，不能把协议版本差异当作漏洞证据。

再观察请求侧：

curl -v -H 'Accept: application/json' \
  http://127.0.0.1:18080/headers

-v 的连接信息与头部写到标准错误，响应体通常在标准输出。> 标记发送，< 标记接收。-i 是把响应头放进输出；-I 则发出 HEAD 请求，二者不等价。教学服务没有实现 HEAD，使用 -I 可能得到 501。curl 参数文档

在浏览器访问 /health，打开开发者工具的 Network，刷新一次。试着找到请求方法、状态码、响应头和响应体；不要把浏览器额外请求 favicon 的 404 与 /health 的结果混在一起。

curl --noproxy '*' \
  --resolve lesson.test:18080:127.0.0.1 \
  -v http://lesson.test:18080/health

--resolve 只为这一次 curl 提供名字到地址的映射；没有修改系统 DNS 或 hosts。观察连接地址仍是 127.0.0.1，而 HTTP Host 包含 lesson.test:18080。--noproxy '*' 避免本次练习被代理设置转走。

思考：如果服务器按 Host 选择站点，连接到同一个 IP 是否就一定返回同一份内容？这里的实验服务没有虚拟主机路由，但你已经可以区分网络地址和应用主机名。

curl -i http://127.0.0.1:18080/does-not-exist
curl -i http://127.0.0.1:18080/fixed/orders/101

第一条预期 404；第二条预期 401，因为没有提供教学 token。这两次都已成功建立连接并收到 HTTP 响应。

实践中，应用也可能用 404 隐藏无权限资源，因此状态码要结合接口契约和服务日志解释。

HTTPS 在 HTTP 下使用 TLS，主要保护传输中的机密性、完整性以及对端身份验证。它不会替应用检查“用户 A 能不能读取用户 B 的订单”。即便访问控制漏洞位于 HTTPS 接口，漏洞仍然存在。

本实验使用本机明文 HTTP，没有 TLS 服务。向 https://127.0.0.1:18080 发请求失败，并不能证明 TLS 本身不安全。后续证书实验再讨论信任链、主机名匹配和有效期；不要用关闭证书校验来宣称问题已解决。

先回答，再展开。

参考答案