B/S 브 라 우 저 차단 판단 에 관 한 문제 토론

클 라 이언 트 는 스 크 립 트 와 서버 를 통 해 요청 을 유지 합 니 다.매번 새로 고침 을 요청 할 때마다 서버 에서 이 시간 을 검사 합 니 다.만약 시간 이 예정 보다 초과 되 었 다 는 것 을 발견 하면 클 라 이언 트 브 라 우 저가 종료 되 었 음 을 판단 할 수 있 습 니 다.그리고 그 에 상응하는 조작 을 한다.그 클 라 이언 트 브 라 우 저 가 닫 혔 는 지 알 고 싶다 면 세 션 을 폴 링 대상 에 연결 할 수 있 습 니 다.긴 연결 은 모든 서버 가 지원 하 는 것 이 아 닙 니 다.이런 방식 은 당신 의 현실 보다 훨씬 많 습 니 다.나의 개인 적 인 견해.저 는 먼저 이 몇 가지 방법 에 동의 합 니 다.그들 도 이 수 요 를 실현 할 수 있 습 니 다.그들 은 모두 클 라 이언 트 의 문의 로 서버 의 마지막 방문 시간 을 업데이트 하여 서버 의 검 측 시간 을 초과 할 수 있 습 니 다.제 가 이 두 가지 방법 에 대한 이 해 를 말씀 드 리 겠 습 니 다.1 서버 에서 시간 초과 판단 을 어떻게 하고 배경 스 레 드 를 시작 하여 정시 폴 링 을 합 니까?각 session 이 간격 을 초과 하 였 는 지 순환 검사 합 니까?2.스 레 드 를 사용 하면 서버 측 에서 판단 하 는 간격 이나 주기 가 얼마 인지,1 초,10 초,20 초 입 니 다.3.모두 가 10 초 간격 을 사용 하면 고객 도 이 간격 을 견 딜 수 있 습 니 다.결 과 를 보 겠 습 니 다.  1)긴 연결 을 지원 하지 않 는 서버 가 있 는 지 모 르 겠 습 니 다.100 G 파일 을 다운로드 하면 안 되 나 요?중간 에 꼭 n 번 끊 어야 돼 요?  2)당신 의 모든 클 라 이언 트 는 10 초 안에 새로운 요청 을 해서 서버 가 응답 하도록 해 야 합 니 다.저 는 필요 하지 않 습 니 다.  3)폴 링 작업 은 동시 다발 문제,즉 동기 접근 문제 에 주의해 야 합 니 다.데 이 터 는 application 또는 다른 사용자 정의 전역 데이터 구조 에 저장 해 야 합 니 다.다 중 스 레 드 에는 이 문제 가 존재 하지 않 습 니 다.  4)폴 링 은 단일 스 레 드 에 속 하고 통일 적 으로 처리 하 며 긴 연결 은 다 중 스 레 드 이다.  5)클 라 이언 트 가 리 셋 을 요청 할 때마다 연결 을 끊 으 면 서버 의 연결 수 를 줄 이 고 병발 수 를 높 일 수 있 으 나 요청 할 때마다 부담 이 상대 적 으로 증가 합 니 다.4.관건 적 인 차이 점:0.1 초 안에 정확 한 반응 을 해 야 한다 고 요구 하면 연결 이 끊 어 지 는 것 을 발견 하면 바로 처리 해 야 합 니 다.제 다 중 스 레 드 방안 이 더욱 효과 적 이 라 고 생각 합 니 다.브 라 우 저 는 그렇게 짧 은 시간 안에 10 번 의 요청 을 하기 어렵 기 때 문 입 니 다.긴 연결 은 데 이 터 를 보 내 는 간격 만 줄 이면 된다.  요약:수요 결정 응용.시스템 이 요구 하 는 판단 시간 이 짧 을 수록 긴 연결 방안 의 장점 이 크 고 시간 이 길 수록 폴 링 의 가용성 이 강하 다.구체 적 으로 는 응용 에 따라 선택 해 야 한다.일반적인 B/S 판단 에 대해 대부분의 대화방 과 온라인 인원 통 계 는 임 행 폴 링 으로 이 뤄 졌 다.혼자 채 팅 방 을 나 가면 온라인 목록 을 바로 업데이트 하 지 는 않 지만,IM 프로그램(QQ/MSN)등 은 상대 적 으로 매우 정확하게 업데이트 된다.정확 한 판단 이 필요 하 다 면 긴 연결 은 내 가 생각 할 수 있 는 해결 방안 중 하나 라 고 생각한다.다른 하 나 는 애플 트,플래시,ActiveX 등 클 라 이언 트 플러그 인 입 니 다.하지만 메커니즘 과 긴 연결 은 다 르 지 않 습 니 다.두 가지 작은 건의.0.1 까지 반응 하면 되 지만 0.1 초 까지'정확'반응 을 하면 안 된다.TCP 프로 토 콜 은 긴 연결 이지 만 CS 의 한쪽 이 떨 어 졌 을 때 다른 한쪽 이 신속하게 알 수 있 도록 규정 되 어 있 지 않다(그렇지 않 으 면 나중에 TCP 가 표준 적 이지 않 은'심장 박동'프로 토 콜 도 없 을 것 이다).이것 은 중간 네트워크 하드웨어 의 지원 과 관련된다.현실 에서 도 마찬가지다.물론 나 는 판 주 라 는 글 에 윗글 이 있 을 지 모 르 기 때문에 이 시스템 이 어떤 인터넷 에서 실행 되 려 고 하 는 지 모르겠다.2。 글 이'앞 페이지'를 언급 한 이상.이 시스템 은 QQ 나 게임 서버 가 아 닌 것 같 습 니 다.배경 은 일반적인 WEB 서버,IIS 또는 APACHE 를 실행 하 는 것 일 가능성 이 높 습 니 다.이들 의 디자인 목 표 는 명확 하기 때문에 최대 연결 수 제한 이 있다.겉 으로 는 수천 명 이 동시에 온라인 으로 연결 되 어 있어 괜찮아,짧 은 연결 을 사용 하기 때문에 같은 시간의 병발 수 는 보통 충분 하 다.그러나 고객 이 움 직 이지 않 더 라 도 연결 을 유지 해 야 한다 면 이 수 는 곧 한계 가 있 을 것 이다.게임 이나 IM 도구,예 를 들 어 QQ 와 같은 전형 적 인 도구 라 도 TCP 로 서버 를 오래 연결 할 수 는 없다.그래서 제 가 정리 한 것 은 최대 1,200 명 정도 가 동시에 접속 하려 면 건물 주 방법 을 사용 할 수 있다 는 것 입 니 다.인원 이 늘 어 나 면 플래시,activeX,socket...모두 긴 연결 이 불가능 하 며 UDP 로 만 질 지 언 정.