실시간 통신 (3) - 품질 관리와 적응 - soo:bak
작성일 :
네트워크 변화에 어떻게 적응하는가
Part 2에서 WebRTC 스택을 살펴보았습니다.
실제 네트워크는 불안정하기 때문에, 패킷 손실, Jitter, 대역폭 변동에 적절히 대응해야 합니다.
Jitter Buffer
패킷 도착 시간의 변동(Jitter)을 흡수하여 안정적인 재생을 가능하게 합니다.
1
2
3
4
5
6
7
8
9
10
11
네트워크에서:
패킷 1 도착: 0ms
패킷 2 도착: 25ms (+5ms 지터)
패킷 3 도착: 35ms (-5ms 지터)
패킷 4 도착: 65ms (+5ms 지터)
직접 재생하면:
프레임 간격이 불규칙 → 끊김
Jitter Buffer 사용:
버퍼에서 일정 간격으로 꺼냄 → 부드러운 재생
버퍼 크기 트레이드오프
1
2
3
4
5
6
7
8
9
작은 버퍼:
- 낮은 지연
- Jitter 흡수 능력 낮음
- 끊김 가능성 높음
큰 버퍼:
- 높은 지연
- Jitter 흡수 능력 높음
- 대화 지연 증가
적응형 Jitter Buffer
네트워크 상태에 따라 버퍼 크기를 동적으로 조절하여 지연과 안정성의 균형을 맞춥니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
Jitter 낮을 때: 버퍼 줄임 (지연 감소)
Jitter 높을 때: 버퍼 늘림 (안정성 증가)
┌─────────────────────────────────────────┐
│ 적응형 버퍼 크기 │
│ │
│ 버퍼 │ ──────────────── │
│ 크기 │ / \ │
│ │ / \ │
│ │ / \ │
│ └───────────────────────────── │
│ 네트워크 Jitter │
└─────────────────────────────────────────┘
패킷 손실 대응
FEC (Forward Error Correction)
순방향 오류 수정은 원본 데이터와 함께 복구용 데이터를 미리 전송하여, 재전송 없이 손실을 복구합니다.
1
2
3
4
5
원본 패킷: P1 P2 P3 P4
FEC 패킷: F1 (P1⊕P2) F2 (P3⊕P4)
P2 손실 시:
P2 = P1 ⊕ F1 로 복구
장점:
- 재전송 없이 복구
- RTT 영향 없음
단점:
- 대역폭 오버헤드 (20-50%)
- 연속 손실에 약함
WebRTC는 Opus 코덱의 InBand FEC를 지원합니다.
1
a=fmtp:111 useinbandfec=1
Packet Concealment (은닉)
손실된 패킷의 내용을 이전 데이터를 기반으로 추정하여 재생 품질을 유지합니다.
오디오:
- 이전 샘플 반복
- 보간(interpolation)
- 무음 삽입
비디오:
- 이전 프레임 반복
- 모션 보상 예측
NACK과 재전송
NACK(Negative Acknowledgment)를 통해 수신자가 손실된 패킷을 명시적으로 알리고 재전송을 요청합니다.
1
2
3
4
5
6
7
8
수신자 송신자
│ │
│ 패킷 1,2,4 수신 (3 손실) │
│ │
│ ── RTCP NACK (seq=3) ──────► │
│ │
│ ◄──── 패킷 3 재전송 ──────── │
│ │
RTT가 낮을 때만 효과적이며, RTT가 높으면 재전송된 패킷이 재생 시점을 놓칠 수 있습니다.
적응형 비트레이트 (ABR)
네트워크 상태에 따라 인코딩 품질을 동적으로 조절하여 끊김 없는 재생을 유지합니다.
대역폭 추정
RTCP의 피드백을 활용하여 가용 대역폭을 추정합니다.
1
2
3
4
5
6
7
8
9
송신자 수신자
│ │
│ ─── RTP 패킷들 ────────────► │
│ │
│ ◄── RTCP Receiver Report ─── │
│ (손실률, Jitter) │
│ │
│ 손실률 높음 → 대역폭 낮춤 │
│ 손실률 낮음 → 대역폭 올림 │
WebRTC는 Google Congestion Control (GCC)을 사용합니다.
인코더 조절
추정된 대역폭에 맞춰 인코더 파라미터를 조절합니다.
1
2
3
4
5
6
7
8
9
대역폭 높음:
- 비트레이트: 2 Mbps
- 해상도: 1280x720
- 프레임레이트: 30fps
대역폭 낮음:
- 비트레이트: 500 Kbps
- 해상도: 640x360
- 프레임레이트: 15fps
Simulcast
송신자가 여러 품질의 스트림을 동시에 인코딩하여 전송합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌───────────────────────────────────────────────────────────┐
│ 송신자 │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ High │ │ Medium │ │ Low │ │
│ │ 720p │ │ 360p │ │ 180p │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
└────────┼─────────────┼─────────────┼─────────────────────┘
│ │ │
▼ ▼ ▼
┌───────────────────────────────────────────────────────────┐
│ 미디어 서버 (SFU) │
│ │
│ 수신자 A: 대역폭 높음 → High 스트림 전달 │
│ 수신자 B: 대역폭 낮음 → Low 스트림 전달 │
└───────────────────────────────────────────────────────────┘
SVC (Scalable Video Coding)
계층적 인코딩을 통해 하나의 스트림에서 여러 품질 수준을 추출할 수 있습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
SVC 스트림:
┌─────────────────────────────────────┐
│ Enhancement Layer 2 (High) │
├─────────────────────────────────────┤
│ Enhancement Layer 1 (Medium) │
├─────────────────────────────────────┤
│ Base Layer (Low) │
└─────────────────────────────────────┘
대역폭에 따라:
- 높음: 모든 레이어 수신
- 중간: Base + Enhancement 1
- 낮음: Base만 수신
에코 캔슬레이션
음향 에코의 원인
1
2
3
4
5
6
7
8
9
10
┌─────────────────────────────────────────────────────────────┐
│ │
│ 스피커 ─────────────────► 마이크 │
│ │ ▲ │
│ │ 음향 반사 │ │
│ └────────────────────────┘ │
│ │
│ 상대방 목소리가 스피커 → 반사 → 마이크 → 상대방에게 다시 │
│ │
└─────────────────────────────────────────────────────────────┘
이러한 에코는 대화를 크게 방해합니다.
AEC (Acoustic Echo Cancellation)
WebRTC는 소프트웨어 기반 AEC를 기본으로 제공합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
원리:
1. 스피커로 보낸 신호를 기억
2. 마이크 입력에서 해당 신호의 반사를 추정
3. 추정된 에코를 빼서 제거
┌────────────┐
│ 스피커 │──────────────────────────┐
│ 출력 │ │
└─────┬──────┘ │
│ │
▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ 에코 추정 │────│ 에코 빼기 │───│ 출력 │
│ │ │ │ │ (에코 제거)│
└────────────┘ └────────────┘ └────────────┘
▲
│
┌─────┴──────┐
│ 마이크 │
│ 입력 │
└────────────┘
네트워크 문제 진단
getStats() API
WebRTC 연결의 실시간 통계를 조회할 수 있습니다.
1
2
3
4
5
6
7
8
9
10
11
const stats = await peerConnection.getStats();
stats.forEach(report => {
if (report.type === 'inbound-rtp' && report.kind === 'video') {
console.log('Packets received:', report.packetsReceived);
console.log('Packets lost:', report.packetsLost);
console.log('Jitter:', report.jitter);
console.log('Frames decoded:', report.framesDecoded);
console.log('Frames dropped:', report.framesDropped);
}
});
품질 지표 해석
패킷 손실률:
- 1% 미만: 우수
- 1-5%: 수용 가능
- 5% 이상: 품질 저하 심각
Jitter:
- 30ms 미만: 우수
- 30-50ms: 수용 가능
- 50ms 이상: 문제
RTT:
- 150ms 미만: 대화에 적합
- 300ms 이상: 대화 어려움
일반적인 문제들
비디오 정지:
- 높은 패킷 손실
- 키프레임 손실
- 네트워크 대역폭 부족
오디오 끊김:
- Jitter 증가
- 버퍼 언더런
- CPU 과부하
단방향 오디오:
- NAT 트래버설 실패
- 방화벽 차단
- ICE 후보 교환 문제
SFU vs MCU
MCU (Multipoint Control Unit)
중앙 서버에서 모든 미디어를 디코딩하고 합성하여 하나의 스트림으로 제공합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
┌───────────────────────────────────────────────────────────┐
│ MCU │
│ │
│ Alice ─────►│ │◄────── Bob │
│ │ ┌────────────┐ │ │
│ │───│ 합성 │───│ │
│ │ │ (디코딩+ │ │ │
│ Carol ─────►│ │ 믹싱+ │ │◄────── Dave │
│ │ │ 재인코딩) │ │ │
│ │ └────────────┘ │ │
│ │
│ 각 참가자는 합성된 하나의 스트림 수신 │
└───────────────────────────────────────────────────────────┘
장점:
- 클라이언트 대역폭 고정 (참가자 수와 무관)
- 레이아웃 제어 가능
단점:
- 서버 CPU 사용량 높음 (모든 미디어 디코딩/인코딩)
- 지연 증가 (처리 시간)
- 확장성 제한
SFU (Selective Forwarding Unit)
미디어를 디코딩하거나 믹싱하지 않고 선택적으로 전달만 합니다.
1
2
3
4
5
6
7
8
9
10
11
12
┌───────────────────────────────────────────────────────────┐
│ SFU │
│ │
│ Alice ─────►│ │──────► Bob │
│ │ ┌────────────┐ │ (Alice+Carol 수신) │
│ │ │ 라우팅 │ │ │
│ │ │ (디코딩X) │ │ │
│ Carol ─────►│ └────────────┘ │──────► Alice │
│ │ │ (Bob+Carol 수신) │
│ │
│ 각 참가자는 다른 참가자 스트림을 개별 수신 │
└───────────────────────────────────────────────────────────┘
장점:
- 서버 부하 낮음 (포워딩만)
- 지연 낮음
- 확장성 좋음
단점:
- 클라이언트 대역폭 증가 (N-1 스트림 수신)
- 클라이언트 CPU 사용 (다중 디코딩)
확장성 트레이드오프
1
2
3
4
5
참가자 수 MCU 부하 SFU 부하 클라이언트 대역폭(SFU)
2 낮음 낮음 1 스트림
5 중간 낮음 4 스트림
10 높음 낮음 9 스트림
50 매우 높음 중간 49 스트림
대규모 회의는 Simulcast + SFU 조합이 일반적입니다.
정리: 적응이 품질의 핵심
실시간 통신 품질 관리 요약:
| 문제 | 해결책 |
|---|---|
| Jitter | 적응형 Jitter Buffer |
| 패킷 손실 | FEC, NACK, Concealment |
| 대역폭 변동 | 적응형 비트레이트 |
| 에코 | AEC (음향 에코 제거) |
| 확장성 | SFU + Simulcast |
네트워크는 예측할 수 없기 때문에, 적응이 품질 유지의 핵심입니다.
관련 글