TCP `ECONNRESET` 오류, 그 숨겨진 원인은?
로컬호스트에서 실행되는 두 서비스 간 TCP 통신 중 간헐적으로 발생하는 `ECONNRESET` 오류의 원인을 분석함.
서버 측에서 데이터를 클라이언트로 보낸 후 소켓을 닫는 과정에서, 아직 읽히지 않은 데이터가 남아있을 때 TCP RST 패킷이 전송되는 것이 원인으로 추정됨.
실제 환경에서는 Nginx와 Gunicorn 간 통신에서 유사한 문제가 발생했으며, Gunicorn의 지연 처리(Lazy Processing) 방식이 문제의 핵심으로 지목됨.
해결책으로 애플리케이션 레벨에서 HTTP 요청 본문을 명시적으로 읽도록 수정하는 방안이 제시되었음.
TCP RST 발생 메커니즘 분석
커뮤니티에서는 `close()` 시스템 콜이 TCP RST를 유발하는 주요 원인으로 지목됨. 특히, 소켓에 아직 읽히지 않은 데이터가 남아있는 상태에서 `close()`가 호출될 경우, RFC 1122에 따라 데이터 손실을 알리기 위해 RST 패킷이 전송될 수 있다는 가설이 제시됨. 이는 `sendto()`가 성공적으로 반환되었더라도 실제 데이터 전달을 보장하지 않으며, `ECONNRESET` 오류의 근본 원인으로 작용할 수 있음을 시사함.
서버 측 데이터 처리 지연과 `ECONNRESET`
실제 시나리오에서 gunicorn은 Flask 애플리케이션을 서빙하며 Nginx와 연동됨. Nginx가 HTTP 요청을 gunicorn으로 전달할 때, `writev` 시스템 콜을 사용하지만 gunicorn은 때때로 요청 본문(body)을 완전히 `recvfrom`하지 않는 '지연 처리(Lazy Processing)' 방식을 보임. 애플리케이션 레벨에서 요청 본문을 명시적으로 읽지 않으면, gunicorn의 `close()` 호출 시 남아있는 데이터로 인해 TCP RST가 발생하여 클라이언트 측에서 `ECONNRESET` 오류가 나타나는 것으로 분석됨.
클라이언트 측 `--spam` 플래그와 타이밍 문제
클라이언트 프로그램에 `--spam` 플래그를 추가하여 서버로 데이터를 먼저 전송한 후 수신하는 시나리오를 테스트함. 이 경우, `recvfrom()` 호출 시 `ECONNRESET` 오류가 빈번하게 발생함. 이는 단순히 데이터를 많이 주고받는 것 외에도, 클라이언트가 데이터를 보내는 행위와 서버가 데이터를 처리하고 소켓을 닫는 과정 사이의 타이밍(Timing) 또는 상태 동기화(State Synchronization) 문제가 `ECONNRESET`을 유발할 수 있음을 시사함.
Python 스택에서의 근본 원인 규명 시도
문제의 근본 원인을 gunicorn, Flask, 또는 실제 Flask 애플리케이션 중 어디에 있는지 규명하려는 시도가 있었음. gunicorn의 '지연 처리' 방식이 의심되며, 관련 이슈가 이미 보고된 바 있다고 언급됨. 해결책으로 Python 애플리케이션에서 HTTP 요청 본문을 명시적으로 읽도록 수정하는 방안이 제시되었으며, 이는 `close()` 호출 시 불필요한 RST 발생을 방지하는 효과를 가져옴.
