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.
NAT Linux không tung cho bạn cổng ngẫu nhiên: nó GIỮ cổng nguồn 40000 → 40000, dùng cùng một cổng ngoài cho mọi đích, chỉ đổi khi hai máy nội bộ xung đột (→ 42478). Kiểu ánh xạ 'độc lập điểm cuối' này chính là thứ cho gọi video P2P xuyên NAT được. Đo thẳng bằng conntrack.
Bốn chặng gọi tuần tự tốn 261ms; song song hoá còn 63ms. Nhưng một chặng chậm +100ms đẩy tổng song song lên 172ms — bằng chặng chậm nhất, không phải tổng. Và lần đầu đo, mỗi chặng cõng thêm 40ms lạ mà thủ phạm là chính cái máy chủ tôi tự dựng kẹt Nagle. Bài cuối của sê-ri. Đo thật.
Round-robin chia đều tăm tắp theo lượt, kể cả nhét 20 request cho backend chậm nhất. Least-connections thì chỉ đưa nó 2 request, dồn phần còn lại cho hai máy rảnh. 'Đều' không phải 'cân bằng' — và cái khác biệt đó quyết định 1/N người dùng của bạn có phải chờ máy ốm hay không. Đo thật bằng nginx.
Một khung WebSocket gửi 'hi' chỉ tốn 8 byte trên dây. Nhưng giữ 3000 kết nối mở ngốn 45,8 KB mỗi cái trên máy chủ Python — trong khi 3000 socket TCP trần chỉ 0,1 KB. Tôi định đổ tội cho bộ đệm nhân, rồi một phép đo đối chứng lật ngược: cái đắt là runtime, không phải kết nối. Đo thật.
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.