本篇要回答的问题：从网络应用程序的角度看，互联网世界是怎么划分子系统的？每一层负责什么？我们写互联网软件时，TCP/IP 层和 HTTP 层的编程接口分别长什么样、差别多大？
上一讲讲了 IP 网络的工作原理（封包、寻址、传输）。本讲换到"应用程序视角"——架构第一步是需求分析，之后是概要设计（子系统划分）。我们顺着分层全视图，看清网络应用依赖的庞大基础平台，再落到 HTTP 协议的设计精妙之处和 TCP/IP 与 HTTP 两种编程接口的对比。
网络应用程序的全视图
一个典型网络应用从下到上分五层，每层承接的变化点不同：
| 层 | 名称 | 负责什么 | 类比单机 |
|---|---|---|---|
| 一 | 物理层 | 网络设备原生能力 | —— |
| 二 | 数据链路层 | 局部网络的数据传输（固网/WiFi/4G/5G 层出不穷） | —— |
| 三 | IP 网络层 | 互联网世界的一体化、彼此包容 | 操作系统的核心 |
| 四 | TCP/UDP 传输层 | 让通讯可信赖，降低开发负担 | 与 IP 一起构成"内核" |
| 五 | 应用平台层 | HTTP、SMTP/POP3 等应用层协议 | 应用软件 |
关键判断：IP 网络是互联网"操作系统"的核心，是互联网世界可编程的开始；TCP/IP 这层"操作系统"才真正实现了网络价值的最大化——连接一切。
主流应用层协议对比：
| 协议 | 应用场景 | 现状 |
|---|---|---|
| HTTP | 万维网（WWW），承载 RESTful API、gRPC | 已演化为通用传输协议，甚至有 HTTP DNS |
| SMTP/POP3 | 电子邮件 | 借用少，但因 Email 的开放性连接了世界每个人和企业 |
| FTP/NFS/Telnet | 文件/远程登录 | 范围小，部分被 HTTP 替代 |
洞见：微信连接了几乎所有中国人，但相比电子邮件仍是小巫见大巫——因为开放的力量。“用微信的方式打败微信很难，但微信是封闭协议，开放也许是机会。”
应用层协议与网关
NAT 网关是工作在传输层（第四层）的透明代理；若限定数据包是某种应用层协议，就出现了应用层网关（七层网关），如 Nginx、Apache，通常处理 HTTP/HTTPS。
HTTP 请求/回复格式：协议头 + 空行 + 正文。请求行三部分（命令 / 资源路径 / 版本），回复行三部分（版本 / 状态码 / 状态文本）。
| 操作 | 命令 | 业务语义 |
|---|---|---|
| 读取 | GET | 获取资源 |
| 创建 | PUT（或 POST） | 新建资源，需授权 |
| 修改 | POST | 改资源，需授权 |
| 删除 | DELETE | 删资源，需授权 |
HTTP 协议好在哪？关键在协议头设计：
| 优点 | 表现 |
|---|---|
| 极其开放的协议头 | 用户可加自定义字段，惯例以 X- 开头（如七牛 X-Reqid） |
| 规范了业务表达范式 | 用"资源路径"表达资源，PUT-POST-GET-DELETE 表达 CURD |
| 规范了应用层路由 | 强制的 Host 字段以域名表征目标主机，"域名 + 资源路径"是更好的路由依据 |
关键洞见：正因为这些好处，HTTP 逐渐成为网络应用层协议的模板——无论业务如何，都能基于它表达自己的业务逻辑。
TCP/IP 层 vs. HTTP 层编程接口
网络的可编程性从 IP 协议开始。三种协议的编程接口对比：
| 维度 | IP | UDP | TCP |
|---|---|---|---|
| 连接 | 无连接 | 无连接 | 基于连接 |
| 地址 | IPAddr（IP+Zone） | UDPAddr（多了 Port） | TCPAddr（IP+Port+Zone） |
| 可靠性 | 不保证到达/次序 | 不保证，开销极小 | 解决丢包重传、纠正乱序 |
| 适用 | 几乎不直接用 | 音视频（宁可丢帧） | 通用可靠传输 |
洞见：IP 和 UDP 区别极小（UDP 只多了端口），所以很少有应用直接基于 IP 编程；而 TCP 的可靠性对音视频反而是坏特性——重传会加剧网络拥塞。
端口（port）：解决软件间冲突，ip:port 唯一定位通讯地址；最初设计意图是区分应用层协议（80=HTTP，25=SMTP），客观上也缓解了 IPv4 地址紧张。
服务端编程差异：TCP 每 Accept 一个连接可起独立 goroutine 处理；UDP 无连接，需手工按来源 IP+port 分派。
而 HTTP 层编程则简便得多——客户端直接 Get/Post；服务端靠 ServeMux 完成基于"资源路径"的路由：
mux := http.NewServeMux()
mux.HandleFunc("/abc/example", handleAbcExampe)
http.ListenAndServe(addServer, mux)
关键判断：基于 HTTP 与基于 TCP/IP 裸写业务，复杂程度不可同日而语——前者程序架子已成型，只需填业务逻辑。这就是采纳成熟应用层协议的威力。如无特殊理由，架构师应优先选 HTTP。
总结
本讲给出网络应用的分层全视图：物理层→链路层→IP 层→传输层→应用平台层，逐层承接不同变化点，IP+TCP 是互联网的"操作系统内核"。HTTP 凭借开放协议头、规范业务范式、规范应用层路由三大优点成为应用协议模板。编程接口上，TCP/IP 裸写繁琐，HTTP 简便高效。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 互联网"操作系统" | IP 网络层 + TCP/UDP 传输层构成的内核 |
| 应用层网关 | 工作在第七层、处理 HTTP 的代理（Nginx/Apache） |
| HTTP 协议头 | 开放可扩展、规范 CURD、以 Host 做路由 |
| 端口 port | ip:port 唯一定位软件通讯地址 |
| ServeMux | HTTP 服务端基于资源路径的路由器 |
一句话速记
IP+TCP 是互联网的操作系统内核，HTTP 是应用协议的模板——能用 HTTP 就别裸写 TCP，架子现成只填业务。
几条值得记住的判断
- 不要轻易创造新协议，优先选 HTTP 这样成熟的应用层协议。
- UDP ≈ IP + 端口，TCP 才解决可靠性，但可靠性对音视频是坏事。
- 开放是封闭协议的天敌——Email 连接世界靠的就是开放。
思考题
你做业务架构时，是选择自定义网络协议、基于 gRPC，还是基于 HTTP 提供 RESTful API？回到你手上的项目：你为某个内部服务"省事"地自造了一套协议吗？如果改用 HTTP，会失去什么、又能省下多少基础设施（网关、日志、链路追踪）的重复建设？
