Назад к блогу 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 присутствует. На карте ниже указаны 52 RFC, которые влияют на активное поведение сервера Webship или его собственные протокольные основы. Текущие стандарты указаны первыми. Заменённые документы обозначены как совместимая наследственность. Черновые спецификации не переназначаются как 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 — Протокол WebSocket. Апгрейды через реверс-прокси проверяют ключ WebSocket, значение accept, субпротокол, расширения и переход туннеля.
  • RFC 6585 — Дополнительные коды состояния HTTP. Для полей запроса, превышающих допустимый размер, используется определённый ответ 431, если отправка HTTP-ответа всё ещё возможна.
  • RFC 6797 — HTTP Strict Transport Security. Заголовок Strict-Transport-Security отправляется только через защищённый канал и никогда не просачивается из кэшированной записи, не зависящей от транспорта, на открытый HTTP.
  • RFC 7235 — Аутентификация HTTP/1.1. Токены схемы аутентификации разбираются без учета регистра, включая защищенную управляющую поверхность MCP. Их общая семантика HTTP теперь описана в RFC 9110.
  • RFC 7239 — Расширение HTTP Forwarded. Операторы могут выбрать стандартизированное поле Forwarded, устаревшие поля X-Forwarded, оба варианта или ни один; ненадежные входящие поля идентификации удаляются в первую очередь.
  • RFC 7540 — HTTP/2. Это сохраняется как линия совместимости HTTP/2; активным контрактом HTTP/2 является его последующий документ, RFC 9113.
  • RFC 7541 — HPACK: Сжатие заголовков для HTTP/2. Стек HTTP/2, принадлежащий Webship, ограничивает состояние декодера и таблицы кодировщика, при этом сохраняя формат передачи HPACK и кодирование Хаффмана.
  • RFC 7838 — Альтернативные сервисы HTTP. Alt-Svc объявляет конечную точку HTTP/3 без изменения происхождения, представленного URL.
  • RFC 8441 — Начальная настройка WebSockets с помощью HTTP/2. Webship поддерживает расширенную основу согласования CONNECT для нисходящего потока. Он не утверждает, что восходящий HTTP/1.1 поток реализует расширенный CONNECT HTTP/2; неподдерживаемые комбинации восходящих потоков завершаются с явной ошибкой.
  • RFC 8470 — Использование ранних данных в HTTP. Ранние запросы, которые Webship не будет обрабатывать, получают ответ 425 Too Early вместо того, чтобы обрабатываться с небезопасными предположениями о повторной передаче.
  • RFC 8941 — Структурированные значения полей для HTTP. Значения приоритета HTTP используют разбор словаря структурированных полей; неправильно сформированные необязательные поля полностью игнорируются.
  • RFC 9110 — Семантика HTTP. Методы, коды состояния, поля, валидаторы, предуслования, перенаправления, метаданные содержимого, HEAD, CONNECT, OPTIONS и семантика диапазонов имеют один текущий контракт для всех версий протокола.
  • RFC 9111 — HTTP Кэширование. Webship реализует скорректированный возраст, явную свежесть, Vary, only-if-cached, must-revalidate, proxy-revalidate, безопасное использование устаревших данных и инвалидизацию эффективных и связанных URI.
  • RFC 9112 — HTTP/1.1. Правила request-line, field, body-length, transfer-coding, chunk, trailer, persistence и close-delimited применяются до передачи управления приложению.
  • RFC 9113 — HTTP/2. Псевдополя order, authority, запрещённые поля соединения, ограничения TE, жизненный цикл потока, управление потоком, GOAWAY и область ошибок обрабатываются H2-путём, принадлежащим Webship.
  • RFC 9114 — HTTP/3. Webship владеет путями запроса, управляющего потока, SETTINGS, критического потока, отмены и ошибок потока против соединения, используемыми его сервером HTTP/3.
  • RFC 9204 — QPACK: сжатие полей для HTTP/3. Вместимость динамической таблицы ограничена объявленным пределом, потоки инструкций остаются разбираемыми при нулевой вместимости, а недопустимое состояние становится требуемой ошибкой QPACK.
  • RFC 9218 — Расширяемая схема приоритизации для HTTP. Срочность и поэтапная доставка направляют планирование HTTP/3, в то время как неизвестные параметры приоритета остаются расширяемыми.
  • RFC 9220 — Инициализация WebSockets с использованием HTTP/3. Webship реализует основу SETTINGS расширенного CONNECT HTTP/3, используемую современными туннелированными протоколами; это не подразумевает, что каждый возможный протокол CONNECT принимается.
  • RFC 9297 — HTTP-датаграммы и протокол капсул. Сессии WebTransport используют ограниченное декодирование капсул и ассоциацию HTTP-датаграмм, при этом неизвестные капсулы обрабатываются как точки расширения, а не как ошибки парсера.
  • RFC 9421 — Подписи HTTP-сообщений. Дополнительная проверка происхождения ответа с использованием Ed25519 может охватывать выпуск Webship и идентификацию конфигурации без замены TLS или аутентификации приложения.
  • RFC 10008 — Метод HTTP QUERY. Webship рассматривает QUERY как безопасный и идемпотентный, сохраняет его тело при проксировании, включает тело и метаданные представления в идентификатор кэша, запрещает эвристическую свежесть, поддерживает условное поведение и поведение с диапазоном, и никогда не инвалидирует кэш просто из-за использования QUERY.

Транспорт QUIC и управление перегрузкой

TLS, сертификаты и автоматическое управление сертификатами

WebTransport: точно о том, что стандартизировано

WebTransport через HTTP/3 не считается пятьдесят третьим RFC. По состоянию на Webship 1.3.1 его схема передачи по проводу остается draft-ietf-webtrans-http3-16. Webship реализует этот черновик поверх стандартизированного HTTP/3, расширенного CONNECT, QUIC DATAGRAM, HTTP Datagram и упомянутых выше слоев Capsule. Он также реализует согласованное расширение RESET_STREAM_AT, необходимое для сохранения надежного префикса идентификации сессии при сбросе потока WebTransport.

Это различие имеет значение. Совместимость со стандартами не улучшается, если называть проект 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 обслуживает и проксирует большие медиафайлы через HTTP/1.1, HTTP/2 и HTTP/3, используя адаптивный kTLS, планирование BBR, ограниченные буферы и шлюзы целостности без ошибок.

Читать статью

Ваш веб-сервер — это решение по поводу стоимости инфраструктуры

Webship объединяет высокопроизводительную доставку на Rust, современные протоколы, встроенную защиту, локальную наблюдаемость и операции с поддержкой ИИ в одном исполнении — предоставляя инфраструктурным командам реальный путь к меньшему количеству серверов и компонентов на периферии.

Читать статью

Webship 1.3.1: Повышенная производительность HTTP/2 и обратного прокси

Webship 1.3.1 увеличивает прямую пропускную способность h2c на 34,19%, прямую HTTP/2 TLS на 26,67% и обратного прокси H1 на 15,10% по сравнению с 1.2.0, при этом укрепляя стабильность и корректность транспортировки.

Читать статью