TCPが遅すぎる？QUICを使おう！
「それ、QUIC使えないの？」 それがなんであれ、QUICを使うことを主張することで、みんなが「なんか良くわからないけど、TCPを置き換えたほうがいいのかな？」と思うようになるはず。全てのアプリケーションを、TCPの代わりにQUICを使うように修正するとなれば、この先10年間ぐらい、エンジニアみんなの仕事を作ることができます。業界愛ですね。 すでに、SSHやDNSのQUIC対応は始められています。既存のアプリケーションをQUICに対応させる難しさを調査するために、RustでBGP over QUICを実装してみました。 QUICの実装QUICは、TCPと同じく、パケットの再送、輻輳制御など、信頼性のある通信を実現するトランスポートプロトコルです。実装面の大きな違いは、TCPがオペレーティングシステムのプロトコルスタックの一機能として実装されるのに対して、QUICはアプリケーションで実装され
QUIC for SSH の提案仕様が出たよ - ASnoKaze blog
「QUIC-based UDP Transport for SSH」という提案が提出されています。 トランスポートプロトコルとしてQUICを利用することで、様々な恩恵を受けることが出来ます。 ユーザランドでコネクションが管理されるため、TCPとは異なりOSレイヤのでコネクション切断の影響をうけない IPアドレスが変わっても接続を維持できる(コネクションマイグレーション) 経路上の第三者による切断に耐性がある(QUICでは通信の切断にも鍵が必要) 個人的にも、SSHがQUIC上で動作することで切断しづらくなることを期待しております。 それでは、この仕様についてざっと見ていくことにしましょう。 ただ、まだまだこれから議論がされる提案仕様ですので、設計は大きく変わるでしょう。 QUIC-based UDP Transport for SSH の概要 QUICは内部的にTLSハンドシェイクを行って
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
「Debugging Modern Web Protocols with qlog」の紹介 - neko--suki’s blog
Robin Marx氏の論文「Debugging Modern Web Protocols with qlog」の紹介です。何かおかしなところがありましたら原文を確認いただけると。 概要 本論文では「Debugging Modern Web Protocols with qlog」では、QUICのデバッグ用に作られたqlog/qivsに対する ①QUICの開発者がqlog/qvisを採用したいと思うか？ ②qlog/qivsがQUICのデバッグに必要不可欠なものになるのか？ ③qlogはスケールするのか？ という3つの疑問への回答を、実装者へのサーベイ結果と著者の経験をもとに議論している。 論文: https://qlog.edm.uhasselt.be/anrw/files/DebuggingModernWebProtocols_Marx_ANRWReview_23apr2020.pdf
QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog
2020/06/01追記 まるっと解説記事を書き直しました asnokaze.hatenablog.com 目次 Status The Plan Versions Extensions Applications Other Things More Information 関連記事 QUICは現在IETFで標準化が進められているトランスポートプロトコルであり、HTTP/3はそのQUICの上で効率よくHTTPのメッセージをやりとりするプロトコルです。 ChromeやFirefox, Nginxなどがすでに実装を行っており、「相互接続テスト」を定期的に実施している。その他多くの実装があり、「Implementations」から確認ができる。 その標準化状況について、QUIC WGとHTTP WG両方のチェアを務めるMark Nottinghamが先週行われたIETFで発表した「Quick QUI
「Address-bound Token for QUIC」が面白い - ASnoKaze blog
FastlyのKazuhoさんが「Address-bound Token for QUIC」という提案仕様を出している、この中で出てくる "Sharing the Congestion Controller" という仕組みが非常に面白かったので、簡単に書いてみようと思う。 address-bound token この提案では、同一エンドポイント間で複数のQUICコネクションをはる際に、それらのコネクションが同一エンドポイント間でやりとりされていることを確かにする「address-bound token」というものを定義します。 最初のコネクションでサーバからトークンを払い出し、クライアントが続けて同じホスト名か、IPとポートが同じサーバにコネクションを確立する際にこのトークンを提出します。 (transport parameterでaddress_bound_tokenaパラメータを設定し
Why Fastly loves QUIC and HTTP/3
Talk to an expertTry Fastly free Why Fastly loves QUIC and HTTP/3 At Fastly, we're very intentional and selective about where we put our resources. And that means we care more about the kinds of projects we take on and the impact they have, rather than the quantity of projects. Which is why we’re thrilled to be so invested in QUIC, a new transport protocol for the internet that is more responsive,
QUIC開発日記 その1 参戦 - あどけない話
QUICや ああQUICや QUICや 詠み人知らず。QUICの実装の難しさに絶望した心境が詠まれたと伝う。 序章 2017年の7月ごろ、QUICの実装を始めました。Haskellの有名なシリアライザ/デシリアライザである binary や cereal では、バッファ操作ができないので、パケットヘッダを複雑に処理する必要がある QUIC には不向きです。そこで、Haskell HTTP/2 ライブラリから、バッファ操作の部分を切り出して、network-byte-orderというライブラリを作るところから始めました。 その矢先、上司とのミーティングでのこと： 上司「来年度開発室を立ち上げる前に、下期の半年間、現場に行って開発の現場を見てこい」 kazu「いいですけど、他のQUIC実装に遅れをとることになりますが、いいんですか？」 上司「いい。」 という訳で、QUICの開発は中断されました
Enjoy a slice of QUIC, and Rust!
During last year’s Birthday Week we announced early support for QUIC, the next generation encrypted-by-default network transport protocol designed to secure and accelerate web traffic on the Internet. We are not quite ready to make this feature available to every Cloudflare customer yet, but while you wait we thought you might enjoy a slice of quiche, our own open-source implementation of the QUIC
HTTP/3: From root to tip
HTTP is the application protocol that powers the Web. It began life as the so-called HTTP/0.9 protocol in 1991, and by 1999 had evolved to HTTP/1.1, which was standardised within the IETF (Internet Engineering Task Force). HTTP/1.1 was good enough for a long time but the ever changing needs of the Web called for a better suited protocol, and HTTP/2 emerged in 2015. More recently it was announced t
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って
HTTP-over-QUICと呼ばれていたプロトコルの名称がHTTP/3に | スラド
今まで「HTTP-over-QUIC」と呼ばれていたプロトコルが、「HTTP/3」に改称されるようだ。インターネット関連技術の標準化を行なっているInternet Engineering Task Force（IETF）ですでに議論が行われており、正式な承認が出たという（MozillaのエンジニアDaniel Stenberg氏のブログ、ZDNet Japan、マイナビニュース、Publickey）。 QUICはGoogleが開発しているネットワークプロトコルで、低レイテンシ、ネットワーク帯域の効率的な利用、暗号化サポートなどが特徴とされている（過去記事）。HTTP-over-QUICはQUICプロトコル上でHTTPを使ってWebブラウザとWebサーバー間の通信を行うもの。すでにChromeブラウザにはQUICが実装されており、Googleのサービスなどで使われている。
TLSとQUICハンドシェーク - Qiita
TLSと関係の深いQUICのハンドシェークについて紹介します。QUICの仕様は執筆時点の最新版draft-08を元にしています。TLSv1.3の仕様は、draft-22を元にしています。 https://tools.ietf.org/html/draft-ietf-quic-tls-08 https://tools.ietf.org/html/draft-ietf-quic-transport-08 https://tools.ietf.org/html/draft-ietf-tls-tls13-22 QUICはGoogleのQUICプロトコル(gQUIC)を元に、IETF QUIC WGで標準化が進んでいるプロトコルです。IETF版QUICはgQUICを元に開発されているのですが、すでにまったく別物になっていて互換性はありません。QUICはUDPの上で設計されています。 QUICは以下の
QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog
[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP
Google CloudのHTTPSロードバランサーがQUICプロトコルに対応
Webにおける通信で使われるHTTPもしくはHTTPSは、エラー訂正機能を備え信頼性の高い通信が期待できるTCPのプロトコルをベースにしています。しかしTCPは信頼性を高めるために効率を犠牲にしている面があります。そこで、HTTPSに最適化したより効率の良いプロトコルとしてGoogleが提唱し、IETFでの標準化が進められているのがQUICプロトコルです。 QUICはラウンドトリップの短縮や通信の多重化などを実現することで、より小さなレイテンシで効率の良い通信を実現しようとしています。 すでにGoogleは同社のWebサービスやChromeブラウザでQUICの実装を進めているため、ChromeブラウザでGoogleのサービスを利用している多くの場面ですでにQUICは使われています。 そしてGoogle Cloud Platformが提供するHTTPSロードバランサーでも、QUICに対応した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - h2o/quicly: A modular QUIC stack designed primarily for H2O
A quick look at QUIC | APNIC Blog
QUIC v2 · HTTP/3 explained
HTTP and 5G partial draft
Request in a QUIC way @shibuya.apk#28 - Speaker Deck
