QUIC - この10年で最大のインパクトを与えたネットワークプロトコルを俯瞰する
QUICはこの10年で世界的な規模で使用されるようになった新しいプロトコルのひとつであり、ネットワークにもこれまでになかったインパクトをもたらしています。本セッションではQUICがネットワークに与える影響をご紹介しますが、これがQUICの導入を検討する開発者やネットワーク運用者のお役に立てれば幸いです。 本記事は、TechFeed Experts Night#13 〜 HTTP3/QUIC…Webプロトコル最前線のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 @yuyarinと申します。前職では@kensaku_komatsuさんと同じ会社でクラウドを作っていました。現職はモバイルキャリアでエッジコンピューティングの基盤を作っているので、ぜひ
QUICスタックとTLSライブラリの関係とOpenSSLの状況
図1: TLS over TCP と QUIC のスタック構造の比較はじめにQUICはTLSv1.3に相当するセキュリティを標準装備すると説明されます。図1はよく参照されるスタック構成ですが、TLSがQUICスタックの内部に埋め込まれています。縦に積み上げられた “スタック” になっていません。TLSの埋め込みは何を意味しているのでしょうか？本稿の前半ではTLSとQUICの関係と、TLSライブラリの使われ方をTLS over TCPと比較しながら解説します。後半ではOpenSSLのQUIC対応の状況についてふれます。 なお本稿で処理の流れを追う際は送信を中心に取り上げます。受信についても逆順で同様の処理が必要ですが解説は省略しています。 QUICとTLSv1.3の関係TLSには大きく分けて、ハンドシェイクプロトコルとレコードプロトコルがあります。前者は暗号スイートの調停や鍵交換、各種パラメ
QUICをゆっくり解説(1)：QUICが標準化されました | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを
TCPが遅すぎる？QUICを使おう！
「それ、QUIC使えないの？」 それがなんであれ、QUICを使うことを主張することで、みんなが「なんか良くわからないけど、TCPを置き換えたほうがいいのかな？」と思うようになるはず。全てのアプリケーションを、TCPの代わりにQUICを使うように修正するとなれば、この先10年間ぐらい、エンジニアみんなの仕事を作ることができます。業界愛ですね。 すでに、SSHやDNSのQUIC対応は始められています。既存のアプリケーションをQUICに対応させる難しさを調査するために、RustでBGP over QUICを実装してみました。 QUICの実装QUICは、TCPと同じく、パケットの再送、輻輳制御など、信頼性のある通信を実現するトランスポートプロトコルです。実装面の大きな違いは、TCPがオペレーティングシステムのプロトコルスタックの一機能として実装されるのに対して、QUICはアプリケーションで実装され
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
A QUIC Update for Node.js | Nearform
In March of last year, thanks to support from NearForm and Protocol Labs , I started the process of implementing Node.js support for the new QUIC protocol . This new UDP-based transport protocol is intended to ultimately replace the use of TCP for all HTTP traffic. Anyone familiar with UDP should, at this point, rightfully question why it is being used here. UDP is notoriously unreliable, with pac
QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記
OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
QUICの参考書―ゼロから作るRust言語による実装解説―Initial Packet編：MishProto