HTTP không hoạt động như thế. Máy khách gửi yêu cầu, sau đó máy chủ sẽ gửi phản hồi lại. Không có giao tiếp khác xảy ra. Vâng, máy chủ có thể gửi phản hồi thông tin 1xx trước phản hồi chính. Nhưng không có cách nào để khách hàng gửi thông tin cập nhật về một yêu cầu đã gửi.
(Tình huống rất khác nhau đối với HTTP / 2 có thể ghép nhiều yêu cầu trên cùng một kết nối. Một khách hàng có thể hủy một luồng để chỉ ra rằng nó không còn cần thiết sau khi nhận được PUSH_PROMISE từ máy chủ. Tôi sẽ bỏ qua HTTP / 2 cho phần còn lại của câu trả lời này.)
Ngoài ra, các mạng không hoạt động như vậy. Cụ thể, hãy xem sai lầm thứ hai của điện toán phân tán : độ trễ là 0 không. Không phải vậy. Trong khoảng thời gian chờ thứ hai đó, 400ms có thể đã được sử dụng để thiết lập kết nối và gửi yêu cầu và 600ms cho phản hồi, vì một trong các gói đã bị hủy và bạn phải gửi lại mọi thứ và khách hàng của bạn đang ở Úc. Ngoài vấn đề là máy chủ có thể không có đủ thời gian, máy chủ thậm chí còn không biết họ có bao nhiêu thời gian vì độ trễ phản hồi không thể biết trước.
Vì vậy, theo nghĩa đen là thực hiện những thời gian chờ này là không thể, loại giải pháp nào có thể đủ tốt?
Nếu phản hồi sẽ không có giá trị sau khi hết thời gian, máy khách có thể chỉ cần đóng kết nối. Điều này sẽ khiến phản hồi của bạn bị bỏ qua, nhưng sẽ không ngăn chặn phản hồi.
Đóng kết nối TCP mà yêu cầu HTTP được gửi sẽ thông báo cho máy chủ. Nhưng thông báo này chỉ đến với độ trễ, vì vậy có thể quá muộn. Ngoài ra, khung web của bạn có thể không làm gì khi ổ cắm máy khách bị đóng. Trong trường hợp đó, bạn sẽ chỉ nhận được một lỗi thiết lập lại kết nối bởi mạng ngang hàng một khi bạn cố gắng ghi vào ổ cắm đã đóng.
Nếu bạn không muốn dành hơn một giây để xử lý phản hồi, việc thực hiện thời gian chờ đó hoàn toàn là trách nhiệm của bạn và không liên quan gì đến kết nối mạng hoặc HTTP.
Bạn có thể yêu cầu khách hàng cung cấp thời gian chờ cho máy chủ để máy chủ có thể hủy bỏ nếu không thể đáp ứng thời hạn. Điều này có thể được chỉ định làm tiêu đề tùy chỉnh hoặc làm tham số truy vấn trong URL. Thời hạn này phải là một điểm tuyệt đối về thời gian và không phải là thời lượng để sự chậm trễ truyền cũng tiêu tốn thời gian có sẵn. Nhưng độ chính xác của giây phụ rất khó: máy chủ và máy khách cần được đồng bộ hóa với thời gian chính xác và cần sử dụng đồng hồ phù hợp. Tùy thuộc vào thiết lập, mỗi lần nguồn có thể tắt 100ms ngay cả khi được định cấu hình chính xác. Điều này đã ăn một phần đáng kể của ngân sách thời gian của bạn.