HTTP/3 trên QUIC được cho là bắt tay nhanh hơn và chịu mất gói tốt hơn HTTP/2. Tôi đo ra ngược lại: bắt tay 554ms so với 176ms. Nhưng cái sai không nằm ở giao thức — nó nằm ở việc tôi so một thư viện QUIC thuần Python với ngăn xếp TCP của nhân. Bài học lớn nhất cả sê-ri về việc công cụ đo có thể lừa chính người đo.
Ghim lõi giữ cache nóng, nhanh hơn 32% khi working-set vừa cache (64KB) — nhưng 0% khi vượt cache (4MB) vì lúc đó tải là memory-bound. Và cái đuôi trễ nhọn trong máy ảo là nhiễu tầng ảo hóa, không phải do di trú lõi — chỉ lộ ra khi lặp đủ nhiều. Ghim đúng chỗ thì đáng, ghim vì tin đồn thì vô ích.
write() không đưa dữ liệu xuống đĩa ngay. Tôi ghi 300MB không fsync và nhìn Dirty trong /proc/meminfo: nó ghim nguyên 300MB suốt 30 giây rồi mới về 0. Cửa sổ 30 giây đó — nếu mất điện là bay sạch — chính là lý do phải fsync. Đo thật, kèm một cái bẫy quan sát.
Tưởng write() xong là dữ liệu đã an toàn trên đĩa? Tôi đo: write() chỉ copy vào page cache (RAM) rồi trả về ngay — nhanh 7 lần so với ép lên đĩa bằng fsync, nhưng dữ liệu chưa bền, mất điện trước write-back là mất sạch. 'Đã ghi' và 'đã bền' là hai chuyện khác nhau.
Tưởng gọi một lời gọi hệ thống cũng như gọi một hàm thường? Tôi đo thử: vượt ranh giới user→kernel tốn 103ns so với hàm user 0,74ns (139 lần) — và vDSO không vượt ranh giới chỉ 13ns, chứng tỏ chính cú vượt ranh giới là chi phí, không phải việc nhân làm. Nên giảm chi phí = vượt ít lần hơn.
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.