• 第一层：物理层，TCP/IP 里无对应；
• 第二层：数据链路层，对应 TCP/IP 的链接层；
• 第三层：网络层，对应 TCP/IP 的网际层；
• 第四层：传输层，对应 TCP/IP 的传输层；
• 第五、六、七层：统一对应到 TCP/IP 的应用层

总结

• TCP/IP 分为四层，核心是二层的 IP 和三层的 TCP，HTTP 在第四层；
• OSI 分为七层，基本对应 TCP/IP，TCP 在第四层，HTTP 在第七层；
• OSI 可以映射到 TCP/IP，但这期间一、五、六层消失了；
• 日常交流的时候我们通常使用 OSI 模型，用四层、七层等术语；
• HTTP 利用 TCP/IP协议栈逐层打包再拆包，实现了数据传输，但下面的细节并不可见

有一个辨别四层和七层比较好的（但不是绝对的）小窍门，“两个凡是”：凡是由操作系统负责处理的就是四层或四层以下，否则，凡是需要由应用程序（也就是你自己写代码）负责处理的就是七层

原理拆解： 浏览器生成 HTTP 报文后，数据沿协议栈向下传递：传输层把字节流装入 TCP 段并加入端口、序号等信息；网际层再封装为 IP 数据包，写入源和目的地址；链路层最后形成以太网帧并交给物理介质。接收端按相反方向处理，依据以太网类型、IP 协议号和端口逐层分发，最终由应用解析 HTTP。每层只负责自己的寻址、传输或语义职责，因此更换链路介质通常不会改变应用报文。

最小验证： 输入是一段通过明文 HTTP/1.1 连接发送的请求，验证应用层报文只描述请求语义，而连接目标和可靠传输由下层承担。

GET /status HTTP/1.1
Host: example.com
User-Agent: layer-demo/1.0
Accept: application/json
Connection: close

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 15
Connection: close

{"status":"ok"}

关键行 Host 标识应用层目标主机，Content-Type 说明实体格式；报文中没有 TCP 序号、IP 地址或网卡地址，因为这些字段位于更低层。预期应用获得状态码 200 和 JSON 实体。若使用 HTTPS，抓包仍能观察 TCP/IP 或其他承载协议，但普通位置只能看到加密后的 TLS 数据，不能直接读取上述明文。

边界与排查： “操作系统负责就是四层以下”只能帮助快速定位，不能当作严格分界：内核可能参与 TLS 卸载，用户态程序也能自行构造链路层数据包。工程验证可用浏览器网络面板检查 HTTP 语义，用抓包工具查看端口、地址及分段；若域名无法解析，应先检查应用请求之前的 DNS 环节，若握手失败则检查传输层连通性，而不是直接归因于 HTTP。