【问题标题】:Transfer-Encoding: chunked传输编码:分块
【发布时间】:2023-03-16 04:51:01
【问题描述】:

我试图在Transfer-Encoding:chunked 上了解更多信息。参考了一些文章: http://zoompf.com/blog/2012/05/too-chunky"Transfer-Encoding: chunked" header in PHP

我仍然没有得到非常清晰的图像。我了解设置此编码允许服务器将内容设置为浏览器的块,并导致一次部分呈现内容,使网站响应。

如果我有一个在 IBM WAS 上托管的提供动态内容的 Web 应用程序(例如:基于 JSF 的 Web 应用程序),那么大多数网页都旨在为包含大量 CSS 和 JS 文件 + 动态内容的丰富静态内容提供服务器。如何为我的页面设置传输编码“分块”?或者换句话说:

  • 您如何决定哪个页面将具有'Transfer-Encoding: chunked' 以及如何为该页面设置它?

你的亲身经历对我的理解肯定很有价值。

【问题讨论】:

    标签: http tomcat http-headers websphere transfer-encoding


    【解决方案1】:

    Transfer-Encoding: chunked 不需要渐进式渲染。但是,在第一个字节发送前总内容长度未知时需要。

    【讨论】:

    • 您能否以编程方式为您的网页启用此功能?
    • 这取决于您的网络服务器。通常,当您开始发送数据而不知道长度时会自动使用它。
    【解决方案2】:

    当服务器需要发送大量数据时,服务器会使用分块编码,因为它并不确切知道数据将有多大(长度)。在 HTTP 术语中,当服务器发送响应时,服务器会省略 Content-Length 标头。相反,服务器以十六进制格式写入当前块的长度,然后是 \r\n,然后是块,然后是 \r\n(内容以十六进制的块大小开头,然后是块)

    此功能可用于渐进式渲染;但是服务器需要尽可能多地刷新数据,以便客户端可以逐步呈现内容(在 html、css 等情况下)

    当服务器向客户端大量推送数据时,通常会使用此功能 - 通常是大尺寸(mega/giga)

    Mozilla Documentation

    【讨论】:

    • "通常以千兆为单位" - 如果有的话,应该是兆的。 ;) 但它甚至不一定与大小有关:它与 时间 一样多,因此客户端可以继续接收部分,甚至在知道整个响应的确切大小之前。
    • @webjockey,我想知道客户端是否需要分块向服务器发送数据。似乎分块仅由服务器实现。
    • Web 浏览器内置了 tools.ietf.org/html/rfc7230#section-3.3.1 中指定的分块解码算法。我不知道网络服务器是否实现了这种算法。或者,您可以将 mutipart/form-data 与自定义边界标头名称一起使用,但您必须自己实现如何保存以自定义边界标头名称分隔的块中接收的大文件
    猜你喜欢
    • 1970-01-01
    • 2012-11-02
    • 2013-02-13
    • 2012-02-18
    • 2012-01-26
    • 2014-11-08
    • 2011-03-14
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多