Почему конвейерная обработка отключена в современных браузерах?

Многие, если не все современные браузеры не используют конвейерные HTTP-запросы. В теории конвейерная обработка должна ускорить запросы за счет сокращения количества циклов, необходимых для загрузки веб-сайта.

Согласно стандарту HTTP все серверы должны обрабатывать конвейерные запросы, поэтому проблема не должна заключаться в отсутствии поддержки на серверах.

Я видел некоторые проблемы безопасности, такие как DoS-атака уровня 7, если клиент отправляет как можно больше конвейерных запросов на URL-адрес, требующий высокой производительности сервера, игнорируя любые ответы, которые могут быть получены.

Это было бы причиной отключить поддержку конвейерной передачи на сервере (что нарушает стандарт), но я не могу найти никаких причин, чтобы отключить ее на клиентах.

Однако он по умолчанию включен в браузерах Android и мобильных устройствах Chrome.

Почему Chrome, Firefox, IE, Opera и Safari не используют конвейерные HTTP-запросы в настольной (а иногда и мобильной) версии? Каковы их причины отключения?

Источник

1 ответ

Решение

Конвейерная обработка отключена по следующим причинам:

  • Fire Fox:

Более серьезная проблема, откровенно говоря, связана с блокировкой линий и ее влиянием на производительность и надежность. Наивные конвейеры просто ухудшают производительность.

  • Хром:

Опция включения конвейерной обработки была удалена из Chrome, поскольку есть известные ошибки сбоя и известные проблемы блокировки в очереди. Существует также большое количество серверов и промежуточных окон, которые ведут себя плохо и непоследовательно, когда включена конвейерная обработка. Пока они не решены, рекомендуется, чтобы никто не использовал конвейерную обработку. В настоящее время для этого требуется пользовательская сборка Chromium.

В общем:

Багги-прокси по-прежнему широко распространены, и они приводят к странным и ошибочным поведениям, которые веб-разработчики не могут предвидеть и легко диагностировать.

Конвейерная обработка сложна для правильной реализации: размер передаваемого ресурса, эффективный RTT, который будет использоваться, а также эффективная пропускная способность, напрямую влияют на улучшение, обеспечиваемое конвейером. Не зная об этом, важные сообщения могут быть отложены за незначительными. Понятие важности даже развивается во время макета страницы! Поэтому конвейерная обработка HTTP приносит незначительное улучшение только в большинстве случаев.

Трубопроводы являются предметом проблемы HOL.

HTTP/2 предлагает альтернативу:

С HTTP/1.x браузер имеет ограниченную возможность использовать данные с более высоким приоритетом: протокол не поддерживает мультиплексирование, и нет способа передать приоритет запроса на сервер. Вместо этого он должен опираться на использование параллельных соединений, что обеспечивает ограниченный параллелизм до шести запросов на источник. В результате запросы помещаются в очередь на клиенте до тех пор, пока соединение не станет доступным, что добавляет ненужную задержку в сети. Теоретически, HTTP Pipelining пытался частично решить эту проблему, но на практике он не получил одобрения.

HTTP/2 устраняет эту неэффективность: исключается организация очереди запросов и блокировка заголовка строки, поскольку браузер может отправлять все запросы в момент их обнаружения, а браузер может передавать предпочтения приоритетов потока через зависимости и весовые коэффициенты потока, позволяя серверу дальнейшая оптимизация доставки ответов.

Также можно использовать прокси:

Вы можете попробовать кое-что, что я сделал, чтобы ускорить Konqueror в KDE3. Я был недоволен тем, что в Konqueror не было конвейерной передачи HTTP, поэтому после некоторых поисков я установил Polipo в качестве локального HTTP/HTTPS/FTP-прокси и настроил Konqueror на его использование (localhost на порту 8123, если я правильно помню). В дополнение к конвейерной передаче HTTP, Polipo также обеспечил улучшенное кэширование, и, поскольку это был прокси-сервер, я мог настроить каждый браузер на его использование, и кэширование было бы общим для браузеров. (Это также означает, что рекомендуется отключить независимое кэширование каждого браузера.)

Salesforce использует следующий процесс:

У Salesforce есть мощный и проверенный в полевых условиях подход для снижения HOLB на уровне TCP: мы отделяем связь между HTTP-запросом и TCP-соединением. Представьте, что ваш транспорт состоит из нескольких соединений TCP (столько, сколько потребуется для сетевого контекста). Любая часть HTTP-запроса может проходить через любое TCP-соединение. Поэтому, если вы нажмете на HOLB в одном соединении, это не только поможет смягчить затронутые запросы, но также минимизирует влияние на другие запросы приложений, использующие исправные соединения. Результатом является возможность пользоваться преимуществами мультиплексирования и конвейеризации на уровне HTTP при минимизации рисков HOLB.

Рекомендации

Источник

Принятый ответ может быть несколько устаревшим. Сегодня я видел 10 запросов chrome desktop pipeline в одном HTTPS-соединении к нашему серверу, который предоставил мне количество конвейеров.

Источник
Другие вопросы по тегам