文章目录
- 计算机网络
- 网络模型
- 网络OSI
- TCP/IP
- 应用层
- 常用协议
- HTTP报文
- HTTP状态码
- HTTP请求类型
- HTTP握手过程
- HTTP连接
- HTTP断点续传
- HTTPS
- HTTPS握手过程
计算机网络
网络模型
为了解决多种设备能够通过网络相互通信，解决网络互联兼容性问题。
网络模型是计算机网络中用于理解和设计网络通信的分层架构
主要分OSI模型和TCP/IP模型
网络OSI
-
物理层
传输原始比特流，定义物理介质（电缆、光纤等）的电气、机械特性。
数据单元：比特（Bit）
-
数据链路层
数据封帧，在直接相连的节点间可靠传输数据帧，MAC地址寻址，错误检测。
数据单元：帧
-
网络层
负责数据的路由转发分片,IP地址寻址。
数据单元：数据包
-
传输层
端到端通信，确保可靠传输（TCP）或快速传输（UDP）。
数据单元：TCP,UDP
-
会话层
建立、管理和终止会话，同步数据交换。
-
表示层
数据格式转换、加密/解密（如SSL/TLS）、压缩（如JPEG、MPEG）。
-
应用层
提供用户统一的接口，支持应用程序通信。
TCP/IP
-
网络接口层
处理物理连接和本地网络数据传输。
-
网络层
IP寻址、路由。
-
传输层
处理主机到主机的通信（TCP、UDP）。
-
应用层
支持 HTTP、SMTP 等最终用户进程。
应用层
- 提供应用程序与网络之间的交互接口（如浏览器、邮件客户端）。
- 用户通过应用层协议访问网络服务（如访问网页、发送邮件）。
常用协议
HTTP,HTTPS,CDN,DNS等。
默认端口：
HTTP：80
HTTPS: 443
HTTP报文
无论是请求报文还是回应报文，均有3部分组成
|-----------------------|
| 起始行 | → 请求方法/状态码等
|-----------------------|
| 头部字段 | → 元数据（键值对）
|-----------------------|
| 空行 | → 分隔头部和正文
|-----------------------|
| 消息体 | → 实际传输的数据（可选）
|-----------------------|
-
请求报文
[起始行]：方法/请求URL/HTTP版本
[头部字段]：包含关于请求的附加信息，如Host、User-Agent、Content-Type等。
[空行]
[消息体]：用于传递数据（如POST请求的表单或JSON数据）。POST /login HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Content-Type: application/x-www-form-urlencoded Content-Length: 27 username=admin&password=123 -
响应报文
[起始行] :包含HTTP版本/状态码/状态信息。
[头部字段] :包含关于响应的附加信息，响应数据类型,数据类型，cookie等
[空行]
[消息体] :包含响应的数据，通常是服务器返回的HTML、JSON等内容HTTP/1.1 200 OK Content-Type: text/html Content-Length: 137 Date: Wed, 21 Oct 2023 07:28:00 GMT <html> <body> <h1>Welcome to Example.com</h1> </body> </html>
HTTP状态码
| 分类 | 描述 | 常见状态码 |
|---|---|---|
| 1xx | 信息类（请求已被接收，继续处理） | 100, 101 |
| 2xx | 成功类（请求被成功处理） | 200, 201, 204 |
| 3xx | 重定向类（需进一步操作以完成请求） | 301, 302, 304 |
| 4xx | 客户端错误类（请求有误，服务器无法处理） | 400, 401, 403, 404 |
| 5xx | 服务器错误类（服务器处理请求失败） | 500, 502, 503 |
其中常用的状态码：
- 200：请求被成功处理
- 301：资源已永久迁移到新URL（网站更换域名，旧链接跳转到新地址）
- 302：资源临时从其他URL返回，客户端后续应继续请求原地址（未登录用户访问受限页面，临时跳转到登录页）
- 404：请求的资源不存在
- 500：服务器内部错误，无法完成请求（后端代码抛出未捕获的异常，如数据库连接失败）
HTTP请求类型
-
GET
-
用途：获取资源（从服务器读取数据）。
-
特点：
- 安全且幂等。(幂等：多次重复请求与单次请求效果相同)
- 参数通过 URL 传递（如
/users?id=1）。 - 通常无请求体（但技术上允许）。
-
示例：
GET /api/users/1 HTTP/1.1 Host: example.com
-
-
POST
-
用途：提交资源（向服务器发送数据，可能创建新资源）。
-
特点：
- 非安全、非幂等（非幂等：多次请求可能产生不同结果）。
- 数据通过请求体传输（如 JSON、表单）。
- 常用于创建新资源或触发复杂操作。
-
示例：
POST /api/users HTTP/1.1 Content-Type: application/json {"name": "Alice", "age": 25}
-
-
PUT
-
用途：全量更新资源（替换目标资源的全部内容）。
-
特点：
- 幂等。
- 需指定完整资源数据，用于覆盖已有内容。
- 若资源不存在，可能创建新资源（取决于实现）。
-
示例：
PUT /api/users/1 HTTP/1.1 Content-Type: application/json {"name": "Bob", "age": 30}
-
-
DELETE
-
用途：删除资源。
-
特点：
- 幂等。
- 通常无请求体。
-
示例：
DELETE /api/users/1 HTTP/1.1 Host: example.com
-
-
HEAD
-
用途：获取资源的元数据（与
GET类似，但无响应体）。 -
特点：
- 安全且幂等。
- 常用于检查资源是否存在或验证缓存。
-
示例：
HEAD /api/users/1 HTTP/1.1 Host: example.com
-
HTTP握手过程
HTTP 本身无握手过程，其通信依赖 TCP 三次握手建立连接。
整个过程如下:
1.TCP三次握手
客户端 服务器
| |
| ---- SYN（seq=x） ----------> |
| |
| <--- SYN-ACK（seq=y, ack=x+1）-|
| |
| ---- ACK（ack=y+1） --------->|
| |
-
步骤解释：
-
SYN：客户端发送同步报文，携带初始序列号
seq=x。 -
SYN-ACK：服务器回应同步确认，携带自己的序列号
seq=y和对客户端的确认号ack=x+1。 -
ACK：客户端确认服务器的响应，连接建立。
-
2.HTTP请求/响应
TCP 连接建立后，客户端直接发送 HTTP 请求：
GET /index.html HTTP/1.1
Host: example.com
服务器返回 HTTP 响应：
HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
3.连接关闭
通信完成后，通过四次挥手关闭连接：
客户端 服务器
| |
| ---- FIN -------------------> |
| <---- ACK ------------------- |
| |
| <---- FIN ------------------- |
| ---- ACK -------------------> |
| |
HTTP连接
HTTP是基于 TCP 传输协议实现的，客户端与服务端要进行 HTTP 通信前，需要先建立 TCP 连接,然后客户端发送 HTTP 请求，服务端收到后就返回响应。
- 短连接
这样的连接就是短连接，一次连接只能请求一次资源。
-
长连接
HTTP 的 Keep-Alive 就是实现了这个功能，可以使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态，避免了连接建立和释放的开销，这个方法称为 HTTP 长连接。
HTTP断点续传
断点续传允许客户端只请求资源的一部分，而不是整个文件。这对于大文件下载非常有用，特别是当下载中断时，可以从中断的地方继续，而不必重新开始
举个例子，大文件下载中断后恢复的流程如下：
假设文件总大小为2GB(2,147,483,648 字节)，已经下载了500MB(即 524,288,000 字节)后中断了，剩余1.5GB未下载。
-
客户端首次下载（0~500MB）
客户端未指定
Range头部，尝试完整下载：GET /large-video.mp4 HTTP/1.1 Host: example.com -
服务器响应
服务器返回完整文件（若支持断点续传，会包含
Accept-Ranges: bytes）：HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 2147483648 Content-Type: video/mp4 [视频文件的前 524,288,000 字节...（下载中途网络断开）] -
客户端发送 HEAD 请求
确认服务器是否支持范围请求：
HEAD /large-video.mp4 HTTP/1.1 Host: example.com -
服务器响应：
返回
Accept-Ranges: bytes表示支持：HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 2147483648 Content-Type: video/mp4 Last-Modified: Wed, 21 Oct 2023 00:00:00 GMT ETag: "abc123xyz" -
客户端发起续传请求：
通过
Range头部指定从已下载位置继续请求：GET /large-video.mp4 HTTP/1.1 Host: example.com Range: bytes=524288000- # 请求 500MB 之后的所有数据 If-Range: "abc123xyz" # 使用 ETag 校验文件未修改-
Range: bytes=524288000-：表示请求从第 500MB 到文件末尾。 -
If-Range：若文件未修改（ETag 匹配），服务器返回剩余部分；若已修改，返回完整文件。
-
-
服务器处理请求：
-
文件未修改：返回
206 Partial Content和剩余数据：HTTP/1.1 206 Partial Content Content-Range: bytes 524288000-2147483647/2147483648 Content-Length: 1623195648 # 剩余 1.5GB 的长度（2147483648 - 524288000=1623195648） Content-Type: video/mp4 ETag: "abc123xyz" [视频文件的 500MB ~ 2GB 数据] -
文件已修改：返回
200 OK和完整文件（需重新下载）。
-
-
客户端合并文件：
客户端将已下载的
500MB数据与续传的1.5GB数据按字节顺序拼接，得到完整文件。
HTTPS
HTTP和 HTTPS（HTTP Secure）是 Web 通信的核心协议，HTTPS 本质是 HTTP 的安全版本，通过加密和身份验证保障数据传输的安全性。
HTTP为什么不安全？
核心原因在于其明文传输、缺乏身份验证和完整性保护
-
明文传输
HTTP协议在传输过程中不加密数据，所有内容（如密码、银行卡号、聊天记录）均以明文形式在网络中传输。
-
无身份验证
HTTP协议不验证服务器身份，用户无法确认自己连接的是真实服务器还是攻击者的伪造站点。
-
数据无完整性保护
HTTP传输的数据无完整性校验机制，攻击者可随意修改传输内容。
所以就需要用到HTTPS进行安全管理：
那么HTTPS是如何保证安全性的呢？
- 在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
- HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
- HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
HTTPS握手过程
HTTPS 在 TCP 连接基础上增加了 TLS/SSL 握手，用于协商加密参数、验证身份并生成会话密钥。
1.TCP 三次握手
与 HTTP 相同，首先建立 TCP 连接。
2.TLS握手
客户端 服务器
| |
| ---- Client Hello（支持的加密套件等）-----> |
| |
| <---- Server Hello（选定加密套件）--------- |
| <---- Certificate（服务器证书）----------- |
| <---- Server Key Exchange（可选）--------- |
| <---- Server Hello Done ---------------- |
| |
| ---- Client Key Exchange（预主密钥）------> |
| ---- Change Cipher Spec（准备加密）-------> |
| ---- Finished（加密验证）----------------> |
| |
| <---- Change Cipher Spec（准备加密）------- |
| <---- Finished（加密验证）---------------- |
| |
-
第一次握手
客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
- TLS 版本：支持的 TLS 版本。
- 随机数1：32 字节的随机数，用于生成会话密钥。
- 加密套件列表：支持的加密算法组合
-
第二次握手
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。
- TLS 版本：双方协商后的版本。
- 随机数2：32 字节的随机数，也用于生成会话密钥。
- 选定的加密套件：从客户端列表中选择的加密套件
- 证书链：服务器公钥证书（由 CA 签发）
-
第三次握手
Client Key Exchange。
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
- 随机数3：该随机数会被服务器公钥加密。
- 加密通信算法改变通知，通知服务器后续消息将加密。
- 客户端握手结束通知。
密钥生成过程：
- 客户端使用3个随机数生成 主密钥（Master Secret）。
- 主密钥进一步生成 会话密钥（Session Key）
-
第四次握手
- 服务器 → 客户端
服务器确认加密参数：- Change Cipher Spec：通知客户端后续消息加密。
- Finished：发送加密的验证消息，确认握手完整性。
- 服务器 → 客户端
3.加密的HTTP通信
握手完成后，所有 HTTP 数据通过会话密钥加密传输：
客户端 服务器
| |
| ---- Encrypted HTTP Request -----------> |
| <---- Encrypted HTTP Response ---------- |
| |
4.连接关闭
先关闭 TLS 连接，再关闭 TCP 连接。
不断学习中，结合小林Coding整理了些笔记，感谢大家的观看>W<
![2025年渗透测试面试题总结-华顺信安[实习]安全服务工程师（题目+回答）](https://i-blog.csdnimg.cn/direct/2ea6508e11f348769528e86055da4fc5.png)
