참고: 본 자료는 각 벤더의 공식 데이터시트(2023~2025년 기준)를 기반으로 작성된 요약 자료입니다.
실제 성능은 측정 환경(패킷 사이즈, 암호화 알고리즘, 활성화된 보안 기능 등)에 따라 달라질 수 있으니, 도입 검토 시 반드시 최신 데이터시트와 PoC 결과를 함께 확인하시기 바랍니다.
LOW
저사양 — SOHO / 소규모 지점용
소규모 사무실, 원격 지점, 재택근무 게이트웨이용. 일반적으로 1U 데스크탑 폼팩터, IPsec VPN 1 Gbps 이하.
데이터센터 & 통신사용. Maestro 오케스트레이터로 최대 52노드 가상 게이트웨이 확장 가능.
모델
방화벽 처리량
위협방어 처리량
IPsec VPN 처리량
동시 VPN 터널
동시 세션
SecurityPower
Quantum 16200
80 Gbps
22 Gbps
26 Gbps
50,000
25M
7,800 SPU
Quantum 16600
100 Gbps
30 Gbps
35 Gbps
75,000
30M
9,800 SPU
Quantum 19100
88 Gbps
36 Gbps
37 Gbps
100,000
35M
10,000 SPU
Quantum 19200
100 Gbps
44 Gbps
42 Gbps
120,000
40M
11,500 SPU
Quantum 26000
200 Gbps
70 Gbps
85 Gbps
200,000
70M
22,000 SPU
Quantum 28000
400 Gbps
120 Gbps
150 Gbps
300,000
120M
42,000 SPU
Maestro Hyperscale (52노드)
1.5 Tbps+
650 Gbps
800 Gbps+
1,000,000+
500M+
2,000,000+ SPU
🟫 Juniper — SRX4600 / SRX5400 / SRX5600 / SRX5800
통신사 & 대형 데이터센터 코어. SRX5800은 12 슬롯 모듈형 샤시.
모델
방화벽 처리량
IPsec VPN 처리량
동시 VPN 터널
동시 세션
신규 세션/초
폼팩터
SRX4600
160 Gbps
40 Gbps
30,000
30M
575,000
2U
SRX4700
350 Gbps
90 Gbps
60,000
60M
1.5M
2U
SRX5400
480 Gbps
100 Gbps
75,000
90M
1.0M
5U 샤시
SRX5600
960 Gbps
200 Gbps
100,000
175M
1.8M
8U 샤시
SRX5800
2.0 Tbps
400+ Gbps
200,000
350M
3.6M
16U 샤시 (12슬롯)
측정 기준 및 참고사항
방화벽 처리량(Firewall Throughput): 일반적으로 1518B UDP 패킷 기준의 최대 단순 포워딩 성능. NGFW/위협방어 활성화 시 통상 30~50%로 감소.
IPsec VPN 처리량: AES-256-GCM 또는 AES-128 + SHA1/SHA256 기준 (벤더마다 상이). 패킷 사이즈 1280~1400B가 일반적.
동시 IPsec 터널(Concurrent Tunnels): 동시에 유지 가능한 IKEv2 site-to-site 또는 GRE-over-IPsec 터널 수.
SSL VPN 사용자/처리량: 원격접속(클라이언트 SSL VPN) 동시 사용자 또는 처리량. 라이선스에 따라 추가 제한이 있을 수 있음.
동시 세션(Concurrent Sessions): 상태 테이블에서 유지 가능한 동시 연결 수.
SecurityPower(SPU): Check Point 고유 지표. 실제 운영 환경에서 IPS·AV·앱컨트롤 등을 켜고 측정한 종합 처리 능력 단위.
벤더별 강점 요약
Cisco — 네트워크 인프라와의 통합(SD-WAN, ISE, DNA), 글로벌 지원·국내 레퍼런스 풍부
Palo Alto Networks — 애플리케이션 식별(App-ID)·콘텐츠 ID 기반 NGFW 1위. Prisma Access(SASE) 통합 강점
Fortinet — 자체 ASIC(NP/SP) 기반 IPsec 성능 가성비 최고. SD-WAN/SASE/스위치/AP까지 보안 패브릭 통합
Check Point — 위협 인텔리전스(ThreatCloud)·정책 관리 UX. Maestro 하이퍼스케일
SonicWall — 중소·중견 시장 가성비. RTDMI 샌드박싱
Juniper — 라우팅·캐리어 환경 강점, MX/PTX와 결합한 SP 보안
주의: 본 표의 수치는 각 벤더 공식 데이터시트의 대표값을 발췌·정리한 것이며, 모델 라인업·EOL/EoS·소프트웨어 버전에 따라 변동될 수 있습니다.
구매·도입 의사결정 시에는 최신 공식 데이터시트(vendor.com/datasheet)와 현장 PoC를 반드시 병행하시기 바랍니다.
[5년 전] 처음으로 엄지 발가락에 2mm 정도 크기의 사마귀가 보였음. 처음에는 사마귀인 줄 모를 정도로 좁쌀처럼 작았음.
[4년 전] 환부가 10mm 정도로 커서 양말을 벗으면 바로 사마귀가 보였음. 이때부터 피부과를 찾아봤음. 피부과에서 레이저 치료를 받았고, 9개월 정도는 매끈한 상태를 유지했음.
[3년 전] 다시 동일한 위치에 사마귀가 재발했음. (피부과 의사가 레이저 치료할 때, 1년 뒤에 사마귀가 재발할거라고 했음) 사마귀 치료로 유명한 한의원이 있어서 200만원 정도 내고 치료를 시작했음. (3개월 치료 프로그램) 3개월간 한방 치료를 받았지만 1%도 좋아지지 않았음. 원장 한의사가 3개월 연장 치료하면 100% 완치된다고 설득함. (즉, 200만원을 추가 결제하라는 뜻 ㅠㅠ)
그냥 한의원을 나왔음.
한의사에게 완전 속았음. ㅠㅠ (시간과 돈 낭비 ㅠㅠ)
[2년 전] 아들 딸과 토요일, 일요일마다 수영장에 가서 2시간씩 수영을 했음. 1년 넘게 이런 패턴으로 수영을 했었는데, 1년이 지날 때쯤 발가락에 있던 사마귀가 사라졌음 :) 그 뒤로 지금까지 사마귀는 재발하지 않고 있음.
[원인 분석 및 결론] 수영장에서 수영을 2시간씩 꾸준하게 했을 때, 사마귀(유두종 바이러스)가 치료된 이유가 무엇일까? 내가 생각하기에는; - 직접적인 원인: 2시간 동안 수영하면서 피부가 물에 퉁퉁부었고, 그때 사마귀가 있는 부위를 살살 문질렸을 때 피부 조직이 평소보다 많이 떨어졌음. (어떤 날은 수영장에서 샤워하는 동안에 피부 상처 딱지가 떨어지듯 사마귀 환부의 피부가 떨어질 때도 있었음) 이것을 1년 동안 반복하니까 사마귀 환부가 점점 작아지다가 사라진 듯. - 간접적인 원인: 주2회씩, 2시간씩 수영을 하니까 면역력이 좋아진 것 같음. 그리고 수영장 수질 유지를 위해서 물에 약품을 섞었을텐데, 그 약품 때문에 피부에 있는 균과 바이러스들이 죽었을듯.
위의 3가지 원인이 복합적으로 작용해서 사마귀를 치료했다고 생각함. ㅎㅎㅎ 혹시 사마귀 치료로 어려움을 겪는 분이 있다면 위의 방법을 추천함 :)
budget 소진이나 시간 제한 때문에 아직 처리할 패킷이 있는데 루프가 끝나면 /proc/net/softnet_stat의 세 번째 필드(time_squeeze)가 증가한다. 이 값이 0보다 크면 한도에 걸린 것이다. CPU 여유가 있다면 netdev_budget을 올려서 net_rx_action이 더 많은 패킷을 처리하도록 할 수 있다.
# 기본값 300, 필요 시 증가
echo 900 > /proc/sys/net/core/netdev_budget
netif_receive_skb → enqueue_to_backlog. 패킷이 CPU별 입력 큐에 들어가고, 해당 원격 CPU의 NAPI 구조체가 그 CPU의 poll_list에 추가되며 IPI가 큐에 넣어진다. 그러면 원격 CPU의 ksoftirqd가 깨어나 같은 방식으로 net_rx_action → process_backlog로 그 CPU의 입력 큐에서 패킷을 꺼낸 뒤 __netif_receive_core → 프로토콜 스택으로 넘긴다. 즉, 수신 처리 부하가 여러 CPU에 나뉜다.
RPS 유무에 따른 경로
RPS를 쓰면 패킷이 CPU별 큐로 나뉘고 IPI로 다른 CPU의 ksoftirqd가 깨어나 부하가 분산된다.
멀티큐 NIC는 큐별로 다른 CPU에 IRQ를 붙여 softIRQ 부하를 나누고, RPS는 큐 수보다 CPU가 많을 때 추가로 부하를 분산할 때 유용하다.
6. 프로토콜 스택부터 사용자 소켓까지
__netif_receive_core 이후 경로는 대략 다음과 같다.
IPv4의 경우 ip_rcv로 패킷 수신.
netfilter 및 라우팅 최적화.
로컬로 오는 패킷은 상위 프로토콜(UDP 등)로 전달.
UDP면 udp_rcv → udp_queue_rcv_skb, sock_queue_rcv로 사용자 소켓의 수신 버퍼에 큐잉. 그 전에 BPF 등이 처리될 수 있다.
Protocol Stack부터 User Socket 까지 흐름도
ip_rcv → netfilter/라우팅 → UDP → 소켓 큐 → 사용자 공간.
7. 모니터링 및 튜닝
링/큐 크기와 드롭
링은 고정 크기 원형 큐이므로, 처리보다 도착이 빠르면 큐가 가득 차 패킷이 드롭된다.
ethtool -S enp8s0f0 | grep drop
드롭이 늘면:
멀티큐 사용: ethtool -l로 현재 설정, ethtool -L로 큐 개수 조정. 큐가 여러 개면 DMA/처리 부하가 여러 CPU에 나뉜다.
큐(디스크립터) 길이 증가: ethtool -g로 최대/현재 값 확인, ethtool -G로 조정. 큐를 길게 하면 처리량은 늘 수 있지만 지연 변동이 커질 수 있고, 짧으면 지연은 줄일 수 있지만 드롭 위험이 있다.
softIRQ 소비 확인
cat /proc/net/softnet_stat | awk '{print $3}'
세 번째 필드가 time_squeeze이다. 0보다 크면 budget/시간 제한으로 아직 처리할 패킷이 있는데 루프가 끝난 경우다. CPU 여유가 있으면 netdev_budget을 올려 본다.
수신 처리 호출 스택 예시
# 예: netif_receive_skb_internal 부근 커널 스택
netif_receive_skb_internal+1
napi_gro_receive+186 # RX 링에서 꺼낸 직후
igb_poll+1153
net_rx_action+329
__do_softirq+222
...
Linux OS에서 QCOW2, ISO, LOG 파일, 동영상 미디어 파일 등을 CLI 명령으로 복사할 때
복사 진행 정도를 확인하려면 아래의 방법을 이용하면 된다.
cp 명령 대신 rsync 명령을 사용
## 파일 1개 복사할 때
$ rsync --progress origin_file_name dest_file_name
## Directory 전체 복사할 때
## 참고: -a 옵션은 permission, timestamp 정보를 유지하도록 함
$ rsync -a --info=progress2 origin_dir_name dest_dir_name
progress 명령을 사용
이미 cp, mv 명령을 실행한 뒤, 다른 터미널에서 progress 명령을 실행하여 진행 상황을 본다.
$ sudo apt install progress
## 아래 명령은 cp, mv 등 파일 복사/이동에 관한 process 등을 자동으로 찾아서 진행률을 보여준다.
$ progress -mw
방금 다운로드한 kernel version을 확인하려면, Makefile을 열어서 파일 내용의 위 5줄을 읽어야 한다.
$ cat Makefile
VERSION = 7
PATCHLEVEL = 0
SUBLEVEL = 0
EXTRAVERSION = -rc2
NAME = Baby Opossum Posse
... 중간 생략 ...
만약 특정 version의 kernel source code를 가져와서 build하고 싶다면, 아래 예시와 같이 `git fetch` 명령을 실행해야 한다.
$ git fetch origin tag v6.19 --no-tags
$ git checkout v6.19
## 또는 아래와 같이 처음부터 `git clone`할 때, 특정 tag를 지정해서 가져온다.
$ git clone --depth 1 --branch v6.19 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-6.19
Kernel source code를 build하기 위해 필요한 utility program을 설치하기
