Ile narzutów nakłada SSL?

Wiem, że nie ma jednej, szybkiej odpowiedzi, ale czy istnieje ogólne przybliżone oszacowanie rzędu wielkości dla narzutu szyfrowania SSL w porównaniu z komunikacją niezaszyfrowaną przez gniazdo? Mówię tylko o przetwarzaniu komunikacji i czasie połączenia, nie licząc przetwarzania na poziomie aplikacji.

Aktualizacja

Jest pytanie o HTTPS i HTTP , ale jestem zainteresowany szukaniem niżej w stosie.

(Zastąpiłem wyrażenie „rząd wielkości”, aby uniknąć nieporozumień; używałem go raczej jako nieformalnego żargonu niż w formalnym sensie CompSci. Oczywiście, gdybym miał to na myśli formalnie, jako prawdziwy maniak myślałbym raczej binarnie niż dziesiętny! ;-)

Aktualizacja

Załóżmy, że na żądanie w komentarzu mówimy o wiadomościach o dużej wielkości (zakres od 1 000 do 10 000) przez trwałe połączenia. Zatem konfiguracja połączenia i narzut pakietów nie są znaczącymi problemami.

Rząd wielkości: zero.

Innymi słowy, po dodaniu TLS nie zobaczysz, że przepustowość spadnie o połowę ani nic podobnego. Odpowiedzi na pytanie „zduplikowane” koncentrują się głównie na wydajności aplikacji i porównaniu z narzutem SSL. To pytanie w szczególności wyklucza przetwarzanie aplikacji i ma na celu porównanie tylko wersji bez SSL z SSL. Chociaż optymalizacja ma sens z całościowego spojrzenia na wydajność, nie o to chodzi w tym pytaniu.

Głównym narzutem SSL jest uzgadnianie. Tam właśnie dzieje się kosztowna asymetryczna kryptografia. Po negocjacjach używane są stosunkowo wydajne szyfry symetryczne. Dlatego bardzo pomocne może być włączenie sesji SSL dla usługi HTTPS, w której nawiązywanych jest wiele połączeń. W przypadku długotrwałego połączenia ten „efekt końcowy” nie jest tak istotny, a sesje nie są tak przydatne.

Oto interesująca anegdota. Kiedy Google przestawił Gmaila na HTTPS, nie były potrzebne żadne dodatkowe zasoby; bez sprzętu sieciowego, bez nowych hostów. To tylko zwiększyło obciążenie procesora o około 1%.

Drugi @erickson: Kara za czystą prędkość przesyłania danych jest znikoma. Nowoczesne procesory osiągają przepustowość kryptowalut / AES na poziomie kilkuset Mb / s. Więc jeśli nie korzystasz z systemu o ograniczonych zasobach (telefon komórkowy), protokół TLS / SSL jest wystarczająco szybki, aby przesyłać dane.

Należy jednak pamiętać, że szyfrowanie znacznie utrudnia buforowanie i równoważenie obciążenia. Może to spowodować ogromny spadek wydajności.

Ale konfiguracja połączenia naprawdę zatrzymuje pokaz dla wielu aplikacji. Przy niskiej przepustowości, dużej utracie pakietów, połączeniach z dużymi opóźnieniami (urządzenie mobilne na wsi) dodatkowe obiegi wymagane przez TLS mogą spowodować, że coś powolnego stanie się bezużyteczne.

Na przykład musieliśmy zrezygnować z szyfrowania dostępu do niektórych naszych wewnętrznych aplikacji internetowych - były one prawie bezużyteczne, jeśli były używane z Chin.

Zakładając, że nie liczysz konfiguracji połączenia (jak wskazałeś w swojej aktualizacji), w dużym stopniu zależy to od wybranego szyfru. Narzut sieci (pod względem przepustowości) będzie znikomy. Narzut procesora będzie zdominowany przez kryptografię. Na moim mobilnym Core i5 mogę zaszyfrować około 250 MB na sekundę za pomocą RC4 na jednym rdzeniu. (RC4 jest tym, co powinieneś wybrać, aby uzyskać maksymalną wydajność). AES jest wolniejszy, zapewniając „tylko” około 50 MB / s. Tak więc, jeśli wybierzesz poprawne szyfry, nie uda ci się utrzymać pojedynczego rdzenia zajęty narzutem kryptograficznym, nawet jeśli masz w pełni wykorzystaną linię 1 Gbit. [ Edycja : RC4 nie powinno być używane, ponieważ nie jest już bezpieczne. Jednak obsługa sprzętowa AES jest obecnie obecna w wielu procesorach, co sprawia, że ​​szyfrowanie AES jest naprawdę szybkie na takich platformach.]

Jednak ustanowienie połączenia jest inne. W zależności od implementacji (np. Obsługa fałszywego startu TLS), doda okrążenia, które mogą powodować zauważalne opóźnienia. Dodatkowo drogie szyfrowanie odbywa się przy pierwszym nawiązaniu połączenia (wspomniany powyżej procesor może zaakceptować tylko 14 połączeń na rdzeń na sekundę, jeśli głupio użyjesz kluczy 4096-bitowych i 100, jeśli używasz kluczy 2048-bitowych). Przy kolejnych połączeniach często ponownie wykorzystuje się poprzednie sesje, unikając kosztownego krypto.

Podsumowując:

Transfer przy nawiązanym połączeniu:

• Opóźnienie: prawie żadne
• Procesor: pomijalny
• Przepustowość: pomijalna

Pierwsze nawiązanie połączenia:

• Opóźnienie: dodatkowe przejazdy w obie strony
• Przepustowość: kilka kilobajtów (certyfikaty)
• Procesor na kliencie: średni
• Procesor na serwerze: wysoki

Kolejne zestawienia połączeń:

• Opóźnienie: dodatkowa podróż w obie strony (nie wiem, czy jedna, czy wiele, może zależeć od implementacji)
• Przepustowość: pomijalna
• CPU: prawie żaden