Fórum Root.cz
Hlavní témata => Server => Téma založeno: M. N. 18. 01. 2017, 22:26:26
-
Nazdar rooti.
Mám následující problém. Seshora od mgmnt přišel požadavek na překlopení webu na https. Jedná se o jeden poměrně čtený web. Začali jsme tedy polehoučku, nejdříve s webem, který servíruje statiku. Běží na soudobém HW HP/Intel, 18 GB paměti a v režimu http nemá nejmenší problém, vytížení 4 "jader" je okolo 10%, hlavně díky IO. Nastudoval jsem jak zkonfigurovat https na nginx sestavil velmi jednoduchý a přímočarý config s redirectem z 80 na 443. Rovnou jsem aktivoval http2 s představou, že takto bude méně spojení/ssl sessions.
V běžném provozu a s keepalive 2s obsluhujeme cca 30 req. paralelně s cca 900 otevřenými spojeními na keep alive.
Hlavní server, který servíruje obsah zůstal (prozatím a navenek) http.
V okamžiku spuštění naběhla obrovsky zátěž, takřka ke 100% na každém z jader. do několika minut zátěž klesla k 60% per jádro (top) Nicméně bylo to odpoledne v času klidu. Večer jsem musel potupně přepnout zpět na http protože server začal kolabovat - vracel 500.
Nicméně, zřejmě kvůli hlavičce Strict-Transport-Security máme doteď problémy u některých obrázků browsery tvrdošíjně trvají na https :(
DOTAZ: Proč je tam ta pekelná zátěž, když *všichni* se dušují, že její nárůst bude minimální. Evidentně je to buď pověra, nebo mám chybu v konfiguraci... Vnitřně si to vysvětluju tak, že TLS handshake s celou parádou je výpočetně náročná operace a "prostě je to tak" - ale celkem se mi s tím těžko smiřuje.
... a mimochodem, počet otevřených spojení na keepalive samozřejmě vůbec neklesl, ba právě naopak, ale to asi kvůli zpomalení servírování.
Máte někdo vysvětlení?
Dík za váš případný čas ...
M.
--SSL config ---
server {
listen 443 ssl http2;
server_name *****.cz;
ssl_certificate ****.crt;
ssl_certificate_key ****.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
ssl_dhparam /path/to/dhparam.pem;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
add_header Strict-Transport-Security "max-age=0; includeSubDomains" always;
root /static/html;
location / {
index index.html index.htm;
add_header Access-Control-Allow-Origin "*";
}
}
--- SSL -----
-
Jedná se o jeden poměrně čtený web. Začali jsme tedy polehoučku, nejdříve s webem, který servíruje statiku. ... Večer jsem musel potupně přepnout zpět na http ... Nicméně, zřejmě kvůli hlavičce Strict-Transport-Security máme doteď problémy u některých obrázků browsery tvrdošíjně trvají na https :(
Dej si ránu do hlavy a pak dej výpověď.
::) ::) ::)
-
ChaCha šifry jsou hodně pomalé (https://calomel.org/aesni_ssl_performance.html). Zkuste použít jen AES:
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5
Máte předgenerované 2048-bitové DH? Ta cesta (/path/to/dhparam.pem) je editovaná nebo nenastavená?
-
Máte předgenerované 2048-bitové DH? Ta cesta (/path/to/dhparam.pem) je editovaná nebo nenastavená?
... to je samozřejmě upraveno tady pro diskusi, DH je 2048b
-
Co vím, tak šifry založené na DH jsou obecně pomalé. Pokud se jedná o hodně navštěvované stránky dal bych do konfigurace šifer jen:
ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
To by mělo problém vyřešit.
-
Děkuju @sten a @mmenphis. Je to asi nakopnutí správným směrem. CPU na serveru má AES-NI, ale není to aktivní, takže to budu muset nechat přenastavit v BIOS a pak překontrolovat OpenSSL; podle toho odkazu od sten by tam měl být velmi výrazný rozdíl.
Napíšu sem jak to dopadlo.
M.
-
tvoj sef by mal hlavne pouvazovat nad testovacim servrom :) otestovat konfiguraciu a dat tam na skusku nejaky trafic s cca 30 spojeniami je celkom trivialny task. Clovek by sa tak vyhol tym 500vkam v produkcii :)
-
Osobně myslím, že je chyba někde jinde. Buď v konfiguraci, která tu není a nebo v backendu. Původní příspěvek bohužel neobsahuje výpis topu/htopu/ps ani kompletní konfiguraci, takže můžeme jen hádat. I při použití pomalejších šifer by zatížení nevyletělo na 100 % na takovém stroji při 30 spojeních za sekundu.
P.S. Ta Strict-Transport-Security hlavička je dobrá bota :-)
-
Ještě jednou díky za pomoc. Bylo to opravdu těmi šiframi. Zátěž se na serveru pohybuje, v průměru, do 20% per jádro, jedno je trvale vyšší než ta ostaní. Rezerva je ještě v AES-NI - ta přijde aktivovat později.
M.