모바일 네트워크에 대기 시간이 긴 이유는 무엇입니까? 어떻게 줄일 수 있습니까?


39

모바일 네트워킹 기술을 사용할 수없는 지역에서 인터넷에 액세스하는 데 점점 더 많이 사용되고 있습니다.

모바일 네트워킹은 일반적으로 기본 인터넷 연결로 아직 실행 가능하지 않지만 모바일 기술은 비상 폴백에 적합한 옵션처럼 보입니다.

Bandwith는 문제가되지 않습니다 : HDSPA를 사용하면 몇 MBit의 속도가 가능하여 적절한 업 링크를 제공합니다. 그러나 개인 경험으로는 GPRS, UMTS 등을 통한 모바일 네트워크 인터넷 링크가 일반 DSL (UMTS의 경우 200-400ms, GPRS의 경우 훨씬 더 큼)보다 대기 시간이 훨씬 깁니다. 물론 VoIP 및 전화 회의와 같은 많은 응용 프로그램에는 적합하지 않습니다.

  • 이 대기 시간은 어디에서 발생합니까?
  • 지연 시간이 짧은 응용 프로그램에 UMTS를 사용할 수 있도록이 문제를 완화 할 수있는 기술이 있습니까?

본질적인 기술적 이유가 있다고 가정하지만 그 이유는 무엇입니까? 데이터가 무선으로 전송되는 방식과 관련이 있습니까? 무선 전송으로 인해 WLAN이 대기 시간이 훨씬 짧은 이유는 무엇입니까?


6
runningamajortelecom.stackexchange.com에 속합니다. ;-)
ceejayoz

모바일 기기 유형, 셀 타워 위치, 신호 장벽 등
DanBig

3
이 질문은 수퍼 유저에게는 적합하지 않습니다. 여기에 속합니다.
resmon6

2
그들은 그것을 극복 할 것이다. 네트워크 엔지니어로서 저는이 질문에 대한 신중한 답변을 기대합니다.
resmon6

답변:


46

Ilya Grigorik의 "고성능 브라우저 네트워킹"책은 바로 이것에 대한 답변입니다. 모바일 네트워크 전용의 전체 챕터 (7)가 있습니다. 이 책은 고성능 문제는 거의 항상 대기 시간과 관련이 있다고 말합니다. 일반적으로 대역폭이 충분하지만 프로토콜이 방해를받습니다. TCP slow start , RRC ( Radio Resource Controller ) 또는 차선 구성으로되어 있습니다. 모바일 네트워크에서만 대기 시간이 길어지면 설계 방식대로 진행됩니다.

이 책에는 일반적인 대기 시간에 대한 표가 있습니다.

표 7-2. 활성 모바일 연결의 데이터 속도 및 대기 시간

세대 | 데이터 전송률 | 지연 시간
2G | 100–400 Kbit / s | 300–1000ms
3G | 0.5–5 Mbit / s | 100–500ms
4G | 1–50 Mbit / s | <100ms

대기 시간과 관련이 있지만 TCP 특성 3 방향 핸드 셰이크 또는 느린 시작은 유선 연결에 동일하게 영향을 미치기 때문에 실제로 질문에 대답하지 않습니다. 모바일 네트워크의 대기 시간에 실제로 영향을 미치는 것은 IP 기반 계층입니다. IP 아래 계층의 대기 시간이 0.5 초인 경우 서버에 대한 TCP 연결은 ~ 1.5 초 (0.5 초 * 3)가 걸리므로 숫자가 매우 빠르게 나타납니다. 앞서 말했듯이 모바일이 유휴 상태가 아니라고 가정합니다. 핸드셋이 유휴 상태 인 경우 먼저 네트워크에 "연결"해야합니다. 즉, 타워와 단순화 된 리소스를 협상해야하고 (간체 화됨) LTE에서 50-100ms, 3G에서 최대 몇 초가 소요됩니다. 이전 네트워크에서.

그림 7-12. LTE 요청 흐름 지연

  1. 제어 평면 대기 시간 : RRC 협상 및 상태 전환에 발생하는 고정 된 일회성 대기 시간 비용 : 유휴 상태에서 활성 상태 인 경우 <100ms, 휴면 상태에서 활성 상태 인 경우 <50ms
  2. 사용자 평면 대기 시간 : 장치와 라디오 타워간에 전송되는 모든 응용 프로그램 패킷의 고정 비용 : <5 ms.
  3. 핵심 네트워크 대기 시간 : 무선 타워에서 패킷 게이트웨이로 패킷을 전송하기위한 캐리어에 따른 비용 : 실제로는 30–100 ms.
  4. 인터넷 라우팅 대기 시간 : 네트워크 사업자의 패킷 게이트웨이와 공용 인터넷의 대상 주소 사이의 가변 대기 시간 비용.

실제로, 배치 된 많은 4G 네트워크의 종단 간 대기 시간은 일단 장치가 연결 상태가되면 30–100ms 범위에있는 경향이 있습니다.

따라서 하나의 요청 (그림 8-2. "단순"HTTP 요청의 구성 요소)이 있습니다.

  1. RRC 협상 50-2500 ms
  2. DNS 조회 1 RTT
  3. TCP 핸드 셰이크 1 RTT (기존 연결) 또는 3 RTT (새 연결)
  4. TLS 핸드 셰이크 1-2 RTT
  5. HTTP 요청 1-n RTT

그리고 실제 데이터로 :

표 8-1. 단일 HTTP 요청의 대기 시간 오버 헤드

                       | 3G | 4G
컨트롤 플레인 | 200–2,500ms | 50–100ms
DNS 조회 | 200ms | 100ms
TCP 핸드 셰이크 | 200ms | 100ms
TLS 핸드 셰이크 | 200–400ms | 100–200ms
HTTP 요청 | 200ms | 100ms
총 대기 시간 오버 헤드 | 200–3500ms | 100 ~ 600ms

또한 모바일 네트워크에서 정상적으로 수행하려는 대화 형 응용 프로그램이있는 경우 Nagle 알고리즘을 비활성화하여 실험 할 수 있습니다 (커널은 여러 개의 작은 패킷을 보내는 대신 데이터가 더 큰 패킷으로 병합되기를 기다립니다). 테스트 방법을 찾으십시오 에 https://stackoverflow.com/a/17843292/869019 .


https://hpbn.co/ 에서 Velocity Conference가 후원하는 모든 사람이 책 전체를 무료로 읽을 수있는 옵션이 있습니다 . 이 책은 웹 사이트를 개발하는 사람들에게만 권장되는 것이 아니라 일부 네트워크를 통해 클라이언트에게 바이트를 제공하는 모든 사람에게 유용합니다.


매우 흥미로운 정보에 감사드립니다. 모든 사람이이 책을 읽을 수있는 것은 아니기 때문에 (답변이 독자적이어야 함) : TCP 느린 시작, 라디오 컨트롤러 및 구성이 대기 시간에 어떻게 기여하는지 조금 더 설명해 주시겠습니까?
sleske

1
방금 책의 조각과 표로 답을 편집 했으므로 독자적으로 유용합니다.
Jorge Nerín

2
자체 참고 사항 : 지연 시간에 대한 또 다른 흥미로운 논문 : Qualcomm의 HSPA 데이터 네트워크 지연 시간 .
sleske 2013

정말 고맙습니다. 원격으로 배포 된 키오스크의 3G 모뎀에서 대기 시간 문제가 발생하는 이유를 상사에게 설명하려고하는데 이것이 공원을 넘어 뜨 렸습니다.
jklemmack

4

"셀룰러 광대역"기술을 사용할 때 발생할 수있는 많은 대기 시간이 여러 가지 문제의 복합적인 문제라고 생각합니다.

거리는 있지만 syneticon-dj가 언급했듯이 실제로 왕복 시간의 아주 작은 비율입니다.

고려해야 할 사항은 다음과 같습니다. 고객 (특히 가정 또는 소규모 비즈니스 고객)으로서 경험하는 지연은 적어도 어느 정도 인위적으로 유발 될 수 있습니다. SCADA 등을위한 M2M 활용을위한 3G 및 GSM 통신 클래스가 있으며, 때로는 더 큰 신뢰성과 낮은 대기 시간 전송을 제공 할 수 있습니다. 결과적으로 일반적으로 엄청나게 비쌉니다.

기본적으로 트래픽 조정에 반대합니다. ISP / Telco가 더 나은 유료 고객의 우선 순위를 정하기 위해 수행하고 있거나 연결된 셀이 약간 바쁘거나 전체 네트워크가 약간 느립니다 (2012 년 1 월 1 일 00:00 GMT 시도). 예).

그러나이 모든 것을 둘러싼 방법이 있습니다.하지만 조금 교묘합니다. 트래픽이 모바일 WWAN을 향하기 전에 기본적으로 TCP 연결 프록시가 필요합니다. ISP의 트래픽 조절에 의해 실제 ACK가 지연 될 수 있으므로이 프록시는 본질적으로 스푸핑 된 ACK를 응용 프로그램에 보냅니다.
분명히 모호하지만 많은 위성 제공 업체가이 메커니즘을 사용하여 지연 시간을 실제보다 낮게 보이게합니다.


tcp 프록시는 흥미로운 아이디어이며 TCP가 사용 가능한 대역폭을 더 잘 활용할 수 있도록 도와줍니다. 그러나 OP가 요구하는 응용 프로그램 유형에는 실제로 도움이되지 않습니다. 연결 대기 시간은 사용자가 볼 수 있습니다. 아마도 Phoebus : e2epi.internet2.edu/phoebus.html 을 TCP 프록시로 사용할 수 있다고 생각합니다 .
Dan Pritts

2

게임에 늦었지만, 다음 주제에 관한 퍼포먼스 캘린더 기사를 확인하고 싶을 것입니다 : http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-link/

tl; dr-모바일 대기 시간의 주요 부분은 백홀에서 라우팅이 최적화되지 않았기 때문입니다.


흥미로운 점. 그러나 이것은 문제의 일부만을 설명합니다. GPRS의 대기 시간은 일반적으로 500-1,000ms입니다. 대륙 전체의 대기 시간은 일반적으로 200-300ms를 넘지 않으므로 매우 낭비적인 라우팅조차도 1,000ms를 제공해서는 안됩니다.
sleske

@sleske GPRS (및 다른 오래된 기술)를 사용하면 대역폭 병목 현상이 발생했다고 생각합니다. 대기열을 시작하기 전에 56kb / s (최대)의 많은 패킷을 넣을 수 있습니다 (잘못되었을 수도 있지만 56kb / s가 초당 약 1500 바이트 프레임을 의미하지는 않습니까?).
r0u1i

백홀은 답이 아닙니다. 적어도 메트로 관점에서. SLA는 8-12ms 범위, MSC / MTSO에 이르는 모든 곳에서 캐리어 이더넷의 백홀 트래픽이 필요합니다. 셀 캐리어가 트래픽을 백본으로 라우팅하는 방법은 비즈니스이지만 일반적인 ISP / 비 셀룰러 트래픽과 다르지 않아야합니다.

1

휴대 전화 모뎀 기술은 야외 통신의 특성으로 인해 대기 시간이 길어집니다. WLAN 전송 거리는 일반적으로 언급 한 다른 기술보다 훨씬 짧기 때문에 대기 시간이 단축되는 한 가지 이유입니다.


6
여기서 거리는 사소한 문제입니다. 공기 중 전파 전파 속도는 진공 (약 300.000km / s)의 광 속도와 거의 비슷하므로 3km 거리에서도 0.02ms의 왕복 지연이 발생합니다.
the-wabbit

2
@ syneticon-dj 타워로의 트립 트립은 셀룰러 네트워크에서 지연의 (작은 부분)에 불과하다는 점에서 부분적으로 정확합니다. 통신 이중화 (실제 세계에서는 무선 링크가 완벽하지 않으며 오류 수정은 본질적으로 지연을 유발 함)가 있습니다. , CO의 음성 또는 데이터 링크에 연결 한 다음, Big Bad Internet에서 제공되는 데이터 연결에 대해 모든 지연이 있다고 가정합니다.
voretaq7

1
충돌 감지 / 충돌 방지 알고리즘과 현재 작동 매개 변수 (전송 속도가 느려서 비트 시간이 증가하여 1-4ms를 고려해야 함)도 추가합니다. 그러나 포괄적 인 답변을 작성하기 위해 UMTS에 대해 충분히 알지 못합니다.
the-wabbit

@ syneticon-dj 좋은 포인트; 저는 CDMA 기술에 관한 논문을 썼습니다. 그러나 그것은 오래 전입니다!
Isaac Butt
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.