计算机网络-HTTP与HTTPS

发布于：2025-05-20 ⋅ 阅读:(15) ⋅ 点赞:(0)

文章目录

计算机网络

网络模型

为了解决多种设备能够通过网络相互通信，解决网络互联兼容性问题。

网络模型是计算机网络中用于理解和设计网络通信的分层架构

主要分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） --------->|
  |                              |

  • 步骤解释：

    1. SYN：客户端发送同步报文，携带初始序列号 seq=x。

    2. SYN-ACK：服务器回应同步确认，携带自己的序列号 seq=y 和对客户端的确认号 ack=x+1。

    3. 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未下载。

  1. 客户端首次下载（0~500MB）

    客户端未指定 Range 头部，尝试完整下载：

    GET /large-video.mp4 HTTP/1.1
Host: example.com

  2. 服务器响应

    服务器返回完整文件（若支持断点续传，会包含 Accept-Ranges: bytes）：

    HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 2147483648
Content-Type: video/mp4

[视频文件的前 524,288,000 字节...（下载中途网络断开）]

  3. 客户端发送 HEAD 请求

    确认服务器是否支持范围请求：

    HEAD /large-video.mp4 HTTP/1.1
Host: example.com

  4. 服务器响应：

    返回 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"

  5. 客户端发起续传请求：

    通过 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 匹配），服务器返回剩余部分；若已修改，返回完整文件。

  6. 服务器处理请求：

    • 文件未修改：返回 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 和完整文件（需重新下载）。

  7. 客户端合并文件：

    客户端将已下载的 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：该随机数会被服务器公钥加密。
    • 加密通信算法改变通知，通知服务器后续消息将加密。
    • 客户端握手结束通知。

    密钥生成过程：

    1. 客户端使用3个随机数生成 主密钥（Master Secret）。
    2. 主密钥进一步生成 会话密钥（Session Key）

  • 第四次握手

    • 服务器 → 客户端
      服务器确认加密参数：
      • Change Cipher Spec：通知客户端后续消息加密。
      • Finished：发送加密的验证消息，确认握手完整性。

3.加密的HTTP通信

握手完成后，所有 HTTP 数据通过会话密钥加密传输：

客户端                                    服务器
  |                                          |
  | ---- Encrypted HTTP Request -----------> |
  | <---- Encrypted HTTP Response ---------- |
  |                                          |

4.连接关闭

先关闭 TLS 连接，再关闭 TCP 连接。

在这里插入图片描述
不断学习中，结合小林Coding整理了些笔记，感谢大家的观看>W<

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布