一、先说结论

这一篇主要回答：

1. 服务发现、DNS、注册中心三者有什么关系？

如果先把主线压缩成几句话，可以这样记：

• 三者本质上都在解决“请求该发给谁”这个问题
• 服务发现是更大的机制概念
• DNS 和注册中心是实现服务发现的两种常见手段
• DNS 更适合域名到 IP 的基础解析，注册中心更适合微服务实例的动态发现与治理

这里整理的是更偏工程落地、线上排障和协议选型的网络场景题。

如果前面的 应用层、传输层、网络层 更偏基础原理，那么这一组内容更偏：

• 为什么系统会这样设计
• 为什么线上会出现这些现象
• 出了问题该怎么定位

后续文章会重点覆盖：

• 服务调用链路为什么大多基于 TCP
• 连接池、线程池、长连接为什么重要
• 接口超时和性能问题怎么拆链路定位
• 反向代理、真实 IP、Session 一致性、Token 分布式适配等

一、先说结论

这一篇主要回答：

1. Nginx 反向代理后，客户端真实 IP 怎么拿？
2. 为什么不能无脑相信 X-Forwarded-For？

如果先把答案压缩成几句话，可以这样记：

• 反向代理后，后端服务直接看到的通常是 Nginx 的 IP
• 真实客户端 IP 一般要靠代理转发的请求头传递，比如 X-Forwarded-For 和 X-Real-IP
• 只有在请求确实经过受信任代理时，才能把这些头当作真实来源来信任

一、先说结论

这一篇主要回答三个经常一起出现的工程问题：

1. 为什么数据库连接、RPC、HTTP 调用大多基于 TCP，而不是 UDP？
2. RPC 为什么有的基于 HTTP，有的基于 TCP？
3. 项目里为什么要用连接池、线程池、长连接？

如果先把主线压缩成几句话，可以这样记：

• 数据库、RPC、HTTP 这类调用，更重视数据完整、可靠、有序地到达
• 所以它们更依赖可靠传输能力，而 TCP 是最成熟、最常见的方案
• 基于 HTTP 的 RPC 更重生态兼容性，基于 TCP 的 RPC 更重性能和协议控制力
• 连接池、线程池、长连接本质上都是“昂贵资源不要反复新建”