QUIC Version 2 の仕様 (RFC 9369) - ASnoKaze blog
(追記: 2023/06/01 RFC 9369になりました) 「QUIC Version 2」という仕様が提案されています。これは、「RFC 9000」で標準化されたQUIC v1と機能上はまったく同じものです。 この提案仕様の目的は、主にふたつあります。 硬直化(ossification)の問題を緩和し将来のQUICバージョンをインターネットでデプロイしやすくする バージョンネゴシエーションを実行できるようにする 11月に実施されたIETF 112の後に、QUIC WGのメーリングリストで、この仕様にWGとして取り組んでいくコンセンサスが得られました。現在はWG Draftとなっています。 なお、Version 2はまだ2番目のバージョンということで便宜上そう呼んでいるようです。バージョン番号の正式なアサインは後に行われます。 硬直化(ossification)の問題の緩和 硬直化とは
QUIC の Initial Packet を復号する
QUIC の Initial Packet のヘッダ保護解除とペイロード復号を Python で実装して復号してみます。 はじめに QUICパケットは暗号化通信をする際に (1) パケットのペイロードを暗号化して (2) パケットのヘッダーを暗号化します。 ここでは説明のために、前者を「暗号化」、後者を「ヘッダー保護」と呼ぶことにしています。 QUICパケットの復号は、ヘッダ保護を解除してからペイロードを復号します。 本記事では RFC 9000, RFC 9001 の仕様を元に、Initial Packetのヘッダ保護解除とペイロード復号をPythonで実装していきます。 1. Client Initial Packet を解析する Initial Packet は通常UDPで受信しますが、今回はすでにバイト列を受信したとして、その後の解析に注目していきます。 解析対象は RFC 900
QUIC event definitions for qlog の紹介 - Qiita
本記事ではIETFで標準化が行われている、QUICなどのロギングを行うフォーマットであるqlogの、QUICに関するイベントを定義している「QUIC event definitions for qlog」について紹介します。 QUIC event definitions for qlog とは qlogには発生したイベントを記録するeventという情報をロギングする仕組みがあります。「QUIC event definitions for qlog」では、qlogにQUICの情報をログとして記録するための、イベント定義が行われています。 具体手的には、eventに対する、イベントの種類を特定するためのname (category + event)と定義されたイベントをロギングするときに含む具体的なデータの定義が行われています。 それぞれのイベントには、重要性、dataに含まれるデータの定義、
curl wants to QUIC | daniel.haxx.se
The interesting Google transfer protocol that is known as QUIC is being passed through the IETF grinding machines to hopefully end up with a proper “spec” that has been reviewed and agreed to by many peers and that will end up being a protocol that is thoroughly documented with a lot of protocol people’s consensus. Follow the IETF QUIC mailing list for all the action. I’d like us to join the fun S
GoogleのQUICプロトコル：TCPからUDPへWebを移行する | POSTD
QUIC（Quick UDP Internet Connections）プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 （冗談で） TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastのcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの本当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ （ネットワークパケットの往復） が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 （出典： UDPを介
QUICの技術要素分解
この投稿はHTTP2 Advent Calendar 2014の18日目の記事です。 前日は HTTP2におけるProxyに関する議論 でした。 (あらすじ・前略) もっこすにはHTTPがわからぬ。もっこすは、ただのゲーマーである。ヴァナディールで市場価格操作に命を懸け、艦娘と遊んで暮らしてきた。けれどもトランスポート層のプロトコルについては、人一倍に敏感であった。 HTTP2とは直接関係ないので、念のため概要を説明してから進みます。HTTP2勉強会 #hｔtp2studyシリーズに参加されている方だと、もうご存知の方が多そうな気はしますが、とりあえず。 QUICとは、Googleが開発しChromiumに実装中のトランスポート層、すなわちTCPと同じ層のプロトコルです。Internet上で運用される独自実装トランスポートの常として、UDPで包んだ中に独自実装が入っています。 QUICの主
Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記
まずは免責事項。 1.Disclaimer 本ブログの記載内容は、筆者が独自に QUIC に関する Chromium のソースを分析し、検証した結果です。 QUICに関するGoogle からの公式な技術資料は現状公開されていません。 今後、QUICの技術仕様の公表で本ブログの記述内容が不十分だったり、誤っている可能性があります。ご理解の上お読みください。 (注： 2013年6月27日に Google は正式に QUIC 仕様を公開しました。「Experimenting with QUIC 」 本ブログの内容は大筋では間違っていませんが、当時の解析漏れやその後の開発等により、細かいところで異なっていたり、説明が大きく不足している部分もあります。お読みになる際はご注意ください。) 2. はじめに、 Googleがまたまた新しいプロトコルの実装を始めました。Web表示の高速化を目指した SPDY
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - alipay/quic-lb: nginx-quic-lb is an implementation of ietf-quic-lb, based on nginx-release-1.18.0, you can see the detailed code in this pull request
GitHub - h2o/quicly: A modular QUIC stack designed primarily for H2O