Mạng 03/09/2026 9 phút

Nửa Internet khuyên vặt tcp_fin_timeout để 'chữa' TIME_WAIT — tôi đo ra nó chẳng đụng tới con số đó

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ạng 03/09/2026 9 phút

Đầu kia biến mất im lặng, mặc định TCP mất hơn 2 tiếng mới nhận ra — công thức để xuống vài giây

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ạng 03/09/2026 9 phút

Một lookup lẽ ra 50ms treo thành 6 giây — thủ phạm là truy vấn IPv6 mà getaddrinfo lặng lẽ chờ

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ạng 03/09/2026 9 phút

'Đổi DNS rồi mà chưa ăn' — tôi đo từng giây để thấy chính xác vì sao, và trễ đúng bao lâu

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.