宠物网站页面设计创意国外,上海闵行发布,网络互动公司排名,杭州建设企业网站的一、HTTP/1.0
1996年5月#xff0c;HTTP/1.0版本发布#xff0c;为了提高系统的效率#xff0c;HTTP/1.0规定浏览器与服务器只保持短暂的连接#xff0c;浏览器的每次请求都需要与服务器建立一个TCP连接#xff0c;服务器完成请求处理后立即断开TCP连接#xff0c;服务器…一、HTTP/1.0
1996年5月HTTP/1.0版本发布为了提高系统的效率HTTP/1.0规定浏览器与服务器只保持短暂的连接浏览器的每次请求都需要与服务器建立一个TCP连接服务器完成请求处理后立即断开TCP连接服务器不跟踪海个客户也不记录过去的请求。 请注意上面提到的HTTP/1.0中浏览器与服务器只保持短暂的连接连接无法复用。也就是说每个TCP连接只能发送一个请求。发送数据完毕连接就关闭如果还要请求其他资源就必须再新建一个连接。我们知道TCP连接的建立需要三次握手是很耗费时间的一个过程。所以HTTP/1.O版本的性能比较差。现在随便打开一个网页上面都会有很多图片、视频等资源HTTP/1.0显然无法满足性能要求。
二、HTTP/1.1 1、持久连接 HTTP/1.0 中一个 TCP 连接只能发送一个请求和响应而 HTTP/1.1 进行了优化同一个 TCP 连接可以发送多次 HTTP 请求减少了建立和关闭连接的性能开销。 2、管道机制 持久连接虽然可以多个请求复用同一个连接但是每次都需要等到上一个请求响应完成后才能发送下一个请求。管道机制中只要第一个请求发出去了不必等其回来就可以发第二个请求出去即相当于同时发出多个请求因而可以减少整体的响应时间。 问题采用管道机制虽然可以发送多个请求但是服务器必须按照接收请求的顺序依次发送对这些管道化请求的响应以保证客户端能够区分出每次请求的响应内容。这就导致了假如服务端在处理一个请求时耗时比较长那么后续请求的处理都会被阻塞住会导致客户端迟迟收不到数据这称为「队头堵塞」--在HTTP2中解决。 3、缓存控制 HTTP/1.1 在 HTTP/1.0 基础之上增加了一些请求响应头以更好的实现对缓存的控制。
新增 Cache-Control 代替原先的 Expires新增 If-None-Match 和 Etag 代替原先的 If-Modified-Since和 Last-Modified 。 4、断点续传 利⽤ HTTP 消息头使⽤分块传输编码将实体主体分块传输。
三、HTTP/2.0
1、头部压缩
HTTP/1.1 中的请求头携带大量信息而且每次都要重复发送即使是同样的内容每次请求都需要附带这会造成性能的损耗。HTTP/2 进行了优化引入了头信息压缩机制。
客户端和服务器同时维护一张头信息表高频出现的字段会存入这个表生成一个索引号。发送报文时直接使用索引号替代字段。另外索引表中不存在的字段使用压缩。
同时多个请求中如果请求头相同则后续请求只需要发送差异的部分重复的部分无需再发送。
2、二进制帧 在HTTP/2中在应用层(HTTP2.0)和传输层(TCP或者UDP)之间加了一层二进制分帧层。这是HTTP2中最大的改变。HTTP2之所以性能会比HTTP1.1有那么大的提高很大程度上正是由于这一层的引入。 在二进制分帧层中HTTP/2会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用二进制格式的编码。这种单连接多资源的方式减少了服务端的压力使得内存占用更少连接吞吐量更大。而且TCP连接数的减少使得网络拥塞状况得以改善同时慢启动时间的减少使拥塞和丢包恢复速度更快。
3、多路复用 在 HTTP/2 中定义了流Stream的概念它是二进制帧的双向传输序列一个数据流对应着一个完整的请求-响应过程在同一个请求响应过程中往返的帧会分配一个唯一的流编号Stream ID。 在流的支持下HTTP/2 可以在一个 TCP 连接中传输多个请求或响应而不用按照顺序一一对应即实现多路复用因为它们属于不同的流所发送的帧头部都会携带 Stream ID可以通过此 Stream ID 有效区分不同的请求-响应。 因而 HTTP/2 解决了 HTTP/1.1 的『队头阻塞』问题多个请求 - 响应之间没有了顺序关系不需要排队等待降低了延迟大幅度提高了连接的利用率。
4、服务器主动推送 在 HTTP/1.1 中只能客户端发起请求服务器对请求进行响应。而在 HTTP/2 中服务端可以主动给客户端推送必要的资源以减少请求延迟时间。 比如当客户端向服务器请求一个 HTML 文件后服务器除了将此 HTML 文件响应给客户端外还可以提前主动将此 HTML 中所依赖的 JS 和 CSS 文件推送给客户端这样客户端在解析 HTML 时无需耗费额外的请求去得到相应的 JS 和 CSS 文件。
四、HTTP/3.0QUIC 协议
1、 无队头阻塞 HTTP/2 通过多路复用解决了 HTTP1.1 的『队头阻塞』问题但其只是解决了 HTTP 这一层面的『队头阻塞』问题底层仍然采用的 TCP 连接HTTP/2 并没有解决 TCP 的『队头阻塞』问题。 TCP 是可靠的、面向字节流的协议。HTTP/2 的多个请求虽然可以跑在同一个 TCP 连接中但如果出现丢包现象TCP 就需要进行重传这可能就会导致整个 TCP 连接上的所有流阻塞直到丢的包重传成功这就是 TCP 的『队头阻塞』问题。 为了解决此问题HTTP/3 底层不再使用 TCP而是采用 UDP而 UDP 是无连接的多个流互相独立之间不再有依赖因而即使某个流发生了丢包只会对该流产生影响并不会使得其他流阻塞 这时候有的小伙伴可能会问了HTTP/3 底层不采用 TCP那怎么保证可靠传输呢答案就是 HTTP/3 在应用层自己重新实现了可靠性机制。也就是说HTTP/3 将原先 TCP 协议提供的部分功能上移至 QUIC而且进行了改进。
