asp商业网站源码,nas服务器可以做网站吗,网盘建网站,口碑好的做pc端网站去年年底#xff0c;据国际互联网工程任务组( IETF )消息#xff0c;HTTP-over-QUIC 实验性协议将被重命名为 HTTP/3#xff0c;即有望成为 HTTP 协议的第三个正式版本#xff0c;也就是说HTTP/3可能要来了。 该消息是如此的惹人注目#xff0c;是因为HTTP是我们身边的协议… 去年年底据国际互联网工程任务组( IETF )消息HTTP-over-QUIC 实验性协议将被重命名为 HTTP/3即有望成为 HTTP 协议的第三个正式版本也就是说HTTP/3可能要来了。 该消息是如此的惹人注目是因为HTTP是我们身边的协议Web应用都离不开它。 温故知新梳理一下过往或许更能够理解未来。HTTP1.x的过往HTTP协议大约诞生在我上大一的时候好像是HTTP0.9客户端请求和服务器响应都是ascii码客户端以回车符结尾服务器返回HTML。后来的HTTP1.0服务器响应增加了很多状态请求和响应也多了很多的header响应的内容也不再局限于纯文本了。HTTP是一个应用层协议由请求和响应构成是一个标准的客户端服务器模型是一个无状态的协议。HTTP是建立在TCP之上的每个请求都要经历三次握手和慢启动。客户端是依据域名来向服务器建立连接一般PC端的浏览器支持同域68个连接手机端的连接数则一般控制在46个。连接数不是越多越好资源开销和整体延迟都会随之增大。HTTP 1.1 导致了2000年的互联网热潮。HTTP1.1 支持只发送header信息(不带任何body信息)如果服务器认为客户端有权限请求服务器则返回100否则返回401。客户端如果接受到100才开始把请求body发送到服务器。这样当服务器返回401的时候客户端就可以不用发送请求body了节约了带宽。另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后只需要跟服务器请求另外的部分资源即可。RANGE:bytes是HTTP/1.1新增内容HTTP/1.0每次传送文件都是从文件头开始即0字节处开始。RANGE:bytesXXX表示要求服务器从文件XXX字节处开始传送这大概就是平时所说的断点续传。相关的部分协议标准如下协议编号 协议名称简要描述RFC7230 HTTP/1.1: Message Syntax and Routing底层消息解析和连接管理等RFC7231HTTP/1.1: Semantics and Content方法、状态码和header等RFC7232HTTP/1.1: Conditional Requests例如If-Modified-SinceRFC7233HTTP/1.1: Range Requests获取部分内容等RFC7234HTTP/1.1: Caching浏览器和中介缓存等RFC7235HTTP/1.1: AuthenticationHTTP 的一个authentication框架等现如今Web应用不再单纯是web 网页还有支持多设备和多媒体。 一个SPA的应用可能有上百的连接模块拆分导致了更多的请求大部分时间都消耗在网络上。HTTP 1.x header 往往较大且无法压缩。TCP协议利用过低不可复用连接连接数限制且协议过于庞大。HTTP1.x遇到的问题和解决方案HTTP1.x主要存在连接无法复用和head of line blocking这两个问题。在第一个请求没有收到回复之前后续从应用层发出的请求只能排队。网络通畅的时候性能影响不大一旦第一个请求没有抵达服务器或者response因为网络阻塞没有及时返回就会影响所有后续请求。HTTP1.0协议头里可以设置Connection:Keep-Alive。在header里设置Keep-Alive可以在一定时间内复用连接具体复用时间的长短可以由服务器控制一般在15秒左右这与运营商蜂窝网络的linger time相关。HTTP1.1之后Connection的默认值就是Keep-Alive如果要关闭连接复用需要显式的设置Connection:Close。这对PC端浏览器的体验帮助很大因为大部分的请求在集中在一小段时间以内。但移动app的请求比较分散且时间跨度相对较大一般会从应用层寻求其它解决方案长连接方案或者伪长连接方案。为了解决HTTP连接复用可以采用长轮询HTTP streaming和websocket等方式。和传统的HTTP短链接相比长连接轮询会在用户增长的时候极大的增加服务器压力。移动端网络环境复杂像wifi和4g的网络切换等这些场景都需要考虑重建连接。长轮询方式稳定性并不好需要做好数据可靠性的保证比如重发和ack机制。而且response有可能会被中间代理cache住要处理好业务数据的过期机制。HTTP streaming是通过在server response的头部里增加Transfer Encoding: chunked来告诉客户端后续还会有新的数据。如果永远不会结束客户端就会一直处于等待response的过程中。代理服务器会等待服务器的response结束之后才会将结果推送到请求客户端。对于streaming这种业务数据无法按照请求来做分割所以客户端每收到一块数据都需要自己做协议解析。显然这个数据通道也是单向的还有个缺陷就是不会产生重复的header数据。websocket提供双向的数据通道优势在于提供了message的概念比基于字节流的tcp socket使用更简单同时又提供了传统的HTTP所缺少的长连接功能。但代价相对较高基于tcp的socket编程技术难度相对复杂很多而且需要自己制定协议。HTTP/2 要点HTTP2.0是以SPDY为原型进行讨论和标准化的采用二进制格式传输数据而非 HTTP/1.x 的文本格式。请求和响应都统一为流对消息头采用 HPACK 进行压缩传输能够节省消息头占用的网络的流量。多路复用就是所有的请求都是通过一个 TCP 连接并发完成并支持Server Push和基于优先级的流量控制。HTTP/2 中的帧帧(frame)是HTTP2中最小的通信单位每个帧都会有帧header每个帧用来承载HTTP header 或负荷数据或其他特定类型的帧。帧是遵循二进制编码的。帧格式如下length定义了整个帧的长度type定义帧主要有10种的类型帧类型codeDATA0x0HEADERS0x1PRIORITY0x2RSTSTREAM0x3PUSHPROMISE0x4SETTINGS0x5PING0x6GOAWAY0x7WINDOW_UPDATE0x8CONTINUATION0x9flags用位定义了一些重要的参数,stream id用作流控制而payload才是请求的正文。虽然协议的格式和HTTP1.x完全不同了但并没有改变HTTP1.x的语义只是把原来HTTP1.x的header和body部分用frame重新封装了一层而已。调试的时候浏览器甚至会把HTTP2.0的frame自动还原成HTTP1.x的格式。HTTP2.0与HTTP1.0的对比如下HTTP/2 中的header 压缩HTTP1.x的header由于cookie和user agent很容易变得较大而且每次都要重复发送。HTTP/2使用encoder来减少需要传输的header大小通讯双方各自cache一份header fields表既避免了重复header的传输又减小了需要传输的大小。高效的压缩算法可以很大的压缩header减少发送包的数量从而降低延迟。HTTP/2中的HPACK使用一份索引表来定义常用的 HTTP Header,保留原有的header list的顺序,通过索引键值压缩。 静态表中包含了一些预定义的header字段动态表默认是空的会在头部解压缩的时候确定是否添加entry。客户端和服务器端使用header表来跟踪和存储之前发送的每一个键值对。在tcp连接期间二者共同维护和更新。对于无法用索引替代的字符有的会采用哈夫曼编码压缩。HTTP/2 中的多路复用把HTTP 消息分解为独立的帧交错发送然后在另一端根据Stream ID 重新组装是HTTP 2.0 最重要的一项增强。每个 Frame Header 都有一个 Stream ID。每次请求/响应使用不同的 Stream ID。通过 Stream ID 标识所有的请求和响应都可以同时跑在一个TCP 连接上了。 下图是 HTTP 和 spdy的并发模型对比和一般TCP连接释放一样如果客户端没有数据要请求或服务端数据发送完毕后会主动发送关闭连接的报文。或者是服务端连续发送探测报文客户端无响应服务端就关闭了这个连接。当流并发时就会涉及到流的优先级和依赖。优先级高的流会被优先发送。每个HTTP/2流里面可以带有优先级(31位0为优先级最高)的值这个值确定着客户端和服务器处理不同的流采取不同的优先级策略高优先级的流都应该优先发送。图片请求的优先级要低于CSS和SCRIPT脚本这可以确保重要的东西可以被优先加载。但又不会绝对的绝对地遵守可能又会引入队列阻塞的问题高优先级的请求慢导致阻塞其他资源交付。从tcp连接和网络来看优先级使得网络拥塞得到改善慢启动时间减少拥塞和丢包恢复速度变快。HTTP/2 中的PushServer Push 就是服务器向客户端推送资源而无需客户端明确地请求或者服务器可以对一个客户端请求发送多个响应。当服务端需要主动推送某个资源时便会发送一个 Frame Type 为 PUSH_PROMISE 的 帧里面带了 PUSH 需要新建的 Stream ID。客户端解析 帧时发现它是一个 PUSH_PROMISE 类型便会准备接收服务端要推送的流。HTTP/2连接建立后客户端与服务器交换SETTINGS 帧以此来限定双向并发流的最大数量。因此客户端可以限定推送流的数量或者通过把这个值设置为0完全禁用服务器推送而且所有推送的资源都遵守同源策略。服务器不能随便将第三方资源推送给客户端而必须是经过双方确认才行。所有服务器推送流都由PUSH_PROMISE 发起PUSH_PROMISE 帧必须在返回响应之前发送以免客户端出现竞态条件。客户端接收到PUSH_PROMISE 帧之后可以视自身需求选择拒绝这个流。基于HTTP/2的开发HTTP/2 已经得到了较为广泛的支持服务器的支持包括Apache HTTP Server 2.4.17 Apache Tomcat 8.5NGINX 1.9.5面向PHP的Swoole面向Python 的Twisted...支持HTTP/2的客户端包括Chromium Mozilla Firefoxcurl and libcurlOkHTTP (java Android)面向Obj-C/swift 的 WKWebView...客户端与服务器同时支持HTTP/2的包括Jetty/Nettylua-HTTPNode.js 8.4.0面向perl 的 Protocol::HTTP2面向Go 的HTTP2...支持HTTP/2的代理中介包括HAProxyngHTTP2GFE...详情可以参考HTTPs://github.com/HTTP2/HTTP2-spec/wiki/Implementations。调试工具可以使用chrome的浏览器以及Wireshark等等。在开发中使用了HTTP/2 并不是万事大吉了在HTTP1.X 中的一些优化还需要继续使用例如减少DNS查询和重定向CDN的使用对代码、图片等资源的压缩对文本开启GZip以及使用HTTP的缓存机制(Expires/Cache-Control和Last-Modified / ETag)等等。对于那些可以感知缓存的资源内联或者Push 消息可以利用cookie 协助用户标记。由于HTTP/2基于单个TCP连接容易受到 Head of Line Blocking 的影响从而导致传输速度受限还会受到TCP丢包的影响所以HTTP/2在资源数量较少的网站可能效果不明显。TCP协议的升级依赖于操作系统内核的升级尤其是网络操作系统的升级往往不可控因此业界开始重新审视UDP HTTP/3 所使用的QUIC 就是基于UDP协议的。HTTP/3 何时才能实施呢整个互联网支持HTTP/3 可能还需要一段不短的时间吧参考资料《HTTP 权威指南》HTTPs://HTTP2.akamai.com/demoHTTP://HTTP2.loadimpact.com/entry/RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) RFC 7541 - HPACK: Header Compression for HTTP/2
