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.
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.