Time to First ByteのConnection Duration（TCP + TLS）サブパートを最適化する

Optimize the Connection Duration (TCP + TLS) Sub-part of the Time to First Byte

この記事は、私たちのTime to First Byte (TTFB)ガイドの一部です。connection durationはTTFBの4番目のサブパートであり、ブラウザがTCP接続を確立し、サーバーとTLS暗号化をネゴシエートするのに費やす時間を表します。サーバーから地理的に離れているユーザーの場合、TCPおよびTLSハンドシェイクに必要な複数のラウンドトリップにより、connection durationがTTFBに100〜500ミリ秒追加される可能性があります。

Time to First Byte (TTFB) は、以下のサブパートに分類できます：

• Waiting + Redirect（またはwaiting duration）
• Worker + Cache（またはcache duration）
• DNS（またはDNS duration）
• Connection（またはconnection duration）
• Request（またはrequest duration）

Time to First Byteの最適化をお考えですか？ この記事では、Time to First Byteのconnection duration部分について説明します。Time to First Byteを理解または修正しようとしており、connection durationの意味がわからない場合は、この記事を読み始める前に、Time to First Byteとは何かおよびTime to First Byteの問題の特定と修正をお読みください。

Time to First Byteのconnection duration部分は、ブラウザがWebサーバーに接続している時間で構成されます。その接続後、ブラウザとサーバーは通常、暗号化レイヤー（TLS）を追加します。これら2つの接続をネゴシエートするプロセスにはいくらかの時間がかかり、その時間がTime to First Byteに追加されます。

接続プロセスの詳細

Transmission Control Protocol（TCP）は、クライアント（ブラウザ）とサーバー間の信頼できる接続を確立する役割を担います。このプロセスには3ウェイハンドシェイクが含まれます：

• SYN（Synchronize）パケット：クライアントはSYNパケットをサーバーに送信し、接続を開始して同期を要求します。
• SYN-ACK（Synchronize-Acknowledge）パケット：サーバーはSYN-ACKパケットで応答し、SYNパケットの受信を確認し、接続の確立に同意します。
• ACK（Acknowledge）パケット：クライアントはACKパケットをサーバーに送り返し、SYN-ACKパケットの受信を確認します。この時点でTCP接続が確立され、クライアントとサーバー間でデータを確実に転送できるようになります。

TCPは、データが正しい順序で送受信されることを保証し、失われたパケットを再送し、ネットワークの容量に合わせてフロー制御を管理します。

TCP接続が確立されると、Transport Layer Security（TLS）プロトコルを使用して接続が保護されます。TLSハンドシェイクには、サーバーを認証し、安全な通信チャネルを確立するためのいくつかの手順が含まれます：

• ClientHello：クライアントは「ClientHello」メッセージをサーバーに送信し、サポートされているTLSバージョン、暗号スイート、および乱数（Client Random）を示します。
• ServerHello：サーバーは「ServerHello」メッセージで応答し、クライアントのリストからTLSバージョンと暗号スイートを選択し、デジタル証明書と乱数（Server Random）を提供します。
• 証明書と鍵の交換: サーバーは認証のためにデジタル証明書をクライアントに送信します。クライアントは、信頼できる認証局と照らし合わせて証明書を検証します。
• プレマスターシークレット：クライアントはプレマスターシークレットを生成し、サーバーの公開鍵（証明書から）で暗号化して、サーバーに送信します。
• セッション鍵の生成：クライアントとサーバーの両方は、プレマスターシークレットとClient RandomおよびServer Randomを使用して、共通鍵暗号用の共有セッション鍵を生成します。
• Finishedメッセージ：クライアントとサーバーは、セッション鍵で暗号化されたメッセージを交換し、ハンドシェイクが成功したこと、および双方が正しいセッション鍵を持っていることを確認します。

TLSハンドシェイクが完了すると、クライアントとサーバーは安全な暗号化された接続を確立します。これにより、交換されるすべてのデータが、第三者による盗聴や改ざんから確実に保護されます。

TLS 1.3 vs TLS 1.2：なぜそれがTTFBにとって重要なのか

サーバーが使用するTLSのバージョンは、connection durationに直接影響します。TLS 1.3は、ハンドシェイクを完了するために必要なラウンドトリップの数を減らすため、TLS 1.2よりも高速です：

TLS 1.3は、ハンドシェイクを2回のラウンドトリップから1回に減らします。サーバーから100ミリ秒離れているユーザー（ラウンドトリップタイム）の場合、これによりすべての新しい接続で約100ミリ秒節約されます。再訪問者の場合、TLS 1.3の0-RTT（ゼロラウンドトリップタイム）再開により、以前に交換されたセッション情報を再利用することで、クライアントは再接続時に暗号化されたデータをすぐに送信できます。これにより、再訪問者のTLSハンドシェイクのオーバーヘッドをほぼゼロに減らすことができます。

HTTP/3とQUIC：高速接続の未来

HTTP/3は、QUICプロトコルと統合することでTLS接続を高速化します。これにより、ハンドシェイクプロセスを1つに統合して安全な接続を確立するために必要なラウンドトリップの数を減らし、より高速な再接続のための0-RTT再開をサポートします。さらに、QUICはUDPを使用することでhead-of-line blockingを排除し、輻輳制御を改善するため、より効率的なデータ転送とより高速なページロードにつながります。

HTTP/3は、connection durationに直接影響を与える、HTTP/2に対するいくつかの改善をもたらします：

• 統合されたハンドシェイク: TCP上のHTTP/2では、TCPハンドシェイクとTLSハンドシェイクが順番に発生します（新しい接続の場合は合計3回のラウンドトリップ）。QUIC上のHTTP/3は、トランスポートハンドシェイクとTLSハンドシェイクを1回のラウンドトリップに統合します。新しい接続の場合、HTTP/2と比較してラウンドトリップ全体を1回分節約できます。
• 0-RTT接続再開: TLS 1.3と同様に、QUICは0-RTT再開をサポートします。再訪問者は、ハンドシェイクの完了を待たずにすぐにデータの送信を開始できます。これは、Wi-Fiとセルラー接続を頻繁に切り替えるモバイルユーザーにとって特に効果的です。
• head-of-line blockingの排除: TCP上のHTTP/2では、1つのパケットが失われると、そのパケットが再送されるまで、その接続上のすべてのストリームがブロックされます。QUICはUDPを使用し、ストリームを独立して処理するため、失われたパケットはそれが属する特定のストリームにのみ影響します。これにより、信頼性の低いネットワークでもより安定した接続パフォーマンスが得られます。
• 接続マイグレーション: QUIC接続は、送信元IPとポートではなく、接続IDによって識別されます。これは、モバイルユーザーがWi-Fiからセルラーに移動し（IPアドレスが変更され）ても、再確立することなくQUIC接続が維持されることを意味します。これにより、通常であれば必要となる完全なTCP + TLSハンドシェイクを回避できます。

接続時間はTime to First Byteにどのように影響するか？

接続時間がTTFBに与える影響を最小限に抑える方法

重要なオリジンにPreconnectを使用する

<link rel="preconnect">リソースヒントは、そのオリジンのリソースが実際に必要になる前に、指定されたオリジンへの接続（DNS + TCP + TLS）を確立するようにブラウザに指示します。これにより、リソースが最終的にリクエストされたときに、クリティカルパスからconnection durationが排除されます：

<!-- 重要なサードパーティのオリジンへのPreconnect -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">

preconnectは控えめに使用してください（最大3〜5つのオリジン）。各preconnectは完全なTCP + TLS接続を開き、CPUとネットワークリソースを消費します。すべてのページロードで必要となるオリジンにのみpreconnectを使用してください。たまにしか必要とされないオリジンには、代わりにdns-prefetchを使用してください（私たちのDNS durationガイドを参照）。

TLS 1.3およびHTTP/3のためのサーバー設定

• HTTP/3：TCPの代わりにUDP上でQUICプロトコルを提供し、より高速で効率的なデータ転送を可能にします。
• TLS 1.3：セキュリティを強化し、ハンドシェイクのラウンドトリップを減らします。0-RTT接続再開に必要です。
• 0-RTT接続再開：再訪問するクライアントが、以前に交換された情報を再利用することで、再接続時に暗号化されたデータをすぐに送信できるようにするTLS 1.3の機能です。
• TCP Fast Open：初期のSYNパケットでデータを送信できるようにし、TCPハンドシェイクのラウンドトリップタイムを短縮します。
• TLS False Start：TLSハンドシェイクが完了する前に、データの早期送信を可能にします。
• OCSP Stapling：クライアントが認証局に直接連絡する必要性をなくすことで、証明書の検証を高速化します。

TLS 1.3とOCSP Staplingを有効にするNginxの設定例を以下に示します：

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # TLS 1.3暗号スイート
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # OCSP Staplingを有効にする
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # セッション再開を有効にする（TLSセッションチケット）
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... サーバー設定の残り
}

Apacheの場合、以下でTLS 1.3を有効にします：

<VirtualHost *:443>
    SSLEngine on
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # OCSP Staplingを有効にする
    SSLUseStapling On
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    # セッション再開を有効にする
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... 仮想ホスト設定の残り
</VirtualHost>

Time to First Byteのヒント：CDNはより短いラウンドトリップタイムを提供するだけではありません。プレミアムCDNプロバイダーはこれらの設定を正しく構成しているため、CDNを使用すると多くの場合、TCPおよびTLSの接続時間がすぐに改善されます。開始するには、私たちのパフォーマンスのためのCloudflare設定に関するガイドをご覧ください。

JavaScriptでConnection Durationを測定する

Navigation Timing APIを使用すると、ブラウザで直接TTFBのconnection durationサブパートを測定できます：

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');

  const tcpDuration = nav.connectEnd - nav.connectStart;
  const tlsDuration = nav.connectEnd - nav.secureConnectionStart;
  const totalConnection = tcpDuration;

  console.log('Connection Duration:', totalConnection.toFixed(0), 'ms');
  console.log('  TCP handshake:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  TLS negotiation:', tlsDuration.toFixed(0), 'ms');

  if (nav.nextHopProtocol) {
    console.log('  Protocol:', nav.nextHopProtocol);
  }
}).observe({
  type: 'navigation',
  buffered: true
});

nextHopProtocolプロパティは、接続に使用されたプロトコルを明らかにします。一般的な値は「h2」（HTTP/2）、「h3」（HTTP/3）、および「http/1.1」です。サーバーがHTTP/3をサポートしているにもかかわらず、RUMデータでほとんどの接続が「h2」を使用していることが示されている場合、Alt-Svcヘッダーを介してHTTP/3のサポートが適切にアドバタイズされていない可能性があります。

遅延した接続時間によるTTFBの問題を見つける方法

接続レイテンシによって実際のユーザーが経験する影響を見つけるには、CoreDashのようなRUMツールを使用する必要があります。Real User Monitoringを使用すると、28日間のGoogleの遅延なしに、より詳細にCore Web Vitalsを追跡できます。

CoreDashで、「Time to First Byte breakdown」をクリックして、Time to First Byteの接続部分を視覚化します。

さらに読む：最適化ガイド

関連ガイド：

• 103 Early Hints：サーバーはメインレスポンスを処理している間にもリソースヒント（preload、preconnect）を送信できるため、ブラウザはより早く接続の確立を開始できます。
• パフォーマンスのためのCloudflare設定：Cloudflareは自動的にHTTP/3、TLS 1.3、およびOCSP Staplingを有効にします。CDNを使用すると、サーバーがユーザーに近づき、すべての接続のラウンドトリップタイムも短縮されます。

TTFBサブパート：完全ガイド

connection durationは、TTFBの5つのサブパートの1つです。全体像を理解するために、他のサブパートもご覧ください：

• TTFBの問題の特定と修正：すべてのTTFB最適化の診断の出発点。
• Waiting Duration：リダイレクト、ブラウザのキューイング、およびHSTS最適化。
• Cache Duration：Service Workerのパフォーマンス、ブラウザキャッシュのルックアップ、およびbfcache。
• DNS Duration：DNSプロバイダーの選択、TTL設定、およびdns-prefetch。
• Request Duration：サーバー処理時間、データベースクエリ、およびバックエンド最適化。