Người gọi có thể hủy bỏ việc thực thi mã được yêu cầu HTTP không?


8

Một bên thứ ba sẽ thực hiện các yêu cầu HTTP đến API mà tôi đang xây dựng, yêu cầu API phản hồi trong chưa đầy một giây. Câu hỏi của tôi là, họ có cách nào (theo nghĩa đen là bất kỳ cách nào, trong giới hạn của giao thức http và / hoặc tcp / ip) để hủy bỏ việc thực thi mã của tôi nếu mất nhiều hơn một giây không?


1
Họ có thể đặt thời gian chờ của HTTPClient trực tiếp, nhưng điều đó không hủy bỏ mã đang chạy ở phía máy chủ.
Jon Raynor

15
Đúng. Định vị địa lý IP và một tên lửa hành trình. Nếu đó không phải là những gì bạn có trong đầu, bạn sẽ phải nói chính xác hơn rất nhiều với "nghĩa đen theo bất kỳ cách nào".
Jörg W Mittag

Có thể có hàng chục lý do có thể "khiến người dùng tin tưởng" rằng quá trình này mất hơn 1 giây. Ví dụ, độ trễ. Bạn biết đấy, ai đó trong văn phòng tải xuống nội dung đáng ngờ ... Vào thời điểm người dùng gửi yêu cầu hủy, quá trình có thể đã kết thúc thành công. 1 giây là ít thời gian (tôi nghĩ) cho một con người.
Laiv

@jmoreno "giới hạn" của bạn có bao gồm tôi thêm nút hủy để người dùng nhấp không? Hay bạn đang tìm kiếm thứ gì đó thấp hơn trong ngăn xếp osi so với lớp ứng dụng?
candied_orange

2
Thật ngạc nhiên khi đây là VTC. Câu trả lời là chắc chắn. Không có gì ngăn bạn đăng ký các yêu cầu theo một cách nào đó và thêm một điểm cuối hoặc phương thức API hủy bỏ chúng - thông qua quản lý quy trình gốc hoặc bằng cách yêu cầu "hủy bỏ" kiểm tra định kỳ nếu chúng được hướng dẫn dừng ...
svidgen

Câu trả lời:


10

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.


Tất nhiên bạn có thể gửi thời gian chờ là thời gian tương đối - điều đó chỉ có nghĩa là máy chủ không thể ngừng xử lý x giây sau khi bạn gửi yêu cầu, nhưng chỉ x giây sau khi máy chủ nhận được yêu cầu. Có thể tốt hơn nếu bạn không thể đảm bảo rằng đồng hồ của bạn và đồng hồ máy chủ là như nhau. Nếu chúng cách nhau hai phút, tất cả các yêu cầu có thời gian chờ một phút (trong thời gian tuyệt đối) có thể bị từ chối.
gnasher729

1

Tôi cho rằng họ có thể đóng kết nối, nhưng tôi không biết điều đó có thực sự khiến mã của bạn bị hủy bỏ hay không - nó sẽ phụ thuộc vào cách viết mã của bạn.

Họ cũng có thể gửi một tin nhắn khác có nghĩa là "bạn mất quá nhiều thời gian vì vậy đừng bận tâm" nhưng trong trường hợp đó, có lẽ bạn đã sẵn sàng để xử lý một tin nhắn CANCEL_REQUEST rõ ràng.


Tôi nghĩ rằng việc ghi vào một cổng đóng sẽ báo hiệu, nhưng tất nhiên bạn có thể bỏ qua hoặc xử lý tín hiệu đó (tôi chỉ biết điều này từ phía khách hàng, nơi vấn đề này sẽ khiến máy khách gặp sự cố nếu bạn không xử lý nó). Ngoài ra, máy khách không thể bắt buộc máy chủ làm bất cứ điều gì. Tất nhiên, máy chủ có thể hủy bỏ công việc của nó một cách tự nguyện nếu cổng bị đóng hoặc hủy bỏ công việc nếu nó không được thực hiện trong thời gian chờ hoặc hủy bỏ công việc nếu máy khách gửi tin nhắn để hủy yêu cầu.
gnasher729
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.