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.
Với khách mới, push né được một vòng khứ hồi (185 xuống 120ms) — đẹp. Nhưng với khách quay lại đã cache CSS, nó gửi lại nguyên 33 KB thừa để đổi vài mili giây, trong khi đường tuần tự chỉ tốn 72 byte nhờ 304. Vì đa số lưu lượng là khách quay lại, một ý tưởng đẹp lại thua trên thực tế. Đo thật.
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.
Mỗi cookie bạn đặt được đính vào MỌI request tới miền — kể cả ảnh và CSS không dùng nó. Một kho cookie 147 byte khiêm tốn nhân với 30 request thành ~4,4 KB tải lên mỗi lần xem trang, và một ngày đẹp trời cookie phình quá trần header có thể làm chết cả trang với đúng một người dùng. Đo thật.
Mỗi 301/302 thêm một vòng khứ hồi (~60ms) khi tái dùng kết nối, nhưng tới hai vòng nếu đổi host. 301 được cache nên lần sau miễn phí, 302 thì trả mỗi lần. Và một cái bẫy ít ai để ý: 301/302 có thể biến POST thành GET, làm mất sạch dữ liệu — 307/308 mới giữ. Đo thật.
Ai cũng sợ 'thêm một lớp proxy là thêm độ trễ'. Đo thật: proxy cùng máy backend thêm ~0ms, nhưng khác máy thì cộng đúng một vòng khứ hồi (~29ms). Không có 'phí proxy cố định' — cái giá bằng đúng khoảng cách bạn đặt nó tới backend. Đo bằng nginx.