Wydajność HTTP a HTTPS

363

Czy istnieją jakieś zasadnicze różnice w wydajności między http a https? Wydaje mi się, że pamiętam, że HTTPS może być piąty tak szybko jak HTTP. Czy dotyczy to serwerów / przeglądarek obecnej generacji? Jeśli tak, to czy są jakieś oficjalne dokumenty na jego poparcie?

Jim Geurts
źródło
1
Powinieneś także sprawdzić HTTP2, które przeglądarki obsługują obecnie tylko w połączeniu z HTTPS. en.wikipedia.org/wiki/HTTP/2
Luca Steeb
1
httpsjest zawsze wolniejszy niż http(lub znacznie wolniejszy).
i486
Jeśli dzieje się jakieś przezroczyste buforowanie (na przykład kałamarnica), może to być znaczące. Sam protokół, nie sądzę, że ma duży koszt.
Rolf

Odpowiedzi:

231

Jest na to bardzo prosta odpowiedź: profil wydajności serwera WWW, aby zobaczyć, jaka jest obniżka wydajności dla konkretnej sytuacji. Istnieje kilka narzędzi służących do porównania wydajności serwera HTTP i HTTPS (przychodzą na myśl JMeter i Visual Studio) i są one dość łatwe w użyciu.

Nikt nie może udzielić sensownej odpowiedzi bez pewnych informacji na temat charakteru witryny, sprzętu, oprogramowania i konfiguracji sieci.

Jak powiedzieli inni, będzie pewien poziom narzutu z powodu szyfrowania, ale w dużym stopniu zależy to od:

  • Sprzęt komputerowy
  • Oprogramowanie serwera
  • Stosunek zawartości dynamicznej do statycznej
  • Odległość klienta do serwera
  • Typowa długość sesji
  • Etc (mój osobisty faworyt)
  • Zachowanie klientów w pamięci podręcznej

Z mojego doświadczenia wynika, że ​​HTTPS ma mniejszy wpływ na serwery obciążone treściami dynamicznymi, ponieważ czas spędzony na szyfrowaniu (narzut SSL) jest nieznaczny w porównaniu z czasem generowania treści.

Serwery, które są ciężkie w obsłudze dość niewielkiego zestawu statycznych stron, które można łatwo buforować w pamięci, cierpią z powodu znacznie większego obciążenia (w jednym przypadku przepustowość została zmniejszona w „intranecie”).

Edycja: Jedną z kwestii poruszonych przez kilka innych jest to, że uzgadnianie SSL jest głównym kosztem HTTPS. To prawda, dlatego „typowa długość sesji” i „zachowanie klientów w pamięci podręcznej” są ważne.

Wiele bardzo krótkich sesji oznacza, że ​​czas uzgadniania przerasta wszelkie inne czynniki wydajności. Dłuższe sesje będą oznaczać, że koszt uzgadniania zostanie poniesiony na początku sesji, ale kolejne żądania będą miały stosunkowo niski narzut.

Buforowanie klienta może odbywać się na kilku etapach, od dowolnego serwera proxy na dużą skalę po indywidualną pamięć podręczną przeglądarki. Zasadniczo zawartość HTTPS nie będzie buforowana we współdzielonej pamięci podręcznej (chociaż kilka serwerów proxy może wykorzystać do tego celu zachowanie typu człowiek w środku). Wiele przeglądarek buforuje zawartość HTTPS dla bieżącej sesji i często w różnych sesjach. Wpływ braku buforowania lub mniejszego buforowania oznacza, że ​​klienci będą częściej pobierać tę samą zawartość. Powoduje to więcej żądań i przepustowości do obsługi tej samej liczby użytkowników.

James Schek
źródło
James, miał nadzieję, że uda ci się przedstawić krótki komentarz na temat porównawczej prędkości tego rozwiązania aSSL : assl.sullof.com/assl Czy możesz coś zyskać pod względem wydajności? Dzięki!
Matt Gardner,
PS: Rozumiem, że to rozwiązanie wymaga klucza po stronie klienta (który może być zaimplementowany w przypadku aplikacji webkit / titanium), celem jest po prostu maksymalizacja tego elementu równania prędkości wraz z innymi, o których wspomniałeś.
Matt Gardner,
7
Ten post tak naprawdę nie odpowiada na pytanie. Wygląda na to, że Jim Geurts pyta o wydajność samych HTTP i HTTPS, a nie o konkretną implementację. HTTPS jest niezaprzeczalnie wolniejszy, ponieważ działa więcej. Pytanie brzmi, o ile wolniej? Wszyscy wiedzą, że jeśli dodasz więcej zmiennych, otrzymasz różne wyniki.
Elliot Cameron,
73
Ta odpowiedź wspomina na początku wiele nieistotnych (innymi słowy) rzeczy . Uzyskuje 5 akapitów, aby uzyskać właściwą odpowiedź, czyli UCHWYT .
bobobobo,
2
Treści wyświetlane przez HTTPS nie będą buforowane przez serwery proxy . Wszystkie nowoczesne przeglądarki domyślnie buforują zawartość HTTPS, chyba że wyraźnie to nie wyjaśni, jak wyjaśnia Jeff Atwood
Jarek Przygódzki
222

HTTPS wymaga wstępnego uścisku dłoni, który może być bardzo wolny. Rzeczywista ilość danych przesyłanych w ramach uzgadniania nie jest ogromna (zwykle poniżej 5 kB), ale w przypadku bardzo małych żądań może to być dość duże obciążenie. Jednak po zakończeniu uzgadniania używana jest bardzo szybka forma szyfrowania symetrycznego, więc narzut jest minimalny. Konkluzja: wysyłanie wielu krótkich żądań przez HTTPS będzie nieco wolniejsze niż HTTP, ale jeśli przesyłasz dużo danych w jednym żądaniu, różnica będzie nieznaczna.

Jednak Keepalive jest domyślnym zachowaniem w HTTP / 1.1, więc wykonasz pojedynczy uścisk dłoni, a następnie wiele żądań przez to samo połączenie. To robi znaczącą różnicę dla HTTPS. Prawdopodobnie powinieneś profilować swoją witrynę (jak sugerowali inni), aby się upewnić, ale podejrzewam, że różnica w wydajności nie będzie zauważalna.

Graeme Perrow
źródło
19
Okazuje się, że ten koszt uzgadniania zostanie zapłacony co najmniej około 4-10 razy na sesję, ponieważ większość przeglądarek używa wielu połączeń z tym samym serwerem. W zależności od tego, jak długo https-keep-alive jest dla przeglądarki, może być ponoszony wielokrotnie podczas sesji.
James Schek
6
jeśli chodzi o funkcję podtrzymywania HTTP, mamy do czynienia ze scenariuszem, w którym połączenia nie są trwałe. Dla każdego żądania budowane jest połączenie żądania i rozdawane, co oznacza uścisk dłoni MA-SSL. Istnieją możliwości, w których klient lub serwer mógł skonfigurować zamknięcie połączeń. Zazwyczaj występuje w środowiskach Tomcat / Websphere.
zkarthik
8
@JamesSchek Wiele połączeń powinno ponownie wykorzystywać tę samą sesję SSL , co znacznie zmienia obraz. To samo dotyczy, nawet jeśli HTTP utrzymanie przy życiu nie działa.
Markiz Lorne
14
@EJP To prawda. W 2013 r. Większość przeglądarek / serwerów i implementacji SSL / TLS korzysta z ponownego użycia sesji. W 2008 r. Nie zawsze było to bezpieczne założenie.
James Schek 30.01.2013
3
To pytanie pojawia się wysoko w Google dla „wydajności http vs. https”. Chociaż powyższa odpowiedź była prawdziwa w 2008 r., Nie jest już prawdziwa w 2015 r. I nie powinna być wykorzystywana jako podstawa decyzji o unikaniu używania protokołu https.
Paul Schreiber
101

Aby naprawdę zrozumieć, w jaki sposób HTTPS zwiększy twoje opóźnienie, musisz zrozumieć, w jaki sposób nawiązywane są połączenia HTTPS. Oto ładny schemat . Kluczem jest to, że zamiast klienta otrzymującego dane po 2 „etapach” (jedna podróż w obie strony, wysyłasz żądanie, serwer wysyła odpowiedź), klient nie otrzyma danych, dopóki co najmniej 4 etapy (2 wycieczki w obie strony) . Jeśli więc pakiet potrzebuje 100 ms na przejście między klientem a serwerem, pierwsze żądanie HTTPS zajmie co najmniej 500 ms.

Oczywiście można to złagodzić, ponownie wykorzystując połączenie HTTPS (co przeglądarki powinny zrobić), ale wyjaśnia część tego początkowego przeciągnięcia podczas ładowania strony internetowej HTTPS.

twk
źródło
1
Jeśli chodzi o klienta Java, jak sprawić, by połączenie HTTPS było ponownie użyteczne? Mam na myśli, czy mogę zrobić obiekt statyczny HttpsConnection i użyć go ponownie? (w kontekście aplikacji internetowej)
Niks
1
5 lat później link do ładnego schematu +1 nie działa, czy ktoś może go znaleźć i podać w odpowiedzi zamiast linku?
Jim Wolff
2
@FRoZen znalazł alternatywny link
Stefan L
Myślę też, że ta strona jest bardzo dobrym diagramem http, aby lepiej zrozumieć cały obraz: blog.catchpoint.com/2010/09/17/anatomyhttp
Eliptyczny widok
1
@Nikhil Java automatycznie ponownie wykorzystuje bazowe połączenie i udostępnia je w żądaniach, chyba że wymuszone przez użytkownika za pośrednictwem disconnect. Sprawdź dokumenty .
Mohnish
76

Narzut NIE jest spowodowany szyfrowaniem. W nowoczesnym procesorze szyfrowanie wymagane przez SSL jest banalne.

Narzut ten wynika z uścisków SSL, które są długie i drastycznie zwiększają liczbę podróży w obie strony wymaganych dla sesji HTTPS w porównaniu z sesją HTTP.

Zmierz (za pomocą narzędzia takiego jak Firebug) czasy ładowania strony, gdy serwer znajduje się na końcu symulowanego łącza o dużym opóźnieniu. Istnieją narzędzia do symulacji łącza o dużym opóźnieniu - w przypadku Linuksa istnieje „netem”. Porównaj HTTP z HTTPS w tej samej konfiguracji.

Opóźnienie można w pewnym stopniu złagodzić poprzez:

  • Zapewnienie, że Twój serwer używa HTTP HTTP - pozwala to klientowi na ponowne użycie sesji SSL, co pozwala uniknąć konieczności ponownego uzgadniania
  • Zmniejszenie liczby żądań do jak najmniejszej liczby - poprzez łączenie zasobów tam, gdzie to możliwe (np. Pliki JS, CSS) i zachęcanie do buforowania po stronie klienta
  • Zmniejsz liczbę ładowań strony, np. Ładując dane niepotrzebne na stronę (być może w ukrytym elemencie HTML), a następnie wyświetlając je za pomocą skryptu klienta.
MarkR
źródło
8
Bardzo zgadzam się z @MarkR. Mój najnowszy profil mojej strony głównej, HTTP vs HTTPS, średni czas ładowania wynosił odpowiednio 1,5 i 4,5 s. Przyglądając się szczegółom połączenia, dużym czynnikiem spowalniającym były dodatkowe podróże w obie strony z powodu uzgadniania SSL. Przeglądarki mobilne przez 3G były jeszcze gorsze. Liczby wynosiły odpowiednio 5 i 9.
Clint Pachl,
26

Aktualizacja z grudnia 2014 r

Możesz łatwo przetestować różnicę między wydajnością HTTP a HTTPS we własnej przeglądarce, korzystając ze strony testowej HTTP vs HTTPS firmy AnthumChris : „Ta strona mierzy czas ładowania przez niezabezpieczone połączenia HTTP i szyfrowane połączenia HTTPS. Obie strony ładują 360 unikatowych obrazów niebuforowanych (łącznie 2,04 MB). ”

Wyniki mogą Cię zaskoczyć.

Ważne jest, aby mieć aktualną wiedzę na temat wydajności HTTPS, ponieważ urząd certyfikacji Let's Encrypt zacznie wydawać bezpłatne, zautomatyzowane i otwarte certyfikaty SSL latem 2015 r. Dzięki Mozilli, Akamai, Cisco, Electronic Frontier Foundation i IdenTrust.

Aktualizacja z czerwca 2015 r

Aktualizacje dotyczące Let's Encrypt - od września 2015:

Więcej informacji na Twitterze: @letsencrypt

Aby uzyskać więcej informacji na temat wydajności HTTPS i SSL / TLS, zobacz:

Aby uzyskać więcej informacji na temat znaczenia używania HTTPS, zobacz:

Podsumowując, pozwólcie, że zacytuję Ilyę Grigorik : „TLS ma dokładnie jeden problem z wydajnością: nie jest wystarczająco szeroko stosowany. Wszystko inne można zoptymalizować”.

Podziękowania dla Chrisa - autora testu porównawczego HTTP vs HTTPS - za komentarze poniżej.

rsp
źródło
6
Że „Test HTTP a HTTPS” celowo wprowadza w błąd, nie należy do niego linkować. Ta strona faktycznie porównuje HTTP do SPDY . To prawda, jeśli mi nie wierzysz, wypróbuj to w IE i zobacz, co mówi. Nie ma sytuacji, w której żądanie HTTP jest szybsze niż równoważne żądanie HTTPS.
2015 r. O
3
Google zmusiło SPDY do korzystania z zabezpieczonych połączeń wyłącznie z powodów politycznych, a nie technicznych. HTTP / 2 (który wykorzystuje te same techniki poprawy prędkości SPDY) może korzystać z niezabezpieczonego połączenia i jest nieco szybszy. Niezabezpieczone połączenie jest zawsze zawsze co najmniej nieco szybsze niż połączenie zabezpieczone przy użyciu tego samego protokołu. „Test HTTP a HTTPS” jest celowo zwodniczy i wprowadza w błąd.
2015 r. O
3
Witryna zapewnia porównanie ilościowe z liczbami rzeczywistymi, a celem jest zachęcenie większej liczby osób do ochrony swoich użytkowników za pomocą HTTPS. Dotychczasowe opinie nas zabierają i zawsze mamy swobodę budowania powolnych, niepewnych aplikacji dla IE przez HTTP. Zawsze będę głosować za budowaniem szybkich, nowatorskich i bezpiecznych aplikacji internetowych dla Chrome / Firefox za pomocą HTTPS.
AnthumChris
2
Arytmetyka na httpvshttps.com wygląda źle: 1,7 sekundy w porównaniu do 34 sekund nie jest „95% szybsze”. Jest 20 razy szybszy lub 1900% szybszy. Powinien raczej porównywać prędkości niż czas trwania.
Pułkownik Panic
2
Test wprowadza w błąd i wprowadza w błąd. Na tools.ietf.org/html/rfc7540#section-3.2 nie ma powodu, dla którego HTTP / 2 nie może być używane w niezabezpieczonym połączeniu. Duże firmy dążą do uniwersalnego wykorzystania HTTPS. Przyczyny są różne. Ale fakt pozostaje. O ile na stronie nie ma danych osobowych, nie ma powodu, aby uruchamiać SSL. I chociaż tak w dzisiejszych komputerach, uzgadnianie SSL jest banalne. Jeśli zaczniemy to mówić, a to jest trywialne, rzeczy po prostu się ugrzęzną. Wykonaj test 1: 1 dla HTTP / 1.1 w porównaniu z HTTP / 1.1 SSL i HTTP / 2 w porównaniu z HTTP / 2 SSL. Następnie omów.
Shinrai,
23

Aktualna najwyższa odpowiedź nie jest w pełni poprawna.

Jak zauważyli inni, https wymaga uzgadniania i dlatego robi więcej objazdów TCP / IP.

W środowisku sieci WAN zazwyczaj opóźnienie staje się czynnikiem ograniczającym, a nie zwiększonym wykorzystaniem procesora na serwerze.

Pamiętaj tylko, że opóźnienie z Europy do USA może wynosić około 200 ms (czas podróży w obie strony).

Możesz to łatwo zmierzyć (w przypadku pojedynczego użytkownika) za pomocą HTTPWatch .

kalarepa
źródło
12

Oprócz wszystkiego wspomnianego do tej pory, należy pamiętać, że niektóre (wszystkie?) Przeglądarki internetowe nie przechowują buforowanej zawartości uzyskanej za pośrednictwem HTTPS na lokalnym dysku twardym ze względów bezpieczeństwa. Oznacza to, że z perspektywy użytkownika strony z dużą ilością zawartości statycznej będą się ładować wolniej po ponownym uruchomieniu przeglądarki, a z perspektywy serwera liczba żądań zawartości statycznej przez HTTPS będzie wyższa niż w przypadku HTTP.

Alexander
źródło
6
Wysłanie nagłówka „Cach-Control: max-age = X, public” spowoduje, że nowoczesne przeglądarki (właśnie przetestowane FF4, Chrome12, IE8, IE9) buforują zawartość. Zauważyłem jednak, że te przeglądarki wysyłają warunkowy komunikat GET, który może powodować dodatkowe opóźnienia w przypadku dodatkowych podróży w obie strony, szczególnie jeśli połączenie SSL nie jest buforowane (Keep Alive).
Clint Pachl,
6

Nie ma na to ani jednej odpowiedzi.

Szyfrowanie zawsze zużywa więcej procesora. W wielu przypadkach można to przenieść na dedykowany sprzęt, a koszt będzie się różnić w zależności od wybranego algorytmu. 3des jest na przykład droższy niż AES. Niektóre algorytmy są droższe dla szyfratora niż deszyfratora. Niektóre mają odwrotny koszt.

Droższy niż masowe krypto jest koszt uzgadniania. Nowe połączenia zużyją znacznie więcej procesora. Można to zmniejszyć dzięki wznowieniu sesji kosztem utrzymania starych tajemnic sesji, dopóki nie wygasną. Oznacza to, że drobne żądania od klienta, który nie wraca po więcej, są najdroższe.

W przypadku ruchu krzyżowego Internet może nie zauważyć tego kosztu w szybkości transmisji danych, ponieważ dostępna przepustowość jest zbyt niska. Ale na pewno zauważysz to w użyciu procesora na zajętym serwerze.

Darron
źródło
6

Mogę powiedzieć (jako użytkownik połączenia telefonicznego), że ta sama strona przez SSL jest kilka razy wolniejsza niż przez zwykły HTTP ...

Brian Knoblauch
źródło
6
Słuszna uwaga. Odkryłem również, że czasy ładowania przez sieć telefonii komórkowej (3G) są również 2x do 3x wolniejsze.
Clint Pachl,
Tak! Zaledwie półtora roku po tej odpowiedzi przeprowadziłem się do nowego domu i wreszcie mogłem przejść na DSL za mniej pieniędzy niż posiadanie linii POTS!
Brian Knoblauch
6

W wielu przypadkach wpływ uzgadniania SSL na wydajność zostanie złagodzony przez fakt, że sesję SSL można buforować na obu końcach (komputer i serwer). Na przykład na komputerach z systemem Windows sesja SSL może być buforowana do 10 godzin. Zobacz http://support.microsoft.com/kb/247658/EN-US . Niektóre akceleratory SSL będą także miały parametry pozwalające dostroić czas buforowania sesji.

Innym czynnikiem, który należy wziąć pod uwagę, jest to, że treści statyczne obsługiwane przez HTTPS nie będą buforowane przez serwery proxy, co może zmniejszyć wydajność wielu użytkowników uzyskujących dostęp do witryny za pośrednictwem tego samego serwera proxy. Można to złagodzić przez to, że zawartość statyczna będzie również buforowana na komputerach stacjonarnych, a statyczna zawartość HTTPS w programie Internet Explorer w wersji 6 i 7 buforuje buforowaną zawartość, chyba że otrzyma inne instrukcje (Menu Narzędzia / Opcje internetowe / Zaawansowane / Zabezpieczenia / Nie zapisuj zaszyfrowanych stron na dysk).


źródło
4

Zrobiłem mały eksperyment i otrzymałem 16% różnicy czasu dla tego samego obrazu z flickr (233 kb):

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

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

wprowadź opis zdjęcia tutaj

Oczywiście liczby te zależą od wielu czynników, takich jak wydajność komputera, szybkość połączenia, obciążenie serwera, QoS na ścieżce (konkretna ścieżka sieciowa pobierana z przeglądarki na serwer), ale pokazuje ogólną ideę: HTTPS jest wolniejszy niż HTTP, ponieważ wymaga wykonania większej liczby operacji (uzgadnianie SSL oraz kodowanie / dekodowanie danych).

Chaczatur
źródło
4
nie można utworzyć metryki analizy statystycznej na podstawie 2 żądań, po jednym dla każdego.
Tom Roggero,
3

Oto świetny artykuł (nieco stary, ale wciąż świetny) na temat opóźnienia uzgadniania SSL. Pomógł mi zidentyfikować SSL jako główną przyczynę spowolnienia dla klientów korzystających z mojej aplikacji przez wolne połączenia internetowe:

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

OrPo
źródło
2

Ponieważ badam ten sam problem dla mojego projektu, znalazłem te slajdy. Starsze, ale ciekawe:

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

Mircea Stanciu
źródło
Uważam, że uproszczone diagramy są pomocne, ale też trochę brakuje. Myślę, że Aby lepiej zrozumieć liczbę podróży w obie strony, ta strona dla http jest pomocna: blog.catchpoint.com/2010/09/17/anatomyhttp W takim razie, jak mogę powiedzieć dla https: dodajemy jedną podróż w obie strony.
Widok eliptyczny
2

Wydaje się, że jest tu nieprzyjemny przypadek: Ajax przez przeciążone Wi-Fi.

Ajax zwykle oznacza, że ​​limit czasu KeepAlive upłynął po powiedzmy 20 sekundach. Jednak wifi oznacza, że ​​(idealnie szybkie) połączenie ajaxowe musi odbywać wiele podróży w obie strony. Co gorsza, Wi-Fi często traci pakiety i są retransmisje TCP. W tym przypadku HTTPS działa naprawdę bardzo źle!

Richard
źródło
2

PORÓWNANIE WYDAJNOŚCI HTTP VS HTTPS

Zawsze kojarzyłem HTTPS z wolniejszym czasem ładowania strony w porównaniu do zwykłego starego HTTP. Jako twórca stron internetowych, wydajność strony jest dla mnie ważna i wszystko, co spowolni działanie moich stron, jest nie-nie.

Aby zrozumieć wpływ na wydajność, poniższy schemat przedstawia podstawowe wyobrażenie o tym, co dzieje się pod maską podczas zgłaszania żądania zasobu za pomocą HTTPS.

wprowadź opis zdjęcia tutaj

Jak widać na powyższym schemacie, istnieje kilka dodatkowych kroków, które należy wykonać podczas korzystania z HTTPS w porównaniu do zwykłego HTTP. Podczas składania żądania za pomocą protokołu HTTPS musi wystąpić uścisk dłoni w celu zweryfikowania autentyczności żądania. Ten uścisk dłoni jest dodatkowym krokiem w porównaniu z żądaniem HTTP i niestety niesie ze sobą pewne obciążenie.

Aby zrozumieć wpływ na wydajność i przekonać się, czy wpływ na wydajność byłby znaczący, wykorzystałem tę witrynę jako platformę testową. Udałem się do webpagetest.org i użyłem wizualnego narzędzia porównującego, aby porównać ładowanie tej strony przy użyciu HTTPS vs. HTTP.

Jak widać z tego miejsca, jest wynik testu wideo użyciem HTTPS miał wpływ na czas ładowania mojej strony, jednak różnica jest znikoma i zauważyłem różnicę jedynie 300 milisekund. Należy pamiętać, że czasy te zależą od wielu czynników, takich jak wydajność komputera, szybkość połączenia, obciążenie serwera i odległość od serwera.

Twoja witryna może być inna i ważne jest, aby dokładnie ją przetestować i sprawdzić wpływ wydajności na przejście na HTTPS.

Sunny SM
źródło
1
Ogólnie rzecz biorąc, przykład jest dobry, ale jest bardziej zaangażowany niż przedstawiony, szczególnie w przypadku Perfect Forward Secretrecy. W użyciu są również cztery klucze symetryczne.
zaph
0

Istnieje sposób, aby to zmierzyć. Narzędzie z apache o nazwie jmeter będzie mierzyć przepustowość. Jeśli skonfigurujesz duże próbkowanie usługi za pomocą jmeter, w kontrolowanym środowisku, z SSL i bez SSL, powinieneś uzyskać dokładne porównanie kosztów względnych. Byłbym zainteresowany twoimi wynikami.

dakrakot
źródło
-1

HTTPS ma narzut związany z szyfrowaniem / deszyfrowaniem, więc zawsze będzie nieco wolniejszy. Zakończenie SSL jest bardzo obciążające procesor. Jeśli masz urządzenia do odciążania protokołu SSL, różnica w opóźnieniach może być ledwo zauważalna w zależności od obciążenia serwerów.

Corey Goldberg
źródło
-1

Ważniejszą różnicą w wydajności jest to, że sesja HTTPS jest otwarta ketp, gdy użytkownik jest podłączony. „Sesja” HTTP trwa tylko dla pojedynczego żądania elementu.

Jeśli prowadzisz witrynę z dużą liczbą równoczesnych użytkowników, spodziewaj się zakupu dużej ilości pamięci.

Martin Beckett
źródło
2
Brak w HTTP 1.1. Połączenia pozostają otwarte przez długi czas.
Sklivvz
-1

To prawie na pewno będzie prawdą, biorąc pod uwagę, że SSL wymaga dodatkowego kroku szyfrowania, który po prostu nie jest wymagany przez HTTP inny niż SLL.

Orion Adrian
źródło
2
Że istnieje różnica w wydajności między tymi dwoma przypadkami.
David The Man,
2
Ale pytanie brzmi: „Czy są jakieś zasadnicze różnice w wydajności między http a https?”
Sklivvz
-1

HTTPS rzeczywiście wpływa na szybkość strony ...

Powyższe cytaty pokazują głupotę wielu osób w zakresie bezpieczeństwa witryny i szybkości. Uzgadnianie serwera HTTPS / SSL powoduje początkowe opóźnienie w nawiązywaniu połączeń internetowych. Występuje powolne opóźnienie, zanim cokolwiek zacznie się renderować na ekranie przeglądarki użytkownika. To opóźnienie jest mierzone w informacjach o czasie do pierwszego bajtu.

Narzut związany z uzgadnianiem HTTPS pojawia się w informacjach o czasie do pierwszego bajtu (TTFB). Typowe wartości TTFB wynoszą od poniżej 100 milisekund (najlepszy przypadek) do ponad 1,5 sekundy (najgorszy przypadek). Ale oczywiście z HTTPS jest o 500 milisekund gorszy.

W obie strony bezprzewodowe połączenia 3G mogą trwać 500 milisekund lub więcej. Dodatkowe podróże dwukrotnie opóźniają się do 1 sekundy lub dłużej. Jest to duży, negatywny wpływ na wydajność mobilną. Bardzo złe wieści.

Moja rada, jeśli nie wymieniasz poufnych danych, to wcale nie potrzebujesz SSL, ale jeśli lubisz witrynę e-commerce, możesz po prostu włączyć HTTPS na niektórych stronach, na których wymieniane są wrażliwe dane, takie jak logowanie i kasa.

Źródło: Pagepipe

svelandiag
źródło
-2

Przeglądarki mogą akceptować protokół HTTP / 1.1 z HTTP lub HTTPS, ale przeglądarki mogą obsługiwać tylko protokół HTTP / 2.0 z HTTPS. Różnice w protokołach od HTTP / 1.1 do HTTP / 2.0 sprawiają, że HTTP / 2.0 jest średnio 4-5 razy szybszy niż HTTP / 1.1. Ponadto w przypadku witryn, które implementują HTTPS, większość robi to za pośrednictwem protokołu HTTP / 2.0. Dlatego HTTPS prawie zawsze będzie szybszy niż HTTP po prostu ze względu na inny używany protokół. Jednak jeśli HTTP przez HTTP / 1.1 jest porównywany z HTTPS przez HTTP / 1.1, wtedy HTTP jest średnio nieco szybszy niż HTTPS.

Oto kilka porównań, które prowadziłem za pomocą Chrome (wer. 64):

HTTPS przez HTTP / 1.1:

  • Średni czas ładowania strony wynosi 0,47 sekundy
  • 0,05 sekundy wolniej niż HTTP przez HTTP / 1.1
  • 0,37 sekundy wolniej niż HTTPS przez HTTP / 2.0

HTTP przez HTTP / 1.1

  • Średni czas ładowania strony wynosi 0,42 sekundy
  • 0,05 sekundy szybciej niż HTTPS przez HTTP / 1.1
  • 0,32 sekundy wolniej niż HTTPS przez HTTP / 2.0

HTTPS przez HTTP / 2.0

  • Średni czas ładowania 0,10 sekundy
  • 0,32 sekundy szybciej niż HTTP przez HTTP / 1.1
  • 0,37 sekundy szybciej niż HTTPS przez HTTPS / 1.1
abcjme
źródło