ChromeのCache Transparencyに関するメモ - ASnoKaze blog
Chromeではキャッシュの効率改善を目的とした「Cache Transparency」という仕組みが検討されているようです。 これは、「Double-keyed HTTP cache」によってキャッシュヒット率低下を緩和します まだまだ実験を行っている段階ですが、簡単にメモとして残しておく 背景: Double-keyed HTTP cache Double-keyed HTTP cacheは、ユーザのプライバシーを保護するために、HTTPのキャッシュをサイトごとに分離する仕組みです。 簡単な例で見ていきましょう https://a.example のサイトは、https://cdn.exampleより js, css, 画像などのファイルを読み込みます https://b.example のサイトは、https://cdn.exampleより js, css, 画像などのファイルを読み
HTTPで再開可能なアップロードを可能にする提案仕様 - ASnoKaze blog
HTTPでファイルをアップロードする時、ネットワークの寸断などによりアップロードが中途半端に終わってしまうことがあります。アップロードが途中まで成功したとしても、一度切断するとそこから再開する方法は標準化されていません。 (PUTリクエスト + Rangeヘッダによる再開をサポートしているシステムもありますが標準化されてはいません。 参考URL) そこで、再開可能なアップロードの仕組みを定義した「Resumable Uploads Protocol」という仕様がIETFに提出されています。この仕様は、Transloadit Ltd, Apple Inc, Cloudflare などの方々の共著になっています。 Resumable Uploads Protocol の概要 「Resumable Uploads Protocol」は、一度中断しても再開可能なアップロード方式を定義しています。
ブラウザでTCPを直接送受信できるDirect Sockets APIについて - ASnoKaze blog
ブラウザから直接TCP・UDPで送受信する「Direct Sockets API」という仕組みが議論されています。 実験段階ですが、Chromeでは起動時にオプションを付けることでこの機能を有効にできます。今回はTCPの方で簡単に動作を見てみます。 Direct Sockets API Direct Sockets APIは、TCP・UDPで直接送受信可能にするAPIです。既存のアプリケーションプロトコル(SSHやIRC)、P2Pのような機能を実現可能になります。 もちろんセキュリティ上の問題もあるので、Chromeでは現状デフォルトでは有効になっていない機能です。 セキュリティ面についてはだいぶGithubリポジトリで議論されておりますので目を通すと良いでしょう。ローカルネットワークへの通信やSame-Origin-Policy(CORS)回避の話が上がっていますが、今回は細かくは紹介し
2021年 HTTPやQUICの最新動向振り返り - ASnoKaze blog
2021年について、プロトコル周りの動向を振り返っていきたいと思います。 今年は、個人的には次の2点がホットトピックと挙げられると思います。 QUICやHTTP/3を活用した応用系プロトコルの作業が進む プライバシー系の取り組みが活発化 それでは、個別に補足していきます。（IETFの動向がメインです。なお、個人的にキャッチアップできてないトピックもあります...） HTTP関連 まずは、HTTPです。HTTP/3の標準化が注目を浴びていますが、HTTP/1.1やHTTP/2なども改定作業が行われております。あわせて、HTTPセマンティクスは各バージョンから独立し、各バージョンから参照される形となりました。それぞれRFC出版の最終段階となっています。 書いた記事はここらへん HTTPのバージョンについて、現在のまとめ HTTPセマンティクス仕様の改訂版 まとめ HTTP/2の改定版仕様の変更
0.0.0.0/8のIPアドレスなどを利用可能にする提案仕様 - ASnoKaze blog
IPv4アドレスの枯渇すると言われ続けております。 「The IPv4 unicast extensions project」では、予約されているIPアドレスなどをユニキャストアドレスとして利用可能にし、4億1900万ものIPアドレスを追加することを謳っています。 実際、IETFで予約済みアドレスをユニキャストアドレスとして使用できるようにする提案を提出しています。 240.0.0.0/4 を利用可能にする提案 (draft-schoen-intarea-unicast-240) 0.0.0.0/8を利用可能にする提案 (0.0.0.0は除く) (draft-schoen-intarea-unicast-0) 127.1.0.0 ~ 127.255.255.255を利用可能にする提案 (draft-schoen-intarea-unicast-127) IPアドレスのホスト部が0のものを利
匿名かつ検証可能なPrivate Access Tokensの提案仕様 (プライベートアクセストークン) - ASnoKaze blog
「Private Access Tokens」という提案仕様が、Google, Apple, Fastly, Cloudflareの方々らの共著でIETFに提出されています。なお、すでに実装が進められているそうです。 この「Private Access Tokens」の一つのモチベーションに次のようなものがあります。 昨今、プライバシー保護の要求は高まっており、ユーザのIPアドレスを秘匿する、iCloud Private RelayやOblivious HTTPといった技術が出てきています。いままではIPアドレスベースでアクセスレートリミットを行っていましたが、 そのような環境でも、アクセスのレートリミットを設けたいというというのが一つの目的です。 それを、追加のユーザインタラクション無しに、かつユーザをトラッキングできないような匿名なトークンで行うというのがPrivate Access
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
