Как я могу установить Кодирование Передачи на разделенный на блоки, явно или неявно, в ответе ASP.NET?
Я могу просто установить Transfer-Encoding заголовок?
Будет вызов Response.Flush() в какой-то момент заставьте это происходить неявно?
Править
Нет, я не Могу звонить Response.Headers.Add("Transfer-Encoding","anything"); Это бросает.
какие-либо другие предложения?
Похожие страницы:
Включите разделенное на блоки кодирование передачи в ASP.NET
2 ответа
TL; DR: Указание длины содержимого - лучший способ получить быстрый первый байт; вы разрешите фрагменты на уровне TCP, а не HTTP. Если вы не знаете длину содержимого, установка context.Response.BufferOutput на false отправит вывод, как он записан, выходной поток с использованием кодирования передачи по фрагментам.
Почему вы хотите установить Кодировка передачи: фрагментированная ? Передача по частям - это, по сути, обходной путь, позволяющий отправлять документы, длина содержимого которых заранее не известна. Однако ASP.NET по умолчанию буферизует весь вывод и, следовательно, знает общую длину содержимого.
Конечно, HTTP накладывается на TCP, и за кулисами TCP в любом случае «разбивает» на части, разбивая даже монолитный HTTP-ответ на пакеты - это означает, что если вы заранее укажете длину содержимого и отключите буферизацию вывода, вы: Я получу максимальную задержку без , требующего фрагментации на уровне HTTP. Таким образом, вам не нужно фрагментировать HTTP-уровень для обеспечения быстрого первого байта, когда вы знаете длину содержимого.
Хотя я не являюсь экспертом по HTTP, я реализовал простой сервер потокового мультимедиа с поиском поддержки, динамическим сжатием, кешированием и т. Д., И у меня есть разумное представление о важности быстрого первого байта, а разбиение на части - это как правило, худший вариант , если вам известна длина содержимого - что почти наверняка является причиной того, что ASP.NET не позволяет вам устанавливать ее вручную - в этом нет необходимости.
Однако, если вы не знаете длину содержимого HTTP до того, как передача будет слишком затратной, а буферизация будет слишком затратной, вы отключите буферизацию вывода, и, предположительно, сервер при необходимости будет использовать кодирование передачи по частям.
Когда сервер использует кодирование передачи по частям? Я только что проверил, и действительно, если для context.Response.BufferOutput установлено значение false , и когда длина содержимого равна не задано, ответ разбивается на части; такой ответ на 1-2% больше в моем полностью ненаучном быстром тесте XML-документа Content-Encoding: gzip размером 1,7 МБ. Поскольку для уменьшения избыточности 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: фрагменты в заголовке. Надеюсь, это поможет.