2025-11-18

배경

이론상 HTTP 스펙에서 POST, PATCH, PUT 요청 크기 제한 X, but 실 서비스 환경에서는 요청 크기 및 요청 횟수 제한
일반적인 요청 흐름 : 프록시 서버 → 로드밸런서 → 웹 서버 → 메인 서버
- 메인 서버 부하 방지를 위해, 앞 단계에서 요청량 조절
- CloudFront(CDN/프록시) : 헤더 포함 요청 크기는 20MB 제한, 초당 요청 횟수는 250,000건 제한
- AWS API Gateway(로드밸런서) : 요청 본문 최대 10MB 제한, 초당 요청 수 Region별 10,000개 제한, 초과 시 429(Too Many Requests) 오류
- Nginx(웹 서버) : 기본 요청 본문 크기는 기본 1MB, 초과 시 413(Request Entity Too Large) 오류
- Express(메인 서버) : body-parser 미들웨어 사용 시 요청 본문 크기는 100kb 제한, 초과 시 PayloadTooLargeError 오류

요청 크기 제한의 필요성

메모리 사용량 증가
- 대부분의 서버/프레임워크는 요청 본문을 메모리에 올려 처리, 요청 제한 없을 시 OOM(Out Of Memory) 발생 위험
- 앞단에서 크기 제한하는 구조 필요
응답 지연 및 타임아웃
- 큰 요청일수록 전송 및 파싱 소요 시간 증가 → 타임아웃 발생, 다른 요청들의 대기 시간 증가
- Nginx : 새로운 요청들이 큐에 쌓임 → 서비스 전반 속도 저하
- Express : Node.js는 단일 스레드 이벤트 루프 기반, 하나의 큰 요청으로 인해 이벤트 루프가 막힘
전송 실패 리스크 증가
- POST/PUT 요청 시, 서버는 요청 본문(body)을 완전히 받아야 유효한 요청으로 인식 → 전송 도중 통신 단절 시, 처음부터 재전송
- 클라이언트가 자동 재시도 수차례 시도 → rate spike 발생, 시스템 부하 가중
- Chunked Upload : 위 문제 방지를 위해 파일을 여러 조각으로 분할 전송
보안 리스크
- DoS(Denial of Service) 수단 : 공격자가 의도적으로 거대한 요청 송신 → 서버는 파싱에 리소스 낭비
- Large Payload DoS : 매우 큰 POST 요청 반복 송신
- Slow HTTP Attack : Content-Length를 크게 설정, 데이터를 매우 천천히 전송 → 커넥션 장시간 점유

results matching ""