QUICはTCPの代替ではない
ブルース・デイヴィーのブログより。 TCPの新しい決定的な仕様(RFC 9293)の公開は、私たちの世界ではとても大きな出来事で、このトピックに関する2回目の投稿をせずにはいられませんでした。特に、QUICとTCPを比較した議論に興味をそそられ、今週のニュースレターを書くきっかけとなりました。 TCPの過去と未来に関する前回の投稿では、QUICがTCPを置き換え始めるかも知れないという可能性について触れました。今週は、QUICは実際にはTCPが解決する問題とは異なる問題を解決しているので、TCPの置き換えとは別のものとして見るべきであると主張したいと思います。一部の(あるいはほとんどの)アプリケーションでは、QUICがデフォルトのトランスポートになるかも知れませんが、それはTCPが本来意図されていなかった役割に押しやられたからだと思います。なぜ私がそのような主張をするのか、一歩下がって考え
Googleが開発してるらしい QUIC as a VPN (QBone)について (2020年更新) - Qiita
(落ちの無い話です) [追記] IETF107 (2020/03/25)において、Googleでの利用例が共有されました。それについて、記事最後に追記しました。 公式な情報はまだないが、GoogleがQUICコネクションをVPNとして利用する「QUIC as a VPN (QBone)」なるものを作ってるのは窺い知ることができる。 2017年6月に、GoogleでQUICの開発に携わっているIan Swett氏より「QUIC Messages」という提案書が出ている。この提案書の、提案背景の章で「QUIC as a VPN (QBone)」は登場する。 Today, most production QUIC traffic is HTTP. However, developers are actively working on running WebRTC over QUIC (aka Q
QUIC開発日記 その1 参戦 - あどけない話
QUICや ああQUICや QUICや 詠み人知らず。QUICの実装の難しさに絶望した心境が詠まれたと伝う。 序章 2017年の7月ごろ、QUICの実装を始めました。Haskellの有名なシリアライザ/デシリアライザである binary や cereal では、バッファ操作ができないので、パケットヘッダを複雑に処理する必要がある QUIC には不向きです。そこで、Haskell HTTP/2 ライブラリから、バッファ操作の部分を切り出して、network-byte-orderというライブラリを作るところから始めました。 その矢先、上司とのミーティングでのこと： 上司「来年度開発室を立ち上げる前に、下期の半年間、現場に行って開発の現場を見てこい」 kazu「いいですけど、他のQUIC実装に遅れをとることになりますが、いいんですか？」 上司「いい。」 という訳で、QUICの開発は中断されました
QUICの仕様におけるアンプ攻撃対策 - Qiita
HTTP over QUIC (HTTP/3) がUDPベースとなるニュースを見て、いわゆるAmplification攻撃(アンプ攻撃, 増幅攻撃などとも)について気になってる人もいるようなので、初心者ながら簡単に調べる。 なお、トランスポートプロトコルであるQUIC側の機能であり正確にはHTTP3で提供される対策機能ではない。 IETF版QUIC draft-16ベースの説明になります。 QUICについて 手前味噌ですが、前提となるQUICに関する資料は下記を参照 QUICの話 (QUICプロトコルの簡単なまとめ) HTTP over QUICと、その名称について (HTTP3について) QUICのコネクションマイグレーションについて アンプ攻撃とは そもそもアンプ攻撃とは、送信元アドレスを攻撃対象となる対象のIPに偽装したUDPパケットをサーバに送信することによって、サーバからの応答を
HTTP/3 | daniel.haxx.se
The protocol that’s been called HTTP-over-QUIC for quite some time has now changed name and will officially become HTTP/3. This was triggered by this original suggestion by Mark Nottingham. The QUIC Working Group in the IETF works on creating the QUIC transport protocol. QUIC is a TCP replacement done over UDP. Originally, QUIC was started as an effort by Google and then more of a “HTTP/2-encrypte
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
Kazuho's Weblog: 次世代プロトコル（QUIC etc.）のセキュリティとプライバシー @ #builderscon
９月６日より開催中の builderscon 2018 において、登壇の機会をいただき、インターネットのトランスポート層プロトコルについてセキュリティやプライバシーに関わる設計がどのように進めてられているか、TLS と QUIC を中心に発表しました。 QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。 聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。 PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記
The Road to QUIC
QUIC (Quick UDP Internet Connections) is a new encrypted-by-default Internet transport protocol, that provides a number of improvements designed to accelerate HTTP traffic as well as make it more secure, with the intended goal of eventually replacing TCP and TLS on the web. In this blog post we are going to outline some of the key features of QUIC and how they benefit the web, and also some of the
GoogleのQUICの論文が知見の塊だった - ASnoKaze blog
20181107追記 QUICプロトコルについての概要は別途記事を書きました asnokaze.hatenablog.com 概要 ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。 この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。 すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。
DNS over QUICの提案仕様が出た - ASnoKaze blog
2020/04/28 追記 仕様の名前が少々変わりましたが、WG Draftとなり作業は引き続き続けられています。 「Specification of DNS over Dedicated QUIC Connections」 QUICの標準化とアプリケーションレイヤ IETFでQUICの標準化が活発に行われており、トランスポート・TLS・HTTP各レイヤのドラフト仕様の改定が進められております。 標準化を行うにあたって当初より、DNSのトランスポートとしてQUICを使用したいという話題は出ていましたが、QUICワーキンググループのチャーターでは、まずはQUICのアプリケーションレイヤとしてHTTPの標準化を行ってから他のアプリケーションプロトコルについて進める旨書かれている。 とはいえDNS over QUICをやりたい人はいるようで、4/11にインターネットドラフトが出されている。共著者
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: A UDP-Based Secure and Reliable Transport for HTTP/2
Network Working Group J. Iyengar Internet-Draft I. Swett Intended status: Informational Google Expires: December 19, 2015 June 17, 2015 QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2 draft-tsvwg-quic-protocol-00 Abstract QUIC (Quick UDP Internet Connection) is a new multiplexed and secure transport atop UDP, designed from the ground up and optimized for HTTP/2 semantics. While built wi
Technical Overview of QUIC
QUIC is a new transport protocol developed by Google that aims to solve issues with TCP and TLS by multiplexing streams over UDP. It includes features like stream multiplexing, connection migration, 0-RTT connection establishment, and forward error correction. The document provides technical details on QUIC including its version history, wire format specifications, frame types, cryptographic hands
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - cloudflare/quiche: 🥧 Savoury implementation of the QUIC transport protocol and HTTP/3
https://www.ietf.org/proceedings/93/slides/slides-93-hopsrg-6.pdf