Як оптимізувати час завантаження початкового з'єднання та фазу рукостискання SSL веб-сторінки в мережі 3G?


11

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

Статистика завантаження сторінки

Вид даних, що обробляються на сторінці: Тестована веб-сторінка отримує 5 даних JSON в парі з ключовими значеннями через AJAX та відображає їх на веб-сторінці. Це дуже легка сторінка з лише 5-6 текстовим вмістом.

Я бачив, як багато веб-сайтів швидше завантажуються в мобільній мережі 3G (режим H). Мій веб-сайт занадто повільний під час початкової фази встановлення з'єднання в мережі 3G. Чи може мені хтось допомогти, як вирішити / оптимізувати затримку на початковій фазі з'єднання? Чи вирішить цю проблему перехід на спеціальний хостинг?

Веб-сервер не зайнятий і завжди є багато процесора та пам'яті.

Конфігурація сервера: Екземпляр Amazon EC2 - Спільний хостинг (32 процесора та 60 ГБ оперативної пам’яті). Веб-сервер - Apache. SSL - Symantec.


Ви пробували використовувати пружний балансир навантаження та справляєте його з HTTPS? Це те, що я використовую в Amazon, і я не бачив подібних проблем з продуктивністю. Знову ж таки, я ніколи спеціально не перевіряв 3G-з'єднання.
Стівен Остерміллер

Дякую. Сервер не збалансований. Знову перевіримо сервер на певні параметри і спробуємо його.
User234334

Відповіді:


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 - файл!
  • Скористайтеся мережею доставки вмісту , вона вивантажує запити сервера та завдання стиснення.
  • Використовуйте кеш лаку, щоб зменшити навантаження на базу даних за допомогою кешування сторінок
  • Визначте свої статичні файли на жорсткому диску за допомогою HDParm
  • Визначте свій сервер за допомогою інструмента бенчмаркінгу сервера Apache HTTP
  • Визначте веб-сайт із 10 пропусками з кількома віддаленими місцями за допомогою WebPageTest

Дякую за детальне пояснення. Знову перевіримо сервер на запропоновані параметри і реалізуємо найкраще!
User234334

Графік запитання відокремлює рукостискання 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-сторінками для тестування, а потім перемістіть ваш основний сайт (масштабування за межами вільних рівнів, якщо потрібно).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.