Connection Timeout, Socket Timeout, Read Timeout은 같은 말이 아니에요

네트워크 요청이 멈출 때 timeout이라는 말 하나로 묶어 버리면 문제를 정확히 못 잡아요. 연결 자체가 안 되는 경우와, 연결은 됐지만 응답이 늦는 경우는 원인이 달라요. 이름도 비슷해서 더 자주 헷갈려요.

세 timeout은 기다리는 지점이 달라요

구분	무엇을 기다리나요?	주로 발생하는 구간
Connection Timeout	서버와 TCP 연결이 맺어질 때까지	DNS, 라우팅, 핸드셰이크
Socket Timeout	연결은 되었지만 소켓에 데이터가 오기까지	응답 대기, 중간 읽기
Read Timeout	응답 바이트를 읽는 동안 새 데이터가 오지 않는 시간	느린 API, 정지된 업스트림

라이브러리마다 이름을 조금 다르게 쓰지만 핵심은 비슷해요. connection timeout은 서버까지 길을 찾고 악수하는 시간이고, read timeout은 악수 후 첫 응답과 다음 응답 사이를 기다리는 시간이에요.

실무에서는 socket timeout을 read timeout과 거의 같은 뜻으로 쓰는 경우가 많아요. 다만 쓰는 클라이언트마다 의미가 조금씩 다를 수 있으니, 실제 설정 이름을 먼저 확인해야 해요.

왜 구분해야 하나요

연결 문제는 네트워크 경로, 방화벽, DNS, 서버 기동 지연과 연결돼요. 읽기 문제는 업스트림 처리 시간, DB 부하, 대규모 응답, 느린 외부 API와 연결돼요. 같은 timeout 로그라도 어디에서 끊겼는지에 따라 해결책이 완전히 달라져요.

예를 들어 새 배포 직후 Connection Timeout이 늘었다면 서버가 아직 준비되지 않았거나 로드 밸런서 헬스 체크가 늦을 수 있어요. 반대로 Read Timeout이 늘었다면 서버는 살아 있지만 내부 작업이 너무 느리다는 뜻일 가능성이 커요.

문제의 성격이 다르니 대응도 달라야 해요. 연결이 안 되면 경로를 고치고, 응답이 느리면 처리 시간을 줄이거나 병목을 찾아야 해요.

설정은 짧게, 원인은 따로 봐야 해요

timeout을 길게 늘리면 실패를 늦출 뿐이에요. 사용자는 더 오래 기다리고, 서버는 더 많은 연결을 붙잡고 있어요. 그래서 보통은 connection timeout을 짧게, read timeout은 업무 허용 범위에 맞게 두고, 재시도는 idempotent한 요청에만 제한적으로 걸어요.

연결 실패는 빠르게 드러내고,
처리는 허용 범위 안에서 기다리되,
무한정 붙잡아 두지는 않아요.

이 원칙을 지키면 timeout은 문제를 숨기는 값이 아니라 장애를 빨리 드러내는 값이 돼요. 특히 사용자에게 한 번의 요청이 끝없이 걸리는 상황을 줄일 수 있어요.

실무 기준을 두면 덜 흔들려요

설정값을 정할 때는 다음 순서가 좋아요.

1. 연결이 안 되면 몇 초 안에 실패시킬지 정해요.
2. 응답을 얼마나 기다릴지 서비스 기준 시간으로 정해요.
3. 재시도는 멱등 요청에만 두고, 횟수도 적게 잡아요.
4. 타임아웃이 늘어났을 때는 값을 먼저 키우기보다 원인을 확인해요.

이 순서를 지키면 숫자만 늘려서 문제를 덮는 일을 줄일 수 있어요.

정리

1. Connection Timeout은 연결 자체를 맺는 시간을 봐요.
2. Socket Timeout과 Read Timeout은 연결 이후 응답을 기다리는 시간을 봐요.
3. timeout을 길게 잡는 것보다, 어디에서 실패했는지 분리해서 보는 편이 중요해요.

참고

• 매일메일 102번 질문