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