HTTP 1.1 Đường ống

Question

Tôi phải triển khai một máy khách HTTP trong Java và theo nhu cầu của tôi, có vẻ như cách hiệu quả nhất để làm điều đó là triển khai đường dẫn HTTP (theo RFC2616).

Ngoài ra, tôi muốn gửi đường ống POST. (Ngoài ra tôi không nói về ghép kênh. Tôi đang nói về pipelining tức là nhiều yêu cầu qua một kết nối trước khi nhận bất kỳ yêu cầu HTTP phản hồi nào)

Tôi không thể tìm thấy thư viện của bên thứ ba nói rõ rằng nó hỗ trợ pipelining. Nhưng tôi có thể sử dụng ví dụ Apache HTTPCore để xây dựng một khách hàng như vậy, hoặc nếu tôi phải tự xây dựng nó.

Vấn đề tôi gặp phải là ý tưởng hay. Tôi đã không tìm thấy bất kỳ tài liệu tham khảo có thẩm quyền rằng HTTP pipelining là một cái gì đó nhiều hơn một mô hình lý thuyết và được thực hiện đúng bởi các máy chủ HTTP. Ngoài ra, tất cả các trình duyệt hỗ trợ pipelining đều có tính năng này tắt theo mặc định.

Vì vậy, tôi nên cố gắng triển khai ứng dụng khách như vậy hoặc tôi sẽ gặp nhiều rắc rối do triển khai của máy chủ (hoặc proxy). Có bất kỳ tài liệu tham khảo nào đưa ra các hướng dẫn về chúng không?

Nếu đó là ý tưởng tồi thì mô hình lập trình thay thế cho hiệu quả là gì? Các kết nối TCP riêng biệt?

Answer 1

Tôi đã thực hiện một khách hàng HTTP pipelined. Khái niệm cơ bản có vẻ dễ dàng nhưng việc xử lý lỗi rất khó.Hiệu suất đạt được là không đáng kể mà chúng tôi đã từ bỏ các khái niệm từ lâu.

Theo ý kiến ​​của tôi, điều đó không có ý nghĩa đối với trường hợp sử dụng thông thường. Nó chỉ có một số lợi ích khi các yêu cầu có kết nối logic. Ví dụ, bạn có một giao dịch 3-yêu cầu và bạn có thể gửi tất cả trong một lô. Nhưng thông thường bạn có thể kết hợp chúng thành một yêu cầu nếu chúng có thể được pipelined.

Tiếp theo là một rào cản tôi có thể ghi nhớ,

1. keepalive TCP của không đảm bảo kết nối liên tục. Nếu bạn có 3 yêu cầu đường ống trong kết nối, máy chủ sẽ ngắt kết nối sau phản hồi đầu tiên. Bạn phải thử lại hai yêu cầu tiếp theo.

2. Khi bạn có nhiều kết nối, cân bằng tải cũng phức tạp. Nếu không có kết nối nhàn rỗi, bạn có thể sử dụng kết nối bận hoặc tạo kết nối mới.

3. Hết giờ cũng khó khăn. Khi một yêu cầu hết thời gian, bạn phải loại bỏ tất cả sau khi yêu cầu bởi vì họ phải quay trở lại theo thứ tự.

Answer 2

POST không nên pipelined

8.1.2.2 Pipelining

Một khách hàng có hỗ trợ kết nối dai dẳng CÓ THỂ "đường ống" yêu cầu của nó (ví dụ, gửi nhiều yêu cầu mà không cần chờ đợi cho mỗi câu trả lời) . Máy chủ PHẢI gửi câu trả lời tới các yêu cầu đó theo cùng thứ tự mà đã nhận được yêu cầu.

Clients mà giả dai dẳng kết nối và đường ống ngay lập tức sau khi thiết lập kết nối NÊN được chuẩn bị để thử lại kết nối của họ nếu lần pipelined đầu tiên thất bại. Nếu khách hàng thực hiện thử lại như vậy, nó PHẢI KHÔNG phải là đường ống trước khi nó biết kết nối là liên tục. Khách hàng PHẢI cũng sẵn sàng gửi lại yêu cầu nếu máy chủ đóng kết nối trước khi gửi tất cả các câu trả lời tương ứng .

Khách hàng KHÔNG yêu cầu đường ống NÊN sử dụng phương pháp phi idempotent hoặc chuỗi phi idempotent các phương pháp (xem phần 9.1.2). Nếu không, chấm dứt sớm kết nối giao thông có thể dẫn đến kết quả không xác định . Một khách hàng có nhu cầu gửi yêu cầu không phải là yêu cầu không có giá trị NÊN chờ đến gửi yêu cầu đó cho đến khi có nhận được trạng thái phản hồi cho yêu cầu trước đó .

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Answer 3

pipelining hầu như không có sự khác biệt đối với máy chủ http; họ thường xử lý yêu cầu trong kết nối serially anyway - đọc yêu cầu, viết phản hồi, sau đó đọc yêu cầu tiếp theo ...

nhưng khách hàng rất có thể sẽ cải thiện thông lượng bằng cách ghép kênh. trang web thường có nhiều máy với nhiều cpus, tại sao bạn muốn tự nguyện giới hạn yêu cầu của mình thành một dòng? ngày nay nó là nhiều hơn về khả năng mở rộng ngang (yêu cầu đồng thời). tất nhiên, tốt nhất là chuẩn bị nó.