Webship 블로그로 돌아가기

Webship 엔지니어링

Webship: 세계에서 가장 RFC 호환성이 높은 웹 서버

Webship는 RFC 요구 사항을 HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, 캐싱, 리버스 프록시, WebTransport, ACME 및 새로운 QUERY 메서드 전반에 걸친 명시적 동작으로 전환합니다. 전체 52개의 RFC 표준 지도를 탐색해 보세요.

웹은 정확한 합의에 의해 유지됩니다. Content-Length 필드는 각 중간 단계에서 동일한 의미여야 합니다. 캐시는 검증이 필요한 응답을 재사용해서는 안 됩니다. 잘못된 형식의 HTTP/3 필드 섹션은 올바른 범위에서 실패해야 합니다. 안전한 메서드는 리버스 프록시를 통과한 후에도 안전해야 합니다.

Webship 1.3.1은 한 가지 규칙을 중심으로 만들어졌습니다: 바이트가 의미를 유지할 때만 속도가 중요합니다.

그것이 바로 우리가 Webship을 세계에서 가장 RFC 호환성이 높은 범용 웹 서버라고 설명하는 이유입니다. 이것은 모든 RFC의 선택적 기능이 존재한다는 주장이 아니라, 명확한 경계를 가진 엔지니어링적 주장입니다. 아래 지도는 Webship의 활성 서버 동작이나 자체 프로토콜 기반에 영향을 미치는 52개의 RFC를 명시하고 있습니다. 현재 표준이 먼저 나오며, 대체된 문서는 호환성 계보로 표시됩니다. 초안 사양은 RFC로 재분류되지 않습니다.

호환성은 배지가 아니라 행동입니다

Webship는 생산 서버가 가장 자주 모호해지는 장소에서 기준을 적용합니다:

  • HTTP/1.1 프레이밍은 상충되는 길이, 잘못된 전송 코딩, 과도한 요청 대상, 잘못된 청크, 그리고 요청 스머글링 형태를 거부합니다.
  • HTTP/2와 HTTP/3는 금지된 연결 필드를 거부하고, 의사 필드를 검증하며, 압축된 필드 섹션에 한계를 두고, 스트림 오류를 연결 오류와 분리합니다.
  • 정적 파일은 HEAD 의미론, 검증자, 전제 조건 순서, 바이트 범위, 리디렉션 및 콘텐츠 유형을 유지합니다.
  • 리버스 프록시는 홉 단위 필드를 제거하면서 프레이밍, 취소, 트레일러, 업그레이드, 안전한 재시도 및 전달 신원을 유지합니다.
  • 캐시는 캐싱을 키-값 단축키로 취급하는 대신, 나이, 신선도, 재검증, Vary, 무효화 및 오래된 사용 규칙을 계산합니다.
  • TLS, QUIC, ACME, 초기 데이터 및 WebTransport는 제한된 상태와 명시적인 실패 정책을 사용합니다.

빠른 경로에도 동일한 규칙이 적용됩니다. Webship은 하나의 '정확한' 경로와 다른 벤치마크 경로를 정의하지 않습니다.

HTTP 의미론, 프레이밍, 캐싱 및 프록시

  • RFC 3986 — 통합 자원 식별자(URI): 일반 구문. Webship은 캐시 무효화 결정을 내리기 전에 점(.) 세그먼트를 포함한 상대 위치(Location) 및 콘텐츠 위치(Content-Location) 참조를 정규화합니다.
  • RFC 6455 — 웹소켓 프로토콜. 리버스 프록시 업그레이드는 웹소켓 키, 수락 값, 서브프로토콜, 확장 및 터널 전환을 검증합니다.
  • RFC 6585 — 추가 HTTP 상태 코드. 요청 필드가 너무 큰 경우, HTTP 응답이 여전히 가능한 경우 정의된 431 응답을 사용합니다.
  • RFC 6797 — HTTP 엄격 전송 보안. Strict-Transport-Security는 보안 전송에서만 전송되며, 절대 전송 중립 캐시 항목에서 평문 HTTP로 유출되지 않습니다.
  • RFC 7235 — HTTP/1.1 인증. 인증 스킴 토큰은 보호된 MCP 제어 표면을 포함하여 대소문자를 구분하지 않고 구문 분석됩니다. 일반적인 HTTP 의미론은 이제 RFC 9110에 있습니다.
  • RFC 7239 — 전달된 HTTP 확장. 운영자는 표준 기반 Forwarded 필드, 이전 X-Forwarded 필드, 둘 다 또는 어느 것도 선택할 수 있습니다; 신뢰할 수 없는 수신된 신원 필드는 먼저 제거됩니다.
  • RFC 7540 — HTTP/2. 이것은 HTTP/2 호환성 계보로 유지됩니다; 활성 HTTP/2 계약은 그 후속 문서인 RFC 9113입니다.
  • RFC 7541 — HTTP/2를 위한 헤더 압축: HPACK. Webship에서 소유한 HTTP/2 스택은 HPACK 와이어 포맷과 허프만 코딩을 유지하면서 디코더 상태와 인코더 테이블을 제한합니다.
  • RFC 7838 — HTTP 대체 서비스. Alt-Svc는 URL이 표시하는 원본을 변경하지 않고 HTTP/3 엔드포인트를 광고합니다.
  • RFC 8441 — HTTP/2로 웹소켓 부트스트래핑. Webship는 다운스트림 확장 CONNECT 협상 기반을 지원합니다. HTTP/1.1 업스트림이 HTTP/2 확장 CONNECT를 구현하는 척하지 않습니다; 지원되지 않는 업스트림 조합은 명시적으로 실패합니다.
  • RFC 8470 — HTTP에서 초기 데이터 사용. Webship가 처리하지 않을 초기 요청은 안전하지 않은 재생 가정을 사용하여 처리되는 대신 425 Too Early 응답을 받습니다.
  • RFC 8941 — HTTP를 위한 구조화된 필드 값. HTTP 우선순위 값은 구조화된 필드 사전 파싱을 사용합니다; 잘못된 선택적 필드는 전체가 무시됩니다.
  • RFC 9110 — HTTP 의미론. 메서드, 상태 코드, 필드, 검증기, 전제 조건, 리디렉션, 콘텐츠 메타데이터, HEAD, CONNECT, OPTIONS 및 범위 의미론은 프로토콜 버전에 걸쳐 하나의 현재 계약을 공유합니다.
  • RFC 9111 — HTTP 캐싱. Webship은 수정된 연령(corrected age), 명시적 신선도(explicit freshness), Vary, only-if-cached, must-revalidate, proxy-revalidate, 안전한 오래된 콘텐츠 사용(safe stale use), 그리고 유효한 URI 및 관련 URI의 무효화(invalidation)를 구현합니다.
  • RFC 9112 — HTTP/1.1. 요청 라인, 필드, 본문 길이, 전송 인코딩, 청크, 트레일러, 지속성, 닫기 구분 규칙은 애플리케이션 전달 전에 적용됩니다.
  • RFC 9113 — HTTP/2. 의사 필드 순서, 권한, 금지된 연결 필드, TE 제한, 스트림 생명주기, 흐름 제어, GOAWAY 및 오류 범위는 Webship가 소유한 H2 경로에서 처리됩니다.
  • RFC 9114 — HTTP/3. Webship는 HTTP/3 서버에서 사용하는 요청, 제어 스트림, SETTINGS, 중요한 스트림, 취소, 스트림 대 연결 오류 경로를 소유합니다.
  • RFC 9204 — QPACK: HTTP/3를 위한 필드 압축. 동적 테이블 용량은 광고된 한도로 제한되며, 명령 스트림은 용량이 0일 때도 파싱 가능하고, 잘못된 상태는 필수 QPACK 오류가 됩니다.
  • RFC 9218 — HTTP를 위한 확장 가능한 우선순위 지정 체계. 긴급성과 점진적 전송은 우선순위 매개변수가 알려지지 않은 상태에서도 HTTP/3 스케줄링을 안내합니다.
  • RFC 9220 — HTTP/3로 WebSockets 부트스트랩. Webship은 현대 터널링 프로토콜에서 사용되는 HTTP/3 확장-CONNECT SETTINGS 기반을 구현합니다; 이는 모든 가능한 CONNECT 프로토콜이 허용된다는 것을 의미하지 않습니다.
  • RFC 9297 — HTTP 데이터그램 및 캡슐 프로토콜. WebTransport 세션은 제한된 캡슐 디코딩과 HTTP 데이터그램 연관을 사용하며, 알려지지 않은 캡슐은 파서 실패 대신 확장 지점으로 처리됩니다.
  • RFC 9421 — HTTP 메시지 서명. 선택적 Ed25519 응답 출처는 TLS나 애플리케이션 인증을 대체하지 않고 Webship 릴리스 및 구성 식별을 포함할 수 있습니다.
  • RFC 10008 — HTTP QUERY 메서드. Webship은 QUERY를 안전하고 멱등한 것으로 처리하며, 프록시를 통해 본문을 보존하고, 캐시 식별에는 본문과 표현 메타데이터를 포함하며, 휴리스틱 신선도를 금지하고, 조건부 및 범위 동작을 지원하며, 단순히 QUERY가 사용되었다고 해서 캐시를 무효화하지 않습니다.

QUIC 전송 및 혼잡 제어

TLS, 인증서 및 자동 인증서 관리

WebTransport: 표준화된 내용에 대해 정확히

HTTP/3 위의 WebTransport는 53번째 RFC로 간주되지 않습니다. Webship 1.3.1 기준으로, 그 전송 맵핑은 여전히 draft-ietf-webtrans-http3-16입니다. Webship는 표준화된 HTTP/3, 확장 CONNECT, QUIC DATAGRAM, HTTP Datagram, 그리고 위에 언급된 캡슐 계층 위에 해당 초안을 구현합니다. 또한 WebTransport 스트림이 재설정될 때 신뢰할 수 있는 세션 식별 접두사를 유지하기 위해 필요한 협상된 RESET_STREAM_AT 확장도 구현합니다.

그 구분은 중요합니다. 초안을 RFC라고 부른다고 해서 표준 호환성이 향상되지는 않습니다. 표준 호환성은 초안을 명확히 추적하고, 이를 일반 HTTP 경로와 분리하며, 모든 확장을 협상하고, 모든 세션 자원을 제한하며, 취소 및 실패 동작을 테스트함으로써 향상됩니다.

왜 이러한 폭이 생산에서 중요한가

표준 버그는 거의 단독으로 발생하지 않습니다. 잘못된 HSTS 처리로 인해 캐시 경계가 넘어갈 수 있습니다. 잘못된 QPACK 명령은 관련 없는 요청을 종료시킬 수 있습니다. 안전하지 않은 초기 데이터 가정은 작업을 재실행할 수 있습니다. 요청 본문을 생략한 QUERY 캐시 키는 다른 쿼리의 결과를 반환할 수 있습니다. 트레일러를 제거하거나 취소를 잘못 처리하는 프록시는 애플리케이션 프로토콜을 조용히 변경할 수 있습니다.

Webship의 아키텍처는 이러한 것들을 연결된 관심사로 취급합니다. 파서 제한, 보안 검사, 캐싱, 리버스 프록시, 전송 상태 및 계측은 명시적인 계약을 공유합니다. 그 결과 하나의 서버가 각 모드에 대해 다른 올바름 정의를 제공하지 않고도 HTTP/1.1, HTTP/2, HTTP/3, 정적 전송, 리버스 프록시, 스트리밍, WebTransport 간을 이동할 수 있습니다.

주장을 확인하다

믿음으로 과장된 표현을 받아들이지 마십시오. [Webship 1.3.1 문서](/docs/1.3.1)를 읽고, 구성과 프로토콜 경계를 점검하며, 게시된 동작을 재현하십시오. 그런 다음 [Webship을 다운로드](/downloads)하고 시스템에 중요한 경계 사례를 테스트하십시오.

Webship 엔지니어링

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

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

글 읽기

귀하의 웹 서버는 인프라 비용 결정입니다

Webship는 고처리량 Rust 전송, 최신 프로토콜, 내장 보호, 로컬 관측성, AI-네이티브 운영을 하나의 런타임에서 결합하여 인프라 팀에게 서버와 엣지 구성 요소를 줄일 수 있는 신뢰할 수 있는 경로를 제공합니다.

글 읽기

Webship 1.3.1: 더 높은 HTTP/2 및 리버스 프록시 용량

Webship 1.3.1은 1.2.0에 비해 직접 h2c 용량을 34.19%, 직접 HTTP/2 TLS를 26.67%, 리버스 프록시 H1를 15.10% 증가시키면서 전송 안정성과 정확성을 강화합니다.

글 읽기