Почему HTTP/2 медленнее обычного HTTPS?

Question

Я оценки того, что я могу получить для моего веб-сайта от http2 с точки зрения производительности и получить странный результат - сайт в Европе загружается из США:

• с HTTP/2 - через 6-7 секунд
• с простым HTTPS - через 5-6 секунд (примерно 1 секунду быстрее)

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

Для тестирования я использую мое веб-приложение, охватываемое Apache 2.4.17 (Win32) в качестве прокси (для применения поддержки протоколов HTTP/2 & HTTP/2). Клиентский браузер Chrome 46.0.2490.86 в Windows 7.

Ниже приведены сетевые запросы с захватом. Краткое описание: 1. Fist one - HTML-страница 2. Следующая группа - 6 запросов - ресурсы, объявленные непосредственно в HTML 3. Остальные ресурсы добавлены динамически через скрипт (теги «script» и «link/css» в документе /глава).

В левой части изображения находится HTTP/2, правая сторона - тот же персонал через простой SSL (http2_module выключен).

---

Update: Я проверил "кое-что еще", что поддерживает HTTP/2 в качестве обратного прокси-сервера. Это nginx 1.9.7.1 Kitty от http://nginx-win.ecsds.eu - вилка оригинального nginx 'для окон'. HTTP/2 в оригинальном nginx доступен только in commercial version, поэтому я не мог попробовать. И похоже, что нет никаких других реализаций сервера HTTP/2 + обратного прокси-сервера для окон, или я просто не мог найти их (список here и here).

Результат, который я получил с Китти, еще более вводит в заблуждение - в Apache нет «последовательной нагрузки» ресурсов, но скорость передачи данных в два раза медленнее по HTTP/2, чем по сравнению с обычным SSL. Конечный результат - HTTP/2 значительно медленнее обычного SSL. Ниже они все рядом.

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

Answer 1

Итак, наконец, мое решение - нет ничего плохого в HTTP себя/2, есть что-то не так с реализациями доступных в настоящее время.

• Apache HTTPD 2.4.17/Win32 - имеют некоторую странный эффект 'последовательная нагрузка'
• Nginx Kitty - обеспечивает причудливо медленная скорость передачи
• официальная бесплатная Nginx не http2 модуль построен в

но

• пользовательских -Встроенный Nginx для окон из kevinworthington.com
• Apache HTTPD 2.4.17/Linux

обе представление ожидаемый возможности. Вот скриншот для того же теста, выполненного в «вопросе», но с обратным прокси Apache, размещенным на компьютере Linux другого парня.

Answer 2

Посмотрите на это, это модифицированная версия Nginx, разработанной с Taobao.org, и используется AliExpress и много других занятых сайтов. Он поддерживает HTTP2 из коробки, а также некоторые другие функции, доступные только в коммерческом nginx, например, в прямом управлении.

http://tengine.taobao.org/

Answer 3

Мы бежим последний Nginx с HTTP/2

nginx version: nginx/1.9.10 
built with OpenSSL 1.0.2e 3 Dec 2015 
TLS SNI support enabled 

Мы сделали это наблюдение. Мы регистрируем $ request_time и $ upstream_time. В то время как upstream_time равно, независимо от протокола, общая request_time отличается:

# grep ' 443 ' access.log|grep 'HTTP/1.1'| cut -d ' ' -f 3,4 | awk '{r+=$1; u+=$2} END {print r/NR; print u/NR}' 
0.0116887 # HTTP/1.1 request_time in seconds 
0.00673473 # HTTP/1.1 upstream_time in seconds 

# grep ' 443 ' access.log|grep 'HTTP/2.0'| cut -d ' ' -f 3,4 | awk '{r+=$1; u+=$2} END {print r/NR; print u/NR}' 
0.0363673 # HTTP/2.0 request_time in seconds 
0.00695812 # HTTP/2.0 upstream_time in seconds 

Так общее время запроса HTTP/1.1 в три раза лучше! Возможно, что-то не работает с ведением журнала request_time и http/2 из-за потоков. Я действительно не знаю, но обещание заключалось в том, что http/2 быстрее, чем http/1.1, если обе работают на TLS.

Но я продолжу расследование этого.