ReverseHTTP là gì và tại sao nó lại hữu ích?

Question

reversehttp.net cung cấp cái nhìn sâu sắc ngay lập tức về những gì reversehttp thực sự là và làm thế nào điều này có thể được sử dụng tốt nhất, nó làm cho nó có vẻ rằng công cụ này là quá khó để thực hiện thực tế. Trong những loại môi trường nào, đây có thể là tình hình dữ liệu web thời gian thực lý tưởng và khi nào điều này không hoạt động, Trình duyệt nào hỗ trợ phương thức này và Chính xác là gì?

• Điều gì làm đảo ngược duy nhất từ ​​các triển khai PUSH khác?

Cảm ơn mọi người có thể giúp đỡ và trước hết đã nghe nói về điều này và biết nó là gì.

Answer 1

HTTP ngược là cách để khách hàng giữ kết nối mở với máy chủ web sao cho máy chủ web có thể đẩy cập nhật cho máy khách (thay vì máy khách liên tục phải yêu cầu cập nhật).

Lấy ứng dụng khách Twitter cổ điển của bạn chẳng hạn.

Hiện tại, khách hàng hỏi Twitter định kỳ nếu bạn có bất kỳ cập nhật nào. Nếu không, đó là một yêu cầu lãng phí.

Với công nghệ như Reverse HTTP, khi bạn thiết lập kết nối với Twitter ... Twitter sẽ có thể gửi cho bạn thông tin cập nhật khi chúng xảy ra tiết kiệm cả băng thông, chi phí và một chút nỗ lực.

HTTP ngược hoạt động bằng cách chạy Máy chủ web bên trong trình duyệt mà máy chủ liên lạc.

Có những công nghệ tương tự hoàn thành cùng một mục tiêu theo cách an toàn hơn, an toàn hơn. Microsoft.NET triển khai các loại dịch vụ này dưới dạng dịch vụ Binding Duplex trong WCF bằng cách giữ kết nối giữa máy khách và máy chủ mở khi nó được tạo (thay vì chạy một máy chủ riêng biệt trên máy khách). Ngoài ra còn có một công nghệ được gọi là Comet cho phép điều tương tự.

Answer 2

Chỉ cần truy cập trang: đọc của tôi là thay vì, nói, một điểm bỏ phiếu trình duyệt web để cập nhật và kéo bất kỳ dữ liệu mới, máy chủ web thay vì đẩy dữ liệu mới trên máy khách khi nó trở nên có sẵn.

Đối với các ứng dụng yêu cầu phản hồi nhanh đối với bất kỳ dữ liệu mới nào, điều này sẽ loại bỏ rất nhiều lưu lượng truy cập gây ra bởi việc bỏ phiếu lặp lại.

Answer 3

Từ khi xem một số bản trình diễn (ví dụ: this one) có vẻ như nó được xây dựng ở trên cùng của giao diện kiểu sao chổi chuẩn. Việc thực hiện chỉ trình bày chính nó như là một máy chủ HTTP hoàn chỉnh cho khách hàng. Vì vậy, trong javascript của bạn, có vẻ như "bạn đang lưu trữ một máy chủ web đáp ứng yêu cầu" http://reversehttp.net/demo12345/ "nhưng trên thực tế, các yêu cầu đang được tunnel từ máy chủ web" thực "qua các yêu cầu sao chổi tới javascript khách hàng đang chạy trong trình duyệt và ngược lại. Khi được mô tả như vậy, có vẻ như không hiệu quả, nhưng khi bạn xem xét trong hầu hết các trường hợp, máy khách và máy chủ sẽ chạy trên cùng một máy tính (vì vậy nó chỉ có hai máy tính nói chuyện với nhau). hầu như biến mất.

Answer 4

Tôi đã xem xét nguồn của HTTP ngược mà bạn đã liên kết đến.Việc triển khai bao gồm hai phần:

1. Chuyển tiếp HTTP. Cái này được lưu trữ trên trang web reversehttp.net. Nó chỉ đơn giản chờ các yêu cầu tới một URL nào đó (URL được tạo ra) và chuyển tiếp nó tới một kênh (xem 2). Sau đó nó chờ trên một kênh khác (xem 2) và chuyển tiếp đến người yêu cầu.

2. Máy chủ JavaScript HTTP. "Máy chủ khách" thăm dò "máy chủ máy chủ" cho bất kỳ yêu cầu gửi đến nào bằng cách sử dụng Ajax. Sau đó, khi bạn đã yêu cầu url trên "máy chủ máy chủ" và nó được chuyển tiếp đến một kênh, nó sẽ được gửi đến "máy chủ khách". Sau đó, máy chủ khách sẽ phân tích cú pháp yêu cầu HTTP ban đầu từ yêu cầu ở bước 1, tạo câu trả lời (câu trả lời HTTP). Câu trả lời này sẽ được gửi lại cho "máy chủ máy chủ", kết thúc trong kênh gửi trả lời thực sự cho người yêu cầu.

Hoàn toàn không lưu trữ máy chủ HTTP thực trên máy khách. Điều này đòi hỏi một cổng mở 80, mà hầu hết mọi người không có. Nếu bạn đang đứng sau NAT hoặc Tường lửa, nó sẽ bị chặn theo bất kỳ cách nào, nếu được định cấu hình tốt.

Tôi đoán sử dụng bỏ phiếu dài hoặc Comet là ý tưởng tốt hơn so với sử dụng tính năng này. Chi phí phân tích tiêu đề HTTP trên máy khách khá cồng kềnh.

Đặc điểm kỹ thuật mô tả cách chuyển tiếp các yêu cầu HTTP. Điều này sẽ được thực hiện bằng cách đặt tiêu đề Content-Type của bất kỳ yêu cầu nào đến "máy chủ máy chủ" thành message/http. Tôi nghĩ rằng có những giải pháp tốt hơn cho proxy hoặc chuyển tiếp yêu cầu HTTP anyway, chỉ đơn giản bằng cách thay đổi trường Host của chuyển tiếp sang, thêm trường đặc biệt có chứa một số tham chiếu đến người gửi ban đầu và đường dẫn đi qua và gửi đã sửa đổi yêu cầu HTTP đến máy chủ tiếp theo. Sau đó, người nhận sẽ gửi yêu cầu trở lại đơn giản và người nhận tìm kiếm trường đặc biệt, xuất hiện nguồn gốc của nó và chuyển tiếp câu trả lời thêm trong chuỗi.