第3会FRESH勉強会で発表予定のスライド。HTTPについて詳しくない人のために HTTPの概要から先日RFC化されたHTTP/2の新機能、使いどころを解説します。
21世紀のエンジニアのためのHTTP/2入門 | κeenのHappy Hacκing Blog
第3会FRESH勉強会で発表予定のスライド。HTTPについて詳しくない人のために HTTPの概要から先日RFC化されたHTTP/2の新機能、使いどころを解説します。
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
HTTPステータスコードに追加された「308」とは？
2015年4月6日、HTTPの新たなステータスコードである「308 (Permanent Redirect)」がインターネット技術の標準化団体であるIETFによって「The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)」（RFC 7538）として策定された。 HTTPのステータスコードには、成功を示す200番台、ユーザー側が原因の失敗を示す400番台、サーバー側が原因の失敗を示す500番台などがある。今回仕様が追加された308を含む300番台は「リダイレクション」用に割り当てられており、HTTPの要求を完了させるために要求先とは異なるリソースを参照する必要があることをサーバーがクライアントに伝えるときに使われる。 もっとも使われるのは「304 (Not Modified)」だ。クライアントが持つキャッシュよ
Apache HTTP Server: MPMパラメータ チートシート
こんにちは滝澤です。たまにはapacheネタということで一つ。 Apache HTTP ServerのパラメータチューニングではMaxClientsなどのMPM（マルチ プロセッシング モジュール）関連のディレクティブの設定値を調整することが多いです。本記事ではMPM関連のディレクティブのデフォルト値やディレクティブ間の関係を表にまとめたので紹介します。 注意事項 UNIX系OSにおける説明となります。バージョン2.2系および2.4系の両方について説明します。 関係式においてバージョン2.4系の場合はMaxClientsをMaxRequestWorkersに置き換えて読んでください。 ディレクティブ名には公式サイトのリンクを張っています。公式の説明も確認してください。 デフォルトの欄で括弧付きものはそのディレクティブそのものは設定不可ではあるが、内部的に設定されているデフォルト値を示してい
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
HTTPパーサにおけるSSE4.2最適化の威力と注意点 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、サイボウズ・ラボの光成です。 PicoHTTPParserは@kazuhoさんたちが開発している高速なHTTPパーサです。 同じ作者によるHTTPサーバH2Oにも使われています。 11月4日の開発ブログによると、その時点でNode.jsなどに使われているhttp-parserの10倍程度の速度を誇るそうです（現在はhttp-parserも速度向上しその差は縮まりました。それでも4倍以上の差があるようです）。 該当ブログにはその高速化のためのノウハウが書かれていて大変興味深いです。ただIntel系CPUに搭載されているSIMD命令は用いられていませんでした。今回、@kazuhoさんと一緒に文字列処理専用のSSE4.2を用いることで1.7～1.9倍の高速化を達成しました（Improving Parser Performance using SSE Instructions (in
HTTPの標準規格が15年ぶりに改訂、文書を6分割し改善仕様を盛り込む
図●新たに公開されたRFC7230の冒頭部分 RFC2616を破棄（Obsoletes）したことが示されている。 Webブラウザーによるアクセスをはじめ、スマートフォンアプリや家電機器、IoT（Internet of Things）デバイスの通信など、世の中のいたるところで使われている最も重要な基本プロトコルの一つ「HTTP」（HyperText Transfer Protocol）が6月上旬、実に15年ぶりに改訂された（プロトコルのバージョン自体は1.1のまま）。 インターネット技術の標準化団体であるIETF（Internet Engineering Task Force）が2007年に立ち上げた「HTTPbisワーキンググループ（WG）」が規格改訂に携わった。 1999年の公開以来、長らくインターネットアプリケーション開発者のバイブルとして使われてきた「RFC2616」（RFCはreq
グーグル、HTTPS接続サイトの優遇を検討か
Googleは、暗号化を採用しているサイトの検索順位を上げることを検討しているという。The Wall Street Journal（WSJ）が報じた。 GoogleのDistinguished Engineerで、検索結果からスパムを取り除くウェブスパムプログラムを統括するMatt Cutts氏の発言をもとに、WSJは同氏が最近のカンファレンスでその可能性を「ほのめかした」と報じている。 Googleの広報担当者は、現時点で発表することはないと述べた。 Googleの検索順位のアルゴリズムは、サイトの表示順位を上げ下げする変数が多く、複雑なことで知られる。上記のような変更があった場合、少なくとも短期的には、Googleの検索順位を操作しようとするサイトに有利になる可能性がある。 もっとも、ウェブページへのSSL/TLS暗号化の導入拡大は多くの専門家が推進していることであり、Googleは
間違いだらけのHTTPセッション管理とその対策
(Last Updated On: 2018年10月12日)HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。 まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。 参考： 知らないと勘違いする「合成の誤謬」の罠 開発者は必修、SANS TOP 25の怪物的なセキュリ
SPDY対応するために考えてること - ASnoKaze blog
概要 若者の間でも、SPDYに対応するためのノウハウが共有されていないことは有名である。 そこで、中規模サイトでSSL化、SPDY対応という観点で個人的に考えていることを書き出してみる。 HTTP2は暗号化の議論や、アップグレード、ヘッダ圧縮など細部が違うため別途考慮する必要があるが、今回の話も概ね適応できるだろう。 今回主に考える構成としては、以下の様に前段にリバースプロキシを置く構成である。 幾つかSPDY対応しているソフトウェアがあるが、現状NGINXが無難だと考えているので、NGINX前提で話を進める。 （SPDY対応のロードバランサ製品の導入も出来るだろうが、今回は考慮しない） SSL化とSPDY対応 SDPYではSSL化が必須である。これは、SSLハンドシェイク時にHTTPSとSPDYのどちらで通信を行うかネゴシエーションしているためである（TLS上でのプロトコルネゴシエーショ
非暗号化HTTPはもうすぐ消える？
非暗号化HTTPはもうすぐ消える？ 2013年を通して、米国家安全保障局（NSA）の情報収集活動に関する驚くべき事実が数多く明るみに出た。本質的な信頼性の基盤として長年使われていたプロトコルの、その信頼性が失われていることを受け、インターネット標準化コミュニティは暗号化の必要性に注目するようになった。とりわけ「HTTP 2.0」ではデフォルトで暗号化するべきとの議論が持ち上がっている。トレンドマイクロは、「これは全体的に見て好ましい傾向だが、考慮すべき課題がある」としてブログで主に以下の4点を指摘した。
今夜つける HTTPレスポンスヘッダー （セキュリティ編） - うさぎ文学日記
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です） SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこ
HTTPリクエスト数削減テクニック2： CSS Sprite編
はじめに こんにちは、クラスメソッド株式会社の野中です。 HTTPリクエスト削減テクニックの紹介に入り、前回の『リクエスト数削減テクニック1：インラインイメージ編』では、インラインイメージについて紹介しました。本記事では「CSS Sprite」の基本的な知識と使い方、使いどころについて解説します。すでに定番のテクニックとなっていますが、何となく使っていることが多いと思います。初学者の方にも理解していただけるよう詳しく解説します。 対象者 対象者は主にコーダー、フロントエンドエンジニアです。 デザインとコーディングを合わせて担当するWebデザイナーも対象です。 コーダー・フロントエンドエンジニア Webデザイナー Webディレクター Web担当者 CSS Spriteとは Webサイトではアイコンやナビゲーションなどに多くの画像が使われ、サイトによっては20個30個とたくさんのアイコンが使わ
新たな技術仕様・要素とは？HTTP/2.0相互接続試験参加レポート（技術解説編）
新たな技術仕様・要素とは？HTTP/2.0相互接続試験参加レポート（技術解説編） 大津 繁樹（株式会社インターネットイニシアティブ） 前回のHTTP/2.0接続試験参加（標準化作業編）に続き、今回お届けするのは技術解説編。既存のSPDYでは使われていないようなHTTP/2.0で新しく議論された技術仕様、相互接続試験のポイントとなった技術要素などを中心にレポートします。 HTTP/2.0相互接続試験で重要な技術要素の概要 SPDYを技術ベースにして検討されているHTTP/2.0仕様は、現在60ページ弱の分量です。従来のHTTP/1.1と異なりバイナリー通信を基本とするため、その多くはフレームフォーマットの説明に割かれています。HTTP/2.0で新しく導入されたヘッダ圧縮の仕様(HPACK)は、現在HTTP/2.0の仕様と分離されていますが、将来的には統合することも検討されています。 HTTP
HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
Web表示の高速化を実現するSPDYとHTTP/2.0の標準化 | IIJの技術 | インターネットイニシアティブ（IIJ）
はじめに SPDY(スピーディと読みます)は、GoogleがWebの表示を高速化するために開発した、新しいプロトコルです。新しいと言っても、今後普及が見込まれるような新技術ではなく、既に実用化され多くの方が日常的に利用しています。 現在ChromeやFirefox、Operaのブラウザを使われている方は、Googleのサービスやtwitterにアクセスしていると、実は全く気付かないうちに、このプロトコルを利用しています。 SPDYは2010年6月にリリースされたChromeのバージョン6安定版からデフォルトで有効になっており、Chrome利用者はこの新技術を3年以上も利用していることになります。 一般のユーザはSPDYを使っているかどうか、どうしたらわかるのでしょうか？ Chromeでは、"SPDY Indicator"という便利な拡張機能を提供しています。また同種のツールは、Firefo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2の現状とこれから
HTTP 2.0 - Tokyo
HTTP2 最速実装 〜入門編〜
nghttp2 - HTTP/2.0 C Library — nghttp2 0.1.0-DEV documentation