摘要：梳理应用层核心协议HTTP、HTTPS、DNS，包含协议分层、报文格式、版本演进、Cookie/Session、HTTPS加密原理，适合后端开发面试复习。
一、网络协议分层
OSI七层模型 & TCP/IP四层模型
| 层级 | TCP/IP四层 | 协议 |
|---|---|---|
| 应用层 | 应用层 | DNS、HTTP、HTTPS |
| 表示层 | —— | |
| 会话层 | —— | |
| 传输层 | 传输层 | UDP、TCP |
| 网络层 | 网络层 | IP、路由 |
| 数据链路层 | 链路层 | ETH、ARP |
| 物理层 | —— | 硬件信号 |
辅助技术：网络代理技术、NAT/NAPT地址转换技术
二、HTTP协议（超文本传输协议）
2.1 HTTP基础概念
- 属于应用层协议，传输层底层基于TCP实现。
- 请求‑响应模型：客户端发送请求，服务端返回响应。HTTP是无状态协议，默认短连接。
- 明文字符串协议，所有报文都是可读文本。
- 抓包工具：
Wireshark：抓取网卡全部流量，覆盖全协议Fiddler：代理工具，专门抓取HTTP/HTTPS应用层数据
2.2 HTTP请求报文格式
结构：请求首行 + 请求头部 + 空行
\r\n\r\n+ 请求正文（可选）
1）请求首行
格式：请求方法 URL HTTP/版本，各字段空格分隔，末尾\r\n结尾。
常用请求方法
| 方法 | 作用 |
|---|---|
| GET | 获取服务器资源，参数放在URL查询字符串，长度受限约8KB，无请求体 |
| HEAD | 和GET一致，服务器只返回响应头，不返回响应正文 |
| POST | 向服务器提交数据，数据放在请求正文，长度无限制 |
| PUT | 提交数据，多用于修改服务器上已有资源 |
| DELETE | 请求服务器删除指定资源 |
面试重点：
- GET vs HEAD：都获取资源，HEAD没有响应body，用于探测资源是否存在。
- GET vs POST：GET用于获取，参数在URL；POST用于提交，参数放请求体；GET有长度限制，POST无。GET也可以提交数据，只是不安全、长度受限。
2）URL 统一资源定位符
完整格式：
协议类型://用户名:密码@域名/IP地址:端口号/资源路径?查询字符串#片段标识符示例：[https://www.baidu.com/s?wd=C++](https://www.baidu.com/s?wd=C++)
字段解释：
- 协议类型
http://：HTTP协议，默认端口80https://：加密HTTP，默认端口443
用户名:密码：现已废弃，现代服务器不再支持。- 域名/IP：定位服务器主机；域名会经过DNS解析转为IP地址。
- 端口号：定位服务器机器上运行的进程，不写则使用协议默认端口。
- 资源路径：以
/开头，定位服务器上具体资源，限制客户端访问根目录。 - 查询字符串：
key=val&key2=val2，GET请求携带参数。 - 片段标识符#：浏览器页面内部锚点，不会发给服务器，用于页面内部跳转。
URL编码与解码
问题：URL中如果出现
+、空格、中文等特殊字符，会和URL分隔符号冲突，需要编码。
- 编码：特殊字节转为
%加上两位十六进制。例：+→%2B - 不需要编码：
/. - _ ~ a-z A-Z 0‑9 - 解码：读到
%，读取后面2位十六进制数字，还原原始字节。
3）HTTP协议版本演进
| 版本 | 核心特性 |
|---|---|
| HTTP/0.9 | 早期不成熟版本 |
| HTTP/1.0 | 基础版本；支持GET/HEAD/POST；每次请求新建TCP短连接，请求完断开；基础请求头 |
| HTTP/1.1 | 性能大幅提升：长连接keep‑alive（管线化传输）；增加PUT/DELETE方法；缓存管理； 缺点：队头阻塞：前面请求没返回，后面即使准备好了也不能返回 |
| HTTP/2.0 | 二进制传输；多路复用，解决队头阻塞；头部压缩；服务端主动推送资源； 推送实际业务很少使用，3.0放弃推送 |
| HTTP/3.0 | 底层抛弃TCP，使用QUIC（基于UDP）；头部压缩；连接迁移，弱网、移动端友好 |
HTTP1.1长连接：
Connection: keep‑alive；短连接：Connection: close
4）请求头（key: value）
键值对格式，每行key: value\r\n，头部结束用\r\n\r\n。
常见请求头：
Host: www.baidu.com # 目标服务主机 User‑Agent: xxx # 客户端浏览器设备信息 Referer: [https://xxx.com](https://xxx.com) # 当前请求是从哪个页面跳转过来 Accept: */* # 客户端可以接收哪些响应数据类型 Accept‑Language: zh‑CN # 客户端支持语言 Accept‑Encoding: gzip,deflate # 支持的压缩格式 Connection: keep‑alive # 控制长/短连接 Content‑Type: application/x‑www‑form‑urlencoded # 请求正文数据格式 Content‑Length: 123 # 请求正文字节长度 Cookie: xxx # 客户端存储的身份凭证5）请求正文
POST/PUT/DELETE才有请求正文，GET没有。头部结束空行\r\n\r\n之后，就是正文内容。
2.3 HTTP响应报文格式
结构：响应首行 + 响应头部 + 空行
\r\n\r\n+ 响应正文
1）响应首行
格式：HTTP/版本 状态码 状态描述，例：HTTP/1.1 200 OK
状态码五大类
- 1xx 信息类：协议切换、提示信息
- 2xx 请求成功
200 OK：请求完全成功201 Created：资源创建成功206 Partial Content：断点续传，返回部分数据
- 3xx 重定向，配合响应头
Location使用301 永久重定向：资源永久搬家；浏览器缓存跳转，后续直接访问新地址302 临时重定向：资源临时迁移；下次访问依旧请求旧地址
- 4xx 客户端错误
400 Bad Request：请求报文格式错误404 Not Found：请求资源不存在
- 5xx 服务器错误
500 Internal Server Error：服务器内部异常502 Bad Gateway：网关/代理拿到无效后端响应504 Gateway Timeout：网关后端请求超时
2）响应头
常见响应头：
Location: /image/a.png # 配合3xx重定向 Set‑Cookie: userId=xxx # 服务器下发cookie给浏览器 Content‑Type: text/html # 响应正文MIME类型，告诉客户端如何解析body Content‑Length: 2048 # 响应体字节长度 Cache‑Control: max‑age=xxx # 缓存控制3）响应正文
服务器返回给浏览器的资源，可以是html、json、图片、二进制文件。
2.4 Cookie、Session、Token（HTTP无状态解决方案）
HTTP协议本身无状态：每一次请求相互独立，服务器默认不知道两个请求来自同一个用户，因此需要身份管理。
Cookie
- 流程：服务器通过
Set‑Cookie响应头下发数据；浏览器保存Cookie；之后每次请求自动带上Cookie请求头。 - 缺点：每次http明文携带用户身份信息，存在隐私泄露风险。
- Cookie存储在客户端浏览器。
Session（会话）
Session是基于Cookie做的改进方案。
- 服务器生成唯一
ssid(sessionId)，通过Set‑Cookie: ssid=xxx发给浏览器。 - 浏览器后续请求带上
ssid；真实用户信息保存在服务端Session内存/数据库，客户端只存ssid字符串。 - 优点：敏感数据不放在客户端；缺点：服务器集群时session共享有成本。
Token机制
- 服务器生成一串唯一token字符串，映射用户身份状态。
- token交给客户端本地保存（Cookie / localstorage）。
- 客户端每次请求携带token，服务器校验token完成身份识别。
- 优势：适合分布式、前后端分离、移动端场景，不需要服务端保存会话数据。
三、HTTPS协议
HTTPS本质：HTTP + SSL/TLS加密层，底层传输依旧是TCP。HTTP明文传输不安全，HTTPS对传输数据做加密、身份认证。 默认端口：443
HTTPS解决3个核心问题：
- 数据加密：防止报文被窃听
- 身份认证：确认服务器是真实可信服务器，防止伪装钓鱼
- 数据完整性：报文传输中不能被篡改
SSL/TLS握手核心流程
- 身份认证（CA证书）
- 权威第三方CA机构，服务器向CA申请数字证书。证书包含服务器域名信息、CA机构信息、数字签名。
- 客户端操作系统/浏览器预装CA机构的公钥。
- 握手时服务器把证书发送给客户端。
- 客户端校验证书：
- 对证书原文做hash计算，得到hash值A。
- 使用预装CA公钥，解密证书里的数字签名，得到hash值B。
- A与B对比：一致代表证书没有被篡改，服务器身份可信。
- 混合加密传输
- 非对称加密（公钥私钥）：只用于握手阶段，协商会话密钥；加解密慢，不传输业务数据。
- 对称加密：握手协商出的会话密钥；业务报文使用对称加密，速度快。
HTTPS协议TLS握手完整流程
1.前提：
服务端提前生成一对非对称密钥（公钥+私钥），向CA申请证书时，提交服务器信息和服务器公钥。
CA对服务器信息和公钥做哈希得到摘要，用CA自己的私钥加密摘要，生成数字签名，附加在证书末尾。
客户端收到服务端证书后，使用本地内置CA根证书的公钥解密证书签名，得到哈希摘要A；
客户端本地对证书内容重新哈希计算得到摘要B；
A和B相等代表证书没有被篡改，服务端可信；验证失败直接断开TCP连接。TLS握手流程(TLS1.2)：
2.Client Hello：客户端发送客户端随机数、支持的TLS版本、加密套件列表给服务端。
3.Server Hello：服务端回复服务端随机数、选定加密套件，等到客户端收到之后再返回自己的数字证书。
4.客户端校验证书合法性，失败断开连接；
校验成功，客户端生成预主密钥Pre‑Master Secret，使用服务端公钥加密后发给服务端；
服务端使用自身私钥解密，拿到预主密钥。
双方以预主密钥、客户端随机数、服务端随机数，共同派生会话对称密钥。
双方发送Change Cipher Spec报文通知后续使用对称加密，再发送Finished报文校验握手完整性。
TLS握手完成，后续HTTP报文全部使用对称密钥加密传输。
补充：HTTP3不再使用TCP，使用QUIC(UDP)，把TLS加密内置到QUIC协议内部。
四、DNS协议
DNS：域名解析协议，应用层协议，主要使用UDP，也支持TCP。 作用：把人类可读域名
www.baidu.com，翻译成机器识别的IP地址。
- 用户访问域名，浏览器首先发起DNS查询。
- DNS服务器返回域名对应的IP。
- 客户端拿到IP之后，才向IP发起HTTP/TCP连接。
流程简述：浏览器缓存 → 操作系统hosts文件 → 本地DNS服务器 → 根DNS服务器 → 顶级域服务器 → 权威DNS服务器，最终拿到IP。
域名：域名IP地址不好记忆提出的一种服务器查找技术（使用便于记忆的字符串代替ip地址）
一般在通信前需要进行域名解析，将域名字符串转换为具体的ip地址，在进行TCP连接并通信
域名的层级：根域名、顶级域名、二级域名、三级域名...
顶级域名：地域划分（.cn .us），性质划分（.com，.org , ....）
二级域名：.qq.com
三级域名：.zhidao.baidu.com
域名服务器的层级：根域名服务器 -> 顶级域名服务器 -> 二级域名服务器 ->三级域名服务器 ....
域名解析的过程：
1.查看浏览器缓存
2.查看本机host文件
3.本地域名解析服务器（网络服务运营商：电信，移动，联通等，部署在终端位置）
4.本地域名服务器->根域名服务器->顶级域名服务器->二级域名服务器……(递归查询)
5.（1）本地域名服务器->根域名服务器；
（2）本地域名服务器->顶级域名服务器
（3）本地域名服务器->二级域名服务器
.......(逐层解析，迭代查询)
五、重点
- HTTP1.1：长连接keep‑alive，队头阻塞；HTTP2多路复用解决队头阻塞，二进制帧，头部压缩；HTTP3 QUIC+UDP。
- GET和POST区别；301永久重定向与302临时重定向。
- Cookie客户端存储；Session服务端存储，依赖Cookie携带sessionId。
- HTTPS不是新协议，HTTP套SSL/TLS；CA证书做身份校验；混合加密（非对称协商密钥，对称加密业务数据）。
- TLS协议是基于TCP连接进行的，必须先建立TCP连接在进行TLS握手
- DNS域名解析，域名转IP后才能进行TCPl=连接
降到O(n))
