HTTP ガイド HTTP の概要 典型的な HTTP セッション HTTP メッセージ MIME タイプ（IANA メディア種別） HTTP の圧縮 HTTP キャッシュ HTTP 認証 HTTP Cookie の使用 HTTP のリダイレクト HTTP 条件付きリクエスト HTTP 範囲リクエスト コンテンツネゴシエーション HTTP/1.x のコネクション管理 HTTP の進化 プロトコルのアップグレードの仕組み プロキシサーバーとトンネリング HTTP クライアントヒント HTTP セキュリティ サイトの安全化 HTTP Observatory Permissions Policy コンテンツセキュリティポリシー (CSP) オリジン間リソース共有 (CORS) Cross-Origin Resource Policy (CORP) Strict-Transport-Securit
mod_dosdetector-fork This is a fork of mod_dosdetector hosted at SourceForge.net (http://sourceforge.net/projects/moddosdetector/). このソフトウェアはShinji Tanaka氏作のApacheモジュール`mod_dosdetector'の改造版です。オリジナルのmod_dosdetectorと同じライセンス（mod_dosdetector.cに記載）で公開されます。 この改造版についてのバグ報告や質問などは、 takayuki.3w@gmail.com 宛てに送ってください。 必要環境 バージョン1.1.0より、Apache 2.4以降が必要です。 Apache 2.2で使用したい場合は 1.0.0 を、 Apache 2.0には apache-2.0 ブラ
このエントリではModSecurityをソースからビルドする方法を説明した後、hashdos専用のチューニングを施す流れを説明します。 はじめに既にModSecurityについては、CentOS+yumおよびUbuntu+apt-getにより導入する方法を説明しています。このエントリでは、ModSecurityをソースからビルドする方法を説明します。 ModSecurityのビルドは依存関係が複雑であり、バージョンによってビルド方法が変わるなど、面倒な面があります。このエントリでは、CentOSとUbuntuの場合について、実際的なビルド方法を説明します。 準備するもの ModSecurityは以下のプロダクトに依存しています(ModSecurity HandbookP27)。ビルドに先立って準備しておく必要があります。 Apache Portable Runtime(APR) APR-U
Web サービスをリリースするにあたり避けては通れない（避けて通ってはいけない）性能・負荷テスト工程。 ウォーターフォールやアジャイルなど開発手法は様々ありますが、現実問題、概ね開発工程が遅延する傾向があります。なんとか単体テスト・結合テスト・システムテストはやりきるものの、力尽きて性能・負荷テストを実施せずにリリース・・・なんてことはありませんでしょうか？ そんな場合に限って、リリース直後に高負荷でサービスダウン・・・なんてことになりがちです。 そうならないために性能・負荷テストは必ず実施すべき項目です。ツールとして JMeter がメジャーですがシナリオ作ったり、使い方覚えたりと、正直面倒です。でも apache bench なら使ったことあるし知ってる！という方も多いことでしょう。そこで僕が "簡易的" に性能・負荷テストで使っている方法を公開します。 ab を用いた簡易的な性能・負
このエントリでは、hashdos対策としてのmod_securityの導入と設定の方法を説明します。CentOS環境でyumによりApacheを導入しているサイトに対して、yumによりmod_securityを導入するというシナリオで説明します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数（数万程度）送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。まだhashdosによる攻撃事例は報告されていないようですが、既に攻撃コード（PoC）が公表されているため、いつ攻撃が起こっても不思議ではない状況です。 PHPも影響を受けるプラットフォームであり、PHP5.3.9で対処予定となっていますが、まだPHP5.3.9はリリースされて
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の7日目です。 @methane の新シリーズは Apache+php のチューニングです。 今日のお題は、タイトルのとおり、phpのプロセス数(=並列数)を減らすことです。 これはチューニンガソンでも人気のチューニングだったのですが、 今日はそのメリットをまとめます。 ロードアベレージが下がる プロセス数をコア数＋α程度に抑えると、ロードアベレージがコア数の数倍〜 数十倍になることがなくなります。 例えばロードアベレージがコア数の100倍になると、１リクエストの処理に かかる時間は100倍以上に増え、せっかく処理したのにクライアント側が タイムアウトしていて完全に無駄骨になったり、最悪では再リクエストが来て さらに負荷が上がる負のスパイラルに陥る可能性があります。 たくさん一気に処理しよう
Distributed Object Storage Made Easy! Use commodity hardware/software to build your own scalable object storage! Learn more » What is STF? STF is a simple, yet very scalable distribute storage system. STF powers sites like livedoor Blog, loctouch and many more, serving gigabytes after gigabytes of data. On one such system, it's serving 400Mbps of image at peak hours without a hitch. GET STF! STF i
small lightシリーズ [1] ライブドアのsmalllightを使って動的に画像をリサイズしてみる [2] いろいろsmalllightを使って動的に画像をリサイズしてみる [3] smalllightでのエンジンの選択の仕方 [4] smalllightでのエンジンの選択の仕方 (ヒントオプション追加） 最近、動的に画像をリサイズするのが流行っているようです。 ゆめみラボのmod_ktaiやクックパッドのmod_tofu、livedoorラボEDGEのsmall_lightなどいろいろありますが 今回small_lightを使ってみたので記事を書いてみます。 ついでに速いと噂のlibjpeg-turboも入れてみます。 smalllightとは 公式を見るのが一番早いとは思うので一度見てみてください。（→smalllight） 僕がsmalllightで特にいいなぁと思ったのが
MAMPとかXAMPPは使わないでやります。 標準でApacheが入っているので、前準備はなしでだいじょぶです。 # ターミナル初めての人向け $ で始まってるやつはターミナルから入力します。また sudo はroot権限で実行します。通常ファイルやディレクトリにはPermissionが設定されていて、ユーザーディレクトリより上位階層のファイル・ディレクトリはroot権限がないと変更できません。 ゴール ゴールはローカルのhogeディレクトリに ブラウザから「http://ho.ge/」でアクセスできるようにすることにします。 ちなみに index.html の中身は This is HOGE になってます。これは表示確認ができればなんでもいいです。 これから[ユーザー名]っていう箇所が出てくるんですけど、これは赤線で囲った部分の文字が入ります。 サイドバーにない場合・・・ hogeディレ
Apacheの脆弱性(CVE-2011-3192)いわゆるApache killerが話題になっていますが、その脅威については一部誤解があるようです。 以下は、非常に脅威とする報告の例です。 一方今回のはプロセスの肥大化を伴うので、実メモリ消費して更にスワップも使い尽くしてOS毎激重になったあげくLinuxとかの場合はOOM Killer発動と、他のプロセスや場合によってはOSを巻き込んで逝ってしまいます。 CVE-2011-3192 Range header DoS vulnerability Apache HTTPD 1.3/2.xより引用 以下は、それほど脅威でなかったとする報告の例です。 pooh.gr.jp は結構頑丈だったので 60 並列でやっと CPU idle 30% まで減らせた。 Apache Killer (CVE-2011-3192) 対策 for CentOS 5
nginxやvarnishなどがアツいですが、Apacheもまだまだ実績や安定性から採用されていると思います。ここではデフォルトとは異なる値に変更するサーバ設定を中心に、パフォーマンス改善、安全性向上のためのApacheの設定を紹介します。 mpmの確認 > /path/to/bin/httpd -V Server version: Apache/2.2.19 (Unix) Server built: Jun 23 2011 17:13:13 Server's Module Magic Number: 20051115:28 Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Architecture: 64-bit Server MPM: Worker PreforkやW
一年ほど前にヤフーを退職した私ですが、その後なにをやっているかというと、クックパッドに入社して画像配信をしています。私が入社する前から動いていた画像配信の仕組みは設計が古くてなにかと困っていたので、より良いシステムを開発してリプレースというのをやっています。前職ではなかなかこういう基盤システムを一人でイチから作って運用までするという体験はできなかったので、でかい仕事をできるチャンスに恵まれて大変充実した毎日です。 入社当初はサービス開発の担当だったんですが、開発に必要な基盤システムを作り始めたらどんどんエンジニアリングのレイヤーが下がってきて、気づけばインフラチームに所属していました。 まあそんな話はさておき、この画像配信関連の成果をいくつかの勉強会で発表したので、その資料を紹介します。 サイバーエージェントxクックパッド合同勉強会（amepad） 弊社オフィスで開催された、サイバーエージ
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Apache HTTP ServerのBufferedLogsディレクティブは、マニュアルでexperimentalとされていたので今まで試していませんでした。BufferedLogsディレクティブを有効にすると、リクエストごとにログを出力せずに、いったんバッファに蓄えてまとめて出力するようになります。 マニュアルにはBufferedLogsディレクティブによってディスクアクセスが効率的になると書かれていますが、これが効いてくるのはむしろパイプ経由のログ出力です。ログがパイプに出力されて、パイプの反対側のプログラムが実行可能になる頻度が下がるからです。このところCP
環境 CentOS 5.5 Apache 2.2.3 設定方法 CentOS 5.5では、favicon.icoを設置したとしても、そのままだと.icoファイルはデフォルトのMIMEタイプとしてtext/plainとして扱われます(/etc/httpd/conf/httpd.confのDefaultTypeに記載されています)。 Apacheの設定ファイル(httpd.conf)内でMIMEタイプのマッピングの設定は、以下のファイルを参照していることが分かります。 TypesConfig /etc/mime.typesということで、上記の設定ファイル(/etc/mime.types)に.icoファイル向けのMIMEタイプを追記すればよさそうです。 image/vnd.microsoft.icon icoただし、サーバのリプレイスなどが発生した際に設定し忘れる可能性が高いので、Apacheの
先日、Web サーバ勉強会 #2 が開かれました。内容は、Apache のチューニングということで、参加したかったのですが、他の予定があって参加できませんでした。 そこで、僕が個人的に行っている Apache のチューニングを紹介したいと思います。最初、スライドで作成しようかと思ったのですが、ブログにまとめたほうがよさそうなのでブログにまとめていきます。 まず、大前提として Apache をチューニングするうえで、大事なことはその Apache が提供する Web サービスの種類のよって大きくチューニングする内容が異なるということです。例えば、動画・写真共有サービスと株価情報のサービスを比較すると、当然のことながら大きくサービスの内容が異なりますし、HTTP レベルでみるとクライアントからのリクエスト数、データサイズ、などがかなり違ってきます。 ですので、まずは自分が扱っているウェブサービ
ApacheでX-Sendfileが利用できるmod_xsendfileをPHPと連携して使ってみました。 PHPで認証してから、許可したユーザのみにファイルを出力する、という処理を実装する場合、ファイルはdocument_root外に配置しておいて、readfile()やfpassthru()でファイルを出力するという手法を良く使います。 この方法でも問題無い場合が多いのですが、容量の大きいファイルを出力する際は思ったようなスピードが出ない時があります。 そのような時はmod_xsendfileを使って、ファイル出力の部分をApacheに任せてしまう方法が有効です。 ここでは2010/11/12時点の最新版であるmod_xsendfile 0.12を対象としています。またインストール環境はRHEL、CentOSを想定しています。 mod_xsendfileのインストール mod_xsen
http://httpd.apache.org/docs/2.2/en/mod/mod_proxy.html#proxypass http://httpd.apache.org/docs/2.2/ja/mod/mod_proxy.html#proxypass timeoutとかconnectionとか。今まで真面目にみてなかったので。mod_proxyのdocumentは翻訳が追いついてないためか、日本語のページに記載されている内容は古いversionのものがあるので、なるべく英語のページを見たほうが良い。 とりまメモった内容を記録。体裁は後で整える。 あと、"まとめた"とか言ってるけど、全部のパラメータについて調べたわけではないです。 parameter: default Description timeout: ProxyTimeoutの設定値 ProxyTimeoutのdefault
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く