대용량 파일을 받다가 중간에 연결이 끊기고, 다시 받으려 하면 처음부터 시작되는 경험은 브라우저를 쓰는 사람이라면 누구나 한 번쯤 겪는 일이다. 특히 파이어폭스에서 이런 증상이 반복된다면, 네트워크 품질 문제가 아니라 브라우저 내부의 타임아웃 설정이 원인일 수 있다. 한 개발자가 자신의 TIL(Today I Learned) 메모에서 공유한 내용은, 파이어폭스가 기본으로 들고 있는 응답 타임아웃 값이 대용량 다운로드의 안정성과 이어받기(resume)를 방해한다는 관찰이다. 실무에서 큰 파일을 자주 내려받는 사람에게는 당장 적용해 볼 만한 단서다.
문제의 핵심: 300초 응답 타임아웃
글쓴이에 따르면 파이어폭스 28 버전 이후, 즉 2014년 무렵부터 나온 거의 모든 현대 버전은 network.http.response.timeout 값을 300초로 설정한 채 배포된다. 이 값은 서버로부터 응답을 기다리는 최대 시간을 의미하는데, 대용량 다운로드에서는 이 타임아웃이 오히려 발목을 잡는 것으로 보인다는 것이다. 연결이 한 번 불안정해지면 300초라는 한계에 걸리면서 다운로드 자체가 실패로 처리되고, 그 과정에서 이어받기 기능까지 제대로 동작하지 않는다는 관찰이다.
해결책으로 제시된 방법은 간단하다. 주소창에 about:config를 입력해 설정 페이지에 들어간 뒤, network.http.response.timeout 값을 0(또는 아주 큰 값)으로 바꾸는 것이다. 글쓴이는 이렇게 하면 대용량 다운로드가 이어받기 가능해지고 전반적인 안정성도 어느 정도 개선된다고 전한다. 다만 본인도 왜 이것이 효과가 있는지 정확히는 이해하지 못하며, 어디까지나 실험적인 테스트를 통해 확인한 경험적 결과라는 점을 분명히 밝히고 있다.
.part 파일보다 연결 타임아웃에 기대는 듯한 동작
흥미로운 대목은 파이어폭스의 이어받기 방식에 대한 추측이다. 파이어폭스는 다운로드 중인 파일을 .part라는 임시 파일로 저장한다. 상식적으로는 이 .part 파일에 이미 받은 만큼의 데이터가 들어 있으니, 재개할 때 그 지점부터 이어받으면 될 것 같다. 그런데 글쓴이의 관찰로는, 이 설정을 바꾸지 않으면 파이어폭스가 기존 .part 파일을 그냥 무시해 버린다. 그래서 그는 파이어폭스의 이어받기가 디스크에 남은 부분 파일보다는 연결 타임아웃에 의존하는 것처럼 보인다고 조심스럽게 해석한다. 타임아웃을 초과하면 내부적으로 수행되던 재시도 과정까지 방해받는 것 같다는 추정도 덧붙인다. 다만 그는 파이어폭스 소스 코드를 직접 확인하지는 않았고, 어디를 봐야 할지도 모른다고 솔직하게 적었다.
여기서 반드시 짚어야 할 전제가 있다. 이어받기는 기본적으로 서버가 지원해야 가능한 기능이다. 서버가 HTTP Range 요청 같은 부분 전송을 허용하지 않는다면, 파이어폭스든 다른 어떤 브라우저든 설정을 아무리 만져도 소용이 없다. 이 설정이 고치는 것은 '서버는 이어받기를 지원하는데 파이어폭스가 오류 후 재개를 못 하는' 상황에 한정된다. 즉 브라우저 쪽 한계를 보완하는 것이지, 서버가 못 하는 일을 가능하게 만드는 마법이 아니다.
오래된 고질병과 현실적인 대안
글쓴이는 파이어폭스의 이어받기 기능이 전반적으로 꽤 불안정하다고 평가하며, 이 문제가 형태를 달리하며 2005년부터 알려져 있었다고 언급한다. 20년 가까이 어떤 식으로든 존재해 온 고질적인 증상이라는 것이다. 그는 .part 파일을 수동으로 이리저리 옮겨서 억지로 재개시키는 방법도 찾았지만, 그런 번거로운 일은 하지 않겠다고 잘라 말한다. 대신 파이어폭스를 벗어난 대안으로 명령줄 도구인 wget을 제시한다. wget -c -O "$filename" "$url" 형태로 -c(continue) 옵션을 주면 끊긴 지점부터 이어받을 수 있고, wget 자체가 전반적으로 상당히 안정적이라는 평가다.
한국의 실무자 관점에서 이 메모는 두 가지로 읽힌다. 첫째, 브라우저로 수 기가바이트짜리 ISO 이미지나 데이터셋, 모델 가중치 파일을 반복적으로 내려받아야 하는 상황이라면 about:config에서 타임아웃 값을 조정해 보는 것이 비용이 거의 들지 않는 시도다. 둘째, 그러나 다운로드의 신뢰성이 중요한 자동화나 반복 작업이라면 애초에 브라우저보다 wget이나 curl 같은 전용 도구를 쓰는 편이 안전하다. 브라우저의 다운로드 관리자는 사람이 클릭으로 받는 편의 기능에 최적화되어 있을 뿐, 재시도와 재개의 견고함을 보장하도록 설계된 물건은 아니기 때문이다.
마지막으로 이 글의 한계도 분명히 해 둘 필요가 있다. 내용 전체가 한 개인의 실험적 관찰과 추측에 기반하며, 소스 코드 검증이나 공식 문서의 뒷받침은 없다. 타임아웃을 0으로 두는 것은 비정상적으로 느리거나 응답 없는 서버와의 연결을 무한정 붙들고 있게 만들 소지도 있어, 일반적인 웹 브라우징 환경에서 상시 적용하기보다는 대용량 다운로드가 필요할 때 선택적으로 쓰는 편이 합리적이다. 원인을 완전히 규명한 해법이라기보다, 같은 증상으로 고생하는 사람이 시도해 볼 만한 실마리로 받아들이는 것이 적절하다.