670. XDP (eXpress Data Path)

핵심 인사이트 (3줄 요약)

본질: XDP (eXpress Data Path)는 eBPF (extended Berkeley Packet Filter) 프로그램을 네트워크 인터페이스 카드 (Network Interface Card, NIC) 드라이버의 수신 초입에 붙여, sk_buff가 만들어지기 전에 패킷을 판정하는 초저지연 데이터 경로다.

가치: 드롭·패스·리다이렉트 같은 단순 결정을 가장 앞단에서 끝내므로, DDoS (Distributed Denial of Service) 방어와 고속 로드밸런싱에서 패킷 처리량과 CPU 효율을 동시에 끌어올릴 수 있다.

판단 포인트: XDP의 성패는 “커널 안에 있다”보다 “얼마나 이른 훅에서, 얼마나 짧은 로직으로 실행하느냐”에 달려 있으므로 Native XDP와 Offloaded XDP를 우선 검토하고 Generic XDP는 호환성 용도로 봐야 한다.

Ⅰ. 개요 및 필요성

XDP는 리눅스 네트워크 경로에서 가장 비싼 단계가 시작되기 직전에 끼어드는 기술이다. 일반적인 패킷 수신 경로에서는 패킷이 Direct Memory Access (DMA)로 메모리 페이지에 들어온 뒤, 커널이 메타데이터를 만들고, 여러 후속 훅을 거치며, 필요하면 상위 프로토콜 계층으로 넘긴다. 작은 패킷이 많을수록 이 준비 비용은 실제 업무보다 더 커진다.

예를 들어 100GbE 링크에 64바이트 패킷이 가득 차면 초당 약 1억 4천8백만 개를 처리해야 한다. 이 상황에서 “먼저 커널 구조체를 만들고 나중에 버리자”는 방식은 비효율적이다. XDP는 패킷이 막 들어왔을 때 바로 “버릴지, 넘길지, 다른 곳으로 보낼지”를 결정해 이 낭비를 줄인다.

┌──────────────────────────────────────────────────────────────────────────────┐
│ XDP is placed before sk_buff allocation                                     │
├──────────────────────────────────────────────────────────────────────────────┤
│ Wire -> NIC DMA page -> XDP program -> PASS / DROP / send-back / REDIRECT  │
│                                     │                                        │
│                                     ├─ early finish: no full stack cost      │
│                                     └─ PASS: build sk_buff -> Kernel stack   │
└──────────────────────────────────────────────────────────────────────────────┘

즉, XDP는 커널을 버리는 기술이 아니라 커널이 가장 무거워지기 전에 가벼운 결정을 끝내는 기술이다. 그래서 운영체제 통합성과 초고속 처리 사이의 균형점으로 자주 선택된다.

📢 섹션 요약 비유: XDP는 공항 입국장 안쪽의 심사대가 아니라 비행기에서 내리자마자 있는 1차 게이트와 같다. 위험한 승객을 로비까지 들여보낸 뒤 돌려세우는 것보다, 문 앞에서 판단하는 편이 훨씬 덜 붐빈다.

Ⅱ. 아키텍처 및 핵심 원리

XDP 프로그램은 입력으로 패킷 헤더와 메모리 범위를 담은 컨텍스트를 받고, 반환값 하나로 다음 행동을 결정한다. 이 단순함 덕분에 드라이버 수신 경로에서 매우 빠르게 실행될 수 있다. 핵심은 “조기 실행”과 “짧은 액션 집합”이다.

반환 액션	의미	대표 용도
`XDP_ABORTED`	프로그램 오류로 즉시 중단	디버깅, 안전한 실패
`XDP_DROP`	패킷 즉시 폐기	DDoS 차단, 정책 위반 삭제
`XDP_PASS`	일반 커널 경로로 전달	정상 트래픽 상위 처리
`XDP_TX`	들어온 포트로 다시 송신	간단한 응답, L2 수정
`XDP_REDIRECT`	다른 큐·포트·사용자 공간으로 전달	빠른 포워딩, 로드밸런싱

메모리 모델도 중요하다. XDP는 패킷마다 새 버퍼를 만들기보다 재사용 가능한 페이지 풀을 활용해 할당/해제 비용을 줄인다. 여기에 AF_XDP (Address Family XDP)를 결합하면, 커널 소켓 계층을 깊게 거치지 않고 사용자 공간으로 패킷을 넘겨 매우 빠른 분석기나 패킷 처리기를 만들 수 있다.

또한 XDP는 실행 위치에 따라 성격이 달라진다.

┌─────────────────────────────────────────────────────────────────────┐
│ XDP mode hierarchy                                                 │
├──────────────────────┬──────────────────────────────────────────────┤
│ Offloaded XDP        │ NIC hardware executes the program           │
│ Native XDP           │ Driver receive path executes the program    │
│ Generic XDP          │ After sk_buff allocation, compatibility path │
└──────────────────────┴──────────────────────────────────────────────┘

Generic XDP는 구조상 이미 sk_buff 생성 비용을 치른 뒤라서 성능 상한이 낮다. 반면 Native XDP와 Offloaded XDP는 진짜 장점인 “앞단 실행”을 살릴 수 있다. 따라서 XDP 성능을 말할 때는 반드시 어떤 모드인지 같이 봐야 한다.

📢 섹션 요약 비유: XDP의 액션 집합은 복잡한 재판 절차가 아니라 교차로 신호등에 가깝다. 멈출지, 통과할지, 되돌릴지, 우회시킬지만 아주 빨리 결정해야 전체 흐름이 살아난다.

Ⅲ. 비교 및 연결

XDP를 제대로 위치시키려면 Traffic Control (TC)와 DPDK (Data Plane Development Kit)를 함께 비교하는 것이 좋다. 셋 다 패킷을 빠르게 다루지만, 실행 위치와 운영 모델이 다르기 때문에 적합한 문제도 다르다.

구분	실행 위치	강점	약점	잘 맞는 문제
TC	`sk_buff` 이후	풍부한 정책과 큐 제어	조기 차단에는 불리함	정교한 분류, shaping
XDP	드라이버 수신 초입	매우 낮은 지연, 커널 통합	로직이 짧아야 함	조기 드롭, 빠른 포워딩
DPDK	사용자 공간, 커널 우회	최고 수준 처리량, 전용 데이터 평면	전용 운영 모델 필요	전용 네트워크 장비형 애플리케이션

이 비교의 핵심은 XDP가 “커널 친화적인 빠른 길”이라는 점이다. TC보다 빠르지만 DPDK보다 운영 통합성이 좋고, DPDK보다 유연성이 낮아 보이더라도 리눅스 네트워크 생태계와 함께 움직이기 쉽다. 그래서 대규모 서비스에서는 XDP로 1차 거르고, 필요한 일부만 상위 커널 경로나 사용자 공간 분석기로 넘기는 계층형 설계가 자주 나온다.

📢 섹션 요약 비유: TC가 본관 안내데스크라면 XDP는 정문 보안 게이트이고, DPDK는 아예 별도 전용 출입문을 만든 형태다. 어느 문이 좋은지가 아니라, 손님을 어디에서부터 어떻게 통제할지의 문제다.

Ⅳ. 실무 적용 및 기술사 판단

실무 시나리오

대규모 DDoS 조기 차단
- SYN flood나 명백한 헤더 이상 패킷은 XDP에서 XDP_DROP으로 먼저 제거하는 것이 가장 효과적이다.
- 이 방식은 애플리케이션뿐 아니라 커널 큐와 커넥션 추적 자원까지 함께 보호한다.
Layer 4 (L4) 로드밸런서
- 빠른 해시 기반 서버 선택, 간단한 NAT (Network Address Translation) 수준의 헤더 수정, 빠른 리다이렉트는 XDP와 잘 맞는다.
- 대표적으로 대형 서비스의 소프트웨어 로드밸런서가 XDP를 이용해 초당 수천만 개 패킷을 처리한다.
AF_XDP 기반 사용자 공간 분석기
- 특정 포트나 프로토콜만 선별해 사용자 공간 처리기로 넘기면, 전체 패킷을 전부 복사하지 않고도 빠른 모니터링 경로를 만들 수 있다.
- 이때 멀티큐 NIC와 Receive Side Scaling (RSS)을 함께 사용하면 코어별 분산 효과가 좋아진다.

채택/회피 판단 체크포인트

채택이 유리한 경우
- 헤더 몇 단계만 보고 결정을 내릴 수 있을 때
- 커널 네트워크 기능과 공존해야 하지만, 조기 차단이 절실할 때
- 드라이버가 Native XDP를 제대로 지원하고 멀티큐 구성이 가능한 때
회피가 유리한 경우
- 긴 세션 상태 유지, 복잡한 애플리케이션 계층 해석, 대규모 문자열 검사 같은 무거운 로직이 필요한 경우
- Generic XDP밖에 지원하지 않아 기대 성능이 제한되는 경우
- 팀이 BPF 디버깅과 드라이버 호환성 관리 경험이 부족한 경우

기술사 관점에서 중요한 판단은 “XDP를 썼다”가 아니라 “무엇을 XDP에 남기고 무엇을 상위 계층으로 올릴 것인가”다. XDP에는 최대한 짧고 결정적인 정책만 남기고, 상태가 길어지거나 예외 처리가 복잡해지는 순간 상위 계층으로 넘기는 설계가 안정적이다.

📢 섹션 요약 비유: XDP는 택배 분류장의 초고속 1차 라인과 같다. 상자 모양만 보고 바로 버릴지, 일반 라인으로 보낼지, 특수 라인으로 보낼지는 잘하지만, 상자 안 내용물까지 길게 검사하는 일은 뒤쪽 라인에 맡기는 편이 맞다.

Ⅴ. 기대효과 및 결론

XDP가 잘 맞는 워크로드에서는 커널 상위 계층에 올라오는 패킷 수 자체를 줄여 CPU 사용량과 지연 시간을 동시에 낮출 수 있다. 특히 작은 패킷이 많은 DDoS 방어, 간단한 L4 분산, 빠른 리다이렉트 경로에서는 “패킷을 일찍 버리는 것”만으로도 체감 성능 차이가 크다. 리눅스 내부 기술이면서도 사용자 공간 고속 처리와 하드웨어 오프로딩으로 확장되기 쉽다는 점도 장점이다.

반면 XDP는 만능 패킷 처리기가 아니다. 프로그램 길이가 길어질수록 장점이 줄고, 드라이버 지원 수준에 따라 성능 차이가 크며, Generic XDP에서는 기대보다 덜 빨라질 수 있다. 그래서 XDP를 기억할 때는 “리눅스에서 가장 빠른 훅”이라는 말보다 **“가장 빨리 결정해야 하는 일을 맡기는 위치”**라는 관점이 더 중요하다.

📢 섹션 요약 비유: XDP는 모든 손님을 처리하는 호텔 프런트가 아니라, 문 앞에서 손님 흐름을 정리하는 전문 도어맨이다. 가장 먼저 해야 할 판단을 잘 맡기면 안쪽 직원들이 훨씬 덜 바빠진다.

📌 관련 개념 맵

개념	연결 포인트
eBPF (extended Berkeley Packet Filter)	XDP 프로그램을 기술하는 실행 모델이자 검증 대상이다.
AF_XDP (Address Family XDP)	XDP가 선별한 패킷을 사용자 공간으로 빠르게 연결하는 소켓 계열이다.
Traffic Control (TC)	XDP보다 뒤에서 더 풍부한 정책을 적용하는 커널 패킷 제어 계층이다.
Page Pool	XDP의 고속 메모리 재사용을 가능하게 하는 버퍼 관리 방식이다.
SmartNIC (Smart Network Interface Card)	Offloaded XDP가 실제 하드웨어에서 실행될 때 만나는 플랫폼이다.

📈 관련 키워드 및 발전 흐름도

전통적 커널 방화벽 / 패킷 필터
        │
        ▼
TC (Traffic Control) 기반 BPF 정책
        │
        ▼
XDP (eXpress Data Path)
        │
        ├──────────────▶ AF_XDP (Address Family XDP) 사용자 공간 경로
        │
        ▼
SmartNIC 기반 하드웨어 오프로딩

이 흐름은 “커널 안쪽에서 늦게 판단”하던 패킷 제어가, 점점 더 앞단으로 이동하며 사용자 공간과 하드웨어까지 빠른 길을 확장한 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

XDP는 학교 정문에 있는 아주 빠른 선생님 같아요.
나쁜 장난을 치는 친구는 교실까지 들어오기 전에 바로 돌려보내고, 괜찮은 친구만 안으로 들여보내요.
그래서 학교 안 선생님들은 정말 가르쳐야 할 친구들에게 더 집중할 수 있어요.