HTTP/2で 速くなるとき ならないときたいへん遅ればせながら、YAPC::Okinawa 2018 ONNNASONで使用したスライドを、こちらにて公開する次第です。 ベンチマークの難しさとチューニングの奥深さ、楽しさを共有できた結果がベストトーク賞につながったのかなと考えています。ありがとうございました＆今後ともよろしくお願いいたします。 HTTP/2で 速くなるとき ならないとき from Kazuho Oku
ウェブページを1秒台で表示させる原理と方法 | Philosophy Guides
可能な限り最新の情報を反映していますが、追いつけていないこともあります。本サイトに採用していても、記事に反映できていない設定もあります。ページのソースを読んでいただくと、参考になる箇所があるかもしれません。 ウェブページの高速化に関するテクニックは、ネットで検索すれば簡単に見つけることができます。優れた情報も数多くありますが、｢CSSとJavaScriptはminify（ミニファイ）しておけばOK！」のような都市伝説も少なくありません。 そこで、ここでは本サイトのデザインリニューアル時に施した対策をもとに、一歩進んだウェブページの高速化の方法と、それを支える原理について、できる限り分かりやすく説明したいと思います。フロントエンジニアやデザイナーの方からすれば「んなもん知っとるわ！」な情報なのかもしれませんが、都市伝説を駆逐すべく、私なりの仕方で解説（≒加勢）したいと思います。 初めに結果を
HTTPキャッシュ。なぜ嫌われるのか。 - それマグで！
忌み嫌われるキャッシュたち。 キャッシュはどうやら、世間では嫌われ者のようです。 ScrenCaptured_2016-03-05_0.54.33 どうして、そんなにキャッシュされるのがイヤなんだろうか。 そもそもキャッシュってなんだっけ？ キャッシュとは、更新されていないコンテンツ（画像、CSS、JS、HTML、DNS結果など）を何度も何度も取得行かずに済むように、クライアントPC側で保存し再利用する仕組み。 つまり、転送量の節約。無駄な転送を控える。非常にエコな仕組みであります。 HTTPのエコ。HTTPはエコなプロトコルだったはず。 3つのR です。 Reduce Reuse Remix 。複数のファイルをそれぞれ、別途管理して１つのページとして構成(Remix)する仕組みです。 ブラウザのキャッシュを利用するメリット 通信料の節約、画面表示の高速化、戻るボタン対応など。 ブラウザは
HTTPとサーバ技術の最新動向
デブサミ2016登壇資料。サーバ技術の評価軸、HTTP/2、サーバプッシュ、HTTPS化の負荷、Brotli、サーバ内スクリプティングを俯瞰Read less
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
HTTP ページ上でのパスワード要求はやめましょう
[これは Mozilla のセキュリティエンジニア Tanvi Vyas 氏のブログ記事 No More Passwords over HTTP, Please! を同氏の許可を得て翻訳したものです] Firefox 46 Developer Edition は、HTTP ページ上でログイン情報の入力を求められた場合、開発者に警告を行います。 ユーザ名とパスワードの組み合わせは、ユーザの個人データへのアクセスを管理する手段です。Web サイトはこうした情報を注意深く扱い、パスワードは HTTPS のような安全な (認証、暗号化された) 接続を通じてのみ要求すべきです。しかし残念なことに、HTTP のような安全でない接続でユーザのパスワードが扱われている例が 非常に多く 見られます。このプライバシーとセキュリティの脆弱性を開発者の皆さんに知らせるため、最新の Firefox Develope
HTTPステータスコード451(政治的な検閲)が正式に承認される
mnot’s blog: Why 451? draft-ietf-httpbis-legally-restricted-status-04 HTTPステータスコード451がIETFで正式に承認された。近いうちにRFCとしても発行される。 元ネタは、Ray BradburyのFahrenheit 451(華氏451)というタイトルの小説で、これはディストピアな検閲社会を描いている。 451の意味は、403(禁止/権限がない)と似ているが、正確な意味は、ドラフトを引用すると、以下の通り。 このドキュメントはサーバーオペレーターが、あるリソース、あるいはあるリソースを含むリソース群に対し、閲覧を検閲するよう法的な命令を受け取った時に使うHypertext Transfer Protocol(HTTP)ステータスコードを規定するものである。 このステータスコードは、法律や一般大衆の雰囲気がサーバー
動画ストリーミングの仕組み
ogv.jsについて調べてた時に、Ajaxでストリーミングとか途中再生ってどうやってるのだろうと思ったので調べてみました。 Rangeヘッダ ogv.jsのデモをコンソールで見ると、動画のリソースを細切れにして取ってきていることが分かります。リクエストヘッダにRangeで取得バイト数の範囲を指定すると、その分がレスポンスとして返ってくるという仕組みです。(そういえば大昔に2chブラウザを作った時に、Rangeヘッダで差分取得をやったことがあるのを思い出しました。) ちなみにレスポンスは206 Partial Contentが返ってきて、ヘッダのContent-Rangeには取得した範囲とファイルサイズが書かれています。 HTTP/1.1 206 Partial Content Accept-Ranges: bytes Content-Length: 1048576 Content-Rang
NginxとFFmpegを利用したHTTP Live Streaming配信 – Rest Term
HTTP Live Streaming(HLS)配信の基本的な手順をまとめます。 去年の記事 「NginxのHTTP Pseudo-Streamingを試す」 ではNginxの疑似ストリーミング配信モジュールを試してみましたが、機能不足のため実サービスで使うのは難しいです。そのためWebサーバでストリーミング配信を行いたい場合は今回紹介するHLSなどの利用が推奨されます。 HTTP Live Streaming(HLS)とは Apple公式のドキュメントを読む方が理解は進むと思いますが、一応ここでも簡単に概要を。 HTTP Live Streaming (also known as HLS) is an HTTP-based media streaming communications protocol implemented by Apple Inc. HTTP Live Streami
HTTPセッションとTCP接続
ここで、HTTPのセッションとTCP接続との関係について簡単に説明する。TCPはもともと「接続」の概念の無いIPプロトコルの上に、高品質なデータの転送と「接続」という概念を組入れたプロトコルである。クライアントはサーバに対して80や8080といった受け付けポート番号で接続を開始する。いったん両者間の接続が確立されると、その接続のもとで各種のデータの交換が可能となる。データ交換が終了するとどちらかからこのTCP接続の開放をかける。TCP接続の確立と開放には複雑な両者間のIPによる手続きと時間を要する。 HTTP/1.0では通常下図のように要求／応答ごとにTCP接続がなされる。従って多くの要素からなるHTMLページをダウンロードするにはこれが相当のオーバヘッドとなる。 HTTP/1.1ではこれが改善され、どちらかがConnection: CloseをHTTPヘッダで指定しない限りHTTP応答の
JVNVU#92999848: HTTP リクエスト経由で設定された Cookie によって HTTPS 接続がバイパスされたり情報漏えいが発生する問題
JVNVU#92999848 HTTP リクエスト経由で設定された Cookie によって HTTPS 接続がバイパスされたり情報漏えいが発生する問題 RFC 6265 (旧 RFC 2965) は、いわゆる Cookie による HTTP セッションの状態管理の仕組みを規定しています。RFC 6265 を実装しているほとんどのウェブブラウザでは、HTTP リクエストを通じて設定される Cookie によって、HTTPS 接続がバイパスされたり、セッション情報が取得されたりする問題が存在します。 Cookie を用いて HTTP セッションの状態管理を行う場合、様々なセキュリティ上の問題が発生する可能性があることが知られています。 例えば、RFC 6265 の Section 8.6 には次のように記載されています。 Cookies do not provide integrity gua
HTTP/2時代のウェブサイト設計
CEDEC2021 ダウンロード時間を大幅減！～大量のアセットをさばく高速な実装と運用事例の共有～ SEGADevTech
RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ？のメモ - 小野マトペの納豆ペペロンチーノ日記
Web APIを開発していると、HTTPのヘッダについてRFCにおける規約を確認しなきゃいけない場面がたまにあるので、今回調べたことをまとめた。 HTTP/1.1のRFC HTTP/1.1のRFCといえば、長らくRFC2616であったが、2014年にRFC7230〜7239が発行され、2616は廃止された。 RFC2616 ハイパーテキスト転送プロトコル -- HTTP/1.1 RFC7230〜RFC2739 HTTP/1.1 — RFC 7230 〜 7235 — 日本語訳 両者の変更点については、RFC 723xの付録に記述されているので参照のこと。Content-MD5が廃止されたり、ちょいちょい面白い。文章としても723xの方が分かりやすくなっているので、一度目を通しておくことをお勧めする。 HTTP/1.1 が更新された | The Long Wait あたらしいHTTPの話をし
meta name="referrer"は、HTTPS→HTTPでもリファラを出す新しい仕様 | 初代編集長ブログ―安田英久
今日は、ちょっと技術的な話を。「meta referrer」という、リンクをクリックしてページ移動するときなどにリファラをどう送るかを、ページ側で指定できるタグの実装が進んでいるのです。 グーグルはHTTPSを推奨するけれども、リファラが……グーグルは、サイトがHTTPSかどうかを順位決定の要因とするなど、HTTPSを推奨しています。 でも、自分のサイトをHTTPSにすると、自分のサイトから非HTTPS（ふつうのHTTP）のサイトへのリンクをクリックしたときに、リファラが飛ばないんですよね。 これは、RFC 2616で、「セキュア接続のページから、非セキュア接続のページに移動するときは、リファラを送出するべきではない」と定められているからです（セクション15.1.3）。 とはいえ、Web担のようなメディアでは、「Web担のページから、うちのサイトにけっこう来る人いるんですよ」という反応も大
なぜ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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ブログ（Wireless・のおと）｜サイレックス・テクノロジー株式会社
HTTP/2入門
node.js HTTPサーバでApacheライクなログを記録する - Node.js/JavaScript入門
http://www.google.com/teapot