我可以简单地设置Transfer-Encoding标题吗？
在某个时候调用Response.Flush()会导致这种情况隐式发生吗？
编辑
不，我不能称之为Response.Headers.Add("Transfer-Encoding","anything"); 抛出。
还有其他建议吗？
问问题
39321 次
4 回答
23
TL;DR：指定内容长度是实现快速首字节的最佳方式；您将允许在 TCP 而不是 HTTP 级别进行分块。如果您不知道内容长度，设置context.Response.BufferOutput为false将在使用分块传输编码写入输出流时发送输出。
为什么要设置Transfer-Encoding: chunked？分块传输本质上是一种解决方法，允许发送内容长度事先不知道的文档。然而，ASP.NET 默认缓冲整个输出，因此知道整体内容长度。
当然，HTTP 是在 TCP 之上分层的，并且在幕后 TCP 无论如何都会通过将单个 HTTP 响应拆分为数据包来“分块”——这意味着如果您预先指定内容长度并禁用输出缓冲，您将获得无需HTTP 级分块的 最佳延迟。因此，当您知道内容长度时，您不需要 HTTP 级别的分块来提供快速的第一个字节。
虽然我不是 HTTP 方面的专家，但我已经实现了一个简单的流媒体服务器，它具有寻求支持、动态压缩、缓存等功能，并且我确实对快速首字节的相关性有合理的把握——而分块通常是次要的如果您知道内容长度的选项- 这几乎肯定是 ASP.NET 不允许您手动设置它的原因 - 它只是没有必要。
但是，如果您在传输和缓冲太昂贵之前不知道 HTTP 内容长度，则关闭输出缓冲，并且推测服务器将根据需要使用分块传输编码。
服务器何时使用分块传输编码？我刚刚测试过，确实 ifcontext.Response.BufferOutput设置为false，并且当没有设置内容长度时，响应被分块；在我对 1.7MB 内容编码：gzip xml 文档的完全非科学快速测试中，这样的响应要大 1-2%。由于 gzip 依赖于上下文来减少冗余，我预计压缩率会受到更多影响，但似乎分块并不一定会大大降低压缩率。
如果您查看反射器中的框架代码，似乎传输编码确实是根据需要自动设置的 - 即如果缓冲关闭并且不知道内容长度并且响应是对 HTTP/1.1 请求的响应，则使用分块传输编码. 但是，如果服务器是 IIS7 并且这是一个工作请求（？集成模式？），代码会分支到本机方法 - 可能具有相同的行为，但我无法验证这一点。
于 2010-04-26T06:11:57.443 回答
0
看起来您需要为此设置 IIS。IIS 6 在元数据库中有一个属性 AspEnableChunkedEncoding，您可以在 MSDN 上的http://msdn.microsoft.com/en-us/library/aa965021(VS.90).aspx上看到 IIS 7 映射。这将使您能够在标题中设置 TRANSFER-ENCODING: 分块。我希望这有帮助。
于 2010-04-21T09:56:01.180 回答
0
尽管您将 Buffer 设置为 false 并将内容长度留空，但您需要确保已禁用 IIS7 的“动态内容压缩”功能以使分块响应正常工作。此外，客户端浏览器应至少具有 HTTP 1.1 .. 分块模式不适用于 HTTP 1.0
于 2011-12-02T00:43:49.500 回答
0
Response.Buffer = False
这将设置 HTTP 标头“Transfer-Encoding:Chuncked”并发送每个调用的响应 response.write
于 2016-06-21T20:25:15.860 回答