Truyền phát qua proxy chuyển tiếp so với đệm toàn bộ phản hồi

Khi một lượt tải xuống có vẻ đang chờ, hãy tách ba sự kiện: tiêu đề phản hồi đến, các byte thân đến, và ứng dụng có thể dùng hoặc hiển thị kết quả. Chỉ một vòng quay tải không thể xác định sự kiện nào đang bị trễ.

Các giai đoạn truyền phát thông thường có thể chồng lấn:

origin produces a chunk → proxy forwards bytes → client consumes them

Proxy có thể ghi nội dung phù hợp vào bộ đệm trong khi chuyển tiếp. Việc đệm không đòi hỏi phải chờ toàn bộ tệp. read_ahead_gap của Squid điều khiển việc truy xuất chạy trước khi phân phối, đây là một kiểu đệm khác.

Áp lực ngược có thể tạm dừng việc đọc phía trên khi một máy khách chậm làm đầy hàng đợi đầu ra. Content-Length cũng cung cấp độ dài mà không cần đệm toàn bộ. Mã hóa HTTP/1.1 chunked cho phép phân phối dần dần, nhưng không thể hứa độ trễ thấp nếu một thành phần trước đó giữ dữ liệu.

Tiếp theo hãy kiểm tra các giai đoạn xử lý. Việc ghi lại hoặc kiểm tra có thể cần một phần hoặc toàn bộ thân. Nén và đóng khung ứng dụng có thể làm chậm đầu ra hữu ích. Ở phía máy khách, phương thức chờ toàn bộ mảng byte trả về muộn hơn, và trình duyệt có thể nhận byte trước khi hiển thị được.

Sau khi CONNECT thành công, một proxy thông thường chuyển tiếp luồng dịch vụ mà không cần biết độ dài cuối cùng của tệp được đường hầm. Hãy theo dõi sự kiện đầu tiên còn thiếu ở trên trước khi thay đổi cài đặt bộ đệm hoặc thời gian chờ. Khi curl là người quan sát, tùy chọn no-buffer của nó thay đổi giai đoạn đầu ra cục bộ.