asp.net - 如何在 ASP.NET 响应中将传输编码显式或隐式设置为分块？

Question

我可以简单地设置 Transfer-Encoding header 吗？

在某个时候调用 Response.Flush() 会导致这种情况隐式发生吗？

---

编辑
不，我无法调用 Response.Headers.Add("Transfer-Encoding","anything"); 抛出。

还有其他建议吗？

---

Related:
Enable Chunked Transfer Encoding in ASP.NET

Answer 1

TL;DR: 指定内容长度是实现快速第一个字节的最佳方式；您将允许在 TCP 而不是 HTTP 级别进行分块。如果您不知道内容长度，将 context.Response.BufferOutput 设置为 false 将发送输出，因为它使用分块传输编码写入输出流。

---

为什么要设置Transfer-Encoding: chunked？分块传输本质上是一种变通方法，允许发送内容长度事先未知的文档。然而，ASP.NET 默认情况下缓冲整个输出，因此确实知道整体内容长度。

当然，HTTP 是在 TCP 之上分层的，并且在幕后 TCP 通过将甚至是单一的 HTTP 响应拆分成数据包来“分块”——这意味着如果你预先指定内容长度并禁用输出缓冲，你将获得最佳延迟而不需要 HTTP 级分块。 因此，当您知道内容长度时，您不需要 HTTP 级别的分块来提供快速的第一个字节。

虽然我不是 HTTP 方面的专家，但我已经实现了一个简单的流媒体服务器，包括寻求支持、动态压缩、缓存等，而且我对快速首字节的相关性有合理的把握——分块是如果您知道内容长度， 通常是一个较差的选项 - 这几乎可以肯定是 ASP.NET 不允许您手动设置它的原因 - 它只是没有必要。

但是，如果您不知道在传输和缓冲之前的 HTTP 内容长度太昂贵，您可以关闭输出缓冲，并且服务器可能会根据需要使用分块传输编码。

服务器什么时候使用分块传输编码？ 我刚刚测试过，确实如果 context.Response.BufferOutput 设置为 false，当没有设置内容长度时，响应分块；在我对 1.7MB 内容编码的完全非科学的快速测试中，这样的响应大 1-2%:gzip xml 文档。由于 gzip 依赖上下文来减少冗余，我预计压缩率会受到更大影响，但似乎分块不一定会大大降低压缩率。

如果您查看反射器中的框架代码，似乎传输编码确实是根据需要自动设置的——即如果缓冲关闭并且不知道内容长度并且响应是对 HTTP/1.1 请求的响应，则分块传输使用编码。但是，如果服务器是 IIS7 并且这是一个工作请求(？集成模式？)，代码将分支到本地方法 - 可能具有相同的行为，但我无法验证这一点。