들어가며
리눅스 네트워크를 공부하다 보면 자연스럽게 이런 질문에 도달하게 됩니다.
“리눅스 커널은 HTTP 요청까지 이해할 수 있을까?”
“Cilium은 eBPF로 HTTP 라우팅을 한다고 하는데, 그럼 커널이 L7까지 처리하는 걸까?”
이 질문의 핵심은 하나입니다.
커널은 어디까지 처리하고, 어디부터는 다른 계층의 역할일까?
이 글에서는 패킷이 실제로 어떻게 흐르는지를 기준으로,
커널의 역할 범위와 Cilium의 동작 방식을 하나의 흐름으로 설명합니다.
1. 커널이 보는 세상: “패킷”
애플리케이션 입장에서 네트워크는 “요청”입니다.
하지만 커널 입장에서 이 데이터는 전혀 다른 의미를 가집니다.
커널은 이 데이터를 “HTTP 요청”으로 보지 않습니다.
그저 TCP 위에 실린 데이터일 뿐입니다.
2. 실제 흐름으로 이해하기
애플리케이션이 요청을 보내는 순간, 내부에서는 다음과 같은 일이 일어납니다.
Application
→ send()
→ TCP
→ IP
→ Routing
→ NIC
여기서 중요한 포인트는 다음과 같습니다.
- TCP는 데이터를 나누고 순서를 관리합니다
- IP는 목적지를 결정합니다
- Routing은 “어디로 보낼지”를 선택합니다
이 모든 과정에서 커널이 보는 것은 단 하나입니다.
“이 패킷을 어디로 보내야 하는가?”
3. 커널이 모르는 것
이제 다시 HTTP로 돌아가 보겠습니다.
GET /api/users
Host: example.com
Authorization: Bearer ...
이 정보는 모두 TCP payload 안에 들어 있습니다.
커널은:
/api가 무엇인지- 어떤 Header가 있는지
- 어떤 JSON이 포함되어 있는지
전혀 알지 못합니다.
이유는 단순합니다.
커널은 L3/L4까지만 이해하도록 설계되었기 때문입니다.
4. 그렇다면 HTTP 라우팅은 누가 하는가
HTTP 라우팅은 다음과 같은 형태입니다.
/api → A 서버
/image → B 서버
이 판단을 하려면:
- TCP stream을 재조립하고
- 문자열을 해석하고
- 상태를 유지해야 합니다
이 작업은 커널이 아닌 유저 공간의 애플리케이션이 수행합니다.
대표적으로:
실제 흐름은 다음과 같습니다.
Client
→ Kernel (패킷 전달)
→ Proxy (HTTP 해석)
→ Backend 선택
5. 여기서 등장하는 오해: Cilium은 L7까지 처리하는가
Cilium을 보면 이런 오해가 생기기 쉽습니다.
“eBPF로 HTTP도 처리한다 = 커널이 L7 라우팅을 한다”
하지만 실제 구조는 다릅니다.
6. Cilium의 실제 동작 방식
Cilium은 하나의 컴포넌트가 아니라 두 가지의 조합입니다.
이 둘이 역할을 나눠서 처리합니다.
6.1 첫 번째 단계: eBPF (커널)
패킷이 들어오면 eBPF가 먼저 처리합니다.
- 빠른 패킷 필터링
- connection tracking
- 일부 L7 메타데이터 추출
여기서 중요한 점은:
eBPF는 “이 요청이 HTTP인지” 정도는 인식할 수 있지만,
복잡한 라우팅 결정을 내리지는 않습니다.
6.2 두 번째 단계: Envoy (유저 공간)
L7 처리가 필요한 경우, 트래픽은 Envoy로 전달됩니다.
Envoy는 다음을 수행합니다.
- HTTP parsing
- Header 분석
- Path 기반 routing
GET /api → service A
GET /image → service B
6.3 전체 흐름
Client
→ eBPF (빠른 처리)
→ 필요 시
→ Envoy (HTTP 해석)
→ Backend
7. 왜 이렇게 나누었는가
이 구조는 단순한 설계가 아니라, 명확한 이유를 가지고 있습니다.
성능
- 대부분 트래픽은 eBPF에서 빠르게 처리됩니다
- 필요한 경우에만 Envoy로 전달됩니다
역할 분리
- 커널: 빠르고 단순해야 함
- 유저 공간: 복잡한 로직 처리
8. 핵심 정리
이 글의 내용을 하나로 정리하면 다음과 같습니다.
- 커널은 패킷을 전달하는 역할(L3/L4)을 담당합니다
- HTTP와 같은 L7 정보는 커널이 해석하지 않습니다
- L7 라우팅은 유저 공간 애플리케이션이 수행합니다
- Cilium은 eBPF와 Envoy를 결합하여 이를 효율적으로 처리합니다
9. 한 문장으로 정리
커널은 “어디로 보낼지”를 결정하고,
애플리케이션은 “무엇을 요청했는지”를 판단합니다.
들어가며
리눅스 네트워크를 공부하다 보면 자연스럽게 이런 질문에 도달하게 됩니다.
이 질문의 핵심은 하나입니다.
이 글에서는 패킷이 실제로 어떻게 흐르는지를 기준으로,
커널의 역할 범위와 Cilium의 동작 방식을 하나의 흐름으로 설명합니다.
1. 커널이 보는 세상: “패킷”
애플리케이션 입장에서 네트워크는 “요청”입니다.
하지만 커널 입장에서 이 데이터는 전혀 다른 의미를 가집니다.
커널은 이 데이터를 “HTTP 요청”으로 보지 않습니다.
그저 TCP 위에 실린 데이터일 뿐입니다.
2. 실제 흐름으로 이해하기
애플리케이션이 요청을 보내는 순간, 내부에서는 다음과 같은 일이 일어납니다.
여기서 중요한 포인트는 다음과 같습니다.
이 모든 과정에서 커널이 보는 것은 단 하나입니다.
3. 커널이 모르는 것
이제 다시 HTTP로 돌아가 보겠습니다.
이 정보는 모두 TCP payload 안에 들어 있습니다.
커널은:
/api가 무엇인지전혀 알지 못합니다.
이유는 단순합니다.
4. 그렇다면 HTTP 라우팅은 누가 하는가
HTTP 라우팅은 다음과 같은 형태입니다.
이 판단을 하려면:
이 작업은 커널이 아닌 유저 공간의 애플리케이션이 수행합니다.
대표적으로:
실제 흐름은 다음과 같습니다.
5. 여기서 등장하는 오해: Cilium은 L7까지 처리하는가
Cilium을 보면 이런 오해가 생기기 쉽습니다.
하지만 실제 구조는 다릅니다.
6. Cilium의 실제 동작 방식
Cilium은 하나의 컴포넌트가 아니라 두 가지의 조합입니다.
이 둘이 역할을 나눠서 처리합니다.
6.1 첫 번째 단계: eBPF (커널)
패킷이 들어오면 eBPF가 먼저 처리합니다.
여기서 중요한 점은:
6.2 두 번째 단계: Envoy (유저 공간)
L7 처리가 필요한 경우, 트래픽은 Envoy로 전달됩니다.
Envoy는 다음을 수행합니다.
6.3 전체 흐름
7. 왜 이렇게 나누었는가
이 구조는 단순한 설계가 아니라, 명확한 이유를 가지고 있습니다.
성능
역할 분리
8. 핵심 정리
이 글의 내용을 하나로 정리하면 다음과 같습니다.
9. 한 문장으로 정리