오래된 SW 엔지니어의 평생 공부

고성능 브라우저 네트워킹: 무선 네트워크 개요

유비쿼터스 환경이 급성장하며, 언제 어디서나 온라인 서비스를 이용할 수 있는 시대가 되었다. 이에 따라 무선 네트워크의 중요성도 커졌으며, 현재 사용되는 무선 기술만 해도 WiFi, Bluetooth, ZigBee, NFC, WiMAX, LTE, HSPA, 위성 서비스 등 다양하다.

무선 네트워크의 기본 원리와 성능 결정 요소

무선 네트워크는 유선 네트워크와는 다르게 공유 매체(전파)* 사용하며, 다음과 같은 요소들에 의해 성능이 결정된다. 

1. 대역폭(Bandwidth): 주파수 범위가 넓을수록 전송 속도가 증가한다. 예를 들어, WiFi 802.11n은 40MHz 대역폭을 사용하여 더 빠른 속도를 구현했다.
2. 신호 대 잡음비(SNR): 신호의 세기와 잡음의 비율로, 방해 전파가 많을수록 성능이 저하된다.
3. 변조(Modulation): 디지털 데이터를 아날로그 신호로 변환하는 방법으로, SNR과 기기의 처리 능력에 영향을 받는다.

특히, 샤논의 법칙은 정보 전송량이 대역폭과 신호 대 잡음 비로 결정된다는 것을 보여 준다. 특히, 변조에 따른 정보 효율이 달라 질 수 있다.

무선 네트워크의 종류와 사용처

• PAN (Personal Area Network): Bluetooth, ZigBee, NFC를 사용하여 개인 기기간 연결.
• LAN (Local Area Network): WiFi를 사용해 건물 내 네트워크 확장.
• MAN (Metropolitan Area Network): WiMAX 등으로 도시 네트워크 연결.
• WAN (Wide Area Network): LTE, 위성 서비스 등을 통해 전 세계 연결.

무선 통신 성능 최적화의 중요성

무선 네트워크는 공유 매체 특성상 방해 전파의 영향을 많이 받고, 전송 전력, 변조 방식, 송수신 거리 등 여러 요소에 의해 성능이 좌우된다.

• 셀 호흡(Cell-breathing): 주변 방해 신호가 많을수록 통신 가능 거리가 줄어든다.
• 근거리/원거리 문제(Near-far Problem): 강한 신호가 약한 신호를 밀어내는 현상.

실제 무선 네트워크 성능 측정과 고려사항

무선 네트워크의 성능은 위치, 방해 전파, 송수신 거리 등에 따라 변화무쌍하다.

• 이상적인 환경: 최대 대역폭, 낮은 잡음, 효율적인 변조 방식 사용 시 최적의 성능.
• 실제 환경: 사용자의 위치와 주변 환경에 따라 성능이 크게 달라집니다.

결론 및 전망

무선 네트워크는 편리성과 이동성을 제공하지만, 잡음, 방해 신호, 대역폭 한계 등 여러 제약이 존재합니다. 앞으로 더 빠르고 안정적인 무선 통신을 위해 5G, WiFi 6 등 차세대 기술이 도입될 것이다.

참고 자료

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

TLS의 개념 및 역할

• TLS(Transport Layer Security)는 데이터 암호화, 인증, 무결성을 제공하여 안전한 통신 환경을 조성.
• 초기 SSL 프로토콜에서 발전된 것으로, TCP 위에서 작동하여 HTTP, 이메일 등 애플리케이션의 보안을 강화.

TLS의 작동 원리

• 핸드셰이크 과정: 클라이언트와 서버가 암호화 방식과 키를 협상하여 안전한 터널을 생성.
• 암호화: 대칭키 암호화를 통해 효율적이고 안전한 데이터 전송.
• 인증: 신뢰 사슬을 기반으로 클라이언트와 서버의 신원을 확인.

최적화 기법

• 세션 재개: TLS 핸드셰이크 과정에서 발생하는 레이턴시를 줄이기 위해 세션 캐시나 세션 티켓을 활용.
• TLS 레코드 크기 조정: 레코드 크기를 TCP MSS(Maximum Segment Size)에 맞춰 설정해 효율적 데이터 전송.
• 조기 종료: CDN(콘텐츠 전송 네트워크)나 프록시 서버를 활용해 클라이언트와 가까운 서버에서 세션을 종료해 레이턴시 최소화.
• 압축 비활성화: TLS 레벨에서의 압축은 보안 문제(CRIME 공격) 및 이중 압축 문제로 인해 비활성화 권장.

TLS 관련 최신 기술

• ALPN (Application-Layer Protocol Negotiation): 핸드셰이크 과정에서 애플리케이션 프로토콜 협상을 포함시켜 추가 레이턴시를 줄임.
• SNI(Server Name Indication): 하나의 서버에서 여러 도메인을 운영할 때 필요한 확장.

실무에서의 TLS 활용

• 최신 OpenSSL 및 TLS 버전 사용으로 성능 최적화.
• 인증서 길이 최소화 및 중간 인증서 포함으로 불필요한 레이턴시 방지.
• TLS를 지원하지 않는 구형 클라이언트를 고려해 세션 캐시와 세션 티켓을 병행 사용하는 것이 권장됨.

참고 자료

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

UDP의 특성 및 역할

• UDP는 단순하고 신뢰성을 제공하지 않는 프로토콜로, 데이터그램 방식으로 작동하며 TCP와 달리 연결 상태를 유지하지 않는다.
• 빠르고 효율적인 데이터 전송을 위해 설계되었지만, 재전송, 흐름 제어, 오류 검출 등의 기능은 지원하지 않는다.

UDP의 주요 활용 사례:

• DNS와 같은 간단한 데이터 전송 프로세스에 사용되며, WebRTC와 같은 실시간 통신에서 필수적으로 활용된다.
• UDP는 음성 및 화상 통화, P2P 통신 등 지연 시간이 중요한 애플리케이션에서 적합하다.

NAT(Network Address Translation):

NAT는 IPv4 주소의 부족 문제를 해결하기 위해 개발된 기술로, 로컬 네트워크의 사설 IP 주소를 공용 IP 주소로 변환하여 인터넷 통신이 가능하도록 한다. 이 기술은 특히 라우터에서 사용되며, 내부 네트워크와 외부 네트워크 간의 트래픽을 중계하고 IP 주소를 변환한다.

동작 방식: NAT 기기는 내부 네트워크의 사설 IP 주소와 포트를 외부의 공용 IP 주소와 포트로 변환하여 인터넷에 데이터를 전송하고, 반대로 외부에서 들어오는 패킷의 공용 IP와 포트를 내부의 사설 IP와 포트로 변환한다.
예시: 내부 클라이언트 192.168.0.1:1337이 공용 IP 50.76.44.114:31454로 변환되어 인터넷과 통신. NAT는 IP 주소 부족 문제를 완화하고 내부 네트워크를 외부로부터 보호하는 데 기여했으나, 이로 인해 외부에서 기기가 보이지 않는 것과 같은 새로운 문제들이 발생한다.

NAT 문제 해결:

• UDP와 NAT 간의 문제는 STUN, TURN, ICE 등의 기술을 통해 해결할 수 있다.
• STUN은 공용 IP와 포트를 확인하고, TURN은 UDP가 차단될 때 TCP로 전환하며, ICE는 가장 효율적인 경로를 찾아 연결다.

STUN(Session Traversal Utilities for NAT), TURN(Traversal Using Relays around NAT), ICE(Interactive Connectivity Establishment)의 특징과 역할을 기반으로 표를 정리하면 다음과 같다:

주요 활용 시나리오

• STUN: 클라이언트가 NAT 뒤에 있을 때 공용 IP와 포트 정보를 알아내는 데 사용.
• TURN: STUN을 사용할 수 없거나 NAT 및 방화벽이 UDP를 차단하는 경우 데이터 중계.
• ICE: P2P 애플리케이션에서 최적의 연결 경로를 찾기 위해 STUN, TURN을 조합.

UDP 최적화 및 권장 사항:

• UDP 기반 애플리케이션은 데이터 전송률 조절, 혼잡 제어, 패킷 재전송 등의 메커니즘을 별도로 구현해야 한다.
• RFC 5405에 따르면, UDP 애플리케이션은 인터넷 경로 상황에 유연하게 대응하고, 최소한의 연결 유지 기능을 설계해야 한다.

이 글을 통해 UDP의 기본 개념과 특징, 그리고 이를 최적화하고 활용하는 방법에 대해 이해할 수 있다. UDP는 단순하지만 강력한 전송 프로토콜로, 효율적인 네트워킹과 실시간 데이터 전송에 적합한 선택지가 될 수 있다.

참고문헌

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

[2] https://docs.google.com/presentation/d/1ZgF4MQ-7BBS92Zlz3mB52APRmyoSyaXprwltw5y3VJg/edit#slide=id.p9

TCP와 IP의 개요

• 인터넷의 중심은 TCP(전송 제어 프로토콜)와 IP(인터넷 프로토콜)로 이루어진다.
• TCP는 신뢰성을 보장하며, 데이터 전송 순서 확인, 데이터 재전송 등을 처리한다.
• TCP는 HTTP 표준의 기본 전송 프로토콜로 활용된다.

TCP의 핵심 메커니즘

3-Way 핸드셰이크:

• 연결 성립 전 클라이언트와 서버 간 초기화 절차.
• 왕복 레이턴시가 연결 성능에 영향을 미친다

느린 시작(Slow-Start):

• 새로운 연결에서 데이터 전송 속도를 점진적으로 증가시킨다.
• 초기 처리량이 제한되며, 대규모 데이터를 처리하는 경우 더 큰 영향을 미친다.

TCP Fast Open:

• 구글이 개발한 최적화 기법으로 초기 핸드셰이크 레이턴시를 줄인다.
• SYN 패킷에서 데이터 전송 가능
• HTTP 트랜잭션 속도를 약 10~40%까지 개선.

혼잡 제어(Congestion Control) vs 흐름 제어(Flow Control):

혼잡 회피(Congestion Avoidance) 

• 패킷 손실을 피드백으로 사용하여 혼잡 윈도를 패킷 손실이 발생할 때까지 증사 시킴
• 알고리즘 종류
  • TCP Tahoe and Reno (original implementations) (AIMD)
  • TCP Vegas
  • TCP New Reno
  • TCP BIC
  • TCP CUBIC (default on Linux) or Compound TCP (default on Windows)
    
    

웹 성능 최적화 방법

1. 서버 설정 최적화:
   • 최신 커널 업데이트 및 초기 혼잡 윈도 크기를 10으로 설정.
   • 느린 시작 재시작 기능 비활성화.
2. 네트워크 환경 개선:
   • 서버를 사용자와 가까운 위치에 배치.
   • 기존 TCP 연결을 최대한 재사용.
3. 데이터 전송 최적화:
   • 불필요한 데이터 전송 제거.
   • 전송 데이터를 압축하여 처리량 개선.

결론

TCP는 안정적이고 신뢰할 수 있는 프로토콜로 설계되었지만, 레이턴시가 주요 병목 요인이 될 수 있다. 이를 해결하기 위해 애플리케이션 설계와 서버 설정을 최적화하는 것이 중요하다.

참고 문헌

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

[2] https://docs.google.com/presentation/d/1ZgF4MQ-7BBS92Zlz3mB52APRmyoSyaXprwltw5y3VJg/edit#slide=id.p9

[1]은 웹 성능 최적화에 이야기 하고 있지만, 네트워크를 사용한 성능과 관련된 이론적인 부분을 많이 다루고, 여러 프로토콜에 대해 설명도 잘 되어 있어, 살펴 보고자 한다. 네트워크 성능에 가장 기본적인 지연시간(Latency)와 대역폭(bandwidth, 혹은 troughput)에 대해 이야기 한다.

레이턴시와 대역폭:

레이턴시는 데이터가 출발지에서 도착지까지 이동하는 데 걸리는 시간이다. 대역폭은 네트워크 경로에서 전송 가능한 최대 데이터 용량을 나타낸다. 이 두 요소는 웹 성능 최적화의 핵심 요소로, 서로 상호작용하며 웹 애플리케이션의 속도에 영향을 미친다. 아래 그림에서 볼 수 있듯이 레이턴시는 송신단과 수신단의 거리, 대역폭은 가장 성능이 낮은 링크의 영향이 큰 것을 예상할 수 있다. 

레이턴시의 구성 요소:

• 전파 지연: 신호가 전송 매체를 통해 이동하는 데 걸리는 시간. 예를 들어 광섬유를 거치는 경우 빛의 속도.
• 전송 지연: 패킷이 링크를 통해 전송되는 시간. 전송할 데이터양과 연결하는 링크의 처리량에 따라 달라진다.
• 프로세싱 지연: 라우터 등이 패킷을 처리하는 데 걸리는 시간. 패킷 헤더의 정보를 처리하는데 필요한 시간.
• 큐잉 지연: 패킷이 처리 대기열에서 기다리는 시간. 

이러한 것들이 합쳐져 전체 지연 시간이 된다.

광섬유와 네트워크 속도:

광섬유는 네트워크의 핵심 전송 매체로, 높은 대역폭을 제공하며 장거리 데이터 전송에서 중요한 역할을 한다.
빛의 속도가 빠르지만, 현실적 제약으로 인해 이상적인 속도에 도달하기 어렵다. 네트워크는 기술 발전으로 대역폭은 점차 증가하고 있으나, 레이턴시는 물리적 한계로 인해 큰 개선이 어려운 상황이다. 이를 극복하기 위해 프로토콜 최적화 및 캐싱, 프리페칭 등의 기술을 활용해야 한다. 대표적으로 이러한 상황에서 최적화 전략으로 Content Delivery Network(CDN)와 같은 기술을 활용해 데이터 전송 거리와 레이턴시를 줄이는 방법을 사용하고 있다. 

라스트 마일

인터넷 트래픽의 대부분의 레이턴시는 대륙이나 바다를 건너는 메인 네트워크 구간이 아니라, 집이나 사무실에서 인터넷 서비스 프로바이더(ISP) 네트워크로 연결되는 마지막 구간(최종 몇 킬로미터)에서 발생한다. ISP의 연결 방식, 네트워크 토폴로지, 기술적 제한으로 인해 이 구간에서 지연이 크며, 네트워크 성능의 병목 현상이 자주 발생한다.

참고문서

[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)

[2] https://docs.google.com/presentation/d/1ZgF4MQ-7BBS92Zlz3mB52APRmyoSyaXprwltw5y3VJg/edit#slide=id.p9

Game Streaming 서비스 비교

Game Streaming 서비스가 다양해 지고 있다. [1]에는 최근 Game Streaming 서비스를 비교하고 있다. 이러한 서비스는 스마트 폰과 같은 수신기기에서 서버로 부터 게임 화면을 스트리밍 받아서 지원하는 기술이다. 실재로 WebRTC와 보다 더 짧은 Latency 요구 사항이 요구 된다. 이러한 기술은 대부분 서비스 별로 다르기 때문에 상세 내용이 공개 되어 있지 않다. 하지만, Parsec이라는 기술은 이 상세 내용에 대해서 약간의 정보를 제공하고 있으므로 이를 살펴 보고 특징을 이해할 수 있다.

Parsec 개요

Parsec은 Free Game Software이다. 위에서 설명한 것과 같이 Streaming 방식으로 할 수있게 해준다. 지원이 종료되었지만, 삼성의 PlayGalaxy라는 서비스도 이를 활용한 것이다. [2]에는 Android 및 iOS SDK가 제공된다. Source Code는 제공되지 않는다.

Parsec 기술 설명

Parsec에서는 20ms으로는 아주 훌륭한 게임 경험을 할 수 있지만 40ms만 되어도 사용할 수 없다고 한다. 이는 WebRTC가 1초 미만의 수백 ms의 요구 사항이었다고 보면 이 요구 사항은 이 보다 한단계 더 낮은 Latency를 요구하는 서비스라고 생각할 수 있다.

[3]에서는 Parsec이 동작하는 방식을 설명하고 있다. 

1. Capture raw desktop frames
2. Encode the raw frames
3. Send the encoded frames over the network
4. Decode the frames
5. Render the frames on the screen

1번에서는 Windows 8.1부터 빠른 캡춰를 가능하게 한다고 한다. 2의 경우는 nVidia와 같은 빠른 인코더를 사용해서 성능을 높이고 있다고 한다. 

Codec의 경우는 H.264의 60fps 설정이 저지연으로 동작한다고 한다. 또한 Codec의 인터페이스 사용을 직접하여 지연도 줄인다고 한다.

이렇게 처리된 데이터는 화면에 Rendering되게 되는데, 데이터를 GPU상에서 모두 처리하게 되면 지연이 준다고한다. Memory Copy와 Color coversion등이 효율화 항목 중 하나이다.

네트워크 성능도 중요한데, 아래 그림과 같이 Local에서 하는 것과 Cloud에서 하는것의 성능 차이가 상당히 있다. 5G Network의 Mobile Edge Computing(MEC)를 사용하는 것도 장점이 있을 것이다. 이러한 이유로 xCloud등이 모바일 사업자와 협력하는 것이 이유가 있다고 볼 수 있다.

아래 그림에서와 같이 nVidia와 AMD의 코덱 성능에는 차이가 상당히 있다. 그렇기 때문에 nVidia를 사용하는 것이 Game Streaming에 성능에 차이가 있을 수 있다. 그리고, Encoder쪽의 성능 차이가 중요한 부분일 수 있다고 생각된다.

성능 최적화

nVidia의 코덱을 사용하더라도 설정을 잘 못하면 성능의 차이가 나올 수 있다. [6]에서는 nVidia Codec의 목표에 따른 코덱 최적화 방법을 설명한다. 아래 표가 

상기 테이블의 내용 중 아래 옵션들은 관련된 주요 파라미터 설정에 대한 설명을 포함한다.

-bf set maximum number of B frames between Non B frames (default 0)

-rc-lookahead Number of frames to look ahead for frametype and ratecontrol

-b bitrate video bitrate (pelease use –b:v)

-bufsize set ratecontrol buffer size (in bits)

-g set the group of picture (GOP) size. 999999 is about 44h with 60fps

-maxrate Set maximum bitrate tolerance (in bits/s)

-tune zerolatency

특히, B frame의 사용 여부, bitrate할당 방법의 차이 그리고 GOP 크기등을 통해서 주요한 설정 방법에 대해서도 가늠해 볼 수 있다.

정리하며...

Game Streaming은 이야기 한데로, 표준이 아니면서도 극단적인 스트리밍 요구 사항이 포함되어 있어 매우 흥미롭지만 내용이 많은 내용이 공개 되어 있지 않은 문야이다. 점차 Client의 계산 능력으로는 충분하지 못하고 Cloud에서 힘을 빌려야 하는 응용이 늘어 날 수록 이 기술은 적용 범위가 확대 될 것이므로 기본적인 이해가 필요하다고 생각된다.

참고 자료

[1] Game Streaming 서비스 비교, https://www.clien.net/service/board/lecture/14562043

[2] Parsec SDK; https://github.com/parsec-cloud/parsec-sdk

[3] Parsec Description: https://blog.parsecgaming.com/description-of-parsec-technology-b2738dcc3842

[4] Parsec Introduction to Video Codec, https://blog.parsecgaming.com/an-introduction-to-video-compression-c5061a5d075e

[5] New Nvidia GPUs Outperform New AMD Cards On H.264 Compression Latency, https://blog.parsecgaming.com/new-nvidia-gpus-outperform-new-amd-cards-on-h-264-compression-latency-d32784464b94

[6] Turing H.264 Video Encoding Speed and Quality, https://devblogs.nvidia.com/turing-h264-video-encoding-speed-and-quality/

이 글은 오래전 Wowza에서 발간한 가이드 문서[1]를 살펴 보고 실시간 인터액티브 스트리밍의 구조 관련 내용을 정리하려고 한 것이다. 우선은 일반적인 실시간 연동이라고 하면, Live 방송을 해야 하고, 사용자에게 Interaction을 받아서 이를 처리하여야 한다. 그러므로, 일반적인 Pipeline을 설명하고, 관련된 비디오 스트리밍 프로토콜에 대해서 설명하려 한다.  사용자 인터액션에 대한 처리를 원할히 하기 위해서는 저지연, 즉 Low Latency까지 이야기 되어야 한다.

일반적인 Live Streaming 서비스 구조

우리가 YouTube 혹은 Facebook을 이용하여 라이브 방송하는 구조를 생각할 수 있다. 복잡한 장비를 사용하여 TV 방송 수준 품질의 방송을 하던, 아주 간단하게 휴대폰을 활용하던, 실재 Streaming을 위한 구조는 대동 소이하다.

Live Video Streaming의 경우는, 아래 그림과 같이 First Mile에서는 카메라에서 동영상을 비디오를 촬영하면 이를 전송 가능한 형태로 인코딩한다. 아직까지 일반적으로는 H.264를 많이 사용한다. 이를 처리하기 위한 서버로 전송하는데 아래 그림에서는 Processing 혹은 Ingestion이라고 한다. 이를 위해 전송하는 프로토콜은 RTMP, RTSP/RTP 혹은 SRT를 사용한다고 한다. 

위에서 이야기 한데로 YouTube 혹은 Facebook이 Live 기능을 제공하기 시작하면서 개인 방성 기술에 대해서 여러 접근 법이 있었다. 그리고, 주로 많이 사용되는 것은 한번 상용화가 되기 시작하니 우후 죽순 처럼 RTMP[1] 기술이 주류처럼 나왔지만, 정말 오래된 기술 중 하나인 RTSP/RTP도 사용되고 있다.

처리된 콘텐츠들은 서비스 특징에 따라 전송 방법들을 달리한다. 위의 그림은 YouTube와 같이 많은 사용자들이 볼 수 있는 형태인 DASH 혹은 HLS로 변환하여 Content Delivery Network (CDN)을 통해 배포 하는 사례를 보여 준다.

지연 요구 사항에 따른 Streaming Protocols

아래 그림은 다양한 지연 요구 사항에 따른 Last Mile 처리 Protocol의 사례를 보여 준다. 

처음 이야기 한 것과 같이 HLS, DASH는 일반적으로 많이 사용되고 있다. 많은 비디오 스트리밍 구성들이 캡춰에서 재생까지 30초 이상의 지연(Latency)을 가진다. 쉽게 말하면, YouTube에서 라이브로 보고 있는 내용들인 대부분 30초 전에 일어난 일이라는 것이다.

저지연이면서도 많은 사람들에게 전송하기 위한 Protocol Tuning을 하기 위해서 최적화 작업을 하는 업체들이 많다. 위에 그림에서 볼 수 있듯이 그렇다 하더라도 5초 이상의 지연을 가지게 된다.

이러한 노력에 추가하여, 프로토콜 표준상 최적화를 위해서 Low Latency HLS와 CMAF를 채용한 DASH가 제안되기도 했다. 기본 개념은 HLS/DASH에서 수신하는 작은 조각 (Fragment 혹은 Chunk)라고 불리는 것들을 작게 만들어 수 초대의 지연으로 만들어 일반 방송과 유사한 수준까지 만드는 것이다.

그렇다면, 이보다 낮은 방법은 없는 것인가? Wowza에서는 WebRTC를 제안하고 있다. 하지만, 이는 Peer-To-Peer 방식으로 콘텐트 소비자의 가까운 곳에 Computing Resource를 할당 하는 등 HLS/DASH 기반의 다른 방식에 비해서 비용이 높을 수 있다.

정리

위의 그림 하나로 모두 정리 된다고 볼 수 있지만, 사용자 인터렉션의 요구 사항이 높아지는 가운데, Low Latency HLS 혹은 CMAF를 이용한 DASH까지 가고 있지만, 실재로 서비스의 구성을 잘 고려하지 않으면 원하는 품질을 확보하기 어렵다. 이를 위해서는 실재 컨텐츠의 해상도 품질과 지연 요구 사항을 잘 고려하여 서비스를 고민해야 한다.

참고 문서

[1] Wowza media systems, "Real-Tme Interactive Apps: A Best Practices Guide With The Wowza Streaming Cloud Service", (링크 깨짐) https://www.wowza.com/uploads/images/Real-Time-Interactive-Apps-WSC-2019.pdf

다른 링크

[2] Streaming Protocols: Everything You Need to Know, www.wowza.com/blog/streaming-protocols

[3] 2019 Video Streaming Latency Report, https://www.wowza.com/blog/2019-video-streaming-latency-report