Большая загрузка через прокси: Expect 100-continue

Основная идея

Expect: 100-continue даёт серверу возможность проверить заголовки и ответить окончательным статусом до передачи тела. Клиент всё равно использует таймер ожидания и может начать отправку, если промежуточный ответ не пришёл; это не является гарантией экономии всего трафика.

В статье «Большая загрузка через прокси: Expect 100-continue» важно не приписывать протоколу свойства сервиса. Стандарт описывает формат сообщений и обязательное поведение сторон, а коммерческий продукт отдельно определяет географию, ротацию, срок и поддерживаемые команды. Чёткое разделение помогает понять, почему одна программа принимает строку подключения, а другая требует отдельные поля или вообще не поддерживает нужный режим.

Что подтверждает первичный источник

Проверяем, может ли сервер отклонить запрос до отправки большого тела, и отдельно измеряем ожидание 100 Continue.

Первичный источник «RFC 9110 — Expect, RFC 9112 — HTTP/1.1, MDN Expect, curl manual, NGINX proxy module» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

Практический стенд

Создайте 8 MiB файл без пользовательских данных. Отправьте его на четыре тестовых маршрута с Expect и без него, записывая trace клиента и счётчик принятых origin bytes. Добавьте proxy timeout короче задержки 100 Continue. Отрицательный тест должен показать, какой участник решил начать тело и сколько данных успело пройти.

Проверка шаг за шагом

На своём upload endpoint подготовьте допуск, 401, 413 и медленный промежуточный ответ. Используйте небольшой синтетический файл и ограничитель скорости, чтобы увидеть момент начала body. Сравните прямой путь и proxy, не увеличивая тестовый объём без необходимости.

Начните с матрицы возможностей: схема адреса, TCP или UDP, локальное или удалённое разрешение DNS, способ авторизации и поддержка IPv6. Заполняйте её по документации клиента и прокси, а не по названию настройки. Затем проверяйте по одной возможности на собственном endpoint, начиная с простого TCP-запроса и только потом добавляя DNS, TLS и прикладной сценарий.

При сбое сохраните границу, на которой он возник: разбор адреса, выбор метода авторизации, открытие туннеля, TLS или ответ origin. Коды разных уровней нельзя складывать в одну категорию. Ошибка SOCKS, отказ HTTP CONNECT и статус 403 конечного сайта требуют разных действий, хотя пользователь во всех трёх случаях видит неоткрывшуюся страницу.

• Подготовить четыре ответа
• Измерить отправленные body bytes
• Сравнить Expect и обычный POST
• Проверить timeout посредника

Какие данные сохранить

Фиксируйте request ID, Expect, Content-Length, interim/final statuses, timestamps, client sent bytes, origin received bytes и proxy error category. Payload и Authorization не сохраняйте.

Полезная трассировка содержит протокол и версию, команду клиента, адрес назначения в обезличенном виде, код ответа посредника и код origin. Для DNS отдельно указывайте, кто разрешал имя. Пакетный дамп используют только на тестовом стенде и очищают от полезной нагрузки; для большинства разборов достаточно подробного лога клиента без реквизитов.

Сразу задайте имена колонок отчёта и формат времени. Результат без контекста быстро превращается в догадку: неизвестно, какой адрес использовался, был ли кэш и что изменилось. Сохраняйте не только успех, но и контролируемые отказы. Они доказывают, что проверка действительно различает состояния, а не всегда рисует зелёный индикатор.

Как читать результат

Сохраняйте отдельно время до 100, время до первого байта окончательного ответа, реально переданные body bytes и конечный статус. Если proxy сам сформировал ошибку, origin log не должен показывать полный upload.

HTTP/2 и HTTP/3 иначе кадрируют запрос, а библиотеки имеют собственные пороги и таймеры. Поведение curl нельзя автоматически переносить на браузер.

Один успешный запуск подтверждает только конкретную комбинацию клиента, маршрута и времени. Для устойчивого вывода повторите опыт, изменяя одну переменную, и укажите границы. Если наблюдение расходится с документацией, сначала исключите кэш, версию программы и промежуточный сервер, а затем сформулируйте воспроизводимый пример для поддержки.

Разбор рабочего решения

В практическом разборе «Большая загрузка через прокси: Expect 100-continue» заведите матрицу из строк «возможность» и столбцов «стандарт», «прокси-сервис», «клиент» и «проверено». Например, удалённый DNS может быть предусмотрен форматом SOCKS5, поддерживаться сервисом, но не включаться конкретной библиотекой. Только пересечение четырёх столбцов даёт рабочую функцию. Ссылка на RFC без проверки клиента и зелёный ответ клиента без понимания протокола одинаково недостаточны.

Снимайте минимальную трассу, которая отвечает на вопрос. Для HTTP CONNECT обычно нужны адрес посредника, строка назначения, код посредника, состояние TLS и код origin. Для SOCKS добавьте команду, тип адреса и код ответа. Для DNS укажите, где разрешилось имя. Эти данные позволяют отличить синтаксическую ошибку от запрета политики и сетевого таймаута, не сохраняя полезную нагрузку, cookies или пароль.

После успешного опыта проверьте границы совместимости: вторую версию клиента, один альтернативный формат адреса и контролируемый отказ. Результаты занесите в таблицу поддержки продукта. Не превращайте единичное наблюдение в обещание для всех программ. Если функция зависит от версии, платформы или режима DNS, это должно быть написано рядом с примером подключения, а не спрятано в ответе поддержки.

Типичные ошибки

Распространённые ошибки — путать SOCKS5 с шифрованием, ожидать UDP от любого клиента, записывать IPv6 без квадратных скобок рядом с портом и считать HTTP/2 гарантией ускорения. Проверяйте конкретную реализацию. Даже предусмотренная стандартом команда может быть сознательно отключена сервисом или библиотекой.

Остановитесь, если растёт доля ошибок, источник вернул ограничение, результат требует обхода защиты или в журнал попали секреты. Сначала сохраните обезличенную диагностику и устраните причину. Смена IP или увеличение параллельности в такой точке скрывает проблему и может создать лишнюю нагрузку вместо полезных данных.

Критерии внедрения и сопровождение

Перед внедрением сформулируйте критерий решения: какое наблюдение разрешает продолжить работу, какое требует ручной проверки, а какое немедленно останавливает процесс. Укажите допустимый процент ошибок, максимальное время ожидания и владельца исключения. Без этих границ команда начинает объяснять одинаковый результат по-разному, а временный сбой незаметно превращается в постоянную настройку.

Через неделю после запуска проверьте, совпадают ли фактическая нагрузка, расходы и качество с тестом. Затем назначьте регулярный малый контроль и повторную проверку после обновления клиента, прокси-сервиса или сетевой схемы. Устаревшую инструкцию архивируйте вместе с датой и причиной замены, чтобы сотрудники не использовали две конфликтующие конфигурации.

Рабочий регламент

Превратите удачный опыт в короткий регламент: кто запускает, где лежит безопасная конфигурация, какие лимиты действуют и когда работа должна остановиться. Проверка должна завершаться конечным статусом, а не бесконечной попыткой. После обновления браузера, библиотеки или сетевой схемы запускайте малый контроль до основной очереди.

• Названа версия протокола
• Проверены возможности клиента
• DNS-маршрут указан отдельно
• Различены прокси и origin-коды
• Тест начат с минимального запроса
• Неподдерживаемая функция не обещана пользователю