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

• #7303 martonx veterán coco2 #7299

  Új Válasz 2019-07-24 09:05:58 #7303

  Ú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

  

  martonx

  veterán

  válasz coco2 #7299 üzenetére

  Pont ez az, hogy nincsenek ott, legalábbis az asp.net core, nodejs, python, go és még ki tudja mennyi esetben, ha nem használsz felettük proxy webszervert (mint pl. apache, amit a legelső hsz-emben is írtam, hogy nem szabad ebben az esetben használni, mégis mindig ezzel jössz...), hanem csak önmagukban bután futtatod őket, hogy mondjuk figyelnek a 443-as porton, és ennyi, akkor ezek egyik általad problémásnak tekintett dolgot se fogják figyelni (csak amit direkt felparaméterezel bennük, hogy figyeljenek, mert használni akarod)

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