HTTP vs kinerja HTTPS


363

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?


1
Anda juga harus memeriksa HTTP2, yang saat ini hanya didukung browser saat digunakan dengan HTTPS. en.wikipedia.org/wiki/HTTP/2
Luca Steeb

1
httpsselalu lebih lambat dari http(atau lebih lambat).
i486

Jika ada beberapa caching transparan yang terjadi (cumi-cumi misalnya) maka itu mungkin signifikan. Protokol itu sendiri, saya tidak berpikir itu memiliki overhead yang besar.
Rolf

Jawaban:


231

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.


James, berharap Anda dapat memberikan komentar singkat tentang kecepatan komparatif dari solusi aSSL ini: assl.sullof.com/assl Dari atas kepala Anda, adakah yang memperoleh kinerja bijaksana? Terima kasih!
Matt Gardner

PS: Ini pemahaman saya bahwa solusi ini membutuhkan kunci sisi klien (yang dapat diimplementasikan dalam kasus aplikasi webkit / titanium), tujuannya hanya untuk memaksimalkan komponen persamaan kecepatan ini bersama dengan yang lain yang Anda sebutkan.
Matt Gardner

7
Posting ini tidak benar-benar menjawab pertanyaan. Tampaknya Jim Geurts bertanya tentang sifat kinerja HTTP dan HTTPS sendiri, bukan implementasi tertentu. HTTPS pasti lebih lambat karena ia bekerja lebih banyak. Jadi pertanyaannya adalah, seberapa lambat? Semua orang tahu bahwa jika Anda menambahkan lebih banyak variabel, Anda mendapatkan hasil yang bervariasi.
Elliot Cameron

74
Jawaban ini menyebutkan banyak hal yang tidak relevan (dengan kata lain salah) pada awalnya . Dia membutuhkan 5 paragraf untuk mendapatkan jawaban yang benar, yaitu HANDSHAKING .
bobobobo

2
Konten yang disajikan melalui HTTPS tidak akan di-cache oleh proxy . Semua browser modern men-cache konten HTTPS secara default, kecuali secara eksplisit diberitahu untuk tidak seperti yang dijelaskan oleh Jeff Atwood
Jarek Przygódzki

222

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.


19
Ternyata biaya handshaking ini akan dibayar sekitar 4-10x per sesi, minimal, karena sebagian besar browser menggunakan beberapa koneksi ke server yang sama. Bergantung pada berapa lama https-keep-live untuk peramban, mungkin terjadi berulang kali selama sesi.
James Schek

6
mengenai fitur keepalive HTTP, kami telah mengalami skenario di mana koneksi tidak bertahan lama. Untuk setiap permintaan, koneksi permintaan sedang dibangun dan dirusak jabat tangan MA-SSL. Ada kemungkinan di mana klien atau server mungkin telah mengkonfigurasi untuk menutup koneksi. Biasanya terjadi di lingkungan Tomcat / Websphere.
zkarthik

8
@JamesSchek Banyak koneksi harus menggunakan kembali sesi SSL yang sama , yang mengubah gambar sedikit. Hal yang sama berlaku bahkan jika HTTP keep-live tidak berfungsi.
Marquis of Lorne

14
@ EJP Itu benar. Dan pada tahun 2013, sebagian besar browser / server dan implementasi SSL / TLS memanfaatkan penggunaan kembali sesi. Pada 2008, itu bukan asumsi yang selalu aman.
James Schek

3
Pertanyaan ini muncul tinggi di Google untuk "kinerja http vs https." Meskipun jawaban di atas benar di tahun 2008, itu tidak lagi benar di tahun 2015 dan tidak boleh digunakan sebagai dasar untuk keputusan untuk menghindari penggunaan https.
Paul Schreiber

101

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.


1
Dalam hal klien Java, bagaimana seseorang dapat membuat koneksi HTTPS dapat digunakan kembali? Maksud saya, dapatkah saya membuat objek statis HttpsConnection dan menggunakannya kembali? (dalam konteks aplikasi web)
Niks

1
5 tahun kemudian, tautan ke diagram +1 yang bagus tidak berfungsi, adakah yang bisa menemukannya dan meletakkannya di jawaban alih-alih tautan?
Jim Wolff

2
@FRoZen menemukan tautan alternatif
Stefan L

Juga saya pikir halaman ini adalah diagram http yang sangat baik untuk lebih memahami seluruh gambar: blog.catchpoint.com/2010/09/17/anatomyhttp
Tampilan elips

1
@Nikhil Java secara otomatis menggunakan kembali koneksi yang mendasarinya dan membagikannya di seluruh permintaan, kecuali dipaksakan oleh pengguna melalui disconnect. Periksa dokumen .
Mohnish

76

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.

8
Saya sangat setuju dengan @MarkR. Profil beranda terbaru saya, HTTP vs HTTPS, rata-rata waktu muat masing-masing 1,5 dan 4,5. Ketika melihat rincian koneksi, faktor perlambatan besar adalah perjalanan pulang-pergi tambahan karena jabat tangan SSL. Browser seluler melalui 3G bahkan lebih buruk. Jumlahnya masing-masing 5s dan 9s.
Clint Pachl

26

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:

Info lebih lanjut tentang Twitter: @letsencrypt

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

Untuk info lebih lanjut tentang pentingnya menggunakan HTTPS, lihat:

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.


6
"Uji HTTP vs HTTPS" sengaja menipu, jangan tautkan ke sana. Apa yang sebenarnya dilakukan halaman itu adalah membandingkan HTTP dengan SPDY . Memang benar, jika Anda tidak percaya kepada saya, coba di IE dan lihat apa yang dikatakannya. Tidak ada situasi di mana permintaan HTTP lebih cepat dari permintaan HTTPS yang setara.
orrd

3
Google memaksa SPDY untuk hanya menggunakan koneksi aman karena alasan politis, bukan koneksi teknis. HTTP / 2 (yang menggunakan teknik peningkatan kecepatan SPDY yang sama) dapat menggunakan koneksi yang tidak aman, dan itu sedikit lebih cepat ketika itu terjadi. Koneksi yang tidak aman masih selalu setidaknya sedikit lebih cepat daripada koneksi yang aman menggunakan protokol yang sama. "HTTP vs HTTPS Test" sengaja menipu dan menyesatkan.
orrd

3
Situs web ini menyediakan perbandingan kuantitatif dengan bilangan real, dan ini merupakan upaya untuk mendorong lebih banyak orang untuk melindungi pengguna mereka dengan HTTPS. Pendapat hanya membawa kita sejauh ini, dan kami selalu memiliki kebebasan untuk membangun aplikasi lambat, tidak aman untuk IE melalui HTTP. Saya akan selalu memilih untuk membangun aplikasi web yang cepat, canggih, dan aman untuk Chrome / Firefox dengan HTTPS.
AnthumChris

2
Aritmatika di httpvshttps.com terlihat salah: 1,7 detik dibandingkan dengan 34 detik tidak "95% lebih cepat." Ini 20 × lebih cepat, atau 1900% lebih cepat. Seharusnya membandingkan kecepatan daripada durasi.
Kolonel Panic

2
Tes itu menyesatkan dan menipu. Per tools.ietf.org/html/rfc7540#section-3.2 tidak ada alasan mengapa HTTP / 2 tidak dapat digunakan pada koneksi yang tidak aman. Perusahaan besar mendorong untuk penggunaan HTTPS universal. Alasannya beragam. Namun faktanya tetap ada. Kecuali ada data pribadi pada halaman tersebut, tidak ada alasan untuk menjalankan SSL. Dan sementara ya dengan komputer saat ini, jabatan tangan SSL itu sepele. Jika kita mulai mengatakan ini dan itu hal-hal sepele hanya akan macet. Menghasilkan tes 1: 1 dari HTTP / 1.1 vs HTTP / 1.1 SSL dan HTTP / 2 vs HTTP / 2 SSL. Kemudian Diskusikan.
Shinrai

23

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 .


12

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.


6
Mengirim tajuk "Kontrol-Cach: max-age = X, publik", akan menyebabkan peramban modern (hanya menguji FF4, Chrome12, IE8, IE9) untuk men-cache konten. Namun, saya perhatikan browser ini mengirimkan GET bersyarat, yang dapat menimbulkan latensi tambahan untuk perjalanan pulang-pergi tambahan, terutama jika koneksi SSL tidak di-cache (Keep Alive).
Clint Pachl

6

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.


6

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


6
Poin yang bagus. Saya juga menemukan bahwa memuat kali melalui jaringan ponsel (3G) juga 2x lebih lambat 3x.
Clint Pachl

Ya! Hanya satu setengah tahun setelah jawaban itu saya pindah ke rumah baru dan akhirnya bisa beralih ke DSL dengan uang lebih sedikit daripada memiliki jalur POTS!
Brian Knoblauch

6

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).


4

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

masukkan deskripsi gambar di sini

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).


4
tidak dapat membuat metrik analisis statistik berdasarkan 2 permintaan, satu untuk masing-masing.
Tom Roggero


2

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


Saya menemukan diagram yang disederhanakan membantu tetapi juga sedikit kurang. Saya pikir Untuk lebih memahami jumlah perjalanan pulang pergi halaman ini untuk http sangat membantu: blog.catchpoint.com/2010/09/17/anatomyhttp Maka sedekat yang saya tahu untuk https: kami menambahkan satu perjalanan pulang pergi.
Pandangan elips

2

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!



2

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.

masukkan deskripsi gambar di sini

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.


1
Secara umum contohnya bagus tetapi lebih banyak terlibat daripada yang digambarkan, terutama dengan Perfect Forward Secrecy. Sebenarnya ada empat kunci simetris yang digunakan.
zaph

0

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.


-1

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.


-1

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.


2
Non dalam HTTP 1.1. Koneksi dibiarkan terbuka untuk waktu yang lama.
Sklivvz

-1

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


2
Bahwa ada perbedaan kinerja antara kedua kasus.
David The Man

2
Tetapi pertanyaannya adalah "Apakah ada perbedaan besar dalam kinerja antara http dan https?"
Sklivvz

-1

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


-2

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
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.