web技术_使用浏览器进行全双工通信的 WebSocket&HTTP协议的性能瓶颈&Ajax&Comet&SPDY技术

文章目录

• 使用浏览器进行全双工通信的 WebSocket&HTTP协议的性能瓶颈&Ajax&Comet&SPDY技术
• • http的性能问题
  • • Ajax 的解决方法
    • Ajax的问题
    • Comet 的解决方法(deprecated)
    • • Comet (programming)
      • comet的问题
    • SPDY 技术(deprecated)
    • • spdy的问题
  • websocket技术
  • WebSocket 的设计与功能
  • WebSocket 协议
  • WebSocket 协议的主要特点
  • • 握手·请求
    • 握手·响应
  • http2.0

使用浏览器进行全双工通信的 WebSocket&HTTP协议的性能瓶颈&Ajax&Comet&SPDY技术

http的性能问题

以下这些 HTTP 标准造成性能瓶颈。

• 一条连接上只可发送一个请求。
• 请求只能从客户端开始。客户端不可以接收除响应以外的指令。
• 请求 / 响应首部未经压缩就发送。首部信息越多延迟越大。
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
• 可任意选择数据压缩格式。非强制压缩发送。

Ajax 的解决方法

• Ajax（Asynchronous JavaScript and XML， <u异 步 JavaScript 与 XML技术</u）

  • 一种有效利用 JavaScript 和 DOM（Document Object Model，文档对象模型）的操作，以达到局部 Web 页面替换加载的异步通信手段。

• 和以前的同步通信相比，由于它只更新一部分页面，响应中传输的数据量会因此而减少，这一优点显而易见。

  • Ajax 的核心技术是名为 XMLHttpRequest 的 API，通过 JavaScript脚本语言的调用就能和服务器进行 HTTP 通信。
  • 借由这种手段，就能从已加载完毕的 Web 页面上发起请求，只更新局部页面。

Ajax的问题

• 而利用 Ajax 实时地从服务器获取内容，有可能会导致大量请求产生。
• 另外，Ajax 仍未解决 HTTP 协议本身存在的问题。

Comet 的解决方法(deprecated)

Comet (programming)

• 这是一类过时技术,这里提一下其设计

From Wikipedia, the free encyclopedia

• Comet is a web application model in which a long-held HTTPS request allows a web server to push data to a browser, without the browser explicitly requesting it.

• [1][2] Comet is an umbrella term(总括术语), encompassing multiple techniques for achieving this interaction. 涵盖多种技术来实现这种相互作用

• All these methods rely on features included by default in browsers,

  • such as JavaScript, rather than on non-default plugins.
  • The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.[3]

• The use of Comet techniques in web development predates (早于)the use of the word Comet as a neologism (a newly coined 创造word or expression)for the collective techniques.

• Comet is known by several other names, including Ajax Push,[4][5]

  • Reverse Ajax,[6]
  • Two-way-web,[7]
  • HTTP Streaming,[7]
  • and HTTP server push[8] among others.[9]

• The term Comet is not an acronym, but was coined by Alex Russell in his 2006 blog post Comet: Low Latency Data for the Browser.[10]

• In recent years, the standardisation(标准化) and widespread support of WebSocket and Server-sent events has rendered the Comet model obsolete.

• 一旦服务器端有内容更新了，Comet 不会让请求等待，而是直接给客户端返回响应。
  • 这是一种通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。
  • 通常，服务器端接收到请求，在处理完毕后就会立即返回响应
  • 但为了实现推送功能，Comet 会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。
• 因此，服务器端一旦有更新，就可以立即反馈给客户端。

comet的问题

• 内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了。
• 期间，为了维持连接会消耗更多的资源。
• 另外，Comet也仍未解决 HTTP 协议本身存在的问题。

SPDY 技术(deprecated)

• SPDY (pronounced “speedy”)[1] is an obsolete open-specification communication protocol developed for transporting web content.[1] SPDY became the basis for HTTP/2 specification. However, HTTP/2 diverged from SPDY and eventually HTTP/2 subsumed all usecases of SPDY.[2] After HTTP/2 was ratified as a standard, major implementers, including Google, Mozilla, and Apple, deprecated SPDY in favor of HTTP/2. Since 2021, no modern browser supports SPDY.
• Google announced SPDY in late 2009 and deployed in 2010. SPDY manipulates HTTP traffic, with particular goals of reducing web page load latency and improving web security. SPDY achieves reduced latency through compression, multiplexing, and prioritization,[1] although this depends on a combination of network and website deployment conditions.[3][4][5] The name “SPDY” is a trademark[6] of Google and is not an acronym.[7]

该技术已经过时,此处仅提一下它的设计

• 陆续出现的 Ajax 和 Comet 等提高易用性的技术，一定程度上使HTTP 得到了改善，但 HTTP 协议本身的限制也令人有些束手无策。
• 为了进行根本性的改善，需要有一些协议层面上的改动。
  • SPDY 没有完全改写 HTTP 协议，而是在 TCP/IP 的应用层与运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY规定通信中使用 SSL。
  • SPDY 以会话层的形式加入，控制对数据的流动，但还是采用HTTP 建立通信连接。因此，可照常使用 HTTP 的 GET 和 POST 等方法、Cookie 以及 HTTP 报文等。

spdy的问题

• 因为 SPDY 基本上只是将单个域名（IP 地址）的通信多路复用，所以当一个 Web 网站上使用多个域名下的资源，改善效果就会受到限制。
• SPDY 的确是一种可有效消除 HTTP 瓶颈的技术，但很多 Web 网站存在的问题并非仅仅是由 HTTP 瓶颈所导致。对 Web 本身的速度提升，还应该从其他可细致钻研的地方入手，比如改善 Web 内容的编写方式等。

websocket技术

• 利用 Ajax 和 Comet 技术进行通信可以提升 Web 的浏览速度。
  • 但问题在于通信若使用 HTTP 协议，就无法彻底解决瓶颈问题。
• WebSocket网络技术正是为解决这些问题而实现的一套新协议及 API。
  • 当时筹划将 WebSocket 作为 HTML5 标准的一部分，而现在它却逐渐变成了独立的协议标准。
  • WebSocket 通信协议在 2011 年 12 月 11 日，被 RFC 6455 - The ebSocket Protocol 定为标准。

WebSocket 的设计与功能

• WebSocket，即 Web 浏览器与 Web 服务器之间全双工通信标准。
  • 其中，WebSocket 协议由 IETF 定为标准，WebSocket API 由 W3C 定为标准。
  • 仍在开发中的 WebSocket 技术主要是为了解决 Ajax 和 Comet 里XMLHttpRequest 附带的缺陷所引起的问题。

WebSocket 协议

一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接，之后所有的通信都依靠这个专用协议进行。

通信过程中可互相发送JSON、XML、HTML 或图片等任意格式的数据。

• 由于是建立在 HTTP 基础上的协议，因此连接的发起方仍是客户端，

  而一旦确立 WebSocket 通信连接，不论服务器还是客户端，任意一方都可直接向对方发送报文。

WebSocket 协议的主要特点

• 推送功能支持由服务器向客户端推送数据的推送功能。

  • 这样，服务器可<u直接发送数据，而不必等待客户端的请求</u。

• 减少通信量

  • 只要建立起 WebSocket 连接，就希望一直保持连接状态。
  • 和 TTP相比，不但每次连接时的总开销减少，而且由于 WebSocket 的首部信息很小，通信量也相应减少了。

• 为了实现 WebSocket 通信，在 <uHTTP 连接建立之后，需要完成一次“握手”（Handshaking）的步骤</u。

握手·请求

• 为了实现 WebSocket 通信，需要用到 HTTP 的 Upgrade 首部字段，告知服务器通信协议发生改变，以达到握手的目的。

• Sec-WebSocket-Key 字段内记录着握手过程中必不可少的键值。

• Sec-WebSocket-Protocol 字段内记录使用的子协议。
  • 子协议按 WebSocket 协议标准在连接分开使用时，定义那些连接的名称。

握手·响应

• 对于之前的请求，返回状态码 101 Switching Protocols 的响应。

• Sec-WebSocket-Accept 的字段值是由握手请求中的 Sec-WebSocket-Key 的字段值生成的。
• 成功握手确立 WebSocket 连接之后，通信时不再使用 HTTP 的数据帧，而采用 WebSocket 独立的数据帧。

http2.0

from wikipedia

• HTTP/2 (originally named HTTP/2.0) is a major revision of the HTTP network protocol used by the World Wide Web.

  • It was derived from the earlier experimental SPDY protocol, originally developed by Google.[1][2]
  • HTTP/2 was developed by the HTTP Working Group (also called httpbis, where “bis” means “twice”) of the Internet Engineering Task Force (IETF).[3][4][5]
  • HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997.

• The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard 作为拟定标准考虑 in December 2014,[6][7]

• and IESG approved it to publish as Proposed Standard on February 17, 2015 (and was updated in February 2020 in regard to TLS 1.3).[8][9]

• The HTTP/2 specification was published as RFC 7540 on May 14, 2015.[10]

• The standardization effort was supported by Chrome, Opera, Firefox,[11] Internet Explorer 11, Safari, Amazon Silk, and Edge browsers.[12]

• Most major browsers had added HTTP/2 support by the end of 2015.[13] About 97% of web browsers used have the capability.[14] As of October 2021, 47% (after topping out at just over 50%) of the top 10 million websites supported HTTP/2.[15]

• Its proposed successor is HTTP/3, a major revision that builds on the concepts established by HTTP/2.[2][16][17][[18]](