HTTP 协议及内外网划分详解

内容预览 ≧∀≦ゞ

• 黑客网络基础之超文本协议与内外网划分
• • 声明
  • 导语
  • [1. HTTP 协议简介](#1. HTTP 协议简介)
  • • [HTTP 协议的演变](#HTTP 协议的演变)
    • • [1.1 HTTP/0.9](#1.1 HTTP/0.9)
      • [1.2 HTTP/1.0](#1.2 HTTP/1.0)
      • [1.3 HTTP/1.1](#1.3 HTTP/1.1)
      • [1.4 HTTP/2](#1.4 HTTP/2)
      • [1.5 HTTP/3](#1.5 HTTP/3)
  • [2. HTTP 协议的主要请求方法](#2. HTTP 协议的主要请求方法)
  • • [2.1 GET](#2.1 GET)
    • [2.2 POST](#2.2 POST)
    • [2.3 PUT](#2.3 PUT)
    • [2.4 DELETE](#2.4 DELETE)
    • [2.5 HEAD](#2.5 HEAD)
    • [2.6 OPTIONS](#2.6 OPTIONS)
    • [2.7 TRACE](#2.7 TRACE)
  • [3. HTTP 协议中的 URL 和状态码](#3. HTTP 协议中的 URL 和状态码)
  • • [3.1 HTTP URL 结构](#3.1 HTTP URL 结构)
    • [3.2 HTTP 状态码](#3.2 HTTP 状态码)
    • • 1xx（信息性状态码）
      • 2xx（成功状态码）
      • 3xx（重定向状态码）
      • 4xx（客户端错误状态码）
      • 5xx（服务器错误状态码）
  • [4. 内外网的划分](#4. 内外网的划分)
  • • [4.1 内网（局域网）](#4.1 内网（局域网）)
    • [4.2 外网（广域网）](#4.2 外网（广域网）)
    • [4.3 公网与私网地址](#4.3 公网与私网地址)
    • • [公网地址（Public IP）](#公网地址（Public IP）)
      • [私网地址（Private IP）](#私网地址（Private IP）)
      • 公网与私网的对比
  • 结语

黑客网络基础之超文本协议与内外网划分

---

声明

笔记内容参考了B站UP主 泷羽sec 的学习视频，如有侵权，将立即删除。

本笔记旨在促进网络安全学习，任何不当使用均与作者无关，请勿逾越法律红线，否则后果自负。

希望这些内容能对各位师傅有所帮助，欢迎您的点赞和评论！

---

导语

在现代互联网架构中，HTTP 协议和内外网的划分是理解网络通信与安全的核心。本文将全面介绍 HTTP 协议的演进与常见请求方法，以及内外网和公网、私网地址的定义与用途。

---

1. HTTP 协议简介

HTTP（Hypertext Transfer Protocol，超文本传输协议）是用于在万维网（WWW）上传输超文本数据的通信协议。作为客户端和服务器之间的通信桥梁，HTTP 协议使得客户端（通常是浏览器）能够通过 URL 向 Web 服务器发送请求，服务器则根据请求返回响应。HTTP 协议的无状态性质使得每次请求和响应都是独立的，但也提供了较为简单高效的通信机制。

HTTP 协议工作在客户端-服务器架构（B/S）上，广泛应用于网页浏览、API 调用等多种网络应用中。

HTTP 协议的演变

HTTP 协议自诞生以来经历了多个版本的迭代，每个版本都在性能、功能和安全性方面进行了不同程度的改进，以适应互联网的不断发展和用户需求的变化。

1.1 HTTP/0.9

• 诞生背景：互联网初期，网页内容主要是静态的纯文本，网络带宽和计算能力较为有限。
• 主要特性：HTTP/0.9 版本仅支持最基础的 GET 请求，用于从服务器请求 HTML 文档，且通信非常简洁，完全没有请求头和响应头，只传输纯文本数据。
• 使用场景：主要用于早期的网页浏览，页面内容非常简单，通常仅包括纯文本，几乎不涉及复杂的多媒体或交互。

1.2 HTTP/1.0

• 诞生背景：随着互联网的发展，网页的复杂性和交互性需求逐渐增加，需要更加灵活和高效的协议支持。
• 主要特性：HTTP/1.0 引入了请求头和响应头，支持多种请求方法（如 GET、POST 和 HEAD）。但是每次请求都需要建立新的 TCP 连接，这导致了较高的连接开销，效率较低。
• 使用场景：适用于早期的动态网页和互动型网页，但在多媒体内容丰富的网页上，加载速度和效率较差。

1.3 HTTP/1.1

• 诞生背景：随着 Web 的快速发展，特别是对网页加载速度和性能的需求不断提升，HTTP/1.1 对 HTTP/1.0 进行了改进。

• 主要特性：

  • 持久连接（Keep-Alive）：允许在一个 TCP 连接上发送多个请求和响应，减少了建立和断开连接的频率，显著提升了性能。
  • 管道化（Pipelining）：客户端可以在一个连接上连续发送多个请求，而不必等待每个响应，从而减少了等待时间。
  • 请求方法扩展：HTTP/1.1 引入了 PUT、DELETE、OPTIONS 等新的请求方法，增强了协议的灵活性。
  • 缓存控制：增加了缓存控制机制，允许客户端根据缓存策略决定是否请求最新的资源。
  • 虚拟主机支持：支持在同一个 IP 地址上托管多个网站，提升了服务器的资源利用率。

• 使用场景：广泛应用于绝大多数网站和 Web 应用程序，是一个成熟且稳定的协议版本，特别适用于资源丰富、交互性强的现代网站。

1.4 HTTP/2

• 诞生背景：尽管 HTTP/1.1 已经广泛应用，但它在处理高并发请求时存在性能瓶颈，特别是在多个请求同时发起时，仍然需要建立多个连接，且传输效率较低。

• 主要特性：

  • 二进制分帧：将 HTTP 消息分解为更小的二进制帧进行传输，提高了传输效率和灵活性，同时避免了 HTTP/1.x 中的文本协议问题。
  • 多路复用：在同一个连接上并行处理多个请求和响应，减少了等待时间和延迟，避免了队头阻塞问题。
  • 头部压缩：采用 HPACK 算法对 HTTP 头部进行压缩，大幅减少了冗余数据的传输，提升了效率。
  • 服务器推送：服务器可以在客户端请求某个资源时，主动推送相关资源，减少客户端请求的次数，提高页面加载速度。

• 使用场景：适用于对性能要求较高的现代 Web 应用，尤其是有大量资源（如图片、JS、CSS 等）需要加载的页面。HTTP/2 的性能提升显著，特别是在需要快速加载大规模资源的应用场景中。

1.5 HTTP/3

• 诞生背景：虽然 HTTP/2 在性能上有了显著提升，但其仍然基于 TCP 协议，可能遇到连接建立慢、丢包重传等问题，尤其在网络质量不稳定的情况下表现欠佳。

• 主要特性：

  • 基于 QUIC 协议 ：HTTP/3 基于 Google 开发的 QUIC 协议，采用 UDP 作为传输层，提升了连接建立的速度和拥塞控制的效率。相比传统的基于 TCP 的连接，QUIC 能够减少连接延迟和重传的开销。
  • 0-RTT 连接建立：通过 QUIC 协议，HTTP/3 能实现 0-RTT 连接建立，即客户端和服务器可以在不进行握手的情况下建立连接，极大地降低了连接延迟。
  • 连接迁移：支持在网络环境变化时（如切换网络或改变 IP 地址）保持连接不被中断，提升了用户体验。
  • 前向纠错：QUIC 协议内建前向纠错机制，能够在丢包时减少重传的次数，从而提高传输效率。

• 使用场景：特别适用于低延迟和高并发的应用场景，如在线游戏、实时视频流、金融交易等。HTTP/3 提供了比 HTTP/2 更优秀的性能表现，尤其在不稳定的网络环境中，能够提供更快、更可靠的数据传输。

目前，HTTP/1.1 和 HTTP/2 是使用最广泛的版本。HTTP/1.1 提供了持久连接和多请求支持，而 HTTP/2 则通过多路复用和头部压缩进一步提高了性能。HTTP/3 是较新的版本，仍在逐步普及，特别适用于低延迟要求的场景。

2. HTTP 协议的主要请求方法

HTTP 协议定义了多种请求方法，用于描述客户端与服务器之间的不同交互方式。每种请求方法都具有特定的功能和使用场景，满足各种应用需求。

2.1 GET

• 用途：请求服务器提供指定的资源。GET 方法通常用于获取网页内容、API 数据或其他服务器上的资源。

• 特点：

  • 请求参数在 URL 中传递 ：GET 请求的参数通过查询字符串附加在 URL 后面，例如 https://example.com/page?name=value。
  • 缓存机制：GET 请求可以被缓存（例如浏览器缓存），这有助于加速后续的请求响应。
  • 幂等性：GET 请求是幂等的，即多次请求相同的资源会返回相同的结果，不会对服务器状态产生影响。
  • 安全性：GET 请求不会修改服务器上的资源，因此它被认为是安全的，但 URL 中的参数可能会暴露敏感信息。

• 应用场景：

  • 浏览器访问网页：浏览器通过 GET 请求向服务器请求网页内容。
  • 获取资源：例如获取图片、JSON 数据或其他静态资源。
  • API 请求：许多 RESTful API 使用 GET 方法获取数据。

2.2 POST

• 用途：向服务器提交数据，通常用于创建或更新资源。POST 请求常见于表单提交、文件上传等操作。

• 特点：

  • 数据传输方式：POST 请求的参数放置在请求体中，不会显示在 URL 中，适合传输较为复杂或敏感的数据。
  • 不缓存：POST 请求一般不会被浏览器缓存，确保每次请求都能提交新的数据。
  • 非幂等性：POST 请求通常不是幂等的，即多次发送相同请求可能会导致不同的结果（例如创建多个相同的资源）。

• 应用场景：

  • 表单提交：例如用户注册、登录、评论提交等操作。
  • 文件上传：上传文件时，POST 请求用于将文件数据发送到服务器。
  • API 数据提交：向服务器提交 JSON 或 XML 数据。

2.3 PUT

• 用途：更新服务器上的资源，通常会替换掉现有的资源。PUT 方法用于全量更新资源。

• 特点：

  • 幂等性：PUT 请求是幂等的，即多次发送相同的 PUT 请求会产生相同的结果。不会改变服务器资源的状态，除非传递的内容发生变化。
  • 完整资源替换：PUT 请求通常替换指定资源的完整内容，如果某些字段缺失，可能会导致资源的部分内容被删除或更新。
  • 语义明确：PUT 方法具有明确的语义，表示客户端希望将数据写入服务器，通常是某个指定的资源。

• 应用场景：

  • 更新资源：例如修改用户资料、修改商品信息等。
  • API 更新：PUT 方法常用于 RESTful API 中的资源更新操作。

2.4 DELETE

• 用途：删除服务器上的指定资源。DELETE 方法用于删除一个现有的资源。

• 特点：

  • 幂等性：DELETE 请求是幂等的，即删除某个资源后再次删除相同资源不会产生错误，返回的结果通常是资源已不存在。
  • 不带请求体：DELETE 请求通常不需要请求体，资源的标识（如 ID）直接在 URL 中传递。

• 应用场景：

  • 删除资源：如删除用户账号、删除文件或删除数据库中的记录。
  • API 删除操作：RESTful API 中通过 DELETE 请求删除资源。

2.5 HEAD

• 用途：与 GET 请求类似，但只返回响应头部信息，而不返回资源的实际内容。

• 特点：

  • 节省带宽：HEAD 请求不会返回资源内容，仅返回响应头部信息，适用于需要检查资源是否存在或者获取元信息的场景。
  • 快速检查资源：通过查看资源的状态（如最后修改时间、内容类型等）来确认是否需要进行实际的 GET 请求。
  • 不返回响应体：仅返回头部信息，因此返回数据量小，节省带宽。

• 应用场景：

  • 检查资源存在性：用于检查资源是否存在、是否需要更新缓存。
  • 获取元数据：获取资源的头部信息，如最后修改时间、文件大小、内容类型等。

2.6 OPTIONS

• 用途：请求服务器返回支持的 HTTP 方法和其他选项。这种方法通常用于检查服务器对特定资源的支持和访问控制。

• 特点：

  • 允许跨域请求：OPTIONS 方法常用于跨域请求中，浏览器通过发送预检请求（preflight）来确认是否允许跨域操作。
  • 列举支持的方法 ：通过返回 Allow 响应头，OPTIONS 请求可以列出服务器支持的 HTTP 方法。
  • 访问控制 ：服务器可以通过 Access-Control-Allow-Methods 等头部来控制客户端的访问权限。

• 应用场景：

  • 跨域请求的预检：当浏览器发起跨域请求时，会发送 OPTIONS 请求以确认目标服务器允许哪些类型的请求。
  • API 方法查询：用于查询服务器支持的操作类型。

2.7 TRACE

• 用途：用于诊断和调试，查看请求在网络中的路径。TRACE 请求会返回服务器接收到的请求内容，用于跟踪请求的经过路径。

• 特点：

  • 调试用途：TRACE 请求返回的是 HTTP 请求的完整内容，包括请求头和请求体，通常用于开发和调试环境。
  • 易受攻击：由于 TRACE 请求会将 HTTP 请求内容返回，可能被恶意用户利用来探测服务器和防火墙的配置，泄露敏感信息，因此在生产环境中通常会禁用此方法。

• 应用场景：

  • 网络调试：用于开发环境下调试和诊断 HTTP 请求路径及内容。
  • 安全测试：用于测试服务器是否存在 TRACE 方法漏洞，泄露可能的攻击信息。

3. HTTP 协议中的 URL 和状态码

3.1 HTTP URL 结构

在讨论 URL 时，了解其与 URI 之间的区别至关重要。它们常常被混淆，但实际上有所不同。我们先来看一个典型的 URL 例子：

https://www.baidu.com/web/579.html?replytocom=22#respond

URL 是统一资源定位符（Uniform Resource Locator）的缩写，它用于指定互联网上某个资源的地址。URL 描述了如何通过网络协议访问资源，并且它包含了对资源位置的指示，能够直接指向并定位到一个具体的资源。

在上面的例子中，URL 由以下几个部分组成：

• 协议 （Scheme）：https，表示使用的是 HTTPS 协议。这是访问资源时所用的传输协议，常见的还有 HTTP、FTP 等。
• 域名 （Domain）：www.baidu.com，表示目标服务器的域名地址。
• 端口 （Port）：默认情况下，https 使用 443 端口，http 使用 80 端口。此端口在 URL 中通常是省略的，因为默认端口已预设。
• 虚拟目录/文件名 （Path）：/web/579.html，表示资源的路径，通常指向特定的网页、文件或其他资源。它从服务器的根目录开始，指定了要访问的文件或资源。
• 参数 （Query）：?replytocom=22，表示查询参数，通常用来传递数据给服务器。这些参数通常是键值对的形式，多个参数之间用 & 分隔。
• 锚点 （Fragment）：#respond，用于指示文档中的某个位置，通常用于网页中的跳转，避免重新加载整个页面。

URI 是统一资源标识符（Uniform Resource Identifier）的缩写，是一种更广泛的标识符，它可以是一个 URL，也可以是一个 URN（统一资源名称）。URI 的目的是标识资源，无论它是否能够直接定位资源。

URI 可以分为两类：

1. URL（统一资源定位符）：它不仅标识资源，而且还包含了访问资源的方式（如协议、端口等）。
2. URN（统一资源名称）：它只是标识资源的名称，而不包含任何访问方式。URN 仅用于标识资源，不关心资源的实际位置。

关键区别：

• URL 是一种特殊的 URI，它提供了定位和访问资源所需要的全部信息（如协议、域名、路径、端口等）。
• URI 是资源的标识符，它可能包含 URL，也可能只是一个名字（如 URN），它的作用是标识资源，而不一定提供如何访问它的信息。

3.2 HTTP 状态码

HTTP 状态码是服务器响应客户端请求时返回的三位数字代码，用于指示请求的处理结果。状态码分为五个类别，分别表示不同的处理情况。以下是常见的 HTTP 状态码分类和具体含义：

1xx（信息性状态码）

这些状态码表示服务器已接收到请求并正在继续处理。

• 100 Continue：请求已接收，客户端应继续发送请求的剩余部分。这通常在客户端发送大文件或数据时，服务器希望客户端继续发送数据前发送的响应。

2xx（成功状态码）

这些状态码表示请求已经成功处理，服务器成功返回了所请求的内容。

• 200 OK：请求已成功处理，服务器返回了请求的数据。常见于浏览器请求的页面、资源等。
• 201 Created：请求已成功，并且服务器创建了新的资源。通常在 POST 请求时使用，例如在用户注册时创建新的账户。
• 204 No Content：请求已成功处理，但没有返回任何内容。常用于一些更新操作（例如 PUT 请求）后，表示资源已被更新，但不需要返回数据。

3xx（重定向状态码）

这些状态码表示客户端需要采取进一步的操作来完成请求，通常是由于资源已被移动或需要访问其他地址。

• 301 Moved Permanently：请求的资源已被永久移动到新位置，客户端应使用新的 URL 进行后续请求。这是搜索引擎优化中常用的重定向状态码。
• 302 Found：请求的资源临时被移动到另一位置，客户端继续使用原 URL，但可以根据 Location 头部字段提供的 URL 进行重定向。
• 304 Not Modified ：资源未修改，客户端可以使用缓存中的版本。通常在请求中包含 If-Modified-Since 或 If-None-Match 头部时，服务器通过此状态码通知客户端资源未改变。

4xx（客户端错误状态码）

这些状态码表示请求存在问题，通常是由于客户端的错误。

• 400 Bad Request：请求语法错误或无效，服务器无法理解。通常由于请求格式不正确或缺少必要的参数。
• 401 Unauthorized：请求需要身份认证，客户端未提供有效的凭证。例如，访问需要登录的页面时返回此状态码。
• 403 Forbidden：服务器理解请求，但拒绝执行。常见于没有权限访问资源的情况，尽管认证有效，权限不足也会返回此错误。
• 404 Not Found：服务器无法找到请求的资源。最常见的错误，当用户访问不存在的页面时，通常会看到此状态码。

5xx（服务器错误状态码）

这些状态码表示服务器在处理请求时出现了问题。

• 500 Internal Server Error：服务器内部发生错误，导致无法完成请求。通常是由于服务器配置或程序异常引起的。
• 502 Bad Gateway：服务器作为网关或代理时，从上游服务器接收到无效的响应。常见于使用反向代理服务器时，如果后端服务器出现问题，可能返回此错误。
• 503 Service Unavailable：服务器暂时无法处理请求，通常由于服务器过载或正在维护。这种状态码常见于高峰时段或者服务器正在更新时。
• 504 Gateway Timeout：服务器作为网关或代理时，在等待上游服务器的响应时超时。发生此错误通常是因为后端服务器响应时间过长。

4. 内外网的划分

4.1 内网（局域网）

内网（Local Area Network, LAN）是指组织内部的网络，其范围通常限于一个办公室、建筑物、园区或企业的多个分支机构。由于内网可以被完全控制，因此具有较高的安全性和较好的资源共享能力。

特点：

• 安全性高：内网与外网隔离，通过防火墙、VPN等技术进行安全防护，降低外部威胁。
• 资源共享：内网中的计算机、服务器和打印机等设备可以方便地共享文件和资源，提升工作效率。
• 访问控制：通过身份认证和权限管理，控制用户访问不同的内网资源。

应用场景：

• 企业办公：员工之间通过内网进行文件交换、打印、使用内部应用等。
• 学校教学：教师和学生使用内网进行学习资源的共享、教学管理系统的使用等。
• 医疗机构：医院内部通过内网实现病例管理、预约系统以及医疗设备的互联。

4.2 外网（广域网）

外网（Wide Area Network, WAN）通常指互联网，是全球范围内的开放网络，任何设备如果拥有公网 IP 地址并连接至互联网，就可以与全球其他设备进行通信。外网是数据交换和信息流通的主要载体，但由于其开放性，存在一定的安全隐患。

特点：

• 信息丰富：外网提供了全球的信息和服务，用户可以访问各种网站、在线应用和社交平台。
• 存在安全风险：由于外网的开放性，网络攻击、病毒传播、信息泄露等风险时刻存在。
• 全球连接：外网让不同国家、地区的计算机和设备能够互联互通，极大地推动了全球化。

应用场景：

• 信息获取：访问新闻、学习资源、电子图书等。
• 社交互动：通过社交媒体、即时通讯软件与全球用户互动。
• 电子商务：在线购物、支付、金融交易等。
• 远程办公：通过互联网访问远程服务器、虚拟专用网络（VPN）等工作。

4.3 公网与私网地址

公网和私网地址的区分是网络设计中至关重要的一部分。它们不仅有不同的使用范围，还会影响到网络的拓扑结构、安全性以及访问控制策略。

公网地址（Public IP）

公网地址是全球唯一的 IP 地址，通常由互联网服务提供商（ISP）分配。公网地址可以被全球的任何设备访问，因此其面临更大的安全风险。公网 IP 地址可以直接路由到互联网上的其他设备，且不受网络拓扑的限制。

特点：

• 全球唯一：公网地址是唯一的，世界上任何一个设备都无法使用相同的公网 IP 地址。
• 可路由到互联网上：公网 IP 地址可以通过互联网路由器访问全球任何地方的设备。
• 通常用于外部服务：如网站、服务器、云服务等都需要公网 IP 地址来保证外部用户的访问。

应用场景：

• 服务器托管：企业的 web 服务器、邮件服务器、文件服务器等通常需要公网 IP 地址进行对外服务。
• 网站建设：当企业需要搭建官网、电子商务平台等时，通常会使用公网 IP 地址来确保互联网用户的访问。
• 远程办公：需要通过 VPN 或直接公网访问公司内部系统的远程办公场景。

私网地址（Private IP）

私网地址是保留给局域网使用的 IP 地址，通常由网络管理员在内部网络中自行分配。私网地址不可以直接访问互联网，而是通过网络地址转换（NAT）或代理服务器访问外网。私网地址有多个保留范围，在局域网内是唯一的，但在不同的私有网络中可以重复使用。

特点：

• 仅在内网有效：私网 IP 地址仅对同一内网中的设备有效，无法直接路由到互联网。
• 可重复使用：私网 IP 地址是可复用的，多个不同的局域网可以使用相同的私网 IP 地址。
• 通过 NAT 转换访问外网：私网中的设备访问外网时，通常会通过路由器或防火墙进行 NAT 转换，使用公网地址与外界通信。

常见的私网地址段：

• 10.0.0.0 -- 10.255.255.255（A 类地址）
• 172.16.0.0 -- 172.31.255.255（B 类地址）
• 192.168.0.0 -- 192.168.255.255（C 类地址）

应用场景：

• 企业内部通信：局域网内的所有设备使用私网地址进行通信，无需担心公网地址的消耗和配置。
• 资源共享：打印机、文件服务器、数据库等设备可以在局域网内使用私网地址进行共享。
• VPN：通过 VPN 等方式将远程用户的设备与内网中的私网地址设备连接，确保数据传输的安全性。

公网与私网的对比

特性	公网地址	私网地址
唯一性	全球唯一	仅在局域网内有效
访问范围	任何设备都可以访问	只能通过内网设备访问，需借助 NAT 或代理等技术
地址分配	由 ISP 提供，通常需付费	由组织内部管理，无需支付额外费用
安全性	由于开放性，面临较高的安全风险（需防火墙保护）	安全性较高，外部无法直接访问
常见应用	Web 服务器、邮件服务器、在线服务等	局域网内设备、打印机、文件共享、内部应用等

结语

理解 HTTP 协议的演变、常见请求方法及内外网划分，对于构建高效、安全的网络系统至关重要。掌握这些知识，能帮助企业设计更加安全且高效的网络架构，提高应用的性能与用户体验。

最后，再次感谢您阅读本篇文章，如果您对文中内容有任何疑问或建议，欢迎在评论区与我交流！您的点赞和分享将是我继续创作的动力。