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

HTTP的前世今生

时间:2023-03-27 23:44:06 HTML

HTTP协议是浏览器和服务器之间的通信语言HTTP1协议HTTP/0.9:图灵完备,但功能单一需求:主要用于学术交流,用于网络间传输HTML超文本特点内容:无HTTP请求头和请求体,服务器返回无头信息HTTP/1.0:面向大众,解决刚需:支持多种类型的文件下载通过请求头协商文件类型和压缩responseheaders模式、编码等特性:新的状态码:通过响应行通知浏览器。新缓存:缓存下载的数据。:TCP连接→传输HTTP数据→断开连接TCP相当于每次跟别人说一句话就打招呼,很搞笑HTTP/1.1:seedingandpatchingopentheconnection,TCPconnection默认会一直打开,并且同一个域名最多可以同时建立6个TCP连接。利用CDN实现域名分片机制。使用多个域名下载一个页面的资源,增加TCP并发数。不成熟的HTTP管道是持久的虽然连接可以减少TCP重连的次数,但是TCP连接仍然是串行的。如果一个请求没有及时返回,它会阻塞后续的请求。由于各种原因,该解决方案被放弃了。在HTTP/1.0中,每个域名都绑定了一个唯一的IP地址。一个IP地址只能对应一台物理机。但是随着虚拟机技术的发展,一个物理机可以有多个,每个虚拟机都有自己独立的域名,但是域名的IP是一样的。因此新增了一个Host字段来表示当前的域名,服务端可以根据Host做不同的处理来支持动态生成内容HTTP/1.0中使用Content-Length来判断数据的大小,但是随着服务器的发展,很多页面内容都是动态生成的,所以在传输之前并不知道最终的数据大小,这使得浏览器无法判断是否已经接收到所有的数据Chunk传输机制:服务器将数据分成若干个任意大小的数据块并附加其长度,最后以零长度数据块作为发送完成标志。客户端cookie解决了HTTP的无状态限制,用于识别用户身份,信息仍然存在。问题:带宽利用率不理想。带宽:每秒可以发送或接收的最大字数节点数上行带宽:每秒可以发送的最大字节数下游带宽:每秒可以接收的最大字节数原因:TCP慢启动:TCP建立连接后,进入发送数据状态,发送数据的速度从慢到快,慢启动是TCP为了减少网络拥塞而采取的一种缓冲策略。页面常用的一些关键资源文件并不大,比如HTML/CSS/JS文件。通常,这些文件会在TCP连接建立后发起请求。但是由于启动慢,比正常情况下花费的时间要多很多,延迟了页面第一次渲染的时间。资源竞争:多个TCP连接竞争固定带宽时,无法区分重要资源的优先级。当页面下载资源较多且带宽不够时,TCP连接会动态减慢接收数据的速度,而且这种减慢没有优先级,会造成视频、图片等较大的资源争抢用于渲染初始页面的HTML/CSS等资源并导致白屏队列头阻塞:每个TCP管道一次只能处理一个请求。当请求还没有结束时,其他请求只能等待,类似于在同一个窗口排队等业务。HTTP2协议解决了HTTP1.1中TCP慢启动、带宽资源竞争、队头拥塞等问题。虽然TCP是这些问题的根源,但脱离TCP协议仍然是不可能的。只能想办法避免以上问题HTTP2的核心特性是如何解决队头拥塞的?多路复用机制浏览器发起的每个请求都会携带一个**ID**,服务器返回数据时也会携带相应的ID,浏览器会将返回ID的内容拼接成一个完整的HTTP响应数据。这就像去一家餐厅,你可以自己点菜。点餐后,您等待食物送达。这样就解决了排队点餐造成的同行拥堵问题。请求可以分成数据帧进行传输。当收到一个高优先级的请求时,服务器可以暂停之前的请求,去处理优先级更高的资源请求。实现机制:HTTP2增加了一个新的二进制框架层。浏览器已准备好请求数据。二进制框架层将请求数据转换为单独的请求ID。编号的帧通过协议栈发送给服务器。服务器接收到所有的帧,将所有具有相同ID的帧合并成一个完整的请求报文。服务器处理请求,将处理后的响应行、响应头、响应体分别发送给二进制分帧层二进制分帧层将响应数据转换成带有请求ID号的帧,通过协议栈发送给浏览器.浏览器收到响应帧后,将帧数据提交给相应的请求流程图BT子图HTTP2协议栈子图请求列表...结束子图二进制分帧层子图完整请求头+ID响应头+ID响应体+IDendendrequestlist<-->binaryframinglayer<->TLS[TLSoptional]<-->TCP/IPend如何解决TCP慢启动时间和TCP之间的带宽资源竞争?一个域名只使用一个TCP长连接传输数据,减少了每个TCP连接带来的副作用。HTTP2的其他特性可以设置请求的优先级:优先加载重要资源刚请求HTML时服务器推送,HTML需要的CSS/JS也一起发送给浏览器,对速度起到至关重要的作用第一次打开页面。Headcompression仍然存在,以优化TCP传输层的head-of-lineblocking:虽然HTTP2解决了应用层到传输层的head-of-lineblocking问题,但是从传输层到传输层的丢包重传机制网络层仍然可以阻塞TCP管道,而TCP本来是为单连接设计的,HTTP2在丢包严重的情况下表现比HTTP1.1差,因为后者有6个TCP管道。TCP连接建立延时:在传输数据之前,需要TCP+TLS握手消耗的3~4RTTTCP协议是死板的:因为TCP发展到现在的历史包袱太重,属于相对底层和核心位置的计算机,不可能同步所有设备。HTTP3摆脱了TCP和TLS的负担。构建高效的网络QUIC协议正在考虑兼容中间设备的刚性。不可能重新构建一个新的传输层协议并且很好的兼容。只能在现有基础上进行扩展和优化。因为HTTP3选择了一个折衷的方案——UDP协议,它在UDP的基础上实现了类似TCP的功能。该协议称为QUIC协议。HTTP/2和HTTP/3协议栈的挑战HTTP3兼容性:无论是服务器还是浏览器都没有对HTTP3提供比较完善的支持UDP的市场成熟度:系统内核对UDP的优化远远达不到TCP中间设备的优化水平刚性:UDP的优化不如TCP。使用QUIC协议时,丢包率为3%~7%。总结:核心诉求不够好。HTTP0.9可以传输HTML文件,学术交流简单,图灵完备功能单一。HTTP1.0可下载多种文件类型满足时代迫切下载需求TCP反复握手,效率低HTTP1.1TCP持久会话多路复用优化1.0管道阻塞满足各种需求HTTP2.0实现管道内多路复用,大大提高传输效率1.1TCP协议HTTP3.0带来的各种问题——未来会解决TCP速度快、兼容性差的缺点。从HTTP0.9到以后的HTTP3.0,协议的变化也随着时代和市场的需要而变化。每个大版本的改动都是为了解决一个核心问题,每一次改动都需要慎之又慎。当不可逆转的行为发生时,就会形成沉重的历史包袱,甚至延缓社会的进步,直到忍无可忍时被推翻,再为此付出代价。可能性将是整个世界。