Tại sao bỏ phiếu được chấp nhận trong lập trình web?

108

Tôi hiện đang làm việc trong một dự án Ruby on Rails hiển thị danh sách các hình ảnh.

Một điều bắt buộc đối với dự án này là nó hiển thị các bài đăng mới trong thời gian thực mà không cần phải làm mới trang web. Sau khi tìm kiếm một lúc, tôi tình cờ thấy một số giải pháp và dịch vụ JavaScript như PubNub; tuy nhiên, không có giải pháp nào được cung cấp có ý nghĩa cả.

Trong giải pháp JavaScript ( bỏ phiếu ), điều sau đây xảy ra:

Người dùng 1 xem danh sách ảnh.
Trong nền, mã JavaScript đang bỏ phiếu một điểm cuối mỗi giây để xem có bài đăng mới nào không.
Người dùng 2 thêm một ảnh mới.
Có độ trễ 50 ms trước khi chu kỳ mới được kích hoạt và tìm nạp dữ liệu mới.
Nội dung mới được tải trong DOM .

Điều này có vẻ kỳ lạ khi được dịch sang một ví dụ thực tế:

Người dùng 1 giữ một đống hình ảnh trên bàn của anh ấy / cô ấy.
Anh ấy / cô ấy đi đến nhiếp ảnh gia mỗi giây và hỏi nếu anh ấy có một cái mới.
Nhiếp ảnh gia thực hiện một bức ảnh mới.
Lần thứ hai này khi anh ấy / cô ấy bước vào, cô ấy có thể chụp ảnh và đặt nó lên đống.

Theo tôi, giải pháp nên như sau:

Người dùng 1 giữ một đống hình ảnh trên bàn của anh ấy / cô ấy.
Nhiếp ảnh gia chụp một bức ảnh mới.
Các nhiếp ảnh gia đi đến đống và đặt nó với phần còn lại.

Giải pháp PubNub về cơ bản là giống nhau, tuy nhiên lần này có một thực tập sinh giữa các bên để chia sẻ dữ liệu.

Không cần phải nói, cả hai giải pháp đều rất tiêu tốn năng lượng vì chúng được kích hoạt ngay cả khi không có dữ liệu để tải.

Theo như kiến thức của tôi, không có lời giải thích (logic) tại sao cách thực hiện này được sử dụng trong hầu hết mọi ứng dụng thời gian thực.

loops logic polling

— dennis
nguồn

195

Bỏ qua một lúc rằng các trình duyệt web không phải là máy chủ có thể nhận kết nối đến ... chờ đã, không, đừng bỏ qua điều đó.

— GrandmasterB

17

@dennis: một kết nối liên tục, liên tục giữa máy chủ và máy khách có thể sẽ thoát khỏi nhu cầu bỏ phiếu, nhưng đó không phải là cách Web được thiết kế.

— Thất

58

Làm thế nào về Websockets?

— I.devries

25

Hoặc hãy xem bỏ phiếu dài. Về cơ bản bạn thăm dò ý kiến, nhưng máy chủ không phản hồi trước khi nó có bất kỳ dữ liệu mới nào để hiển thị cho bạn.

— Matsemann

53

Có rất nhiều giải pháp và thuật toán hoàn toàn hợp lý trong không gian máy tính sẽ hoàn toàn vô lý để thực hiện trong không gian.

— tên gì là

179

Đẩy hoạt động tốt cho 1, hoặc một số lượng người dùng hạn chế.

Bây giờ thay đổi kịch bản với một nhiếp ảnh gia và 1000 người dùng mà tất cả đều muốn có một bản sao của bức ảnh. Các nhiếp ảnh gia sẽ phải đi bộ đến 1000 cọc. Một số người trong số họ có thể ở trong văn phòng bị khóa, hoặc trải khắp sàn nhà. Hoặc người dùng của họ đang đi nghỉ, và không quan tâm đến hình ảnh mới tại thời điểm này.

Các nhiếp ảnh gia sẽ bận rộn đi bộ mọi lúc và không chụp ảnh mới.

Về cơ bản: một mô hình kéo / thăm dò tỷ lệ tốt hơn với nhiều độc giả không đáng tin cậy với các yêu cầu thời gian thực lỏng lẻo (nếu một bức ảnh mất 10 giây sau để đến một đống, thì đó là vấn đề lớn).

Điều đó nói rằng, một mô hình đẩy vẫn tốt hơn trong nhiều tình huống. Nếu bạn cần độ trễ thấp (bạn cần ảnh 5s mới sau khi chụp) hoặc cập nhật rất hiếm và yêu cầu thường xuyên và có thể dự đoán được (cứ hỏi người chụp cứ sau 10 giây khi anh ta tạo ảnh mới mỗi ngày), thì việc kéo là không phù hợp. Nó phụ thuộc vào những gì bạn đang cố gắng làm. NASDAQ: đẩy. Dịch vụ thời tiết: kéo. Nhiếp ảnh gia đám cưới: có thể kéo. Tin tức cơ quan ảnh: có thể đẩy.

— ptyx
nguồn

32

Tôi thực sự thích sự tương tự của bạn với 1000 người dùng, một số vào kỳ nghỉ, một số không quan tâm. +1.

— riwalk

4

@EsbenSkovPedersen: Giới hạn ổ cắm không phải do địa chỉ IP. Đó là do mô tả tập tin mở tối đa. Vì vậy, số lượng ổ cắm mở tối đa không phụ thuộc vào số lượng địa chỉ IP bạn sử dụng.

— slebetman

10

Đây là một sự tương tự khủng khiếp để đặt nó nhẹ nhàng. Để việc đẩy hoạt động, bất kỳ ứng dụng khách nào của người dùng cũng phải duy trì kết nối mở. Trong thực tế, bỏ phiếu là một mô phỏng của một kết nối. Nó không giống như bởi vì một số khách hàng đang bỏ phiếu, rằng tất cả các khách hàng được thông báo. Tương tự, khi một số khách hàng mở kết nối cho thông báo đẩy, không phải tất cả khách hàng đều được thông báo. Đây là lời khuyên rất tồi mà mời gọi ném tài nguyên ra khỏi cửa sổ. Bị bắn phá với 10000 yêu cầu mỗi giây hầu như không bao giờ rẻ hơn hoặc tốt hơn là duy trì 10000 ổ cắm mở.

— back2dos

8

@ptyx: Khoảng 1s là khoảng thời gian được thảo luận ở đây. 10k yêu cầu mỗi giây có nghĩa là 10k bắt tay TCP và 10k yêu cầu HTTP (mỗi yêu cầu dễ dàng đạt 2KB), cung cấp cho bạn nhiều đơn đặt hàng tiếng ồn nền lớn hơn đập vào máy chủ của bạn. Có một loạt các thư viện được thử nghiệm chiến đấu giúp đăng ký đẩy dễ dàng như đặt bỏ phiếu tại chỗ. Thậm chí có những khung như metseng.js hoàn toàn trừu tượng hóa toàn bộ vấn đề. Kháng cáo về khả năng mở rộng mà không có bất kỳ lời giải thích nào thêm cũng khó có thể tranh luận. Dù sao, tôi đã nói lên sự nghi ngờ của mình và không muốn bắt đầu một cuộc thảo luận;)

— back2dos

5

Tôi đồng ý với nhận xét của back2dos ở trên. Nếu kéo tỷ lệ tốt hơn đẩy, google, trao đổi ngăn xếp, facebook, dịch vụ chứng khoán trực tuyến, vv sẽ sử dụng công nghệ kéo. Nhưng họ không. Về cơ bản, đập máy chủ thay vì thiết lập một trạm nghe quy mô khủng khiếp. Các dịch vụ chính tránh bỏ phiếu.

— Travis J

106

Tôi thực sự ngạc nhiên khi chỉ có một người nhắc đến WebSockets . Hỗ trợ được thực hiện trong cơ bản mọi trình duyệt chính .

Trong thực tế PubNub sử dụng chúng. Đối với ứng dụng của bạn, trình duyệt có thể sẽ đăng ký vào một ổ cắm sẽ phát bất cứ khi nào có ảnh mới. Ổ cắm sẽ không gửi ảnh, làm phiền bạn, nhưng chỉ là một liên kết để trình duyệt có thể tải xuống không đồng bộ.

Trong ví dụ của bạn hãy tưởng tượng một cái gì đó như:

Người dùng cho phép nhiếp ảnh gia biết rằng anh ta muốn biết về tất cả các bức ảnh trong tương lai
Nhiếp ảnh gia nói qua loa rằng có một bức ảnh mới
Người dùng yêu cầu nhiếp ảnh gia cho ảnh

Điều này hơi giống như giải pháp ví dụ ban đầu của bạn. Nó hiệu quả hơn so với bỏ phiếu vì khách hàng không phải gửi bất kỳ dữ liệu nào đến máy chủ (ngoại trừ nhịp tim .)

Ngoài ra, như những người khác đã đề cập, có những phương pháp khác tốt hơn so với bỏ phiếu đơn giản hoạt động trong các trình duyệt cũ hơn ( longpolling, et al .)

— korylprince
nguồn

43

@RobertHarvey tại sao WebSockets không liên quan đến câu hỏi? Câu hỏi đặt ra là bỏ phiếu có phải là một chiến lược có thể chấp nhận hay không, và ngày nay rõ ràng nó không được chấp nhận (hoặc ít nhất là không tối ưu). WebSockets, các sự kiện do máy chủ gửi và bỏ phiếu dài thực hiện tốt hơn nhiều trên hầu hết mọi trường hợp sử dụng.

— Fabrício Matté

7

@RobertHarvey đó chỉ là sự giải thích của tôi, không có sự chỉnh sửa nào xa như tôi có thể thấy. Chắc chắn, câu hỏi hỏi tại sao nó vẫn được chấp nhận và không phải là chiến lược tối ưu , nhưng đây vẫn là những imho liên quan chặt chẽ.

— Fabrício Matté

25

WebSockets (và tương tự) là cách gần nhất bạn có thể thực hiện "giải pháp" của OP, vì vậy tôi nghĩ rằng nó rất phù hợp mặc dù anh ấy không đề cập cụ thể.

— korylprince

6

Chưa kể, StackExchangecác trang web như trang bạn đang truy cập ngay bây giờ (trừ khi bạn đang xem trang web này được lưu / lưu trong bộ nhớ cache) sử dụng WebSockets. Đây là lý do tại sao tôi cũng tự hỏi tại sao không có ai cho đến khi @korylprince đề cập WebSockets.

— phân chia

6

@ FabrícioMatté: thực tế, không phải mọi trường hợp sử dụng. Bỏ phiếu dài đòi hỏi phải giữ một ổ cắm mở cho mọi người dùng chiếm tài nguyên hệ thống. Các dịch vụ Fr không quá quan trọng về thời gian nhưng có rất nhiều người dùng, việc mở một ổ cắm thường đắt hơn so với việc phục vụ 304 ngắn mỗi giờ. Đối với hầu hết các dịch vụ, một chút chậm trễ không phải là vấn đề. Một máy duy nhất thường có thể phục vụ nhiều khách hàng bỏ phiếu hơn là đẩy.

— Lie Ryan

42

Đôi khi đủ tốt là đủ tốt.

Trong tất cả các cách có thể để thực hiện quy trình truyền thông "thời gian thực", bỏ phiếu có lẽ là cách đơn giản nhất. Bỏ phiếu có thể được sử dụng hiệu quả khi khoảng thời gian bỏ phiếu tương đối dài (ví dụ giây, phút hoặc giờ thay vì tức thời) và chu kỳ đồng hồ tiêu thụ bằng cách kiểm tra kết nối hoặc tài nguyên không thực sự quan trọng.

— Robert Harvey
nguồn

3

Cái này, một ngàn lần này. Nó được chấp nhận vì nó thường đủ tốt.

— corsiKa

1

Đó là một câu trả lời đủ tốt

— Zain R

31

Giao thức HTTP bị hạn chế ở chỗ máy khách PHẢI là người bắt đầu yêu cầu. Máy chủ không thể liên lạc với khách hàng trừ khi đáp ứng yêu cầu của khách hàng.

Vì vậy, để điều chỉnh ví dụ trong thế giới thực của bạn, hãy thêm các hạn chế sau:

Người dùng 2 CHỈ có thể trả lời các câu hỏi của Người dùng 1 bằng một câu trả lời duy nhất, sau đó Người dùng 1 phải rời đi. Người dùng 2 không có cách giao tiếp nào khác.

Với sự hạn chế mới này, bạn sẽ làm thế nào ngoài việc bỏ phiếu?

— cây thông
nguồn

6

HTTP 2.0 sẽ hỗ trợ đẩy máy chủ. "Đẩy cho phép các máy chủ gửi đại diện cho khách hàng mà không có yêu cầu rõ ràng được thực hiện." vi.wikipedia.org/wiki/HTTP_2.0

— kaptan

5

@kaptan, thật tuyệt, nhưng nó không có sẵn. Thực hiện với những gì bạn đã có.

— riwalk

7

Ngoài ra còn có bỏ phiếu dài có sẵn ngay bây giờ và mô phỏng mô hình đẩy bằng cách sử dụng kéo.

— Tim B

24

@dennis: Đã viết phần mềm tự động hóa công nghiệp, tôi chỉ muốn bình luận về ví dụ bỏ phiếu của cảm biến. Cảm biến bỏ phiếu phục vụ hai mục đích - rõ ràng nhất là lấy dữ liệu mới. Điều ít rõ ràng hơn là phát hiện ra rằng cảm biến vẫn còn sống, không bị hỏng do lỗi hoặc cháy do cháy nhà máy hoặc tan chảy do tai nạn công nghiệp. Im lặng, thực tế là bạn không nhận được trả lời, cũng là dữ liệu có giá trị.

— slebetman

3

@dennis Sensors thường cảm nhận nhanh hơn nhiều so với việc bạn quan tâm đến dữ liệu. Bỏ phiếu cho phép bạn có được giá trị cảm biến chính xác khi bạn muốn, mà không bị ngập trong các bản cập nhật mà bạn không quan tâm. (Hãy tưởng tượng nếu HĐH thông báo cho ứng dụng của bạn mỗi khi tệp thay đổi ở bất kỳ đâu trên đĩa, thay vì ứng dụng của bạn cần mở và đọc tệp)

— miễn phí vào

13

Tại sao bỏ phiếu được chấp nhận? Bởi vì trong thực tế mọi giải pháp thực sự là bỏ phiếu cấp thấp!

Nếu máy chủ sẽ cập nhật cho bạn ngay khi có hình ảnh mới, thì nó thường phải có kết nối với bạn - vì địa chỉ IP thay đổi thường xuyên và bạn không bao giờ biết nếu ai đó không quan tâm nữa, vì vậy khách hàng phải gửi một số hình thức tín hiệu duy trì, ví dụ: "Tôi vẫn ở đây, tôi không ngoại tuyến"

Tất cả các kết nối trạng thái (ví dụ: TCP / IP) hoạt động như nhau, vì bạn chỉ có thể gửi các gói dữ liệu đơn lẻ qua Internet; bạn không bao giờ biết nếu bên kia vẫn còn ở đó.

Vì vậy, mọi giao thức đều có thời gian chờ. Nếu một thực thể không trả lời trong vòng X giây, nó được coi là đã chết. Vì vậy, ngay cả khi bạn chỉ có kết nối mở giữa máy chủ và máy khách, mà không gửi bất kỳ dữ liệu nào, máy chủ và máy khách phải gửi các gói duy trì thường xuyên (điều này được xử lý ở mức độ thấp nếu bạn mở kết nối giữa chúng) - và làm thế nào Điều này cuối cùng khác với bỏ phiếu?

Vì vậy, cách tiếp cận tốt nhất có lẽ sẽ là longpolling:

Khách hàng gửi yêu cầu ngay lập tức sau khi tải trang web (ví dụ: nói với nhiếp ảnh gia "Hãy cho tôi biết nếu có bất kỳ hình ảnh mới nào"), nhưng máy chủ không trả lời nếu không có bất kỳ hình ảnh mới nào. Ngay khi hết yêu cầu, khách hàng hỏi lại.

Nếu máy chủ bây giờ có bất kỳ hình ảnh mới, nó có thể trả lời ngay lập tức tất cả các máy khách xếp hàng cho hình ảnh mới. Vì vậy, thời gian phản ứng của bạn sau một hình ảnh mới thậm chí còn ngắn hơn so với đẩy, vì khách hàng vẫn đang chờ trong một kết nối mở để trả lời và bạn không phải xây dựng kết nối với khách hàng. Và các yêu cầu bỏ phiếu từ máy khách không có lưu lượng truy cập nhiều hơn kết nối liên tục giữa máy khách và máy chủ để có câu trả lời!

— Falco
nguồn

Tôi không đồng ý rằng mọi giải pháp kết thúc là bỏ phiếu ở cấp độ thấp. Bạn đang nhầm lẫn bỏ phiếu cần thiết để gửi dữ liệu với bỏ phiếu cần thiết để biết khi nào khách hàng bị mất. Có, cái sau sẽ luôn kết thúc việc bỏ phiếu ở đâu đó trong ngăn xếp giao thức, nhưng điều đó có thể ở tần số rất thấp (chẳng hạn như cứ năm phút một lần) trong khi bỏ phiếu cho dữ liệu thực tế mỗi giây là một sự lãng phí có thể tránh được với thông báo đẩy thực sự đó là KHÔNG bỏ phiếu ở bất kỳ cấp nào của ngăn xếp.

— Allon Guralnek

Hầu hết các gói bảo mật đầu tiên chạy ở tần số khá cao, vì bạn muốn tránh các khoảng thời gian chờ chung nên vài giây không phổ biến đối với TCP / IP và hầu như mọi thứ không sử dụng tcp đều có thể bị chặn bởi tường lửa. Vì vậy, khi tôi cần gửi một gói dữ liệu mỗi X giây, tại sao không điền nó với một số dữ liệu mà hầu như không mất phí?

— Falco

1

@Guralnek ngay cả khi bạn có kết nối với khoảng thời gian duy trì là 5 phút, thời gian chờ sẽ cao hơn, vì bạn phải thêm độ trễ thực tế và các gói bị mất. Và máy chủ sẽ giữ nhiều kết nối trong 5 phút sau khi máy khách bị ngắt kết nối, do đó, tổng thể điều này có thể sẽ tốn nhiều tài nguyên máy chủ hơn trong khi chỉ tiết kiệm băng thông tối thiểu

— Falco

1

+1 để bỏ phiếu dài. Tra cứu Comet en.wikipedia.org/wiki/Comet_%28programming%29

— Zan Lynx

9

Một lợi thế của việc bỏ phiếu là nó hạn chế tác hại có thể gây ra nếu một tin nhắn bị mất hoặc tình trạng của một cái gì đó bị trục trặc. Nếu X yêu cầu Y về trạng thái của nó cứ năm giây một lần, thì việc mất yêu cầu hoặc trả lời sẽ chỉ khiến thông tin của X bị lỗi mười giây thay vì 5. Nếu Y được khởi động lại, X có thể tìm hiểu về nó tiếp theo thời gian Y có thể trả lời một trong những tin nhắn của X. Nếu X được khởi động lại, nó có thể không bao giờ bận tâm hỏi Y về bất cứ điều gì sau đó, nhưng bất cứ ai đang quan sát trạng thái của X sẽ nhận ra rằng nó đã được khởi động lại.

Nếu thay vì X bỏ phiếu Y, X đã dựa vào Y để thông báo cho nó bất cứ khi nào trạng thái của nó thay đổi, thì nếu trạng thái của Y thay đổi và nó đã gửi tin nhắn cho X, nhưng vì bất kỳ lý do nào mà tin nhắn không được nhận, X có thể không bao giờ nhận ra sự thay đổi . Tương tự như vậy nếu Y được khởi động lại và không bao giờ có bất kỳ lý do nào để gửi X tin nhắn về bất cứ điều gì.

Trong một số trường hợp, X có thể hữu ích khi yêu cầu Y tự động gửi tin nhắn với trạng thái của nó, theo định kỳ hoặc khi nó thay đổi và chỉ có cuộc thăm dò X nếu quá lâu mà không nghe thấy gì từ Y. Thiết kế như vậy có thể loại bỏ cần cho X gửi hầu hết các tin nhắn của mình (thông thường, ít nhất X nên thỉnh thoảng thông báo cho Y rằng họ vẫn quan tâm đến việc nhận tin nhắn và Y nên ngừng gửi tin nhắn nếu quá lâu mà không có bất kỳ dấu hiệu quan tâm nào). Thiết kế như vậy, tuy nhiên, đòi hỏi Y phải kiên trìduy trì thông tin về X, thay vì chỉ có thể gửi trả lời cho bất cứ ai đã thăm dò ý kiến và sau đó ngay lập tức quên đi đó là ai. Nếu Y là một hệ thống nhúng, việc đơn giản hóa như vậy có thể giúp giảm đủ yêu cầu bộ nhớ để cho phép sử dụng bộ điều khiển nhỏ hơn và rẻ hơn.

Việc bỏ phiếu có thể có một lợi thế bổ sung khi sử dụng phương tiện liên lạc có khả năng không đáng tin cậy (ví dụ: UDP hoặc radio): phần lớn có thể loại bỏ nhu cầu xác nhận lớp liên kết. Nếu X gửi cho Y một yêu cầu trạng thái Q, Y trả lời với báo cáo trạng thái R và X nghe R, X sẽ không cần nghe bất kỳ loại xác nhận lớp liên kết nào cho Q để biết rằng nó đã được nhận. Ngược lại, một khi Y gửi R, nó không cần biết hoặc quan tâm nếu X nhận được nó. Nếu X gửi yêu cầu trạng thái và không nhận được phản hồi, nó có thể gửi yêu cầu khác. Nếu Y gửi báo cáo và X không nghe thấy, X sẽ gửi yêu cầu khác. Nếu mỗi yêu cầu được đưa ra một lần và mang lại phản hồi hoặc không, không bên nào cần biết hoặc quan tâm liệu có bất kỳ tin nhắn cụ thể nào được nhận hay không. Vì việc gửi xác nhận có thể tiêu tốn gần như nhiều băng thông như yêu cầu hoặc báo cáo trạng thái, sử dụng báo cáo yêu cầu khứ hồi không tốn nhiều chi phí hơn so với báo cáo và xác nhận không được yêu cầu. Nếu X gửi một vài yêu cầu mà không nhận được trả lời, có thể trên một số mạng được định tuyến động cần phải bật xác nhận ở cấp liên kết (và yêu cầu Y yêu cầu như vậy) để ngăn xếp giao thức cơ bản có thể nhận ra vấn đề phân phối và tìm kiếm một tuyến mới, nhưng khi mọi thứ đang hoạt động, mô hình báo cáo yêu cầu sẽ hiệu quả hơn so với sử dụng các xác nhận ở cấp liên kết.

— siêu mèo
nguồn

Vấn đề bạn nói với Y đẩy tin nhắn đến X (đoạn thứ hai) có thể được khắc phục bằng cách gắn số sê-ri cho mỗi tin nhắn. Nếu một tin nhắn bị mất, X sẽ biết vì nó không nhận được chuỗi đó. Tại thời điểm đó, có thể thực hiện các biện pháp khác để đồng bộ hóa với Y. DNS master -> sao chép nô lệ hoạt động theo cách này.

— korylprince

@korylprince: Một trong hai bên có thể tìm hiểu về tin nhắn bị mất nếu bên kia có dịp gửi một cái gì đó (và thực hiện thành công), hoặc nếu nó có lý do để mong đợi một cái gì đó từ phía bên kia và không bao giờ nhận được nó. Nếu một bên gửi cập nhật trạng thái và không yêu cầu xác nhận hoặc bỏ cuộc sau khi thử lại một vài lần và bên kia không mong đợi việc truyền theo lịch trình, thì bên kia sẽ không biết rằng kết nối đã biến mất.

— supercat

2

@korylprince - Vấn đề là, không có tin nhắn định kỳ, X có thể phát hiện tin nhắn bị mất một ngày trễ hoặc trễ một năm hoặc trễ 10 năm. Để phát hiện gói bị thiếu trong thời gian hợp lý, bạn cần phải thăm dò bằng cách nào đó. Bạn có thể "kéo" cuộc thăm dò hoặc bạn có thể "đẩy" cuộc thăm dò. Đầu tiên được gọi là "bỏ phiếu" thứ hai được gọi là "nhịp tim"

— slebetman

Cả hai rất đúng. Tất cả phụ thuộc vào tình hình.

— korylprince

@slebetman: Nếu không có thông điệp định kỳ, nếu Y được khởi động lại, có thể không có cơ chế theo đó X sẽ không bao giờ khám phá ra nó.

— supercat

1

Câu hỏi là để cân bằng số lượng các cuộc thăm dò không cần thiết so với số lần đẩy không cần thiết.

Nếu bạn bình chọn:

Bạn nhận được một câu trả lời tại thời điểm này. Tốt nếu bạn chỉ thỉnh thoảng hỏi hoặc cần một bộ dữ liệu ngay lúc này.
Bạn có thể nhận được câu trả lời "không có nội dung", gây ra tải vô nghĩa trên dòng.
Bạn đặt tải trên dòng chỉ khi bạn bỏ phiếu, nhưng luôn luôn khi bạn bỏ phiếu.

Nếu bạn đẩy:

Bạn cung cấp câu trả lời ngay khi có sẵn, điều này cho phép xử lý ngay lập tức ở phía khách hàng.
Bạn có thể cung cấp dữ liệu cho khách hàng không quan tâm đến dữ liệu này, gây ra tải vô nghĩa trên đường dây.
Bạn đặt tải trên dòng mỗi khi có dữ liệu mới, nhưng chỉ khi có dữ liệu mới.

Có một số giải pháp về cách xử lý các tình huống khác nhau và nhược điểm của chúng, ví dụ như thời gian tối thiểu giữa các cuộc thăm dò, ủy quyền chỉ dành cho cuộc thăm dò để loại bỏ hệ thống chính, hoặc - cho các lần đẩy - một quy định để đăng ký và chỉ định dữ liệu mong muốn theo sau bằng cách không đăng ký khi đăng xuất. Cái nào phù hợp nhất là không có gì bạn có thể nói chung, nó phụ thuộc vào hệ thống.

Trong ví dụ của bạn, bỏ phiếu không phải là giải pháp hiệu quả nhất, mà là giải pháp thiết thực nhất. Rất dễ dàng để viết một hệ thống bỏ phiếu bằng JavaScript và cũng rất dễ thực hiện nó ở phía phân phối. Một máy chủ được tạo để phân phối dữ liệu hình ảnh sẽ có thể xử lý các yêu cầu bổ sung và nếu không, nó có thể được thu nhỏ theo tuyến tính, vì dữ liệu chủ yếu là tĩnh và do đó có thể dễ dàng lưu vào bộ nhớ cache.

Phương pháp đẩy thực hiện đăng nhập, mô tả dữ liệu mong muốn và cuối cùng là đăng xuất sẽ hiệu quả nhất, nhưng có lẽ quá phức tạp đối với "script-kiddy" trung bình và cần xử lý câu hỏi: nếu người dùng sử dụng chỉ cần tắt trình duyệt và đăng xuất không thể được thực hiện?

Có lẽ tốt hơn là có nhiều người dùng (vì việc truy cập rất dễ dàng) hơn là tiết kiệm một số tiền trên một máy chủ bộ đệm khác?

— Hai
nguồn

1

Vì một số lý do, những ngày này, tất cả các nhà phát triển web trẻ dường như đã quên đi những bài học trong quá khứ và tại sao một số điều đã phát triển theo cách họ đã làm.

Băng thông là một vấn đề
Kết nối có thể không liên tục.
Trình duyệt không có nhiều sức mạnh tính toán
Có các phương pháp khác để truy cập nội dung. Web không phải là w3.

Trước những hạn chế này, bạn có thể không có giao tiếp 2 chiều liên tục. Và nếu bạn đã xem mô hình OSI, bạn sẽ thấy hầu hết các cân nhắc đều có nghĩa là tách rời sự kiên trì với kết nối cơ bản.

Với ý nghĩ đó, một phương pháp bỏ phiếu lấy thông tin là một cách tuyệt vời để giảm băng thông và tính toán ở phía máy khách. Sự gia tăng của đẩy thực sự là phần lớn chỉ là khách hàng thực hiện bỏ phiếu liên tục hoặc ổ cắm web. Cá nhân nếu tôi là những người khác ở ngoài đó, tôi sẽ đánh giá cao sự thường xuyên của việc bỏ phiếu như một phương tiện phân tích giao thông, trong đó yêu cầu GET / POST không đúng lúc sẽ báo hiệu một người đàn ông trong tình huống giữa chừng.

— tài khoản khách
nguồn