QUICむけにAES-GCM実装を最適化した話 (1/2)

4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC

[kazuhooku]

書いた。CPUの気持ちになってプログラムを書く話です / 続きは http://blog.kazuhooku.com/2020/06/quicaes-gcm-22.html

[Nyoho]

ガロワ体(有限体のこと)を使うカウンタモードの実装の話。

[yosuke_furukawa]

元々QUICはTCPと比べるとCPUリソースの利用が大きいという話だったのが、この実装によって同程度になる事を検証した記事、AES GCMによってCPUのパイプライン処理が行われ効率化が図れると。

[boxshiitake]

AES-NIはAMDの実装ほうが高速なのでRyzenを使えばもっと速くなると思う

[d-kotani]

大変そうだけど超楽しそう

[moccos_info]

"QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事" の解説というか検証というか？

[wata88]

気になる

[programmablekinoko]

フーム