2011-11-06 37 views
7

Tôi đang viết một máy chủ proxy HTTP và tôi nhận thấy rằng nhiều khách hàng sử dụng tiêu đề "Connection: Keep-Alive" để giữ kết nối liên tục. Có thể máy khách gửi một yêu cầu HTTP khác trước khi máy chủ xử lý yêu cầu đầu tiên không?Máy khách HTTP liên tục có thể gửi nhiều yêu cầu cùng một lúc không?

Ví dụ, máy khách gửi "GET/HTTP/1.1" nhưng trước khi máy chủ có cơ hội trả lời, máy khách gửi "GET/favicon.ico HTTP/1.1". Điều đó có thể không? Hoặc khách hàng có tạm dừng phản hồi trước khi gửi yêu cầu thứ hai không?

Ngoài ra, khi sử dụng kết nối liên tục, có an toàn khi giả định tất cả các yêu cầu thông qua kết nối đó sẽ có cùng tiêu đề "Máy chủ:" không?

+2

[HTTP pipelining] (http://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_proxies), đó là khác biệt so với các kết nối đơn giản là dai dẳng – Flexo

Trả lời

4

Có, khách hàng có thể yêu cầu đường ống. (Xem http://en.wikipedia.org/wiki/HTTP_pipelining).

Chuyển câu hỏi cuối cùng của bạn xung quanh ... sẽ không an toàn để khách hàng cho rằng yêu cầu đối với nhiều máy chủ sẽ được phân phát bằng một đường ống đơn. Có thể không có thông số kỹ thuật nào giải quyết trực tiếp câu hỏi của bạn trên tiêu đề Host: nhưng đó là đặt cược an toàn sẽ giống nhau.

+0

Tôi không hiểu tại sao "nó sẽ không được an toàn cho một khách hàng giả định rằng các yêu cầu tới nhiều máy chủ sẽ được phân phối bởi một đường ống đơn ". Đó là sự lựa chọn của khách hàng để sử dụng một đường ống duy nhất! –

+0

Cảm ơn, tôi không biết về thuật ngữ "HTTP pipelining". Tôi viết máy chủ, không phải máy khách, vì vậy tôi muốn xử lý bất kỳ quark lạ nào mà khách hàng sẽ ném vào tôi. Vì vậy, tôi là bạn nói rằng tôi nên cố gắng để xử lý các trường hợp mà một kết nối liên tục sẽ cố gắng kết nối với một máy chủ khác nhau? – Yifan

+0

Có, tôi nói rằng, ngay cả khi tôi đoán rất ít hoặc không có trình duyệt nào hoạt động như hôm nay. –

1

Về câu hỏi thứ nhất:

Có thể rằng các khách hàng sẽ gửi một yêu cầu HTTP trước khi máy chủ xử lý đầu tiên?

Tôi tin rằng có, nó có thể được (có lẽ tôi sai, tôi nhớ đã đọc rằng một vài năm trước; câu trả lời dứt khoát là trong thông số giao thức HTTP). Nhưng tôi không hiểu tại sao bạn lại hỏi. Ngoài ra, khách hàng có thể mở một số kết nối TCP cùng một lúc với cùng một máy chủ HTTP. Và tất nhiên bạn có nhiều khách hàng đồng thời.

Về câu hỏi thứ hai

Ngoài ra, khi sử dụng một kết nối liên tục, nó là an toàn để giả định tất cả các yêu cầu thông qua kết nối đó sẽ có cùng một "Máy chủ:" tiêu đề?

Tôi tin rằng đó thường là trường hợp, nhưng tôi sẽ không cho rằng chắc chắn. Tôi có thể tưởng tượng rằng một số máy khách HTTP thông minh, nhận ra rằng hai URL với Máy chủ khác nhau: tiêu đề chia sẻ cùng một IP, có thể tái sử dụng cùng một kết nối.

Nhưng tôi không hiểu tại sao bạn lại hỏi. Các kết nối HTTP liên tục đã được phát minh để giảm thiểu các kết nối TCP tốn kém, và hai câu hỏi mà bạn đang hỏi là một điểm cực đoan về điều đó. Có lẽ một số khách hàng HTTP đang làm những gì bạn mô tả hôm nay.

Và bạn phải nghiêm ngặt về những gì bạn gửi (tuân thủ tiêu chuẩn), nhưng linh hoạt đối với những gì bạn chấp nhận.

+0

Tôi hỏi vì tôi đang cố gắng viết một máy chủ proxy HTTP chung và tôi muốn xử lý mọi thứ mà một khách hàng ném vào tôi. – Yifan

+0

Nhưng tôi không thấy tại sao điều đó lại quan trọng với bạn. Một proxy HTTP mạnh mẽ sẽ giả sử là có cho Q1 và không đến Q2. –

5

"Ngoài ra, khi sử dụng kết nối liên tục, có an toàn khi giả định tất cả các yêu cầu thông qua kết nối đó sẽ có cùng tiêu đề" Máy chủ: "không?"

Tôi không nghĩ vậy, hãy xem HTTPbis P1, Section 2.2:

Người nhận phải xem xét tất cả các tin nhắn trong một kết nối trong sự cô lập; vì HTTP là giao thức không trạng thái, không thể giả định rằng hai yêu cầu trên cùng một kết nối đến từ cùng một ứng dụng hoặc chia sẻ bất kỳ thuộc tính phổ biến nào khác.Đặc biệt, các trung gian có thể trộn các yêu cầu từ các máy khách khác nhau vào một kết nối máy chủ duy nhất. Lưu ý rằng một số tiện ích mở rộng HTTP hiện có (ví dụ: [RFC4559]) vi phạm yêu cầu này, do đó có khả năng gây ra sự cố tương tác và các vấn đề về bảo mật.

Các vấn đề liên quan