第2章 詳解QUIC ～ TCPに代わり下位層で使用する新しいトランスポートプロトコル | gihyo.jp
本章では、HTTP/3がTCPに代わって下位層で用いるQUICについて解説します。 QUICはトランスポートプロトコル QUICはトランスポートプロトコルです。QUICの説明に入る前に、トランスポートプロトコルついておさらいします。 TCP/IPの4階層モデル プロトコルは階層で役割を分担しています。TCP/IPの4階層モデルでは、アプリケーション層、トランスポート層、インターネット層、ネットワークインタフェース層に分かれます（図1）。 図1 TCP/IPの4階層モデル アプリケーション層に分類されるアプリケーションプロトコルは、クライアントやサーバで動作するアプリケーションの動作に関するデータやメッセージの通信ルールを規定します。たとえばSMTP（Simple Mail Transfer Protocol）は、メールを送信する通信ルールを規定しています。HTTPはこの層に属します。
HTTP/3｜Webエンジニアが知るべき新常識 ─ QUICやコネクションマイグレーションなどを学ぶ｜ハイクラス転職・求人情報サイト AMBI（アンビ）
HTTP/3｜Webエンジニアが知るべき新常識 ─ QUICやコネクションマイグレーションなどを学ぶ 新しい通信プロトコルとして普及が進んでいるHTTP/3については、エンジニアHubでも過去に概論的な記事を掲載しています。今回はアプリケーション開発者が自社サービスでHTTP/3を採用することを想定して、仕様上の留意点や、どのように使い始めるか、そしてサイトを制作する際に注意しておきたいポイントまでを藤吾郎（gfx）さんに解説していただきました。 本記事ではHTTP/3およびその通信プロトコルであるQUICを、アプリケーション開発者として活用する立場で入門します。HTTP/3は、HTTP/1.1とHTTP/2に続く新しいメジャーバージョンのHTTPプロトコルです。HTTP/3はHTTP/1.1およびHTTP/2を置き換えるポテンシャルを持っています。将来的にほとんどのインターネットトラフィ
HTTP上でL2VPNを実現する Proxying Ethernet in HTTP について - ASnoKaze blog
『Proxying Ethernet in HTTP』という仕様がGoogleのAlejandro R Sedeño氏から提出されています。これは、HTTP上でイーサネットフレームを送受信させるための仕様です。 背景として、IETFでは、Masque WGにおいてHTTPコネクション上で通信をトンネリングする仕組みの標準化を行っています。 RFC 9298 Proxying UDP in HTTP Proxying IP in HTTP すでに標準化が進められている、上記の仕様に続きイーサネットフレームを取り扱えるようにするというのが今回の提案です。ユースケースについては、L2VPNを実現するのに利用する例が挙げられています。 Proxying Ethernet in HTTPの概要 『Proxying Ethernet in HTTP』では、"RFC 9297 HTTP Datagram
QUICはTCPの代替ではない
ブルース・デイヴィーのブログより。 TCPの新しい決定的な仕様(RFC 9293)の公開は、私たちの世界ではとても大きな出来事で、このトピックに関する2回目の投稿をせずにはいられませんでした。特に、QUICとTCPを比較した議論に興味をそそられ、今週のニュースレターを書くきっかけとなりました。 TCPの過去と未来に関する前回の投稿では、QUICがTCPを置き換え始めるかも知れないという可能性について触れました。今週は、QUICは実際にはTCPが解決する問題とは異なる問題を解決しているので、TCPの置き換えとは別のものとして見るべきであると主張したいと思います。一部の(あるいはほとんどの)アプリケーションでは、QUICがデフォルトのトランスポートになるかも知れませんが、それはTCPが本来意図されていなかった役割に押しやられたからだと思います。なぜ私がそのような主張をするのか、一歩下がって考え
A Quick Look at QUIC Censorship
This blog post was originally published by the Open Technology Fund to disseminate Kathrin Elmenhorst’s QUIC-and-HTTP/3 censorship research as part of her ICFP fellowship with OONI. Last year, the new network protocol QUIC was introduced. QUIC is a general-purpose transport layer network with the goal of reducing latency compared to existing protocols. Since the introduction of QUIC, we have seen
The Illustrated QUIC Connection: Every Byte Explained
Every byte explained and reproduced QUIC is a secure UDP-based stream protocol that forms the basis of HTTP/3. In this demonstration a client connects to a server, negotiates a QUIC connection with TLS encryption, sends "ping", receives "pong", then terminates the connection. Click below to begin exploring. The connection begins with the client generating a private/public keypair for key exchange.
Accelerating UDP packet transmission for QUIC
Accelerating UDP packet transmission for QUIC Loading... This was originally published on Perf Planet's 2019 Web Performance Calendar. QUIC, the new Internet transport protocol designed to accelerate HTTP traffic, is delivered on top of UDP datagrams, to ease deployment and avoid interference from network appliances that drop packets from unknown protocols. This also allows QUIC implementations to
GitHub - aws/s2n-quic: An implementation of the IETF QUIC protocol
s2n-quic is a Rust implementation of the IETF QUIC protocol, featuring: a simple, easy-to-use API. See an example of an s2n-quic echo server built with just a few API calls high configurability using providers for granular control of functionality extensive automated testing, including fuzz testing, integration testing, unit testing, snapshot testing, efficiency testing, performance benchmarking,
NginxでのeBPFとSO_REUSEPORTを使ったQUICコネクション受信処理
はじめに2021年7月12日にNgnixブログに掲載された記事 “Our Roadmap for QUIC and HTTP/3 Support in NGINX” では、QUICとHTTP/3機能を2021年末にはメインラインへマージする計画が言及されています。現在のHTTP3/QUIC対応Nginxは、専用の開発ブランチ (nginx-quic)で開発が進められていますが、常に最新のリリース (7月26日時点で1.21.1)を取り込んでおり、HTTP3/QUIC以外の最新機能も利用可能です。筆者も、昨年から開発ブランチの動作を試しており、HTTP3/QUICでの大きな負荷をかけても良好なパフォーマンスを示しています。 さて、Nginxブログで言及されたHTTP3/QUICに関する機能の一つとして、“eBPFを使ったマルチプロセスアーキテクチャ” という項目がありました。QUIC特有の仕
QUICやHTTP/3で利用を避けるべき送信元ポートの議論についての考察 - show log @yuyarin
https://www.slideshare.net/yuyarin/quicnat 最近QUICとNATについての話をJANOGで紹介するぐらいQUICという新しいプロトコルに既存のネットワークインフラがどう適応していくかを考えています。 id:asnokaze さんの記事で紹介されているように、QUICやHTTP3/3で送信元UDPポートとして利用を避けるべきポートの議論が行われています。これはUDPのリフレクション攻撃のへの対応としてインフラストラクチャ側で特定のUDPポートのトラフィックをブロックしているケースがあるからです。実際に私もこのブロックの設定を行ったことがあります。 これはUDPというプロトコルの特性に起因する問題であり、QUIC, HTTP/3に限らずUDPを使うプロトコルに広くある問題です。 asnokaze.hatenablog.com QUICクライアント側で送
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の理解ができることを
WebSocketの次の技術！？WebTransportについての解説とチュートリアル - Qiita
概要 こんにちは。NTTコミュニケーションズのyuki uchidaです。普段はSkyWayというWebRTCプラットフォームの開発やWebRTCリサーチャー(見習い)をしています。 この記事は NTTコミュニケーションズ Advent Calendar 2020 の3日目の記事です。 昨日はMasaki Shimuraさんの記事、 「Threat Intelligenceの活用を促進するMISPの紹介」でした。 この記事は、WebSocketの次の技術ではないかと噂される、WebTransportの概要や双方向通信の歴史をまとめつつ、WebTransportのdatagram形式でデータを送信してみるチュートリアル記事です。 対象読者 WebTransportっていう技術を初めて聞いた人 WebSocketを使ったことがあり、不満がある人 双方向通信・リアルタイム通信について興味がある人
QUICとHTTP/3がIETFのラストコール。RFCによる標準化が間近に
IETFのQUICワーキンググループで標準化作業が進められてきたQUICとHTTP/3が、6月のQUICワーキンググループにおけるラストコールを経て、IETFのステアリンググループであるIESGのラストコールとして10月21日に受諾されました。 ラストコールとしてIESGが受諾したドキュメントは、QUICとHTTP/3の標準化に関わる以下の6つのドキュメントです。 QUIC: A UDP-Based Multiplexed and Secure Transport QUIC Loss Detection and Congestion Control Using TLS to Secure QUIC Version-Independent Properties of QUIC Hypertext Transfer Protocol Version 3 (HTTP/3) QPACK: Head
The Current Plan for Haskell QUIC - あどけない話
In recent days, QUIC is hot. As the following blog posts describe, the standardization of QUIC is now in the final stage and h3-29 (HTTP/3 over QUIC of draft 29) is out there: Chrome is deploying HTTP/3 and IETF QUIC How Facebook is bringing QUIC to billions A Last Call for QUIC, a giant leap for the Internet These blog posts motivated me to explain my plan for "Haskell QUIC" to the Haskell commun
How Facebook is bringing QUIC to billions
We are replacing the de facto protocol the internet has used for decades with QUIC, the latest and most radical step we’ve taken to optimize our network protocols to create a better experience for people on our services. Today, more than 75 percent of our internet traffic uses QUIC and HTTP/3 (we refer to QUIC and HTTP/3 together as QUIC). QUIC has shown significant improvements in several metrics
Developing QUIC Loss Detection and Congestion Control in Haskell - あどけない話
For last two months, I have been trying to implement "QUIC Loss Detection and Congestion Control" in Haskell. This blog article describes a brief summary on what I have done. ACK handling Before loss detection and congestion control were developed, QUIC packets were retransmitted, if necessary, by a simple resender lightweight thread based on timeout. The internal data structure was, of course, Pr
マイクロソフトが「SMB over QUIC」ファイル共有プロトコル実装中。VPNなしでもインターネット上で安全にファイルサーバへのアクセスを実現へ
マイクロソフトが「SMB over QUIC」ファイル共有プロトコル実装中。VPNなしでもインターネット上で安全にファイルサーバへのアクセスを実現へ マイクロソフトが次期Windows Serverに、HTTP/3のベースとなるQUICプロトコルを搭載する予定であることは先週の記事でお伝えしていますが、同社はこのQUICをファイル共有プロトコルであるSMBのトランスポート層に用いた「SMB over QUIC」も開発中です。 最初に同社がこれを明らかにしたのは、今年の3月に公開したブログ「SMB over QUIC: Files Without the VPN」ででした。 そして次期Windows Serverの開発状況を伝える先週のブログ「Announcing Windows Server vNext Preview Build 20201」でも、QUICをHTTP/3だけでなくSMBの
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ハンドシェイクを行って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
QUICとNATと – JANOG48 Meeting