OSI Model

OSI Model 是一个逻辑/概念模型，用来定义 network communication。Open System Interconnection (OSI Model) 描述了计算机 packet 传输时各层协议的分工与边界，标准文本是 ITU-T X.200（与 ISO/IEC 7498-1 等同）。

可以把 OSI Model 看成 computer networking 的「通用语言」。它把一个复杂的通信系统拆成 7 层，每一层叠在上一层之上。

面试里 OSI 本身很少单独考，真正用到它的是两个问题：一个负载均衡器或代理工作在第几层、因此能看到哪些信息；线上出问题时从哪一层开始排查。 本章围绕这两个问题展开。

有约束的设计问题

一个服务有三种入口流量：

1. 浏览器访问的 HTTPS API，要按路径把 /api/orders 和 /api/users 分到不同后端，并按用户做限流。
2. 手机 App 的长连接，走自定义二进制协议（跑在 TCP 上），单机要承载几十万条连接。
3. 客户端直连的 PostgreSQL（TCP 5432），只需要分流到只读副本。

三种流量该用 L4 还是 L7 的负载均衡？出了「连不上」的故障，又该怎么逐层定位？

Why does the OSI model matter?

OSI model 定义了网络讨论里的通用术语，帮助我们把复杂通信过程拆开分析各组件的作用。

现代网络实际跑的是 TCP/IP 协议族。RFC 1122 把它分为 4 层：Link、Internet、Transport、Application，OSI 的 5–7 层在 TCP/IP 里合并为应用层。尽管如此，OSI 依然能帮助我们：

• 更容易 troubleshooting，定位整个 stack 上的问题与威胁
• 让不同厂商的 networking 产品更容易互通
• 帮助形成 security-first 的思维方式
• 把复杂功能拆成更小的组件

工程师口头说的「L4」「L7」就是沿用 OSI 编号：L4 指 TCP/UDP 这一层，L7 指 HTTP、gRPC 这类应用协议。

Layers

OSI 的 7 层从上到下如下：

Application

这是唯一直接和用户数据交互的层。像 browser、email client 这类软件依赖 Application layer 来发起通信。注意：client app 本身不属于 Application layer，应用层关注的是协议和数据处理。常见协议有 HTTP、SMTP、DNS 等。

Presentation

Presentation layer 也叫 Translation layer。它负责把 application layer 的数据转换成可在网络上传输的格式，常见职责包括 translation、encryption/decryption、compression。

TLS 放在哪一层没有统一答案：它提供加密，符合 Presentation 的描述；但它跑在 TCP 之上、HTTP 之下，而 TCP/IP 模型里根本没有第 6 层。面试时说「TLS 在传输层和应用层之间」即可，不要硬套。

Session

Session layer 负责建立/关闭两端通信。通信开启到关闭之间就是一个 session。该层保证 session 足够长以完成数据传输，结束后及时关闭以避免浪费资源，同时还会做 checkpoint 的同步。在 TCP/IP 里，这些职责通常由应用协议自己承担。

Transport

Transport layer（Layer 4）负责端到端通信：把上层数据拆成 segments，交给 Network layer（Layer 3），并在接收端把 segments 重新组装。TCP 和 UDP 在这一层，端口号也在这一层，所以 L4 设备能看到「源 IP:端口 → 目标 IP:端口」和协议，看不到 URL。详见 TCP 与 UDP。

Network

Network layer 负责不同 networks 之间的数据传输。它把 transport layer 的 segments 封装成 packets，负责寻址和 routing（选择路径）。IP 和 ICMP 在这一层。若两端在同一 network，数据不需要经过路由器转发。

Data Link

Data link layer 负责同一网络内相邻设备之间的传输，把 packets 封装成 frames，用 MAC 地址寻址。以太网和交换机（switch）工作在这一层。以太网常见的 MTU 是 1500 字节，减去 20 字节 IPv4 头和 20 字节 TCP 头，每个 TCP segment 最多带 1460 字节数据（MSS）。

Physical

Physical layer 负责把 bit stream（0/1）变成电信号、光信号或无线信号，包括线缆、光纤、网卡的物理接口，以及集线器、中继器这类只转发信号的设备。两端必须遵循相同的信号规范，才能区分 1 和 0。

L4 和 L7 负载均衡：能看到什么，就能做什么

AWS 文档对 NLB 的描述是「functions at the fourth layer of the OSI model」，可处理每秒数百万请求；ALB 工作在第 7 层，按请求内容（路径、Host、Header）路由。

用 Nginx 也能直观看到区别：stream {} 块是 L4 代理，http {} 块是 L7 代理。

# L4：只按连接转发，不认识 HTTP，适合 PostgreSQL 和自定义 TCP 协议
stream {
  upstream pg_replicas {
    server 10.0.2.11:5432;
    server 10.0.2.12:5432;
  }
  server {
    listen 5432;
    proxy_pass pg_replicas;
  }
}

# L7：终止 TLS，按路径分到不同服务
http {
  server {
    listen 443 ssl;
    location /api/orders/ { proxy_pass http://orders_backend; }
    location /api/users/  { proxy_pass http://users_backend; }
  }
}

注意 L4 转发时后端看到的源地址可能是代理的地址，要拿真实客户端 IP 需要 PROXY protocol（Nginx stream 支持 proxy_protocol on）；L7 则通过 X-Forwarded-For 之类的 Header 传递，见 Reverse Proxy。

回到场景

常见组合是两层叠加：最外层 L4 负责扛连接和 TLS 透传或终止，后面一层 L7 负责路由和策略。

按层排障

「连不上」时从下往上，每层一个命令，哪层先失败就是哪层的问题：

ping api.example.com                  # L3：IP 可达吗（很多云环境默认禁 ICMP，不通不代表挂了）
traceroute api.example.com            # L3：在哪一跳断掉
nc -vz api.example.com 443            # L4：端口能建立 TCP 连接吗
openssl s_client -connect api.example.com:443 -servername api.example.com  # TLS：握手和证书
curl -v https://api.example.com/health  # L7：HTTP 状态码和响应头

常见翻车

面试时这样回答

1. 先说层：「这个负载均衡放在 L4 还是 L7，取决于要不要读 HTTP 内容。」
2. 说能力差异：L4 只看 IP 和端口、按连接分发、开销低；L7 能按路径和 Header 路由、限流、鉴权，但要终止 TLS、解析协议。
3. 落到流量：HTTP API 用 L7；自定义 TCP 长连接和数据库用 L4；大系统两层叠加。
4. 说一个代价：L4 后端拿不到客户端 IP，要 PROXY protocol；L7 多一次 TLS 终止和连接开销。
5. 排障顺序：ping / nc / openssl / curl 逐层往上，哪层先失败查哪层。

相关章节：TCP 与 UDP、IP、Load Balancer、Reverse Proxy、SSL / TLS / mTLS、Networking Essentials。

一手证据

• ITU-T X.200：OSI Basic Reference Model
• RFC 1122：Requirements for Internet Hosts
• Nginx：ngx_stream_proxy_module
• Nginx：ngx_http_proxy_module
• AWS：What is a Network Load Balancer?
• AWS：What is an Application Load Balancer?
• HAProxy：The PROXY protocol