在 TCP/IP 四层模型中，应用层位于最上层，直接面向网络应用和用户需求。

应用层规定通信双方交换什么数据、数据具有什么含义，以及应该按照什么规则进行交互。

常见的 HTTP、HTTPS、DNS、DHCP、SSH 等协议都属于这一层。理解应用层之后，TCP/IP 四层模型就形成了一条完整的数据通信链路。

应用层是什么#

TCP/IP 四层模型：

1
┌────────────────────┐
2
│      应用层        │
3
├────────────────────┤
4
│      传输层        │
5
├────────────────────┤
6
│      网际层        │
7
├────────────────────┤
8
│    网络接口层      │
9
└────────────────────┘

前面已经介绍：

1
网络接口层
2
↓
3
如何在当前链路上传输
4

5
网际层
6
↓
7
如何跨网络寻找目标
8

9
传输层
10
↓
11
如何在主机之间进行进程通信

而应用层进一步解决：

通信双方到底要交换什么信息，以及应该如何理解这些信息。

例如：

1
浏览器 ↔ Web Server

双方需要约定：

1
请求是什么格式
2
响应是什么格式
3
状态码是什么意思
4
请求头怎么表示
5
数据怎么表示

这就是应用层协议的作用。

因此：

1
应用层
2
↓
3
定义通信规则和数据语义
4

5
传输层
6
↓
7
负责进程之间的数据传输
8

9
网际层
10
↓
11
负责 IP 寻址和转发
12

13
网络接口层
14
↓
15
负责具体链路传输

应用层与应用程序#

需要注意：

应用层协议 ≠ 应用程序本身。

例如：

1
Chrome
2
Firefox
3
curl

这些是应用程序。

而：

1
HTTP

是应用层协议。

可以理解成：

1
应用程序
2
   │
3
   ▼
4
应用层协议
5
   │
6
   ▼
7
TCP / UDP
8
   │
9
   ▼
10
IP
11
   │
12
   ▼
13
Ethernet

例如：

1
Chrome
2
 ↓
3
HTTP
4
 ↓
5
TCP
6
 ↓
7
IP
8
 ↓
9
Ethernet

因此：

应用层协议规定“怎么交流”，应用程序则负责利用这些协议完成具体功能。

协议与数据格式#

应用层协议通常需要定义：

1
消息格式
2
字段含义
3
请求方式
4
响应方式
5
错误处理
6
状态
7
数据编码

例如一个 HTTP 请求：

1
GET /index.html HTTP/1.1
2
Host: example.com

这里不仅有：

1
请求方法

还有：

1
资源路径
2
协议版本
3
请求头

服务器必须按照 HTTP 的规则解释这些字段。

所以：

应用层协议的核心是建立双方都能够理解的通信语义。

应用层协议的分类#

应用层协议种类非常多，可以按用途粗略划分：

1
Web
2
├── HTTP
3
└── HTTPS
4

5
名称解析
6
└── DNS
7

8
地址配置
9
└── DHCP
10

11
远程管理
12
└── SSH
13

14
文件传输
15
├── FTP
16
└── TFTP
17

18
邮件
19
├── SMTP
20
├── POP3
21
└── IMAP
22

23
时间同步
24
└── NTP

本文重点介绍：

1
HTTP
2
HTTPS
3
DNS
4
DHCP
5
SSH

它们在实际 Linux / 运维工作中非常常见。

HTTP#

什么是 HTTP#

HTTP（Hypertext Transfer Protocol）是 Web 中最重要的应用层协议之一。

它用于：

1
客户端
2
   ↕
3
服务器

之间交换资源。

典型场景：

1
浏览器
2
   │
3
   │ HTTP Request
4
   ▼
5
Web Server
6
   │
7
   │ HTTP Response
8
   ▼
9
浏览器

HTTP 是一种：

请求—响应（Request / Response）协议。

HTTP 请求#

一个典型 HTTP 请求可以简化为：

1
Request Line
2
Headers
3
Blank Line
4
Body

例如：

1
GET /index.html HTTP/1.1
2
Host: example.com
3
User-Agent: curl/8.x
4
Accept: */*

其中：

1
GET
2
↓
3
请求方法
4

5
/index.html
6
↓
7
目标资源
8

9
HTTP/1.1
10
↓
11
协议版本

HTTP 方法#

常见 HTTP 方法包括：

1
GET
2
POST
3
PUT
4
PATCH
5
DELETE
6
HEAD
7
OPTIONS

最常见的有：

GET#

通常用于：

获取资源。

例如：

1
GET /index.html HTTP/1.1

POST#

通常用于：

向服务器提交数据或触发某种处理。

例如：

1
POST /login HTTP/1.1

请求体可能包含：

1
username
2
password

等数据。

PUT#

通常用于：

创建或整体更新某个资源。

PATCH#

通常用于：

对资源进行部分修改。

DELETE#

通常用于：

删除资源。

HTTP 响应#

服务器处理请求后会返回：

1
Response Status
2
Headers
3
Blank Line
4
Body

例如：

1
HTTP/1.1 200 OK
2
Content-Type: text/html
3
Content-Length: 1234
4

5
<html>
6
...
7
</html>

其中：

1
200
2
↓
3
状态码
4

5
OK
6
↓
7
原因短语

HTTP 状态码#

HTTP 状态码通常分为：

1
1xx
2
2xx
3
3xx
4
4xx
5
5xx

可以简单理解为：

状态码范围	含义
`1xx`	信息响应
`2xx`	请求成功
`3xx`	重定向
`4xx`	客户端请求问题
`5xx`	服务器处理问题

常见状态码：

1
200 OK
2
201 Created
3
204 No Content
4

5
301 Moved Permanently
6
302 Found
7
304 Not Modified
8

9
400 Bad Request
10
401 Unauthorized
11
403 Forbidden
12
404 Not Found
13

14
500 Internal Server Error
15
502 Bad Gateway
16
503 Service Unavailable
17
504 Gateway Timeout

其中尤其值得注意：

1
4xx

并不简单等于：

“网络有问题”。

它表示服务器收到了请求，但请求通常存在客户端侧的问题。

而：

1
5xx

通常表示服务器端处理过程中出现问题。

HTTP Header#

HTTP 中大量信息通过：

Header（首部）

传输。

例如：

1
Host: example.com
2
Content-Type: application/json
3
Content-Length: 123
4
User-Agent: curl/8.x
5
Authorization: Bearer ...

常见作用包括：

1
身份信息
2
内容类型
3
内容长度
4
缓存
5
压缩
6
连接控制
7
认证

因此：

1
HTTP Message
2
│
3
├── Start Line
4
├── Headers
5
├── Blank Line
6
└── Body

是理解 HTTP 报文结构的重要基础。

HTTP Body#

Body 是真正承载内容的区域。

例如：

1
HTML
2
JSON
3
图片
4
文件

都可以作为 HTTP Body。

例如：

1
Content-Type: application/json
2

3
{
4
  "name": "Alice"
5
}

这里：

1
Content-Type

告诉接收方：

Body 中的数据是什么类型。

HTTP 与 TCP#

在传统 HTTP/1.1 和 HTTP/2 部署中，HTTP 通常运行在：

1
TCP

之上。

可以简化成：

1
HTTP
2
 ↓
3
TCP
4
 ↓
5
IP
6
 ↓
7
Ethernet

因此：

1
HTTP

负责：

1
Web 通信规则

而：

1
TCP

负责：

1
可靠传输

两者是不同层次的协议。

HTTPS#

什么是 HTTPS#

HTTPS 可以理解为：

HTTP over TLS

即：

1
HTTP
2
 ↓
3
TLS
4
 ↓
5
TCP

TLS 提供：

1
加密
2
身份认证
3
完整性保护

因此：

1
HTTP
2
↓
3
明文应用层协议
4

5
HTTPS
6
↓
7
HTTP + TLS

HTTPS 并不是一个与 HTTP 完全无关的新应用层协议，而是使用 TLS 对 HTTP 通信进行保护。

HTTPS 的基本过程#

可以简化成：

1
Client
2
   │
3
   │ TCP Connection
4
   ▼
5
Server
6
   │
7
   │ TLS Handshake
8
   ▼
9
建立安全通道
10
   │
11
   ▼
12
HTTP Request / Response

因此：

1
TCP
2
 ↓
3
建立传输连接
4

5
TLS
6
 ↓
7
建立安全通信通道
8

9
HTTP
10
 ↓
11
交换 Web 数据

TLS#

TLS（Transport Layer Security）是一种安全协议，用于在通信双方之间建立安全通道。

它主要提供：

1
机密性
2
完整性
3
身份认证

其中：

机密性#

防止通信内容被第三方直接读取。

1
明文
2
 ↓
3
加密
4
 ↓
5
密文

完整性#

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

可以理解为：

1
发送数据
2
 ↓
3
完整性保护
4
 ↓
5
接收端验证

身份认证#

通常通过：

1
数字证书

帮助客户端验证服务器身份。

因此浏览器访问：

1
https://example.com

时，会涉及：

1
TLS
2
+
3
Certificate

等机制。

DNS#

什么是 DNS#

DNS（Domain Name System）用于：

将域名映射为网络中的地址信息。

例如：

1
www.example.com
2
        ↓
3
DNS
4
        ↓
5
93.184.216.34

这样用户不需要记住：

1
93.184.216.34

而可以使用：

1
www.example.com

为什么需要 DNS#

人类更容易记住：

1
www.example.com

而网络通信需要：

1
IP Address

因此 DNS 提供了：

1
Domain Name
2
     ↓
3
DNS
4
     ↓
5
IP Address

但需要注意：

DNS 并不只是简单的“域名转 IP”。

它实际上是一个分布式的名称系统。

DNS 还可以提供：

1
A
2
AAAA
3
CNAME
4
MX
5
NS
6
TXT
7
SRV

等不同类型的记录。

DNS 查询#

例如客户端需要解析：

1
www.example.com

可能会向 DNS 服务器发起：

1
DNS Query

查询：

1
www.example.com

的：

1
A

记录。

DNS Server 返回：

1
93.184.216.34

可以简化成：

1
Client
2
   │
3
   │ Query
4
   ▼
5
DNS Resolver
6
   │
7
   │ Answer
8
   ▼
9
Client

DNS Record#

常见 DNS 记录：

类型	作用
`A`	域名 → IPv4
`AAAA`	域名 → IPv6
`CNAME`	别名
`MX`	邮件服务器
`NS`	权威名称服务器
`TXT`	文本信息
`SRV`	服务位置

例如：

1
example.com
2
   │
3
   ├── A → 192.0.2.1
4
   ├── AAAA → 2001:db8::1
5
   └── MX → mail.example.com

DNS 的层次结构#

DNS 并不是一个：

1
全世界只有一台服务器

而是一个分布式层级系统。

可以简化为：

1
Root
2
 │
3
 ├── .com
4
 ├── .org
5
 └── .net
6
      │
7
      ▼
8
example.com
9
      │
10
      ▼
11
www.example.com

其中：

1
Root
2
↓
3
根 DNS
4

5
TLD
6
↓
7
顶级域
8

9
Authoritative DNS
10
↓
11
权威 DNS

DNS 缓存#

如果每次访问：

1
www.example.com

都从根服务器开始查找，效率会非常低。

因此 DNS 大量使用：

缓存（Caching）

可以理解成：

1
第一次查询
2
   ↓
3
DNS Resolution
4
   ↓
5
得到结果
6
   ↓
7
缓存
8

9
再次查询
10
   ↓
11
直接使用缓存

DNS 记录通常存在：

1
TTL

表示缓存可以保留多长时间。

因此修改 DNS 后并不一定能够立即在所有网络中看到变化。

DNS 与 TCP / UDP#

传统 DNS 查询最常见的传输方式是：

1
UDP
2
53

但 DNS 也可以使用：

1
TCP
2
53

TCP 在 DNS 中并不是简单的“旧协议”。

例如：

1
响应过大
2
区域传送
3
特定 DNS 场景

都可能使用 TCP。

此外，现代 DNS 还存在：

1
DoT
2
DoH
3
DoQ

等更现代的传输方式。

其中：

1
DoT
2
↓
3
DNS over TLS
4

5
DoH
6
↓
7
DNS over HTTPS
8

9
DoQ
10
↓
11
DNS over QUIC

它们的重点是：

对 DNS 通信本身进行不同形式的传输或加密封装。

DHCP#

什么是 DHCP#

DHCP（Dynamic Host Configuration Protocol）用于：

向网络中的主机动态提供网络配置。

例如新设备接入网络后，可能需要获得：

1
IP 地址
2
子网掩码
3
默认网关
4
DNS 服务器
5
租期

这些配置可以通过 DHCP 自动获取。

DHCP 的基本过程#

IPv4 DHCP 初始化通常可以概括成经典的：

1
DHCP Discover
2
       ↓
3
DHCP Offer
4
       ↓
5
DHCP Request
6
       ↓
7
DHCP ACK

常被记成：

DORA

即：

1
Discover
2
Offer
3
Request
4
ACK

DHCP Discover#

新接入网络的客户端可能还没有自己的 IP。

于是发送：

1
DHCP Discover

寻找 DHCP Server。

可以理解成：

1
Client
2
  │
3
  │ 我需要网络配置
4
  ▼
5
广播 / DHCP Server

DHCP Offer#

DHCP Server 提供一个配置方案：

1
IP
2
Subnet Mask
3
Gateway
4
DNS
5
Lease Time

例如：

1
IP = 192.168.1.100
2
Mask = 255.255.255.0
3
Gateway = 192.168.1.1
4
DNS = 192.168.1.1

DHCP Request#

客户端表示：

我希望使用这个配置。

DHCP ACK#

服务器确认：

配置正式分配给你。

于是客户端获得：

1
IP Address
2
+
3
其他网络配置

DHCP 租约#

DHCP 并不是永久把 IP 地址交给客户端。

通常会存在：

Lease（租约）

例如：

1
IP
2
192.168.1.100
3

4
Lease
5
8 hours

到一定时间后客户端需要：

1
续租

否则地址最终可能重新进入地址池。

因此：

1
DHCP
2
↓
3
动态地址管理

非常适合：

1
家庭网络
2
办公网络
3
大型局域网
4
云环境

SSH#

什么是 SSH#

SSH（Secure Shell）是一种用于安全远程登录和管理的协议。

典型：

1
Client
2
   │
3
   │ SSH
4
   ▼
5
Server

例如：

1
ssh user@192.168.1.100

可以建立远程 Shell 会话。

SSH 通常运行在：

1
TCP 22

之上。

SSH 能做什么#

SSH 不只是：

1
远程登录

还可以进行：

1
远程命令执行
2
文件传输
3
端口转发
4
隧道

例如：

1
ssh user@server

远程执行：

1
ssh user@server "systemctl status nginx"

也可以通过：

1
scp
2
rsync
3
sftp

等工具完成文件传输。

SSH 认证#

SSH 常见认证方式包括：

1
密码认证
2
公钥认证

公钥认证可以理解为：

1
Client
2
 ├── Private Key
3
 └── Public Key

服务器保存：

1
authorized_keys

客户端通过私钥证明：

自己拥有对应的身份凭证。

因此：

1
Private Key
2
↓
3
必须妥善保护
4

5
Public Key
6
↓
7
可以放在服务器

在生产环境中，公钥认证通常比单纯密码登录更加适合自动化和安全管理。

FTP 与其他应用层协议#

除了：

1
HTTP
2
DNS
3
DHCP
4
SSH

应用层还有大量协议。

例如：

1
FTP
2
SMTP
3
IMAP
4
POP3
5
NTP
6
SNMP

它们分别解决不同的问题：

1
FTP
2
↓
3
文件传输
4

5
SMTP
6
↓
7
发送邮件
8

9
IMAP / POP3
10
↓
11
获取邮件
12

13
NTP
14
↓
15
时间同步
16

17
SNMP
18
↓
19
网络设备管理

这说明：

应用层并不等于 Web。

Web 只是应用层中非常重要的一部分。

应用层协议如何使用传输层#

不同应用协议可以运行在不同的传输层协议之上。

例如：

1
HTTP/1.1
2
 ↓
3
TCP
4

5
SSH
6
 ↓
7
TCP
8

9
DNS
10
 ↓
11
UDP / TCP
12

13
DHCP
14
 ↓
15
UDP

可以形成：

1
                   应用层
2
                     │
3
      ┌──────────────┼──────────────┐
4
      │              │              │
5
     HTTP           SSH            DNS
6
      │              │              │
7
      └──────┬───────┘              │
8
             ▼                      ▼
9
            TCP                    UDP
10
             │                      │
11
             └──────────┬───────────┘
12
                        ▼
13
                       IP
14
                        │
15
                        ▼
16
                   Ethernet

因此：

应用层协议并不需要自己重新实现 TCP/IP 的底层传输机制，而是建立在传输层提供的能力之上。

一个完整的 Web 请求#

假设用户在浏览器中输入：

1
https://example.com

可以从应用层开始向下理解。

首先需要解析：

1
example.com

于是：

1
DNS
2
 ↓
3
获得 IP

然后建立传输连接：

1
TCP

如果使用 HTTPS，还需要：

1
TLS

之后才发送：

1
HTTP Request

整个过程可以简化成：

1
用户
2
 ↓
3
浏览器
4
 ↓
5
DNS
6
 ↓
7
获得服务器 IP
8
 ↓
9
TCP
10
 ↓
11
TLS
12
 ↓
13
HTTP
14
 ↓
15
IP
16
 ↓
17
Ethernet
18
 ↓
19
服务器

服务器收到数据后则反过来：

1
Ethernet
2
 ↓
3
IP
4
 ↓
5
TCP
6
 ↓
7
TLS
8
 ↓
9
HTTP
10
 ↓
11
Web Server

这就是整个 TCP/IP 协议栈协同工作的一个典型例子。

应用层并不是“最上面就没有协议”#

应用层包含的协议非常多。

例如：

1
Web
2
├── HTTP
3
└── HTTPS
4

5
DNS
6
├── DNS
7
├── DoT
8
└── DoH
9

10
Remote Access
11
├── SSH
12
└── RDP
13

14
Email
15
├── SMTP
16
├── IMAP
17
└── POP3
18

19
Time
20
└── NTP
21

22
Network Management
23
└── SNMP

它们虽然都是应用层协议，但：

1
解决的问题不同
2
消息格式不同
3
状态模型不同
4
传输方式也可能不同

因此学习应用层时，不应该把：

1
应用层 = HTTP

简单画等号。

TCP/IP 四层模型#

现在可以把整个系列完整串起来：

1
┌──────────────────────────────────┐
2
│             应用层               │
3
│ HTTP / DNS / DHCP / SSH / ...     │
4
└────────────────┬─────────────────┘
5
                 │
6
                 ▼
7
┌──────────────────────────────────┐
8
│             传输层               │
9
│          TCP / UDP               │
10
│       Port / Socket              │
11
└────────────────┬─────────────────┘
12
                 │
13
                 ▼
14
┌──────────────────────────────────┐
15
│             网际层               │
16
│      IPv4 / IPv6 / Routing       │
17
│         ICMP / ARP               │
18
└────────────────┬─────────────────┘
19
                 │
20
                 ▼
21
┌──────────────────────────────────┐
22
│           网络接口层             │
23
│ Ethernet / MAC / Frame / NIC     │
24
└──────────────────────────────────┘

每一层解决的问题可以概括成：

1
网络接口层
2
↓
3
当前链路怎么传？
4

5
网际层
6
↓
7
数据应该去哪个 IP？
8

9
传输层
10
↓
11
交给哪个端口？
12
如何传输？
13

14
应用层
15
↓
16
双方具体交换什么信息？

一次完整通信#

假设：

1
浏览器
2
访问
3
https://example.com

可以把整个过程浓缩成：

1
                 应用层
2
                    │
3
               HTTP / HTTPS
4
                    │
5
                    ▼
6
                 传输层
7
                    │
8
                 TCP / UDP
9
                    │
10
                    ▼
11
                 网际层
12
                    │
13
                  IP
14
                    │
15
                    ▼
16
               网络接口层
17
                    │
18
              Ethernet
19
                    │
20
                    ▼
21
                  网络

发送过程中：

1
Application Data
2
      ↓
3
TCP Segment
4
      ↓
5
IP Packet
6
      ↓
7
Ethernet Frame

接收过程中则反过来：

1
Ethernet Frame
2
      ↓
3
IP Packet
4
      ↓
5
TCP Segment
6
      ↓
7
Application Data

这就是：

封装（Encapsulation）与解封装（Decapsulation）。

从运维角度理解应用层#

应用层是运维工作中非常容易接触的一层。

例如：

1
网页打不开

不能简单认为：

1
网络断了

而应该逐层思考：

1
DNS
2
↓
3
域名是否解析？
4

5
TCP
6
↓
7
端口是否建立连接？
8

9
TLS
10
↓
11
证书和握手是否正常？
12

13
HTTP
14
↓
15
状态码是什么？
16

17
Application
18
↓
19
服务本身是否正常？

例如：

1
DNS 正常
2
TCP 正常
3
TLS 正常
4
HTTP = 502

说明问题已经不太可能是：

1
网线
2
IP
3
路由
4
TCP 建连

而应该继续调查：

1
反向代理
2
上游服务
3
应用程序

类似地：

1
ping 正常

也不能证明：

1
HTTP 一定正常

因为：

1
ICMP
2
↓
3
网际层
4

5
HTTP
6
↓
7
应用层

属于完全不同的层次。

应用层的整体认知模型#

可以把应用层浓缩成：

1
                         应用层
2
                            │
3
          ┌─────────────────┼─────────────────┐
4
          │                 │                 │
5
          ▼                 ▼                 ▼
6
         Web              DNS              Remote
7
          │                 │              Management
8
      HTTP/HTTPS            │                 │
9
          │                 │                SSH
10
          │                 │
11
          └────────┬────────┘
12
                   ▼
13
               应用协议
14
                   │
15
                   ▼
16
              定义通信规则
17
                   │
18
        ┌──────────┼──────────┐
19
        │          │          │
20
        ▼          ▼          ▼
21
      消息格式    数据语义    交互流程
22
        │          │          │
23
        └──────────┼──────────┘
24
                   ▼
25
                 TCP/UDP
26
                   │
27
                   ▼
28
                  IP
29
                   │
30
                   ▼
31
               Ethernet

最核心的一点就是：

应用层负责定义“通信双方说什么、怎么说、这些数据代表什么”；下面三层则负责把这些数据送到正确的目标。

TCP/IP 四层模型总结#

至此，整个 TCP/IP 四层模型可以完整理解为：

1
应用层
2
↓
3
定义应用通信协议
4
↓
5
HTTP / DNS / DHCP / SSH
6

7
传输层
8
↓
9
实现进程之间的通信
10
↓
11
TCP / UDP / Port
12

13
网际层
14
↓
15
实现跨网络寻址与转发
16
↓
17
IP / Routing / ICMP
18

19
网络接口层
20
↓
21
实现当前链路上的传输
22
↓
23
Ethernet / MAC / Frame / NIC

可以进一步浓缩成：

1
应用层
2
↓
3
“说什么？”
4

5
传输层
6
↓
7
“交给谁？”
8

9
网际层
10
↓
11
“到哪台主机？”
12

13
网络接口层
14
↓
15
“这一跳怎么发送？”

这四层共同构成了一个完整的网络通信体系。

当浏览器访问一个网站时：

1
HTTP
2
 ↓
3
TCP
4
 ↓
5
IP
6
 ↓
7
Ethernet

每一层都只关注自己的职责，同时把结果交给下一层。

这正是 TCP/IP 分层模型最核心的思想：

把复杂的网络通信拆分成相对独立的功能层，各层通过明确的接口协同工作。

应用层是什么#

应用层与应用程序#

协议与数据格式#

应用层协议的分类#

HTTP#

什么是 HTTP#

HTTP 请求#

HTTP 方法#

GET#

POST#

PUT#

PATCH#

DELETE#

HTTP 响应#

HTTP 状态码#

HTTP Header#

HTTP Body#

HTTP 与 TCP#

HTTPS#

什么是 HTTPS#

HTTPS 的基本过程#

TLS#

机密性#

完整性#

身份认证#

DNS#

什么是 DNS#

为什么需要 DNS#

DNS 查询#

DNS Record#

DNS 的层次结构#

DNS 缓存#

DNS 与 TCP / UDP#

DHCP#

什么是 DHCP#

DHCP 的基本过程#

DHCP Discover#

DHCP Offer#

DHCP Request#

DHCP ACK#

DHCP 租约#

SSH#

什么是 SSH#

SSH 能做什么#

SSH 认证#

FTP 与其他应用层协议#

应用层协议如何使用传输层#

一个完整的 Web 请求#

应用层并不是“最上面就没有协议”#

TCP/IP 四层模型#

一次完整通信#

从运维角度理解应用层#

应用层的整体认知模型#

TCP/IP 四层模型总结#

外部参考#