HTTP 프로 토 콜 기반 의 실시 간 데이터 획득 기술 에 대한 상세 한 설명

HTTP 프로 토 콜
HTTP 프로 토 콜 은 모두 가 잘 알 고 있 습 니 다.본문 을 시작 하기 전에 먼저 HTTP 프로 토 콜 을 간단히 살 펴 보 겠 습 니 다.
HTTP 프로 토 콜 은 TCP 프로 토 콜 에 설 치 된 응용 층 프로 토 콜 입 니 다.프로 토 콜 의 본질은 요청-응답 입 니 다.

즉,HTTP 프로 토 콜 의 경우 서버 가 한 번 응답 하면 전체 요청 이 끝 납 니 다.이것 은 HTTP 요청 의 가장 큰 특징 이자 이 특징 때문에 HTTP 요청 이 할 수 없 는 것 은 서버 가 클 라 이언 트 에 게 데 이 터 를 주동 적 으로 전송 하 는 것 입 니 다.
그러나 HTTP 프로 토 콜 의 광범 위 한 응용 으로 인해 HTTP 프로 토 콜 을 사용 하여 실시 간 데이터 획득 을 실현 하려 는 경우 가 많 습 니 다.이 럴 때 어떻게 해 야 합 니까?먼저 HTTP 프로 토 콜 을 기반 으로 한 실시 간 데이터 획득 방법 을 소개 한다. 
짧 은 폴 링
폴 링 은 가장 보편적 인 HTTP 프로 토 콜 을 바탕 으로 실시 간 데 이 터 를 얻 는 방식 으로 폴 링 은 짧 은 폴 링 과 긴 폴 링 으로 나 뉜 다.짧 은 폴 링 은 매우 간단 하 다.그림 으로 표시 하 자.

클 라 이언 트 가 서버 에 데 이 터 를 요청 하면 서버 는 즉시 데 이 터 를 클 라 이언 트 에 게 되 돌려 줍 니 다.클 라 이언 트 는 원 하 는 데 이 터 를 받 지 못 했 습 니 다(예 를 들 어 결 과 를 되 돌려 클 라 이언 트 에 게 알 리 고 데이터 처리 중).클 라 이언 트 는 계속 요청 을 하고 서버 는 계속 즉시 응답 하 며 반복 합 니 다.
이런 실시 간 데 이 터 를 얻 는 방식 은 비교적 거 칠 고 프로 그래 밍 이 간단 하 며 클 라 이언 트 가 요청 을 보 내 고 서버 에서 실시 간 으로 응답 하면 된다 는 장점 이 있다.단점 은 주로 두 가지 가 있다.

무효 요청 이 많 고 매번 무효 요청 은 대역 폭 과 서버 의 계산 자원 을 낭비 합 니 다

서버 에 대한 부담 이 크 고 정시 에 요청 을 보 내 며 동시에 높 아 지면 서버 에서 순식간에 수천 개의 요청 을 받 을 수 있 고 서버 를 무 너 뜨리 거나 다운 되 기 쉽다

그러면 짧 은 폴 링 은 어떤 장면 에 적합 합 니까?제 이해 에 따 르 면 데이터 변화 가 비교적 빈번 하거나 데이터 가 짧 은 시간 에 한 번 변화 할 것 이 라 고 예상 할 수 있 는 장면 은 짧 은 폴 링 을 사용 할 수 있 습 니 다.예 를 들 어:

사용자 가 PC 에서 물건 을 사서 웹 페이지 를 불 러 일 으 켰 습 니 다.PC 측 과 웹 페이지 측 이 통 하지 않 기 때문에 우 리 는 사용자 가 곧 지불 을 완성 할 것 이 라 고 예상 합 니 다.이 럴 때 간단 한 짧 은 폴 링 을 개발 하기 위해 사용 할 수 있 는 방식 입 니 다.직접 서비스 측 에서 인 터 페 이 스 를 제공 하여 고객 측 에 주문 상 태 를 알려 주 고 클 라 이언 트 는 5 초 에 한 번 씩 요청 하면 됩 니 다.결 과 를 얻 으 면 부탁 하지 않 아 도 됩 니 다.
짧 은 폴 링 을 사용 하려 면 요청 횟수 상한 선 에 대한 통 제 를 잘 해 야 합 니 다.예 를 들 어 100 번 을 요청 해도 사용자 의 지불 이 감지 되 지 않 았 습 니 다.'지불 을 완료 한 후에 제 주문 페이지 에 가서 조회 하 세 요'라 고 창 을 열 면 요청 하지 않 아 도 됩 니 다.
긴 폴 링
긴 폴 링 은 다른 실시 간 으로 데 이 터 를 얻 는 방식 입 니 다.절 차 를 보 세 요.

본질 적 으로 변화 가 없 는 것 은 클 라 이언 트 가 자신 이 원 하 는 데 이 터 를 받 지 못 한 상황 에서 계속 서버 에 요청 을 보 내 는 것 이다.차이 점 은 서버 가 요청 을 받 으 면 직접 응답 하지 않 고 요청 을 끊 는 것 이다.자신 이 정 해진 시간 에 데이터 의 변 화 를 판단 하고 변화 가 있 으 면 바로 클 라 이언 트 에 게 돌아 가 시간 이 초 과 될 때 까지 기다 리 지 않 는 다 는 것 이다.
긴 폴 링 의 장점 은 클 라 이언 트 의 요청 이 불필요 한 클 라 이언 트 요청 을 피 할 수 있다 는 것 이다.단점 은 서버 가 대량의 요청 을 걸 어 자원 소 모 를 증가 시 키 고 서버 가 HTTP 요청 의 병행 수량 에 제한 이 있다 는 것 이다.
위 챗 홈 페이지 판 의 로그 인 은 전형 적 인 긴 폴 링 의 예 이다.

그림 에서 볼 때 클 라 이언 트 가 서버 에 계속 요청 을 보 내 고 서버 가 첫 번 째 로 응답 을 하지 않 아서 클 라 이언 트 가 기다 리 고 시간 이 초 과 된 상황 에서 계속 요청 을 보 냅 니 다.
전체적으로 말 하면 저 는 보통 긴 폴 링 을 사용 하 는 것 이 더 많다 는 것 을 이해 합 니 다.짧 은 폴 링 은 프로 그래 밍 이 간단 하고 소형 응용 에 적합 합 니 다.위 챗 홈 페이지 에 로그 인 하 는 것 처럼 수천 명의 사용자 가 동시에 로그 인 합 니 다.한 동안 서버 에서 수천 개의 요청 을 받 아 처리 하 는 것 이 어디 에 견 딜 수 있 습 니까?모든 서버 에서 처리 요청 의 수량 을 분담 하 는 것 은 결코 문 제 를 해결 하 는 방법 이 아 닙 니 다.
WebSocket
위 에서 두 가지 폴 링 방식 을 소 개 했 지만 두 가 지 를 종합 하면 비교적 뚜렷 한 단점 이 있 고 정리 해 보면 다음 과 같은 몇 가지 가 있다.
4.567917.가짜 실시 간,즉 상기 두 가지 방식 은 모두 진정한 실시 간 이 아니다.짧 은 폴 링 의 클 라 이언 트 폴 링 시간 이 아무리 짧 든 긴 폴 링 의 서비스 측 폴 링 시간 이 아무리 짧 든 어느 정도 지연 시간 이 존재 한다4.567917.모든 폴 링 은 필요 한 데이터 가 돌아 오지 않 으 면 자원 을 계산 하 는 낭비 이다

HTTP 프로 토 콜 자 체 는 중요 한 프로 토 콜 입 니 다.매번 에 HTTP 첫 번 째+HTTP 머리 를 가 져 야 합 니 다.실제로 우리 에 게 필요 한 것 은 HTTP Body 일 뿐 입 니 다.불필요 한 데 이 터 는 대역 폭 에 대한 낭비 입 니 다

따라서 우리 가 할 수 있 는 가장 좋 은 일 은 클 라 이언 트 와 서버 사이 에 통로 가 있 고 서버 데이터 가 변화 할 때 서버 가 자발적으로 클 라 이언 트 에 게 전달 할 수 있다 는 것 이다.웹 소켓 은 HTML 5 이후 이 를 위해 탄생 한 프로 토 콜 로 새로운 프로 토 콜 이지 만 HTTP 프로 토 콜 에 기반 한 것 이다.
웹 소켓 의 원 리 를 보 세 요.간단 합 니 다.

웹 소켓 클 라 이언 트 는 먼저 HTTP 프로 토 콜 을 통 해 몇 개의 특별한 header 를 서버 에 보 내 서 서버 에 현재 내 가 HTTP 요청 을 하고 있 지만 웹 소켓 으로 업그레이드 해 야 한다 고 알려 줍 니 다.

Upgrade:websocket

Connection：Upgrade

Sec-WebSocket-Key: XXX

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: XX

서버 가 웹 소켓 프로 토 콜(Tomcat 7,Jetty 7 이후 모두 웹 소켓 을 지원 합 니 다)을 지원 하면 서버 에서 요청 을 받 고 연결 이 성공 하면 Sec-webSocket-Accept,Sec-webSocket-protocol 이라는 두 헤 더 를 클 라 이언 트 에 게 되 돌려 줍 니 다.또한 Http Status 는 101 로 전환 에 성 공 했 음 을 표시 합 니 다.그러면 클 라 이언 트 와 서버 는 어느 한 측 이 연결 을 끊 지 않 으 면이 통 로 를 바탕 으로 통신 할 수 있다.
다시 한 번 말씀 드 리 겠 습 니 다.HTTP Header 가 871 바이트 라 고 가정 한 테스트 가 있 습 니 다.WebSocket 은 데이터 전송 이 프레임 기반 이기 때문에 프레임 전송 이 더욱 효율 적 이 고 장단 폴 링 에 비해 2 개의 바이트 가 871 바이트 의 Header 를 대체 할 수 있 습 니 다.테스트 결 과 는 다음 과 같 습 니 다.

같은 초당 클 라 이언 트 폴 링 횟수 는 10W/s 의 고주파 횟수 에 달 할 때 폴 링 은 665 Mbps 를 소모 해 야 하 는데 웹 소켓 은 1.526Mbps 로 435 배 에 가깝다.
WebSocket 은 진정한 실시 간 을 실현 하고 대역 폭 자원 을 대량으로 절약 했다.그러나 저 는 자신의 문제 도 있 습 니 다.바로 개발 원가 가 비교적 높다 는 것 입 니 다.이곳 의 개발 원 가 는 자신 이 WebSocket 을 실현 하 는 것 이 아니 라 자바 언어 차원 에서 Netty-Socketio 를 직접 사용 하면 됩 니 다.API 는 간단 하고 WebSocket 에 대한 완전한 실현 을 제공 합 니 다.진정한 개발 원 가 는 분포 식 환경 에서 의 데이터 동기 화 문제 에 있다.
예 를 들 어 온라인 채 팅 시스템 10W 인 이 동시에 온라인 에 있 는데 이때 한 사용자 가 1K 음성 메 시 지 를 보 냈 다.한 컴퓨터 로 10W 의 연결 을 유지 하면 되 지만(여 기 는 HTTP 요청 이 아니 기 때문에 연결 풀 수의 영향 을 받 지 않 는 다)문 제 는 대역 폭 이다.단일 컴퓨터 는 10W 사용자 에 게 1K 음성 메 시 지 를 동시에 전송 하 는데 필요 한 대역 폭 은 최소 10M 이다.이것 은 단순히 데 이 터 를 전송 하 는 것 일 뿐 데이터 가 들 어 오 는 장면 을 고려 하지 않 고 실제 운행 과정 에서 필요 한 대역 폭 이 더 많아 기업 에 있어 매우 큰 비용 이다.
따라서 대량으로 연 결 된 장면 에서 모두 클 러 스 터(실제 적 으로 대량의 연결 이 없 더 라 도 높 은 가용성 을 위해 클 러 스 터 를 할 수 있다)를 한다.10W 는 5 대의 기 계 를 동시에 나 누 어 주 고 모든 기 계 는 2W 로 연결 되 며 클 러 스 터 에서 발생 하 는 문 제 를 고려한다.

클 라 이언 트 1 은 데 이 터 를 서버 1,서버 1 에 연 결 된 모든 클 라 이언 트 가 이 음성 을 푸 시 할 수 있 지만 문 제 는:
4.567917.서버 2~서버 5 중대 의 모든 클 라 이언 트 는 어떻게 데 이 터 를 얻 습 니까?간단 한 방법 은 메시지 큐 를 사용 하여 모든 구독 서버 에 데 이 터 를 메시지 큐 를 통 해 보 내 는 것 입 니 다

그러면 1M 그림 을 전송 하면 데이터 가 너무 커서 메시지 큐 를 사용 하기에 적합 하지 않 습 니 다.어떻게 해 야 합 니까?먼저 데 이 터 를 저장 할 수 있 습 니 다.메시지 큐 는 id 만 보 내 고 메 시 지 를 받 은 서버 는 id 에 따라 실제 데 이 터 를 찾 아 푸 시 할 수 있 습 니 다

4.567917.메시지 큐 에 의존 하면 응용 에 대해 코드 개발 을 해 야 할 뿐만 아니 라 메시지 서버 에 분포 식 클 러 스 터 를 하고 압력 테스트 를 하여 높 은 사용 가능성 을 확보 해 야 한다

2W 연결 이 정상적으로 1K 메 시 지 를 보 낼 것 으로 예상 되 는 것 은 문제 가 없 지만 만약 에 사용자 가 1M 사진 을 보 내 서 예상 대역 폭 을 초과 하면 어 떡 합 니까?업무 상 취사선택 으로 XXX 를 초과 한 데 이 터 를 보 내지 못 하 는 것 입 니까?아니면 기술적 으로 처리 하 는 것 입 니까?

다른 고려 해 야 할 문제 들 이 너무 많이 열거 되 지 않 았 다.한 마디 로 하면 웹 소켓 으로 대량의 요청 과 높 은 병행 장면 에서 코드 개발 비용 이 매우 높다.그러나 웹 소켓 은 진정한 실시 간 서버 에서 클 라 이언 트 의 데 이 터 를 전송 하고 대역 폭 자원 을 대량으로 절약 할 수 있 기 때문에 많은 IM,음성 영상,탄막 등 응용 프로그램 이 웹 소켓 을 사용한다.
총결산
이상 은 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 참고 학습 가치 가 있 기 를 바 랍 니 다.궁금 한 점 이 있 으 시 면 댓 글 을 남 겨 주 셔 서 저희 에 대한 지지 에 감 사 드 립 니 다.