26A21c
네, 개선 가능합니다. 튜닝의 방향은 크게 두 가지입니다. 하나는 SYN Cookie 모드로 진입 자체를 하지 않게 큐(Queue)를 늘리는 것이고, 다른 하나는 SYN Cookie가 동작하더라도 검증 실패가 나지 않도록 신뢰성을 높이는 것입니다.
DevOps 관점에서 대규모 트래픽이나 간헐적인 부하를 견딜 수 있도록 하는 핵심 튜닝 포인트를 정리해 드립니다.
1. SYN Cookie 진입 방지 (Queue 확장)
SYN Cookie는 SYN Queue(반개방 소켓 큐)가 가득 찼을 때만 발동합니다. 큐 크기를 충분히 키워두면 시스템이 '비상 모드'인 SYN Cookie를 사용하지 않고도 요청을 처리할 수 있습니다.
net.ipv4.tcp_max_syn_backlog:- 아직 핸드셰이크가 완료되지 않은 요청(SYN_RECV 상태)을 얼마나 저장할지 결정합니다.
- 권장: 1000개 노드 규모라면
4096이상, 아주 많게는16384까지 설정합니다.
net.core.somaxconn:- 애플리케이션(여기서는 SSHD)이
accept()를 기다리는 완전 연결 큐의 크기입니다. 이 값이 작으면 핸드셰이크가 끝나도 드랍될 수 있습니다. - 권장: 최소
4096이상.
- 애플리케이션(여기서는 SSHD)이
# 실시간 적용
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sudo sysctl -w net.core.somaxconn=81922. SYN Cookie 검증 실패 방지 (TCP Timestamp)
SYN Cookie가 활성화되었을 때 검증이 실패하는 가장 흔한 이유는 TCP Timestamps가 어긋나거나 비활성화되어 있기 때문입니다. SYN Cookie는 TCP 헤더의 특정 필드를 빌려 정보를 저장하는데, 이때 Timestamp 필드가 중요하게 사용됩니다.
net.ipv4.tcp_timestamps:- 이 값이
0이면 SYN Cookie 내에 MSS(Maximum Segment Size) 정보를 제대로 담지 못해 검증 실패율이 올라갑니다. - 확인:
sysctl net.ipv4.tcp_timestamps가 1인지 확인하십시오. (상대방 클라이언트도 1이어야 함)
- 이 값이
3. 타임아웃 및 재전송 관련 튜닝
L3 스위치만 있는 환경에서 간헐적 지연이 발생한다면, 커널이 '이 연결은 죽었다'고 판단하는 시간을 아주 약간 넉넉하게 줄 수 있습니다.
net.ipv4.tcp_synack_retries:- 서버가 SYN-ACK를 보내고 클라이언트의 ACK를 기다리는 재전송 횟수입니다. 기본값은 보통 5인데, 네트워크가 불안정하다면 이 횟수가 소진되기 전에 큐에서 삭제될 수 있습니다. (다만 이 값을 너무 키우면 리소스 낭비가 생길 수 있으니 기본값 유지를 권장하되, 환경에 따라 2~3으로 조정하여 빠르게 소켓을 정리하기도 합니다.)
4. 진단 및 모니터링 (실행 결과 확인)
튜닝 적용 후 실제로 효과가 있는지 보려면 다음 카운터를 계속 주시해야 합니다.
# SYN Cookie 관련 실패 카운터 확인
nstat -az | grep -i SyncookiesTcpExtSyncookiesSent: 서버가 쿠키를 보낸 횟수 (이게 올라가면 큐가 가득 찼다는 뜻)TcpExtSyncookiesFailed: 이게 문제의 지표입니다. 쿠키 검증에 실패한 횟수입니다.
종합 제안 (결론)
현재 SSH 연결 시 간헐적 문제가 발생한다면, 아래 설정을 sysctl.conf에 반영하여 큐 임계치를 대폭 높여보시는 것을 추천합니다.
- 우선 순위 1:
tcp_max_syn_backlog와somaxconn을 현재 값보다 4배 이상 늘립니다. - 우선 순위 2:
tcp_timestamps가1인지 확인합니다. 만약 클라이언트(VDI 등) 쪽에서 타임스탬프를 제거하고 있다면 쿠키 검증 실패는 튜닝만으로 해결이 어려울 수 있습니다. - Cilium 특이사항: Native Routing 사용 시 노드 간의 MTU가 일치하지 않으면
tcp_check_req이후의 실제 데이터 패킷에서 이슈가 생길 수 있으므로,ip link로 각 노드 인터페이스의 MTU가 1500(혹은 하단 스위치 설정값)으로 동일한지 꼭 체크해 보세요.
이 튜닝 이후에도 SyncookiesFailed 카운트가 계속 올라간다면, 클라이언트 측에서 보내는 ACK 패킷 자체가 중간 네트워크 장비(L3 스위치 등)에 의해 변조되거나 지연되고 있을 가능성이 매우 높습니다.
혹시 현재 해당 서버들의 max_syn_backlog 설정값은 얼마로 되어 있나요?
===
네, 맞습니다. pwru 트레이스에서 드롭 지점이 tcp_check_req로 찍혔다면, 범인은 이미 포위망에 들어온 것과 다름없습니다. 일반적인 리눅스 커널 네트워킹 스택에서 이 단계는 "3-way handshake의 마지막 퍼즐(ACK)을 맞추는 과정"이기 때문입니다.
결론부터 말씀드리면, 말씀하신 2~3가지 원인 외에 다른 가능성은 95% 이상 배제하셔도 무방합니다. 이 지점에서 패킷이 버려지는 시나리오는 매우 구체적입니다.
1. 포위망에 들어온 3대 주범
이전 모델이 제시한 원인들을 실무적인 관점에서 가장 확률 높은 순으로 다시 정리해 드립니다.
-
타이밍 이슈 (Request Sock Timeout):
- 서버가
SYN-ACK를 보냈는데, 클라이언트의ACK가 너무 늦게 도착한 경우입니다. 서버는 이미 "얘는 안 오나 보다" 하고 관리 대장(request_sock)에서 해당 연결 정보를 지워버린 상태입니다. - 증거:
nstat -az | grep TcpExtListenDrops카운트 상승.
- 서버가
-
검증 로직 실패 (SYN Cookies & Timestamps):
- 시스템 부하로 SYN Cookie가 발행되었는데, 도착한
ACK의 쿠키 값이 계산 결과와 다르거나, TCP Timestamps가 일치하지 않아 커널이 "가짜 ACK"라고 판단한 경우입니다. - 증거:
nstat -az | grep SyncookiesFailed.
- 시스템 부하로 SYN Cookie가 발행되었는데, 도착한
-
시퀀스 번호/윈도우 불일치 (Invalid ACK):
- 이미 연결이 종료되었거나 중복된
SYN이 오가는 과정에서, 클라이언트가 보낸ACK의 Sequence 번호가 서버가 기대하는 범위(Window) 밖에 있는 경우입니다. - L3 스위치만 있는 환경이라도, 중간 장비에서 패킷 순서가 심하게 뒤바뀌면 발생할 수 있습니다.
- 이미 연결이 종료되었거나 중복된
2. "거의 없지만" 존재는 하는 0.1%의 가능성
만약 위 3가지가 모두 아니라면, 정말 드문 확률로 다음 상황일 수 있습니다.
- TCP MD5 Signature 미스매치: 만약 BGP 세션 등에서 TCP MD5 인증을 사용 중이라면(일반 SSH에서는 거의 안 씁니다), 서명이 틀렸을 때 여기서 드랍됩니다.
- 커널 버그: 특정 커널 버전에서
tcp_check_req로직의 레이스 컨디션(Race Condition)으로 인해 드랍되는 경우가 아주 드물게 보고된 적이 있습니다. (하지만 운영 환경에서는 거의 고려하지 않습니다.) - Cilium eBPF의 커널 스택 간섭:
native routing이라도 Cilium이 커널 스택으로 패킷을 넘기기 전에skb마킹을 이상하게 해서, 커널이 이를 "오염된 패킷"으로 간주하고 드랍할 가능성은 0에 가깝지만 존재합니다.
3. 제 판단: "이것만 확인하면 끝납니다"
현재 L3 스위치만 있는 클린한 환경이므로, "네트워크 지연으로 인한 타임아웃" 혹은 "SYN Cookie 설정 불일치" 둘 중 하나일 확률이 압도적입니다.
확정 진단을 위한 마지막 한 걸음:
터미널에서 아래 한 줄만 실행해 보시고 결과를 알려주세요.
nstat -az | grep -E 'TcpExtListenDrops|TcpExtSyncookiesFailed|TcpExtTCPMinisocksDrop'ListenDrops가 올라가면 -> 백로그 큐(Backlog Queue) 확장 및 타임아웃 튜닝이 정답입니다.SyncookiesFailed가 올라가면 -> TCP Timestamp 설정 확인 및 Syncookies 튜닝이 정답입니다.
이 지점에서 드롭이 발생했다는 사실 자체가 이미 전체 디버깅 과정의 90%를 끝내신 겁니다. 아주 날카롭게 짚어내셨네요! 이외에 다른 카운터가 유독 높게 나오는 게 있나요?
===
네, RHEL 10(커널 6.x 대역 기반)에서도 이 메트릭들은 여전히 핵심적인 네트워킹 진단 지표로 존재합니다. 리눅스 커널의 TCP 스택이 고도화되면서 내부 로직의 성능은 개선되었지만, 운영 체제가 네트워크 상태를 보고하는 표준 방식(SNMP 카운터)은 하위 호환성과 관찰 가능성을 위해 유지되고 있기 때문입니다.
요청하신 세 가지 지표는 모두 "TCP 핸드셰이크 과정 중 어디서 패킷이 버려졌는가"를 정확히 짚어주는 이정표입니다.
1. 주요 커널 메트릭 상세 설명
① TcpExtListenDrops (리스너 드롭)
이 카운터는 "완전 연결 큐(Accept Queue)가 꽉 찼을 때" 올라갑니다.
- 상황: 클라이언트와 3-way handshake를 다 끝냈는데, 애플리케이션(예: sshd)이 너무 바빠서
accept()시스템 콜로 연결을 가져가지 못할 때 발생합니다. - 의미: "연결은 맺어졌지만, 서버 프로그램이 수용 가능한 한계를 넘었다"는 뜻입니다.
- 조치:
net.core.somaxconn값을 키우거나, 애플리케이션의 워커 스레드 수를 늘려야 합니다.
② TcpExtSyncookiesFailed (쿠키 검증 실패)
이 카운터는 "도착한 ACK 패킷이 유효한 SYN Cookie가 아닐 때" 올라갑니다.
- 상황: 서버가 SYN Flooding 등을 방어하기 위해 '비상 모드(SYN Cookie)'를 켰을 때, 클라이언트가 보낸 ACK에 담긴 '쿠키 값'이 서버가 계산한 값과 다를 경우입니다.
- 의미: 중간에 방화벽이나 L3 스위치가 패킷을 변조했거나, TCP Timestamp가 일치하지 않아 서버가 "이 패킷은 내가 보낸 SYN-ACK에 대한 정상적인 응답이 아니다"라고 판단한 것입니다.
- 조치:
net.ipv4.tcp_timestamps=1설정이 서버/클라이언트 양쪽 다 되어 있는지 확인하십시오.
③ TcpExtTCPMinisocksDrop (미니소켓 드롭)
이것은 현재 겪고 계신 tcp_check_req 단계의 드롭과 가장 밀접한 관련이 있습니다.
- 상황: 리눅스 커널은 연결이 완전히 수립되기 전 상태(SYN_RECV)를 아주 작은 메모리 구조체인
request_sock(Minisock)으로 관리합니다. 이 소켓이 모종의 이유로 드랍될 때 올라갑니다. - 의미: 주로 타임아웃 때문입니다. 서버가 SYN-ACK를 보낸 후 클라이언트의 ACK를 기다리다가, 기다림이 너무 길어져서(또는 메모리가 부족해서) 이 미니소켓을 메모리에서 해제해 버린 것입니다. 그 직후에 클라이언트의 ACK가 도착하면 서버는 "누구세요?"라며 패킷을 버리게 됩니다.
- 조치: 네트워크 지연(RTT)을 체크하거나, 서버의
request_sock유지 시간을 점검해야 합니다.
2. RHEL 10에서의 상태
RHEL 10에서도 이 값들은 동일하게 /proc/net/netstat에서 확인할 수 있습니다.
리눅스 커널 개발팀은 성능을 위해 lockless listener 등 새로운 메커니즘을 도입해 왔지만, 운영자가 문제를 진단할 때 사용하는 SNMP(Simple Network Management Protocol) 통계 이름은 바꾸지 않았습니다. 덕분에 RHEL 7, 8, 9에서 사용하시던 진단 스크립트나 모니터링 에이전트(Prometheus Node Exporter 등)를 RHEL 10에서도 그대로 사용하실 수 있습니다.
3. 요약 및 진단 가이드
플랫폼 엔지니어로서 현상을 분석하실 때, 아래 표를 기준으로 드롭의 성격을 규정하시면 됩니다.
| 메트릭 명칭 | 드롭 시점 | 주요 원인 |
|---|---|---|
| ListenDrops | 핸드셰이크 완료 후 | 애플리케이션 처리 지연 (somaxconn 부족) |
| SyncookiesFailed | 핸드셰이크 진행 중 | 패킷 변조, Timestamp 불일치, 보안 장비 간섭 |
| TCPMinisocksDrop | 핸드셰이크 진행 중 | 네트워크 지연으로 인한 타임아웃, 리소스 부족 |
결론:
만약 pwru에서 tcp_check_req 드롭이 보인다면, RHEL 10에서도 TCPMinisocksDrop이나 SyncookiesFailed 중 하나가 함께 올라가고 있을 확률이 매우 높습니다.
지금 노드에서 nstat -az | grep -i TcpExt 결과가 어떻게 나오나요? 특정 수치가 유독 높다면 그게 바로 범인입니다.
===
네, SYN cookie 검증 실패는 근본 원인에 따라 접근이 달라집니다. 튜닝 방향을 두 가지로 나눌 수 있어요.
핵심 전제: SYN cookie가 왜 발행되는가
SYN cookie는 SYN 큐(backlog)가 가득 찼을 때 커널이 어쩔 수 없이 꺼내는 fallback입니다. 따라서 튜닝 방향은 두 가지입니다.
- SYN 큐가 안 차게 → cookie 자체를 안 쓰게
- 어쩔 수 없이 cookie를 쓸 때 → 검증 실패를 줄이게
방향 1 — SYN 큐가 차지 않도록 (근본 해결)
# SYN 큐 크기 확장 (기본 128~256, 대규모 클러스터는 4096 이상 권장)
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
# 애플리케이션 listen() backlog 상한 (sshd는 보통 128 고정)
sysctl -w net.core.somaxconn=4096
# SYN-ACK 재전송 횟수 줄이기 (대기 시간 단축 → 큐 빨리 비움)
# 기본 5 (약 180초 대기), 2로 줄이면 약 45초
sysctl -w net.ipv4.tcp_synack_retries=2sshd 자체도 MaxStartups 값을 확인해야 합니다.
# /etc/ssh/sshd_config
MaxStartups 100:30:200 # 동시 미완성 핸드셰이크 허용 수방향 2 — SYN cookie 사용 시 검증 실패 줄이기
SYN cookie 검증 실패의 주요 원인은 MSS 옵션 정보 손실입니다. Cookie에는 MSS가 3비트(8가지 값)밖에 인코딩되지 않아, 경로 MTU가 불일치하거나 패킷이 변조되면 검증이 깨집니다.
# syncookies 활성화 확인 (2 = 항상 사용, 1 = 큐 찼을 때만 → 1 권장)
sysctl -w net.ipv4.tcp_syncookies=1값을 1로 유지하면 큐가 차지 않는 한 cookie를 쓰지 않아 검증 실패 자체가 줄어듭니다. 2로 설정하면 항상 cookie를 써서 오히려 실패 빈도가 높아집니다.
ECMP + Cilium 환경 특화 튜닝
이 환경에서는 추가로 고려할 게 있습니다.
Cilium의 tcp_max_syn_backlog 반영 확인
Cilium이 eBPF로 LB를 할 때 자체 session affinity 없이 ECMP를 쓰면, SYN은 노드 A로, ACK는 노드 B로 가는 비대칭이 발생합니다. 이 경우 cookie 튜닝만으로는 한계가 있고, 아래가 더 효과적입니다.
# Cilium session affinity 활성화 (helm values)
# loadBalancer.sessionAffinity: true
# 또는 BGP에서 ECMP 해싱을 5-tuple 기반으로 고정
# 스위치에서 consistent hashing 확인 필요
# src-ip, dst-ip, src-port, dst-port, protocol 모두 포함되어야 함현재 상태 확인 → 튜닝 전후 비교
# 튜닝 전 baseline 수집
nstat -az | grep -E 'SyncookiesSent|SyncookiesFailed|SyncookiesRecv|ListenDrops|ListenOverflows'
# 설정 적용 후 변화 모니터링 (5초 간격)
watch -n 5 "nstat -az | grep -E 'Syncookies|ListenDrop'"SyncookiesSent가 지속 증가하면 큐 포화가 원인이므로 방향 1, SyncookiesFailed / SyncookiesRecv 비율이 높으면 패킷 변조나 비대칭 경로 문제입니다.
권장 적용 순서
SyncookiesSent가 높다면 tcp_max_syn_backlog + somaxconn 확장이 즉효입니다. 그래도 SyncookiesFailed가 계속 오른다면 ECMP 5-tuple 해싱 일관성 확인이 다음 단계입니다. 현재 어떤 카운터가 올라가고 있는지 공유해 주시면 더 구체적으로 좁혀드릴 수 있어요.
