영상 통화 한 번의 여행
서울의 한 카페. 카페 Wi-Fi에 연결된 휴대폰으로 부산에 있는 친구에게 영상 통화를 건다. 친구는 길을 걷는 중이라 5G에 연결되어 있다. 화면 속 친구가 웃는 모습이 거의 동시에 보이고, 내 목소리도 거의 바로 들린다. 그 “거의 동시”는 약 0.1초다. 이 장에서는 그 0.1초를 슬로 모션으로 펼친다. 놀랍게도 이 책의 거의 모든 장이 그 안에 들어 있다.
- 카메라에서 상대 화면까지, 영상 패킷 하나가 지나는 모든 구간과 담당 장을 하나의 지도로 연결한다.
- 구간마다 어떤 헤더가 붙고 벗겨지는지, 신호가 전기·빛·전파 중 무엇으로 바뀌는지 따라간다.
- 통화를 맺는 과정(DNS, TLS, 시그널링, STUN·TURN·ICE)이 왜 필요한지 이해한다.
- 입-귀 지연 150 ms 예산을 구간별로 나눠 보고, 어디가 병목인지 찾는다.
- 지터 버퍼, FEC, 손실 은닉, 비트레이트 적응이 나쁜 네트워크를 견디는 방법을 실험한다.
- 영상 통화 1시간의 데이터 양, 비행기 Wi-Fi와 AI 챗봇의 여행을 같은 눈으로 본다.
전체 지도: 카메라에서 친구 화면까지
영상 통화는 한 번 보내고 끝나는 택배가 아니다. 1초에 30장의 장면과 50개의 음성 조각이 끊임없이 출발하는 배달 행렬이다. 그 행렬이 지나는 길을 먼저 한 장의 지도로 보자. 각 상자의 장 번호를 누르면 그 구간을 자세히 다룬 장으로 간다.
보통 택배(파일 다운로드)는 늦더라도 하나도 빠짐없이 와야 한다. 영상 통화는 신선 식품 배달에 가깝다. 매초 수십 개의 상자가 출발하고, 정해진 시각(재생 시각)을 넘긴 상자는 도착해도 버린다. 그래서 등기 우편(TCP)이 아닌 일반 우편(UDP)을 쓰고, 상자에는 순서 번호와 “언제 찍은 장면인지” 적힌 번호표(RTP)를 붙이며, 받는 쪽은 약간의 대기실(지터 버퍼)을 두어 들쭉날쭉한 도착을 고른 박자로 바꾼다.
| 구간 | 신호의 모습 | 대표 지연(한쪽) | 장 |
|---|---|---|---|
| 카메라 캡처 + 인코딩 | 빛 → 전하 → 숫자 | 20~40 ms | 2, 10 |
| 휴대폰 → 공유기 (Wi-Fi) | 전파 (2.4/5/6 GHz, OFDM) | 1~10 ms (붐비면 수십 ms) | 11, 12, 13 |
| 공유기 → 통신사 국사 (FTTH) | 전기 → 빛 (PON) | 1~2 ms | 5, 7 |
| 통신사 라우터 · 백본 (서울→부산) | 빛 (DWDM), 라우터 안에서는 전기 | 3~6 ms | 5, 8, 17 |
| 데이터센터 TURN 경유 (필요할 때만) | 빛 → 전기 → 빛 | +0.5~3 ms (가까울 때) | 20, 21 |
| 5G 코어 → 기지국 → 친구 폰 | 빛 → 전파 (3.5 GHz) | 5~15 ms | 14, 18 |
| 지터 버퍼 + 디코딩 + 화면 표시 | 숫자 → 빛 | 40~80 ms | 9, 10 |
표를 다시 보자. 서울에서 부산까지 400 km를 건너는 네트워크 구간을 모두 합쳐도 20 ms 안팎이다. 오히려 양 끝의 휴대폰 안(캡처, 인코딩, 기다림, 디코딩, 표시)이 더 오래 걸린다. 이 사실은 뒤에서 지연 예산을 짤 때 다시 확인한다.
통화를 맺기까지: 시그널링과 NAT 통과
영상이 흐르기 전에 먼저 할 일이 있다. 내 휴대폰은 친구 휴대폰의 IP 주소를 모른다. 안다고 해도 친구는 이동통신사의 통신사 NAT(CGNAT) 뒤에, 나는 카페 공유기의 NAT 뒤에 숨어 있어서(7장) 바깥에서 먼저 말을 걸 수 없다. 그래서 둘 다 이미 알고 있는 제3자, 즉 통화 서비스의 서버가 중매를 선다. 이렇게 “누가 누구에게, 어떤 조건으로 통화하자”는 약속을 주고받는 일을 시그널링(signaling)이라 한다. 영상 자체가 흐르는 길(미디어 경로)과는 별개의 길이다.
단계별로 쓰이는 이름을 정리하자.
- DNS와 TLS: 앱은 서버 이름을 DNS로 IP 주소로 바꾸고(10장), TLS로 암호화된 연결을 연다(22장). 로그인 토큰도 이 안에서 오간다. 메신저 앱은 보통 켜질 때 이 연결을 만들어 두고 계속 유지한다.
- SDP: 통화 조건을 적은 문서다. SDP(Session Description Protocol)에는 “나는 Opus 음성과 H.264·VP8·AV1 영상을 쓸 수 있다”, “내 암호 인증서 지문은 이것이다” 같은 내용이 들어 있다. 제안(offer)과 응답(answer)을 맞춰 보면 둘 다 쓸 수 있는 코덱이 정해진다. 웹 브라우저와 앱에 내장된 실시간 통신 표준 묶음인 WebRTC가 이 방식을 쓰고, 전화망 쪽의 SIP(VoLTE 등)도 같은 SDP를 주고받는다.
- STUN: NAT 바깥에 있는 서버에 작은 UDP 패킷을 보내면 서버가 “네 패킷은 198.51.100.24:61002에서 왔다”고 알려 준다. 이것이 STUN이다. 공유기 변환표에 적힌 내 바깥 주소를 알아내는 거울이다.
- TURN: 직접 연결이 끝내 안 되면 데이터센터의 TURN 서버가 중계 주소를 빌려 주고, 영상 패킷을 받아 상대에게 그대로 넘겨 준다. 내용은 SRTP로 암호화되어 있어서 중계 서버도 볼 수 없다.
- ICE: 위에서 모은 주소 후보(휴대폰 자신의 주소, STUN으로 알아낸 바깥 주소, TURN 중계 주소)를 서로 교환한 뒤, 가능한 짝을 모두 시험해 가장 좋은 길을 고르는 절차가 ICE(Interactive Connectivity Establishment)다.
1:1은 직접 연결이 가장 좋지만, 10명이 통화할 때 모두가 9명에게 각자 영상을 보내면 내 업로드가 9배가 된다. 그래서 그룹 통화는 데이터센터의 SFU(Selective Forwarding Unit)에 영상을 한 번만 올리고, 서버가 받는 사람 화면 크기에 맞는 해상도를 골라 나눠 준다. 보내는 쪽은 큰 화질·작은 화질을 동시에 올리는(simulcast) 경우가 많다. 서버는 패킷을 고르기만 하고 다시 인코딩하지 않으므로 지연이 거의 늘지 않는다.
패킷 하나의 여행: 한 구간씩
이제 통화가 연결되었다. 내 얼굴이 담긴 한 장면 가운데 패킷 하나를 골라 부산까지 따라가 보자. “다음 →”을 누를 때마다 패킷이 한 구간을 건너고, 아래 그림에 지금 패킷에 붙은 헤더(바깥 → 안쪽), 신호의 모습(전기·빛·전파), 출발·도착 주소가 나타난다. 맨 아래 막대에는 시간이 쌓인다. 경로를 “직접 연결”로 바꾸면 데이터센터를 거치지 않는 길도 볼 수 있다.
영상 패킷 하나가 지나가는 길
RTP(Real-time Transport Protocol)는 배달 규칙이라기보다 상자에 붙이는 번호표다. 순서 번호로 빠진 상자와 뒤바뀐 순서를 알아내고, 타임스탬프로 “이 조각은 몇 번째 순간의 장면인지”를 알아 음성과 영상을 맞춰(립싱크) 재생한다. 실제 배달은 UDP와 IP가 맡는다. 암호화한 버전이 SRTP다. 함께 다니는 RTCP는 “손실 몇 %, 지터 몇 ms”를 상대에게 알려 주는 운송장 피드백이다.
지연 예산: 150 ms 안에 들어오려면
대화가 자연스러우려면 내가 말한 소리가 상대 귀에 닿기까지, 즉 입-귀 지연(mouth-to-ear delay)이 짧아야 한다. 국제전기통신연합의 권고(ITU-T G.114)는 한쪽 방향 150 ms 이하면 대부분의 대화에서 지연을 거의 느끼지 못한다고 본다. 300 ms를 넘어가면 “내가 말을 끝냈나?” 하는 머뭇거림 때문에 서로 말이 겹치기 시작하고, 400 ms를 넘으면 일반적인 대화로는 받아들이기 어렵다.
150 ms라는 예산을 구간마다 나눠 쓴다고 생각해 보자. 아래에서 구간별 조건을 바꿔 가며 어디서 예산이 새는지 찾아보자.
입-귀 지연 예산 계산기
지연 예산은 한 달 생활비와 같다. 월세(빛이 거리를 건너는 시간)는 깎을 수 없다. 서울-뉴욕의 바닷길은 아무리 좋은 장비를 써도 수십 ms다. 그러니 줄일 수 있는 것은 식비와 용돈, 즉 휴대폰 안의 처리와 버퍼다. 먼 나라와의 통화 앱이 인코더를 가볍게 돌리고 지터 버퍼를 아슬아슬하게 잡는 이유다.
손실과 지터에 맞서기
패킷은 일정한 박자로 출발하지만 도착은 들쭉날쭉하다. Wi-Fi에서 순서를 기다리고, 라우터 큐에 잠깐 머물고, 기지국 스케줄러가 차례를 정하기 때문이다. 이 도착 간격의 흔들림이 지터(jitter)다. 그리고 일부는 아예 사라진다(손실). 영상 통화 앱은 네 가지 무기로 맞선다.
- 지터 버퍼(jitter buffer): 도착한 패킷을 바로 재생하지 않고 잠깐 모았다가 고른 박자로 꺼낸다. 버퍼가 깊을수록 늦은 패킷을 더 기다려 주지만, 그만큼 모든 소리가 늦게 들린다.
- FEC(순방향 오류 정정): 여분의 정보를 미리 함께 보내 잃어버린 조각을 받는 쪽이 스스로 복원한다(12장의 오류 정정 부호와 같은 생각). Opus 음성 코덱은 다음 패킷에 이전 조각의 저화질 사본을 넣어 보낼 수 있다. 영상은 패킷 몇 개를 XOR한 복구 패킷을 덧붙인다.
- 패킷 손실 은닉(PLC): 끝내 못 받은 조각은 앞뒤 소리로 그럴듯하게 메우거나, 영상은 이전 장면을 잠시 유지한다. 몇 % 손실까지는 사람이 잘 눈치채지 못한다. 영상의 기준 장면이 깨지면 상대에게 “새 기준 장면(키프레임)을 보내 줘”라고 요청하고, 빠진 패킷만 골라 재전송을 부탁하기도 한다(NACK). 지연 예산이 남을 때만 쓰는 방법이다.
- 비트레이트 적응: 손실과 지연이 늘면 그 자체가 “길이 막힌다”는 신호다. 보내는 양을 줄여 큐가 비게 한다(9장의 혼잡 제어). 다음 절에서 실험한다.
지터 버퍼: 지연과 끊김의 줄다리기
길이 막히면 덜 보낸다: 비트레이트 적응
카페 Wi-Fi가 갑자기 붐비거나 친구가 엘리베이터에 타면, 쓸 수 있는 대역폭이 몇 초 사이에 10분의 1로 떨어진다. 이때 하던 대로 2.5 Mbps를 계속 밀어 넣으면 어떻게 될까? 남는 패킷이 병목 라우터나 기지국의 큐에 쌓이고, 큐가 길어질수록 모든 패킷이 그만큼 늦게 도착한다. 큐가 넘치면 버려진다. 파일 다운로드라면 TCP가 알아서 속도를 줄이지만(9장), UDP 위의 영상 통화는 앱이 직접 해야 한다.
WebRTC가 쓰는 대표적인 방식(구글 혼잡 제어, GCC)은 지연이 늘기 시작하는 것을 손실보다 먼저 알아챈다. 패킷 사이 도착 간격이 보낸 간격보다 점점 벌어지면 “큐가 차고 있다”는 뜻이므로, 큐가 넘치기 전에 인코더의 목표 비트레이트를 낮춘다. 해상도와 프레임률이 잠시 떨어지지만 대화는 끊기지 않는다.
대역폭이 출렁일 때: 적응 vs 고집
데이터 양 감각: 영상 통화 1시간은 몇 GB?
720p 영상 통화는 보통 한 방향에 1.5~2.5 Mbps 수준이다. 1초에 2 Mbit이면 1시간(3,600초)에 7,200 Mbit = 900 MB. 영상 통화는 보내기와 받기가 동시에 일어나므로 휴대폰 요금제에서 빠지는 양은 그 두 배, 1시간에 약 1.8 GB가 된다. 코덱이 좋아지면 같은 화질을 더 적은 비트로 보낸다. 음성은 Opus 기준 수십 kbps라 영상에 비하면 거의 공짜지만, 20 ms마다 보내는 작은 패킷이라 헤더(IP·UDP·RTP·SRTP 약 50바이트) 비율이 의외로 크다.
영상 통화 데이터 계산기
같은 눈으로 본 두 장면
지도를 그리는 법을 익혔으니, 다른 장면도 짧게 같은 방식으로 따라가 보자. 경로의 모양이 달라지면 병목도 달라진다.
장면 A. 비행기 Wi-Fi에서 메시지 보내기
태평양 위 고도 10 km. 기내 Wi-Fi로 “곧 도착해”를 보낸다. 휴대폰 → 기내 Wi-Fi 공유기(13장) → 동체 위 위성 안테나 → 위성 → 지상국(게이트웨이) → 지상 인터넷 → 메신저 서버 → 친구로 이어진다(15장). 기내와 지상 구간은 익숙한 그대로이고, 새로 생긴 것은 우주를 다녀오는 구간 하나다.
| 비행기 Wi-Fi 경로 | 한쪽 지연(대략) | 왕복(핑) | 메시지 / 영상 통화 |
|---|---|---|---|
| 정지궤도(GEO) 위성 | ≈ 270~300 ms | ≈ 600 ms 이상 | 메시지는 충분 / 통화는 말이 겹침 |
| 저궤도(LEO) 위성군 | ≈ 20~40 ms | ≈ 40~80 ms | 둘 다 무난 |
| (비교) 지상 FTTH, 서울-부산 | ≈ 5~10 ms | ≈ 10~20 ms | 둘 다 여유 |
메시지 한 통은 수백 바이트이고 1초 늦어도 아무도 모르니, 정지궤도 위성으로도 충분하다. 다만 메신저가 TCP+TLS 연결을 새로 맺어야 한다면 왕복이 몇 번 필요해서(9·22장) 첫 메시지가 2~3초 걸릴 수 있다. 같은 정지궤도 링크로 영상 통화를 하면 지연 예산 시뮬레이터의 “먼 릴레이”보다도 나쁘다. 병목이 대역폭이 아니라 거리인 대표적인 경우다.
장면 B. AI 챗봇에 질문하기
휴대폰 앱에서 AI 챗봇에게 “부산 맛집 추천해 줘”라고 묻는다. 앞부분은 이미 아는 길이다. Wi-Fi(13장) → 공유기 NAT(7장) → 통신사 → 백본(5·8장) → 클라우드 리전의 로드밸런서(21장)까지 HTTPS(TLS 1.3, 22장)로 간다. 새로운 것은 그다음, 데이터센터 안쪽이다.
| 단계 | 대략의 시간 | 무엇이 병목인가 |
|---|---|---|
| 휴대폰 → 리전 (연결이 열려 있으면 요청 한 번) | 10~50 ms | 거리와 접속망 (영상 통화와 같다) |
| 대기열 + 질문 읽기(프리필) | 0.2~2 s | GPU 연산, 붐비는 정도 |
| 첫 토큰 도착(TTFT) | 0.3~2 s | 대부분 데이터센터 안 |
| 이후 토큰 스트리밍 | 초당 수십~100여 토큰 | GPU 메모리 대역폭, GPU 간 통신 |
영상 통화와 비교하면 무게중심이 정반대다. 영상 통화는 가는 길이 대부분이었지만, AI 챗봇은 네트워크 왕복 수십 ms보다 데이터센터 안의 계산과 GPU 사이 통신이 훨씬 길다. 그래서 AI 데이터센터는 GPU들을 잇는 내부 네트워크(20장)와 광 연결(19장)에 막대한 돈을 쓴다. 답을 토큰 단위로 흘려 보내는 스트리밍은 10장의 동영상 스트리밍처럼 “다 받기 전에 보기 시작”하게 해 체감 지연을 줄인다.
병목 찾기 연습
통화 품질이 나쁠 때 원인은 대개 한 구간이다. 23장의 측정 도구로 증상을 구간에 대응시키는 감각을 연습해 보자. 먼저 결과를 예측하고 위 시뮬레이터로 확인하자.
| 증상 | 먼저 의심할 곳 | 확인 방법(23장) |
|---|---|---|
| 말이 계속 겹친다 (지연이 큼) | 먼 릴레이, 해외 경로, 정지궤도 위성, 과한 지터 버퍼 | 통화 앱의 통계 화면(RTT), traceroute |
| 화면이 자주 멈추고 소리가 뭉개진다 | Wi-Fi 혼잡·약한 신호, 셀 가장자리 (손실·지터) | 신호 세기(RSSI), 공유기 가까이에서 다시 측정 |
| 처음엔 좋다가 점점 흐려진다 | 업로드 대역폭 부족 → 비트레이트 적응 | 속도 측정의 업로드 값, 같은 회선의 대용량 업로드 |
| 연결 자체가 안 된다 | 방화벽의 UDP 차단, TURN 서버 접근 불가 | 다른 네트워크(5G)로 바꿔 시도 |
카페 Wi-Fi에서 부산 친구와 통화한다. 지연 예산은 120 ms로 여유가 있는데 화면이 자꾸 멈추고 소리가 끊긴다. 측정해 보니 Wi-Fi 구간의 지터가 평균 30 ms, 손실률이 4%다. 가장 효과적인 첫 조치는?
지터 버퍼 시뮬레이터에서 지터 30 ms, 손실 4%로 놓고 버퍼와 FEC를 바꿔 보자.
뉴욕 친구와 통화하면 지연이 약 190 ms라 조금 어색하다. 지연 예산 시뮬레이터의 기본값에서 “뉴욕”만 고른 상태다. 다음 중 150 ms 아래로 내려 줄 수 있는 조치는?
지연 예산 시뮬레이터에서 “뉴욕”을 고르고 하나씩 바꿔 보자.
이 책의 모든 층이 0.1초 안에 함께 일한다
영상 통화 한 번을 다시 펼쳐 보면, 이 책의 장들이 하나도 빠짐없이 그 0.1초 안에서 맡은 일을 하고 있다.
| 장 | 영상 통화에서 맡은 일 |
|---|---|
| 01 네트워크 | 두 휴대폰이 “망들의 망”을 거쳐 대역폭과 지연이라는 두 숫자로 연결된다. |
| 02 신호 | 빛(카메라) → 숫자 → 전기·빛·전파 → 숫자 → 빛(화면). 섀넌 한계가 각 링크의 최대 속도를 정한다. |
| 03 계층 | RTP·UDP·IP·링크 헤더가 겹겹이 씌워지고 벗겨진다(캡슐화). |
| 04 구리선 | 공유기와 광 단말 사이의 랜선, 기지국과 장비 사이의 짧은 연결. |
| 05 광통신 | FTTH(PON)와 서울-부산 백본, 뉴욕까지라면 해저 케이블. |
| 06 이더넷 | 공유기·국사·데이터센터 안의 모든 프레임과 스위치. |
| 07 IP | 사설 주소, 카페 공유기 NAT와 통신사 CGNAT, 그리고 그것을 뚫는 STUN. |
| 08 라우팅 | 통신사 라우터들의 최장 접두사 일치, 통신사 사이의 BGP. |
| 09 TCP/UDP | 영상은 UDP + RTP, 시그널링은 TCP, 그리고 혼잡 제어의 생각을 빌린 비트레이트 적응. |
| 10 DNS·웹·스트리밍 | 서버 이름 찾기, 코덱 압축, 스트리밍과 실시간 통신의 차이. |
| 11 전파 | 카페 안 5 GHz와 거리의 3.5 GHz 전파, 감쇠와 벽. |
| 12 변조 | Wi-Fi와 5G 모두 OFDM, MIMO, 오류 정정 부호. |
| 13 Wi-Fi | CSMA/CA로 순서 기다리기. 첫 번째 지터의 원천. |
| 14 이동통신 | 5G 코어의 GTP 터널, 기지국 스케줄러, 이동해도 끊기지 않는 핸드오버. |
| 15 위성 | 비행기·바다 위에서의 연결, 정지궤도와 저궤도의 지연 차이. |
| 16 SerDes | 라우터·스위치·모뎀 칩 사이를 수십 Gbps로 잇는 직렬 링크. |
| 17 네트워크 칩 | 모든 라우터·스위치 안에서 ns 단위로 길을 고르는 스위칭 칩과 NIC. |
| 18 RF 반도체 | 두 휴대폰의 Wi-Fi·5G RF 칩: 증폭기, 필터, 믹서, 데이터 변환기. |
| 19 광 반도체 | ONT와 백본의 레이저·광검출기, 데이터센터의 광 트랜시버. |
| 20 데이터센터 | TURN·SFU·시그널링 서버가 있는 리프-스파인 망. |
| 21 클라우드 | 사용자와 가까운 리전에 릴레이를 두고, 로드밸런서로 나눈다. |
| 22 보안 | TLS로 로그인, DTLS로 열쇠를 나누고 SRTP로 종단 간 암호화. |
| 23 운영 | RTT·손실·지터 측정, 병목 구간 찾기. |
그리고 이 여행에서 반복해서 나타난 큰 원리 몇 가지를 남겨 두자.
- 계층은 서로를 모른다. 통화 앱은 지금 패킷이 전파인지 빛인지 모르고, 백본 라우터는 그 안에 얼굴이 들었는지 모른다. 정해진 헤더만 읽고 넘기기 때문에 각 층이 따로 발전할 수 있다(3장).
- 모든 경계에서 신호가 바뀐다. 빛 → 전기 → 전파 → 전기 → 빛. 바뀌는 곳마다 반도체(16~19장)가 있다.
- 빛의 속도는 협상할 수 없다. 먼 통화의 지연은 거리가 정하고, 우리가 줄일 수 있는 것은 양 끝의 처리와 기다림이다.
- 실시간에서는 늦은 것이 없는 것이다. 그래서 재전송 대신 버퍼, FEC, 은닉, 적응으로 버틴다.
- 가까운 곳에 둔다. 릴레이, 서버, CDN, GPU를 사용자 가까이 둘수록 빨라진다(10·21장).
25장에서는 봉화와 전신에서 6G와 양자 통신까지, 이 모든 층이 어떻게 하나씩 쌓여 왔는지 역사를 따라간다. 26장의 용어집과 종합 퀴즈로 전체를 점검할 수 있다. 직접 확인해 보고 싶다면, 영상 통화 중에 브라우저의 WebRTC 내부 통계 페이지(크롬의 chrome://webrtc-internals)를 열어 보자. 이 장에서 본 RTT, 지터, 손실, 비트레이트, 선택된 ICE 후보가 실시간으로 나온다.
핵심 정리
- 영상 통화 패킷은 카메라 → 코덱 → RTP/SRTP → UDP/IP → Wi-Fi → NAT → FTTH → 라우터·백본 → (필요하면 TURN) → 5G 코어·기지국 → RF 칩 → 지터 버퍼 → 디코더 → 화면을 지나며, 신호는 빛·전기·전파로 여러 번 모습을 바꾼다.
- 통화를 맺으려면 DNS·TLS로 서버에 붙고, SDP로 조건을 맞추는 시그널링을 한 뒤, STUN·TURN 후보를 ICE로 시험해 NAT를 통과할 길을 찾고, DTLS로 SRTP 열쇠를 나눈다.
- 대화가 자연스러우려면 입-귀 지연이 한쪽 150 ms 이내여야 한다. 국내 통화에서는 네트워크보다 휴대폰 안(캡처·인코딩·지터 버퍼·디코딩·표시)이 더 오래 걸리고, 먼 나라와의 통화는 빛의 속도가 바닥을 정한다.
- 실시간 미디어는 늦은 패킷을 버린다. 지터 버퍼는 지연과 끊김을 맞바꾸고, FEC·손실 은닉·비트레이트 적응이 나쁜 네트워크를 견디게 한다.
- 720p 통화는 한 방향 약 2 Mbps, 1시간 양방향 약 1.8 GB 수준이다. 정지궤도 위성은 거리 때문에, AI 챗봇은 데이터센터 안의 계산 때문에 병목의 위치가 달라진다.
확인 퀴즈
영상 통화의 영상 패킷을 TCP가 아닌 UDP로 보내는 가장 큰 이유는?
STUN 서버가 하는 일로 옳은 것은?
서울-부산 영상 통화의 한쪽 지연 약 100 ms 가운데 가장 큰 몫을 차지하는 것은 보통 어디인가?
지터 버퍼를 깊게(예: 40 → 150 ms) 하면 일어나는 일은?
카페 Wi-Fi가 붐벼서 대역폭이 갑자기 줄었는데도 앱이 같은 비트레이트로 계속 보내면 가장 먼저 나타나는 현상은?
정지궤도 위성을 쓰는 비행기 Wi-Fi에서 영상 통화가 어색한 주된 이유는?