상용 NGFW HW 아키텍처

Fortinet 7121F/NP7/CP9, Palo Alto PA-7500/SP3, Check Point 29200/Maestro/LightSpeed, Juniper SRX5800, Cisco Secure Firewall 4245, Sophos XGS 8500 최상급 상용 NGFW 하드웨어 아키텍처 비교, SSL Inspection 오프로드 분류, 암호화(Encryption) 오프로드 아키텍처 3분류, 하드웨어 이벤트 스케줄러(Scheduler)(DLB/SSO), Linux 커널 기반 NGFW, 벤더별 TLS 핸드셰이크·암호화·성능 비교, 패킷 유형별 고성능 흐름, 배포 아키텍처 패턴, HA 구성, TLS 1.3/ECH 대응, PQC 영향, RFC 9411 성능 측정 방법론

상용 NGFW는 암호화·DPI 가속을 위해 크게 두 가지 하드웨어 처리 모델을 사용합니다:

대부분의 상용 NGFW는 두 모델을 혼합(Hybrid)하여 사용합니다. 다만 실무에서는 L4 세션 전달용 fast path와 SSL Inspection용 복호화(Decryption) 경로를 분리해서 봐야 합니다. 같은 장비라도 세션 포워딩은 inline인데, SSL/TLS 검사는 CPU중심 lookaside, SoC중심 lookaside, 카드형 크립토 가속기, 또는 전용 TLS 복호화 엔진일 수 있습니다. 아래 표는 2026년 6월 공식 문서 확인 기준으로 이를 정리한 것입니다:

2026년 6월 공식 자료 확인 요약

아래 내용은 2026년 6월 2일 기준 공식 벤더 문서와 데이터시트를 확인해 반영한 사항입니다. 수치가 포함된 항목은 벤더가 공개한 시험 조건을 함께 보아야 하며, 실제 배치에서는 RFC 9411 방법론으로 재측정해야 합니다.

최상급 NGFW 장비 기준 아키텍처 비교

최고 성능 장비를 볼 때 가장 중요한 질문은 "어떤 칩이 빠른가"가 아니라 어떤 기능을 어느 계층에서 수평 확장하는가입니다. 최상급 NGFW는 대체로 ① 포트·패브릭 계층, ② 첫 패킷·세션 분류 계층, ③ L4/NAT/IPsec fast path 계층, ④ TLS 복호화 계층, ⑤ DPI/IPS/URL/파일 검사 계층, ⑥ 로그·관리 계층을 분리합니다. 아래 표는 공식 자료 기준으로 각 벤더의 플래그십 또는 최상위급 제품군을 이 관점에서 정리한 것입니다.

최상급 장비의 공통 패킷 경로 상세

플래그십 NGFW의 패킷 경로는 대부분 아래와 같은 형태로 수렴합니다. Fortinet은 이 계층을 FIM/FPM/NP7/CP9로, Palo Alto는 NPC/DPC/SFC로, Check Point는 SecureXL/CoreXL/Maestro로, Juniper는 MPC·IOC/SPC/SCB로, Cisco는 flow offload/crypto accelerator/Snort 3로, Sophos는 SlowPath/DPI Engine/FastPath/Xstream Flow Processor로 구현합니다.

벤더별 기능 칩셋 연결 구성도

아래 연결도는 공개 문서에서 확인 가능한 카드·ASIC·기능 블록의 논리 연결을 기준으로 작성했습니다. 실제 PCB 배선, SerDes lane 수, 내부 crossbar, 암호화 엔진 배치, CPU socket 구성은 대부분 벤더가 공개하지 않으므로 그림에 포함하지 않았습니다. 따라서 이 그림은 "실제 보드 회로도"가 아니라 패킷이 어느 기능 블록을 거쳐 성능을 얻는지를 설명하는 구조도입니다.

벤더별 핵심 성능 오프로드 아키텍처 상세도

아래 그림은 각 벤더의 고성능 경로를 패킷이 실제로 어느 기능 블록을 지나 성능을 얻는가라는 관점으로 다시 펼친 것입니다. 녹색 경로는 반복 패킷을 줄이는 fast path, 보라색 경로는 암호화·TLS·IPsec 보조, 주황색 경로는 DPI/IPS/URL/파일 검사처럼 비용이 큰 deep path를 뜻합니다. 벤더가 공개하지 않은 칩 내부 버스 폭, crossbar, crypto engine 세부 배치는 의도적으로 그리지 않았습니다.

벤더별 SSL Inspection 오프로드 분류

SSL/TLS Inspection은 단순히 "암호화 가속" 하나로 끝나지 않습니다. 실제로는 ① TLS 핸드셰이크와 키 교환, ② 레코드 계층 AES-GCM/ChaCha20 암·복호화, ③ 평문 DPI와 정책 엔진(Policy Engine), ④ 인증서/개인키 보관이 서로 다른 자원에 배치됩니다. 벤더별 차이는 바로 이 네 단계가 어디서 실행되는지에 있습니다.

암호화 오프로드 아키텍처 3분류

앞선 표에서 lookaside를 단일 카테고리로 분류했지만, 실제 구현을 살펴보면 lookaside 방식은 가속기의 물리적 위치와 버스 토폴로지(Topology)에 따라 크게 두 가지로 나뉩니다. CPU중심 룩어사이드(CPU-Centric Lookaside)는 PCIe 카드 형태의 외장 가속기를, SoC중심 룩어사이드(SoC-Centric Lookaside)는 SoC 다이 내장 크립토 엔진을 사용합니다. 여기에 데이터 경로 자체에 암호화를 삽입하는 인라인(Inline) 방식까지 포함하면, 암호화 오프로드는 3분류로 정리됩니다.

각 아키텍처의 핵심 차이는 패킷 데이터가 암호화 엔진에 도달하는 경로와 결과가 반환되는 지연 시간입니다. 기존 전용 크립토 가속기 섹션의 HW 스펙표와 함께 참조하면 전체 그림을 파악할 수 있습니다.

CPU중심 룩어사이드(CPU-Centric Lookaside)

CPU중심 룩어사이드는 CPU가 호스트 메모리에 있는 패킷 데이터를 PCIe 버스를 통해 외장 가속기 카드에 전송하고, 가속기가 처리한 결과를 다시 PCIe DMA로 돌려받는 모델입니다. CPU가 submission ring에 작업을 큐잉하면, 가속기가 비동기로 처리한 뒤 completion ring을 통해 완료를 통보합니다.

대표 하드웨어:

• Intel QAT 8970 (PCIe 카드) — 200 Gbps 대칭키, 140K RSA-2048 ops/s. qat_c62x 드라이버. 서버/어플라이언스용 대용량 SSL 프록시에 적합
• Intel QAT 4xxx (4th/5th Gen Xeon 내장) — 100 Gbps. SPR 이후 CPU에 통합되었으나, PCIe 도메인의 별도 디바이스로 노출되어 여전히 CPU중심 룩어사이드 모델
• Marvell NITROX V (PCIe 카드) — 100 Gbps, 최대 64 VF(SR-IOV) 지원. nitrox 드라이버로 커널 crypto API에 등록

커널 crypto API에 등록된 가속기의 우선순위(Priority) 확인:

# 등록된 암호화 알고리즘과 우선순위 확인
cat /proc/crypto | grep -A4 "name.*gcm(aes)"
# 출력 예시: driver = qat_aes_gcm, priority = 4001
# 우선순위가 높을수록 먼저 선택됨 (SW fallback은 보통 100~200)

# QAT 디바이스 상태 확인
cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/fw_counters

/* CPU중심 룩어사이드: 비동기 콜백 패턴 */
struct aead_request *req = aead_request_alloc(tfm, GFP_ATOMIC);
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
                          crypto_done_callback, &result);
aead_request_set_crypt(req, src_sg, dst_sg, payload_len, iv);
aead_request_set_ad(req, assoclen);

ret = crypto_aead_encrypt(req);
if (ret == -EINPROGRESS || ret == -EBUSY) {
    /* 가속기가 비동기 처리 중 — completion 대기 */
    wait_for_completion(&result.completion);
    ret = result.err;
}
/* QAT: PCIe DMA 왕복 지연 ~10-50μs 포함 */

SoC중심 룩어사이드(SoC-Centric Lookaside)

SoC중심 룩어사이드는 크립토 엔진이 SoC 다이 내부에 통합되어 있으며, CPU와 내부 버스(AXI/AHB/ACE)로 직접 연결됩니다. PCIe를 거치지 않으므로 DMA 왕복 지연이 크게 줄어들고, 별도 전원·슬롯이 필요 없어 임베디드·네트워크 장비에 널리 사용됩니다. CPU가 Job Ring(또는 Command Ring)에 작업을 큐잉하면, 내장 크립토 엔진이 내부 버스를 통해 메모리에서 직접 데이터를 읽어 처리합니다.

대표 하드웨어:

• NXP CAAM (Cryptographic Acceleration and Assurance Module) — NXP Layerscape/i.MX SoC에 내장. Job Ring 기반 비동기 처리, 최대 4 JR. Linux 드라이버: caam (drivers/crypto/caam/)
• Marvell OCTEON CPT (Crypto Processing Thread) — OCTEON TX2/CN10K에 내장. 최대 100 Gbps 대칭키. octeontx2-cpt 드라이버
• Broadcom SPU (Security Processing Unit) — BCM58xxx/Memory Stingray SoC. bcm_crypto_spu 드라이버
• ARM CryptoCell — ARM TrustZone 연동 보안 코프로세서, 1-5 Gbps. ccree 드라이버. 상세 스펙은 크립토 가속기 비교표 참조

Device Tree 바인딩 예시 (NXP CAAM):

/* NXP Layerscape SoC — CAAM Device Tree 바인딩 */
crypto@1700000 {
    compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
                 "fsl,sec-v4.0";
    reg = <0x0 0x1700000 0x0 0x100000>;
    interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
    #address-cells = <1>;
    #size-cells = <1>;
    ranges = <0x0 0x0 0x1700000 0x100000>;

    /* Job Ring 0 */
    jr0: jr@10000 {
        compatible = "fsl,sec-v5.4-job-ring",
                     "fsl,sec-v4.0-job-ring";
        reg = <0x10000 0x10000>;
        interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
    };
    /* Job Ring 1 */
    jr1: jr@20000 {
        compatible = "fsl,sec-v5.4-job-ring";
        reg = <0x20000 0x10000>;
        interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
    };
};

인라인 암호화(Inline Crypto)

인라인 암호화는 가속기가 네트워크 데이터 경로(data path) 자체에 위치하여, 패킷이 NIC/SmartNIC을 통과하는 과정에서 암호화·복호화가 수행됩니다. CPU는 암호 키 설정과 SA(Security Association) 구성만 담당하고, 실제 패킷 데이터에는 전혀 관여하지 않습니다. IPSec, MACsec, kTLS(커널 TLS) 3가지 프로토콜이 인라인 오프로드의 대표적 사례입니다.

대표 하드웨어:

• NVIDIA (Mellanox) ConnectX-6 Dx / ConnectX-7 — IPSec inline (200 Gbps), MACsec, kTLS offload. mlx5_core 드라이버. xfrm offload + TC flower 연동
• Intel E810 (Colville) — IPSec inline offload (100 Gbps). ice 드라이버. ethtool -K eth0 esp-hw-offload on으로 활성화
• AMD (Pensando) DSC-200 — SmartNIC/DPU, IPSec + kTLS inline. P4 프로그래머블 파이프라인(Pipeline)에 crypto 엔진 통합

인라인 IPSec 오프로드 설정 확인(상세는 kTLS 오프로드 섹션 참조):

# NIC의 inline crypto 기능 확인
ethtool -k eth0 | grep -E "esp-hw-offload|tls-hw"
# esp-hw-offload: on        ← IPSec inline 지원
# tls-hw-tx-offload: on     ← kTLS TX inline 지원
# tls-hw-rx-offload: on     ← kTLS RX inline 지원

# xfrm (IPSec) offload 설정 — SA에 offload 플래그 추가
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
    proto esp spi 0x100 reqid 1 mode tunnel \
    aead "rfc4106(gcm(aes))" 0x$(xxd -l 20 -p /dev/urandom) 128 \
    offload dev eth0 dir out    # ← inline offload 핵심 옵션

# offload 상태 확인
ip xfrm state show | grep -A2 offload

3종 아키텍처 종합 비교

하드웨어별 아키텍처 분류 상세:

리눅스 커널 Crypto API 매핑

리눅스 커널의 다양한 암호화 서브시스템은 3종 아키텍처를 각각 다른 경로로 활용합니다. 아래 표는 주요 서브시스템별 매핑을 보여줍니다:

커널 crypto API의 우선순위 기반 자동 선택(fallback chain):

# /proc/crypto에서 동일 알고리즘의 우선순위 확인
# 우선순위가 높은 드라이버가 자동 선택됨
$ grep -B1 -A5 "gcm(aes)" /proc/crypto

name         : gcm(aes)
driver       : qat_aes_gcm           # ← QAT 가속기 (CPU중심 Lookaside)
priority     : 4001                    # ← 최우선
async        : yes

name         : gcm(aes)
driver       : caam-gcm-aes           # ← CAAM (SoC중심 Lookaside)
priority     : 3000
async        : yes

name         : gcm(aes)
driver       : generic-gcm-aesni      # ← CPU AES-NI (SW fallback)
priority     : 400
async        : no

# Fallback chain: QAT(4001) → CAAM(3000) → AES-NI(400) → generic(100)
# 가속기 장애 시 자동으로 다음 우선순위 드라이버로 전환

암호화 완료 모델: 동기·비동기·폴링(Polling)

커널 crypto API에서 암호화 요청이 HW 가속기에 제출된 뒤 결과를 수신하는 방식은 크게 3가지로 나뉩니다: 동기(Synchronous), 비동기 인터럽트(Asynchronous Interrupt), 비동기 폴링. 각 모델은 지연 시간, CPU 활용률, 처리량 특성이 근본적으로 다르며, NGFW의 성능 프로파일을 결정하는 핵심 요소입니다.

동기 처리(Synchronous)

동기 모델에서 CPU는 암호화 함수를 호출한 뒤 결과가 반환될 때까지 블로킹됩니다. CPU 자체의 AES-NI/ARMv8-CE 명령어로 처리하는 경우가 대표적이며, 함수 호출과 반환이 동일 컨텍스트에서 완료됩니다.

/* 동기(Synchronous) 처리 — CPU 명령어(AES-NI) 직접 실행 */
struct skcipher_request *req = skcipher_request_alloc(tfm, GFP_KERNEL);
skcipher_request_set_crypt(req, src_sg, dst_sg, len, iv);

/* 콜백 없이 직접 호출 — 반환 시 이미 완료 */
ret = crypto_skcipher_encrypt(req);
/* ret == 0: 즉시 완료 (동기)
 * CPU AES-NI의 경우 /proc/crypto에서 async: no 표시 */

if (ret == 0) {
    /* 암호화 완료 — 결과가 dst_sg에 이미 기록됨 */
    process_encrypted_packet(dst_sg);
}
skcipher_request_free(req);

비동기 인터럽트 처리(Asynchronous Interrupt-Driven)

비동기 인터럽트 모델은 커널 crypto API에서 가장 일반적인 HW 가속기 활용 패턴입니다. CPU가 요청을 가속기의 submission ring에 큐잉하면 즉시 반환되고, 가속기가 처리를 완료하면 인터럽트(IRQ)를 발생시켜 등록된 콜백 함수를 호출합니다.

커널 crypto API에서 비동기 요청의 반환값 의미와 콜백 처리 흐름:

/*
 * crypto API 반환값 — 완료 모델을 결정하는 핵심
 *
 *  0            : 동기 완료 — 결과가 이미 준비됨
 * -EINPROGRESS  : 비동기 처리 시작됨 — 콜백으로 완료 통보 예정
 * -EBUSY        : 백로그(backlog) 큐에 진입 — 큐 공간 확보 후 처리 예정
 * -ENOSPC       : 큐 가득 참(백로그 미허용 시) — 호출자가 재시도해야 함
 * 기타 음수     : 오류 (키 설정 오류, 메모리 부족 등)
 */

/* ── 비동기 콜백 구조체 ── */
struct crypto_async_result {
    struct completion completion;   /* wait_for_completion() 대상 */
    int err;                        /* 콜백에서 설정되는 최종 에러 코드 */
};

/* ── 콜백 함수 — 가속기 인터럽트 핸들러에서 호출됨 ── */
static void crypto_op_complete(void *data, int err)
{
    struct crypto_async_result *result = data;
    /*
     * err == 0        : 암호화 성공
     * err == -EINPROGRESS : 백로그에서 꺼내어 처리 시작
     *                       (CRYPTO_TFM_REQ_MAY_BACKLOG 설정 시)
     * err < 0 (기타)  : HW 오류
     */
    if (err == -EINPROGRESS)
        return;  /* 아직 완료 아님 — 실제 완료 시 다시 호출됨 */

    result->err = err;
    complete(&result->completion);  /* 대기 중인 스레드 깨움 */
}

/* ── 요청 제출 — CRYPTO_TFM_REQ_MAY_BACKLOG 플래그 상세 ── */
struct aead_request *req = aead_request_alloc(tfm, GFP_ATOMIC);
aead_request_set_callback(req,
    CRYPTO_TFM_REQ_MAY_BACKLOG |   /* 큐 가득 차도 백로그 허용 */
    CRYPTO_TFM_REQ_MAY_SLEEP,      /* 콜백에서 sleep 가능 (프로세스 컨텍스트) */
    crypto_op_complete, &result);
aead_request_set_crypt(req, src_sg, dst_sg, payload_len, iv);
aead_request_set_ad(req, assoclen);

ret = crypto_aead_encrypt(req);
switch (ret) {
case 0:
    /* 동기 완료 — SW fallback이 선택된 경우 또는
     * 가속기가 즉시 처리 완료한 경우 */
    process_result(req);
    break;

case -EINPROGRESS:
    /* 비동기 처리 시작 — 가속기가 DMA로 데이터 전송 중
     * 완료 시 crypto_op_complete() 콜백 호출됨 */
    break;

case -EBUSY:
    /* 가속기 큐 가득 참 + 백로그에 진입
     * CRYPTO_TFM_REQ_MAY_BACKLOG 덕분에 거부되지 않음
     * 콜백이 두 번 호출됨:
     *   1차: err=-EINPROGRESS (백로그→실제 큐 이동 시)
     *   2차: err=0 (처리 완료 시) */
    break;

default:
    /* 오류 — 키 미설정, 메모리 부족, HW 장애 등 */
    pr_err("crypto op failed: %d\n", ret);
    break;
}

백로그(Backlog) 큐 동작 상세:

┌─────────────────────────────────────────────────────────┐
│              가속기 Submission Ring (크기: 512)            │
│  [req1] [req2] [req3] ... [req510] [req511] [req512]    │
│  ← 가득 참 (new request 도착)                            │
└─────────────────────────────────────────────────────────┘
                         │
    ┌────────────────────┼────────────────────┐
    │ MAY_BACKLOG 미설정  │  MAY_BACKLOG 설정   │
    ▼                    │                    ▼
 -ENOSPC 반환            │              -EBUSY 반환
 (호출자가 재시도)        │         (백로그 큐에 진입)
                         │                    │
                         │    ┌───────────────┘
                         │    ▼
                         │  Backlog Queue
                         │  [req513] [req514] ...
                         │    │
                         │    │  Ring 슬롯 빌 때
                         │    ▼
                         │  콜백(err=-EINPROGRESS)
                         │  → 실제 큐로 이동
                         │    │
                         │    │  HW 처리 완료
                         │    ▼
                         │  콜백(err=0)
                         │  → 최종 완료
                         └────────────────────

비동기 폴링 처리(Asynchronous Polling)

비동기 폴링 모델에서는 인터럽트 대신 CPU가 주기적으로 completion ring(또는 상태 레지스터(Register))을 직접 확인합니다. 인터럽트 발생·처리·컨텍스트 전환 오버헤드를 제거하여 초저지연을 달성할 수 있지만, 폴링 동안 CPU 사이클을 소모합니다.

커널 6.0+에서 도입된 crypto_engine 폴링 모드와 DPDK 환경의 busy-polling이 대표적입니다:

커널 crypto_engine 폴링 모드 — 커널 6.0+에서 struct crypto_engine은 가속기 드라이버에 폴링 기반 완료 처리를 지원합니다:

/*
 * crypto_engine 폴링 모드 (커널 6.0+)
 * drivers/crypto/crypto_engine.c
 *
 * 기본 인터럽트 모드 대비 폴링 모드 전환 조건:
 * 1. 고처리량 시나리오 (인터럽트 스톰 방지)
 * 2. 초저지연 요구 (IRQ 컨텍스트 전환 제거)
 */

/* ── 드라이버에서 폴링 모드 지원 등록 ── */
struct crypto_engine *engine;
engine = crypto_engine_alloc_init(dev, true);  /* rt=true: 실시간 우선순위 */

/* 폴링 기반 완료 처리 — 전용 kthread가 CQ를 확인 */
static int hw_accel_poll_completions(struct crypto_engine *engine)
{
    struct hw_completion_ring *cq = engine->priv;
    int completed = 0;

    /* completion ring의 유효한 엔트리를 순회 */
    while (cq->head != cq->tail) {
        struct crypto_async_request *req;
        struct hw_cq_entry *entry = &cq->entries[cq->head];

        /* 완료 여부 확인 (HW가 done 비트 설정) */
        if (!(READ_ONCE(entry->flags) & HW_CQ_DONE))
            break;

        req = entry->async_req;
        /* DMA 매핑 해제 */
        dma_unmap_sg(dev, req->src, sg_nents(req->src),
                     DMA_BIDIRECTIONAL);

        /* 콜백 호출 — 인터럽트 컨텍스트가 아닌
         * kthread 컨텍스트에서 실행 */
        crypto_finalize_request(engine, req, 0);

        cq->head = (cq->head + 1) % cq->ring_size;
        completed++;
    }
    return completed;
}

/*
 * 인터럽트 vs 폴링 전환 (적응형 모드)
 * 처리량이 임계치를 초과하면 자동으로 폴링 전환
 */
static irqreturn_t hw_accel_irq_handler(int irq, void *data)
{
    struct hw_accel_dev *hdev = data;

    if (hdev->completions_per_sec > POLL_THRESHOLD) {
        /* 고처리량 → 인터럽트 비활성화 + 폴링 모드 전환 */
        disable_irq_nosync(irq);
        hdev->polling = true;
        /* kthread가 폴링 루프 시작 */
        wake_up_process(hdev->poll_thread);
        return IRQ_HANDLED;
    }
    /* 일반 모드 — 인터럽트 기반 완료 */
    return hw_accel_process_irq(hdev);
}

DPDK / 유저스페이스 busy-polling — NGFW에서 DPDK 기반 데이터 플레인(VPP, Suricata AF_XDP)을 사용할 경우:

/*
 * DPDK cryptodev 폴링 모드 — 유저스페이스 busy-polling
 * rte_cryptodev_dequeue_burst()로 완료된 작업 수집
 */

/* 1. 암호화 요청 배치 제출 (enqueue) */
uint16_t enqueued = rte_cryptodev_enqueue_burst(
    cdev_id,        /* crypto device ID */
    qp_id,          /* queue pair */
    crypto_ops,     /* 요청 배열 */
    nb_ops          /* 배치 크기 (32-256) */
);

/* 2. busy-polling으로 완료 수집 (dequeue) */
uint16_t dequeued;
do {
    dequeued = rte_cryptodev_dequeue_burst(
        cdev_id, qp_id,
        completed_ops,  /* 완료된 요청 배열 */
        MAX_BURST       /* 최대 수집 수 */
    );
    /*
     * dequeued == 0: 아직 완료된 작업 없음 → 재폴링
     * 인터럽트·컨텍스트 전환 없이 즉시 재확인
     * → 지연 최소화, 단 CPU 100% 사용
     */
} while (dequeued == 0);

/* 3. 완료된 작업 처리 */
for (int i = 0; i < dequeued; i++) {
    if (completed_ops[i]->status ==
        RTE_CRYPTO_OP_STATUS_SUCCESS) {
        /* 암호화 완료 — 다음 파이프라인 단계로 전달 */
        forward_packet(completed_ops[i]->sym->m_dst);
    }
}

완료 모델 종합 비교

적응형 인터럽트 병합과 하이브리드 폴링

실무 NGFW에서는 순수 인터럽트나 순수 폴링이 아닌, 트래픽 부하에 따라 동적으로 전환하는 적응형(adaptive) 모델을 사용합니다. 리눅스 커널 NAPI(New API)가 네트워크 드라이버에서 사용하는 것과 동일한 원리입니다:

                     트래픽 부하
        낮음 ◀──────────────────────────▶ 높음
        ┌───────────┬───────────┬──────────────┐
 완료   │ 인터럽트   │ 인터럽트   │    폴링      │
 감지   │ (즉시)     │ (병합)    │ (busy-poll)  │
 방식   │           │           │              │
        ├───────────┼───────────┼──────────────┤
 IRQ    │ 요청당     │ N개 묶음  │   비활성화    │
 빈도   │ 1회       │ (coalesce)│   (0회)      │
        ├───────────┼───────────┼──────────────┤
 CPU    │ 최소       │ 낮음      │   전용 코어   │
 사용   │           │           │   100%       │
        ├───────────┼───────────┼──────────────┤
 지연   │ ~5μs      │ ~10-30μs  │   <1μs       │
        │           │ (병합     │   (즉시      │
        │           │  대기시간) │    감지)     │
        └───────────┴───────────┴──────────────┘

        ◀─ 유휴 시    적응형 전환 ──────▶ 포화 시

/*
 * 적응형 인터럽트/폴링 전환 — NAPI식 crypto 완료 처리
 * 고처리량 시 인터럽트 스톰을 방지하고 배치 처리 효율 극대화
 */
#define POLL_BUDGET      64    /* 한 번의 폴링에서 최대 처리 수 */
#define IRQ_TO_POLL_THRESH  1000  /* IRQ/초 임계치 → 폴링 전환 */
#define POLL_TO_IRQ_THRESH  100   /* 폴링 공회전 → IRQ 복귀 */

/* ── 인터럽트 핸들러: 고부하 감지 시 폴링 전환 ── */
static irqreturn_t crypto_irq_handler(int irq, void *data)
{
    struct crypto_hw_queue *q = data;

    q->irq_count++;

    if (q->irq_count > IRQ_TO_POLL_THRESH) {
        /* 인터럽트 빈도 과다 → 폴링 모드 전환 */
        disable_irq_nosync(irq);
        q->mode = CRYPTO_MODE_POLL;
        napi_schedule(&q->napi);   /* 폴링 스케줄링 */
        return IRQ_HANDLED;
    }

    /* 일반 모드: 개별 완료 처리 */
    crypto_process_completions(q, 1);
    return IRQ_HANDLED;
}

/* ── NAPI식 폴링 핸들러 ── */
static int crypto_napi_poll(struct napi_struct *napi, int budget)
{
    struct crypto_hw_queue *q =
        container_of(napi, struct crypto_hw_queue, napi);
    int completed = 0;

    /* completion ring에서 완료된 항목 배치 수집 */
    completed = crypto_poll_completions(q, budget);

    if (completed < budget) {
        /*
         * 배치 미달 → 트래픽 감소 감지
         * 폴링 종료 + 인터럽트 복원
         */
        q->idle_polls++;
        if (q->idle_polls > POLL_TO_IRQ_THRESH) {
            napi_complete(napi);
            q->mode = CRYPTO_MODE_IRQ;
            q->irq_count = 0;
            q->idle_polls = 0;
            enable_irq(q->irq_num);  /* 인터럽트 복원 */
        }
    } else {
        q->idle_polls = 0;  /* 배치 꽉 참 → 계속 폴링 */
    }
    return completed;
}

인터럽트 병합(Interrupt Coalescing) 설정 — QAT 가속기 예시:

# QAT 인터럽트 병합 설정
# /etc/sysconfig/qat 또는 sysfs 경로

# 병합 타이머: N μs 동안 완료를 모아서 단일 IRQ 발생
echo 10 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_coal_timer_ns
# 10μs 간격 → 초당 최대 100K IRQ (vs 병합 없이 수백만)

# 병합 카운트: N개 완료마다 IRQ 1회
echo 32 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_coal_count
# 32개 완료 묶음 → IRQ 횟수 1/32로 감소

# 현재 모드 확인
cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_mode
# adaptive / timer / count / poll

# ethtool로 NIC crypto 인터럽트 병합 설정 (ConnectX-7)
ethtool -C eth0 rx-usecs 10 tx-usecs 10
# 10μs 간격으로 RX/TX 인터럽트 병합

아키텍처 선택 가이드

시나리오별로 최적의 암호화 오프로드 아키텍처를 선택하는 기준:

하드웨어 이벤트 스케줄러 (Intel DLB / Marvell SSO)

NGFW 데이터 플레인에서 수백만 플로우를 다수의 CPU 코어에 효율적으로 분배하는 것은 핵심 과제입니다. RSS(Receive Side Scaling)는 해시(Hash) 기반 정적 분배만 가능하여 코어 간 부하 불균형이 발생하고, 소프트웨어 큐 관리는 잠금 경합(Lock Contention)과 캐시(Cache) 바운싱 오버헤드를 유발합니다. 하드웨어 이벤트 스케줄러는 이 문제를 전용 ASIC/SoC 블록으로 해결합니다.

대표적인 HW 이벤트 스케줄러로 Intel의 DLB(Dynamic Load Balancer)와 Marvell의 SSO(Schedule/Synchronize/Order)가 있으며, 둘 다 원자적(Atomic) 플로우 스케줄링, 순서 보장(Ordering), 동적 부하 분산(Load Balancing)을 하드웨어 수준에서 제공합니다.

이벤트 스케줄러 핵심 개념

HW 이벤트 스케줄러는 패킷을 직접 전달하지 않고, 이벤트(Event) 단위로 작업을 추상화합니다. 하나의 이벤트는 패킷 도착, 타이머(Timer) 만료, 크립토 완료 등 다양한 소스에서 발생하며, 스케줄러가 이를 워커 코어(Worker Core)에 분배합니다.

3종 스케줄링 모드가 NGFW 파이프라인에서 각각 다른 단계에 적용됩니다:

Intel DLB (Dynamic Load Balancer)

Intel DLB(이전 명칭 HQM — Hardware Queue Manager)는 4th Gen Xeon(SPR) 이후 CPU에 내장된 하드웨어 이벤트 스케줄러입니다. PCIe 디바이스로도 출시되었으며(DLB 2.0/2.5), DPDK eventdev 라이브러리를 통해 VPP, DPDK 기반 NGFW, Open vSwitch 등에서 활용됩니다.

DLB 핵심 사양:

DLB의 핵심 구성 요소:

• QID(Queue ID) — 논리적 이벤트 큐. 하나의 QID에 스케줄링 타입(atomic/ordered/parallel)과 우선순위를 설정합니다. NGFW에서는 파이프라인 단계별(방화벽(Firewall)→IPS→암호화) QID를 할당합니다
• CQ(Consumer Queue) — 워커 코어가 이벤트를 수신하는 큐. 각 코어에 1개 CQ를 바인딩하고, 폴링 또는 인터럽트로 이벤트를 가져옵니다
• PP(Producer Port) — 이벤트 소스(NIC RX, crypto 완료 등)가 이벤트를 제출하는 포트
• Credit — 흐름 제어(Flow Control) 메커니즘. Producer는 이벤트 제출 시 credit을 소모하고, Consumer가 처리 완료 후 반환합니다. Credit 고갈 시 자동 배압(backpressure) 발생
• Directed Port/Queue — 스케줄링 없이 특정 CQ에 직접 전달하는 1:1 경로. 파이프라인 단계 간 명시적 전달에 사용

DPDK eventdev를 통한 DLB 설정과 NGFW 파이프라인 구성:

/*
 * DPDK eventdev API로 DLB 기반 NGFW 파이프라인 구성
 * rte_event_dev → rte_event_queue → rte_event_port 매핑
 */
#include <rte_eventdev.h>
#include <rte_event_eth_rx_adapter.h>
#include <rte_event_crypto_adapter.h>

/* 1. DLB eventdev 초기화 */
struct rte_event_dev_config dev_conf = {
    .nb_event_queues = 4,        /* QID 4개 (FW/IPS/Crypto/TX) */
    .nb_event_ports = 8,         /* 워커 코어 8개 */
    .nb_events_limit = 4096,     /* 최대 동시 이벤트 수 */
    .nb_event_queue_flows = 1024,/* 플로우 해시 엔트리 수 */
    .nb_event_port_dequeue_depth = 32,
    .nb_event_port_enqueue_depth = 32,
};
rte_event_dev_configure(evdev_id, &dev_conf);

/* 2. 파이프라인 단계별 QID 설정 */
struct rte_event_queue_conf q_conf;

/* QID 0: 방화벽 (Atomic — conntrack 상태 보호) */
q_conf.schedule_type = RTE_SCHED_TYPE_ATOMIC;
q_conf.priority = RTE_EVENT_DEV_PRIORITY_HIGHEST;
q_conf.nb_atomic_flows = 1024;   /* 동시 추적 플로우 수 */
rte_event_queue_setup(evdev_id, 0, &q_conf);

/* QID 1: IPSec 암복호화 (Ordered — 순서 보장 + 병렬) */
q_conf.schedule_type = RTE_SCHED_TYPE_ORDERED;
q_conf.priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
rte_event_queue_setup(evdev_id, 1, &q_conf);

/* QID 2: IPS/DPI (Parallel — 최대 처리량) */
q_conf.schedule_type = RTE_SCHED_TYPE_PARALLEL;
rte_event_queue_setup(evdev_id, 2, &q_conf);

/* QID 3: TX (Directed — 특정 TX 코어로 직접 전달) */
/* Directed는 별도 API로 설정 */

/* 3. 워커 포트 설정 — 각 코어에 CQ 바인딩 */
struct rte_event_port_conf p_conf = {
    .dequeue_depth = 32,
    .enqueue_depth = 32,
    .new_event_threshold = 128,  /* credit 기반 배압 임계치 */
};
for (int i = 0; i < 8; i++) {
    rte_event_port_setup(evdev_id, i, &p_conf);
    /* 포트 i → QID 0,1,2 매핑 (어떤 단계든 처리 가능) */
    rte_event_port_link(evdev_id, i, queues, priorities, 3);
}

/* 4. NIC RX → DLB 이벤트 어댑터 연결 */
rte_event_eth_rx_adapter_create(rx_adapter_id, evdev_id, &p_conf);
rte_event_eth_rx_adapter_queue_add(rx_adapter_id,
    eth_port_id, -1, /* 모든 RX 큐 */
    &(struct rte_event_eth_rx_adapter_queue_conf){
        .ev.queue_id = 0,    /* 첫 단계: FW QID */
        .ev.sched_type = RTE_SCHED_TYPE_ATOMIC,
        .ev.flow_id = 0,     /* RSS 해시를 flow_id로 사용 */
    });
rte_event_eth_rx_adapter_start(rx_adapter_id);

/* 5. 워커 루프 — 이벤트 수신·처리·전달 */
static void worker_loop(uint8_t port_id)
{
    struct rte_event events[32];
    while (!quit) {
        uint16_t nb = rte_event_dequeue_burst(
            evdev_id, port_id, events, 32, 0 /* no wait */);

        for (int i = 0; i < nb; i++) {
            struct rte_mbuf *pkt = events[i].mbuf;
            uint8_t cur_qid = events[i].queue_id;

            switch (cur_qid) {
            case 0: /* 방화벽 단계 — Atomic */
                if (firewall_check(pkt) == FW_PASS) {
                    /* 다음 단계(Crypto)로 전달 */
                    events[i].queue_id = 1;
                    events[i].op = RTE_EVENT_OP_FORWARD;
                } else {
                    rte_pktmbuf_free(pkt);
                    events[i].op = RTE_EVENT_OP_RELEASE;
                }
                break;

            case 1: /* IPSec 단계 — Ordered */
                ipsec_process(pkt);
                events[i].queue_id = 2;
                events[i].op = RTE_EVENT_OP_FORWARD;
                /* DLB가 자동으로 원래 순서 복원 */
                break;

            case 2: /* IPS/DPI 단계 — Parallel */
                ips_inspect(pkt);
                /* TX로 직접 전송 */
                rte_eth_tx_burst(tx_port, 0, &pkt, 1);
                events[i].op = RTE_EVENT_OP_RELEASE;
                break;
            }
        }
        rte_event_enqueue_burst(evdev_id, port_id, events, nb);
    }
}

# DLB 디바이스 확인
lspci | grep -i "dynamic load balancer"
# 6b:00.0 System peripheral: Intel Corporation
#         Dynamic Load Balancer (DLB) [8086:2710]

# 커널 드라이버 로드
modprobe dlb2
ls /dev/dlb*    # /dev/dlb0, /dev/dlb1, ...

# sysfs에서 DLB 리소스 확인
cat /sys/class/dlb2/dlb0/total_resources
# num_sched_domains: 32
# num_ldb_queues: 96
# num_ldb_ports: 64
# num_dir_ports: 96
# num_ldb_credits: 16384

# DPDK에서 DLB eventdev 바인딩
dpdk-devbind.py -b vfio-pci 0000:6b:00.0
# EAL 파라미터
--vdev=event_dlb2 --allow=0000:6b:00.0

Marvell OCTEON SSO (Schedule/Synchronize/Order)

Marvell OCTEON SSO는 OCTEON TX2/CN10K SoC에 내장된 하드웨어 이벤트 스케줄러입니다. Intel DLB와 유사한 기능을 제공하지만, SoC 내부의 모든 HW 가속기(크립토, 정규식, 압축)와 내부 버스로 직접 연동되는 것이 핵심 차이입니다. 패킷이 NIC에서 수신되면 SSO를 거쳐 CPU 코어에 분배되고, 크립토 처리 완료 후 다시 SSO로 돌아와 다음 단계 코어로 전달됩니다.

SSO 핵심 사양 (CN10K 기준):

SSO의 DLB 대비 핵심 차별점:

• HW 가속기 직접 연동: CPT(크립토), REE(정규식), ZIP(압축) 완료 시 자동으로 SSO 이벤트가 생성됩니다. DLB는 CPU가 가속기 완료를 확인한 뒤 이벤트를 재제출해야 하지만, SSO는 CPU 개입 없이 파이프라인이 진행됩니다
• WQE(Work Queue Entry): 패킷 메타데이터와 처리 컨텍스트를 포함하는 HW 구조체(Struct). NIC(RPM)이 패킷 수신 시 자동 생성하여 SSO에 제출합니다
• SWTAG(Software Tag Switch): 워커가 처리 중 태그 타입을 동적으로 변경할 수 있습니다. 예: conntrack 조회 시 Atomic → 패턴 매칭 시 Ordered로 전환
• TIM(Timer Wheel): HW 타이머가 만료되면 SSO 이벤트로 자동 전환. 세션 타임아웃 처리에 CPU 타이머 인터럽트 불필요

SSO를 활용한 NGFW 이벤트 드리븐 파이프라인:

/*
 * OCTEON CN10K SSO 기반 NGFW 파이프라인
 * DPDK eventdev API (event_cnxk 드라이버)
 *
 * 파이프라인: NIC RX → [SSO] → FW(Atomic) → [SSO] →
 *            CPT(Crypto) → [SSO] → IPS(Ordered) → TX
 */

/* 1. SSO 이벤트 수신 — MMIO GET_WORK */
static void sso_worker_loop(uint8_t port_id)
{
    struct rte_event ev;
    while (!quit) {
        /* SSO에서 이벤트 수신 (HW 폴링, ~10ns 지연) */
        if (rte_event_dequeue_burst(evdev_id, port_id,
                                     &ev, 1, 0) == 0)
            continue;

        struct rte_mbuf *pkt = ev.mbuf;
        uint32_t tag = ev.flow_id;  /* 플로우 해시 */

        switch (ev.queue_id) {
        case SSO_GRP_FIREWALL:  /* Atomic 모드 */
            /*
             * 동일 tag(flow)의 이벤트는 이 코어에서만 처리됨
             * → conntrack 조회/갱신에 락 불필요!
             */
            if (conntrack_lookup(tag, pkt) == CT_NEW) {
                conntrack_insert(tag, pkt);  /* lock-free */
            }
            if (!acl_check(pkt)) {
                rte_pktmbuf_free(pkt);
                ev.op = RTE_EVENT_OP_RELEASE;
                break;
            }

            /* IPSec 필요 시 → CPT(크립토)로 전달 */
            if (needs_ipsec(pkt)) {
                /*
                 * SSO → CPT 직접 전달 (CPU 미개입)
                 * CPT 완료 시 자동으로 SSO 이벤트 재생성
                 * → SSO_GRP_POST_CRYPTO 그룹으로 도착
                 */
                submit_to_cpt(pkt, SSO_GRP_POST_CRYPTO);
                ev.op = RTE_EVENT_OP_RELEASE;
            } else {
                ev.queue_id = SSO_GRP_IPS;
                ev.op = RTE_EVENT_OP_FORWARD;
                /* SWTAG: Atomic → Ordered 전환 */
                ev.sched_type = RTE_SCHED_TYPE_ORDERED;
            }
            break;

        case SSO_GRP_POST_CRYPTO:  /* CPT 완료 이벤트 */
            /*
             * CPU가 CPT를 폴링하지 않음!
             * HW가 암호화 완료 → SSO에 이벤트 자동 생성
             */
            ev.queue_id = SSO_GRP_IPS;
            ev.sched_type = RTE_SCHED_TYPE_ORDERED;
            ev.op = RTE_EVENT_OP_FORWARD;
            break;

        case SSO_GRP_IPS:  /* Ordered 모드 */
            ips_pattern_match(pkt);
            /* NIX TX로 직접 전송 — 순서 자동 보장 */
            ev.queue_id = SSO_GRP_TX;
            ev.op = RTE_EVENT_OP_FORWARD;
            break;
        }

        rte_event_enqueue_burst(evdev_id, port_id, &ev, 1);
    }
}

/* 2. HW 타이머를 이용한 세션 타임아웃 */
static void setup_session_timeout(uint32_t flow_tag,
                                   uint64_t timeout_ns)
{
    /*
     * OCTEON TIM(Timer Wheel)에 타이머 등록
     * 만료 시 SSO 이벤트로 자동 변환 → CPU 인터럽트 불필요
     */
    struct rte_event_timer tim = {
        .ev.queue_id = SSO_GRP_TIMEOUT,
        .ev.sched_type = RTE_SCHED_TYPE_ATOMIC,
        .ev.flow_id = flow_tag,
        .timeout_ticks = timeout_ns / tim_tick_ns,
        .state = RTE_EVENT_TIMER_ARMED,
    };
    rte_event_timer_arm_burst(timer_adapter_id, &tim, 1);
    /* timeout_ns 후 SSO_GRP_TIMEOUT에 이벤트 도착 */
}

DLB vs SSO 종합 비교

NGFW 파이프라인에서의 이벤트 스케줄러 활용

기존 NGFW 데이터 플레인은 run-to-completion(단일 코어가 패킷을 끝까지 처리) 또는 SW 파이프라인(SW 큐로 단계 간 전달) 모델을 사용합니다. HW 이벤트 스케줄러는 이를 HW 파이프라인으로 대체하여 잠금 경합·캐시 미스·부하 불균형을 제거합니다.

 NGFW 이벤트 드리븐 파이프라인 예시 (DLB/SSO 공통)

 ┌──────────┐     ┌─────────┐     ┌──────────┐     ┌─────────┐
 │  NIC RX  │────▶│  HW     │────▶│  Stage 1 │────▶│  HW     │
 │ (패킷    │     │  Event  │     │ conntrack│     │  Event  │
 │  수신)   │     │  Sched  │     │ + ACL    │     │  Sched  │
 └──────────┘     │ [Atomic]│     │ (lock-   │     │[Ordered]│
                  └─────────┘     │  free)   │     └────┬────┘
                                  └──────────┘          │
                  ┌─────────────────────────────────────┘
                  │
                  ▼
 ┌──────────┐     ┌─────────┐     ┌──────────┐     ┌─────────┐
 │ Stage 2  │────▶│  HW     │────▶│  Stage 3 │────▶│  NIC TX │
 │ IPSec    │     │  Event  │     │  IPS/DPI │     │ (패킷   │
 │ 암복호화 │     │  Sched  │     │ 시그니처 │     │  송신)  │
 │ (QAT/CPT)│     │[Parallel│     │  매칭    │     └─────────┘
 └──────────┘     │ or Auto]│     └──────────┘
   ↑ HW 완료 시   └─────────┘      순서 복원은
   SSO: 자동 이벤트                  HW reorder 버퍼가
   DLB: SW re-enqueue              자동 처리

Fortinet NP7 / CP9 / SoC5 계열

Fortinet FortiGate는 제품군에 따라 구현이 다르지만, 공개 자료 기준으로 보면 세션 전달용 Network Processor와 검사용 보안/콘텐츠 프로세서를 결합한 하이브리드 구조입니다. 고성능 chassis/데이터센터 계열은 NP7 계열이 inline fast path를 맡고, SSL Inspection과 콘텐츠 검사는 별도 inspection 경로가 담당합니다. 브랜치 SoC 장비는 SoC5(문서상 SP5/NP7Lite 언급 포함)처럼 동일 SoC 내부에 해당 기능이 더 밀집되어 있어 SoC중심 lookaside에 가까운 하이브리드로 보는 편이 정확합니다:

• NP7 / NP6 계열 (Network Processor) — [Inline] L2~L4 세션 오프로드, NAT, IPSec/VXLAN/GRE fast path. Session table에 ESTABLISHED 세션을 등록하면 이후 패킷이 NP에서 직접 전달됩니다.
• CP9 / CP10 및 보안 프로세서 경로 — [Lookaside 또는 SoC 내부 inspection path] 프록시 기반 SSL/TLS 검사, 콘텐츠 검사, 파일/패턴 매칭을 보조합니다.
• SoC5 / NP7Lite 계열 — [SoC-Centric Hybrid] 네트워크 처리와 inspection 가속기가 같은 패키지 안에 결합되어 branch 모델의 전력과 지연을 줄입니다.

NP7 세션 오프로드 프로세스

FortiGate에서 세션이 NP7으로 오프로드되는 과정:

1. 첫 패킷: CPU(IPS Engine)가 수신 → conntrack + UTM(IPS/AV/App Control) 전체 검사
2. 세션 수립: 검사 통과 시 CPU가 ISF(Iterate Session Filter)에 오프로드 결정 쿼리
3. NP7 등록: session_offload_add() → NP7 Session Table에 5-tuple + NAT 정보 + QoS 태그 기록
4. 후속 패킷: NP7 ASIC이 Session Table lookup → NAT rewrite → QoS → forwarding (CPU bypass)
5. 세션 종료: TCP FIN/RST → NP7이 CPU에 알림 → Session Table 삭제 → 통계 동기화

# FortiGate 진단 명령
diagnose npu np7 session-stats         # NP7 오프로드 세션 통계
diagnose npu np7 sse-stats all         # Session Search Engine 통계
diagnose npu np7 port-list             # NP7 포트 매핑 확인
diagnose sys session filter dport 443  # 특정 포트 세션 확인
get system performance firewall statistics # 전체 성능 통계

# NP7 오프로드 비율 확인
diagnose npu np7 session-stats
# 출력 예:
# NP7 offload sessions: 1,234,567
# CPU sessions: 12,345
# Offload ratio: 99.0%

# 특정 세션의 오프로드 상태 확인
diagnose sys session filter src 10.0.0.1
diagnose sys session list
# 출력에서 npu_state=offloaded 확인

Fortinet 보안 프로세서/SoC inspection 경로

Fortinet 공개 자료는 제품군에 따라 CP9/CP10, SoC5, 보안 프로세서 등 서로 다른 명칭을 사용합니다. 공통점은 세션 전달용 NP fast path와 별도의 inspection 암호화 경로가 존재하는 점입니다. CPU가 TLS 정책과 평문 검사를 총괄하되, 핸드셰이크와 레코드 암·복호화의 상당 부분을 이 inspection 경로가 보조합니다.

Fortinet SSL Deep Inspection 파이프라인

FortiGate가 SSL Deep Inspection(SSL 딥 인스펙션)을 수행할 때의 내부 패킷 흐름입니다:

1. 클라이언트 → FortiGate TLS 핸드셰이크: inspection 경로가 ECDHE/RSA 키 교환을 보조하고, FortiGate의 CA 인증서로 서버 인증서를 동적 생성하여 클라이언트에 제공합니다.
2. FortiGate → 서버 TLS 핸드셰이크: inspection 경로가 실제 서버와 별도의 TLS 세션을 수립하고 서버 인증서를 검증합니다.
3. 데이터 복호화: inspection 경로가 클라이언트 TLS 세션의 레코드를 하드웨어에서 복호화하고, 평문을 CPU(IPS 엔진)에 전달합니다.
4. DPI/IPS 검사: CPU + CP 계열 가속기가 평문에 대해 App Control, IPS 시그니처 매칭, AV 스캔, DLP를 수행합니다.
5. 재암호화: inspection 경로가 서버 TLS 세션용 레코드로 재암호화하고, 이후 패킷이 NP로 전달됩니다.

# FortiGate SSL Inspection 진단 명령
diagnose sys session filter proto 6 dport 443
diagnose sys session list
# 출력에서 확인할 항목:
# npu_state=0 (SSL Inspection 세션은 offload 안 됨)
# ssl_action=deep-inspection
# ssl_cipher=ECDHE-RSA-AES256-GCM-SHA384

# SSL Inspection 통계
get system performance firewall statistics
# SSL proxy 관련 카운터와 전체 처리량은 FortiOS/모델별 출력 항목 확인

# SSL Inspection 정책 설정
config firewall ssl-ssh-profile
  edit "deep-inspect"
    set ssl-anomaly-log enable
    config https
      set ports 443
      set status deep-inspection
      set cert-validation-timeout 30
    end
  next
end

# NP7 오프로드와 SSL inspection 경로 분리 확인
diagnose npu np7 session-stats
# 비-SSL fast path 세션은 NP7 카운터에서 증가하고, deep-inspection 세션은 session list에서 별도 확인

NP7의 IPSec 암호화 처리 상세

NP7은 IPSec VPN 트래픽에 대해 ESP 패킷의 전체 처리(캡슐화(Encapsulation) + 암호화 + 포워딩)를 하드웨어에서 수행합니다:

Palo Alto Networks SP3

Palo Alto Networks의 공개 자료는 SP3(Single-Pass Parallel Processing)의 핵심을 분리된 control plane/data plane, 병렬 처리 하드웨어, single-pass 소프트웨어로 설명합니다. 따라서 세션 fast path는 장비 내부 dataplane hardware가 inline으로 처리하지만, SSL/TLS 복호화와 평문 검사는 Fortinet이나 Juniper처럼 분리된 전용 SSL ASIC보다 dataplane CPU 자원에 밀착된 CPU중심 lookaside로 해석하는 편이 정확합니다. 다시 말해, 세션 분류는 inline이고 decryption은 SP3 파이프라인 안에서 CPU가 소화합니다:

• Single-Pass Parallel Processing — [Inline CPU] 패킷이 한 번의 통과로 FW, App-ID, IPS, URL 필터링을 병렬 처리
• NPC (Network Processing Card) — 고성능 모델에 추가 가능한 데이터 플레인 카드
• Dataplane packet-processing hardware — [Inline] 세션 테이블 lookup, NAT rewrite, 포워딩을 모델별 dataplane에서 가속
• Dataplane CPU 코어에서 App-ID/DPI/decryption을 처리하고, packet-processing 하드웨어가 세션 분류와 패킷 전달을 보조합니다.

Single-Pass 아키텍처 상세

Palo Alto의 핵심 차별점은 Single-Pass Parallel Processing (SP3) 아키텍처입니다:

Packet-processing hardware의 역할: 공개 자료 수준에서는 세션 분류, 포워딩, NAT, dataplane 병렬 처리를 보조하는 하드웨어로 해석하는 것이 안전합니다. App-ID, Threat Prevention, SSL Forward Proxy는 single-pass dataplane 소프트웨어와 CPU 자원을 사용하므로, 검사 대상 세션이 CPU를 완전히 bypass한다고 단정하면 안 됩니다.

Palo Alto SSL 복호화 아키텍처

Palo Alto 공개 자료에서 SSL Forward Proxy는 클라이언트-방화벽, 방화벽-서버의 두 TLS 세션을 만들고 보안 정책과 decryption profile을 적용하는 방식입니다. 독립 SSL ASIC 명칭이 공개되어 있지 않으므로, SSL 복호화 성능은 dataplane CPU, 모델별 하드웨어, 정책 프로필이 결합된 결과로 보는 편이 정확합니다.

Palo Alto의 접근법은 Fortinet처럼 NP/CP/SoC 계열 가속기를 강하게 전면화하는 방식과 다릅니다. 장점: single-pass 정책 처리와 PAN-OS 기능 통합이 명확합니다. 주의점: SSL 활성화 시 처리량은 모델별 SSL decryption 데이터시트와 실제 decryption profile 조건으로 별도 확인해야 합니다.

# Palo Alto SSL 복호화 진단 명령
show counter global filter delta yes | match ssl
# ssl_proxy_session_new: 연결/초 (CPS)
# ssl_proxy_session_active: 현재 활성 SSL 세션
# ssl_decrypt_success: 복호화 성공 패킷
# ssl_decrypt_fail: 복호화 실패 (cipher 미지원 등)
# ssl_cert_verify_fail: 인증서 검증 실패

show session all filter ssl-decrypt yes
# SSL 복호화 중인 세션 목록

show system resources
# CPU 사용률 확인 → SSL 활성 시 증가폭

# SSL 복호화 정책 설정 (PAN-OS)
set rulebase decryption rules "decrypt-outbound" {
    from any; to any;
    source any; destination any;
    service any; action decrypt;
    type { ssl-forward-proxy { }; };
    profile "default";
}

# SSL 복호화 프로파일
set profiles decryption "strict" {
    ssl-forward-proxy {
        block-expired-certificate yes;
        block-untrusted-issuer yes;
        block-unsupported-version yes;
        block-unsupported-cipher yes;
        min-version tls1-2;
    };
}

# Palo Alto CLI 진단 명령
show running resource-monitor           # CPU/메모리/세션 사용률
show session all filter state active    # 활성 세션 목록
show session info                       # 세션 통계 (CPS, CC)
show counter global filter delta yes \
  packet-filter yes                     # 실시간 카운터
debug dataplane packet-diag set filter \
  match src 10.0.0.1                    # 특정 IP 패킷 추적

Check Point SecureXL / Maestro

Check Point는 SecureXL/CoreXL 중심의 소프트웨어 기반 inline 가속 아키텍처를 사용합니다. 일부 제품군은 Lightspeed 계열 가속으로 L4 방화벽 fast path를 강화하지만, 공개 자료 기준으로 범용 HTTPS Inspection의 TLS 레코드 처리까지 전용 SSL ASIC이 대신한다고 보기는 어렵습니다. 따라서 HTTPS Inspection은 CPU/CoreXL 중심 경로로 분류하는 편이 안전합니다:

• SecureXL — [Inline 커널] 커널 레벨 가속. Accept Template(ESTABLISHED 세션 direct forward)과 Drop Template(미리 차단 목록)으로 CPU 부하를 줄입니다.
• CoreXL — [Inline CPU] 멀티코어 병렬 처리. SND(Secure Network Distributor)가 RSS처럼 코어 간 패킷을 분배합니다.
• Maestro HyperScale — 여러 Security Gateway를 하나의 논리 장비로 클러스터링하여 수평 확장
• SSL/IPSec — [CPU/CoreXL 중심] 범용 CPU AES-NI와 SecureXL/CoreXL 경로로 처리합니다. 모델별 가속 카드가 있더라도 HTTPS Inspection 성능은 공식 데이터시트와 실제 프로필 조건으로 확인해야 합니다.

SecureXL 처리 경로 상세

SecureXL은 3가지 처리 경로(Accelerated Path, Medium Path, Firewall Path)로 패킷을 분류합니다:

Accept Template은 Linux conntrack의 ESTABLISHED + flowtable 개념과 유사합니다. conntrack이 세션 상태를 추적하고, Accept Template이 검사가 완료된 세션의 5-tuple을 커널 가속 테이블에 등록합니다. Drop Template은 이미 DROP 판정이 난 소스 IP/포트를 캐시하여, 동일한 악성 트래픽이 재전송(Retransmission)될 때 CPU까지 가지 않고 즉시 DROP합니다.

CoreXL / SND 아키텍처

Check Point의 멀티코어 아키텍처는 Linux의 RSS/RPS와 유사하지만 보안에 최적화되어 있습니다:

• SND (Secure Network Distributor) — 전용 코어가 NIC에서 패킷을 수신하여 CoreXL 인스턴스에 분배. CPU affinity 기반으로 세션을 고정 코어에 할당
• CoreXL FW Instance — 각 코어가 독립적인 FW 인스턴스를 실행. 세션 테이블은 공유하되, 처리는 병렬
• Multi-Queue — SND가 NIC의 RSS 큐를 활용하여 하드웨어 수준 분산

# Check Point 진단 명령 (Gaia OS)
fwaccel stat                            # SecureXL 가속 통계
fwaccel stats -s                        # 경로별 패킷/바이트 통계
fwaccel conns                           # Accept Template 연결 수
fw ctl multik stat                      # CoreXL 인스턴스별 통계
cpview                                  # 실시간 성능 모니터 (TUI)

# SecureXL 비활성화/활성화 (성능 비교 테스트)
fwaccel off     # 가속 비활성화 → 전체 Firewall Path
fwaccel on      # 가속 재활성화

# 특정 세션의 처리 경로 확인
fw ctl zdebug + drop    # 디버그 로그

Check Point HTTPS Inspection 아키텍처

Check Point는 Fortinet(CP/SoC inspection 경로)이나 전용 크립토 ASIC 없이 순수 소프트웨어 기반의 HTTPS Inspection을 수행합니다. CoreXL의 멀티코어 병렬 처리와 SecureXL의 가속 경로를 조합하여 성능을 최적화합니다.

SecureXL과 HTTPS Inspection의 관계: HTTPS Inspection이 활성화되면 해당 세션은 Firewall Path(가장 느린 경로)에서 처리됩니다. Accelerated Path로 승격될 수 없으므로, HTTPS Inspection 비율이 높을수록 SecureXL 가속 효과가 감소합니다.

# Check Point HTTPS Inspection 진단
fwaccel stat
# Accelerated Conns: 1,200,000
# HTTPS Inspect Conns: 45,000 (Firewall Path)
# → HTTPS Inspection 세션은 Accelerated Path 불가

# HTTPS Inspection 통계
cpstat -f https_inspection fw
# Total inspected connections: 45,000
# Bypassed connections: 5,000 (bypass 규칙 적용)
# Certificate cache hit ratio: 85%

# CoreXL 인스턴스별 SSL 부하 분포
fw ctl multik stat
# 각 CoreXL 인스턴스의 CPU 사용률 확인
# HTTPS Inspection 활성 시 불균형 주의

# HTTPS Inspection 바이패스 규칙 (성능 최적화)
# SmartConsole → Security Policies → HTTPS Inspection
# 금융/의료 사이트, Windows Update 등 → Bypass 권장

Juniper Express Path

Juniper SRX 시리즈의 Express Path는 fast-path 패킷을 flow daemon이 아닌 network processor 경로에서 처리하도록 설계된 가속 기능입니다. SRX5000 계열은 NP/PFE 기반 전달 경로와 SPC(Service Processing Card) 서비스 경로를 조합합니다. IPSec, SSL Proxy, UTM 처리는 플랫폼·카드·라이선스·정책에 따라 서비스 처리 경로를 사용하므로, 모든 SSL 암호화가 SPC3의 특정 엔진에서 전담된다고 단정하면 안 됩니다:

• Express Path — [Inline] 확립된 세션의 패킷을 flowd를 bypass하여 NP에서 forwarding
• Services Processing Card / SPU 경로 — [Service path] IPSec, SSL Proxy, UTM 같은 서비스 처리를 담당합니다. 실제 암호화 가속 범위와 처리량은 카드·Junos 버전·기능 조합별 공식 문서로 확인해야 합니다.

Express Path 동작 원리

Juniper SRX의 패킷 처리 아키텍처:

1. NP (Network Processor): 모든 패킷의 1차 수신. 세션 테이블에서 lookup
2. Express Path 히트: 기존 세션 매칭 → NP에서 직접 forwarding + NAT rewrite (flowd bypass)
3. Express Path 미스: 새 세션 → flowd(flow daemon)로 전달 → 정책 평가 + IPS/AppID
4. 세션 설치: flowd가 정책 통과 시 세션을 NP Express Path 테이블에 등록

# Juniper SRX 진단 명령
show security flow statistics           # 플로우 통계 (Express Path 비율)
show security monitoring fpc 0          # FPC별 세션/처리량
show security flow session              # 세션 테이블
show security flow session summary      # 세션 요약 (활성/최대)

# Express Path 상태 확인
show pfe statistics traffic
# express-path-packets, slow-path-packets 비교

# Services Offload Engine 상태
show chassis fpc pic-status

SPC3 (Services Processing Card) 암호화 가속

Juniper SRX 5000 시리즈는 SPC3 같은 서비스 카드를 통해 보안 서비스 처리 용량을 확장합니다. 공개 문서는 SRX5800 섀시, SPC3 카드, Express Path, Inline IPsec, SSL Proxy 기능을 각각 설명하지만, 카드 내부 crypto engine별 TLS CPS나 인증서 캐시 구조를 일관된 공개 수치로 제공하지 않습니다.

# Juniper SRX SPC3 암호화 관련 진단
show security ipsec statistics
# ESP 암·복호화 패킷/바이트 통계

show security ipsec sa
# SA 목록 + 하드웨어 가속 여부

show services ssl proxy statistics
# SSL Proxy 세션 수, CPS, 처리량

show chassis fpc 0 pic 0
# SPC3 카드 상태 + 크립토 엔진 사용률

# SPC3 IPSec 오프로드 설정
set security ipsec vpn site-a {
    ike {
        gateway gw-site-a;
        ipsec-policy ipsec-pol;
    }
    establish-tunnels immediately;
}
# SPC3가 자동으로 IPSec 처리를 하드웨어에서 수행

SPC3 SSL Forward Proxy 핸드셰이크 처리

Juniper SRX의 SSL Forward Proxy는 클라이언트 측 TLS 세션과 서버 측 TLS 세션을 분리하여 복호화, 보안 검사, 재암호화를 수행합니다. 이 처리는 Express Path의 단순 fast-path 전달과 다른 서비스 처리 경로이며, SPC/SPU 자원과 flowd 정책 처리, 지원 cipher/group 조건이 함께 영향을 줍니다.

Cisco Secure Firewall 4200 / FTD / Snort 3

Cisco Secure Firewall 계열은 ASA 계열의 stateful firewall 처리(LINA), FTD(Threat Defense) 정책 처리, Snort 3 DPI 엔진, crypto accelerator, flow offload를 결합합니다. 4200 Series 공식 데이터시트는 multi-threaded Snort 3 engine, cryptographic acceleration architecture, TLS hardware decryption, 최대 16-node cluster, 400G interface option을 공개합니다. 따라서 Cisco의 고성능 구조는 "모든 패킷을 Snort로 보냅니다"가 아니라, 먼저 L3/L4에서 fast path/offload 가능성을 판정하고, 복호화가 필요한 TLS/VPN 비용을 crypto accelerator로 낮춘 뒤, 실제 위협 판단은 Snort 3 worker에 병렬 분산하는 방식으로 이해해야 합니다.

Sophos XGS / Xstream FastPath

Sophos XGS 계열은 Fortinet의 NP/CP 조합이나 Palo Alto의 섀시형 NPC/DPC 구조와 달리, multi-core x86 CPU와 Xstream Flow Processor를 결합한 dual-processor appliance 구조입니다. Sophos Firewall 21.5 공식 문서는 데이터 경로를 SlowPath, DPI Engine, offload module, FastPath로 나누어 설명합니다. 핵심은 첫 패킷과 보안 판정은 CPU/SlowPath/DPI Engine이 수행하고, 신뢰된 후속 흐름과 일부 crypto 작업만 FastPath/Xstream Flow Processor로 넘겨 CPU를 절약하는 방식입니다.

XGS 8500 공식 성능 수치와 조건

Sophos XGS 2U 공식 페이지의 XGS 8500 수치는 다음과 같습니다. 이 수치는 vendor datasheet 조건이므로, Fortinet/Palo Alto/Check Point/Juniper/Cisco 수치와 직접 순위 비교하지 않고 조건별로 분리해 봐야 합니다.

Sophos 오프로드 결정 흐름

1. 초기 수신: 패킷이 XGS 포트로 들어오면 SlowPath의 firewall stack과 user space module이 세션 상태, 정책, NAT, 라우팅을 평가합니다.
2. 보안 검사 필요성 판단: 웹/앱/IPS/TLS/멀웨어 검사가 필요한 흐름은 DPI Engine으로 전달됩니다. DPI Engine은 DAQ 계층을 통해 stream을 받고, 보안 판정과 offload 가능성을 결정합니다.
3. Firewall acceleration: 초기 패킷 검사 후 신뢰된 흐름은 FastPath로 넘어가며, FastPath는 매 패킷마다 전체 firewall processing을 반복하지 않도록 stateful tracking으로 처리합니다.
4. PKI acceleration: TLS Inspection에서 X.509 서버 인증서를 재서명해야 하는 qualifying flow는 Xstream Flow Processor의 crypto hardware로 PKI 작업을 넘길 수 있습니다. 공식 문서가 명시한 항목은 certificate re-signing이며, inspected TLS flow의 AES-GCM 레코드 전체가 NPU에서 line-rate로 처리된다고 확대 해석하면 안 됩니다.
5. IPsec acceleration: XFRM stack이 Phase 2 SA를 기준으로 FastPath에 IPsec encryption/decryption offload를 지시합니다. 3DES, Blowfish, MD5 조합은 offload 대상에서 제외됩니다.
6. Fallback: FastPath가 처리할 수 없는 프로토콜과 조건은 SlowPath로 남습니다. 공식 문서는 IP in IP 같은 미지원 프로토콜, SSL VPN, proxies/WAF, QoS/DoS, wireless/RED/LAG/PPPoE, IP fragmentation, packet capture 등을 제한 조건으로 제시합니다.

Sophos FastPath/PKI/IPsec 확인 명령

# Firewall acceleration 상태 확인 및 제어
system firewall-acceleration show
system firewall-acceleration enable
system firewall-acceleration disable

# PKI acceleration은 IPS/DPI 설정에 속합니다.
show ips-settings
set ips pki-acceleration enable
set ips pki-acceleration disable

# IPsec SA offload 상태 확인 및 제어
system ipsec-acceleration show
system ipsec-acceleration enable
system ipsec-acceleration disable

Linux 커널 기반 NGFW

Linux 커널과 오픈소스 도구를 조합하여 NGFW를 구축하는 접근법입니다. Inline SmartNIC + Lookaside SW 하이브리드 모델로, EST 세션은 SmartNIC eSwitch가 inline 처리(라인레이트)하고, DPI는 NFQUEUE를 통해 유저스페이스 Suricata에 위임(lookaside)합니다. 암호화는 NIC inline crypto 또는 QAT lookaside를 선택할 수 있습니다:

• nftables + NFQUEUE + Suricata — [Lookaside] 커널 네이티브 방화벽 + 유저스페이스 DPI
• nf_flowtable + SmartNIC — [Inline] eSwitch FDB HW offload로 EST 세션 라인레이트 가속
• IPSec (xfrm) — [Inline] NIC inline crypto 또는 [Lookaside] QAT 가속
• kTLS — [Inline] NIC TLS offload 또는 [Lookaside] QAT 가속
• VPP 기반 대안 — FD.io VPP의 유저스페이스 데이터 플레인으로 Netfilter 대신 패킷 처리

Linux NGFW 스택 구성

Linux 커널 기반 NGFW를 상용 수준으로 구축하기 위한 전체 스택:

VPP 기반 NGFW 데이터 플레인

FD.io VPP를 사용하면 커널 Netfilter 대신 유저스페이스에서 패킷 처리하여 더 높은 성능을 달성합니다:

• 장점: 벡터 패킷 처리(batch), DPDK 기반 NIC 접근, 커널 overhead 제거 → 단일 코어 40Gbps+
• 단점: 커널 네트워크 스택(Network Stack)(conntrack, nftables, flowtable)을 사용할 수 없음. VPP 자체 ACL/NAT 플러그인 사용
• 하이브리드 접근: VPP가 Fast Path를 처리하고, 새 세션만 TAP 인터페이스를 통해 커널/Suricata로 전달

# VPP 기반 NGFW 설정 예시
# /etc/vpp/startup.conf
dpdk {
  dev 0000:03:00.0 { name eth0 }
  dev 0000:03:00.1 { name eth1 }
}

# VPP CLI에서 ACL + session 설정
vppctl acl-plugin acl add permit+reflect \
  src 10.0.0.0/8 dst 0.0.0.0/0 proto tcp
vppctl set acl-plugin interface eth0 input acl 0

# 새 세션만 TAP으로 전달 (DPI)
vppctl create tap id 0
vppctl set interface state tap0 up

Linux NGFW SSL/TLS 검사 아키텍처

Linux 기반 NGFW에서 SSL/TLS 검사는 여러 오픈소스 컴포넌트를 조합하여 구현합니다. 상용 NGFW와 달리 단일 통합 솔루션이 아닌 계층별 독립 도구의 조합이며, 각 계층에서 inline/lookaside HW 가속을 선택적으로 적용할 수 있습니다.

SSL 검사 아키텍처 선택지

Linux NGFW에서 SSL/TLS 트래픽을 검사하는 대표적인 3가지 아키텍처입니다:

벤더별 SSL/TLS 핸드셰이크 처리 비교

모든 NGFW의 SSL/TLS Inspection은 MITM(Man-in-the-Middle) TLS Proxy 방식입니다. 클라이언트와 서버 사이에 두 개의 독립된 TLS 세션을 수립하고, NGFW가 중간에서 복호화 → DPI → 재암호화를 수행합니다. 벤더 간 차이는 각 TLS 핸드셰이크 단계의 처리 위치(CPU vs 전용 HW)와 처리 방식(inline vs lookaside)에 있습니다.

TLS 핸드셰이크 단계별 벤더 비교

SSL/TLS 처리 성능 비교

상용 NGFW 암호화 처리 비교

암·복호화 트래픽 관점에서 각 벤더의 아키텍처를 비교합니다. SSL/TLS Inspection과 IPSec VPN 처리는 NGFW 성능에서 가장 큰 차이를 만드는 영역입니다.

종합 최적 NGFW H/W 아키텍처

앞의 Fortinet, Palo Alto Networks, Check Point, Juniper, Cisco, Sophos, Linux 기반 구조를 종합하면 최고 성능 NGFW는 특정 벤더의 한 가지 방식만 복제하는 장비가 아닙니다. 최적 구조는 L2~L4 반복 전달, IPsec/TLS crypto, DPI/IPS/App-ID, 파일·샌드박스 연동, 관측성·HA·정책 제어를 서로 다른 하드웨어 계층에 분리하고, 첫 패킷에서 세션을 정확히 분류한 뒤 이후 패킷을 가장 싼 경로로 고정하는 구조입니다.

최고 성능을 위한 10가지 설계 원칙

목표 참조 아키텍처

아래 목표 모델은 “최고 L4 처리량”과 “최고 보안 처리량”을 동시에 노리는 구조입니다. 핵심은 하나의 거대한 fast path가 아니라, fast path, service path, deep path, control path를 명확히 분리하고 세션 metadata로 다시 묶는 것입니다.

Plane별 하드웨어 구성

트래픽 유형별 최적 경로 매트릭스

Scheduler와 Queue 설계

최고 성능 NGFW에서 가장 쉽게 과소평가되는 부분은 scheduler입니다. RSS는 NIC queue로 첫 분산을 제공하지만, DPI, crypto, file extraction, sandbox, logging은 flow별 비용이 크게 다릅니다. 따라서 DPDK eventdev가 설명하는 ordered, atomic, parallel scheduling 개념처럼 순서 보존이 필요한 작업, flow state lock이 필요한 작업, 완전 병렬 가능한 작업을 queue 단계에서 구분해야 합니다.

메모리, NUMA, Fabric 설계

최고 성능 NGFW는 packet engine보다 메모리와 내부 fabric에서 먼저 실패하는 경우가 많습니다. 세션 테이블, TLS proxy buffer, TCP stream 재조립, file extraction, log buffer가 같은 DRAM 채널을 공유하면 fast path가 아무리 빨라도 L7 성능이 떨어집니다.

Crypto 설계 관점

crypto는 “가속기가 있으면 빠릅니다”로 끝나지 않습니다. IPsec, TLS handshake, TLS record, certificate signing, PQC fallback은 서로 다른 data shape와 queue 특성을 갖습니다.

성능과 보안 정확성의 균형

최고 성능 구조는 더 많은 세션을 offload하는 구조가 아니라, offload해도 되는 세션과 절대 offload하면 안 되는 세션을 정확히 구분하는 구조입니다. 성능 최적화가 보안 회피 경로가 되면 NGFW의 목적이 무너집니다.

최적 아키텍처 산정 체크리스트

1. 트래픽을 먼저 나눕니다.
   FW-only, NAT/CGN, IPsec, TLS Inspection, QUIC, 파일 검사, east-west, DDoS/scan 비율을 분리합니다.
2. 각 비율을 다른 하드웨어 plane에 매핑합니다.
   L4는 NPU/ASIC, IPsec은 crypto engine, TLS는 crypto+DPI, 파일 검사는 memory+sandbox queue, east-west는 DPU/eSwitch로 분리합니다.
3. 성능 수치를 하나로 합치지 않습니다.
   Firewall Gbps, NGFW Gbps, TLS Inspection Gbps, HTTPS CPS, concurrent sessions, latency를 서로 다른 KPI로 유지합니다.
4. Offload hit ratio를 목표값으로 둡니다.
   전체 처리량 목표보다 “어떤 세션이 왜 fast path에 못 들어갔는가”를 추적해야 튜닝이 가능합니다.
5. Crypto queue와 DPI queue를 따로 포화시킵니다.
   TLS handshake burst, AES-GCM bulk, IPS rule-heavy stream, 파일 검사 burst를 독립 테스트합니다.
6. HA와 장애를 성능 시험에 포함합니다.
   session sync, SA sync, policy update, active-passive failover, service card 장애 시 fast path 재구축 시간을 측정합니다.
7. 미래 프로토콜을 반영합니다.
   TLS 1.3, QUIC/HTTP/3, ECH, DoH/DoQ, ML-KEM hybrid TLS를 별도 프로파일로 준비합니다.

2026년 구매 가능한 제품으로 구성하는 방법

2026년 6월 기준으로 직접 구현형 최고 성능 NGFW appliance를 만든다면, 단일 부품으로 모든 plane을 만족시키기보다 server CPU + DPU/SmartNIC + crypto accelerator + 고속 NIC/switch + DDR5/NVMe를 조합하는 것이 현실적입니다. 아래 표의 “구매 가능”은 제조사가 공식 제품군을 유지하고 OEM/총판/파트너 경로로 조달 가능한 범주를 뜻합니다. 실제 SKU, 리드타임, 펌웨어 기능, 드라이버 지원, 수출통제, 보안 인증은 구매 시점에 별도 확인해야 합니다.

FPGA / Adaptive SoC 후보군

FPGA는 최적 NGFW H/W 아키텍처에서 상용 ASIC과 범용 CPU 사이의 programmable fast path 역할을 할 수 있습니다. 특히 ECH/QUIC/HTTP3, 신규 tunnel header, proprietary telemetry, ultra-low-latency prefilter, packet digest 생성처럼 고정 ASIC 업데이트 주기보다 빠르게 바뀌는 기능에 적합합니다. 다만 FPGA는 “구매하면 바로 NGFW가 되는 부품”이 아니라, RTL/HLS/oneAPI/Vitis/SDK로 pipeline을 직접 구현해야 하는 제품군입니다.

구현 목적별 권장 조합

주요 NGFW 패킷 유형별 고성능 처리 흐름

NGFW 성능은 "장비 전체 처리량"보다 패킷 유형별로 어느 경로에 태우는지가 더 중요합니다. 같은 100Gbps 링크라도 단순 EST 세션, NAT 세션, IPsec 터널, SSL Inspection 세션, QUIC/ECH 세션, 파일 검사 세션은 병목 위치가 완전히 다릅니다. 고성능 설계의 핵심은 첫 패킷에서 충분히 분류하고, 이후 패킷은 가장 싼 경로로 고정하며, 비싼 L7 검사는 필요한 세션에만 적용하는 것입니다.

벤더별 패킷 흐름 최적화 관점

NGFW 배포 아키텍처 패턴

NGFW를 네트워크에 배치하는 방식에 따라 가시성, 성능 영향, 장애 복원력이 달라집니다. 배포 모드는 크게 4가지로 분류되며, 각 모드에서 HW 오프로드의 적용 범위가 다릅니다.

인라인 배포의 장애 대응: HW 바이패스

인라인 브릿지/라우팅 배포에서 NGFW 장애 시 네트워크 단절을 방지하기 위해 HW 바이패스(Hardware Bypass) 모듈을 사용합니다. 바이패스는 전기·광학 수준에서 패킷을 NGFW를 우회하여 직접 전달합니다.

# SmartNIC 바이패스 모드 설정 (Silicom 예시)
# Watchdog 타이머 설정 — 5초 무응답 시 자동 바이패스
bpctl_util eth0 set_bypass_wd 5000   # 5000ms = 5초

# 바이패스 상태 확인
bpctl_util eth0 get_bypass
# bypass: off (normal mode)

# 수동 바이패스 전환 (유지보수 시)
bpctl_util eth0 set_bypass on

# Intel E810 NIC 바이패스 (ice 드라이버)
ethtool --set-priv-flags eth0 bypass on

고가용성(HA) 아키텍처

NGFW의 HA 구성은 세션 동기화가 핵심입니다. 장애 발생 시 기존 세션이 끊기지 않으려면 Active 장비의 conntrack 테이블을 Standby 장비에 실시간 복제해야 합니다.

# Linux NGFW HA 구성 — conntrackd + Keepalived

# 1. conntrackd — 세션 테이블 실시간 동기화
# /etc/conntrackd/conntrackd.conf
Sync {
    Mode FTFW {                    # Fault Tolerant FW 모드
        ResendQueueSize 131072
        ACKWindowSize 300
    }
    Multicast {
        IPv4_address 225.0.0.50
        Group 3780
        IPv4_interface 192.168.100.1
        Interface eth2              # 전용 동기화 인터페이스
    }
}
General {
    HashSize 32768
    HashLimit 131072
    Syslog on
    LockFile /var/lock/conntrack.lock
    UNIX { Path /var/run/conntrackd.ctl }
    Filter From Userspace {
        Protocol Accept {
            TCP SCTP DCCP
        }
        Address Ignore {
            IPv4_address 127.0.0.1
            IPv4_address 192.168.100.0/24  # 동기화 서브넷 제외
        }
    }
}

# 2. Keepalived — VIP failover
# /etc/keepalived/keepalived.conf
vrrp_instance NGFW_HA {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ngfw_ha_secret
    }
    virtual_ipaddress {
        10.0.0.1/24       # 게이트웨이 VIP
    }
    notify_master "/etc/conntrackd/primary-backup.sh primary"
    notify_backup "/etc/conntrackd/primary-backup.sh backup"
    notify_fault  "/etc/conntrackd/primary-backup.sh fault"
}

# 3. failover 스크립트 — primary-backup.sh
# primary 승격 시 conntrackd에서 세션 테이블 bulk 로드
# conntrackd -C /etc/conntrackd/conntrackd.conf -c
# conntrackd -C /etc/conntrackd/conntrackd.conf -B

TLS 1.3/ECH와 SSL Inspection의 미래

TLS 1.3과 ECH(Encrypted Client Hello)의 확산은 NGFW SSL Inspection에 근본적인 도전을 제기합니다. 기존 SSL Inspection의 핵심 가정 — ClientHello에서 SNI를 읽을 수 있고, MITM 프록시를 통해 복호화할 수 있습니다 — 이 흔들리고 있습니다.

TLS 1.3이 NGFW에 미치는 영향

ECH(Encrypted Client Hello)의 도전

ECH는 TLS ClientHello의 SNI 필드를 암호화하여 중간자(NGFW 포함)가 접속 대상 서버를 식별하지 못하게 합니다. 이는 SNI 기반 SSL Inspection 정책의 핵심 전제를 무력화합니다.

NGFW 벤더별 ECH 대응 전략:

포스트 양자(PQC) 암호화와 NGFW

NIST가 표준화한 포스트 양자 암호화 알고리즘(ML-KEM, ML-DSA)이 TLS에 도입되면, NGFW의 SSL Inspection 성능에 직접적인 영향을 미칩니다.

상용 vs Linux NGFW 선택 기준

상용 NGFW와 Linux 기반 NGFW는 하드웨어 아키텍처뿐 아니라 운영 모델, 비용 구조, 조직 역량 요구사항이 근본적으로 다릅니다. 아래 표는 실무에서 선택 시 고려해야 할 핵심 차원을 정리합니다.

시나리오별 선택 가이드

성능 비교 벤치마크 (참고 수치)

다음 표는 공식 데이터시트에 공개된 대표 수치와, 공식 수치가 공개되지 않은 항목의 확인 상태를 분리한 참고표입니다. 서로 다른 벤더의 데이터시트는 패킷 크기, 보안 기능 조합, TLS 버전, cipher suite, 로깅 조건이 다르므로 직접적인 순위표로 사용하면 안 됩니다. 실제 환경에서는 정책 복잡도, 트래픽 믹스, DPI 시그니처 수에 따라 크게 달라집니다:

Linux NGFW의 처리량은 eSwitch/flowtable 오프로드 비율, Suricata 룰셋, TLS 프록시 구현, QAT/NIC 드라이버 지원 범위에 크게 좌우됩니다. 따라서 상용 데이터시트와 비교할 때는 L4 forwarding, DPI, TLS inspection, CPS를 분리하여 같은 트래픽 조건으로 재측정해야 합니다.

NGFW 성능 측정 방법론 (RFC 9411)

RFC 9411 (Benchmarking Methodology for Network Security Device Performance)은 NGFW 성능을 표준화된 방식으로 측정하기 위한 IETF 표준입니다. 벤더 데이터시트의 수치는 대부분 최적 조건에서 측정되므로, 실제 환경 성능을 예측하려면 RFC 9411 기반 독립 벤치마크가 필수입니다.

핵심 성능 메트릭

트래픽 프로파일과 성능 변동

데이터시트 수치와 실제 성능의 격차는 트래픽 프로파일에 의해 결정됩니다. RFC 9411은 다양한 실 환경 트래픽 패턴을 반영한 테스트를 권고합니다.

참고자료

벤더 기술 문서

• Fortinet: NP7 acceleration — NP7 fast path, hyperscale session/NAT setup, ISF, 200Gbps/NP, 1,200만 세션 설명
• Fortinet: CP9 capabilities — flow-based IPS/Application Control pattern matching, IPsec, SSL/TLS protocol processor 설명
• Fortinet: FortiGate 90G/91G fast path architecture — SOC5(SP5), NP7Lite, CP10, integrated switch fabric 설명
• Fortinet: FortiGate-7000F overview — FIM의 NP7 session-aware load balancing과 FPM의 NP7/CP9 역할
• Fortinet: FortiGate 7121F — 16U 12-slot chassis, 1Tbps fabric backplane, FIM/FPM/SMM 구조
• Fortinet: FortiGate 7121F Data Sheet — FPM-7620F NP7/CP9 성능과 SSL Inspection/NGFW/Threat Protection 수치
• Palo Alto Networks: PA-7500 Series Firewall Overview — MPC, NPC, DPC, SFC 모듈형 chassis 구조와 PAN-OS 11.1 지원
• Palo Alto Networks: PA-7500 NPC — QSFP-DD 400G/100G/40G 포트와 SFP-DD 포트 구성
• Palo Alto Networks: PA-7500 Hardware Firewall Innovations — App-ID 1.5Tbps, L7 Threat Prevention 1.44Tbps, NPC/DPC 최대 구성
• Palo Alto Networks: PA-Series Hardware Architectures — PA-7500 NPC/DPC/MPC/SFC와 FE-400 ASIC 기능 블록 설명
• Palo Alto Networks: Single Pass Parallel Processing Architecture — SP3 single-pass software와 parallel processing hardware 개념
• Palo Alto Networks: SSL Forward Proxy — client-NGFW, NGFW-server 두 TLS 세션으로 복호화·검사·재암호화하는 흐름
• Check Point Quantum Force 29200 — 29200 성능 highlight와 2RU modular platform 설명
• Check Point Quantum Force 29200 Data Sheet — 29200 공식 데이터시트
• Check Point Maestro Hyperscale Network Security — Maestro 175 fabric capacity, threat prevention, port 구성
• Check Point R82: CoreXL — 다중 Firewall kernel instance와 SecureXL instance 병렬 처리
• Check Point: fwaccel stat — SecureXL KPPAK/UPPAK, Acceleration, Cryptography, Accept/NAT Template 상태 확인
• Check Point Maestro: SMO and Policies — Security Group을 단일 Security Gateway처럼 관리하는 SMO 구조
• Juniper: SRX5400/SRX5600/SRX5800 Firewalls Datasheet — SRX5800 3.36Tbps FW, 638Gbps IPS, 699Gbps VPN, SPC/IOC 확장 구조
• Juniper: SRX5800 Firewall System Overview — SCB, SPC, MPC, IOC, Flex IOC 12-slot carrier-class 구조
• Juniper: Express Path Overview — fast-path packet을 SRX firewall SPU 대신 network processor에서 처리하는 구조
• Juniper: Inline IPsec — IPsec 처리를 CPU에서 Packet Forwarding Engine ASIC으로 오프로드하는 구조
• Juniper: SSL Proxy — forward/reverse SSL proxy와 TLS 1.3 secp256r1 key exchange 제한
• Cisco Secure Firewall 4200 Datasheet — multi-threaded Snort 3, crypto acceleration, TLS hardware decryption, 16-node cluster, 400G interface option
• Cisco Secure Firewall Threat Defense Command Reference — show snort tls-offload와 TLS crypto acceleration 진단
• Cisco: Large flow offloads — prefilter policy와 static flow offload 동작
• Sophos Firewall 21.5: Architecture for offloading — SlowPath, DPI Engine, FastPath, Xstream Flow Processor, PKI/IPsec acceleration과 제한 조건
• Sophos XGS 2U Enterprise and Campus Edge Firewalls — XGS 8500 Firewall/TLS Inspection/IPS/IPsec/NGFW/Threat Protection 성능과 포트 구성
• Sophos Enterprise Firewall: Xstream Architecture — Xstream TLS inspection, DPI Engine, FastPath 개요
• Sophos: XGS 7500 and XGS 8500 announcement — XGS 7500/8500 성능 highlight와 SFOS 19.5 MR1 지원 시점
• NVIDIA MLNX_OFED: Connection Tracking Offload — ConnectX-6/7 CT offload 설정 가이드
• NVIDIA BlueField: TC Flower Offload — BlueField DPU TC flower 규칙 HW offload
• NVIDIA ConnectX-7 Product Brief — ConnectX-7 NIC 사양 및 오프로드 기능
• NVIDIA Crypto Offload — ConnectX-6 Dx/7 IPSec, TLS 하드웨어 암호화 오프로드
• Intel ICE Driver (E810) — E810 eSwitch switchdev 모드 지원 드라이버
• Broadcom SmartNIC — Stingray PS1100R, 하드웨어 방화벽 오프로드

표준/벤치마크

• RFC 9411: Benchmarking Methodology for Network Security Device Performance — NGFW 벤치마크 표준 방법론
• RFC 3511: Benchmarking Methodology for Firewall Performance — 전통 방화벽 벤치마크 (RFC 9411의 기반)
• FortiGate 7000 Series Data Sheet — Fortinet 7081F 사양
• PA-5400 Series Data Sheet — Palo Alto PA-5440 사양
• Check Point Quantum Gateway 모델 비교 — Check Point 28000 시리즈 사양