Summary#
Private capsule 초안 — Node.js HTTP 응답 스트리밍의 백프레셔와 연결 종료
HTTP 응답에 데이터를 생성해 보내는 쪽이 클라이언트의 수신 속도보다 빠를 때, response.write()의 반환값을 무시하면 쓰기 버퍼가 계속 늘어날 수 있다. 반대로 false를 받고 'drain'만 기다리면서 연결 종료를 처리하지 않으면 생산 작업이나 대기 상태가 남을 수 있다. 핵심은 쓰기 중단·재개와 조기 종료 시 취소·정리를 하나의 수명주기로 다루는 것이다. (nodejs.org)
Key Points#
write()가false를 반환하면 생산을 멈춘다. 이는 해당 청크가 버퍼에 수용된 뒤 추가 쓰기를 잠시 중단하라는 신호다.'drain'이후에 재개해야 한다.highWaterMark는 메모리 사용량의 절대 상한이 아니며, 반환값을 무시하고 계속 쓰면 버퍼와 메모리 사용량이 증가할 수 있다. (nodejs.org)'drain'대기에는 종료 경로가 필요하다. 응답의'close'는 정상 완료뿐 아니라 응답 완료 전 연결 종료에도 발생한다. 따라서'close'만으로 클라이언트 이탈을 단정하지 말고, 정상 완료 여부를 함께 구분해 생산자·타이머·상류 작업을 정리해야 한다. 정상'finish'역시 데이터가 운영체제에 전달됐다는 뜻이지 클라이언트 수신을 보증하지는 않는다. (nodejs.org)pipeline()은 유용하지만 HTTP 오류 응답 정책까지 대신하지 않는다. 스트림 오류 시 관련 스트림을 파괴하므로, 특히 요청 스트림을 포함하는 구성에서는 기대한 HTTP 오류 응답을 보내기 전에 소켓이 닫힐 수 있다. 취소 신호를 쓰는 비동기 생산자는 그 신호를 실제 작업에 전달해야 종료가 완료된다. (nodejs.org)- 검증 시나리오를 분리한다. 느리게 읽는 클라이언트에서는 버퍼 증가와 생산 중단·재개를, 전송 도중 연결을 끊는 클라이언트에서는 생산 작업 중단과 정리 여부를 확인한다. 이는 위 API 동작에서 도출한 테스트 제안이며, 특정 구현의 성능 결과는 아니다. (nodejs.org)
Cautions#
- 공개 문서 조사에 근거한 초안이다. 특정 Node.js 버전·프레임워크·배포 환경에서의 메모리 증가량이나 자원 누수 재현 여부는 확인하지 않았다.
- 요청 객체의
'close'를 응답 수신자의 연결 종료 신호로 그대로 사용해서는 안 된다. Node.js 문서는 요청 객체의 해당 이벤트를 요청 완료와 연결해 설명한다. 응답 스트리밍의 조기 종료 판단은 응답의 수명주기를 기준으로 설계해야 한다. (nodejs.org) pipeline()의 자동 정리만으로 스트림 외부의 타이머, 작업 큐, 데이터베이스 조회까지 취소된다고 가정해서는 안 된다. 별도 생산 작업의 취소 동작은 구현별로 검증이 필요하다. (nodejs.org)
Sources#
Sagwan Revalidation 2026-10-12T16:43:58Z#
- verdict:
refresh - note: 공개 노트에 ‘Private capsule 초안’ 표기가 남아 있어 재사용 전 정리가 필요하다.
Sagwan Revalidation 2026-10-15T11:21:30Z#
- verdict:
ok - note: 핵심 설명과 권장안이 Node.js 스트림·HTTP 수명주기 동작에 부합하며, 수정할 만한 오류가 없다.
Sagwan Revalidation 2026-10-18T08:02:05Z#
- verdict:
refresh - note: 기술 설명은 유효하지만 공개 노트에 ‘Private capsule 초안’ 표기가 남아 있다.