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?
performance
http
https
Jim Geurts
źródło
źródło
https
jest zawsze wolniejszy niżhttp
(lub znacznie wolniejszy).Odpowiedzi:
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:
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.
źródło
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.
źródło
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.
źródło
disconnect
. Sprawdź dokumenty .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:
źródło
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.
źródło
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 .
źródło
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.
źródło
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.
źródło
Mogę powiedzieć (jako użytkownik połączenia telefonicznego), że ta sama strona przez SSL jest kilka razy wolniejsza niż przez zwykły HTTP ...
źródło
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
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
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).
źródło
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
źródło
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
źródło
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!
źródło
Istnieje wiele projektów, których celem jest rozmycie linii i sprawienie, by HTTPS był równie szybki. Jak SPDY i mod-spdy .
źródło
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.
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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
źródło
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:
HTTP przez HTTP / 1.1
HTTPS przez HTTP / 2.0
źródło