Új hozzászólás Aktív témák

• #7305 dqdb nagyúr coco2 #7299

  Új Válasz 2019-07-24 09:22:59 #7305

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dqdb

  nagyúr

  válasz coco2 #7299 üzenetére

  A titkosítás teljesítményre gyakorolt hatását ketté kell bontani kapcsolatfelépítésre és a már felépített kapcsolaton keresztüli kommunikációra.

  Egy TLS kapcsolatnál a felépítés költsége az igazán jelentős, ez hálózati oldalon egy extra RTT körből jön össze a protokoll miatt (a TLS1.3 és a neked ajánlott HTTP/2 rendelkezik zero-RTT opcióval, szóval ez eliminálható), CPU oldalon egy privát kulcsos műveletből, ami a kriptográfiai műveletek között messze a legdrágább.

  Először lefuttattam egy Core i5-4590-en a kéznél levő őskövület, 2012-es OpenSSL 1.0.1c egy szálon futó sebességtesztjét:

  sign verify sign/s verify/s
  rsa 2048 bits 0.004417s 0.000136s 226.4 7361.3
  rsa 4096 bits 0.032730s 0.000511s 30.6 1955.3

  Aztán beugrott, hogy azóta bekerülhetett AES-NI támogatás az OpenSSL-be és a CNG-be is (saját céges teszt volt RSA aláírás témakörben, azon az OpenSSL-t használó C kód és a CNG-t használó C# kód ugyanazt a teljesítményszintet nyújtotta), ezért fordítottam OpenSSL 1.1.1c-t, és lemértem azzal is:

  sign verify sign/s verify/s
  rsa 2048 bits 0.000616s 0.000029s 1623.4 33982.7
  rsa 3072 bits 0.002859s 0.000060s 349.8 16806.2
  rsa 4096 bits 0.006546s 0.000104s 152.8 9661.8

  Az előrelépés látványos, és a fenti processzor egyetlen szálon 1623 aláírást tud végrehajtani másodpercenként a most elterjedt 2048 bites kulccsal. Mivel ennek a kulcsméretnek várhatóan már csak pár éve van, hogy átcsússzon nem ajánlottba (bár addig még rengeteg, hogy határozottan kerülendő legyen), bekerült a 3072 és 4096 bites kulcsméret is, azokat is érdemes nézegetni, hogy mire lehet majd 8-10 éven belül számítani. Az ECC opciókat kihagytam, azok CPU erőforrásban a 2048 és 3072 bites RSA között vannak valahol korábbi céges tesztjeink alapján.

  Ha már felépült a kapcsolat, akkor azon titkosítva mennek át az adatok, ez ma tipikusan AES128/AES256. Lássuk a teszteket (csak frissebb OpenSSL, itt 10% javulás volt csak a korábbihoz képest):

  type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
  aes-128 cbc 138254.38k 146752.33k 153316.83k 148921.83k 151887.48k 151125.24k
  aes-192 cbc 107198.00k 121410.13k 124547.81k 122201.29k 128566.72k 129934.99k
  aes-256 cbc 97304.25k 107784.19k 107225.75k 105430.48k 106100.13k 104593.96k

  Azaz a ma elterjedt AES128-cal egyetlen szál 138 MB/s sebességre képes a gépemen, ebbe az általad megadott 15 MB/s sebességigény röhögve belefér, egyetlen átlagosan erősnek nevezhető CPU egyetlen szála 11%-os terheléssel kiszolgálja a létrejött TLS csatornán a titkosítást, ezt én elhanyagolható erőforrástöbbletnek nevezném. Az AES128 várhatóan még sokáig velünk lesz ajánlott formában, itt erőforrás szempontjából a jövőre nézve a legrosszabb eset az AES256-ra áttérés jelenti.

  A fentiekből látható, hogy nem kell hatalmas szerverfarm ahhoz, hogy kiszolgálj 10000 kapcsolódást, elég egy szerver megfelelően sok maggal, de az is látható, hogy a HTTP Keep-Alive funkcióra egyszerűen kötelező építeni, mert ezzel a kapcsolatfelépítést tudod megspórolni, minden kéréshez külön TLS csatornát építeni drága hobbi és ahhoz tényleg kell az erőforrás (azonban mivel böngésző a túloldal, ezért ahhoz komolyan meg kell dolgozni, hogy kiiktasd azon az oldalon a keep alive-ot).

  10000 tps-hez a szervert megfelelően össze kell rakni. Felejtsd el az async idők előttről itt ragadt HttpListener-t, az ASP.NET Core-ra építs IIS vagy Kestrel alapokon (és azonnal kapsz HTTP/2 támogatást), ahogyan martonx ajánlotta, vagy ha pehelysúlyra vágysz HTTP/2 nélkül, akkor ott a uHttpSharp. A kérések kiszolgálását kizárólag async kód végezze kihasználva az aszinkron futás lehetőségét az összes IO műveletnél, mert ilyen terhelés töredékénél is luxusnak számít az 1 worker thread/kérés működés (az általad írt 1 process/kérés pedig teljes mértékben az).

  További olvasnivaló a témában itt.

Új hozzászólás Aktív témák