公共の数のオリジナル記事：猿周Xiansenプログラム。このプラットフォームは、私の記事のように、私はマイクロチャンネル公衆番号への関心を歓迎し、定期的に更新されていません。
最近nginxの上の一連の記事を更新されて、最終的にいくつかの重要な知識ポイントnginxのは、ほぼ同じ話します。シリーズの最後としてBenpianスペースNginxは、主に頻繁にインタビューnginxの知識ポイントの間に尋ねためにいくつかの回答を得ました。実際には、nginxのポイントのための面接の質問は基本的には同様の問題を行くように依頼するように依頼することはあまりないです。次はnginxの基本的な面接の質問を見てみましょう。
nginxの役割
問題は、nginxの有用性を議論し、エントリーレベルの知識です。nginxのは、高性能なWebサーバで、プロキシサーバーを逆にするだけでなく、IMAP / POP3 / SMTPサーバー：私は長い間、いくつかの重要なポイントはそれに答えるための場所であるとして、あなたは、このような答えを考えることができると思います。負荷分散を実現することができるだけでなく、あなたはまた、インターフェース電流制限、キャッシングや他の機能を行うことができます。
nginxのの視点を使用して
そして、約30,000の同時接続をサポートできる実際の運用環境でのepoll nginxのkqueueのネットワークI / Oモデルを使用します。
nginxの低メモリ消費量。
nginxのクロスプラットフォーム、および構成が困難の比較的低い程度です。
その後、nginxの組み込みのヘルスチェック、負荷のサーバがダウンした場合のバランス、および処理のために別のサーバーに送信された要求を受信しました。
サポートGzip圧縮は、ローカルブラウザキャッシュヘッダーヘッドを追加することができます。
nginxのは、構成の変更が円滑にサービスを中断することなく行うことができ、ホットデプロイをサポートしています。
nginxの非同期は、Webサーバー上の圧力を低下させる、ユーザの要求を受け取ります。
高い同時実行nginxのを達成する方法
非同期ノンブロッキング：この問題は、小さな5つの単語のうち、出現しているnginxの友人のうちの理解かもしれません。nginxのは、実際にファイルディスクリプタモデルと有意に最適化された基本コードを使用して、非同期の非ブロッキングです。nginxのは、マスター・プロセス・モデル複数のワーカープロセスを使用することである前に、実際には、そこが語られ、それは要求を受信するたびに、要求は要求を処理するためにワーカープロセスに配布するために、特定のポリシーに従ってマスターになります。ワーカー・プロセスの数は、一般的に数とCPUコアと一致するように設定され、コールバック要求を受信したときに、新しい要求を受信し、古いプロセスの要求に戻って行くことができるコールバック要求を待っているアイドル時間をワーカースレッドを行います非同期モードを非ブロック、したがって、いくつかのワーカープロセスを完了すると、高い同時実行性の問題を達成しました。
なぜ、nginxのは、マルチスレッドを使用していませんか？
我々はすべて知っているように、新しいスレッドを作成していない、我々は、CPUとメモリを割り当てる必要があります。もちろん、作成プロセスは同じですが、理由は、あまりにも多くのスレッドの過度のメモリ消費を引き起こす可能性があります。したがって、nginxのシングルスレッドの非同期処理のユーザ要求、およびnginxの性能をより効率的になるように、継続的にCPUとメモリ消費量サーバーを削減するために、新しいスレッドのためのメモリを割り当てる必要はありません。
nginxのは、どのように要求を処理するには？
nginxの開始後、最初の解析の設定ファイルが正常に仮想サーバーのIPアドレスとポート番号を解決される、addrreuseオプションのプロセスを習得メインプロセスでソケットを作成しており、ソケットが対応するIPアドレスとポートにバインドされていますそして、監視。その後、クライアントとnginxのは、3ウェイハンドシェイクを実施するとき、あなたはnginxのと成功した接続を作成することができ、子プロセスワーカープロセスを作成します。新しい要求が来ると1つのワーカープロセスが正常に競争するとき、アイドル状態のワーカープロセスは、競争力となり、あなたはこのソケット接続が正常に確立されているでしょう、そしてngx_connection_t構造体を作成し、読み取りと書き込みと追加するためにイベントハンドラを設定しますイベントは、クライアントとのデータ交換を読み書きするために使用されます。要求またはクライアントnginxのアクティブな接続の端が閉じているときは、この時間は、要求が処理されます。
なぜ、静的および動的な分離を行いますか？
日々の開発では、このような画像などのフロントエンドのリソース要求静的ファイルは、バックエンドサーバーを経由する必要はありませんが、APIのこれらのタイプは、あなたがバックエンドのために処理要求を必要とする呼び出して、そのリソースファイルの応答速度を改善するために、我々は静的および動的分離を使用する必要がありますアーキテクチャを行うための戦略。私たちは、静的ファイルにnginxのを置くことができ、要求はさらに処理を動的にバックエンドサーバのリソースに転送されます。
いくつかの一般的な方法nginxの負荷分散？
ポーリング：ポーリング負荷分散とnginxのデフォルトモード、個別のバックエンドサーバーがダウンした場合、時系列順に処理を実行するために別のバックエンドサーバーに割り当てられたそれぞれの新しい要求、ヘルスチェックnginxのこれは、バックエンドサーバーを除去することができます。しかし、ポーリングは明白です：信頼性が低いと負荷分散の不均衡は、そのポーリングは、静止画像サーバまたはサーバリソースに適しています。
重量：重量比は、要求を処理する異なるバックエンドサーバーの割合を変更することができ、異なるバックエンドサーバごとに異なる重みを設定してもよいです。あなたは、バックエンドサーバーの優れたパフォーマンスにより高い重みを与えることができます。
ip_hash：固定、各ユーザーが開始された要求は、同じバックエンドサーバで処理するので、あなたはセッションの問題を解決できるように、この方法では、要求を処理するための要求のバックエンドサーバのIPアドレスのハッシュ結果に応じて割り当てられます。
失敗：主に短時間優先割当要求に応答して、バックエンドサーバー、バックエンドサーバーの応答時間に基づいて割当要求に対して、ポーリングモードに幾分類似こうして。
url_hash：結果が異なるサーバーに異なる要求を割り当てるためのリクエストURLのハッシュに基づいている、このように、このように要求が各urlで行われますが、バックエンドサーバ、で処理されたときに、バックエンド・サーバ・キャッシュのより効率的な。
セッションがどのように対処する非同期の？
実際には、上記のソリューションは、負荷分散方法はip_hash方法を使用して、IPアドレス、ユーザーがサーバーを自動的に見つけて、バックエンドデバイス、再びアクセスを訪問した場合、この要求は、ハッシュアルゴリズムを変換されます。もちろん、Redisのことで、ユーザのセッションをキャッシュし、そして彼らが同期セッションの問題に対処することができます。
nginxの一般的な最適配分
Worker_processesは、ワーカー・プロセスの数は、nginxのは、ワーカー・プロセスの数を言及し、一般的にCPUコアの数と一致するように設定されているだけで作成する必要があり、指定さに調整します。
nginxのは、同時にクライアントの数にサービスを提供するように設定worker_connectionsを調整します。Worker_processes構成は毎秒サービス、クライアントの最大数を得るために組み合わせることができます。
gzip圧縮を起動し、ファイルサイズは、HTTPクライアントの帯域幅を削減するために圧縮することができます大幅にページの読み込み速度を向上させることができます。
キャッシングは、要求された静的リソース場合、大幅にパフォーマンスを向上させることができ、キャッシュを有効にする、有効になっています。約この記事は、Nginxは見ることができるキャッシュキャッシュを有効にする：nginxのキャッシュ原理とメカニズムを
nginxのフォワードプロキシ
フォワードプロキシは、それはフォワードプロキシどのような代理店モデルと誰もが最も接触しているのですか？我々は、すべての国が正常であるにGoogleがアクセスできないことを知っているが、時には我々はGoogleにアクセスするための理由は、技術的な問題の時間を必要とする、我々は最初に我々がアクセスにプロキシサーバへのリクエストは、プロキシサーバーが送信されます、プロキシサーバーは、Googleにアクセスすることができますでしょうデータへのアクセスは、私たちに返されるGoogleが、その後、このようなプロセスは、プロキシを転送することです。フォワードプロキシ最大の特徴は、サーバのアドレスにアクセスするために要求プロキシサーバからのみ明らかGoogleのサーバーを知って明確にするために、本当のクライアントの特定の情報を非表示にすることができフォワードプロキシから特定したクライアントを知らないクライアントが必要です。
クライアントは、フォワードプロキシサーバを設定するだけでなく、IPアドレスとポートエージェントフォワードプロキシサーバを知っている必要がありますする必要があります。クライアントとGoogleのサーバーの間に位置し、サーバで、Googleのサーバーからデータを取得するために、クライアントが要求を送信し、プロキシサーバに（Googleのサーバー）のターゲットを指定し、フォワードプロキシはクライアントの代理でまとめることができプロキシサーバは、元にリクエストを送信すると、得られたデータがクライアントに返されます。いくつかのフォワードプロキシの役割の概要：
- 外国のサイトへのアクセスは、リソースへのアクセスを高速化するキャッシュにアクセスしていません
- クライアントアクセスの認可、認証プロキシアクセス
- あなたは、ユーザーのアクセス記録（アクセス管理）、情報を隠すために外部ユーザーを記録することができます
nginxのリバースプロキシ
サーバーから送信された要求への複数のクライアント、nginxのサーバ要求を受信した後は、ビジネス・ロジックの処理のために別のサーバーに転送一定のルールに基づいて、それは、我々だけ言及しているロード・バランシング戦略です。この時点で、クライアントは、要求が特定されたが、要求は、nginxのプレイがリバースプロキシ役割であるサーバープロセス、明確ではありませんでした。理解することができ、外部リバースプロキシは透明であり、来場者へのアクセスは、彼らがプロキシされているかわかりません。リバースプロキシサーバプロキシは、主に情報を隠すためにプロキシサーバーを逆分散サーバクラスタ配置の場合に使用されます。二つの役割にリバースプロキシを要約したものです。
通常、パブリックネットワークアドレスにアクセスするためのリバースプロキシとして、ネットワーク内のネットワーク内のWebサーバーをセキュリティを確保
リバースプロキシサーバーを介してロードサイトを最適化するために、ロードバランシング、
nginxのでフォワードプロキシとリバースプロキシの違い
フォワードプロキシでは、クライアントの情報要求のソースを非表示にします。
リバースプロキシでは、隠されたサーバは、特定の情報の処理を依頼します。
プログラムAPE周Xiansen：私の個人的な社会的関心の番号へようこそ