[网络协议]认识HTTP以及迭代历程

什么是HTTP，你真的了解HTTP吗，它的优点有哪些，在迭代的过程中他有哪些改动，HTTPS和HTTP都有哪些区别，下面详细的聊一下。

什么是HTTP

http是超文本传输协议，可以将其拆成三个部分（超文本、传输、协议）

协议

协议在生活中也经常遇见，比如租房协议、毕业时的三方协议。协议也就是两个或者以上的参与者遵守一种行为约定规范。

HTTP协议我们可以理解为是一种计算机可以理解的通信规范（两个以上参与者），以及相关的各种控制和错误处理方式（行为约定和规范）。

传输

传输就是把一堆东西从A点搬运到B点，或者从B点搬运到A点。

HTTP协议时一个双向协议。

客户端和服务器是双向传输的，双方约定使用HTTP协议来通信，预设客户端向服务器发送请求，服务器向客户端返回数据。

需要注意的是，尽管两者之间是双向传输，但是中间允许有中转或者接力。只要中间人遵从HTTP协议，不打扰基本数据的传输，就可以添加额外的东西。

基于协议和传输，我们可以将HTTP理解为一个在计算机世界里专门用来做两点之间传输数据的约定和规范。

超文本

超文本是HTTP的传输内容。

字面理解，就是超越了普通的文本，是文字、图片、视屏等的混合体，最关键的事由超链接，能从一个文本跳转到另外一个文本。

HTML就是最常见的超文本，它本身知识纯文字文件，但是内部多标签定义了图片、视频等的链接，再经过浏览器的解释，呈现给我们的就是一个文字，有画面的网页。

所以HTTP就介绍成一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

那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 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

[404 Bad Request] 表示客户端请求的报文有错误，但只是个笼统的错误。

[403 Forbidden] 表示服务器禁止访问资源，并不是客户端的请求出错。

[404 Not Found] 表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5XX

5XX 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

[500 Internal Server Error] 与400类型，是个笼统的错误码，服务器发生了什么错误我们并不知道。

[501 Not Implemented] 表示客户端请求的功能还不支持，类似于“即将开业，敬请期待”的意思。

[502 Bad Gateway] 通常是服务器作为网管或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

[503 Service Unavailable] 表示当前服务器很忙，无法响应服务器。

HTTP常见字段

Host

客户端发送请求时，用来指定服务器的域名。

有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。

Host: www.A.com

Content-Length

服务器在返回数据时，会有Content-Length字段，表明本次资源的数据长度

Content-Length: 1000

Connection

用于客户端要求服务器使用TCP持久连接，以便其他请求复用。

HTTP/1.1 版本的默认连接都是持久连接，单位了兼容老版本的HTTP，需要指定Connection首部字段的值为 Keep-alive.

Connection: keep-alive

一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。

Content-Type

用于服务器回应时，告诉客户端，本次数据是什么格式。

Content-Type: text/html; charset=utf-8

类型表明发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式，

Accept:*/*

上面代码中，客户端声明自己可以接受任何格式的数据。

Content-Encoding

Content-Encoding 说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。

Content-Encoding: gzip

上述表示服务器返回的数据采用了gzip方式压缩，告知客户端需要用此方式解压。

客户端在请求时，用Accept-Encoding 字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

Get 与 Post

Get方法的含义就是从服务器获取资源，这个资源可以使静态文本、页面、图片视频等。

Post 方法可以提交指定的数据，数据放在报文的body里。

get和post方法都是安全和幂等的吗

先说明安全和幂等的概念：

• 在HTTP协议里，所谓的安全是指请求方法不会破坏服务器上的资源。
• 所谓幂等意思是多次执行相同的操作，结果都是相同的。

所以get方法是安全且幂等的，因为它是只读操作，无论操作多少次，服务器上的数据都是安全，且每次结果都是相同的。

post方法因为是新增或者提交数据的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以是不幂等的。

HTTP的特性

你知道HTTP（1.1）的优点有哪些，怎么体现的？

HTTP最突出的优点是简单，灵活和易扩展，应用广泛和跨平台。

简单

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

灵活和易于扩展

HTTP协议里的请求方法，URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许卡司法人员自定义和扩展。

且HTTP所处的层是应用层，下层可以随意变化。

应用广泛和跨平台

HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、

刷贴吧到购物、理财

缺点

HTTP 的缺点是无状态、明文传输，同时还具有不安全的特性。

无状态不需要记录额外的信息，减轻服务器的负担，能够吧更多的资源提供给对外服务，但是因为没有记忆力，需要关联操作时操作比较麻烦。

对于无状态，可以使用cookie来解决，记录下客户端的状态。

明文传输移位了传输的信息可以直接阅读，带来调试的遍历性，但是这样相当于信息裸奔，信息没有隐私可言，容易被窃取。

因为使用明文，容易被窃取信息，通信是不验证身份，也容易遭遇伪装，报文的完整性也可能被篡改，出现垃圾植入的问题。

安全性问题可以通过HTTPS解决，也是通过引入SSL/TLS层，使得在安全上达到了一致。

HTTP/1.1的性能如何？

HTTP协议时基于TCP/IP协议，并使用了请求-应答的通信模式，

长连接

HTTP/1.0性能上的一个很大问题，就是发起一个请求就要新建一次TCP连接，而且是串行请求，做了无谓的TCP连接建立和断开，增加了通信开销。

为了解决该问题，HTTP/1.1突出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了TCP连接的重复建立和断开所造成的的额外开销，减轻了服务器端的负载。只要任意一端没有明确提出断开连接，则保持TCP连接状态。

网络管道传输

HTTP/1.1采用了长连接的方式，这使得管道网络传输成为了可能。

即可在同一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发送第二个请求出去，可以减少整体的响应时间。

但是还是需要按照顺序返回，先响应A请求，完成后再回应B请求。要是前面的回应特别慢，后面就会有许多请求排队等待，成为对头阻塞。

对头阻塞

因为当顺序发送的请求中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到的数据，这也就是对头阻塞。

总之 HTTP/1.1 的性能一般般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能。

HTTP与HTTPS

HTTP于HTTPS有哪些区别

1. HTTP是差文本传输协议，信息明文传输，存在安全风险问题。HTTPS解决其不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，是的报文能够加密传输。
2. HTTP连接建立相对简单，三次握手后便可以进行HTTP的报文传输。而HTTPS在TCP三次握手之后，还需要进行SSL/TSL的握手过程，才可以进行报文传输。
3. HTTP 的端口号为80，HTTPS 的端口号为443。
4. HTTPS协议需要想CA（证书权威机构）申请数字证书，来保证服务器的身份是可靠的。

HTTPS解决了HTTP的哪些问题？

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

窃听风险

篡改风险

冒充风险

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。

校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。

身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

HTTPS是如何解决上面三个风险的。

混合加密

混合加密保证了信息的机密性，解决了窃听风险

采用对称加密和非对称加密结合的混合加密方式

? 通信前采用非对称加密的方式交换会话秘钥，后续就不再使用非对称加密

? 在通信过程中全部采用堆成加密的会话秘钥的方式加密明文数据

原因

对称加密只是用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换

非对称加密使用两个密钥（公钥和私钥），公钥可以任意分发而私钥保密，解决了密钥交换的问题但是速度慢

摘要算法

摘要算法用来实现完整性，能够为数据生成独一无二的指纹，用于校验数据的完整性，解决了篡改的风险。

客户端再发送明文之前会通过摘要算法算出明文的指纹，发送的时候把指纹+明文一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户携带的指纹和当前算出的指纹做比较，若指纹相同，说明数据是完整的。

数字证书

通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

客户端先想服务器端所要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

这就就存在了问题，如何保证公钥不被篡改和信任度？

这里就需要借助第三方权威机构CA（数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

HTTPS是如何建立连接的？其间交互了什么？

SSL/TSL协议基本流程

• 客户端向服务器所要并验证服务器的公钥
• 双方协商产生会话秘钥
• 双方采用会话秘钥进行加密通信

前两步是SSL/TSL的建立过程，也就是握手阶段。

SSL/TLS的握手阶段涉及四次通信

1. ClientHello

   首先由客户端向服务器发起加密通信请求，也就是ClientHello请求。

   主要发送的信息

   • 客户端支持的SSL/TLS协议版本，如TLS1.2版本
   • 客户端生产的随机数（Client Random），后面用于生产会话秘钥
   • 客户端支持的密码套件列表，如RSA算法

2. ServerHello

   服务器收到客户端请求后，向客户端发出响应，也就是Server Hello。回应内容如下

   • 确认SSL/TLS协议版本，如果浏览器不支持，则关闭加密通信。
   • 服务器生产的随机数（Server Random），用于后面生产会话秘钥
   • 确认密码套件列表，如RSA算法。
   • 服务器的数字证书

3. 客户端回应

   客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的CA公钥，确认服务器的数字证书的真实性。

   如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息

   • 一个随机数，该随机数会被服务器公钥加密。
   • 加密通信算法改变通知，表示随后的信息都将用会话秘钥加密通信
   • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来提供服务端校验

   上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时拥有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的会话秘钥，

4. 服务器的最后回应

   服务器收到客户端的第三个随机数之后，通过写上的加密算法，计算出本次通信的会话秘钥，然后先给客户端发送最后的信息

   • 加密通信算法改变通知，表示随后的信息都将用会话秘钥加密通信
   • 服务器握手结束通知，保湿服务器的握手阶段已经结束。这一项同时吧之前所有的内容的发生的数据做个摘要，用来供客户端校验

HTTP/1.1、HTTP/2、HTTP/3演变

http/1.1与http/1.0 性能上的提升

1.1的TCP长链接改善了1.0短连接的性能开销

支持管道传输，减少整体等待时间

但是http1.1还是有性能瓶颈

• 头部信息未压缩
• 首部冗长，每次发送相同的首部造成资源浪费
• 服务器按顺序响应，如果响应较慢，就会一直请求不到数据，造成头部阻塞
• 没有请求优先级
• 请求只能从客户端开始，服务器只能被动响应

针对HTTP/1.1的性能瓶颈，HTTP/2做了哪些优化

首先HTTP2是基于HTTPS 的，所以他的安全性有保障

1. 头部压缩，协议会帮你消除多个请求中相同的头你信息

   这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表， 生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

2. 二进制格式

   不是纯文本形式的报文，采用了二进制格式，头信息和数据体都是二进制，统称为帧（头信息帧和数据帧），增加了数据传输的效率

3. 数据流

   数据包不是按顺序发送的，每个请求或回应的所有数据包，称为一个数据流。每个数据流都有其独一无二的编号。

   还可以指定数据流的优先级。服务器先响应优先级高的请求。

4. 多路复用

   HTTP/2可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。

   不需要排队等待，也就不会出现对头阻塞问题，降低了延迟，大幅度提高了连接的利用率。

5. 服务器推送

   服务器不再是被动响应，也可以主动向客户端发送消息。

针对HTTP/2，HTTP/3 做了哪些优化

? HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了

? HTTP/2 多个请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求

? 这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了UDP！

-基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。