第5周——学习网络安全基础概念

引言

大家好！我是Aang (@iamaangx028)，一名正在进入网络安全领域的学生。作为学习旅程的一部分，我将通过每周博客与大家分享我的进展。

截至目前，我们已经学习了基础网络概念和浏览器概念。现在，我认为我们可以开始学习Web概念了。我们将循序渐进，一次一个概念。如果你还没有阅读我之前的博客，强烈建议你先阅读那些内容。不过，如果你已经具备了必要的基础知识，也没关系。让我们开始吧！

欢迎来到万维网

让我们尝试学习万维网的基本概念。这个阶段将比网络部分和浏览器部分花费更多时间，但我们会尽量覆盖尽可能多的概念。首先，让我们了解HTTP是如何演变的。

HTTP演进——HTTP/0.9/1.0/1.1/2.0/3.0

人们使用Web的方式迅速变化，其背后的工程技术也是如此！我们知道Tim Berners-Lee爵士为超文本传输协议（HTTP）和超文本标记语言（HTML）奠定了基础。

HTTP/0.9

1991年，HTTP/0.9是HTTP的第一个版本。它只有GET方法和请求资源的路径。除此之外，没有其他内容：没有头部、没有状态码、没有Content-Type，什么都没有！没有正式的请求评论（RFC）。它看起来如下：

请求：

1

GET /mypage.html

响应：

1

<html> .... </html>

通常，如果用户想要访问资源，会先进行成功的TCP三次握手，然后发送GET请求。如果服务器愿意发送响应，它就会发送。然后进行TCP拆除。TCP拆除只是客户端和服务器结束TCP会话的一种方式。因此，每次新请求都需要建立和关闭TCP连接，这并不高效。

HTTP/1.0

1996年，HTTP/1.0发布，为Web的变化奠定了基础。HTTP/1.0支持新的HTTP方法（如POST、HEAD）、状态码、头部（如Content-Type）以及浏览器和服务器之间的内容协商。与HTTP/0.9相比，HTTP/1.0有重大变化。

工程师们想出了发送其他媒体类型（如图像、视频和文本）的方法。通过在请求和响应中使用Content-Type头部，服务器和客户端都能够理解它们处理的文件的MIME类型。当时，互操作性问题很常见。甚至RFC（请求评论）和其他文档也被开发并维护，以帮助其他开发者理解Web。

尽管如此，它仍然遵循严格的请求-响应模型，这意味着只有在第一个请求的响应到达后才会发送第二个请求。即使在HTTP/1.0中，TCP会话默认在请求资源的数据传输后立即拆除。但有人说HTTP/1.0支持Connection: Keep-alive头部，但默认未使用。

HTTP/1.0可以通过SSL/TLS握手支持安全HTTP。因此，在HTTP/1.0中，每个请求都必须经过TCP三次握手和TLS握手。考虑到当时带宽的成本和价值，这是不可行的。我认为不无限期保持连接的原因之一是当时计算机的内存不足。

1994年底，HTTP发生了重大变化。Netscape公司在基本的TCP/IP栈之上开发了一个加密传输层，以防止中间人攻击（MITM）。Netscape引入了SSL 1.0，但从未向公众发布其文档。后来，发布了SSL 2.0等版本。SSL首先被电子商务网站采用。但后来，由于更强大的网站被开发，并且网站需要像PII这样的敏感信息来提供越来越多的服务，SSL/TLS成为所有网站的强制要求。

HTTP/1.1

HTTP/1.1于1997年发布，仅在HTTP/1.0发布几个月后。这个版本的HTTP使用最广泛。大多数遗留应用程序和服务器都支持HTTP/1.1。

HTTP/1.1解决了HTTP/1.0中的一些主要问题。它解决了请求资源的数据传输完成后立即拆除TCP连接的问题。在HTTP/1.1中，我们不需要为每个请求的资源反复执行三次握手和TLS握手。Connection: Keep-Alive在HTTP/1.1中成为默认设置。因此，我们可以在单个TCP和TLS会话中请求多个资源。会话或连接将保持活动状态，直到发送关闭请求或会话分配的时间到期（以先到者为准）。

HTTP/1.1还支持流水线（Pipelining），这在HTTP的初始版本中是无法看到的。这种流水线使客户端（如浏览器）甚至可以在收到第一个请求的响应之前发送多个请求。这样，客户端无需等待第一个请求的响应。因此，这些重大改进使浏览器能够比以前更快地加载页面。

但是，正如彼得叔叔所说，能力越大，责任越大。流水线实现有一些限制；你得到的响应必须与发送请求的顺序相同。因此，即使请求3的响应3准备发送到浏览器，如果第一个或第二个请求的响应延迟，响应3也会延迟。有时甚至更糟。鉴于TCP会发送自动重复请求（ARQ）以尝试获取丢失的数据片段，剩余的响应会被阻塞。这就是工程师所说的队头阻塞（Head of Line Blocking）。

因此，开发人员必须非常注意实现这种流水线，否则整个浏览器将无法工作。但正确实现这一点很困难。后来的一些浏览器禁用了这种流水线来从服务器获取资源。

在HTTP/1.1中，头部未压缩；相反，响应内容被压缩为不同的格式，如Brotli、GZIP、Deflate或identity。头部仅以文本形式发送。除了这些改进，HTTP/1.1支持分块响应。HTTP/1.1支持不同的缓存机制。Host头部还有助于在服务器的单个IP地址上托管不同的网站，这有助于高效使用服务器。

虽然HTTP/1.1中可以重用TCP连接来请求多个资源，但客户端仍然必须等待第一个请求的响应，这我们已经讨论过是队头阻塞。作为这个问题的解决方法，客户端会向一个源最多建立6个并行TCP连接。这提高了性能效率。同样，HTTP/1.1运行非常稳定。但一切都需要更新，HTTP/1.1也是如此。HTTP/1.1甚至在不同年份有两次重大修订。

如果你想更深入地学习，请随时查看这篇博客。

HTTP/2.0

HTTP/2.0于2015年发布。这个版本的HTTP是当今使用最广泛的。它解决了HTTP/1.1中的主要问题，如队头阻塞。

HTTP/2.0是一个二进制协议，因为与HTTP/1.1不同，它压缩头部并以流中的帧形式发送。如果你将国家高速公路视为TCP连接，这些流就像高速公路上的不同车道。每个车道促进帧与服务器之间的传输。这种实现解决了队头阻塞问题并提高了效率。

如果你深入思考这些帧是什么，帧实际上是我们从客户端发送到服务器的头部和数据。头部使用HPACK编码。数据（请求体）不一定由客户端压缩，除非你在请求中明确提及Content-Encoding: br, gzip, deflate。然后，这些数据（编码的头部和请求体）被制成通信的最小单位——帧。有不同的帧类型，如数据帧（Data FRAME）、头部帧（Header FRAME）。这些帧然后在流中发送到服务器。一个TCP连接中可以有多个流。每个帧都有一个流ID。这些帧在传输过程中可以混合，并在接收端放回原始序列。此外，我们可以为对我们最重要的帧设置优先级。

HTTP/2.0还支持服务器推送，意思是服务器用来在请求的资源之外发送额外资源的技术，即使没有被要求。

再次说明，所有这些过程都由应用层中的二进制分帧层处理。

HTTP/3.0

随着网站变得越来越复杂，HTTP/2.0显示出一些限制。到目前为止，所有HTTP版本都建立在TCP连接上。但由于TCP连接的性质，每当一些帧丢失时，会发送自动重复请求以获取丢失的帧，这会导致响应延迟。例如，如果JavaScript文件的某些部分丢失，整个渲染会停止，因为浏览器渲染引擎给JavaScript文件更高的优先级，正如我们上周博客所学。

为了避免这种情况，谷歌开发了QUIC协议，它建立在UDP协议上。UDP是一种无连接协议。QUIC代表快速UDP互联网连接。基本上，HTTP/3 = HTTP + QUIC + UDP。因此，鉴于QUIC是在UDP上开发的，每当一些帧丢失时，特定的流会被阻塞，而其他流可以无缝工作。现在网站正在采用HTTP/3.0。

因此，为了更清楚地说明：

在HTTP/1.1中，当你从浏览器发送请求时，头部以纯文本形式发送，尽管它们高度可压缩。因为它是这样开发的！但包含实际HTML/CSS/JS文档的响应体由服务器以压缩格式（brotli、Gzip、deflate，基于客户端的要求和服务器的可用性）发送到客户端（浏览器）。

在HTTP/2中，当你从浏览器发送请求时，头部被压缩并以二进制格式发送到服务器。这使得服务器解析头部的工作变得容易。但是，如果请求以二进制发送，那么当在Burp Suite中拦截时，我们如何能够以人类可读的格式看到请求呢？应该有一些我们不知道的事情在发生！

是的，你怀疑是对的。当你通过Burp Suite代理浏览器的流量时，浏览器理解并自动将HTTP/2降级为HTTP/1.1。这就是为什么我们可以在Burp Suite拦截选项卡中以人类可读的格式看到请求。当你转发它时，如果服务器支持，Burp Suite可以将请求升级到HTTP/2。或者你甚至可以在Burp Suite中更改此设置，将其保留为HTTP/1.1。

如果你想知道Burp Suite如何监听所有SSL/TLS流量，请阅读以下内容：Burp Suite可以这样做，只是因为你将PortSwigger的CA证书导入到浏览器的受信任根CA中。因此，有了这个CA证书，Burp Suite可以向任何网站颁发假SSL证书并自行签名。每当你尝试连接到安全网站时，会向网站发送CONNECT请求。但如果你通过Burp Suite代理流量，Burp Suite只会签署一个假SSL证书并将其发送到浏览器。鉴于你将Portswigger的CA导入到受信任的CA中，浏览器认为假SSL证书是合法证书。然后Burp Suite可以连接到网站，而网站这次发送原始SSL证书，Burp Suite根据其自己的受信任CA列表进行验证。这样，Burp Suite可以将自己置于浏览器（客户端）和网站（服务器）之间。因此，通常来说，对于浏览器，Burp Suite是服务器，而不是网站。而对于服务器，Burp Suite是客户端，而不是浏览器（当你通过Burp Suite代理流量时）。

内容协商

内容协商是一种用于以最合适的表示形式访问URI资源（来自服务器）的技术。不同的客户端（例如浏览器、Postman和CURL）对渲染资源有不同的方式和要求。换句话说，Firefox浏览器期望桌面视图和移动视图的资源表示不同。表示不过是相同资源的不同格式。

因此，客户端要求服务器发送最适合客户端的资源表示。然后服务器识别客户端请求，并尝试获取客户端要求的最合适的表示，并将其发送给客户端。客户端通过指定Accept:和Accept-*:头部来询问它想要的格式。下面是一个例子：

1
2
3
4
5
6


Accept: text/*
Accept-Encoding: br, gzip, deflate
Accept-Language: en-US
Accept-CH: # 在Accept-CH中，CH代表客户端提示。用于提供有关设备的信息，如内存、视口宽度和头部中的宽度。
# 有时使用UA。但这不是最佳实践。
User-Agent: 

响应头部

1

Vary:

内容协商有两种方式：

服务器驱动（主动）
代理驱动（反应式）

在服务器驱动中，客户端通过在头部中提供所需值来指定它期望的内容。然后服务器使用这些提示，并使用内部算法尝试获取请求资源的最合适表示。该内部算法是服务器特定的，不是标准的。有时，服务器无法找到请求类型的表示。然后，服务器可能发送406 Not Acceptable或415 Unsupported Media Type，或者有时根据服务器的配置发送默认格式。服务器在响应中发送Vary头部，指示服务器发送回客户端的内容，以便客户端可以理解并相应处理。

在代理驱动中，服务器发送所有可用的300多个选择。然后客户端从给定列表中选择任何一个。然后服务器发送回所选资源的表示。

但大多数时候，内容协商使用服务器驱动的方式。

资源

总的来说，我用来学习并觉得值得提及的资源是这些：

这篇MDN文档的HTTP演进，用于深入理解！
这个YouTube视频也帮助我理解了概念。

一些最后的闲聊

啊，这周就到这里了！是的，我觉得这周我们覆盖的内容很少。这些话题非常重要，所以我花了更多时间通过提问如什么、为什么，甚至有时如果会怎样来学习和理解每个话题。所以花了很多时间。我甚至花了两天时间处理一些个人工作。因此，这周的生产力下降了很多！希望从明天开始恢复势头。当然，我们错过了一些重要的话题。将尝试在接下来的几周内覆盖那些。所以，是的，下周见！祝你有一个高效的一周！

有反馈、更正或学习Web相关概念的酷想法吗？如果你有有趣的事情要讨论，请在X上联系我！

深入浅出HTTP协议演进与网络安全基础

本文详细解析HTTP协议从0.9到3.0版本的演进过程，涵盖TCP连接管理、头部压缩、流 multiplexing等核心技术，并探讨内容协商机制及Burp Suite中间人代理原理，帮助读者构建完整的Web安全基础知识体系。