新しいメディア転送プロトコル Media over QUIC Transport について - ASnoKaze blog
QUIC上でライブメディアなどを扱うプロトコルの標準化が、IETFのMoQ WGで進められています。 WarpやRUSHというプロトコル案が出ていましたが、プロトコルの設計が進み、コアプロトコルになる『Media over QUIC Transport (MOQT)』が登場しています。この仕様は、Twitch、Facebook(Meta)、Cisoco、Googleの方の共著となっています。 プロトコル スタック MOQTは、QUICプロトコルもしくはWebTransport上に位置するプロトコルです。その上に、Warpのようなメディアフォーマット・ストリームフォーマットを定義する仕様が乗っかります。(WarpとMOQTの役割が分割された感じになります。) (MoQ WG中間会議資料より) Warp 「WARP Streaming Format」は、MOQTのストリームフォーマットを定義す
QUIC is now RFC 9000
Why FastlyProductsServicesSolutionsDevelopersPartnersResourcesPricing QUIC is now RFC 9000QUIC is a new latency-reducing, reliable, and secure internet transport protocol that is slated to replace TCP, the most commonly used transport today. We’ve talked before about how we love QUIC and are deeply invested in making it a success because it aligns with our mission to build a faster, more resilient
quic-go が QUIC DATAGRAM に対応したので早速試してみる - aptpod Tech Blog
はじめに VPoP として弊社の製品全体を統括しております、岩田です。 弊社では以前から、自社製品が使用する通信方式の下回りとして QUIC を使用することができないか 、継続的に調査や検討を行ってきました。QUIC が HTTP/3 をメインターゲットとして最低限の仕様策定を進める方向になって以降、QUIC 検討に対する社内の熱量も多少減退してはいたものの、昨年の WebTransport 周辺の動きを受けて、再度勢いを取り戻しつつあります。 QUIC DATAGRAM は、QUIC を HTTP 向けの ベターTCP としてだけではなく、UDPベース であることを生かしたユースケースで利用できるようにするための追加仕様で、UDP Like な通信を導入することで QUIC の用途を映像伝送やゲームなどのリアルタイム通信に拡張しようとするもの です。QUIC DATAGRAM 自体は、提
QUICむけにAES-GCM実装を最適化した話 (2/2)
前半で述べたように、OpenSSLのAEAD暗号器は、長いAEADブロックの処理を前提に作られています。平文の暗号化処理においては理論上の上限にあたる速度を叩き出す一方、事前処理と事後処理、および呼出オーバーヘッドについては、あまり最適化が図られているとは言えません。これは、AEAD暗号の主な使用用途が、これまでTLSという長いAEADブロックを使う（ことが一般的な）プロトコルであったことを反映していると言えるでしょう。 一方、QUICにおいては、UDPパケット毎に独立した、短いAEADブロックを暗号化する必要があり、したがって、次のような速度向上の機会があることが分かります。 AEAD処理をひとつの関数にまとめ、事前処理と事後処理を、パイプライン化されスティッチングされた暗号処理と並行に走らせることができれば、AEADブロックが短くても、理論値に近いスループットを発揮するような、AES-
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
QUICの実装はTCP並みの効率を実現できるか？ Fastly奥氏らがベンチマークを紹介
現在標準化が進められている次世代HTTPの「HTTP/3」は、トランスポートプロトコルとして「QUIC」と呼ばれる新しいプロトコルを採用します。 現時点のHTTPはトランスポートプロトコルとして「TCP」が採用されています。その上で、可能な限り高速な通信が行えるようにさまざまな工夫や最適化が進められてきました。そしてもうこれ以上高速にしようとすると、TCPそのものを改善していくべきだろう、というところまできたのです。 それがHTTP/3で「QUIC」が採用される大きな理由といわれています。 TCPは内部で輻輳制御や再送などを自動的に行うことで通信が確実に行われることを保証してくれる便利なプロトコルですが、それゆえに、確実に通信が行われるまで待つ必要があるために通信環境によっては遅くなりがち、などの側面があります。 そこでQUICは、TCPのような通信の保証がない代わりにリアルタイム性の高い
HTTP のプライオリティが大きく変わろうとしている話（その他 IETF 105 雑感）
先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
