Technical SEO

TCP Handshake Time

Thời gian thiết lập kết nối TCP giữa client và server, ảnh hưởng đến độ trễ ban đầu của yêu cầu HTTP.

4 lượt xem Cập nhật: 27/05/2026

TCP Handshake Time là gì?

TCP Handshake Time (thời gian bắt tay TCP) là tổng thời gian cần để thiết lập một kết nối TCP giữa trình duyệt (client) và máy chủ (server). Quá trình này diễn ra trước khi bất kỳ dữ liệu HTTP nào được gửi đi, và bao gồm ba bước trao đổi gói tin: SYN → SYN-ACK → ACK. Đơn vị đo thường là mili giây (ms), và giá trị điển hình trên mạng ổn định là từ 20–150 ms — tùy khoảng cách địa lý, chất lượng mạng và cấu hình server.

Tại sao quan trọng trong SEO?

Google đã xác nhận từ năm 2010 rằng tốc độ tải trang là yếu tố xếp hạng trên cả desktop và mobile. Trong đó, TCP Handshake Time trực tiếp ảnh hưởng đến Time to First Byte (TTFB) — chỉ số đo thời gian từ lúc trình duyệt gửi yêu cầu đến khi nhận byte đầu tiên từ server. Nếu TTFB cao (>600 ms), Google có thể đánh giá trang là “chậm”, làm giảm khả năng hiển thị trong kết quả tìm kiếm, đặc biệt trên thiết bị di động.

Ngoài ra, handshake chậm làm tăng độ trễ ban đầu của mọi yêu cầu tài nguyên (CSS, JS, hình ảnh), gây nghẽn chuỗi render, làm chậm First Contentful Paint (FCP) và Largest Contentful Paint (LCP) — hai chỉ số Core Web Vitals bắt buộc từ năm 2021.

Cách hoạt động

Khi người dùng nhập URL hoặc nhấp vào liên kết, trình duyệt phải tạo kết nối TCP với server trước khi gửi yêu cầu HTTP GET. Quy trình gồm:

  1. Sent SYN: Trình duyệt gửi gói tin SYN (synchronize) với số thứ tự ngẫu nhiên (ISN) để đề nghị mở kết nối.
  2. Received SYN-ACK: Server phản hồi bằng gói SYN-ACK: xác nhận số thứ tự của client (ACK = ISN + 1), đồng thời gửi số thứ tự riêng (ISNserver) để đồng bộ.
  3. Sent ACK: Client gửi lại ACK (ACK = ISNserver + 1) để hoàn tất thiết lập. Lúc này kết nối ở trạng thái ESTABLISHED và sẵn sàng truyền dữ liệu.

Tổng thời gian từ bước 1 đến bước 3 chính là TCP Handshake Time. Nó không phụ thuộc vào nội dung trang, mà chịu ảnh hưởng bởi độ trễ mạng (RTT – Round-Trip Time), tải server, và cơ chế tối ưu hóa như TCP Fast Open (TFO).

Hướng dẫn thực hiện

Để đo và cải thiện TCP Handshake Time, bạn cần kết hợp công cụ phân tích và cấu hình kỹ thuật:

  1. Đo lường thực tế:
    • Dùng Chrome DevTools > Network tab: chọn một yêu cầu, xem phần Timing → mục Connect (bao gồm DNS + TCP handshake + TLS nếu có).
    • Dùng lệnh curl -w "@curl-format.txt" -o /dev/null -s https://example.com với file curl-format.txt chứa %{time_connect} để xuất thời gian kết nối thuần (không bao gồm DNS).
    • Phân tích qua WebPageTest: báo cáo chi tiết từng giai đoạn, bao gồm TCP Connect dưới tiêu đề Waterfall.
  2. Tối ưu hóa phía client:
    • Kích hoạt HTTP/2 hoặc HTTP/3: giúp tái sử dụng kết nối (connection reuse), giảm số lần handshake cần thiết cho nhiều tài nguyên.
    • Sử dụng preconnect trong thẻ <head>: <link rel="preconnect" href="https://cdn.example.com"> để trình duyệt bắt đầu DNS + TCP + TLS sớm hơn.
  3. Tối ưu hóa phía server:
    • Bật TCP Fast Open (TFO) trên Linux kernel ≥ 3.7 (đã hỗ trợ từ Ubuntu 14.04, CentOS 7+): cho phép gửi dữ liệu cùng gói SYN đầu tiên, cắt giảm 1 RTT. Cấu hình: net.ipv4.tcp_fastopen = 3 trong /etc/sysctl.conf.
    • Giảm độ trễ mạng bằng cách đặt server gần đối tượng người dùng qua CDN (Cloudflare, Cloud CDN, AWS CloudFront).
    • Đảm bảo không có firewall hoặc load balancer nào chặn hoặc làm chậm gói SYN/SYN-ACK (kiểm tra log iptables, tcpdump).

Lỗi thường gặp

Dưới đây là các vấn đề phổ biến khiến TCP Handshake Time tăng bất thường và cách xử lý:

Vấn đề Dấu hiệu Cách khắc phục
Server quá tải hoặc không phản hồi SYN-ACK kịp thời Thời gian Connect > 1000 ms trong DevTools; gói SYN-ACK bị mất hoặc chậm trong tcpdump Tăng net.core.somaxconn, kiểm tra tải CPU/memory, tối ưu ứng dụng nền (PHP-FPM, Node.js event loop)
Tường lửa hoặc DDoS protection chặn SYN Không thấy gói SYN-ACK trong tcpdump; kết nối timeout sau ~3s Kiểm tra quy tắc iptables/nftables; điều chỉnh threshold của Cloudflare Rate Limiting hoặc WAF
Khoảng cách vật lý quá xa giữa client và server RTT cao (>150 ms) dù mạng ổn định; handshake time dao động theo vị trí người dùng Sử dụng CDN với điểm hiện diện (PoP) gần khu vực người dùng; cân nhắc multi-region hosting

Ví dụ thực tế

Một website thương mại điện tử tại Việt Nam có server đặt tại Hà Nội, chưa dùng CDN. Khi kiểm tra từ TP.HCM qua WebPageTest:

  • TCP Handshake Time trung bình: 89 ms
  • TTFB trung bình: 210 ms

Sau khi triển khai Cloudflare với chế độ Optimized và bật TFO trên server:

  • TCP Handshake Time giảm còn 32 ms (do kết nối qua PoP gần nhất ở TP.HCM)
  • TTFB giảm xuống 125 ms
  • LCP cải thiện từ 3.8s → 2.1s; tỷ lệ người dùng thoát (bounce rate) giảm 14% trong 30 ngày.
Lưu ý: Kết quả thay đổi tùy mức độ tối ưu ban đầu, lưu lượng và cấu hình CDN — không phải mọi trường hợp đều đạt được mức giảm tương tự.

Câu hỏi thường gặp

TCP Handshake Time khác gì so với TTFB?

TCP Handshake Time chỉ đo thời gian thiết lập kết nối TCP (3 bước SYN/SYN-ACK/ACK), trong khi TTFB (Time to First Byte) bao gồm cả DNS lookup, TCP handshake, TLS handshake (nếu HTTPS), và thời gian server xử lý yêu cầu để trả byte đầu tiên. TCP handshake là một thành phần con của TTFB.

Có nên tối ưu TCP Handshake Time nếu đang dùng HTTP/2?

Có. Mặc dù HTTP/2 tái sử dụng kết nối, nhưng lần đầu truy cập vẫn cần handshake ban đầu. Với người dùng mới hoặc sau khi kết nối hết hạn (idle timeout), việc giảm handshake time vẫn giúp cải thiện TTFB và trải nghiệm khởi tạo trang. Ngoài ra, các tài nguyên ngoài miền chính (ví dụ: CDN, analytics) vẫn cần handshake riêng.

Tôi không kiểm soát server — có thể làm gì?

Nếu dùng shared hosting hoặc SaaS (Shopify, WordPress.com), bạn không thể bật TCP Fast Open hay điều chỉnh kernel. Lúc này, tập trung vào giải pháp khả thi: dùng CDN hỗ trợ preconnect và HTTP/3, tối ưu DNS (chọn nhà cung cấp DNS nhanh như Cloudflare DNS), và giảm số lượng domain ngoài (third-party domains) để hạn chế handshake mới.