Bagaimana cara mengoptimalkan waktu buka koneksi awal dan fase handshake SSL dari suatu halaman web pada jaringan 3G?


11

Situs web saya www.example.com (diaktifkan SSL) dihosting di hosting bersama Amazon EC2. Ini memuat lebih cepat (waktu muat <2 detik) pada koneksi wifi / broadband. Masalahnya adalah pada jaringan 3G di ponsel ** (mode H dan bukan mode H +) **. Memulai fase koneksi dan proses jabat tangan SSL membutuhkan banyak waktu - 12 detik. Memantau parameter waktu melalui tab Jaringan Chrome. Di bawah ini adalah waktu pengambilan yang diukur untuk halaman web.

Halaman memuat Statistik Waktu Jaringan

Jenis data yang ditangani pada halaman: Halaman web yang diuji menerima 5 data kunci JSON yang dipasangkan melalui AJAX dan menampilkannya di halaman web. Ini adalah halaman yang sangat ringan dengan hanya 5-6 konten teks.

Saya telah melihat banyak situs web memuat lebih cepat pada jaringan seluler 3G (mode H). Situs web saya terlalu lambat selama tahap pembuatan koneksi awal pada jaringan 3G. Dapatkah seseorang tolong bantu saya tentang cara menyelesaikan / mengoptimalkan keterlambatan pada tahap koneksi awal? Akankah pindah ke hosting khusus menyelesaikan masalah saat ini?

Server Web tidak sibuk dan ada banyak CPU DAN memori tersedia selalu.

Konfigurasi Server: Instance Amazon EC2 - Hosting bersama (32 CPU dan 60 GB RAM). Server Web - Apache. SSL - Symantec.


Sudahkah Anda mencoba menggunakan penyeimbang beban elastis dan membuatnya menangani HTTPS? Itulah yang saya gunakan di Amazon, dan saya belum melihat masalah kinerja seperti ini. Kemudian lagi, saya tidak pernah secara khusus menguji koneksi 3G.
Stephen Ostermiller

Terima kasih. Server tidak memuat seimbang. Akan menguji server pada parameter tertentu lagi dan akan mencobanya.
User234334

Jawaban:


8

Koneksi Awal

Anda akan menemukan bahwa koneksi awal termasuk menegosiasikan SSL, jadi karena handshake tinggi, itu indikator yang baik bahwa ada sesuatu yang salah dengan cara Anda mengatur SSL.

Google Chrome: Memahami Pengaturan Sumber Daya

Waktu yang diperlukan untuk membuat koneksi, termasuk jabat tangan / mencoba kembali dan menegosiasikan SSL.

SSL Handshake dan TTFB

Anda memiliki dua masalah utama, Waktu yang dihabiskan untuk menyelesaikan jabat tangan SSL dan server menunggu TTFB (waktu hingga byte pertama).

  • TTFB: 4079ms (harus kurang dari 1000ms)
  • Jabat tangan SSL 11830 ms (harus kurang dari 100 ms)

Perlu juga dicatat bahwa ketika pengujian dengan perangkat 3G / 4G dapat menyebabkan byte pertama lebih lama karena fakta bahwa sinyal telepon berbeda dalam kekuatan ... ini dapat menyebabkan masalah koneksi intermiten dan waktu latensi yang bervariasi.

Langkah 1: Investigasi masalah SSL

Cukup jelas bahwa Anda memiliki masalah SSL serius dan kemungkinan besar karena instalasi OpenSSL yang salah atau serupa. Mulailah dengan menguji sertifikat SSL Anda menggunakan Labs SSL dan kemudian memperbaiki masalah atau peringatan yang disarankan.

Jika SSL masih beroperasi lambat maka kemungkinan besar Anda memiliki server yang kelebihan beban atau kesalahan server. Jika itu nanti maka Anda harus mencoba dan mempersempit di mana kesalahan itu berada. Gunakan tumpukan Kesalahan Server jika Anda memerlukan bantuan lebih lanjut tentang masalah ini, satu pengguna melaporkan bahwa membuat kunci baru menyelesaikan masalah SSL lambat yang ia temui yang mungkin, atau mungkin tidak relevan.

Load balancers dapat membantu jika ini merupakan masalah sumber daya server.

Langkah 2: Investigasi TTFB

Setelah Anda menyelidiki menyelesaikan masalah SSL dan Anda masih memiliki TTFB yang meningkat maka Anda harus menguji server Anda dengan memastikan bahwa ia memiliki sumber daya yang cukup.

Waktu byte pertama dipengaruhi oleh tetapi tidak terbatas pada:

  • Jarak dari pengguna ke pusat data hosting server dapat meningkatkan TTFB
  • GZIP yang tidak terpecah dapat meningkatkan TTFB
  • Jaringan yang macet dapat meningkatkan TTFB
  • Server yang macet dapat meningkatkan TTFB

Terkadang meningkatkan CPU dan RAM tidak selalu merupakan pilihan terbaik. Terkadang lebih baik untuk memperkenalkan penyeimbang beban karena tidak hanya artinya Anda dapat dengan mudah menjalankan beberapa server secara berdampingan tetapi sebenarnya juga membongkar caching dan permintaan SSL. Beberapa manfaat lain termasuk:

SUMBER

  • Caching: Alat dapat menyimpan konten yang tidak berubah (seperti gambar) dan menayangkannya langsung ke klien tanpa mengirim lalu lintas ke server web.
  • Kompresi: Mengurangi jumlah lalu lintas untuk objek HTTP dengan mengompresi file sebelum dikirim.
  • SSL Offloading: Memproses traffic SSL sangat menuntut pada server web CPU, jadi load balancer dapat melakukan pemrosesan ini sebagai gantinya.
  • Ketersediaan tinggi: Dua peralatan penyeimbang beban dapat digunakan jika salah satunya gagal.

Kiat untuk menurunkan TTFB Anda:

  • Pastikan database Anda berada di jaringan yang sama, atau cloud SQL berkualitas .
  • Memastikan database Anda dibaca dari memori dan TIDAK PERNAH yang SWAP berkas!
  • Memanfaatkan jaringan pengiriman konten , itu membongkar permintaan server dan tugas kompresi.
  • Manfaatkan Varnish Cache untuk mengurangi beban pada database dengan menyimpan halaman
  • Benchmark file statis Anda pada hard disk menggunakan HDParm
  • Benchmark server Anda menggunakan alat pembandingan server HTTP Apache
  • Benchmark situs web dengan 10 berlalu dengan beberapa lokasi jarak jauh menggunakan WebPageTest

Terima kasih atas penjelasan terperinci Anda. Akan menguji server lagi pada parameter yang disarankan dan akan menerapkan yang terbaik!
User234334

Grafik pada pertanyaan memisahkan jabat tangan SSL dari permintaan awal dan TTFB. Menurut grafik itu, masalahnya sebenarnya dengan SSL sebelum permintaan dibuat.
Stephen Ostermiller

@StephenOstermiller terlihat dengan baik. TTFB yang menunggu adalah 4000ms sedangkan SSL lebih dari 11000ms. Kemungkinan SSL memengaruhi TTFB. Saya telah memperbarui pertanyaan untuk mencerminkan hal itu.
Simon Hayter

Terima kasih! Saya menguji SSL saya di www.ssllabs.com dan peringkatnya "A". Tidak ada peringatan / masalah yang dilaporkan. Saya menemukan bahwa versi Apache 2.2.15 yang sudah usang. Perlu memperbarui sekarang. Konten situs web saya (ukuran dalam TB) ada di / var / www / html /. Apakah memperbarui / menginstal ulang Apache akan menghapus konten situs web saya? Adakah metode teraman untuk memperbarui tanpa kehilangan data?
User234334

Satu hal lagi - OpenSSL juga versi terbaru.
User234334

6

Membaca judul pertanyaan Anda , ada dua hal yang dapat Anda lakukan untuk mempercepat koneksi awal dan jabat tangan SSL / TLS. Ini berfungsi untuk koneksi apa pun, bukan hanya 3G, jadi Anda harus menggunakan ini sebagai praktik terbaik.

Pertama, gunakan HTTP / 2 untuk melayani situs. Ini membutuhkan Apache 2.4.17 atau lebih baru .

Kedua, konfigurasikan Apache untuk menggunakan stapel OCSP. Ini membutuhkan Apache 2.3.3 atau lebih baru plus OpenSSL 0.9.8h atau lebih baru, dengan panduan yang baik untuk memasangnya di sini . Stapel OCSP tidak akan mempercepat, tetapi itu akan melakukan beberapa pekerjaan untuk klien dan menghindarkan mereka dari kesulitan dalam mencoba pencarian OCSP.

Membaca teks isi dari pertanyaan Anda , saya pikir Anda memiliki masalah yang lebih besar dengan lingkungan hosting Anda. Waktu muat tersebut tidak dapat diterima. Anda menyebutkan bahwa itu adalah 'shared hosting', Anda harus menghubungi siapa pun yang mengelola shared hosting itu dan bertanya mengapa server mereka sangat lambat. Anda mungkin lebih baik mencoba host bersama yang berbeda, atau menjalankan VPS sendiri (ini lebih banyak pekerjaan tetapi memberikan kecepatan dan fleksibilitas yang lebih baik).

Karena Anda sudah menggunakan AWS, mengapa tidak mencoba tingkat gratis mereka untuk menguji berbagai hal dan membuat server Anda bekerja dan dioptimalkan? Gunakan dengan subdomain dan beberapa halaman HTML statis untuk pengujian dan kemudian pindahkan situs utama Anda (naikkan melewati batas tingkat gratis jika diperlukan).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.