Connection vs Read Timeout

“API 응답 없음”.

특정 API 호출이 긴 시간 동안 hanging 중일 수 있다.

이런 식으로 개발하면서 한 번쯤은 무한정 로딩 스피너를 경험한 적이 있을 수 있다.

이 문제의 상당수는 타임아웃과 관련이 있을 가능성이 크다. 그냥 기본값으로 두거나, 어림짐작으로 “대충 5초?” 하고 설정하기에는 너무 중요한 값이다.

Connection Timeout vs Read Timeout: 차이점

Connection Timeout: TCP 3-way handshake 시간

Connection 타임아웃을 쉽게 생각해보면 “상대방에게 전화를 거는 시간” 이다.

• 상대방에게 전화를 걸고, 특정 시간안에 연결되지 않으면 끊긴다.

• 클라이언트와 서버 간의 TCP 3-way handshake를 통해 논리적인 연결을 수립하는 데까지 허용되는 시간이라고도 할 수 있다. (연결이 성립되기까지의 최대 대기 시간)

즉, Connection Timeout은 TCP 연결 자체가 성립되지 않은 상태에서 연결 시도가 일정 시간 내에 완료되지 못했을 때 발생한다.

Client ────SYN────→ Server
Client ←──SYN+ACK─── Server
Client ────ACK────→ Server

위 과정에서 소요되는 시간이 Connection Timeout이다.

Connection Timeout이 발생하는 조건

• 서버가 죽었을 때

• 방화벽에서 패킷을 막을 때

• 네트워크 장비 이슈 등 (네트워크 경로에 문제 발생)

• 스레드 풀 고갈과 같은 애플리케이션 병목도, accept 호출이 지연되면서 간접적으로 Connection Timeout의 원인이 될 수 있다.

Read Timeout: 연결 이후, 답변을 기다리는 시간

Read 타임아웃은 “전화에 연결되고, 상대방이 답변하기까지 기다리는 시간”이다.

이미 TCP 연결이 성립된 상태에서 요청을 보낸 쪽이 응답 데이터를 일정 시간 동안 받지 못했을 때 발생한다.

• 전화가 연결되고, 상대방이 아무 대답 없이 침묵하는 상황을 얼마나 기다릴지 정하는 시간이다.

• 연결은 성공했지만, 서버가 요청을 처리하고 데이터를 보내주기 전까지 무한정 기다리지 않도록 방지하는 안정장치이기도 하다.

👨‍💻 클라이언트: "데이터 주세요!" 
🖥️ 서버: "처리 중..." (침묵...) 
⏰ 타임아웃: "너무 오래 기다렸어요!"

연결은 성공했지만, 실제 데이터를 주고받는 과정에서의 최대 대기 시간이다.

Read Timeout이 발생하는 조건

• 서버에서 요청 처리가 오래 걸리는 경우

• 응답 데이터가 큰 경우

• 중간 네트워크에서 패킷 유실이 발생한 경우 (혹은 네트워크 불안정)

Timeout을 위한 Golden Principle

그래서 각 timeout 값을 설정하기 위해서 서비스만의 규칙이 존재해야 한다.

아래 두 조건을 고려할 수 있다.

1. 네트워크는 완벽하지 않다. 패킷 유실은 장애 상황이 아니어도 언제든 일어날 수 있다.

• 간혈적인 패킷 유실은 정상적인 상황이다. 타임아웃이 너무 짧으면 정상적인 네트워크 지연도 에러로 처리하게 된다.

1. 정말 네트워크 장애가 발생했다면, 최대한 빨리 인지하고 대응해야 한다.

• 네트워크에 진짜 문제가 발생한 것이라면 최대한 빨리 감지해야 한다. 타임아웃이 너무 길면 장애 대응이 늦어진다.

타임아웃을 너무 짧게 잡으면, 가끔 발생하는 패킷 유실에도 서비스가 실패했다고 판단하게 되고, 반대로 너무 길게 잡으면, 실제 장애가 발생했을 때 사용자는 하염없이 기다리고 시스템은 문제를 너무 늦게 발견게 된다.

따라서 이러한 조건을 설정하고 이를 만족하는 기준을 정하는 게 좋다.

패킷 유실과 재전송 메커니즘

Linux는 SYN 패킷이 유실되면 1초 후 재전송한다.

즉, Linux Kernel에 하드코딩된 초기 재전송 타임아웃, InitRTO 값을 사용한다는 것이다.

• 이 값은 기본적으로 1초이며, RFC 6298에 따른 초기 RTO 값이라고 한다.

• InitRTO는 TCP Handshake 중 첫 SYN 패킷에만 적용되며, 이후의 RTO는 RTT 측정에 기반해 동적으로 조정된다.

• SYN 패킷이 한 번 유실된다면 최소한 연결을 맺는데 1초 이상의 시간이 소요된다.

# 패킷 유실 확인
ss -i  # retrans 카운터 확인
netstat -s | grep -i retrans

TCP RTO는 연결 이후에도 계속 사용되는 개념이다.

1. 연결 시 (SYN 단계)

• RTT를 모르니까 InitRTO(1초) 사용

• SYN 패킷 유실 시 1초 후 재전송

1. 연결 후 (데이터 통신)

• SYN + ACK를 받으면서 첫 RTT 측정

• 이후 RTT 기반으로 RTO 동적 계산

• 최소값: 200ms (tcp_rto_min)

• 최대값: 120초 (tc_rto_max)

즉, 초기 연결 시 RTO 값이 정해지고, 이후 패킷 교환 과정에서 측정되는 RTT(왕복 시간)를 반영해 RTO가 계속 변화하고, 연결 이후에도 RTO는 변화하며, 네트워크 상황에 맞춰 동적으로 조정되는 값이다.

SYN 또는 SYN+ACK 패킷 유실 시:
클라이언트는 1초(InitRTO)를 기다린 후 SYN 패킷을 재전한다.
만약 재전송도 실패하면, 다음 재전송까지 2초, 4초, 8초... 식으로 지수적으로(Exponential Backoff) 대기 시간이 늘어난다.

실제 시간 계산:

• 1번 유실: 1초 지연

• 2번 유실: 1 + 2 = 3초 지연

• 3번 유실: 1 + 2 + 4 = 7초 지연

Connection Timeout

커넥션 타임아웃은 TCP 연결 과정에서 발생한다. 여기서 패킷이 유실될 수 있는 경우는 크게 세 가지이다.

1. 클라이언트가 보낸 연결 요청(SYN) 패킷 유실 (클라이언트 → [유실] → 서버)

2. 서버가 보낸 연결 수락(SYN + ACK) 패킷 유실 (클라이언트 ← [유실] ← 서버)

3. 클라이언트가 보낸 최종 확인(ACK) 패킷 유실 (클라이언트 → [유실] → 서버)

여기서 중요한 개념이 하나 있는데, RTO(Retransmission Timeout, 재전송 타임아웃)이다.

패킷을 보내고 이 시간만큼 응답이 없으면 “아, 유실됐구나”하고 재전송을 시도한다.

특히, 연결을 처음 시도할 때는 RTT(Rount Trip Time, 데이터 왕복 시간)를 모르기 때문에, InitRTO 값을 사용한다.

위에서 언급한 패킷 유실 시의 시간 계산을 기준으로,

• Connection Timeout을 3초로 설정했다면

• 한 번의 패킷 유실은 허용하고, 연속된 두 번의 패킷 유실이 발생했을 때 빠르게 실패하겠다는 의미이다.

Read Timeout: 서비스 특성에 맞게 설정

Read Timeout은 Connection Timeout보다 복잡하다. 고려해야 할 요소가 더 많기 때문이다.

• 연결이 되고 나면 RTT 기반으로 RTO(Retransmission Timeout)를 계산한다.

• 서버의 처리 시간(Server-Side Processing Time)을 함께 고려해야 한다.

# Read Timeout 설정 시 고려해야 할 시간
Read Timeout > (서버 처리 시간) + (RTT) + (패킷 재전송 시간 = RTO)

• 서버 처리 시간: 서버가 클라이언트의 요청을 받아 처리하는 데 걸리는 실제 시간

• RTT: 클라이언트에서 서버로 요청이 전달되고, 다시 응답이 클라이언트에 도착하는 데 걸리는 총 왕복 시간

• 패킷 재전송 시간: 네트워크 상에서 패킷이 유실되었을 경우 재전송이 일어나면서 추가로 소요되는 시간(RTO)를 포함한다.

여기서 RTT나 패킷 재전송 시간보다 서버 처리 시간이 전체 시간을 좌우하는 경우가 대부분이다.

호출한 API가 복잡한 DB 쿼리를 수행하거나 다른 서비스를 호출한다면, 수백 ms ~ 수초가 걸릴 수 있다.

그렇기 때문에 Read Timeout을 설정하는 가장 좋은 방법은 데이터에 기반하는 것이다.

백엔드 서비스에 APM이 구성되어 있다고 가정하자.

우리는 APM을 통해 호출하려는 API의 P95 또는 P99 응답 시간을 확인할 수 있다.

• P99: 전체 요청 중 99%가 이 시간안에 응답했다는 의미로, 대부분의 정상적인 경우를 포함하는 안정적인 지표다.

그래서 A 서비스의 P99 응답 시간이 700ms라면, Read Timeout은 네트워크 상황을 고려한 버퍼(e.g., 300ms ~ 500ms)를 더해 1초 ~ 1.2초로 설정하는 것이 매우 합리적일 수 있다.

만약 API 응답 시간을 전혀 모르는 상황이라면, 1~3초의 보수적인 값으로 시작하고 반드시 모니터링을 통해 조정하는 것이 좋을 것 같다.

추가 내용

1. Read Timeout은 무조건 클라이언트에서 설정한다.

Read Timeout은 요청을 보낸 쪽(클라이언트)이 응답을 얼마나 기다릴지를 결정하는 정책이기 때문이다. 서버는 클라이언트가 얼마나 기다려줄지 알지 못한다.

1. Read Timeout 서버 로그

직접적으로 "Read Timeout"이라는 로그는 남지 않는다.

서버는 클라이언트가 타임아웃으로 끊어진 사실을 모른다. 서버는 자신의 작업을 완료하고 클라이은테에게 응답을 보내는 순간, 클라이언트가 커넥션을 끊었다는 사실을 인지하고 서버에 다음과 같은 네트워크 오류는 남길 수 있다.

• java.net.SocketException: Broken pipe

• Connection reset by peer

중요한 것은, 서버의 작업 자체는 성공적으로 완료되었을 수 있기 때문에 클라이언트는 "실패"로 처리했지만 서버에서는 이미 DB에 데이터가 저장되면서 데이터 불일치를 유발할 수 있다. Refer: https://alden-kang.tistory.com/20