Apache サーバー (mod_deflate) で gzip 圧縮を有効にした後、エンド ユーザーが非圧縮の応答よりも平均 200 ミリ秒遅く処理されていることが一貫してわかりました。
これは予想外だったので、テキスト/HTML 応答のみを圧縮するように圧縮ディレクティブを変更し、wireshark を起動して、圧縮前後のネットワーク ダンプを調べました。
これは、ネットワーク内のトラフィックが最小のGETに関する私の観察です。
圧縮前
電信送金: 46 46 トランスの合計時間: 791ms 私。TCP seq/ack: 14ms ii. 最初のデータ セグメント: 693ms iii. 残り: 83 ミリ秒 (転送された 27/28 データ ユニット + tcp/ip ハンドシェイク)
圧縮後
電信送金: 10 46 トランスの合計時間: 926ms 私。TCP seq/ack: 14ms ii. 最初のデータ セグメント: 746ms iii. 残り: 165 ミリ秒 (6 つのデータ ユニットのうち 5 つが転送された)
圧縮が設定された後、ネットワーク上のトランザクション数が非圧縮よりも大幅に少ないことは明らかで理解できます。
ただし、圧縮されたデータ ユニットは、ソースから宛先への転送にはるかに長い時間がかかりました。
圧縮の追加作業には当然時間がかかるようですが、送信された各データが圧縮時に大幅に遅くなった理由を理解できません。
圧縮プロセスに関する私の理解は次のとおりです。
1. Apache が GET リクエストを受け取る 2. Apache がリソースを識別する 3. リソースを圧縮する 4.圧縮された応答で応答する
このスキームでは、3番目のステップは（応答の最初のセグメントの前のステップは、圧縮+応答であるため、より長い時間がかかりますが、私が想定した残りのチャンクは平均して等しいと仮定します非圧縮チャンクとしての時間ですが、そうではありません。
誰でも理由を教えてもらえますか...または、このシナリオを分析するためのより良い方法を提案してください。また、誰かが前後の比較を持っていますか...フィードバック/コメント/質問をいただければ幸いです