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?

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.

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.

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.

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.

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:

• Let's Encrypt Launch Schedule (16 czerwca 2015 r.)
• Szyfrujmy certyfikaty root i pośrednie (4 czerwca 2015)
• Draft Let's Encrypt Subscriber Agreement (21 maja 2015 r.)

Więcej informacji na Twitterze: @letsencrypt

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

• Czy TLS jest jeszcze szybki?
• Sieć przeglądarek o wysokiej wydajności, rozdział 4: Zabezpieczenia warstwy transportowej
• Overclocking SSL
• Anatomia i wydajność przetwarzania SSL

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

• Dlaczego HTTPS do wszystkiego? (Standard tylko HTTPS)
• Let's Encrypt (Internet Security Research Group)
• HTTPS Everywhere (Electronic Frontier Foundation)

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.

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 .

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.

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.

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

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

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

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

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

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!

Czy TLS jest już szybki? Tak.

• Zegarek: https://www.youtube.com/watch?v=0EB7zh_7UE4
• Czytaj: https://istlsfastyet.com/

Istnieje wiele projektów, których celem jest rozmycie linii i sprawienie, by HTTPS był równie szybki. Jak SPDY i mod-spdy .

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.

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.

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.

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.

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.

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.

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

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