[네트워크] Request Timeout 종류 정리

https://danlebrero.com/2019/12/11/apache-http-client-timeouts-config-production-asynchronous-http-client-pictures/

 

서버간 통신이 많아지는 MSA 구조가 각광 받으면서 내부 시스템 안에서도 서로 클라이언트와 서버가 되어 데이터를 주고 받는 비중이 점점 커지고 있다. 이런 상황에서 통신을 요청하는 클라이언트는 다양한 Timeout 오류를 만날 수 있는데, 이런 Timeout에 대한 종류를 잘 구별한다면 각각의 상황에 따라 구분해서 처리할 수 있다.

한번은 쥬니어 개발자에게 API 요청이 타임아웃 오류 응답을 받는데, 백엔드 서버로 들어오지 않고 앞 단의 Nginx 까지는 액세스 로그가 찍히는 상황이라 도저히 이유를 모르겠다는 질문을 받은 적이 있다. 이런 경우는 타임아웃이 어떤 종류로 발생하고 있는지 먼저 확인하는 것이 중요하다. 타임아웃의 종류가 밝혀지면 디버그나 분석을 해야하는 범위도 좁혀지기 때문이다.

Connection Timeout

클라이언트가 서버에 요청을 보내기 전에 먼저 클라이언트는 서버와 connection을 맺어야 하는데 이 connection 자체가 성공하지 못하고 일정 시간이 지나서 최종 connection이 실패됐을 때 발생하는 Timeout이다. 이 경우에는 서버에 접근이 안되는 경우라서 클라이언트는 서버의 장애 상황으로 간주할 수 있다. 보통 이 경우에 클라이언트는 일시적인 오류 상황으로 구분하여 처리를 하거나 미리 정의된 dafault 데이터나 cache 데이터로 fallback 처리하기도 한다.

 

Socket Timeout

클라이언트와 서버가 connection을 맺은 이후에 실제 데이터를 주고 받는 과정은 실제로는 N번의 패킷 전송과정을 거치게 되는데 이 과정 사이의 간격 시간이 일정 시간을 경과하면 발생하는 Timeout이다.

 

Read Timeout

클라이언트와 서버가 connection에는 성공했지만 실제 데이터를 전송하는 I/O 과정이 길어지는 경우 일정 시간이 경과되면 클라이언트는 connection을 끊게된다. 이런 상황에서 발생하는 Timeout이 Read Timeout이며, 이 경우에는 보통 주고 받는 데이터의 양이나 네트워크 속도에 따라서 대응을 다르게한다. 만약 데이터의 양이 크다면 이를 분할해서 받을 수 있도록 API 자체 Spec을 변경하거나 Retry 전략을 사용할 수 있고, 속도가 느려서 발생하는 상황이라면 전반적으로 네트워크 대역폭 증가를 위한 인프라 작업을 고려할 수 있다. 

 

Write Timeout

클라이언트가 서버로 데이터를 보내는 경우 일정 시간이 지나는 경우 발생하는 Timeout이다. 이 경우에도 서버로 전송하는 데이터의 크기와 네트워크 상황을 고려해서 오류 처리 전략을 고려한다.