当前位置: 首页 > Web前端 > HTML

HTTP都到了3.0了,1和2你还不懂吗?

时间:2023-03-28 18:11:14 HTML

完整阅读本文大约需要5分钟。概述HTTP协议有四个比较重要的阶段,即0.9/1/2/3,其中1又分为1.0和1.1。协议规定了什么1.HTTP/0.9服务于简单的HTML文件传输HTTP/0.9只能用于传输小型HTML文件,使用ASCII字节码对请求进行编码,对应的格式非常简单,请求只有一个请求行,对应的部分只有一个对应的body2.HTTP/1.0可以支持多种文件类型因为HTTP/1.0支持的文件格式更加多样,所以需要在请求中标注“我需要的文件类型,文件编码...”,header应运而生;服务器收到请求后,可能无法按照规定的要求准备数据,所以会在响应中标记数据的最终组织形式,所以有一个响应头请求结构//请求行GET/4848HTTP/1.0//请求标头连接:Keep-AliveUser-Agent:Mozilla/3.01(X11;I;SunOS5.4sun4m)Pragma:no-cacheHost:tecfa.unige.ch:7778Accept:image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,*/*对应结构//响应行-通过里面的状态码,上报服务器的最终处理状态HTTP/1.0200ok//响应头Date:Wed,164月97日22:54:42GMTServer:E_WEB(E_MOO-Web-Server/1.2d-NotWOO)(LambdaMOO1.8.0p5)Content-type:text/html//Responsebody查询结果

查询结果

...常见请求头和响应头的具体含义。浏览器会用请求头告诉服务器它想要的文件类型、文件编码、压缩形式、文件语言……服务器会用响应头告诉浏览器最终处理结果文件类型不仅仅是HTML,还有javascript/CSS/picture/audio/video//请求头accept:application/json,text/plain,*/*//响应头content-type:application/json文件压缩格式为了减少传输压力,服务器会在传输前压缩数据,所以浏览器需要知道服务器压缩方法,通常针对CSS/JS文件//请求头accept-encoding:gzip,deflate,br//响应头content-encoding:gzip文件编码格式不同类型的文件有不同的编码形式,为了能够准确读取文件,浏览器需要知道文件的编码类型//请求头accept:text/plain;charset=utf-8//响应头内容类型:application/json;charset=utf-8cacheHTTP/1.0提供了缓存机制,用于缓存下载的数据//requestheaderresponseheadercache-control:no-store,no-cache,must-revalidate通过UA获取客户端的基本信息,你可以知道浏览器版本、操作系统等信息//Requestheaderuser-agent:Mozilla/5.0(Macintosh;IntelMacOSX10_15_7)3.HTTP/1.1开始支持持久连接HTTP请求是基于TCP请求的,所以你需要体验一下HTTP1.1中TCP连接的建立和断开,每个HTTP请求都建立在一个TCP连接之上,增加了很多不必要的开销。同样发起了三个请求,两者的时间对比:长连接是由请求头控制的。如果不做特殊处理,默认会保持持久连接。//Requestheaderconnection:keep-alive可以通过以下方式关闭持久连接//Requestheaderconnection:close另外,HTTP/1.1还引入了其他特性虚拟主机随着虚拟主机技术的发展,我们希望使用一个physicalhost上去映射多个虚拟主机:每个虚拟主机都有自己的域名,但是这些独立的域名都指向同一个IP地址。HTTP/1.1在请求头中增加了一个Host字段,表示当前请求的域名地址,这样服务器就可以根据不同的域名做不同的处理//请求头Host:nian.frontend.com支持动态生成内容随着服务器端技术的发展,很多页面的内容都是动态生成的,所以在数据传输之前并不知道最终的数据大小,导致浏览器不知道什么时候才能收到所有的文件数据。以前,响应头会通过Content-Length设置完整的数据大小。HTTP/1.1通过引入Chunktransfer机制解决了这个问题:服务器会将数据分成若干个任意大小的数据块,每个数据块会以前一个数据块的长度发送,最后使用一个零长度的块作为发送数据完成标志。这提供了对动态内容的支持。//ResponseheaderTransfer-Encoding:chunked流水线尝试HTTP/1.1试图通过流水线技术解决队头阻塞。流水线:多个HTTP请求一起发送,服务器根据请求的先后顺序回复到队列的头部由于各种原因,最后都放弃了流水线技术。用来告诉服务器这两个请求是否来自同一个浏览器。//响应头Set-Cookie:yummy_cookie=choco//请求头Cookie:yummy_cookie=choco;四、HTTP/2.0实现了多路复用HTTP/1.1实现了持久连接,但是每个长连接,在一个时间点,只有一个HTTP请求在传输。这导致带宽利用率非常低。比如我们常说的100M带宽,实际下载速度理论上可以达到12.5M/S,但在加载页面资源时可能只能达到2.5M/S。造成这种带宽利用率不足,TCP慢启动,TCP竞争和队头阻塞的原因有3个HTTP队头阻塞:只有当前请求收到响应后,才能处理其他请求,这样就无法处理数据并行请求HTTP/2.0采用Multiplexing来解决HTTP队头阻塞,从而可以并行发出请求。多路复用的实现:二进制分帧使用同一个TCP连接,但是每个HTTP请求都有一个唯一的请求号来区分彼此。所有发送的信息都会经过二进制分帧层的处理,转换成具有相应请求号的帧。接收端接收到所有的帧后,会将编号相同的帧组合起来成为一条完整的消息。此外,HTTP/2.0还引入了其他特性。资源优先级复用技术将请求分成一帧一帧地传输。额外的好处是:当收到高优先级的请求时,可以暂停其他请求,优先处理关键资源服务器推送服务器推送对页面首次打开速度起着至关重要的作用。当浏览器请求一个HTML页面时,服务器知道它会引用几个重要的JS/CSS文件。所以会一起发送给浏览器,这样浏览器解析完HTML文件后,就可以直接得到需要的CSS文件和Javascript文件,并且header压缩浏览器和服务器会维护重复的header字段成为一个当实际传输字典时,只使用了一个短键值。5、HTTP/3.0采用UDP协议在开始了解3.0之前,我们先详细了解一下2.0存在的问题:TCP队头阻塞和TCP握手时间过长什么是队头阻塞?Head-of-lineblocking分为httpHead-of-lineblocking和TCPHead-of-lineblockingHTTPHead-of-lineblocking是指客户端只有收到上一个HTTP请求的响应后,才能发送下一个请求.上面描述的HTTP/2.0已经解决。TCP队头阻塞是指由于数据包是有序传输的,如果中间有任何一个数据包丢失,则必须等待重传,导致后续数据包被阻塞。随着丢包率的增加,HTTP/2.0的传输效率会越来越差。测试数据表明,当系统丢包率达到2%时,HTTP/1的传输效率优于HTTP/2。TCP握手时间过长。建立TCP连接时,需要与服务器进行三次握手。确认连接成功,如果使用HTTPS,还需要TLS握手过程,所以需要两次握手延迟过程。在此背景下,HTTP/3.0被提出。它基于QUIC协议。网络性能优化还需要吗?HTTP/2.0多路复用的影响是巨大的,从Web开发者工具中的网络请求可以直观地看出。在1.1版本下,请求被阻塞了很长时间(前面灰色部分),正是因为TCP连接一次只能服务一个HTTP/1.1请求。在2.0版本中,可以及时响应请求。在2.0时代,之前的一些优化方式会适得其反。在文件合并之前,我们会使用JS文件合并、sprite图片等方式来减少HTTP请求次数,达到优化的目的。因为1.1时代的TCP只能串行复用,现在可以并行传输了。如果合并文件a、b、c,资源a的单独更新会导致本地缓存合并文件整体更新。代替压缩文件,可以更小的粒度更新资源,这是一个更好的选择。在域名分片技术出现之前,由于浏览器对同一个域名的TCP连接数有限制,我们通常会将文件放在几个不同的域名下,以防止超过连接数的HTTP请求被阻塞。但是有了多路复用,可以同时下载同一个域名下的文件,而且只有一个域名,我们只需要建立一个TCP连接就可以了。