...
ウェブホスティングのロゴ

HTTP/2のパフォーマンスを最大化するためにApache mod_http2を最適に設定する

Apacheの設定を行います mod_http2 HTTP/2のパフォーマンスが即座に発揮されるように：適切なプロトコルネゴシエーション、適切なMPMスレッド、そして適切なTLS設定。ストリーム、ウィンドウサイズ、キープアライブに関する明確な基準値を設定することで、安定した ロード時間 アクセス数の多いページから。.

中心点

  • MPMイベント 導入し、キープアライブを適切に設定する
  • プロトコル h2 http/1.1（ProtocolsHonorOrder On）
  • H2WindowSize 適度に増やし、ストリーム数を制限する
  • 労働者 H2MinWorkers/H2MaxWorkers を使用して制御する
  • TLS/ALPN 最適化とロギングの精度向上

mod_http2 の有効化：基本と前提条件

私はまず mod_http2 およびプロトコルのネゴシエーション。モジュールの読み込みは LoadModule で行い、その後、Protocols h2 http/1.1 を設定して、HTTP/2 を優先しつつ HTTP/1.1 も引き続き提供するようにします。本番環境での提供に際しては、有効な ティーエルエス, 、最新の暗号スイート、およびSSLv2/SSLv3などの無効化された旧式プロトコル。適切なTLSとALPNがなければ、最新のブラウザはプロトコルの機能を十分に活用できません。高い同時接続数に対応するため、事前にMPMを計画しています。preforkではHTTP/2のパフォーマンスが著しく低下するからです。.

LoadModule http2_module modules/mod_http2.so
Protocols h2 http/1.1

VirtualHosts で HTTP/2 を適切に有効にする

私は特定の場所でHTTP/2を有効にします。 vHost ポート443で、順序を固定します。これにより、ApacheがまずHTTP/2を提供し、必要な場合にのみHTTP/1.1に切り替わるように強制します。Curlで素早く確認すると、「HTTP/2 200」という結果が表示され、この動作が確認できます。ディレクティブ プロトコル・名誉・勲章 プロトコルの順序が固定されるように、これを「On」に設定します。これにより、ホストごとに明確で予測可能な配信を実現できます。.

Protocols h2 http/1.1
  ProtocolsHonorOrder On
  SSLEngine on
  # 証明書、暗号スイート、OCSP など

MPMの選択とキープアライブの微調整

高い並行性を実現するために、私は以下を採用しています mpm_event, 、というのも、スレッドやイベントは多数の接続を効率的に処理してくれるからです。StartServers、ThreadsPerChild、MaxRequestWorkers の各値は、スワップが発生しないよう、RAM の使用量を見積もってから設定しています。 HTTP/2については、KeepAliveTimeoutの値を上げ、持続的な接続が複数のリクエストを処理するのに十分な時間を確保できるようにしています。同時に、リソースを定期的に解放するために、MaxKeepAliveRequestsを制限しています。MPMの違いについてさらに詳しく知りたい方は、私の記事 event vs worker MPM, 、実務上、選挙の手続きを容易にするものです。.

ストリーム、多重化、およびフロー制御

並列処理を制御しています ストリーム H2MaxSessionStreams を使用して、クライアントが過剰なリソースを占有するのを防ぎます。アセットの数やバックエンドの挙動にもよりますが、100 から 200 の間の値が適していることが多いです。 スループット向上のために、H2WindowSize を調整し、フローウィンドウを適度に拡大しています。多くの場合、256 KB に設定しています。これにより、メモリを過度に消費することなく、ウィンドウの更新回数を減らすことができます。その仕組みを理解したい方は、私の記事をご覧ください。 HTTP/2 マルチプレキシング, 、優先順位や障害についてわかりやすく説明している。.

ワーカースレッド、タイムアウト、プッシュ

私は寸法を決定します H2MinWorkers また、ハードウェアやMPMに合わせてH2MaxWorkersを設定し、負荷のピークがレイテンシのピークにつながらないようにしています。さらに、H2TimeoutとH2KeepAliveTimeoutを適切に設定し、応答のないセッションが不必要に長くリソースを占有しないようにしています。 H2Directディレクティブについては、パブリックサイトでは無効にしています。なぜなら、こうしたサイトではPrior Knowledgeを伴うh2cがほとんど意味をなさないからです。H2Pushに関しては保守的な姿勢を貫き、厳密な測定結果が出た場合にのみ有効にしています。 多くの環境において、適切なキャッシュ、クリティカルCSS、非同期スクリプトの組み合わせが、より信頼性の高い 加速.

TLS、ALPN、および暗号スイートを正しく設定する

TLSはHTTPSのvHostでのみ有効にし、古いものは削除します プロトコル 一貫性を重視しています。スムーズなネゴシエーションを実現するため、ALPNを活用し、クライアントが余分なラウンドを経ることなく直接HTTP/2に移行できるようにしています。 短い証明書チェーン、OCSPステープリング、セッション再開機能により、ハンドシェイク時のオーバーヘッドを削減します。これにより、読み込み時間やスループットに顕著な影響を与えるミリ秒単位の時間を節約できます。詳細については、私のガイドで詳しく解説しています。 ALPN と HTTP/2 を組み合わせて、暗号やオプションを的確に選択できるようにします。.

ロギング、テスト、およびトラブルシューティング

私はそれを増やします LogLevel HTTP/2については、まずは「info」モードで接続の確立、ストリーム、フロー制御を監視します。そうすることでボトルネックを早期に特定し、設定値を段階的に調整していくことができます。 curl を使用して、コンソールから直接ヘッダー、プロトコル、サーバーの応答を確認します。負荷テストでは、静的ルートと動的ルートについて、レスポンス時間、スループット、エラー率を個別に測定します。最適化が確実に効果を発揮するように、変更のたびに測定データで裏付けをとっています。.

LogLevel http2:info


# 簡易テスト：
# curl -v --http2 -I https://example.com/

例：簡潔なHTTP/2設定

私は……をお見せします 構成, これは多くのプロジェクトで実績があり、明確な出発点を提供するものです。Event-MPMは、プロセスを過負荷にすることなく、多数の同時接続に対応します。 HTTP/2ディレクティブはストリーム数を制限し、ウィンドウサイズを適度に拡大し、十分な数のワーカーを確保します。Keep-Aliveの設定は寛容なままですが、MaxKeepAliveRequestsによって周期的な解放が行われます。微調整はRAM、CPU、アプリスタック、トラフィックプロファイルによって異なるため、変更のたびに再測定を行っています。.

# MPM イベント

  StartServers 2
  MinSpareThreads 25
  MaxSpareThreads 75
  ThreadsPerChild 25
  MaxRequestWorkers    150
  MaxConnectionsPerChild 1000


# HTTP/2 コア
Protocols h2 http/1.1
ProtocolsHonorOrder On

# mod_http2 チューニング
H2MaxSessionStreams   150
H2WindowSize 262144
H2MinWorkers 10
H2MaxWorkers 75
H2KeepAliveTimeout    30
H2Timeout 60
# H2Push オフ   # はオプションのままにする

# TLS（例）
SSLProtocol all -SSLv2 -SSLv3
# SSLCipherSuite として、最新かつブラウザ互換のものを選択
# OCSP Stapling / セッション再開を有効化

mod_http2のチューニングに関する目安表

私はこれを使っています 標準値 まず初期値として設定し、トラフィック、ハードウェア、アプリの測定結果に基づいて調整します。この表には、代表的な初期値と適切な範囲がまとめられています。ウィンドウやストリーム数が大きすぎるとRAMを消費し、小さすぎるとスループットが低下します。 重要なのは、MaxRequestWorkers とバックエンドの処理能力とのバランスを調整することです。私は、原因と結果を明確に把握するために、各設定レベルを個別にテストしています。.

ディレクティブ／設定 開始値 チューニング・コリドー ヒント
H2MaxSessionStreams 100 120–200 ワーカー予算が許容する範囲内であること
H2WindowSize 65535 B 256 KB ～ 1 MB 容量が大きいほど、Windowsの更新プログラムは少なくなりますが、RAMは多くなります
H2MinWorkers 10 10–25 小規模なシステムがベースロードを賄う
H2MaxWorkers 50 50–75+ 負荷のピークを緩和し、RAMを注視する
KeepAliveTimeout 15秒 20～30秒 HTTP/2は、接続時間が長いという利点がある
MaxKeepAliveRequests 100 100～500 リソースを定期的に解放する
MPM イベント: MaxRequestWorkers 150 150–300 RAM予算に基づいて計算する

現実的な負荷試験と測定戦略

私はチェックする 応答時間 HTML、静的アセット、動的APIルートごとに分けてテストします。その後、同時接続数が増加するにつれてスループットとエラー率を評価し、パフォーマンスの転換点を見つけ出します。そして、H2WindowSize、ストリーム数、キープアライブを段階的に調整し、A/Bテストの結果を比較します。 さらに、ボトルネックの移動が見逃されないよう、CPU、RAM、ネットワーク、TLSハンドシェイク時間を監視します。このようにして、アプリケーションに適した構成を実現し、ピーク時の余裕を確保します。.

インフラとホスティング環境の構築も考慮に入れる

私は最新の情報を重視しています アパッチ-最新バージョン、適切にメンテナンスされたTLSスタック、そしてチューニングが効果を発揮するための高性能なハードウェア。大規模なオンラインショップやWordPressポータルサイトの場合、Event-MPM、HTTP/2、迅速な証明書管理を標準で提供するプロバイダーを選ぶ価値があります。 ベンチマークテストにおいて、webhoster.deはこうしたセットアップにおいて信頼できるプロバイダーであることが実証されています。そこでは、最新の構成と専門的なサポートを組み合わせています。この基盤があるからこそ、目安となる数値をより迅速に検証し、運用にスムーズに反映させることができるのです。.

ロードバランサーの背後でのHTTP/2およびリバースプロキシとしてのHTTP/2

Apacheの前に ロードバランサー またはCDNでターミネートされる。重要なのは、ALPNが正しくネゴシエーションされ、エッジまでHTTP/2が有効なままであることだ。TLSターミネーションの背後で、Apacheはバックエンドとして引き続きHTTP/1.1しか認識できないが、クライアントがエッジ経由でh2で処理されている限り、これは問題ない。もし私がApache自体を リバースプロキシ アップストリーム（例：アプリサーバー）への接続については、HTTP/2も使用するかどうかを慎重に判断しています。 にとって バックエンドではHTTP/1.1を使用しています。多くのバックエンドでは、HTTP/1.1で安定しており、測定も容易です。ただし、遅延が発生しやすいサービスや遠隔地のサービスの場合、アップストリームへのHTTP/2利用により、マルチプレクシングによって遅延を低減できます。 重要なのは、フロントエンド、プロキシ層、バックエンド間の同時実行リソース配分を調整することです。そうしないと、ボトルネックが単に1つ上の階層に移ってしまうだけです。.

PHP-FPM、アプリケーションサーバー、および並行処理予算

一票 最大リクエストワーカー数 Apacheでは、アプリケーション層におけるプロセス／スレッド数によって異なります（例：PHP-FPMのpm.max_children、Node/Javaのワーカー数）。 HTTP/2は、1つの接続につき多数の同時ストリームを開くことができます。Webサーバーが、バックエンドが並列で処理できる数よりもはるかに多くの同時リクエストを受け入れると、キューが長くなり、レイテンシが増加します。 そのため、H2MaxSessionStreams、MaxRequestWorkers、およびバックエンド・ワーカーの数を、マルチプレックスによるパフォーマンス向上がバックエンドのブロッキングによって台無しにならないように調整しています。動的なページについては厳格な上限を設定する一方で、静的なアセットについてはキャッシュから積極的に配信するようにしています。.

ヘッダーの効率化、HPACK、およびアセット戦略

HTTP/2 はヘッダーを HPACK. とはいえ、巨大なクッキーヘッダー、肥大化したユーザーエージェント文字列、あるいは不要なカスタムヘッダーが多数存在すると、CPUやメモリを消費してしまいます。私はクッキーを整理し、Set-Cookieのドメイン／サブドメインを調整し、本当に必要なものだけを束ねています。 配信側では、適切なキャッシュヘッダー、ETag、Last-Modifiedを設定し、アセットには明確なバージョン管理を施します。HTTP/2では、ドメインシャーディングや人為的なバンドリングの重要性を相対化しています。マルチプレクシングのおかげで、バックエンドが追いつく限り、多数の小さなファイルももはや問題ではありません。 バランスには常に気を配っています。1ページあたりのリクエスト数が多すぎるとスケジューリングのオーバーヘッドが増加し、バンドルのサイズが大きすぎるとキャッシュヒット率が低下し、レンダリングがブロックされてしまいます。.

圧縮、サイズ、およびレスポンス形式

テキストリソースには、効率的なものを利用しています 圧縮 (gzip または brotli) を使用し、ごく小さなファイルまで圧縮されないよう、適切な最小サイズに注意を払います。HTTP/2 では、圧縮された小さなリソースも並列でストリーミングされるため、パフォーマンスが維持されます。 同時に、First Byte Timeに大きな影響を与えるため、過剰に大きなHTMLレスポンスを最小限に抑えています。画像は適切な形式とサイズで提供し、CPU負荷の急上昇を抑えるため、リクエストパス内での不要な再エンコードやサーバーサイドでの変換は避けています。.

運用、制限、およびリソース計画

十分に計画している ファイル記述子 また、多数の同時接続が ulimit の制限によって失敗しないように、プロセスリミットを設定します。Event-MPM は接続を効率的に維持しますが、各接続は一定のメモリを消費します。 MaxRequestWorkers、キープアライブウィンドウ、H2MaxSessionStreamsの合計値は、負荷のピーク時でもシステム全体がスワップに追いやられないように設定しています。ローリングデプロイについては、 しとやか リロード；MaxConnectionsPerChild はプロセスを最新の状態に保ち、徐々に進行するリークを防ぎます。私は定期的にワーカーのヒープフットプリントを測定し、それに応じてライフタイムを調整しています。.

実務における故障事例と的確な診断

私は典型的な HTTP/2のエラー画面: GOAWAYフレームが多数発生している場合は、接続切断やハードリミットが疑われます。RST_STREAMが頻発する場合は、タイムアウト、クライアントによるリクエストの中断、またはアップストリームのエラーが考えられます。 負荷テストで4xx/5xxエラーが頻繁に発生する場合は、Windowやストリームを調整する前に、まずバックエンドとデータベースを確認します。診断のため、一時的にLogLevel http2をdebugに上げ、異常な挙動が見られるパスを特定し、h2対応ツールで測定を行います。 重要：変更するのは常に a テスト実行ごとに調整ネジを1つずつ調整し、原因と結果の関係を明確にする。.

日常における「Early Hints」、「Push」、そして優先順位付け

頼りにしているのは 初期のヒント (103) HTTP/2のプッシュを検討する前に、軽いヒントパスとして活用します。Early Hintsは、リソースを恒久的に複製することなく、重要なリソースの読み込みをブラウザに先行させます。 Pushは、メトリクスでその効果が実証されている場合、例えば非常に小さく変更されないCSSスニペットやフォントなどに対して、的を絞って測定結果に基づいて行います。 優先順位の決定にあたっては、主に整然としたHTMLの順序、プリロードヒント、そしてアプリケーションの明確なクリティカルパス戦略に依存しています。これにより、最新のブラウザと堅牢に連携することができます。.

タイムアウト、再試行、およびユーザー体験

私はキャリブレーションを行います。 タイムアウト これにより、正当ではあるが処理速度の遅いクライアントが早すぎる段階で切断されることを防ぎつつ、フリーズしたストリームは迅速に処理されるようにします。 H2TimeoutとH2KeepAliveTimeoutについては、矛盾する切断基準が生じないよう、適切なプロキシおよびバックエンドのタイムアウト設定と連動させています。 チューニングの際には、リトライ（クライアントまたはプロキシ）が連鎖的に発生しないよう注意しています。そうしないと、メリットよりも負荷の方が大きくなってしまいます。目標は、測定可能な良好な読み込み時間であり、いかなる代償を払ってでも最大の生並行性を実現することではありません。.

セキュリティ、TLSの微調整、および安定性

私はTLSスタックを スリム: 短いチェーン、スタック型OCSP、セッション再開、およびECDHEを用いた最新の暗号アルゴリズム。再ネゴシエーションは避けており、ヘッダーのサイズオーバーは意図的に制限しています（例：Cookieなど）。 これにより、ハンドシェイク時のオーバーヘッドを最小限に抑えることで、安定性と計画性が向上します。 コンプライアンス要件については、セキュリティとパフォーマンスのバランスを適切に保つよう、チケットの有効期間、セッションキャッシュ、および暗号スイートを設計しています。変更については、実験室環境だけでなく、実際のターゲットクライアント環境での測定データに基づいて検証を行っています。.

モニタリング、指標、および継続的な最適化

職場で観察している h2の割合, 、レイテンシの分布（p50/p95/p99）、エラー率、オープンコネクション、およびプロセスごとのRAM使用量。 mod_statusと外部メトリクスにより、キープアライブウィンドウとストリームのサイズ設定が適切かどうかを確認します。p95レイテンシにばらつきが見られる場合は、まずバックエンドとネットワークパスを確認し、その後にウィンドウやストリームを検証します。 さらに、TLSハンドシェイク時間を確認します。これが長くなっている場合、ボトルネックは多くの場合Apacheより手前（証明書の状態、エントロピー、ハードウェア暗号化）にあります。このフィードバックループを通じて、設定を実際の状況に即した状態に保ち、トラフィックパターンやリリースに合わせて調整しています。.

アップグレードおよび互換性に関する事項

私は次のことを計画している。 定期的な更新 Apacheとmod_http2については、安定性、フロー制御、エラー処理の改善が直接測定可能であるため、積極的に導入しています。アップグレード前には、代表的なデータを用いて負荷テストを行い、本番環境のグラフと比較します。 クライアント構成が混在している場合（古いブラウザ、ボット、各種デバイスなど）、意図的にHTTP/1.1をフォールバックとして有効にしておきますが、ボットが過剰な数の接続を確立し、それによってワーカーを占有していないかを確認します。そのような場合は、制限を設定するか、トラフィックを分離して、 実際のユーザー 優先される。.

拡張の道筋と運用モデル

私は次のように定義します。 スケーリングパス: 垂直方向（RAM/CPUの増強、ワーカープールの拡大）または水平方向（ロードバランサーの背後にフロントエンドを増やす）。セッションアフィニティが必須でない限り、HTTP/2は水平方向に良好にスケーリングします。 ステートフルなコンポーネント（例：サーバーサイドのセッション）については、ノードあたりでどの程度の並列ストリームが適切か、またスティッキーセッションが本当に必要かどうかを検討します。これにより、長時間のストリームが多すぎて特定のノードに過大な負荷がかかる一方で、他のノードが遊んでいるという状況を回避できます。.

私の簡単な要約

起動させる HTTP/2 vHost内で的を絞って設定を行い、Event-MPMを選択し、Keep-Aliveを増加させ、プロトコルを明確に設定します。その後、RAMとCPUの負荷バランスが保たれるよう、ストリーム、ウィンドウサイズ、ワーカーを調整します。ALPN、短い証明書チェーン、レジュメーションを組み合わせたTLSにより、接続確立時に貴重なミリ秒単位の時間を節約できます。 http2:infoへのロギングと体系的な負荷テストにより、変更のすべてを追跡可能です。このようにしてパフォーマンスは段階的に向上し、ユーザーは途切れることのない高速なページ体験を得ることができます。.

現在の記事