출처: https://hpbn.co/webrtc/
Browser APIs and Protocols: WebRTC - High Performance Browser Networking (O'Reilly)
What every web developer must know about mobile networks, protocols, and APIs provided by browser to deliver the best user experience.
hpbn.co
참고: 현대오토에버 3D
https://developers.hyundaimotorgroup.com/blog/540
[디지털 트윈 기술 #2] WebRTC와 디지털 트윈: 웹에서 3D 실시간 환경을 제공하는 방법
스마트 팩토리를 구현하기 위해 적용한 디지털 트윈 기술 중 WebRTC에 관한 내용을 소개드립니다!
developers.hyundaimotorgroup.com
[18장 WebRTC]
1. WebRTC의 표준화와 개발
2. 오디오 및 비디오 엔진
3. 실시간 네트워크 전송 기술
4. 피어 간 연결 설정
5. 미디어 및 애플리케이션 데이터 전달
6. DataChannel
7. WebRTC 활용 사례 및 성능
8. 성능 점검 체크리스트
18장 WebRTC
- WebRTC는 실시간 통신을 가능하게 하는 표준, 프로토콜, JavaScript API의 집합
=> 브라우저 간(피어 간) 오디오, 비디오, 데이터 공유를 가능하게 함
=> 제3자 플러그인이나 독점 소프트웨어 필요없이 단순한 JavaScript API만으로 기능
- 고품질의 실시간 통신 애플리케이션 구현 위한 브라우저의 기능 지원
=> 브라우저가 추상화한 3가지 주요 API
1) MediaStream: 오디오 및 비디오 스트림 획득
2) RTCPeerConnection: 오디오 및 비디오 데이터 전송
3) RTCDataChannel: 임의 데이터 전송
- 실제로는 API만이 아닌 시그널링, 피어 탐색, 연결 협상, 보안, 다양한 프로토콜 계층 등이 필요
=> WebRTC의 아키텍처와 프로토콜은 연결 설정 지연, 프로토콜 오버헤드, 전송 방식 등의 성능 특성에 직접적인 영향
=> 일반적인 브라우저 통신과 달리 WebRTC는 데이터를 UDP 위에서 전송
1. WebRTC의 표준화와 개발
- WebRTC 아키텍처 표준
=> 애플리케이션과 브라우저 API뿐만 아니라 다양한 프로토콜과 데이터 형식을 포함한 수십 개의 표준 으로 구성
1) Web Real-Time Communications (WEBRTC): W3C 워킹 그룹은 브라우저 API 정의를 담당
2) Real-Time Communication in Web-browsers (RTCWEB) :IETF 워킹 그룹은 브라우저 내 피어 간 통신을 위한 프로토콜, 데이터 형식, 보안 등 모든 필수 요소를 정의
2. 오디오 및 비디오 엔진
- 브라우저에서 풍부한 화상 회의 경험을 제공하기 위해서는
1) 브라우저가 시스템 하드웨어에 접근하여 오디오와 비디오를 직접 캡처할 수 있어야 함
=> 로우 오디오/비디오 스트림만으로는 충분하지 않음
=> 각 스트림은 품질 향상, 동기화가 필요하며, 클라이언트 간의 변동하는 네트워크 대역폭과 지연 시간에 따라 비트레이트를 조정해야 함
2) 수신 측에서는
=> 클라이언트는 스트림을 실시간으로 디코딩하고 네트워크 지터(jitter - 지연시간에서의 변동성)와 지연(delay)에 유연하게 적응해야 함
- WebRTC는 완전한 기능을 갖춘 오디오 및 비디오 엔진을 브라우저에 제공
=> 신호 처리 작업을 자동으로 수행
* 브라우저가 오디오/비디오 스트림과 네트워크 상태의 변화를 감지하여 실시간으로 처리 파이프라인을 조정
=> 이후 애플리케이션은 최적화된 미디어 스트림을 받아서 로컬 출력, 피어에게 전송, 또는 HTML5 미디어 API로 후처리
1) 오디오 엔진
=> 캡처된 오디오 스트림은 노이즈 감소 및 에코 제거를 위해 처리되고, 최적화된 좁은 대역(narrowband) 또는 넓은 대역(wideband) 오디오 코덱 중 하나로 자동 인코딩됨
=> 네트워크 지터나 패킷 손실의 부정적인 영향을 숨기기 위한 에러 은폐 알고리즘이 적용됨
2) 비디오 엔진
=> 이미지 품질을 최적화하고, 최적의 압축 및 코덱 설정을 선택하며, 지터와 패킷 손실을 숨기기 위한 처리를 수행
- getUserMedia로 오디오와 비디오 가져오기
- Media Capture API
=> W3C의 Media Capture and Streams 명세
=> 오디오 및 비디오 스트림을 요청하고, 획득한 미디어를 처리하거나 조작할 수 있는 새로운 JavaScript API들을 정의
=> 하나 이상의 MediaStreamTrack으로 구성되어 있는 MediaStream 객체를 중심으로 구현
* MediaStream 객체는 실시간 미디어 스트림으로 데이터 획득, 트랙 조작, 출력 지정을 코드로 제어함
- 제공되는 API를 사용하면 각 트랙을 조작, 복제, 제약 조건 수정 등이 가능
=> getUserMedia(): 플랫폼에서 오디오 및 비디오 스트림을 획득하는 간단한 API 예시
* 획득된 스트림은 아래의 다양한 브라우저 API로 전달할 수 있음
1) Web Audio API: 브라우저 내 오디오 처리
2) Canvas API: 비디오 프레임 캡처 및 후처리
3) CSS3/WebGL: 2D/3D 시각 효과 적용
3. 실시간 네트워크 전송 기술
- 실시간 통신은 시간에 민감
=> 오디오 및 비디오 스트리밍 애플리케이션은 간헐적인 패킷 손실을 견디도록 설계 됨
=> 코덱은 소량의 데이터 손실을 자체적으로 보완할 수 있으며, 출력 품질에 미치는 영향은 미미한 경우가 많음
- 실시간 데이터 전송에서는 신뢰성보다 시간 민감성이 더 중요
=> TCP가 아닌 UDP가 선호됨
* TCP는 신뢰성과 순서를 보장하지만, 중간 패킷이 유실되면 재전송을 기다리느라 전체 전송이 지연됨
* UDP는 신뢰성이나 순서 보장을 하지 않으며, 수신된 패킷을 즉시 애플리케이션에 전달
- WebRTC는 전송 계층에서 UDP를 사용
=> 지연과 타이밍이 중요
=> NAT와 방화벽을 통과하기 위한 절차, 스트림 협상, 데이터 암호화, 혼잡 제어 및 흐름 제어 등의 추가 기능이 필요
- WebRTC의 모든 요구 사항을 충족하기 위해 추가적인 프로토콜 스택이 필요
1) ICE: P2P 연결 협상 및 설정
2) STUN: NAT 환경에서 자신의 공인 IP/포트 조회
3) TURN: 직접 연결 불가 시 중계 서버 사용
4) SDP: 스트림 설정 정보를 기술하는 형식
5) DTLS: 데이터 전송을 위한 암호화 보안 프로토콜
6) SCTP: 여러 데이터 스트림을 하나의 커넥션으로 다중화
7) SRTP: 실시간 오디오/비디오 전송을 위한 보안 프로토콜
UDP의 “미제공 서비스(non-services)” 특성
1) 메시지 전송 보장 없음
2) 응답/재전송/타임아웃 없음
3) 순서 보장 없음
4) 시퀀스 넘버, 재정렬, 헤드-오브-라인 블로킹 없음
5) 연결 상태 추적 없음
6) 연결 수립 및 종료 상태 없음
7) 혼잡 제어 없음
8) 네트워크 피드백 없음
- RTCPeerConnection API 간단 소개
- RTCPeerConnection 인터페이스
=> 각 P2P 연결의 전체 생명주기를 관리하는 역할
=> 피어 투 피어 연결을 설정하고 유지하는 데는 많은 프로토콜이 동원되지만, 브라우저가 애플리케이션에 제공하는 API는 상대적으로 단순
=> RTCPeerConnection은 연결 설정, 상태 관리, 연결 수명주기를 단일 인터페이스로 캡슐화함
1) RTCPeerConnection은 ICE 절차를 통해 NAT 환경을 자동으로 처리
2) 피어 간 STUN 기반의 keepalive 패킷을 자동 전송
3) 로컬 스트림을 추적 및 관리
4) 원격 스트림도 추적 및 관리합니다.
5) 필요 시 자동으로 스트림을 재협상(renegotiation)
6) 연결 생성, 응답 수락, 현재 상태 확인 등의 다양한 API 기능을 제공
4. 피어 간 연결 설정
- P2P 연결 설정의 어려움
=> 기존 방식은 모두 명확하게 정의된 HTTP 핸드셰이크를 기반으로 작동
=> 서버가 클라이언트에 의해 접근 가능하다는 전제를 가짐
- NAT 환경에서의 WebRTC 문제
=> WebRTC의 경우, 대부분의 피어는 서로 다른 사설망 안에 위치하고, 하나 이상의 NAT 뒤에 있으므로 -> 상대 피어에 직접 접근할 수 없음
=> 세션을 시작하려면 각 피어의 가능한 IP/포트 후보를 수집하고, NAT를 통과하며, 연결 가능한 조합을 찾는 작업을 거쳐야 함
* 하지만 성공을 보장할 수는 없음
- 피어가 항상 대기 중이라는 보장이 없음
=> HTTP 요청의 경우, 서버는 항상 연결 요청을 수신 대기 중이라는 암묵적인 전제가 있음
=> 반면에 피어는 오프라인이거나, 연결 불가 상태이거나, 혹은 연결을 원치 않을 수도 있음
- 성공적인 P2P 연결을 위해 해결해야 할 문제들
=> 상대 피어에게 연결 의도를 전달하여 수신 대기를 시작하게 해야 함
=> 양측에서 가능한 라우팅 경로를 수집하고 이를 교환해야 함
=> 사용할 미디어 및 스트림의 파라미터(코덱, 프로토콜 등)를 교환해야 함
- WebRTC는 ICE 프로토콜이 라우팅과 연결 가능성 테스트를 자동 수행
=> 하지만 시그널링(Signaling) 및 초기 세션 협상은 개발자가 직접 구현해야 함
- 신호 교환(Signaling)과 세션 협상(Session Negotiation)
- Signaling 채널의 필요성
=> 연결 가능성 테스트나 세션 협상이 이루어지기 전에, 연결가능 여부를 확인해야 함
=> 상대 피어가 패킷을 수신 대기 중이 아닌 경우에 대비해 최소한 공유된 signaling 채널이 필요
=> WebRTC 표준에서는 signaling에 대한 구현이나 권장 방식을 제공하지 않음
- Signaling에 사용 가능한 기존 프로토콜
* WebRTC 애플리케이션은 기존 signaling 프로토콜 및 게이트웨이를 사용할 수도 있고, 자체적인 signaling 서버와 프로토콜을 직접 구현할 수도 있음
1) SIP: VoIP와 화상회의에 널리 쓰이는 세션 시작 프로토콜
2) Jingle: XMPP의 세션 제어 확장
3) ISUP: 공중 전화망(PSTN)에서 사용하는 전화 세션 설정용 신호 프로토콜
- Signaling 서버의 역할
1) 기존 통신망과 WebRTC를 연결해주는 게이트웨이 역할
2) 서로 연결된 피어 간에 메시지를 중계하는 단순 메시지 전달자
5. 미디어 및 애플리케이션 데이터 전달
- 오퍼-응답 과정을 마친 뒤에도 WebRTC는 아직 전송 계층까지 절반만 구성된 상태
=> UDP만으로는 암호화, 흐름 제어, 혼잡 제어 등이 부족하여 성능 저하 위험 있음
=> WebRTC는 UDP 위에 다음과 같은 보안/전송 프로토콜을 덧붙임
1) DTLS: 암호화 키 협상 및 애플리케이션 데이터 보안 전송
2) SRTP: 오디오/비디오 실시간 전송
3) SCTP: 일반 애플리케이션 데이터 전송
- DTLS를 통한 안전한 통신
- WebRTC는 모든 데이터 전송을 암호화해야 하므로, UDP 환경에서도 TLS와 동일한 보안을 제공하는 DTLS를 사용
=> DTLS는 TLS에서 순서 보장, 무결성 유지 등이 어려운 문제를 해결하기 위해
1) 시퀀스 번호와 프래그먼트 오프셋을 추가
2) UDP 손실을 보완하는 재전송 타이머 도입
3) TLS 핸드셰이크의 순서를 보장하는 “미니 TCP” 구조 구현
=> 결과적으로 DTLS는 UDP 환경에서도 TLS와 같은 보안을 유지하며 핸드셰이크와 인증을 안정적으로 수행
- WebRTC는 각 피어마다 자가 서명 인증서를 자동 생성하고, DTLS는 인증을 애플리케이션에 위임함
=> DTLS는 조각화와 순서 오류에 대비하기 위해 두 가지 핵심 규칙을 적용
1) 각 레코드는 하나의 UDP 패킷에 담겨야 함
2) 블록 암호만 사용 가능, 스트림 암호는 사용 금지
* 이유: UDP는 조각화, 순서 재조립 기능이 없기 때문에 패킷 단위로 처리해야 안정적임
- SRTP 및 SRTCP를 통한 미디어 전송
- WebRTC는 미디어 획득, 인코딩, 전송, 흐름 제어까지 브라우저가 전부 자동 처리하는 구조
=> 애플리케이션은 미디어 품질 초기 조건만 설정하고, 이후 전송 품질은 브라우저가 실시간 조정
=> WebRTC는 VoIP에서 쓰이던 SRTP/SRTCP 프로토콜을 재사용해 미디어 및 제어 데이터를 암호화 전송
1) SRTP: 오디오/비디오 스트림 전송
2) SRTCP: 송수신 통계 및 제어 정보 전송
- 브라우저는 초기에는 낮은 비트레이트로 시작하여, 이후 네트워크 상황에 맞춰 자동으로 스트림 품질 조정
=> WebRTC는 자체적으로 적응형 스트리밍(adaptive bitrate streaming)을 구현하며, 최고 품질이 항상 보장되지는 않음
* 네트워크 상황에 따라 달라짐
- SCTP를 활용한 애플리케이션 데이터 전송
- WebRTC는 DataChannel API를 통해 피어 간 애플리케이션 데이터 전송을 지원하며, 이를 위해 SCTP를 사용
=> SCTP는 DTLS 위에서 실행되어 암호화된 데이터 전송을 지원함
=> SCTP는 TCP와 UDP의 장점을 결합하여 다음을 지원
1) 순서/비순서 전송
2) 신뢰성/비신뢰성 설정
3) 조각화/재조립
4) 스트림 다중화
5) 흐름/혼잡 제어
- SCTP는 핸드셰이크 및 혼잡 제어 메커니즘도 가지고 있어, 성능과 안정성을 보장
=> WebRTC 요구사항 중 일부 기능(예: 부분 신뢰성, 우선순위)은 확장 또는 상위 계층 구현이 필요
6. DataChannel
- DataChannel
=> WebRTC에서 피어 간 텍스트/바이너리 데이터를 양방향으로 교환하는 API
=> WebSocket처럼 동작하지만, 서버 없이 피어 투 피어로 동작하며 더 많은 기능 제공
* 주요 특징
1) RTCPeerConnection을 통해 생성, 서버 URL 필요 없음
2) 양쪽 피어 모두 채널을 시작 가능, ondatachannel 이벤트로 수신 가능
3) 전송 특성(순서, 신뢰성 등)을 채널마다 설정 가능 (WebSocket은 TCP 고정)
- 이벤트 및 속성은 WebSocket과 동일한 구조(onopen, onmessage, binaryType, protocol 등)
1) WebSocket은 생성자에서 서버 URL을 지정해야 하지만, DataChannel은 RTCPeerConnection 객체의 팩토리 메서드로 생성
2) WebSocket은 항상 클라이언트가 연결을 시작하지만, DataChannel은 양쪽 피어 중 누구든지 채널 생성을 시작할 수 있음
* 새로운 채널이 생성되면 상대 피어에서는 ondatachannel 콜백이 호출됨
3) WebSocket은 TCP 기반으로 항상 신뢰성 있고 순서가 보장된 전송을 사용하지만, DataChannel은 각 채널마다 전송 방식과 신뢰성을 직접 설정할 수 있음
- 설정과 협상
- 오디오/비디오/DataChannel 전송 모두 offer/answer 흐름, 프로토콜 협상, 연결 검사 과정 필요
=> SRTP(Secure Real-time Transport Protocol): 오디오/비디오용
=> SCTP(Stream Control Transmission Protocol): DataChannel용
- DataChannel을 쓰려면, SDP에 SCTP 파라미터가 포함되어야 하며, 사전에 DataChannel이 등록되어 있어야 자동 포함됨
=> DataChannel의 세부 설정(예: 신뢰성, 순서, 프로토콜 등)은 SDP에 포함되지 않음
→ 연결 후 DATA_CHANNEL_OPEN 메시지를 통해 각 채널 정보 전송
→ 이후, 각 채널은 SCTP 스트림 단위로 전송
→ 하나의 연결 안에서 다중 채널을 효율적으로 병렬 전송 가능
- 메시지 순서 및 신뢰성 설정
- DataChannel은 순서/신뢰성 설정이 자유로운 P2P 데이터 전송 채널
=> 설정 가능한 옵션
1) 순차/비순차 전송 (in-order / out-of-order)
2) 신뢰성 있음 / 부분 신뢰성 (reliable / partially reliable)*
- 부분 신뢰성 설정 방법 두 가지
* 동시에 둘 다 설정하면 오류 발생
1) 재전송 횟수 기반: 최대 몇 번까지만 재시도
2) 타임아웃 기반: 정해진 시간 내 도착하지 않으면 폐기
- 각 채널은 서로 독립적이며, SCTP 연결을 공유하지만 데이터는 병렬 전송 가능
=> 용도별 예시
1) 채팅 메시지: 순차 + 신뢰성 (TCP처럼)
2) 일시적 알림, 위치 업데이트 등: 비순차 + 부분 신뢰성 (지연보다 손실 허용)
- 부분 신뢰성 전송과 메시지 크기
- 부분 신뢰성 채널에서 큰 메시지(예: 120KB)를 보내면 손실 확률이 급격히 증가함
=> SCTP 기준 실제 데이터 페이로드는 약 1,150바이트 → 120KB는 107개 패킷으로 분할
=> 패킷 손실률이 1%라도, 메시지 전체 손실 가능성 매우 높음
=> 이를 피하려면
1) 재전송 설정 추가 (maxRetransmits, maxPacketLifetime)
2) 메시지를 작게 나누기 (1,150바이트 미만 권장)
=> 최적의 재전송 값은 없으며, 네트워크 품질에 따라 달라짐 → 작고 짧은 메시지가 가장 안정적
7. WebRTC 활용 사례 및 성능
- WebRTC는 P2P 연결 구현에 필요한 복잡한 요소들(NAT 우회, 연결 검사, 보안, 혼잡 제어 등)을 내부적으로 처리해주는 기술
=> 브라우저에서 실시간 P2P 애플리케이션을 단순한 API로 만들 수 있게 해주는 것이 WebRTC의 가장 큰 장점
=> 그러나 “피어 투 피어 방식 = 고성능”은 아님
1) 피어 간 네트워크 품질이 불규칙
2) 미디어 전송은 높은 처리량 요구
3) 신뢰성 없는 전송 방식은 예외 처리가 까다로움
=> 결국, 성능 좋은 WebRTC 애플리케이션을 만들려면 여전히 세심한 설계와 튜닝이 필요함
- 오디오, 비디오, 데이터 스트리밍
- WebRTC는 오디오·비디오 스트리밍을 자동으로 최적화하지만, 대역폭과 지연 시간의 한계는 여전히 존재
=> HD 스트리밍은 최소 1–2 Mbps 필요,업로드보다 다운로드 대역폭이 더 높을 수 있음
=> 네트워크 상태는 항상 변동 → 애플리케이션은 적응형 설계 필요
=> WebRTC의 미디어 엔진은 자동으로 가용 대역폭에 맞춰 품질을 조절
=> DataChannel 전송은 직접 버퍼 상태를 모니터링하고 필요시 전송 조절 로직을 구현해야 함
- 다자간 통신 아키텍처
- HD 품질의 양방향 미디어 스트림이 오가는 단일 피어 투 피어(P2P) 연결만으로도 사용자의 대역폭 대부분을 소모할 수 있음
=> 다자간 화상 통화와 같은 애플리케이션에서는, 각 피어 간의 스트림 연결 및 분산 구조(아키텍처)를 신중히 설계해야 함
- 1:1 연결
=> 가장 간단하고 관리하기 쉬운 구조
=> 두 피어가 직접 연결되므로 추가 최적화가 필요 없음- N:1 메시(mesh) 아키텍처 (모든 피어 간 직접 연결)
=> 예: 4명이 있다면 각 피어는 3개의 연결을 유지해야 함
=> 전체 연결 수: N * (N - 1) / 2
* 피어 수가 증가하면 총 연결 수가 기하급수적으로 증가
=> 특히 업링크 대역폭이 제한된 환경(모바일 등)에서는 이 구조는 빠르게 병목 현상을 유발함
- 스타(topology) 아키텍처 (중앙 노드를 통한 중계)
=> 각 피어는 중앙 슈퍼노드(supernode)와만 연결
=> 슈퍼노드는 각 피어로부터 미디어를 받고 다시 분배
* 슈퍼노드만 모든 트래픽을 처리하고, 다른 피어들은 슈퍼노드 하나만 상대
* 슈퍼노드 유형
1) 일반 피어 중 하나 (예: 방장 또는 호스트)
2) 가장 빠른 네트워크 상태를 가진 피어 (선출 필요)
3) 전용 중계 서버 (3rd-party 서버도 가능)
=> 슈퍼노드 역할은 상황과 서비스 구조에 따라 결정
* 예: 소규모 회의라면 호스트가 직접, 대규모 서비스라면 전용 서버
- 인프라 및 용량 계획
- WebRTC는 P2P 연결 기반이지만, 시그널링 서버와 STUN/TURN 서버 등 중앙 인프라가 필수
=> STUN은 연결 초기 단계에서만 사용
=> TURN은 연결 실패 시 중계 역할을 수행 (사용 비율 8~10%)
- 시그널링은 WebSocket이나 SSE 등 저지연 기술로 구축 필요
=> TURN은 고비용·고부하 인프라 → 철저한 용량 계획 필수
=> 다자간 RTC 서비스는 스트림 중계를 위한 중앙 게이트웨이가 필요하며, 단순 패킷 프록시를 넘어서 고성능 처리 능력까지 요구
- 데이터 효율성과 압축
- 오디오/비디오 스트림은 WebRTC 엔진이 자동으로 압축 및 최적화함
=> 해상도, 비트레이트, 프레임률 등 네트워크에 따라 자동 조정
=> 반면, DataChannel을 통한 데이터 전송은 수동 최적화 필요
* 압축되지 않은 상태로 전송됨
* 바이너리 또는 UTF-8 데이터 전송은 가능하나, 용량 최적화는 애플리케이션 몫
- UDP 기반 프로토콜 특성상
=> 전송 중 오버헤드 발생 (UDP + DTLS + SCTP)
=> 순서 보장/신뢰성 미보장 전송에 따른 처리 고려 필요
8. 성능 점검 체크리스트
1. 시그널링 서비스 (Signaling service)
=> 지연이 낮은 전송 방식(WebSocket 등) 사용
=> 충분한 용량(capacity)을 할당할 것
=> 연결이 완료된 이후에는 DataChannel을 통해 시그널링 전환도 고려
2. 방화벽 및 NAT 우회 (Firewall and NAT traversal)
=> RTCPeerConnection을 시작할 때 STUN 서버 필수 제공
=> 가능한 경우 Trickle ICE 방식 사용
→ 시그널링 교환이 늘어나지만 연결 설정이 더 빠름
=> TURN 서버를 준비해 P2P 연결 실패 시 중계 가능하도록 구성
=> TURN 서버는 많은 트래픽을 유발하므로 충분한 처리 용량 확보 필요
3. 데이터 분산 (Data distribution)
=> 다자간 통신 시, 슈퍼노드(supernode)나 중앙 중계 서버 사용 고려
=> 중계 서버에서 수신 데이터를 최적화한 뒤 다른 피어로 전달하는 전략도 유용
4. 데이터 효율성 (Data efficiency)
=> 오디오/비디오 스트림에 적절한 제약조건(해상도, 프레임레이트 등) 설정
=> DataChannel에서 바이너리 데이터 전송 시 최적화
=> UTF-8 텍스트는 압축을 적용하는 것을 고려 (예: Gzip, Brotli)
=> DataChannel의 버퍼링 양을 모니터링하고, 네트워크 상태에 따라 동적으로 조정
5. 전송 및 신뢰성 (Delivery and reliability)
=> 헤드-오브-라인 블로킹(HOL blocking)**을 피하려면 순서 없는 전송 사용 고려
=> 순서 보장(in-order delivery)을 사용할 경우, 메시지 크기를 작게 유지해 HOL 블로킹 영향 최소화
=> 1,150바이트 이하의 소형 메시지 전송이 이상적 → 큰 메시지는 패킷 손실 시 전체 전송 실패 가능성 증가
=> 부분 신뢰성(partial reliability) 사용 시, 메시지 크기, 지연 시간, 데이터 유형에 맞는 재전송 횟수와 타임아웃 값 설정