Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

关于流加载的块传输问题

  HTTP 提供了两种传输模式,一种是使用 Content-Length 直接告诉客户端有多少数据需要传。另一种则是使用 Transfer-Encoding: chunked,将数组分块,每一块单独维护自己的长度,传输过程中客户端无法知道数据总长度,直到收到一个空块时视为结束。
  Chunked 通常用户服务器异步地动态生成数据(服务器自己也不知道最终会生成多少数据,先把生成的数据传给客户端),而如果服务器可以确定数据长度的话就可以使用 Content-Length,这可以避免每个数据库都带自己的长度信息所造成的额外开销。
  仅此而已吗?也许说到这儿会有人不服吧。Chunked 将数据分成多个块输出,客户端可以分别处理每个块?这是一个误区。其实无论是 Content-Length 还是 Chunked,从更底层的角度看,数据都是一份份地传输。Chunked 只是 HTTP 这个层面上的分块而已。无论何种传输方式,客户端都总是可以获取到传输进度,甚至可以部分解析已经传输的内容。
  当然,「部分解析已经传输的内容」还需要考虑 GZIP。GZIP 也是将数据以一个个包的形式压缩,只有加载一个完整的 GZIP 包后才能解压得到数据。然而通常 GZIP 的 buffer 不会设置太大,所以对「部分解析已经传输的内容」也不会有太大影响。
  影响整个流加载的应该是更底层(甚至和 MTU 有关)的设置,或者是 fastcgi 与 HTTP 服务器之类的 buffer 设置之类的,GZIP 和 Chunked 应该不是问题所在。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^