cloudflare2026년 8월 3일

Cloudflare Workers와 Containers, 이제 인바운드 TCP 연결 및 gRPC 지원 (새 탭에서 열림)

Cloudflare는 Workers에 인바운드 TCP 소켓을 직접 처리하는 `connect(socket)` 기능과 컨테이너 기반의 양방향 gRPC 지원을 추가했습니다. 이를 통해 클라이언트의 TCP 연결을 Worker, Durable Object, Container로 전달하고, 다양한 언어로 작성된 gRPC 서버를 Cloudflare 네트워크에서 실행할 수 있습니다. 특히 저지연·양방향 통신이 중요한 음성 AI와 실시간 애플리케이션을 클라이언트 가까이에서 처리하는 것이 목표입니다. ## Workers의 인바운드 TCP 지원 - 기존 Workers는 주로 HTTP 요청을 처리하거나 아웃바운드 TCP 연결을 생성하는 방식이었지만, 이제 `connect(socket)` 핸들러로 들어오는 TCP 연결을 받을 수 있습니다. - 소켓은 `readable`과 `writable` 스트림으로 제공되며, 다음과 같이 데이터를 읽고 쓸 수 있습니다. - `socket.writable.getWriter()`로 데이터 전송 - `socket.readable.pipeTo(...)`로 다른 소켓에 데이터 전달 - TCP 연결을 Worker에서 직접 종료하거나, 다른 Worker·Durable Object·Container로 라우팅할 수 있습니다. ## Durable Objects와 Container로 소켓 전달 - Worker는 Durable Object의 `connect()` 메서드를 호출해 인바운드 소켓을 특정 객체로 전달할 수 있습니다. - Durable Object는 양방향 스트림을 연결해 클라이언트와 서버 사이의 바이트를 그대로 중계할 수 있습니다. - Durable Object에서 Container의 TCP 포트에 연결한 뒤 다음과 같이 양방향 파이프를 구성합니다. - 클라이언트 → Container - Container → 클라이언트 - Container에서는 Python, Go 등 원하는 언어와 TCP 서버 구현을 사용할 수 있습니다. - 따라서 특정 RPC 프레임워크에 종속되지 않고, TCP를 사용하는 어떤 프로토콜이나 프로그램도 Cloudflare에서 처리할 수 있습니다. ## Spectrum을 이용한 TCP 진입점 - Cloudflare Spectrum은 HTTP가 아닌 TCP·UDP 트래픽을 Cloudflare 네트워크로 받아들이는 인그레스 프록시입니다. - 새로운 Spectrum 애플리케이션 유형에서는 유입된 TCP 연결을 지정한 Worker의 `connect(socket)` 핸들러로 전달할 수 있습니다. - 결과적으로 클라이언트부터 Cloudflare Worker, Durable Object, Container 내부 서버까지 전체 네트워크 경로를 제어할 수 있습니다. ## Cloudflare Containers의 양방향 gRPC - gRPC는 HTTP/2와 TCP를 기반으로 하는 RPC 프레임워크로, 모바일 앱·분산 시스템·음성 AI 서비스에서 널리 사용됩니다. - 실시간 음성 애플리케이션은 단일 연결에서 클라이언트와 서버가 모두 지속적으로 메시지를 보내야 하므로 양방향 스트리밍이 중요합니다. - Cloudflare의 새 기능을 사용하면 다음과 같은 gRPC 서버를 Container에 배포할 수 있습니다. - 모든 언어로 작성된 gRPC 서버 - 클라이언트와 서버 간 full-duplex 양방향 스트리밍 - 지속적인 단일 TCP 연결 - 예시 gRPC 서버는 연결 직후 `connected` 메시지를 보내고, 클라이언트 메시지마다 `echo` 응답을 보내며, 연결 종료 시 `goodbye` 메시지를 전송합니다. - Cloudflare는 330개 이상의 위치에서 요청을 처리하므로, 서버를 사용자와 가까운 위치에서 실행해 지연 시간을 줄일 수 있습니다. ## Workers 기반 gRPC API - Workers에서는 gRPC 서버를 직접 구현하거나 기존 gRPC 서버를 호출할 수 있습니다. - 개발자는 `gRPC-web` 방식으로 코드를 작성하고, Cloudflare가 요청과 응답을 실제 gRPC 형식으로 변환합니다. - 지원 범위에는 다음이 포함됩니다. - 단일 요청·응답 방식인 unary RPC - 서버가 여러 메시지를 보내는 server-streaming RPC - Container로 소켓을 직접 전달하는 양방향 스트리밍 gRPC - 이 기능을 활용하면 기존 gRPC 생태계를 유지하면서 Cloudflare의 글로벌 네트워크와 Workers의 라우팅 기능을 함께 사용할 수 있습니다. ## 음성 AI와 실시간 서비스에 대한 의미 - AI 음성 비서, 실시간 받아쓰기, 음성 기반 에이전트는 모델·클라이언트·지원 서비스 사이의 낮은 지연 시간이 필수적입니다. - WebSockets와 Durable Objects도 적합하지만, 이미 gRPC를 사용하는 기존 시스템은 새 인프라로 전면 재작성할 필요가 줄어듭니다. - Cloudflare는 TCP 연결을 직접 전달하므로 음성 데이터나 스트리밍 추론 요청처럼 연결을 오래 유지하는 서비스에 적합합니다. - 해당 기능은 현재 프라이빗 베타로 제공되며, 사용을 위해 별도 신청이 필요합니다. 실시간 음성 AI나 기존 gRPC 시스템을 Cloudflare에 배포하려는 경우, `connect(socket)`을 이용해 Worker–Durable Object–Container 간 양방향 스트림을 구성하는 방식이 유용합니다. 다만 현재는 프라이빗 베타이므로 실제 도입 전 지원 프로토콜, 연결 수명, 지연 시간, 비용 및 운영 제한을 확인하는 것이 좋습니다.

tcpcloudflare-workersgrpcdurable-objects+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 기반 계측이 혼잡 제어 버그를 찾는 데 효과적임을 보여준다.

tcplinux-kernelquichttp3+3

cloudflare2026년 3월 31일

Programmable Flow Protection 소개: Magic Transit 고객을 위한 맞춤형 DDoS 완화 로직 (새 탭에서 열림)

클라우드플레어는 매직 트랜짓(Magic Transit) 고객이 자신의 네트워크 환경에 맞춘 DDoS 방어 로직을 직접 설계하고 배포할 수 있는 '프로그래밍 가능한 플로우 보호(Programmable Flow Protection)' 기능을 출시했습니다. 이 기능은 표준화되지 않은 독자적인 UDP 프로토콜을 사용하는 기업들이 eBPF 프로그램을 통해 트래픽의 정당성을 직접 판단하게 함으로써, 기존의 일률적인 차단 방식이 가졌던 오탐 문제를 해결합니다. 고객은 클라우드플레어의 글로벌 네트워크 인프라 위에서 직접 작성한 코드를 실행해 대규모 공격을 정교하고 유연하게 방어할 수 있습니다. ### 커스텀 UDP 프로토콜 방어의 한계 극복 * 기존 DDoS 방어 시스템은 TCP, DNS, NTP 등 잘 알려진 프로토콜의 특성을 활용해 공격을 식별하지만, 기업 고유의 커스텀 UDP 프로토콜은 내부 구조를 알 수 없어 정교한 대응이 어려웠습니다. * 알려지지 않은 UDP 트래픽에 공격이 발생할 경우, 기존에는 특정 IP나 포트 전체를 차단하거나 속도 제한(Rate Limit)을 거는 투박한 방식을 사용해야 했습니다. * 이러한 방식은 공격 트래픽뿐만 아니라 정상적인 사용자의 패킷까지 차단하여 서비스 지연이나 연결 끊김을 유발하는 부작용이 있었습니다. ### eBPF 기반의 맞춤형 방어 메커니즘 * 고객은 eBPF(Extended Berkeley Packet Filter) 프로그램을 작성하여 어떤 패킷이 '정상'이고 '비정상'인지 직접 정의할 수 있습니다. * 작성된 프로그램은 클라우드플레어의 전 세계 엣지 네트워크에 배포되어 모든 유입 패킷에 대해 즉각적인 판단(통과, 차단, 챌린지 등)을 수행합니다. * 커널 공간이 아닌 사용자 공간(Userspace)에서 프로그램을 실행함으로써 보안성을 확보하면서도, 클라우드플레어의 기존 DDoS 방어 계층 이후에 실행되어 다층적인 보호를 제공합니다. ### 상태 저장 및 고급 기능 지원 * 단순한 패킷 필터링을 넘어, 클라이언트의 상태를 저장하고 관리할 수 있는 '상태 저장(Stateful)' 기능을 지원합니다. * 클라우드플레어는 프로그램 실행 간 상태 유지, 암호화 검증, 챌린지 패킷 발송 등을 돕는 전용 API 및 헬퍼 함수(Helper Functions)를 제공합니다. * 이를 통해 게임 엔진의 고유 헤더 검증이나 토큰 기반의 인증 등 복잡한 애플리케이션 계층의 방어 로직을 네트워크 하단에서 구현할 수 있습니다. ### 실무 적용 예시: 독자적인 게임 프로토콜 보호 * 독자적인 헤더 구조를 가진 UDP 포트 기반 온라인 게임 서버의 경우, 공격자가 무작위 페이로드를 보내면 일반적인 장비로는 구분할 수 없습니다. * '프로그래밍 가능한 플로우 보호'를 활용하면 패킷 헤더 내의 특정 바이트나 고유 토큰을 검사하는 코드를 배포하여, 유효하지 않은 모든 트래픽을 클라우드플레어 엣지에서 즉시 제거합니다. * 결과적으로 원본 서버(Origin)에 도달하기 전에 공격이 차단되어 서버 자원을 보호하고 실제 이용자에게는 쾌적한 환경을 제공하게 됩니다. 현재 이 기능은 매직 트랜짓 엔터프라이즈 고객을 대상으로 베타 서비스 중입니다. 표준 프로토콜을 벗어난 고유의 통신 방식을 보유하고 있으며, 기존의 단순 차단 방식만으로는 서비스 품질 유지가 어려운 기업에게 이 기능을 통한 정밀한 트래픽 제어를 권장합니다.

tcpcloudflarenetwork-securityebpf+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` 명령어를 통해 직접 확인할 수 있습니다.

tcpcloudflaresasequic+4