HTTP/2 入門
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
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ラストコール) (予定)
Tips - 静的リソースのURIに?をつけるべからず : 404 Blog Not Found
2014年03月14日20:00 カテゴリTipsCode Tips - 静的リソースのURIに?をつけるべからず Webを支える技術 HTTP、URI、HTML、そしてREST 山本陽平 であればなおのことこの実装はNG。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer BlogはてなブログではJavaScriptを配信する際には、上記のURLのように、?よりあとの部分にabc078624b2a746c618156847827166bのようなバージョンIDを付与しています。JavaScriptが変更
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 –
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 – Jxck HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。 GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します. Make the Web Faster: TCP Fast Open 3 Way Handshake TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状
GitHubのエラー・ページ
GitHubのStyleguideにエラー・ページのセクションがあるのを知った。それによると外部ファイルに依存しないように書いているらしい。CSSはstyle要素で、JavaScriptはscript要素で、画像ファイルはBase64エンコードしてData URIで、それぞれHTMLに直接埋め込むというスタイル。 実際に404のテンプレートでもちゃんとそうなっていた。フロントエンド脳なので、HTTPリクエストを減らして、エラー・ページのコストを下げたいのかなと単純に考えてしまったけど、Not Foundの連鎖を避けることとか外部ファイルがCDN経由の場合の確実性を上げることとかの方が強い理由のようだ。エラー・ページを単独で機能するようにしておき、エラー時に余計な負荷を与えないようにすることにより、より速やかに復帰できるように、ということになりそう。 HTTPエラー・ページの意味も重要だけど
HTTPエラーページに意味を持たせよう
Translation of: Adding meaning to your HTTP error pages! by Stuart Colville This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license はじめに ウェブ上で何かを検索しようとすると、既に存在しないページしか検索結果になく、それらへのリンクをクリックすることはよくあるだろう。その開いたページにデフォルトのエラー・メッセージの他に何も情報が載っていなかった場合、多くの人々は戻るボタンを押し次の検索結果を開こうとするだろう。 サイト製作者である我々はもっと訪問者に意味のあるエラーページを作成することができる。そうすればたとえエラーページであっても訪問者をサイトに留まらせ、彼ら
HTTPでHashやArrayを送る手法に仕様は存在しない……の? - ただのにっき(2013-09-15)
■ HTTPでHashやArrayを送る手法に仕様は存在しない……の? jQueryでこんなふうに書くと: $.post('/', { hash: { foo: 'hoge', bar: 'fuga'}, array: ['baz', 'piyo'] }); サーバ側でこんなふうに受け取れて(これはSinatra): post '/' do params.each do |key, val| puts "#{key}: #{val} as #{val.class}" end end ちゃんとHashやArrayとしてアクセスできる: hash: {"foo"=>"hoge", "bar"=>"fuga"} as Hash array: ["baz", "piyo"] as Array ああこりゃ便利だね、で済ましてもいいんだけど、HTTP POSTの中身なんてただのバイト列なんだから型の情
HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Studying HTTP