虽然大多数业务项目会直接使用框架，但如果不理解 Node.js 原生的网络能力，就很难真正理解请求生命周期、连接复用和协议差异。这一篇会从 HTTP 起步，再逐步拉到 TCP 和 UDP 的视角。
为什么要先理解原生 HTTP？
很多人做服务端时会直接上框架，这本身没有问题。但框架只是帮你把很多重复工作包装好了，并没有改变底层通信的本质。请求是怎么到来的、响应是怎么写回去的、连接如何被建立和关闭，这些基础认知仍然存在。
理解原生 HTTP 的意义，不是让你以后都手写服务器，而是让你知道框架到底帮你抽象掉了哪些细节。只有这样，后面你在处理中间件、流式响应、文件下载或代理转发时，才不会完全失去底层感觉。
HTTP 与 HTTPS：服务端通信的最小模型
从 Node.js 视角看，HTTP 最核心的事情其实很朴素：
- 接收请求；
- 读取请求信息；
- 根据路径、方法和内容决定处理逻辑；
- 最终把响应写回去。
HTTPS 则是在这个基础上增加了安全传输层。你可以先把它理解成：HTTP 负责应用层协议语义，HTTPS 则让这层通信在网络传输过程中更安全可靠。
这意味着，当你做 Node 服务端时，不应该只关心“路径对不对”，还要有协议层意识：请求和响应本来就是网络通信，而不是框架内部对象的魔法变形。
Node.js 里的 fetch 和浏览器里一样吗？
现代 Node.js 也提供了 fetch 能力，这让服务端发请求的体验和浏览器看起来更接近了。但“看起来相似”不代表它们语境完全一样。
在浏览器里，fetch 更多是页面逻辑访问远程资源；在 Node.js 中，它经常承担的是：
- 服务端调用其他服务；
- API 聚合；
- 后台任务请求第三方接口；
- 内部脚本拉取远程数据。
这意味着，Node 中的 fetch 往往更强调：
- 超时和重试策略；
- 服务间调用失败如何处理；
- 请求头、认证信息和代理环境；
- 返回结果如何和本地业务逻辑协作。
也就是说，服务端 fetch 更接近系统协作，而不是页面交互。
TCP、UDP 和 HTTP 之间是什么关系？
很多初学者第一次接触这些概念时，容易把它们都当成“网络协议”混在一起记。但它们不在同一层。
一个更稳妥的理解方式是：
- TCP 和 UDP 更偏传输层；
- HTTP 更偏应用层；
- HTTPS 则是在 HTTP 之上叠加安全传输能力。
你并不需要一开始就把网络分层体系背得滚瓜烂熟，但至少要知道：HTTP 并不是凭空存在的，它依赖底层传输协议把请求和响应送来送去。
理解这一点的价值在于，当你后面遇到连接问题、超时问题、长连接问题时，就不会只从“接口没返回”这一层去想。
总结
这一篇我们先把 Node.js 网络世界的最小地图搭起来了：原生 HTTP 服务说明了请求和响应的基本形态，HTTPS 提醒你安全传输是协议的一部分，fetch 把服务端请求协作纳入视野，而 TCP 与 UDP 则帮助你建立更底层的分层认知。
网络这一层真正重要的，不是把所有协议细节一次背完，而是知道 Node.js 服务端本质上就是在持续处理网络通信。
下一篇我们会回到运行时并发能力，继续看多进程、多线程和子进程分别该怎么理解和选择。