HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 奥氏はHTTP/3に対応したHTTPサーバ「H2O」の開発を行うだけでなく、IETFでHTTP/3の標準策定にも関わるなど、日本においてもっともHTTP/3に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで
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 ワーキング
HTTP and 5G (fixed1)
5GのNG-RANのOverallに関するTS、TS 38.300 V1.0.0をまとめた資料。 LTEのTS 36.300相当です。 まだ仕様未FIXでFFSのところも多いです。適宜バージョンアップしていきます。 不明点、最新の議論状況を反映できるところはできるだけ反映しました。 1 Scope 2 References 3 Abbreviations and Definitions 4 Overall Architecture and Functional Split 5 Physical Layer 6 Layer 2 7 RRC 8 NG Identities 9 Mobility and State Transitions 10 Scheduling 11 UE Power Saving 12 QoS 13 Security 14 Network Interfaces 15 Fu
HTTP3Study に行ってきたメモ #http3study - console.lealog();
HTTP3Study (new) - connpass まったく詳しくない分野で脳内補完が効かないのと英語なのとで、まったく自信のないメモに仕上がりました。 間違ってたらむしろ教えてほしいです！ HTTP/3 (英語セッション) from Mark Nottingham はじめに ここは最初にWGのMtgをした部屋なので不思議な感じ 仕様の解説というより、経緯とか周辺について話すよ 仕様について議論してるけど、全ての実装・ユースケースを把握してるわけではない いままで HTTP/0.9 今でも使われてるかも `GET /`だけみたいにシンプル HTTP/1.0 いくつかヘッダがついたりした まだシンプルだったあの頃 1993年とかそのへんからユースケースが混んできた なのでみんな拡張をはじめた UAとかHostとか HTTP/1.1 Transfer-Encoding: chunk gzi
Measurement Dashboard
Histogram Type Ping Count Sample Count Sample Sum Number of dates Selected Dates
詳解 HTTP/3 の翻訳に寄せて - inductor's blog
これは、mohikanz アドベントカレンダー20日目の記事です。 はじめに 詳解 HTTP/3(HTTP/3 explained)は、IETF のドラフトドキュメントを除いた HTTP/3 および QUIC に関する恐らくはじめての体系的な本です。 プロジェクトが始まったのは 2018 年 2 月で、当時は QUIC に関する詳細を主なターゲットにしていたようでしたが、同年 11 月に HTTP over QUIC が HTTP/3 となることが"ほぼ"確定した時点でタイトルも HTTP/3 explained と変わりました。 この本を書いたのは Daniel Stenberg というスウェーデンのデベロッパーで、一般には curl の作者として知られています。 恐らく、HTTP に関わる方であれは一度は使ったことがあるツール・ライブラリなのではないでしょうか。 ともかくとして、QUI
HTTP over QUICと、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog
[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICのAckとロスリカバリについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze
Cookieにかわる Sec-HTTP-State ヘッダの提案 - ASnoKaze blog
20190424 追記 IETFに提案仕様が提出されました https://tools.ietf.org/html/draft-west-http-state-tokens-00 Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。 現在はIETFのHTTPbis WGのMLに投稿されただけで仕様が正式にinternet-draftとして提出されたものではありません。まだまだどうなるかは全然わからない状態です。 この提案では、現在のCookieはセキュリティと非効率性とプライバシーの問題があると言っています。 現在のcookieは、Same-Origin-Policyとは異なりオリジンを超えて
CORSでハマったことまとめ - pixiv inside [archive]
こちらは ピクシブ株式会社 Advent Calendar 2014 の12/16の記事です。 こんにちは、エンジニアの@dnskimoです。 先日、はじめてCORSを実装する機会があったので、覚書がてらまとめておきたいと思います。 CORSとは Cross-origin resource sharingの略です。 読み方は「コルス」でいいんでしょうか？ Same-Origin Policyに弾かれずに、異なるドメイン間でリソースを共有する仕組みです。 2014年1月にW3C勧告になり、JSONPに替わる方法として徐々に普及してきているようです（要出典）。 アクセスコントロールの仕様も定義されているので、特定のサイトからのみ利用可能なAPIを作る際などに便利です。 JSONPのような「裏ワザ」的な方法ではないところも個人的に好みです。 詳しいことはネット上に素晴らしい記事がたくさんあるので
![CORSでハマったことまとめ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f6a93da881857fccf6161c1a2f6935458bfbb97/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20141216%2F20141216151227.jpg)
Big Sky :: net/http でレスポンスの内容を確認したいなら io.TeeReader を使おう
« Golang で物理ファイルの操作に path/filepath でなく path を使うと爆発します。 | Main | VimConf2017 に参加してきた。 » printf デバッグは便利だ。技術の後退と言われようと printf でないと解決できない事はまだまだたくさんあります。 今日は net/http でクライアントが得たレスポンスの JSON を確認したいといった場合に、どうデバッグしたらいいかを書いてみたいと思う。 Go のインタフェースは大よそ io.Reader もしくは io.Writer を使う様に設計されている。こうする事でプログラムがメモリを一度に沢山確保してしまわない様にしています。 package main import ( "encoding/json" "fmt" "log" "net/http" ) type Foo struct { ID
418 I'm A Teapot · Issue #14644 · nodejs/node
Node implements the 418 I'm a Teapot status code in a few places. Its source is RFC2324, Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). Note the title - HTCPCP/1.0 is not HTTP/1.x. HTCPCP was an April 1 joke by Larry to illustrate how people were abusing HTTP in various ways. Ironically, it's not being used to abuse HTTP itself -- people are implementing parts of HTCPCP in their HTTP stacks.
Multiple HTTP Authorization headers?
Is it possible to include multiple Authorization Headers in an HTTP message? Specifically, I would like to include one of Bearer token type (passing an OAuth access token) and one of Basic type (passing a base64 encoded username:password). GET /presence/alice HTTP/1.1 Host: server.example.com Authorization: Bearer mF_9.B5f-4.1JqM Authorization: Basic YXNkZnNhZGZzYWRmOlZLdDVOMVhk I see no reason th
AbemaTVの動画配信を支えるサーバーサイドシステム
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
CORS(Cross-Origin Resource Sharing)について整理してみた | DevelopersIO
ブラウザからAmazon S3に直接ファイルをアップロードしたい 先日、Amazon S3にファイルをアップロードするWebアプリを作ろうとして色々調べていたところ、S3にCORSという仕様のクロスドメインアクセスの設定をすることによって、ブラウザから直接S3にアップロードをする方法にたどり着きました。ただ、この方法を使うにあたってはCORSというクロスドメインアクセスの仕様をきちんと理解しておいた方が良さそうでしたので、まずはCORSについて自分なりに整理してみました。 なお、弊社の横田がCORSとS3についての記事を以前書いていますので、S3のCORSサポートに関する概要を知りたい方はそちらをご覧下さい。 CORS(Cross-Origin Resource Sharing)によるクロスドメイン通信の傾向と対策 CORS ブラウザでAjax通信を行う際には、同一生成元ポリシー(Same
先輩と覚える HTTP ステータスコード
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
ブログ記事: body 付きの DELETE リクエストについて｜ニモニク - 株式会社ニーモニック
今回は2つの問題が混在しているため、切り分けて考える必要がある。 まずは「body を含む DELETE」について。HTTP リクエストの DELETE は、クライアントからサーバにデータベースレコードなどの削除を要求するメソッドだが、Google App Engine においては、DELETE メソッドに body（オブジェクトボディ）を含めてはいけないようなのだ。では、RFC にはどう規定されているかといえば、section 9: Method Definitions を見る限り特に禁止しているわけでもない。 Stack Overflow を検索してみたところ、App Engine : 400 - Your client has issued a malformed or illegal request というそのものずばりな投稿があった。どうやら GAE のサーバは body を含む
Big Sky :: golang の http.Client を速くする
« Windows からも ssh でリモートコマンド実行したい、それ golang で出来るよ | Main | Re: Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる » この記事には幾らか正しくない部分がありました。後で訂正していきますが、ひとまず shogo82148 さんの解説記事も確認下さい。 http.Client はリクエスト毎に名前を引くので連続したアクセスはあまり速くない。 Goのhttp.Clientで名前解決結果cacheする楽な方法ないかな — fujiwara (@fujiwara) December 7, 2016 Go 1.8 からは Resolver が提供されるので、自前で簡単に名前引きのキャッシュを実装出来る。 Go 1.9 だった様です。 Go 1.8 Release Notes -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Building Protocols with HTTP
知っているようで知らないWebサーバアーキテクチャ
Teppei Sato on Twitter: "日本でいまだにprotocol-relative URLを推奨する言説が見られるの、多数あるGoogle HTML/CSS Style Guideの適当和訳サイトが、背景を考えずルールだけをコピペしているのが原因ではと推測"