Một getaddrinfo gửi HAI truy vấn (A và AAAA) và chờ cả hai; nếu AAAA bị một tường lửa im lặng bỏ rơi, lookup treo ~6 giây dù IPv4 đã sẵn ngay từ mili giây đầu. Cộng thêm sự thật ít ai biết: hệ điều hành không hề cache DNS. Đo thật bằng máy chủ DNS tự dựng.
Một bản ghi DNS được đệm đúng bằng TTL giây rồi mới hỏi lại nguồn; đổi bản ghi ở nguồn chỉ có hiệu lực sau khi bản sao đệm hết hạn — trễ đúng một TTL. Và cái con số TTL bạn đọc từ dig không phải TTL gốc mà là TTL còn lại đang đếm ngược. Đo thật từng giây.
Một GET trên kết nối mới tốn 2 vòng khứ hồi (bắt tay + trao đổi), HTTPS lần đầu tới 3; tái dùng kết nối còn 1. Và với thân 40 byte, riêng header response chiếm ~78%. Client tự viết của tôi báo request 72 byte — client kiểu trình duyệt là 524, gấp 7 lần. Đo thật bằng tcpdump.
Tái dùng một kết nối cho 20 request né được 19 lần bắt tay, nhanh gấp đôi trên đường RTT ~55ms (2360ms xuống 1195ms). Nhưng đúng phép đo đó trên localhost chỉ chênh 1ms — vì loopback giấu sạch mọi chi phí tính bằng RTT. Đo thật, và vì sao đừng bao giờ đánh giá keep-alive trên máy mình.
Một lần revalidate với ETag khớp biến response 56 KB thành 152 byte — tiết kiệm hơn 99% băng thông. Nhưng một ETag đổi mỗi lần (bug rất phổ biến) biến mọi 304 thành 200, đốt lại toàn bộ băng thông mà trang vẫn chạy đúng, test vẫn xanh, không lỗi nào báo. Đo thật bằng byte trên dây.
HTTP/2 ghép 20 request thành 20 luồng song song trên MỘT kết nối, xong trong 249ms; HTTP/1.1 sáu kết nối mất 823ms, một kết nối nối đuôi tận 3396ms. Tôi tự tin phô điểm yếu chặn-đầu-hàng-TCP của HTTP/2 dưới mất gói — nhưng phép đo của tôi sai hình dạng nên nó không hiện. Đo thật.