nginx 499 エラー処理と nginx 設定パラメータ
背景
最近、コストを削減し、効率を高め、ci および stg マシンを節約するというグループの取り組みに応えて、私たちのプロジェクトはコンテナ化され始めました。変換プロセス中に、リンクへのアクセスが変更され、その結果 499 になりました。解決策は次のとおりです。
アクセスリンク: ドメイン名 —> ELB (イントラネット アクセス) —> openrestry (stg 環境、カスタム lua スクリプトをサポート) —> ELB (サービス固定 IP の提供) —> (コンテナ クラスター) POd
499件が処理されました
nigx が 499 を報告した理由は、サーバーの応答がタイムアウトし、nginx がアクティブに切断されたためです。例: nginx 設定のデフォルトのタイムアウト時間は 60 秒です。サーバー インターフェイスが 62 秒間応答すると、結果が返されます。その後、60 秒になると、nginx はアクティブに切断します。
1. proxy_xxx_timeout を次のように調整します。
2. インターフェースを最適化し、インターフェースの応答速度を向上させます。
server{
location / {
proxy_connect_timeout 200;
proxy_send_timeout 200;
proxy_read_timeout 200;
}
}
proxy_connect_timeout: バックエンド サーバーとの接続を確立するためのタイムアウトを秒単位で制御します。デフォルトは 60 秒です。
proxy_read_timeout: バックエンド サーバーからの応答を待機するタイムアウト期間を秒単位で制御します。デフォルトは 60 秒です。
proxy_send_timeout: バックエンド サーバーにリクエストを送信する際のタイムアウトを秒単位で制御します。デフォルトは 60 秒です。
これら 3 つのパラメーターは、nginx をリバース プロキシとして使用するときにバックエンド サーバーとの通信のタイムアウト時間を制限するために使用されます。これにより、プロキシ サーバーがバックエンド サーバーの応答によってブロックされ、クライアントの要求に応答できなくなるのを防ぎます。例えば、バックエンドサーバーに異常やネットワーク障害が発生した場合、応答が遅れたり、応答が返ってこない場合、プロキシサーバーはタイムアウトを待ってエラー応答を返します。
注: これらのタイムアウト設定を使用する場合は、アプリケーションのネットワークと動作環境を考慮して、適切なタイムアウトを決定する必要があります。タイムアウトの設定が短すぎると要求が失敗する可能性があり、設定が長すぎるとフロントエンド Web サイトの応答が遅くなる可能性があります。実際の状況に応じて適切に調整し、テストして信頼性とパフォーマンスを確保できます。パラメーターの値が大きいほど優れていますが、インターフェイスの応答が非常に遅い場合は、パフォーマンスの最適化を実行する必要があります。
知識の拡充: nginx 設定パラメータ
server{
location / {
proxy_ignore_client_abort on;
proxy_connect_timeout 200;
proxy_send_timeout 200;
proxy_read_timeout 200;
}
}
proxy_ignore_client_abort: 「クライアントの終了を無視する」機能を実装するために使用されます。デフォルトでは、「nginx」はクライアントとの接続リクエストをバックエンドサーバーに転送しますが、クライアントが途中でリクエストサービスから切断された場合、通常はバックエンドへの接続が早期に閉じられます。このとき、バックエンド プログラムは一定期間実行し続ける可能性がありますが、プロキシ サーバーに応答を送信できなくなり、プロキシ サーバーで誤った応答が返される可能性があります。
proxy_ignore_client_abort: off デフォルト設定、クライアントの切断により応答が中止されます。
proxy_ignore_client_abort: on クライアントの切断により応答が中止されません。プロキシ サーバーはクライアント要求の終了を無視し、応答が完了するまでバックエンド サーバーに応答を継続させます。
http:{
fastcgi_connect_timeout 200;
fastcgi_send_timeout 200;
fastcgi_read_timeout 200;
}
上記のパラメータにテクノロジーの選択に FastCGI が含まれている場合は、上記の fastcgi_xx_timeout パラメータをオンにすることを検討できます。
FastCGI (Fast Common Gateway Interface) は、Web アプリケーション用のインターフェース プロトコルであり、動的な Web コンテンツを処理する新しい方法を提案しています。astCGI の処理方法は以前の CGI スクリプトとは異なります。CGI スクリプトはリクエストごとに新しいプロセスを開始するため、パフォーマンスの低下やリソースの浪費が発生する可能性があります。FastCGI はいくつかのプロセス再利用テクノロジを利用して、各アプリケーションがメモリ内に留まって次のリクエストを待機できるようにし、パフォーマンスを大幅に向上させます。
Tomcat コンテナには FastCGI 機能が組み込まれていないため、標準の SpringBoot アプリケーションでは、FastCGI プロトコルと通信するためにサードパーティの FastCGI ライブラリまたはフレームワークを特別にインストール、構成、使用する必要があります。たとえば、Mod_jk を使用して、Tomcat とフロントエンド Web サーバー間の FastCGI 通信を実装できます。
http {
client_max_body_size 500m; //限制客户端请求体超过配置的值，超过返回413
client_body_buffer_size 10M; //
# client_body_temp: /xx // 大于client_body_buffer_size是存储的磁盘目录
keepalive_timeout 65s; //
client_header_timeout 600s; //
client_body_timeout 600s; //
proxy_connect_timeout 200s;
proxy_send_timeout 200s;
proxy_read_timeout 200s;
proxy_max_temp_file_size 0;
limit_req_zone $binary_remote_addr zone=burstLimit:10m rate=40r/s;
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_types text/plain text/css application/json application/x-javascript application/javascript text/javascript appliaction/xml;
gzip_comp_level 3;
gzip_disable "MSIE [1-6].(?!.*SV1)";
gzip_vary off;
}
client_max_body_size: クライアント リクエスト ボディが設定された値を超えないよう制限します。値を超えた場合、413 Request Entity Too Large が返されます。http、server、location で設定できます。このパラメーターは、すべてのリクエストの合計サイズを制御するのではなく、単一のリクエスト本文のサイズ用です。
client_body_buffer_size: クライアントが本体データをメモリに要求するときに割り当てられるバッファのサイズ。要求されたデータがこの設定より小さい場合、データは最初にメモリに直接保存されます。要求された値が client_body_buffer_size より大きく、client_max_body_size より小さい場合、データは最初に一時ファイルに保存されます。一時ファイルは /tmp/ であり、 client_body_temp を構成することで指定することもできます。
client_body_temp: リクエスト本文が client_body_buffer_size より大きく、client_max_body_size より小さい場合、指定されたディスク パスに保存されるようにこのパラメータを構成します。これにはアクセス許可 (chomd) の変更が必要であることに注意してください。そうでない場合は、アクセス許可が拒否されましたが報告されます。
keepalive_timeout: http/1.1 プロトコルを使用する場合、キープアライブを使用して TCP 接続を再利用し、ネットワーク接続を確立するための TCP 3 ウェイ ハンドシェイクと 4 つのウェーブにかかる時間を短縮できます。keepalive_time は、各リクエストが完了した後、指定された時間接続を維持することを意味します。これにより、頻繁に接続を作成および閉じるプロセスを回避できます。デフォルト値は 75 秒で、0 に設定すると、キープアライブ接続が禁止されます。
client_header_timeout: クライアントが完全なリクエスト ヘッダーをサーバーに送信するためのタイムアウト、デフォルトは 60 秒です。クライアントが指定された時間内に完全なリクエスト ヘッダーを送信しない場合、nginx は http 408 (リクエスト タイムアウト) を返します。
client_body_timeout: クライアントが完全なリクエスト本文をサーバーに送信するためのタイムアウト。デフォルトは 60 秒です。クライアントが指定された時間内にリクエスト本文データを受信しない場合、リクエスト全体のデータ送信はその後開始されないことに注意してください。ヘッダーの受信 ボディの送信プロセスのタイムアウト (公式ドキュメント: タイムアウトは、リクエスト ボディ全体の送信ではなく、連続する 2 つの読み取り操作の間の期間にのみ設定されます) クライアントがこの時間内に何も送信しなかった場合、リクエストは 408 (リクエスト タイムアウト) エラーで終了します。)、nginx は http 408 (リクエスト タイムアウト) を返します。
proxy_max_temp_file_size: ディスクにキャッシュされるファイルのサイズ。0 に設定すると、ディスクにキャッシュされません。設定値を超えると、nginx は配信コンテンツをプロキシ サーバーと同期し、ディスクへのバッファリングを行わなくなります。
limit_req_zone: nginx 電流制限モジュール。$binary_remote_addr は制限の対象を示します。remote_addr は 7 ～ 15 バイトを占める IP 情報を記録します。binary_remote_addr は、わずか 4 バイトを占める圧縮された IP を示します。zone=name:size は、アクセス頻度情報を保存するために name と size という名前のメモリ空間を割り当てます。rate=40r/s は、同じ IP が 1 秒あたり 40 リクエストのみを許可することを意味します。
gzip: on: 静的リソースの gzip 圧縮をオンにし、オフにするには off
gzip_min_length: 1k 圧縮を有効にするサイズを構成します。これより大きいリソースのみが圧縮されます。これより小さい場合は、圧縮しません。
gzip_buffers 4: 16k バッファ、メモリ バッファ内で圧縮されるブロックの数、および各ブロックの大きさはどれくらいですか?
gzip_types: text/plain text/css application/json application/x-javascript application/javascript text/javascript application/xml; これらの種類のファイルには圧縮を使用します
gzip_comp_level: 3; 圧縮レベル (レベル [1-9] が高いほど、圧縮は小さくなり、CPU コンピューティング時間がより多く消費されます)
gzip_disable: "MSIE [1-6].(?!.*SV1)"; 通常の一致では gzip 圧縮が実行されないのはどのような URI ですか? これは、ie6 以下では gzip が有効になっていないことを意味します (これらのバージョンでは機能しないため)サポートします）
gzip_vary: off 圧縮フラグを送信するかどうか
nginxはヘルスチェックを追加します
オープンソース バージョンの nginx には負荷分散バックエンド ノードのヘルス チェックは付属していませんが、追加の nginx_upstream_check_module モジュールを通じてバックエンド ノードのヘルス チェックを実行します。
upstream name{
server 192.168.0.1:80;
server 192.168.0.2:80;
check interval=3000 rise=2 fail=5 timeout=1000 type=http;
}
name のアップストリーム ロード バランシングでは、各ノードが 3 秒ごとにテストされます。リクエストが 2 回正常であれば、リアルサーバーのステータスはアップとしてマークされます。検出が 5 回失敗すると、リアルサーバーのステータスはダウンとしてマークされます。タイムアウトは 1 秒です。
さまざまな負荷分散ソフトウェアおよびハードウェア
ELB HAproxy nginx openresty F5 LVS
HaProxy: 負荷分散ソフトウェア (nginx の役割と同様) は、TCP/HTTP プロトコルの負荷分散をサポートし、その負荷分散機能を非常に豊富にします。約 8 種類の負荷分散アルゴリズムをサポートし、特に http モードでは、多数の実用的な分散アルゴリズムが存在します。 、システムの現在の状態をリアルタイムに把握できる優れた機能を備えた監視ページ、強力なACLサポートにより、ユーザーの利便性が高くなります（ACL アクセス制御リスト アクセス制御リスト：ACLルールに準拠したリクエストはバックエンドによって指定されます）サーバー プールは ACL ルールに基づいて負荷分散を実行します。準拠していない場合、応答は直接中断されるか、実行のために他のサーバーに渡される可能性があります); 独自の監視とチェックが付属しており、nginx はサポートする追加モジュールを追加する必要があります健康診断。欠点は、構成ファイルが比較的煩雑で、展開および保守には一定の技術レベルと経験が必要であることです。
ELB: AWS が提供するクラウド ソフトウェア ロード バランシング サービスは、クラウド アプリケーションのデプロイメントに実用的で、ある程度使いやすいですが、欠点は、カスタマイズが制限されており、エンタープライズ レベルのニーズに十分に対応できない可能性があることです。
F5: 負荷分散ハードウェアのパフォーマンスは非常に優れており、1 秒あたりに処理されるリクエストの数は数百万に達することがあります。購入価格も数十万から 100 万元と非常に高価です。特にトラフィックの多い大企業に適しています。
LVS: Alibaba の Zhang Wensong 博士によって開発されたソフトウェア負荷分散は、中国で最初のフリー ソフトウェアです. 設定が簡単で、負荷耐性が強い. 欠点: 定期的な処理をサポートしていない、動的および静的な分離をサポートしていません、ネットワーク環境に比較的依存します。
openresty: 自由度の高い nginx の拡張機能. 実用的な Lua と多数のサードパーティ モジュールをサポート. 高い同時実行性と高いスケーラビリティを処理できる Web アプリケーションとゲートウェイを簡単に構築できるため、nginx を単純なロードから変えることができます強力なゲートウェイとユニバーサル Web アプリケーション プラットフォームのバランスを保ちます。
参考
nginx公式ドキュメント モジュールngx_http_core_module
Nginx タイムアウト keeplive_timeout 設定の詳細な説明
nginx 電流制限方法 1:limit_req&limit_req_zone で処理速度を制限する