모바일 네트워킹 기술을 사용할 수없는 지역에서 인터넷에 액세스하는 데 점점 더 많이 사용되고 있습니다.
모바일 네트워킹은 일반적으로 기본 인터넷 연결로 아직 실행 가능하지 않지만 모바일 기술은 비상 폴백에 적합한 옵션처럼 보입니다.
Bandwith는 문제가되지 않습니다 : HDSPA를 사용하면 몇 MBit의 속도가 가능하여 적절한 업 링크를 제공합니다. 그러나 개인 경험으로는 GPRS, UMTS 등을 통한 모바일 네트워크 인터넷 링크가 일반 DSL (UMTS의 경우 200-400ms, GPRS의 경우 훨씬 더 큼)보다 대기 시간이 훨씬 깁니다. 물론 VoIP 및 전화 회의와 같은 많은 응용 프로그램에는 적합하지 않습니다.
- 이 대기 시간은 어디에서 발생합니까?
- 지연 시간이 짧은 응용 프로그램에 UMTS를 사용할 수 있도록이 문제를 완화 할 수있는 기술이 있습니까?
본질적인 기술적 이유가 있다고 가정하지만 그 이유는 무엇입니까? 데이터가 무선으로 전송되는 방식과 관련이 있습니까? 무선 전송으로 인해 WLAN이 대기 시간이 훨씬 짧은 이유는 무엇입니까?
답변
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 요청 흐름 지연
- 제어 평면 대기 시간 : RRC 협상 및 상태 전환에 발생하는 고정 된 일회성 대기 시간 비용 : 유휴 상태에서 활성 상태 인 경우 <100ms, 휴면 상태에서 활성 상태 인 경우 <50ms
- 사용자 평면 대기 시간 : 장치와 라디오 타워간에 전송되는 모든 응용 프로그램 패킷의 고정 비용 : <5 ms.
- 핵심 네트워크 대기 시간 : 무선 타워에서 패킷 게이트웨이로 패킷을 전송하기위한 캐리어에 따른 비용 : 실제로는 30–100 ms.
- 인터넷 라우팅 대기 시간 : 네트워크 사업자의 패킷 게이트웨이와 공용 인터넷의 대상 주소 사이의 가변 대기 시간 비용.
실제로, 배치 된 많은 4G 네트워크의 종단 간 대기 시간은 일단 장치가 연결 상태가되면 30–100ms 범위에있는 경향이 있습니다.
따라서 하나의 요청 (그림 8-2. “단순”HTTP 요청의 구성 요소)이 있습니다.
- RRC 협상 50-2500 ms
- DNS 조회 1 RTT
- TCP 핸드 셰이크 1 RTT (기존 연결) 또는 3 RTT (새 연결)
- TLS 핸드 셰이크 1-2 RTT
- 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가 후원하는 모든 사람이 책 전체를 무료로 읽을 수있는 옵션이 있습니다 . 이 책은 웹 사이트를 개발하는 사람들에게만 권장되는 것이 아니라 일부 네트워크를 통해 클라이언트에게 바이트를 제공하는 모든 사람에게 유용합니다.
답변
“셀룰러 광대역”기술을 사용할 때 발생할 수있는 많은 대기 시간이 여러 가지 문제의 복합적인 문제라고 생각합니다.
거리는 있지만 syneticon-dj가 언급했듯이 실제로 왕복 시간의 아주 작은 비율입니다.
고려해야 할 사항은 다음과 같습니다. 고객 (특히 가정 또는 소규모 비즈니스 고객)으로서 경험하는 지연은 적어도 어느 정도 인위적으로 유발 될 수 있습니다. SCADA 등을위한 M2M 활용을위한 3G 및 GSM 통신 클래스가 있으며, 때로는 더 큰 신뢰성과 낮은 대기 시간 전송을 제공 할 수 있습니다. 결과적으로 일반적으로 엄청나게 비쌉니다.
기본적으로 트래픽 조정에 반대합니다. ISP / Telco가 더 나은 유료 고객의 우선 순위를 정하기 위해 수행하고 있거나 연결된 셀이 약간 바쁘거나 전체 네트워크가 약간 느립니다 (2012 년 1 월 1 일 00:00 GMT 시도). 예).
그러나이 모든 것을 둘러싼 방법이 있습니다.하지만 조금 교묘합니다. 트래픽이 모바일 WWAN을 향하기 전에 기본적으로 TCP 연결 프록시가 필요합니다. ISP의 트래픽 조절에 의해 실제 ACK가 지연 될 수 있으므로이 프록시는 본질적으로 스푸핑 된 ACK를 응용 프로그램에 보냅니다.
분명히 모호하지만 많은 위성 제공 업체가이 메커니즘을 사용하여 지연 시간을 실제보다 낮게 보이게합니다.
답변
게임에 늦었지만, 다음 주제에 관한 퍼포먼스 캘린더 기사를 확인하고 싶을 것입니다 :
http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-link/
tl; dr-모바일 대기 시간의 주요 부분은 백홀에서 라우팅이 최적화되지 않았기 때문입니다.
답변
휴대 전화 모뎀 기술은 야외 통신의 특성으로 인해 대기 시간이 길어집니다. WLAN 전송 거리는 일반적으로 언급 한 다른 기술보다 훨씬 짧기 때문에 대기 시간이 단축되는 한 가지 이유입니다.