Webship 엔지니어링

TLS 종료 또는 패스-스루? 올바른 Webship 리버스 프록시 경계 선택

TLS 종료는 라우팅, 캐싱 및 HTTP 보안 검사를 가능하게 합니다; 패스스루는 평문과 세션 키를 원본에서 유지합니다. 이 가이드는 트레이드오프, 측정된 성능 및 실시간 Webship 구성을 설명합니다.

2026년 9월 10일에 게시됨

TLS 종료와 TLS 패스스루 중 선택하는 것은 단순한 프록시 설정이 아닙니다. 이는 암호화가 어디에서 끝나는지, 어느 시스템이 세션 키를 보관하는지, Webship이 HTTP를 검사할 수 있는지, 그리고 어느 계층이 애플리케이션 보안을 시행해야 하는지를 결정합니다.

Webship는 기본값으로 패스스루를 사용합니다. 이는 애플리케이션 평문과 활성 세션 키가 원본에 그대로 유지되도록 합니다. 엣지가 HTTP 요청을 이해하고 처리해야 할 때만 종료를 활성화하세요.

한 문장으로 된 결정

원본 서버가 TLS 경계를 반드시 가져야 하는 경우 TLS 패스스루를 사용합니다. Webship가 HTTP 트래픽을 라우팅, 보호, 변환, 캐시 또는 관찰해야 하는 경우 TLS 종료를 사용합니다.

어느 모드도 보편적으로 더 안전한 것은 아닙니다. 패스스루(pass-through)는 엣지에서 처리되는 민감한 자료를 줄이지만, 엣지의 HTTP 보안 제어를 제거합니다. 종료(termination)는 검사 가능한 시행 지점을 추가하지만, Webship을 신뢰할 수 있는 TLS 경계의 일부로 만듭니다.

| 관심사 | TLS 종료 | TLS 패스스루 | | --- | --- | --- | | TLS 엔드포인트 | Webship | 출처 | | Webship에서 애플리케이션 일반 텍스트 | 예 | 아니요 | | Webship에서 활성 다운스트림 세션 키 | 예 | 아니요 | | HTTP 경로 또는 메서드별 라우트 | 예 | 아니요 | | WAF, API Shield, 및 본문 제한 Webship | 예 | 아니요 | | 프록시 캐시, 재작성 및 전달 헤더 | 예 | 아니오 | | TCP 라우팅 입력 | HTTP 권한 및 경로 정책 | ClientHello SNI | | HTTP/3 라우팅 | HTTP 요청 데이터 | 하나의 공유 UDP 출처 | | 원본 책임 | HTTP 또는 별도로 구성된 업스트림 TLS | 전체 TLS, ALPN 및 HTTP 스택 |

따라서 중요한 질문은 '어떤 스위치가 더 빠른가?'가 아니다. 중요한 질문은 '어떤 구성 요소가 요청을 보고 제어할 수 있도록 허용되어야 하는가?'이다.

Webship을 종료하면 어떤 결과가 발생합니까

tls_termination = true와 함께, Webship는 다운스트림 TLS를 완료하고 복호화된 요청을 HTTP 리버스 프록시 파이프라인으로 전달합니다. 이는 다음과 같은 기능을 가능하게 합니다:

경로, 호스트 및 메서드 인식 라우팅;
WAF 및 API Shield 검사;
요청 본문 제한 및 정책 시간 초과;
프록시 캐싱 및 생성 안전 무효화;
포워딩 헤더 관리 및 HTTP 접근 로그 필드;
본체 인식 쿼리 처리, 안전한 경우 재시도, 및 회로 차단기 정책;
클라이언트 측 연결과 업스트림 연결 간의 프로토콜 변환.

이 모드는 보안 책임도 변경합니다. Webship 호스트는 인증서 개인 키, 세션 키, 복호화된 요청 및 응답 데이터, 관찰 가능 출력, 그리고 모든 캐시된 표현을 보호해야 합니다. 다음 홉을 암호화 상태로 유지해야 하는 경우, 타입이 지정된 업스트림 TLS를 별도로 구성하십시오. 그렇지 않으면 HTTP 업스트림은 일반 텍스트입니다.

종료는 Webship가 단순한 암호화 전송 중계가 아니라 애플리케이션 인식 엣지로 동작할 것으로 예상될 때의 오른쪽 경계입니다.

무엇이 패스스루를 보존하는가

tls_termination = false—기본값—을 사용하면 Webship은 HTTP 요청이나 응답을 복호화하지 않고 암호화된 TLS 또는 QUIC 트래픽을 전달합니다. 애플리케이션 평문과 활성 세션 키는 원본에 그대로 남아 있습니다.

인증서가 애플리케이션 계층에 남아 있어야 하거나, 규정 준수 정책상 엣지에서의 복호화가 금지되거나, 특정 원본 TLS 식별자가 클라이언트에 변경되지 않고 전달되어야 하는 경우, 그 더 작은 신뢰 경계는 가치가 있습니다. 또한 중계 경로에서 HTTP 파싱 및 정책 작업을 제거합니다.

절충안은 엄격합니다: Webship는 복호화할 수 없는 것은 검사할 수 없습니다. HTTP WAF 규칙을 적용하거나, 경로별로 라우팅하거나, 헤더를 재작성하거나, 본문 인식 API 정책을 시행하거나, HTTP 필드 접근 로그를 작성할 수 없습니다. 원본 서버는 이러한 모든 제어를 스스로 제공해야 합니다.

따라서 패스스루는 '기능이 적은 종결'이 아니다. 그것은 다른 보안 소유자를 가진 다른 아키텍처이다.

프로토콜별 제한이 중요하다

HTTP/1.1 TLS 및 HTTP/2 TLS의 경우, Webship은 SNI에 의해 구성된 TCP 목적지를 선택할 수 있을 정도로만 ClientHello를 검사합니다. 각 패스스루 도메인은 실제 요청 경로가 암호화된 상태로 유지되므로 모든 요청을 처리할 수 있는 path_prefix = "/" 경로가 필요합니다. SNI가 없는 클라이언트는 구성에 도메인이 하나만 있을 경우에만 허용됩니다.

오리진은 클라이언트의 ALPN을 협상하고 선택된 프로토콜을 지원해야 합니다. Webship은 TLS 세션이 변경되지 않은 상태로 통과하는 동안 HTTP/2 클라이언트를 HTTP/1.1 오리진으로 변환할 수 없습니다.

HTTP/3는 UDP 위에서 QUIC을 사용하며 더 엄격한 경계를 가집니다. 패스스루는 암호화된 HTTP 권한에 따라 안전하게 라우팅할 수 없으므로, 구성된 모든 HTTP/3 경로는 동일한 IP-소켓 UDP 원본으로 해결되어야 합니다. Webship은 구성 유효성 검사 중에 Unix 소켓과 다중 HTTP/3 패스스루 원본을 거부하며, 모호하게 라우팅하지 않습니다.

Cleartext HTTP/1.1와 h2c는 reverse_proxy.tls_termination의 영향을 받지 않습니다. 이 설정은 하류 HTTP/1.1 TLS, HTTP/2 TLS, 및 HTTP/3 TLS만 제어합니다.

측정된 요청 용량

Webship 1.3.1 Debian 용량 벤치마크는 두 개의 암호화된 리버스 프록시 모드를 각각 측정했습니다. 모든 수락된 샘플은 HTTP, 소켓, 프로토콜, 프록시, 주요 페이지 오류 및 HTTP/3 패킷 손실 오류가 0이어야 했습니다.

| 리버스 프록시 모드 | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS 종료 | 123,344 RPS | 124,957 RPS | 131,529 RPS | | TLS 패스스루 | 203,950 RPS | 266,845 RPS | 167,010 RPS |

소규모 응답 패스스루는 수행할 애플리케이션 작업이 적습니다: TLS를 종료하고, HTTP를 분석하고, 정책을 평가하며, 새로운 하류 TLS 스트림을 생성하는 대신 암호화된 전송 데이터를 전달합니다. 더 높은 패스스루 요청률은 그보다 좁은 작업을 반영합니다.

이 행들은 동일한 기능 세트를 나타내는 것이 아니며, 하나의 보안 아키텍처가 보편적으로 더 낫다고 주장하는 데 사용되어서는 안 됩니다. 종료(Termination)는 의도적으로 통과(pass-through) 방식으로 제공할 수 없는 HTTP 인식 기능을 위해 비용을 지불합니다.

일괄 스트리밍은 결과를 변경합니다

같은 벤치마크는 100MB 스트리밍 매트릭스에 대해 정확히 99,943,778바이트의 응답 본문을 사용했습니다. 여기서 TLS 종료는 세 가지 프로토콜 모두에서 중간 페이로드 처리량이 더 높게 나타났습니다:

| 리버스 프록시 모드 | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS 종료 | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | TLS 패스스루 | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

왜 방향이 바뀌나요? 종료 모드에서는 벤치마크 원점이 Webship에게 평문 HTTP를 전송하고, Webship이 최적화된 다운스트림 대용량 경로를 소유합니다. 큰 HTTP/1.1 및 HTTP/2 응답은 적응형 Linux kTLS와 한정된 전송 전용 버퍼링을 사용할 수 있습니다. HTTP/3는 kTLS 대신 QUIC 페이싱, DPLPMTUD, 및 리액터별 배칭을 사용합니다.

패스스루 모드에서 오리진은 다운스트림 TLS를 소유하며 Webship은 그 결과 생성된 암호화된 스트림이나 QUIC 패킷을 전달합니다. 이것은 오리진 TLS 경계를 유지하지만, Webship의 HTTP 인식 벌크 응답 경로는 사용할 수 없습니다.

7개 샘플 HTTP/3 자격 시험은 안정성도 확인했습니다. 종료된 스트리밍은 변동 계수 2.12%와 함께 1,938.6 MiB/s의 중간값에 도달했으며, 패스스루는 변동 계수 1.65%로 1,748.5 MiB/s에 도달했습니다. 두 경우 모두 클라이언트, 프로토콜, 패킷 손실 오류 없이 정확한 데이터를 전달했습니다.

의도적으로 패스스루를 구성하다

최소한의 패스스루 구성은 TLS 식별을 준비된 상태로 유지하여 운영자가 인증서 경로를 변경하지 않고 나중에 종료를 활성화할 수 있도록 합니다:

[reverse_proxy]
enabled = true
tls_termination = false

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

설정된 Webship 인증서는 검증되었지만 활성 패스스루 세션에서는 사용되지 않습니다. 10.0.0.20:443의 원본은 TLS를 종료하고 클라이언트가 협상한 프로토콜을 지원해야 합니다.

엣지가 HTTP를 필요로 할 때 종료를 활성화합니다

애플리케이션 인식 엣지를 위해, 종료를 활성화하고 생성된 HTTP 트래픽을 선택한 오리진으로 전송하십시오:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

이 구성은 HTTP를 라우팅하고 검사할 수 있습니다. Webship와 오리진 간의 네트워크가 이미 신뢰되거나 격리되지 않은 경우 업스트림 TLS를 추가하세요.

재시작 없이 모드를 전환 Webship

Webship는 구성 파일 재로드 또는 버전 확인된 webship.reverse_proxy.apply_config MCP 도구를 통해 tls_termination를 변경할 수 있습니다. webship.reverse_proxy.get_config로 현재 객체와 버전을 읽고, 반환된 전체 객체에서 의도한 필드만 변경한 다음 일치하는 expected_version_id와 함께 제출하십시오.

새로운 TCP 연결은 새로운 모드를 사용합니다. HTTP/3 클라이언트는 교체된 UDP 전송에 다시 연결합니다. 인증서 및 키 경로 변경은 프로세스에 묶여 있으며 재시작이 필요하므로, 실제 전환 전에 유효한 종료 신원을 준비해 두십시오.

버전 확인은 한 운영자가 동시에 이루어지는 구성 변경을 덮어쓰는 것을 방지합니다. 거부된 업데이트는 활성 런타임과 저장된 구성을 변경하지 않습니다.

실용적인 선택 체크리스트

다음 모든 항목이 해당될 때 통과를 선택하십시오:

원본은 인증서 경계와 세션 키를 유지해야 합니다.
SNI 수준 TCP 라우팅—또는 하나의 공유 HTTP/3 UDP 출처—면 충분합니다.
오리진은 필요한 WAF, 인증, 로깅, 본문 제한 및 남용 제어를 제공합니다.
엣지 캐시, 경로 재작성, 전달 헤더 정책 또는 HTTP 프로토콜 변환이 필요하지 않습니다.

Webship에서 다음 중 어느 것이 필요한 경우 종료를 선택하십시오:

호스트, 경로 또는 메서드별로 라우트합니다.
WAF 또는 API Shield로 요청을 검사합니다.
본문 크기 제한, HTTP 시간 제한 또는 엣지 인증을 적용합니다.
응답을 캐시하거나 HTTP 헤더를 재작성하십시오.
다운스트림과 업스트림 HTTP 프로토콜 간에 변환합니다.
프록시 경계에서 HTTP 필드를 관찰하십시오.

어떤 모드를 선택하든, SNI, ALPN, 인증서 신원, 클라이언트 취소, 업스트림 하프-클로즈, 그리고 정확한 응답 무결성을 테스트하세요. 요청 용량과 스트리밍 처리량은 별도로 측정하세요: 작은 응답에 가장 빠른 모드가 반드시 100MB 본문에 가장 빠른 모드인 것은 아닙니다.

Webship는 프록시가 신뢰 경계를 조용히 확장해서는 안 되므로 패스스루를 기본값으로 설정합니다. HTTP 인식 엣지 동작이 그 책임을 감당할 가치가 있을 때 종료는 여전히 명시적이고 활성화된 운영 선택으로 남습니다.

전체 [리버스 프록시 문서](/docs/1.3.1)를 읽고, 승인된 [벤치마크 매트릭스](/benchmarks)를 비교하거나 [다운로드](/downloads)에서 Webship를 다운로드하세요.

출처 및 내용 방법

성능 값은 2026년 9월 11일자 Webship 1.3.1 통합 Debian 용량 벤치마크에서 채택된 중앙값이며, 그 승인 기준은 클라이언트, HTTP, 소켓, 프로토콜, 프록시, 주요 페이지 결함 및 HTTP/3 패킷 손실 오류가 없어야 합니다.