HTTP的一些概念
文章目录
-
- HTTP定义
-
- URI&URL
- HTTP 常见的状态码
- http 首部
-
- 请求首部字段
- 响应首部字段
- 为cookie服务的首部字段
- get请求和post请求及区别
- GET 和 POST 方法是否安全和幂等
- HTTP特性
-
- HTTP（1.1） 的优点有哪些
- HTTP/1.1 的缺点
- HTTP/1.1 的性能
-
- HTTP/1.1 相比 HTTP/1.0 提高了什么性能
- HTTP 与 HTTPS
-
- HTTP 与 HTTPS 有哪些区别
- HTTPS 解决了 HTTP 的哪些问题
- HTTPS 是如何建立连接的
- SSL/TLS 协议建立的详细流程：
- HTTPS的缺点
- HTTP/1.1、HTTP/2、HTTP/3 演变
-
- 1.相比 HTTP/1.0，HTTP/1.1提高了什么性能？
- 2.对于HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？
- HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？
HTTP定义
超文本传输协议，是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。超文本包含文字、图片、视频等。
URI&URL
URI:统一资源标识符，不仅可以标识http，ftp等其他的网络资源
URL:统一资源定位符，使用web浏览器访问web页面时需要输入的网页地址
- URI用字符串标识某一互联网资源，而URL表示资源的地点（在互联网上所处的位置）。可见URL是URI的子集
HTTP 常见的状态码
http 首部
请求首部字段
客户端发送到服务端的 HTTP 请求，这个数据包称为请求报文。其中的头字段，就是请求头字段。
Accept：客户端希望获得资源的类型
Accept-Encoding：客户端支持的压缩算法
Accept-Language：客户端支持的语言
Host：当前请求的域名
Connection：客户端是否希望使用 TCP 长连接，如keep-alive 表示长连接；close 表示短连接
User-Agent：用户代理。该字段标注了发送方的一些信息，你可以通过它来知道请求方是浏览器、爬虫、postman 还是 cURL。
响应首部字段
服务端响应客户端的请求报文，会返回响应报文，响应报文的头字段，就是所谓的响应头字段。
Content-Type：服务端返回的资源类型，可以带上使用的编码格式
Content-Encoding：返回资源使用的压缩格式
Content-Length：HTTP 消息体的长度
Date：HTTP 响应报文生成的时间
Connection：服务端决定使用长连接还是短连接
Server：使用了哪种服务器
为cookie服务的首部字段
- Set-Cookie
- Cookie
get请求和post请求及区别
get请求:从指定的资源请求数据，用于获取数据，一般用于搜索排序和筛选之类的操作。
post请求:向指定的资源提交要被处理的数据，用于将数据发送给服务器，一般用于修改和写入数据。
get请求和post请求本质上就是TCP连接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。（1）post请求更安全（不会作为url的一部分，不会被缓存、保存在服务器日志、以及浏览器浏览记录中，get请求的是静态资源，则会缓存，如果是数据，则不会缓存）
（2）post请求发送的数据更大（get请求有url长度限制，http协议本身不限制，请求长度限制是由浏览器和web服务器决定和设置）
（3）post请求能发送更多的数据类型（get请求只能发送ASCII字符）
（4）传参方式不同（get请求参数通过url传递，post请求放在request body中传递）
（5）get请求产生一个TCP数据包；post请求产生两个TCP数据包（get请求，浏览器会把http header和data一并发送出去，服务器响应200返回数据；post请求，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 返回数据）
注意：在发送 POST 的时候都没有带 Expect 头，server 也自然不会发 100 continue。
GET 和 POST 方法是否安全和幂等
- 在 HTTP 协议里，「安全」是指请求方法不会「破坏」服务器上的资源。
- 「幂等」是多次执行相同的操作，结果都是「相同」的
- 结论：
GET 方法是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。
POST既不安全也不幂等，因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的
HTTP特性
HTTP（1.1） 的优点有哪些
HTTP 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」
简单：HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛
灵活和易于扩展：HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充
应用广泛和跨平台：HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，天然具有跨平台的优越性
HTTP/1.1 的缺点
HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」
无状态双刃剑
- 无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务
- 无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。
这样每操作一次，都要验证信息。
对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。
Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态
明文传输双刃剑
- 明文意味着在传输过程中的信息，是可方便阅读的，比如 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。
- 但是这正是这样，HTTP 的所有信息都暴露出来。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取
不安全
HTTP 比较严重的缺点就是不安全：
- 通信使用明文（不加密），内容可能会被窃听。
- 不验证通信方的身份，因此有可能遭遇伪装。
- 无法证明报文的完整性，所以有可能已遭篡改。
- HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。
HTTP/1.1 的性能
HTTP 协议是基于 TCP/IP，并且使用了「请求 - 应答」的通信模式，所以性能的关键就在这两点里。
1.长连接
早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。
为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
当然，如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。
2.管道网络传输
HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。
如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。
所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。
3. 队头阻塞
「请求 - 应答」的模式加剧了 HTTP 的性能问题。
因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」。
HTTP/1.1 相比 HTTP/1.0 提高了什么性能
- 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
- 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
但 HTTP/1.1 还是有性能瓶颈：
- 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应
HTTP 与 HTTPS
HTTP 与 HTTPS 有哪些区别
1.HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
2.HTTP 连接建立相对简单，是无状态的， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
3.使用的是完全不同的连接方式，用的端口也不一样，HTTP 的端口号是 80，HTTPS 的端口号是 443。
4.HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
HTTP与HTTPS：
HTTPS 解决了 HTTP 的哪些问题
HTTP 由于是明文传输，所以安全上存在以下三个风险：
- 窃听风险，比如通信链路上可以获取通信内容，用户号容易没
篡改风险，比如强制入垃圾广告，视觉污染，用户眼容易瞎
冒充风险，比如冒充淘宝网站，用户钱容易没
HTTPS解决了上述的风险：
- 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没
HTTPS 是如何建立连接的
SSL/TLS 协议基本流程：
客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。
前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。
SSL/TLS 的「握手阶段」涉及四次通信，可见下图：
SSL/TLS 协议建立的详细流程：
1. ClientHello
首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
在这一步，客户端主要向服务器发送以下信息：
（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。
（2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。
（3）客户端支持的密码套件列表，如 RSA 加密算法。
2. SeverHello
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：
（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
（2）服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。
（3）确认的密码套件列表，如 RSA 加密算法。
（4）服务器的数字证书。
3.客户端回应
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。
（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。
4. 服务器的最后回应
服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：
（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。
HTTPS的缺点
虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
HTTP/1.1、HTTP/2、HTTP/3 演变
1.相比 HTTP/1.0，HTTP/1.1提高了什么性能？
- 使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
- 支持 管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
但 HTTP/1.1 还是有性能瓶颈：
- 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应。
2.对于HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？
HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
- 头部压缩
HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的分。
这就是 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。- 二进制格式
HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。
头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。
报文差异：
这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。- 数据流
HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。
每个请求或回应的所有数据包，称为一个数据流（Stream）。
每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数
客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。
- 多路复用
HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。
移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。
举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。多路复用：
- 服务器推送
HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。
HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？
- HTTP/2 主要的问题在于：
多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。
所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
- HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
- HTTP/2 多请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。
这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的一个丢包全部重传问题。
大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
- QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。
- TL3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack。
- HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。
TCP HTTPS（TLS/1.3） 和 QUIC HTTPS:
所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。
QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题。所以 HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。
参考：
- 小林coding
- https://zhuanlan.zhihu.com/p/389041095