Как я могу установить для Transfer-Encoding явное или неявное разделение на части в ответе ASP.NET?
Могу ли я просто установить Transfer-Encoding заголовок?
Будет звонить Response.Flush() в какой-то момент вызвать это неявно?
РЕДАКТИРОВАТЬ
Нет не могу позвонить Response.Headers.Add("Transfer-Encoding","anything"); Это бросает.
какие-либо другие предложения?
Связанные с:
Включить Chunked Transfer Encoding в ASP.NET
4 ответа
TL;DR: указание длины контента - лучший способ получить быстрый первый байт; вы разрешите чанкинг на уровне TCP, а не на уровне HTTP. Если вы не знаете длину контента, настройка context.Response.BufferOutput в false будет отправлять выходные данные в том виде, в котором они записаны, в выходной поток с использованием chunked Transfer-Encoding.
Почему вы хотите установить Transfer-Encoding: chunked? Чанкованные переводы - это, по сути, обходной путь, позволяющий отправлять документы, длина содержимого которых заранее неизвестна. Однако ASP.NET по умолчанию буферизирует весь вывод и, следовательно , знает общую длину содержимого.
Конечно, HTTP является многоуровневым по TCP, и за кулисами TCP все равно "разбивает" на части, разбивая даже монолитный HTTP-ответ на пакеты - это означает, что если вы укажете длину содержимого заранее и отключите буферизацию вывода, вы получите лучшая задержка без необходимости разбиения по уровням HTTP. Таким образом, вам не нужно разбиение на уровни HTTP, чтобы обеспечить быстрый первый байт, когда вы знаете длину содержимого.
Хотя я не эксперт по HTTP, я реализовал простой сервер потокового мультимедиа с поддержкой, динамическим сжатием, кэшированием и т. Д., И у меня есть разумное представление о релевантности быстрого первого байта - и разбиение на блоки обычно уступает Опция, если вы знаете длину содержимого - именно поэтому ASP.NET не позволит вам установить его вручную - это просто не нужно.
Однако, если вы не знаете длину содержимого HTTP до того, как передача и буферизация станут слишком дорогими, вы отключите буферизацию вывода и, по-видимому, сервер по необходимости будет использовать кодирование передачи по частям.
Когда сервер использует кодирование передачи по частям? Я только что проверил, и действительно, если context.Response.BufferOutput установлен в falseи когда длина содержимого не установлена, ответ разбивается на части; такой отклик на 1-2% больше в моем совершенно ненаучном быстром тесте с кодировкой содержимого 1,7 Мб: gzip xml document. Поскольку gzip полагается на контекст для уменьшения избыточности, я ожидал, что степень сжатия пострадает больше, но кажется, что разбиение на фрагменты не обязательно сильно снижает коэффициенты сжатия.
Если вы посмотрите на код платформы в отражателе, то кажется, что кодировка передачи действительно устанавливается автоматически по мере необходимости - то есть, если буферизация отключена, а длина содержимого не известна, а ответ на запрос HTTP/1.1, используется кодирование передачи по частям., Однако, если сервером является IIS7 и это рабочий запрос ("интегрированный режим"), код переходит к собственному методу - возможно, с таким же поведением, но я не могу это проверить.
Похоже, вам нужно настроить IIS для этого. IIS 6 имеет свойство AspEnableChunkedEncoding в метабазе, и вы можете увидеть сопоставления IIS 7 для этого на MSDN по адресу http://msdn.microsoft.com/en-us/library/aa965021(VS.90).aspx. Это позволит вам установить TRANSFER-ENCODING: chunked в вашем заголовке. Надеюсь, это поможет.
Несмотря на то, что для параметра Buffer задано значение false и оставлено пустым длина содержимого, необходимо убедиться, что вы отключили функцию "Динамическое сжатие содержимого" для IIS7, чтобы обеспечить работу фрагментированного ответа. Кроме того, браузер клиента должен иметь как минимум HTTP 1.1 . Chunked режим не будет работать для HTTP 1.0
Response.Buffer = False
Это установит заголовок HTTP "Tranfer-Encoding:Chuckeg" и отправит ответ каждый обзвоненный response.write