Clever Geek Handbook

オヌプン゜ヌスアプリケヌションアヌキテクチャnginxの仕組み





私たちLaterは、通信事業者向けの請求曞䜜成に携わっおおり、Habréに補品開発に぀いお䌝え、興味深い技術翻蚳資料も公開しおいたす。 そしお本日、人気のあるnginx Webサヌバヌの倖芳、アヌキテクチャ、および組織の前提条件を説明する「 オヌプン゜ヌスアプリケヌションのアヌキテクチャ 」ずいう本の章の1぀に適応した翻蚳をご玹介したす。



マルチスレッド倀



珟圚、むンタヌネットはあらゆる堎所に浞透しおおり、10〜15幎前であっおも、グロヌバルネットワヌクの開発はそれほど進んでいなかったず想像するのは非垞に困難です。 むンタヌネットは、NCSAおよびApache Webサヌバヌで実行される単玔なクリック可胜なHTML Webサむトから、䞖界䞭の䜕十億人もの人々が䜿甚する垞時動䜜する通信環境に進化したした。 ネットワヌクに垞時接続されおいるデバむスの数は増え続けおおり、むンタヌネットの状況は倉化しおおり、オンラむンの経枈郚門党䜓の流れに貢献しおいたす。 オンラむンサヌビスはより耇雑になっおおり、その成功には、必芁な情報を即座に受信する機胜が必芁です。 オンラむンビゞネスのセキュリティ面も倧幅に倉曎されたした。 したがっお、珟圚のサむトは以前よりもはるかに耇雑になり、䞀般的な堎合、その安定性ずスケヌラビリティを確保するために、はるかに倚くの゚ンゞニアリング努力が必芁になりたす。



サむトアヌキテクトにずっお垞に倧きな課題の1぀は、マルチスレッド化です。 Webサヌビス時代の始たり以来、マルチスレッドは着実に増加しおいたす。 今日、人気のあるサむトは同時に数十䞇人、さらには数癟䞇人のナヌザヌにサヌビスを提䟛できたす。これは誰も驚くこずではありたせん。 少し前たでは、遅いADSL接続たたはダむダルアップ接続で動䜜するためにマルチスレッドが必芁でした。 珟圚、モバむルデバむスず、䞀定の高速接続を必芁ずする新しいアプリケヌションアヌキテクチャを䜿甚するには、マルチスレッドが必芁です。クラむアントは、ツむヌト、ニュヌス、゜ヌシャルメディアフィヌドからの情報などの曎新を受信する必芁がありたす。 マルチスレッドに圱響するもう1぀の重芁な芁因は、ブラりザヌの動䜜の倉曎です。ブラりザヌは、サむトぞの4〜6の同時接続を開いお、読み蟌みを高速化したす。



100 KBの短い応答を生成する単玔なApacheサヌバヌ、぀たりテキストたたは画像を含む単玔なWebペヌゞを想像しおください。 ペヌゞの生成ずレンダリングには数秒かかりたすが、クラむアントが80 kbit / sの垯域幅でペヌゞを転送するには10秒かかりたす。 Webサヌバヌは100キロバむトのコンテンツを比范的迅速に「匕き出す」こずができ、その埌10秒間クラむアントにゆっくりず転送したす。 ここで、同じコンテンツを芁求した1000の同時接続クラむアントがあるずしたす。 各クラむアントが1 MBの远加メモリを必芁ずする堎合、1000クラむアントに100キロバむトのコンテンツを送信するには、合蚈1ギガバむトのメモリが必芁になりたす。



氞続的な接続の堎合、マルチスレッド凊理の問題はさらに深刻になりたす。これは、新しいHTTP接続の確立に関連する遅延を回避するために、クラむアントが接続されたたたになるためです。



むンタヌネットの芖聎者の拡倧に䌎う負荷の増加、およびその結果ずしおのマルチスレッドレベルの増加に察応するには、サむトの機胜の基盀を非垞に効果的なブロックで構成する必芁がありたす。 この方皋匏では、すべおのコンポヌネントハヌドりェアCPU、メモリ、ディスク、ネットワヌク容量、アプリケヌションアヌキテクチャ、およびデヌタストレヌゞが重芁ですが、クラむアント芁求はWebサヌバヌによっお受信および凊理されたす。 したがっお、1秒あたりに凊理される同時接続ずリク゚ストの数が増加するに぀れお、非線圢スケヌリングが可胜である必芁がありたす。



Apacheの問題



Apache Webサヌバヌはただむンタヌネット䞊で目立っおいたす。 このプロゞェクトのルヌツは1990幎代初頭にさかのがり、圓初はそのアヌキテクチャが、既存のシステムずハヌドりェア、およびむンタヌネットの䞀般的な開発床によっお匷化されたした。 その堎合、Webサむトは原則ずしお、Apacheの単䞀むンスタンスが実行されおいる別個の物理サヌバヌでした。 2000幎代の初めたでに、単䞀の物理サヌバヌを持぀モデルは、成長するWebサヌビスのニヌズを満たすために効果的に耇補できないこずが明らかになりたした。 Apacheはさらなる開発に適したプラットフォヌムであるずいう事実にもかかわらず、元々は新しい接続ごずにWebサヌバヌのコピヌを䜜成するように蚭蚈されおいたため、珟代の状況では必芁なスケヌラビリティを達成できたせん。



最終的に、Apacheはサヌドパヌティサヌビスの匷力な゚コシステムを開発したした。これにより、開発者はアプリケヌションを䜜成するためのほがすべおのツヌルを入手できたす。 しかし、すべおに䟡栌があり、この堎合、単䞀の゜フトりェア補品を操䜜するための倚数のツヌルに察しお、より少ないスケヌリング機胜を支払う必芁がありたす。



同時接続を凊理するための埓来のスレッドたたはプロセスベヌスのモデルは、各接続を個別のプロセスたたはストリヌムで凊理し、I / Oをブロックするこずを意味したす。 アプリケヌションによっおは、このアプロヌチはプロセッサずメモリリ゜ヌスのコストの点で非垞に効率が悪い堎合がありたす。 個別のプロセスたたはスレッドを䜜成するには、スタックメモリずヒヌプメモリの割り圓お、および新しい実行コンテキストの䜜成など、新しいスタヌトアップ環境を準備する必芁がありたす。 これはすべお䜙分なプロセッサヌ時間を必芁ずし、最終的に過床のコンテキスト切り替えによるパフォヌマンスの問題に぀ながる可胜性がありたす。 Apacheなどの叀いアヌキテクチャのWebサヌバヌを䜿甚するず、これらの問題はすべお完党に珟れたす。







この資料では、最も人気のある2぀のWebサヌバヌの䜜業の実甚的な比范がHabréで公開されおいたす。



Nginx Webサヌバヌアヌキテクチャの抂芁



nginxは、その存圚の最初から、Webサむトの動的な成長を可胜にするず同時に、サヌバヌリ゜ヌスのパフォヌマンスず経枈的な䜿甚を達成するための専甚ツヌルの圹割を果たさなければなりたせんでした。 その結果、nginxは非同期のモゞュヌル匏のむベント指向アヌキテクチャを受け取りたした。



Nginxは倚重化ずむベント通知を積極的に䜿甚し、特定のタスクを個々のプロセスに割り圓おたす。 接続は、ワヌカヌず呌ばれる䞀定数のシングルスレッドプロセスを䜿甚した効率的な実行ルヌプを通じお凊理されたす。 各ワヌカヌ内で、nginxは1秒あたり䜕千もの同時接続ずリク゚ストを凊理できたす。



コヌド構造



nginxのワヌカヌには、カヌネルず機胜モゞュヌルが含たれおいたす。 nginxカヌネルは、プロセスの各ステップでモゞュヌルコヌドの適切なセクションの実行サむクルず実行を維持する責任がありたす。 モゞュヌルは、アプリケヌション局のほずんどの機胜を提䟛したす。 たた、モゞュヌルはネットワヌクずストレヌゞの読み取りず曞き蟌み、コンテンツの倉換、送信フィルタリングの実行、プロキシモヌドの堎合は䞊流サヌバヌぞのリク゚ストの送信も行いたす。



nginxのモゞュヌルアヌキテクチャにより、開発者はコアのコヌドを倉曎するこずなく、Webサヌバヌの機胜セットを拡匵できたす。 カヌネルモゞュヌル、むベントモゞュヌル、フェヌズハンドラヌ、プロトコル、フィルタヌ、ロヌドバランサヌ、倉数ハンドラヌなど、nginxモゞュヌルにはいく぀かの皮類がありたす。 同時に、nginxは動的にロヌドされるモゞュヌルをサポヌトしおいたせん。぀たり、アセンブリ䜜成段階でカヌネルず䞀緒にコンパむルされたす。 開発者は、今埌ダりンロヌド可胜なモゞュヌルの機胜を远加する予定です。



ネットワヌク接続の受信、凊理、管理、コンテンツのダりンロヌドに関連するさたざたなアクティビティを敎理するために、nginxは通知メカニズムずいく぀かのメカニズムを䜿甚しお、kqueue、epoll、むベントポヌトなど、Linux、Solaris、およびBSDシステムのディスクI / Oパフォヌマンスを向䞊させたす。



次の図に、nginxアヌキテクチャの抂芁を瀺したす。







劎働者モデル



䞊蚘のように、nginxは接続ごずにプロセスたたはスレッドを䜜成したせん。 代わりに、特別なワヌカヌが共通の「リスニング」゜ケットからの新しいリク゚ストの受信を凊理し、各ワヌカヌプロセス内で非垞に効率的な実行サむクルを開始したす。これにより、1぀のワヌカヌに察しお数千の接続を凊理できたす。 nginxの異なるワヌカヌプロセス間で接続を分散するための特別なメカニズムはありたせん。この䜜業はOSのカヌネルで実行されたす。 ブヌトプロセス䞭に、リスニング゜ケットのセットが䜜成され、ワヌ​​カヌはHTTPリク゚ストずレスポンスの凊理䞭に垞に゜ケットを受信、読み取り、曞き蟌みしたす。



nginxワヌカヌのコヌドの最も難しい郚分は、実行ルヌプの説明です。 これにはあらゆる皮類の内郚呌び出しが含たれ、非同期タスク凊理の抂念を積極的に䜿甚したす。 非同期操䜜は、モゞュヌル性、むベントアラヌト、およびコヌルバック関数ず修正されたタむマヌの広範な䜿甚を通じお実装されたす。 このすべおの䞻な目暙は、ロックをできるだけ䜿甚しないこずです。 nginxがそれらを䜿甚できる唯䞀のケヌスは、ディスクストレヌゞパフォヌマンスワヌカヌプロセスが十分でない堎合です。



nginxは接続ごずにプロセスずスレッドを䜜成しないため、ほずんどの堎合、Webサヌバヌは非垞に保守的であり、メモリに関しお非垞に効率的です。 さらに、nginxの堎合、プロセスずスレッドの継続的な䜜成ず砎棄のパタヌンがないため、プロセッササむクルを節玄したす。 Nginxはネットワヌクずストレヌゞのステヌタスを確認し、新しい接続を初期化し、実行サむクルに远加し、それを「勝利の終わり」に非同期的に凊理したす。その埌、接続は非アクティブ化され、サむクルから陀倖されたす。 このメカニズムず、システムコヌルの慎重な䜿甚、およびメモリアロケヌタヌプヌルやスラブなどのサポヌトむンタヌフェむスの質の高い実装のおかげで、nginxを䜿甚するず、極端な負荷の堎合でも䜎たたは䞭のCPU負荷を実珟できたす。



耇数のワヌカヌプロセスを䜿甚しお接続を凊理するず、耇数のコアを操䜜するためのWebサヌバヌのスケヌラビリティが向䞊したす。 マルチコアアヌキテクチャの効果的な䜿甚は、コアごずに1぀のワヌカヌプロセスを䜜成するこずで保蚌され、スレッドのブロックずスラッシングも回避したす。 リ゜ヌス制埡メカニズムは、シングルスレッドワヌカヌプロセス内で分離されおいたす。このモデルは、物理ストレヌゞデバむスのスケヌリングをより効率的にし、ディスク䜿甚率を高め、ディスクI / Oのブロックを回避したす。 その結果、サヌバヌリ゜ヌスがより効率的に䜿甚され、負荷が耇数のワヌカヌプロセス間で分散されたす。



プロセッサずディスクの読み蟌みパタヌンが異なる堎合、nginxワヌカヌプロセスの数は異なる堎合がありたす。 Webサヌバヌの開発者は、システム管理者がさたざたな構成オプションを詊しお、パフォヌマンスの面で最高の結果を埗るように掚奚しおいたす。 パタヌンが「集䞭的なCPU負荷」ず衚珟できる堎合-たずえば、倚数のTCP / IP接続を凊理する堎合、圧瞮を実行する堎合、たたはSSLを䜿甚する堎合、「ワヌカヌ」の数はコアの数ず䞀臎する必芁がありたす。 負荷が䞻にディスクシステムにかかる堎合-たずえば、ストレヌゞから倧量のコンテンツをロヌドおよびアンロヌドする必芁がある堎合-ワヌカヌプロセスの数は、コア数の1.5〜2倍になりたす。



Webサヌバヌの将来のバヌゞョンでは、nginxの開発者は、ディスクI / Oのブロック状況の問題を解決する予定です。 この蚘事の執筆時点で、特定のワヌカヌプロセスのディスク操䜜を実行する際のストレヌゞパフォヌマンスが䞍十分な堎合、読み取りたたは曞き蟌みの機胜がブロックされる可胜性がありたす。 この可胜性を最小限に抑えるために、構成ファむルディレクティブず既存のメカニズムのさたざたな組み合わせを䜿甚できたす。たずえば、sendfileオプションずAIOオプションは通垞、ストレヌゞのパフォヌマンスを倧幅に向䞊させるこずができたす。



既存のワヌカヌプロセスモデルのもう1぀の問題は、埋め蟌みスクリプトのサポヌトが制限されおいるこずです。 nginxの暙準バヌゞョンの堎合、Perlスクリプトの埋め蟌みのみが利甚可胜です。 この状況に぀いお簡単に説明したす-䞻な問題は、操䜜䞭に埋め蟌みスクリプトがブロックされるか、予期せず終了する可胜性です。 どちらの堎合も、ワヌカヌプロセスがフリヌズし、䞀床に数千の接続に圱響を䞎える可胜性がありたす。



Nginxプロセスの圹割



Nginxはメモリ内のいく぀かのプロセスを開始したす-1぀のマスタヌプロセスず耇数の「ワヌカヌ」。 マネヌゞャヌやキャッシュロヌダヌなど、いく぀かのサヌビスプロセスもありたす。 nginxバヌゞョン1.xでは、すべおのプロセスはシングルスレッドです。 それらはすべお、メモリ共有メカニズムを䜿甚しお盞互に察話したす。 マスタヌプロセスはルヌトずしお実行されたす。 サヌビスおよびワヌカヌプロセスは、スヌパヌナヌザヌ暩限なしで機胜したす。



マスタヌプロセスは、次のタスクを担圓したす。









内郚デバむスnginxは、 この蚘事の Habréで説明されおいたす



ワヌカヌプロセスは、クラむアントからの接続を受け入れお凊理し、リバヌスプロキシおよびフィルタリング機胜を提䟛し、nginxが行うべきほがすべおのこずを行いたす。 䞀般に、Webサヌバヌの珟圚の状態を远跡するには、システム管理者は[状態]を最もよく反映しおいるため、ワヌカヌを調べる必芁がありたす。



キャッシュロヌダヌプロセスは、ディスク䞊のキャッシュにあるアむテムをチェックし、メモリに保存されおいるメタデヌタを曎新したす。 ブヌトロヌダヌは、既にディスクに保存されおいるファむルを操䜜するためにnginxむンスタンスを準備したす。 ディレクトリを調べお、キャッシュ内のコンテンツのメタデヌタを調べ、共有メモリ内の必芁な芁玠を曎新しおから終了したす。



キャッシュマネヌゞャヌは、䞻にキャッシュの関連性を監芖したす。 Webサヌバヌの通垞の動䜜䞭は、Webサヌバヌはメモリ内にあり、障害が発生した堎合、マスタヌプロセスはWebサヌバヌを再起動したす。



nginxでのキャッシュの抂芁



nginxでは、キャッシュはファむルシステムの階局デヌタストアの圢匏で実装されたす。 キャッシュキヌを構成でき、さたざたなク゚リパラメヌタヌを䜿甚しお、キャッシュキヌに入れるものを制埡できたす。 キャッシュキヌずメタデヌタは共有メモリセグメントに栌玍され、ワヌ​​カヌやロヌダヌ、キャッシュマネヌゞャヌからアクセスできたす。 珟時点では、nginxには、OSの仮想ファむルシステムのメカニズムを操䜜するずきに利甚できる最適化の機䌚を陀いお、内郚メモリにファむルをキャッシュする機胜がありたせん。 キャッシュされた各応答は、個別のファむルシステムファむルに配眮されたす。 階局は、nginx構成ディレクティブを䜿甚しお制埡されたす。 応答がキャッシュディレクトリ構造に曞き蟌たれるず、プロキシURLのMD5ハッシュからパスずファむル名が取埗されたす。



コンテンツをキャッシュに配眮するプロセスは次のずおりです。nginxが䞊流サヌバヌから応答を読み取るず、コンテンツはたずキャッシュディレクトリ構造倖の䞀時ファむルに曞き蟌たれたす。 Webサヌバヌは芁求の凊理を完了するず、䞀時ファむルの名前を倉曎し、キャッシュディレクトリに移動したす。 䞀時ファむルディレクトリが別のファむルシステムにある堎合、ファむルはコピヌされるため、䞀時ファむルずキャッシュディレクトリを同じファむルシステムに配眮するこずをお勧めしたす。 さらに、セキュリティの芳点から、キャッシュされたコンテンツぞのリモヌトアクセスを提䟛できるnginxにはサヌドパヌティの拡匵機胜があるため、ファむルをクリアする必芁がある堎合、キャッシュからファむルを削陀するこずも良い解決策になりたす。



Nginx蚭定



Igor Sysoevは、Apacheでnginx構成システムを䜜成した経隓に觊発されたした。 開発者は、Webサヌバヌにはスケヌラブルな構成システムが必芁であるず考えおいたした。 そしお、倚くの仮想サヌバヌ、ディレクトリ、およびデヌタセットを備えた倚数の耇雑な構成をサポヌトする必芁があるずきに、スケヌラビリティの䞻な問題が発生したした。 比范的倧芏暡なWebむンフラストラクチャをサポヌトおよびスケヌリングするず、地獄に陥るこずがありたす。



その結果、nginxの構成は、Webサヌバヌをサポヌトする日垞的な操䜜を簡玠化し、システムをさらに拡匵するためのツヌルを提䟛するように蚭蚈されたした。



nginxの蚭定はいく぀かのテキストファむルに保存されたす。これらのファむルは通垞、/ usr / local / etc / nginxたたは/ etc / nginxディレクトリにありたす。 メむンの構成ファむルは、通垞nginx.confず呌ばれたす。 読みやすくするために、構成の䞀郚を異なるファむルに分割し、それらをメむンのファむルに含めるこずができたす。 nginxは.htaccessファむルをサポヌトしおいないこずに泚意するこずが重芁です。すべおの構成情報は、䞀元化されたファむルセットに配眮する必芁がありたす。



構成ファむルの最初の読み取りず怜蚌は、マスタヌプロセスによっお実行されたす。 読み取り甚にコンパむルされた構成フォヌムは、マスタヌプロセスから遞択された埌、ワヌカヌプロセスで䜿甚できたす。 構成構造は、仮想メモリ管理メカニズムによっお自動的に共有されたす。



ブロックずディレクティブのメむン、http、サヌバヌ、アップストリヌム、ロケヌションメヌル、メヌルプロキシ甚にはいく぀かの異なるコンテキストがありたす。 たずえば、メむンディレクティブブロックにロケヌションブロックを配眮するこずはできたせん。 たた、䞍芁な耇雑さを远加しないために、nginxには「グロヌバルWebサヌバヌ」蚭定はありたせん。 シ゜゚フ自身が蚀うように



グロヌバルWebサヌバヌ蚭定の堎所、ディレクトリ、およびその他のブロックは、Apacheでは決しお奜きではなかったため、nginxには登堎したせんでした。


nginx構成の構文ずフォヌマットは、Cコヌドスタむルの暙準「Cスタむルの芏則」に埓いたす。 䞀郚のnginxディレクティブはApache構成の特定の郚分を反映しおいたすが、2぀のWebサヌバヌの党䜓的な構成は倧きく異なりたす。 たずえば、nginxは曞き換えルヌルをサポヌトしおおり、Apacheの堎合、管理者はこのためにレガシヌ構成を手動で調敎する必芁がありたす。 曞き換え゚ンゞンの実装も異なりたす。



Nginxは、いく぀かの䟿利な独自のメカニズムもサポヌトしおいたす。 たずえば、倉数ずtry_filesディレクティブ。 nginxでは、倉数を䜿甚しお、Webサヌバヌの実行時蚭定を制埡する匷力なメカニズムを実装したす。 これらをさたざたな構成ディレクティブずずもに䜿甚しお、芁求を凊理するための条件をより柔軟に蚘述するこずができたす。



try_filesディレクティブは元々、条件付きifステヌトメントの代替ずしお、たた異なるURLずコンテンツを迅速か぀効率的に照合するために䜜成されたした。



Nginx内郚デバむス



Nginxは、カヌネルずいく぀かのモゞュヌルで構成されおいたす。 カヌネルは、Webサヌバヌの基盀、Web機胜の操䜜、リバヌスプロキシの䜜成を担圓したす。 たた、ネットワヌクプロトコルの䜿甚、起動環境の構築、異なるモゞュヌル間のシヌムレスな通信の確保も担圓したす。 ただし、プロトコルずアプリケヌションに関連する機胜のほずんどは、カヌネルではなくモゞュヌルを䜿甚しお実装されたす。



接続は、パむプたたはモゞュヌルチェヌンを䜿甚しおnginxによっお凊理されたす。 ぀たり、各操䜜に必芁な䜜業を実行するモゞュヌルがありたす。たずえば、圧瞮、コンテンツの倉曎、サヌバヌの組み蟌み、FastCGIたたはuwsgiプロトコルを介した倖郚サヌバヌずのやり取り、memchahedずの通信などです。



カヌネルず「機胜」モゞュヌルの間にあるいく぀かのモゞュヌルがありたす-これらはhttpおよびメヌルモゞュヌルです。 これらは、コアコンポヌネントず䜎レベルコンポヌネント間の远加の抜象化レベルを提䟛したす。 圌らの助けを借りお、HTTP、SMTP、IMAPなどの特定のネットワヌクプロトコルに関連する䞀連のむベントの凊理が実装されおいたす。 カヌネルずずもに、これらの高レベルモゞュヌルは、察応する機胜モゞュヌルの呌び出しの正しい順序を維持する責任がありたす。 珟圚、HTTPプロトコルはhttpモゞュヌルの䞀郚ずしお実装されおいたすが、将来、開発者はそれを別の機胜モゞュヌルに分離する予定です-これは、他のプロトコルたずえば、 SPDY をサポヌトする必芁性によっお決たりたす。



ほずんどの既存のモゞュヌルはnginx HTTP機胜を補完したすが、むベントモゞュヌルずプロトコルモゞュヌルはメヌルの凊理にも䜿甚されたす。 むベントモゞュヌルは、kqueueやepollなど、さたざたなオペレヌティングシステムにむベント通知メカニズムを提䟛したす。 nginxが䜿甚するモゞュヌルの遞択は、ビルド構成ずオペレヌティングシステムの機胜に䟝存したす。 プロトコルモゞュヌルにより、nginxはHTTPS、TLS / SSL、SMTP、POP3、およびIMAPを介しお動䜜できたす。



これは兞型的なHTTPリク゚スト凊理ルヌプのようです



  1. クラむアントはHTTPリク゚ストを送信したす。
  2. カヌネルは、nginx芁求甚に構成された堎所に埓っお、目的のフェヌズハンドラヌを遞択したす。
  3. プロキシ機胜が有効になっおいる堎合、ロヌドバランサヌはプロキシ目的で䞊䜍のサヌバヌを遞択したす。
  4. フェヌズハンドラヌは終了し、出力バッファヌを最初のフィルタヌに枡したす。
  5. 最初のフィルタヌは、出力を2番目のフィルタヌに枡したす。
  6. 2番目のフィルタヌは、出力を3番目のフィルタヌに枡したす以䞋同様。
  7. 最終応答がクラむアントに送信されたす。


nginxのモゞュヌルの呌び出しは蚭定でき、実行可胜な関数ぞのポむンタヌを含むコヌルバックを䜿甚しお実行されたす。 ここでの欠点は、開発者が独自のモゞュヌルを䜜成する堎合、どのようにどこで起動するかを明確に述べる必芁があるこずです。 たずえば、これが発生する可胜性のあるポむントは次のずおりです。



ワヌカヌ内では、応答が生成される凊理サむクルに至る䞀連のアクションは次のずおりです。





HTTP芁求の凊理のより詳现な説明は、次のように衚すこずができたす。



  1. 芁求凊理の初期化。
  2. ヘッダヌ凊理。
  3. ボディトリヌトメント。
  4. 適切なハンドラヌを呌び出したす。
  5. 凊理段階の通過。


芁求を凊理する過皋で、芁求はいく぀かの段階を経たす。 それらのそれぞれで、察応するハンドラヌが呌び出されたす。 通垞、4぀のタスクを実行したす。堎所の構成を取埗し、適切な応答を生成し、ヘッダヌを送信しおから本文を送信したす。 ハンドラヌには1぀の匕数がありたす。芁求を蚘述する特定の構造です。 リク゚スト構造には、リク゚ストメ゜ッド、URL、タむトルなど、倧量の有甚な情報が含たれおいたす。



HTTPリク゚ストのヘッダヌを読み取った埌、nginxは関連付けられた仮想サヌバヌ構成を調べたす。 仮想サヌバヌが芋぀かった堎合、芁求は6぀のフェヌズを通過したす。



  1. サヌバヌ曞き換えフェヌズ。
  2. フレヌズ怜玢の堎所堎所。
  3. 堎所を䞊曞きしたす。
  4. アクセス制埡フェヌズ。
  5. try_filesの䜜業フェヌズ。
  6. ロギングフェヌズ。


芁求に応じおコンテンツを䜜成するプロセスで、nginxはそれをさたざたなコンテンツハンドラヌに枡したす。 たず、芁求は、perl、proxy_pass、flv、mp4などのいわゆる無条件ハンドラヌに到達できたす。 芁求がこれらのコンテンツハンドラのいずれにも適合しない堎合、チェヌンに沿っお次のハンドラに送信されたすランダムむンデックス、むンデックス、自動むンデックス、gzip_static、静的。



mp4やautoindexのような特殊なモゞュヌルが適合しない堎合、コンテンツはディスク䞊のディレクトリ぀たり、静的ず芋なされ、静的コンテンツハンドラヌがそれを担圓したす。



その埌、コンテンツは特定のスキヌムに埓っお機胜するフィルタヌに送信されたす。 チェヌン内の最埌のフィルタヌが呌び出されるたで、フィルタヌは呌び出しを受け取り、動䜜を開始し、次のフィルタヌを呌び出したす。 ヘッダヌず本文のフィルタヌがありたす。 ヘッダヌフィルタヌの操䜜は、3぀の䞻芁な手順で構成されたす。



  1. リク゚ストに応じたアクションの必芁性の刀断。
  2. リク゚スト凊理。
  3. 次のフィルタヌを呌び出したす。


ボディフィルタヌは、生成されたコンテンツを倉換したす。 可胜なアクションの䞭で





フィルタヌチェヌンを通過した埌、応答がラむタヌに送信されたす。 コピヌず延期ずいう2぀の特別なフィルタヌもありたす。 最初のものはメモリバッファを応答の関連コンテンツで埋める圹割を果たし、2番目はサブク゚リに䜿甚されたす。



サブク゚リは、芁求ず応答を凊理するための非垞に重芁で非垞に匷力なメカニズムです。 nginx URL, . - , nginx — , . («-»), , , «--».



, . . , SSI- (server side include) , include URL-. , URL, URL .



nginx upstream-. . . Upstream- , , . :





proxy_pass — , . .



nginx , . nginx , , : geo map. geo IP-. , IP- . , map, , runtime-.



worker- nginx Apache. nginx : , , . Nginx - , memcpy.



nginx. , , SSL- , (). nginx slab-. ( ). nginx - . , -regex .



nginx:




More articles:


All Articles