Lonjakan latensi saat proses handshake TLS pada aplikasi modern sering terjadi meskipun edge proxy sudah mengaktifkan HTTP/3 dan TLS 1.3. Masalah ini biasanya muncul pada koneksi pertama (cold start) client browser dan native mobile app. Penyebab utamanya adalah penambahan 1 Round-Trip Time (RTT) akibat ketiadaan record HTTPS DNS (RFC 9460), yang memaksa client melakukan downgrade bootstrap sebelum menegosiasikan protokol optimal.

Gejala: Latensi Tinggi pada Cold Connection

Pada metrik backend gateway dan Real User Monitoring (RUM), terlihat anomali distribusi durasi time_to_first_byte (TTFB) dan tls_handshake_time:

  • Koneksi berulang (warm connection) menunjukkan durasi handshake TLS 1.3/QUIC mendekati 0-RTT atau 1-RTT (sekitar 20–40 ms).
  • Koneksi baru (cold connection) melonjak hingga 2-3 RTT (100–150 ms) sebelum stream data pertama terkirim.
  • Client awalnya selalu menginisiasi TCP Three-Way Handshake + TLS 1.3, menerima header Alt-Svc: h3=":443", baru kemudian beralih ke UDP/QUIC pada request berikutnya.

Root Cause Analysis: Kegagalan Protokol Bootstrap

Browser berbasis Chromium, Safari, dan library HTTP mobile modern mengimplementasikan RFC 9460 (SVCB/HTTPS DNS Resource Record). Mekanisme resolusi standar hanya menanyakan record A dan AAAA. Akibatnya, client tidak mengetahui kapabilitas protokol server sebelum koneksi pertama terjadi.

Tanpa record HTTPS DNS:

  1. Client mengirim DNS query tipe A/AAAA dan HTTPS secara paralel.
  2. DNS resolver mengembalikan respon NODATA untuk tipe query HTTPS.
  3. Client tidak menerima parameter service binding seperti alpn (Application-Layer Protocol Negotiation) dan ipv4hint/ipv6hint.
  4. Client terpaksa memilih fallback aman: inisiasi TCP handshake (1 RTT) dilanjutkan TLS handshake (1 RTT) via HTTP/1.1 atau HTTP/2.
  5. Server merespons request dengan header HTTP Alt-Svc. Client mencatat preferensi HTTP/3 untuk request selanjutnya.

Siklus di atas membuang 1 hingga 2 RTT penuh pada request pertama. Jika record HTTPS tersedia, client langsung mengeksekusi QUIC handshake (0-RTT atau 1-RTT) langsung via UDP tanpa membuka socket TCP terlebih dahulu.

Konfigurasi Record HTTPS DNS (RFC 9460)

Record HTTPS menyediakan prioritas, target domain, supported ALPN, dan IP hints langsung dalam fase resolusi DNS.

1. Format Zone File (BIND 9.18+)

Tambahkan konfigurasi berikut pada zone file authoritative name server:

; Format: <name> <ttl> IN HTTPS <priority> <target_name> <params>
api.example.com.   300 IN HTTPS 1 . (
    alpn="h3,h2"
    ipv4hint=198.51.100.10
    ipv6hint=2001:db8::10
)

Prioritas 1 menandakan mode ServiceMode. Target . mengindikasikan bahwa target domain identik dengan origin domain.

2. Format Raw Hex (Legacy DNS Provider)

Jika DNS provider belum mendukung parsing parameter RFC 9460 secara native, gunakan representasi generic record (TYPE65):

api.example.com.   300 IN TYPE65 \# 24 0001 00 00010006026833026832 00040004c633640a

Verifikasi dan Validasi

Verifikasi Resolusi DNS

Gunakan dig versi 9.18 atau lebih baru untuk memastikan DNS mengembalikan record HTTPS dengan benar:

dig HTTPS api.example.com +short

Output yang valid:

1 . alpn="h3,h2" ipv4hint=198.51.100.10 ipv6hint=2001:db8::10

Validasi Eliminasi Latensi pada Backend Gateway

Periksa access log gateway (seperti Envoy atau NGINX) untuk memastikan request pertama langsung masuk via protokol HTTP/3 tanpa proses bootstrap HTTP/2.

Contoh format log Envoy:

[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %DURATION% "alpn=%DOWNSTREAM_TLS_ALPN%"

Sebelum implementasi record HTTPS:

[2024-04-10T10:00:00.100Z] "GET /v1/health HTTP/2" 200 45 "alpn=h2"
[2024-04-10T10:00:00.350Z] "GET /v1/data HTTP/3" 200 18 "alpn=h3"

Setelah implementasi record HTTPS:

[2024-04-10T10:05:00.050Z] "GET /v1/health HTTP/3" 200 19 "alpn=h3"

Request awal langsung menegosiasikan QUIC, memotong fase TCP handshake dan meniadakan penambahan 1 RTT pada cold connection.