Time to First Byte의 연결 시간(TCP + TLS) 하위 요소 최적화

Time to First Byte의 연결 시간(TCP + TLS) 하위 요소 최적화

이 문서는 Time to First Byte (TTFB) 가이드의 일부입니다. 연결 시간은 TTFB의 네 번째 하위 요소이며 브라우저가 TCP 연결을 설정하고 서버와 TLS 암호화를 협상하는 데 보내는 시간을 나타냅니다. 서버에서 지리적으로 멀리 떨어진 사용자의 경우, TCP 및 TLS 핸드셰이크에 필요한 여러 번의 왕복으로 인해 연결 시간이 TTFB에 100~500밀리초를 추가할 수 있습니다.

Time to First Byte (TTFB)는 다음 하위 요소로 나눌 수 있습니다.

• 대기 + 리디렉션 (또는 대기 시간)
• 워커 + 캐시 (또는 캐시 시간)
• DNS (또는 DNS 시간)
• 연결 (또는 연결 시간)
• 요청 (또는 요청 시간)

Time to First Byte를 최적화하고 싶으신가요? 이 문서는 Time to First Byte의 연결 시간 부분에 대해 다룹니다. Time to First Byte를 이해하거나 수정하려고 하지만 연결 시간이 무엇을 의미하는지 모르는 경우, 이 문서를 시작하기 전에 Time to First Byte란 무엇인가 및 Time to First Byte 문제 수정 및 식별을 읽어보세요.

Time to First Byte의 연결 시간 부분은 브라우저가 웹 서버에 연결하는 시간으로 구성됩니다. 해당 연결 후 브라우저와 서버는 일반적으로 암호화 계층(TLS)을 추가합니다. 이 두 연결을 협상하는 프로세스에는 약간의 시간이 걸리며, 해당 시간이 Time to First Byte에 추가됩니다.

상세한 연결 과정

전송 제어 프로토콜(TCP)은 클라이언트(브라우저)와 서버 간의 안정적인 연결을 설정하는 역할을 합니다. 이 과정에는 3방향 핸드셰이크가 포함됩니다.

• SYN(Synchronize) 패킷: 클라이언트는 연결을 시작하고 동기화를 요청하기 위해 서버에 SYN 패킷을 보냅니다.
• SYN-ACK(Synchronize-Acknowledge) 패킷: 서버는 SYN-ACK 패킷으로 응답하여 SYN 패킷 수신을 확인하고 연결 설정에 동의합니다.
• ACK(Acknowledge) 패킷: 클라이언트는 ACK 패킷을 서버로 다시 보내 SYN-ACK 패킷 수신을 확인합니다. 이 시점에서 TCP 연결이 설정되어 클라이언트와 서버 간에 데이터를 안정적으로 전송할 수 있습니다.

TCP는 데이터가 올바른 순서로 송수신되도록 보장하고, 손실된 패킷을 다시 보내며, 네트워크 용량에 맞게 흐름 제어를 관리합니다.

TCP 연결이 설정되면 전송 계층 보안(TLS) 프로토콜을 사용하여 연결을 보호합니다. TLS 핸드셰이크에는 서버를 인증하고 보안 통신 채널을 설정하는 여러 단계가 포함됩니다.

• ClientHello: 클라이언트는 지원되는 TLS 버전, 암호 제품군(cipher suites) 및 난수(Client Random)를 나타내는 "ClientHello" 메시지를 서버로 보냅니다.
• ServerHello: 서버는 "ServerHello" 메시지로 응답하여 클라이언트의 목록에서 TLS 버전과 암호 제품군을 선택하고, 디지털 인증서와 난수(Server Random)를 제공합니다.
• 인증서 및 키 교환(Certificate and Key Exchange): 서버는 인증을 위해 디지털 인증서를 클라이언트로 보냅니다. 클라이언트는 신뢰할 수 있는 인증 기관에 대해 인증서를 검증합니다.
• 프리마스터 시크릿(Premaster Secret): 클라이언트는 프리마스터 시크릿을 생성하고 서버의 공개 키(인증서에서 가져옴)로 암호화하여 서버로 보냅니다.
• 세션 키 생성(Session Key Generation): 클라이언트와 서버는 모두 Client Random 및 Server Random과 함께 프리마스터 시크릿을 사용하여 대칭 암호화를 위한 공유 세션 키를 생성합니다.
• 완료 메시지(Finished Messages): 클라이언트와 서버는 세션 키로 암호화된 메시지를 교환하여 핸드셰이크가 성공했는지, 양 당사자가 올바른 세션 키를 가지고 있는지 확인합니다.

TLS 핸드셰이크가 완료되면 클라이언트와 서버는 안전한 암호화 연결을 설정한 것입니다. 이렇게 하면 교환되는 모든 데이터가 제3자의 도청 및 조작으로부터 보호됩니다.

TLS 1.3 대 TLS 1.2: TTFB에 중요한 이유

서버가 사용하는 TLS 버전은 연결 시간에 직접적인 영향을 미칩니다. TLS 1.3은 핸드셰이크를 완료하는 데 필요한 왕복 횟수를 줄이기 때문에 TLS 1.2보다 빠릅니다.

TLS 1.3은 핸드셰이크를 두 번의 왕복에서 한 번으로 줄입니다. 서버에서 100ms 떨어져 있는 사용자(왕복 시간)의 경우, 새 연결마다 약 100ms가 절약됩니다. 재방문자의 경우, TLS 1.3의 0-RTT(0 왕복 시간) 재개를 통해 클라이언트는 이전에 교환된 세션 정보를 재사용하여 다시 연결 시 즉시 암호화된 데이터를 보낼 수 있습니다. 이를 통해 재방문자의 경우 TLS 핸드셰이크 오버헤드를 거의 0으로 줄일 수 있습니다.

HTTP/3 및 QUIC: 빠른 연결의 미래

HTTP/3는 핸드셰이크 과정을 하나로 결합하여 보안 연결 설정에 필요한 왕복 횟수를 줄이고 더 빠른 재연결을 위해 0-RTT 재개를 지원하는 QUIC 프로토콜과 통합하여 TLS 연결 속도를 높입니다. 또한 QUIC의 UDP 사용은 HOL(head-of-line) 차단을 제거하고 혼잡 제어를 개선하여 보다 효율적인 데이터 전송과 더 빠른 페이지 로드를 제공합니다.

HTTP/3는 연결 시간에 직접적인 영향을 미치는 HTTP/2에 비해 몇 가지 개선 사항을 제공합니다.

• 결합된 핸드셰이크: TCP 기반의 HTTP/2의 경우 TCP 핸드셰이크와 TLS 핸드셰이크가 순차적으로 발생합니다(새 연결의 경우 총 3회 왕복). QUIC 기반의 HTTP/3는 전송 및 TLS 핸드셰이크를 단일 왕복으로 결합합니다. 새 연결의 경우 HTTP/2에 비해 전체 왕복 1회를 절약할 수 있습니다.
• 0-RTT 연결 재개: TLS 1.3과 마찬가지로 QUIC는 0-RTT 재개를 지원합니다. 재방문자는 핸드셰이크가 완료될 때까지 기다리지 않고 즉시 데이터 전송을 시작할 수 있습니다. 이는 Wi-Fi와 셀룰러 연결 사이를 자주 전환하는 모바일 사용자에게 특히 효과적입니다.
• HOL(head-of-line) 차단 없음: TCP 기반의 HTTP/2의 경우 패킷 하나가 손실되면 해당 패킷이 재전송될 때까지 해당 연결의 모든 스트림이 차단됩니다. QUIC는 UDP를 사용하고 스트림을 독립적으로 처리하므로 손실된 패킷은 해당 패킷이 속한 특정 스트림에만 영향을 미칩니다. 이로 인해 불안정한 네트워크에서 보다 일관된 연결 성능이 제공됩니다.
• 연결 마이그레이션: QUIC 연결은 소스 IP와 포트가 아닌 연결 ID로 식별됩니다. 즉, 모바일 사용자가 Wi-Fi에서 셀룰러로 이동할 때(그리고 IP 주소가 변경될 때) QUIC 연결은 재설정할 필요 없이 유지됩니다. 이렇게 하면 그렇지 않은 경우 필요했을 전체 TCP + TLS 핸드셰이크를 피할 수 있습니다.

연결 시간이 Time to First Byte에 어떤 영향을 미치나요?

TTFB에 대한 연결 시간 영향을 최소화하는 방법

중요한 원본(Origins)에 대해 사전 연결(Preconnect) 사용

<link rel="preconnect"> 리소스 힌트는 해당 원본의 리소스가 실제로 필요하기 전에 지정된 원본에 대한 연결(DNS + TCP + TLS)을 설정하도록 브라우저에 지시합니다. 이렇게 하면 리소스가 최종적으로 요청될 때 중요한 경로(critical path)에서 연결 시간이 제거됩니다.

<!-- 중요한 타사 원본에 사전 연결 -->
<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">

사전 연결을 신중하게 사용하세요(최대 3~5개 원본). 각 사전 연결은 전체 TCP + TLS 연결을 열어 CPU와 네트워크 리소스를 소비합니다. 모든 페이지 로드에 필요한 원본에만 사전 연결합니다. 가끔만 필요한 원본의 경우 대신 dns-prefetch를 사용하세요(DNS 시간 가이드 참조).

TLS 1.3 및 HTTP/3용 서버 구성

• HTTP/3: TCP 대신 UDP를 통한 QUIC 프로토콜을 가져와 더 빠르고 효율적인 데이터 전송을 가능하게 합니다.
• TLS 1.3: 보안을 강화하고 핸드셰이크 왕복을 줄입니다. 0-RTT 연결 재개에 필요합니다.
• 0-RTT 연결 재개(Connection Resumption): 재방문 클라이언트가 이전에 교환된 정보를 재사용하여 재연결 시 즉시 암호화된 데이터를 보낼 수 있도록 하는 TLS 1.3 기능입니다.
• TCP Fast Open: 초기 SYN 패킷에 데이터를 전송할 수 있도록 하여 TCP 핸드셰이크의 왕복 시간을 줄입니다.
• TLS False Start: TLS 핸드셰이크가 완료되기 전에 데이터를 일찍 보낼 수 있습니다.
• OCSP 스테이플링(Stapling): 클라이언트가 인증 기관에 직접 연락할 필요를 없애 인증서 유효성 검사 속도를 높입니다.

다음은 TLS 1.3 및 OCSP 스테이플링을 활성화하는 예제 Nginx 구성입니다.

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # TLS 1.3 cipher suites
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # Enable OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # Enable session resumption (TLS session tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... rest of your server configuration
}

Apache의 경우 다음으로 TLS 1.3을 활성화합니다.

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

    # Enable OCSP Stapling
    SSLUseStapling On
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    # Enable session resumption
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... rest of your virtual host configuration
</VirtualHost>

Time to First Byte 팁: CDN은 더 짧은 왕복 시간을 제공할 뿐만 아니라 프리미엄 CDN 제공업체가 이러한 설정을 올바르게 구성해 두었기 때문에 CDN을 사용하면 TCP 및 TLS 연결 시간이 즉시 향상되는 경우가 많습니다. 시작하려면 성능을 위해 Cloudflare 구성하기에 대한 가이드를 참조하세요.

JavaScript로 연결 시간 측정

Navigation Timing API를 사용하여 브라우저에서 직접 TTFB의 연결 시간 하위 요소를 측정할 수 있습니다.

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 분석(Time to First Byte breakdown)"을 클릭하여 Time to First Byte의 연결 부분을 시각화합니다.

추가 읽기: 최적화 가이드

관련 가이드:

• 103 초기 힌트(Early Hints): 서버는 기본 응답을 처리하는 동안 리소스 힌트(미리 로드, 사전 연결)를 보낼 수 있으므로 브라우저가 더 일찍 연결 설정을 시작할 수 있습니다.
• 성능을 위해 Cloudflare 구성하기: Cloudflare는 HTTP/3, TLS 1.3 및 OCSP 스테이플링을 자동으로 활성화합니다. 또한 CDN을 사용하면 서버를 사용자에게 더 가깝게 만들어 모든 연결에 대한 왕복 시간을 줄일 수 있습니다.

TTFB 하위 요소: 전체 가이드

연결 시간은 TTFB의 5가지 하위 요소 중 하나입니다. 전체적인 그림을 이해하려면 다른 하위 요소를 탐색해 보세요.

• TTFB 문제 수정 및 식별: 모든 TTFB 최적화를 위한 진단 시작점입니다.
• 대기 시간: 리디렉션, 브라우저 대기열(queuing) 및 HSTS 최적화.
• 캐시 시간: 서비스 워커 성능, 브라우저 캐시 조회 및 bfcache.
• DNS 시간: DNS 제공업체 선택, TTL 구성 및 dns-prefetch.
• 요청 시간: 서버 처리 시간, 데이터베이스 쿼리 및 백엔드 최적화.