무선 연결을 통해 소켓이 어떻게 작동합니까?

나는 안드로이드를 사용하는 클라이언트 측 (특히 모바일) 응용 프로그램에서만 일했습니다. 모든 네트워킹은 HttpUrlConnection과 같은 프레임 워크 제공 구성 요소를 사용하여 HTTP 계층에서 처리됩니다.

그러나 Websockets / XMPP 등과 같은 푸시 메시징 시스템은 모두 서버와의 지속적인 연결을 유지합니다. Google Play 지원 기기로 구워진 Google의 GCM조차도 서버와의 지속적인 연결을 유지합니다.

내 질문은 배터리를 소모하지 않고 어떻게 작동합니까? 연속적인 HTTP 요청을 순차적으로 수행하면 배터리가 많이 소모됩니다. 이러한 지속적인 연결은 동일한 문제가 발생하지 않고 어떻게 유지됩니까?

열린 TCP 연결은 논리적 상태입니다. 데이터가 항상 앞뒤로 전송되는 것은 아닙니다. 최초의 3 방향 핸드 셰이크 후에 "연결됨"상태가되었습니다. 3 방향 연결 해제가 발생하거나 연결 유지가 실패 할 때까지 해당 상태에 있습니다.

연결 수명 동안 기본 "물리적"매체의 리소스를 설정하여 해당 연결에 대한 데이터 전송을 수행 할 수 있습니다. 유선 연결의 경우 이더넷 프레임을 주변으로 전송해야합니다. 3G / 4G 무선 연결의 경우 필요에 따라 하위 수준의 프로토콜로 연결하여 설정합니다.

따라서 연결 수명 동안 물리적 인 기본 데이터 연결이 존재하지 않습니다. 대신 TCP 연결의 피어 중 하나가 데이터를 보내야 할 때까지 대기하는 것이 휴면 상태입니다.

또 다른 문제는 TCP가 ack 기반이라는 것입니다. TCP 피어는 확실히 수신 된 내용을 서로 효율적으로 파악할 수 있습니다. 실패하면 TCP가 재전송됩니다. 이것은 상당히 안정적인 물리적 링크에는 효과적이지만 무선 연결과 같이 잡음이 많거나 끊어진 링크에서는 분리되는 경향이 있습니다. 아시다시피, 이러한 환경에서 acks / retransmission은 매우 자주 발생합니다.

따라서 일반적으로 기본 무선 프로토콜은 TCP 재전송의 필요성을 줄이기 위해 가능한 모든 작업을 수행합니다. 예를 들어, 무선 계층에는 많은 오류 검사 기능이 내장되어 있습니다. 무선 영역 (기지국 / 전화기)의 피어도 상대방에게 무언가 를 받지 못했을 때 나크 기반 프로토콜을 사용합니다 . 되고 NAK 기반 (다른 측면이 있지라고하지 않는 한 우리가 모든 것을 잘 가정) 오류를 검사의 오버 헤드를 줄일 수 있습니다. 또한 전에 오류 를 해결하는 데 도움이됩니다.TCP 계층으로 버블 링되므로 재전송을 시도하는 많은 TCP 스 래싱을 피할 수 있습니다. 또한, 무선 피어로의 재전송 범위가 줄어 듭니다. 전화기는 인터넷상의 서버에게 다시 무선 링크를 통한 기지국을 요구할 필요가 없습니다.