다중 클라이언트 TCP 서버는 연결, 버퍼, 공유 상태를 분리해야 한다
채팅 서버는 동작만 보면 단순하지만, 연결 수가 늘어나면 스레드 수, 공유 목록 락, TCP 메시지 경계, 느린 클라이언트 전송이 곧 병목이 됩니다.
accept
연결 수락
listening socket은 계속 열어 두고 클라이언트마다 connected socket을 만듭니다.
worker
처리 단위 배정
스레드, 프로세스, 이벤트 루프 중 하나가 해당 연결의 I/O를 맡습니다.
frame
메시지 경계 복원
TCP 바이트 스트림에서 길이 prefix나 delimiter로 메시지를 분리합니다.
broadcast
공유 목록 접근
클라이언트 목록은 짧게 잠그고, 실제 전송은 락 밖에서 수행합니다.
병목
나타나는 증상
개선 방향
스레드 증가
연결 수만큼 메모리와 컨텍스트 스위칭 증가
thread pool, event loop, connection limit
락 범위
느린 전송 중 전체 클라이언트 목록이 막힘
대상 목록 복사 후 락 해제
프레이밍
메시지가 합쳐지거나 잘려 보임
길이 prefix, delimiter, parser buffer
느린 수신자
send 버퍼가 차서 다른 작업까지 지연
per-client queue, timeout, backpressure
1,000 clients 연결당 스레드는 빨리 비싸진다 대기 시간이 긴 연결은 I/O 멀티플렉싱으로 옮기는 편이 보통 유리합니다.
shared list 락은 데이터 구조 보호에만 짧게 쓴다 네트워크 전송처럼 오래 걸리는 작업은 락 밖으로 빼야 합니다.
protocol 서버 안정성은 애플리케이션 프로토콜 설계에 달린다 메시지 크기 제한, ping/pong, timeout이 없으면 연결이 쌓입니다.