DevOps - TCP 재전송과 타임아웃
TCP는 자신이 보낸 데이터에 응답을 받지 못하면 패킷을 재전송하는데 이를 TCP 재전송이라고 한다.
성능 저하가 불가피하게 일어남에도 통신의 특성상 반드시 필요한 과정이다.
그 과정과 그로 인해 발생할 수 있는 타임아웃에 대해 알아보자.
1. TCP 재전송과 RTO
TCP 과정에서 데이터를 보낸 쪽은 받는 쪽의 ACK를 기다리는데, 만약 받지 못한다면 패킷이 중간에 손실되었다고 판단하고 재전송한다.
여기서 ACK를 얼마나 기다려야하는지에 대한 값을 RTO (Retransmission Timeout)라 부른다.
RTO 안에 ACK를 받지 못하면 TCP 재전송이 발생하는 것이다.
RTO는 일반적인 RTO와 InitRTO 두 가지가 있다.
일반적인 RTO : RTT(RoundTripTime) 기준으로 설정
InitRTO : 두 종단간 최초연결시, 첫번째 syn 패킷에 대한 RTO 기준으로 설정
+) 리눅스에서는 ss 명령으로 RTO 값을 확인할 수 있다.
시간이 이러하다면 재전송 횟수에 대해서는 제한이 있을까?
2. 재전송을 결정하는 커널 파라미터
재전송과 관련된 커널 파라미터는 5개 값이 있다.
1) net.ipv4.tcp_syn_retries
SYN에 대한 재시도 횟수를 결정하며 기본값은 5이다.
2) net.ipv4.tcp_synack_retries
SYN + ACK 의 재전송 횟수를 결정하며 기본값은 5이다.
3) net.ipv4.tcp_orphan_retries
orphan socket이라 불리는 상태의 소켓들에 대한 재전송 횟수를 결정한다.
+) orphan socket : 특정 프로세스에 할당되지 않고 커널에 귀속되어 정리되기를 기다리는 소켓 중에서도 FIN_WAIT1 상태의 소켓 // FIN_WAIT1 소켓이 마지막으로 보내는 패킷에 해당하기 때문에
4) net.ipv4_tcp_retries1
IP 레이어에 네트워크가 잘못되었는지 확인하도록 사인을 보내는 기준 // = soft threshold
5) net.ipv4_tcp_retries2
더 이상 통신을 할 수 없다고 판단하는 기준 // = hard threshold
이 횟수를 넘겨야 실제 연결이 끊어짐
3. 재전송 추적하기
TCP 재전송을 추적하기 위해서는 의심 서버에서 tcpdump를 추출하는 것이 가장 좋지만, 너무 많은 패킷이 잡혀 힘들 수도 있다.
이 때 tcpretrans 스크립트를 활용하면 재전송이 일어나는 패킷을 추적해서 타임아웃 등의 이슈가 있을 때 원인을 추적할 수 있다.
4. RTO_MIN 값 변경하기
RTO_MIN 값이 200ms이기 때문에 아무리 RTT가 작은 내부 통신의 경우에도 RTO 값은 200ms 밑으로 내려갈 수 없다.
RTO_MIN 값을 더 줄일 수는 없을까?
RTO_MIN은 ip route 명령의 rto_min 옵션을 통해 변경할 수 있다.
세션별로 바꿀 수는 없지만 하나의 네트워크 디바이스를 기준으로 바꿀 수는 있다.
그러나 외부에 노출된 웹 서버에는 다양한 고객들이 접근하므로 기본값을 따르는 것이 좋다.
내부 통신 서버에서 사용하는 경우, 서비스의 품질을 높이는 방법이 될 수 있지만 또 값이 너무 낮다면 잦은 재전송이 일어날 수 있기에 잘 조절해야한다.
5. 애플리케이션 타임아웃
TCP 재전송이 일어나면 애플리케이션에서는 요청한 내용을 전달받지 못해 타임아웃이 발생한다.
그러나 타임아웃의 임계치를 몇 초로 설정했느냐에 따라 타임아웃이 발생하지 않을 수도 있다.
애플리케이션에서 발생할 수 있는 타임아웃에는
1) Connection Timeout 과 2) Read Timeout이 있다.
1) Connection Timeout
TCP handshake 과정에서 재전송이 일어날 경우 발생
최소 권장 설정 값 : 3s 이상 ( syn 재전송 1초 + 상대방의 syn ack재전송 1초 보다 큰 값으로 설정해야 불필요한 타임아웃 에러 줄임)
2) Read Timeout
맺어져있는 세션을 통해 데이터를 요청하는 과정에서 발생
최소 권장 설정 값 : 300 ms 이상 (RTO_MIN이 200ms로 세션이 재전송할 때 최소한 200ms 가 걸리기 때문)