performance - length作用 - transfer encoding chunked例子



内容长度标头与分块编码 (2)

如果内容的长度是事先知道的,那么我肯定会喜欢上面的分块。 如果在本地磁盘文件系统或数据库中有静态文件的含义,那么任何自我推荐的编程语言和RDBMS都提供了事先获得内容长度的方法。 你应该利用它。

另一方面,如果内容长度事实上是不可预知的(例如当你的意图是将多个文件压缩在一起并将其作为一个文件发送),那么以块的形式发送可能比在服务器的内存中缓冲或写入本地磁盘文件系统。 但这确实会对用户体验造成负面影响,因为下载进度是未知的。 不耐烦的人可能会放弃下载并继续前进。

事先知道内容长度的另一个好处是能够恢复下载。 我在你的发布历史中看到你的主要编程语言是Java; 你可以在这里找到一篇文章,其中有更多的技术背景信息和一个Java Servlet的例子。

我试图衡量设置Content-Length HTTP标头与使用分块编码从我的服务器返回[可能]大文件的优点和缺点。 其中一个或另一个需要使用持久连接符合HTTP 1.1规范。 我看到Content-Length头的优点是:

  • 下载对话框可以显示准确的进度条
  • 客户知道,如果文件可能/可能不会太大,他们摄取

缺点是必须在返回对象之前计算大小,这并不总是实用的,并且可能会增加服务器/数据库的利用率。 分块编码的缺点是在每个块和下载进度条之前添加块大小的小开销。 有什么想法吗? 对于这两种方法,我可能没有想到的任何其他HTTP考虑因素?


Answer #1

毫无疑问地使用Content-Length。 从这个服务器的利用率将几乎不存在,对您的用户的好处将是巨大的。

对于动态内容,添加压缩响应支持( gzip )也非常简单。 这需要输出缓冲,这反过来给你的内容的长度。 (不适用于文件下载或已经压缩的内容(声音,图像))。

考虑添加对部分内容 /字节范围服务的支持 - 即重新启动下载的能力。 在这里看到一个字节范围的例子 (这个例子是在PHP中,但适用于任何语言)。 提供部分内容时,您需要Content-Length。

当然,这些不是银弹:对于流媒体来说,使用输出缓冲或响应大小是毫无意义的; 对于大文件,输出缓冲没有意义,但内容长度和字节服务很有意义(重新启动失败的下载是可能的)。

就我个人而言,只要我知道它,我就会服务于Content-Length。 对于文件下载,检查文件大小在资源方面是微不足道的。 结果:用户有一个确定的进度条(由于gzip,动态页面下载速度更快)。





content-length