目录
0 引言
针对HTTP协议的知识点总结
1 什么是HTTP协议
HTTP协议中文名是超文本传输协议,分为三个层面来理解:
- 协议:规定了应用进程之间通信的规范
- 传输:两点之间传输数据
- 超文本:能传输的数据不仅只有文本内容,还有图片,视频等超文本内容
2 HTTP报文有什么
请求报文
-
请求行
-
请求方法:GET/POST
-
请求url地址
-
协议及其版本号
-
-
请求头
包含了客户端的一些属性,格式为 属性名:属性值,服务端可以通过这一部分来获取我们的客户端信息
-
请求体
对于我们的POST请求,需要项服务器提交一些数据,这些数据就存储在请求体重
响应报文
-
响应头
-
协议及其版本号
-
状态码
-
-
响应头
包含了我们服务端的一些属性,格式为 属性名:属性值,客户端通过这部分报文可以获取服务端的信息
-
响应体
服务端期望传送给客户端的数据
常用的字段
-
host 请求字段,告诉服务器这个请求由哪个主机来处理
-
user-agent 请求字段,它使用一个字符串来描述发起请求的客户端,服务器可以一句它来返回最合适此浏览器显示的页面
-
Date 通用字段,通常出现在响应头中,表示http报文创建的时间
-
server 响应字段,告诉客户端正在提供web服务的软件名称和版本号
状态码
-
1xx 提示信息,表示目前是协议处理的中间状态
-
2xx 表示请求处理成功
-
3xx 表示重定向
-
4xx 客户端错误,通常是请求报文错误,服务器无法处理
-
5xx 服务端错误,通常是服务器内部处理请求时出现异常
3 HTTP缓存技术
强制缓存
-
当我们在第一次请求资源的时候,服务端会返回这个资源与资源的过期时间,客户端接受到后就将该资源和过期时间缓存起来
-
后面再继续请求相同的资源的时候,客户端会先到缓存中去查看资源是否已经过期,未过期则直接返回,过期则向服务器再次发送请求
-
服务器再次受到请求后会更新资源的过期时间
协商缓存
协商缓存是基于强制缓存+资源标识实现的
-
第一次请求资源的时候服务端会给资源加上一个标识etag与过期时间,然后客户端将其保存在自己的缓存中
-
客户端后面请求资源的时候会先去查询缓存,资源未过期则直接返回,否则带上etag再次请求服务器资源
-
服务端接受到请求后会做以下处理:
-
返回304,即etag相同,不会返回资源
-
返回200,返回请求的资源
-
-
客户端若接受到304则直接去缓存中查询并返回,200则更新缓存
4 HTTP1.1的特点
优点
-
简单
-
灵活易扩展
-
应用广泛和跨平台
缺点
-
无状态双刃剑
-
无状态可以让无服务不用记住客户端的状态减轻了服务端的压力
-
无状态使得客户端一些关联请求比较麻烦,为了解决这个问题从而引入了cookie
-
-
明文传输双刃剑
-
明文传输信息易阅读,错误易排除
-
不安全
-
http1.1性能
-
长连接
http1.0有个最大的问题就是每次请求都要进行tcp三次握手与四次挥手,http1.1对其进行了优化,允许在一个tcp连接中进行多次请求
-
管道传输
长连接使得一次性发送多次请求成为了可能
-
队头阻塞
基于请求响应的模式,先发送的HTTP请求若长时间没有回应会阻塞后面的http请求
-
请求头和响应头未经过压缩就进行传输
-
没有请求优先级控制
5 HTTPS加密方式
https中TLS采用的方式混合加密,所谓的的混合加密方式就是在通信刚开始的时候采用非对称加密,解决秘钥交换的过程:
-
客户端用CA的公钥加密pre-master
-
服务端用自己的私钥解密处pre-master
然后用client-random, server-random, pre-master三者计算出自己的会话密码,之后就是采用对称加密的方式进行通信了。
之所以采用两种方式混合是因为对称加密虽然快但是无法做到安全的秘钥交换,非对称加密虽然能够做到安全的秘钥交换但是由于算法的原因比较慢,所以综合二者的优点形成的混合加密方式更加安全高效
6 HTTPS连接建立的过程
HTTPS加密过程(RSA秘钥交换算法)
-
ClientHello
首先客户端向服务端发送加密通信请求,也就是CilentHello请求,这一步客户端会给服务端发送以下消息:
-
客户端支持的SSL/TLS版本
-
客户端产生的随机数Client Random,用于后面生成会话秘钥
-
客户端支持的密码套件列表
-
-
ServerHello
服务端接受到请求后,向客户端发出相应,也就是ServerHello请求,服务端回复的内容如下:
-
确认SSL/TLS的版本,若服务端不支持则直接关闭连接通信
-
服务端产生随机数Server Random,用于后面产生会话秘钥
-
确认的密码套件列表
-
服务器的数字证书
-
-
客户端回应
客户端接受到服务端的回应之后,首先通过浏览器和操作系统中CA公钥,确认服务器的数字证书的真实性。若果证书没有问题,客户端就会从数字证书中取出服务器的公钥,然后使用它加密报文,向服务器发送以下信息:
-
一个随机数,该随机数会被服务器公钥加密
-
加密通信算法改变通知,表示随后的信息都会用会话秘钥加密
-
客户端握手结束通知,表示客户端的握手阶段已经结束。
-
-
服务器的最后回应
服务器接受到第三个随机数后,会通过协商的加密算法,计算出本次通信的会话秘钥,然后,向客户端发送最后的信息:
-
加密通信算法改变通知,表示随后的信息都用会话秘钥进行加密
-
服务器握手结束通知,表示服务器的握手阶段已经结束
-
数字证书包含什么
-
公钥
-
持有者信息
-
证书认证机构信息CA
-
CA对这份文件的数字签名及使用的算法
-
证书有效期
-
其他信息
证书的作用就是客户端用来验证服务端是否合法
数字证书的具体工作流程
-
CA证书的签发流程
首先CA把服务器公钥,持有者信息,证书有效期等信息打成一个包,然后通过一定的hash算法计算出该包的hash值,并用CA的私钥对其加密,然后将其印到数字证书上,也就是CA对于数字证书的一个签名
-
客户端对CA证书的校验流程
客户端首先用相同的hash算法计算出数字证书的一个hash值,然后用CA的公钥(这个公钥一般在客户端浏览器或者操作系统中)对证书签名解密后得到CA证书机构的签名,然后将该签名与客户端自己计算出来的hash值进行比较,相同则表示证书有效,不同则表示无效
7 HTTP与HTTPS的区别
-
ttp是超文本传输协议,信息是明文传输,存在安全风险的问题,HTTPS则解决了http不安全的风险。在tcp和http网络层之间加入了SSL/TLS安全协议,使得报文能够加密传输
-
http连接的建立相对简单,tcp三次握手之后便可进行http报文传输,而HTTPS在tcp三次握手之后,还需进行SSL/TLS握手过程,才能够进入加密报文传输
-
http的端口号是80,HTTPS的端口号是443
-
HTTPS协议需要向CA(证书权威机构)申请数字整数,来保证服务器的身份是可信的
8 HTTP2.0做了哪些优化
为了解决http1.1请求响应模型,头部巨大重复,并发连接耗时和服务器不能主动推送消息等问题,从而引入了http2.0,http2.0通过以下方面对http1.1进行了优化
-
头部压缩
采用[静态表+动态表+哈夫曼编码]的方式进行了头部压缩,所谓的静态表就是将我们头部常用的字段做了一个映射表,表中有三个字段分别是index, header-name,header-value。这样我们就可以用一个字节的index来表示头部中的某一个属性了,对于属性值不确定的字段我们通过对其采用哈夫曼编码后也能大大降低传输的字节数。
所谓的动态表就是存储了哪些在一个连接中经常用到的属性的表,是对静态表的一种扩展。
-
二进制传输
http2.0不再采用文本传输,而是通过二进制数据帧进行传输,大大提高了传输与数据处理效率。
-
并发传输
http2.0采用了stream来解决并发传输的问题,客户端和服务端通过stream传输信息,多个stream可以复用用一个tcp连接来进行传输。通过stream进行传输时,需要注意同一个streamid中的frame必须是严格有序的,不同streamid的frame是可以并发传输的,最后在接受端通过streamid进行组织从而得到完整有序的消息。
这种实现并发的方式比HTTP1.1要厉害许多,http1.1要处理100个并发请求的话需要建立100个TCP连接,这就涉及到tcp连接的建立与释放,耗时也耗资源,而http2.0要实现100个并发请求的话只需要创建100个流就行了,省去了非常多TCP连接的开销。同时我们的流是可以设置优先级的,这样我们就能设置哪些请求优先相应从而提高用于体验
-
服务端推送消息
传统的http1.1协议我们在请求一个页面时可能有html资源和css资源,对于这些资源客户端都需要发送相应的请求,而http2.0在客户端请求html资源时,客户端可以通过相应的stream推送css资源
9 HTTP3.0做了哪些优化
http2.0存在的问题
http2.0存在的问题主要是由于传输层使用TCP协议导致的。
-
队头阻塞
我们使用了多个流复用TCP连接,从而能够发送多个http请求,但是由于TCP连接的特点,当我们低序列号的数据包丢失,高序列号的数据包即使已经到达接收端也必须等待低序列号的数据包被重传了才能被接受
-
TCP三次握手与TLS四次握手RTT延迟
TCP与TLS四次握手共需要3个RTT延时,再加上TCP慢启动的特性会导致最开始建立连接的时候比较慢
-
网络迁移需要重新进行连接
因为我们的TCP连接是通过四元组(源IP,源端口,目标IP,目标端口)来对一条连接进行标识的,所以当我们从移动网络换成WiFi时就需要再次进行TCP连接
QUIC协议
quic协议是基于UDP协议的,它具有TCP连接拥塞避免,流量控制等特性,相当于让不可靠的UDP变得可靠的。该协议相比TCP具有以下特点
-
无队头阻塞
quic协议也是多个流复用一个quic连接,但是各个流之间互相不影响,也就是说某个流中数据包丢失发送阻塞时并不会导致其他流中的数据包发生阻塞
-
连接RTT延时小
quic基于TLS1.3协议,只需在一个RTT延时内就能建立起安全的连接
-
连接切换
quic并没有使用四元组来标识一个连接,而是使用连接ID来表示通信的两个端点,所以即使连接断了,再次恢复的时候只要有足够的上下文信息(连接ID,TLS秘钥等),那么仍然可以继续使用原来的连接