Nginxを使用してTLSトラフィックを終了する場合、Cloudflareのパッチを使用してサーバーの応答時間を改善できます。 カットの下の詳細。
TLSおよびTCP
ご存知のように、インターネット上のデータはマルチレイヤープロトコルスタックを使用して送信されます。 ここで、TCPとTLSの相互作用に関心があります。 TCPの主な目標は、元の順序での信頼できるパケット配信です。 TLS（HTTPSサイト）を使用するサービスがある場合、すべての暗号化されたTLSデータはTCPを使用して送信されます。
TCPレベル：接続直後、サーバーは
initcwdパケットしか送信できません（古いシステムでは3パケット、新しいシステムでは10パケット）。 その後、サーバーはクライアントからの確認（ACK）を待機し、送信ウィンドウ内のパケット数が徐々に増加し、接続のスループットが増加します。
通常のHTTPトラフィックの場合、すべてが正常です。新しいパケットごとに、ブラウザーが使用できるデータが到着します。
TLSの問題
TLSを使用する場合、NginxはTLSレコードサイズのサイズを制御する特別なバッファー（サイズは
ssl_buffer_sizeディレクティブで指定されます）を使用します。 ブラウザ（クライアント）は、TLSレコードを完全に受信した後にのみデータを使用できます。 同時に、最大（およびNginxのデフォルト）ssl_buffer_sizeサイズは16kです。
パケット送信の初期ウィンドウ= 10であるため、約14kのトラフィックを取得できます。これは、
TLSレコード （16k）よりも少ないです。 これにより、有用なコンテンツの取得が遅れる可能性があります。
HTTP / 2を使用する場合は、http2_chunk_size設定（デフォルトでは8k）に注意する必要があります。これは、応答本文が分割される部分の最大サイズを設定します。 この場合、サーバーへの接続は1つのみ使用されるため、このTCP接続で同時に多くのリソースが転送され、遅延の可能性が高くなります。
何ができますか？
できる最も簡単なことは、
ssl_buffer_sizeを例えば8kまたは12kに減らすことです。 これは、Nginxの標準バージョンで実行できます。 ただし、大量のデータを送信すると、効率が低下します（オーバーヘッドが高くなります）。
理想的なssl_buffer_sizeは存在しないことがわかりました。
動的TLSレコードサイズ
ここで、Cloudflareの
パッチセットが役立ちます。
これらのパッチを使用して、TLSレコードの動的サイズのサポートを取得します。
新しい接続では、レコードサイズは1パケットのサイズ以下に設定されます。特定の数のレコードを渡した後、サイズを3 TCPパケットに増やし、最大サイズ（16k）に増やすことができます。 接続がアイドル状態になると、プロセスが再び開始されます。 このプロセスのすべてのパラメーターは構成可能です。
パッチを適用する
新しい機能を取得するには、パッチを適用してNginxをビルドする必要があります。 OpenSSLを使用してNginxをビルドすることについては既に書いたので、パッチを適用するプロセスについて詳しく見ていきましょう。
パッチを適用するに
は、githubページにアクセスする必要があり
ます 。
このページでは、各ファイルの個々のパッチを分離する必要があります。 パッチ自体の記録は次のように始まります。
diff --git a/src/event/ngx_event_openssl.cb/src/event/ngx_event_openssl.c
このエントリから、このパッチが何を指しているのかが明確になります（この場合は
src / event / ngx_event_openssl.c ）。
パッチテキストをファイル（たとえば、
openssl.c.patch ）にコピーし、ソースファイルの横に配置します。
次のコマンドでパッチを適用します。
patch ngx_event_openssl.c < openssl.c.patch
そのため、すべてのパッチファイルを調べます（合計で4つのファイルが必要です）。
さて、通常どおりNginxをコンパイルします（1.11.2を使用し、すべてがうまくいきました）。
Nginxを構成する
パッチにより、新しい設定が追加されます。 およそ次の値が得られます。
詳細は、Cloudflareブログの元の
記事に記載されています。
TLSレコードサイズの最適化の原理については、
本HPBNで読むことができます。
それは私にとっては、自宅でそれを実装している間、私たちはテストしています。 すでに設定の経験がある場合は、コメントで共有してください。