guidenetworking 2026-07-17squidforward-proxyhttp-connecthttps-proxyconnection-reusekeep-alivehttp2tlslab

HTTPS_PROXY 통신 흐름 실측 가이드 — CONNECT 이후 · 연결 재사용 · 재현 랩

원본은 스타일링된 HTML 실측 가이드

이 글의 본체는 실측 가이드 전문이다. raw socket + ssl.MemoryBIO로 찍은 와이어 바이트, 5케이스 재사용 매트릭스, 재현 랩 전체 스크립트, 랩에서 밟은 함정 6개를 포함한다. 모든 수치는 Squid 6.14 · curl 8.5 · TLS 1.3 랩 실측값.

→ 전문 보기 (https-proxy-connect-flow-and-lab.html)

이 페이지는 핵심 요약본.

한 문단 요약

CONNECT 200 이후에도 새로 열리는 것은 없다. 프록시에 연결했던 같은 소켓(fd) 위에서 앱↔프록시의 평문 대화(전반)와 앱↔origin의 암호화 대화(후반)가 시간순으로 이어질 뿐이고, Squid는 후반부에서 화자가 아니라 전선이다. “연결 재사용"이 헷갈리는 이유는 연결이라는 한 단어가 네 개 층(TCP·터널·TLS 세션·HTTP 요청)을 가리키기 때문 — 위 세 층은 한 몸으로 태어나 함께 죽고, 요청만 N개다. 그래서 터널 수를 정하는 주체는 Squid가 아니라 앱과 origin이다. keep-alive면 3요청이 1터널, Connection: close면 요청마다 새 터널·새 ACL 심사·새 로그 줄, HTTP/1.1 동시 요청은 반드시 터널을 늘리고 HTTP/2는 스트림으로 접어 넣는다. 이 성질이 egress gateway(A안) 용량 산정의 기준 단위가 “요청 수"가 아니라 “동시 터널 수"인 이유다.

구성

장	주제	핵심
00	세 줄 요약	소켓 하나·대화 둘, TLS 세션 단위, 터널 수는 앱이 정한다
01	CONNECT 이후	같은 fd 위에서 화자만 바뀐다. ACL 심사는 터널 개설 시 딱 1회
02	바이트로 확인	raw socket 실측 — SNI만 평문, 경로 문자열은 와이어에서 소멸
03	연결 재사용과 네 개의 층	TCP·터널·TLS는 1개, 요청만 N개. 풀 키 = (scheme, host, port, proxy)
04	재사용 매트릭스	5케이스 실측 — 측정 원리는 “터널 1개 = access.log 1줄”
05	재현 랩 구성	세 관측 지점(앱·Squid·origin) + 가짜 프록시·MemoryBIO 트릭
06	함정 6개	ACL first-match, ipcache, 단일 스레드 교착, 404=close 등
07	진단 치트시트	파드에서 읽기 전용으로 실패 구간 판별

재사용 매트릭스 — 5케이스 실측

케이스	조건	요청	터널
A	순차 · keep-alive · 같은 호스트	3	1
B	순차 · `Connection: close`	3	3
C	병렬 · HTTP/1.1	3	3
D	순차 · 서로 다른 호스트	2	2
E	병렬 · HTTP/2	3	1

운영에서 놓치기 쉬운 것

Squid 로그 줄 수는 요청 수가 아니라 터널 수다. keep-alive면 3요청이 1줄, h2 앱이면 수천 요청이 1줄. 로그 줄 수 기반 감사·과금·이상탐지는 이미 어긋나 있을 수 있다.
TLS 검증 실패는 프록시 로그에 안 남는다. Squid는 200 주고 정상 터널로 기록하는데 앱만 실패하는 패턴 — 사내 CA 미배포·인증서 만료·SAN 불일치가 전부 여기다. 진단은 앱 쪽 curl -v의 subject/issuer 줄.
앱의 동시 터널 수 = gateway의 동시 연결 수. A안에서 Envoy는 TCP 프록시라 downstream:upstream을 1:1로 맺는다. 앱 커넥션 풀 설정(예: Go MaxIdleConnsPerHost 기본 2)이 gateway ephemeral port 소모량을 그대로 결정한다.
TLS session resumption ≠ 터널 재사용. 핸드셰이크 왕복은 줄지만 CONNECT·ACL 심사·로그 줄은 그대로 새로 발생한다 — 다른 층의 최적화다.

Files

Raw Markdown (index.md)