네트워크 스택 (Network Stack)

Linux 커널 네트워크 스택: sk_buff, TCP/IP, netfilter, socket, NAPI 종합 가이드.

네트워크 스택 개요

Linux 네트워크 스택은 OSI 7계층 모델에 대응하는 계층적 구조로 설계되어 있습니다. 패킷은 sk_buff(소켓 버퍼) 구조체로 표현되며, 각 계층을 통과하면서 헤더가 추가/제거됩니다.

sk_buff 구조체

struct sk_buff는 네트워크 패킷을 표현하는 핵심 자료구조입니다. 패킷 데이터, 헤더 포인터, 메타데이터를 포함합니다.

struct sk_buff {
    union {
        struct {
            struct sk_buff *next, *prev;
        };
        struct rb_node rbnode;
    };
    struct sock     *sk;           /* 소속 소켓 */
    struct net_device *dev;       /* 네트워크 디바이스 */

    unsigned char   *head;         /* 버퍼 시작 */
    unsigned char   *data;         /* 현재 계층 데이터 시작 */
    unsigned char   *tail;         /* 데이터 끝 */
    unsigned char   *end;          /* 버퍼 끝 */

    unsigned int    len;           /* 총 데이터 길이 */
    __u16           protocol;      /* ETH_P_IP 등 */
    __u16           transport_header;
    __u16           network_header;
    __u16           mac_header;
    /* ... */
};

Netfilter

Netfilter는 커널의 패킷 필터링 프레임워크입니다. 네트워크 스택의 여러 지점(hook)에 콜백 함수를 등록하여 패킷을 검사, 수정, 차단합니다. iptables/nftables의 백엔드입니다.

#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>

static unsigned int my_hook(void *priv,
    struct sk_buff *skb,
    const struct nf_hook_state *state)
{
    struct iphdr *iph = ip_hdr(skb);
    pr_info("packet from %pI4\n", &iph->saddr);
    return NF_ACCEPT;  /* or NF_DROP, NF_QUEUE */
}

static struct nf_hook_ops my_nf_ops = {
    .hook     = my_hook,
    .pf       = NFPROTO_IPV4,
    .hooknum  = NF_INET_PRE_ROUTING,
    .priority = NF_IP_PRI_FIRST,
};

nf_register_net_hook(&init_net, &my_nf_ops);

네트워크 디바이스

struct net_device는 네트워크 인터페이스(eth0, wlan0 등)를 나타냅니다. NAPI(New API)를 통한 고속 패킷 처리를 지원합니다.

소켓 계층 (Socket Layer)

소켓은 유저스페이스 프로세스와 커널 네트워크 스택을 연결하는 인터페이스입니다. struct socket과 struct sock의 이중 구조로 되어 있습니다.

struct socket {                    /* VFS/유저 인터페이스 */
    socket_state        state;       /* SS_CONNECTED 등 */
    short               type;        /* SOCK_STREAM, SOCK_DGRAM */
    struct file         *file;       /* VFS file 연결 */
    struct sock         *sk;         /* 프로토콜 소켓 */
    const struct proto_ops *ops;   /* sendmsg/recvmsg 등 */
};

struct sock {                      /* 프로토콜 계층 (TCP/UDP) */
    struct sock_common  __sk_common;
    struct sk_buff_head sk_receive_queue;  /* 수신 큐 */
    struct sk_buff_head sk_write_queue;    /* 송신 큐 */
    atomic_t            sk_wmem_alloc;     /* 송신 버퍼 사용량 */
    atomic_t            sk_rmem_alloc;     /* 수신 버퍼 사용량 */
    int                 sk_sndbuf;         /* SO_SNDBUF */
    int                 sk_rcvbuf;         /* SO_RCVBUF */
    /* ... */
};

TCP 내부 구현

TCP 연결 상태 머신

커널의 TCP 구현은 RFC 793의 상태 머신을 정밀하게 따릅니다:

/* include/net/tcp_states.h */
enum {
    TCP_ESTABLISHED = 1,
    TCP_SYN_SENT    = 2,
    TCP_SYN_RECV    = 3,
    TCP_FIN_WAIT1   = 4,
    TCP_FIN_WAIT2   = 5,
    TCP_TIME_WAIT   = 6,
    TCP_CLOSE       = 7,
    TCP_CLOSE_WAIT  = 8,
    TCP_LAST_ACK    = 9,
    TCP_LISTEN      = 10,
    TCP_CLOSING     = 11,
    TCP_NEW_SYN_RECV = 12,
};

TCP_NEW_SYN_RECV(12)는 커널 4.4+에서 추가된 최적화 상태입니다. 기존 SYN_RECV가 전체 struct sock을 할당하던 것과 달리, 경량 request_sock만 사용하여 SYN Flood 방어 시 메모리 효율을 높입니다. 상세 구현은 TCP 심화 섹션을 참고하세요.

혼잡 제어 (Congestion Control)

Linux는 플러그인 방식의 혼잡 제어 알고리즘을 지원합니다. 기본값은 CUBIC이며, BBR, Reno 등을 선택할 수 있습니다. 상세한 알고리즘 내부 동작은 혼잡 제어 심화 섹션에서 다룹니다.

/* 혼잡 제어 알고리즘 등록 */
struct tcp_congestion_ops tcp_reno = {
    .name        = "reno",
    .ssthresh    = tcp_reno_ssthresh,
    .cong_avoid  = tcp_reno_cong_avoid,
    .undo_cwnd   = tcp_reno_undo_cwnd,
    .owner       = THIS_MODULE,
};

/* sysctl로 알고리즘 선택 */
/* net.ipv4.tcp_congestion_control = bbr */
/* net.ipv4.tcp_available_congestion_control 로 목록 확인 */
/* net.ipv4.tcp_allowed_congestion_control = cubic reno bbr */

NAPI 상세 구현

/* 드라이버: NAPI 초기화 */
netif_napi_add(netdev, &priv->napi, my_poll);
napi_enable(&priv->napi);

/* 인터럽트 핸들러: 폴링 모드로 전환 */
static irqreturn_t my_irq_handler(int irq, void *data)
{
    struct my_priv *priv = data;
    disable_hw_irq(priv);           /* HW 인터럽트 비활성화 */
    napi_schedule(&priv->napi);     /* 폴링 스케줄 */
    return IRQ_HANDLED;
}

/* 폴링 함수: softirq 컨텍스트에서 실행 */
static int my_poll(struct napi_struct *napi, int budget)
{
    int work_done = 0;
    while (work_done < budget) {
        struct sk_buff *skb = read_packet_from_hw(priv);
        if (!skb) break;
        napi_gro_receive(napi, skb);  /* GRO 처리 후 상위 전달 */
        work_done++;
    }
    if (work_done < budget) {
        napi_complete_done(napi, work_done);
        enable_hw_irq(priv);          /* 인터럽트 재활성화 */
    }
    return work_done;
}

라우팅 서브시스템

Linux 라우팅은 FIB(Forwarding Information Base)를 기반으로 Longest Prefix Match(LPM) 조회를 수행합니다. Policy Routing, ECMP, VRF, SRv6 등 고급 기능을 포함한 상세한 내용은 별도 페이지에서 다룹니다.

TC (Traffic Control)와 qdisc

패킷 스케줄링과 트래픽 셰이핑을 담당합니다. 각 네트워크 디바이스에 qdisc(큐잉 규칙)가 연결됩니다.

NAPI 심화 — 성능 튜닝과 주의사항

NAPI 상태 전이와 Budget 관리

GRO (Generic Receive Offload)

GRO는 NAPI poll 내에서 수신된 여러 패킷을 하나의 대형 skb로 병합하여 상위 스택 호출 횟수를 줄입니다. LRO(Large Receive Offload)의 소프트웨어 대체로, 원본 헤더 정보를 보존하여 포워딩 환경에서도 안전합니다.

/* === GRO 수신 경로 ===
 *
 * NIC IRQ → napi_schedule()
 *  └→ NAPI poll()
 *      └→ napi_gro_receive(napi, skb)
 *          └→ dev_gro_receive()
 *              └→ inet_gro_receive()        (L3: IP)
 *                  └→ tcp4_gro_receive()    (L4: TCP)
 *                      ├→ 동일 flow 검색 (rxhash → gro_hash 버킷)
 *                      ├→ 병합 기준 검증:
 *                      │   - 동일 src/dst IP + port
 *                      │   - TCP seq 연속 (이전 끝 + 1)
 *                      │   - ACK만 설정 (SYN/FIN/RST → 거부)
 *                      │   - 윈도우 크기 동일
 *                      │   - TCP 타임스탬프 일관성
 *                      └→ 결과:
 *                          GRO_MERGED     : 기존 skb에 병합
 *                          GRO_HELD       : gro_list에 보관 (새 flow)
 *                          GRO_NORMAL     : 병합 불가 → 일반 경로
 */

/* NAPI poll 함수에서 GRO 사용 패턴 */
napi_gro_receive(napi, skb);   /* 일반적: 완전한 skb를 GRO 처리 */
napi_gro_frags(napi);          /* 페이지 기반 수신 시 (헤더/데이터 분리)
                                 * 고성능 NIC 드라이버에서 선호:
                                 *   napi->skb에 헤더(선형) + 페이로드(frag)
                                 *   → 메모리 복사 최소화 */

/* GRO 데이터 병합 방식 */
/* 1. frag 기반: skb_shinfo→frags[]에 페이지 추가 (MAX_SKB_FRAGS=17 제한)
 * 2. frag_list 기반: skb_shinfo→frag_list에 skb 체인 (제한 없음)
 *    → frag 공간 부족 시 자동 전환 */

/* GRO flush 조건:
 * 1. napi_complete_done() 호출 시 (budget 미만 처리)
 * 2. gro_hash 버킷에 MAX_GRO_SKBS(8)개 초과 시
 * 3. 비연속 패킷 수신 시 (seq 불연속, 다른 플래그)
 * 4. gro_flush_timeout 타이머 만료 시
 *    → sysctl net.core.gro_flush_timeout (기본 0 = 즉시 flush)
 *    → net.core.napi_defer_hard_irqs와 함께 사용하면 GRO 효율↑ */

/* GRO 성능 효과 예시 (1500 MTU, TCP):
 *   GRO OFF: 1M pps → 1M번 netif_receive_skb() 호출
 *   GRO ON:  1M pps → ~15K번 호출 (64KB super-packet 생성)
 *   → CPU 사용률 대폭 감소, 처리량 증가
 *
 * 포워딩 환경 (라우터, 브리지):
 *   GRO OFF: 43개 패킷 × routing/conntrack/NAT
 *   GRO ON:  1개 대형 skb × routing/conntrack/NAT → ~43배 효율 */

/* HW-GRO (커널 5.19+) — NIC가 GRO 수행하되 헤더 보존 */
/* # ethtool -K eth0 rx-gro-hw on
 * → LRO와 달리 원본 헤더 정보 유지 → 포워딩에도 안전
 * → NIC의 RSC(Receive Side Coalescing) 기능 활용 */

/* GRO 제어 및 확인 */
/* # ethtool -K eth0 gro on|off           # SW GRO 전환 */
/* # ethtool -K eth0 rx-gro-hw on|off     # HW GRO 전환 (5.19+) */
/* # ethtool -k eth0 | grep gro           # 상태 확인 */
/* # ethtool -S eth0 | grep gro           # GRO 통계 확인 */

NAPI 드라이버 구현 주의사항

RSS, RPS, RFS — 멀티코어 네트워크 분산

Toeplitz Hash — RSS 해시 알고리즘

RSS의 핵심은 NIC 하드웨어가 패킷 헤더로부터 해시 값을 계산하여 수신 큐를 결정하는 것이다. 대부분의 NIC는 Microsoft가 정의한 Toeplitz 해시를 사용한다. Toeplitz 해시는 XOR 기반의 비트 연산으로, 하드웨어 구현이 매우 단순하면서도 트래픽 분산 특성이 우수하다.

해시 입력 (Hash Input)

NIC는 패킷 유형에 따라 해시 입력 필드를 선택한다:

Toeplitz 해시 알고리즘

Toeplitz 해시는 해시 키(Key)와 입력 데이터를 비트 단위로 XOR 누적하여 32비트 해시를 생성한다:

/*
 * Toeplitz Hash 의사코드
 *
 * input[]:  해시 입력 (예: src_ip + dst_ip + src_port + dst_port)
 *           IPv4 4-tuple = 12바이트 (96비트)
 * key[]:    해시 키 (40바이트 = 320비트, 네트워크 바이트 순서)
 * 결과:     32비트 해시 값
 */
uint32_t toeplitz_hash(uint8_t *input, int input_len, uint8_t *key)
{
    uint32_t result = 0;
    int i, j;

    for (i = 0; i < input_len; i++) {
        for (j = 0; j < 8; j++) {
            if (input[i] & (1 << (7 - j))) {
                /* key의 (i*8+j) 위치에서 시작하는 32비트를 XOR */
                result ^= get_unaligned_be32(key + i) << j
                        | (uint32_t)get_unaligned_be32(key + i + 4) >> (32 - j);
            }
        }
    }
    return result;
}

커널 내부의 소프트웨어 구현은 include/linux/netdevice.h의 인라인과 lib/toeplitz.c에 위치한다. RPS가 사용하는 소프트웨어 해시도 동일한 Toeplitz를 사용하며, net/core/flow_dissector.c의 __skb_get_hash()에서 호출된다:

/* include/linux/netdevice.h — 커널 소프트웨어 Toeplitz */
static inline __u32
__toeplitz_hash(const __u32 *key_cache, int nkeys,
                const __u32 *data, int ndata)
{
    __u32 hash = 0;
    int i;

    for (i = 0; i < ndata; i++)
        hash ^= toeplitz_byte(data[i], key_cache + i);
    return hash;
}

해시 키 (Hash Key)

Toeplitz 해시 키는 일반적으로 40바이트 (320비트)이다. NIC 드라이버가 초기화 시 기본 키를 설정하며, ethtool로 조회·변경할 수 있다:

# 현재 RSS 해시 키 조회
$ ethtool -x eth0
RX flow hash indirection table for eth0 with 4 RX ring(s):
    0:      0     1     2     3     0     1     2     3
    8:      0     1     2     3     0     1     2     3
  ...
RSS hash key:
6d:5a:56:da:25:5b:0e:c2:41:67:25:3d:43:a3:8f:b0:d0:ca:2b:cb:...

# 커스텀 해시 키 설정 (대칭 키 예시 — src/dst 교환 시 동일 해시)
$ ethtool -X eth0 hkey \
  6d:5a:56:da:25:5b:0e:c2:41:67:25:3d:43:a3:8f:b0:d0:ca:2b:cb:...

# 해시 함수 종류 확인 (toeplitz / xor / crc32)
$ ethtool -x eth0 | grep "RSS hash function"
RSS hash function:
    toeplitz: on
    xor: off
    crc32: off

# 해시 함수 변경 (NIC 지원 시)
$ ethtool -X eth0 hfunc toeplitz

해시 필드 설정 (ethtool -N)

프로토콜별로 해시에 사용할 필드를 세밀하게 제어할 수 있다:

# TCP4: 4-tuple 해시 (기본값)
$ ethtool -N eth0 rx-flow-hash tcp4 sdfn
# s=src IP, d=dst IP, f=src port, n=dst port

# UDP4: 2-tuple로 변경 (단편화 이슈 방지)
$ ethtool -N eth0 rx-flow-hash udp4 sd

# 현재 설정 확인
$ ethtool -n eth0 rx-flow-hash tcp4
TCP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]

RETA — Redirection Table (인다이렉션 테이블)

Toeplitz 해시가 32비트 해시 값을 생성하면, NIC는 이 값의 하위 N비트를 인덱스로 사용하여 RETA(Redirection Table)를 참조한다. RETA의 각 엔트리는 실제 수신 큐 번호를 가리킨다.

RETA 구조와 크기

RETA의 각 엔트리는 0부터 시작하는 수신 큐 번호를 저장한다. 기본적으로 라운드 로빈(RETA[i] = i % num_queues)으로 초기화되며, 이렇게 하면 트래픽이 모든 큐에 균등하게 분배된다.

RETA 조회 및 설정

# RETA 인다이렉션 테이블 조회
$ ethtool -x eth0
RX flow hash indirection table for eth0 with 4 RX ring(s):
    0:      0     1     2     3     0     1     2     3
    8:      0     1     2     3     0     1     2     3
   16:      0     1     2     3     0     1     2     3
   24:      0     1     2     3     0     1     2     3
   ...

# 균등 분배 (기본값) — N개 큐에 라운드 로빈
$ ethtool -X eth0 equal 4
# RETA = [0,1,2,3,0,1,2,3,...] → 4개 큐 균등 분배

# 가중치 분배 — 큐별 비율 지정
$ ethtool -X eth0 weight 3 1 1 1
# Queue 0에 50%, Queue 1~3에 각 16.7%
# RETA = [0,0,0,1,0,0,0,2,...] 등으로 채워짐

# 특정 큐만 사용 (큐 0, 1만 활성)
$ ethtool -X eth0 weight 1 1 0 0
# Queue 2, 3은 RSS 트래픽 수신 안 함

커널 내부: RETA 설정 경로

RETA 설정은 ethtool_ops 콜백을 통해 드라이버로 전달된다:

/* include/linux/ethtool.h — 드라이버가 구현하는 콜백 */
struct ethtool_ops {
    /* RETA 인다이렉션 테이블 조회/설정 */
    int (*get_rxfh_indir_size)(struct net_device *);
    int (*get_rxfh)(struct net_device *,
                    struct ethtool_rxfh_param *);
    int (*set_rxfh)(struct net_device *,
                    struct ethtool_rxfh_param *,
                    struct netlink_ext_ack *);
    /* ... */
};

/* ethtool_rxfh_param — RETA + 해시 키 + 해시 함수를 한 번에 전달 */
struct ethtool_rxfh_param {
    u32 *indir;          /* RETA 테이블 (큐 번호 배열) */
    u8  *key;            /* Toeplitz 해시 키 */
    u8   hfunc;          /* 해시 함수 (ETH_RSS_HASH_*) */
    u32  indir_size;     /* RETA 엔트리 수 */
    u32  key_size;       /* 해시 키 바이트 수 */
};

예를 들어 Intel ixgbe 드라이버에서의 RETA 프로그래밍:

/* drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
 * RETA를 하드웨어 레지스터에 기록 */
static void ixgbe_store_reta(struct ixgbe_adapter *adapter)
{
    u32 reta_entries = ixgbe_rss_indir_tbl_entries(adapter);  /* 128 */
    u32 i, reta = 0;

    for (i = 0; i < reta_entries; i++) {
        reta |= (u32)adapter->rss_indir_tbl[i] <<
                (i & 0x3) * 8;        /* 4개 엔트리를 32비트에 패킹 */
        if ((i & 3) == 3) {
            IXGBE_WRITE_REG(hw, IXGBE_RETA(i >> 2), reta);
            reta = 0;
        }
    }
}

RSS 전체 흐름 요약

RSS 디버깅 및 모니터링

# 큐별 패킷 수 확인 — 분배가 균등한지 검증
$ ethtool -S eth0 | grep rx_queue
     rx_queue_0_packets: 1523847
     rx_queue_1_packets: 1518293
     rx_queue_2_packets: 1521056
     rx_queue_3_packets: 1519834

# 큐별 IRQ 확인
$ grep eth0 /proc/interrupts
 128:   152384    0    0    0  IR-PCI-MSI eth0-TxRx-0
 129:        0  151829    0    0  IR-PCI-MSI eth0-TxRx-1
 130:        0    0  152105    0  IR-PCI-MSI eth0-TxRx-2
 131:        0    0    0  151983  IR-PCI-MSI eth0-TxRx-3

# IRQ affinity 설정 (큐 0 → CPU 0)
$ echo 1 > /proc/irq/128/smp_affinity

# 활성 큐 수 변경
$ ethtool -L eth0 combined 8     # combined RX+TX 8큐로
$ ethtool -l eth0                 # 현재 설정 확인
Channel parameters for eth0:
Pre-set maximums:
RX:     0
TX:     0
Other:  1
Combined:    63
Current hardware settings:
RX:     0
TX:     0
Other:  1
Combined:    8

# sk_buff의 해시 값 확인 (BPF로)
$ bpftrace -e 'kprobe:netif_receive_skb {
    printf("hash=0x%x queue=%d\n",
           ((struct sk_buff *)arg0)->hash,
           ((struct sk_buff *)arg0)->queue_mapping);
}'

Flow Director — 정밀 플로우 스티어링

RSS의 해시 기반 분배로 충분하지 않을 때, Flow Director (Intel의 fdir / ntuple filter)로 특정 플로우를 원하는 큐에 직접 매핑할 수 있다. Flow Director 규칙은 RSS보다 높은 우선순위를 가진다:

# 특정 목적지 포트의 트래픽을 큐 3으로 스티어링
$ ethtool -N eth0 flow-type tcp4 dst-port 80 action 3

# 특정 5-tuple 매칭
$ ethtool -N eth0 flow-type tcp4 \
    src-ip 10.0.0.1 dst-ip 10.0.0.2 \
    src-port 12345 dst-port 443 action 2

# 현재 규칙 목록
$ ethtool -n eth0
4 RX rings available
Total 2 rules
Filter: 1023
    Rule Type: TCP over IPv4
    Src IP addr: 0.0.0.0 mask: 255.255.255.255
    Dest IP addr: 0.0.0.0 mask: 255.255.255.255
    TOS: 0x0 mask: 0xff
    Src port: 0 mask: 0xffff
    Dest port: 80 mask: 0x0
    Action: Direct to queue 3

# 규칙 삭제
$ ethtool -N eth0 delete 1023

RPS (Receive Packet Steering) — 소프트웨어 RSS

RPS는 커널 소프트웨어에서 수신 패킷을 여러 CPU로 분배하는 메커니즘이다. RSS를 지원하지 않는 NIC나, 큐 수가 CPU 수보다 적은 환경에서 유용하다. NIC의 하드웨어 큐에서 패킷을 받은 CPU가 해시를 계산하고, 그 결과에 따라 다른 CPU의 backlog 큐에 패킷을 넣어 처리를 분산시킨다.

RPS 아키텍처

RPS 커널 구현

RPS의 핵심 로직은 net/core/dev.c의 get_rps_cpu() 함수에 있다. 이 함수는 패킷의 해시 값을 계산하고, rps_map을 참조하여 대상 CPU를 결정한다:

/* net/core/dev.c — RPS CPU 선택 핵심 로직 */
static int get_rps_cpu(struct net_device *dev,
                       struct sk_buff *skb,
                       struct rps_dev_flow **rflowp)
{
    struct netdev_rx_queue *rxqueue;
    struct rps_map *map;
    struct rps_sock_flow_table *sock_flow_table;
    int cpu = -1;
    u32 hash;

    rxqueue = dev->_rx + skb_get_rx_queue(skb);
    map = rcu_dereference(rxqueue->rps_map);
    if (!map)
        return -1;

    /* 패킷의 flow hash 계산 (Toeplitz 기반) */
    hash = skb_get_hash(skb);
    if (!hash)
        return -1;

    /* RFS (sock_flow_table)가 설정된 경우, 소켓을 처리하는 CPU 우선 */
    sock_flow_table = rcu_dereference(rps_sock_flow_table);
    if (sock_flow_table) {
        /* RFS 로직: 소켓의 마지막 처리 CPU를 참조 */
        /* ... (아래 RFS 섹션 참조) */
    }

    /* 해시 기반 CPU 선택: hash를 rps_map의 CPU 배열 인덱스로 변환 */
    cpu = map->cpus[reciprocal_scale(hash, map->len)];

    return cpu;
}

대상 CPU가 결정되면, enqueue_to_backlog()를 통해 해당 CPU의 per-CPU backlog 큐(softnet_data.input_pkt_queue)에 패킷을 삽입하고, IPI(Inter-Processor Interrupt)로 대상 CPU를 깨운다:

/* net/core/dev.c — 대상 CPU의 backlog에 패킷 삽입 */
static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
                              unsigned int *qtail)
{
    struct softnet_data *sd = &per_cpu(softnet_data, cpu);

    rps_lock_irqsave(sd, &flags);
    if (skb_queue_len(&sd->input_pkt_queue) <= netdev_max_backlog) {
        __skb_queue_tail(&sd->input_pkt_queue, skb);
        rps_unlock_irq_restore(sd, &flags);

        /* 대상 CPU에 NET_RX_SOFTIRQ 스케줄링 (IPI 발생) */
        ____napi_schedule(sd, &sd->backlog);
        return NET_RX_SUCCESS;
    }

    /* backlog 큐 초과 → 패킷 드롭 */
    sd->dropped++;
    rps_unlock_irq_restore(sd, &flags);
    kfree_skb(skb);
    return NET_RX_DROP;
}

RPS 핵심 자료구조

/* include/linux/netdevice.h — rps_map: 큐별 대상 CPU 목록 */
struct rps_map {
    unsigned int   len;          /* 활성 CPU 수 */
    struct rcu_head rcu;
    u16            cpus[];      /* CPU 번호 배열 */
};

/* softnet_data: per-CPU 네트워크 처리 구조체 */
struct softnet_data {
    struct list_head     poll_list;       /* NAPI poll 리스트 */
    struct sk_buff_head  input_pkt_queue; /* RPS backlog 큐 */
    struct sk_buff_head  process_queue;   /* 처리 중인 큐 */
    struct napi_struct   backlog;         /* backlog NAPI */
    unsigned int         dropped;         /* 드롭 카운터 */
    /* ... */
};

RPS 설정 방법

# RPS 설정: 특정 RX 큐에서 어떤 CPU로 패킷을 분산할지 결정
# rps_cpus: CPU 비트맵 (16진수)

# 8-core 시스템에서 모든 CPU 활성화
$ echo ff > /sys/class/net/eth0/queues/rx-0/rps_cpus
# ff = 11111111(2) → CPU 0~7 모두 사용

# NUMA 노드 0의 CPU(0~3)만 사용
$ echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
# f = 00001111(2) → CPU 0~3만

# 32-core 시스템: 모든 CPU
$ echo ffffffff > /sys/class/net/eth0/queues/rx-0/rps_cpus

# backlog 큐 크기 조절 (기본 1000)
$ echo 5000 > /proc/sys/net/core/netdev_budget
$ echo 10000 > /proc/sys/net/core/netdev_max_backlog

# RPS flow hash 엔트리 수 (전역, RFS와 함께 사용)
$ echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

# 큐별 flow 엔트리 수
$ echo 2048 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

# 현재 설정 확인
$ cat /sys/class/net/eth0/queues/rx-0/rps_cpus
000000ff
$ cat /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
0

RSS vs RPS 비교

RFS (Receive Flow Steering) — 캐시 친화적 분배

RFS는 RPS를 확장하여 패킷을 해당 소켓을 마지막으로 처리한 CPU로 전달한다. RPS가 해시 기반으로 아무 CPU나 선택하는 것과 달리, RFS는 애플리케이션의 CPU 위치를 추적하여 L1/L2 캐시 히트율을 극대화한다.

RFS 동작 원리

RFS는 두 개의 해시 테이블을 사용한다:

/* include/linux/netdevice.h — RFS 자료구조 */
struct rps_sock_flow_table {
    u32   mask;             /* 엔트리 수 - 1 (power of 2) */
    u32   ents[];           /* flow hash → desired CPU */
};

struct rps_dev_flow {
    u16   cpu;              /* 패킷이 마지막으로 전달된 CPU */
    u16   filter;           /* aRFS에서 사용하는 필터 ID */
    unsigned int last_qtail; /* 마지막 삽입 시 큐 tail 위치 */
};

struct rps_dev_flow_table {
    unsigned int          mask;  /* 엔트리 수 - 1 */
    struct rcu_head       rcu;
    struct rps_dev_flow   flows[];
};

RFS CPU 선택 로직

RFS의 CPU 선택은 get_rps_cpu() 내부에서 다음 우선순위로 진행된다:

/* get_rps_cpu() 내부 RFS 로직 (단순화) */

/* 1. 전역 sock_flow_table에서 desired CPU 조회 */
desired_cpu = sock_flow_table->ents[hash & sock_flow_table->mask];

/* 2. per-queue dev_flow_table에서 current CPU 조회 */
rflow = &flow_table->flows[hash & flow_table->mask];
current_cpu = rflow->cpu;

/* 3. CPU 선택 결정 */
if (desired_cpu == current_cpu) {
    /* 동일 CPU → 그대로 사용 (최적) */
    cpu = desired_cpu;
} else if (current_cpu_unset || current_cpu_offline ||
         unlikely(qtail - rflow->last_qtail >= backlog_len)) {
    /* current CPU가 미설정/오프라인/backlog 소진됨
     * → desired CPU로 전환 (out-of-order 방지 후) */
    cpu = desired_cpu;
    rflow->cpu = cpu;
} else {
    /* current CPU의 backlog에 아직 이전 패킷이 있음
     * → 순서 보장을 위해 current CPU 유지 */
    cpu = current_cpu;
}

RFS 설정 방법

# 1. 전역 sock_flow_table 크기 설정 (power of 2 권장)
# 활성 연결 수의 2배 이상으로 설정
$ echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

# 2. 큐별 dev_flow_table 크기 설정
# rps_sock_flow_entries / N (N = RX 큐 수)
$ echo 2048 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
$ echo 2048 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt
# ... 모든 RX 큐에 대해 반복

# 3. RPS도 함께 활성화해야 동작함 (RFS는 RPS 위에서 동작)
$ echo ff > /sys/class/net/eth0/queues/rx-0/rps_cpus

# 한 번에 모든 큐 설정 (스크립트)
for rxq in /sys/class/net/eth0/queues/rx-*; do
    echo ff > $rxq/rps_cpus
    echo 2048 > $rxq/rps_flow_cnt
done

소켓 측 CPU 갱신

소켓의 desired CPU는 sock_rps_record_flow()를 통해 갱신된다. 이 함수는 recvmsg(), sendmsg(), tcp_v4_rcv() 등 소켓 처리 경로에서 호출된다:

/* include/net/sock.h — 소켓 처리 시 CPU 기록 */
static inline void sock_rps_record_flow(const struct sock *sk)
{
    struct rps_sock_flow_table *table;

    table = rcu_dereference(rps_sock_flow_table);
    if (table) {
        u32 hash = sk->sk_rxhash;
        if (hash) {
            u32 index = hash & table->mask;
            /* 현재 CPU를 desired CPU로 기록 */
            if (table->ents[index] != raw_smp_processor_id())
                table->ents[index] = raw_smp_processor_id();
        }
    }
}

XPS (Transmit Packet Steering) — 송신 측 CPU-큐 매핑

XPS는 송신(TX) 패킷을 보내는 CPU에 최적화된 TX 큐를 선택하는 메커니즘이다. 멀티큐 NIC에서 TX 큐를 CPU에 적절히 매핑하면 lock contention 감소와 캐시 효율 향상을 얻을 수 있다.

XPS가 해결하는 문제

XPS 없이 멀티큐 NIC에서 패킷을 전송하면, 커널은 skb_tx_hash()를 사용해 해시 기반으로 TX 큐를 선택한다. 이 경우 여러 CPU가 같은 TX 큐를 사용하여 TX 큐 락 경합이 발생할 수 있다:

/* XPS 미설정 시: 해시 기반 TX 큐 선택 */
static u16 skb_tx_hash(const struct net_device *dev,
                       const struct sk_buff *skb)
{
    /* 여러 CPU가 같은 큐를 선택할 수 있음 → lock contention */
    return reciprocal_scale(skb_get_hash(skb),
                           dev->real_num_tx_queues);
}

XPS 동작 원리

XPS를 설정하면, 각 TX 큐에 대해 어떤 CPU가 사용할 수 있는지를 매핑한다. 패킷 전송 시 현재 CPU에 매핑된 TX 큐 중 하나를 선택하여 lock contention을 최소화한다:

/* include/linux/netdevice.h — XPS 매핑 구조체 */
struct xps_map {
    unsigned int   len;          /* 큐 수 */
    unsigned int   alloc_len;
    struct rcu_head rcu;
    u16            queues[];    /* 이 CPU가 사용할 TX 큐 번호 배열 */
};

struct xps_dev_maps {
    struct rcu_head rcu;
    unsigned int   nr_ids;      /* CPU 수 또는 RX 큐 수 */
    s16            num_tc;      /* Traffic Class 수 */
    struct xps_map __rcu *attr_map[];  /* per-CPU 또는 per-RX-queue 매핑 */
};

/* net/core/dev.c — XPS가 활성화된 경우의 TX 큐 선택 */
static int __netdev_pick_tx(struct net_device *dev,
                           struct sk_buff *skb,
                           struct net_device *sb_dev)
{
    struct xps_dev_maps *dev_maps;
    struct xps_map *map;
    int queue_index = -1;

    /* 1. XPS RX-queue 매핑 시도 (수신 큐 → 송신 큐) */
    dev_maps = rcu_dereference(dev->xps_maps[XPS_RXQS]);
    if (dev_maps) {
        map = rcu_dereference(dev_maps->attr_map[skb_get_rx_queue(skb)]);
        if (map)
            queue_index = map->queues[reciprocal_scale(
                skb_get_hash(skb), map->len)];
    }

    /* 2. XPS CPU 매핑 시도 (현재 CPU → 송신 큐) */
    if (queue_index < 0) {
        dev_maps = rcu_dereference(dev->xps_maps[XPS_CPUS]);
        if (dev_maps) {
            map = rcu_dereference(
                dev_maps->attr_map[raw_smp_processor_id()]);
            if (map)
                queue_index = map->queues[
                    reciprocal_scale(skb_get_hash(skb), map->len)];
        }
    }

    /* 3. XPS 미설정 시 fallback: skb_tx_hash() */
    if (queue_index < 0)
        queue_index = skb_tx_hash(dev, skb);

    return queue_index;
}

XPS 두 가지 모드

XPS 설정 방법

# === XPS CPU 모드: CPU → TX 큐 1:1 매핑 ===

# TX Queue 0 → CPU 0 전용
$ echo 1 > /sys/class/net/eth0/queues/tx-0/xps_cpus
# 1 = 00000001(2) → CPU 0만

# TX Queue 1 → CPU 1 전용
$ echo 2 > /sys/class/net/eth0/queues/tx-1/xps_cpus
# 2 = 00000010(2) → CPU 1만

# TX Queue 2 → CPU 2 전용
$ echo 4 > /sys/class/net/eth0/queues/tx-2/xps_cpus

# TX Queue 3 → CPU 3 전용
$ echo 8 > /sys/class/net/eth0/queues/tx-3/xps_cpus

# 8-queue NIC에서 CPU 1:1 매핑 스크립트
for i in $(seq 0 7); do
    printf '%x' $((1 << i)) > /sys/class/net/eth0/queues/tx-$i/xps_cpus
done

# NUMA 인식 매핑: NUMA 0 CPU(0~3) → TX Queue 0~3
#                 NUMA 1 CPU(4~7) → TX Queue 4~7
$ echo 0f > /sys/class/net/eth0/queues/tx-0/xps_cpus  # CPU 0~3
$ echo 0f > /sys/class/net/eth0/queues/tx-1/xps_cpus
$ echo 0f > /sys/class/net/eth0/queues/tx-2/xps_cpus
$ echo 0f > /sys/class/net/eth0/queues/tx-3/xps_cpus
$ echo f0 > /sys/class/net/eth0/queues/tx-4/xps_cpus  # CPU 4~7
$ echo f0 > /sys/class/net/eth0/queues/tx-5/xps_cpus
$ echo f0 > /sys/class/net/eth0/queues/tx-6/xps_cpus
$ echo f0 > /sys/class/net/eth0/queues/tx-7/xps_cpus

# === XPS RXQ 모드: RX 큐 → TX 큐 매핑 ===
# 커널 4.18+ 필요, RSS/RPS로 수신한 큐와 동일 TX 큐 사용

# TX Queue 0 → RX Queue 0에서 수신한 패킷의 응답 전송
$ echo 1 > /sys/class/net/eth0/queues/tx-0/xps_rxqs
# TX Queue 1 → RX Queue 1
$ echo 2 > /sys/class/net/eth0/queues/tx-1/xps_rxqs

# 현재 설정 확인
$ cat /sys/class/net/eth0/queues/tx-0/xps_cpus
00000001
$ cat /sys/class/net/eth0/queues/tx-0/xps_rxqs
0

XPS 모니터링

# TX 큐별 전송 통계
$ ethtool -S eth0 | grep tx_queue
     tx_queue_0_packets: 982341
     tx_queue_0_bytes: 587204160
     tx_queue_1_packets: 978892
     tx_queue_1_bytes: 585023408
     tx_queue_2_packets: 981204
     tx_queue_2_bytes: 586921600
     tx_queue_3_packets: 979563
     tx_queue_3_bytes: 585425376

# TX 큐 락 경합 확인 (perf로)
$ perf stat -e 'lock:contention_begin' -a -- sleep 5

# BPF로 TX 큐 선택 과정 추적
$ bpftrace -e 'kretprobe:__netdev_pick_tx {
    printf("cpu=%d txq=%d\n", cpu, retval);
}'

aRFS (Accelerated RFS) — 하드웨어 가속 RFS

aRFS는 RFS의 결정을 NIC 하드웨어에 반영하여, 패킷이 DMA 단계에서부터 올바른 CPU의 RX 큐로 전달되도록 한다. RFS가 소프트웨어로 패킷을 재분배하는 것과 달리, aRFS는 NIC의 ntuple filter (Flow Director)를 동적으로 프로그래밍하여 하드웨어 수준에서 스티어링한다.

aRFS 동작 흐름

aRFS 커널 API

aRFS를 지원하려면 NIC 드라이버가 ndo_rx_flow_steer 콜백을 구현해야 한다:

/* include/linux/netdevice.h — aRFS 드라이버 콜백 */
struct net_device_ops {
    /* ... */
    int (*ndo_rx_flow_steer)(struct net_device *dev,
                             const struct sk_buff *skb,
                             u16 rxq_index,
                             u32 flow_id);
    /* rxq_index: 대상 RX 큐 번호 */
    /* flow_id:   고유 플로우 식별자 */
    /* 반환값:     NIC에 설정된 필터 ID */
};

/* 예: Intel ixgbe 드라이버의 aRFS 구현 */
static int ixgbe_rx_flow_steer(struct net_device *dev,
                               const struct sk_buff *skb,
                               u16 rxq_index, u32 flow_id)
{
    struct ixgbe_adapter *adapter = netdev_priv(dev);
    struct ixgbe_fdir_filter *input;

    /* 패킷의 5-tuple로 Flow Director 필터 생성 */
    input = kzalloc(sizeof(*input), GFP_ATOMIC);
    /* skb에서 src/dst IP, port 추출 → ATR 필터 설정 */
    ixgbe_fdir_write_perfect_filter(adapter, input, rxq_index);

    return filter_id;
}

aRFS 설정

# aRFS 요구사항:
# 1. NIC가 ntuple filter (Flow Director) 지원
# 2. NIC 드라이버가 ndo_rx_flow_steer 구현
# 3. RFS가 활성화되어 있어야 함

# ntuple filter 활성화
$ ethtool -K eth0 ntuple on

# RFS 설정 (aRFS의 전제 조건)
$ echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
for rxq in /sys/class/net/eth0/queues/rx-*; do
    echo 2048 > $rxq/rps_flow_cnt
done

# aRFS 지원 여부 확인
$ ethtool -k eth0 | grep ntuple
ntuple-filters: on

# 현재 aRFS/Flow Director 규칙 수 확인
$ ethtool -S eth0 | grep fdir
     fdir_match: 28745
     fdir_miss: 312
     fdir_overflow: 0

멀티코어 네트워크 분산 전체 비교

네트워크 패킷 흐름 (Packet Flow) 심화

Netfilter 체인과 패킷 경로

패킷 경로별 상세 흐름

Connection Tracking (conntrack) 심화

/* conntrack은 PREROUTING/OUTPUT 훅에서 패킷의 연결 상태를 추적 */
/* 모든 netfilter 기반 NAT, stateful 방화벽의 기초 */

/* conntrack 엔트리 상태 */
IP_CT_NEW           /* 첫 번째 패킷 (SYN) */
IP_CT_ESTABLISHED   /* 양방향 트래픽 확인됨 */
IP_CT_RELATED       /* 기존 연결과 관련 (FTP data, ICMP error) */
IP_CT_INVALID       /* 상태 추적 실패 */

/* conntrack 해시 테이블 크기 — 성능에 직접 영향 */
/* /proc/sys/net/netfilter/nf_conntrack_max = 262144 */
/* /proc/sys/net/netfilter/nf_conntrack_buckets (readonly) */
/* 최적: max = buckets × 4 (체인 길이 ~4 유지) */

패킷 드롭 디버깅

# 드롭 모니터 — 패킷이 어디서 드롭되는지 추적
perf record -e skb:kfree_skb -a sleep 10
perf script

# dropwatch 도구 활용
dropwatch -l kas
> start
# 출력: drop at: tcp_v4_rcv+0x1a (sobjects hit: 15)

# nftables/iptables 카운터로 규칙별 드롭 확인
iptables -L -v -n | grep DROP
nft list ruleset | grep drop

# 인터페이스 통계로 드롭 위치 파악
ethtool -S eth0 | grep -i drop
cat /proc/net/softnet_stat  # 컬럼: processed, dropped, time_squeeze

# netstat 프로토콜별 에러 통계
netstat -s | grep -i -E "drop|error|overflow|pruned"

# BPF 기반 패킷 추적 (bcc/bpftrace)
bpftrace -e 'tracepoint:skb:kfree_skb { @[kstack] = count(); }'

패킷 흐름 설계 시 고려사항

SmartNIC / DPU 기반 네트워크 가속

DPU(Data Processing Unit)는 단순 NIC를 넘어 자체 프로세서(ARM SoC), 메모리, 스토리지 인터페이스, 하드웨어 가속기를 탑재한 독립적인 컴퓨팅 플랫폼입니다. 데이터센터의 네트워킹, 보안, 스토리지 처리를 호스트 CPU에서 DPU로 오프로드하여 인프라 오버헤드를 제거하고, 호스트 CPU를 애플리케이션 워크로드에 전용할 수 있습니다.

NIC vs SmartNIC vs DPU 비교

DPU 하드웨어 아키텍처

DPU의 핵심 특징은 완전한 Linux 커널을 자체 ARM SoC에서 구동한다는 점입니다. 호스트와 독립적인 OS를 실행하면서 네트워크, 스토리지, 보안 서비스를 제공하고, 호스트에는 SR-IOV VF나 Virtio 디바이스만 노출합니다. 이로써 호스트 OS가 침해되더라도 인프라 서비스(방화벽, 암호화, 스토리지 가상화)의 무결성이 유지됩니다.

주요 DPU/IPU 제품군

DPU 오프로드 기능 상세

커널의 DPU 지원 서브시스템

리눅스 커널은 DPU를 지원하기 위해 여러 서브시스템을 활용합니다. 핵심은 devlink(디바이스 구성), switchdev(eSwitch 제어), representor port(VF/SF를 호스트에서 관리), auxiliary bus(다기능 디바이스 분할)입니다.

devlink: DPU 구성 및 관리

devlink은 DPU/SmartNIC를 관리하는 핵심 커널 인터페이스입니다. eSwitch 모드 전환, 포트 기능 설정, 리소스 할당, 펌웨어 관리, 헬스 리포터 등을 통합적으로 제어합니다.

# ━━━ devlink 기본 관리 ━━━

# DPU 디바이스 목록 조회
devlink dev show
# pci/0000:03:00.0: fw.mgmt 24.39.1002 fw.app 24.39.1002

# 펌웨어 버전 상세 조회
devlink dev info pci/0000:03:00.0
# driver: mlx5_core
# fw.mgmt: 24.39.1002
# fw.undi: 14.32.17
# fw.psid: MT_0000000835

# ━━━ eSwitch 모드 전환 ━━━

# legacy 모드 → switchdev 모드 (eSwitch 활성화)
# ⚠️ 모드 전환 시 네트워크 순간 단절 발생
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# eSwitch 인라인 모드 설정 (매칭 깊이)
devlink dev eswitch set pci/0000:03:00.0 inline-mode transport

# 현재 eSwitch 모드 확인
devlink dev eswitch show pci/0000:03:00.0
# mode switchdev inline-mode transport encap-mode basic

# ━━━ SR-IOV VF 관리 ━━━

# VF 생성 (PCIe SR-IOV)
echo 8 > /sys/class/net/enp3s0f0np0/device/sriov_numvfs

# VF의 MAC, VLAN, 대역폭 설정
ip link set enp3s0f0np0 vf 0 mac 00:11:22:33:44:55
ip link set enp3s0f0np0 vf 0 vlan 100
ip link set enp3s0f0np0 vf 0 max_tx_rate 10000  # Mbps

# VF representor 포트 확인 (switchdev 모드에서 자동 생성)
ip link show | grep "enp3s0f0np0_"
# enp3s0f0np0_0  ← VF0 representor
# enp3s0f0np0_1  ← VF1 representor

# ━━━ Scalable Functions (SF) ━━━

# SF 생성 (SR-IOV VF의 경량 대안, BlueField/ConnectX-7+)
devlink port add pci/0000:03:00.0 flavour pcisf pfnum 0 sfnum 88
devlink port function set pci/0000:03:00.0/32768 hw_addr 00:00:00:00:88:88 state active

# SF 포트 기능 설정
devlink port function set pci/0000:03:00.0/32768 \
    roce true \
    migratable true \
    ipsec_crypto true \
    ipsec_packet true

# SF의 auxiliary 디바이스 활성화
devlink port function set pci/0000:03:00.0/32768 state active

# 생성된 SF 확인
devlink port show pci/0000:03:00.0/32768
# pci/0000:03:00.0/32768: type eth netdev en3f0pf0sf88 flavour pcisf
#   controller 0 pfnum 0 sfnum 88 splittable false
#   function: hw_addr 00:00:00:00:88:88 state active opstate attached

Representor Port 아키텍처

Representor port는 switchdev 모드에서 DPU가 호스트 측에 노출하는 가상 netdev입니다. 각 VF/SF에 대응하는 representor가 생성되어, 호스트에서 TC flower 규칙을 통해 VF/SF 트래픽을 제어할 수 있습니다. 이는 OVS offload의 핵심 메커니즘입니다.

/* drivers/net/ethernet/mellanox/mlx5/core/eswitch.h */
struct mlx5_eswitch_rep {
    struct mlx5_eswitch *esw;
    u16 vport;                      /* 연결된 VF/SF의 vport 번호 */
    u16 vlan;                       /* 기본 VLAN */
    struct net_device *netdev;       /* representor netdev */
    struct mlx5_flow_handle *send_to_vport_rule;
    struct mlx5e_rep_priv *rep_data;
};

/* Representor의 역할:
 * 1. VF/SF로 향하는 slow-path 패킷의 수신/송신 경로
 * 2. TC flower 규칙의 연결점 (representor에 규칙 설치 → eSwitch HW로 오프로드)
 * 3. OVS 브릿지의 포트로 연결 (ovs-vsctl add-port br0 enp3s0f0np0_0)
 * 4. conntrack offload의 앵커 포인트
 */

/* drivers/net/ethernet/mellanox/mlx5/core/en_rep.c */
static const struct net_device_ops mlx5e_netdev_ops_rep = {
    .ndo_open         = mlx5e_rep_open,
    .ndo_stop         = mlx5e_rep_close,
    .ndo_start_xmit   = mlx5e_xmit,           /* slow-path 송신 */
    .ndo_setup_tc     = mlx5e_rep_setup_tc,   /* TC flower 오프로드 진입점 */
    .ndo_get_stats64  = mlx5e_rep_get_stats,  /* HW 카운터 기반 통계 */
};

OVS TC Flower Offload 동작 원리

Open vSwitch(OVS)는 가상 스위칭의 표준이지만, 소프트웨어 처리로 인해 CPU 오버헤드가 큽니다. DPU의 eSwitch를 활용하면 OVS 플로우를 하드웨어로 오프로드하여 호스트 CPU 사용을 90% 이상 줄일 수 있습니다.

# ━━━ OVS-DPDK + TC Flower HW Offload 설정 ━━━

# 1. eSwitch를 switchdev 모드로 전환
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# 2. OVS에서 하드웨어 오프로드 활성화
ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
ovs-vsctl set Open_vSwitch . other_config:tc-policy=skip_sw

# 3. OVS 브릿지에 PF와 VF representor 연결
ovs-vsctl add-br br-int
ovs-vsctl add-port br-int enp3s0f0np0       # PF (uplink)
ovs-vsctl add-port br-int enp3s0f0np0_0     # VF0 representor
ovs-vsctl add-port br-int enp3s0f0np0_1     # VF1 representor

# 4. 오프로드 동작 흐름:
#   a) 첫 패킷: eSwitch → representor → OVS userspace → flow 결정
#   b) OVS가 TC flower 규칙을 representor에 설치
#   c) 드라이버가 TC flower → eSwitch HW 규칙으로 변환
#   d) 이후 패킷: eSwitch HW에서 직접 포워딩 (CPU 바이패스)

# 오프로드된 플로우 확인
tc -s filter show dev enp3s0f0np0_0 ingress
# filter protocol ip pref 2 flower chain 0
#   eth_type ipv4
#   src_ip 10.0.0.5
#   dst_ip 10.0.0.10
#   in_hw in_hw_count 1    ← HW 오프로드 확인
#     action order 1: mirred (Egress Redirect to device enp3s0f0np0_1)
#     hw_stats immediate

# OVS 오프로드 통계 확인
ovs-appctl dpctl/dump-flows type=offloaded
# recirc_id(0),in_port(2),eth(...),ipv4(src=10.0.0.5,dst=10.0.0.10,...)
# packets:1523400, bytes:97497600, used:0.001s, flags:SFPR

auxiliary_bus: DPU 다기능 디바이스 분할

auxiliary_bus는 하나의 PCIe 디바이스가 여러 기능(네트워크, RDMA, crypto, vDPA 등)을 독립적인 커널 드라이버에 분배하기 위한 메커니즘입니다. DPU처럼 다기능 디바이스에서 핵심적인 역할을 합니다.

/* include/linux/auxiliary_bus.h */
struct auxiliary_device {
    struct device dev;
    const char *name;   /* "mlx5_core.eth.0", "mlx5_core.rdma.0" 등 */
    u32 id;
};

struct auxiliary_driver {
    int (*probe)(struct auxiliary_device *adev,
                const struct auxiliary_device_id *id);
    void (*remove)(struct auxiliary_device *adev);
    const char *name;
    struct device_driver driver;
    const struct auxiliary_device_id *id_table;
};

/* mlx5 DPU에서 auxiliary_bus 활용 예시:
 *
 * mlx5_core (PCI 드라이버)
 *   ├── mlx5_core.eth.0     → mlx5e (이더넷 netdev)
 *   ├── mlx5_core.rdma.0    → mlx5_ib (RDMA/RoCE)
 *   ├── mlx5_core.vnet.0    → mlx5_vnet (vDPA - virtio 에뮬레이션)
 *   ├── mlx5_core.sf.88     → Scalable Function #88
 *   └── mlx5_core.crypto.0  → Crypto offload
 *
 * 각 기능이 독립 드라이버로 동작하며, 개별 로드/언로드 가능
 */

/* Scalable Function 등록 (drivers/net/ethernet/mellanox/mlx5/core/sf/) */
static int mlx5_sf_dev_probe(struct auxiliary_device *adev,
                             const struct auxiliary_device_id *id)
{
    struct mlx5_sf_dev *sf_dev = container_of(adev, struct mlx5_sf_dev, adev);
    struct mlx5_core_dev *mdev;

    mdev = mlx5_sf_dev_to_mdev(sf_dev);
    /* SF용 mlx5_core_dev 초기화 → 독립 netdev + RDMA + crypto 생성 */
    return mlx5_init_one(mdev);
}

IPsec / TLS 인라인 암호화 오프로드

DPU는 IPsec ESP와 TLS(kTLS)의 암호화/복호화를 하드웨어에서 수행하여 라인 레이트 암호화를 제공합니다. 커널의 xfrm_dev_offload 인터페이스를 통해 SA를 NIC에 직접 설치합니다.

/* include/net/xfrm.h — 하드웨어 오프로드 구조체 */
struct xfrm_dev_offload {
    struct net_device *dev;
    struct net_device *real_dev;  /* bond/vlan의 실제 HW 디바이스 */
    unsigned long offload_handle; /* 드라이버의 HW 오브젝트 핸들 */
    u8 dir : 2;                  /* XFRM_DEV_OFFLOAD_IN/OUT */
    u8 type : 2;                 /* CRYPTO (암호만) / PACKET (전체) */
    u8 flags : 2;
};

/* IPsec 오프로드 타입:
 * XFRM_DEV_OFFLOAD_CRYPTO — 암호화/복호화만 HW, 헤더 처리는 SW
 *   → ESP trailer/header는 커널이 추가, 암호 연산만 NIC 가속
 *   → 대부분의 NIC에서 지원 (ConnectX-6+, E810)
 *
 * XFRM_DEV_OFFLOAD_PACKET — 전체 IPsec 처리를 HW에서 수행
 *   → ESP 헤더 추가, SPI 매칭, anti-replay, 암호화 모두 NIC
 *   → 호스트 CPU 관여 0%. 최대 성능
 *   → BlueField-2/3에서 지원 (full offload)
 */

/* mlx5 드라이버의 IPsec offload 등록 */
/* drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c */
static const struct xfrmdev_ops mlx5e_ipsec_xfrmdev_ops = {
    .xdo_dev_state_add    = mlx5e_xfrm_add_state,    /* SA를 HW에 설치 */
    .xdo_dev_state_delete = mlx5e_xfrm_del_state,    /* HW SA 삭제 */
    .xdo_dev_state_free   = mlx5e_xfrm_free_state,   /* 리소스 해제 */
    .xdo_dev_offload_ok   = mlx5e_ipsec_offload_ok,  /* 오프로드 가능 여부 확인 */
    .xdo_dev_policy_add   = mlx5e_xfrm_add_policy,   /* SP를 HW에 설치 */
    .xdo_dev_policy_delete= mlx5e_xfrm_del_policy,
};

# ━━━ IPsec HW Offload 설정 예시 ━━━

# 1. 디바이스의 IPsec offload 지원 확인
ethtool -k enp3s0f0np0 | grep esp
# esp-hw-offload: on
# esp-tx-csum-hw-offload: on

# 2. IPsec SA 추가 시 offload 지정
ip xfrm state add \
    src 10.0.0.1 dst 10.0.0.2 \
    proto esp spi 0x1000 mode transport \
    aead "rfc4106(gcm(aes))" 0x$(openssl rand -hex 20) 128 \
    offload dev enp3s0f0np0 dir out   # ← HW offload 지정

ip xfrm state add \
    src 10.0.0.2 dst 10.0.0.1 \
    proto esp spi 0x2000 mode transport \
    aead "rfc4106(gcm(aes))" 0x$(openssl rand -hex 20) 128 \
    offload dev enp3s0f0np0 dir in

# 3. packet offload (full offload — BlueField-2/3)
ip xfrm state add \
    src 10.0.0.1 dst 10.0.0.2 \
    proto esp spi 0x3000 mode tunnel \
    aead "rfc4106(gcm(aes))" 0x$(openssl rand -hex 20) 128 \
    offload packet dev enp3s0f0np0 dir out  # ← packet 전체 오프로드

# 4. HW offload 상태 확인
ip xfrm state list
# ... offload type packet dev enp3s0f0np0 dir out ...

# 5. kTLS offload (TLS 1.3)
ethtool -k enp3s0f0np0 | grep tls
# tls-hw-tx-offload: on
# tls-hw-rx-offload: on
# tls-hw-record: on

# nginx에서 kTLS + HW offload 활용 (커널 5.2+)
# setsockopt(fd, SOL_TLS, TLS_TX, ...) → 커널이 자동 HW 오프로드

DPU 스토리지 오프로드

DPU는 네트워크뿐만 아니라 스토리지 가상화도 오프로드합니다. NVMe-oF(NVMe over Fabrics) 타겟을 DPU에서 실행하거나, virtio-blk 백엔드를 DPU의 ARM에서 처리하여 호스트 CPU를 완전히 해방시킵니다.

# ━━━ NVMe-oF SNAP (BlueField DPU) ━━━

# DPU ARM 측에서 NVMe-oF SNAP 컨트롤러 생성
# → 호스트에 가상 NVMe 디바이스가 나타남

# 1. SNAP 서비스 시작 (DPU ARM에서)
snap_rpc.py controller_nvme_create \
    --pf_id 0 \
    --nqn nqn.2022-01.com.nvidia:subsys1

# 2. 원격 NVMe-oF 타겟 연결
snap_rpc.py subsystem_nvme_create \
    --nqn nqn.2022-01.com.nvidia:subsys1 \
    --trtype rdma \
    --traddr 192.168.100.10 \
    --trsvcid 4420

# 호스트에서 확인 (별도 드라이버 불필요)
nvme list
# /dev/nvme0n1  SNAP Virtual NVMe  1.95 TB

# ━━━ vDPA (virtio DataPath Acceleration) ━━━

# DPU에서 vDPA 디바이스 생성 → VM에 virtio-net HW 가속 제공
# 호스트 커널의 vDPA bus + vhost-vdpa로 QEMU에 연결

# 1. vDPA management 디바이스 확인
vdpa mgmtdev show
# auxiliary/mlx5_core.sf.4:
#   supported_classes net

# 2. vDPA 디바이스 생성
vdpa dev add name vdpa0 mgmtdev auxiliary/mlx5_core.sf.4 \
    mac 00:11:22:33:44:55 max_vqp 8

# 3. QEMU에서 vhost-vdpa 디바이스로 VM에 연결
# -netdev vhost-vdpa,vhostdev=/dev/vhost-vdpa-0,id=vdpa0
# -device virtio-net-pci,netdev=vdpa0

DPU 보안 아키텍처

DPU의 가장 중요한 가치 중 하나는 인프라 보안의 격리입니다. 호스트 OS와 독립된 신뢰 도메인에서 보안 서비스를 실행하여, 호스트가 침해되더라도 인프라 무결성을 유지합니다.

# ━━━ BlueField DPU 보안 모드 설정 ━━━

# DPU 동작 모드 확인 (mlxconfig)
mlxconfig -d /dev/mst/mt41692_pciconf0 query | grep -i "internal_cpu"
# INTERNAL_CPU_MODEL = EMBEDDED_CPU(1)

# 호스트 권한 모드 설정
# Privileged:    호스트가 DPU PF를 직접 제어 (개발/테스트용)
# Restricted:    DPU ARM이 모든 제어권 보유, 호스트는 VF만 사용
# Restricted+:   호스트가 DPU 리셋/재부팅도 불가
mlxconfig -d /dev/mst/mt41692_pciconf0 set INTERNAL_CPU_PAGE_SUPPLIER=ECPF
mlxconfig -d /dev/mst/mt41692_pciconf0 set INTERNAL_CPU_ESWITCH_MANAGER=ECPF
mlxconfig -d /dev/mst/mt41692_pciconf0 set INTERNAL_CPU_OFFLOAD_ENGINE=ENABLED

# ━━━ DPU 기반 격리된 방화벽 ━━━

# DPU ARM에서 nftables 방화벽 실행 (호스트 독립)
# → eSwitch를 통과하는 모든 호스트 트래픽에 적용
# → 호스트 root 권한으로도 우회 불가
nft add table inet host_fw
nft add chain inet host_fw input { type filter hook ingress device enp3s0f0np0 priority 0 \; }
nft add rule inet host_fw input ip saddr != 10.0.0.0/8 drop

# DPU의 독립 로깅 (syslog → 중앙 서버)
# 호스트 침해 시에도 DPU 로그는 보존

DPU 프로그래밍 모델

/* P4 프로그래밍 예시 — DPU의 프로그래머블 파이프라인에서 실행
 * Intel IPU (IPDK) 또는 AMD Pensando에서 P4 컴파일러로 HW 테이블 생성
 */

/* 커스텀 헤더 파싱 및 매칭 */
header custom_header_t {
    bit<16> type_id;
    bit<32> tenant_id;
    bit<16> service_tag;
}

parser CustomParser(packet_in pkt, out headers_t hdr) {
    state start {
        pkt.extract(hdr.ethernet);
        transition select(hdr.ethernet.etherType) {
            0x8100: parse_vlan;
            0x0800: parse_ipv4;
            0xFE01: parse_custom;  /* 커스텀 프로토콜 */
            default: accept;
        }
    }
    state parse_custom {
        pkt.extract(hdr.custom);
        transition parse_ipv4;
    }
}

/* 매칭 테이블: tenant_id 기반 라우팅 */
table tenant_routing {
    key = {
        hdr.custom.tenant_id : exact;
        hdr.ipv4.dstAddr     : lpm;
    }
    actions = {
        forward_to_port;
        apply_encryption;
        drop;
    }
    size = 1048576;  /* 100만 엔트리 */
}

DPU 모니터링 및 디버깅

# ━━━ devlink 헬스 리포터 ━━━
# DPU 하드웨어 상태 모니터링

devlink health show pci/0000:03:00.0
# reporter fw_fatal:
#   state healthy error 0 recover 0
# reporter fw:
#   state healthy error 0 recover 0
# reporter vnic:
#   state healthy error 0 recover 0

# 헬스 리포터 상세 덤프
devlink health dump show pci/0000:03:00.0 reporter fw

# ━━━ eSwitch 플로우 카운터 ━━━
# HW 오프로드된 플로우의 패킷/바이트 통계

tc -s filter show dev enp3s0f0np0_0 ingress
# filter ... flower ...
#   Sent 98234567 bytes 1523400 pkt (hardware)
#   action ... mirred ... (hardware)
#     Sent 98234567 bytes 1523400 pkt

# ━━━ DPU 리소스 사용량 ━━━

# 사용 가능한 HW 리소스 조회
devlink resource show pci/0000:03:00.0
# name flow_table size 4194304 occ 152340
# name flow_counter size 16777216 occ 304680
# name encap_entries size 65536 occ 1024

# ━━━ ethtool 확장 통계 ━━━

ethtool -S enp3s0f0np0 | grep -E "offload|hw_"
# rx_vport_rdma_unicast_packets: 4523100
# tx_vport_rdma_unicast_packets: 3891200
# rx_hw_timestamp: 15234001

# ━━━ SF/VF 개별 통계 ━━━

# Scalable Function 상태 확인
devlink port function show pci/0000:03:00.0/32768
# function:
#   hw_addr 00:00:00:00:88:88 state active opstate attached
#   roce true migratable true ipsec_crypto true

# ━━━ 디버깅 팁 ━━━
# HW offload 문제 시: skip_hw → skip_sw 순서로 테스트
# 1단계: skip_hw로 SW 경로에서 규칙이 올바른지 확인
tc filter add dev rep0 ingress flower ... action ... skip_hw
# 2단계: skip_sw로 HW 전용으로 전환, in_hw 확인
tc filter add dev rep0 ingress flower ... action ... skip_sw

# 오프로드 실패 원인 확인 (커널 로그)
dmesg | grep -i "offload\|eswitch\|flower"
# mlx5_core: TC flower offload failed: -EOPNOTSUPP (지원 안 되는 액션)
# mlx5_core: flow table full, falling back to software

DPDK (Data Plane Development Kit) 심화

DPDK는 Intel이 주도하여 개발한 고성능 패킷 처리 프레임워크로, 커널 네트워크 스택을 완전히 바이패스하여 유저 공간에서 NIC를 직접 제어합니다. 표준 커널 드라이버가 인터럽트 기반으로 패킷을 처리하는 반면, DPDK는 폴링(polling) 기반 PMD(Poll Mode Driver)를 사용하여 컨텍스트 스위칭과 인터럽트 오버헤드를 제거합니다. 10~400GbE 환경에서 수십~수백 Mpps(백만 패킷/초)의 처리량을 단일 서버에서 달성할 수 있으며, 통신사(NFV), 클라우드(가상 스위칭), 금융(초저지연 트레이딩), CDN, 보안 장비 등에서 핵심 기술로 사용됩니다.

DPDK 아키텍처 개요

커널 네트워크 스택 vs DPDK 비교

EAL (Environment Abstraction Layer)

EAL은 DPDK의 초기화 계층으로, 애플리케이션이 하드웨어와 OS 세부 사항에 독립적으로 동작하도록 추상화합니다. rte_eal_init() 호출 시 수행되는 핵심 작업:

/* rte_eal_init() 초기화 순서 (Linux) */

1. 커맨드라인 파싱 (-l, -n, --socket-mem, --file-prefix, --proc-type ...)
2. Hugepage 매핑
   ├── /sys/kernel/mm/hugepages/ 에서 hugepage 정보 수집
   ├── hugetlbfs 마운트 확인 (/dev/hugepages 또는 --huge-dir)
   ├── hugepage 파일 생성 → mmap() → 물리 주소 역변환 (pagemap)
   └── NUMA 노드별 메모리 할당 (--socket-mem 0,1024 → 노드1에 1GB)
3. 메모리 초기화
   ├── malloc_heap 설정 (NUMA-aware)
   ├── memzone 등록 (이름→주소 매핑)
   └── mempool 사전 할당 준비
4. CPU 코어 관리
   ├── -l 0-3 또는 --lcores 옵션에서 논리 코어 목록 파싱
   ├── pthread 생성 + CPU affinity 설정 (pthread_setaffinity_np)
   └── main lcore 결정 (첫 번째 코어)
5. PCI 버스 스캔
   ├── /sys/bus/pci/devices/ 순회
   ├── VFIO 또는 UIO 바인딩 상태 확인
   └── 지원되는 PMD와 디바이스 매칭 (vendor:device ID)
6. 서비스 코어 (선택)
   └── --service-lcore로 비데이터 경로 작업 전담 코어 지정
7. 로깅, 타이머, 인터럽트 핸들러 초기화

/* DPDK 애플리케이션 기본 구조 */
#include <rte_eal.h>
#include <rte_ethdev.h>
#include <rte_mbuf.h>

int main(int argc, char *argv[])
{
    /* EAL 초기화: hugepage 매핑, 코어 설정, PCI 스캔 */
    int ret = rte_eal_init(argc, argv);
    if (ret < 0)
        rte_exit(EXIT_FAILURE, "EAL init failed\n");

    /* Mempool 생성 (패킷 버퍼 풀) */
    struct rte_mempool *mbuf_pool = rte_pktmbuf_pool_create(
        "MBUF_POOL",
        8192,              /* 풀 크기 (mbuf 개수) */
        256,               /* per-core 캐시 크기 */
        0,                 /* priv_size */
        RTE_MBUF_DEFAULT_BUF_SIZE,  /* 데이터룸 크기 */
        rte_socket_id()    /* NUMA 소켓 */
    );

    /* 포트 설정 및 시작 */
    struct rte_eth_conf port_conf = { 0 };
    rte_eth_dev_configure(port_id, nb_rx_q, nb_tx_q, &port_conf);
    rte_eth_rx_queue_setup(port_id, 0, 1024, rte_eth_dev_socket_id(port_id),
                          NULL, mbuf_pool);
    rte_eth_tx_queue_setup(port_id, 0, 1024, rte_eth_dev_socket_id(port_id),
                          NULL);
    rte_eth_dev_start(port_id);

    /* 메인 패킷 처리 루프 (busy-poll) */
    while (!force_quit) {
        struct rte_mbuf *bufs[32];
        uint16_t nb_rx = rte_eth_rx_burst(port_id, 0, bufs, 32);
        if (nb_rx == 0)
            continue;

        /* 패킷 처리 ... */
        process_packets(bufs, nb_rx);

        uint16_t nb_tx = rte_eth_tx_burst(port_id, 0, bufs, nb_rx);
        for (uint16_t i = nb_tx; i < nb_rx; i++)
            rte_pktmbuf_free(bufs[i]);  /* 전송 실패 mbuf 반환 */
    }

    rte_eal_cleanup();
    return 0;
}

PMD (Poll Mode Driver)

PMD는 DPDK의 핵심으로, 커널 드라이버 없이 유저 공간에서 NIC를 직접 제어합니다. NIC의 PCIe BAR를 mmap()하여 하드웨어 레지스터에 직접 접근하고, DMA 디스크립터 링(descriptor ring)을 유저 공간 메모리에 배치합니다.

/* PMD RX 동작 원리 (ixgbe PMD 기준) */

  NIC Hardware                        User Space (PMD)
  ┌─────────────┐                    ┌─────────────────────┐
  │   RX Queue  │                    │   RX Descriptor Ring│
  │  ┌────────┐ │  DMA               │  ┌───────────────┐  │
  │  │ 패킷   │─┼──────────────────→│  │ DD bit = 1    │  │  ← NIC가 DMA 완료 후 DD 설정
  │  │ 수신   │ │                    │  │ mbuf addr     │  │
  │  └────────┘ │                    │  │ pkt_len, etc. │  │
  │             │                    │  └───────────────┘  │
  │  Tail Reg ←─┼────────────────────┤  PMD가 tail 갱신   │
  └─────────────┘                    │  (새 mbuf 주소 제공) │
                                     └─────────────────────┘

  1. PMD가 RX descriptor의 DD(Descriptor Done) 비트를 폴링
  2. DD=1이면 → DMA 완료 → mbuf에 패킷 데이터가 있음
  3. descriptor에서 패킷 메타데이터(길이, RSS hash, VLAN 등) 추출
  4. 사용된 descriptor에 새 mbuf 주소를 채워 NIC에 반환 (tail 레지스터 갱신)
  5. rte_eth_rx_burst()가 최대 nb_pkts개의 mbuf 포인터 배열을 반환

/* PMD의 RX burst 내부 (간략화) — ixgbe_recv_pkts() 기반 */
static uint16_t
pmd_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
{
    struct pmd_rx_queue *rxq = rx_queue;
    volatile union rx_desc *rxdp;  /* 하드웨어 descriptor 포인터 */
    uint16_t nb_rx = 0;

    while (nb_rx < nb_pkts) {
        rxdp = &rxq->rx_ring[rxq->rx_tail];

        /* DD 비트 확인: NIC가 DMA를 완료했는가? */
        if (!(rxdp->wb.status & RX_DESC_DD))
            break;  /* 더 이상 수신된 패킷 없음 */

        /* mbuf 회수 및 메타데이터 설정 */
        struct rte_mbuf *mb = rxq->sw_ring[rxq->rx_tail];
        mb->pkt_len = rxdp->wb.pkt_len;
        mb->data_len = rxdp->wb.pkt_len;
        mb->hash.rss = rxdp->wb.rss_hash;
        mb->vlan_tci = rxdp->wb.vlan_tag;

        rx_pkts[nb_rx++] = mb;

        /* 새 mbuf를 할당하여 descriptor에 채움 (NIC에 반환) */
        struct rte_mbuf *nmb = rte_mbuf_raw_alloc(rxq->mb_pool);
        rxdp->read.pkt_addr = rte_mbuf_data_iova(nmb);
        rxq->sw_ring[rxq->rx_tail] = nmb;

        rxq->rx_tail = (rxq->rx_tail + 1) & rxq->rx_tail_mask;
    }

    /* tail 레지스터 갱신 → NIC에 새 descriptor 사용 가능 알림 */
    if (nb_rx)
        rte_write32(rxq->rx_tail, rxq->tail_ptr);

    return nb_rx;
}

/* PMD의 TX burst 내부 (간략화) */
static uint16_t
pmd_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
{
    struct pmd_tx_queue *txq = tx_queue;
    uint16_t nb_tx = 0;

    /* 이전에 전송 완료된 descriptor 정리 (mbuf 반환) */
    tx_free_bufs(txq);

    while (nb_tx < nb_pkts) {
        volatile union tx_desc *txdp = &txq->tx_ring[txq->tx_tail];
        struct rte_mbuf *mb = tx_pkts[nb_tx];

        /* TX descriptor에 mbuf의 DMA 주소와 길이 설정 */
        txdp->read.buffer_addr = rte_mbuf_data_iova(mb);
        txdp->read.cmd_type_len = mb->data_len | TX_DESC_EOP | TX_DESC_RS;

        txq->sw_ring[txq->tx_tail] = mb;
        txq->tx_tail = (txq->tx_tail + 1) & txq->tx_tail_mask;
        nb_tx++;
    }

    /* tail 레지스터 갱신 → NIC가 전송 시작 */
    rte_wmb();  /* 메모리 배리어: descriptor 쓰기 완료 보장 */
    rte_write32(txq->tx_tail, txq->tail_ptr);

    return nb_tx;
}

rte_mbuf 구조체

rte_mbuf는 DPDK의 패킷 버퍼로, 커널의 sk_buff에 대응하지만 설계 철학이 다릅니다. sk_buff는 동적으로 할당되며 메타데이터가 풍부한 반면, rte_mbuf는 Mempool에서 사전 할당되어 고정 크기의 경량 구조체입니다.

/* rte_mbuf 핵심 필드 (lib/mbuf/rte_mbuf_core.h) */
struct rte_mbuf {
    /* ── 캐시라인 0 (핫 필드) ── */
    void         *buf_addr;       /* 가상 주소: headroom + 데이터 시작 */
    rte_iova_t    buf_iova;       /* IO 가상 주소 (DMA용, IOVA) */

    union {
        struct {
            uint32_t pkt_len;       /* 전체 패킷 길이 (체인 포함) */
            uint16_t data_len;      /* 이 세그먼트의 데이터 길이 */
            uint16_t vlan_tci;      /* VLAN Tag */
        };
    };
    uint64_t      ol_flags;       /* Offload 플래그 (checksum, TSO, VLAN...) */

    union {
        uint32_t rss;            /* RSS 해시값 */
        struct {
            uint16_t hash;
            uint16_t id;
        } fdir;                     /* Flow Director 필터 ID */
    } hash;

    uint16_t      data_off;       /* buf_addr부터 데이터 시작까지 오프셋 (headroom) */
    uint16_t      refcnt;         /* 참조 카운트 (공유 mbuf) */
    uint16_t      nb_segs;        /* 체인된 세그먼트 수 */
    uint16_t      port;           /* 입력 포트 ID */

    /* ── 캐시라인 1 (TX offload) ── */
    uint64_t      tx_offload;     /* L2/L3/L4 len, TSO segsz 등 (비트필드) */
    struct rte_mempool *pool;    /* 소속 Mempool (반환 시 사용) */
    struct rte_mbuf    *next;    /* 다음 세그먼트 (체인) */

    /* buf_addr 이전에 headroom(128B), 뒤에 데이터+tailroom이 위치 */
    /*                                                            */
    /* ┌──────────┬──────────┬──────────────────────┬──────────┐ */
    /* │ rte_mbuf │ headroom │     packet data      │ tailroom │ */
    /* │ (struct) │ (128B)   │     (variable)       │          │ */
    /* └──────────┴──────────┴──────────────────────┴──────────┘ */
    /* ^buf_addr  ^data_off                                     */
};

Ring 라이브러리

DPDK rte_ring은 고정 크기, FIFO, lock-free 큐로, 코어 간 패킷 전달, 멀티프로세스 IPC, 태스크 분배 등에 사용됩니다. CAS(Compare-And-Swap) 연산 기반으로 락 없이 다수 생산자/소비자를 지원합니다.

/* Ring 기본 사용 */
struct rte_ring *ring = rte_ring_create(
    "MY_RING",
    1024,                /* 크기 (2의 거듭제곱이어야 함) */
    rte_socket_id(),     /* NUMA 소켓 */
    RING_F_SP_ENQ | RING_F_SC_DEQ  /* 단일 생산자/소비자 (더 빠름) */
);

/* 생산자: 패킷을 Ring에 삽입 */
struct rte_mbuf *pkts[32];
unsigned nb = rte_eth_rx_burst(port, 0, pkts, 32);
unsigned sent = rte_ring_enqueue_burst(ring, (void **)pkts, nb, NULL);

/* 소비자: Ring에서 패킷 추출 (다른 코어) */
struct rte_mbuf *dequeued[32];
unsigned got = rte_ring_dequeue_burst(ring, (void **)dequeued, 32, NULL);

/* rte_ring 내부 구조 — Lock-free CAS 기반 */

  ┌───────────────────────────────────────────────────┐
  │ rte_ring (크기 = 2^n)                               │
  │                                                     │
  │  prod.head ──→ prod.tail ──→ ... ──→ cons.head ──→ cons.tail
  │                                                     │
  │  [slot0][slot1][slot2][...][slotN-1]                │
  │    ↑                   ↑                            │
  │  cons.tail          prod.head                       │
  └───────────────────────────────────────────────────┘

  Enqueue (MP — 다중 생산자):
  1. prod.head를 CAS로 원자적 증가 (여러 생산자가 동시에 슬롯 예약)
  2. 예약된 슬롯에 데이터 복사
  3. prod.tail을 순서대로 갱신 (모든 이전 생산자가 완료될 때까지 대기)

  Dequeue (MC — 다중 소비자):
  1. cons.head를 CAS로 원자적 증가 (여러 소비자가 동시에 슬롯 예약)
  2. 예약된 슬롯에서 데이터 읽기
  3. cons.tail을 순서대로 갱신

  SP/SC (단일 생산자/소비자):
  - CAS 대신 단순 증가. 메모리 배리어만 사용. 30~50% 더 빠름

Mempool과 메모리 관리

rte_mempool은 고정 크기 객체의 풀로, DPDK에서 mbuf 할당/해제의 핵심입니다. Hugepage 위에 구축되며, per-core 캐시로 코어 간 경합을 최소화합니다.

/* Mempool 메모리 레이아웃 */

  Hugepage (2MB 또는 1GB)
  ┌──────────────────────────────────────────────┐
  │  rte_mempool header                           │
  │  ┌──────────────────────────────────────────┐ │
  │  │ Per-Core Cache (core 0): [mbuf ptr] x 256│ │  ← 락 없이 할당/반환
  │  │ Per-Core Cache (core 1): [mbuf ptr] x 256│ │
  │  │ Per-Core Cache (core 2): [mbuf ptr] x 256│ │
  │  │ ...                                      │ │
  │  └──────────────────────────────────────────┘ │
  │  Ring (공용 풀): [mbuf ptr] x N               │  ← per-core 캐시 부족 시 사용
  │  ┌──────────────────────────────────────────┐ │
  │  │ mbuf[0] | headroom | data area           │ │  ← 물리적으로 연속
  │  │ mbuf[1] | headroom | data area           │ │
  │  │ ...                                      │ │
  │  │ mbuf[N] | headroom | data area           │ │
  │  └──────────────────────────────────────────┘ │
  └──────────────────────────────────────────────┘

  할당 경로:
  1. per-core 캐시에서 mbuf 포인터 가져옴 (O(1), 락 없음)
  2. 캐시 비어있으면 → 공용 Ring에서 배치로 가져옴 (CAS 1회)

  반환 경로:
  1. per-core 캐시에 mbuf 포인터 반환 (O(1), 락 없음)
  2. 캐시 가득 차면 → 공용 Ring에 배치로 반환

/* Mempool 생성과 NUMA 인식 */
struct rte_mempool *pool;

/* 기본: 패킷 mbuf 풀 */
pool = rte_pktmbuf_pool_create(
    "PKT_POOL",
    65535,                   /* 총 mbuf 개수 (2^n - 1 권장) */
    512,                     /* per-core 캐시 크기 (0이면 캐시 비활성) */
    0,                       /* priv_size: mbuf당 추가 메타데이터 크기 */
    RTE_MBUF_DEFAULT_BUF_SIZE,  /* 2048 + 128(headroom) = 2176 */
    rte_socket_id()          /* NUMA 노드 */
);

/* 고급: 외부 메모리로 Mempool 생성 (huge 1GB) */
struct rte_pktmbuf_extmem ext_mem = {
    .buf_ptr  = mmap_addr,      /* 사전 매핑된 hugepage 주소 */
    .buf_iova = iova_addr,      /* IOMMU 매핑된 DMA 주소 */
    .buf_len  = 1ULL << 30,    /* 1GB */
    .elt_size = 2176,           /* mbuf + data 크기 */
};
pool = rte_pktmbuf_pool_create_extbuf("EXT_POOL", 65535, 512,
                                        0, 2176, rte_socket_id(),
                                        &ext_mem, 1);

DPDK 커널 인터페이스: VFIO vs UIO

DPDK가 유저 공간에서 NIC를 제어하려면 커널의 도움이 필요합니다. PCIe BAR 메모리를 유저 공간에 매핑하고, DMA를 위한 물리/IO 주소 변환을 제공하는 두 가지 메커니즘:

# ━━━ VFIO 기반 DPDK 디바이스 바인딩 ━━━

# 1. IOMMU 활성화 확인
dmesg | grep -i iommu
# "DMAR: IOMMU enabled" 또는 "AMD-Vi: IOMMU performance counters supported"

# 2. vfio-pci 모듈 로드
modprobe vfio-pci

# 3. NIC 상태 확인
dpdk-devbind.py --status

# Network devices using kernel driver
# 0000:03:00.0 'Ethernet Controller X710' if=ens3f0 drv=i40e
# 0000:03:00.1 'Ethernet Controller X710' if=ens3f1 drv=i40e

# 4. 커널 드라이버에서 언바인딩 → VFIO에 바인딩
ip link set ens3f0 down
dpdk-devbind.py --bind=vfio-pci 0000:03:00.0

# 5. 바인딩 확인
dpdk-devbind.py --status
# Network devices using DPDK-compatible driver
# 0000:03:00.0 'Ethernet Controller X710' drv=vfio-pci

# ━━━ Hugepage 설정 ━━━

# 2MB hugepage 1024개 = 2GB
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# NUMA 노드별 설정 (듀얼 소켓)
echo 512 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
echo 512 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

# 1GB hugepage (부팅 커맨드라인에서만 예약 가능)
# GRUB: default_hugepagesz=1G hugepagesz=1G hugepages=4

# hugetlbfs 마운트
mount -t hugetlbfs nodev /dev/hugepages

# ━━━ UIO 기반 (레거시, IOMMU 없는 환경) ━━━
modprobe uio_pci_generic
dpdk-devbind.py --bind=uio_pci_generic 0000:03:00.0
# ⚠ DMA 격리 없음 — 프로덕션에서 비권장

/* 커널 VFIO-PCI 드라이버가 DPDK에 제공하는 인터페이스 */

/* 1. Container FD — IOMMU 도메인 (DMA 매핑 관리) */
container_fd = open("/dev/vfio/vfio", O_RDWR);
ioctl(container_fd, VFIO_SET_IOMMU, VFIO_TYPE1v2_IOMMU);

/* 2. Group FD — IOMMU 그룹 */
group_fd = open("/dev/vfio/15", O_RDWR);
ioctl(group_fd, VFIO_GROUP_SET_CONTAINER, &container_fd);

/* 3. Device FD — 특정 PCI 디바이스 */
device_fd = ioctl(group_fd, VFIO_GROUP_GET_DEVICE_FD, "0000:03:00.0");

/* 4. BAR 매핑 — NIC 레지스터에 직접 접근 */
struct vfio_region_info reg = { .argsz = sizeof(reg), .index = 0 };
ioctl(device_fd, VFIO_DEVICE_GET_REGION_INFO, &reg);
bar0 = mmap(NULL, reg.size, PROT_READ | PROT_WRITE, MAP_SHARED,
            device_fd, reg.offset);
/* 이제 bar0[offset]으로 NIC 레지스터 직접 read/write 가능 */

/* 5. DMA 매핑 — hugepage를 IOMMU에 등록 */
struct vfio_iommu_type1_dma_map dma = {
    .argsz = sizeof(dma),
    .flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE,
    .vaddr = (uint64_t)hugepage_vaddr,
    .iova  = (uint64_t)hugepage_vaddr,  /* VA=IOVA 모드 */
    .size  = hugepage_size,
};
ioctl(container_fd, VFIO_IOMMU_MAP_DMA, &dma);
/* NIC DMA가 이 hugepage 영역에 접근 가능 */

패킷 처리 파이프라인 모델

DPDK 애플리케이션은 두 가지 기본 패킷 처리 모델을 사용합니다:

/* Run-to-Completion 모델 — 단순, 코어당 독립 처리 */

  Core 0                    Core 1                    Core 2
  ┌──────────────┐          ┌──────────────┐          ┌──────────────┐
  │ RX (Port 0)  │          │ RX (Port 0)  │          │ RX (Port 1)  │
  │     ↓        │          │     ↓        │          │     ↓        │
  │ Process pkt  │          │ Process pkt  │          │ Process pkt  │
  │     ↓        │          │     ↓        │          │     ↓        │
  │ TX (Port 1)  │          │ TX (Port 1)  │          │ TX (Port 0)  │
  └──────────────┘          └──────────────┘          └──────────────┘
  Queue 0                   Queue 1                   Queue 0

  - 각 코어가 RX → 처리 → TX를 완전히 독립 수행
  - 코어 간 통신 불필요 (Ring 없음)
  - RSS로 트래픽을 RX 큐별로 분산
  - 단순하고 확장성 좋음. 대부분의 L2/L3 포워딩에 적합

/* Pipeline 모델 — 복잡한 처리를 단계별로 분리 */

  Core 0 (RX)          Core 1 (Worker)       Core 2 (Worker)       Core 3 (TX)
  ┌────────────┐       ┌────────────┐       ┌────────────┐       ┌────────────┐
  │ RX burst   │──Ring→│ DPI/파싱   │──Ring→│ NAT/암호화 │──Ring→│ TX burst   │
  │ (Port 0,1) │       │ L3~L7 분류 │       │ 정책 적용  │       │ (Port 0,1) │
  └────────────┘       └────────────┘       └────────────┘       └────────────┘

  - 처리 단계를 여러 코어에 분배
  - 코어 간 rte_ring으로 패킷 전달
  - 각 단계의 부하를 독립적으로 스케일링 가능
  - DPI, 방화벽, 암호화 등 복잡한 처리에 적합
  - 단점: Ring 통과 시 지연 추가, NUMA 크로싱 주의

/* Run-to-Completion 모델 구현 예시 (RSS 기반 L2 포워딩) */

/* 포트 설정: 코어 수만큼 RX/TX 큐 생성 */
struct rte_eth_conf port_conf = {
    .rxmode = {
        .mq_mode = RTE_ETH_MQ_RX_RSS,    /* RSS 활성화 */
    },
    .rx_adv_conf = {
        .rss_conf = {
            .rss_hf = RTE_ETH_RSS_IP | RTE_ETH_RSS_TCP | RTE_ETH_RSS_UDP,
        },
    },
};
rte_eth_dev_configure(port_id, nb_cores, nb_cores, &port_conf);

/* 각 코어에 RX/TX 큐 1개씩 할당 */
for (int q = 0; q < nb_cores; q++) {
    rte_eth_rx_queue_setup(port_id, q, 1024, socket_id, NULL, mbuf_pool);
    rte_eth_tx_queue_setup(port_id, q, 1024, socket_id, NULL);
}

/* 워커 함수: 각 코어가 독립적으로 실행 */
static int
worker_main(void *arg)
{
    unsigned core_id = rte_lcore_id();
    unsigned queue_id = core_to_queue[core_id];

    while (!force_quit) {
        struct rte_mbuf *pkts[32];
        uint16_t nb_rx = rte_eth_rx_burst(port_id, queue_id, pkts, 32);

        for (uint16_t i = 0; i < nb_rx; i++) {
            struct rte_ether_hdr *eth = rte_pktmbuf_mtod(pkts[i],
                                        struct rte_ether_hdr *);
            /* MAC 주소 스왑 (L2 포워딩) */
            struct rte_ether_addr tmp = eth->dst_addr;
            eth->dst_addr = eth->src_addr;
            eth->src_addr = tmp;
        }

        uint16_t nb_tx = rte_eth_tx_burst(port_id, queue_id, pkts, nb_rx);
        for (uint16_t i = nb_tx; i < nb_rx; i++)
            rte_pktmbuf_free(pkts[i]);
    }
    return 0;
}

/* 모든 워커 코어에서 실행 시작 */
rte_eal_mp_remote_launch(worker_main, NULL, CALL_MAIN);

AF_XDP PMD — 커널 통합 고성능 경로

AF_XDP는 DPDK의 완전한 커널 바이패스와 커널 네트워크 스택 사이의 중간 지점입니다. 커널의 XDP 훅에서 패킷을 유저 공간으로 제로카피 전달하므로, VFIO 바인딩 없이 커널 드라이버를 유지하면서 고성능 패킷 처리가 가능합니다.

# ━━━ AF_XDP PMD로 DPDK 실행 ━━━

# NIC은 커널 드라이버에 그대로 유지 (VFIO 바인딩 불필요!)
ip link show ens3f0
# ens3f0: ... state UP ... driver: i40e

# AF_XDP PMD로 DPDK 앱 실행
dpdk-l2fwd -l 0-3 -n 4 \
  --vdev net_af_xdp0,iface=ens3f0,start_queue=0,queue_count=4 \
  -- -p 0x1

# 제로카피 모드 (NIC 드라이버가 지원하는 경우)
# i40e, ice, mlx5 등이 AF_XDP 제로카피 지원
dpdk-l2fwd -l 0-3 -n 4 \
  --vdev net_af_xdp0,iface=ens3f0,start_queue=0,queue_count=4 \
  -- -p 0x1
# 제로카피는 NIC 드라이버가 자동 감지하여 활성화

/* AF_XDP 제로카피 패킷 흐름 */

  NIC RX Queue ─── DMA ───→ UMEM (hugepage 공유 메모리)
                                    │
                              XDP 프로그램
                              (XDP_REDIRECT)
                                    │
                                    ↓
                            AF_XDP Socket
                            (Fill/Comp/RX/TX Ring)
                                    │
                                    ↓
                          DPDK af_xdp PMD
                          rte_eth_rx_burst()
                                    │
                                    ↓
                          DPDK Application

  - UMEM: 유저 공간과 커널이 공유하는 메모리 영역 (hugepage 기반)
  - Fill Ring: 앱 → 커널. 빈 버퍼 주소 전달 (NIC DMA 타겟)
  - Completion Ring: 커널 → 앱. TX 완료된 버퍼 반환
  - RX Ring: 커널 → 앱. 수신 패킷의 UMEM 오프셋 전달
  - TX Ring: 앱 → 커널. 전송할 패킷의 UMEM 오프셋 전달
  - 제로카피: NIC가 UMEM에 직접 DMA → 복사 없이 앱에 전달

OVS-DPDK (Open vSwitch + DPDK)

OVS-DPDK는 Open vSwitch의 데이터플레인을 DPDK로 교체하여 가상 스위칭 성능을 극대화한 구성입니다. 클라우드/NFV 환경에서 VM/컨테이너 간 네트워크 트래픽을 유저 공간에서 처리하여, 기존 커널 OVS 대비 5~10배의 처리량을 달성합니다.

/* OVS-DPDK 아키텍처 */

  VM1 (virtio)    VM2 (virtio)    VM3 (vhost-user)     물리 NIC
  ┌──────────┐   ┌──────────┐   ┌──────────────┐   ┌──────────────┐
  │  Guest   │   │  Guest   │   │   Guest      │   │   25GbE      │
  │  virtio  │   │  virtio  │   │   virtio     │   │   (VFIO)     │
  └────┬─────┘   └────┬─────┘   └──────┬───────┘   └──────┬───────┘
       │              │                │                   │
  vhost-user     vhost-user       vhost-user          DPDK PMD
  socket         socket           socket
       │              │                │                   │
  ┌────┴──────────────┴────────────────┴───────────────────┴───────┐
  │                    OVS-DPDK (vswitchd)                         │
  │  ┌──────────────────────────────────────────────────────────┐  │
  │  │  DPDK Datapath (PMD threads)                             │  │
  │  │  - EMC (Exact Match Cache): 가장 빈번한 플로우 캐시       │  │
  │  │  - dpcls (Datapath Classifier): 튜플 기반 플로우 매칭     │  │
  │  │  - upcall → ofproto: 미스 시 OpenFlow 테이블 참조         │  │
  │  └──────────────────────────────────────────────────────────┘  │
  │  ┌──────────────────────────────────────────────────────────┐  │
  │  │  OpenFlow Pipeline (ofproto)                             │  │
  │  │  Table 0 → Table 1 → ... → Actions                      │  │
  │  └──────────────────────────────────────────────────────────┘  │
  └────────────────────────────────────────────────────────────────┘

  - PMD threads: 전용 CPU 코어에서 busy-poll로 모든 포트 폴링
  - vhost-user: UNIX 소켓으로 QEMU와 공유 메모리 설정, 게스트 virtio 큐에 직접 접근
  - EMC hit rate가 높을수록 성능 극대화 (해시 기반 O(1) 조회)

# ━━━ OVS-DPDK 설정 예시 ━━━

# 1. OVS에 DPDK 초기화 파라미터 설정
ovs-vsctl --no-wait set Open_vSwitch . \
  other_config:dpdk-init=true \
  other_config:dpdk-socket-mem="1024,1024" \
  other_config:dpdk-lcore-mask=0x3 \
  other_config:dpdk-hugepage-dir="/dev/hugepages"

# 2. OVS 데몬 재시작
systemctl restart openvswitch-switch

# 3. DPDK 브릿지 생성
ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev

# 4. DPDK 물리 포트 추가 (VFIO 바인딩된 NIC)
ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 \
  type=dpdk options:dpdk-devargs=0000:03:00.0

# 5. vhost-user 포트 추가 (VM 연결용)
ovs-vsctl add-port br0 vhost-user0 -- set Interface vhost-user0 \
  type=dpdkvhostuserclient \
  options:vhost-server-path="/tmp/vhost-user0"

# 6. PMD 스레드 CPU 할당 (NUMA 인식)
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x3C

# 7. 플로우 설정 (OpenFlow)
ovs-ofctl add-flow br0 "in_port=dpdk-p0,actions=output:vhost-user0"
ovs-ofctl add-flow br0 "in_port=vhost-user0,actions=output:dpdk-p0"

# ━━━ 성능 확인 ━━━
ovs-appctl dpif-netdev/pmd-stats-show   # PMD 스레드 통계
ovs-appctl dpif-netdev/pmd-rxq-show     # RX 큐 매핑
ovs-appctl dpctl/dump-flows             # 데이터패스 플로우
ovs-appctl coverage/show                # 내부 이벤트 카운터

DPDK 성능 튜닝

# ━━━ 시스템 레벨 DPDK 성능 튜닝 ━━━

# CPU 격리 (GRUB 커맨드라인)
# GRUB_CMDLINE_LINUX="isolcpus=4-15 nohz_full=4-15 rcu_nocbs=4-15 \
#   intel_pstate=disable processor.max_cstate=1 intel_idle.max_cstate=0 \
#   default_hugepagesz=1G hugepagesz=1G hugepages=8 \
#   iommu=pt intel_iommu=on"

# NUMA 토폴로지 확인 — NIC이 어느 NUMA 노드에 있는지
cat /sys/bus/pci/devices/0000:03:00.0/numa_node
# 0  → NUMA 노드 0의 코어와 메모리를 사용해야 함

# 해당 NUMA 노드의 코어 확인
lscpu | grep "NUMA node0"
# NUMA node0 CPU(s): 0-7,16-23

# irqbalance 비활성화 + DPDK 코어에서 IRQ 배제
systemctl stop irqbalance
# /proc/irq/default_smp_affinity에서 DPDK 코어 제외
echo 000F > /proc/irq/default_smp_affinity  # 코어 0-3만 IRQ 허용

# CPU 주파수 고정 (Turbo Boost는 유지, P-state 전환 최소화)
cpupower -c 4-15 frequency-set -g performance

# 코어별 C-state 확인
turbostat --quiet --show Core,CPU,Busy%,Bzy_MHz,IRQ,C1%,C6% sleep 1

Eventdev — 이벤트 기반 패킷 스케줄링

rte_eventdev는 DPDK의 이벤트 기반 프로그래밍 모델로, 하드웨어 이벤트 스케줄러(Intel DLB2 등)나 소프트웨어 구현을 통해 패킷을 워커 코어에 동적으로 분배합니다. Run-to-Completion과 Pipeline 모델의 장점을 결합합니다.

/* Eventdev 동작 모델 */

  RX Adapter              Event Scheduler              TX Adapter
  (NIC RX → 이벤트)       (이벤트 → 워커 분배)          (이벤트 → NIC TX)
  ┌──────────┐           ┌──────────────┐              ┌──────────┐
  │ Port 0   │──event──→│  Atomic Queue │──event──→   │ Port 0   │
  │ Port 1   │          │  Ordered Queue│──event──→   │ Port 1   │
  └──────────┘          │  Parallel Que.│──event──→   └──────────┘
                        └──────────────┘
                              │
                   ┌──────────┼──────────┐
                   ↓          ↓          ↓
              Worker 0   Worker 1   Worker 2
              (Core 4)   (Core 5)   (Core 6)

  큐 타입:
  - Atomic: 같은 플로우는 항상 같은 워커에 전달 (순서 보장, 락 불필요)
  - Ordered: 순서 보장하면서 병렬 처리. 출력 시 원래 순서로 재정렬
  - Parallel: 순서 무관, 최대 병렬성

  장점:
  - 트래픽 부하에 따라 워커 수 동적 조절 가능
  - Atomic 큐로 플로우별 락 없는 처리 보장
  - 하드웨어 스케줄러(DLB2)는 CPU 오버헤드 없이 이벤트 분배

DPDK 멀티프로세스 모드

DPDK는 primary-secondary 프로세스 모델을 지원합니다. Primary 프로세스가 EAL 초기화, 포트 설정, Mempool 생성을 수행하고, Secondary 프로세스가 공유 메모리(hugepage)를 통해 동일한 자원에 접근합니다.

/* DPDK 멀티프로세스 아키텍처 */

  Primary Process                  Secondary Process(es)
  ┌──────────────────────┐        ┌──────────────────────┐
  │ rte_eal_init()       │        │ rte_eal_init(         │
  │  --proc-type primary │        │  --proc-type secondary│
  │                      │        │  --file-prefix dpdk0) │
  │ - Hugepage 매핑 생성 │        │ - 같은 Hugepage 매핑  │
  │ - Mempool 생성       │        │ - Mempool 룩업        │
  │ - 포트 설정/시작     │        │ - 포트 룩업           │
  │ - Ring 생성          │        │ - Ring 룩업           │
  └──────────┬───────────┘        └──────────┬───────────┘
             │                               │
             └───────────┬───────────────────┘
                         ↓
              Shared Hugepage Memory
              ┌──────────────────────────────┐
              │ Mempool, Ring, mbuf           │
              │ (물리 주소 동일, VA도 동일)    │
              │ rte_config 공유 메모리         │
              └──────────────────────────────┘

  사용 사례:
  - 패킷 캡처: primary가 포워딩, secondary가 pdump로 미러링
  - 무중단 업그레이드: 새 secondary가 시작된 후 기존 교체
  - 모니터링: secondary가 통계/텔레메트리 수집

# 멀티프로세스 실행 예시

# Primary 프로세스 시작
dpdk-l2fwd -l 0-3 -n 4 --proc-type primary -- -p 0x3

# Secondary 프로세스 (패킷 덤프)
dpdk-pdump -l 4 --proc-type secondary -- \
  --pdump 'port=0,queue=*,rx-dev=/tmp/rx.pcap'

# Secondary 프로세스 (통계 모니터링)
dpdk-proc-info --proc-type secondary -- --stats

DPDK 디버깅과 모니터링

# ━━━ DPDK 디버깅/모니터링 명령 모음 ━━━

# 포트 통계 (기본 + 확장)
dpdk-proc-info -- --stats
dpdk-proc-info -- --xstats  # NIC별 상세 카운터 (rx_good_bytes, tx_errors, ...)

# 실시간 패킷 캡처 (secondary 프로세스)
dpdk-pdump -l 8 --proc-type secondary -- \
  --pdump 'port=0,queue=*,rx-dev=/tmp/capture.pcap'
# 캡처 파일을 tcpdump/Wireshark로 분석
tcpdump -r /tmp/capture.pcap

# 텔레메트리 API (DPDK 20.05+)
# UNIX 소켓 경로: /var/run/dpdk/rte/dpdk_telemetry.vX
dpdk-telemetry.py
# 대화형 쿼리:
# --> /ethdev/stats,0
# --> /ethdev/xstats,0
# --> /eal/params
# --> /mempool/list

# testpmd로 성능 측정
dpdk-testpmd -l 0-3 -n 4 -a 0000:03:00.0 -- \
  -i \
  --forward-mode=io \
  --rxq=4 --txq=4 \
  --nb-cores=3 \
  --burst=32

# testpmd 내부 명령:
# testpmd> start
# testpmd> show port stats all
# testpmd> show fwd stats all
# testpmd> show port xstats 0
# testpmd> stop

# Mempool 상태 확인
dpdk-proc-info -- --mempool=MBUF_POOL

# EAL 로그 레벨 (런타임 조정)
# --log-level=lib.eal:8   (DEBUG)
# --log-level=pmd.net.mlx5:7  (INFO)

/* 프로그래밍 방식 통계 수집 */
struct rte_eth_stats stats;
rte_eth_stats_get(port_id, &stats);

printf("Port %u: RX %lu pkts (%lu bytes) TX %lu pkts (%lu bytes)\n",
       port_id,
       stats.ipackets, stats.ibytes,
       stats.opackets, stats.obytes);
printf("  RX errors: %lu  TX errors: %lu  RX no-mbuf: %lu\n",
       stats.ierrors, stats.oerrors, stats.rx_nombuf);

/* 확장 통계 (xstats): NIC별 상세 카운터 */
int len = rte_eth_xstats_get(port_id, NULL, 0);
struct rte_eth_xstat *xstats = malloc(len * sizeof(*xstats));
struct rte_eth_xstat_name *names = malloc(len * sizeof(*names));
rte_eth_xstats_get(port_id, xstats, len);
rte_eth_xstats_get_names(port_id, names, len);

for (int i = 0; i < len; i++)
    printf("  %s: %lu\n", names[i].name, xstats[i].value);

VPP (FD.io) — 유저 공간 네트워크 스택

VPP(Vector Packet Processing)는 Cisco가 개발한 고성능 유저 공간 네트워크 스택으로, DPDK PMD 위에서 동작하며 L2~L4 스위칭/라우팅, NAT, IPSec, ACL 등 커널 네트워크 스택의 기능을 유저 공간에서 구현합니다.

DPDK 관련 커널 소스 구조

DPDK 자체는 유저 공간 라이브러리이지만, 커널 측에서 DPDK 동작을 지원하는 핵심 구성 요소:

# DPDK 관련 커널 설정 (CONFIG_*)

# VFIO (권장)
CONFIG_VFIO=m
CONFIG_VFIO_PCI=m
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_NOIOMMU=y          # no-IOMMU 모드 (테스트용)

# UIO (레거시)
CONFIG_UIO=m
CONFIG_UIO_PCI_GENERIC=m

# IOMMU
CONFIG_IOMMU_SUPPORT=y
CONFIG_INTEL_IOMMU=y            # Intel VT-d
CONFIG_AMD_IOMMU=y              # AMD-Vi
CONFIG_IOMMU_DEFAULT_DMA_LAZY=y # IOVA 지연 해제 (성능)

# Hugepage
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_TRANSPARENT_HUGEPAGE=y   # THP (DPDK는 명시적 hugetlbfs 선호)

# AF_XDP
CONFIG_XDP_SOCKETS=y
CONFIG_BPF_SYSCALL=y
CONFIG_NET_CLS_BPF=m

# NUMA
CONFIG_NUMA=y
CONFIG_NUMA_BALANCING=y

xfrm 프레임워크와 IPSec 심화

xfrm(transform)은 리눅스 커널의 IPSec 구현 프레임워크입니다. 패킷의 암호화, 인증, 압축, 캡슐화를 처리하며, SA(Security Association)와 SP(Security Policy) 데이터베이스로 관리됩니다.

xfrm 아키텍처

IPSec 프로토콜 비교

터널 모드 vs 트랜스포트 모드

# 트랜스포트 모드: 호스트-to-호스트, 원본 IP 헤더 유지
# [IP Header][ESP Header][Payload (encrypted)][ESP Trailer][ESP Auth]
ip xfrm state add src 10.0.0.1 dst 10.0.0.2     proto esp spi 0x100 mode transport     enc "aes" 0x$(openssl rand -hex 16)     auth "hmac(sha256)" 0x$(openssl rand -hex 32)

# 터널 모드: 게이트웨이-to-게이트웨이, 원본 패킷 전체 캡슐화
# [New IP][ESP Header][Original IP][Payload (encrypted)][ESP Trailer][Auth]
ip xfrm state add src 203.0.113.1 dst 198.51.100.1     proto esp spi 0x200 mode tunnel     enc "aes" 0x$(openssl rand -hex 16)     auth "hmac(sha256)" 0x$(openssl rand -hex 32)

# Security Policy (어떤 트래픽에 IPSec 적용할지)
ip xfrm policy add src 192.168.1.0/24 dst 192.168.2.0/24 dir out     tmpl src 203.0.113.1 dst 198.51.100.1 proto esp mode tunnel

# 현재 SA/SP 확인
ip xfrm state list    # SA 목록 (키, SPI, 알고리즘)
ip xfrm policy list   # SP 목록 (셀렉터, 방향)
ip xfrm monitor       # 실시간 xfrm 이벤트 모니터링

커널 xfrm 내부 구조

/* net/xfrm/xfrm_state.c — Security Association */
struct xfrm_state {
    struct xfrm_id id;            /* (daddr, spi, proto) */
    xfrm_address_t saddr;        /* 소스 주소 */
    struct xfrm_lifetime_cfg lft; /* 수명: 바이트, 패킷, 시간 */

    struct xfrm_algo_auth *aalg;  /* 인증 알고리즘 (HMAC-SHA256 등) */
    struct xfrm_algo *ealg;       /* 암호 알고리즘 (AES-CBC 등) */
    struct xfrm_algo *calg;       /* 압축 알고리즘 (deflate 등) */
    struct xfrm_algo_aead *aead;  /* AEAD (AES-GCM 등) */

    u8 mode;                      /* XFRM_MODE_TRANSPORT / TUNNEL */
    u32 replay_maxdiff;           /* Anti-replay 윈도우 */
    struct xfrm_replay_state_esn *replay_esn;

    /* H/W offload (SmartNIC inline crypto) */
    struct xfrm_dev_offload xso;
};

/* net/ipv4/esp4.c — ESP 패킷 처리 */
/* esp_output(): 송신 패킷 암호화 (POSTROUTING 단계) */
/* esp_input():  수신 패킷 복호화 (PREROUTING 단계) */

권장 알고리즘 조합

IPSec/xfrm 주의사항

IPSec 디버깅

# xfrm 통계 — 오류 원인 파악
ip -s xfrm state   # SA별 패킷/바이트 카운터
ip -s xfrm policy  # SP별 매칭 카운터
cat /proc/net/xfrm_stat
# XfrmInError: 복호화/인증 실패
# XfrmInNoStates: 매칭 SA 없음
# XfrmOutPolBlock: SP에 의해 차단
# XfrmOutBundleGenError: SA 번들 생성 실패

# 패킷 캡처 (ESP 헤더 확인)
tcpdump -i eth0 esp
tcpdump -i eth0 'ip proto 50'  # ESP
tcpdump -i eth0 'ip proto 51'  # AH

# IKE 데몬 로그 (strongSwan)
swanctl --log --level 2

ESP 패킷 형식 상세

ESP(Encapsulating Security Payload, IP 프로토콜 50)는 현대 IPSec의 핵심 프로토콜입니다. 트랜스포트 모드와 터널 모드에서 패킷 구조가 다르며, AEAD 알고리즘 사용 여부에 따라 내부 처리도 달라집니다.

/* ESP 헤더 (RFC 4303) — include/uapi/linux/ip.h */
struct ip_esp_hdr {
    __be32 spi;        /* Security Parameters Index — SA 식별 */
    __be32 seq_no;     /* 시퀀스 번호 (Anti-replay용, 단조 증가) */
    __u8   enc_data[]; /* 가변 길이: IV + 암호화된 페이로드 */
};

/* ESP Trailer (암호화 영역 끝에 위치) */
/*   [Padding (0~255 bytes)]     — 블록 정렬용 */
/*   [Pad Length (1 byte)]       — 패딩 바이트 수 */
/*   [Next Header (1 byte)]      — 원본 프로토콜 (TCP=6, UDP=17 등) */
/*   [ICV (12~16 bytes)]         — Integrity Check Value (MAC) */

/* ESN (Extended Sequence Number, RFC 4304) */
/* 32비트 시퀀스 번호는 10Gbps에서 ~7분 만에 소진 */
/* ESN은 64비트로 확장: 상위 32비트는 패킷에 미포함, ICV 계산에만 사용 */
struct xfrm_replay_state_esn {
    __u32 bmp_len;     /* 비트맵 길이 (워드 수) */
    __u32 oseq;        /* 송신 시퀀스 (하위 32비트) */
    __u32 seq;         /* 수신 시퀀스 (하위 32비트) */
    __u32 oseq_hi;     /* 송신 시퀀스 (상위 32비트) */
    __u32 seq_hi;      /* 수신 시퀀스 (상위 32비트) */
    __u32 replay_window; /* Anti-replay 윈도우 크기 */
    __u32 bmp[];       /* 수신 비트맵 (가변 길이) */
};

AH 패킷 형식과 한계

AH(Authentication Header, IP 프로토콜 51)는 패킷의 무결성과 인증을 제공하지만 암호화는 하지 않습니다. IP 헤더를 포함한 전체 패킷이 인증 범위에 포함되는 것이 ESP와의 핵심 차이점이며, 이것이 NAT 환경과 호환되지 않는 근본 원인입니다.

/* AH 헤더 (RFC 4302) — include/uapi/linux/ip_auth.h */
struct ip_auth_hdr {
    __u8   nexthdr;     /* 다음 헤더 (TCP=6, ESP=50 등) */
    __u8   hdrlen;      /* 헤더 길이 (32비트 워드 단위 - 2) */
    __be16 reserved;    /* 예약 (0) */
    __be32 spi;         /* Security Parameters Index */
    __be32 seq_no;      /* 시퀀스 번호 */
    __u8   auth_data[]; /* ICV — 가변 길이 (알고리즘에 따라) */
};

/* AH 인증 범위: IP 헤더 전체 + AH 헤더 + 페이로드 */
/* 단, 변경 가능(mutable) 필드는 0으로 치환 후 MAC 계산: */
/*   - TTL (hop마다 감소)          */
/*   - Header Checksum (TTL 변경 시 재계산) */
/*   - TOS/DSCP (라우터가 변경 가능) */
/*   - Flags (Fragment offset)     */

IKE 프로토콜과 SA 협상

IKE(Internet Key Exchange)는 IPSec SA의 자동 협상 프로토콜입니다. 커널의 xfrm 프레임워크는 데이터 평면(패킷 암호화/복호화)만 처리하며, SA 생성/삭제/갱신의 제어 평면은 유저스페이스 IKE 데몬(strongSwan, Libreswan)이 Netlink를 통해 커널에 주입합니다.

Diffie-Hellman 그룹과 PFS: IKE_SA_INIT에서 DH 교환으로 공유 비밀 생성. PFS(Perfect Forward Secrecy)를 활성화하면 CREATE_CHILD_SA에서도 새로운 DH 교환을 수행하여, IKE SA 키가 노출되더라도 개별 CHILD SA(IPSec SA)의 트래픽 키는 보호됩니다. 주요 DH 그룹:

커널과 IKE 데몬 상호작용: IKE 데몬은 AF_NETLINK/NETLINK_XFRM 소켓을 통해 커널 xfrm 서브시스템과 통신합니다. 주요 Netlink 메시지:

/* include/uapi/linux/xfrm.h — 주요 XFRM Netlink 메시지 타입 */
/* SA (Security Association) 관리 */
XFRM_MSG_NEWSA      /* IKE → 커널: SA 생성 (키, 알고리즘, SPI, 모드) */
XFRM_MSG_DELSA      /* IKE → 커널: SA 삭제 */
XFRM_MSG_GETSA      /* IKE → 커널: SA 조회 */
XFRM_MSG_UPDSA      /* IKE → 커널: SA 갱신 (rekey) */

/* SP (Security Policy) 관리 */
XFRM_MSG_NEWPOLICY  /* IKE → 커널: 정책 생성 (셀렉터, 방향, 액션) */
XFRM_MSG_DELPOLICY  /* IKE → 커널: 정책 삭제 */

/* 커널 → IKE 이벤트 (비동기 알림) */
XFRM_MSG_ACQUIRE    /* 커널 → IKE: 매칭 SA 없음, 새 SA 생성 요청 */
XFRM_MSG_EXPIRE     /* 커널 → IKE: SA 수명 만료 (soft/hard) */
XFRM_MSG_MIGRATE    /* MOBIKE: SA를 새 주소로 마이그레이션 */
XFRM_MSG_MAPPING    /* NAT-T: NAT 매핑 변경 알림 */

/* 워크플로 예시:
 * 1. 패킷 도착 → xfrm_policy 매칭 → 해당 SA 없음
 * 2. 커널이 XFRM_MSG_ACQUIRE 전송 → IKE 데몬 수신
 * 3. IKE 데몬이 피어와 IKEv2 교환 수행
 * 4. IKE 데몬이 XFRM_MSG_NEWSA + XFRM_MSG_NEWPOLICY로 SA/SP 커널에 주입
 * 5. 대기 중이던 패킷 처리 재개
 */

xfrm 패킷 처리 경로

xfrm의 패킷 처리는 Netfilter 훅과 밀접하게 통합되어 있습니다. 송신 경로에서는 라우팅 후 xfrm 정책 검색을 수행하고, 수신 경로에서는 ESP 복호화 후 정책 검증을 거칩니다.

/* net/xfrm/xfrm_output.c — 송신 경로 핵심 */
static int xfrm_output_one(struct sk_buff *skb, int err)
{
    struct xfrm_state *x = skb_dst(skb)->xfrm;
    /* 1. 시퀀스 번호 할당 (ESN 지원) */
    err = x->outer_mode.output(x, skb);    /* 터널: 외부 IP 헤더 추가 */
    err = x->type->output(x, skb);         /* ESP: esp_output() 호출 */
    /* 2. skb→dst를 외부 라우팅 엔트리로 교체 */
    /* 3. 중첩 SA가 있으면 다음 xfrm_state에 대해 반복 (bundle) */
}

/* net/ipv4/esp4.c — ESP 암호화 처리 */
static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
{
    struct crypto_aead *aead = x->data;
    /* 1. ESP 헤더 (SPI + Seq#) 삽입 */
    /* 2. IV 생성 (AEAD: salt + seq_no) */
    /* 3. 패딩 추가 (블록 크기 정렬) */
    /* 4. aead_request 생성 → crypto_aead_encrypt() */
    /*    → 비동기 완료: esp_output_done() 콜백 */
    /* 5. ICV 첨부 */
}

/* net/xfrm/xfrm_input.c — 수신 경로 핵심 */
int xfrm_input(struct sk_buff *skb, int nexthdr,
              __be32 spi, int encap_type)
{
    /* 1. (daddr, spi, proto)로 SAD 해시 테이블 검색 */
    x = xfrm_state_lookup(net, &daddr, spi, nexthdr, family);
    /* 2. anti-replay 검사 */
    xfrm_replay_check(x, skb, seq);
    /* 3. ESP 복호화: x→type→input() → esp_input() */
    /* 4. anti-replay 윈도우 업데이트 */
    xfrm_replay_advance(x, seq);
    /* 5. 정책 검증: 복호화된 패킷이 SP와 일치하는지 확인 */
    /*    (수신 정책 없으면 드롭 — XfrmInNoPols) */
}

/* xfrm_state 해시 테이블 검색 — O(1) 평균 */
/* 키: (daddr, spi, proto) → 해시 버킷 → 체인 순회 */
/* 대규모 SA 환경에서도 검색 성능 보장 */

xfrm_policy 내부 구조

/* include/net/xfrm.h — Security Policy 핵심 구조체 */
struct xfrm_policy {
    struct hlist_node bydst;       /* dst 주소별 해시 체인 */
    struct hlist_node byidx;       /* 인덱스별 해시 체인 */

    struct xfrm_selector selector;  /* 트래픽 셀렉터 (아래 상세) */
    struct xfrm_lifetime_cfg lft;   /* 수명: 바이트/패킷/시간 */
    struct xfrm_lifetime_cur curlft; /* 현재 사용량 카운터 */

    u8 type;           /* XFRM_POLICY_TYPE_MAIN / SUB */
    u8 action;         /* XFRM_POLICY_ALLOW / BLOCK */
    u8 flags;          /* XFRM_POLICY_LOCALOK, ICMP 등 */
    u8 xfrm_nr;        /* tmpl 배열 크기 (최대 6) */
    u16 family;        /* AF_INET / AF_INET6 */
    u32 priority;      /* 정책 우선순위 (낮을수록 높음) */
    u32 if_id;         /* xfrm interface ID (4.19+) */

    struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH]; /* SA 템플릿 */
    /* tmpl: 요구하는 SA의 속성 (proto, mode, reqid, level) */
};

/* 트래픽 셀렉터 — 어떤 패킷에 정책을 적용할지 결정 */
struct xfrm_selector {
    xfrm_address_t daddr;    /* 목적지 주소 */
    xfrm_address_t saddr;    /* 소스 주소 */
    __be16 dport;             /* 목적지 포트 */
    __be16 dport_mask;        /* 포트 마스크 (0xFFFF = exact) */
    __be16 sport;             /* 소스 포트 */
    __be16 sport_mask;
    __u16 family;             /* AF_INET / AF_INET6 */
    __u8 prefixlen_d;         /* 목적지 서브넷 길이 */
    __u8 prefixlen_s;         /* 소스 서브넷 길이 */
    __u8 proto;               /* 프로토콜 (6=TCP, 17=UDP, 0=all) */
    int ifindex;              /* 인터페이스 바인딩 */
    __kernel_uid32_t user;   /* UID 기반 정책 (Android) */
};

SPD 검색 알고리즘: 정책 검색은 3개의 방향(in/out/fwd)별로 독립된 해시 테이블에서 수행됩니다. 패킷의 (src, dst, proto, sport, dport)를 셀렉터와 매칭하며, 여러 정책이 매칭되면 priority가 가장 낮은(= 우선순위 높은) 정책이 선택됩니다.

/* net/xfrm/xfrm_policy.c — SPD 검색 핵심 */
static struct xfrm_policy *
xfrm_policy_lookup_bytype(struct net *net, u8 type,
    const struct flowi *fl, u16 family, u8 dir)
{
    /* 1. (dst_addr, family) 기반 해시 버킷 선택 */
    /* 2. 버킷 내 정책 순회 → 셀렉터 매칭 검사 */
    /*    xfrm_selector_match(sel, fl, family) */
    /* 3. 매칭된 정책 중 priority 최소값 반환 */
    /* 4. action == BLOCK이면 패킷 드롭 (XfrmOutPolBlock) */
    /* 5. action == ALLOW이면 tmpl 배열로 SA 검색 */
}

/* 정책 방향 (dir) */
XFRM_POLICY_IN   0  /* 수신: 복호화 후 정책 검증 */
XFRM_POLICY_OUT  1  /* 송신: 패킷 나가기 전 정책 검색 */
XFRM_POLICY_FWD  2  /* 포워딩: 라우터 역할 시 터널 간 전달 */

NAT Traversal (NAT-T) 상세

ESP는 IP 프로토콜 번호 50을 사용하므로, 포트 번호가 없어 일반 NAT가 처리할 수 없습니다. NAT-T(NAT Traversal, RFC 3948)는 ESP 패킷을 UDP 4500 포트로 캡슐화하여 NAT 장비를 통과할 수 있게 합니다.

/* NAT-T 감지: IKEv2 NAT_DETECTION_*_IP payload */
/* IKE_SA_INIT 교환에서 양쪽이 NAT 감지 해시 전송:
 *   HASH = SHA-1(SPIi | SPIr | IP | port)
 * 수신 측에서 자신의 IP/port로 재계산한 해시와 비교
 * → 불일치하면 경로 상에 NAT 존재 → NAT-T 활성화
 */

/* 커널 NAT-T 처리: net/ipv4/esp4.c + net/ipv4/udp.c */
/* 수신: UDP 4500 소켓에 ESP-in-UDP 핸들러 등록 */
static int esp4_rcv_cb(struct sk_buff *skb)
{
    /* 1. UDP 헤더 제거 */
    /* 2. SPI로 xfrm_state 검색 */
    /* 3. encap_type = UDP_ENCAP_ESPINUDP 설정 */
    /* 4. esp_input()으로 복호화 진행 */
}

/* 송신: xfrm_state에 encap 정보가 있으면 UDP 래핑 */
struct xfrm_encap_tmpl {
    __u16 encap_type;   /* UDP_ENCAP_ESPINUDP (2) */
    __be16 encap_sport; /* 로컬 UDP 포트 (4500) */
    __be16 encap_dport; /* 원격 UDP 포트 (4500) */
    xfrm_address_t encap_oa; /* 원본 주소 (NAT 이전) */
};

xfrm interface vs VTI

리눅스에서 route-based VPN을 구현하는 두 가지 방법이 있습니다: 레거시 VTI(Virtual Tunnel Interface)와 커널 4.19에서 도입된 xfrm interface입니다. xfrm interface는 VTI의 한계를 해결하고 현대 VPN 아키텍처에 필수적인 기능을 제공합니다.

# xfrm interface 생성 및 설정
# 1. xfrm interface 생성 (if_id=42로 SA와 바인딩)
ip link add xfrm0 type xfrm dev eth0 if_id 42
ip addr add 10.10.0.1/30 dev xfrm0
ip link set xfrm0 up

# 2. SA에 if_id 지정
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0x1000 mode tunnel if_id 42 \
    aead 'rfc4106(gcm(aes))' 0x$(openssl rand -hex 20) 128

# 3. 정책에 if_id 지정
ip xfrm policy add dir out if_id 42 \
    src 0.0.0.0/0 dst 0.0.0.0/0 \
    tmpl src 203.0.113.1 dst 198.51.100.1 proto esp mode tunnel

# 4. 라우팅: xfrm interface를 통해 터널 트래픽 라우팅
ip route add 192.168.2.0/24 dev xfrm0

# 멀티 터널 시나리오 (서로 다른 피어에 대해 별도 xfrm interface)
ip link add xfrm1 type xfrm dev eth0 if_id 43
ip link add xfrm2 type xfrm dev eth0 if_id 44
# → BGP/OSPF 동적 라우팅을 각 xfrm interface에서 실행 가능

# 네임스페이스 격리 (멀티 테넌트)
ip netns add tenant1
ip link set xfrm0 netns tenant1
ip netns exec tenant1 ip addr add 10.10.0.1/30 dev xfrm0
ip netns exec tenant1 ip link set xfrm0 up
# → tenant1 네임스페이스 내에서만 IPSec 터널 접근 가능

Anti-replay 메커니즘

Anti-replay는 공격자가 캡처한 ESP 패킷을 재전송하는 것을 방지합니다. 수신 측은 슬라이딩 윈도우 비트맵을 유지하여 이미 처리한 시퀀스 번호의 패킷을 거부합니다.

/* net/xfrm/xfrm_replay.c — anti-replay 검사 (ESN 모드) */
static int xfrm_replay_check_esn(struct xfrm_state *x,
    struct sk_buff *skb, __be32 net_seq)
{
    u32 seq = ntohl(net_seq);
    struct xfrm_replay_state_esn *replay_esn = x->replay_esn;
    u32 wsize = replay_esn->replay_window;
    u32 top = replay_esn->seq;         /* 최신 수신 시퀀스 */
    u32 bottom = top - wsize + 1;     /* 윈도우 왼쪽 경계 */

    /* Case 1: 윈도우 오른쪽 밖 → 새 패킷, 수락 */
    if (likely(seq > top))
        return 0;

    /* Case 2: 윈도우 왼쪽 밖 → 너무 오래된 패킷, 드롭 */
    if (seq < bottom)
        return -EINVAL;  /* XfrmInSeqOutOfWindow */

    /* Case 3: 윈도우 내 → 비트맵 검사 */
    u32 diff = top - seq;
    u32 pos = diff / 32;
    u32 bit = 1 << (diff % 32);
    if (replay_esn->bmp[pos] & bit)
        return -EINVAL;  /* XfrmInStateReplay — 중복 패킷 */

    return 0;  /* 윈도우 내 미수신 패킷, 수락 */
}

/* 윈도우 업데이트: 패킷 수락 후 비트맵 갱신 */
static void xfrm_replay_advance_esn(struct xfrm_state *x, __be32 net_seq)
{
    /* seq > top이면 윈도우 오른쪽으로 슬라이드 */
    /* 이동 과정에서 벗어난 비트들은 0으로 클리어 */
    /* 새 seq 위치의 비트를 1로 설정 */
}

IPSec 하드웨어 오프로드

소프트웨어 ESP 처리는 CPU 집약적이어서 10Gbps 이상 환경에서 병목이 됩니다. 리눅스 커널은 3가지 수준의 하드웨어 오프로드를 지원합니다.

/* include/net/xfrm.h — H/W 오프로드 구조체 */
struct xfrm_dev_offload {
    struct net_device *dev;     /* 오프로드 대상 NIC */
    struct net_device *real_dev; /* bond/vlan 하위 실제 디바이스 */
    unsigned long offload_handle; /* 드라이버 전용 핸들 */
    u8 dir : 2;               /* XFRM_DEV_OFFLOAD_IN / OUT */
    u8 type : 2;              /* CRYPTO / PACKET (inline) / FULL */
    u8 flags : 2;             /* XFRM_DEV_OFFLOAD_FLAG_ACE 등 */
};

/* NIC 드라이버가 구현하는 xdo_dev_* 콜백 */
struct xfrmdev_ops {
    int (*xdo_dev_state_add)(struct xfrm_state *x,
                             struct netlink_ext_ack *extack);
    void (*xdo_dev_state_delete)(struct xfrm_state *x);
    void (*xdo_dev_state_free)(struct xfrm_state *x);
    bool (*xdo_dev_offload_ok)(struct sk_buff *skb,
                              struct xfrm_state *x);
    /* PACKET/FULL 오프로드 시 정책 콜백도 구현 */
    int (*xdo_dev_policy_add)(struct xfrm_policy *p, ...);
};

# Inline crypto offload 설정 (NVIDIA ConnectX-6 Dx 예시)
# 1. SA 생성 시 offload 지정
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0x1000 mode tunnel \
    aead 'rfc4106(gcm(aes))' 0x$(openssl rand -hex 20) 128 \
    offload dev eth0 dir out

# 2. 오프로드 상태 확인
ip xfrm state list
# → "offload type packet dev eth0 dir out" 표시

# Intel QAT crypto offload (AEAD)
# QAT 드라이버 로드 → openssl engine → strongSwan에서 QAT 플러그인 사용
modprobe qat_4xxx                    # Intel 4세대 QAT 디바이스
# strongSwan: charon.plugins.openssl.engine_id = qatengine

# 오프로드 실패 시 자동 소프트웨어 폴백
# ethtool -k eth0 | grep esp
# esp-hw-offload: on → 하드웨어 오프로드 활성화됨

strongSwan/Libreswan 실전 설정

IKE 데몬은 커널 xfrm과 협력하여 SA의 자동 생성/갱신/삭제를 처리합니다. 현대 리눅스 환경에서는 strongSwan(swanctl)과 Libreswan(ipsec.conf)이 주로 사용됩니다.

# /etc/swanctl/swanctl.conf — strongSwan site-to-site 설정
connections {
    site-to-site {
        version = 2                    # IKEv2 전용
        local_addrs = 203.0.113.1
        remote_addrs = 198.51.100.1

        local {
            auth = pubkey                # X.509 인증서 인증
            certs = server.pem
            id = vpn.example.com
        }
        remote {
            auth = pubkey
            id = vpn.peer.com
        }

        proposals = aes256gcm128-x25519-sha256  # IKE SA 암호 스위트
        dpd_delay = 30s                 # DPD 간격

        children {
            lan-to-lan {
                local_ts = 192.168.1.0/24   # 로컬 트래픽 셀렉터
                remote_ts = 192.168.2.0/24  # 원격 트래픽 셀렉터
                esp_proposals = aes256gcm128-x25519  # CHILD SA 암호 스위트
                rekey_time = 3600s          # 1시간마다 rekey
                replay_window = 2048       # Anti-replay 윈도우
                start_action = start        # 부팅 시 자동 연결
                dpd_action = restart        # DPD 실패 시 재연결
                # hw_offload = packet      # inline crypto 오프로드 (지원 NIC)
            }
        }
    }
}

# Road Warrior (모바일 클라이언트) 설정
connections {
    roadwarrior {
        version = 2
        local_addrs = %any              # 서버: 모든 주소에서 수신
        pools = pool-ipv4               # 클라이언트에게 IP 할당

        local {
            auth = pubkey
            certs = server.pem
        }
        remote {
            auth = eap-mschapv2         # EAP 인증 (사용자/비밀번호)
            eap_id = %any
        }

        children {
            rw-child {
                local_ts = 0.0.0.0/0    # 모든 트래픽 터널링
            }
        }
    }
}

pools {
    pool-ipv4 {
        addrs = 10.10.0.0/24
        dns = 8.8.8.8, 8.8.4.4
    }
}

IPSec 성능 튜닝

IPSec 성능은 암호 알고리즘, CPU 아키텍처, 패킷 크기, NIC 설정에 크게 의존합니다. 고성능 환경에서는 체계적인 벤치마크와 프로파일링이 필수적입니다.

# CPU affinity와 RPS/RFS 최적화
# ESP 처리를 특정 CPU에 고정하여 캐시 효율 극대화

# 1. NIC 인터럽트를 특정 CPU에 바인딩
# (CPU 0~3: 일반 트래픽, CPU 4~7: ESP 처리)
for i in /proc/irq/*/smp_affinity_list; do
    irq=$(echo $i | grep -oP '/proc/irq/\K[0-9]+')
    cat /proc/irq/$irq/actions | grep -q eth0 && echo "4-7" > $i
done

# 2. RPS (Receive Packet Steering) — 소프트웨어 수신 분산
echo f0 > /sys/class/net/eth0/queues/rx-0/rps_cpus   # CPU 4-7
echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

# 3. xfrm 관련 sysctl 파라미터
sysctl -w net.core.xfrm_larval_drop=1    # SA 미완성 시 패킷 즉시 드롭 (대기 안 함)
sysctl -w net.core.xfrm_acq_expires=30   # ACQUIRE 타임아웃 (초)
sysctl -w net.core.xfrm_aevent_rseqth=2  # replay 이벤트 시퀀스 임계값
sysctl -w net.ipv4.xfrm4_gc_thresh=32768 # xfrm dst 가비지 컬렉션 임계값

# perf 프로파일링 — ESP 처리 핫스팟 식별
perf top -C 4-7 -g                        # ESP 처리 CPU에서 실시간 프로파일
perf record -C 4-7 -g -- sleep 10        # 10초 샘플링
perf report --sort=dso,sym                # 심볼별 CPU 사용량
# 주요 핫스팟: gcm_hash_crypt_*, aesni_ctr_enc, esp_output/input

# 암호 알고리즘 벤치마크 (커널 crypto API 테스트)
modprobe tcrypt sec=1 mode=211           # AES-GCM 벤치마크
dmesg | tail -50                          # 결과 확인

WireGuard 심화

WireGuard는 Jason A. Donenfeld가 설계한 차세대 VPN 프로토콜로, Linux 커널 5.6에 공식 통합되었습니다 (drivers/net/wireguard/). IPSec이나 OpenVPN 대비 코드량이 약 4,000줄(vs IPSec 수만 줄)로 극도로 간결하며, 최신 암호화 프리미티브만 사용하여 보안 감사가 용이합니다. 커널 레벨에서 동작하므로 유저스페이스 VPN 대비 높은 성능을 제공합니다.

WireGuard vs IPSec vs OpenVPN 비교

암호화 프리미티브

WireGuard는 암호 민첩성(cipher agility)을 의도적으로 배제합니다. 단일 고정 암호 스위트만 사용하여 다운그레이드 공격을 원천 차단합니다:

/* drivers/net/wireguard/noise.h — Noise Protocol 상수 */
#define NOISE_PUBLIC_KEY_LEN     32   /* Curve25519 공개키 */
#define NOISE_SYMMETRIC_KEY_LEN  32   /* ChaCha20-Poly1305 키 */
#define NOISE_TIMESTAMP_LEN      12   /* TAI64N 타임스탬프 */
#define NOISE_AUTHTAG_LEN        16   /* Poly1305 인증 태그 */
#define NOISE_HASH_LEN           32   /* BLAKE2s 해시 길이 */

Noise Protocol Framework (IK 패턴)

WireGuard는 Noise Protocol Framework의 Noise_IKpsk2 패턴을 사용합니다. "IK"는 Initiator가 Responder의 정적 공개키를 미리 알고 있다(Known)는 의미이며, psk2는 선택적 사전 공유 키(Pre-Shared Key)를 두 번째 메시지에서 믹스한다는 뜻입니다.

/* Noise_IKpsk2 핸드셰이크 패턴 */
/*
 * ← s                              (Responder 정적 공개키를 미리 알고 있음)
 * ...
 * → e, es, s, ss                   (메시지 1: Initiation)
 * ← e, ee, se, psk                 (메시지 2: Response)
 *
 * e  = 임시(ephemeral) 키 생성
 * es = Initiator 임시키 × Responder 정적키 DH
 * s  = Initiator 정적키 (암호화하여 전송)
 * ss = Initiator 정적키 × Responder 정적키 DH
 * ee = Initiator 임시키 × Responder 임시키 DH
 * se = Responder 임시키 × Initiator 정적키 DH
 * psk = Pre-Shared Key 믹스 (양자 내성 레이어)
 */

/* 핸드셰이크 메시지 구조 — drivers/net/wireguard/messages.h */

/* 메시지 타입 */
enum message_type {
    MESSAGE_HANDSHAKE_INITIATION  = 1,
    MESSAGE_HANDSHAKE_RESPONSE    = 2,
    MESSAGE_HANDSHAKE_COOKIE      = 3,
    MESSAGE_DATA                  = 4,
};

/* 메시지 1: Handshake Initiation (148 바이트) */
struct message_handshake_initiation {
    struct message_header header;  /* type(1) + reserved(3) */
    __le32 sender_index;           /* Initiator 세션 ID */
    u8 unencrypted_ephemeral[NOISE_PUBLIC_KEY_LEN]; /* e: 임시 공개키 (평문) */
    u8 encrypted_static[NOISE_PUBLIC_KEY_LEN
                        + NOISE_AUTHTAG_LEN];  /* s: 정적 공개키 (암호화) */
    u8 encrypted_timestamp[NOISE_TIMESTAMP_LEN
                           + NOISE_AUTHTAG_LEN]; /* TAI64N 타임스탬프 (암호화) */
    struct message_macs macs;      /* mac1 + mac2 (DoS 방어) */
};

/* 메시지 2: Handshake Response (92 바이트) */
struct message_handshake_response {
    struct message_header header;
    __le32 sender_index;           /* Responder 세션 ID */
    __le32 receiver_index;         /* Initiator의 sender_index */
    u8 unencrypted_ephemeral[NOISE_PUBLIC_KEY_LEN]; /* e: 임시 공개키 */
    u8 encrypted_nothing[NOISE_AUTHTAG_LEN];       /* 빈 AEAD (인증만) */
    struct message_macs macs;
};

/* 메시지 4: 데이터 패킷 */
struct message_data {
    struct message_header header;
    __le32 key_idx;                /* 수신자 세션 인덱스 */
    __le64 counter;                /* nonce (8바이트, 리플레이 방지) */
    u8 encrypted_data[];           /* 암호화된 IP 패킷 + Poly1305 태그 */
};

핸드셰이크 상세 과정

/* WireGuard Noise IK 핸드셰이크 상세 흐름 */

/*
 * 사전 조건:
 *   - Initiator (I): 자신의 정적 키쌍 (Si_priv, Si_pub)
 *   - Responder (R): 자신의 정적 키쌍 (Sr_priv, Sr_pub)
 *   - I는 Sr_pub를 미리 알고 있음 (설정 시 지정)
 *
 * 초기 상태:
 *   C = HASH("Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s")  ← chaining key
 *   H = HASH(C || "WireGuard v1 zx2c4 Jason@zx2c4.com...")  ← hash
 *   H = HASH(H || Sr_pub)  ← Responder 공개키를 해시에 믹스
 *
 * ─── 메시지 1: Initiation (I → R) ───
 *   Ei_priv, Ei_pub = DH_GENERATE()        임시 키쌍 생성
 *   H = HASH(H || Ei_pub)                  임시 공개키 해시
 *   C, k = KDF2(C, DH(Ei_priv, Sr_pub))   es: 임시×정적 DH → 키 유도
 *   encrypted_static = AEAD(k, 0, Si_pub, H)  정적 공개키 암호화
 *   H = HASH(H || encrypted_static)
 *   C, k = KDF2(C, DH(Si_priv, Sr_pub))   ss: 정적×정적 DH → 키 유도
 *   encrypted_timestamp = AEAD(k, 0, TAI64N(), H)  타임스탬프 암호화
 *   H = HASH(H || encrypted_timestamp)
 *
 * ─── 메시지 2: Response (R → I) ───
 *   Er_priv, Er_pub = DH_GENERATE()        임시 키쌍 생성
 *   H = HASH(H || Er_pub)
 *   C, k = KDF2(C, DH(Er_priv, Ei_pub))   ee: 양쪽 임시키 DH
 *   C, k = KDF2(C, DH(Er_priv, Si_pub))   se: Responder임시×Initiator정적
 *   C, k = KDF2(C, psk)                    psk 믹스 (없으면 all-zero)
 *   encrypted_nothing = AEAD(k, 0, "", H)  빈 페이로드 인증
 *   H = HASH(H || encrypted_nothing)
 *
 * ─── 세션 키 유도 ───
 *   T_send, T_recv = KDF2(C, "")           양방향 전송 키 생성
 *   → I는 T_send로 암호화, T_recv로 복호화
 *   → R는 T_recv로 암호화, T_send로 복호화
 */

/* drivers/net/wireguard/noise.c — 핸드셰이크 Initiation 생성 (단순화) */
bool wg_noise_handshake_create_initiation(
    struct message_handshake_initiation *dst,
    struct noise_handshake *handshake)
{
    struct noise_symmetric_key *key;

    down_read(&handshake->lock);

    /* 1. 임시 키쌍 생성 (Curve25519) */
    curve25519_generate_secret(handshake->ephemeral_private);
    curve25519_generate_public(dst->unencrypted_ephemeral,
                               handshake->ephemeral_private);

    /* 2. 임시 공개키를 해시 체인에 믹스 */
    mix_hash(handshake->hash,
             dst->unencrypted_ephemeral, NOISE_PUBLIC_KEY_LEN);

    /* 3. DH(Ei_priv, Sr_pub) → chaining key 갱신 */
    if (!mix_dh(handshake->chaining_key, key,
               handshake->ephemeral_private,
               handshake->remote_static))
        goto out;

    /* 4. 정적 공개키 암호화 전송 */
    message_encrypt(dst->encrypted_static,
                    handshake->static_identity->static_public,
                    NOISE_PUBLIC_KEY_LEN, key, handshake->hash);

    /* 5. DH(Si_priv, Sr_pub) → chaining key 갱신 */
    mix_dh(handshake->chaining_key, key,
           handshake->static_identity->static_private,
           handshake->remote_static);

    /* 6. TAI64N 타임스탬프 암호화 (리플레이 방지) */
    tai64n_now(timestamp);
    message_encrypt(dst->encrypted_timestamp,
                    timestamp, NOISE_TIMESTAMP_LEN,
                    key, handshake->hash);

    /* 7. MAC 계산 (DoS 방어) */
    message_macs(dst, dst->macs, handshake);

    up_read(&handshake->lock);
    return true;
out:
    up_read(&handshake->lock);
    return false;
}

DoS 방어: 쿠키 메커니즘

WireGuard는 핸드셰이크 패킷에 두 개의 MAC을 포함하여 DoS 공격을 완화합니다:

/* drivers/net/wireguard/messages.h */
struct message_macs {
    u8 mac1[COOKIE_LEN];  /* 항상 검증 — BLAKE2s(msg, peer_pubkey) */
    u8 mac2[COOKIE_LEN];  /* 부하 시에만 검증 — BLAKE2s(msg, cookie) */
};

/*
 * mac1: 메시지 무결성 + 피어 인증 (항상 검증)
 *   → mac1 = BLAKE2s(responder_pub, msg_without_macs)
 *   → 유효한 피어만 올바른 mac1을 생성 가능
 *
 * mac2: DoS 방어 토큰 (서버 부하 시에만 요구)
 *   → 서버가 과부하 감지 시 MESSAGE_HANDSHAKE_COOKIE 응답
 *   → cookie = Xchacha20Poly1305(BLAKE2s(client_ip:port), random_secret)
 *   → 클라이언트는 받은 cookie로 mac2를 재계산하여 재전송
 *   → IP 주소 기반이므로 스푸핑된 IP로는 cookie 수신 불가
 */

/* drivers/net/wireguard/cookie.c — 쿠키 검증 흐름 (단순화) */
enum cookie_mac_state
wg_cookie_validate_packet(struct cookie_checker *checker,
                          struct sk_buff *skb, bool check_cookie)
{
    struct message_macs *macs = (void *)(skb->data + skb->len
                                         - sizeof(*macs));

    /* 1단계: mac1 검증 (항상) */
    blake2s(computed_mac1, skb->data,
            skb->len - sizeof(*macs),
            checker->mac1_key, COOKIE_LEN);
    if (!crypto_memneq(computed_mac1, macs->mac1, COOKIE_LEN))
        return INVALID_MAC;

    /* 2단계: 부하 상태 시 mac2 검증 */
    if (!check_cookie)
        return VALID_MAC_BUT_NO_COOKIE;

    make_cookie(cookie, skb, checker);
    blake2s(computed_mac2, skb->data,
            skb->len - COOKIE_LEN,
            cookie, COOKIE_LEN);
    if (!crypto_memneq(computed_mac2, macs->mac2, COOKIE_LEN))
        return VALID_MAC_WITH_COOKIE_BUT_RATELIMITED;

    return VALID_MAC_WITH_COOKIE;
}

커널 구현 아키텍처

/* drivers/net/wireguard/ 소스 파일 구조 */
/*
 * drivers/net/wireguard/
 * ├── main.c           ← 모듈 초기화 (wg_mod_init)
 * ├── device.c         ← netdevice 생성/소멸, ndo_start_xmit
 * ├── device.h         ← struct wg_device 정의
 * ├── noise.c          ← Noise Protocol 핸드셰이크 엔진
 * ├── noise.h          ← noise_handshake, noise_keypair 구조체
 * ├── peer.c           ← struct wg_peer 생성/관리
 * ├── peer.h           ← 피어 구조체 정의
 * ├── allowedips.c     ← IP 기반 라우팅 트라이 (Cryptokey Routing)
 * ├── allowedips.h     ← allowedips_node 구조체
 * ├── queueing.c       ← 암호화/복호화 병렬 큐 관리
 * ├── queueing.h       ← crypt_queue, 큐잉 매크로
 * ├── send.c           ← 패킷 암호화 + 전송 (xmit)
 * ├── receive.c        ← 패킷 수신 + 복호화 (rx)
 * ├── socket.c         ← UDP 소켓 관리
 * ├── netlink.c        ← Generic Netlink 인터페이스 (wg set/show)
 * ├── cookie.c         ← MAC/쿠키 DoS 방어
 * ├── cookie.h         ← cookie_checker 구조체
 * ├── timers.c         ← 키 재협상, keepalive 타이머
 * ├── timers.h         ← 타이머 상수 정의
 * ├── peerlookup.c     ← 인덱스 해시 테이블 (세션 ID → keypair)
 * ├── peerlookup.h     ← index_hashtable 구조체
 * ├── ratelimiter.c    ← 핸드셰이크 속도 제한
 * └── ratelimiter.h    ← 레이트리미터 구조체
 */

주요 데이터 구조

/* drivers/net/wireguard/device.h — WireGuard 디바이스 (인터페이스당 1개) */
struct wg_device {
    struct net_device *dev;          /* 커널 net_device (wg0, wg1, ...) */
    struct crypt_queue encrypt_queue; /* 암호화 큐 (per-CPU 워커) */
    struct crypt_queue decrypt_queue; /* 복호화 큐 (per-CPU 워커) */
    struct sock __rcu *sock4;         /* IPv4 UDP 소켓 */
    struct sock __rcu *sock6;         /* IPv6 UDP 소켓 */
    struct noise_static_identity static_identity; /* 정적 키쌍 */
    struct list_head peer_list;      /* 피어 연결 리스트 */
    struct allowedips peer_allowedips;/* AllowedIPs 라우팅 테이블 */
    struct index_hashtable index_hashtable; /* 세션 인덱스 → keypair */
    struct cookie_checker cookie_checker;  /* DoS 방어 쿠키 */
    u16 incoming_port;               /* 수신 UDP 포트 (기본 51820) */
    u32 fwmark;                      /* 라우팅 마크 */
    struct mutex device_update_lock;  /* 디바이스 설정 변경 잠금 */
    struct mutex socket_update_lock;  /* 소켓 변경 잠금 */
};

/* drivers/net/wireguard/peer.h — 피어 (원격 엔드포인트당 1개) */
struct wg_peer {
    struct wg_device *device;        /* 소속 디바이스 */
    struct noise_handshake handshake; /* 핸드셰이크 상태 */
    struct noise_keypairs keypairs;   /* 현재/이전/다음 세션 키 */
    struct endpoint endpoint;         /* 최종 알려진 IP:port */
    struct allowedips_node *allowedips_list; /* 허용 IP 목록 */

    /* 타이머 */
    struct timer_list timer_retransmit_handshake;
    struct timer_list timer_send_keepalive;
    struct timer_list timer_new_handshake;
    struct timer_list timer_zero_key_material;
    struct timer_list timer_persistent_keepalive;

    /* 통계 */
    u64 rx_bytes, tx_bytes;
    struct timespec64 walltime_last_handshake;

    struct kref refcount;             /* 참조 카운트 */
    struct rcu_head rcu;              /* RCU 해제 */
    struct list_head peer_list;       /* wg_device→peer_list 연결 */

    /* 전송 큐 */
    struct prev_queue tx_queue, rx_queue; /* napi 기반 큐 */
    struct napi_struct tx_napi, rx_napi;  /* NAPI 폴링 */
};

/* drivers/net/wireguard/noise.h — 핸드셰이크 상태 */
struct noise_handshake {
    struct index_hashtable_entry entry; /* 인덱스 해시 테이블 엔트리 */
    u8 remote_static[NOISE_PUBLIC_KEY_LEN];   /* 상대 정적 공개키 */
    u8 remote_ephemeral[NOISE_PUBLIC_KEY_LEN]; /* 상대 임시 공개키 */
    u8 ephemeral_private[NOISE_PUBLIC_KEY_LEN]; /* 내 임시 비밀키 */
    u8 hash[NOISE_HASH_LEN];           /* 핸드셰이크 해시 (H) */
    u8 chaining_key[NOISE_HASH_LEN];   /* 체인 키 (C) */
    u8 preshared_key[NOISE_SYMMETRIC_KEY_LEN]; /* PSK (선택) */
    u8 latest_timestamp[NOISE_TIMESTAMP_LEN];  /* 리플레이 방지 */
    enum noise_handshake_state state; /* CREATED/CONSUMED/RESPONSE */
    struct noise_static_identity *static_identity; /* 디바이스 정적 키 */
    struct rw_semaphore lock;
};

/* 세션 키쌍 — 핸드셰이크 완료 후 데이터 전송에 사용 */
struct noise_keypair {
    struct index_hashtable_entry entry;
    u8 sending_key[NOISE_SYMMETRIC_KEY_LEN];   /* 송신 키 */
    u8 receiving_key[NOISE_SYMMETRIC_KEY_LEN]; /* 수신 키 */
    struct noise_replay_counter receiving_counter; /* 리플레이 윈도우 */
    atomic64_t sending_counter;         /* 송신 카운터 (nonce) */
    ktime_t birthdate;                   /* 키 생성 시각 */
    bool is_initiator;                   /* 이 핸드셰이크의 Initiator? */
    struct kref refcount;
    struct rcu_head rcu;
};

AllowedIPs: Cryptokey Routing

WireGuard의 핵심 개념인 Cryptokey Routing은 AllowedIPs 트라이(trie) 자료구조로 구현됩니다. 각 IP 대역은 특정 피어의 공개키에 매핑되어, 일반 라우팅 테이블처럼 최장 접두사 매칭(LPM)으로 패킷의 피어를 결정합니다:

/* drivers/net/wireguard/allowedips.h */
struct allowedips_node {
    struct wg_peer __rcu *peer;  /* 이 대역에 매핑된 피어 */
    struct allowedips_node __rcu *bit[2]; /* 0비트/1비트 자식 */
    u8 cidr;                     /* 서브넷 마스크 길이 */
    u8 bit_at_a, bit_at_b;       /* 압축된 비트 위치 */
    u8 bitlen;                   /* 주소 길이 (32=IPv4, 128=IPv6) */
    u8 bits[16] __aligned(sizeof(u64)); /* IP 주소 비트 */
};

struct allowedips {
    struct allowedips_node __rcu *root4; /* IPv4 트라이 루트 */
    struct allowedips_node __rcu *root6; /* IPv6 트라이 루트 */
    u64 seq;                             /* 시퀀스 (변경 추적) */
};

/* AllowedIPs 동작 예시:
 *
 * [Peer A] PublicKey = aaa...
 *   AllowedIPs = 10.0.0.0/24, fd00::1/128
 *
 * [Peer B] PublicKey = bbb...
 *   AllowedIPs = 10.0.1.0/24, 0.0.0.0/0
 *
 * 송신 결정:
 *   dst=10.0.0.5   → Peer A (10.0.0.0/24 매칭)
 *   dst=10.0.1.100 → Peer B (10.0.1.0/24 매칭)
 *   dst=8.8.8.8    → Peer B (0.0.0.0/0 기본 경로)
 *
 * 수신 검증:
 *   Peer A에서 수신한 패킷의 inner src가 10.0.0.5 → 허용
 *   Peer A에서 수신한 패킷의 inner src가 10.0.1.5 → 드롭 (AllowedIPs 불일치)
 *
 * → 송신: AllowedIPs로 피어 결정 (라우팅)
 * → 수신: AllowedIPs로 소스 IP 검증 (역방향 경로 필터링)
 */

/* drivers/net/wireguard/allowedips.c — 최장 접두사 매칭 (LPM) */
struct wg_peer *wg_allowedips_lookup_dst(
    struct allowedips *table,
    struct sk_buff *skb)
{
    if (skb->protocol == htons(ETH_P_IP))
        return lookup(table->root4, 32,
                      &ip_hdr(skb)->daddr);  /* IPv4 목적지 */
    else if (skb->protocol == htons(ETH_P_IPV6))
        return lookup(table->root6, 128,
                      &ipv6_hdr(skb)->daddr); /* IPv6 목적지 */
    return NULL;
}

/* 수신 시: 소스 IP가 피어의 AllowedIPs에 포함되는지 검증 */
struct wg_peer *wg_allowedips_lookup_src(
    struct allowedips *table,
    struct sk_buff *skb)
{
    if (skb->protocol == htons(ETH_P_IP))
        return lookup(table->root4, 32,
                      &ip_hdr(skb)->saddr);  /* IPv4 소스 */
    else if (skb->protocol == htons(ETH_P_IPV6))
        return lookup(table->root6, 128,
                      &ipv6_hdr(skb)->saddr);
    return NULL;
}

패킷 처리 흐름

/* WireGuard 송신 패킷 흐름 (Transmit Path)
 *
 * 애플리케이션 → socket → IP 라우팅 → wg0 dev
 *   │
 *   ↓  ndo_start_xmit() (device.c)
 *   ├─ AllowedIPs 테이블에서 dst IP로 피어 검색
 *   ├─ 피어 없음 → ICMP unreachable + 드롭
 *   │
 *   ├─ 세션 키 확인
 *   │   ├─ 유효한 keypair 있음 → 암호화 큐에 추가
 *   │   └─ 키 없음/만료 → 핸드셰이크 시작 + 패킷 대기열
 *   │
 *   ↓  encrypt_queue (queueing.c)
 *   ├─ per-CPU 워커가 ChaCha20-Poly1305로 암호화
 *   ├─ 카운터(nonce) 증가 (atomic64_inc_return)
 *   ├─ message_data 헤더 부착
 *   │
 *   ↓  NAPI tx_napi 폴링 (send.c)
 *   ├─ UDP 소켓으로 캡슐화 전송
 *   └─ peer->endpoint (IP:port)로 전송
 *
 *
 * WireGuard 수신 패킷 흐름 (Receive Path)
 *
 * NIC → netif_receive_skb → IP → UDP → wg 소켓
 *   │
 *   ↓  wg_receive() (socket.c → receive.c)
 *   ├─ 메시지 타입 판별
 *   │   ├─ MESSAGE_DATA (4):
 *   │   │   ├─ key_idx로 index_hashtable에서 keypair 검색
 *   │   │   ├─ 리플레이 윈도우 검사 (counter)
 *   │   │   ├─ decrypt_queue에 추가
 *   │   │   │
 *   │   │   ↓  per-CPU 워커가 복호화
 *   │   │   ├─ ChaCha20-Poly1305 복호화 + 인증 검증
 *   │   │   ├─ 실패 → 드롭 (인증 태그 불일치)
 *   │   │   │
 *   │   │   ↓  NAPI rx_napi 폴링
 *   │   │   ├─ AllowedIPs로 inner src IP 검증
 *   │   │   ├─ 불일치 → 드롭 (피어 스푸핑 방지)
 *   │   │   ├─ 피어 endpoint 업데이트 (로밍 지원)
 *   │   │   └─ netif_receive_skb() → 일반 IP 처리
 *   │   │
 *   │   ├─ MESSAGE_HANDSHAKE_INITIATION (1):
 *   │   │   ├─ mac1 검증 → 부하 시 mac2 검증
 *   │   │   ├─ Noise handshake 처리
 *   │   │   └─ Response 메시지 생성 + 전송
 *   │   │
 *   │   ├─ MESSAGE_HANDSHAKE_RESPONSE (2):
 *   │   │   ├─ 핸드셰이크 완료
 *   │   │   ├─ 세션 키 유도 (T_send, T_recv)
 *   │   │   └─ 대기 중인 패킷 전송
 *   │   │
 *   │   └─ MESSAGE_HANDSHAKE_COOKIE (3):
 *   │       └─ cookie 저장 → mac2 재계산 후 재전송
 */

/* drivers/net/wireguard/device.c — 패킷 송신 진입점 */
static netdev_tx_t wg_xmit(struct sk_buff *skb,
                            struct net_device *dev)
{
    struct wg_device *wg = netdev_priv(dev);
    struct wg_peer *peer;
    struct noise_keypair *keypair;
    int ret;

    /* 1. AllowedIPs에서 목적지 IP로 피어 검색 */
    peer = wg_allowedips_lookup_dst(&wg->peer_allowedips, skb);
    if (unlikely(!peer)) {
        ret = -ENOKEY;
        net_dbg_ratelimited("%s: No peer for dst\n", dev->name);
        goto err;
    }

    /* 2. 유효한 세션 키 확보 */
    keypair = wg_noise_keypair_current(peer);
    if (unlikely(!keypair)) {
        /* 키 없음 → 핸드셰이크 시작, 패킷 큐잉 */
        wg_packet_queue_staged_packets(peer, skb);
        wg_packet_send_handshake_initiation(peer);
        return NETDEV_TX_OK;
    }

    /* 3. 암호화 큐에 추가 (per-CPU 워커가 처리) */
    wg_packet_encrypt_worker(skb, keypair, peer);

    return NETDEV_TX_OK;
err:
    kfree_skb(skb);
    return NETDEV_TX_OK;
}

/* drivers/net/wireguard/send.c — 암호화 처리 (단순화) */
static void encrypt_packet(struct sk_buff *skb,
                           struct noise_keypair *keypair)
{
    struct message_data *header;
    u64 nonce;
    bool ret;

    /* nonce 원자적 증가 (리플레이 방지) */
    nonce = atomic64_inc_return(&keypair->sending_counter) - 1;
    if (nonce >= REJECT_AFTER_MESSAGES) {
        /* 2^64 - 2^13 - 1 메시지 초과 → 키 재협상 필요 */
        goto err;
    }

    /* 데이터 헤더 구성 */
    header = (struct message_data *)skb_push(skb,
              sizeof(struct message_data));
    header->header.type = cpu_to_le32(MESSAGE_DATA);
    header->key_idx = keypair->remote_index;
    header->counter = cpu_to_le64(nonce);

    /* ChaCha20-Poly1305 AEAD 암호화 */
    ret = chacha20poly1305_encrypt(
        skb->data + sizeof(*header),  /* 평문 IP 패킷 */
        skb->len - sizeof(*header),
        NULL, 0,                       /* AAD 없음 */
        nonce,
        keypair->sending_key);        /* 세션 송신 키 */

    /* Poly1305 인증 태그 (16바이트) 자동 부착 */
}

/* drivers/net/wireguard/receive.c — 수신 복호화 + AllowedIPs 검증 */
static void wg_packet_consume_data_done(
    struct wg_peer *peer,
    struct sk_buff *skb,
    struct endpoint *endpoint)
{
    struct net_device *dev = peer->device->dev;
    struct wg_peer *routed_peer;
    unsigned int len;

    /* inner 패킷 프로토콜 확인 */
    if (unlikely(skb_network_header(skb)[0] >> 4 != 4
                && skb_network_header(skb)[0] >> 4 != 6))
        goto dishonest;

    /* 핵심: AllowedIPs로 소스 IP 검증 (역방향 경로 필터링) */
    routed_peer = wg_allowedips_lookup_src(
        &peer->device->peer_allowedips, skb);
    if (unlikely(routed_peer != peer))
        goto dishonest;  /* 피어가 허용되지 않은 IP로 패킷 전송 → 드롭 */

    /* 피어 endpoint 업데이트 (로밍 지원) */
    wg_socket_set_peer_endpoint(peer, endpoint);

    /* 통계 갱신 */
    len = skb->len;
    wg_timers_data_received(peer);

    /* 복호화된 패킷을 네트워크 스택에 주입 */
    if (likely(netif_receive_skb(skb) == NET_RX_SUCCESS))
        peer->rx_bytes += len;
    return;

dishonest:
    net_dbg_ratelimited("%s: Packet from peer with wrong inner src\n",
                        dev->name);
    ++dev->stats.rx_errors;
    kfree_skb(skb);
}

병렬 암/복호화와 NAPI

WireGuard는 암호화 연산을 per-CPU 워크큐에서 병렬 처리하고, 결과를 NAPI 폴링으로 순서대로 전달합니다. 이 설계로 멀티코어 환경에서 선형적 성능 확장을 달성합니다:

/* drivers/net/wireguard/queueing.h — 병렬 암호화 큐 */
struct crypt_queue {
    struct ptr_ring ring;          /* lock-free 링 버퍼 (skb 포인터) */
    struct work_struct work;        /* per-CPU 워크큐 (암/복호 실행) */
    int last_cpu;                   /* 마지막 사용 CPU (로드 밸런싱) */
};

/*
 * 스레딩 모델:
 *
 *   [xmit 또는 UDP recv]
 *         │
 *         ↓
 *   crypt_queue.ring에 skb 추가
 *         │
 *         ↓
 *   per-CPU 워커 (encrypt/decrypt)  ← 실제 암호 연산 (CPU 집약)
 *   ┌─CPU0─┐ ┌─CPU1─┐ ┌─CPU2─┐
 *   │ skb1 │ │ skb2 │ │ skb3 │    ← 병렬 처리
 *   └──┬───┘ └──┬───┘ └──┬───┘
 *      │        │        │
 *      ↓        ↓        ↓
 *   peer->tx/rx_queue (prev_queue)  ← 순서 보장 큐
 *         │
 *         ↓
 *   NAPI 폴링 (tx_napi / rx_napi)  ← softirq에서 순서대로 전송/주입
 *
 * 핵심: 암호화는 병렬, 전달은 순서대로 (per-peer NAPI)
 */

/* drivers/net/wireguard/queueing.c — per-CPU 워커 분배 */
int wg_queue_enqueue_per_device_and_peer(
    struct crypt_queue *device_queue,
    struct prev_queue *peer_queue,
    struct sk_buff *skb)
{
    int cpu;

    /* 라운드 로빈으로 CPU 선택 */
    cpu = wg_cpumask_next_online(&device_queue->last_cpu);

    /* peer 큐에 순서 슬롯 예약 (FIFO 보장) */
    atomic_set(&PACKET_CB(skb)->state, PACKET_STATE_UNCRYPTED);
    prev_queue_enqueue(peer_queue, skb);

    /* device 큐에 추가 → per-CPU 워커 기동 */
    ptr_ring_produce(&device_queue->ring, skb);
    queue_work_on(cpu, wg_packet_crypt_wq,
                  &per_cpu_ptr(device_queue->worker, cpu)->work);
    return 0;
}

타이머 메커니즘

WireGuard는 5개의 타이머로 핸드셰이크 수명주기, keepalive, 키 제로화를 관리합니다:

/* drivers/net/wireguard/timers.h — 타이머 상수 */
#define REKEY_AFTER_MESSAGES     (1ULL << 60)   /* 2^60 메시지 후 키 갱신 */
#define REJECT_AFTER_MESSAGES   (U64_MAX - (1ULL << 13) - 1) /* nonce 한계 */
#define REKEY_AFTER_TIME         120           /* 2분 후 키 갱신 */
#define REJECT_AFTER_TIME        180           /* 3분 후 키 거부 */
#define REKEY_TIMEOUT            5             /* 핸드셰이크 재전송 간격 */
#define KEEPALIVE_TIMEOUT        10            /* Passive keepalive */
#define MAX_TIMER_HANDSHAKES     90            /* 최대 재전송 횟수 */

/* drivers/net/wireguard/timers.c — 키 갱신 로직 (단순화) */
static void wg_expired_retransmit_handshake(struct timer_list *timer)
{
    struct wg_peer *peer = from_timer(peer, timer,
                                        timer_retransmit_handshake);

    if (peer->timer_handshake_attempts > MAX_TIMER_HANDSHAKES) {
        /* 7.5분 동안 응답 없음 → 키 소재 제로화 */
        pr_debug("%s: Handshake timed out for peer %llu\n",
                 peer->device->dev->name, peer->internal_id);
        wg_noise_handshake_clear(&peer->handshake);
        wg_noise_keypairs_clear(&peer->keypairs);
        return;
    }

    /* Initiation 재전송 + 지수 백오프 아닌 고정 5초 간격 */
    ++peer->timer_handshake_attempts;
    wg_packet_send_handshake_initiation(peer);
}

/* 데이터 수신 시 keepalive 타이머 재설정 */
void wg_timers_data_received(struct wg_peer *peer)
{
    if (!timer_pending(&peer->timer_send_keepalive))
        mod_timer(&peer->timer_send_keepalive,
                  jiffies + KEEPALIVE_TIMEOUT * HZ);
}

/* 데이터 송신 시 키 수명 확인 */
void wg_timers_data_sent(struct wg_peer *peer)
{
    struct noise_keypair *keypair =
        rcu_dereference(peer->keypairs.current_keypair);

    /* REKEY_AFTER_TIME (120초) 경과 → 새 핸드셰이크 */
    if (keypair && keypair->is_initiator &&
        wg_birthdate_has_expired(keypair, REKEY_AFTER_TIME))
        wg_packet_send_handshake_initiation(peer);
}

리플레이 방지 (Sliding Window)

/* drivers/net/wireguard/noise.h — 리플레이 카운터 */
struct noise_replay_counter {
    u64 counter;                  /* 수신된 최대 nonce */
    unsigned long backtrack[COUNTER_BITS_TOTAL / BITS_PER_LONG];
                                   /* 비트맵 슬라이딩 윈도우 (2048비트) */
    struct spinlock lock;
};

/*
 * 리플레이 방지 알고리즘:
 *
 * 1. 수신 nonce > counter → 윈도우 슬라이드, counter 갱신, 허용
 * 2. counter - COUNTER_WINDOW_SIZE < nonce <= counter
 *    → backtrack 비트맵에서 해당 비트 확인
 *    → 이미 설정됨 → 리플레이 → 드롭
 *    → 미설정 → 비트 설정 + 허용
 * 3. nonce <= counter - COUNTER_WINDOW_SIZE → 너무 오래됨 → 드롭
 *
 * COUNTER_WINDOW_SIZE = 2048
 * → 최대 2048개 패킷의 순서 뒤바뀜 허용
 * → UDP 전송 환경에서 충분한 여유
 */

/* 리플레이 검사 */
bool wg_noise_counter_validate(
    struct noise_replay_counter *counter,
    u64 their_counter)
{
    bool ret = false;
    unsigned long index;

    spin_lock_bh(&counter->lock);

    if (unlikely(their_counter >= REJECT_AFTER_MESSAGES))
        goto out;

    if (their_counter > counter->counter) {
        /* 새로운 최대값 → 윈도우 전진 */
        index = their_counter >> COUNTER_REDUNDANT_BITS;
        /* 이전 비트들 클리어 */
        bitmap_clear(counter->backtrack, ...);
        counter->counter = their_counter;
        ret = true;
    } else if (their_counter + COUNTER_WINDOW_SIZE >
               counter->counter) {
        /* 윈도우 범위 내 → 비트맵 확인 */
        index = their_counter >> COUNTER_REDUNDANT_BITS;
        if (test_and_set_bit(index & (COUNTER_BITS_TOTAL - 1),
                             counter->backtrack))
            ret = false;  /* 이미 수신됨 → 리플레이 */
        else
            ret = true;   /* 처음 수신 → 허용 */
    }
    /* else: 윈도우 밖 → ret = false (너무 오래됨) */

out:
    spin_unlock_bh(&counter->lock);
    return ret;
}

로밍 (Roaming) 메커니즘

WireGuard는 피어의 endpoint(IP:port)를 고정하지 않고, 정상적으로 인증된 패킷이 도착할 때마다 소스 주소를 업데이트합니다. 이로써 모바일 기기의 네트워크 전환(Wi-Fi ↔ LTE) 시 자동으로 VPN이 유지됩니다:

/* drivers/net/wireguard/socket.c — 엔드포인트 업데이트 */
void wg_socket_set_peer_endpoint(
    struct wg_peer *peer,
    const struct endpoint *endpoint)
{
    /* 인증된 패킷의 소스 주소가 변경된 경우에만 업데이트 */
    if (endpoint_eq(&peer->endpoint, endpoint))
        return;

    write_lock_bh(&peer->endpoint_lock);
    peer->endpoint.addr = endpoint->addr;
    write_unlock_bh(&peer->endpoint_lock);
}

/*
 * 로밍 시나리오:
 *
 * 1. 서버(S)는 클라이언트(C) endpoint = 1.2.3.4:51820
 * 2. C가 Wi-Fi → LTE로 전환 → IP가 5.6.7.8로 변경
 * 3. C는 기존 세션 키로 패킷을 5.6.7.8에서 전송
 * 4. S는 수신 → 복호화 성공 → AllowedIPs 검증 통과
 * 5. S는 C의 endpoint를 5.6.7.8:port로 자동 업데이트
 * 6. 이후 S→C 응답은 5.6.7.8로 전송
 *
 * → 재연결, 재인증 불필요 (세션 키가 유효한 한 즉시 전환)
 * → 단, 정적 공개키를 알고 유효한 세션 키로 인증된 패킷만
 *   endpoint 변경을 유발 → 스푸핑 불가
 */

Netlink 인터페이스 (Generic Netlink)

WireGuard는 wg(8) 유틸리티와 Generic Netlink로 통신합니다. 패밀리 이름 "wireguard"로 등록되며, WG_CMD_SET_DEVICE와 WG_CMD_GET_DEVICE 두 개의 명령을 지원합니다:

/* drivers/net/wireguard/netlink.c — Generic Netlink 정의 */
static const struct genl_ops wg_genl_ops[] = {
    {
        .cmd    = WG_CMD_GET_DEVICE,
        .doit   = wg_get_device_dump,  /* wg show */
        .dumpit = wg_get_device_dump,
        .flags  = GENL_UNS_ADMIN_PERM,
    },
    {
        .cmd    = WG_CMD_SET_DEVICE,
        .doit   = wg_set_device,       /* wg set */
        .flags  = GENL_UNS_ADMIN_PERM,
    },
};

static struct genl_family wg_genl_family __ro_after_init = {
    .name     = WG_GENL_NAME,         /* "wireguard" */
    .version  = WG_GENL_VERSION,      /* 1 */
    .maxattr  = WGDEVICE_A_MAX,
    .module   = THIS_MODULE,
    .ops      = wg_genl_ops,
    .n_ops    = ARRAY_SIZE(wg_genl_ops),
};

/* Netlink Attribute 계층 구조:
 *
 * WGDEVICE_A_IFNAME        ← 인터페이스 이름 ("wg0")
 * WGDEVICE_A_PRIVATE_KEY   ← 디바이스 비밀키
 * WGDEVICE_A_PUBLIC_KEY    ← 디바이스 공개키
 * WGDEVICE_A_LISTEN_PORT   ← 수신 UDP 포트
 * WGDEVICE_A_FWMARK        ← 라우팅 마크
 * WGDEVICE_A_PEERS         ← 중첩 피어 목록
 *   └─ WGPEER_A_PUBLIC_KEY       ← 피어 공개키
 *      WGPEER_A_PRESHARED_KEY    ← PSK (선택)
 *      WGPEER_A_ENDPOINT         ← IP:port
 *      WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL
 *      WGPEER_A_ALLOWEDIPS       ← 중첩 IP 목록
 *        └─ WGALLOWEDIP_A_FAMILY   ← AF_INET/AF_INET6
 *           WGALLOWEDIP_A_IPADDR   ← IP 주소
 *           WGALLOWEDIP_A_CIDR_MASK ← 서브넷 마스크
 *      WGPEER_A_LAST_HANDSHAKE_TIME
 *      WGPEER_A_RX_BYTES
 *      WGPEER_A_TX_BYTES
 */

설정 예제와 커널 동작

# WireGuard 인터페이스 생성 (ip-link netlink → rtnl_newlink)
ip link add wg0 type wireguard
# → rtnl_link_ops.newlink() → wg_newlink()
#   → alloc_netdev() + register_netdevice()
#   → wg0 netdevice 생성 (net_device_ops = wg_netdev_ops)

# 키 생성 (유저스페이스에서 Curve25519 키쌍 생성)
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
# → wg genkey: /dev/urandom에서 32바이트 읽기 + Curve25519 클램핑
#   wg pubkey: curve25519(private_key, basepoint) → 공개키

# WireGuard 설정 (Generic Netlink → WG_CMD_SET_DEVICE)
wg set wg0 \
    listen-port 51820 \
    private-key /etc/wireguard/private.key \
    peer "peer_public_key_base64" \
        endpoint 203.0.113.1:51820 \
        allowed-ips 10.0.0.0/24,fd00::/64 \
        persistent-keepalive 25
# → sendmsg(genl_sock, WG_CMD_SET_DEVICE, attrs)
#   → wg_set_device() → 피어 생성, AllowedIPs 트라이 구축

# IP 주소 할당 + 인터페이스 활성화
ip addr add 10.0.0.1/24 dev wg0
ip link set wg0 up
# → dev_open() → ndo_open() → wg_open()
#   → UDP 소켓 바인드 (listen-port)

# 라우팅 설정 (선택: 전체 트래픽 VPN 터널링)
ip route add default dev wg0 table 51820
ip rule add not fwmark 51820 table 51820
ip rule add table main suppress_prefixlength 0
# → fwmark로 WireGuard 자체 UDP 트래픽은 기본 경로 사용
#   나머지 트래픽은 wg0으로 라우팅

# 상태 확인 (Generic Netlink → WG_CMD_GET_DEVICE)
wg show wg0
# interface: wg0
#   public key: (base64)
#   private key: (hidden)
#   listening port: 51820
#
# peer: (base64)
#   endpoint: 203.0.113.1:51820
#   allowed ips: 10.0.0.0/24, fd00::/64
#   latest handshake: 23 seconds ago
#   transfer: 2.45 GiB received, 1.23 GiB sent
#   persistent keepalive: every 25 seconds

네트워크 네임스페이스와 WireGuard

/* WireGuard의 네임스페이스 분리 설계
 *
 * WireGuard 인터페이스는 두 개의 네임스페이스에 걸칠 수 있습니다:
 *
 *   ┌─── 내부 네임스페이스 (wg0이 속한 곳) ──┐
 *   │  애플리케이션 → wg0 → 암/복호화        │
 *   │  (VPN 터널 내부 트래픽)                 │
 *   └──────────────┬─────────────────────────┘
 *                  │ UDP 소켓
 *   ┌──────────────↓─────────────────────────┐
 *   │  외부 네임스페이스 (UDP 소켓이 바인드)   │
 *   │  eth0 → 인터넷 (암호화된 UDP 패킷)      │
 *   └────────────────────────────────────────┘
 *
 * → 컨테이너(내부 NS)에 wg0을 넣고,
 *   호스트(외부 NS)에서 실제 네트워크 통신
 * → 컨테이너는 평문 트래픽만 보고, 키 접근 불가
 */

/* drivers/net/wireguard/socket.c — 네임스페이스 분리 */
int wg_socket_init(struct wg_device *wg, u16 port)
{
    struct net *net;
    struct udp_tunnel_sock_cfg cfg = { ... };

    /* creating_net: wg 디바이스가 생성된 네임스페이스 (외부)
     * → UDP 소켓은 여기에 바인드
     * dev_net(wg->dev): wg0이 현재 속한 네임스페이스 (내부)
     * → 평문 패킷은 여기로 주입 */
    net = wg->creating_net;  /* 소켓은 생성 네임스페이스에서 */

    udp_sock_create(net, &cfg, &new4);
    setup_udp_tunnel_sock(net, new4, &cfg);
    rcu_assign_pointer(wg->sock4, new4->sk);
    return 0;
}

# 네임스페이스 활용 예: 컨테이너에 WireGuard 제공

# 1. 호스트 네임스페이스에서 WireGuard 생성
ip link add wg0 type wireguard
wg set wg0 private-key /etc/wireguard/key peer "..." endpoint ... allowed-ips 0.0.0.0/0

# 2. wg0을 컨테이너 네임스페이스로 이동
ip link set wg0 netns container_ns

# 3. 컨테이너 내에서 IP 할당
ip -n container_ns addr add 10.0.0.2/24 dev wg0
ip -n container_ns link set wg0 up
ip -n container_ns route add default dev wg0

# → UDP 소켓은 호스트 NS에서 동작 (eth0으로 통신)
# → 컨테이너는 wg0만 보이고, 비밀키에 접근 불가
# → 완전한 네트워크 격리 + VPN 터널링

성능 특성과 최적화

# WireGuard 성능 측정

# iperf3 벤치마크 (서버 측)
iperf3 -s -B 10.0.0.1

# iperf3 벤치마크 (클라이언트 측, wg0 경유)
iperf3 -c 10.0.0.1 -t 30 -P 4  # 4 parallel streams

# SIMD 가속 확인
dmesg | grep -i wireguard
# wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com
# wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld.
#            All Rights Reserved.

# 암호화 구현 확인 (SIMD 사용 여부)
grep -r "chacha20" /proc/crypto
# name         : chacha20
# driver       : chacha20-simd      ← SIMD 가속 활성

# CPU별 암호화 처리 분포 확인
perf top -g -p $(pgrep -f "wg-crypt")

# MTU 최적화 (WireGuard 오버헤드 고려)
# 이더넷 1500 - IPv4(20) - UDP(8) - WG헤더(32) - AuthTag(16) = 1424
ip link set wg0 mtu 1420  # 기본값 (약간의 여유 포함)

보안 속성 분석

디버깅과 모니터링

# WireGuard 상태 확인
wg show all
wg show wg0 dump  # 스크립트 파싱용 탭 구분 출력

# 커널 로그 (동적 디버깅 활성화)
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
dmesg -w | grep wireguard

# 인터페이스 통계
ip -s link show wg0
# RX: bytes packets errors dropped
# TX: bytes packets errors dropped

# Netlink 디버깅 (strace로 wg 유틸리티 추적)
strace -e trace=network wg show wg0 2>&1 | grep -E "sendmsg|recvmsg"

# 패킷 캡처 (외부 UDP 캡슐화된 패킷)
tcpdump -i eth0 udp port 51820 -nn
# → 암호화된 WireGuard 패킷만 보임 (평문 확인 불가)

# 내부 트래픽 캡처 (복호화된 평문)
tcpdump -i wg0 -nn
# → VPN 터널 내부의 평문 IP 패킷

# 핸드셰이크 모니터링
watch -n 1 'wg show wg0 latest-handshakes'

# perf로 CPU 프로파일링 (암호화 병목 확인)
perf record -g -p $(pgrep -f wg-crypt) -- sleep 10
perf report --sort=dso,symbol

# 트래픽 흐름 추적 (ftrace)
echo 1 > /sys/kernel/debug/tracing/events/net/netif_receive_skb/enable
echo 'dev == "wg0"' > /sys/kernel/debug/tracing/events/net/netif_receive_skb/filter
cat /sys/kernel/debug/tracing/trace_pipe

IPv4 심화

IPv4 헤더 구조와 커널 처리

/* include/uapi/linux/ip.h */
struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
    __u8    ihl:4,         /* Internet Header Length (단위: 4바이트) */
            version:4;    /* IP 버전 (항상 4) */
#elif defined(__BIG_ENDIAN_BITFIELD)
    __u8    version:4,
            ihl:4;
#endif
    __u8    tos;             /* Type of Service / DSCP + ECN */
    __be16  tot_len;         /* 패킷 전체 길이 (헤더 + 페이로드) */
    __be16  id;              /* 식별자 (단편화용) */
    __be16  frag_off;        /* 플래그(3bit) + Fragment Offset(13bit) */
    __u8    ttl;             /* Time To Live */
    __u8    protocol;        /* 상위 프로토콜 (6=TCP, 17=UDP, 132=SCTP) */
    __sum16 check;           /* 헤더 체크섬 */
    union {
        struct {
            __be32  saddr;   /* 소스 IP 주소 */
            __be32  daddr;   /* 목적지 IP 주소 */
        };
        __be32 addrs[2];
    };
    /* IP 옵션 (ihl > 5일 때, 최대 40바이트) */
};

IPv4 수신 경로 (ip_rcv)

/* net/ipv4/ip_input.c — IPv4 패킷 수신 진입점 */
int ip_rcv(struct sk_buff *skb, struct net_device *dev,
           struct packet_type *pt, struct net_device *orig_dev)
{
    struct iphdr *iph;

    /* 1. 기본 검증 */
    if (!pskb_may_pull(skb, sizeof(struct iphdr)))
        goto drop;

    iph = ip_hdr(skb);

    /* 2. 버전, IHL, 길이 검증 */
    if (iph->ihl < 5 || iph->version != 4)
        goto inhdr_error;
    if (ntohs(iph->tot_len) < (iph->ihl * 4))
        goto inhdr_error;

    /* 3. 헤더 체크섬 검증 */
    if (ip_fast_csum((u8 *)iph, iph->ihl))
        goto csum_error;

    /* 4. Netfilter PREROUTING 훅 */
    return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
                   dev_net(dev), NULL, skb, dev, NULL,
                   ip_rcv_finish);
    /* → ip_rcv_finish → 라우팅 결정 → ip_local_deliver 또는 ip_forward */
}

/* ip_rcv_finish → ip_route_input_noref → 라우팅 결정 */
/*   목적지가 로컬: ip_local_deliver → ip_local_deliver_finish */
/*   목적지가 외부: ip_forward → ip_forward_finish */
/*   브로드캐스트:  ip_local_deliver (+ 포워딩 가능) */
/*   멀티캐스트:    ip_mr_input (멀티캐스트 라우팅) */

IP 체크섬 (Checksum) 심화

IP 체크섬은 RFC 1071에 정의된 1의 보수(one's complement) 합 알고리즘을 사용합니다. IPv4 헤더의 무결성을 보장하는 핵심 메커니즘으로, 매 홉(hop)마다 TTL이 감소하므로 라우터는 체크섬을 매번 재계산해야 합니다.

체크섬 알고리즘 원리

IP 체크섬은 헤더를 16비트 워드 단위로 나누어 1의 보수 덧셈을 수행한 뒤, 결과의 1의 보수를 취합니다:

/*
 * RFC 1071 — Internet Checksum 알고리즘
 *
 * 1. 체크섬 필드를 0으로 설정
 * 2. 헤더를 16비트 워드 단위로 분할
 * 3. 모든 워드를 1의 보수 합산 (캐리 발생 시 하위에 더함)
 * 4. 최종 합의 1의 보수(비트 반전)가 체크섬 값
 *
 * 검증: 체크섬 포함하여 전체 합산 → 결과가 0xFFFF이면 유효
 */

/* 단순 구현 (이해용 — 실제 커널은 최적화 버전 사용) */
static __sum16 simple_ip_checksum(const void *data, int len)
{
    const __be16 *ptr = data;
    u32 sum = 0;
    int nwords = len / 2;

    while (nwords-- > 0)
        sum += *ptr++;

    /* 홀수 바이트 처리 (IP 헤더에서는 발생하지 않지만 범용 구현) */
    if (len & 1)
        sum += *(u8 *)ptr;

    /* 캐리 폴딩: 상위 16비트를 하위 16비트에 반복 합산 */
    while (sum >> 16)
        sum = (sum & 0xFFFF) + (sum >> 16);

    return (__sum16)~sum;
}

커널 체크섬 구현

리눅스 커널은 성능을 위해 아키텍처별 최적화된 체크섬 함수를 제공합니다:

/* arch/x86/include/asm/checksum.h — x86 최적화 */
static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
{
    unsigned int sum;

    asm(
        "  movl (%1), %0\n"          /* 첫 번째 32비트 워드 로드 */
        "  subl $4, %2\n"            /* ihl -= 4 (최소 5이므로 1부터 루프) */
        "  jbe 2f\n"
        "  addl 4(%1), %0\n"         /* 두 번째 워드 가산 */
        "  adcl 8(%1), %0\n"         /* ADC: 캐리 포함 가산 (1의 보수 합) */
        "  adcl 12(%1), %0\n"        /* 네 번째 워드 */
        "1: adcl 16(%1), %0\n"       /* 루프: IP 옵션 영역 */
        "  lea 4(%1), %1\n"
        "  decl %2\n"
        "  jne 1b\n"
        "  adcl $0, %0\n"            /* 마지막 캐리 추가 */
        "  movl %0, %2\n"
        "  shrl $16, %0\n"           /* 상위 16비트 */
        "  addw %w2, %w0\n"          /* 16비트 폴딩 */
        "  adcl $0, %0\n"
        "  notl %0\n"                 /* 비트 반전 (1의 보수) */
        "2:"
        : "=r"(sum), "=r"(iph), "=r"(ihl)
        : "1"(iph), "2"(ihl)
        : "memory"
    );
    return (__sum16)sum;
}

/*
 * ip_fast_csum 동작 요약:
 *   - 32비트 단위로 ADC(Add with Carry) 명령어 사용
 *   - 처음 4워드(20바이트 기본 헤더)는 언롤링으로 분기 없이 처리
 *   - IP 옵션이 있으면(ihl > 5) 루프로 추가 워드 처리
 *   - 최종 32비트 → 16비트 폴딩 + NOT
 *   - 반환값 0 = 체크섬 유효, 비-0 = 오류
 */

/* include/net/checksum.h — 범용 체크섬 유틸리티 */

/* 부분 체크섬 계산 (임의 길이 데이터) */
__wsum csum_partial(const void *buff, int len, __wsum wsum);
/*
 * 데이터 버퍼의 부분 체크섬을 계산하여 기존 wsum에 누적.
 * TCP/UDP 페이로드 체크섬 계산의 핵심 함수.
 * 아키텍처별 어셈블리 최적화 제공 (x86, ARM, MIPS 등).
 *
 * x86_64: ADCQ 명령어로 64비트 단위 처리 → 대용량 데이터에서 2배 빠름
 * ARM: LDMIA + ADC 조합으로 레지스터 파이프라인 최적화
 */

/* 32비트 합을 16비트 체크섬으로 최종 폴딩 */
static inline __sum16 csum_fold(__wsum csum)
{
    u32 sum = (__force u32)csum;
    sum = (sum & 0xFFFF) + (sum >> 16);  /* 첫 번째 폴딩 */
    sum = (sum & 0xFFFF) + (sum >> 16);  /* 두 번째 폴딩 (캐리 전파) */
    return (__sum16)~sum;
}

/* 체크섬 검증: 전체 합이 0이면 유효 */
static inline __sum16 csum_verify(__wsum csum)
{
    return csum_fold(csum);  /* 결과가 0이면 유효 */
}

증분 체크섬 갱신 (Incremental Update)

라우터가 패킷을 포워딩할 때 TTL을 감소시키면 체크섬도 갱신해야 합니다. RFC 1624에 따라 전체를 재계산하지 않고 변경된 필드만으로 증분 갱신하여 성능을 최적화합니다:

/* include/net/ip.h — TTL 감소 + 체크섬 증분 갱신 */
static inline int ip_decrease_ttl(struct iphdr *iph)
{
    u32 check = (__force u32)iph->check;
    check += (__force u32)htons(0x0100);
    /*
     * TTL은 8번째 바이트 (offset 8).
     * TTL이 1 감소하면 16비트 워드 관점에서 상위 바이트가 1 감소.
     * 1의 보수 합에서 필드 감소 = 체크섬에 해당 차이를 더함.
     * htons(0x0100) = 빅엔디안에서 TTL 바이트 위치의 +1.
     *
     * 1의 보수 산술: ~(C + (-m) + m') = ~C' (RFC 1624)
     *   C  = 기존 체크섬의 1의 보수
     *   m  = 변경 전 값
     *   m' = 변경 후 값
     *   C' = 새 체크섬의 1의 보수
     */
    iph->check = (__force __sum16)(check + (check >= 0xFFFF));
    /* check >= 0xFFFF: 캐리 발생 시 +1 (end-around carry) */
    return --iph->ttl;
}

/* net/core/utils.c — 범용 증분 체크섬 갱신 */
void inet_proto_csum_replace4(__sum16 *sum, struct sk_buff *skb,
                              __be32 from, __be32 to, bool pseudohdr)
{
    /*
     * NAT에서 IP 주소 변경 시 사용.
     * from: 변경 전 주소, to: 변경 후 주소
     * pseudohdr: true면 TCP/UDP 의사 헤더 체크섬도 갱신
     *
     * 내부적으로 csum_replace4() 호출:
     *   ~csum_partial(&to, 4, csum_partial(&from_complement, 4, ~old_csum))
     *
     * 핵심: 전체 패킷을 다시 순회하지 않고 O(1)에 체크섬 갱신
     */
    if (skb->ip_summed != CHECKSUM_PARTIAL) {
        *sum = csum_fold(
            csum_partial((u8 *)&to, 4,
                csum_partial((u8 *)&from, 4,
                    ~csum_unfold(*sum))));
    } else if (pseudohdr) {
        *sum = ~csum_fold(
            csum_partial((u8 *)&to, 4,
                csum_partial((u8 *)&from, 4,
                    csum_unfold(*sum))));
    }
}

/* 2바이트 필드 변경 (포트 번호 등) */
void inet_proto_csum_replace2(__sum16 *sum, struct sk_buff *skb,
                              __be16 from, __be16 to, bool pseudohdr);
/* NAT에서 포트 변환(NAPT) 시 TCP/UDP 체크섬 증분 갱신에 사용 */

TCP/UDP 의사 헤더 체크섬

TCP와 UDP는 IP 계층의 주소 정보를 체크섬에 포함하기 위해 의사 헤더(pseudo-header)를 사용합니다. 이 설계는 잘못된 호스트로 배달된 패킷을 상위 계층에서 탐지할 수 있게 합니다:

/*
 * TCP/UDP 의사 헤더 (RFC 793, RFC 768)
 *
 * +--------+--------+--------+--------+
 * |           Source Address           |  (4 bytes)
 * +--------+--------+--------+--------+
 * |        Destination Address         |  (4 bytes)
 * +--------+--------+--------+--------+
 * |  Zero  |Protocol|   TCP/UDP Len   |  (4 bytes)
 * +--------+--------+--------+--------+
 *
 * 실제 전송되지 않지만, 체크섬 계산에만 포함됨
 */

/* include/net/ip.h — 의사 헤더 체크섬 계산 */
static inline __wsum csum_tcpudp_nofold(
    __be32 saddr, __be32 daddr,
    __u32 len, __u8 proto, __wsum sum)
{
    /* x86 최적화 구현 (인라인 어셈블리) */
    asm(
        "  addl %1, %0\n"    /* sum += saddr */
        "  adcl %2, %0\n"    /* sum += daddr + carry */
        "  adcl %3, %0\n"    /* sum += (proto << 8) + len + carry */
        "  adcl $0, %0\n"    /* 마지막 캐리 추가 */
        : "=r"(sum)
        : "g"(daddr), "g"(saddr),
          "g"((u32)((u32)len + ((u32)proto << 8))),
          "0"(sum)
    );
    return sum;
}

/* 최종 TCP/UDP 체크섬 = csum_fold(의사 헤더 + 헤더 + 페이로드) */
static inline __sum16 csum_tcpudp_magic(
    __be32 saddr, __be32 daddr,
    __u32 len, __u8 proto, __wsum sum)
{
    return csum_fold(csum_tcpudp_nofold(saddr, daddr, len, proto, sum));
}

/* 전송 경로에서 TCP 체크섬 계산 예시 */
/* tcp_v4_send_check() → tcp_v4_check() */
static inline __sum16 tcp_v4_check(int len, __be32 saddr,
                                    __be32 daddr, __wsum base)
{
    return csum_tcpudp_magic(saddr, daddr, len, IPPROTO_TCP, base);
    /*
     * base = csum_partial(TCP 헤더 + 페이로드)
     * 의사 헤더(src_ip, dst_ip, 프로토콜, 길이) + 실제 데이터를
     * 하나의 1의 보수 합으로 통합
     *
     * HW offload 시 (CHECKSUM_PARTIAL):
     *   의사 헤더 체크섬만 미리 계산하여 TCP 헤더의 check 필드에 기록
     *   NIC가 나머지(TCP 헤더 + 페이로드) 합산을 HW로 처리
     */
}

하드웨어 체크섬 오프로드 상세

최신 NIC는 체크섬 계산을 하드웨어로 수행하여 CPU 부담을 크게 줄입니다. sk_buff의 ip_summed 필드와 관련 필드들이 이를 제어합니다:

/* sk_buff 체크섬 관련 필드 */
struct sk_buff {
    /* ... */
    __u8   ip_summed:2;       /* CHECKSUM_NONE/UNNECESSARY/COMPLETE/PARTIAL */
    union {
        __wsum csum;           /* 수신: HW가 계산한 raw 체크섬 (COMPLETE) */
        struct {
            __u16 csum_start;  /* 송신: 체크섬 계산 시작 오프셋 (skb->head 기준) */
            __u16 csum_offset; /* 송신: 체크섬 저장 위치 (csum_start 기준) */
        };
    };
    /* ... */
};

/* ======== 수신 경로 (RX) ======== */

/* 1) CHECKSUM_COMPLETE: NIC가 L4 전체 패킷 합을 계산하여 제공 */
/*    드라이버: skb->csum에 HW 체크섬 저장 */
/*    스택: skb_checksum_validate()에서 의사 헤더만 추가로 합산하여 검증 */
static inline bool __skb_checksum_validate_needed(
    struct sk_buff *skb, bool zero_okay, __wsum pseudohdr)
{
    if (skb->ip_summed == CHECKSUM_COMPLETE) {
        /* HW csum + 의사 헤더 합산 → 폴딩 → 0이면 유효 */
        if (!csum_fold(csum_add(skb->csum, pseudohdr)))
            return false;  /* 유효 → SW 재검증 불필요 */
    }
    return true;  /* SW 검증 필요 */
}

/* 2) CHECKSUM_UNNECESSARY: NIC가 체크섬 검증까지 완료 */
/*    가장 빠름. loopback, 일부 고급 NIC */

/* 3) CHECKSUM_NONE: HW 지원 없음 → SW 전체 검증 */

/* ======== 송신 경로 (TX) ======== */

/* CHECKSUM_PARTIAL: 프로토콜 스택이 의사 헤더 체크섬만 계산 */
/*   NIC가 csum_start부터 패킷 끝까지의 체크섬을 계산하여 */
/*   csum_start + csum_offset 위치에 기록 */
static inline void skb_set_transport_header_csum(
    struct sk_buff *skb, int offset)
{
    skb->ip_summed = CHECKSUM_PARTIAL;
    skb->csum_start = skb_headroom(skb) + offset;
    skb->csum_offset = offsetof(struct tcphdr, check);
    /* TCP: csum_offset = 16 (check 필드의 오프셋) */
    /* UDP: csum_offset = 6  (check 필드의 오프셋) */
}

/* NIC가 HW offload를 지원하지 않을 때의 SW fallback */
int skb_checksum_help(struct sk_buff *skb)
{
    /*
     * CHECKSUM_PARTIAL → CHECKSUM_NONE으로 변환
     * SW로 체크섬을 직접 계산하여 패킷에 기록
     *
     * 호출 시점:
     *   - NIC가 NETIF_F_HW_CSUM / NETIF_F_IP_CSUM 미지원
     *   - Netfilter가 패킷을 변조하여 HW offload 불가능
     *   - veth, bridge 등 가상 디바이스 경유
     */
    __wsum csum;
    int offset = skb->csum_start - skb_headroom(skb);

    csum = skb_checksum(skb, offset, skb->len - offset, 0);
    *(__sum16 *)(skb->data + offset + skb->csum_offset) = csum_fold(csum);
    skb->ip_summed = CHECKSUM_NONE;
    return 0;
}

NIC 체크섬 피처 플래그

# 현재 NIC의 체크섬 오프로드 상태 확인
ethtool -k eth0 | grep checksum
# rx-checksumming: on
# tx-checksumming: on
#   tx-checksum-ipv4: on
#   tx-checksum-ipv6: on
#   tx-checksum-ip-generic: off [not requested]

# 개별 제어
ethtool -K eth0 rx off          # 수신 체크섬 오프로드 비활성화
ethtool -K eth0 tx-checksum-ipv4 off  # 송신 IPv4 체크섬 오프로드 비활성화

IPv4 vs IPv6 체크섬 차이

/* include/net/ip6_checksum.h — IPv6 의사 헤더 체크섬 */
__sum16 csum_ipv6_magic(
    const struct in6_addr *saddr,   /* 128비트 소스 주소 */
    const struct in6_addr *daddr,   /* 128비트 목적지 주소 */
    __u32 len,                       /* Upper-Layer Packet Length */
    __u8  proto,                      /* Next Header (6=TCP, 17=UDP) */
    __wsum csum                       /* 기존 부분 합 */
);
/*
 * IPv6 의사 헤더 (RFC 8200, Section 8.1):
 *   Source Address (16) + Dest Address (16) +
 *   Upper-Layer Packet Length (4) + zero (3) + Next Header (1)
 * = 40바이트
 *
 * IPv4보다 의사 헤더가 크므로 csum 연산이 조금 더 비싸지만,
 * IP 헤더 체크섬 자체가 없어 라우터 포워딩은 더 빠름
 */

IP 단편화와 재조합

IPv4 패킷이 MTU를 초과하면 단편화(fragmentation)가 발생합니다. 커널은 수신 시 ip_defrag()로 단편을 재조합합니다:

/* frag_off 필드 해석 */
#define IP_DF       0x4000   /* Don't Fragment 플래그 */
#define IP_MF       0x2000   /* More Fragments 플래그 */
#define IP_OFFSET   0x1FFF   /* Fragment Offset 마스크 (단위: 8바이트) */

/* 단편화 여부 확인 */
if (iph->frag_off & htons(IP_MF | IP_OFFSET))
    /* 이 패킷은 단편이다 → 재조합 필요 */
    return ip_defrag(net, skb, IP_DEFRAG_LOCAL_DELIVER);

/* net/ipv4/ip_fragment.c — 재조합 핵심 */
/* ip_defrag()는 해시 테이블(inet_frag_queue)에 단편을 수집
 *   키: (src_ip, dst_ip, id, protocol)
 *   모든 단편 도착 시 → ip_frag_reasm()으로 하나의 skb로 합침
 *
 * 타임아웃: ipfrag_time (기본 30초)
 *   → 시간 내 모든 단편 미도착 시 재조합 포기, skb 해제
 *
 * 메모리 제한: ipfrag_high_thresh / ipfrag_low_thresh
 *   → 재조합 대기 메모리가 high_thresh 초과 시 오래된 큐 강제 해제
 */

Path MTU Discovery (PMTUD) 심화

Path MTU Discovery는 송신자와 수신자 사이 경로에서 단편화 없이 전송 가능한 최대 패킷 크기를 동적으로 탐지하는 메커니즘입니다. IPv4에서는 RFC 1191, IPv6에서는 RFC 8201로 정의되며, 리눅스 커널은 기본적으로 PMTUD를 활성화합니다.

PMTUD 동작 원리

PMTUD의 핵심은 IP 헤더의 DF(Don't Fragment) 비트와 ICMP 메시지의 상호작용입니다:

커널 PMTUD 구현

리눅스 커널의 PMTUD는 라우팅 서브시스템과 전송 계층이 긴밀하게 협력하여 동작합니다. PMTU 값은 dst_entry 경로 정보에 저장되며, fib_nh_exception 구조체를 통해 per-destination으로 관리됩니다.

/* include/net/dst.h — 경로의 PMTU 조회 */
static inline u32 dst_mtu(const struct dst_entry *dst)
{
    /* dst_ops에 정의된 mtu 콜백 호출
     * IPv4: ipv4_mtu() → PMTU 캐시 또는 인터페이스 MTU 반환
     * IPv6: ip6_mtu() → PMTU 캐시 또는 인터페이스 MTU 반환 */
    return dst->ops->mtu(dst);
}

/* net/ipv4/route.c — IPv4 PMTU 조회 */
static unsigned int ipv4_mtu(const struct dst_entry *dst)
{
    unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
    struct net *net = dev_net(dst->dev);

    if (mtu)
        return mtu;            /* 명시적으로 설정된 route MTU */

    mtu = READ_ONCE(dst->dev->mtu);  /* 인터페이스 MTU */

    if (unlikely(ip_mtu_locked(dst)))
        return mtu;            /* 관리자가 lock한 MTU (변경 불가) */

    /* fib_nh_exception에 캐싱된 PMTU가 있으면 그 값 사용 */
    if (mtu > IPV4_MIN_MTU)   /* 68바이트 (RFC 791 최소) */
        return mtu;

    return IPV4_MIN_MTU;
}

ICMP "Fragmentation Needed" 수신 처리

ICMP Type 3, Code 4 메시지를 수신하면 커널은 해당 목적지에 대한 PMTU를 갱신합니다:

/* net/ipv4/route.c — PMTU 갱신 핵심 함수 */
static void __ip_rt_update_pmtu(struct rtable *rt,
                                struct flowi4 *fl4, u32 mtu)
{
    struct dst_entry *dst = &rt->dst;
    struct net *net = dev_net(dst->dev);
    struct fib_result res;
    bool lock = false;

    /* RFC 1191: PMTU는 최소 68바이트 (IPv4 최소 MTU) */
    if (mtu < IPV4_MIN_MTU) {
        lock = true;
        mtu = IPV4_MIN_MTU;
    }

    /* ip_no_pmtu_disc 설정 시 PMTUD 무시 */
    if (mtu < ip_rt_min_pmtu(net))
        mtu = ip_rt_min_pmtu(net);

    /* FIB nexthop exception에 PMTU 캐싱 */
    rcu_read_lock();
    if (fib_lookup(net, fl4, &res, 0) == 0) {
        struct fib_nh_common *nhc = FIB_RES_NHC(res);
        update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock,
                              jiffies + ip_rt_mtu_expires(net));
    }
    rcu_read_unlock();
}

/* net/ipv4/icmp.c — ICMP "Fragmentation Needed" 수신 경로 */
/*
 * icmp_rcv()
 *   → icmp_unreach()             (Type 3 처리)
 *     → icmp_unreach_handler()
 *       → ICMP_MIB_INMSGS++
 *       → 내부 IP 헤더에서 원본 (src, dst, proto) 추출
 *       → 상위 프로토콜의 err_handler 호출:
 *         TCP: tcp_v4_err() → tcp_v4_mtu_reduced()
 *         UDP: udp_err()   → ip_icmp_error()
 *         → ip_rt_update_pmtu() 호출하여 라우팅 캐시 갱신
 */

TCP와 PMTUD 연동

TCP는 PMTU 변경에 가장 적극적으로 대응하는 프로토콜입니다. ICMP 에러 수신 시 MSS를 조정하고 필요하면 세그먼트를 재전송합니다:

/* net/ipv4/tcp_ipv4.c — PMTU 감소 시 TCP 처리 */
static void tcp_v4_mtu_reduced(struct sock *sk)
{
    struct inet_sock *inet = inet_sk(sk);
    struct dst_entry *dst;
    u32 mtu;

    /* LISTEN 상태에서는 무시 */
    if ((1 << sk->sk_state) & (TCPF_LISTEN | TCPF_CLOSE))
        return;

    dst = inet_csk_update_pmtu(sk, tcp_sk(sk)->mtu_info);
    if (!dst)
        return;

    mtu = dst_mtu(dst);

    /* 새 PMTU에 맞춰 MSS 재계산 */
    if (inet_csk(sk)->icsk_pmtu_cookie > mtu) {
        /* TCP MSS = PMTU - IP 헤더(20) - TCP 헤더(20+옵션)
         * 예: PMTU=1400 → MSS = 1400 - 20 - 32 = 1348 */
        tcp_sync_mss(sk, mtu);

        /* 이미 전송된 세그먼트가 새 PMTU 초과 시
         * 재전송 큐의 세그먼트를 분할하여 재전송 */
        tcp_simple_retransmit(sk);
    }
}

/* TCP MSS 클램핑 관련 sysctl */
/* net.ipv4.tcp_mtu_probing:
 *   0 = 비활성 (기본)
 *   1 = PMTUD 블랙홀 감지 시에만 probing 활성화
 *   2 = 항상 probing 활성화
 *
 * net.ipv4.tcp_base_mss:
 *   MTU probing 시작 MSS (기본: 1024)
 *   → PMTUD 블랙홀 감지 시 이 값부터 시작하여 점진적으로 증가
 *
 * net.ipv4.tcp_mtu_probe_floor:
 *   probing 최소 MSS (기본: 48)
 */

PMTUD 블랙홀 문제

PMTUD의 가장 심각한 문제는 블랙홀(Black Hole)입니다. 중간 경로의 방화벽이나 라우터가 ICMP "Fragmentation Needed" 메시지를 차단하면, 송신자는 PMTU를 알 수 없어 큰 패킷이 사라지는 현상이 발생합니다:

# PMTUD 블랙홀 증상 진단
# 1. 작은 패킷(ping)은 정상, 큰 패킷(SSH, HTTP)이 멈춤
ping -c 3 -M do -s 1472 목적지     # DF=1, 1500B (20+8+1472) → 통과 확인
ping -c 3 -M do -s 1400 목적지     # 점진적으로 줄여 병목 MTU 탐지

# 2. tracepath로 PMTU 탐색 (ICMP 기반)
tracepath -n 목적지
# 출력 예:
#  1?: [LOCALHOST]      pmtu 1500
#  1:  192.168.1.1      0.345ms
#  2:  10.0.0.1         1.234ms pmtu 1400    ← 여기서 MTU 감소
#  3:  172.16.0.1       2.567ms reached
#      Resume: pmtu 1400

# 3. 커널 PMTU 캐시 확인
ip route get 목적지
# 출력 예:
# 목적지 via 192.168.1.1 dev eth0 src 192.168.1.100
#     cache expires 542sec mtu 1400

# 4. PMTU 캐시 강제 삭제 (재탐색 유도)
ip route flush cache

블랙홀 해결 방법

TCP MTU Probing (PLPMTUD) 상세

RFC 4821/8899에 정의된 Packetization Layer PMTUD (PLPMTUD)는 ICMP에 의존하지 않고 전송 계층에서 직접 적정 패킷 크기를 탐색합니다. 리눅스의 tcp_mtu_probing이 이 메커니즘을 구현합니다:

/* net/ipv4/tcp_timer.c — TCP MTU Probing 구현 */
static void tcp_mtup_probe(struct sock *sk)
{
    struct tcp_sock *tp = tcp_sk(sk);
    struct inet_connection_sock *icsk = inet_csk(sk);
    struct sk_buff *skb;
    int probe_size;

    /* 이진 탐색으로 최적 MSS 탐색
     * search_low  = 현재 동작하는 MSS (확인된 하한)
     * search_high = 시도할 MSS 상한
     * probe_size  = (search_low + search_high) / 2 */
    probe_size = (icsk->icsk_mtup.search_low +
                  icsk->icsk_mtup.search_high) / 2;

    /* probe 패킷 전송:
     * - 일반 데이터를 probe_size 크기로 전송
     * - ACK 수신 → search_low = probe_size (성공, 상향 탐색)
     * - RTO 타임아웃 → search_high = probe_size (실패, 하향 탐색)
     * - search_high - search_low < 8 이면 탐색 종료 */
}

/* tcp_mtu_probing 동작 모드:
 *
 * 모드 0 (기본): MTU probing 비활성. 전통적 PMTUD만 사용.
 *
 * 모드 1 (블랙홀 감지):
 *   - 정상 시에는 전통적 PMTUD 사용
 *   - TCP 재전송 타임아웃(RTO) 반복 시 블랙홀로 판단
 *   - 블랙홀 감지 → tcp_base_mss부터 이진 탐색 시작
 *   - 장점: 오버헤드 최소, 블랙홀 자동 복구
 *
 * 모드 2 (항상 활성):
 *   - 연결 시작부터 MTU probing 수행
 *   - ICMP가 전혀 동작하지 않는 환경에 적합
 *   - 오버헤드가 있으므로 일반적으로 모드 1 권장
 */

IPv6 Path MTU Discovery

IPv6는 중간 라우터의 단편화를 금지하므로 PMTUD가 더욱 중요합니다. 최소 MTU는 1280바이트이며, ICMPv6 "Packet Too Big" (Type 2)를 사용합니다:

/* net/ipv6/route.c — IPv6 PMTU 갱신 */
static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
                               struct sk_buff *skb, u32 mtu,
                               bool confirm_neigh)
{
    struct rt6_info *rt6 = (struct rt6_info *)dst;

    /* IPv6 최소 MTU = 1280 (RFC 8200) */
    if (mtu < IPV6_MIN_MTU)
        mtu = IPV6_MIN_MTU;

    /* rt6_exception에 PMTU 캐싱 (IPv4의 fib_nh_exception과 유사) */
    rt6_do_update_pmtu(rt6, mtu);
    rt6_update_exception_stamp_rt(rt6);
}

/* IPv4 vs IPv6 PMTUD 차이점:
 *
 * 항목               IPv4 (RFC 1191)          IPv6 (RFC 8201)
 * ─────────────────────────────────────────────────────────────
 * ICMP 메시지        Type 3 Code 4            ICMPv6 Type 2
 *                    "Frag Needed"            "Packet Too Big"
 * 최소 MTU           68 바이트               1280 바이트
 * 중간 라우터 단편화  허용 (DF=0일 때)        금지 (항상)
 * 송신측 단편화       선택적                   Fragment Extension Header 사용
 * DF 비트            명시적 설정 필요          암묵적 (항상 DF=1 동작)
 * PMTU 만료          ip_rt_mtu_expires        rt6_mtu_expires
 * 최소 PMTU sysctl   ip_rt_min_pmtu          (없음, 항상 1280)
 */

PMTUD 관련 sysctl 매개변수 종합

터널과 PMTUD

VPN, GRE, VXLAN 등 터널 환경에서는 캡슐화 오버헤드로 인해 PMTUD가 특히 중요합니다:

# 터널별 일반적인 오버헤드와 권장 내부 MTU (외부 MTU=1500 기준)
#
# 터널 유형         오버헤드          내부 MTU   비고
# ──────────────────────────────────────────────────────────────
# GRE               24B (IP+GRE)      1476      키/시퀀스 시 +4~8B
# GRE + IPsec ESP   ≈80~120B          ≈1380     암호화 알고리즘에 따라 변동
# VXLAN             50B (UDP+VXLAN)   1450      Jumbo Frame 사용 시 완화
# WireGuard         60B (UDP+WG)      1420      IPv6 외부: 1400
# IPsec ESP(전송)   36~73B            ≈1430     암호화 + 인증
# IPsec ESP(터널)   56~93B            ≈1400     + 외부 IP 헤더 20B
# GENEVE            50~258B           ≈1450     가변 옵션 길이
# IP-in-IP (IPIP)   20B               1480      최소 오버헤드

# 터널 PMTUD 설정 예시
ip tunnel add gre1 mode gre remote 10.0.0.2 local 10.0.0.1 \
    pmtudisc                         # DF 비트 설정 (PMTUD 활성, 기본값)

ip link set gre1 mtu 1476            # 내부 MTU 수동 설정

# 터널 인터페이스에 MSS clamping 적용
iptables -t mangle -A FORWARD -o gre1 -p tcp \
    --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# 커널 내부: 터널 xmit 시 PMTU 처리
# ip_tunnel_xmit() → 내부 패킷 크기 > 터널 PMTU?
#   → DF=1인 내부 패킷: 원래 송신자에게 ICMP "Frag Needed" 전송
#   → DF=0인 내부 패킷: 내부 패킷을 단편화 후 각각 캡슐화

PMTUD 디버깅

# 1. 현재 경로의 PMTU 확인
ip route get 203.0.113.50
# 203.0.113.50 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 0
#     cache expires 542sec mtu 1400   ← PMTU가 캐싱됨

# 2. 모든 PMTU 예외 확인 (fib_nh_exception)
ip route show cache
# 203.0.113.50 via 192.168.1.1 dev eth0
#     cache expires 542sec mtu 1400
# 198.51.100.25 via 192.168.1.1 dev eth0
#     cache expires 310sec mtu 1380

# 3. ICMP "Fragmentation Needed" 수신 모니터링
tcpdump -i eth0 'icmp[icmptype] == 3 and icmp[icmpcode] == 4' -nn -v
# → IP 10.0.0.1 > 192.168.1.100: ICMP 203.0.113.50 unreachable -
#   need to frag (mtu 1400), length 556

# 4. ICMPv6 "Packet Too Big" 모니터링
tcpdump -i eth0 'icmp6 and ip6[40] == 2' -nn -v

# 5. nstat으로 PMTU 관련 통계 확인
nstat -az | grep -i -E 'Pmtu|Frag|Mtu'
# IpFragOKs          0     # 성공적으로 단편화한 패킷 수
# IpFragFails        5     # DF=1로 단편화 실패 (ICMP 전송됨)
# IpFragCreates      0     # 생성된 단편 수
# IpReasmReqds       12    # 재조합 요청 수
# IpReasmOKs         12    # 재조합 성공 수
# IpReasmFails       0     # 재조합 실패 수

# 6. ftrace로 PMTU 갱신 추적
echo 1 > /sys/kernel/debug/tracing/events/fib/fib_table_lookup/enable
echo 'nexthop_exceptions != 0' > /sys/kernel/debug/tracing/events/fib/fib_table_lookup/filter
cat /sys/kernel/debug/tracing/trace_pipe

# 7. 수동 PMTU 테스트 (이진 탐색)
# MTU 1500에서 시작하여 DF 비트로 테스트
for size in 1472 1400 1300 1200; do
    ping -c 1 -M do -s $size -W 2 목적지 &> /dev/null \
        && echo "MTU >= $((size + 28)): OK" \
        || echo "MTU <  $((size + 28)): FAIL"
done

IPv4 전송 경로

/* net/ipv4/ip_output.c — IPv4 전송 */
int ip_queue_xmit(struct sock *sk, struct sk_buff *skb, struct flowi *fl)
{
    /* 1. 라우팅 조회 (캐시된 dst 또는 새로 lookup) */
    rt = ip_route_output_flow(net, fl4, sk);

    /* 2. IP 헤더 구성 */
    iph = ip_hdr(skb);
    iph->version  = 4;
    iph->ihl      = 5;
    iph->tos      = inet->tos;           /* IP_TOS 소켓 옵션 */
    iph->tot_len  = htons(skb->len);
    iph->id       = ip_select_ident(...); /* per-destination 카운터 */
    iph->frag_off = htons(IP_DF);        /* PMTUD 활성 시 DF 설정 */
    iph->ttl      = ip_select_ttl(inet, &rt->dst);
    iph->protocol = sk->sk_protocol;
    iph->saddr    = fl4->saddr;
    iph->daddr    = fl4->daddr;

    /* 3. Netfilter LOCAL_OUT 훅 → ip_output */
    return NF_HOOK(NFPROTO_IPV4, NF_INET_LOCAL_OUT,
                   net, sk, skb, NULL, rt->dst.dev,
                   dst_output);
}

/* ip_output → ip_finish_output → ip_fragment (필요 시) → dev_queue_xmit */
/* ip_fragment: skb->len > mtu && DF 미설정 시 단편화 수행
 *   → ICMP "Fragmentation Needed" (DF 설정 시) 또는 실제 단편화
 *   → GSO skb는 skb_gso_segment()으로 분할 후 각각 전송
 */

IP 옵션 처리

IPv6 심화

IPv6 헤더 구조

IPv6 헤더는 고정 40바이트로 IPv4보다 단순하지만, 확장 헤더 체인으로 유연성을 제공합니다:

/* include/uapi/linux/ipv6.h */
struct ipv6hdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
    __u8    priority:4,      /* Traffic Class 상위 4비트 */
            version:4;       /* IP 버전 (항상 6) */
#elif defined(__BIG_ENDIAN_BITFIELD)
    __u8    version:4,
            priority:4;
#endif
    __u8    flow_lbl[3];     /* Traffic Class 하위 4비트 + Flow Label 20비트 */
    __be16  payload_len;     /* 페이로드 길이 (확장 헤더 포함, 기본 헤더 제외) */
    __u8    nexthdr;         /* 다음 헤더 타입 (6=TCP, 17=UDP, 43=Routing 등) */
    __u8    hop_limit;       /* IPv4의 TTL에 해당 */
    struct in6_addr saddr;   /* 소스 주소 (128비트) */
    struct in6_addr daddr;   /* 목적지 주소 (128비트) */
};
/* 크기: 정확히 40바이트 (IPv4와 달리 가변 길이 아님) */

/* 커널에서 IPv6 헤더 접근 */
struct ipv6hdr *hdr = ipv6_hdr(skb);
pr_info("src=%pI6c dst=%pI6c nexthdr=%u\n",
        &hdr->saddr, &hdr->daddr, hdr->nexthdr);

확장 헤더 체인

IPv6는 옵션을 확장 헤더로 체인 연결합니다. nexthdr 필드가 다음 헤더 타입을 지정합니다:

/* 확장 헤더 순회: 커널 내부 패턴 */
int ipv6_find_tlv(struct sk_buff *skb, int offset, int type)
{
    /* nexthdr 체인을 따라가며 특정 TLV 옵션 검색 */
    /* 각 확장 헤더: nexthdr(1) + hdrlen(1) + data(가변) */
    /* hdrlen 단위: 8바이트 (실제 길이 = (hdrlen+1)*8) */
}

/* ipv6_skip_exthdr: 확장 헤더를 건너뛰고 실제 상위 프로토콜 위치 찾기 */
int nexthdr = ipv6_hdr(skb)->nexthdr;
int offset = sizeof(struct ipv6hdr);
__be16 frag_off;
offset = ipv6_skip_exthdr(skb, offset, &nexthdr, &frag_off);
/* 반환: nexthdr = 실제 프로토콜 (TCP/UDP 등), offset = 페이로드 시작 위치 */

/* Fragment 헤더 구조 */
struct frag_hdr {
    __u8    nexthdr;          /* 단편화된 원본의 상위 프로토콜 */
    __u8    reserved;
    __be16  frag_off;         /* Offset(13bit) + Res(2bit) + MF(1bit) */
    __be32  identification;   /* 단편 식별자 (per-destination) */
};

NDP (Neighbor Discovery Protocol)

IPv6에서 ARP를 대체하는 NDP는 ICMPv6 기반으로 주소 해석, 라우터 발견, 주소 자동 설정을 수행합니다:

/* net/ipv6/ndisc.c — NDP 핵심 */
/* Neighbor Solicitation 수신 처리 */
static void ndisc_recv_ns(struct sk_buff *skb)
{
    struct nd_msg *msg = (struct nd_msg *)skb_transport_header(skb);
    struct in6_addr *target = &msg->target;

    /* DAD (Duplicate Address Detection) 확인 */
    if (ipv6_addr_any(&ipv6_hdr(skb)->saddr)) {
        /* 소스 = :: → DAD 요청 (주소 중복 검사) */
        /* 같은 주소를 가진 인터페이스가 있으면 DAD 실패 */
    }

    /* 타겟 주소가 로컬이면 NA(Neighbor Advertisement) 응답 */
    if (ipv6_chk_addr(net, target, dev, 0))
        ndisc_send_na(dev, &saddr, target, ...);
}

/* SLAAC (Stateless Address AutoConfiguration) */
/* RA에서 prefix 정보를 받아 자동으로 IPv6 주소 생성:
 *   주소 = prefix (64bit) + interface ID (64bit, EUI-64 또는 랜덤)
 *   net.ipv6.conf.*.use_tempaddr = 2 → RFC 4941 Privacy Extension
 *     → 임시 주소 자동 생성 (기본 24시간 유효)
 */

Flow Label과 ECMP

/* Flow Label: 20비트 (IPv6 헤더 내) */
/* 동일 flow의 패킷을 동일 경로로 라우팅 (ECMP 해시 입력) */

/* 커널 자동 설정: net.ipv6.flowlabel_state_ranges */
/* TCP: 연결별 고유 flow label 자동 할당 (auto_flowlabels) */
/* sysctl: net.ipv6.auto_flowlabels = 1 (기본 활성) */

/* 소켓에서 flow label 명시적 설정 */
struct in6_flowlabel_req freq = {
    .flr_label  = htonl(0x12345),
    .flr_action = IPV6_FL_A_GET,
    .flr_share  = IPV6_FL_S_EXCL,
};
setsockopt(fd, SOL_IPV6, IPV6_FLOWLABEL_MGR, &freq, sizeof(freq));

/* ECMP에서의 활용:
 * 라우터가 5-tuple 대신 (src, dst, flow_label)로 해시
 * → UDP 멀티플렉싱 환경에서도 안정적 경로 고정
 * → 특히 QUIC처럼 하나의 UDP 포트에 다수 연결 시 효과적
 */

커널 듀얼 스택 구현

/* IPv4-mapped IPv6 주소: ::ffff:a.b.c.d */
/* 듀얼 스택 소켓이 IPv4 패킷을 수신하면:
 *   커널이 IPv4 주소를 mapped 형태로 변환하여 IPv6 소켓에 전달
 *   → 애플리케이션은 하나의 IPv6 소켓으로 양쪽 모두 처리 가능
 *
 * IPV6_V6ONLY 소켓 옵션:
 *   setsockopt(fd, SOL_IPV6, IPV6_V6ONLY, &on, sizeof(on));
 *   → IPv6 전용으로 제한 (mapped address 거부)
 */

/* 커널 내부: IPv4/IPv6 프로토콜 핸들러 등록 */
static struct inet_protosw tcpv6_protosw = {
    .type       = SOCK_STREAM,
    .protocol   = IPPROTO_TCP,
    .prot       = &tcpv6_prot,          /* IPv6 TCP 핸들러 */
    .ops        = &inet6_stream_ops,
};
/* tcp_v6_rcv()에서 IPv4-mapped 주소 패킷도 처리:
 *   ipv6_addr_v4mapped(&hdr->daddr) → tcp_v4_rcv()로 fallback
 */

TCP 심화 — 커널 내부 메커니즘

3-Way Handshake와 커널 구조체

/* TCP 연결 수립 과정의 커널 내부 */

/* 1단계: 클라이언트 SYN 전송 */
/*   tcp_v4_connect() → tcp_connect() → tcp_transmit_skb()
 *   → TCP_SYN_SENT 상태 전이
 *   skb에 SYN 플래그 + 초기 시퀀스 번호(ISN) + MSS/Window Scale 옵션 설정
 *   ISN: secure_tcp_seq() → siphash 기반 (예측 불가)
 */

/* 2단계: 서버 SYN+ACK 수신 */
/*   tcp_v4_rcv() → tcp_v4_do_rcv() → tcp_rcv_state_process()
 *   LISTEN 소켓에서 수신 → request_sock (미니 소켓) 생성
 *   → inet_csk_reqsk_queue_hash_add()로 SYN 큐에 추가
 *   → SYN+ACK 응답 전송
 */

/* 3단계: 클라이언트 ACK 수신 */
/*   서버: tcp_check_req() → 전체 struct sock 생성
 *   → inet_csk_complete_hashdance()로 accept 큐에 이동
 *   → TCP_ESTABLISHED 상태
 */

/* Listen 소켓의 큐 구조:
 *   SYN 큐 (반개방 연결):  request_sock으로 관리
 *     → 크기: /proc/sys/net/ipv4/tcp_max_syn_backlog
 *   Accept 큐 (완전 연결):  listen() backlog 인자로 제한
 *     → 크기: min(backlog, /proc/sys/net/core/somaxconn)
 */

SYN Cookie 메커니즘

SYN Flood 공격 시 SYN 큐가 가득 차면 SYN Cookie가 발동합니다. 서버 상태를 저장하지 않고 SYN+ACK의 시퀀스 번호에 연결 정보를 인코딩합니다:

/* net/ipv4/syncookies.c */
/* SYN Cookie ISN 생성: */
/* ISN = hash(saddr, daddr, sport, dport, count) + (count << 24)
 *        + (MSS 인덱스 << 접근자)
 *
 * 인코딩 정보:
 *   - 타임스탬프 (분 단위 카운터, 상위 비트)
 *   - MSS 값 (8개 고정 값 중 하나로 양자화)
 *   - 상대방 IP/포트 해시
 *
 * ACK 수신 시: ISN 검증 → request_sock 없이 직접 sock 생성
 */

/* 제약사항:
 *   - Window Scale, SACK, Timestamp 옵션 정보 손실
 *     → TCP 성능 저하 가능 (큰 윈도우, SACK 불가)
 *   - 커널 4.4+: TCP_SAVED_SYN으로 일부 완화
 *   - tcp_syncookies = 1: SYN 큐 overflow 시에만 활성화 (권장)
 *   - tcp_syncookies = 2: 항상 활성화 (성능 저하 감수)
 */

/* sysctl 설정 */
/* net.ipv4.tcp_syncookies = 1   (기본: overflow 시 활성화) */
/* net.ipv4.tcp_max_syn_backlog = 4096 (SYN 큐 크기) */
/* net.core.somaxconn = 4096 (accept 큐 크기) */

Window Scaling과 수신 윈도우

/* TCP 윈도우: 16비트 필드 → 최대 65535바이트 */
/* Window Scale 옵션 (RFC 7323): 3-way handshake 시 협상 */
/* 실제 윈도우 = header의 window × 2^(scale factor) */
/* 최대 scale factor = 14 → 최대 윈도우 = 65535 × 16384 ≈ 1GB */

/* net/ipv4/tcp_output.c */
static u16 tcp_select_window(struct sock *sk)
{
    struct tcp_sock *tp = tcp_sk(sk);

    /* 가용 수신 버퍼 크기를 윈도우로 광고 */
    u32 cur_win = tcp_receive_window(tp);

    /* 윈도우 축소 방지 (RFC 규칙) */
    if (new_win < cur_win)
        new_win = cur_win;

    /* Window Scale 적용 */
    return new_win >> tp->rx_opt.rcv_wscale;
}

/* 커널 자동 튜닝 (tcp_rmem) */
/* net.ipv4.tcp_rmem = 4096  131072  6291456
 *                     min   default  max
 *   커널이 RTT와 BDP(Bandwidth-Delay Product)에 따라
 *   수신 버퍼를 default~max 범위에서 자동 조절
 *   → tcp_moderate_rcvbuf=1 (기본) 일 때 활성화
 */

SACK (Selective Acknowledgment)

/* SACK: 수신자가 비연속적으로 받은 블록을 명시적으로 알림 */
/* → 송신자가 손실된 세그먼트만 정확히 재전송 가능 */

/* TCP 헤더 옵션으로 SACK 블록 전달 (최대 4블록) */
/* [Kind=5] [Length] [Left Edge 1][Right Edge 1] [Left Edge 2][Right Edge 2] ... */

/* net/ipv4/tcp_input.c */
static int tcp_sacktag_write_queue(struct sock *sk,
    const struct sk_buff *ack_skb, u32 prior_snd_una, ...)
{
    /* SACK 블록을 파싱하여 재전송 큐의 skb에 마킹 */
    /* TCPCB_SACKED_ACKED:  상대가 수신 확인한 블록 */
    /* TCPCB_SACKED_RETRANS: 재전송된 블록 */
    /* TCPCB_LOST:           손실로 판단된 블록 → 재전송 대상 */
}

/* SACK 관련 sysctl */
/* net.ipv4.tcp_sack = 1          (기본 활성화) */
/* net.ipv4.tcp_dsack = 1         (D-SACK: 중복 수신 알림) */
/* net.ipv4.tcp_fack = 0          (FACK: 6.x에서 제거됨) */

/* SACK 없이 3-duplicate ACK만 사용하면:
 *   연속 손실 시 하나씩 재전송 → 복구 느림
 * SACK 활성화 시:
 *   손실된 세그먼트를 한 RTT 내에 모두 재전송 가능
 */

TCP Keepalive

/* TCP Keepalive: 유휴 연결의 생존 여부 확인 */
/* net/ipv4/tcp_timer.c */

/* keepalive 타이머 동작:
 *   1. 마지막 데이터 이후 tcp_keepalive_time 경과 → 첫 probe 전송
 *   2. 응답 없으면 tcp_keepalive_intvl 간격으로 반복
 *   3. tcp_keepalive_probes 회 응답 없으면 연결 종료 (RST)
 */

/* sysctl 기본값 */
/* net.ipv4.tcp_keepalive_time  = 7200  (2시간 유휴 후 시작) */
/* net.ipv4.tcp_keepalive_intvl = 75    (75초 간격 probe) */
/* net.ipv4.tcp_keepalive_probes = 9    (9회 실패 시 종료) */
/* → 총 ~2시간 11분 후 연결 종료 */

/* 소켓별 설정 (sysctl 기본값 오버라이드) */
int optval = 1;
setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &optval, sizeof(optval));

int idle = 60;    /* 60초 유휴 후 시작 */
setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &idle, sizeof(idle));

int interval = 10; /* 10초 간격 */
setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &interval, sizeof(interval));

int maxpkt = 3;   /* 3회 실패 시 종료 */
setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &maxpkt, sizeof(maxpkt));

TCP Fast Open (TFO)

/* TCP Fast Open: SYN 패킷에 데이터를 포함하여 1-RTT 절감 */
/* RFC 7413, 커널 3.7+ */

/* 동작 원리:
 *   1. 최초 연결: 일반 3-way handshake + 서버가 TFO 쿠키 발급
 *   2. 이후 연결: SYN + 쿠키 + 데이터 → 서버 즉시 응답 가능
 *   → HTTP 요청/응답에서 1-RTT 절감
 */

/* sysctl 설정 */
/* net.ipv4.tcp_fastopen = 3
 *   비트 0: 클라이언트 TFO 활성화
 *   비트 1: 서버 TFO 활성화
 *   비트 2: 쿠키 없이 TFO 허용 (보안 위험)
 */

/* 서버 측 */
int qlen = 5;
setsockopt(fd, SOL_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen));
/* qlen: TFO 대기열 크기 */

/* 클라이언트 측 */
sendto(fd, data, len, MSG_FASTOPEN,
       (struct sockaddr *)&addr, sizeof(addr));
/* connect() 없이 첫 sendto()에서 SYN+데이터 전송 */

TCP 성능 관련 sysctl 종합

tcp_sock 핵심 구조체

struct tcp_sock은 struct inet_connection_sock을 확장하며, TCP 연결의 모든 상태를 관리합니다. 소켓 하나당 약 2KB 이상의 메모리를 차지합니다:

/* include/linux/tcp.h */
struct tcp_sock {
    struct inet_connection_sock  inet_conn;

    /* === 시퀀스 번호 관리 === */
    u32     snd_una;        /* 전송 완료 확인된 첫 바이트 (send unacknowledged) */
    u32     snd_nxt;        /* 다음 전송할 시퀀스 번호 */
    u32     snd_wnd;        /* 상대방이 광고한 수신 윈도우 크기 */
    u32     rcv_nxt;        /* 다음 수신 기대 시퀀스 번호 */
    u32     rcv_wnd;        /* 광고할 수신 윈도우 크기 */
    u32     write_seq;      /* 유저가 write()한 마지막 바이트 다음 */
    u32     copied_seq;     /* 유저가 read()한 마지막 바이트 다음 */

    /* === 혼잡 제어 상태 === */
    u32     snd_cwnd;       /* 혼잡 윈도우 (cwnd) — 패킷 단위 */
    u32     snd_ssthresh;   /* 슬로 스타트 임계값 */
    u32     prior_cwnd;     /* 손실 복구 전 cwnd (undo용) */
    u32     prr_delivered;  /* PRR 알고리즘: 복구 중 전달된 세그먼트 */
    u32     prr_out;        /* PRR: 복구 중 전송한 세그먼트 */

    /* === RTT 측정 === */
    u32     srtt_us;        /* smoothed RTT (마이크로초 × 8) */
    u32     mdev_us;        /* RTT 편차 (마이크로초 × 4) */
    u32     rttvar_us;      /* RTT 분산 (RTO 계산용) */
    u32     rto;            /* 재전송 타임아웃 (jiffies) */

    /* === 재전송 관리 === */
    u32     retrans_out;    /* 현재 네트워크에 있는 재전송 세그먼트 수 */
    u32     lost_out;       /* 손실로 판단된 세그먼트 수 */
    u32     sacked_out;     /* SACK 확인된 세그먼트 수 */
    u8      reordering;     /* 현재 관측된 재정렬 수준 */

    /* === TCP 옵션 === */
    struct tcp_options_received rx_opt;
    /*   .rcv_wscale    수신 Window Scale factor
     *   .snd_wscale    전송 Window Scale factor
     *   .tstamp_ok     Timestamp 옵션 협상 여부
     *   .sack_ok       SACK 옵션 협상 여부
     *   .wscale_ok     Window Scale 협상 여부
     */

    /* === Pacing === */
    u64     tcp_mstamp;     /* 가장 최근 전송 시각 */
    u32     sk_pacing_rate; /* bytes/sec 단위 전송 속도 */

    /* === 혼잡 제어 알고리즘 private 데이터 === */
    u64     ca_priv[104 / sizeof(u64)];
    /* CUBIC: bic_K, bic_origin_point, cnt 등
     * BBR:   bw[], min_rtt_us, mode, cycle_idx 등
     */
};

TCP 연결 종료와 TIME_WAIT

TCP 연결 종료는 4-Way Handshake 또는 동시 종료(simultaneous close)로 진행됩니다. TIME_WAIT 상태는 지연 패킷 처리와 연결 식별자 재사용 방지를 위해 필수적입니다:

/* TCP 4-Way Handshake 연결 종료 */

/* 능동 종료자 (Active Close) — close() 호출 측 */
/*
 * ESTABLISHED → FIN_WAIT1 → FIN_WAIT2 → TIME_WAIT → CLOSED
 *
 * 1. close()/shutdown() 호출
 *    → tcp_close() → tcp_send_fin()
 *    → FIN 세그먼트 전송, 상태 → FIN_WAIT1
 *
 * 2. 상대방 ACK 수신
 *    → tcp_rcv_state_process() → FIN_WAIT2
 *    → tcp_fin_timeout (기본 60초) 타이머 시작
 *
 * 3. 상대방 FIN 수신
 *    → tcp_fin() → ACK 전송
 *    → TIME_WAIT 상태 전이
 *
 * 4. TIME_WAIT: 2 × MSL (Maximum Segment Lifetime) 동안 대기
 *    → Linux: 60초 고정 (TCP_TIMEWAIT_LEN)
 *    → 이유: 지연 패킷 흡수 + 마지막 ACK 재전송 보장
 */

/* 수동 종료자 (Passive Close) — FIN 수신 측 */
/*
 * ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED
 *
 * 1. 상대방 FIN 수신
 *    → ACK 자동 전송, 상태 → CLOSE_WAIT
 *    → 애플리케이션에 EOF(read()=0) 전달
 *
 * 2. 애플리케이션 close() 호출
 *    → tcp_send_fin(), 상태 → LAST_ACK
 *
 * 3. 마지막 ACK 수신
 *    → CLOSED, 소켓 해제
 */

/* TIME_WAIT 소켓 최적화 */
struct tcp_timewait_sock {
    struct inet_timewait_sock tw_sk;
    u32    tw_rcv_nxt;      /* 기대 수신 시퀀스 */
    u32    tw_snd_nxt;      /* 마지막 전송 시퀀스 */
    u32    tw_rcv_wnd;      /* 수신 윈도우 */
    u32    tw_ts_recent;    /* 최근 타임스탬프 */
    long   tw_ts_recent_stamp;
};
/* → 전체 tcp_sock (~2KB) 대신 경량 구조체 (~240B) 사용
 *   → TIME_WAIT 소켓 수만 개에도 메모리 절약
 */

# TIME_WAIT 관련 sysctl 튜닝

# TIME_WAIT 소켓 재사용 (동일 4-tuple에 한해)
net.ipv4.tcp_tw_reuse = 1
# 조건: Timestamp 옵션 활성화 + 이전 타임스탬프보다 큰 값
# 2: loopback에서만 활성화 (기본값, 커널 5.7+)

# TIME_WAIT 소켓 최대 수
net.ipv4.tcp_max_tw_buckets = 262144
# 초과 시 새 TIME_WAIT 즉시 종료 (로그: "time wait bucket table overflow")

# FIN_WAIT2 타임아웃 (orphan 소켓)
net.ipv4.tcp_fin_timeout = 30
# 기본 60초 → 고부하 서버에서 30초로 단축 권장

# orphan 소켓 최대 수
net.ipv4.tcp_max_orphans = 65536
# close() 후 아직 FIN 교환 중인 소켓

TCP 재전송 메커니즘

TCP의 신뢰성 보장 핵심은 재전송입니다. 커널은 타이머 기반 재전송(RTO)과 빠른 재전송(Fast Retransmit) 두 가지 메커니즘을 사용합니다:

/* === RTO (Retransmission Timeout) 계산 — RFC 6298 === */
/* net/ipv4/tcp_input.c: tcp_rtt_estimator() */

/* RTT 샘플 수집 (Timestamp 옵션 또는 전송 시각 기록) */
/*
 * SRTT = (1 - α) × SRTT + α × RTT_sample     (α = 1/8)
 * RTTVAR = (1 - β) × RTTVAR + β × |SRTT - RTT_sample|  (β = 1/4)
 * RTO = SRTT + max(G, 4 × RTTVAR)             (G = clock granularity)
 *
 * 커널 구현 (정수 연산, 스케일링):
 *   tp→srtt_us    = srtt × 8     (마이크로초)
 *   tp→mdev_us    = rttvar × 4   (마이크로초)
 *   tp→rto        = jiffies 단위
 */

static void tcp_rtt_estimator(struct sock *sk, long mrtt_us)
{
    struct tcp_sock *tp = tcp_sk(sk);
    long m = mrtt_us;  /* 새 RTT 샘플 */
    u32 srtt = tp->srtt_us;

    if (srtt != 0) {
        m -= (srtt >> 3);         /* m = sample - srtt/8 */
        srtt += m;                  /* srtt = 7/8 × srtt + 1/8 × sample */
        if (m < 0) m = -m;
        m -= (tp->mdev_us >> 2);   /* mdev 갱신 */
        tp->mdev_us += m;
    } else {
        /* 첫 번째 RTT 샘플 */
        srtt = m << 3;             /* srtt = sample × 8 */
        tp->mdev_us = m << 1;      /* mdev = sample × 2 */
        tp->rttvar_us = max(tp->mdev_us, tcp_rto_min_us(sk));
    }
    tp->srtt_us = max(1U, srtt);
}

/* RTO 범위 제한 */
/* 최소: TCP_RTO_MIN = 200ms (HZ/5)
 * 최대: TCP_RTO_MAX = 120초 (120*HZ)
 * 초기: TCP_TIMEOUT_INIT = 1초 (SYN 재전송 시작값)
 */

/* === 재전송 타이머와 지수 백오프 === */
/* net/ipv4/tcp_timer.c: tcp_retransmit_timer() */

/*
 * RTO 만료 시 동작:
 *   1. snd_una 이후 첫 번째 미확인 skb를 재전송
 *   2. RTO를 2배로 증가 (지수 백오프: exponential backoff)
 *   3. snd_cwnd = 1 MSS (혼잡 윈도우 최소화)
 *   4. snd_ssthresh = max(flight_size/2, 2)
 *   5. 재전송 횟수 카운터 증가
 *
 * 최대 재전송 횟수:
 *   tcp_retries1 = 3   → 이 횟수 초과 시 라우팅 테이블 갱신 시도
 *   tcp_retries2 = 15  → 이 횟수 초과 시 연결 종료 (RST)
 *     → ~13~30분 (RTO 백오프에 따라 변동)
 *
 * SYN 재전송 횟수:
 *   tcp_syn_retries = 6    → 약 127초
 *   tcp_synack_retries = 5 → 약 63초
 */

void tcp_retransmit_timer(struct sock *sk)
{
    struct tcp_sock *tp = tcp_sk(sk);

    if (!tp->packets_out)  /* 미확인 패킷 없으면 무시 */
        return;

    /* 재전송 실행 */
    tcp_retransmit_skb(sk, tcp_rtx_queue_head(sk), 1);

    /* 지수 백오프: RTO × 2 */
    inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
        min(tp->rto << 1, TCP_RTO_MAX), TCP_RTO_MAX);
}

/* === Fast Retransmit / Fast Recovery (RFC 5681, RFC 6675) === */

/*
 * 빠른 재전송 (Fast Retransmit):
 *   3개의 중복 ACK (duplicate ACK) 수신 시
 *   → RTO 만료를 기다리지 않고 즉시 재전송
 *   → SACK 기반: 3개 이상의 세그먼트가 SACK 확인되면 gap을 손실로 간주
 *
 * 빠른 복구 (Fast Recovery):
 *   → ssthresh = max(flight_size / 2, 2)
 *   → cwnd = ssthresh + 3 (중복 ACK 수만큼)
 *   → 중복 ACK마다 cwnd++ (새 세그먼트 전송 가능)
 *   → 새 ACK(snd_una 전진) 수신 시 cwnd = ssthresh, 복구 종료
 *
 * PRR (Proportional Rate Reduction, RFC 6937):
 *   → 커널 기본 복구 알고리즘 (3.2+)
 *   → 기존 Fast Recovery의 버스트 문제 해결
 *   → 손실 복구 중에도 일정한 비율로 세그먼트 전송
 *   → prr_delivered, prr_out으로 전송량 조절
 */

/* 손실 감지 상태 머신 (tcp_ca_state) */
enum tcp_ca_state {
    TCP_CA_Open     = 0,  /* 정상 동작 (cwnd 증가) */
    TCP_CA_Disorder = 1,  /* 중복 ACK/SACK 감지 (아직 손실 미확정) */
    TCP_CA_CWR      = 2,  /* ECN-Echo 수신 → cwnd 감소 중 */
    TCP_CA_Recovery = 3,  /* Fast Retransmit 진입 (SACK 기반 복구) */
    TCP_CA_Loss     = 4,  /* RTO 만료 → cwnd=1, 전체 재전송 */
};

혼잡 제어 심화 — CUBIC과 BBR

Linux의 혼잡 제어 프레임워크는 struct tcp_congestion_ops 인터페이스를 통해 알고리즘을 플러그인으로 교체할 수 있습니다:

/* include/net/tcp.h */
struct tcp_congestion_ops {
    /* 필수 콜백 */
    void (*cong_avoid)(struct sock *sk, u32 ack, u32 acked);
    /* → ACK 수신 시 cwnd 조절 (Slow Start / Congestion Avoidance) */

    u32  (*ssthresh)(struct sock *sk);
    /* → 손실 감지 시 새 ssthresh 계산 */

    /* 선택적 콜백 */
    void (*init)(struct sock *sk);
    void (*release)(struct sock *sk);
    void (*set_state)(struct sock *sk, u8 new_state);
    void (*cwnd_event)(struct sock *sk, enum tcp_ca_event ev);
    void (*pkts_acked)(struct sock *sk, const struct ack_sample *sample);
    u32  (*undo_cwnd)(struct sock *sk);
    u32  (*sndbuf_expand)(struct sock *sk);

    /* BBR 등에서 사용 */
    u32  (*min_tso_segs)(struct sock *sk);
    void (*cong_control)(struct sock *sk, const struct rate_sample *rs);
    /* → cong_control이 정의되면 cong_avoid/ssthresh 대신 호출
     *   BBR은 이 콜백에서 cwnd와 pacing_rate를 직접 설정 */

    char            name[TCP_CA_NAME_MAX];
    struct module   *owner;
};

CUBIC 알고리즘 내부

/* net/ipv4/tcp_cubic.c — Linux 기본 혼잡 제어 (커널 2.6.19+) */

/* CUBIC 핵심 아이디어:
 *   cwnd 증가를 3차 함수(cubic function)로 모델링
 *   → 손실 전 cwnd(Wmax)에 빠르게 접근, 이후 느리게 탐색
 *   → 고대역폭·고지연 네트워크에서 Reno보다 빠른 대역폭 활용
 */

/* CUBIC 윈도우 함수:
 *   W(t) = C × (t - K)³ + Wmax
 *
 *   C = 0.4 (스케일링 상수)
 *   K = ³√(Wmax × β / C)  — 원점에서 Wmax까지 도달 시간
 *   β = 0.7 (손실 시 cwnd 감소 비율: new_cwnd = Wmax × 0.7)
 *   t = 마지막 손실 이후 경과 시간
 */

struct bictcp {
    u32  cnt;             /* cwnd 증가 속도 (ACK당 1/cnt MSS) */
    u32  last_max_cwnd;    /* Wmax: 마지막 손실 시점 cwnd */
    u32  last_cwnd;        /* 직전 cwnd 값 */
    u32  last_time;        /* 직전 갱신 시각 */
    u32  bic_origin_point; /* CUBIC 함수 원점 */
    u32  bic_K;            /* Wmax 도달 시간 K */
    u32  epoch_start;      /* 현재 에포크 시작 시각 */
    u32  ack_cnt;          /* 에포크 내 ACK 카운트 */
    u32  tcp_cwnd;         /* Reno 모드 cwnd (하이브리드용) */
};

/* CUBIC 슬로 스타트: Hystart++
 *   → 표준 슬로 스타트의 과도한 오버슈트 방지
 *   → ACK 지연 변화량으로 BDP 근처 감지
 *   → 탐지 시 ssthresh 설정하고 congestion avoidance 전환
 *   → net.ipv4.tcp_hystart = 1 (기본 활성화)
 */

BBR 알고리즘 내부

/* net/ipv4/tcp_bbr.c — Google BBR (커널 4.9+) */

/* BBR 핵심 원리:
 *   손실이 아닌 "대역폭(BtlBw)"과 "최소 RTT(RTprop)"를 측정하여
 *   최적 전송 속도를 결정
 *
 *   pacing_rate = BtlBw × pacing_gain
 *   cwnd = BDP × cwnd_gain = BtlBw × RTprop × cwnd_gain
 */

struct bbr {
    u32  min_rtt_us;          /* 관측된 최소 RTT (10초 윈도우) */
    u32  min_rtt_stamp;       /* min_rtt 측정 시각 */
    u32  bw[2];              /* 최대 대역폭 샘플 (windowed max) */
    u32  mode:3,             /* 현재 상태: STARTUP/DRAIN/PROBE_BW/PROBE_RTT */
         prev_ca_state:3,
         round_start:1,
         idle_restart:1,
         probe_rtt_round_done:1;
    u32  cycle_idx;           /* PROBE_BW 사이클 위치 (0~7) */
    u32  pacing_gain;         /* 현재 pacing gain (× BBR_UNIT) */
    u32  cwnd_gain;           /* 현재 cwnd gain */
};

/* BBR 상태 머신 */
/*
 * 1. STARTUP (슬로 스타트 대응)
 *    pacing_gain = 2.89 (= 2/ln2), cwnd_gain = 2.89
 *    → 대역폭이 3 라운드 연속 25% 미만 증가하면 DRAIN 전환
 *
 * 2. DRAIN
 *    pacing_gain = 1/2.89 ≈ 0.35
 *    → 큐에 쌓인 데이터 배출 (inflight ≤ BDP까지)
 *
 * 3. PROBE_BW (정상 상태 — 대부분 시간)
 *    8-phase 사이클:
 *    [1.25, 0.75, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0]
 *    → 1.25: 대역폭 탐색 (약간 공격적 전송)
 *    → 0.75: 큐 배출
 *    → 1.0 × 6: 안정 상태 유지
 *
 * 4. PROBE_RTT (10초마다)
 *    cwnd = 4 패킷으로 축소, 200ms 유지
 *    → 최소 RTT 재측정 (큐 비우고 순수 전파 지연 측정)
 */

TCP 데이터 전송/수신 경로

유저 프로세스의 send()/recv() 호출이 커널 내부에서 처리되는 전체 경로입니다:

/* === 전송 경로 (send → wire) === */

/* 1. 시스템 콜 진입 */
/* send(fd, buf, len, flags)
 *   → sys_sendto() → sock_sendmsg() → tcp_sendmsg()
 */

/* 2. tcp_sendmsg() — net/ipv4/tcp.c */
/*
 *   a) 유저 데이터를 sk_buff 체인으로 복사 (send buffer)
 *      → sk->sk_write_queue에 추가
 *      → 가능하면 기존 skb의 남은 공간에 append (coalescence)
 *      → copy_from_iter()로 유저 → 커널 복사
 *
 *   b) write_seq 갱신
 *
 *   c) 전송 조건 확인 후 tcp_push() 호출
 *      → Nagle 알고리즘 확인 (TCP_NODELAY 아니면)
 *      → 혼잡 윈도우 / 수신 윈도우 확인
 */

/* 3. tcp_write_xmit() — 실제 세그먼트 전송 루프 */
/*
 *   while (cwnd에 여유 && 전송 대기 skb 있음) {
 *     tcp_transmit_skb():
 *       a) TCP 헤더 구성 (seq, ack, window, options)
 *       b) 체크섬 계산 (또는 hw checksum offload 설정)
 *       c) IP 계층 전달: ip_queue_xmit()
 *       d) retransmit queue에 skb 유지 (ACK 대기)
 *
 *     pacing 적용: sk→sk_pacing_rate에 따라 전송 간격 조절
 *     TSO 적용: 대형 세그먼트를 NIC에서 분할하도록 설정
 *   }
 */

/* 4. IP → 디바이스 → NIC */
/*   ip_queue_xmit() → ip_local_out() → NF_INET_LOCAL_OUT
 *   → dst_output() → ip_output() → NF_INET_POST_ROUTING
 *   → ip_finish_output() → neigh_output() → dev_queue_xmit()
 *   → qdisc → NIC 드라이버 → 하드웨어 전송
 */

/* === 수신 경로 (wire → recv) === */

/* 1. NIC → NAPI → IP */
/*   NIC 인터럽트 → NAPI poll → napi_gro_receive()
 *   → netif_receive_skb() → ip_rcv()
 *   → NF_INET_PRE_ROUTING → ip_rcv_finish()
 *   → ip_local_deliver() → NF_INET_LOCAL_IN
 *   → tcp_v4_rcv()
 */

/* 2. tcp_v4_rcv() — TCP 수신 핵심 */
/*
 *   a) 4-tuple (src_ip, dst_ip, src_port, dst_port)로 소켓 조회
 *      → inet_lookup_established() 또는 inet_lookup_listener()
 *      → Early Demux 최적화 적용 가능
 *
 *   b) 체크섬 검증 (HW offload 또는 SW)
 *
 *   c) tcp_v4_do_rcv() → tcp_rcv_established() (대부분의 경우)
 */

/* 3. tcp_rcv_established() — Fast Path / Slow Path */
/*
 *   Fast Path (예측 기반 — 일반적 경우):
 *     → 다음 기대 시퀀스와 일치하는 순서 데이터
 *     → ACK 번호가 유효
 *     → 윈도우 변화 없음
 *     → 직접 sk→sk_receive_queue에 추가
 *     → 매우 빠름 (헤더 예측으로 분기 최소화)
 *
 *   Slow Path:
 *     → 비순서 데이터 → Out-of-Order 큐에 추가
 *     → SACK 처리, 윈도우 업데이트, URG 등
 *     → tcp_data_queue() → tcp_ofo_queue() (재정렬)
 */

/* 4. 유저 read() */
/*   recv()/read() → tcp_recvmsg()
 *     → sk_receive_queue에서 데이터를 유저 버퍼로 복사
 *     → copied_seq 갱신
 *     → 수신 윈도우 갱신 → ACK 전송 (조건부)
 *
 *   Delayed ACK: 즉시 ACK 대신 최대 40ms 지연 (tcp_delack_timer)
 *     → 데이터 응답에 ACK를 피기백(piggyback)하여 패킷 수 절감
 *     → 2번째 세그먼트마다 즉시 ACK (quick_ack)
 */

TCP 메모리 관리와 TSQ

/* === TCP 메모리 관리 3단계 === */
/* net.ipv4.tcp_mem = low pressure high  (페이지 단위)
 *
 * 전체 TCP 소켓이 사용하는 메모리를 3단계로 관리:
 *
 * 1. low 미만: 정상 동작
 *    → 소켓별 버퍼 자동 튜닝 정상 작동
 *
 * 2. pressure (low < 현재 < high):
 *    → tcp_memory_pressure 플래그 설정
 *    → 소켓별 버퍼 축소 시작
 *    → 새 버퍼 할당에 제한
 *    → sk_stream_moderate_sndbuf()로 전송 버퍼 감소
 *
 * 3. high 이상:
 *    → 새 메모리 할당 거부 (소켓 write 블로킹)
 *    → 기존 연결의 전송도 지연될 수 있음
 *    → OOM 방지를 위한 최후 방어선
 *
 * 현재 사용량 확인: cat /proc/net/sockstat
 *   TCP: inuse 1234 orphan 0 tw 56 alloc 1234 mem 789
 *   (mem = 현재 사용 페이지 수)
 */

/* === 소켓별 메모리 관리 === */
/*
 * sk→sk_wmem_queued:  전송 버퍼에 쌓인 바이트
 * sk→sk_rmem_alloc:   수신 버퍼에 쌓인 바이트
 * sk→sk_sndbuf:       전송 버퍼 상한 (tcp_wmem 기반 자동 조절)
 * sk→sk_rcvbuf:       수신 버퍼 상한 (tcp_rmem 기반 자동 조절)
 *
 * sk_wmem_queued ≥ sk_sndbuf 이면:
 *   → sk_stream_wait_memory(): write() 블로킹
 *   → epoll: EPOLLOUT 해제
 */

/* === TSQ (TCP Small Queues) — net/ipv4/tcp_output.c === */
/* 커널 3.6+ (commit 46d3ceab) */

/* 문제: 대량의 TCP 세그먼트가 qdisc 큐에 쌓이면
 *   → 지연 시간 증가 (버퍼블로트)
 *   → 다른 플로우에 대한 공정성 저하
 *   → 혼잡 제어의 피드백 루프가 느려짐
 *
 * 해결: 소켓당 qdisc/NIC에 대기 중인 바이트 수를 제한
 *   → sk→sk_pacing_status로 추적
 *   → 제한: sysctl net.ipv4.tcp_limit_output_bytes (기본 1MB)
 *
 * 동작:
 *   tcp_write_xmit()에서 전송 전 확인:
 *   if (sk→sk_wmem_queued - sk→sk_wmem_alloc > limit)
 *       → 전송 보류, tasklet으로 나중에 재시도
 *
 * TSQ tasklet:
 *   NIC 드라이버가 skb 전송 완료 → skb_orphan()
 *   → sk→sk_wmem_alloc 감소
 *   → tcp_tsq_handler() → tcp_write_xmit() 재개
 *
 * 효과:
 *   → qdisc 큐 깊이 감소 → 지연 시간 대폭 개선
 *   → BBR의 pacing과 함께 사용하면 버퍼블로트 근본 해결
 */

TCP Segmentation Offload (TSO/GSO)

TSO/GSO는 TCP 전송 성능의 핵심입니다. 커널이 MSS보다 훨씬 큰 대형 skb를 생성하여 네트워크 스택을 한 번만 통과시킨 후, 최종 단계에서 분할합니다.

/* === TSO (TCP Segmentation Offload) — 하드웨어 오프로드 === */
/*
 * 일반 전송 (오프로드 없음):
 *   write(fd, buf, 64000) → 커널이 MSS(1460) 단위로 44개 skb 생성
 *   → 각 skb마다: TCP 헤더 생성, IP 헤더, 체크섬, qdisc, NIC DMA
 *   → 매우 높은 per-packet CPU 오버헤드
 *
 * TSO 활성:
 *   → 커널이 64KB 대형 skb 1개 생성
 *   → 네트워크 스택(IP, Netfilter, TC, qdisc) 1번 통과
 *   → NIC 하드웨어가 MSS 단위 분할:
 *     - 각 세그먼트에 TCP 헤더 복사 (seq 증가, PSH/FIN 조정)
 *     - IP 헤더 복사 (total_length, ID 증가)
 *     - 체크섬 계산 (TCP pseudo-header + payload)
 *   → CPU 부하 대폭 절감 — 10Gbps+ 환경에서 필수
 *
 * 확인: ethtool -k eth0 | grep tcp-segmentation
 *   tcp-segmentation-offload: on
 */

/* === GSO (Generic Segmentation Offload) — 소프트웨어 fallback === */
/*
 * TSO의 소프트웨어 일반화 (커널 2.6.18+, Herbert Xu):
 *   → TSO와 동일하게 대형 skb를 생성하여 스택 통과
 *   → validate_xmit_skb()에서 분할 결정:
 *     NIC가 TSO 지원 (NETIF_F_TSO) → 그대로 NIC에 전달
 *     NIC가 TSO 미지원 → skb_gso_segment()로 소프트웨어 분할
 *
 * GSO의 핵심 가치:
 *   1. TSO 미지원 NIC에서도 중간 계층 처리 비용 절감
 *   2. 터널(VXLAN, GRE), 가상화(veth, bridge) 환경에서 동작
 *   3. TCP 외 프로토콜 지원: UDP GSO, SCTP GSO, ESP GSO
 *   4. GRO ↔ GSO 대칭: 포워딩 시 GRO로 병합된 skb를 GSO로 재분할
 *
 * 전송 경로:
 *   tcp_sendmsg() → tcp_write_xmit() [대형 skb 생성, gso_size=MSS]
 *   → ip_queue_xmit() → __dev_queue_xmit() → qdisc (1개 skb만 처리)
 *   → validate_xmit_skb() → NIC feature 확인
 *     ├→ HW TSO 가능: skb 그대로 NIC 전달
 *     └→ HW 미지원: skb_gso_segment() → N개 세그먼트로 분할
 */

/* GSO 유형 (skb_shinfo→gso_type 비트마스크):
 *   SKB_GSO_TCPV4         IPv4 TCP (기본 TSO/GSO)
 *   SKB_GSO_TCPV6         IPv6 TCP
 *   SKB_GSO_UDP_L4        UDP L4 세그먼트 (4.18+, QUIC/WireGuard)
 *   SKB_GSO_UDP           UDP IP 단편화 (UFO)
 *   SKB_GSO_GRE           GRE 터널 내부 GSO
 *   SKB_GSO_UDP_TUNNEL    VXLAN/Geneve 내부 GSO
 *   SKB_GSO_PARTIAL       부분 GSO: 외부 HW + 내부 SW
 *   SKB_GSO_ESP           IPsec ESP GSO
 *   SKB_GSO_SCTP          SCTP 청크 GSO
 *   SKB_GSO_FRAGLIST      frag_list 기반 (GRO→포워딩→GSO)
 *   SKB_GSO_TCP_ECN       ECN 활성 TCP GSO
 *   SKB_GSO_DODGY         신뢰할 수 없는 GSO (VM 전달 등)
 */

struct sk_buff *skb;
/* TSO/GSO 관련 skb 필드 (skb_shared_info) */
skb_shinfo(skb)->gso_size;    /* 분할 단위 크기 (MSS)
                               * TCP: MSS (예: 1460)
                               * UDP GSO: 데이터그램 크기 (예: 1472)
                               * 0이면 GSO 미사용 */
skb_shinfo(skb)->gso_segs;    /* 예상 세그먼트 수 (힌트)
                               * DIV_ROUND_UP(payload_len, gso_size)
                               * BQL(Byte Queue Limit) 계산에 활용 */
skb_shinfo(skb)->gso_type;    /* SKB_GSO_* 비트마스크 (OR 조합)
                               * 예: SKB_GSO_TCPV4 | SKB_GSO_TCP_ECN */

/* 예: 64KB 데이터 + MSS=1460인 경우
 *   → gso_size = 1460 (분할 단위)
 *   → gso_segs = 64000/1460 ≈ 44개 세그먼트
 *   → 커널은 1개의 skb만 처리:
 *     - ip_queue_xmit() 1회, qdisc 1회
 *     - Netfilter/conntrack/NAT 1회
 *   → 최종 분할:
 *     NIC TSO → 하드웨어가 44개 와이어 프레임 생성
 *     SW GSO → validate_xmit_skb()에서 44개 skb 분할
 *
 * GSO 최대 크기:
 *   net_device→gso_max_size (기본 65536)
 *   BIG TCP (6.3+): IPv6에서 ~185KB까지 확장 가능
 *   ip link set dev eth0 gso_max_size 185000
 */

/* 유용한 헬퍼 함수 */
skb_is_gso(skb);               /* gso_size != 0이면 true */
skb_gso_network_seglen(skb);   /* 세그먼트의 실제 와이어 크기 */
skb_gso_segment(skb, features);/* SW GSO 분할 수행 → skb 리스트 반환 */

Nagle 알고리즘, TCP_NODELAY, TCP_CORK