计算机网络与前后端通信

核心主线：

应用层协议规定“怎么说话” → 传输层负责“怎么传” → 网络层负责“送到哪里” → 数据链路层负责“这一跳怎么送” → 物理层负责“真正变成信号传出去”。

1. 协议

协议（Protocol）可以理解为通信双方共同遵守的一套规则。

它规定：

消息的组织方式
消息内容的含义
发送方是谁、接收方是谁
定义通信的成功和失败，以及失败后的处理方式

例如：

HTTP：规定发送方（Web 客户端）和接收方（服务器）怎么交流
TCP/UDP：规定数据传输是否可靠（建立连接丢包重传保证顺序/不建立连接直接发）
IP：规定如何寻址和进行网络间转发
ARP：帮助在局域网中根据 IP 找到对应的 MAC 地址

所以：

协议 ≈ 通信双方共同遵守的“语言规则”。

2. OSI 七层模型

OSI 模型把网络通信抽象成七层：

层	名称	主要解决什么
7	应用层	应用程序之间怎么交流
6	表示层	数据如何表示、编码、加密、压缩
5	会话层	管理通信会话
4	传输层	端到端的数据传输
3	网络层	寻址、路由
2	数据链路层	相邻设备之间如何传输
1	物理层	真正传输比特的物理信号

重点记三个：

HTTP    → 应用层
TCP/UDP → 传输层
IP      → 网络层

3. 实际网络模型

实际互联网开发中，经常使用 TCP/IP 模型，而不是严格使用 OSI 七层模型。

可以简单理解成：

HTTP（应用层）
 ↓
TCP / UDP（传输层）
 ↓
IP（网络层）
 ↓
Wi-Fi / Ethernet（网络接口层）
 ↓
电信号 / 无线信号（物理介质）

OSI 七层更多是一种理解网络的理论模型，现实协议并不会严格一层对应一个协议。

4. 数据的传输封装

封装（Encapsulation）

发送数据的时候：

应用层：（HTTP 数据）
            ↓ 加 TCP 头
传输层：（TCP 头 + HTTP 数据）
            ↓ 加 IP 头
网络层：（IP 头 + TCP 头 + HTTP 数据）
            ↓ 加链路层头部
数据链路层：帧头 + IP 包 + 帧尾
            ↓ 二进制数据
物理层：电信号 / 光信号 / 无线信号

接收端则反过来（解封装）：

物理信号
 ↓
数据链路层拆帧
 ↓
网络层处理 IP
 ↓
传输层处理 TCP/UDP
 ↓
应用层解析 HTTP
 ↓
应用程序得到真正的数据

6. HTTP介绍

HTTP：HyperText Transfer Protocol，超文本传输协议

应用层协议：规定客户端和服务器之间如何交流，是一套公开的通信规则。

例如，客户端发送：

GET /api/user/123 HTTP/1.1
Host: example.com

服务器返回：

HTTP/1.1 200 OK
{
    "name": "Tom"
}

HTTP 标准

请求方法

GET
POST
PUT
DELETE
HEAD
OPTIONS
...

状态码

200 → 成功
301/302 → 重定向
400 → 请求错误
401 → 未认证
403 → 禁止访问
404 → 找不到资源
500 → 服务器错误

请求头

例如：

Host
Content-Type
Authorization
Cookie
User-Agent
...

响应头

例如：

Content-Type
Content-Length
Set-Cookie
Cache-Control
...

基本任何编程语言都可以实现 HTTP

HTTP 标准
   ↓
各个程序员/公司按照标准实现
   ↓
Java HTTP 库
Python HTTP 库
Android HTTP 库
浏览器
Spring
Nginx
...

8. GET 和 Controller 是什么关系？

这是前后端开发里非常重要的一点。

假设前端发送：

GET /api/user/123

这里：

GET

是 HTTP 标准规定的请求方法。

而：

/api/user/123

是这个 Web API 的路径。

后端 Spring Boot 可以写：

@GetMapping("/api/user/{id}")
public User getUser(...) {
    ...
}

于是：

前端
 ↓
发送 HTTP GET 请求
 ↓
GET /api/user/123
 ↓
服务器
 ↓
Spring MVC
 ↓
匹配 @GetMapping
 ↓
Controller 方法执行
 ↓
返回数据
 ↓
HTTP Response
 ↓
前端

因此：

HTTP 是通信规则，GET 是 HTTP 定义的一种请求方法，API 是后端提供的接口，Controller 是服务器中负责处理这个请求的代码。

9. 前后端通信本质是什么？

例如一个前端页面请求用户信息：

前端
  ↓
HTTP GET
  ↓
/api/user/123
  ↓
后端 Controller
  ↓
业务逻辑
  ↓
数据库
  ↓
生成 JSON
  ↓
HTTP Response
  ↓
前端

底层又可以继续往下展开：

HTTP
 ↓
TCP
 ↓
IP
 ↓
链路层
 ↓
物理层

所以：

前后端通信最常见的应用层协议就是 HTTP/HTTPS。

10. 本地前后端也可以使用 HTTP

例如：

前端：
localhost:3000

后端：
localhost:8080

前端请求：

http://localhost:8080/api/user

依然可以使用 HTTP。

如果 HTTP 使用 TCP，那么大致可以理解成：

HTTP
 ↓
TCP
 ↓
IP（127.0.0.1）
 ↓
本机回环网络
 ↓
后端程序

数据实际上没有离开电脑。

11. HTTP 和 HTTPS

HTTP

HTTP
 ↓
TCP
 ↓
IP

数据通常是明文传输。

HTTPS

可以简单理解成：

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

TLS 提供：

加密
防止数据被篡改
服务器身份验证

所以：

HTTPS ≈ HTTP + TLS

12. TLS 是什么？

TLS：

Transport Layer Security

它负责保护网络通信。

主要解决三个问题：

① 保密

别人截获数据，也不能直接看懂。

② 防篡改

防止数据在传输过程中被偷偷修改。

③ 身份验证

帮助确认：

“我连接的服务器确实是我要访问的服务器。”

13. TCP 和 UDP

TCP 和 UDP 都属于：

传输层协议

它们主要解决：

数据怎么从一个程序传到另一个程序。

TCP

TCP 强调可靠性。

具有：

建立连接
数据确认
重传
顺序控制
流量控制等

可以粗略想成：

“先建立可靠的通信关系，再传数据。”

UDP

UDP 更简单。

它不会像 TCP 那样提供完整的可靠传输机制。

特点：

无连接
开销小
延迟低
不保证一定到达
不保证顺序

所以：

TCP → 更强调可靠
UDP → 更强调低延迟、简单

14. TCP/UDP 和 HTTP 的关系

这里非常容易混淆。

TCP/UDP 和 HTTP 不是同一个层次的东西。

应用层：
HTTP
WebSocket
DNS
自定义游戏协议
...

传输层：
TCP
UDP

所以：

TCP/UDP 负责“怎么传”，应用层协议负责“数据是什么意思、怎么组织”。

例如：

HTTP：
GET /user/123

HTTP 决定这句话的格式和含义。

TCP 负责把这些数据可靠地传过去。

15. WebSocket 和 HTTP

WebSocket 是一种应用层通信协议。

它和普通 HTTP 最大的区别之一，是通信模式不同。

HTTP

典型模式：

客户端 → 请求
服务器 → 响应

例如：

客户端：我要用户信息
服务器：给你 JSON

WebSocket

建立连接后，可以进行持续的双向通信：

客户端 ←→ 服务器
       ←→
       ←→
       ←→

服务器可以主动给客户端发送消息。

因此适合：

实时聊天
实时通知
实时状态更新
某些实时应用

16. 不使用 HTTP 的场景怎么办？

HTTP 只是应用层协议之一。

其他场景可以使用：

HTTP
WebSocket
TCP 自定义协议
UDP 自定义协议
gRPC
RTP
WebRTC
Unix Socket
...

例如：

场景	常见技术
普通网页	HTTP/HTTPS
前后端 API	HTTP/HTTPS
实时聊天	WebSocket 等
游戏	TCP/UDP + 自定义协议等
音视频实时通信	RTP/WebRTC 等
本机进程通信	Unix Socket 等
服务间通信	HTTP、gRPC 等

17. 游戏是怎么通信的？

例如多人游戏：

玩家 A
 ↓
游戏服务器
 ↓
玩家 B

客户端可能发送：

玩家位置
玩家方向
操作状态
...

服务器再进行：

接收
 ↓
判断
 ↓
更新游戏状态
 ↓
广播给其他玩家

游戏可以使用：

UDP
+
自定义游戏协议

也可能使用 TCP 或其他方案。

关键是：

UDP/TCP 负责传输，游戏自己定义的数据格式负责表达“玩家移动了”“开火了”等含义。

18. 微信聊天的基本原理

聊天软件的核心并不是简单的：

手机 A ←→ 手机 B

而更常见的是：

手机 A
   ↓
微信服务器
   ↓
手机 B

例如 A 发：

“你好”

大致过程：

A 手机
 ↓
聊天客户端
 ↓
微信服务器
 ↓
服务器判断 B 是谁
 ↓
找到 B 的连接/消息投递路径
 ↓
B 手机
 ↓
聊天客户端
 ↓
显示“你好”

大型聊天系统背后会使用大量服务器组成分布式集群。

所以不是：

“一台服务器连接十几亿人。”

而是：

大量服务器共同承担连接、消息路由、存储、推送等工作。

具体使用哪些内部协议和架构属于大型系统的实现细节，不需要把它简单等同于某一个 HTTP 或 WebSocket。

19. 音视频通信

音视频又是一个很好的例子，因为：

数据的“内容编码”和“网络通信协议”是两回事。

例如视频：

摄像头
 ↓
视频编码
 ↓
H.264 / H.265 / AV1 等
 ↓
通过通信协议传输
 ↓
网络
 ↓
接收端
 ↓
解码
 ↓
屏幕

这里：

H.264

主要解决：

视频数据怎么编码。

而：

RTP / WebRTC 等

解决的是：

实时音视频如何进行网络通信。

20. 数据链路层是什么？

数据链路层主要解决：

相邻设备之间，这一跳怎么传数据。

例如：

电脑
 ↓
Wi-Fi
 ↓
路由器

这就是一条链路。

数据链路层常见概念：

MAC 地址
Frame（帧）
Ethernet（以太网）
Wi-Fi
ARP 等相关机制

21. 为什么已经有 IP，还需要链路层？

因为：

IP 解决的是“网络层面的目的地和路由”，而链路层解决的是“当前这一跳怎么把数据交给相邻设备”。

例如：

电脑
 ↓
路由器 A
 ↓
路由器 B
 ↓
路由器 C
 ↓
服务器

IP 负责：

最终要去服务器

而链路层负责：

这一跳到底怎么交给旁边这个设备？

22. 帧为什么是一跳一变？

这是理解链路层的关键。

假设：

电脑 A
 ↓
路由器
 ↓
服务器

A → 路由器：

帧
MAC A → MAC 路由器
IP A  → IP 服务器

路由器收到以后，会重新封装下一跳的链路层帧：

帧
MAC 路由器 → MAC 下一跳
IP A       → IP 服务器

所以：

IP 包可以一路向最终目的地传递，而链路层的帧通常是“一跳一换”。

23. ARP 是什么？

ARP：

Address Resolution Protocol

它解决一个很实际的问题：

已经知道目标的 IP 地址，但是我怎么知道它对应的 MAC 地址？

例如：

我知道：
192.168.1.20

但我要在局域网里发帧，
还需要知道：

对应的 MAC 地址是多少？

ARP 就可以帮助完成这个映射。

可以粗略理解：

IP 地址
 ↓ ARP
MAC 地址

因此 ARP 和数据链路层密切相关，但严格划分时，它并不完全等同于传统 OSI 二层协议。

24. MAC 地址是什么？

MAC 地址可以简单理解成：

网络接口在局域网通信中的链路层地址。

例如：

电脑网卡
 ↓
MAC 地址

而 IP 是：

网络层地址

所以：

MAC → 主要用于一跳通信
IP  → 用于网络间寻址和路由

25. 交换机是什么？

交换机主要工作在数据链路层。

它主要处理：

MAC 地址
Frame（帧）

例如：

电脑 A ─┐
电脑 B ─┼─ 交换机
电脑 C ─┘

交换机会学习：

MAC A → 端口 1
MAC B → 端口 2
MAC C → 端口 3

收到一个帧以后，根据目标 MAC 地址决定：

应该从哪个端口发出去。

26. 路由器是什么？

路由器主要关注：

IP 地址

它负责不同网络之间的数据转发。

例如：

局域网
   ↓
路由器
   ↓
互联网
   ↓
服务器所在网络

路由器根据 IP 和路由表决定：

下一步往哪里走。

27. 交换机 vs 路由器

最简单的记忆方式：

	交换机	路由器
主要关注	MAC	IP
主要处理	帧	IP 包
主要作用	局域网内部转发	不同网络之间转发
典型层次	数据链路层	网络层

可以记成：

交换机 → MAC → 局域网内怎么走

路由器 → IP → 不同网络之间怎么走

28. 交换机是不是必须的？

不一定。

例如家里的设备：

手机
  ↓ Wi-Fi
路由器

不需要额外买一个交换机。

或者：

电脑
  ↓ 网线
路由器

也可以直接通信。

交换机主要是在：

需要连接很多有线设备时扩展网络。

而且现实中的家用路由器往往已经把：

路由器
+ 交换机
+ Wi-Fi AP

等功能集成在一个设备里。

29. 最后把整个知识体系串起来

假设：

你在浏览器输入一个网站，然后请求服务器。

整个过程可以粗略画成：

                 应用层
┌─────────────────────────────┐
│ HTTP / HTTPS                │
│ “我要 /api/user/123”        │
└──────────────┬──────────────┘
               ↓
                 传输层
┌─────────────────────────────┐
│ TCP / UDP                   │
│ “我负责把数据传过去”         │
└──────────────┬──────────────┘
               ↓
                 网络层
┌─────────────────────────────┐
│ IP                          │
│ “我要去哪个 IP”              │
└──────────────┬──────────────┘
               ↓
               数据链路层
┌─────────────────────────────┐
│ Ethernet / Wi-Fi / MAC      │
│ “这一跳交给哪个设备”         │
└──────────────┬──────────────┘
               ↓
                 物理层
┌─────────────────────────────┐
│ 电信号 / 光 / 无线信号       │
│ “真正把比特传出去”           │
└─────────────────────────────┘

而中间如果经过多个路由器：

电脑
 ↓
交换机 / Wi-Fi
 ↓
路由器
 ↓
互联网
 ↓
路由器
 ↓
服务器

IP 负责整个旅程的寻址和路由；链路层负责每一跳；TCP负责端到端传输；HTTP负责应用之间怎么交流。

30. 最值得记住的一张图

             “说什么？”
                  ↓
        ┌─────────────────┐
        │ HTTP / WebSocket │
        │    应用层        │
        └────────┬────────┘
                 ↓
             “怎么传？”
                 ↓
        ┌─────────────────┐
        │   TCP / UDP     │
        │    传输层       │
        └────────┬────────┘
                 ↓
             “去哪儿？”
                 ↓
        ┌─────────────────┐
        │       IP        │
        │     网络层      │
        └────────┬────────┘
                 ↓
           “这一跳怎么走？”
                 ↓
        ┌─────────────────┐
        │ Ethernet / Wi-Fi│
        │    链路层       │
        └────────┬────────┘
                 ↓
             “怎么变成信号？”
                 ↓
        ┌─────────────────┐
        │    物理层       │
        │ 电/光/无线信号   │
        └─────────────────┘

一句话总结：

应用层决定“数据说什么、长什么样”；传输层决定“端到端怎么传”；网络层决定“往哪台机器/哪个网络走”；链路层决定“这一跳交给谁”；物理层负责“真的把 0 和 1 变成信号传出去”。

这套框架一旦理解了，你后面再学 DNS、HTTP、HTTPS、WebSocket、RPC、游戏协议、音视频协议、Nginx、前后端部署，基本都可以把它们放到这张图里的相应位置。

31. HTTP、TCP、UDP 的连接与握手流程

31.1 HTTP 本身有没有“握手”？

要先区分：

HTTP 是应用层协议，TCP 是传输层协议。

传统 HTTP/1.1 通常运行在 TCP 上，所以你访问一个 HTTP 网站时，通常是：

HTTP
 ↓
TCP
 ↓
IP

因此我们经常看到“HTTP 请求之前先 TCP 三次握手”。

但严格来说：

三次握手是 TCP 的，不是 HTTP 的。

HTTP 自己主要负责的是：

请求 → 响应

例如：

客户端                    服务器
  │                         │
  │──── HTTP GET ──────────>│
  │                         │
  │<─── HTTP 200 + 数据 ────│

32. TCP 三次握手

TCP 是面向连接的协议。

在真正传输数据之前，客户端和服务器需要先建立 TCP 连接。

经典的三次握手：

客户端                              服务器
  │                                  │
  │──── SYN ────────────────────────>│
  │                                  │
  │<─── SYN + ACK ──────────────────│
  │                                  │
  │──── ACK ────────────────────────>│
  │                                  │
  │        TCP连接建立                │

TCP 建立连接之后，双方就可以传数据：

客户端                         服务器
  │                              │
  │──── 数据 ──────────────────>│
  │<─── ACK ───────────────────│
  │                              │
  │──── 数据 ──────────────────>│
  │<─── ACK ───────────────────│

TCP 提供：

可靠传输
按序交付
重传
流量控制
拥塞控制

33. 为什么需要三次？

核心是：

让双方都确认彼此的发送和接收能力正常，同时同步连接状态。

简化过程可以理解成：

① DNS
   ↓
找到服务器 IP

② TCP 三次握手
   ↓
建立 TCP 连接

③ TLS 握手
   ↓
建立安全加密通信

④ HTTP 请求
   ↓
GET /index.html

⑤ HTTP 响应
   ↓
200 OK + 网页数据

36. TCP 四次挥手

TCP 连接不是永远存在的。

通信结束时，需要关闭连接。

经典过程叫：

四次挥手

简化：

客户端                              服务器
  │                                  │
  │──── FIN ────────────────────────>│
  │                                  │
  │<─── ACK ────────────────────────│
  │                                  │
  │<─── FIN ────────────────────────│
  │                                  │
  │──── ACK ────────────────────────>│
  │                                  │
  │          连接关闭                 │

37. UDP 有没有握手？

UDP 没有 TCP 那样的三次握手。

UDP 是：

无连接的传输协议。

例如：

客户端                         服务器
  │                              │
  │──── UDP 数据 ──────────────>│
  │──── UDP 数据 ──────────────>│
  │──── UDP 数据 ──────────────>│

不需要：

SYN
SYN + ACK
ACK

因此 UDP 开销更小，发送数据更加直接。