排查 on 方糖猫Blog

☸️ Kubernetes 学习总结与避坑指南

Wed, 12 Feb 2025 10:00:00 +0800

☸️ Kubernetes 学习总结与避坑指南

参考书籍：龚正等《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触》、Marko Lukša《Kubernetes in Action》目标读者：会一点 Docker、刚接触 K8s，或者「YAML 会抄但一出问题就懵」的同学。

Kubernetes（简称 K8s，因为 K 和 s 之间有 8 个字母）是 Google 开源的容器编排系统，解决了「成百上千个容器跑在成百上千台机器上，谁来调度、谁来扩容、挂了谁来拉起」的问题。它不是一门「背完概念就会」的技术——新人最常见的状态是：每个名词都听过，但它们之间怎么串起来的说不清楚，Pod 一挂就不知道该看哪里。

这篇文章帮你建立主干知识框架：

K8s 集群整体长什么样？Master 和 Node 各自干什么？
Pod、Node、Service、Ingress、ConfigMap 这些核心对象到底是什么关系？
Istio 服务网格在解决什么问题？
共享存储（PV/PVC/NAS）怎么用，有哪些坑？
排查 K8s 问题需要补哪些 Unix 网络编程基础知识？
生产环境如何做内外网访问隔离（私网端点 / 内网 LB / NetworkPolicy）？
在阿里云 ACK（以及 AWS EKS）上落地时要注意什么？
Jenkins 如何与 K8s 打通，实现自动化部署、验证与失败回滚？
遇到 CrashLoopBackOff、OOMKilled、502、DNS 慢这些经典问题，该按什么思路排查？

一、K8s 整体架构：一个「中心化大脑 + 一群干活的节点」

K8s 集群在逻辑上分为两大部分：

控制平面（Control Plane，俗称 Master）：集群的大脑，负责「决策」——调度、扩缩容、故障自愈。
工作节点（Node）：真正跑容器的机器，负责「执行」。

graph TB
    subgraph 控制平面["控制平面 Control Plane（阿里云 ACK 托管，用户不可见）"]
        APIServer[kube-apiserver<br/>集群唯一入口，所有操作都经过它]
        ETCD[(etcd<br/>分布式 KV 存储<br/>集群所有状态都在这里)]
        Scheduler[kube-scheduler<br/>决定 Pod 调度到哪个 Node]
        CM[kube-controller-manager<br/>各种控制器：副本数维持、节点监控等]
        CCM[cloud-controller-manager<br/>对接云厂商：SLB/EBS/路由]
    end

    subgraph 节点1["Worker Node 1"]
        K1[kubelet<br/>节点上的「包工头」]
        P1[kube-proxy<br/>维护 Service 网络规则]
        C1[容器运行时<br/>containerd]
        Pod1[Pod A] ~~~ Pod2[Pod B]
    end

    subgraph 节点2["Worker Node 2"]
        K2[kubelet]
        P2[kube-proxy]
        C2[containerd]
        Pod3[Pod C]
    end

    APIServer --> ETCD
    Scheduler --> APIServer
    CM --> APIServer
    CCM --> APIServer
    K1 --> APIServer
    K2 --> APIServer
    User[kubectl / CI/CD] --> APIServer

记住这条主线：所有组件只跟 apiserver 说话，apiserver 把状态写进 etcd。你敲的每一条 kubectl 命令、每一个控制器的决策，都是「读/写 apiserver」这个动作。理解了这一点，后面所有概念都好串了。

K8s 的核心设计思想是声明式 API + 控制器循环：

graph LR
    A[你提交 YAML<br/>期望状态：3 个副本] --> B[apiserver 存进 etcd]
    B --> C{控制器不断对比<br/>期望状态 vs 实际状态}
    C -->|实际只有 2 个| D[再创建 1 个 Pod]
    D --> C
    C -->|一致| E[什么都不做]

这就是「自愈」的本质：不是有人盯着修，而是控制器永远在循环纠偏。所以 K8s 里的对象是「期望状态」的描述，不是一条条命令。

二、Node：干活的机器

2.1 Node 上有什么

每个 Node 上必装三个组件：

kubelet：节点代理。接收 apiserver 下发的 Pod 定义（PodSpec），调用容器运行时把容器拉起来，并持续上报节点和 Pod 状态。Pod 挂了重启、探针检测，都是 kubelet 干的。
容器运行时：真正拉镜像、跑容器的软件。Docker 已在 K8s 1.24 后被移除，现在主流是 containerd。
kube-proxy：维护节点上的网络规则（iptables/IPVS），让 Service 的虚拟 IP 能转发到真实 Pod。

2.2 节点相关的避坑点

节点 NotReady：最常见的原因是 kubelet 挂了、节点磁盘满（DiskPressure）、内存不足（MemoryPressure）或网络不通。排查顺序：先 kubectl describe node <名字> 看 Conditions，再登节点看 systemctl status kubelet 和日志 journalctl -u kubelet。
磁盘压力：容器日志、镜像、emptyDir 都在吃节点磁盘。务必给应用日志配轮转（logrotate 或运行时自带的日志上限 containerLogMaxSize），否则磁盘写满会把节点上所有 Pod 驱逐（Evicted）。
不要随意登节点手工改东西：K8s 期望节点是「牛」不是「宠物」——可替换、不特殊。手工装的 Agent、改的 iptables 规则，节点一重建全没了。需要节点级能力请用 DaemonSet。

三、Pod：K8s 的最小调度单元

3.1 为什么不是直接调度容器

Pod 是一组共享网络和存储的容器集合。同一个 Pod 里的容器：

共享同一个 IP 和端口空间（通过 localhost 直接互通）
可以共享 Volume

graph TB
    subgraph Pod["Pod（10.0.1.15）"]
        direction LR
        C1[主容器<br/>app:8080]
        C2[边车容器<br/>日志采集]
        V[(共享 Volume<br/>日志目录)]
        C1 --> V
        C2 --> V
    end
    C1 -.->|localhost:8080| C2

这个设计的经典用途就是 Sidecar（边车）模式：日志采集、流量代理（Istio 的 Envoy）都以边车容器形式注入 Pod，主容器无感知。

新人直觉「一个 Pod 跑一个容器」，这对 90% 的场景是对的。只有容器之间必须同生共死、共享 localhost 或共享文件时，才放进同一个 Pod。

3.2 Pod 生命周期与探针

stateDiagram-v2
    [*] --> Pending: 创建，等调度/拉镜像
    Pending --> Running: 调度成功，容器启动
    Running --> Succeeded: 正常退出（Job 类）
    Running --> Failed: 异常退出
    Running --> Running: 探针失败→kubelet 重启容器

三个探针，新人人手必配：

探针	作用	配错的后果
`livenessProbe`	判断容器是否活着，失败则重启容器	太灵敏 → 无限重启循环
`readinessProbe`	判断是否能接流量，失败则从 Service 摘除	不配 → 启动期请求打到没 ready 的 Pod，报 502
`startupProbe`	启动探针，成功前禁用另外两个	慢启动应用（如老 Java 服务）不配 → 被 liveness 误杀

3.3 资源 requests/limits 与 QoS：最容易被忽视的重灾区

resources:
  requests:        # 调度依据：保证分到这么多
    cpu: "250m"    # 0.25 核
    memory: "512Mi"
  limits:          # 使用上限
    cpu: "500m"
    memory: "1Gi"

requests 是调度的唯一依据：节点剩余可分配资源 ≥ Pod 的 requests 总和，Pod 才调度得上去。不配 requests，调度就是瞎排，节点超载。
CPU 超 limit → 被限流（throttle），容器变慢但不死；内存超 limit → OOMKilled，直接杀。这是两种完全不同的失败模式，排查时先分清。
QoS 等级：requests=limits 为 Guaranteed（最后被驱逐）；都不配为 BestEffort（节点资源紧张时最先被杀）。生产核心服务至少配 Burstable。

四、工作负载：不要直接创建裸 Pod

实际工作中你几乎不会手写 Pod，而是使用「管理 Pod 的控制器」：

对象	适用场景	一句话
Deployment	无状态服务（Web/API）	副本数 + 滚动更新 + 回滚
StatefulSet	有状态服务（MySQL/Kafka）	稳定的名字和网络标识、按序启停
DaemonSet	节点级 Agent（日志/监控）	每个 Node 跑一个
Job / CronJob	一次性/定时任务	跑完即退

Deployment 滚动更新过程：

sequenceDiagram
    participant U as 用户
    participant D as Deployment
    participant RS1 as ReplicaSet v1
    participant RS2 as ReplicaSet v2

    U->>D: kubectl set image 更新镜像
    D->>RS2: 创建新 RS，先拉起 1 个新 Pod
    RS2-->>D: 新 Pod ready
    D->>RS1: 缩掉 1 个旧 Pod
    Note over D,RS2: 循环：新 +1 → 旧 -1
    D->>RS1: 缩到 0（旧 RS 保留，可回滚）
    U->>D: kubectl rollout undo（随时回滚）

避坑点：

maxSurge / maxUnavailable 控制滚动节奏。默认 25%/25%，意味着更新中可能瞬间少 25% 的可用副本——容量紧张的服务要调小 maxUnavailable。
回滚靠旧 ReplicaSet 保留的 Pod 模板，revisionHistoryLimit 默认 10，别设成 0 否则无法回滚。
镜像 tag 不要用 latest：无法回滚、无法审计，且 imagePullPolicy 行为反直觉。用 git commit 号或语义化版本。

五、K8s 网络模型与必备的 Unix 网络编程知识

K8s 的网络问题占了线上故障的一半以上。而很多「K8s 网络问题」本质上是 Unix 网络编程/TCP 协议问题，只是发生在容器环境里。这一节把两边打通。

5.1 K8s 网络的三条铁律

K8s 对网络模型只有三个基本要求（具体实现交给 CNI 插件，如 Flannel、Calico、阿里云 Terway）：

每个 Pod 有自己的独立 IP
任意两个 Pod 之间可以直接通信（不经过 NAT）
Node 和 Pod 之间可以直接通信

graph LR
    subgraph 节点A["Node A"]
        PA["Pod A<br/>10.244.1.5"]
    end
    subgraph 节点B["Node B"]
        PB["Pod B<br/>10.244.2.8"]
    end
    PA <-->|"Pod 网络（CNI：Terway/Flannel/Calico）<br/>直连，无 NAT"| PB

5.2 Service：一组 Pod 的稳定入口

Pod 会漂移（重建后 IP 就变了），所以不能在代码里写死 Pod IP。Service 提供一个固定虚拟 IP（ClusterIP）+ DNS 名字，负载均衡到后端 Pod。

graph LR
    Client[客户端 Pod] -->|"访问 my-svc:80<br/>DNS 解析为 10.96.0.10"| SVC["Service: my-svc<br/>ClusterIP 10.96.0.10"]
    SVC -->|kube-proxy 的 iptables/IPVS 规则转发| P1[Pod 1]
    SVC --> P2[Pod 2]
    SVC --> P3[Pod 3]

三种 Service 类型：

ClusterIP（默认）：仅集群内可达
NodePort：在每个节点开一个高端口（30000-32767），可从集群外访问
LoadBalancer：对接云厂商负载均衡器（阿里云 CLB/SLB、AWS NLB/ALB），对外暴露的标准姿势

5.3 为什么排查 K8s 网络要懂 Unix 网络编程

下面这几组知识，是在 K8s 环境里排查连接问题的「元技能」：

（1）TCP 连接状态与 TIME_WAIT

TCP 挥手后主动关闭方会进入 TIME_WAIT 状态，默认保持 2MSL（Linux 上约 60s）。在高并发短连接场景（比如服务间大量 HTTP/1.0 式短调用），客户端端口会被 TIME_WAIT 大量占用，最终 Cannot assign requested address。

stateDiagram-v2
    ESTABLISHED --> FIN_WAIT1: 主动方 close()
    FIN_WAIT1 --> FIN_WAIT2: 收到对端 ACK
    FIN_WAIT2 --> TIME_WAIT: 收到对端 FIN
    TIME_WAIT --> CLOSED: 2MSL 超时（约60s）
    ESTABLISHED --> CLOSE_WAIT: 对端先 close()
    CLOSE_WAIT --> LAST_ACK: 我方 close()
    LAST_ACK --> CLOSED

K8s 里的对应症状与解法：

症状：服务间调用偶发超时，ss -s 看到 timewait 几万。
正解：应用层用长连接 + 连接池（HTTP keep-alive、gRPC），别依赖 net.ipv4.tcp_tw_reuse 这类内核参数硬扛。
另一个常见坑是 CLOSE_WAIT 堆积：对端关了连接但你的代码没 close()（连接泄漏），ss -ant | grep CLOSE_WAIT 一查便知。

（2）socket、backlog 与「连接被 Reset」

服务端 listen(fd, backlog) 的 backlog 是「已完成三次握手但应用还没 accept」的队列长度。K8s 场景下突发流量打到刚重启的 Pod，如果应用 backlog 太小（或迟迟不 accept），内核会直接 RST，客户端看到的是 Connection reset by peer。这类问题在 Pod 扩容瞬间、探针刚通过时高发——readinessProbe 通过 ≠ 应用真的能扛流量。

（3）epoll 与 I/O 多路复用

一个进程通过 epoll 可以管理数万连接（C10K 问题的解法）。Nginx Ingress、Envoy 都是 epoll 模型。要懂的点：

进程能开的连接数受 文件描述符上限限制：ulimit -n。容器里同样生效，高并发服务记得确认 limit（cat /proc/<pid>/limits）。
每个 TCP 连接 = 一个四元组（源IP:源端口 → 目标IP:目标端口）。客户端对单一目标的并发连接数理论上受源端口数（约 2.8 万个可用）限制——这又回到「必须用连接池复用连接」。

（4）conntrack：K8s 特有的网络坑

kube-proxy 的 iptables 模式依赖内核 conntrack（连接跟踪表）。节点上连接数巨大时 conntrack 表被打满（默认 nf_conntrack_max 往往不够），表现为新建连接随机丢包、无日志，极难排查。解法：调大 net.netfilter.nf_conntrack_max，或干脆把 kube-proxy 切到 IPVS 模式。阿里云 ACK 的 Terway 模式在这方面压力小很多。

（5）DNS：K8s 里的「隐形依赖」

集群内所有服务名解析都靠 CoreDNS。两个经典坑：

glibc 的 DNS 解析是串行的，且默认 ndots:5 导致集群内短域名先查 5 次后缀。症状：应用偶发解析慢 5s（一次超时重传）。解法：FQDN 写法 my-svc.my-ns.svc.cluster.local.（结尾加点）或调整 Pod 的 dnsConfig。
Java 应用默认永久缓存 DNS 结果（networkaddress.cache.ttl=-1），Service 后端 IP 变了 JVM 不知道。容器里务必显式设置 DNS 缓存 TTL（如 30s）。

5.4 内外网访问隔离：哪些服务能暴露，哪些必须藏住

生产集群的基本安全原则：默认所有东西都不出集群，只开必要的口子。K8s 默认网络是「全通」的（任何 Pod 可以访问任何 Pod，LoadBalancer 一不小心就开到公网），隔离要靠自己显式配置。隔离分三个层面，从外到内：

graph TB
    Internet[公网用户] -->|只放行 443| WAF[WAF / 安全组<br/>云平台层]
    WAF --> PubLB[公网 ALB/CLB<br/>仅 Web 入口服务]
    PubLB --> PubIng[Ingress Controller<br/>公网命名空间]
    PubIng --> WebSvc[Web Service<br/>ClusterIP]

    Office[办公网/运维] -->|VPN/跳板机| IntLB[内网 LoadBalancer<br/>intranet 类型]
    IntLB --> AdminSvc[管理后台 / 监控<br/>Grafana / Jenkins]

    subgraph 集群内["集群内部（东西向流量）"]
        WebSvc -->|NetworkPolicy 允许| AppSvc[业务 Service]
        AppSvc -->|NetworkPolicy 允许| DBSvc[数据库 Proxy Service]
        AppSvc -.->|NetworkPolicy 拒绝| Other[其他 namespace]
    end

第一层：云网络边界（VPC / 安全组）

API Server 用私网端点：阿里云 ACK 创建集群时选择「专有网络（私网）」API Server 访问，或只绑定内网 EIP，运维通过 VPN/跳板机访问；公网端点即便有证书认证也是攻击面。AWS EKS 对应 endpoint private access。
节点安全组收紧入方向：只放行 NodePort 范围给内网、放行 LB 健康检查来源，其余一律拒绝。ACK 的节点安全组默认规则要审一遍。
数据库、Redis 这类云产品走 VPC 内网地址，安全组只对集群节点网段开放。

第二层：Service 暴露方式——内外网分流的关键

LoadBalancer 类型 Service 默认创建的是公网 LB，这是最常见的「误暴露」事故。面向内部的服务要用注解显式声明内网 LB：

# 阿里云：内网 CLB（VPC 内可达，公网不可达）
apiVersion: v1
kind: Service
metadata:
  name: internal-admin
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
spec:
  type: LoadBalancer
  ports:
    - port: 80

AWS EKS 对应注解：service.beta.kubernetes.io/aws-load-balancer-internal: "true"（NLB）或 aws-load-balancer-scheme: internal（ALB Controller）。

经验法则：

对外服务：公网 ALB/CLB + Ingress，前面最好再挂 WAF。
对内服务（管理后台、监控、Jenkins）：内网 LB 或纯 ClusterIP，配合 VPN/跳板机访问。
默认用 ClusterIP，需要出集群时再显式升级类型——把「暴露」当成一个需要评审的动作。
Ingress 上还可以用注解做来源 IP 白名单（如 nginx.ingress.kubernetes.io/whitelist-source-range: 10.0.0.0/8），给内部接口再加一道闸。

第三层：NetworkPolicy——集群内部的东西向隔离

即使流量不出集群，「测试 namespace 的 Pod 误连生产数据库」这类事故也常见。NetworkPolicy 是 Pod 级的防火墙（需要 CNI 支持，ACK 的 Terway、Calico 都支持，Flannel 不支持）：

# 第一步：namespace 默认全拒（白名单模式的起点）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: prod
spec:
  podSelector: {}          # 选中 namespace 内所有 Pod
  policyTypes: ["Ingress", "Egress"]
---
# 第二步：只放行需要的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-app
  namespace: prod
spec:
  podSelector:
    matchLabels: {app: order-svc}
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels: {app: web-frontend}
      ports:
        - port: 8080

避坑点：

NetworkPolicy 是白名单累加模型：任何一条 policy 选中某 Pod，该 Pod 未被放行的方向就被默认拒绝。写漏了 DNS（Egress 到 kube-dns 的 53 端口）会导致全 namespace 解析失败——默认拒绝后记得显式放行 DNS。
策略只对选中后新建立的连接生效，且 Flannel 下写了也不生效（静默失效，最坑的一种）。
云安全组管的是「节点/LB 维度」，NetworkPolicy 管的是「Pod 维度」，两者互补不替代。
上了 Istio 的话，还可以用 AuthorizationPolicy 做带身份（mTLS 服务身份）的七层鉴权，比纯 IP/端口的 NetworkPolicy 更细。

六、Ingress：HTTP 流量的统一入口

Service 解决的是四层（TCP）负载均衡；Ingress 解决的是七层（HTTP/HTTPS）路由：按域名、按路径把外部流量分发到不同 Service。

graph TB
    User[外部用户] -->|HTTPS| LB[云负载均衡<br/>阿里云 ALB/CLB]
    LB --> IC[Ingress Controller<br/>Nginx / ALB Ingress]
    IC -->|"a.example.com/api/*"| S1[Service: api]
    IC -->|"a.example.com/web/*"| S2[Service: web]
    IC -->|"b.example.com/*"| S3[Service: admin]
    S1 --> P1[api Pod]
    S2 --> P2[web Pod]
    S3 --> P3[admin Pod]

注意分清两层：

Ingress 资源（YAML 对象）：只是路由规则的声明，本身不做任何事。
Ingress Controller（真正干活的组件）：如 ingress-nginx、阿里云 ALB Ingress Controller。它 watch Ingress 资源，把规则翻译成 Nginx 配置并热加载。

避坑点：

pathType: Prefix 和 Exact 的区别，/api 配 Prefix 会把 /apiserver 也匹配进去。
后端重写（rewrite-target）是最容易写错的注解，先想清楚「客户端路径 → 后端真实路径」的映射。
HTTPS 证书放在 Secret 里，过期忘续是经典事故——建议上 cert-manager 自动签发续期。
502 的第一排查动作：看 Ingress Controller 日志里 upstream 是「连接拒绝」（Pod 没 ready）还是「超时」（应用卡死）。

七、ConfigMap 与 Secret：配置和代码分离

十二要素应用的第一条就是「配置存环境」。K8s 里对应两个对象：

ConfigMap：普通配置（应用参数、配置文件、特性开关）
Secret：敏感配置（密码、密钥、证书），etcd 中 Base64 编码（注意：Base64 不是加密，生产环境要开 etcd 静态加密或对接 KMS）

两种注入方式：

# 方式一：环境变量
env:
  - name: DB_HOST
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: db_host

# 方式二：挂载为文件（推荐，支持热更新）
volumeMounts:
  - name: config
    mountPath: /etc/app
volumes:
  - name: config
    configMap:
      name: app-config

两个必踩的坑，提前告诉你：

环境变量注入的配置，改了 ConfigMap 不会生效，必须重启 Pod。文件挂载方式会自动更新（kubelet 定期同步，有分钟级延迟），但应用要支持 reload。
subPath 挂载的 ConfigMap 不会自动更新。这是用了 subPath 挂单个配置文件的同学必踩的坑——改完 ConfigMap 发现容器里还是旧的。解法：挂载整个目录，或接受重启 Pod 的事实。
ConfigMap 有 1MB 大小限制，别把大文件塞进去。

八、共享存储：PV / PVC / StorageClass

容器是临时的，数据要持久化就必须落到外部存储。K8s 的存储抽象分三层：

graph TB
    subgraph 管理员/云平台侧
        SC[StorageClass<br/>定义「用什么盘」<br/>如 alicloud-disk-essd / nas]
        PV[PersistentVolume<br/>一块真实的存储<br/>云盘/NAS 文件系统]
    end
    subgraph 应用侧
        PVC[PersistentVolumeClaim<br/>「我要 100Gi 存储」的申请单]
        Pod[Pod 挂载 PVC]
    end
    PVC -->|绑定| PV
    SC -->|动态供给：PVC 一创建<br/>自动开出对应 PV| PV
    Pod --> PVC

现代用法几乎全是动态供给：你只需要写 PVC 声明要多少空间，StorageClass 自动调用云厂商 API 创建云盘/NAS，不用手工建 PV。

三种访问模式（Access Modes）是高频考点：

模式	含义	典型存储
ReadWriteOnce (RWO)	只能挂到一个节点	云盘（阿里云 ESSD、AWS EBS）
ReadWriteMany (RWX)	多节点共享读写	文件存储（阿里云 NAS、AWS EFS）
ReadOnlyMany (ROX)	多节点只读	对象存储挂载、只读数据卷

共享存储的避坑清单：

云盘（RWO）不能跨可用区挂载。PV 创建在可用区 A，Pod 被调度到可用区 B 就永远 Pending。解法：用 WaitForFirstConsumer 模式的 StorageClass（等 Pod 定好节点再开盘），并用拓扑约束调度。
要多副本共享文件（如多个 Web Pod 共享上传目录），必须用 NAS/EFS 这类 RWX 存储，云盘做不到。
NAS 挂载注意权限问题：容器内进程 UID 和 NAS 目录属主不匹配会 Permission denied，用 securityContext.fsGroup 或挂载参数解决。
删除 PVC 会不会丢数据，取决于 PV 的 persistentVolumeReclaimPolicy（Retain 保留 / Delete 连盘一起删）。生产数据盘务必确认是 Retain。
StatefulSet 用 volumeClaimTemplates 给每个副本独立开盘，扩缩容时数据卷跟着 Pod 名字走，这是有状态服务的标准姿势。

九、Istio 服务网格：把「网络能力」从业务代码里剥出来

微服务多了之后，每个服务都要自己实现超时重试、熔断、灰度、流量监控——这些和业务无关。Istio 的思路：给每个 Pod 注入一个 Envoy 边车代理，接管所有进出流量，上述能力全部在代理层实现，业务代码零侵入。

graph TB
    subgraph 控制平面["Istio 控制平面（istiod）"]
        Pilot[配置下发<br/>流量规则]
        Citadel[证书管理<br/>mTLS]
    end
    subgraph 数据平面
        subgraph PodA["Pod A"]
            App1[业务容器] --- E1[Envoy 边车]
        end
        subgraph PodB["Pod B"]
            App2[业务容器] --- E2[Envoy 边车]
        end
    end
    Pilot -.->|xDS 配置下发| E1
    Pilot -.->|xDS 配置下发| E2
    E1 <-->|"mTLS 加密流量<br/>（应用无感知）"| E2

核心能力速览：

流量管理：VirtualService + DestinationRule 实现按权重灰度（v1 90% / v2 10%）、按 Header 路由、超时重试、熔断
安全：服务间自动 mTLS 加密 + 身份认证（AuthorizationPolicy）
可观测：不用改代码就拿到全链路指标、调用拓扑、访问日志
入口：Istio Gateway 替代/补充原生 Ingress，作为网格的南北向入口

避坑点（Istio 坑不少，挑最重要的）：

边车有成本：每个 Pod 多一份 Envoy 的 CPU/内存（默认 requests 约 100m/128Mi），上千 Pod 规模要算这笔账，必要时调小。
Sidecar 启动顺序：业务容器可能比 Envoy 先起来导致启动瞬间网络不通（现在 holdApplicationUntilProxyStarts 可解）；Job 类任务跑完 Envoy 不退导致 Job 永不结束，需要显式退出或关掉注入。
协议识别：Service 端口名要带协议前缀（name: http-xxx），否则 Istio 按 TCP 处理，七层能力全部失效。这是网格内路由不生效的第一嫌疑。
排障三板斧：istioctl analyze（静态检查配置）、istioctl proxy-config（看 Envoy 实际生效配置）、Envoy 的 :15000/stats 和 :15000/clusters。
新人别一上来就上全量 Istio。先在非核心 namespace 开注入练手，理解 VirtualService 再说。

十、云上落地：阿里云 ACK 为主，AWS EKS 对照

自己从零搭一套生产级 K8s（etcd 高可用、证书、网络插件）成本极高，生产环境几乎都用云厂商托管服务。

10.1 阿里云 ACK 关键点

graph TB
    subgraph 阿里云托管["ACK 托管层（免费/Pro）"]
        MA[控制平面：apiserver/etcd/scheduler<br/>阿里云托管，SLA 保障]
    end
    subgraph 你的账号["你的 VPC 内"]
        N1[ECS 节点池 1<br/>按量/抢占式]
        N2[ECS 节点池 2<br/>弹性伸缩 ESS]
    end
    MA --> N1
    MA --> N2
    N1 -.对接.-> CLB[CLB/ALB<br/>负载均衡]
    N1 -.对接.-> NAS[云盘 ESSD / NAS<br/>持久存储]
    N1 -.对接.-> SLS[SLS 日志 / ARMS 监控<br/>可观测]

实践经验：

网络插件选 Terway：Pod 直接用 VPC 弹性网卡 IP，无 overlay 开销、conntrack 压力小，还能配 NetworkPolicy；Flannel 适合小规模简单场景。Terway 模式下规划 VPC 网段要留够，每个 Pod 占一个真实 IP。
节点池 + 弹性伸缩：按业务波峰波谷自动扩缩节点；抢占式实例（Spot）跑无状态任务能省 70% 成本，但要容忍随时被回收。
Ingress 用 ALB Ingress Controller：比自建 Nginx Ingress 省心，ALB 本身按量弹性，且和 ACK 深度集成。
日志和监控开箱即用：日志服务 SLS（采集容器 stdout 和文件日志）、ARMS Prometheus 监控，别再自己搭 ELK 了。
镜像仓库 ACR：用 ACR EE（企业版）+ ACK 免密拉取插件，避免在 YAML 里配 imagePullSecret。
存储选 CNFS/云盘 ESSD（有状态单副本）+ NAS（共享文件）+ OSS（静态资源、备份） 的组合。

10.2 AWS EKS 速查对照

需求	阿里云 ACK	AWS EKS
网络插件	Terway（VPC 网卡直连）	aws-vpc-cni（同理）
七层入口	ALB Ingress	AWS Load Balancer Controller (ALB/NLB)
块存储	云盘 ESSD	EBS (gp3)
共享文件存储	NAS	EFS
日志	SLS	CloudWatch
监控	ARMS Prometheus	Managed Prometheus / Grafana
镜像仓库	ACR	ECR
无服务器节点	虚拟节点（ECI）	Fargate

概念完全互通，换云只是换 Controller 和注解。

十一、典型问题排查手册

11.1 通用排查流程

graph TD
    A[发现问题] --> B{Pod 状态？<br/>kubectl get pods}
    B -->|Pending| C[kubectl describe pod<br/>看 Events]
    C --> C1{原因}
    C1 -->|资源不足| C2[加节点/降 requests<br/>或开弹性伸缩]
    C1 -->|存储挂载失败| C3[检查 PVC 绑定/可用区]
    C1 -->|镜像拉取失败| C4[ImagePullBackOff：查镜像名/凭证/网络]
    B -->|CrashLoopBackOff| D[kubectl logs --previous<br/>看上一个容器的临终日志]
    D --> D1{原因}
    D1 -->|应用自身报错| D2[修代码/配置]
    D1 -->|Exit 137| D3[OOMKilled：调大 memory limit<br/>或查内存泄漏]
    D1 -->|Exit 143| D4[被优雅终止：查探针/滚动更新]
    B -->|Running 但访问异常| E[分层验证]
    E --> E1[1. 进 Pod 内 curl localhost 通吗？]
    E1 --> E2[2. curl Pod IP 通吗？]
    E2 --> E3[3. curl Service ClusterIP 通吗？<br/>查 Endpoints 是否有后端]
    E3 --> E4[4. Ingress 域名通吗？<br/>查 Controller 日志]

11.2 高频问题速查表

症状	最常见原因	第一动作
ImagePullBackOff	镜像名/tag 错、私有仓库无凭证、节点无公网	`describe pod` 看 Events 报错原文
CrashLoopBackOff	配置错、依赖没起来、探针误杀	`kubectl logs --previous`
OOMKilled (137)	内存 limit 太小或泄漏	看监控曲线，调 limit；Java 服务注意堆外内存
Pod 一直 Pending	资源不够、PVC 未绑定、污点/亲和性	`describe pod` 看调度失败原因
服务间偶发超时	conntrack 满、DNS 慢、TIME_WAIT 耗尽	`ss -s`、CoreDNS 日志、查连接池配置
滚动更新后 502	没配 readinessProbe / 没处理 SIGTERM 优雅退出	配探针 + preStop + 应用优雅关闭
ConfigMap 改了不生效	环境变量注入 / subPath 挂载	重启 Pod 或改为目录挂载
跨可用区挂载失败	云盘和节点不在同一 AZ	WaitForFirstConsumer + 拓扑约束

11.3 优雅退出：滚动更新不断流的完整姿势

Pod 被删除时的标准流程（很多人只知道一半）：

sequenceDiagram
    participant K as kubelet
    participant P as Pod
    participant EP as Endpoints

    K->>EP: 把 Pod 从 Service 摘除（不再接新流量）
    K->>P: 执行 preStop 钩子（如 sleep 5，等摘流量生效）
    K->>P: 发送 SIGTERM
    P->>P: 应用应：停止接新请求，处理完存量请求后退出
    Note over K,P: 超过 terminationGracePeriodSeconds（默认30s）
    K->>P: SIGKILL 强杀

三个缺一不可：readinessProbe 保证新 Pod ready 才切流量；preStop/优雅关闭保证老 Pod 处理完存量请求；terminationGracePeriodSeconds 给够时间。Java/Go 服务请确认框架注册了 SIGTERM 处理器（Spring Boot 的 server.shutdown=graceful、Go 的 signal.Notify）。

11.4 kubectl 排障速查

kubectl get pods -o wide -n <ns>          # 看状态和所在节点
kubectl describe pod <pod> -n <ns>        # 看 Events（排障第一步）
kubectl logs <pod> -c <container> --previous   # 崩溃前的日志
kubectl get endpoints <svc> -n <ns>       # Service 后面到底有没有 Pod
kubectl exec -it <pod> -- sh              # 进容器内验证网络
kubectl run debug --rm -it --image=busybox:1.36 -- sh   # 临时网络调试 Pod
kubectl top pod / kubectl top node        # 资源占用
kubectl get events --sort-by=.lastTimestamp -n <ns>     # 按时间看事件

十二、CI/CD：Jenkins 与 K8s 打通，实现自动化部署与验证

手工 kubectl apply 只适合学习。生产环境的标准做法是把「构建 → 推镜像 → 部署 → 验证 → 失败回滚」串成流水线，代码合并后自动完成发布。

12.1 整体流水线长什么样

graph LR
    Dev[开发者 git push] --> Hook[Webhook 触发 Jenkins]
    Hook --> Build[阶段1: 构建<br/>单测 + Docker 镜像]
    Build --> Push[阶段2: 推送镜像<br/>到 ACR/ECR<br/>tag = git commit]
    Push --> Deploy[阶段3: 部署<br/>kubectl set image<br/>更新 K8s]
    Deploy --> Verify[阶段4: 验证<br/>rollout status + 冒烟测试]
    Verify -->|成功| Done[发布完成<br/>钉钉/邮件通知]
    Verify -->|失败| RB[自动回滚<br/>rollout undo] --> Alarm[告警通知]

关键认知：K8s 侧不需要装任何 Jenkins 插件或 Agent 也能被部署——Jenkins 只要有目标集群的 kubeconfig（访问凭证），用 kubectl 就能驱动 apiserver 完成一切。打通的本质就两件事：凭证怎么管、流水线脚本怎么写。

12.2 Jenkins 的两种部署形态

形态	说明	适用
Jenkins 在集群外（独立服务器/另一集群）	通过 kubeconfig 远程操作业务集群	一套 Jenkins 管多个集群，最常见
Jenkins 跑在 K8s 集群内	配合 Kubernetes 插件，每次构建动态拉起一个 Pod 作为构建 agent，用完即销毁	构建任务多、想弹性利用集群资源

graph TB
    subgraph Jenkins侧["Jenkins（集群外或集群内）"]
        J[Jenkins Master]
        C1[凭据1: kubeconfig<br/>Secret file 类型]
        C2[凭据2: ACR 账号<br/>Username/Password 类型]
        J --> C1
        J --> C2
    end
    subgraph 阿里云["阿里云"]
        J -->|docker push| ACR[ACR 镜像仓库]
        J -->|"kubectl（走内网 API Server 端点）"| API[ACK apiserver]
        API --> Pod[滚动更新业务 Pod]
        Pod -->|免密拉取| ACR
    end

推荐做法：Jenkins 与 ACK 在同一 VPC 内，kubectl 直接走 API Server 的内网端点（安全且免公网流量）；镜像仓库用 ACR 企业版 + ACK 免密拉取，业务侧零凭证。

12.3 最小权限的部署凭证：别把 admin kubeconfig 给 Jenkins

这是 CI/CD 安全的第一课。给 Jenkins 一个只能操作特定 namespace、只能改 Deployment 的 ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-deployer
  namespace: prod
---
# Role 只在 prod namespace 内生效
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: prod
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "patch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-deployer
  namespace: prod
subjects:
  - kind: ServiceAccount
    name: jenkins-deployer
    namespace: prod
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

然后为这个 SA 生成 token，做成只含该 token 的 kubeconfig，存进 Jenkins 的 Secret file 凭据。好处：凭证泄露也只影响一个 namespace 的 Deployment，且可以随时 kubectl delete rolebinding 吊销。

12.4 完整 Jenkinsfile 示例

pipeline {
    agent any
    environment {
        IMAGE     = "registry.cn-hangzhou.aliyuncs.com/mycompany/order-svc"
        TAG       = "${env.GIT_COMMIT.take(8)}"   // 用 git commit 做 tag，可回滚可追溯
        KUBECONFIG = credentials('ack-prod-kubeconfig')   // Secret file 凭据
    }
    stages {
        stage('构建') {
            steps {
                sh 'mvn -q test'                       // 先跑单测，挂了直接终止
                sh "docker build -t ${IMAGE}:${TAG} ."
            }
        }
        stage('推送镜像') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'acr-account',
                    usernameVariable: 'U', passwordVariable: 'P')]) {
                    sh 'echo $P | docker login registry.cn-hangzhou.aliyuncs.com -u $U --password-stdin'
                    sh "docker push ${IMAGE}:${TAG}"
                }
            }
        }
        stage('部署到 ACK') {
            steps {
                sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                    set image deployment/order-svc order-svc=${IMAGE}:${TAG}"
            }
        }
        stage('验证') {
            steps {
                // 阻塞等待滚动更新完成；超时/失败会非零退出
                sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                    rollout status deployment/order-svc --timeout=300s"
                // 冒烟测试：走内网 SLB 打健康检查和关键接口
                sh "curl -fsS --retry 5 --retry-delay 3 \
                    http://order-svc-internal.prod.svc.cluster.local/healthz || exit 1"
            }
        }
    }
    post {
        failure {
            // 部署验证失败自动回滚到上一个版本
            sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                rollout undo deployment/order-svc || true"
        }
    }
}

12.5 「验证」环节的正确姿势

很多流水线只做到 kubectl apply 就算「发布成功」，这是自欺欺人。apply 返回成功只代表 apiserver 收下了 YAML，Pod 起不起得来是另一回事。可靠的验证链：

rollout status 阻塞等待：确认所有新副本 ready（背后靠的就是 readinessProbe——再次体现探针的重要性）。
冒烟测试：对真实入口打 /healthz 和一两个核心业务接口，确认「能起来」且「能干活」。
失败自动回滚：rollout undo 依赖旧 ReplicaSet 还在（revisionHistoryLimit 别设 0）且镜像 tag 可追溯——这就是前面说「不要用 latest」的根本原因。
更严谨的做法是灰度验证：先用 Istio 把 5% 流量切到新版本观察指标，确认无误再全量（见第九章）。

12.6 CI/CD 避坑清单

镜像 tag 必须唯一可追溯：git commit 短哈希或构建号，杜绝 latest，否则回滚时根本不知道该回滚到哪个镜像。
凭据最小化 + 分环境：dev/staging/prod 用不同的 SA 和 Jenkins 凭据，prod 的部署动作加人工审批（Jenkins 的 input 步骤）。
声明式优先：服务变多后，把 kubectl set image 换成 Helm/Kustomize（YAML 也进 Git 仓库，可审计可 diff）；再进一步上 GitOps（ArgoCD/Flux）——Jenkins 只负责构建推镜像，部署由集群内的 ArgoCD 从 Git 仓库自动同步，Jenkins 不再需要生产集群的任何凭证，安全性大幅提升。
Jenkins 到集群的网络：kubectl 走内网 API Server 端点；如果 Jenkins 在另一个 VPC，用云企业网/对等连接打通，不要把 API Server 暴露公网给 Jenkins 用。
构建产物（镜像）与部署配置分离管理，避免「同一个 tag 被覆盖推送」导致回滚失效——ACR 里给 prod 仓库开镜像 tag 不可变（immutable）开关。

十三、学习路线建议

第一周：本地装 minikube 或 kind，把 Deployment/Service/ConfigMap 各玩一遍，亲手制造一次 CrashLoopBackOff 并修好它。
第二周：搞懂网络——Pod 网络、Service 转发（iptables）、Ingress、NetworkPolicy 内外网隔离，配合 tcpdump/ss 在容器里抓包看真实流量。
第三周：上云。开一套阿里云 ACK（按量付费，玩完就删），跑通「ACR 推镜像 → ACK 部署 → ALB Ingress 暴露 → NAS 挂共享盘 → SLS 看日志」全流程。
第四周：打通 CI/CD。用 Jenkins + 最小权限 SA 实现「推代码 → 自动构建 → 自动部署 → rollout 验证 → 失败回滚」完整流水线。
进阶：Helm 包管理、HPA 自动扩缩容、Istio 灰度发布、GitOps（ArgoCD）。

最后送一句《Kubernetes 权威指南》反复强调的心法：K8s 的一切都是声明式的——你描述「我要什么」，控制器负责「做到」。排查问题时永远先问：期望状态（YAML/Spec）是什么？实际状态（Status/Events）是什么？两者的差距就是答案所在。

参考资料：

《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触（第 4 版）》龚正等

《Kubernetes in Action》Marko Lukša

《Unix 网络编程卷1》W. Richard Stevens（网络排障内功）

Kubernetes 官方文档

阿里云 ACK 文档

TCP/IP 学习总结与避坑指南

Sat, 09 Dec 2017 10:00:00 +0800

TCP/IP 学习总结与避坑指南

最近华为项目交付碰到各种头大的网络问题，现在整理下TCP/IP相关知识。参考书籍：W. Richard Stevens《TCP/IP 详解卷1：协议》、W. Richard Stevens《Unix 网络编程卷1：套接字联网 API》
目标读者：刚接触网络编程，或者学了很多概念但总觉得「协议栈串不起来」「代码一跑就掉坑」的同学。

TCP/IP 不是一门「背完就能会」的技术。它由一整套分层协议组成，每一层只关心自己的事情，又通过严格定义的头部把信息交给下一层。理解这套分层思维，是看懂网络报文、写出稳定网络程序、排查线上连接问题的第一步。

这篇文章不会把所有 RFC 都讲一遍（那是 1000 多页书做的事），而是帮你建立主干知识框架：

TCP/IP 协议栈为什么要分层？数据是怎么一层层包起来的？
IP、TCP、UDP、ARP、ICMP、DNS 这些协议各自解决什么问题？
Unix Socket 编程的核心 API 与调用顺序是什么？
写网络程序最容易踩哪些坑，怎么避开？
遇到连接失败、卡顿、端口耗尽这些问题，该按什么思路排查？

读完之后，你应该能看懂 Wireshark 里的大部分常见报文，也能独立写出稳定的 TCP 客户端/服务端，并具备基础的线上网络问题排查能力。

一、TCP/IP 协议栈：为什么必须分层？

网络通信的复杂度非常高：不同的物理介质、不同的操作系统、不同的应用程序要在全球范围内交换数据。如果不分层，每一台设备都要同时处理「电信号怎么传」「数据怎么路由」「传输可不可靠」「应用数据什么意思」所有问题。

分层的目的就是关注点分离：每一层只解决本层的问题，向上层提供服务，把复杂问题拆成可管理的小块。

1.1 OSI 七层模型 vs TCP/IP 四层模型

教学中常用 OSI 七层模型，但互联网实际运行的是 TCP/IP 四层模型。

graph LR
    subgraph OSI七层模型
        A7[7 应用层] --> A6[6 表示层]
        A6 --> A5[5 会话层]
        A5 --> A4[4 传输层]
        A4 --> A3[3 网络层]
        A3 --> A2[2 数据链路层]
        A2 --> A1[1 物理层]
    end

    subgraph TCP/IP四层模型
        B4[应用层<br/>HTTP/FTP/DNS/SMTP] --> B3[传输层<br/>TCP/UDP]
        B3 --> B2[网络层<br/>IP/ICMP/IGMP]
        B2 --> B1[网络接口层<br/>以太网/WiFi/PPP]
    end

    A7 -.对应.-> B4
    A6 -.对应.-> B4
    A5 -.对应.-> B4
    A4 -.对应.-> B3
    A3 -.对应.-> B2
    A2 -.对应.-> B1
    A1 -.对应.-> B1

TCP/IP 层	核心协议	解决的问题
应用层	HTTP、DNS、FTP、SMTP、SSH	应用程序之间「说什么」
传输层	TCP、UDP	进程到进程的通信，可靠或高效传输
网络层	IP、ICMP、IGMP、路由协议	主机到主机的寻址与路由
网络接口层	以太网、WiFi、ARP、PPP	相邻设备之间的物理/逻辑传输

新手容易混淆的点：TCP/IP 里的「应用层」实际上对应了 OSI 的应用层、表示层、会话层三层。不要死磕七层，实际工程里四层模型更常用。

1.2 数据封装与解封装

每一层都会给上一层的数据加一个「头部」，然后交给下一层。接收方则逐层去掉头部，把数据交给上层。

flowchart TB
    subgraph 发送方
        A[应用数据] -->|"应用层封装"| B["应用层头部 + 应用数据"]
        B -->|"传输层封装"| C["TCP/UDP 头部 + 应用层数据"]
        C -->|"网络层封装"| D["IP 头部 + TCP 数据段"]
        D -->|"链路层封装"| E["以太网头部 + IP 数据报 + 以太网尾部"]
    end

    E -->|"比特流在物理介质传输"| F

    subgraph 接收方
        F["以太网帧"] -->|"链路层解封装"| G["IP 数据报"]
        G -->|"网络层解封装"| H["TCP/UDP 数据段"]
        H -->|"传输层解封装"| I["应用层数据"]
        I -->|"应用层处理"| J[交给对应进程]
    end

关键概念：

MTU（Maximum Transmission Unit）：链路层帧能承载的最大数据量，以太网常见值是 1500 字节。
MSS（Maximum Segment Size）：TCP 一次能发送的最大数据段，通常 = MTU - IP 头 - TCP 头，以太网常见 1460 字节。
分片（Fragmentation）：当 IP 数据报超过链路 MTU 时，IP 层会把它切成多个片。TCP 一般会通过 MSS 避免分片，UDP 则容易触发分片。

避坑技巧：

不要随意修改 MTU，VPN/隧道场景特别容易出现「大数据包被静默丢弃」的问题。
UDP 应用如果要传输大报文，建议在应用层自己拆包，不要让 IP 层分片。

二、链路层与 ARP：同一局域网怎么找到对方？

链路层负责相邻节点之间的数据传输。在以太网里，设备用 MAC 地址标识，交换机根据 MAC 地址转发帧。

2.1 以太网帧结构

+----------------+----------------+----------------+----------------+----------------+
| 目的 MAC 6B    | 源 MAC 6B      | 类型 2B        | 数据 46~1500B  | FCS 4B         |
+----------------+----------------+----------------+----------------+----------------+

MAC 地址：48 位，全球唯一（理论上），用于局域网内定位网卡。
类型字段：例如 0x0800 表示上层是 IP，0x0806 表示 ARP。
FCS（Frame Check Sequence）：帧校验序列，检测传输过程中的比特错误。

2.2 ARP：IP 地址 → MAC 地址

ARP（Address Resolution Protocol）解决的是「知道对方 IP，但不知道对方 MAC」的问题。

sequenceDiagram
    participant A as 主机 A<br/>192.168.1.10
    participant B as 主机 B<br/>192.168.1.20

    A->>B: ARP 请求：谁的 IP 是 192.168.1.20？请告诉我你的 MAC
    Note over A,B: 广播帧，局域网内所有主机收到
    B->>A: ARP 应答：我是 192.168.1.20，MAC 是 xx:xx:xx:xx:xx:xx
    Note over A,B: 单播帧，只有 A 收到

ARP 表会缓存一段时间：arp -a 可以查看本机 ARP 缓存。

避坑技巧：

ARP 只在同一二层网络（同一广播域）有效。跨网段通信时，主机把报文发给网关，由网关继续转发。
网关配错是新手常见问题：如果默认网关不在同一子网，ARP 请求会失败，数据根本发不出去。
ARP 欺骗/中间人攻击在局域网内存在，敏感环境要开启动态 ARP 检测（DAI）或静态绑定。

三、IP 协议：主机到主机的寻址与路由

IP（Internet Protocol）是网络层的核心，负责把数据从源主机送到目的主机。它不保证可靠、不保证有序，这些由 TCP 或应用层自己处理。

3.1 IPv4 头部核心字段

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

关键字段含义：

Version：IPv4 填 4，IPv6 填 6。
IHL（Header Length）：头部长度，单位是 4 字节。没有选项时最小是 5，即 20 字节。
Total Length：整个 IP 数据报的长度，最大 65535 字节。
Identification / Flags / Fragment Offset：用于分片和重组。
TTL（Time to Live）：每经过一个路由器减 1，到 0 被丢弃，防止报文在网络里无限循环。
Protocol：上层协议类型。6 = TCP，17 = UDP，1 = ICMP，等等。
Source/Destination Address：源 IP 和目的 IP。

3.2 IP 地址、子网掩码与 CIDR

IP 地址 = 网络号 + 主机号。子网掩码用来划分这两部分。

IP 地址：    192.168.1.100   → 11000000.10101000.00000001.01100100
子网掩码：   255.255.255.0   → 11111111.11111111.11111111.00000000
网络号：     192.168.1.0     → 前 24 位
主机号：     0.0.0.100       → 后 8 位

CIDR 表示法：192.168.1.0/24，斜杠后面的数字表示网络号位数。

判断两台主机是否在同一子网：用各自的 IP 和子网掩码做按位与，得到网络号，网络号相同就在同一子网。

3.3 路由基础

当目的 IP 不在本子网时，主机会把报文发给默认网关（Default Gateway）。路由器根据路由表决定下一跳。

flowchart LR
    A[主机 A<br/>192.168.1.10/24] -->|"目的 IP 不在同一子网"| R[路由器<br/>192.168.1.1]
    R -->|"查路由表"| B[主机 B<br/>10.0.0.5/24]

常用查看命令：

# Linux/macOS
ip route show        # 查看路由表
route -n             # 旧命令

# Windows
route print

避坑技巧：

配置静态 IP 时，最容易漏掉或配错的就是子网掩码和默认网关。只配 IP 不配上两者，通常只能 ping 通同网段。
/24 和 /16 的区别不只是数字大小，它决定了网络规模和可用主机数。/24 有 254 个可用主机地址，/16 有 65534 个。
路由表顺序很重要：更具体的子网（前缀更长）优先于默认路由。

四、ICMP：IP 的「诊断助手」

ICMP（Internet Control Message Protocol）本身不传输用户数据，而是用于传递控制消息和诊断信息。

4.1 Ping 原理

Ping 使用 ICMP Echo Request 和 Echo Reply。

sequenceDiagram
    participant A as 主机 A
    participant B as 主机 B

    A->>B: ICMP Echo Request
    Note over A,B: 携带标识符和序列号
    B->>A: ICMP Echo Reply
    Note over A,B: A 根据往返时间计算延迟

Ping 不通不一定是对端关机，可能是：

防火墙拦截了 ICMP
路由不可达
对端 ARP 表异常
本机默认网关配错

4.2 Traceroute 原理

Traceroute 利用 TTL 递增或端口不可达来追踪路径。

flowchart LR
    A[主机] -->|"TTL=1"| R1[路由器 1]
    R1 -->|"TTL 超时，返回 ICMP Time Exceeded"| A
    A -->|"TTL=2"| R2[路由器 2]
    R2 -->|"TTL 超时，返回 ICMP Time Exceeded"| A
    A -->|"TTL=3"| B[目标主机]
    B -->|"端口不可达 / Echo Reply"| A

避坑技巧：

有些路由器配置了「不回应 ICMP Time Exceeded」，Traceroute 会显示 * * *，不代表网络不通。
防火墙可能会阻断 Traceroute 的 UDP 探测端口，换 -I（ICMP）或 -T（TCP）模式可能成功。

五、UDP：简单、高效、不可靠

UDP（User Datagram Protocol）提供无连接、不可靠、面向数据报的传输服务。

5.1 UDP 头部

 0      7 8     15 16    23 24    31
+--------+--------+--------+--------+
|     Source Port    |   Dest Port   |
+--------+--------+--------+--------+
|     Length         |   Checksum    |
+--------+--------+--------+--------+
|          data octets ...            |
+-------------------------------------+

Source Port / Dest Port：各 16 位，标识发送和接收进程。
Length：UDP 头部 + 数据的总长度。
Checksum：可选（IPv4 中），覆盖头部、数据和伪头部。

5.2 UDP 的特点与适用场景

特点	说明
无连接	不需要建立连接，直接发
不可靠	不保证到达、不保证顺序、不重传
低开销	头部只有 8 字节
面向数据报	发一次收一次，保留边界

适合用 UDP 的场景：DNS 查询、视频直播、在线游戏、VoIP、NTP、QUIC 底层。

避坑技巧：

UDP 没有流量控制，发送方太快会导致接收方丢包。实时音视频要做抖动缓冲（jitter buffer）和前向纠错（FEC）。
UDP 报文超过 MTU 会被 IP 层分片，分片丢失会导致整个 UDP 报文作废。大数据包要在应用层分片。
不要认为 UDP 一定比 TCP 快。在丢包率高的网络里，应用层自己实现可靠传输可能比 TCP 更复杂且效果更差。

六、TCP：可靠传输的基石

TCP（Transmission Control Protocol）是互联网最常用的传输协议。它提供面向连接、可靠、按序、字节流的服务。

6.1 TCP 头部核心字段

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             |
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

关键字段：

Sequence Number（序号）：标识本报文段发送的数据在字节流中的位置。
Acknowledgment Number（确认号）：期望收到的下一个字节的序号。
ACK：确认号有效。
SYN：发起连接。
FIN：结束连接。
RST：重置连接，通常表示异常。
Window（窗口大小）：接收方当前可用缓存大小，用于流量控制。

6.2 三次握手：建立连接

sequenceDiagram
    participant C as 客户端
    participant S as 服务端

    C->>S: SYN, seq=x
    Note over C,S: 客户端请求建立连接
    S->>C: SYN, seq=y, ACK=x+1
    Note over C,S: 服务端同意，也请求建立反向连接
    C->>S: ACK=y+1
    Note over C,S: 客户端确认，连接建立

为什么是三次？

两次握手无法确认客户端的接收能力，也不能防止历史重复连接请求造成资源浪费。
三次是「双方都能发送和接收」的最小验证次数。

关键状态：

客户端：SYN_SENT → ESTABLISHED
服务端：LISTEN → SYN_RCVD → ESTABLISHED

6.3 四次挥手：关闭连接

sequenceDiagram
    participant C as 客户端
    participant S as 服务端

    C->>S: FIN, seq=u
    Note over C,S: 客户端没有数据要发了
    S->>C: ACK=u+1
    Note over C,S: 服务端确认，但可能还有数据要发
    S->>C: FIN, seq=w
    Note over C,S: 服务端也没有数据要发了
    C->>S: ACK=w+1
    Note over C,S: 客户端确认

为什么一般是四次？

TCP 是全双工的，两个方向要分别关闭。一方发完 FIN 只表示「我这方向没数据了」，另一方可能还有数据要发。

关键状态与时间等待：

主动关闭方最后进入 TIME_WAIT，等待 2MSL（Maximum Segment Lifetime，通常 1-4 分钟）后才彻底关闭。
TIME_WAIT 的作用：
1. 确保最后一个 ACK 被对方收到，如果丢失可以重传。
2. 让网络中延迟的报文自然消失，避免影响下一个使用相同四元组的新连接。

6.4 TCP 状态机

stateDiagram-v2
    [*] --> CLOSED
    CLOSED --> SYN_SENT : 主动打开/send SYN
    CLOSED --> LISTEN : 被动打开
    SYN_SENT --> ESTABLISHED : 收到 SYN+ACK
    LISTEN --> SYN_RCVD : 收到 SYN
    SYN_RCVD --> ESTABLISHED : 收到 ACK
    ESTABLISHED --> FIN_WAIT_1 : 主动关闭/send FIN
    ESTABLISHED --> CLOSE_WAIT : 收到 FIN
    FIN_WAIT_1 --> FIN_WAIT_2 : 收到 ACK
    FIN_WAIT_1 --> TIME_WAIT : 收到 FIN+ACK
    FIN_WAIT_2 --> TIME_WAIT : 收到 FIN
    CLOSE_WAIT --> LAST_ACK : 发送 FIN
    LAST_ACK --> CLOSED : 收到 ACK
    TIME_WAIT --> CLOSED : 2MSL 超时

6.5 可靠传输机制

TCP 通过以下机制保证可靠性：

flowchart LR
    A[序号与确认机制] --> B[超时重传]
    C[滑动窗口] --> D[流量控制]
    E[拥塞窗口] --> F[拥塞控制]
    B --> G[可靠传输]
    D --> G
    F --> G

序号与确认：每发一个字节都有序号，接收方用 ACK 确认连续收到的最大序号。

超时重传：发送方启动定时器，超时未收到 ACK 就重传。

滑动窗口：允许发送方在没收到 ACK 的情况下连续发送多个段，提高吞吐量。

流量控制：接收方通过 Window 字段告诉发送方自己还能接收多少数据，防止接收方缓存溢出。

拥塞控制：发送方根据网络拥塞程度调整发送速率，主要算法包括慢启动、拥塞避免、快重传、快恢复。

6.6 拥塞控制四个阶段

flowchart TB
    A[慢启动<br/>cwnd 指数增长] -->|"cwnd >= ssthresh"| B[拥塞避免<br/>cwnd 线性增长]
    B -->|"收到 3 个重复 ACK"| C[快重传<br/>立即重传]
    C --> D[快恢复<br/>cwnd=ssthresh]
    D --> B
    B -->|"超时"| E[超时重传<br/>cwnd=1]
    E --> A

慢启动（Slow Start）：初始窗口小，每收到一个 ACK 窗口近似翻倍，直到达到慢启动阈值（ssthresh）。
拥塞避免（Congestion Avoidance）：超过阈值后，窗口线性增长。
快重传（Fast Retransmit）：收到 3 个重复 ACK 就立刻重传，不等超时。
快恢复（Fast Recovery）：快重传后不把窗口降到 1，而是降到 ssthresh，再线性增长。

6.7 Nagle 算法与延迟 ACK

Nagle 算法：减少小报文数量。如果上一次发送的数据还没被确认，且当前数据量小于 MSS，就把小数据攒起来一起发。
延迟 ACK：接收方不立即对每个收到的段发 ACK，而是等 40ms 左右，看是否有数据要一起回，减少 ACK 数量。

避坑技巧：

Nagle + 延迟 ACK 会造成明显延迟：发送方等小 ACK，接收方等大数据一起回，形成「写 - 等 - 写 - 等」的 ping-pong 效应。
交互式应用（如游戏、SSH、RPC）通常要关闭 Nagle：setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on))。
批量传输场景（文件下载）可以保留 Nagle，减少小包数量。

七、DNS 与 DHCP：网络配置的基础设施

7.1 DNS：域名 → IP

DNS（Domain Name System）是互联网的「电话簿」，把人类可读的域名解析成 IP 地址。

flowchart LR
    A[客户端] -->|"查询 example.com"| B[本地 DNS 缓存]
    B -->|"未命中"| C[递归 DNS 服务器]
    C -->|"迭代查询"| D[根 DNS 服务器]
    D --> E[.com 顶级域服务器]
    E --> F[example.com 权威服务器]
    F -->|"返回 IP"| C
    C -->|"返回 IP"| A

DNS 记录类型：

类型	用途
A	域名 → IPv4 地址
AAAA	域名 → IPv6 地址
CNAME	域名别名
MX	邮件交换服务器
NS	权威 DNS 服务器
TXT	文本记录，常用于验证和 SPF

避坑技巧：

DNS 有缓存，修改记录后全球生效可能要几分钟到 48 小时（受 TTL 控制）。
注意 DNS 解析失败和连接超时的区别：先 nslookup/dig 确认域名能否解析，再 ping/telnet 确认网络层是否通。
gethostbyname 不是线程安全的，现代程序应使用 getaddrinfo。

7.2 DHCP：自动获取网络配置

DHCP（Dynamic Host Configuration Protocol）让主机自动获取 IP 地址、子网掩码、网关、DNS 服务器。

sequenceDiagram
    participant H as 主机
    participant D as DHCP 服务器

    H->>D: DHCP Discover（广播）
    D->>H: DHCP Offer
    H->>D: DHCP Request
    D->>H: DHCP ACK

八、Unix 网络编程核心：Socket API

Socket 是 Unix 系统提供的网络编程接口，屏蔽了底层协议细节，让程序像读写文件一样通信。

8.1 TCP 服务端典型调用流程

flowchart TB
    A[socket] --> B[bind]
    B --> C[listen]
    C --> D[accept]
    D --> E[read/write]
    E --> F[close]

8.2 TCP 客户端典型调用流程

flowchart TB
    A[socket] --> B[connect]
    B --> C[read/write]
    C --> D[close]

8.3 核心 API 说明

API	作用
`socket()`	创建套接字，指定协议族（IPv4/IPv6）和类型（流式/数据报）
`bind()`	把套接字绑定到本地地址和端口
`listen()`	把套接字置为监听状态，指定全连接队列长度
`accept()`	从全连接队列取出一个已完成握手的连接
`connect()`	客户端发起连接
`read()/write()` 或 `recv()/send()`	收发数据
`close()`	关闭连接
`shutdown()`	半关闭：只关闭读或写

8.4 最简 TCP 服务端示例

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define PORT 8080
#define BACKLOG 128

int main() {
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    if (listen_fd < 0) {
        perror("socket");
        exit(1);
    }

    int reuse = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse));

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = INADDR_ANY;
    addr.sin_port = htons(PORT);

    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind");
        exit(1);
    }

    if (listen(listen_fd, BACKLOG) < 0) {
        perror("listen");
        exit(1);
    }

    printf("Server listening on port %d\n", PORT);

    while (1) {
        struct sockaddr_in client_addr;
        socklen_t len = sizeof(client_addr);
        int conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &len);
        if (conn_fd < 0) {
            perror("accept");
            continue;
        }

        char buf[1024];
        ssize_t n = read(conn_fd, buf, sizeof(buf) - 1);
        if (n > 0) {
            buf[n] = '\0';
            printf("Received: %s\n", buf);
            write(conn_fd, "OK\n", 3);
        }

        close(conn_fd);
    }

    close(listen_fd);
    return 0;
}

8.5 最简 TCP 客户端示例

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define SERVER "127.0.0.1"
#define PORT 8080

int main() {
    int fd = socket(AF_INET, SOCK_STREAM, 0);
    if (fd < 0) {
        perror("socket");
        exit(1);
    }

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(PORT);
    inet_pton(AF_INET, SERVER, &addr.sin_addr);

    if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("connect");
        exit(1);
    }

    write(fd, "hello\n", 6);

    char buf[1024];
    ssize_t n = read(fd, buf, sizeof(buf) - 1);
    if (n > 0) {
        buf[n] = '\0';
        printf("Server reply: %s", buf);
    }

    close(fd);
    return 0;
}

九、Unix 网络编程常见陷阱与避坑技巧

9.1 必须设置 SO_REUSEADDR

int reuse = 1;
setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse));

原因：服务端主动关闭连接后会进入 TIME_WAIT，该连接的本地端口短时间内不能复用。如果不设置 SO_REUSEADDR，重启服务时可能报 Address already in use。

注意：SO_REUSEADDR 允许复用 TIME_WAIT 的端口，但不会允许两个进程同时绑定到完全相同的 IP:端口（Linux 上 SO_REUSEPORT 才能做到）。

9.2 正确处理 SIGPIPE

向一个已经收到 RST 的 socket 写数据会触发 SIGPIPE 信号，默认行为是终止进程。

signal(SIGPIPE, SIG_IGN);  // 忽略信号

更优雅的做法是在写之前检查连接状态，或者使用 MSG_NOSIGNAL 标志：

send(fd, buf, len, MSG_NOSIGNAL);

9.3 处理部分读写

TCP 是字节流，read 和 write 不保证一次读完或写完。

// 可靠的写：循环写直到写完
ssize_t write_all(int fd, const void *buf, size_t len) {
    const char *p = buf;
    size_t remaining = len;
    while (remaining > 0) {
        ssize_t n = write(fd, p, remaining);
        if (n < 0) {
            if (errno == EINTR) continue;
            return -1;
        }
        p += n;
        remaining -= n;
    }
    return len;
}

9.4 处理 EINTR

慢系统调用（如 accept、read、write）被信号中断后会返回 -1 并设置 errno = EINTR。 robust 的程序应该重试：

while ((n = read(fd, buf, len)) < 0 && errno == EINTR)
    ;

9.5 不要用 strlen 计算二进制数据长度

send(fd, buf, strlen(buf), 0) 只适合文本。二进制数据里可能有 \0，要用实际长度。

9.6 使用 getaddrinfo 替代 gethostbyname

gethostbyname 只支持 IPv4，不是线程安全的，已经被废弃。现代程序应使用 getaddrinfo：

struct addrinfo hints, *res;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;      // 支持 IPv4 和 IPv6
hints.ai_socktype = SOCK_STREAM;

int err = getaddrinfo("example.com", "80", &hints, &res);
if (err != 0) {
    fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(err));
    exit(1);
}

int fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
connect(fd, res->ai_addr, res->ai_addrlen);

freeaddrinfo(res);  // 记得释放

9.7 区分 close 与 shutdown

close(fd)：关闭文件描述符，引用计数减到 0 时释放资源，双向关闭。
shutdown(fd, SHUT_WR)：只关闭写方向，读仍然可以接收数据，常用于通知对端「我发完了」。

9.8 阻塞 vs 非阻塞 IO

模式	特点	适用场景
阻塞	调用没完成就挂起	简单程序、每个连接一个线程/进程
非阻塞	调用立即返回，没数据返回 EAGAIN/EWOULDBLOCK	高并发、IO 多路复用

9.9 IO 多路复用

单线程服务大量连接时，要用 IO 多路复用同时监视多个 fd 的就绪状态。

flowchart LR
    A[主线程] --> B[select/poll/epoll]
    B -->|"哪些 fd 可读/可写"| C[处理可读 fd]
    B --> D[处理可写 fd]

机制	特点
select	有 fd 数量限制（通常 1024），每次调用要遍历全部 fd
poll	用数组描述 fd，没有数量硬限制，但仍需遍历
epoll（Linux）	事件驱动，只关注活跃的 fd，支持边缘触发和水平触发
kqueue（BSD/macOS）	类似 epoll，事件驱动

epoll 水平触发（LT）vs 边缘触发（ET）：

LT：只要 fd 还有数据可读，epoll 就会一直通知。
ET：只有 fd 状态变化时通知一次，需要一次性把数据读完，通常配合非阻塞 IO。

十、典型 Unix 网络障碍问题与排查思路

10.1 排查流程总览

flowchart TD
    A[网络问题] --> B[确认是 DNS/路由/端口/应用哪一层]
    B --> C{能解析域名吗?}
    C -->|否| D[检查 DNS / hosts / 防火墙]
    C -->|是| E{能 ping 通 IP 吗?}
    E -->|否| F[检查路由 / ACL / 安全组]
    E -->|是| G{端口通吗?}
    G -->|否| H[检查服务是否监听 / 防火墙 / 安全组]
    G -->|是| I[检查应用日志 / 抓包 / 连接状态]

10.2 Connection refused

原因：目标 IP 可达，但目标端口没有进程在监听，或者防火墙明确拒绝。

排查：

# 服务端检查是否在监听
ss -tlnp | grep 8080
netstat -tlnp | grep 8080

# 客户端测试端口是否开放
telnet server_ip 8080
nc -vz server_ip 8080

10.3 Connection timed out

原因：报文到达目的地过程中被丢弃，没有收到任何 RST 或响应，常见于防火墙静默丢弃、路由不可达、NAT 映射问题。

排查：

# 看路径到哪里断了
traceroute server_ip
mtr server_ip

# 抓包看 SYN 有没有出去、有没有回来
tcpdump -i any port 8080 -nn

10.4 Too many TIME_WAIT / 端口耗尽

现象：高并发短连接场景下，客户端连接失败，报错 Cannot assign requested address。

原因：大量主动关闭的连接堆积在 TIME_WAIT，占用了本地端口。

解决思路：

尽量使用长连接 / 连接池。
服务端设置 SO_REUSEADDR。
Linux 可调整 net.ipv4.ip_local_port_range 扩大临时端口范围。
开启 net.ipv4.tcp_tw_reuse（谨慎，仅对客户端出站连接有效，不要开 tcp_tw_recycle，已在内核 4.12 后移除）。

10.5 CLOSE_WAIT 堆积

现象：服务端 ss -tan | grep CLOSE_WAIT 看到很多连接。

原因：对端已经发了 FIN，但本端应用没有调用 close()，通常是因为：

应用逻辑忘记关闭 socket。
应用在处理完数据前阻塞在某处，无法执行 close。
异常分支没有释放连接资源。

解决：检查代码里所有异常路径是否都调用了 close，确保每个 accept 出来的 fd 都有对应的关闭点。

10.6 SYN Flood / 半连接队列溢出

现象：服务偶尔出现连接建立慢或大量 SYN_SENT/SYN_RECV。

原理：Linux 内核有两个队列：

半连接队列（syn queue）：存放收到 SYN 但还没完成三次握手的连接。
全连接队列（accept queue）：存放已完成三次握手但还没被 accept 取走的连接。

flowchart LR
    A[客户端 SYN] -->|"进入半连接队列"| B[SYN_RCVD]
    B -->|"收到 ACK"| C[ESTABLISHED]
    C -->|"进入全连接队列"| D[等待 accept]
    D -->|"accept 取走"| E[交给业务处理]

排查：

ss -s          # 查看连接统计
ss -lnt        # 看全连接队列长度和溢出次数
netstat -s | grep overflow

解决：

调大 net.ipv4.tcp_max_syn_backlog。
开启 SYN Cookies：net.ipv4.tcp_syncookies = 1。
增大 listen(fd, backlog) 的 backlog，同时配合 somaxconn 调整。
提升应用 accept 速度。

10.7 高并发下 accept 慢或全连接队列溢出

现象：连接完成三次握手，但客户端一直等待服务端响应。

原因：accept 处理太慢，全连接队列满了，新的完成连接被丢弃。

解决：

用多线程/多进程分担 accept。
使用 IO 多路复用 + 事件驱动架构。
调整 net.core.somaxconn 和 listen() 的 backlog。

10.8 MTU/MSS 导致的大包不通

现象：小数据包能通，大数据包不通；或某些网站/服务能打开，某些打不开。

原因：路径中某段链路 MTU 较小，大包被丢弃，且中间设备不发送 ICMP “Fragmentation Needed”，导致无法自动降包大小。这就是著名的 PMTUD（Path MTU Discovery）黑洞。

解决：

设置 net.ipv4.tcp_mtu_probing = 1 启用 TCP MTU 探测。
在 VPN/隧道两端统一调低 MTU/MSS。
中间网络设备不要丢弃 ICMP “Fragmentation Needed”。

10.9 应用层协议粘包/拆包

现象：TCP 客户端发了两条消息，服务端一次 read 读到了两条消息的内容。

原因：TCP 是字节流，没有消息边界。应用层需要自己定义消息边界。

常见解决方案：

固定长度：每个消息固定 N 字节。
分隔符：如 \n、自定义分隔符。
长度前缀：消息头 4 字节表示消息体长度。

// 长度前缀示例：先读 4 字节长度，再读对应长度的 body
uint32_t len;
read_all(fd, &len, 4);
len = ntohl(len);
read_all(fd, body, len);

十一、学习路线与推荐资源

11.1 学习顺序建议

flowchart LR
    A[网络分层模型] --> B[IP/子网/路由]
    B --> C[ARP/ICMP]
    C --> D[TCP 握手挥手与状态机]
    D --> E[滑动窗口与拥塞控制]
    E --> F[Socket API 编程]
    F --> G[IO 多路复用]
    G --> H[Wireshark 抓包分析]
    H --> I[线上问题排查]

11.2 推荐实践

用 Wireshark 抓一次完整的三次握手和四次挥手，亲眼看看每个字段的值。
写一个 echo 服务器，先用阻塞 IO，再用 select/epoll 改写。
故意制造问题：把客户端改成快速创建大量短连接，观察 TIME_WAIT；把服务端 accept 故意睡几秒，观察全连接队列溢出。
用 ss、tcpdump、traceroute、nc、iperf 这些工具做实验。

11.3 推荐参考书

《TCP/IP 详解卷1：协议》（W. Richard Stevens）——协议细节最权威。
《Unix 网络编程卷1：套接字联网 API》（W. Richard Stevens）——Socket 编程圣经。
《Wireshark 网络分析就这么简单》——抓包实战。
《Linux 高性能服务器编程》（游双）——中文入门友好。

十二、总结

TCP/IP 协议栈并不神秘，它的核心思想就是分层与解耦：

链路层负责「相邻设备怎么传」。
网络层负责「怎么找到对方主机」。
传输层负责「怎么把数据交给正确的进程，并决定可靠还是高效」。
应用层负责「这些数据代表什么业务含义」。

Unix 网络编程的核心是理解 Socket API 的调用顺序、IO 模型、以及 TCP 连接的生命周期。写出稳定的网络程序，不在于记住所有参数，而在于理解：

连接是什么时候建立的，什么时候关闭的。
数据是怎么流动的，会不会被截断、会不会粘包。
异常情况下系统会怎么表现，程序能不能正确处理。

希望这份总结能帮你把《TCP/IP 详解》里的知识点串成一张网，少踩一些网络编程里的经典大坑。