Как оптимизировать время загрузки начального соединения и фазы SSL-рукопожатия веб-страницы в сети 3G?

11

Мой веб-сайт www.example.com (с поддержкой SSL) размещен на хостинге Amazon EC2. Он загружается быстрее (время загрузки <2 секунд) по Wi-Fi / широкополосному соединению. Проблема в сети 3G в мобильном телефоне ** (режим H, а не режим H +) **. Инициируйте фазу соединения, и процесс рукопожатия SSL займет много времени - 12 секунд. Отслеживал параметры синхронизации через вкладку Chrome Network. Ниже приводится измеренное время загрузки веб-страницы.

Статистика загрузки сети

Вид данных, обрабатываемых на странице: протестированная веб-страница получает 5 парных данных JSON с ключом-значением через AJAX и отображает их на веб-странице. Это очень легкая страница с 5-6 текстовым содержанием.

Я видел, как многие сайты загружаются быстрее в мобильной сети 3G (режим H). Мой веб-сайт работает слишком медленно на начальном этапе установления соединения в сети 3G. Может кто-нибудь помочь мне, как решить / оптимизировать задержку на начальном этапе подключения? Решит ли переход на выделенный хостинг существующую проблему?

Веб-сервер не занят, и всегда доступно много ресурсов процессора и памяти.

Конфигурация сервера: Amazon EC2 Instance - Общий хостинг (32 ЦП и 60 ГБ ОЗУ). Веб-сервер - Apache. SSL - Symantec.

User234334
источник
Вы пытались использовать упругий балансировщик нагрузки и иметь его обрабатывать HTTPS? Это то, что я использую в Amazon, и я не видел таких проблем с производительностью. Опять же, я никогда специально не проверял соединение 3G.
Стивен Остермиллер
Спасибо. Сервер не сбалансирован по нагрузке. Снова протестируем сервер по определенным параметрам и попробуем.
Пользователь234334

Ответы:

8

Начальное соединение

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

Google Chrome: понимание сроков ресурсов

Время, необходимое для установления соединения, включая TCP-рукопожатия / повторные попытки и согласование SSL.

SSL рукопожатие и TTFB

У вас есть две основные проблемы: время, потраченное на завершение рукопожатия SSL, и серверы, ожидающие TTFB (время до первого байта).

  • TTFB: 4079 мс (должно быть меньше 1000 мс)
  • SSL рукопожатие 11830 мс (должно быть меньше 100 мс)

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

Шаг 1: Исследование проблемы SSL

Совершенно очевидно, что у вас серьезная проблема с SSL и, скорее всего, из-за неправильной установки OpenSSL или аналогичной. Начните с тестирования вашего SSL-сертификата с использованием SSL Labs, а затем исправьте любые проблемы или предупреждения, которые он предлагает.

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

Балансировщики нагрузки могут помочь, если это проблема с ресурсом сервера.

Шаг 2: Исследование TTFB

После того, как вы исследовали, решили проблему SSL и у вас все еще есть увеличенный TTFB, тогда вы должны протестировать свой сервер, убедившись, что на нем достаточно ресурсов.

Время первого байта зависит, но не ограничивается:

  • Расстояние от пользователя до дата-центра, на котором размещен сервер, может увеличить TTFB
  • Некэшированный GZIP может увеличить TTFB
  • Перегруженные сети могут увеличить TTFB
  • Перегруженные серверы могут увеличить TTFB

Иногда увеличение ЦП и ОЗУ не всегда лучший вариант. Иногда лучше ввести балансировщик нагрузки, потому что это не только означает, что вы можете легко запускать несколько серверов одновременно, но и фактически разгружает кеширование и запросы SSL. Некоторые другие преимущества включают в себя:

ИСТОЧНИК

  • Кэширование: устройство может хранить содержимое, которое не изменяется (например, изображения), и предоставлять его напрямую клиенту без отправки трафика на веб-сервер.
  • Сжатие: уменьшает объем трафика для объектов HTTP путем сжатия файлов перед их отправкой.
  • Разгрузка SSL: обработка трафика SSL требует нагрузки на ЦП веб-сервера, поэтому балансировщик нагрузки может выполнить эту обработку вместо этого.
  • Высокая доступность: в случае отказа одного можно использовать два устройства балансировки нагрузки.

Советы по снижению вашего TTFB:

  • Убедитесь, что ваша база данных находится в той же сети или в качественном облаке SQL .
  • Убедитесь , что ваша база данных считываются из памяти и НИКОГДА SWAP - файл!
  • Используйте сеть доставки контента , она разгружает запросы сервера и задачи сжатия.
  • Используйте Varnish Cache для уменьшения нагрузки на базу данных путем кэширования страниц.
  • Оценивайте свои статические файлы на жестком диске с помощью HDParm
  • Оцените ваш сервер с помощью инструмента тестирования Apache HTTP-сервера
  • Оцените веб-сайт с 10 проходами с несколькими удаленными местоположениями, используя WebPageTest
Саймон Хейтер
источник
Спасибо за ваше подробное объяснение. Снова протестируем сервер по предложенным параметрам и реализуем лучшее!
Пользователь234334
График вопроса отделяет рукопожатие SSL от первоначального запроса и TTFB. Согласно этому графику, проблема на самом деле связана с SSL перед выполнением запроса.
Стивен Остермиллер
@StephenOstermiller замечен. Время ожидания TTFB составляет 4000 мс, а SSL превышает 11000 мс. Вероятно, SSL влияет на TTFB. Я обновил вопрос, чтобы отразить это.
Саймон Хейтер
Спасибо! Я проверил свой SSL на www.ssllabs.com, и рейтинг был "A". Никаких предупреждений / проблем не поступало. Я обнаружил, что версия Apache 2.2.15 устарела. Нужно обновить его сейчас. Содержимое моего сайта (размер в ТБ) находится в / var / www / html /. Будет ли обновление / переустановка Apache удалять содержимое моего сайта? Любой безопасный способ обновления без потери данных?
User234334
Еще один момент - OpenSSL также последней версии.
User234334
6

Читая заголовок вашего вопроса , вы можете сделать две вещи, чтобы ускорить начальное соединение и SSL / TLS рукопожатие. Они работают для любого соединения, а не только для 3G, поэтому вы все равно должны использовать их в качестве передового опыта.

Во-первых, используйте HTTP / 2 для обслуживания сайта. Для этого требуется Apache 2.4.17 или более поздняя версия .

Во-вторых, настройте Apache для использования сшивания OCSP. Для этого требуется Apache 2.3.3 или более поздней версии плюс OpenSSL 0.9.8h или более поздней версии с хорошим руководством по настройке здесь . Сшивание OCSP не ускорит процесс, но сделает часть работы для клиента и избавит его от попыток поиска OCSP.

Читая основной текст вашего вопроса , я думаю, что у вас гораздо больше проблем со средой хостинга. Эти времена загрузки недопустимы. Вы упоминаете, что это «виртуальный хостинг», вам следует связаться с тем, кто управляет этим виртуальным хостингом, и спросить, почему их сервер работает так необычно медленно. Возможно, вам лучше попробовать другой общий хост или запустить VPS самостоятельно (это больше работы, но дает лучшую скорость и гибкость).

Поскольку вы уже пользуетесь услугами AWS, почему бы не попробовать их бесплатную версию, чтобы протестировать и настроить и оптимизировать собственный сервер? Используйте его с поддоменом и некоторыми статическими HTML-страницами для тестирования, а затем переместите ваш основной сайт (при необходимости увеличьте пределы свободного уровня).

Том Броссман
источник