cgi php-cgi、PHP の基本原理

一概念:

cgi

cgi (共通ゲートウェイインターフェース)、共通ゲートウェイインターフェース。 Web サーバー (nginx など) とスクリプト パーサー (php-cgi など) の間で対話するときに使用されるプロトコル。リクエストされた URL、http ヘッダー、投稿データなどのデータがスクリプト パーサーに渡される形式と、スクリプト パーサーが http 応答を返す形式を指定します。

fastcgi

fastcgi は、CGI プロトコルのアップグレード版です。標準 CGI は、リクエストごとに対応するスクリプトの設定ファイル (php.ini など) を解析し、設定と拡張機能をロードし、実行環境を初期化します。パフォーマンスは非常に悪いです。 fastcgi は、応答速度を向上させるためにマスターワーカー モードと常駐メモリ戦略を採用しています。

php-cgi

php の fastcgi 実装は、php スクリプト パーサーとして php スクリプトを実行する役割もあります。欠点は、プロセス管理とスケジューリングが不十分であることです。

php-fpm

は、spawn-fcgiと同様に、php-cgiプロセスの管理とスケジュールに使用されます

2つの原則

まず、通常のCGIのワークフローを理解します:
Webサーバーはユーザーリクエストを受信し、送信しますCGI プログラムにリクエストを送信すると、CGI プログラムはリクエストで送信されたパラメータをそれに応じて処理し、標準の HTML ステートメントを出力して Web サーバーに返し、Web サーバーはそれをクライアントに返します。これが動作原理です。普通のCGI。
上記より、CGI が実現したいのは動的な Web ページにすぎません。この処理方法の特徴は、リクエストを受信するたびに、Web サーバーがそれを処理するために別の CGI プログラムのプロセスをフォークする必要があることです。このように、Web サーバーが特定のプログラム処理から分離され、構造が明確で制御性が高いという利点があります。同時に、アクセス需要が高い場合、CGI プロセスのフォークが巨大なサーバーになるという欠点があります。データの負担を想像してみてください。何百もの同時リクエストが原因でサーバーが何百ものプロセスをフォークするかどうかがわかります。これが、cgi が常にパフォーマンスが低く、リソース消費量が多いことで悪名が高い理由です。
現在一般的な解決策は、モジュール設計を使用することです。基本的に、現在の Web サーバーは、モジュールがその設計仕様に従って設計されている限り、対応するモジュール機構を備えています。 IIS の isapi や apache の dso のように、Web サーバー自体のプロセス処理に挿入できるため、パフォーマンスが大幅に向上します。しかし、この方法には、異なる規格に従って異なる Web サーバーを開発する必要がある、入力検証作業が Web サーバーに移管されるなど、Web サーバーの独立性が達成できないなどの欠点があります。たとえば、問題が発生するとウェブ全体に影響を及ぼします。 サーバー処理フロー。たとえば、Web サーバー プロセスを挿入すると、マルチユーザー ラベルとして実行できなくなり、仮想ホストの権限を処理できなくなります。
幸いなことに、fastcgi という別の選択肢があります。 Fastcgi は、CGI アーキテクチャに基づく拡張機能であり、その中心的なアイデアは、Web サーバーと特定の CGI プログラムの間にインテリジェントで持続可能な中間層を確立し、CGI プログラムの動作を管理することで、Web サーバーはリクエストを送信するだけで済みます。この層は、いくつかの再利用可能な CGI プログラム インスタンスを取得し、これらのインスタンスにリクエストを分散します。そのため、一方では、プロセスの繰り返しのフォークが回避されます。さらに、中間層の制御および検出メカニズムを使用して、これらのインスタンスの実行ステータスを監視することができ、さまざまな条件に応じてインスタンスをフォークまたはリサイクルして、柔軟性と安定性の両方を実現できます。 PHP の基本的な動作原理 ://www.nowmagic .net/librarys/veda/detail/102/

上記では、PHP の基本原理である cgi php-cgi について、その側面も含めて紹介しています。PHP チュートリアルに興味のある友人に役立つことを願っています。