B/S가 브라우저 연결 끊김_자바스크립트 능력을 판단하는 문제에 대한 토론

클라이언트는 스크립트를 통해 요청을 유지하며, 서버는 이 시간을 확인하여 해당 시간이 미리 정해진 시간을 초과한 것으로 판단되면 클라이언트의 브라우저가 종료된 것으로 판단할 수 있습니다. 그런 다음 해당 작업을 수행하십시오. 어떤 클라이언트 브라우저가 닫혔는지 알고 싶다면 세션을 폴링 개체에 바인딩하면 됩니다. 모든 서버가 긴 연결을 지원하는 것은 아닙니다. 이 방법은 귀하의 방법보다 훨씬 현실적입니다.
개인적인 생각입니다.
먼저 이러한 접근 방식에 동의합니다. 또한 이 요구 사항을 충족할 수도 있습니다. 모두 클라이언트 폴링을 통해 서버의 마지막 액세스 시간을 업데이트하고 서버가 시간 초과를 감지하도록 합니다. 이 두 가지 방법에 대한 나의 이해에 대해 이야기하겠습니다

1 서버 측에서 시간 초과를 판단하고 정기적인 폴링을 위해 백그라운드 스레드를 시작하는 방법은 무엇입니까? 각 세션이 간격을 초과하는지 확인하기 위해 반복하시겠습니까?
2 쓰레드를 사용한다면 서버가 판단하는 간격이나 주기는 1초, 10초, 20초...
3 모두가 10초 간격을 사용한다면 고객도 이 간격을 견딜 수 있다. , 결과를 보자
1) 어떤 서버가 장거리 연결을 지원하지 않는지 모르겠습니다. 100G 파일을 다운로드하면 작동하지 않습니까? 중간에 n번 연결을 끊어야 하나요?
2) 각 클라이언트는 서버가 응답하도록 10초 이내에 새 요청을 발행해야 하지만 내 클라이언트는 그럴 필요가 없습니다.
3) 폴링 작업 중 동시성 문제, 즉 동기 액세스에 주의하세요. 문제는 데이터가 애플리케이션이나 기타 사용자 정의 전역 데이터 구조에 저장되어야 하며 멀티스레딩에는 이 문제가 없다는 것입니다
4) 폴링은 단일 스레드로 균일하게 처리되는 반면 긴 연결은 멀티 스레드입니다
5) 각 요청 새로 고침 후 클라이언트 연결을 끊으면 서버가 차지하는 연결 수를 줄이고 동시성 수를 늘릴 수 있지만 상대적으로 각 요청의 부담이 늘어납니다.
4 주요 차이점: 요청이 0.1초 내에 정확 내에 이루어져야 하는 경우 반응, 연결이 끊어진 것으로 확인되면 즉시 처리해야 합니다. 브라우저가 짧은 시간 내에 10개의 요청을 보내기 어렵기 때문에 제 멀티 스레드 솔루션이 더 효과적일 것이라고 생각합니다. . 긴 연결의 경우 데이터 전송 간격을 줄이기만 하면 됩니다.



요약:
요구에 따라 애플리케이션이 결정됩니다.
시스템에서 요구하는 판단 시간 제한이 짧을수록 긴 연결 솔루션의 장점은 커집니다. 시간이 길수록 폴링의 가용성은 더욱 강해집니다. 애플리케이션에 따라 구체적인 결정을 내려야 합니다.
일반적인 B/S 판단을 위해 대부분의 채팅방과 온라인 인구 통계는 이동 중에도 여론 조사 작업을 하고 있습니다. 상대방이 채팅방을 나가면 온라인 목록이 바로 업데이트되지는 않지만 IM 프로그램(QQ/MSN) 등은 비교적 정확하게 업데이트됩니다.

정확한 판단이 필요하다면 제가 생각할 수 있는 솔루션 중 하나는 긴 연결이고, 다른 하나는 소켓을 사용하는 애플릿, 플래시, ActiveX 등과 같은 클라이언트 플러그인입니다. 그러나 메커니즘과 긴 연결에는 차이가 없습니다.
두 가지 팁

1. 0.1의 응답을 얻는 것은 괜찮지만 0.1초의 "정확한" 응답을 얻는 것은 불가능합니다. TCP 프로토콜은 장기 연결이지만 CS의 한쪽 끝이 끊어지면 다른 쪽 끝이 이를 빨리 알 수 있다고 규정하지 않습니다. 그렇지 않으면 나중에 TCP에서 표준이 아닌 "하트비트" 프로토콜이 없습니다. . 이는 중간 네트워크 하드웨어 지원과 관련이 있습니다. 이는 현실에서도 마찬가지이다. 물론, 위의 글과 마찬가지로 이 글도 운영자가 작성했을지 모르기 때문에 이 시스템이 어떤 네트워크에서 실행될지는 알 수 없습니다.

2. 기사에서 "이전 페이지"를 언급했기 때문입니다. 이 시스템은 QQ나 게임 서버가 아니어야 할 것 같습니다. 배경은 아마도 일반 웹 서버, IIS 또는 APACHE를 실행하고 있을 것입니다. . 설계 목표가 명확하므로 최대 연결 수를 갖게 됩니다. 표면적으로는 수천 명이 동시에 온라인에 접속해도 문제가 되지 않습니다. 연결 시간이 짧기 때문에 일반적으로 동시 실행 횟수이면 충분합니다. 그러나 클라이언트가 비활성 상태인 경우에도 연결을 유지해야 한다면 이 숫자는 곧 한계에 도달하게 됩니다.
게임이나 IM 도구(일반적으로 QQ)라도 오랫동안 서버에 연결하기 위해 감히 TCP를 사용하지 않습니다.

그래서 내 결론은 최대 100~200명이 동시에 온라인에 접속하는 프로젝트를 계획한다면(동시 활동이 아닌) 원본 포스터의 방법을 사용할 수 있다는 것입니다. . 플래시, 액티브X, 소켓 등 인원이 늘어나면 긴 연결은 불가능하고 UDP를 사용하는 것이 좋습니다.