Content-Length: 321899 | pFad | http://b.hatena.ne.jp/motchang/http/
逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
HTTP/3が正式に勧告、脱TCP時代の幕開けか
インターネット関連技術の標準化を手掛けるIETF（Internet Engineering Task Force）は2022年6月6日（米国時間）、通信プロトコル「HTTP/3（HyperText Transport Protocol/3）」を「RFC 9114」として勧告した。HTTP/3はインターネット通信の多くを占めるWebにおける通信プロトコルの最新版である。 最大の特徴は、トランスポートのプロトコルに「QUIC（Quick UDP Internet Connections）」を採用した点。QUICは2021年にIETFで「RFC 9000」として勧告された。その名前が示すように、TCP（Transmission Control Protocol）ではなく、UDP（User Datagram Protocol）に基づくプロトコルだ。TCPが備えていた再送制御の仕組みや、TLS（Tr
有効期限切れのキャッシュをそのまま再利用させないための must-revalidate ディレクティブ - 30歳からのプログラミング
レスポンスヘッダのCache-Controlフィールドに設定できるディレクティブとして、must-revalidateがある。 これは、有効期限が切れたキャッシュをそのまま再利用することを許可せず、必ずオリジンサーバに問い合わせることを指示するディレクティブである。 逆に言うと、must-revalidateがない場合、既に有効期限が切れているキャッシュが再検証なしに使われてしまう可能性がある。 この記事では、must-revalidateの有無で動作がどのように変わるのか、CDN として Cloudflare を利用した構成を使って確認していく。 API の返り値をキャッシュしたいので、「キャッシュ レベル」を「Cache Everything」にしている。 また、クライアントのキャッシュが再利用されないように、シークレットウィンドウを使って動作確認している。 結論を先に書くと、must
Cloudflare CDN での Cookie の取り扱いと注意点 - 30歳からのプログラミング
CDN のエッジサーバにキャッシュされたコンテンツは、最初にアクセスしたクライアント以外にも利用される。 例えば、キャッシュが存在しない状態で A というクライアントがhttps://example.com/someにアクセスした場合、オリジンサーバがコンテンツを返す。その際、エッジサーバがそのコンテンツをキャッシュしたとする。そうすると、次に A がこの URL にアクセスした場合はもちろん、A 以外がこのエッジサーバ経由でアクセスした場合も、オリジンサーバへの問い合わせは行われず、エッジサーバがキャッシュを返すようになる。 そのため、レスポンスの高速化や、オリジンサーバの負荷軽減が見込める。 だがそれは、エッジサーバにキャッシュしたコンテンツは不特定多数のクライアントに閲覧される可能性がある、ということを意味する。 アクセス制限がないコンテンツならそれで構わないのだが、アクセス制限のあ
draft-ietf-httpbis-early-hints-00
Internet Engineering Task Force (IETF) K. Oku Request for Comments: 8297 Fastly Category: Experimental December 2017 ISSN: 2070-1721 An HTTP Status Code for Indicating Hints Abstract This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response. Status of This Memo This document is not an Internet Stan
実サービスにおけるHTTP/2ネゴシエーション数を調べる | GREE Engineering
こんにちは、インフラストラクチャ本部の後藤です。 先日、HTTP/2がRFC7540としてRFC化されました。RFCの中でも触れられている通り、日本の方も沢山関与されています。本当に皆様お疲れ様でした。 仕様としては一段落したHTTP/2ですが、実際に使っていく段階へと移ってく上で気になるのがどれ位のクライアントがHTTP/2に対応しているかということです。Google ChromeやFirefoxの最新版では既にHTTP/2対応していますが、全てのユーザがそれを使っているわけではありません。 そこで、今回は実際に弊社のサービスでHTTP/2対応クライアントの接続がどれ程あるのか調べてみました。(HTTP/2をサービスとしてサポートしているわけではありません。) ユーザエージェントから調べる方法もあるのですが、今回はALPNを元に調べました。 ALPNについて HTTP/2で通信する際のネ
2014年のWebパフォーマンスふりかえり - 来年以降の期待etc
ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ
なぜHTTPSはHTTPより速いのか
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
HTTP/2 入門
5. 現在までの流流れ 2012/01: IETF HTTPbis WGで次世代のHTTPの話が出始める 2012/06: HTTP/2の議論論を開始するための草案が提出される 2012/11: SPDYを議論論の開始点として策定が始まる 2013/01: 最初の草案がリリースされる 2013/08: 最初の実装向け草案がリリースされる 2014/05: ＜今はココ!＞ 2014/07: 最終草案リリース (WGラストコール) (予定)
GitHub - jimhigson/oboe.js: A streaming approach to JSON. Oboe.js speeds up web applications by providing parsed objects before the response completes.
This project is now archived. As of 2024, no code changes have been made in 5 years, and I (Jim) have not had the time to port it to new technology, or maintain it in a way that it deserves. For existing projects using this code, it should continue to work, but I would recommend looking for other solutions. I (Jim) still think there is a clear gap in the market for a streaming-first JSON parser th
Versioning your APIs
As I developed Flying Sphinx, I found myself both writing and consuming several APIs: from Heroku to Flying Sphinx, Flying Sphinx to Heroku, the flying-sphinx gem in apps to Flying Sphinx, Flying Sphinx to Sphinx servers, and Sphinx servers to Flying Sphinx. None of that was particularly painful - but when Josh Kalderimis was improving the flying-sphinx gem, he noted that the API it interacts with
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
Node.js で https をサポートする http proxy サーバを 80行で書いた - Qiita
新しく普通に使える http proxyサーバ を書いた。 https をサポートする http proxy サーバ 前回、Qiitaに投稿した記事「Node.jsによる必要最小限のhttpサーバとhttpsサーバとhttp proxyサーバ」では、 http proxyサーバ と言っても、本当に http だけしかサービスしてくれないので、 proxy 経由では、Google さえアクセスできず、あまり役に立ちませんでした。 そこで、今度は HTTP/1.1 の CONNECT メソッドをサポートしました。 これで Google も Facebook もアクセスできます。 またまた、必要最小限の機能しか実装していません。 なので、 注意点 がひとつあります。 この http proxyサーバ を動作させる前に、以下のリンクの情報をお読みください。 脆弱なホストを狙った不正中継を見抜く -
HTTP/2.0 Initial Draft Released
The first implementable draft of HTTP/2.0 was released on July 8th by the HTTPbis working group of the IETF. The 2.0 version of HTTP is based on the SPDY protocol developed by Google — in fact, the initial draft was a copy of the SPDY specification as a base for diffs. HTTP/2.0 is intended as an alternative to HTTP/1.1, rather than deprecating the old version. There is good reason for this: The ne
GmailがハマったSPDYの落とし穴 - ぼちぼち日記
1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY＆WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図１：2012年のハイプサイクル： 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo
FacebookがSPDYを始めました！ - ぼちぼち日記
1. SPDYが熱いです！ ちょうど先週末CROSS2013の 次世代Webセッション(プロトコル編) にパネラーとして参加させていただきました。 次世代Webの鍵となるWebSocket・SPDY・HTTP/2.0について熱い話ができとても満足しています。会場は満員で皆さんがとても興味を持って聞いていただいているのも十分感じることができました。 参加していただいた方、本当にありがとうございました。 2. LINEがSPDYを使っている セッションでは、つい最近 LINE が SPDY を使っているという発表( http://tech.naver.jp/blog/?p=2381 )について紹介し、その有用性についていくつかコメントをしました。 SPDYは、 Google が2011年より2年近くほとんどのGoogleサービスで実運用していますが、Google以外で世界的にメジャーな大規模の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/motchang/http/
Alternative Proxies:
Developing the fastest HTTP/2 server
How to version REST URIs
http2.0 勉強会 (2013/08/14 19:00〜)
Build and implement a single sign-on solution