TCP Connection이 급증하면 Linux 서버에서는 어떤 일이 발생할까?

TCP 연결 급증이 리눅스 서버에 미치는 영향과 대응 전략

인터넷 세상에서 서버는 수많은 사용자의 요청을 처리하는 심장과 같습니다. 이때 서버와 클라이언트가 데이터를 주고받기 위해 맺는 약속이 바로 TCP 연결입니다. 하지만 갑작스러운 트래픽 폭주나 외부 공격으로 인해 TCP 연결이 한꺼번에 몰리면 리눅스 서버는 비명을 지르게 됩니다. 이번 글에서는 TCP 연결 급증이 서버 내부에서 어떤 문제를 일으키는지, 그리고 이를 어떻게 관리하고 최적화해야 하는지 실무적인 관점에서 살펴보겠습니다.

TCP 연결의 생애 주기와 서버가 겪는 병목 현상

TCP 연결은 3단계 핸드셰이크 과정을 거쳐 생성됩니다. 클라이언트가 SYN을 보내고, 서버가 SYN-ACK로 응답하며, 클라이언트가 최종 ACK를 보내야 비로소 데이터 전송 준비가 완료됩니다. 문제는 이 과정이 메모리와 CPU 자원을 소모한다는 점입니다. 연결이 급증하면 다음과 같은 현상이 발생합니다.

• 메모리 고갈: 각 연결은 커널 내부에 소켓 버퍼를 할당받습니다. 연결 수가 수만 단위로 넘어가면 커널 메모리가 부족해져 시스템 전체가 느려집니다.

• 파일 디스크립터 한계: 리눅스에서 모든 것은 파일로 관리됩니다. 소켓 역시 파일 디스크립터(File Descriptor)를 소모하는데, 시스템에 설정된 최대치를 넘어서면 새로운 연결을 맺을 수 없습니다.
• CPU 과부하: 수많은 연결의 상태를 추적하고 패킷을 처리하기 위해 CPU는 문맥 교환(Context Switching)을 빈번하게 수행해야 하며, 이는 처리 효율을 급격히 떨어뜨립니다.

TCP 연결 폭주 시 나타나는 주요 증상과 오해

많은 운영자가 서버가 느려지면 무조건 CPU나 메모리 부족을 의심합니다. 하지만 TCP 연결 문제일 때 나타나는 독특한 징후들이 있습니다. 흔한 오해와 사실을 정리해 드립니다.

• 오해: 연결이 많으면 무조건 서버가 뻗는다. 사실: 적절히 설정된 서버라면 수만 개의 연결도 충분히 견딥니다. 문제는 연결을 맺고 끊는 과정에서의 비효율성입니다.

• 오해: TIME_WAIT 상태는 서버가 고장 난 것이다. 사실: TIME_WAIT는 TCP 프로토콜의 정상적인 종료 과정입니다. 다만, 이 상태가 너무 많으면 새로운 포트를 할당할 수 없어 문제가 됩니다.
• 징후: 서버 응답 속도가 갑자기 느려지고, 특정 포트로의 접속이 거부(Connection Refused)된다면 TCP 백로그(Backlog) 큐가 가득 찼을 가능성이 높습니다.

실무에서 활용하는 리눅스 커널 튜닝 가이드

TCP 연결 급증에 대비하기 위해서는 리눅스 커널 파라미터를 최적화하는 것이 필수입니다. 다음 설정들은 /etc/sysctl.conf 파일에서 조정할 수 있습니다.

• net.core.somaxconn: 서버가 대기 상태로 유지할 수 있는 연결 요청의 최대 개수입니다. 기본값이 작다면 1024 이상으로 늘리는 것이 좋습니다.

• net.ipv4.tcp_max_syn_backlog: 아직 연결이 완료되지 않은 SYN 요청을 보관하는 큐의 크기입니다. SYN 플러딩 공격 방어 및 급증하는 접속 처리에 효과적입니다.
• net.ipv4.tcp_tw_reuse: TIME_WAIT 상태의 소켓을 새로운 연결에 재사용할 수 있게 합니다. 포트 고갈 문제를 해결하는 가장 강력한 방법 중 하나입니다.
• net.ipv4.ip_local_port_range: 서버가 외부로 연결할 때 사용할 수 있는 로컬 포트 범위를 넓혀줍니다.

전문가가 제안하는 비용 효율적인 트래픽 관리 전략

단순히 커널 설정만 바꾸는 것은 임시방편일 뿐입니다. 근본적인 해결을 위해서는 아키텍처 차원의 접근이 필요합니다.

• 로드 밸런서 도입: 서버 한 대에 모든 연결을 집중시키지 말고, 앞단에 로드 밸런서(Nginx, HAProxy, L4 스위치)를 두어 부하를 분산하세요. 로드 밸런서는 연결 유지 관리(Keep-Alive)에 최적화되어 있습니다.
• HTTP Keep-Alive 활용: 매번 연결을 새로 맺고 끊는 비용은 매우 큽니다. 클라이언트와 서버 간의 연결을 유지하여 재사용하면 핸드셰이크 비용을 획기적으로 줄일 수 있습니다.
• 연결 풀링(Connection Pooling): 데이터베이스나 외부 API 서버와 연결할 때 매번 연결을 맺지 말고, 미리 연결을 생성해두고 재사용하는 풀링 기법을 적용하세요.
• Rate Limiting 적용: 비정상적인 연결 급증을 막기 위해 IP별, 사용자별 접속 제한을 두어 서버 자원을 보호해야 합니다.

자주 묻는 질문과 답변

Q: TIME_WAIT 상태가 수천 개인데 서버가 위험한가요?

A: 단순히 수치만 높다고 위험한 것은 아닙니다. 시스템의 가용 포트 범위를 확인하고, 새로운 연결을 맺는 데 지장이 없다면 정상적인 동작입니다. 하지만 포트 고갈이 발생한다면 tcp_tw_reuse 설정을 고려하세요.

Q: 서버가 갑자기 응답하지 않을 때 가장 먼저 무엇을 확인해야 하나요?

A: netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 명령어를 사용하여 현재 연결 상태별 개수를 확인하세요. SYN_RECV가 비정상적으로 많다면 SYN 플러딩 공격을 의심해야 하고, ESTABLISHED가 너무 많다면 애플리케이션의 처리 지연을 의심해야 합니다.

Q: 커널 파라미터를 무조건 크게 늘리면 좋나요?

A: 아닙니다. 모든 설정은 메모리 점유와 직결됩니다. 서버의 실제 물리 메모리 사양을 고려하여 단계적으로 조정해야 하며, 설정 후에는 반드시 부하 테스트 도구(ab, wrk, jmeter 등)를 통해 안정성을 검증해야 합니다.

성능 최적화를 위한 실전 체크리스트

서버 운영 중 TCP 연결과 관련된 이슈를 예방하기 위해 다음 사항들을 정기적으로 점검하십시오.

• 파일 디스크립터 한도 확인: ulimit -n 명령어로 현재 프로세스가 열 수 있는 최대 파일 수를 확인하고, 필요시 65535 이상으로 상향 조정하세요.
• 로그 모니터링: dmesg 명령어를 통해 “TCP: request_sock_TCP: Possible SYN flooding on port”와 같은 경고 메시지가 반복되는지 확인하세요.
• 애플리케이션 타임아웃 설정: 클라이언트의 연결이 너무 오래 유지되지 않도록 적절한 타임아웃 값을 애플리케이션 레벨에서 설정하는 것이 좋습니다.
• 모니터링 툴 활용: Prometheus와 Grafana를 사용하여 커널 수준의 TCP 지표를 시각화하면 문제 발생 시 원인을 훨씬 빠르게 파악할 수 있습니다.

TCP 연결 관리는 서버 운영의 기본기이자 가장 깊이 있는 영역 중 하나입니다. 서버가 처리할 수 있는 연결의 한계를 이해하고, 이를 효율적으로 분산하고 재사용하는 구조를 설계한다면, 갑작스러운 트래픽 급증에도 당황하지 않고 안정적인 서비스를 유지할 수 있을 것입니다. 오늘 설명해 드린 커널 설정과 아키텍처 전략을 현재 운영 중인 서버에 맞게 조금씩 적용해 보시길 권장합니다.