웹 프로그래밍에서 폴링이 허용되는 이유는 무엇입니까?

현재 이미지 목록을 보여주는 Ruby on Rails 프로젝트를 진행 중입니다.

이 프로젝트의 필수 요소는 웹 페이지를 새로 고칠 필요없이 실시간으로 새 게시물을 표시한다는 것입니다. 잠시 동안 검색 한 후 PubNub와 같은 일부 JavaScript 솔루션 및 서비스를 발견했습니다. 그러나 제공된 솔루션 중 어느 것도 전혀 의미가 없습니다.

JavaScript 솔루션 ( polling )에서 다음이 발생합니다.

• 사용자 1은 사진 목록을 봅니다.
• 백그라운드에서 JavaScript 코드는 매초마다 엔드 포인트를 폴링하여 새 게시물이 있는지 확인합니다.
• 사용자 2가 새 사진을 추가합니다.
• 새 사이클이 트리거되고 새 데이터를 가져 오기 전에 50ms의 지연이 있습니다.
• 새 컨텐츠가 DOM에 로드됩니다 .

실제 예제로 변환하면 이상하게 보입니다.

• 사용자 1은 자신의 책상에 사진 더미를 보관합니다.
• 매 초마다 사진 작가에게 걸어가 새로운 사진이 있는지 묻습니다.
• 사진사가 새로운 사진을 만듭니다.
• 두 번째로 들어 오면 사진을 찍어 더미에 넣을 수 있습니다.

내 생각에 해결책은 다음과 같아야합니다.

• 사용자 1은 자신의 책상에 사진 더미를 보관합니다.
• 사진사가 새로운 사진을 찍습니다.
• 사진가는 더미로 걸어가 나머지와 함께 넣습니다.

PubNub 솔루션은 기본적으로 동일하지만 이번에는 데이터를 공유하기 위해 당사자간에 인턴이 있습니다.

말할 것도없이, 두 솔루션 모두로드 할 데이터가없는 경우에도 트리거되므로 매우 에너지 소모가 많습니다.

내가 아는 한이 구현 방식이 거의 모든 실시간 애플리케이션에 사용되는 이유에 대한 논리적 인 설명은 없습니다.

푸시는 1 명 또는 제한된 수의 사용자에게 적합합니다.

이제 사진사 한 명과 사진 사본을 원하는 1000 명의 사용자로 시나리오를 변경하십시오. 사진 작가는 1000 개의 더미까지 걸어야합니다. 그들 중 일부는 사무실에 잠겨 있거나 바닥에 퍼져있을 수 있습니다. 또는 휴가중인 사용자이며 현재 새 사진에 관심이 없습니다.

사진가는 항상 바쁘고 새로운 사진을 찍지 않을 것입니다.

근본적으로 풀 / 폴 (pull / poll) 모델은 실시간 요구 사항이 느슨한 많은 신뢰할 수없는 독자에게 더 잘 확장됩니다 (그림이 10 초 후에 파일에 도달하면 큰 문제가됩니다).

즉, 푸시 모델은 많은 상황에서 여전히 더 좋습니다. 짧은 대기 시간이 필요하거나 (촬영 후 5 초 후에 새 사진이 필요함) 업데이트가 드물고 자주 예측할 수있는 요청 (사진이 하루에 새 사진을 생성 할 때 매 10 초마다 계속 요청)하는 경우 당기는 것이 부적절합니다. 당신이하려는 일에 달려 있습니다. 나스닥 : 푸시. 날씨 서비스 : 당기기. 결혼 사진 작가 : 아마 풀. 뉴스 사진 대행사 : 아마 푸시.

한 사람 만이 WebSockets 를 언급 한 것에 정말 놀랐습니다 . 지원은 기본적으로 모든 주요 브라우저에서 구현됩니다 .

실제로 PubNub는이를 사용합니다. 응용 프로그램의 경우 브라우저는 새 사진을 사용할 수있을 때마다 브로드 캐스트하는 소켓을 구독합니다. 소켓은 사진을 보내지 않고 브라우저를 비동기식으로 다운로드 할 수 있도록 링크 만 제공합니다.

귀하의 예에서 다음과 같은 것을 상상해보십시오.

1. 사용자는 미래의 모든 사진에 대해 알고 싶다고 사진 작가에게 알립니다
2. 사진 작가는 새로운 사진을 사용할 수 있다고 스피커를 통해 말합니다
3. 사용자가 사진사에게 사진 요청

이것은 원래 예제 솔루션과 다소 비슷합니다. 클라이언트가 서버에 데이터를 보낼 필요가 없기 때문에 폴링보다 효율적입니다 ( 심장 박동 제외 ).

또한 다른 사람들이 언급했듯이 구형 브라우저에서 작동하는 간단한 폴링보다 나은 다른 방법이 있습니다 ( longpolling 등 ).

때로는 충분하면 충분합니다.

"실시간"통신 프로세스를 구현할 수있는 모든 가능한 방법 중에서 폴링이 가장 간단한 방법 일 것입니다. 폴링 간격이 상대적으로 길면 (즉, 순간이 아닌 몇 초, 몇 분 또는 몇 시간) 폴링을 효과적으로 사용할 수 있으며 연결 또는 리소스를 확인하여 소비되는 클럭주기는 중요하지 않습니다.

HTTP 프로토콜은 클라이언트가 요청을 시작하는 프로토콜이어야한다는 점에서 제한됩니다. 클라이언트의 요청에 응답하지 않으면 서버가 클라이언트와 통신 할 수 없습니다.

실제 예를 조정하려면 다음 구속 조건을 추가하십시오.

• 사용자 2는 한 문장으로 만 사용자 1의 질문에 응답 할 수 있으며 그 후에는 사용자 1이 떠나야합니다. 사용자 2는 다른 통신 방법이 없습니다.

이 새로운 구속으로 폴링 이외의 다른 방법은 무엇입니까?

폴링이 허용되는 이유는 무엇입니까? 실제로 모든 솔루션은 실제로 저수준 폴링이기 때문에!

새 사진을 사용할 수있는 즉시 서버에서 업데이트해야하는 경우 IP 주소가 자주 변경되고 더 이상 관심이없는 사람이 누구인지 알 수 없기 때문에 일반적으로 연결되어 있어야합니다. 연결 유지 신호 (예 : "여전히 여기 있습니다, 오프라인이 아닙니다")

인터넷을 통해 단일 데이터 패킷 만 보낼 수 있으므로 모든 상태 저장 연결 (예 : TCP / IP)은 동일하게 작동합니다. 상대방이 아직 있는지 알 수 없습니다.

따라서 모든 프로토콜에는 시간 초과가 있습니다. 엔터티가 X 초 내에 응답하지 않으면 사망 한 것으로 간주됩니다. 따라서 데이터를 보내지 않고 서버와 클라이언트 사이에 열린 연결 만 있더라도 서버와 클라이언트는 정기적 인 연결 유지 패킷을 보내야합니다 (이는 연결을 열면 낮은 수준으로 처리됨). 이것은 결국 폴링과 다른 점이 있습니까?

따라서 가장 좋은 방법은 아마도 폴링 일 것입니다.

클라이언트는 사이트를로드 한 직후 요청을 보냅니다 (예 : 사진사에게 "새 사진이 있는지 알려주세요"). 그러나 새 사진이 없으면 서버가 응답하지 않습니다. 요청 시간이 초과되면 클라이언트가 다시 묻습니다.

이제 서버에 새 그림이 있으면 새 그림을 위해 대기중인 모든 클라이언트에 즉시 응답 할 수 있습니다. 따라서 새 사진을 보낸 후의 반응 시간은 푸시보다 더 짧습니다. 클라이언트가 여전히 응답을 위해 열린 연결을 기다리고 있기 때문에 클라이언트와의 연결을 구축 할 필요가 없기 때문입니다. 그리고 클라이언트로부터의 폴링 요청은 응답을 위해 클라이언트와 서버 사이의 지속적인 연결보다 더 많은 트래픽이 아닙니다!

폴링의 한 가지 장점은 메시지가 누락되거나 무언가의 상태가 글리치 될 경우 발생할 수있는 피해를 제한한다는 것입니다. X가 5 초마다 한 번씩 Y의 상태를 요청하면 요청 또는 응답이 유실되면 X의 정보가 5가 아닌 10 초가 지난 것입니다. Y가 재부팅되면 X가 다음에 대해 알 수 있습니다. 시간 Y는 X의 메시지 중 하나에 응답 할 수 있습니다. X가 재부팅되면 나중에 Y에게 아무것도 요구하지 않을 수 있지만 X의 상태를 관찰하는 사람은 재부팅되었음을 인식해야합니다.

X 폴링 Y 대신에 X는 상태가 변경 될 때마다이를 알리기 위해 Y에 의존 한 경우, Y의 상태가 변경되어 X에 메시지를 보냈지 만 어떤 이유로 든 메시지를받지 못한 경우 X는 변경을 인식하지 못할 수 있습니다. . 마찬가지로 Y가 재부팅되고 X에 메시지를 보낼 이유가없는 경우에도 마찬가지입니다.

어떤 경우에는 X가 주기적으로 또는 변경 될 때마다 상태를 가진 메시지를 자율적으로 보내도록 요청하는 것이 도움이 될 수 있으며, Y로부터 아무 것도 듣지 않고 너무 오래 갈 경우에만 X 폴링을 요구할 수 있습니다. X는 대부분의 메시지를 보내야합니다 (일반적으로 X는 메시지 수신에 관심이 있다는 메시지를 적어도 가끔 Y에게 알려야하며 관심 표시없이 너무 오래 보내면 메시지 전송을 중지해야합니다). 그러나 그러한 설계는 Y를 지속적으로 요구할 것이다.폴링 한 사람에게 간단히 답장을 보낸 다음 그 사람이 누구인지 즉시 잊어 버리지 않고 X에 대한 정보를 유지하십시오. Y가 임베디드 시스템 인 경우, 이러한 단순화는 더 작고 저렴한 컨트롤러를 사용할 수 있도록 메모리 요구 사항을 충분히 줄이는 데 도움이 될 수 있습니다.

폴링은 잠재적으로 신뢰할 수없는 통신 매체 (예 : UDP 또는 라디오)를 사용할 때 추가 이점을 가질 수 있습니다. 링크 계층 승인의 필요성을 크게 제거 할 수 있습니다. X가 Y에게 상태 요청 Q를 보내면, Y는 상태 보고서 R로 응답하고 X는 R을 듣는다. X는 그것이 수신되었다는 것을 알기 위해 어떤 종류의 링크 계층 확인도들을 필요가 없다. 반대로, Y가 R을 보내면 X가 그것을 받았는지 알거나 신경 쓸 필요가 없습니다. X가 상태 요청을 보내고 응답을받지 못하면 다른 요청을 보낼 수 있습니다. Y가 보고서를 보내고 X가 들리지 않으면 X는 다른 요청을 보냅니다. 각 요청이 한 번 나가서 응답을 얻거나 응답하지 않으면 어느 쪽 당사자도 특정 메시지가 수신되었는지 알거나 신경 쓸 필요가 없습니다. 승인을 보내는 것은 상태 요청 또는 보고서만큼 많은 대역폭을 소비 할 수 있으므로, 요청 보고서의 왕복을 사용하는 것은 원치 않는 보고서 및 승인보다 많은 비용이 들지 않습니다. X가 응답하지 않고 몇 가지 요청을 보내는 경우 일부 동적 라우팅 네트워크에서 기본 프로토콜 스택이 전달 문제를 인식하고 검색 할 수 있도록 링크 수준 승인을 활성화하고 (요청에서 Y도 마찬가지라고 요청해야 함) 새로운 경로이지만 상황이 작동하는 경우 요청 보고서 모델이 링크 수준 승인을 사용하는 것보다 더 효율적입니다.

문제는 불필요한 폴링 양과 불필요한 푸시 양의 균형을 맞추는 것입니다.

설문 조사를하는 경우 :

• 이 순간에 답을 얻습니다. 가끔 요청하거나이 순간에 데이터 세트가 필요한 경우에 좋습니다.
• "컨텐츠 없음"응답이 표시되어 회선에 무의미한로드가 발생할 수 있습니다.
• 폴링 할 때만, 항상 폴링 할 때 회선에 부하를가합니다.

밀면 :

• 사용 가능한 경우 즉시 답변을 제공하므로 클라이언트 측에서 즉시 처리 할 수 ​​있습니다.
• 이 데이터에 관심이없는 클라이언트에게 데이터를 전달하여 회선에 무의미한로드를 유발할 수 있습니다.
• 새 데이터가있을 때마다 새 데이터가있을 때만로드를로드하십시오.

예를 들어 폴링 사이의 최소 시간, 메인 시스템에서로드를 제거하는 폴링 전용 프록시 또는 푸시의 경우 등록 및 지정 규칙과 같은 다양한 시나리오 및 단점을 처리하는 방법에 대한 몇 가지 솔루션이 있습니다. 원하는 데이터 다음에 로그 오프 등록을 취소합니다. 가장 적합한 것은 일반적으로 말할 수있는 것이 아니며 시스템에 따라 다릅니다.

귀하의 예에서 폴링은 가장 효율적인 솔루션이 아니라 가장 실용적인 솔루션입니다. JavaScript로 폴링 시스템을 작성하는 것은 매우 쉽고 전달 측면에서도 구현이 매우 쉽습니다. 이미지 데이터를 제공하도록 만들어진 서버는 추가 요청을 처리 할 수 ​​있어야하며 그렇지 않은 경우 데이터가 대부분 정적이므로 쉽게 캐시 할 수 있으므로 선형으로 확장 할 수 있습니다.

로그인, 원하는 데이터에 대한 설명 및 마지막으로 로그 오프를 구현하는 푸시 방법이 가장 효율적이지만 아마도 "스크립트 학습"에 비해 너무 복잡하고 질문을 처리해야합니다. 브라우저를 종료하고 로그 오프를 수행 할 수 없습니까?

다른 캐시 서버에 약간의 비용을 절약하는 것보다 더 많은 사용자를 확보하는 것이 더 낫습니다.

어떤 이유로 오늘날 요즘의 모든 젊은 웹 개발자들은 과거의 교훈을 잊어 버린 것 같습니다.

1. 대역폭은 문제였습니다
2. 연결이 간헐적 일 수 있습니다.
3. 브라우저는 많은 컴퓨팅 능력을 가지고 있지 않았습니다
4. 콘텐츠에 액세스하는 다른 방법이있었습니다. 웹은 w3이 아닙니다.

이러한 제약 조건에 직면하여 지속적인 양방향 통신이 이루어지지 않을 수 있습니다. 그리고 OSI 모델을 살펴보면 대부분의 고려 사항은 지속성을 기본 연결과 분리하는 것입니다.

이를 염두에두고 정보를 끌어 오는 폴링 방법은 클라이언트 측에서 대역폭과 계산을 줄이는 좋은 방법입니다. 푸시의 상승은 실제로 클라이언트가 지속적인 폴링 또는 웹 소켓을 수행하는 대부분의 경우입니다. 개인적으로 내가 다른 사람이라면 트래픽 분석 수단으로서 폴링의 규칙성에 감사합니다. 시간이 지남에 따라 GET / POST 요청이 어떤 상황에서 사람에게 신호를 보냅니다.