HTTP——HTTP特性,缓存技术以及HTTP版本的演变

HTTP

HTTP基本概念

HTTP是什么?

HTTP是一个超文本传输协议

1. 协议:可以分成协和议两部分来解释

协:表示有两个及以上的参与者.

议:表示对参与者行为的一种约定和规范.

HTTP是一个协议,它规定了计算机之间通信的规范以及相关的各种控制和错误处理方式.

2. 传输:HTTP是一个双向的协议,既可以从A地传到B地,也可以从B地传到A地.在传输过程中,也可以有中间者进行中转或者接力.
3. 超文本:传输的信息不仅仅是一些纯文本,还包括图片,音频,超链接等多种格式的数据.

总结而言,HTTP就是一个在两点之间进行双向传输图片,音频等超文本数据的一种约定和规范

HTTP常见的状态码有哪些?

1. 1xx:提示信息,表示目前处于中间过程,后续还有其他操作
   ​ 1xx的状态码表示当前处于中间过程,在实际应用中很少遇到.
2. 2xx:成功,表示报文成功传输且被处理
   200:表示一切成功,且响应报文中有body数据
   204:表示一切成功,但响应报文中无body数据
   206:表示响应报文中的资源只是其中的一部分,并不是全部.
3. 3xx:重定向,表示访问的资源位置发生了改变
   301:永久重定向,客户端需要用其他的url访问该资源
   302:短暂重定向,资源的位置没变,但是暂时需要用其他url访问该资源
   304:不是重定向,表示客户端可以继续使用缓存资源
4. 4xx:客户端错误
   400:笼统的一个错误,只是表示客户端发生了错误.
   403:表示服务器禁止访问资源,并不是客户端的错误
   404:表示请求的资源在服务器上不能存在或未找到.
5. 5xx:服务器错误
   500:笼统的一个错误,只是表示服务器发生了错误
   501:表示客户端请求的功能还不支持
   502:服务器作为网关或代理时表示后端的服务器发生了错误
   503:表示服务器当前很忙,无法响应客户端

HTTP常见字段有哪些?

Host字段:用来指定访问的服务器的域名
Content-Length字段:表示服务器的响应报文中数据的长度
Connection字段:客户端要求服务器要持久连接
Content-Type字段:服务器回应时,响应报文中数据的格式
Accept字段:客户端可以接受的数据格式
Content-Encoding字段:服务器回应时,响应博文中数据的压缩方法
Accept-Encoding:客户度可以接受的数据的压缩方法

Get和Post

1. GET和POST有什么区别?
   按照RFC规范
   1. GET是从服务器上获取指定资源;POST是根据请求负荷对指定的资源做处理.
   2. GET是安全,幂等的,可缓存的,POST是不安全,不幂等也不可缓存的
2. GET和POST方法都是安全和幂等的吗?
   在HTTP协议中,安全指的是请求方法不会破坏服务器上的资源;幂等是多次相同的请求得到的结果是相同.
   从RFC规范的定义来看
   **GET方法是安全和幂等的,**因为GET方法是只读操作,只是从服务器上获取到对应的资源,多次执行相同的GET方法获取到的资源是相同的
   POST方法是不安全和幂等的,因为它会修改服务器上一些资源,且多次执行相同的请求会创建多个资源.
   上述阐述是基于RFC规范的,但在实际应用中,不一定会完全遵照RFC规范,因此GET请求也可以用于修改服务器上数据,也可能是不安全和不幂等的,POST请求也可以是只读操作,也可以是安全和幂等的.

HTTP特性

HTTP/1.1的优点

1. 简单

   HTTP报文由header+body两部分组成,header是简单的key-value内容,易于理解和学习.

2. 灵活 易拓展
   字段的不限制使用使得开发者可以根据需求随意使用和补充,同时HTTP属于应用层,其下层可以随意变化.

3. 应用广泛和跨平台
   应用HTTP的应用和软件非常广泛,同时天然具有跨平台的特性

HTTP/1.1的缺点

1. 无状态
   好处是服务器不需要花费额外的资源去记录状态信息;缺点是服务器没有记忆能力,在完成关联性操作时非常繁琐
   常见的解决方法是引入cookie和session
2. 明文传输
   好处是方便阅读,方便调试;缺点是重要信息是在传输过程中是暴露在外的,极容易被窃取和篡改
3. 不安全
   是用明文通信,内容容易被窃听;不验证通信双方的身份,有可能遭遇伪装;无法证明报文的完整性,所以有可能已遭篡改

HTTP/1.1的性能如何

1. 长连接
   在HTTP/1,0中,一次通信需要建立连接,断开连接.为了避免频繁通信导致服务器频繁建立,断开连接的开销,HTTP/1.1引入了长连接;即在建立了连接后,不会马上断开,之后的通信可以直接展开,知道通信双方有一方主动断开连接.当然如果通信双方长时间没有数据交互,服务器会主动断开连接.[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LFP2uqwK-1661780932252)(C:\Users\qiu\AppData\Roaming\Typora\typora-user-images\1659049292155.png)]
2. 管道网络传输
   在同一个TCP连接里,客户端可以发起多个请求,且之后的请求不需要等待前面请求响应后才能发送的限制,进而避免了前面连接在服务器异常时,后续请求无法继续发送的问题,也就是解决了请求的队头阻塞;但并没有解决响应的队头阻塞:服务器必须根据请求接收的顺序来发送响应
   注意:实际应用中HTTP/1.1基本上没有支持管道网络传输
3. 队头阻塞
   总结:HTTP/1.1相比HTTP/1.0性能有所提升,但整体性能一般般,后续的HTTP/2和HTTP/3就是在优化HTTP的性能

HTTP缓存技术

1. HTTP缓存有哪些实现方式

   强制缓存和协商缓存

2. 什么是强制缓存?
   强制缓存是指只要浏览器判断缓存没有过期,则直接使用浏览器本地的缓存
   强制缓存的具体流程:

   1. 浏览器第一次请求服务器的资源,服务器在响应报文中加上Cache-Control字段,设置缓存的过期时间
   2. 浏览器在之后访问同样的资源时会和Cache-Control中缓存的过期时间对比,如果没有过期则直接使用缓存,否则访问服务器.
   3. 在访问服务器后,服务器会在响应报文中添加Cache-Control设置缓存的过期时间

3. 什么是协商缓存?
   与服务器协商后来判断是否使用本地缓存,协商缓存有两种实现方式

   1. If-Modified-Since和Last-Modified
      当资源过期以后,请求报文中的If-Modified-Since会带上Last-Modified的时间,服务器收到请求报文后会发现有If-Modified-Since字段后,会将请求报文中的Last-Modifed的时间与资源最近更新的时间作比较,如果前者比较大,则返回200(返回最新的资源),否则返回304,使用本地缓存
   2. If-None-Match和Etag
      当资源过期时,浏览器发现响应报文中有Etag字段后会再次发送请求报文,并将If-None-Match的值设置为Etag的值发送给服务器,服务器收到请求后会对比资源是否发生了修改,如果修改则返回200,否则返回304
      协商缓存是在强制缓存未命中的基础上实施的.ETag的优先级要高于Last-Modified[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xnsEvhrh-1661780932253)(C:\Users\qiu\AppData\Roaming\Typora\typora-user-images\1659020090570.png)]

HTTPS与HTTP

1. HTTP与HTTPS的区别?

   1. HTTP是明文传输;HTTPS中引入SSL/TLS安全协议,使得数据是加密传输
   2. HTTP建立连接的过程相对简单,是在TCP三次握手之后建立连接;HTTPS在TCP三次握手之后还需要SSL/TLS的握手过程
   3. HTTP的端口号是80,HTTPS的端口号是443
   4. HTTPS需要向CA申请数字证书来证明服务器的身份是可信的

2. HTTPS解决了HTTP哪些问题?

   1. 窃听风险
   2. 篡改风险
   3. 冒充风险

   HTTPS引入SSL/TLS协议来解决HTTP中上述的不安全问题.

   1. 信息加密:采用混合加密的方式

   2. 校验机制:摘要算法来实现数据的完整性,为每个数据生成一个独有的指纹,指纹用于校验数据的完整性

   3. 身份证书:将服务器公钥放到身份证书中.

   4. 混合加密
      采用非对称加密的方式进行密钥的安全交换;采用对称加密的方式进行加密数据传输
      对称加密只使用一个密钥,运算速度快,密钥必须保密,无法做到密钥的安全交换
      非对称加密有两个密钥:公钥和私钥,公钥可以任意而私钥需要保密,可以解决密钥交换但速度慢

   5. 摘要算法+数字签名
      为了保证数据的完整性,会用摘要算法(哈希)计算出数据的一个指纹(哈希),服务器会对接收到的数据再次计算出一个指纹并与报文中数据的指纹做对比,如果相同则说明数据是完整的.
      为了保证数据和哈希不被替换,需要用数字签名算法对哈希进行加密.数字签名主要采用的是非对称加密方式.非对称加密有两个密钥,一个公钥,一个私钥;二者是可以相互加密解密的.
      1. 公钥加密,私钥解密:保证数据传输的安全性.私钥是保密的,只有持有私钥的人才能解密数据.
      2. 私钥加密,公钥解密:防止发送数据的人不会被冒充.因为私钥是解密的,所以用公钥能够解密出正确数据说明发送方是持有私钥的.
      数字签名就是采用[私钥加密,公钥解密]的方式保证不被冒充.服务器将公钥发送给客户端,然后用私钥加密数据,客户端如果能够用公钥正常解密,就说明发送的数据来源于服务器
      3. 身份证书
      为了保证服务器发送的公钥不被伪造,引入身份证书.服务器会向CA申请数字证书,并将服务器公钥放到身份证书中,只要证书是可信的,公钥就可信

3. HTTPS是如何建立连接的?期间交互了什么?
   在经过TCP三次握手之后,进入SSL/TLS的四次握手过程:客户端向服务器索要并验证密钥,客户端和服务器协商产生会话密钥
   SSL/TLS建立连接的过程

   1. 客户端向服务器发起加密通信请求,信息:客户端支持的SSL/TLS版本+客户端生成的随机数A+客户端支持的密码套件列表
   2. 服务器收到客户端的请求后,向客户端发出响应,信息:选择的SSL/TLS版本+服务器生成的随机数B+选择的密码套件+服务器的数字证书
      3. 客户端收到服务器的响应后,首先通过浏览器或者操作系统得到CA的公钥,确认服务器证书的真实性,之后会取出证书里的服务器的公钥,然后使用它加密报文,信息:一个随机数(pre-master key)(被加密),加密通信算法改变通知,表示之后通信用会话密钥,客户端握手结束通知,并将之前的所有的数据作个摘要,供服务器校验
   3. 服务器收到报文后,用私钥解密第三个随机数后,根据协商加密算法计算出会话密钥.信息:加密通信算法改变通知,之后通信用会话密钥,服务器握手结束通知,并将之前的所有数据作个摘要供客户端校验

4. HTTPS的应用数据是如何保证完整性的?
   TLS在实现上分为握手协议和记录协议
   记录协议负责数据的完整性和来源的验证.
   具体过程:
   1. 首先,消息被分割成多个较小的片段,然后分别对每个片段进行压缩.
   2. 经过压缩的片段会加上消息认证码(MAC值,通过哈希算法生成),这是为了保证数据的完整性,并进行数据的认证.
   3. 经过压缩的片段和消息认证码会通过对称密码加密
   4. 经过加密的数据加上报头形成报文交给传输层TCP.

HTTP/1.1 HTTP/2 HTTP/3演变

1. HTTP/1.1相比HTTP/1.0提高了什么性能?
   1. 使用长连接的方式改善了HTTP1.0的短连接造成的性能开销
   2. 支持管道网络运输,支持一次发送多个请求报文,减少整体的响应时间
   HTTP1.1性能瓶颈
   1. 报文头部未经压缩就发送,首部信息越多延迟就越大.
   2. 发送冗长的首部,每次互相发送相同的首部造成的浪费较多
   3. 服务器是按照请求的顺序响应的,响应可能会造成队头阻塞
   4. 没有请求优先级控制
   5. 请求只能从客户端发出,服务器只能被动响应

2. HTTP/2做了什么优化?
   HTTP/2是基于HTTPS的,在安全性上有保障

   1. 头部压缩
      HTTP/2会压缩头,如果你同时发出多个请求,它们的头是一样或相似的,协议会帮你消除掉重复的部分.
      利用HPACK算法,在客户端和服务器各自维护一张头部信息表,所有字段都会存入这个表,生成一个索引号,以后发送同样的字段时只发送一个索引

   2. 二进制格式
      HTTP/2中的报文由HTTP/1.1的纯文本格式改成了二进制形式.统称为帧:头信息帧和数据帧.这样提高了计算机处理数据的效率.

   3. 数据流
      HTTP/2中的数据包不是顺序发送的,可以乱序发送.同一个连接里连续的数据包可能属于不同的回应.一个请求或响应中的所有数据包称为数据流,为了区分不同的数据包,每一个数据包都会标记一个Stream ID,一个数据流中的数据包的Stream ID是相通的.接收方可以根据Stream ID来组装数据包
      客户端和服务器都可以建立Stream,为了区分,客户端的Stream ID是奇数,服务器是偶数

      客户端可以数据流的优先级是服务器优先/靠后处理

   4. 多路复用
      一个连接中可以同时发送多个请求/响应(HTTP/1.1不能解决响应队头阻塞的问题).

   5. 服务器推送
      服务器可以主动向客户端发送信息,较少了消息传递的次数
      HTTP/2虽然采用多路复用解决了响应的队头阻塞问题,但仍无法完全解决队头阻塞问题.问题处在TCP层,TCP是面向字节流的,所以TCP层接收到的数据要求是完整且连续的,这样才能从内核中将数据提供给HTTP.但当发生丢包现象后,由于要保证连续,所有包都需要等待丢包重传后才能传给HTTP,因此造成了阻塞.

3. HTTP/3做了什么优化?
   HTTP/3完全解决了队头阻塞问题:将HTTP下层的TCP改成了UDP.
   UDP对发送顺序和连续性没有要求,所以可以解决队头阻塞的问题.但UDP是不可靠的,但基于UDP的QUIC协议可以实现类似TCP的可靠传输
   QUIC的3个特性
   1. 无队头阻塞
   QUIC同样采用HTTP/2中的多路复用与Stream的概念.与HTTP/2不同的是丢包后QUIC只会影响丢的包本身,而不会影响其他包
   2. 更快的连接建立
   在HTTP/3之前,TCP和TLS是分层的,分别属于传输层和表示层,所以需要分批实现,先TCP握手,然后TLS握手
   HTTP/3中少了TCP握手,而TLS握手转变成了QUIC握手,由四次握手改变为了三次握手(2个RTT---->1个RTT),甚至可以是两次握手(0个RTT).握手的目的是确认双方的连接ID.
   3. 连接迁移
   基于TCP的HTTP协议是通过四元组(源IP,源端口,目的IP,目的端口)来确认连接的,当移动设备的网络环境发生变化(从流量切换到WIFi)时,对应的IP地址发生了改变,因此连接会发生断开再重连,重连需要经过TCP三次握手和TLS四次握手的时延,连接迁移的成本很大.
   而QUIC是基于连接ID来确认连接.这样即使IP地址变化了,只要上下文信息仍保持,连接就无须重连,可以继续正常使用
   总的来说,QUIC是一个在UDP之上结合了TCP+TLS+HTTP/2的多路复用的协议,但由于QUIC是新协议,许多网络设备会将其当做是UDP,而有些网络设备会丢弃UDP包,这样就会导致丢弃QUIC包.因此HTTP/3的普及速度非常缓慢.