Một kết nối rảnh có peer chết âm thầm: TCP mặc định mất ~2 giờ 11 phút mới phát hiện. Đặt ba núm keepalive thì xuống đúng IDLE + CNT×INTVL giây — vài giây. Đo thật công thức, kèm một bug 'hai chữ timeout' suýt làm tôi kết luận keepalive không chạy.
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.
Xin bytes=30000- để tải tiếp chỉ lấy 70 KB còn lại thay vì cả 100 KB; xin một khúc giữa chỉ lấy 100 byte. Nhưng khoảng byte của HTTP bao gồm cả hai đầu còn lát cắt Python thì không — trộn lẫn là mỗi tệp thiếu đúng một byte và hỏng âm thầm. Đo thật, kèm cái bẫy off-by-one kinh điển.
Nagle và delayed ACK, mỗi cái đều hợp lý khi đứng riêng, gặp nhau tạo một thế chờ chết: một vòng request/response kẹt đúng ~40ms, lặp đi lặp lại. Đo thật con số (43ms so với 0,04ms — chênh gần 900 lần), và vì sao bug này khét tiếng khó tái hiện.
Bên đóng kết nối trước phải nằm TIME_WAIT đúng 60 giây trên Linux, và tcp_fin_timeout (thứ ai cũng khuyên vặn) KHÔNG chỉnh được nó — vì nó điều khiển một trạng thái khác. Đo thật ai gánh TIME_WAIT, bao lâu, và vì sao nó đặt trần ~470 kết nối/giây tới mỗi đích.
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.