Connection Timeout vs Read Timeout

CS 스터디 중 스터디원이 팀 프로젝트를 진행하며 겪은 문제를 공유해주었는데, 서버간 통신중 HTTP 응답이 너무 오래동안 오지 않아 Timeout이 발생했다고 하였다. 여기서 Timeout의 개념을 제대로 알고 있지 않다고 느껴 공부한 내용을 정리해보고자 한다..! Connection Timeout과 Read Timeout의 개념, 그리고 어느 정도로 Timeout을 설정하면 좋은지 알아보자!

Connection Timeout

• 서버, 클라이언트 간 종단을 연결하는데 소요되는 최대 시간
• 해당 시간을 넘기게 되면 연결 할 수 없는 것으로 판단하고 에러가 발생

Read Timeout

• 연결된 종단 간에 데이터를 주고 받을 때 소요되는 최대 시간
• 클라이언트가 서버에 접속은 하였으나 서버가 로직을 수행하는 시간이 너무 길어 제대로 응답을 못준 상태로 클라이언트가 연결을 해제하는 것

어떻게 설정하는 것이 좋은가?

• 패킷 유실은 장애 상황이 어니어도 발생할 수 있다.
• 그런데 만약 실제로 장애 상황이 발생하여 패킷이 유실될 때 최대한 빠르게 조치하기 위해서는 Timeout 값을 짧게 주는 것이 좋다
  • 하지만 너무 짧게 주면 간헐적으로 발생되는 패킷 유실에 대해 너무 민감하게 반응해버리게 된다

⇒ 따라서 한 번의 패킷 유실정도는 재전송을 통해 해결할 수 있는 수준의 타임아웃을 주는 것이 좋다!!

• Connection Timeout
  • 핸드 쉐이크 과정에서 SYN, SYN+ACK, ACK 패킷이 유실되었을 때, 총 3가지를 고려해보면 될 것이다
• Read Timeout
  • 기본적으로 Connection Timeout에 비해 짧게 설정한다
  • 이는 RTO가 RTT를 기준으로 만들어져 1초보다 짧기 때문

    RTO (Retransmission Timeout) : 타이머가 작동하는 시간

    • 첫 SYN 패킷은 정보가 없음으로 initRTO라는 지정된 값으로 사용하며, 리눅스는 1초이다
    • 따라서 기본적으로 어플리케이션에서의 타임아웃은 1초 이상으로 설정한다
    • 이미 맺은 세션의 재전송은 RTT 기반으로 1초 미만이겠지만, Handshake를 맺는데에는 최소 1초 이상은 걸리기 때문
    • 그러나 커넥션 풀을 사용한다면 initRTO가 발생할 일이 없기 때문에 더 작은 값으로 설정해도 된다

    RTT (Round Trip Time) : 네트워크 통신을 하는 두 노드 간에 패킷이 전달되는데 소요된 시간

    • 종단간 거리가 멀면 값이 커진다
    • ping 리눅스 명령어로 확인할 수 있다

      ping -c 3 www.google.com

    • time이 실제 패킷이 왕복하는데 걸린 시간이고 ttl은 IP 패킷 수명이다

      64 bytes from 142.250.206.196: icmp_seq=0 ttl=114 time=31.094 ms
      64 bytes from 142.250.206.196: icmp_seq=1 ttl=114 time=38.236 ms
      64 bytes from 142.250.206.196: icmp_seq=2 ttl=114 time=30.828 ms
      
      --- www.google.com ping statistics ---
      3 packets transmitted, 3 packets received, 0.0% packet loss
      round-trip min/avg/max/stddev = 30.828/33.386/38.236/3.431 ms

참조

https://alden-kang.tistory.com/20
https://brunch.co.kr/@alden/15