# 번들 HTTP 진단 런타임

HTTP/1.1, HTTP/2, HTTP/3는 같은 번들 curl 클라이언트를 사용합니다. macOS arm64와 Linux x64는 curl 8.22.0, OpenSSL 3.5.9, nghttp2 1.70.0, ngtcp2 1.25.0, nghttp3 1.18.0을 사용합니다. Windows x64는 curl.se 공식 curl-for-win 8.22.0_3 정적 빌드와 LibreSSL 4.3.3, 그리고 같은 HTTP 라이브러리를 사용합니다. 시스템 curl로의 대체, 런타임 다운로드, 관리자 권한은 필요하지 않습니다. Windows 업스트림의 재현 가능한 빌드 방법은 https://github.com/curl/curl-for-win/tree/9d77e31e 에 있습니다.

패키징하기 전에 `python3 scripts/native/build.py`(Windows: `python scripts/native/build.py`)로 빌드하세요. macOS/Linux에는 C/C++ 도구, CMake, Ninja, Perl, make, pkg-config가 필요합니다. 소스는 버전과 업스트림 SHA-256으로 `scripts/native/dependencies.lock.json`에 고정되어 있습니다. 스크립트는 모든 다운로드를 검증하고, 서드파티 전송 라이브러리를 정적으로 링크하며, HTTP2/HTTP3/SSL 기능이 없으면 실패합니다. 운영체제 라이브러리만 동적으로 남습니다. Windows는 로컬에서 컴파일한 Windows 전송 스택이 아니라 고정된 공식 바이너리 압축 파일을 사용합니다. 번들 CA 파일에는 별도로 고정된 해시가 있으며, 구성 요소 라이선스와 업스트림 빌드 출처 정보가 런타임과 함께 제공됩니다.

클라이언트와 신뢰 저장소는 app.asar 바깥의 `resources/native-runtime/<platform>-<arch>/`에 설치됩니다. 진단할 때마다 사용 전에 구성 요소 해시, 아키텍처, 실행 파일 기능을 검증합니다. 설정 파일, 프록시, TLS 신뢰 관련 환경 변수 재정의, 라이브러리 주입 변수는 제외됩니다. curl은 절대 경로, 셸 비활성화, 검증된 CA 신뢰, 명시적으로 확인된 IP 주소 계열로 실행되며, 쿠키와 자동 리디렉션 없이 출력과 시간을 제한합니다. 리디렉션은 애플리케이션이 검증하고 다시 확인합니다. 443이 아닌 포트의 HTTPS도 지원합니다.

HTTP/3는 `--http3-only`를 사용하며, HTTP 버전 3을 보고하고 인증서 검증에도 성공한 전송이 완료된 경우에만 확인됩니다. 404와 같은 HTTP 오류 응답으로도 프로토콜을 확인할 수 있습니다. Alt-Svc는 광고일 뿐 증거가 아닙니다. QUIC 시간 초과, 인증서 실패, DNS 실패, 연결 거부, 호환되지 않는 프로토콜, 구성 요소 장애는 각각 구분됩니다. UDP 시간 초과로는 서버 지원 여부가 확인되지 않은 채로 남습니다. QUIC 핸드셰이크 시간은 TCP 시간으로 보고되지 않습니다.

측정할 때마다 별도의 프로세스/연결을 시작합니다. warm 옵션은 번들 클라이언트에서 연결이 재사용되었다고 주장하지 않습니다. 이렇게 해서 프로토콜 비교의 일관성을 유지합니다. 보고서에는 런타임 버전, 기능, TLS 검증, QUIC 시간이 포함되며, 기록/내보내기에서는 본문, URL 쿼리, 인증 헤더가 제거됩니다.

전송 스택이나 CA 신뢰 저장소를 업데이트할 때는 이 고정값들을 업데이트하고 지원되는 모든 플랫폼에서 다시 빌드하세요. 게시된 아티팩트와 소스 스냅샷은 변경되지 않습니다.