Ile narzuca SSL?

Question

Ile narzuca SSL?

Wiem, że nie ma jednej twardej i szybkiej odpowiedzi, ale czy istnieje ogólne ~~oszacowanie rzędu wielkości~~ przybliżenie kosztów szyfrowania SSL w porównaniu z niezaszyfrowaną komunikacją z gniazdem? Mówię tylko o przetwarzaniu łączności i czasie drutu, nie licząc przetwarzania na poziomie aplikacji.

Update

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

(zastąpiłem frazę " kolejność magnitude", aby uniknąć nieporozumień; używałem go jako Nieformalnego żargonu, a nie w formalnym sensie CompSci. Oczywiście, gdybym miał miał to na myśli formalnie, jako prawdziwy geek myślałem raczej o binarnych niż dziesiętnych! ;-)

Update

Na żądanie w komentarzu, Załóżmy, że mówimy o wiadomościach dobrej wielkości (zakres 1k-10k) nad trwałymi połączeniami. Tak więc konfiguracja połączenia i narzut pakietów nie są istotnymi problemami.

164

performance ssl sockets overhead

Author: Community, 2009-02-14

Source

3 answers

Popieram @erickson: kara za czystą prędkość transferu danych jest znikoma. Nowoczesne procesory osiągają przepustowość crypto / AES kilkuset MBit/s. Więc jeśli nie korzystasz z systemu ograniczonego zasobami (telefon komórkowy), TLS / SSL jest wystarczająco szybki, aby zawiesić dane.

Należy jednak pamiętać, że szyfrowanie znacznie utrudnia buforowanie i równoważenie obciążenia. Może to skutkować ogromną karą za wydajność.

Ale konfiguracja połączenia jest naprawdę ogranicznikiem show dla wielu aplikacji. Przy niskiej przepustowości, wysoka utrata pakietów, wysokie opóźnienia połączeń (urządzenie mobilne na wsi) dodatkowe objazdy wymagane przez TLS mogą sprawić, że coś powolnego stanie się bezużyteczne.

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

39

Author: max,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-06-02 23:04:32

Zakładając, że nie liczysz konfiguracji połączenia (jak wskazałeś w aktualizacji), zależy to w dużej mierze od wybranego szyfru. Napowietrzność sieci (pod względem przepustowości) będzie znikoma. Nadmiarowość procesora będzie zdominowana przez kryptografię. Na moim mobilnym Core i5 mogę szyfrować 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, dostarczając "tylko" około 50 MB / s. Więc jeśli wybierzesz poprawne szyfry, nie uda Ci się zachować pojedynczy rdzeń prądowy zajęty narzutami krypto, nawet jeśli masz w pełni wykorzystywaną linię 1 Gbit. [ Edit : RC4 nie powinien być używany, ponieważ nie jest już bezpieczny. Jednak wsparcie sprzętowe AES jest obecnie obecne w wielu procesorach, co sprawia, że szyfrowanie AES jest naprawdę szybkie na takich platformach.]

Ustanowienie połączenia jest jednak inne. W zależności od implementacji (np. wsparcie dla TLS false start), doda on trasy w obie strony, co może spowodować zauważalne opóźnienia. Dodatkowo, kosztowne krypto odbywa się przy pierwszym nawiązaniu połączenia (wyżej wymieniony procesor może akceptować tylko połączenia 14 na rdzeń na sekundę, jeśli głupio użyłeś kluczy 4096-bitowych i 100, jeśli używasz kluczy 2048-bitowych). Przy kolejnych połączeniach poprzednie sesje są często ponownie używane, unikając kosztownych krypto.

Podsumowując:

Transfer przy ustalonym połączeniu:

opóźnienie: prawie brak
procesor: nieistotny
Szerokość pasma: nieistotne

Pierwsze połączenie:

opóźnienie: dodatkowe przejazdy w obie strony
przepustowość: kilka kilobajtów (certyfikatów)
CPU na kliencie: medium
CPU na serwerze: high

Kolejne połączenia:

Szerokość pasma: znikoma
procesor: prawie żaden

10

Author: Jan Schejbal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-10-08 18:17:31

score 172 · Accepted Answer

Rząd wielkości: zero.

Innymi słowy, po dodaniu protokołu TLS nie zobaczysz swojej przepustowości zmniejszonej o połowę lub czegoś podobnego. Odpowiedzi na pytanie "duplikat" koncentrują się w dużym stopniu na wydajności aplikacji i tym, jak to porównuje się z obciążeniem SSL. To pytanie w szczególności wyklucza przetwarzanie aplikacji i stara się porównać tylko SSL Z SSL. Chociaż przy optymalizacji ma sens globalne spojrzenie na wydajność, to nie o to chodzi w tym pytaniu pytam.

Głównym obciążeniem SSL jest uścisk dłoni. Tam właśnie dochodzi do kosztownej kryptografii asymetrycznej. Po negocjacjach stosuje się stosunkowo wydajne szyfry symetryczne. Dlatego bardzo pomocne może być włączenie sesji SSL dla usługi HTTPS, w której odbywa się wiele połączeń. W przypadku długotrwałego Połączenia ten "efekt końcowy" nie jest tak znaczący, a sesje nie są tak przydatne.

Oto ciekawa anegdota. Kiedy Google przełączyło Gmaila na HTTPS, Brak dodatkowych zasobów; brak sprzętu sieciowego, brak nowych hostów. Zwiększyło to tylko obciążenie procesora o około 1%.