Webship 엔지니어링

Webship과 함께 스트리밍: 정확성을 희생하지 않고 높은 처리량

Webship가 적응형 kTLS, BBR 페이싱, 제한된 버퍼, 제로 오류 무결성 게이트를 사용하여 HTTP/1.1, HTTP/2, HTTP/3를 통해 대용량 미디어 파일을 제공하고 프록시하는 방법을 알아보세요.

2026년 9월 10일에 게시됨

스트리밍 성능은 단순히 비디오 플레이어의 문제만이 아닙니다. 소프트웨어 아티팩트, 모델 가중치, 백업, 오디오 라이브러리, 그리고 대규모 API 내보내기 모두 동일한 기본 원칙에 의존합니다: 바이트를 빠르게 이동시키고, 정확한 페이로드를 보존하며, 역압을 존중하고, 클라이언트가 연결을 끊을 때 깔끔하게 중단하는 것입니다.

Webship은 이러한 요구 사항들을 HTTP/1.1, HTTP/2, HTTP/3, 직접 파일 전송, 리버스 프록싱, 그리고 WebTransport를 포괄하는 하나의 전송 문제로 다룹니다. 빠른 경로는 프레이밍, 취소, 트레일러, 보안 검사, 그리고 제한된 메모리를 유지할 때만 유용합니다.

측정된 100MB 스트리밍 용량

Webship 1.3.1 Debian 용량 실행은 고정 100MB 픽스처로 측정된 중앙값 페이로드 처리량을 기록했습니다. 수락된 모든 샘플은 정확히 99,943,778바이트의 응답 본문과 클라이언트, 프로토콜, 프록시, 주요 페이지 결함, 그리고 HTTP/3 패킷 손실 오류가 없음을 요구했습니다.

| Webship 모드 | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | 직접 파일 전달 | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | 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은 측정된 모든 프로토콜에 대해 가장 높은 직접 및 TLS 종료 중간값을 나타냈습니다. 전체 행렬에는 Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora, 그리고 Bun이 [벤치마크 페이지](/benchmarks)에 포함되어 있습니다.

이 숫자는 벤치마크 호스트에서의 용량을 측정한 것입니다. 이는 임의의 인터넷 경로에 대한 약속이 아닙니다. 스토리지 지연 시간, 네트워크 대역폭, 왕복 시간, 패킷 손실, TLS 정책, 동시성, 원본 동작은 여전히 실제 전달 속도를 결정합니다.

하나의 이진, 세 가지 전송 전략

큰 응답은 작은 HTML 문서와 같은 정책의 혜택을 받지 않습니다. Webship은 일반 요청 경로를 보수적으로 유지하고 입증된 대량 응답만을 촉진합니다.

HTTP/1.1: 파일 주변의 전환이 적음

리눅스에서, Webship는 응답 헤드와 파일 페이로드를 하나의 최선-effort TCP 코르크 간격 안에 유지합니다. 큰 TLS 응답이 벌크 경로에 적합해지면, 직접 파일 전달은 Rustls 레코드에서 감사된 단방향 커널 TLS로 이동할 수 있으며 페이로드를 애플리케이션 버퍼를 통해 복사하지 않고 sendfile을 사용할 수 있습니다.

연결은 여전히 사용자 공간 TLS에서 시작됩니다. 작은 응답은 그곳에 남아 있습니다. Webship는 연결이 대용량 데이터를 전송하고 있음을 증명하는 최소 1 MiB의 응답 본문 이후에만 kTLS 전환을 요청합니다.

HTTP/2: 흐름 제어를 깨지 않고 배치 처리

HTTP/2 멀티플렉싱은 통제되지 않은 버퍼링을 비싸게 만든다. Webship은 스트림과 연결 흐름 제어 제한을 유지하면서 기록을 배치한다. 높은 동시성 스트리밍의 경우, 128 KiB TLS 쓰기 버퍼는 두 개의 64 KiB DATA 프레임을 담을 수 있으며, 연결 전송 예산은 명시적이고 제한된 상태로 유지된다.

이미 준비된 업스트림 바디 프레임은 하이퍼 프레이밍, 트레일러, 취소, 검사 또는 백프레셔를 우회하지 않고도 미리 가져올 수 있습니다. 이는 프로토콜 계약을 유지하면서 피할 수 있는 스케줄러 라운드를 줄여줍니다.

HTTP/3: kTLS 대신 QUIC 페이싱

HTTP/3는 TCP kTLS 경로를 절대 사용하지 않습니다. Webship는 전송 인식 QUIC 페이싱, 제한된 데이터그램 패킷화, DPLPMTUD, 그리고 리액터별 타이머 기반 마이크로배칭을 적용합니다. 대형 HTTP/3 응답과 수락된 WebTransport 세션은 일반 트래픽에 사용되는 CUBIC 정책을 변경하지 않고 BBR을 선택할 수 있습니다.

집중적인 HTTP/3 안정성 검증에는 일곱 개의 승인된 샘플이 사용되었습니다. TLS 종료 스트리밍은 변동 계수 2.12%로 1,938.6 MiB/s의 중간값을 제공했습니다. TLS 패스 스루는 변동 계수 1.65%로 1,748.5 MiB/s를 제공했습니다. 두 시리즈 모두 본문 무결성, 클라이언트, 프로토콜, 패킷 손실 오류가 없었습니다.

직접 전달 또는 리버스 프록시?

배포된 파일 트리를 Webship가 소유할 때 직접 배달을 사용하세요. 이는 원본 홉을 제거하고 가장 효율적인 정적 파일 경로를 가능하게 합니다.

최소한의 다중 프로토콜 사이트는 다음과 같이 보입니다:

listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"

[[sites]]
domain = "media.example.com"
root = "/srv/media"

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

[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"

경로로 라우팅해야 하거나, WAF 또는 API Shield 검사를 적용해야 하거나, 본문 제한을 적용해야 하거나, 전달 헤더를 추가해야 하거나, HTTP 필드를 관찰해야 하는 경우 Webship에서 리버스 프록시 TLS 종료를 사용하십시오:

[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 = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]

원본이 애플리케이션 평문과 활성 세션 키를 유지해야 하는 경우 tls_termination = false을 설정하십시오. 패스스루는 암호화된 HTTP 필드를 검사할 수 없습니다. 따라서 TCP 패스스루는 ClientHello SNI에 따라 라우팅되며, HTTP/3 패스스루는 하나의 공유 UDP 원본이 필요합니다.

대량 스트리밍을 명시적으로 조정

고동시성 HTTP/2 TLS 스트리밍을 위해, Webship는 이 프로세스 기반 설정을 문서화합니다:

[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"

위의 연결 예산은 256개의 활성 스트림에 대해 128 KiB의 크레딧을 제공합니다. 이를 보편적인 기본값이 아니라 용량 결정으로 간주하십시오. 증가시키기 전에 예상 동시성에서 메모리, 지연 시간 및 처리량을 측정하십시오.

리눅스에서 커널 TLS와 BBR 모듈을 로드하고 Webship 서비스 계정이 BBR을 선택할 수 있도록 허용합니다. Webship은 필요한 커널 기능을 사용할 수 없을 경우 바인딩 전에 실패하므로, 배포가 이를 실행하지 않으면서 최적화된 경로를 조용히 사용할 수 없습니다. 다른 운영 체제는 해당 플랫폼에 문서화된 휴대 가능한 Rustls 및 혼잡 제어 경로를 유지합니다.

WebTransport은 다른 스트리밍 형태입니다

WebTransport는 안전한 세션에서 신뢰할 수 있는 스트림과 신뢰할 수 없는 데이터그램을 결합합니다. TCP kTLS를 사용하지 않습니다. Webship의 제한된 진단 엔드포인트는 출처를 검증하고 세션, 스트림, 캡슐, 데이터그램, 바이트 및 유휴 시간 제한을 적용합니다.

1.3.1 용량 테스트에서, 직접 WebTransport 는 신뢰할 수 있는 스트림에서 1,018.1 MiB/s, 데이터그램에서 1,038.9 MiB/s에 도달했습니다. TLS 패스스루는 각각 548.6 MiB/s 및 629.7 MiB/s에 도달했습니다. 두 모드 모두 다섯 개 샘플 모두를 통과했으며, 거부된 샘플, 손실된 데이터그램, 클라이언트 주요 오류가 없었습니다.

새로운 WebTransport 클라이언트에는 HTTP/3를 사용하는 것이 좋습니다. HTTP/2 경로는 이전 만료된 초안 설정과의 호환성을 위해 존재합니다.

프로덕션 트래픽 전에 확인할 사항

작고 합성된 반응뿐만 아니라 실제로 제공할 미디어나 아티팩트의 정확한 크기를 테스트하세요.
클라이언트에서 응답 길이와 내용 요약을 확인하십시오.
운동 취소, 범위 요청, 느린 독자, 및 원점 반닫힘 동작.
CPU, 메모리, 소켓 오류, 재전송 및 꼬리 지연과 함께 지속적인 처리량을 측정하십시오.
직접 모드, TLS 종료 모드, 패스스루 모드를 각각 검증하세요. 이들은 서로 다른 보안 및 라우팅 경계를 가지고 있습니다.
일반적인 생산 트래픽에는 계측을 끄고, 조사할 때만 제한된 진단을 의도적으로 활성화하세요.
커널, 컨테이너, 또는 systemd 샌드박스 변경 후 Linux kTLS와 BBR 사전 점검을 다시 확인하십시오.

전체 경로가 협력할 때 스트리밍은 빠릅니다. Webship의 설계는 하나의 운영 모델과 하나의 정확성 기준을 유지하면서 대용량 데이터 최적화를 프로토콜별로 유지합니다.

전체 [Webship 1.3.1 문서](/docs/1.3.1)를 읽고, [벤치마크 방법론 및 경쟁사 매트릭스](/benchmarks)를 확인하거나, [다운로드](/downloads)에서 서명된 빌드를 다운로드하세요.