计算机网络八股——HTTP协议与HTTPS协议

HTTP1.1简述与特性

1. 报文清晰易读

2. 灵活和易于扩展

3. ⽆状态

4. 明⽂传输、不安全

HTTP协议发展过程

HTTP/1.1的不足

HTTP/2.0

HTTP/3.0

HTTPS协议

HTTP协议和HTTPS协议的区别

HTTPS中的加密方式

HTTPS中建立连接的方式

前言：

到时候我想要写一篇文章就是：在浏览器中输入URL并按下回车会发生什么？

然后将几篇文章全部串联到一起，现在几天的任务就是将这里的每个小部分进行一个详细的介绍

HTTP1.1简述与特性

Web 上的通信都是建⽴在 HTTP 协议上的：

1. 客户端发起 HTTP 请求；

2. 服务器做出响应处理后，返回 HTTP 响应报⽂；

HTTP协议主要有以下特点：（注意这里指的是HTTP1.1协议的特性，对于更高级版本的HTTP协议里，很多特性已经不再适合。）

报文格式简单，易于阅读
灵活和易于扩展
⽆状态
明⽂传输、不安全

下面我将详细介绍以下HTTP协议的这几个特点：

1. 报文清晰易读

HTTP基本报⽂格式为header+body，头部信息也是key-value简单⽂本的形式，易于理解。

HTTP/1.1 的报文格式非常便于阅读，因为它：

是文本格式： 请求行、状态行和头部都是由可读的 ASCII/ISO-8859-1 字符组成的文本行。
结构清晰： 头部是简单的 "Key: Value" 形式，每行一个头部字段，以空行结束头部，后面跟着报文体（如果存在）。

这使得开发者、系统管理员等可以很方便地使用 telnet、curl -v 或者查看网络抓包工具（如 Wireshark）中的文本视图来直接阅读、理解和调试 HTTP/1.1 报文。

2. 灵活和易于扩展

HTTP协议⾥的各种请求⽅法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，允许开发⼈员⾃定义和扩充; HTTP⼯作在应⽤层（OSI第七层），下层可以随意变化;

HTTPS就是在HTTP与TCP之间增加了SSL/TSL安全传输层，HTTP/3把TCP换成了基于UDP的QUIC。

常见状态码详细介绍

HTTP 协议规范（以及后续的 RFC 文档）定义了大量的标准状态码，用于表示服务器对客户端请求的处理结果。这些状态码被分组在不同的类别中：

HTTP 状态码（Status Code）只包含在 HTTP 响应报文中。它是响应报文的起始行（Status-Line）的一部分。

如果客户端收到了来自目标地址的有效的 HTTP 响应报文，并且其中包含了 HTTP 状态码，那么这基本上可以确定您已经成功连接到了目标服务器。

1xx

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx

3xx 类状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location ，指明后续要跳转的 URL，浏览器会自动重定向新的

URL。「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

4xx

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。

3. ⽆状态

无状态

服务器不会保留任何关于客户端在之前请求中的信息或状态。每一次 HTTP 请求都是完全独立的，服务器处理当前的请求时，不会记住或依赖于客户端之前发送的任何请求。

简单来说，就像服务器得了“短期失忆症”。客户端每发送一个请求给服务器，服务器就像是第一次见到这个客户端一样，它只根据当前请求报文中的信息来进行处理和响应。

无状态带来了什么影响？

优点：

最大的优点就是：服务器设计简单： 服务器不需要为每个客户端维护大量的状态信息，大大简化了服务器的设计。

缺点：

每次请求需要携带足够的信息： 由于服务器不记事儿，客户端每次发送请求时，必须携带所有必要的信息来完成本次请求。例如，如果要访问需要登录才能看到的页面，每次请求都需要带上身份认证信息。
需要额外的机制来管理会话状态： 对于需要保持用户状态的应用（如购物车、用户登录），仅仅依赖无状态的 HTTP 是不够的。为了记住用户是谁、购物车里有什么，需要在 HTTP 协议之上引入其他的技术或方法来管理状态。

通过 Cookie（在客户端存储标识符）和 Session（在服务器端存储具体状态），我们就可以在无状态的 HTTP 协议上构建有状态的 Web 应用。

Cookie（客户端）中常见的保存内容包括：

会话标识符 (Session ID)： 这是最常见和核心的用途。Cookie 中通常存储一个由服务器生成的唯一的 Session ID，用于在服务器端查找对应的 Session 数据。这个 Session ID 是服务器在用户第一次访问时生成的，并通过 HTTP 响应头部的 Set-Cookie 发送给浏览器。之后，浏览器在向同一个网站发送后续请求时，会自动在请求头部的 Cookie 字段中带上这个 Session ID 发送给服务器。
用户偏好设置： 比如用户选择的语言、主题、页面布局、是否记住用户名等简单的配置信息。
跟踪信息： 用于网站分析或广告跟踪，记录用户的访问行为、来源、最后访问时间等标识符或简单数据。
状态标志： 例如，用户是否已经看过某个新手引导、某个弹窗广告，或者接受了 Cookie 政策等。
“记住我”功能相关的 Token： 为了实现长期登录（“记住我”），Cookie 中会存储一个由服务器生成的、用于下次访问时自动登录的 Token 或标识符，而不是直接存储用户名和密码（非常不安全）。

Cookie 保存的是用于在客户端和服务器之间传递或在客户端本地持久化少量信息的文本数据，主要用于用户识别、状态管理和个性化设置等方面，绝对不应该在 Cookie 中直接存储敏感信息，特别是用户的密码。

Cookie 一般可以被设置为在客户端长久保存，几天、几个月甚至几年。

Session（服务器端）： Session 机制则负责在服务器端存储用户的具体状态信息。服务器接收到客户端发送的请求后，从 Cookie 中读取 Session ID。然后根据这个 Session ID，在服务器端的内存、数据库、文件或缓存（如 Redis）中查找对应的用户状态数据（例如：用户是否已登录、用户的用户名、购物车中的商品列表、用户的权限等）。

Session 的目的是为了在一次连续的、相对短暂的用户访问过程中维持状态。一旦用户离开、长时间不活动或明确结束会话，相关的 Session 数据就会被清理，以确保服务器资源的有效利用和数据安全。

服务器端的 Session 是临时存在的

4. 明⽂传输、不安全

HTTP 报文（特别是头部信息、请求 URL、以及报文体如果是文本格式的内容）在客户端和服务器之间传输时，是不经过加密的，直接以文本（字符串）的形式在网络上传输。

易于理解和调试： 正因为是明文，开发者或管理员可以使用抓包工具（如 Wireshark）或者在浏览器开发者工具中直接看到 HTTP 请求和响应的详细内容，非常便于理解和调试。
安全性风险： 这是明文传输最大的问题。由于数据是直接可读的，如果传输的内容包含敏感信息，比如：登录的用户名和密码，用户在表单中输入的个人信息，请求的 URL 本身（可能包含敏感参数）。

任何能够截获网络流量的第三方（比如在同一个 Wi-Fi 下的人、互联网服务提供商、网络路由器等）都可以直接读取这些信息，造成数据泄露的风险。

为了解决 HTTP 的明文传输带来的安全问题，就引入了 HTTPS。HTTPS 是在 HTTP 和 TCP 之间增加了一层 SSL/TLS 加密层。这样一来，即使 HTTP 报文内容是明文的，但在通过网络传输之前，整个报文会被 SSL/TLS 层加密，变成只有服务器（拥有私钥）才能解密的密文。传输过程中的第三方截获到的将是无法解读的乱码，大大提高了通信的安全性。

HTTP协议发展过程

⽬前为⽌，HTTP 常⻅的版本有 HTTP/1.1 ， HTTP/2.0 ， HTTP/3.0 ，不同版本的 HTTP 特性是不⼀样的。我们上面介绍到的HTTP/1.1的很多特点已经不适用 HTTP/2.0 ， HTTP/3.0了。

关于HTTP1.1之前的版本我们就来进行简单了解一下就行啦：

HTTP/0.9

HTTP/0.9 是最早的HTTP版本，在1991年就已经发布，只⽀持 GET ⽅法，也没有请求头，服务器只能返回 HTML格式的内容。

HTTP/1.0

HTTP/1.0 是HTTTP 协议的第⼀个正式版本, 主要具有以下特性：

引⼊了请求头和响应头，⽀持多种请求⽅法和状态码

不⽀持持久连接，每次请求都需要建⽴新的连接，属于短连接

为了解决 HTTP/1.0 每次请求都需要建⽴新的连接的问题， HTTP/1.1 提出了⻓连接（持久连接），只要客户端和服务器任意⼀端没有明确提出断开连接，则保持TCP连接状态。

HTTP/1.1的不足

首先说一下HTTP/1.1的一些其他缺点，当然这是相对于HTTP/2.0的改进来说的啦。

1. 在 HTTP/1.1 中，为了确保通信的正确性和可靠性，客户端通常会等待接收到一个请求的完整响应后，才在同一个持久连接上发送下一个请求。

关于HTTP请求，我想先补充一下：访问一个网页（输入一次网址）需要发出多次 HTTP 请求这个知识。

一个标准的 HTTP 请求是为了获取一个特定的“资源”（Resource）。在很多情况下，这个“资源”对应于服务器上的一个文件（比如一个 HTML 文件、一个 CSS 文件、一个图片文件）。

一个网页是由多个文件进行组成的，所以访问一个网页需要多次发出HTTP请求，而我们的HTTP1.1协议的请求必须等到上一个HTTP请求的响应到达才可以发送下一个。这就导致浏览器渲染页面时候渲染得很慢，因为数据可能需要一段时间才能完全准备好。

虽然HTTP/1.1 理论上有一个叫做**管线化（Pipelining）**的功能，允许客户端在收到上一个请求的响应之前就发送下一个请求。如果管线化被完全启用且工作正常，那么就不需要等收到响应再发送下一个请求。但是几乎没有浏览器会采用HTTP/1.1的管线化。

因为HTTP1.1的管线化要求数据必须顺序响应，比如请求了1，2，3，响应也必须按照1，2，3来响应。

在 HTTP/1.1 开启管线化后，接收响应的顺序和请求顺序不一致（比如请求 1, 2, 3，响应收到 2, 1, 3），通常会导致直接的错误，浏览器也很难进行有效的暂存和重组。

原因在于 HTTP/1.1 是基于文本流的协议，并且在同一个连接上，客户端解析响应必须是严格按照顺序来的。感觉HTTP/1.1的管线化很鸡肋，所以一般不开启HTTP1.1的管线化也正常！

为了提高HTTP/1.1请求响应速度，我们可以采用如下优化方式：

1. 建立多条tcp连接，这是现代浏览器在处理 HTTP/1.1 网页时默认采用的策略。它们通常会限制对同一个域名同时建立的连接数（一般是 6-8 个）。

2. 将一些文件内容尽可能合并，减少需要传输的文件数量，例如，将多个 CSS 文件合并成一个 CSS 文件，将多个 JS 文件合并成一个 JS 文件，将多个小图片合并成一个雪碧图 - Sprite Image）。

雪碧图：

将网页中多个小图片（例如各种图标、按钮背景、小装饰图等）合并到一张大的图片文件中。
在网页中使用这些小图片时，不再分别引用原始的单个图片文件。而是将需要使用小图片元素的背景图片设置为这张大的雪碧图。
然后，通过 CSS 的 background-position 属性，精确地控制元素的背景图片显示区域，只显示雪碧图中的某个特定小图片部分。同时设置元素的 width 和 height 来定义这个显示区域的大小。

HTTP/2.0

二进制分帧层 (Binary Framing Layer)：

特点： 这是 HTTP/2 最基础的变化。HTTP/2 不再是 HTTP/1.1 那样的纯文本协议，而是在应用层和传输层之间增加了一个二进制分帧层。HTTP/2 的所有通信都被分解为更小的、带有标识符和长度前缀的二进制帧 (Frames)。
工作原理： 不同类型的消息（如头部、数据）都被封装在不同类型的帧中。这些帧拥有流标识符 (Stream Identifier)，用于区分它们属于哪个请求或响应。
带来的改进： 这是实现 HTTP/2 其他所有高级特性的基础。将报文分割成帧使得多路复用、优先级控制等成为可能，改变了 HTTP/1.1 基于文本和顺序解析的模式。

多路复用 (Multiplexing)：

特点： 允许在单个 TCP 连接上同时发送和接收多个 HTTP 请求和响应，并且它们可以乱序发送和到达。
工作原理： 通过二进制分帧和流（Stream）的概念实现。每个请求/响应都在一个独立的逻辑流中进行，由唯一的 Stream ID 标识。不同流的帧可以在同一个 TCP 连接上交错发送。客户端和服务器根据帧的 Stream ID 将它们重新组装成完整的请求或响应。
带来的改进 (解决 HTTP/1.1 队头阻塞和多连接开销)： 这是 HTTP/2 解决 HTTP/1.1 应用层队头阻塞问题的核心机制。一个请求/响应的延迟不会阻塞同一连接上的其他请求/响应。同时，它大幅减少了 HTTP/1.1 中为了提高并行度而不得不建立多个 TCP 连接的开销（三次握手、四次挥手、慢启动等），降低了延迟和服务器资源消耗。

头部压缩 (Header Compression - HPACK)：

特点： 有效地压缩 HTTP 头部，减少重复数据的传输。
工作原理： HTTP/2 使用 HPACK 压缩算法。它在客户端和服务器之间维护和更新一个共享的头部信息表，包括静态表（预定义常见的头部字段）和动态表（记录本次连接中发送过的头部）。传输头部时，如果头部字段是表中已有的，只需发送其索引；如果是新的字段，则发送其值并更新表。此外，还使用了 Huffman 编码对字符串进行压缩。
带来的改进 (解决头部冗余)： 大幅减少了重复发送的头部数据量，特别是在请求同一个网站的多个资源时，头部通常非常相似，压缩效果显著，节省了带宽，提高了传输效率。

强制使用 HTTPS (De Facto Requirement for HTTPS)：

特点： 虽然 HTTP/2 规范本身允许在明文 TCP 上运行（称作 h2c），但目前绝大多数主流浏览器（如 Chrome, Firefox, Edge, Safari）只支持在 TLS/SSL 加密连接上运行 HTTP/2（称作 h2）。
带来的影响： 实际上促使了网站向 HTTPS 迁移，因为只有使用了 HTTPS，才能享受到 HTTP/2 带来的性能优势，从而提高了整个 Web 的安全性。

HTTP/3.0

HTTP/2.0仍然可能面临传输层（TCP 层面）的队头阻塞问题。

因为 HTTP/2 的所有流（Streams）的数据帧都是在同一个 TCP 连接上进行传输的，它们的数据是被混合（多路复用）在一起发送的。如果 TCP 连接中的一个数据包丢失了，并且这个数据包中包含了多个 HTTP/2 流的帧数据，那么 TCP 层面的阻塞会导致所有这些流以及后续流的数据都无法及时递交给 HTTP/2 层进行处理和重组，直到丢失的数据包被恢复。

HTTP/3： 基于 UDP 的 QUIC 协议，提供了传输层面的多路复用。QUIC 的流是独立的，一个流的丢包不会阻塞其他流的数据传输。因此，HTTP/3 彻底解决了队头阻塞问题（包括应用层和传输层）。但是目前HTTP/3.0应用不广泛，目前用的最多的还是HTTP/2.0。

HTTPS协议

HTTP协议和HTTPS协议的区别

HTTP：超文本传输协议

HTTPS：超文本安全传输协议

HTTPS 本质上不是一个全新的、独立的协议，它更准确地说是一个 在安全层上运行的 HTTP 协议。它是在标准的 HTTP 协议与底层的传输协议（主要是 TCP）之间插入了 TLS/SSL（传输层安全/安全套接层） 协议。

当您建立一个安全的 HTTPS 连接时，实际使用的是 TLS 协议（通常是 TLS 1.2 或 TLS 1.3）

TLS 是 SSL 的继任者（或升级版本）。它是基于 SSL 3.0 演变而来的。SSL 版本（特别是 SSL 2.0 和 SSL 3.0）由于存在已知的严重安全漏洞，已经被弃用了。我们现在可以认为HTTPS = HTTP + TLS。

安全性 (Security):
- HTTP: 数据在客户端和服务器之间以明文形式传输。这意味着任何能够截获网络流量的第三方（如网络管理员、ISP、攻击者）都可以直接读取传输的数据内容，包括敏感信息（用户名、密码、支付信息等）。数据也容易被篡改而客户端无法得知。
- HTTPS: 数据在传输前会经过 TLS/SSL 加密。截获的数据是加密后的密文，难以解读。TLS/SSL 还提供数据完整性检查，确保数据在传输过程中没有被篡改。此外，通过服务器身份认证（通常基于数字证书），客户端可以确认正在通信的服务器是合法的，防止中间人攻击。

协议层级 (Protocol Stack):
- HTTP: 直接运行在 TCP 协议之上。
- HTTPS: 运行在 TLS/SSL 协议之上，而 TLS/SSL 又运行在 TCP/UDP 协议之上。简而言之，是 HTTP -> TLS/SSL -> TCP/UDP。

URL 前缀 (URL Scheme):
- HTTP: 使用 http://。
- HTTPS: 使用 https://。

默认端口 (Default Port):
- HTTP: 默认使用端口 80。
- HTTPS: 默认使用端口 443。

证书要求 (Certificate Requirement):
- HTTP: 不需要任何证书。
- HTTPS: 服务器必须拥有由受信任的证书颁发机构 (CA) 颁发的 SSL/TLS 数字证书。这个证书用于证明服务器的身份。虽然获取证书曾需要付费，但现在有许多机构提供免费证书（如 Let's Encrypt）。

连接建立过程 (Connection Process):
- HTTP: TCP 三次握手即可开始传输 HTTP 数据。
- HTTPS: 在 TCP 三次握手之后，还需要进行 TLS/SSL 握手过程。这个握手过程用于协商加密算法、交换密钥、进行身份验证等。这会增加一些初始连接建立的延迟。

HTTP 本身不加密，HTTPS 的加密是由 TLS/SSL 层完成的，通过复杂的握手过程（利用非对称加密和证书认证）来安全地协商出会话期间用于数据传输的对称密钥，然后使用该对称密钥对所有 HTTP 数据进行快速加密传输。

HTTPS中的加密方式

对称加密

对称加密也称为私钥加密，使⽤相同的密钥来进⾏加密和解密。在加密过程中，明⽂数据通过应⽤特定的算法和密钥进⾏加密，⽣成密⽂数据。解密过程则是将密⽂数据应⽤同样的算法和密钥进⾏解密，恢复为明⽂数据。由于加密和解密都使⽤相同的密钥，因此对称加密算法的速度通常较快，但密钥的安全性很重要。如果密钥泄漏，攻击者可以轻易地解密数据。

对称加密指的就是，双方都知道加密的算法，并且都拥有解密的钥匙，但是这个钥匙如果不小心被攻击者知道的话，即使双方通信时使用的是加密好的文件，攻击者也可以用偷来的钥匙进行解开。你可能会想为什么这个私钥有机会被攻击者偷到呢？因为这个私钥一定是需要一方通过网络明文传递给另一方的，这样就给了攻击者可乘之机。

⾮对称加密

⾮对称加密也称为公钥加密，使⽤⼀对不同但相关的密钥：公钥和私钥。公钥⽤于加密数据，私钥⽤于解密数据。如果使⽤公钥加密数据，只有拥有相应私钥的⼈才能解密数据；如果使⽤私钥加密数据，可以使⽤相应公钥解密。除了加密和解密，⾮对称加密还⽤于【数字签名】，可以验证消息的来源和完整性。

非对称加密实际上是把制作这把锁的方法公开，任何人都可以按照你说的方法来制造这把锁并且把想要保密的内容锁上，然后只有你自己有这把钥匙打开！钥匙一直掌握在你自己的手中，没有进行传播，不可能出现泄露。

你可能会想就是为什么制作锁的方式公布出去了之后，难道不能通过这个锁推断出钥匙是什么样子的吗？这就涉及数学中的陷门单向函数

例如 RSA 算法。生成密钥时，你选择两个非常大的素数作为私钥的一部分，然后将它们相乘得到一个更大的合数，这个合数就是公钥的一部分。乘法是容易的。但给定一个非常大的合数，想要找出它的两个原始素数因子（分解因数），在目前没有任何已知的快速算法，计算量会随着数字的增大呈指数级增长。

HTTPS中的非对称加密+对称加密

HTTPS 中采用的加密算法是 非对称加密 + 对称加密的混合加密方式。

在握手阶段 (Handshake Phase)：
- 主要使用非对称加密。这是为了安全地协商和交换用于后续数据传输的对称密钥。因为非对称加密的公钥(锁的制作方法)是公开的，发送方可以用公钥加密一个密钥，只有拥有对应私钥的接收方能解密得到，这样发送方和接收方就都获得了对称加密算法中的私钥，并且这个私钥没有在网络中以明文的方式传播，所以黑客是获取不到对称加密的私钥的。
- 同时，非对称加密（通过数字签名）也用于验证服务器的身份（客户端使用 CA 的公钥验证服务器证书上的签名）。
在数据传输阶段 (Data Transfer Phase)：
- 一旦握手完成，双方就使用在握手阶段协商和生成好的对称密钥来对实际传输的大量 HTTP 数据（请求头、体、响应头、体）进行对称加密。

为什么采用混合方式？

非对称加密虽然安全（密钥交换和身份验证），但计算开销大，速度慢，不适合用来加密大量的数据。
对称加密计算开销小，速度快，适合用来加密大量的数据，但它的问题在于如何安全地在通信双方之间共享密钥。

HTTPS 的混合加密正是解决了这个矛盾：利用非对称加密的安全性来解决对称密钥的共享问题（安全地交换对称密钥），然后利用对称加密的高效性来解决大量数据加密的问题。

HTTPS中建立连接的方式

HTTPS 连接的建立过程可以分解为两个主要步骤：

底层 TCP 连接建立：
- 这是任何基于 TCP 的网络通信（包括 HTTP 和 HTTPS）都需要的第一步。
- 客户端和服务器之间进行经典的 TCP 三次握手 (Three-Way Handshake)：
  - 客户端 -> 服务器: SYN (同步序列号)
  - 服务器 -> 客户端: SYN-ACK (同步序列号并确认)
  - 客户端 -> 服务器: ACK (确认)
- 握手成功后，客户端和服务器之间就建立了一个可靠的、双向的 TCP 连接。
TLS/SSL 安全连接建立
- 客户端向服务器索要并验证服务器的公钥（非对称加密）。
- 双⽅协商⽣产「会话秘钥」（对称加密）。
- 双⽅采⽤「会话秘钥」进⾏加密通信。