Lý thuyết: Có thể/khả thi để phân phối nội dung tĩnh thông qua Websockets?

Question

Trong thế giới web, trình duyệt web tạo một yêu cầu mới cho mọi tệp tĩnh mà nó phải truy xuất, vì vậy; một tệp định kiểu, tệp javascript, hình ảnh nội tuyến - tất cả đều bắt đầu một yêu cầu máy chủ mới. Mặc dù kiến ​​thức về trang web của tôi khá tốt, nhưng các công nghệ cơ bản như websockets có phần mới đối với tôi về cách chúng hoạt động và những gì chúng có khả năng.

Câu hỏi của tôi khá lý thuyết, nhưng tôi tự hỏi liệu có thể bây giờ hoặc sẽ có thể phục vụ các tệp tĩnh thông qua một websocket? Xem xét các ổ cắm web là một kết nối liên tục từ máy khách (trình duyệt web) đến máy chủ, có nghĩa là các ổ cắm web có thể được sử dụng để phân phối một số nếu không phải tất cả nội dung tĩnh vì nó chỉ là một kết nối trái với nhiều kết nối.

Để làm rõ một chút.

Tôi nhận thấy từ ngữ của mình về các kết nối không chính xác như được chỉ ra bởi Greg bên dưới. Nhưng từ những gì tôi hiểu lý do CDN được tạo và vẫn được sử dụng hôm nay là giải quyết vấn đề với trình duyệt và máy chủ có giới hạn cứng về số lượt tải xuống đồng thời, khi bạn đạt đến giới hạn đó, yêu cầu của bạn sẽ được xếp hàng thời gian tải trang. Tôi biết rằng chúng cũng được tạo ra để cung cấp các yêu cầu ít cookie hơn. Vì vậy, thực sự câu hỏi của tôi nên là: "Có thể sử dụng ổ cắm web thay cho CDN không?"

BrowserScope có một số chỉ số hữu ích, có vẻ như giới hạn yêu cầu là khoảng 6 cho mỗi tên máy chủ cho hầu hết các trình duyệt hiện đại và thậm chí là IE8. Nhưng như tôi đã nói, đôi khi mọi người có hơn 6 tài nguyên, điều này có nghĩa là họ đang xếp hàng đợi và làm chậm thời gian tải trang khi các websockets có khả năng làm giảm thời gian tải xuống này?

Answer 1

Đó chắc chắn là có thể nhưng có một vài lý do tại sao bạn có thể không muốn sử dụng này cho các tài nguyên tĩnh:

• Bạn cần ít nhất một tài nguyên được tĩnh phân phối qua các cơ chế HTTP tiêu chuẩn có nghĩa là bạn cần một cái gì đó có khả năng phục vụ tài nguyên tĩnh anyways. Nói chung, bạn muốn giữ Javascript tách biệt với HTML của bạn, điều đó có nghĩa là một tải tĩnh khác. Hoặc bạn có thể lộn xộn và đặt mã WebSocket được nhúng vào trang chính, nhưng bạn vẫn thực sự tốt hơn hết.
• Bạn không thể mở kết nối WebSocket cho đến khi tập lệnh trên trang bắt đầu chạy. Việc thiết lập kết nối WebSocket thêm một số độ trễ ban đầu.
• Hầu hết các trình duyệt sẽ tải tài nguyên tĩnh không xung đột song song (một số trình duyệt cũ có giới hạn nghiêm trọng về số lượng kết nối song song, nhưng chúng vẫn có song song). Bạn có thể mở nhiều kết nối WebSocket cho các tài nguyên tĩnh khác nhau, nhưng thực hiện điều này một cách đáng tin cậy và hiệu quả sẽ tốn rất nhiều công sức. Các trình duyệt đã giải quyết hầu hết các vấn đề này đối với tài nguyên tĩnh.
• Mỗi kết nối WebSocket là một thông báo dựa trên tin nhắn được bảo đảm. Kết hợp với tính chất tuần tự hóa của việc thực thi Javascript, điều này có nghĩa là bạn có thể xử lý một thông báo WebSocket tại một thời điểm. Bạn có thể sử dụng các Web Worker để có thể xử lý nhiều hơn một kết nối WebSocket song song, nhưng kịch bản lệnh render chính sẽ vẫn được tuần tự hóa trên các kết nối đó.Bạn chắc chắn có thể làm cho hiệu quả này, nhưng một lần nữa, đây không phải là một vấn đề tầm thường và các trình duyệt đã giải quyết được rất nhiều vấn đề tải tài nguyên tĩnh này.
• Nhiều máy chủ web hỗ trợ tài nguyên gziping trước khi phân phối chúng. WebSocket chưa có hỗ trợ nén (nó đang được thảo luận như một phần mở rộng trong nhóm làm việc). Điều này có nghĩa là nếu bạn muốn nén tài nguyên của mình qua WebSocket, bạn sẽ phải làm điều này trong Javascript, điều này sẽ làm tăng thêm độ trễ.

Nếu bạn có các bộ phận của trang của bạn được tự động cập nhật sử dụng các tài nguyên tĩnh (ví dụ như tải trong hình ảnh mới vào một canvas trò chơi HTML5), sau đó WebSockets có thể lựa chọn tốt nhất của bạn bởi vì một kết nối WebSocket đã được thành lập sẽ có độ trễ thấp và chi phí cho việc đẩy các bản cập nhật từ máy chủ, sau đó nhận các bản cập nhật này qua HTTP. Nhưng tôi sẽ không khuyên bạn nên sử dụng WebSockets cho các tài nguyên tĩnh ban đầu khi bạn tải trang đầu tiên.

Answer 2

Câu trả lời này không thực sự giải quyết cổng web câu hỏi của bạn, nhưng nó có thể làm cho nó trở nên lỗi thời:

Công nghệ thế hệ tiếp theo đó là nghĩa vụ để giải quyết vấn đề chuyển giao nhiều tài sản qua kết nối duy nhất là SPDY, đó là hiện là ứng cử viên cho HTTP 2.0. Nó có triển khai làm việc trong Chrome và Firefox và đã có một số hỗ trợ phía máy chủ thử nghiệm bởi những người như Google và Twitter.