Apakah ada perbedaan besar dalam kinerja antara http dan https? Saya ingat pernah membaca bahwa HTTPS bisa menjadi yang kelima secepat HTTP. Apakah ini valid dengan webservers / browser generasi saat ini? Jika demikian, apakah ada whitepaper yang mendukungnya?

Ada jawaban yang sangat sederhana untuk ini: Profil kinerja server web Anda untuk melihat apa penalti kinerja untuk situasi khusus Anda. Ada beberapa alat di luar sana untuk membandingkan kinerja server HTTP vs HTTPS (JMeter dan Visual Studio datang ke pikiran) dan mereka cukup mudah digunakan.

Tidak ada yang dapat memberikan jawaban yang berarti tanpa beberapa informasi tentang sifat situs web Anda, perangkat keras, perangkat lunak, dan konfigurasi jaringan.

Seperti yang dikatakan orang lain, akan ada beberapa tingkat overhead karena enkripsi, tetapi sangat tergantung pada:

• Perangkat keras
• Perangkat lunak server
• Rasio konten dinamis vs statis
• Jarak klien ke server
• Panjang sesi tipikal
• Dll (favorit pribadi saya)
• Perilaku caching klien

Dalam pengalaman saya, server yang banyak pada konten dinamis cenderung kurang terpengaruh oleh HTTPS karena waktu yang dihabiskan untuk enkripsi (overhead-SSL) tidak signifikan dibandingkan dengan waktu pembuatan konten.

Server yang banyak melayani satu set halaman statis yang cukup kecil yang dapat dengan mudah di-cache dalam memori menderita overhead yang jauh lebih tinggi (dalam satu kasus, throughput dikacaukan pada "intranet").

Sunting: Satu poin yang telah diangkat oleh beberapa orang lain adalah bahwa handshaking SSL adalah biaya utama HTTPS. Itu benar, itulah sebabnya "panjang sesi khas" dan "perilaku caching klien" penting.

Banyak, sesi yang sangat singkat berarti waktu berjabat tangan akan membebani faktor kinerja lainnya. Sesi yang lebih lama akan berarti biaya handshaking akan dikeluarkan pada awal sesi, tetapi permintaan berikutnya akan memiliki overhead yang relatif rendah.

Caching klien dapat dilakukan pada beberapa langkah, di mana saja dari server proxy skala besar hingga cache browser individual. Umumnya konten HTTPS tidak akan di-cache dalam cache bersama (meskipun beberapa server proxy dapat mengeksploitasi perilaku tipe man-in-the-middle untuk mencapai hal ini). Banyak browser menyimpan konten HTTPS untuk sesi saat ini dan sering kali lintas sesi. Dampak dari tidak-caching atau lebih sedikit caching berarti klien akan lebih sering mengambil konten yang sama. Ini menghasilkan lebih banyak permintaan dan bandwidth untuk melayani jumlah pengguna yang sama.

HTTPS membutuhkan jabat tangan awal yang bisa sangat lambat. Jumlah aktual data yang ditransfer sebagai bagian dari jabat tangan tidak besar (di bawah 5 kB biasanya), tetapi untuk permintaan yang sangat kecil, ini bisa menjadi sedikit overhead. Namun, begitu jabat tangan selesai, bentuk enkripsi simetris yang sangat cepat digunakan, sehingga biaya overhead di sana minimal. Intinya: membuat banyak permintaan pendek melalui HTTPS akan sedikit lebih lambat dari HTTP, tetapi jika Anda mentransfer banyak data dalam satu permintaan, perbedaannya tidak signifikan.

Namun, keepalive adalah perilaku default di HTTP / 1.1, jadi Anda akan melakukan satu jabat tangan dan kemudian banyak permintaan melalui koneksi yang sama. Ini membuat perbedaan yang signifikan untuk HTTPS. Anda mungkin harus membuat profil situs Anda (seperti yang disarankan orang lain) untuk memastikan, tetapi saya menduga bahwa perbedaan kinerja tidak akan terlihat.

Untuk benar-benar memahami bagaimana HTTPS akan meningkatkan latensi Anda, Anda harus memahami bagaimana koneksi HTTPS dibuat. Ini diagram yang bagus . Kuncinya adalah bahwa alih-alih klien mendapatkan data setelah 2 "kaki" (satu perjalanan pulang-pergi, Anda mengirim permintaan, server mengirim tanggapan), klien tidak akan mendapatkan data hingga setidaknya 4 kaki (2 perjalanan pulang pergi) . Jadi, jika dibutuhkan 100 ms untuk paket untuk berpindah antara klien dan server, permintaan HTTPS pertama Anda akan membutuhkan setidaknya 500 ms.

Tentu saja, ini dapat dikurangi dengan menggunakan kembali koneksi HTTPS (browser mana yang harus dilakukan), tetapi hal itu menjelaskan bagian dari kios awal ketika memuat situs web HTTPS.

Biaya overhead BUKAN karena enkripsi. Pada CPU modern, enkripsi yang diperlukan oleh SSL sepele.

Biaya overhead ini disebabkan oleh jabat tangan SSL, yang panjang dan secara drastis meningkatkan jumlah perjalanan bolak-balik yang diperlukan untuk sesi HTTPS melalui sesi HTTP.

Ukur (menggunakan alat seperti Firebug) waktu pemuatan halaman saat server berada di ujung tautan latensi tinggi yang disimulasikan. Ada alat untuk mensimulasikan tautan latensi tinggi - untuk Linux ada "netem". Bandingkan HTTP dengan HTTPS pada pengaturan yang sama.

Latensi dapat dikurangi sampai batas tertentu dengan:

• Memastikan bahwa server Anda menggunakan HTTP keepalives - ini memungkinkan klien untuk menggunakan kembali sesi SSL, yang menghindari perlunya jabat tangan lain
• Mengurangi jumlah permintaan menjadi sesedikit mungkin - dengan menggabungkan sumber daya jika memungkinkan (misalnya. Js termasuk file, CSS) dan mendorong caching sisi klien
• Kurangi jumlah pemuatan halaman, mis. Dengan memuat data yang tidak diperlukan ke halaman (mungkin dalam elemen HTML tersembunyi) dan kemudian memperlihatkannya menggunakan skrip klien.

Pembaruan Desember 2014

Anda dapat dengan mudah menguji perbedaan antara kinerja HTTP dan HTTPS di browser Anda sendiri menggunakan situs web HTTP vs HTTPS Test oleh AnthumChris : “Halaman ini mengukur waktu pemuatannya terhadap HTTP yang tidak aman dan koneksi HTTPS terenkripsi. Kedua halaman memuat 360 gambar unik, yang tidak di-cache (total 2,04 MB). "

Hasilnya mungkin mengejutkan Anda.

Penting untuk memiliki pengetahuan terkini tentang kinerja HTTPS karena Let's Encrypt Certificate Authority akan mulai menerbitkan sertifikat SSL gratis, otomatis, dan terbuka di Musim Panas 2015, terima kasih kepada Mozilla, Akamai, Cisco, Electronic Frontier Foundation dan IdenTrust.

Pembaruan Juni 2015

Pembaruan pada Let's Encrypt - Tiba September 2015:

• Let's Encrypt Jadwal Peluncuran (16 Jun 2015)
• Let's Encrypt Root dan Intermediate Certificates (Jun 4, 2015)
• Draft Let's Encrypt Agreement Pelanggan (21 Mei 2015)

Info lebih lanjut tentang Twitter: @letsencrypt

Untuk info lebih lanjut tentang kinerja HTTPS dan SSL / TLS, lihat:

• Apakah TLS Cepat?
• Jaringan Browser Kinerja Tinggi, Bab 4: Transport Layer Security
• SSL overclocking
• Anatomi dan Kinerja Pemrosesan SSL

Untuk info lebih lanjut tentang pentingnya menggunakan HTTPS, lihat:

• Mengapa HTTPS untuk Segalanya? (The HTTPS-Only Standard)
• Let's Encrypt (Kelompok Riset Keamanan Internet)
• HTTPS Everywhere (Electronic Frontier Foundation)

Singkatnya, izinkan saya mengutip Ilya Grigorik : "TLS memiliki satu masalah kinerja: ia tidak digunakan secara luas. Semua hal lain dapat dioptimalkan."

Terima kasih kepada Chris - penulis patokan HTTP vs HTTPS Test - untuk komentarnya di bawah.

Jawaban teratas saat ini tidak sepenuhnya benar.

Seperti yang orang lain tunjukkan di sini, https memerlukan jabat tangan dan karenanya melakukan lebih banyak pulang-pergi TCP / IP.

Dalam lingkungan WAN biasanya maka latensi menjadi faktor pembatas dan bukan peningkatan penggunaan CPU pada server.

Perlu diingat bahwa latensi dari Eropa ke AS dapat sekitar 200 ms (waktu perjalanan).

Anda dapat dengan mudah mengukur ini (untuk kasus pengguna tunggal) dengan HTTPWatch .

Selain semua yang disebutkan sejauh ini, harap diingat bahwa beberapa browser web (semua?) Tidak menyimpan konten yang di-cache yang diperoleh melalui HTTPS pada hard drive lokal untuk alasan keamanan. Ini berarti bahwa dari halaman perspektif pengguna dengan banyak konten statis akan tampak memuat lebih lambat setelah browser dimulai kembali, dan dari perspektif server Anda, volume permintaan untuk konten statis melalui HTTPS akan lebih tinggi daripada yang seharusnya melalui HTTP.

Tidak ada jawaban tunggal untuk ini.

Enkripsi akan selalu mengkonsumsi lebih banyak CPU. Ini dapat diturunkan ke perangkat keras khusus dalam banyak kasus, dan biayanya akan bervariasi berdasarkan algoritma yang dipilih. 3des lebih mahal daripada AES, misalnya. Beberapa algoritma lebih mahal untuk enkripsi daripada decryptor. Beberapa memiliki biaya yang berlawanan.

Lebih mahal daripada kripto curah adalah biaya jabat tangan. Koneksi baru akan mengkonsumsi lebih banyak CPU. Ini dapat dikurangi dengan dimulainya kembali sesi, dengan biaya menjaga rahasia sesi lama sampai mereka berakhir. Ini berarti bahwa permintaan kecil dari klien yang tidak kembali lebih banyak adalah yang paling mahal.

Untuk lalu lintas internet lintas, Anda mungkin tidak melihat biaya ini dalam kecepatan data Anda, karena bandwidth yang tersedia terlalu rendah. Tetapi Anda pasti akan melihatnya dalam penggunaan CPU pada server yang sibuk.

Saya dapat memberitahu Anda (sebagai pengguna dialup) bahwa halaman yang sama melalui SSL beberapa kali lebih lambat daripada melalui HTTP biasa ...

Dalam sejumlah kasus, dampak kinerja jabat tangan SSL akan dikurangi dengan fakta bahwa sesi SSL dapat di-cache di kedua ujungnya (desktop dan server). Pada mesin Windows misalnya, sesi SSL dapat di-cache hingga 10 jam. Lihat http://support.microsoft.com/kb/247658/EN-US . Beberapa akselerator SSL juga akan memiliki parameter yang memungkinkan Anda untuk menyesuaikan waktu sesi di-cache.

Dampak lain yang perlu dipertimbangkan adalah bahwa konten statis yang dilayani melalui HTTPS tidak akan di-cache oleh proxy, dan ini dapat mengurangi kinerja di beberapa pengguna yang mengakses situs melalui proxy yang sama. Ini dapat dikurangi dengan fakta bahwa konten statis juga akan di-cache di desktop, Internet Explorer versi 6 dan 7 cache konten HTTPS cacheable kecuali diminta untuk melakukan sebaliknya (Menu Alat / Opsi Internet / Lanjutan / Keamanan / Jangan menyimpan halaman yang dienkripsi ke disk).

Saya membuat percobaan kecil dan mendapat perbedaan waktu 16% untuk gambar yang sama dari flickr (233 kb):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

Tentu saja angka-angka ini tergantung pada banyak faktor, seperti kinerja komputer, kecepatan koneksi, beban server, QoS on path (jalur jaringan tertentu yang diambil dari browser ke server) tetapi ini menunjukkan ide umum: HTTPS lebih lambat daripada HTTP, karena itu membutuhkan lebih banyak operasi untuk diselesaikan (handshaking SSL dan pengodean / dekode data).

Berikut ini adalah artikel yang bagus (sedikit lama, tetapi masih bagus) tentang latensi handshake SSL. Membantu saya mengidentifikasi SSL sebagai penyebab utama lambatnya klien yang menggunakan aplikasi saya melalui koneksi internet yang lambat:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

Karena saya sedang menyelidiki masalah yang sama untuk proyek saya, saya menemukan slide ini. Lebih tua tapi menarik:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm

Tampaknya ada tepi kasus buruk di sini: Ajax over wifi yang padat.

Ajax biasanya berarti bahwa KeepAlive telah kehabisan waktu setelah mengatakan 20 detik. Namun, wifi berarti koneksi ajax (idealnya cepat) harus melakukan beberapa round trip. Lebih buruk lagi, wifi sering kehilangan paket, dan ada transmisi ulang TCP. Dalam hal ini, HTTPS berkinerja sangat sangat buruk!

Apakah TLS belum cepat? Iya.

• Tonton: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Baca: https://istlsfastyet.com/

Ada banyak proyek di luar sana yang bertujuan untuk mengaburkan garis dan membuat HTTPS sama cepatnya. Seperti SPDY dan mod-spdy .

PERBANDINGAN KINERJA HTTP VS HTTPS

Saya selalu mengaitkan HTTPS dengan waktu pemuatan laman yang lebih lambat bila dibandingkan dengan HTTP lama. Sebagai pengembang web, kinerja halaman web penting bagi saya dan apa pun yang akan memperlambat kinerja halaman web saya adalah tidak-tidak.

Untuk memahami implikasi kinerja yang terlibat, diagram di bawah ini memberi Anda ide dasar tentang apa yang terjadi di bawah tenda ketika Anda membuat permintaan untuk sumber daya menggunakan HTTPS.

Seperti yang Anda lihat dari diagram di atas, ada beberapa langkah tambahan yang perlu dilakukan ketika menggunakan HTTPS dibandingkan dengan menggunakan HTTP biasa. Saat Anda mengajukan permintaan menggunakan HTTPS, jabat tangan harus dilakukan untuk memverifikasi keaslian permintaan. Jabat tangan ini merupakan langkah ekstra bila dibandingkan dengan permintaan HTTP dan sayangnya menimbulkan beberapa overhead.

Untuk memahami implikasi kinerja dan melihat sendiri apakah dampak kinerja akan signifikan, saya menggunakan situs ini sebagai platform pengujian. Saya menuju ke webpagetest.org dan menggunakan alat perbandingan visual untuk membandingkan pemuatan situs ini menggunakan HTTPS vs HTTP.

Seperti yang dapat Anda lihat dari Here is Test video Result menggunakan HTTPS memang berdampak pada waktu buka halaman saya, namun perbedaannya dapat diabaikan dan saya hanya melihat perbedaan 300 milidetik. Penting untuk dicatat bahwa waktu ini tergantung pada banyak faktor, seperti kinerja komputer, kecepatan koneksi, beban server, dan jarak dari server.

Situs Anda mungkin berbeda, dan penting untuk menguji situs Anda secara menyeluruh dan memeriksa dampak kinerja yang terlibat dalam beralih ke HTTPS.

Ada cara untuk mengukur ini. Alat dari apache yang disebut jmeter akan mengukur throughput. Jika Anda membuat sampel besar layanan Anda dengan jmeter, dalam lingkungan yang terkontrol, dengan dan tanpa SSL, Anda harus mendapatkan perbandingan yang akurat dari biaya relatif. Saya akan tertarik dengan hasil Anda.

HTTPS memiliki overhead enkripsi / dekripsi sehingga akan selalu sedikit lebih lambat. Pengakhiran SSL sangat intensif menggunakan CPU. Jika Anda memiliki perangkat untuk mengeluarkan SSL, perbedaan dalam latensi mungkin hampir tidak terlihat tergantung pada beban server Anda.

Perbedaan kinerja yang lebih penting adalah bahwa sesi HTTPS terbuka terbuka saat pengguna terhubung. 'Sesi' HTTP hanya berlangsung untuk satu permintaan item.

Jika Anda menjalankan situs dengan sejumlah besar pengguna secara bersamaan, diharapkan untuk membeli banyak memori.

Ini hampir pasti akan menjadi kenyataan mengingat SSL membutuhkan langkah enkripsi tambahan yang tidak diperlukan oleh HTTP non-SLL.

HTTPS memang memengaruhi kecepatan halaman ...

Kutipan di atas mengungkapkan kebodohan banyak orang tentang keamanan dan kecepatan situs. Handshaking server HTTPS / SSL menciptakan kios awal dalam membuat koneksi Internet. Ada penundaan lambat sebelum sesuatu mulai ditampilkan di layar browser pengunjung Anda. Penundaan ini diukur dalam informasi Time-to-First-Byte.

Overhead jabat tangan HTTPS muncul dalam informasi Time-to-First-Byte (TTFB). TTFB umum berkisar dari di bawah 100 milidetik (kasus terbaik) hingga lebih dari 1,5 detik (kasus terburuk). Tapi, tentu saja, dengan HTTPS 500 milidetik lebih buruk.

Pulang pergi, koneksi 3G nirkabel dapat 500 milidetik atau lebih. Perjalanan ekstra ini menunda dua kali lipat menjadi 1 detik atau lebih. Ini adalah dampak negatif yang besar pada kinerja seluler. Berita yang sangat buruk.

Saran saya, jika Anda tidak bertukar data sensitif maka Anda tidak memerlukan SSL sama sekali, tetapi jika Anda menyukai situs web e-commerce maka Anda dapat mengaktifkan HTTPS pada halaman tertentu di mana data sensitif dipertukarkan seperti Login dan checkout.

Sumber: Pagepipe

Browser dapat menerima protokol HTTP / 1.1 dengan HTTP atau HTTPS, namun browser hanya dapat menangani protokol HTTP / 2.0 dengan HTTPS. Perbedaan protokol dari HTTP / 1.1 ke HTTP / 2.0 membuat HTTP / 2.0, rata-rata, 4-5 kali lebih cepat daripada HTTP / 1.1. Juga, dari situs yang menerapkan HTTPS, kebanyakan melakukannya melalui protokol HTTP / 2.0. Oleh karena itu, HTTPS hampir selalu akan lebih cepat daripada HTTP hanya karena protokol berbeda yang biasanya digunakan. Namun, jika HTTP over HTTP / 1.1 dibandingkan dengan HTTPS over HTTP / 1.1, maka HTTP sedikit lebih cepat, rata-rata, daripada HTTPS.

Berikut adalah beberapa perbandingan yang saya jalankan menggunakan Chrome (Ver. 64):

HTTPS melalui HTTP / 1.1:

• 0,47 detik waktu buka halaman rata-rata
• 0,05 detik lebih lambat dari HTTP melalui HTTP / 1.1
• 0.37 detik lebih lambat dari HTTPS melalui HTTP / 2.0

HTTP over HTTP / 1.1

• Rata-rata waktu pemuatan halaman 0,42 detik
• 0,05 detik lebih cepat dari HTTPS melalui HTTP / 1.1
• 0.32 detik lebih lambat dari HTTPS melalui HTTP / 2.0

HTTPS melalui HTTP / 2.0

• Rata-rata waktu muat 0,10 detik
• 0,32 detik lebih cepat dari HTTP melalui HTTP / 1.1
• 0,37 detik lebih cepat dari HTTPS melalui HTTPS / 1.1