新しいメディア転送プロトコル 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のストリームフォーマットを定義す
HTTP/3 DATAGRAMの優先度制御の提案仕様 - ASnoKaze blog
HTTP/3 DATAGRAMの優先度制御方式を定義した「HTTP Datagram Prioritization」が提出されました。 これについて簡単に眺めていきます。 目次 背景: HTTP/3 DATAGRAMについて 補足: HTTP/3の優先度 DATAGRAM の優先度 IETF 111の発表スライド 感想 背景: HTTP/3 DATAGRAMについて 下記の記事で書いた通り、HTTP/3の拡張仕様でパケロス時に再送を必要としないアプリケーションデータの送受信ができるようになっています。 asnokaze.hatenablog.com 特に、WebSocketの次世代版ともいわれるWebTransportや、HTTP/3コネクションをトンネルさせるMASQUEといった仕様で使われるものです。 WebTransport over HTTP/3のプロトコル仕様 - ASnoKaz
ブラウザからTCP, UDPソケットを操作するDirect Sockets API - ASnoKaze blog
2020/01/14: 実際に動くのを確認しました asnokaze.hatenablog.com (2020/09/17 注釈: Raw SocketsからDirect Socketsに名称が変更されました) ブラウザでTCP, DUPソケットを操作可能にする「Direct Sockets API」という仕様がW3CのWICGで議論されている。 また、blink-devでも「Intent to Prototype: Raw Sockets API」とプロトタイプの議論が行われている。 多くの方がセキュリティ上の懸念を抱くと思うが、ドキュメントでも慎重に検討すると書かれている。GithubでIssueを立てることも可能なので、思うことがある方は、まだまだ議論は始まったばかりでもあるので是非フィードバックされると良いと思う。(割と普通に聞いてもらえます) なお、Raw Socketsという名
TLS Encrypted Client Hello の暗号化(ECH)に関するメモ - ASnoKaze blog
2020/07/19 追記 最新版では仕様名が encrypting the entire ClientHello (ECHO)から、TLS Encrypted Client Hello(ECH) に変更されました 広域盗聴行為(RFC7258)への対策として、通信の暗号化が行われています。 TLS1.3からは、サーバ側証明書は暗号化されるようになり、観測者が得られる情報はIPアドレスやSNIから得られるホスト名などになりました。 このSNIの情報も暗号化するために、さまざな議論が行われました。その中で出てきた提案として「Encrypted Server Name Indication for TLS 1.3」という提案仕様があります。 この仕様はすでに、TLS WGでWG Draftとなっており第6版まで出てます。版が進む中で幾つかの変更があり、HTTPSSVCレコードの利用や、encr
QUICのAckとロスリカバリについて - ASnoKaze blog
QUICのAckとロスリカバリについて自分なりにまとめる。 （トランスポートは詳しくないのでご容赦ください） あわせて、関連記事もどうぞ 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と、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog とくに、ストリームやフレームに関しては下記記事を参照のこと asnokaze.hatenablog.com はじめに QUICで
HTTPメッセージに署名をするSignatureヘッダの標準化 - ASnoKaze blog
HTTPメッセージに署名をするSignatureヘッダを定義する「Signing HTTP Messages」という仕様が提案されています。 HTTPメッセージへの署名は、様々なところで行われていますが、それぞれ独自の方式で行われています。例えば、AWS APIを叩く際に利用する「Signature Version 4 Signing」や、OAuth2.0 DPoPなどでHTTPメッセージへの署名が行われています。 その他にも、WebPackagingで使用される「Signed HTTP Exchanges」といったところでも署名が行われています。 一方でTLSではだめなのかという話もありますが、TLSを用いることでHTTPメッセージの機密性および完全性は保護されますが、TLS終端プロキシなどを経由するとそれ移行の部分で通信の完全性は担保されません。クライアントとサーバ間でHTTPメッセー
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
