cloudflare2026년 7월 31일

MoQ를 위한 API: 자체 격리 릴레이 프로비저닝 (새 탭에서 열림)

Cloudflare는 MoQ(Media over QUIC)를 애플리케이션용으로 운영할 수 있도록 격리된 릴레이와 인증·권한 관리 기능을 추가했다. 프로비저닝 API나 대시보드에서 릴레이를 생성하면 별도 서버나 로드 밸런서 없이 Cloudflare 전역 네트워크에 수초 내 배포된다. 퍼블리셔와 구독자에게 서로 다른 토큰을 발급해 실시간 미디어 스트림의 접근 권한도 분리할 수 있다. ## MoQ의 구조와 장점 - MoQ는 IETF에서 개발 중인 공개 표준 기반의 publish/subscribe 프로토콜이다. - 퍼블리셔는 이름이 지정된 데이터 스트림을 전송하고, 구독자는 스트림 이름으로 원하는 데이터를 요청한다. - 릴레이는 데이터 내용을 해석하지 않고 스트림을 구독자들에게 복제·전달한다. - 하나의 프로토콜로 라이브 비디오, 화상 통화, 저지연 메시징 등 다양한 실시간 데이터를 처리할 수 있다. - QUIC을 기반으로 하므로 HTTP/3와 같은 낮은 지연 특성을 활용한다. - 애플리케이션이 직접 미디어 서버를 구축하거나 대규모 fan-out 서버를 운영할 필요가 줄어든다. ## 공개 프리뷰의 한계 - Cloudflare는 지난해 330개 이상의 도시에 있는 서버를 MoQ 릴레이로 개방했다. - 인증 없이 누구나 사용할 수 있어 프로토콜 테스트와 클라이언트 개발에 적합했다. - 그러나 인증이 없으면 누가 퍼블리시하거나 구독할 수 있는지 통제할 수 없다. - 예를 들어 경매 서비스에서는 시청자가 방송자의 트랙을 탈취하지 못하도록 퍼블리셔와 구독자의 권한을 분리해야 한다. - 따라서 기밀성, 인증, 역할 기반 접근 제어가 필요한 운영 환경에는 기존 공개 릴레이를 사용할 수 없었다. ## Cloudflare 릴레이의 격리 방식 - 릴레이를 생성해도 VM, 컨테이너, 전용 프로세스가 새로 실행되는 것은 아니다. - 기존 Cloudflare 글로벌 네트워크 위에 애플리케이션별 격리된 범위를 생성한다. - 각 범위는 다음을 분리한다. - 애플리케이션의 네임스페이스 - 미디어 트랙과 객체 - 접속 가능한 클라이언트 - 퍼블리시·구독 권한 - 클라이언트는 Anycast 엔드포인트에 접속하고, Cloudflare가 전 세계 네트워크로 라우팅한다. - 지역 선택, 용량 산정, 서버 배포, 로드 밸런서 설정 없이 즉시 사용할 수 있다. - 웹 호스팅에서 새 서버를 띄우는 것보다 가상 호스트를 추가하는 방식에 가깝다. ## 프로비저닝 API와 토큰 권한 - 프로비저닝 API는 미디어 데이터를 처리하지 않는 제어 평면이다. - 관리 대상은 두 가지다. - **Relay**: 애플리케이션별로 격리된 MoQ 실행 범위 - **Token**: 특정 릴레이에 대한 작업 권한을 부여하는 인증 정보 - 토큰은 다음 권한을 조합할 수 있다. - `publish` - `subscribe` - `publish`와 `subscribe` 모두 - 토큰마다 만료 시간을 설정할 수 있고, 개별적으로 폐기할 수 있다. - 기본적으로 토큰 권한은 릴레이 전체에 적용된다. - 현재는 세부 트랙별 권한보다 릴레이 단위 권한을 제공하며, 향후 더 정교한 권한 체계를 개발할 예정이다. - Cloudflare는 MoQ Transport draft-14와 draft-16 및 인증 기능을 지원한다. ## 릴레이 생성과 기본 토큰 - HTTP API에서는 릴레이 이름만 지정해 생성할 수 있다. - 생성 결과로 릴레이 ID와 기본 토큰 2개가 반환된다. - 퍼블리시와 구독이 모두 가능한 토큰 - 구독만 가능한 토큰 - 추가 토큰을 생성해 시청자, 방송자, 운영 도구 등 역할별로 권한을 세분화할 수 있다. - 예를 들어 시청자용 토큰은 `subscribe`만 허용하고, 2027년 1월 1일 만료되도록 설정할 수 있다. - 동일한 작업은 Cloudflare 대시보드의 **Media > Realtime > MoQ Relay** 메뉴에서도 수행할 수 있다. - 릴레이는 베타 기간 동안 무료로 제공된다. ## 퍼블리셔와 구독자의 연결 - 방송자에게는 `publish` 권한이 포함된 토큰을 제공한다. - 시청자에게는 `subscribe` 전용 토큰을 제공한다. - 클라이언트는 MoQ 세션을 열 때 토큰을 전달한다. - 릴레이는 토큰의 권한을 확인해 퍼블리시와 구독 작업을 허용하거나 거부한다. - 토큰은 MoQ 접속 URL 경로를 통해 전달되며, `moq-rs` 같은 오픈소스 도구와 FFmpeg를 이용해 fragmented MP4 스트림을 퍼블리시할 수 있다. ## 실용적인 결론 실시간 영상이나 저지연 데이터 서비스를 구축한다면 Cloudflare MoQ 릴레이를 통해 서버 운영과 확장 부담을 줄일 수 있다. 운영 시에는 방송자와 시청자 토큰을 반드시 분리하고, 만료 기간과 폐기 정책을 설정해 권한 탈취 위험을 최소화하는 것이 좋다.

quiccloudflarejwtcdn+3

cloudflare2026년 5월 12일

‘idle’이 유휴 상태가 아닐 때: 리눅스 커널 최적화가 QUIC 버그가 된 과정 (새 탭에서 열림)

CUBIC의 혼잡 윈도우(cwnd)가 심각한 손실 이후 최솟값에 고정되어 회복하지 못하는 QUIC 버그가 발견됐다. 손실이 2초 후 완전히 사라졌는데도 quiche의 CUBIC은 회복 상태와 혼잡 회피 상태를 RTT 주기로 반복하며 전송량을 늘리지 못했다. 원인은 Linux TCP CUBIC의 유휴 상태 최적화를 QUIC에 적용하는 과정에서 `bytes_in_flight == 0` 상황이 잘못 해석된 데서 비롯됐으며, 결국 매우 작은 수정으로 문제가 해결됐다. ## CUBIC과 혼잡 윈도우의 역할 - 혼잡 제어 알고리즘(CCA)은 송신자가 네트워크에 동시에 전송할 수 있는 데이터의 상한인 `cwnd`를 조절한다. - `cwnd`가 크면 한 번에 더 많은 데이터를 전송하고, 작으면 전송 속도가 제한된다. - 손실 기반 알고리즘인 CUBIC은 다음과 같은 전제를 따른다. - 패킷 손실이 없으면 네트워크 여유가 있다고 보고 전송률을 증가시킨다. - 패킷 손실이 발생하면 네트워크 용량을 초과했다고 판단해 전송률을 줄인다. - CUBIC은 Linux의 기본 TCP 혼잡 제어기이며, Cloudflare의 QUIC 구현인 quiche에서도 기본값으로 사용된다. ## 재현 조건과 이상 증상 - 문제는 초반에 심각한 패킷 손실이 발생한 뒤 회복하는 통합 테스트에서 발견됐다. - 테스트 조건: - localhost에서 실행되는 HTTP/3 클라이언트와 서버 - RTT 10ms - 10MB 파일 다운로드 - CUBIC 사용 - 연결 시작 후 2초 동안 무작위 30% 패킷 손실 - 이후 패킷 손실 제거 - 10초 타임아웃 - 정상이라면 손실 구간에서 `cwnd`가 감소한 뒤, 손실이 사라지면 다시 증가해 4~5초 안에 다운로드를 완료해야 한다. - 그러나 100회 반복 시 약 60~61%가 10초 안에 완료되지 못했다. ## 손실이 없는데도 회복하지 못한 CUBIC - 2초 이후 패킷 손실은 완전히 사라졌지만 `bytes_in_flight`와 `cwnd`는 계속 최솟값에 머물렀다. - CUBIC은 약 6.7초 동안 회복 상태와 혼잡 회피 상태를 999회 반복했다. - 상태 전환 주기는 약 14ms로, 연결의 RTT 10ms와 비슷했다. - `cwnd`는 2700바이트, 즉 최대 세그먼트 크기의 패킷 2개 수준에 고정됐다. - 다운로드 서버 입장에서는 클라이언트의 ACK가 도착할 때마다 전송 중인 바이트가 0이 되고, 다시 두 패킷을 보내는 과정이 반복됐다. - 이 ACK 기반의 전송 리듬이 CUBIC의 상태 전환을 매 RTT마다 잘못 촉발한 것으로 분석됐다. ## Reno 비교를 통한 CUBIC 특화 문제 확인 - 동일한 테스트를 Reno로 실행한 결과 100% 성공했다. - Reno는 손실이 끝난 뒤 정상적으로 `cwnd`를 증가시키고 다운로드를 완료했다. - 따라서 네트워크 시뮬레이션이나 QUIC 전반의 문제가 아니라 CUBIC 구현의 특정 로직에 문제가 있음을 확인했다. ## Linux TCP의 유휴 상태 최적화 - 문제의 출발점은 2017년 Linux 커널에 적용된 TCP CUBIC 최적화였다. - 기존 구현에서는 CUBIC의 시간 기준점인 `epoch`가 연결 시작 시점과 손실 발생 시점에만 갱신됐다. - 애플리케이션이 오랫동안 유휴 상태에 있다가 다시 전송하면 `현재 시각 - epoch_start` 값이 지나치게 커질 수 있었다. - 그 결과 CUBIC의 목표 전송률과 증가 기울기가 비정상적으로 커지고, `ca->cnt`가 지나치게 작아질 수 있었다. - Linux는 이를 완화하기 위해 `ca->cnt`에 최솟값 2를 적용했으며, 특히 `slow_start_after_idle`이 비활성화된 경우 유휴 후 위험한 cwnd 증가가 발생할 수 있었다. - 이 최적화는 TCP에서 애플리케이션이 전송을 제한한 구간을 혼잡으로 오인하지 않도록 하기 위한 것이었지만, QUIC 구현에 이식되는 과정에서 `bytes_in_flight == 0`인 상황이 예상과 다르게 작동했다. ## 문제의 본질 - CUBIC은 실제 패킷 손실이 없더라도 전송 중인 바이트가 0이 되는 순간을 유휴 또는 특수한 상태로 처리한다. - 하지만 이 테스트에서는 연결이 유휴한 것이 아니라, `cwnd`가 두 패킷으로 제한되어 ACK를 받은 뒤 잠시 `bytes_in_flight`가 0이 되는 상황이 반복됐다. - 결과적으로 CUBIC의 유휴 상태 처리와 회복 상태 전환이 ACK 클록과 결합되어 매 RTT마다 잘못된 상태 변화를 일으켰다. - 그 결과 혼잡 윈도우가 최소값에서 탈출하지 못하고, 손실이 사라진 뒤에도 전송 속도가 회복되지 않았다. ## 실용적인 시사점 - 혼잡 제어 테스트는 정상적인 성장 구간뿐 아니라, `cwnd`가 최솟값으로 떨어진 뒤 회복하는 시나리오도 반드시 포함해야 한다. - `bytes_in_flight == 0`은 실제 애플리케이션 유휴 상태와 ACK 직후의 일시적인 상태를 구분하지 않으면 오판의 원인이 될 수 있다. - TCP 최적화 코드를 QUIC에 이식할 때는 전송 모델과 ACK 처리 방식의 차이를 검증해야 한다. - 이 사례는 상태 전환 횟수와 RTT 상관관계를 관찰하는 qlog 기반 계측이 혼잡 제어 버그를 찾는 데 효과적임을 보여준다.

quiclinux-kernelhttp3tcp+3

slack2026년 3월 31일

커스텀에서 오픈으로: Prometheus를 활용한 확장 가능한 네트워크 프로빙 및 HTTP/3 준비성 (새 탭에서 열림)

Slack은 HTTP/3 도입 과정에서 기존 모니터링 도구가 QUIC/UDP 기반 엔드포인트를 측정하지 못하는 관측성 공백을 발견했다. 이를 해결하기 위해 Prometheus Blackbox Exporter에 `quic-go` 기반 HTTP/3 프로빙 기능을 추가하고 오픈소스로 공개했다. 그 결과 HTTP/1.1, HTTP/2, HTTP/3를 Grafana에서 통합 관찰하고 더 정확한 알림과 장애 분석이 가능해졌다. ### 기존 모니터링 도구의 한계 - Slack은 AWS Availability Zone 간 내부 트래픽과 인터넷에서 인프라로 유입되는 외부 트래픽을 상용 SaaS 및 자체 도구로 측정해 왔다. - HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용한다. - 기존 SaaS 관측성 도구 대부분은 HTTP/3 프로빙을 기본 지원하지 않았다. - 핵심 모니터링 도구인 Prometheus Blackbox Exporter(BBE)에도 QUIC 네이티브 지원이 없었다. - 수십만 개의 HTTP/3 엔드포인트를 측정할 수 없어 HTTP/2로의 회귀, 실제 왕복 시간(RTT), 클라이언트 관점의 성능 변화를 파악하기 어려웠다. ### `quic-go` 기반 HTTP/3 프로브 구현 - 인턴 Sebastian Feliciano가 BBE에 QUIC 지원을 구현하고 오픈소스로 기여했다. - Go용 QUIC 라이브러리로 널리 사용되는 `quic-go`를 선택했다. - HTTP/3 전송 계층을 다음과 같이 구성해 기존 HTTP 클라이언트에 연결했다. ```go http3Transport := &http3.Transport{ TLSClientConfig: tlsConfig, QUICConfig: &quic.Config{}, } client = &http.Client{ Transport: http3Transport, } ``` - BBE의 기존 설정 방식과 아키텍처를 유지해 새로운 프로브도 기존 기능과 조합할 수 있도록 설계했다. - 이를 통해 HTTP/3 엔드포인트에 대해 설정 가능한 Prometheus 프로브가 제공됐다. ### 오픈소스 기여와 사내 통합 - 새로운 기능을 Prometheus BBE에 upstream 기여해 다른 조직도 사용할 수 있게 했다. - 오픈소스 PR의 병합을 기다리는 동안, Slack은 새 기능을 활용하는 사내 프로빙 시스템도 별도로 설계했다. - 결과적으로 외부 공개 기능과 Slack 인프라에 맞춘 운영 시스템을 함께 확보했다. ### 통합 관측성과 운영 개선 - Grafana에서 HTTP/1.1, HTTP/2, HTTP/3 지표를 하나의 화면에서 확인할 수 있게 됐다. - 프로토콜별 성능을 비교하고 다른 텔레메트리와 상관관계를 분석하기 쉬워졌다. - HTTP/3 엔드포인트의 상태와 성능을 기반으로 더 정확하고 신뢰성 높은 알림을 만들 수 있게 됐다. - 장애 발생 시 관련 지표를 한곳에서 확인해 원인 분석과 디버깅 속도를 높였다. ### 향후 확장 방향 - **SNI 라우팅 테스트** - 공유 IP를 사용하는 CDN이나 멀티테넌트 로드밸런서에서 요청한 호스트명이 올바른 백엔드로 라우팅되는지 검증한다. - 올바른 TLS 인증서가 반환되는지도 확인해 잘못된 라우팅을 방지할 수 있다. - **종단 간 네트워크 경로 시각화** - 단순한 성공/실패 확인을 넘어 모니터링 에이전트부터 서비스까지의 네트워크 홉을 시각화한다. - 지연 증가나 패킷 손실이 어느 구간에서 발생했는지 파악할 수 있다. ### 실무적인 시사점 - 새로운 프로토콜이나 인프라로 마이그레이션하기 전에 먼저 관측성을 확보해야 한다. - 기존 도구에 기능이 없을 때 직접 구현하고 오픈소스로 공유하면 조직과 커뮤니티 모두의 비용을 줄일 수 있다. - HTTP/3 도입을 검토하는 팀이라면 Prometheus Blackbox Exporter의 QUIC 프로브를 활용해 마이그레이션 전후 성능과 장애를 지속적으로 비교하는 것이 좋다.

quicobservabilitygoprometheus+4

cloudflare2026년 3월 5일

'Silent drop' 해결: (새 탭에서 열림)

Cloudflare는 Cloudflare One Client에 '동적 경로 MTU 발견(Dynamic Path MTU Discovery, PMTUD)' 기술을 도입하여, 네트워크 경로상에서 패킷 크기 제한으로 인해 연결이 끊기는 'PMTUD 블랙홀' 문제를 해결했습니다. 기존의 수동적인 방식 대신 MASQUE 프로토콜을 활용한 능동적 탐색 방식을 채택함으로써, 사용자는 LTE/5G나 위성 네트워크와 같은 제한적인 환경에서도 패킷 손실 없이 안정적인 연결을 유지할 수 있습니다. 이 기술은 현대적인 보안 암호화로 인해 커진 패킷을 네트워크 환경에 맞춰 실시간으로 최적화하여 하이브리드 작업자와 긴급 구조대원 등의 연결성을 획기적으로 개선합니다. **현대적 보안과 레거시 인프라의 충돌** - 표준 이더넷의 최대 전송 단위(MTU)는 보통 1500바이트이지만, 현대적인 보안 요구사항(FIPS 140-2 준수 등)으로 인해 패킷 내 암호화 및 메타데이터 오버헤드가 증가하고 있습니다. - LTE/5G, 위성 링크, 공공 안전 네트워크 등 일부 환경은 MTU 제한이 1500바이트 미만인 경우가 많아, 보안 패킷이 해당 라우터를 통과하지 못하는 상황이 발생합니다. - 원래는 라우터가 ICMP 메시지를 통해 패킷이 너무 크다는 사실을 알려야 하지만, 방화벽이나 중간 장비(middlebox)가 이 메시지를 차단하면 보낸 쪽에서 이유도 모른 채 데이터가 사라지는 '블랙홀' 현상이 발생하여 연결이 끊어집니다. **능동적 프로빙을 통한 PMTUD 구현** - Cloudflare는 RFC 8899 표준을 기반으로 한 능동적 경로 MTU 발견 방식을 구현하여 레거시 ICMP 피드백에 대한 의존도를 없앴습니다. - Cloudflare의 오픈 소스 QUIC 라이브러리로 구축된 MASQUE 프로토콜을 활용해, 클라이언트가 Cloudflare 에지 서버로 다양한 크기의 암호화된 프로브(Probe) 패킷을 직접 보냅니다. - 지원되는 MTU 범위의 상한선부터 중간값까지 테스트하며 에지 서버의 응답 여부를 확인하고, 해당 경로에 정확히 맞는 MTU 크기를 찾아냅니다. - 사용자가 Wi-Fi(MTU 1500)에서 셀룰러(MTU 1300) 환경으로 이동하더라도, 클라이언트가 실시간으로 가상 인터페이스의 MTU를 조정하여 세션 중단 없이 연결을 유지합니다. **실제 환경에서의 연결 안정성 강화** - 차량용 라우터를 사용하는 긴급 구조대원의 경우, 복잡한 NAT 트래버스나 우선순위 라우팅 층을 거치며 MTU가 급격히 줄어들 때 발생하던 CAD(컴퓨터 지원 파견) 시스템의 연결 끊김 현상을 방지합니다. - 해외 호텔이나 공공 네트워크를 사용하는 하이브리드 작업자는 이중 NAT나 노후화된 중간 장비가 있는 환경에서도 화상 회의나 파일 전송이 끊기지 않는 최적화된 경로를 수 초 내에 확보할 수 있습니다. - 이 기술은 애플리케이션 계층에서 하위 네트워크의 불안정성을 느끼지 못하도록 '스티키(Sticky)'한 연결 상태를 제공합니다. 현재 Windows, macOS, Linux 환경에서 MASQUE 프로토콜을 사용하는 Cloudflare One Client 사용자라면 누구나 이 기능을 무료로 이용할 수 있습니다. 네트워크 변동성이 큰 환경에서 업무를 수행하는 팀이라면 MASQUE 프로토콜 활성화를 통해 패킷 드롭 없는 안정적인 연결을 경험해 보기를 권장합니다.

quiccloudflarenetworkingencryption+4

cloudflare2026년 3월 5일

더 빠른 SASE 클라이언트 (새 탭에서 열림)

Cloudflare는 Zero Trust 보안 환경에서 발생하는 프록시 성능 저하 문제를 해결하기 위해 SASE 클라이언트의 프록시 모드 아키텍처를 완전히 재설계했습니다. 기존의 WireGuard 기반 Layer 3 터널링 대신 QUIC 프로토콜을 활용한 직접 Layer 4 프록싱 방식을 도입하여, 보안 수준을 유지하면서도 데이터 전송 속도를 2배로 높이고 지연 시간을 대폭 단축했습니다. 이번 업데이트를 통해 사용자들은 고해상도 영상 스트리밍이나 대용량 파일 전송 시에도 프록시 사용 전과 다름없는 쾌적한 인터넷 환경을 경험할 수 있게 되었습니다. ### 기존 아키텍처의 한계와 smoltcp의 병목 현상 * **Layer 4와 Layer 3의 충돌**: 초기 Cloudflare One 클라이언트는 호환성을 위해 SOCKS5/HTTP 프록시를 사용했으나, 기반 터널은 Layer 3(L3) 프로토콜인 WireGuard로 구축되어 L4 TCP 트래픽을 L3 패킷으로 변환해야 하는 기술적 난제가 있었습니다. * **사용자 공간 TCP 스택의 제약**: 커널 수준의 변환이 어려운 멀티 플랫폼 환경을 지원하기 위해 Rust 기반의 사용자 공간 TCP 구현체인 `smoltcp`를 사용했으나, 이는 임베디드 시스템에 최적화되어 있어 최신 TCP 기능을 지원하지 못했습니다. * **이중 변환 오버헤드**: 클라이언트에서 L4를 L3 패킷으로 쪼개고, Cloudflare 에지(Edge)에서 이를 다시 L4 스트림으로 복구하는 과정이 반복되면서 고속 광랜 환경에서도 성능 상한선이 발생하는 병목 현상이 나타났습니다. ### QUIC 및 MASQUE를 활용한 직접 L4 프록싱 * **아키텍처의 근본적 변화**: 프록시 모드에서 WireGuard 사용을 중단하고, QUIC의 확장 프로토콜인 MASQUE를 도입하여 트래픽을 Layer 4 수준에서 직접 처리하도록 변경했습니다. * **HTTP/3 CONNECT 메서드 활용**: RFC 9114 표준을 따르는 HTTP/3의 CONNECT 메서드를 사용하여 브라우저의 요청을 L3 패킷으로 분해하지 않고 QUIC 스트림에 직접 캡슐화합니다. * **기술적 이점**: `smoltcp` 레이어를 완전히 제거하여 패킷 처리 오버헤드를 없앴으며, QUIC 고유의 현대적인 혼잡 제어(Congestion Control) 및 흐름 제어 기능을 활용할 수 있게 되었습니다. * **최적화 가능성**: 클라이언트와 Cloudflare 에지 사이의 QUIC 파라미터를 세밀하게 조정하여 네트워크 환경에 최적화된 성능 구현이 가능해졌습니다. ### 새로운 프록시 모드의 주요 수혜 사례 * **타사 VPN과의 공존**: 특정 사내 자원 접속을 위해 레거시 VPN을 병행 사용해야 하는 환경에서, 성능 저하 없이 웹 트래픽에만 Zero Trust 보안을 계층적으로 적용할 수 있습니다. * **고대역폭 애플리케이션 분할**: 브라우저 트래픽만 Cloudflare Gateway로 라우팅하는 환경에서 고화질 콘텐츠 스트리밍이나 대규모 데이터셋 처리가 원활해집니다. * **개발자 및 파워 유저**: CLI 도구나 스크립트에서 SOCKS5 보조 리스너를 사용하는 개발자들이 원격 API 호출 및 데이터 전송 시 Cloudflare 글로벌 네트워크의 저지연 이점을 그대로 누릴 수 있습니다. ### 적용 방법 및 확인 사항 새로운 성능 개선 사항을 적용하려면 Cloudflare One 클라이언트 버전이 **2025.8.779.0 이상**(Windows, macOS, Linux)이어야 합니다. 관리자 대시보드의 장치 프로필 설정에서 서비스 모드를 'Local proxy mode'로, 터널 프로토콜을 'MASQUE'로 설정해야 합니다. 사용 중인 프로토콜은 터미널에서 `warp-cli settings | grep protocol` 명령어를 통해 직접 확인할 수 있습니다.

quiccloudflaresasehttp3+4

cloudflare2026년 1월 13일

이란의 인터넷 차단에 대해 우리가 (새 탭에서 열림)

2025년 말 이란 내 경제적 불만과 정권 교체 요구로 촉발된 대규모 시위에 대응하여 이란 정부가 전국적인 인터넷 차단 조치를 단행했습니다. Cloudflare Radar 데이터 분석 결과, 2026년 1월 8일부터 이란의 인터넷 트래픽은 사실상 전무한 상태로 떨어졌으며 이는 과거 2019년과 2022년의 사례와 유사한 국가 차원의 의도적인 차단으로 확인됩니다. 현재 이란은 전 세계 인터넷으로부터 거의 완전히 고립된 상태이며, 이러한 기술적 단절은 시위 확산을 막기 위한 정부의 강력한 통제 수단으로 활용되고 있습니다. **1월 8일 발생한 급격한 연결 단절** - 1월 8일 11:50(UTC)경, 이란 네트워크에서 공고되는 IPv6 주소 공간이 98.5% 급감하며 글로벌 인터넷에서 해당 주소로 접근할 수 있는 경로가 사라졌습니다. - 이로 인해 인간이 생성하는 트래픽 중 IPv6가 차지하는 비중이 12%에서 2%로 떨어졌으며, 100분 뒤에는 사실상 0%에 수렴했습니다. - 같은 날 16:30~17:00(UTC) 사이, MCCI(AS197207), IranCell(AS44244), TCI(AS58224) 등 이란 주요 통신사들의 트래픽이 90% 이상 빠지기 시작해 18:45(UTC)에는 국가 전체 트래픽이 0에 도달했습니다. **일시적인 연결 복구와 제한된 접근** - 차단 다음 날인 1월 9일, 테헤란 대학교(AS29068)와 샤리프 공과대학교(AS12660) 등 일부 주요 교육 기관의 네트워크 연결이 몇 시간 동안 일시적으로 복구되었다가 다시 중단되었습니다. - Cloudflare의 공용 DNS resolver(1.1.1.1)에 대한 요청 트래픽이 잠시 급증하는 현상이 관찰되었으나, 곧 이전 최고치의 0.01% 미만 수준으로 다시 떨어졌습니다. **전면 차단에 앞선 기술적 검열 징후** - 전면적인 인터넷 셧다운이 발생하기 수일 전인 12월 31일부터 주요 네트워크에서 HTTP/3 및 QUIC 프로토콜의 사용 비중이 40%에서 5% 미만으로 급격히 감소했습니다. - 이는 정부가 전면 차단을 시행하기 전, 고도화된 레이어 기반의 필터링과 화이트리스트 시스템을 적용하여 특정 통신 방식을 먼저 차단했음을 시사합니다. **지속되는 셧다운 상황** - 1월 10일 이후 현재까지 이란의 인터넷 트래픽은 회복될 기미를 보이지 않고 있으며, 전 세계와 연결된 통로가 대부분 막혀 있는 상태입니다. 이란 내부의 실시간 연결 상태와 네트워크별 지표는 Cloudflare Radar의 트래픽 및 라우팅 페이지를 통해 지속적으로 모니터링할 수 있습니다.

quicdnsbgpipv6+4