超文本传输协议（HTTP）与超文本传输安全协议（HTTPS）

一、HTTP

超文本传输协议（HyperText Transfer Protocol，HTTP）是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

HTTP 是用于从互联网服务器传输超文本到本地浏览器或者另一个服务器的协议。

HTTP 是由蒂姆·伯纳斯-李（Imothy John Berners-Lee）于1989年在欧洲核子研究组织（CERN）所发起。1990年HTTP协议开始得到使用和发展，并经过不断的完善和扩展。

HTTP的标准制定由万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（Internet Engineering Task Force，IETF）进行协调。

HTTP 常见到版本有 HTTP/1.1，HTTP/2.0，HTTP/3.0。

1.HTTP 报文结构

1. 请求报文

HTTP请求是我们请求数据时先发送给服务器的数据，表明向服务器要什么。

HTTP请求由：请求行（Request Line）、请求头（Request Headers）、请求体组成的，
注意：GET请求是没有请求体的。

https://i-blog.csdnimg.cn/direct/c8bc984545834e898d389567cdd90ef3.png#pic_center" alt="在这里插入图片描述" />

（1）请求行（Request Line）

方法：如 GET、POST、PUT、DELETE等，指定要执行的操作。
请求 URI（统一资源标识符）：请求的资源路径，通常包括主机名、端口号（如果非默认）、路径和查询字符串。
HTTP 版本：如 HTTP/1.1 或 HTTP/2。

请求行的格式示例：GET /index.html HTTP/1.1
https://i-blog.csdnimg.cn/direct/27bde7a77329483b8f0db3ebc261d9b2.png#pic_center" alt="在这里插入图片描述" />

（2）请求标头（Request Headers）

包含了客户端环境信息、请求体的大小（如果有）、客户端支持的压缩类型等。

常见的请求头包括Host、User-Agent、Accept、Accept-Encoding、Content-Length等。

Host：客户端发送请求时，用来指定服务器的域名；
Content-Length：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度；
Connection：最常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用；
Content-Type：用于服务器回应时，告诉客户端，本次数据是什么格式；
Content-Encoding：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式；
Accept：告诉浏览器，它所支持的数据类型；
Accept-Encoding：支持哪种编码格式（如GBK UTF-8 GB2312 ISO8859-1）；
Accept-Language：告诉浏览器，它的语言环境；
Cache-Control：缓存控制；
Connection：告诉浏览器，请求完成是断开还是保持连接；

https://i-blog.csdnimg.cn/direct/10449c40273248f588d2c7a96f5c0d1c.png#pic_center" alt="在这里插入图片描述" />

（3）空行（Empty Line）

请求头和请求体之间的分隔符，表示请求头的结束。

（4）请求体（Request Body）

当请求方式是post的时，请求体会有请求的参数，格式如下：

username=root&password=123456

如下图是来自牛客网的一个完整请求报文
https://i-blog.csdnimg.cn/direct/697121590cb044ceb6532001a951ad84.png" alt="在这里插入图片描述" />

2. 响应报文

HTTP请求是我们服务器接受请求后返回的消息。

https://i-blog.csdnimg.cn/direct/65ed66c5443d45339c904fe8caca1212.png#pic_center" alt="在这里插入图片描述" />

（1）状态行（Status Line）

HTTP 版本：如 HTTP/1.1 或 HTTP/2。
状态码（status code）：表明请求是成功或失败。常见的状态码是 200、404 或 302。
状态文本（status text）：一个简短的信息，通过状态码的文本描述，帮助人们理解该 HTTP 消息。

状态行的格式示例：HTTP/1.1 200 OK
https://i-blog.csdnimg.cn/direct/f71d73cc281e4b5d8b104c940226c2e1.png#pic_center" alt="在这里插入图片描述" />

（2）响应标头（Response Headers）

包含了客户端环境信息、请求体的大小（如果有）、客户端支持的压缩类型等。

常见的请求头包括Host、User-Agent、Accept、Accept-Encoding、Content-Length等。

Host：客户端发送请求时，用来指定服务器的域名；
Accept：告诉浏览器，它所支持的数据类型；
Accept-Encoding：支持哪种编码格式（如GBK UTF-8 GB2312 ISO8859-1）；
Accept-Language：告诉浏览器，它的语言环境；
Cache-Control：缓存控制；
Connection：告诉浏览器，请求完成是断开还是保持连接；
Refresh：告诉客户端，多久刷新一次；
Location：让网页重新定位；
https://i-blog.csdnimg.cn/direct/a7bd444d3f94485cbd43a78790cc806d.png#pic_center" alt="在这里插入图片描述" />

（3）空行（Empty Line）

请求头和请求体之间的分隔符，表示请求头的结束。

（4）响应体（Response Body）

响应的最后一部分是主体。不是所有的响应都有主体：具有状态码（如 201 或 204）的响应，通常不会有主体。

如下图是来自牛客网的一个完整的响应报文。
https://i-blog.csdnimg.cn/direct/6741efb2d33d4738aa0698a9a1a4785f.png#pic_center" alt="在这里插入图片描述" />

2.HTTP状态码

HTTP状态码（HTTP Status Code）是用以表示网页服务器超文本传输协议响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。

所有状态码被分为五类，状态码的第一个数字代表了响应的五种状态之一。

状态码的类别

类别	描述
1xx	信息性响应 – 请求已接收，正在继续处理
2xx	成功 – 请求已成功接收、理解并接受
3xx	重定向 – 资源发生了变动，需要客户端用新的 URL 重新发送请求以完成请求
4xx	客户端错误 – 客户端发送的报文有误
5xx	服务器错误 – 服务器处理时内部发生了错误

常见的状态码：

类别	描述
200	请求被正常处理
204	请求被受理但没有资源可以返回
206	客户端只是请求资源一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
301	永久性重定向
302	临时重定向
303	与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
304	发送附带条件的请求时，条件不满足时返回，与重定向无关
307	临时重定向，与302类似，只是强制要求使用POST方法
400	请求报文语法有误，服务器无法识别
401	请求需要认证
403	请求的对应资源禁止被访问
404	服务器无法找到对应资源
500	服务器内部错误
503	服务器正忙

3.HTTP 请求方法

HTTP/1.1协议中共定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：

请求方式	描述
GET	用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器。
POST	用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
HEAD	获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
PUT	传输文件，报文主体中包含文件内容，保存到对应URI位置。
PATCH	客户端向服务器传送的数据取代指定的文档的内容(部分取代)。
TRACE	回显客户端请求服务器的原始请求报文，用于"回环"诊断。
DELETE	删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS	查询相应URI支持的HTTP方法。

GET方法与POST方法的区别

GET重点在从服务器上获取资源，POST重点在向服务器发送数据；
GET传输的数据量小，因为受URL长度限制，但效率较高；POST可以传输大量数据，所以上传文件时只能用POST方式；
GET是不安全的，因为GET请求发送数据是在URL上，是可见的，可能会泄露私密信息，如密码等； POST是放在请求头部的，是安全的。

4. 一次完整的HTTP请求所经历几个步骤

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：

建立TCP连接（三次握手）
Web浏览器向Web服务器发送请求行
一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GET /sample/hello.jsp HTTP/1.1。
Web浏览器发送请求头
浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。
Web服务器应答
客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。
Web服务器发送应答头
正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
Web服务器向浏览器发送数据
Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
Web服务器关闭TCP连接

二、HTTP/1.1

HTTP1.1（Hypertext Transfer Protocol Version 1.1）是超文本传输协议的一个版本，它是用来在Internet上传送超文本的传送协议。

万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（Internet Engineering Task Force，IETF）在1999年6月公布的 RFC 2616，定义了HTTP/1.1协议。

1.HTTP/1.1 对比 HTTP/1.0 的提升

HTTP1.1相比于HTTP1.0在多个方面进行了显著的提升和优化。这些提升主要体现在连接管理、缓存处理、请求和响应头部、错误处理、请求方法以及性能优化等方面。以下是对HTTP1.1相比于HTTP1.0的主要提升的详细归纳：

连接方式：HTTP/1.0默认使用非持久连接，即每次请求都需要建立一个TCP连接，完成后立即断开。这种方式会导致大量的连接建立和断开操作，增加了网络延迟和资源消耗。而HTTP/1.1则引入了长连接（持久连接）的概念，通过Connection: keep-alive头部字段来保持TCP连接不断开，用于传送多个HTTP请求和响应。这减少了建立和关闭连接的消耗和延迟，提高了网络利用率。
状态码：HTTP/1.0 仅定义了 16 种状态码，HTTP/1.1新增了一些错误状态码，如414（URL地址太长）、410（所请求资源被永久删除）、416（请求的范围不满足）、417（期望失败）等，用于更细致地描述错误情况。
请求方法：HTTP/1.1在HTTP/1.0的基础上扩展了一些请求方法，如OPTIONS、PUT、DELETE等。这些方法用于支持更多的操作，如查询服务器支持的通信选项、上传文件到服务器、删除服务器上的资源等。
缓存处理
- 强制缓存：HTTP/1.0中的缓存处理是可选的，而HTTP/1.1则强制要求所有的客户端和服务器都必须支持缓存处理。这通过Cache-Control等头部字段来实现，提高了缓存的效率和准确性。
- 断点传输：HTTP/1.1 还支持断点传输，即在上传/下载资源时，如果资源过大或网络中断，可以从已经上传/下载好的地方继续请求，而不需要从头开始。这通过 Range 和 Content-Range 头部字段来实现，提高了传输效率。
请求和响应头部
- 引入Host头域：HTTP/1.0 中没有 Host 头，一个 IP 地址对应一个站点。但随着虚拟主机技术的出现，一个物理服务器上可以存在多个虚拟主机，它们共享一个 IP 地址。因此，HTTP/1.1 引入了 Host 头域来区分不同的站点。
- 新增和改进头部字段：HTTP/1.1 新增了一些头部字段，如 If-Modified-Since、If-Unmodified-Since、If-None-Match 等，用于更精细地控制缓存和资源更新。同时，它也改进了 Expires 等头部字段的使用方式。

性能优化
- 管道化传输：基于 HTTP/1.1 的长连接，请求管道化成为可能。这允许客户端在不需要等待前一个请求响应的情况下，发送多个请求。虽然服务器仍然需要按照请求的先后顺序进行响应，但管道化传输可以减少整体的响应时间。

综上所述，HTTP/1.1 相比于 HTTP/1.0 在连接管理、缓存处理、请求和响应头部、错误处理、请求方法以及性能优化等方面都进行了显著的改进和优化。这些改进使得HTTP/1.1 更加高效、安全和灵活，成为当前 Web 开发中广泛使用的协议版本。

2.HTTP/1.1 的性能瓶颈

请求与响应的头部（Header）信息在未经压缩的情况下直接发送，这会导致随着首部信息的增多，传输延迟也会相应增大。HTTP/1.1 仅支持对Body部分进行压缩处理。
在通信过程中，往往会发送冗长的首部信息。如果每次通信都重复发送相同的首部，这无疑会造成大量的资源浪费。
服务器在处理请求时，通常是按照请求的顺序逐一进行响应的。因此，一旦某个请求的处理速度较慢，就会导致后续的请求被长时间等待，即出现“队头阻塞”现象。
在当前的通信机制中，缺乏对请求优先级的控制。这意味着所有请求都被视为同等重要，无法根据实际需求进行优先级排序。
目前的通信模式仍然是从客户端发起请求，服务器则被动地进行响应。这种单向的通信方式限制了双方之间的交互灵活性和效率。

三、HTTP/2

互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小组在2014年12月将HTTP/2.0标准提议递交至IESG进行讨论，并于2015年2月17日被批准。

2015年5月HTTP/2.0标准于RFC 7540正式发表。

相比于HTTP/1.1，HTTP/2.0做了如下提升。

二进制帧（Binary Framing）
- HTTP/1.1：数据以文本形式传输，报文结构为“请求行/状态行 + 头部字段 + 消息体”。
- HTTP/2.0：引入了二进制分帧（Binary Framing）机制，将所有传输的信息分割为更小的帧，并对它们采用二进制格式的编码。这提高了传输效率，并允许在传输过程中进行更精细的控制，如流量控制、优先级处理等。
头部压缩（Header Compression）
- HTTP/1.1：请求和响应的头部信息以纯文本形式传输，且每次请求都会重复发送相同的头部信息，这导致了不必要的带宽消耗和延迟。
- HTTP/2.0：引入了头部压缩（Header Compression）机制，使用 HPACK 算法对头部信息进行编码和压缩。在通信的两端维护一个索引表，记录出现过的头部字段和值，对于相同的头部，只需发送索引而不是完整的字段和值，从而减少了数据传输量。
服务器推送（Server Push）
- HTTP/1.1：服务器只能被动地响应客户端的请求，无法主动推送资源给客户端。
- HTTP/2.0：引入了服务器推送（Server Push）机制，允许服务器在客户端请求某个资源后，主动推送其他相关的资源给客户端。这减少了客户端需要发送的请求数量，提高了页面加载速度。
多路复用（Multiplexing）
- HTTP/1.1：使用持久连接（也称为长连接）来减少TCP连接建立和断开的次数，但每个请求仍然需要在不同的连接或同一个连接的不同时间点上串行发送。尽管引入了管道化（pipelining）技术，允许在同一个连接上发送多个请求而不必等待响应，但服务器仍然需要按照请求的顺序返回响应，存在队头阻塞（head-of-line blocking）问题。
- HTTP/2.0：引入了多路复用（Multiplexing）机制，允许在同一个TCP连接上并发地发送和接收多个请求和响应。每个请求和响应都被分割成更小的帧（frames），并在连接上交错传输。这样，即使一个请求/响应的处理被延迟，也不会阻塞其他请求/响应的传输，从而解决了队头阻塞问题。
流量控制：HTTP/2.0为数据流和连接的流量提供了一个简单的机制，基于窗口更新帧进行流量控制。
请求优先级：HTTP/2.0通过依赖和权重允许开发者对请求进行优先级排序，从而提高了应用程序的性能。

综上所述，HTTP/2.0在连接管理、头部压缩、数据传输格式、服务器推送等方面相比HTTP/1.1都有显著的提升。
这些提升使得HTTP/2.0更加高效、安全、灵活，并能够更好地适应现代网络环境的需求。

四、HTTP/3

在2018年10月28日的邮件列表讨论中，互联网工程任务组（IETF） HTTP和QUIC工作组主席 Mark Nottingham 提出了将HTTP-over-QUIC更名为HTTP/3.0的正式请求。IETF成员在2018年11月给出了官方批准，认可HTTP-over-QUIC成为HTTP/3.0。

2022年6月6日，IETF正式标准化HTTP/3.0为RFC9114。

相比于HTTP/2.0，HTTP/3 做了以下提升。

传输协议：HTTP/2.0 是基于 TCP 协议实现的，HTTP/3.0 新增了 QUIC（Quick UDP Internet Connections）协议（UDP 的升级版本）来实现可靠的传输，提供与 TLS/SSL 相当的安全性，具有较低的连接和传输延迟。
连接建立：HTTP/2.0 需要经过经典的 TCP 三次握手过程，TCP 和 TLS 是分层的，需要分批次来握手，先 TCP 握手，再 TLS 握手。由于 QUIC 协议的特性连接建立仅需 0-RTT 或者 1-RTT。这意味着 QUIC 在最佳情况下不需要任何的额外往返时间就可以建立新连接。
头部压缩（Header Compression）：HTTP/2.0 使用 HPACK 算法进行头部压缩，而 HTTP/3.0 使用更高效的 QPACK 头压缩算法。
队头阻塞：HTTP/2.0 多请求复用一个 TCP 连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。由于 QUIC 协议的特性，HTTP/3.0 在一定程度上解决了队头阻塞（Head-of-Line blocking, 简写：HOL blocking）问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。
连接迁移：HTTP/3.0 支持连接迁移，因为 QUIC 使用 64 位 ID 标识连接，只要 ID 不变就不会中断，网络环境改变时（如从 Wi-Fi 切换到移动数据）也能保持连接；而 TCP 连接是由（源 IP，源端口，目的 IP，目的端口）组成，这个四元组中一旦有一项值发生改变，这个连接也就不能用了。

五、HTTPS

1.HTTP 的问题

HTTP 由于是明文传输，所以安全上存在以下三个风险。

窃听风险，比如通信链路上可以获取通信内容，可以盗取用户信息。
篡改风险，比如强制植入垃圾广告，视觉污染。
冒充风险，比如冒充淘宝网站，欺诈用户。

2.HTTPS

超文本传输安全协议（HyperText Transfer Protocol Secure，HTTPS）是一种通过计算机网络进行安全通信的传输协议。
HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。

HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换资料的隐私与完整性。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。

3.HTTPS和HTTP区别

HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP）数据传输过程是加密的，安全性较好。
HTTPS需要到 CA（Certificate Authority，数字证书认证机构）申请证书
两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
HTTP和HTTPS使用的是完全不同的连接方式（HTTP的连接很简单，是无状态的；HTTPS 协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。）
HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 SSL 握手需要的 9 个包，所以一共是 12 个包。
HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

4.HTTPS工作原理

HTTPS（Hypertext Transfer Protocol Secure）是在HTTP基础上使用SSL/TLS协议加密通信的安全版本。HTTPS通过加密数据传输，确保数据在传输过程中的安全性和完整性。以下是HTTPS加密过程的简要步骤：

客户端发送支持SSL/TLS的请求：客户端向服务器发起连接请求，包含了支持的SSL/TLS版本、加密套件等信息。
服务器回复证书：服务器将自己的数字证书发送给客户端，证书中包含了服务器公钥（RSA加密）以及相关信息，用于加密会话密钥。
客户端验证证书：客户端收到服务器的证书后，会验证证书的合法性、有效期、域名、证书颁发机构等。
生成会话密钥：客户端生成一个随机数作为“会话密钥”（session key），用于对称加密（RSA加密）通信，该密钥不会在网络上传输。
使用服务器公钥加密会话密钥：客户端使用服务器的公钥对会话密钥使用MD5（或者SHA1）算法进行加密得到了RSA签名，然后发送给服务器，此时只有服务端通过RSA私钥能解密。
服务器解密会话密钥：服务器使用自己的私钥对客户端发送过来的加密的会话密钥进行解密，获取会话密钥。
加密通信：一旦建立了安全的通信信道，客户端和服务器就可以使用会话密钥对称加密算法（如AES）进行加密和解密通信内容。由于对称密钥加密效率高，因此实际通信中都使用对称加密算法进行数据传输。
会话结束：当客户端和服务器通信结束时，会话密钥将被丢弃，下次通信需要重新生成新的会话密钥进行加密。

通过以上握手和加密过程，HTTPS能够保护Web通信的安全性和隐私性，防止敏感信息在传输过程中被泄露或篡改。这使得用户可以放心地在互联网上进行敏感信息的传输和交换。