この記事では、「出力バッファリング」レイヤーがPHPでどのように実装されているか、どのように機能するか、PHPからどのように対話するかについて説明します。 この層には複雑なものは何もありませんが、多くの開発者はその処理方法をまったく理解していないか、完全に明確ではありません。 これから説明するものはすべて、PHPバージョン5.4以降に属します。 それから出発して、出力バッファ（BV）に関連する多くのことが変更されました。 実際、この機能は完全に書き直されているため、バージョン5.3との互換性は部分的にしか保持されていません。

出力バッファーとは何ですか？

PHPの出力ストリームには、通常、開発者が表示する必要のあるテキスト形式のバイトが含まれています。 ほとんどの場合、このためにechoまたはprintf（）コンストラクトが使用されます。 まず、何かを出力する関数はPHPドメインのBVを使用することを理解する必要があります。 PHPの拡張機能について説明すると、アップストリームBVをバイパスして、SAPIに直接書き込む関数にアクセスできます。 C APIはlxr.php.net/xref/PHP_5_5/main/php_output.hに文書化されています。たとえば、デフォルトのバッファーサイズなど、多くの情報をここから収集できます。



2番目の重要なポイント：BVレイヤーは、出力データがバッファリングされる唯一のレイヤーではありません。



3番目：使用しているSAPI（webまたはcli）に応じて、BVレイヤーの動作は異なります。



以下は、上記のすべてを理解するのに役立つ図です。







ここで、PHPは3つの論理バッファリングレイヤーを使用して出力データを制御していることがわかります。 それらの2つは同じ「出力バッファー」に属し、3つ目はSAPIに属します。 出力ストリームがPHPドメインを離れてアーキテクチャの下位レベルに到達すると、途中で新しいバッファーが表示される場合があります。ターミナルバッファー、FastCGIバッファー、Webサーバーバッファー、オペレーティングシステムバッファー、TCP / IPスタックバッファーです。 それを忘れないでください。 この記事のフレームワークではPHPについてのみ説明しますが、最下層とユーザーに向かう途中のスタックにはまだ多くのソフトウェアツールがあります。



SAPI CLIに関する重要な注意： output_bufferingパラメーターiniを0に設定することにより、PHPのデフォルト出力バッファーを無効にします。したがって、CLIでob_（）関数を手動で記述するまで、デフォルトですべての出力はSAPIレイヤーに直接送られます。 さらに、CLIではimplicit_flushパラメーターに値1が暗黙的に指定されています。開発者はこのパラメーターの本質を常に誤解していますが、コードでは完全に明確であると述べています。 つまり、CLI SAPIを使用して出力用のデータを書き込むたびに、それらはすぐに下位レベルに送信され、そこで標準出力として書き込まれ、リセットされます。

標準PHP出力バッファリングレイヤー

CLIではなく、たとえばPHP-FPMのようなSAPIを使用する場合、バッファに関連するiniの3つのパラメーターを試すことができます。

• output_buffering
• implicit_flush
• output_handler

それらがini_set（）を使用しても、PHPがスクリプトを実行する前にPHPの起動時に読み込まれるため、効果はありません。 これらのパラメータのいずれかでini_set（）を使用すると、値が変更されますが、どこでも使用されません。 遅すぎる-BIレイヤーはすでに実行されており、アクティブです。 これらのパラメーターを変更するには、php.iniを編集するか、PHPバイナリに-dスイッチを適用します。



デフォルトでは、PHPに同梱されているphp.ini、 output_bufferingは 「4096」（バイト）に設定されています。 php.iniを使用しない場合（または–nスイッチを指定してPHPを実行する場合）、デフォルト値は「0」、つまり無効になります。 ハードコードが「オン」に設定されている場合、出力バッファの標準サイズ（16 KB）が割り当てられます。



おそらく既に推測したように、Web環境で出力にバッファーを使用すると、パフォーマンスに有益な効果があります。 最初の4 KBで十分です。これは、PHPが基礎となるSAPIレイヤーとの対話を開始するまで、最大4096のASCII文字を書き込むことができるためです。 Webでは、バイト単位でデータを送信しても、パフォーマンスは向上しません。 サーバーがすべてのコンテンツをまとめて送信するか、まとめて送信する方がはるかに優れています。 レベルがデータを交換する頻度が少ないほど、パフォーマンスが向上します。 したがって、必ず出力バッファを使用してください。 PHPはリクエストの最後にその内容を送信します。このために何もする必要はありません。



前の章で、CLIのコンテキストでimplicit_flushについて言及しました。 他のSAPIの場合、 implicit_flushは最初は無効になっています。 SAPIへの書き込み直後にSAPIのリセットを歓迎する可能性は低いため、これは良いことです。 FastCGIプロトコルの場合、リセットは、書き込みのたびにパケットを終了して送信することと比較できます。 ただし、最初にFastCGIバッファーを完全にいっぱいにしてから、パケットを送信することをお勧めします。 SAPIバッファーを手動でリセットする必要がある場合は、これにPHP関数flush（）を使用します。 前述のように、各レコードの後に​​リセットするには、php.iniでimplicit_flushパラメーターを使用できます。 または、PHP関数ob_implicit_flush（）の 1回の呼び出し。



バッファーの出力前に、コールバックoutput_handlerをバッファーのコンテンツに適用できます。 一般に、PHP拡張機能のおかげで、多くのコールバックを使用できます（ユーザーはそれらを作成することもできます。これについては、次の章で説明します）。

• ob_gzhandler：ext / zlibによる出力の圧縮
• mb_output_handler：ext / mbstringで文字エンコーディングを変換します
• ob_iconv_handler：ext / iconvで文字エンコーディングを変換します
• ob_tidyhandler：HTML出力をext / tidyでフラッシュ
• ob_ [inflate / deflate] _handler：ext / httpで出力を圧縮します
• ob_etaghandler：ext / httpを使用してETagヘッダーを自動生成

使用できるコールバックは1つだけです。コールバックは、バッファーのコンテンツを受け取り、出力の有用な変換を行います。これは朗報です。 サーバーがユーザーに送信するWebサーバーにPHPが送信するデータを分析するには、コールバックと出力バッファーを使用すると便利です。 ところで、「結論」とは、見出しと本文の両方を意味します。 HTTPヘッダーも出力バッファ層の一部です。

ボディとヘッダー

出力バッファを使用する場合（カスタムであるか標準のバッファであるかは関係ありません）、HTTPヘッダーとコンテンツを好きなように送信できます。 どのプロトコルでも最初にヘッダーを送信し、次に本文を送信する必要がありますが、BVレイヤーを使用する場合はPHPが送信します。 ヘッダー（ header（）、setcookie（）、session_start（） ）で動作するPHP関数は、実際には内部関数sapi_header_op（）を使用します。これは、単にヘッダーバッファーを埋めます。 その後、たとえばprintf（）を使用して出力データを書き込むと、対応する出力バッファーの1つに書き込まれます。 そして、最初にPHPバッファを送信している間



ヘッダーを送信してから、ボディのみを送信します。 PHPのこの懸念が気に入らない場合は、BVレイヤーを完全に無効にする必要があります。

カスタム出力バッファー

これがどのように機能し、何ができるかの例を見てみましょう。 標準のPHPバッファリングレイヤーを使用する場合、CLIはレイヤーとして無効になっているため使用できないことに注意してください。



以下は、内部SAPI Webサーバーを使用して標準のPHPレイヤーを操作する例です。

/*  : php -doutput_buffering=32 -dimplicit_flush=1 -S127.0.0.1:8080 -t/var/www */ echo str_repeat('a', 31); sleep(3); echo 'b'; sleep(3); echo 'c';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

標準の32バイトの出力バッファーでPHPを開始し、その後、実行遅延がオンになるまですぐに31バイトを書き込みました。 何も送信されない限り、画面は黒です。 その後、 sleep（）アクションが終了し、別のバイトを書き込むことで、バッファーが完全にいっぱいになります。 その後、 implicit_flushの値が1であるため、彼はすぐにSAPIレイヤーのバッファーに自分自身をフラッシュし、出力に自分自身をフラッシュします。 完了すると、空の31バイトのバッファーが1バイトで埋められ、その後PHPが終了してバッファーをフラッシュします。 で画面に表示されます。



これは、ob関数を呼び出さない標準のPHPバッファーの動作です。 これが標準バッファーであること、つまり、すでに使用可能であることを忘れないでください（CLIを使用することはできません）。



ob_start（）を使用すると、メモリがなくなるまでカスタムバッファを必要な数だけ実行できます。 各バッファは前のバッファの後ろに配置され、すぐに次のバッファにフラッシュされます。これにより、徐々にオーバーフローが発生します。

 ob_start(function($ctc) { static $a = 0; return $a++ . '- ' . $ctc . "\n";}, 10); ob_start(function($ctc) { return ucfirst($ctc); }, 3); echo "fo"; sleep(2); echo 'o'; sleep(2); echo "barbazz"; sleep(2); echo "hello"; /* 0- FooBarbazz\n 1- Hello\n */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

出力バッファ装置

前述したように、バージョン5.4以降、出力バッファリングメカニズムは完全に書き直されました。 それ以前は、コードは非常に乱雑で、多くのことが簡単ではなく、多くの場合バグが発生していました。 詳細については、 こちらをご覧ください 。 新しいコードベースは、はるかにきれいで、整理されており、新しい機能が登場しています。 確かに、バージョン5.3との互換性は部分的にしか提供されていません。



おそらく最も楽しい革新の1つは、拡張機能が、他の拡張機能のコールバックと競合するコールバックと出力バッファーを宣言できるようになったことです。 以前は、他の拡張機能もコールバックを宣言できる状況を完全に管理することは不可能でした。



データを大文字に変換するコールバックを登録する方法を示す簡単なサンプルを次に示します。

 #ifdef HAVE_CONFIG_H #include "config.h" #endif #include "php.h" #include "php_ini.h" #include "main/php_output.h" #include "php_myext.h" static int myext_output_handler(void **nothing, php_output_context *output_context) { char *dup = NULL; dup = estrndup(output_context->in.data, output_context->in.used); php_strtoupper(dup, output_context->in.used); output_context->out.data = dup; output_context->out.used = output_context->in.used; output_context->out.free = 1; return SUCCESS; } PHP_RINIT_FUNCTION(myext) { php_output_handler *handler; handler = php_output_handler_create_internal("myext handler", sizeof("myext handler") -1, myext_output_handler, /* PHP_OUTPUT_HANDLER_DEFAULT_SIZE */ 128, PHP_OUTPUT_HANDLER_STDFLAGS); php_output_handler_start(handler); return SUCCESS; } zend_module_entry myext_module_entry = { STANDARD_MODULE_HEADER, "myext", NULL, /* Function entries */ NULL, NULL, /* Module shutdown */ PHP_RINIT(myext), /* Request init */ NULL, /* Request shutdown */ NULL, /* Module information */ "0.1", /* Replace with version number for your extension */ STANDARD_MODULE_PROPERTIES }; #ifdef COMPILE_DL_MYEXT ZEND_GET_MODULE(myext) #endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

落とし穴

ほとんどの場合、それらは文書化されており、一部は非常に明白であり、一部はあまり多くありません。 明らかなものは、たとえば、BVのコールバック内からバッファ関数を呼び出したり、そこからデータ出力を書き込んだりしないようにする必要があるためです。



非自明な落とし穴には、一部のPHP関数が内部BVを使用してそれを埋め、それをリセットまたは戻すという事実が含まれます。 次のバッファがスタックにプッシュされます。 このような関数には、 print_r（）、highlight_file（）、 SoapServer :: handle（）が含まれます。 BVのコールバック内からそれらを使用しないでください-これは予測できない結果を招く可能性があります。

おわりに

出力層は、PHPからの出力の可能性のある「漏れ」をキャッチし、指定されたサイズのバッファーに保存する一種のネットワークと比較できます。 バッファがいっぱいになると、バッファが存在する場合は、下位レベルにフラッシュ（書き込み）されます。 少なくとも利用可能な最も低いもの-SAPIバッファへ。 ユーザーは、バッファーの数、サイズ、およびバッファーの各レイヤーで許可される操作（フラッシュ、フラッシュ、または削除）を制御できます。 これは非常に柔軟なツールであり、たとえば、ライブラリおよびフレームワークの作成者が出力ストリームを完全に制御し、グローバルバッファに送り、そこで処理することができます。 この場合、PHP自体がヘッダーと出力ストリームの送信順序を調整します。



デフォルトでは、iniファイルの3つの設定によって制御される1つの出力バッファーがあります。 これは、書き込み操作の実行頻度を減らし、SAPIレイヤーに頻繁にアクセスしないように設計されているため、ネットワークにアクセスしません。 これは、全体的なパフォーマンスを向上させるために行われます。 また、PHPの拡張機能は、各バッファで起動されるコールバックを宣言できます。たとえば、データ圧縮、文字列置換、HTTPヘッダー制御、その他多くの操作のためです。