DevOps 先决条件：你必须理解的“Boring”基础

Source: Dev.to

DevOps Day 0

• 网络默认是不可靠的
  数据包可能会 丢失、延迟、重复或乱序。
  可靠性是协议 添加 的，而不是网络保证的。

  这一核心理念解释了：

  • 重试
  • 超时
  • 迟缓
  • “随机”故障

• IP 地址标识机器

  • 网络中的每个设备都需要一个 唯一的 IP。
  • IP = 机器的身份。
  • 私有 IP 用于 内部。
  • 公网 IP 用于 互联网。
  • 路由器使用 NAT 将多个私有 IP 映射到一个公网 IP。
  • 如果两台机器 共享同一个 IP → 通信会中断。

• 端口标识服务

  • 一台机器可以运行多个服务。
  • 每个服务监听一个 端口。
  • 同一时间 每个端口只能有一个服务。

  定位一个服务意味着：

  IP + Port

  示例：

  192.168.1.10:443

• 通信需要三件事
  要让一台机器与另一台机器通信，需要：

  1. 正确的 IP（机器）
  2. 正确的 端口（服务）
  3. 打开的 网络路径（路由 + 防火墙）

  任意一项失败 → 无法通信。

TCP vs UDP（两种可靠性策略）

UDP

• 快速
• 不保证交付
• 不重试
• 不保证顺序
• 开销低

使用场景： 速度比准确性更重要，重试成本低。
示例： DNS、视频流、指标采集。

TCP

• 可靠
• 保证交付
• 有序数据
• 对丢失的数据包进行重试
• 由于开销较大，速度相对慢

使用场景： 正确性至关重要。
示例： HTTP/HTTPS、数据库、API、SSH。

实际系统中的故障表现

UDP 故障

• 数据缺失
• 不稳定行为
• 快速失败

TCP 故障

• 延迟增加
• 请求挂起
• 静默变慢

UDP 快速失败，TCP 缓慢失败。

DNS 默认使用 UDP

DNS 选择 UDP 的原因是：

• 请求体积小
• 建立连接成本高
• 重试比等待更便宜

当需要（大响应、DNSSEC）时，DNS 可以回退到 TCP。

三种可能的连接结果（关键）

连接到 IP:PORT 时：

• ✅ 成功

  • 服务已启动
  • 网络路径通畅

• ❌ 连接被拒绝

  • 机器可达
  • 该端口没有服务在监听 → 应用/端口问题

• ⏳ 连接超时

  • 服务不可达
  • 数据包被阻塞或丢失 → 网络/防火墙问题

监听范围很重要

服务的监听地址可以是：

• localhost → 仅本机可访问
• 0.0.0.0 → 任意位置均可访问

这就是经典的 “在我机器上能跑” 问题的根源。

核心 Day 0 思维模型（记住它）

• IP = 谁
• 端口 = 什么
• 协议 = 怎么做
• 防火墙 = 是否允许
• DNS = 便利性

只要能在这些维度上进行推理，就能排查大多数故障。