- 超文本传输协议HTTP 0.9
- HTTP 1,支持多文件的下载
-
- 请求行,请求头 , 响应头,响应体
-
- 提供了cache机制,用户代理,状态码等一些基础信息
HTTP 1.1
- 缝缝补补的HTTP/ 1.1
-
- 改进持久连接,在HTTP1 中每次请求都需要经过握手和回收阶段
-
- 提供虚拟主机的支持,一个物理主机可以提供多个虚拟地址
-
- 对动态生成的内容提供了完美支持
-
- 客户端cookie,
-
- 增加了持久连接
-
- 每个域名最多维护6个TCP持久连接
-
- 使用CDN实现域名分片机制 CDN加速
- 使用CDN实现域名分片机制 CDN加速
HTTP 1.1 的主要问题
带宽指的是每秒最大能发送或者接收的字节数,发送的为上行带宽,接收的为下行带宽 着部分的带宽利用率并不理想
- TCP的慢启动
- 开启多条TCP连接后,连接会竞争固定的带宽
-
- 比如一个页面有 200 个文件,使用了 3 个 CDN,那么加载该网页的时候就需要建立 6 * 3,也就是 18 个 TCP 连接来下载资源;
- HTTP 1.1 的队头阻塞问题
HTTP 2 的多路复用
HTTP/2 的解决方案可以总结为:一个域名只使用一个 TCP 长连接和消除队头阻塞问题
- 长连接处理TCP的慢启动
- HTTP/2 最核心、最重要且最具颠覆性的多路复用机制。 每份数据都有对应的 ID,浏览器接收到之后,会筛选出相同 ID 的内容,将其拼接为完整的 HTTP 响应数据。
HTTP/2 使用了多路复用技术,可以将请求分成一帧一帧的数据去传输,这样带来了一个额外的好处,就是当收到一个优先级高的请求时,比如接收到 JavaScript 或者 CSS 关键资源的请求,服务器可以暂停之前的请求来优先处理关键资源的请求
多路复用的实现
从图中可以看出,HTTP/2 添加了一个二进制分帧层
我们结合图例分析一下HTTP 2的请求过程和接受过程
- 首先,浏览器准备好请求数据,包括了请求行、请求头等信息,如果是 POST 方法,那么还要有请求体。
- 这些数据经过二进制分帧层处理之后,会被转换为一个个带有请求 ID 编号的帧,通过协议栈将这些帧发送给服务器。
- 服务器接收到所有帧之后,会将所有相同 ID 的帧合并为一条完整的请求信息。
- 然后服务器处理该条请求,并将处理的响应行、响应头和响应体分别发送至二进制分帧层。
- 同样,二进制分帧层会将这些响应数据转换为一个个带有请求 ID 编号的帧,经过协议栈发送给浏览器。
- 浏览器接收到响应帧之后,会根据 ID 编号将帧的数据提交给对应的请求
其语言特性并没有大的改变 cache,cookie
HTTP/2 的其他特性
基于二进制分帧层
- 可以设置请求的优先级
- 服务器推送
-
- 推送额外的相关内容
- 头部压缩
-
- 请求头请求体
HTTP3 用掉TCP,TCL 包袱构建高效网络
HTTP/2 的一个核心特性是使用了多路复用技术,因此它可以通过一个 TCP 连接来发送多个 URL 请求。多路复用技术能充分利用带宽,最大限度规避了 TCP 的慢启动所带来的问题,同时还实现了头部压缩、服务器推送等功能,使得页面资源的传输速度得到了大幅提升。在 HTTP/1.1 时代,为了提升并行下载效率,浏览器为每个域名维护了 6 个 TCP 连接;而采用 HTTP/2 之后,浏览器只需要为每个域名维护 1 个 TCP 持久连接,同时还解决了 HTTP/1.1 队头阻塞的问题。
-
TCP 连接看成按照顺序传输数据的管道,之后的数据需要需要该数据重新传输
-
TCP 的对头阻塞
-
TCP 建立连接的延时
网络延迟又称为 RTT(Round Trip Time)。我们把从浏览器发送一个数据包到服务器,再从服务器返回数据包到浏览器的整个往返时间称为 RTT
HTTPS: 让数据传输更安全
页面安全,系统安全,和网络安全
存在中间人攻击的行为简单来说在将 HTTP 数据提交给 TCP层之后,数据会经过用户电脑、WiFi路由器、运营商和目标服务器
所以引入了加密方案
从图中我们可以看出 HTTPS 并非是一个新的协议,通常 HTTP 直接和 TCP 通信,HTTPS 则先和安全层通信,然后安全层再和 TCP 层通信。也就是说 HTTPS 所有的安全核心都在安全层,它不会影响到上面的 HTTP 协议,也不会影响到下面的 TCP/IP,因此要搞清楚 HTTPS 是如何工作的,就要弄清楚安全层是怎么工作的。
总的来说,安全层有两个主要的职责:对发起 HTTP 请求的数据进行加密操作和对接收到 HTTP 的内容进行解密操作
安全层的核心就是加解密
- 第一版:使用对称加密
-
- 对称加密。所谓对称加密是指加密和解密都使用的是相同的密钥
-
- 浏览器发送它所支持的加密套件列表和一个随机数 client-random,这里的加密套件是指加密的方法,加密套件列表就是指浏览器能支持多少种加密方法列表
-
- 服务器会从加密套件列表中选取一个加密套件,然后还会生成一个随机数 service-random,并将 service-random 和加密套件列表返回给浏览器。
-
- 最后浏览器和服务器分别返回确认消息。
-
- 这样浏览器端和服务器端都有相同的 client-random 和 service-random 了,然后它们再使用相同的方法将 client-random 和 service-random 混合起来生成一个密钥 master secret,有了密钥 master secret 和加密套件之后,双方就可以进行数据的加密传输了。
缺点 但是需要注意的是其中传输 client-random 和 service-random的过程却是明文的,所以hacker拿到协商的加密套件和双方的随机数依然可以进行破解。
非对称加密的请求流程
- 使用非对称加密
-
- 首先浏览器还是发送加密套件列表给服务器。
-
- 然后服务器会选择一个加密套件,不过和对称加密不同的是,使用非对称加密时服务器上需要有用于浏览器加密的公钥和服务器解密 HTTP 数据的私钥,由于公钥是给浏览器加密使用的,因此服务器会将加密套件和公钥一道发送给浏览器。
-
- 最后就是浏览器和服务器返回确认消息。
缺点
- 非对称加密的效率太差
- 无法保证服务器发送给浏览器的数据安全。虽然浏览器端可以使用公钥来加密,但是服务器端只能采用私钥来加密,私钥加密只有公钥能解密,但黑客也是可以获取得到公钥的,这样就不能保证服务器端数据的安全了
对称加密和非对称加密搭配使用
- 首先浏览器向服务器发送对称加密套件列表、非对称加密套件列表和随机数 client-random
- 服务器保存随机数 client-random,选择对称加密和非对称加密的套件,然后生成随机数 service-random,向浏览器发送选择的加密套件、service-random 和公钥;
- 浏览器保存公钥,并利用 client-random 和 service-random 计算出来 pre-master,然后利用公钥对 pre-master 加密,并向服务器发送加密后的数据;
- 最后服务器拿出自己的私钥,解密出 pre-master 数据,并返回确认消息。
服务器和浏览器就有了共同的 client-random、service-random 和 pre-master,然后服务器和浏览器会使用这三组随机数生成对称密钥
添加数字证书