济南网站建设cn un,中国建造师官网查询,电子商务系统的构成,东莞网络优化推广公司哪家好本文是《Web性能权威指南》第四部分——浏览器API与协议的读书笔记。 第一部分——网络技术概览#xff0c;请参考网络技术概览#xff1b; 第二部分——无线网络性能#xff0c;请参考无线网络性能#xff1b; 第三部分——HTTP#xff0c;请参考HTTP。
浏览器网络概述 …本文是《Web性能权威指南》第四部分——浏览器API与协议的读书笔记。 第一部分——网络技术概览请参考网络技术概览 第二部分——无线网络性能请参考无线网络性能 第三部分——HTTP请参考HTTP。
浏览器网络概述
现代浏览器是一个囊括数百个组件的操作系统包括进程管理、安全沙箱、分层优化缓存、JS虚拟机、图形渲染和GPU管道、存储系统、传感器、音频与视频、网络机制等。
浏览器乃至运行在其中的应用的性能取决于若干组件解析、布局、HTML与CSS的样式计算、JS执行速度、渲染管道、网络相关各层协议的配合。
连接管理与优化
浏览器完成套接字重用、请求优先级排定、晚绑定、协议协商、施加连接数限制把请求管理生命周期与套接字管理分开。
套接字是以池的形式进行管理的即按照来源每个池都有自己的连接限制和安全约束。挂起的请求是排好队的、有优先次序的然后再适时把它们绑定到池中个别的套接字上。除非服务器有意关闭连接否则同一个套接字可以自动用于多个请求 解读
来源由应用协议、域名和端口三个要件构成套接字池属于同一个来源的一组套接字。实践中所有主流浏览器的最大池规模都是6个套接字。
浏览器的套接字池管理的好处
可自动重用TCP连接从而有效保障性能可按照优先次序发送排队的请求可重用套接字以最小化延迟并提升吞吐量可预测请求提前打开套接字可优化何时关闭空闲套接字可优化分配给所有套接字的带宽。
网络安全与沙箱
浏览器沙箱机制对不受信任的应用代码采取一致的安全与策略限制。
浏览器提供的安全策略
连接限制浏览器管理所有打开的套接字池并强制施加连接数限制保护客户端和服务器的资源不会被耗尽请求格式化与响应处理浏览器格式化所有外发请求以保证格式一致和符合协议的语义从而保护服务器。类似地响应解码也会自动完成以保护用户TLS协商浏览器执行TLS握手和必要的证书检查。任何证书有问题比如服务器正在使用自已签发的证书用户都会收到通知同源策略浏览器会限制应用只能向哪个来源发送请求还有其他很多。
充分体现最低特权(Least Privilege)原则。浏览器只向应用代码公开那些必要的API和资源应用提供数据和URL浏览器执行请求并负责管理每个连接的整个生命周期。
另外同源策略实际上是一组相关机制涉及对DOM访问、cookie和会话状态管理、网络及其他浏览器组件的限制。
资源与客户端状态缓存
浏览器缓存管理
浏览器针对每个资源自动执行缓存指令浏览器会尽可能恢复失效资源的有效性浏览器会自动管理缓存大小及资源回收。
浏览器还提供会话认证和cookie管理。认证的会话可以在多个标签页或浏览器口间共享反之亦然如果用户在某个标签页中退出那么其他所有打开窗口中的会话都将失效。
应用API与协议
不存在哪个协议或API最好的问题。每个稍微复杂点的应用都会基于不同的需求用到各种传输机制包括读写浏览器缓存、协议开销、消息延迟、可靠性、数据传输类型。
XHR、SSE和WebSocket的高级特性
项目XMLHttpRequestServer-Sent EventWebSocket请求流否否是响应流受限是是分帧机制HTTP事件流二进制分帧二进制数据传输是否(base64)是压缩是是受限应用传输协议HTTPHTTPWebSocket网络传输协议TCPTCPTCP
XMLHttpRequest
XHR是浏览器层面的API可以让开发人员通过JS实现数据传输。XHR是在IE5中首次亮相的后来成为AJAXAsynchronous JavaScript and XML核心技术是几乎所有Web应用必不可少的基本构件。
XHR诞生前网页要获取客户端和服务器的任何状态更新都必须刷新一次。XHR可实现异步且完全通过应用的JS代码完成。XHR是从制作网页转换为开发交互应用的根本技术。
XHR是浏览器提供的应用API即浏览器会自动完成所有底层工作
连接管理协议协商HTTP请求格式化连接建立、套接字池和连接终止选择最佳的HTTP传输协议HTTP 1.0、1.x和2.0处理HTTP缓存、重定向和内容类型协商保障安全、验证和隐私其他很多。
这并不是说XHR在任何场景中都是最有效的传输方式。
XHR简史
XHR的早期版本能力有限只能传输文本处理上传的能力不足不能处理跨域请求。W3C于2008年发布XHR Level 2草案新增支持如下新功能
请求超时传输二进制和文本数据应用重写媒体类型和编码响应监控每个请求的进度事件有效的文件上传安全的跨来源请求。
所有新的XHR2功能都是通过同一个XMLHttpRequest API提供的接口不变功能增强。
CORS
跨源资源共享
一个源由应用协议、域名和端口这三个要件共同定义。
要启用cookie和HTTP认证客户端必须在发送请求时通过XHR对象发送额外的属性withCredentials而服务器也必须以适当的首部Access-Control-Allow-Credentials响应表示它允许应用发送用户的隐私数据。如果客户端需要写或者读自定义的HTTP首部或者想要使用“不简单的方法”发送请求那么它必须首先要获得第三方服务器的许可即向第三方服务器发送一个预备preflight请求
XHR下载
XHR可传输文本数据、二进制数据。浏览器会自动为各种原生数据类型提供编码和解码服务应用在直接将这些数据传给XHR时就已经编码/解码好了反之亦然。浏览器可自动解码的数据类型如下
ArrayBuffer固定长度的二进制数据缓冲区Blob二进制大对象或不可变数据Document解析后得到的HTML或XML文档JSON表示简单数据结构的JS对象Text简单的文本字符串。
浏览器可依靠HTTP的content-type首部来推断数据类型应用也可在发起XHR请求时显式重写数据类型。
Blob是HTML5的File API就像一个不透明的引用可指向任何数据块二进制或文本。只能查询其大小、MIME类型或将它切分成更小的块用于提供一种JS API之间的高效的互操作机制。
XHR上传
通过XHR上传任何类型的数据都很简单且高效
var xhr new XMLHttpRequest();
xhr.open(POST, /upload);
xhr.onload function() { ... };
xhr.send(text string);// 发送字符串XHR对象的send()方法可接受DOMString、Document、FormData、Blob、File及ArrayBuffer对象并自动完成相应的编码设置适当的HTTP内容类型content-type然后再分派请求。
XHR不支持请求流这意味着在调用send()时必须提供完整的文件。一种解决方案切分文件然后通过多个XHR请求分段上传。
监控下载和上传进度
网络连接可能会间歇性中断而延迟和带宽也高度不稳定。XHR对象提供一个方便的API用于监控进度事件可代表请求的当前状态。
事件类型说明触发次数loadstart传输已开始一次progress正在传输零或多次error传输出错零或多次abort传输终止零或多次load传输成功零或多次loadend传输完成一次
每个XHR请求开始时都会触发loadstart事件而结束时都会触发loadend事件。要监控进度可以在XHR对象上注册一系列JavaScript事件监听器
var xhr new XMLHttpRequest();
xhr.open(GET, /resource);
xhr.timeout 5000; // 设置请求的超时时间为5000ms,默认无超时限制
xhr.addEventListener(load, function() { ... }); // 为请求成功注册回调
xhr.addEventListener(error, function() { ... });
var onProgressHandler function(event) {if (event.lengthComputable) {var progress (event.loaded / event.total) * 100;}
}
xhr.upload.addEventListener(progress, onProgressHandler); // 为上传进度事件注册回调
xhr.download.addEventListener(progress, onProgressHandler);
xhr.send();解读load和error被触发代表XHR传输的最终状态progress事件则可能触发任意多次这就为监控传输状态提供便利可比较loaded与total属性估算传输完成的数据比例。
要估算传输完成的数据量服务器必须在其响应中提供内容长度Content-Length首部。分块数据则无法估计进度。
流式数据传输
XHR2规范提供读取服务器部分响应的能力但效率却很低且有诸多限制。
XHR加Streams API可让浏览器支持高效的XHR流。通过XHR实现流式上传还不行通过XHR实现流式下载却得到浏览器有限支持。
SSE提供方便的流API用于从服务器向客户端发送文本数据WebSocket提供高效双向的流机制同时支持二进制和文本数据。
Firefox和IE都提供定制的XHR流扩展
Firefox支持moz-chunked-text和moz-chunked-arraybufferIE支持ms-stream。
通过将XHR对象上的responseType属性设置为前述数据类型这两个浏览器就可以不缓冲整个响应同时允许通过XHR对象递增地读取二进制响应。
实时通知与交付
客户端和服务端交互
必要时客户端可向服务器发送一个XHR请求以更新服务器上的相应数据服务器的数据更新主动通知客户端不容易。
HTTP没有提供服务器向客户端发起连接的方式。
解决方法
客户端轮询服务端利用流式传输让服务器推送通知。
XHR轮询
轮询间隔长轮询间隔意味着延迟交付而短轮询间隔会导致客户端与服务器间不必要的流量和协议开销。
最佳的轮询间隔取决于应用而且始终都会存在关于效率和消息延迟的权衡。
轮询最适合间隔时间长新事件到达时间有规律且传输数据量大的场景。这个组合可以抵消多余的HTTP开销并将消息交付的延迟最小化。
XHR长轮询
长轮询在没更新时不再返回空响应而是把连接保持到有更新时。 Comet利用长时间保留的HTTP请求挂起的GET来让服务器向浏览器推送数据的技术也叫保留AJAX、AJAX推送、HTTP推送。
长轮询解决消息交付延迟的问题消灭空检查减少XHR请求次数和轮询的整体开销。
长轮询不一定总是比轮询更好。
实践中并不是所有更新都具有相同的优先级或者延迟要求。可考虑采取混合策略在服务器上累积低优先级的更新同时对高优先级消息则立即触发更新。
使用场景及性能
XHR实现异步通信分派和控制HTTP请求只要几行JS代码浏览器包办各种复杂任务
浏览器格式化HTTP请求并解析响应浏览器强制施加相关的安全同源策略浏览器处理内容协商如gzip压缩浏览器处理请求和响应的缓存浏览器处理认证、重定向等
局限
XHR不适合流式数据处理XHR实时交付更新有延迟或高开销。
服务器发送事件
Server-Sent EventsSSE。SSE设计两个组件使得服务器可向客户端流式发送文本消息比如服务器上生成的实时通知或更新
浏览器中的EventSource可让客户端以DOM事件的形式接收到服务器推送的通知新的事件流数据格式用于交付每一次更新。
这两者使SSE成为在浏览器中处理实时数据的高效而不可或缺的工具
通过一个长连接低延迟交付高效的浏览器消息解析不会出现无限缓冲自动跟踪最后看到的消息及自动重新连接消息通知在客户端以DOM事件形式呈现。
实际上SSE提供的是一个高效、跨浏览器的XHR流实现消息交付只使用一个长HTTP连接。与自己实现XHR流不同浏览器会管理连接、解析消息从而让开发者只关注业务逻辑。
API
使用实例
var source new EventSource(/path/to/stream-url); // 打开到流终点的SSE连接
source.onopen function () { ... }; // 可选回调建立连接时调用
source.onerror function () { ... }; // 可选回调连接失败时调用
source.addEventListener(foo, function (event) {processFoo(event.data);
});
// 监听所有事件不明确指定事件类型
source.onmessage function (event) {log_message(event.id, event.data);if (event.id CLOSE) {// 如果服务器发送CLOSE消息ID关闭SSE连接source.close();}
}EventSource可以像常规XHR一样利用CORS许可及选择同意机制实现客户端到远程服务器的流式事件数据传输。
SSE实现节省内存的XHR流。与原始的XHR流在连接关闭前会缓冲接收到的所有响应不同SSE连接会丢弃已经处理过的消息而不会在内存中累积。
EventSource接口还能自动重新连接并跟踪最近接收的消息如果连接断开EventSource会自动重新连接到服务器还可以向服务器发送上一次接收到的消息ID基于事件流协议以便服务器重传丢失的消息并恢复流。
Event Stream协议
SSE事件流是以流式HTTP响应形式交付的客户端发起常规HTTP请求服务器以自定义的text/event-stream内容类型响应然后交付UTF-8编码的事件数据。
事件流协议
事件载荷就是一或多个相邻data字段的值事件可以带ID和event表示事件类型事件边界用换行符标识。
在接收端EventSource接口通过检查换行分隔符来解析到来的数据流从data字段中提取有效载荷检查可选的ID和类型最后再分派一个DOM事件告知应用。如果存在某个类型那么就会触发自定义的DOM事件处理程序否则就会调用通用的onmessage回调。
不支持二进制传输是有意为之的。SSE的设计目标是简单、高效作为一种服务器向客户端传送文本数据的机制。如果你想传输二进制数据WebSocket才是更合适的选择。
除了自动解析事件数据SSE还内置支持断线重连恢复客户端因断线而丢失的消息。默认情况下如果连接中断浏览器会自动重新连接。SSE规范建议的间隔时间是2~3秒这也是大多数浏览器采用的默认值。服务器也可设置一个自定义间隔时间只要在推送任何消息时向客户端发送一个retry命令即可。
根据应用的要求和数据流服务器可以采取不同的实现策略
如果丢失消息可接受就不需要事件ID或特殊逻辑只要让客户端重连并恢复数据流即可如果必须恢复消息则服务器就需要指定相关事件的ID以便客户端在重连时报告最后接收到的ID。同样服务器也需要实现某种形式的本地缓存以便恢复并向客户端重传错过的消息。
使用场景及性能
SSE是服务器向客户端发送实时文本消息的高性能机制服务器可以在消息刚刚生成就将其推送到客户端低延迟使用长连接的事件流协议还可gzip压缩低开销浏览器负责解析消息也没有无限缓冲。还有超级简单的EventSource API能自动重新连接和把消息通知作为DOM事件。
SSE的两个局限
只能从服务器向客户端发送数据不能满足需要请求流的场景比如向服务器流式上传大文件事件流协议设计为只能传输UTF-8数据即使可以传输二进制流效率也不高。
UTF-8的限制可在应用层克服。
实时推送就像轮询一样可能会极大影响电池的待机时间。首先可以考虑批量处理消息尽量少唤醒无线电模块。其次避免不必要的长连接SSE连接在无线电空闲时不会断开。
WebSocket
WebSocket可实现客户端与服务器间双向的基于消息的文本或二进制数据传输。它是浏览器中最靠近套接字的API。浏览器基于WebSocket提供的服务
连接协商和同源策略与既有HTTP基础设施的互操作基于消息的通信和高效消息分帧子协议协商及可扩展能力。
自定义数据交换协议的问题通常也在于自定义。因为应用必须考虑状态管理、压缩、缓存及其他原来由浏览器提供的服务。设计限制和性能权衡始终会有利用WebSocket也不例外。WebSocket并不能取代HTTP、XHR或SSE而为了追求最佳性能关键还是要利用这些机制的长处。
WebSocket由多个标准构成WebSocket API是W3C定义的而WebSocket协议RFC 6455及其扩展则由HyBi Working GroupIETF定义。
API
WebSocket API使用示例
// 打开新的安全WebSocket连接(wss)
var ws new WebSocket(wss://example.com/socket);
// 可选回调连接出错、关闭、建立
ws.onerror function (error) { ... }
ws.onclose function () { ... }
ws.onopen function () {// 客户端发送消息ws.send(Connection established. Hello server!);
}
// 回调函数服务器发回消息客户端执行业务逻辑
ws.onmessage function(msg) {if(msg.data instanceof Blob) {processBlob(msg.data);} else {processText(msg.data);}
}WS与WSS
WebSocket资源URL采用自定义模式ws表示纯文本通信wss表示使用加密信道通信TCPTLS。
WebSocket的连接协议也可用于浏览器之外的场景可通过非HTTP协商机制交换数据。所以自定义URL协议。
接收文本和二进制数据
ArrayBuffer表示一个普通的、固定长度的二进制数据缓冲。可用ArrayBuffer创建一或多个ArrayBufferView对象每一个都可通过特定格式来展示缓冲中的内容。在取得这个类型的ArrayBuffer对象后可以对同一个缓冲创建多个不同的视图每个视图的偏移量和数据类型都可以不一样。每个视图都以父缓冲、开始字节偏移量和要处理的元素数作为参数其中偏移量根据之前字段的大小计算。ArrayBuffer和WebSocket实际上为开发者在浏览器中处理二进制数据提供所有必要的工具。
发送文本和二进制数据
WebSocket提供双向通信信道即在同一个TCP连接上可双向传输数据。
send()方法是异步的查询套接字的bufferedAmount属性监控在浏览器中排队的数据量来获取数据发送状态。
所有WebSocket消息都会按照它们在客户端排队的次序逐个发送。大量排队的消息甚至一个大消息都可能导致排在它后面的消息延迟队首阻塞。
为解决这个问题应用可以将大消息切分成小块通过监控bufferedAmount的值来避免队首阻塞。甚至还可以实现自己的优先队列而不是盲目都把它们送到套接字上排队。
子协议协商
WebSocket协议对每条消息的格式事先不作任何假设仅用一位标记消息是文本还是二进制以便客户端和服务器有效地解码数据而除此之外的消息内容就是未知的。
如果需要沟通关于消息的元数据客户端和服务器必须达成沟通这一数据的子协议。
与WebSocket消息的灵活性和低延迟对应的就是应用逻辑必须复杂一点。
如果子协议协商成功就会触发客户端的onopen回调应用可查询WebSocket对象上的protocol属性从而得知服务器选定的协议。反之服务器如果不支持客户端声明的任何一个协议则WebSocket握手是不完整的此时会触发onerror回调连接断开。
协议
HyBi Working Group制定的WebSocket通信协议RFC 6455包含两个高层组件
开放性HTTP握手用于协商连接参数二进制消息分帧机制用于支持低开销的基于消息的文本和二进制数据传输。
WebSocket协议是一个独立完善的协议可在浏览器之外实现。
二进制分帧层
客户端和服务器WebSocket应用通过基于消息的API通信发送端提供任意UTF-8或二进制的净荷接收端在整个消息可用时收到通知。使用自定义二进制分帧格式把每个消息切分成多个帧发送到目的地之后再组装起来等到接收到完整消息后再通知接收端。 两个概念
帧最小的通信单位包含可变长度的帧首部和净荷部分净荷可能包含完整或部分应用消息消息一系列帧与应用消息对等。
是否把消息分帧由客户端和服务器实现决定应用层可以不关心。但提到性能优化得理解帧
每一帧的第一位FIN表示当前帧是不是消息的最后一帧。一条消息有可能只对应一帧。操作码4位表示被传输帧的类型传输应用数据时是文本1还是二进制2连接有效性检查时是关闭8、呼叫ping9还是回应pong10。掩码位表示净荷是否有掩码只适用于客户端发送给服务器的消息。净荷长度由可变长度字段表示如果是0~125就是净荷长度如果是126则接下来2字节表示的16位无符号整数才是这一帧的长度如果是127则接下来8字节表示的64位无符号整数才是这一帧的长度。掩码键包含32位值用于给净荷加掩护。净荷包含应用数据如果客户端和服务器在建立连接时协商过也可以包含自定义的扩展数据。
所有客户端发送帧的净荷都要使用帧首部中指定的值加掩码这样可以防止客户端中运行的恶意脚本对不支持WebSocket的中间设备进行缓存投毒攻击cache poisoning attack参考DNS-cache-poisoning/。
服务器发送的每个WebSocket帧会产生2~10字节分帧开销客户端必须发送掩码键会增加4字节结果就是6~14字节开销。此外没有其他元数据如首部字段或其他关于净荷的信息所有WebSocket通信都是通过交换帧实现的而帧将净荷视为不透明的应用数据块。
队首阻塞WebSocket消息可能会被分成一或多个帧但不同消息的帧不能交错发送因为没有与HTTP 2.0分帧机制中流ID对等的字段。
WebSocket不支持多路复用每个WebSocket连接都需要一个专门的TCP连接。
协议扩展
数据格式和WebSocket协议的语义可以通过新的操作码和数据字段扩展。
HyBi Working Group进行两项扩展
多路复用扩展Multiplexing Extension for WebSockets可将WebSocket的逻辑连接独立出来实现共享底层的TCP连接使用信道ID扩展每个WebSocket帧从而实现多个虚拟WebSocket信道共享一个TCP连接。压缩扩展Compression Extensions for WebSocket增加压缩功能相当于HTTP的传输编码协商。
压缩扩展有两种方式
逐帧压缩以帧为单位对被分成多个帧的大消息不友好消息压缩以消息为单位。
要使用扩展客户端必须在第一次的Upgrade握手中通知服务器服务器必须选择并确认要在商定连接中使用的扩展。
HTTP升级协商
WebSocket协议提供很多强大的特性基于消息的通信、自定义二进制分帧层、子协议协商、可选的协议扩展等。
WebSocket可利用HTTP完成握手可重用并扩展HTTP的Upgrade流为其添加自定义WebSocket首部以完成协商
Sec-WebSocket-Version客户端发送表示想使用的WebSocket协议版本RFC 6455。如果服务器不支持这个版本必须回应自己支持的版本Sec-WebSocket-Key客户端发送自动生成的一个键以验证服务器支持请求的协议版本Sec-WebSocket-Accept服务器响应包含Sec-WebSocket-Key的签名值证明它支持请求的协议版本Sec-WebSocket-Protocol用于协商应用子协议客户端发送支持的协议列表服务器必须只回应一个协议名Sec-WebSocket-Extensions用于协商本次连接要使用的WebSocket扩展客户端发送支持的扩展服务器通过返回相同的首部确认自己支持一或多个扩展。
所有兼容RFC 6455的WebSocket服务器都使用相同的算法计算Sec-WebSocket-Accept将Sec-WebSocket-Key内容与标准定义的唯一GUID字符串拼接起来计算出SHA1散列值结果是一个base64编码字符串把这个字符串发给客户端即可。
一个成功的WebSocket握手必须是客户端发送协议版本和自动生成的Sec-WebSocket-Key服务器返回101HTTP响应码Switching Protocols和散列形式的Sec-WebSocket-Accept确认选择的协议版本
客户端必须发送Sec-WebSocket-Version和Sec-WebSocket-Key服务器必须返回Sec-WebSocket-Accept确认协议客户端可以通过Sec-WebSocket-Protocol发送应用子协议列表服务器必须选择一个子协议并通过Sec-WebSocket-Protocol返回协议名如果服务器不支持任何一个协议连接断开。客户端可以通过Sec-WebSocket-Extensions发送协议扩展服务器可以通过Sec-WebSocket-Extensions确认一或多个扩展如果服务器没有返回扩展则连接不支持扩展。
如果HTTP中间设备不理解WebSocket协议则可能导致各种问题盲目的连接升级、意外缓冲WebSocket帧、不明就里地修改内容、把WebSocket流量误当作不完整的HTTP通信。
解决方法在执行HTTP Upgrade握手之前先协商一次TLS会话使用WSS建立一条端到端的安全通道。
使用场景及性能
WebSocket不能取代XHR或SSE。
请求和响应流
WebSocket是唯一一个能通过同一个TCP连接实现双向通信的机制客户端和服务器随时可以交换数据。WebSocket在两个方向上都能保证文本和二进制应用数据的低延迟交付。 解读
XHR是专门为“事务型”请求/响应通信而优化的客户端向服务器发送完整的、格式良好的HTTP请求服务器返回完整的响应。这里不支持请求流在Streams API可用之前没有可靠的跨浏览器响应流APISSE可以实现服务器到客户端的高效、低延迟的文本数据流客户端发起SSE连接服务器使用事件源协议将更新流式发送给客户端。客户端在初次握手后不能向服务器发送任何数据。
把传输机制从XHR切换为SSE或WebSocket并不会减少客户端与服务器间的往返次数不管什么传输机制数据包的传播延迟都一样。
排队延迟消息在被发送给另一端之前必须在客户端或服务器上等待的时间。
XHR轮询排队延迟就是客户端轮询间隔服务器上的消息可用之后必须等到下一次客户端XHR请求才能发送
SSE和WebSocket使用持久连接服务器和客户端如果是WebSocket就可在消息可用时立即发送它。
消息开销
建立WebSocket连接后应用消息会被拆分为一或多个帧每个帧会添加2~14字节开销。分帧按照自定义二进制格式完成UTF-8和二进制应用数据可有效地通过相同的机制编码。不包括IP、TCP和TLS分帧开销无论使用什么协议TLS一共会给每个消息增加60~100字节。
对比
SSE会给每个消息添加5字节但仅限于UTF-8内容HTTP 1.x包括XHR及其他常规请求会携带500~800字节的HTTP元数据加上cookieHTTP 2.0可压缩HTTP元数据。如果请求都不修改首部开销可低至8字节。
数据效率及压缩
XHR请求可协商最优的传输编码格式如对文本数据采用gzip压缩。SSE局限于UTF-8文本数据事件流数据可在整个会话期间使用gzip压缩。
WebSocket可传输文本和二进制数据不同类型的数据得分开压缩二进制的净荷也可能已压缩过。因此WebSocket必须实现自己的压缩机制并针对不同的消息类型选择不同的压缩机制。
HyBi工作组正在为WebSocket协议制定以消息为单位的压缩扩展。
Chrome和某些WebKit浏览器支持WebSocket协议压缩扩展的老版本以帧为单位压缩。
自定义应用协议
部署WebSocket基础设施
三个方面
位于各自网络中的路由器、负载均衡器和代理外部网络中透明、确定的代理服务器如ISP和运营商的代理客户网络中的路由器、防火墙和代理。
性能检查表
部署高性能的WebSocket服务要求细致地调优和考量无论在客户端还是在服务器上。可参考下列要点
使用安全WebSocket基于TLS的WSS实现可靠的部署密切关注腻子脚本的性能如果使用腻子脚本利用子协议协商确定应用协议优化二进制净荷以最小化传输数据考虑压缩UTF-8内容以最小化传输数据设置正确的二进制类型以接收二进制净荷监控客户端缓冲数据的量切分应用消息以避免队首阻塞合用的情况下利用其他传输机制。
在移动端使用WebSocket时要注意以下问题
节约用电消除周期性及无效的数据传输内格尔及有效的服务器推送消除不必要的长连接。
