Длина второго заголовка директ: второй заголовок и дополнительные символы в текстах объявлений Директа — Новости рекламных технологий Яндекса

Содержание

Второй заголовок в Яндекс Директ — длина когда показывается

В интернет-маркетинге роль продавца отведена контекстной рекламе. Но рекламодателю не всегда удается полностью раскрыть преимущества своего предложения из-за ограниченного размера объявления. Яндекс, ориентируясь на Google, создал для своих объявлений второй заголовок. С его появлением CTR контекстной рекламы в Директе увеличился как на десктопных, так и на мобильных устройствах.

Давайте разберемся, как настраивается и работает второй заголовок Яндекс Директ.

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

Вы можете сэкономить место в описании и разместить длинные ключи в 2-х заголовках (если в один они не вмещаются):

Создать заголовок 2 можно при редактировании существующей рекламной кампании или создании новой. В интерфейсе Директа появляются первый и второй.

Укажите конкретную стоимость товара (услуги) представленных на сайте или обозначьте ее границы – это привлечет на сайт большее количество потенциальных покупателей:

Сообщите ваше месторасположение – пользователи интернет склонны обращать внимание на рекламные предложения, связанные с их местом жительства:

При составлении фразы обязательно используйте слова, побуждающие к действию: «получите», «перейдите на сайт», «купите» и др.:

Размер второго заголовка

Длину второго заголовка Google и Яндекс ограничили до 30 знаков. Размер первого – 35 символов, текста описания – 81.

Поле заголовка 1 и описание нужно обязательно заполнить – заголовок 2 заполняете по желанию. При его отсутствии можно продолжать работать с первым – вместо заголовка 2 покажется начало текста или URL сайта.

При подсчете символов Яндекс не учитывает следующие знаки препинания:

  • кавычки,
  • запятую,
  • точку,
  • точку с запятой,
  • двоеточие,
  • восклицательный знак.

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

Составляйте краткие, емкие фразы, несущие максимальный объем информации, иначе поисковая система не пропустит объявление к выдаче.

Важный момент: если оба заголовка содержат максимальное количество символов, в Яндекс-поиске реально покажется только первый.

Проверяем, как объявление показывается на поиске

Отредактируем объявление Яндекс Директ и посмотрим, как оно покажется на поиске. Для этого выбираем вкладку «На компьютерах»:

Можно также увидеть, как будет выглядеть объявление при поиске на мобильных устройствах.

Яндекс показывает дополнительный заголовок, если ширина объявления не превышает 517 пикселей. Присутствие «широких символов» (ш, ж, ю, ы, м) дополнительно увеличивает его ширину.

Чтобы поисковая система показала оба заголовка, они должны содержать 50– 56 знаков (с учетом пробелов и тире).

Если вы хотите создать дополнительный заголовок в РСЯ, не вписывайте в него ключевые выгоды. В настоящее время нет точных данных о его показах на РСЯ, – если он не покажется, рекламное предложение будет выглядеть некорректно.

Подведем итог

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

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

Не стоит вписывать в дополнительный заголовок важную для клиента информацию – лучше используйте текст (он показывается всегда).

Заполняйте первый заголовок на 100%, а второй на 10-20 символов, обязательно проверяйте в Директе, как выглядит ваше предложение.

Если реклама показывается без дополнительного заголовка, можно сократить суммарное количество символов до 53 или оставить как есть (где-то он все равно покажется).

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

Если вам сложно разобраться в тонкостях создания объявлений в Яндекс Директ, то советуем воспользоваться нашим сервисом Анализ обьявлений конкурентов, который поможет найти объявления конкурентов и оперативно отслеживать их изменения.

Зачем нужен второй заголовок в Яндекс.Директ? Использование заголовка на примерах

Не так давно Яндекс добавил возможность использования второго заголовка длиной до 30 символов для текстово-графических объявлений.

Связано это с исследованиями Яндекса, которые показали, что длинные заголовки привлекают внимание пользователей лучше, чем короткие. Следовательно, это приводит к увеличению числа кликов и прибыли (как рекламодателя, так и Яндекса).

Как обещает российская компания — использование второго заголовка позволяет увеличить CTR рекламным объявлений: до 5% на ПК и до 10% — на рекламе в мобильных устройствах.

Отмечу, что приложение Директ Коммандер также поддерживает создание объявлений с двумя заголовками. Почитайте, что пишет сам Яндекс о новых возможностях — https://yandex.ru/support/direct-news/n-2017-08-15.html

Что можно написать во втором заголовке

В целом правила по заполнению второго заголовка не отличается от правил применимых к первому. Давайте попробуем найти несколько интересных применений использования второго заголовка.

1. Можно использовать в качестве призыва к действию:

2. Описывать преимущества товара или компании: акции, гарантия, цена или скидка:

3. Дополнительное упоминание бренда и компании:

4. Прочая дополнительная информация:

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

Вывод

Нововведения Яндекса дают ощутимую свободу для творчества всем рекламодателям. Длина первой части осталась неизменной и составляет

35 символов, вторая позволит добавить 30 дополнительных знаков. Кроме этого, увеличилась длина объявления с 75 знаков до 81-го.

Невероятная возможность реализовать все задуманные фантазии в месседже для клиента!

Но это еще не все! Теперь не учитываются знаки препинания в общем объеме текста, что позволяет написать максимально «вкусное» и интересное предложение для аудитории. Однако, и здесь есть ограничения по количеству ‒ максимум 15 знаков, но этого более чем достаточно. К таким относятся:

  • кавычки и двоеточие;
  • запятая и точка;
  • восклицательный знак.

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

Остались вопросы по настройке? Задавайте в комментариях ниже или пишите мне на личную почту [email protected]

. С удовольствием помогу с решением вопроса

Сохраните ссылку

Читайте дальше:

Метки #контекстная реклама, #яндекс.директ

Второй заголовок Директа — да он просто ОГРОМЕН!!!

Павел Ломакин

Кто то помнит как все начиналось в Яндекс Директ? И как мало давалось нам для выражения сокровенных мыслей и донесения важнейших качеств товара рекламодателя до пользователя? Вот и я не помню! Но было все намного суровей, чем сейчас уж поверьте. Ведь было всего каких то жалких 33 финтифлюшечки называемых символами для самого важного и это во времена, когда великие мошенники рекламы(по другому их называют маркетологами) вроде Огилви или Траута призывают уделять больше всего  внимания именно заголовку, как самому влиятельному элементу объявления по захвату внимания читателя.

Тут конечно можно привести аналогию с конкурирующей контекстной системой забугорного гиганта, но должен сказать , что в этот раз разработчики Директа его переплюнули. Честь им и хвала! О чем идет речь читаем ниже.

Неудивительно, что чем больше вы можете сказать в заголовке тем лучше. Яндекс Директ дал нам эту возможность в полной мере и теперь вместо расширения заголовка за счет подтягивания текста объявления, скрадывая количество символов,  внедрил возможность написания отдельного полноценного второго заголовка. Так что теперь у вас есть:

  • заголовок 1 = 35 символов
  • длина второго заголовка директ = 30 символов
  • текст объявления = 81 символ

То есть вместо максимальных ранее 56 символов, теперь целых 65, Карл, а вместо привычных 75 на текст объявления стало 81. Интересно почему именно 81?

Ну и ладно. Кстати на этом чудеса не кончаются. Теперь при подсчете количества символов не учитываются знаки препинания до 15 штук. Точки, запятые, восклицательные знаки и пр. Божечки мои! Это даже интереснее, так как теперь меньше будешь думать(лучше конечно больше), как перефразировать то или иное предложение, которое не влазит из за точки или запятой. Иногда приходилось жертвовать грамматикой ради достижения целей так как великий и могучий не всегда спасал. Это очень плохо и не надо так!

Немного подробнее о том как это работает и почему иногда не показывается второй заголовок. Настоятельно рекомендую прочитать статью об расширенном заголовке если еще не читали.

Итак у вас есть форма для написания объявления.

Тут все просто, вписываете второй заголовок и все. Но в каких случаях он будет отображаться? На этом нужно остановиться подробнее. Вот как выглядит второй заголовок директ на поиске

Вы можете разбить ключевые слова на два заголовка если в один не влезает и тем самым решить проблему с длинными ключами не занимая места в тексте объявления.

Во вторых вы можете использовать в первом заголовке  шаблон(о том что это такое и как использовать читайте здесь) в случае когда вам нужно например объединить несколько ключевых фраз в одну группу, при этом не потеряв релевантность и что самое главное возобновить открутку если вдруг схлопотали статус мало показов. Все это круто, но есть(надеюсь пока и недолго) один большой жирный минус! Отображение второго заголовка стабильно работает в большинстве случаев когда ваш заголовок не превышает 50-56 символов с учетом 2-х пробелов и дефиса между заголовками! На официальном блоге даже приводятся слова о том, что должны поместиться 512 пикселей и вообще лучше поменьше использовать буквы типа Ш, Щ и т. п. якобы они занимают дофигища места, но я думаю никто это всерьез не воспринял, так как высчитывать пиксели или подбирать буквы при написании объявления…. ну вы серьезно? Вот такой вот облом к концу моего повествования)))

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

Следите за руками. Первая пилюля это то, что ситуация со временем поменяется и я серьезно об этом говорю. Директ меняется сейчас со страшной силой , то ли еще будет. Во вторых( и это огромный жирный плюс сам по себе) Яндекс увеличил первый заголовок, как я уже писал выше до 35 символов, а сам текст до 81 и это очень много. Ну и вишенка на торте это то, что если ты сделаешь и первый и второй заголовок в 56 символов(для стабильности показов), то это не будет как в варианте с расширенным заголовком и у тебя не сканибалят часть текста и можно полноценно использовать все 81 символы. Вот так вот. Надеюсь я был убедительным. Удачи вам!

Внимание, эксклюзив! Второй заголовок в Яндекс.Директ — сейчас самое время!

  • Главная
  • Блог
  • Внимание, эксклюзив! Второй заголовок в Яндекс.Директ — сейчас самое время!
Н

аш эксперт, маркетолог Артём Жидков одним из первых протестировал новые возможности Яндекс. Директ и поспешил поделиться новыми фишками с нашими читателями. Пройдет несколько месяцев, и правки в своих рекламных кампаниях сделают многие. Но пока есть шикарная возможность стать первыми и перетянуть на себя больше трафика. Пока конкуренты дремлют – самое время действовать!

Итак, какие новости приготовил нам Яндекс.Директ?

1. Заголовок расширился с 33 до 35 символов. Плюс при подсчете символов не учитываются знаки препинания (до 15 символов). Так что теперь информации в рекламное объявление можно вместить чуть больше, чем ранее! Яндекс.Директ: Заголовок расширился с 33 до 35 символов Кто-то скажет — подумаешь, 3-4 символа. Ерунда! Ан нет, уважаемые, кто хоть раз прописывал заголовки, пытаясь туда вместить все ключевые слова, меня поймет. Иногда из-за нехватки 1 символа приходится урезать целое слово. Например, ключевая фраза «гидроизоляция кровли жидкой резиной» Длина этой фразы — 35 символов. Раньше вставить этот ключ целиком в заголовок было нереально: пришлось бы убирать какое-то слово. И осталось бы «гидроизоляция кровли резиной», или «гидроизоляция жидкой резиной».  Согласитесь, уже не то, правда? Ведь вероятность того, что клиент нажмет на объявление, полностью повторяющее его поисковый запрос, гораздо выше! Теперь же вся фраза прекрасно вписывается — а значит, ваш трафик растет. Яндекс.Директ: заголовок 2. Появился ВТОРОЙ заголовок на 30 символов. Это ли не чудо! Теперь ваши объявления станут еще более заметными — особенно сейчас, когда это нововведение еще не внедрили 99 процентов рекламодателей. Ну, вы-то уже в курсе и войдете в 1 процент счастливчиков! Раньше заголовок расширялся за счет первого предложения текста объявления при условии, что длина заголовка + длина первого предложения текста + 3 ≤ 56 символов. Сейчас это тоже работает, но по старым правилам символов для текста объявления остается совсем немного. То ли дело сейчас! Яндекс.Директ: Появился ВТОРОЙ заголовок на 30 символов Правда, есть один нюанс. Яндекс не обещает, что второй заголовок стопроцентно будет показываться — это якобы зависит от площади, которую займут на экране оба заголовка. В связи с этим сейчас в любом случае есть смысл оставить первое предложение в тексте, чтоб оно подставлялось, если второй заголовок не покажется. И еще одна рекомендация от Яндекса. Старайтесь использовать короткие и броские преимущества вашего второго заголовка – такие, как «Скидки до 70%!», «Бесплатная доставка», «В наличии», «Доставим завтра» и другие. Шанс, что небольшие заголовки вместятся, намного выше! 3. Текст объявления расширился с 75 до 81 символа. И кстати, тут тоже больше не учитываются знаки препинания. Ну тут особо и комментировать нечего: больше слов — значит, больше информации о вашем товаре. Можно ли было раньше вместить столько информации в текст объявления? 4. Возможность добавлять уточнения в текстово-графических объявлениях в РСЯ. Это не самая свежая новость, но по статистике внедрили эти изменения пока единицы. Стоит заметить, что уточнения будут показываться не во всех форматах, но там, где покажутся — лишними точно не будут. Посмотрите на две этих картинки. То, что у объявления справа выше CRT – сомнения не вызывает. Возможность добавлять уточнения в текстово-графических объявлениях в РСЯ Резюме
  1. Чем масштабнее ваше объявление в сравнении с объявлением конкурентов, тем большую часть рынка вы перетягиваете на себя.
  2. В большой семье зубами не щелкай! Те, кто вовремя корректирует свой бизнес под текущие реалии, — всегда на передовой!
Написать автору можно во Вконтакте: vk.com/zhidkov_direct Сайт Артема Жидкова — www.guru-directa.pro

Автор: Екатерина

Журналист Поделитесь, пожалуйста, с друзьями!

Читайте другие статьи по теме

Второй заголовок в Яндекс Директ

С 16 августа Яндекс предоставил нам возможность еще лучше расписать свои рекламные преимущества. Сделал он это, увеличив количество символов в тексте объявлении с 75 до 81, первом заголовке с 33 до 35, и добавив второй заголовок. О нем и будет идти речь в этой статье.

Второй заголовок в Яндекс Директ ‒ это дополнительное расширение для Ваших рекламный объявлений. К сожалению, на данный момент он отображается только у поисковых кампаний. Скорее всего эту функцию в дальнейшем откроют и для РСЯ, сейчас она тестируется.

Читайте наши статьи в блоге EDISON

Как добавить второй заголовок Яндекс Директ?

Вы можете прописать его как на сервере Яндекс Директ, так и в Директ Коммандер. Также это обычная выгрузка кампаний из этих двух систем с редактированием Excel-файла, и его дальнейшей загрузкой обратно.

Второй заголовок на сервере Яндекс Директ

Второй заголовок в Директ Коммандер

Второй заголовок при выгрузке в Excel-файл

Как работает второй заголовок Яндекс Директ?

Длина второго заголовка должна составлять 30 символов. Помимо этого, Яндекс перестал учитывать в количестве символов знаки препинания. К ним относятся: точки (.), запятые (,), кавычки («»), двоеточия (:), точки с запятой (;) и восклицательные (!) знаки. Это большой плюс, так как теперь вы можете написать более цепляющие и продающие заголовки. Однако, ограничение на знаки препинания все же есть (до 15 символов).

Стоит ли использовать второй заголовок в Яндекс Директ?

Однозначно стоит, ведь использование дополнительных символов повышает CTR (кликабельность) объявления до 10%.

Однако, у этого нововведения все-таки имеется один существенный минус – второй заголовок не всегда отображается (в отличие от Google Adwords). Скорее всего это исправят в дальнейшем, а пока, отобразится он или нет, зависит от площади, которую займут в итоге оба заголовка на экране.

Поэтому старайтесь прописывать в нем те дополнительные преимущества, без которых Ваше объявление не потеряет общий смысл. И, желательно, кратко. Например, УТП, показывающее большой ассортимент товаров (Более 300 моделей!).

Спасибо за внимание.

Читайте наши статьи в блоге EDISON

9 классических ошибок при создании объявления в Яндекс.Директ.

Здесь вы узнаете:

Ошибка 1. Нерелевантность заголовка.
Ошибка 2. Дополнительные символы в заголовке.
Ошибка 3. Отображаемая ссылка.
Ошибка 4. УТП и призыв к действию.
Ошибка 5. Контактные данные.
Ошибка 6. Быстрые ссылки без УТП.
Ошибка 7. Звезды рейтинга.
Ошибка 8. Номера телефонов.
Ошибка 9. Ссылка на главную страницу.

Какие распространенные ошибки допускают компании при создании объявления в Яндекс.Директ? Какова структура объявления? Что делать с нерелевантными заголовками, быстрыми ссылками без УТП и звездами на Яндекс.Маркете? Ответы в этой статье.

Объявления в Яндекс.Директ обычно состоит из:

• заголовка;
• ссылки;
• текста объявления;
• контактной информации;
• 4 быстрых ссылок;
• и рейтинга на Яндекс.Маркете (звезды).

Классические ошибки «директологов» при составлении объявлений в Яндекс.Директ вошли в список из 9 пунктов, приведенных ниже.

Ошибка 1. Нерелевантность заголовка.

Заголовок объявления не соответствует ключевому запросу пользователя. В таком случае повышается ставка, а сам заголовок не подсвечивается.

Необходимо четко понимать, готовы ли вы платить за нерелевантный заголовок или лучше обратить на него внимание и исправить.

Ошибка 2. Дополнительные символы в заголовке.

ЯД допускает создание заголовка на 33 символа. Но есть определенные обстоятельства, при которых длину заголовка можно увеличить еще на 23. Таким образом, его длина будет составлять уже 56 символов! Слишком часто на это не обращают внимание.

Ошибка 3. Отображаемая ссылка.

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

Ошибка 4. УТП и призыв к действию.

Текст объявления должен обязательно содержать информацию об акции, уникальном торговом предложении (УТП) и «Call to action» (призыв к действию). Желательно указывать дату завершения спецпредложения (deadline).

Призывом к действию могут стать такие слова:

• Смотрите!
• Жмите!
• Подробнее.
• Цены на сайте и др.

Ошибка 5. Контактные данные.

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

Ошибка 6. Быстрые ссылки без УТП.

Исследуя конкурентов, можно увидеть, что быстрые ссылки выглядят следующим образом:

• фото;
• о нас;
• контакты;
• цены.

Настоятельно рекомендуем писать в быстрых ссылках уникальное торговое предложение (УТП). Например, монтаж за один день (а не просто «монтаж»), скидка 20% (а не просто «скидка»), гарантия на 3 года (а не просто «гарантия»).

Ошибка 7. Звезды рейтинга.

Здесь целых два ошибочных варианта: либо забываем ставить галочку «не показывать» звезды, либо показываем их, когда звезд слишком мало.

Если рейтинг на Яндекс.Маркете составляет 1—2 звезды — это вряд ли добавит лояльности посетителей к компании. Если рейтинг 4—5, следует показывает его обязательно, но если 3 и меньше — отключить.

Ошибка 8. Номера телефонов.

Компания работает по всей стране? Следует обязательно разделять компании на региональные и московские. В первом случае нужно указать бесплатный региональный номер, а во втором — столичный.

Классическая ошибка, когда московская компания указывает в объявлении по всей России московский номер, тогда как могла бы указать 8 800 и повысить кликабельность объявления.

Ошибка 9. Ссылка на главную страницу.

Ссылка в тексте объявления ведет на страничку, которая не имеет никакого отношения к тексту объявления и поисковому запросу клиента. Неверно будет отправлять трафик только на главную страницу.

Если посетитель ищет «купить мобильный телефон Марка», то он должен попасть на страничку со всеми телефонами данной фирмы, а не просто на главную страницу интернет–магазина.

В таком случае эффективность рекламной кампании будет намного выше, если клиенты будут «приземляться» на релевантные страницы.

Чит–код (бонус)

В рекламных объявлениях можно указывать любимый логотип компании в виде «favicon».

Следует знать, что есть определенные «фавиконы» для сайта, которые повышают кликабельность объявления. К таким «фавиконам» можно отнести: галочку красного цвета или стрелочку. Это поднимает кликабельность на 1% и позволяет сэкономить до 5% от стоимости клика.

Выводы

Это 9 самых распространенных ошибок при создании объявлений в ЯД. Теперь вы знаете из чего должно состоять объявление, каких критериев следует придерживаться при написании текста объявления, что такое релевантность, правильные заголовки, быстрые ссылки с УТП и звезды в ЯМ.

9 идей для второго заголовка в поисковых объявлениях

Материал взят с ppc.world, автор статьи — София Биткова

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

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

Google AdWords и Яндекс.Директ позволяют использовать в объявлении два заголовка, которые отображаются через дефис. При составлении объявления специалистам необходимо учитывать технические ограничения и требования рекламных систем, особенности размещения и специфику предложения рекламодателя.

Заголовки в Google AdWords

Второй заголовок в AdWords появился вместе с запуском расширенных текстовых объявлений. В каждое поле «заголовок» входит по 30 символов, включая знаки препинания. В мобильной версии заголовок занимает, как правило, две строки.

Такие объявления показываются в поиске и Контекстно-медийной сети Google.

Заголовки в Яндекс.Директе

Яндекс.Директ добавил второй заголовок в текстово-графические объявления не так давно, в августе 2017 года. Как и в AdWords заголовки отображаются через дефис, и на мобильных часть текста переносится на строку ниже.

Первый заголовок может включать 35 символов, а второй — до 30. Причем система не учитывает в общем количестве символов многие знаки препинания.

Второй заголовок доступен только для поисковых объявлений, в РСЯ Яндекс еще тестирует этот формат.

Обратите внимание: второй заголовок не всегда отображается на поиске Яндекса. Будет ли он показан, зависит от площади, которую объявление занимает на экране. Команда Яндекс.Директа предупреждала об этом рекламодателей и составила примерные требования к его размерам:

  • объявление на поиске может занимать до 517 пикселей. Если ширина обоих заголовков больше этого значения, то пользователи не увидят второго заголовка. Важно, что количество пикселей увеличивается, если в объявлении срабатывает подсветка;
  • общее количество символов в верхней строке с учетом тире между заголовками и двух пробелов — 50-56 знаков.

Чтобы было проще следить за лимитами, Евгений Юдин написал надстройку для Excel с функциями, которые подсчитывают длину текста в пикселях, в том числе с учетом подсветки. Скачать надстройку можно с Google Диска, инструкция по использованию — в блоге автора.

Что можно добавить во второй заголовок

Расширенные текстовые объявления AdWords и объявления со вторым заголовком в Директе популярны среди рекламодателей, потому что позволяют обратиться к аудитории и рассказать больше о компании.

Мы подготовили советы и рекомендации, как с пользой применить второй заголовок и улучшить эффективность объявления.

Добавьте ключевую фразу в заголовок

Благодаря этому пользователь поймет — вы предлагаете именно то, что он ищет.

Ключевая фраза может быть добавлена как в первый, так и во второй заголовок. Главное — органично вписать ее в обращение к потенциальному покупателю. Избегайте перенасыщения заголовка ключевыми фразами, задействуйте поле «описание» и пути URL.

В поиске Яндекса часть заголовка, совпадающая с запросом, выделяется жирным шрифтом (в Google подсвечиваются ключевые слова только в описании). Это привлекает внимание пользователей.

 

 

Расскажите о конкурентных преимуществах

В заголовок можно добавить важную информацию о рекламируемом товаре или услуге, кратко описать суть предложения или представить позицию компании на рынке.

 

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

 

Добавьте цену

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

 

Акцентируйте внимание на спецпредложениях и акциях

Многих пользователей заинтересует привлекательная возможность сэкономить.

 

Ограниченное время действия акции подтолкнет пользователя кликнуть по объявлению.

 

Сообщите, где вы находитесь

Пользователи склонны обращать внимание на заголовки, связанные с их местом жительства или содержащие упоминание о нем.

 

Добавьте название бренда

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

 

Расскажите последние новости

Оповещайте пользователей о поступлении нового товара, расширении списка услуг или начале распродажи. Многие могли уже совершать покупки в вашей компании, и новинки будут поводом еще раз посмотреть ассортимент.

 

Используйте CTA

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

 

Или добавьте слова, обозначающие покупательские действия: выбирайте, заказывайте, покупайте.

 

Вопрос-ответ

Такая тактика задействует оба заголовка.

 

И еще один лайфхак: графическое выделение

Заглавная буква в начале каждого слова делает заголовок заметнее среди результатов поиска, особенно если оно располагается под результатами выдачи.

 

Заключение

Следите за качеством и актуальностью объявлений. Информация в заголовке должна совпадать с данными на посадочной странице. В тексте не должны встречаться грамматические или пунктуационные ошибки, это отталкивает пользователей и негативно влияет на эффективность продвижения.

Учитывайте редакционные правила Google AdWords, которые, например, запрещают использовать восклицательный знак в заголовке. Помните об ограничениях Яндекс.Директа: старайтесь писать независимые друг от друга заголовки, дополняющие друг друга. В случае если второй заголовок не отображается, смысл предложения не должен потеряться.

Не забывайте про креативный подход. Внимание пользователей можно привлечь с помощью необычной подачи или игры слов в заголовке, даже если это противоречит привычным советам по применению.

Ethernet Header — обзор

Dissecting Packets

С некоторой математикой вернемся к пакету, показанному на рисунке 13.2, и разберем его по каждому отдельному протоколу. Если вы понимаете, как создаются пакеты, вы знаете, что пакет создается, начиная с данных уровня приложения, и заголовки из протоколов, работающих на нижних уровнях, добавляются по мере создания пакета, перемещаясь сверху вниз. Это означает, что последний добавляемый заголовок протокола находится на уровне канала передачи данных, а это означает, что мы должны сначала встретить этот заголовок.Наиболее распространенным протоколом канального уровня является Ethernet, но давайте проверим, что здесь используется.

Чтобы убедиться, что мы действительно видим трафик Ethernet, мы можем сравнить то, что, как мы знаем, должен выглядеть заголовок Ethernet, с тем, что мы имеем в начале этого пакета. Формат заголовка Ethernet можно найти в Приложении 3, но для удобства мы включили его сюда, на рис. 13.13.

Рисунок 13.13. Карта пакетов для заголовка Ethernet

Глядя на формат заголовка Ethernet, вы увидите, что первые 6 байтов пакета зарезервированы для MAC-адреса назначения, а вторые шесть байтов, начиная с 0x6, зарезервированы для MAC-адреса источника. адрес.На рисунке 13.14 показано, что эти байты соответствуют MAC-адресам двух хостов в нашем примере. Единственное другое поле, которое включается в заголовок Ethernet, — это двухбайтовое поле типа 0x12, которое используется, чтобы сообщить нам, какой протокол следует ожидать после заголовка Ethernet. В этом случае поле типа имеет шестнадцатеричное значение 08 00, что означает, что следующим встроенным протоколом, которого следует ожидать, будет IP. Длина заголовка Ethernet статична и составляет 14 байтов, поэтому мы знаем, что 00 — это последний байт заголовка.

Рисунок 13.14. Идентифицированный заголовок Ethernet

Из траншей

Хотя я включил заголовок Ethernet в этот пример, заголовок уровня канала передачи данных по умолчанию не печатается с помощью tcpdump. Поскольку во всех примерах в этой книге используется Ethernet, в следующих примерах этот заголовок не будет отображаться, а вместо этого будет использоваться протокол сетевого уровня.

Поскольку заголовок Ethernet был достаточно любезным, чтобы сообщить нам, что мы должны ожидать следующий заголовок IP, мы можем применить то, что мы знаем о структуре заголовка IP, к следующей части пакета.Мы пытаемся разбить этот пакет по отдельному протоколу, поэтому нас не беспокоит каждое отдельное значение в этом заголовке, но есть несколько значений, которые нам нужно будет оценить, чтобы определить длину IP-заголовка и какой протокол ожидать следующего.

Во-первых, нам нужно определить, какая версия IP здесь используется. Как мы узнали ранее, версия IP идентифицируется полубайтом байта 0x0 более высокого порядка в заголовке IP. В данном случае мы имеем дело с IPv4.

Длина IP-заголовка может изменяться в зависимости от набора поддерживаемых им опций, поэтому следующее, что нам нужно определить, — это длина IP-заголовка.Ранее мы узнали, что поле длины IP-заголовка содержится в нижнем полубайте байта 0 × 0 в IP-заголовке, который имеет значение 4. Однако это вычисляемое поле, поэтому мы должны умножить это поле на 5, чтобы достигают длины IP-заголовка, которая составляет 20 байтов. Это означает, что последние два байта IP-заголовка — 02 1e.

В качестве последней остановки в заголовке IP нам нужно определить, какой протокол следует ожидать в пакете следующим образом. Заголовок IP дает нам эту информацию с полем протокола в 0x9.Здесь это значение — 06, то есть значение, присвоенное протоколу TCP (рисунок 13.15).

Рисунок 13.15. Идентифицированный IP-заголовок

Теперь, когда мы перешли к протоколу TCP, мы должны определить, присутствуют ли какие-либо данные уровня приложения. Для этого мы должны определить длину заголовка TCP (рисунок 13.16), который, как и заголовок IP, является переменной в зависимости от используемых параметров.

Рисунок 13.16. Карта пакетов для заголовка TCP

Это достигается путем проверки поля смещения данных TCP в полубайте более высокого порядка 0 × 12.Значение этого поля — 5, но, опять же, это вычисляемое поле, и его необходимо умножить на четыре, чтобы получить реальное значение. Это означает, что длина заголовка TCP действительно составляет 20 байт.

Если вы отсчитаете 20 байтов от начала заголовка TCP, вы обнаружите, что после конца заголовка все еще есть данные. Это данные прикладного уровня. К сожалению, TCP не имеет какого-либо поля, которое сообщало бы нам, какой протокол уровня приложения ожидать в приложении, но что-то мы можем сделать, это взглянуть на поле порта назначения (предполагая, что это трафик от клиента к серверу, в противном случае мы бы посмотрели на поле порта источника) на 0 × 2: 2 в заголовке TCP.Это поле имеет значение 00 50, которое в десятичной форме преобразуется в 80. Поскольку порт 80 обычно используется протоколом HTTP, возможно, последующие данные являются данными HTTP. Вы можете проверить это, сравнив шестнадцатеричные данные с картой протокола протокола HTTP или просто взяв эти данные от конца заголовка TCP до конца пакета и преобразовав их в текст ASCII (рисунок 13.17).

Рисунок 13.17. Идентифицированный заголовок TCP

Осторожно

Просто потому, что вы обнаруживаете данные на порте, который обычно связан с определенной службой, такой как порт 80 и HTTP или порт 22 и SSH, вы не всегда должны делать предположение, что эти службы несет прямую ответственность за трафик, который вы видите.Дело в том, что любую службу можно настроить для работы на любом порту, и злоумышленники часто используют эту тактику. Например, злоумышленники очень часто запускают настраиваемые протоколы, используемые для управления портом 80. Это дает злоумышленнику множество преимуществ, в том числе возможность выводить трафик из сети, поскольку порт 80 почти всегда разрешен для выхода. брандмауэры и возможность спрятаться среди беспорядочного и непредсказуемого трафика из-за управляемого пользователем HTTP-трафика.

Распределение уровня протокола только что проанализированного пакета показано на рис. 13.18.

Рисунок 13.18. Уровень протокола HTTP-пакета

Теперь давайте поговорим о некоторых инструментах, которые вы можете использовать для отображения пакетов и взаимодействия с ними.

Формат беговой головки для бумаги в стиле APA


Челси Ли

Если вас когда-либо смущало, что такое бегущая голова, или вы задавались вопросом, как отформатировать ее для статьи в стиле APA, читайте дальше.

Что такое бегущая голова?

Бегущая головка — это короткий заголовок, который появляется в верхней части каждой страницы вашего документа в заголовке страницы. Текущий заголовок идентифицирует страницы для читателя на случай, если они разделены, и если вы отправляете свою статью для публикации, он делает это, сохраняя при этом вашу анонимность во время процесса рецензирования (вот почему бегущая строка — это короткое название, а не ваше имя. ). В опубликованных статьях бегущая строка также быстро определяет статью для читателя.

Длина бегущей строки не должна превышать 50 символов, включая пробелы и другие знаки препинания. Если заголовок статьи уже состоит из 50 символов или меньше, вы можете использовать заголовок статьи в качестве бегущей строки. В противном случае вы можете сократить название статьи, как хотите. Вот пример:

Название статьи:

Что студенты узнают о человеческом интеллекте? Анализ вводных учебников психологии

Беговая головка:

ОБУЧЕНИЕ ИНТЕЛЛЕКТУАЛЬНОМУ БАКЛАССУ

Инструкции по форматированию

В заголовке каждой страницы отображается бегущий заголовок вместе с номером страницы.(Заголовок по своей природе расположен в пределах верхнего поля вашей бумаги; все поля должны быть установлены равными 1 дюйму.) Только на первой странице бумаги бегущей строке предшествуют слова бегущая головка и a двоеточие. На всех остальных страницах отображается только бегущая головка и номер страницы без метки Running head: .

Эти требования означают, что вам, вероятно, потребуется настроить текстовый редактор так, чтобы на первой странице был другой заголовок.Если вы используете APA Style CENTRAL для написания статей, заголовок страницы и бегущая строка будут форматироваться автоматически.

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

После того, как вы настроили свой документ на другой заголовок первой страницы в Microsoft Word, следуйте этим инструкциям, чтобы настроить заголовок на первой странице бумаги:

  • Добавьте номер страницы, используя функцию автоматической нумерации.
  • Поместите номер страницы в верхний правый угол.
  • В заголовке введите метку Бегущая головка: (не курсивом, только буква «R» с заглавной буквы), а затем введите саму беговую головку заглавными буквами, убедившись, что ее длина не превышает 50 символов (включая пробелы и другие знаки препинания).
  • Поместите курсор между концом бегущего заголовка и номером страницы и нажмите клавишу табуляции, чтобы выровнять бегущий заголовок влево, при этом оставив номер страницы выровненным по правому краю.
  • При необходимости измените шрифт в заголовке на Times New Roman размером 12 пунктов.

Заголовок первой страницы будет выглядеть так:

На второй странице бумаги повторите процесс вставки номера страницы и бегущей строки в заголовок страницы, за исключением того, что не добавляйте метку Текущая головка. Заголовок на второй и последующих страницах будет выглядеть так:

Верхний колонтитул страницы теперь должен быть правильно отформатирован для стиля APA на всех страницах вашей статьи.Вы также можете увидеть примеры формата бегущей головки в наших образцах документов в стиле APA.

Другие направления и шаблон беговой головки

Скриншоты в этом посте взяты из Word 2016; если вы используете другую версию Microsoft Word, следуйте этим инструкциям от Microsoft, чтобы настроить заголовок. Если вы используете другое программное обеспечение для обработки текстов, не стесняйтесь делиться ссылками или инструкциями в комментариях.

Я также создал шаблон бегущей головы для Word, который вы можете скачать, в котором она уже настроена для вас.

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

Если вас когда-либо смущало, что такое бегущая голова, или вы задавались вопросом, как отформатировать ее для статьи в стиле APA, читайте дальше.

Что такое контрабанда HTTP-запросов? Учебник и примеры

В этом разделе мы объясним атаки контрабанды HTTP-запросов и опишем, как могут возникнуть распространенные уязвимости, связанные с контрабандой запросов.

Что такое контрабанда HTTP-запросов?

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

Примечание

Контрабанда HTTP-запросов была впервые задокументирована в 2005 году и недавно получила широкое распространение в исследовании PortSwigger по этой теме.

Что происходит при атаке контрабанды HTTP-запросов?

Современные веб-приложения часто используют цепочки HTTP-серверов между пользователями и конечной логикой приложения. Пользователи отправляют запросы на интерфейсный сервер (иногда называемый балансировщиком нагрузки или обратным прокси), и этот сервер перенаправляет запросы на один или несколько внутренних серверов. Этот тип архитектуры становится все более распространенным, а в некоторых случаях неизбежным в современных облачных приложениях.

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

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

Здесь злоумышленник заставляет часть своего внешнего запроса интерпретировать внутренним сервером как начало следующего запроса. это эффективно добавляется к следующему запросу и может мешать тому, как приложение обрабатывает этот запрос. Это просьба контрабандное нападение, и оно может иметь разрушительные результаты.

Как возникают уязвимости, связанные с контрабандой HTTP-запросов?

Большинство уязвимостей, связанных с контрабандой HTTP-запросов, возникает из-за того, что спецификация HTTP предоставляет два разных способа указать, где находится запрос. заканчивается: заголовок Content-Length и заголовок Transfer-Encoding .

Заголовок Content-Length прост: он определяет длину тела сообщения в байтах.Для пример:

POST / search HTTP / 1.1
Хост: normal-website.com
Content-Type: application / x-www-form-urlencoded
Content-Length: 11

q = контрабанда

Заголовок Transfer-Encoding может использоваться для указания того, что тело сообщения использует кодирование по частям. Этот означает, что тело сообщения содержит один или несколько блоков данных. Каждый блок состоит из размера блока в байтах (выраженного в шестнадцатеричный), за которым следует новая строка, за которой следует содержимое блока.Сообщение заканчивается блоком нулевого размера. Например:

POST / search HTTP / 1.1
Host: normal-website.com
Content-Type: application / x-www-form-urlencoded
Transfer-Encoding: фрагментировано

b
q = контрабанда
0

Примечание

Многие тестеры безопасности не знают, что фрагментированное кодирование может использоваться в HTTP-запросах, по двум причинам:

  • Burp Suite автоматически распаковывает фрагментированную кодировку, чтобы сообщения было легче просматривать и редактировать.
  • Браузеры обычно не используют фрагментированное кодирование в запросах, и обычно это видно только в ответах сервера.

Поскольку спецификация HTTP предоставляет два разных метода для указания длины HTTP-сообщений, возможно для одного сообщение использовать оба метода одновременно, так что они конфликтуют друг с другом. Спецификация HTTP пытается предотвратить эту проблему с помощью заявляя, что если заголовки Content-Length и Transfer-Encoding являются присутствует, то заголовок Content-Length следует игнорировать.Этого может быть достаточно, чтобы избежать двусмысленности когда в игре задействован только один сервер, но не когда два или более серверов связаны вместе. В этой ситуации проблемы могут возникнуть у двоих. причины:

  • Некоторые серверы не поддерживают заголовок Transfer-Encoding в запросах.
  • Некоторые серверы, которые действительно поддерживают заголовок Transfer-Encoding , могут быть вынуждены не обрабатывать его, если заголовок каким-то образом запутан.

Если интерфейсный и внутренний серверы ведут себя по-разному в отношении (возможно, запутанного) Transfer-Encoding заголовок, то они могут не согласиться с границами между последовательными запросами, что приведет к уязвимостям, связанным с контрабандой запросов.

Как выполнить атаку контрабанды HTTP-запросов

Атаки с контрабандой запросов включают размещение заголовка Content-Length и заголовка Transfer-Encoding . Заголовок в один HTTP-запрос и манипулирует ими, чтобы интерфейсный и внутренний серверы обрабатывали запрос по-разному.В точный способ, которым это делается, зависит от поведения двух серверов:

  • CL.TE: внешний сервер использует заголовок Content-Length , а внутренний сервер использует заголовок Transfer-Encoding .
  • TE.CL: внешний сервер использует заголовок Transfer-Encoding , а внутренний сервер использует заголовок Content-Length .
  • TE.TE: внешний и внутренний серверы поддерживают заголовок Transfer-Encoding , но один из серверы можно заставить не обрабатывать его, каким-то образом запутав заголовок.

Уязвимости CL.TE

Здесь внешний сервер использует заголовок Content-Length , а внутренний сервер использует заголовок Transfer-Encoding . Мы можем выполнить простую атаку контрабанды HTTP-запросов следующим образом:

POST / HTTP / 1.1
Хост: уязвимый-website.com
Content-Length: 13
Transfer-Encoding: chunked

0
SMUGGLED

Внешний сервер обрабатывает заголовок Content-Length и определяет, что тело запроса составляет 13 байтов. долго, до конца ПРОБЛЕМА . Этот запрос пересылается на внутренний сервер.

Внутренний сервер обрабатывает заголовок Transfer-Encoding и поэтому обрабатывает тело сообщения как использующее фрагментированное кодирование.Он обрабатывает первый фрагмент, который имеет нулевую длину, и поэтому обрабатывается как завершающий запрос. В следующие байты, SMUGGLED , остаются необработанными, и внутренний сервер будет рассматривать их как начало следующего запроса в последовательности.

Уязвимости TE.CL

Здесь внешний сервер использует заголовок Transfer-Encoding , а внутренний сервер использует заголовок Content-Length .Мы можем выполнить простую атаку контрабанды HTTP-запросов следующим образом:

POST / HTTP / 1.1
Хост: уязвимый-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

Примечание

Чтобы отправить этот запрос с помощью Burp Repeater, вам сначала нужно перейти в меню Repeater и убедиться, что «Update Content-Length» опция не отмечена.

Вам необходимо включить завершающую последовательность \ r \ n \ r \ n после финального 0 .

Внешний сервер обрабатывает заголовок Transfer-Encoding и поэтому обрабатывает тело сообщения как использующее фрагментированное кодирование. Он обрабатывает первый блок длиной 8 байт до начала строки, следующей за SMUGGLED . Он обрабатывает второй фрагмент, который, как указано, имеет нулевую длину, и поэтому рассматривается как завершающий запрос.Этот запрос пересылается на внутренний сервер.

Внутренний сервер обрабатывает заголовок Content-Length и определяет, что тело запроса составляет 3 байта. длинный, до начала строки после 8 . Следующие байты, начиная с SMUGGLED , остаются необработанными, и внутренний сервер будет рассматривать их как начало следующего запрос в последовательности.

Здесь внешний и внутренний серверы поддерживают заголовок Transfer-Encoding , но один из серверов можно заставить не обрабатывать его, каким-либо образом запутав заголовок.

Есть потенциально бесконечные способы обфускации заголовка Transfer-Encoding . Например:

Transfer-Encoding: xchunked

Transfer-Encoding: chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding: [tab] chunked

[space] Transfer-Encoding: chunked

X: X [\ n] Transfer-Encoding: по фрагментам

Transfer-Encoding
: по фрагментам

Каждый из этих методов предполагает небольшое отклонение от спецификации HTTP.Реальный код, реализующий спецификацию протокола редко соблюдает его с абсолютной точностью, и для разных реализаций характерно допускать разные вариации от Технические характеристики. Чтобы обнаружить уязвимость TE.TE, необходимо найти некоторую разновидность заголовка Transfer-Encoding , при которой только один из внешних или внутренних серверов обрабатывает его, в то время как другой сервер игнорирует это.

В зависимости от того, является ли это внешним или внутренним сервером, который может быть вынужден не обрабатывать обфусцированный заголовок Transfer-Encoding , остальная часть атаки примет ту же форму, что и для CL.TE или TE.CL уязвимости уже описаны.

Как предотвратить уязвимости, связанные с контрабандой HTTP-запросов

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

  • Отключить повторное использование внутренних подключений, чтобы каждый запрос к серверной части отправлялся через отдельное сетевое подключение.
  • Используйте HTTP / 2 для внутренних соединений, поскольку этот протокол предотвращает двусмысленность границ между запросами.
  • Используйте одно и то же программное обеспечение веб-сервера для внешнего и внутреннего серверов, чтобы они согласовали границы между Запросы.

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

компонентов маршрута HTTP — документация envoy 1.20.0-dev-63749f

Эта документация предназначена для API Envoy v3.

Начиная с Envoy v1.18 API v2 был удален и больше не поддерживается.

Если вы обновляете конфигурацию API версии 2, вы можете просмотреть документацию по API версии 2:

config.route.v3.VirtualHost

[config.route.v3.VirtualHost proto]

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

 {
  "имя": "...",
  "домены": [],
  "маршруты": [],
  "require_tls": "...",
  "виртуальные_кластеры": [],
  "rate_limits": [],
  "request_headers_to_add": [],
  "request_headers_to_remove": [],
  "response_headers_to_add": [],
  "response_headers_to_remove": [],
  "корс": "{...} ",
  "typed_per_filter_config": "{...}",
  "include_request_attempt_count": "...",
  "include_attempt_count_in_response": "...",
  "retry_policy": "{...}",
  "hedge_policy": "{...}",
  "per_request_buffer_limit_bytes": "{...}"
}
 
имя

(строка, ТРЕБУЕТСЯ ) Логическое имя виртуального хоста. Это используется при излучении определенных статистика, но не имеет отношения к маршрутизации.

доменов

( повторяющаяся строка , ТРЕБУЕТСЯ ) Список доменов (заголовок хоста / органа власти), которые будут сопоставлены с этим виртуальный хост.Хосты с подстановочными знаками поддерживаются в форме суффикса или префикса.

Порядок поиска доменов:
  1. Точные доменные имена: www.foo.com .

  2. Подстановочные знаки суффиксного домена: * .foo.com или * -bar.foo.com .

  3. Подстановочные знаки домена префикса: foo. * или foo- * .

  4. Специальный подстановочный знак * , соответствующий любому домену.

Примечание

Подстановочный знак не соответствует пустой строке.например * -bar.foo.com будет соответствовать baz-bar.foo.com , но не -bar.foo.com . Сначала совпадают самые длинные символы подстановки. Только один виртуальный хост во всей конфигурации маршрута может соответствовать * . Домен должен быть уникальным для всех виртуальных хостов, иначе конфигурация не загрузится.

Домены не могут содержать управляющие символы. Это подтверждается well_known_regex HTTP_HEADER_VALUE.

маршрутов

( повторяется конфиг.route.v3.Route) Список маршрутов, которые будут сопоставлены по порядку для входящих запросов. Будет использован первый совпадающий маршрут.

require_tls

(config.route.v3.VirtualHost.TlsRequirementType) Определяет тип принудительного применения TLS, которого ожидает виртуальный хост. Если этого варианта нет указано, для виртуального хоста не требуется TLS.

virtual_clusters

( повторяется config.route.v3.VirtualCluster) Список виртуальных кластеров, определенных для этого виртуального хоста. Виртуальные кластеры используются для сбора дополнительной статистики.

rate_limits

( повторяется config.route.v3.RateLimit) Задает набор конфигураций ограничения скорости, которые будут применяться к виртуальный хост.

cors

(config.route.v3.CorsPolicy) Указывает, что виртуальный хост имеет политику CORS.

typed_per_filter_config

( повторяется map ) Поле per_filter_config может использоваться для обеспечения специфичного для виртуального хоста конфигурации для фильтров.Ключ должен соответствовать имени фильтра, например envoy.filters.http.buffer для буферного фильтра HTTP. Использование этого поля — фильтр специфический; см. документацию по HTTP-фильтру если и как это используется.

include_request_attempt_count

(bool) Определяет, должен ли быть включен заголовок x-envoy-try-count в восходящем запросе. Установка этого параметра приведет к тому, что он переопределит любой существующий заголовок значение, поэтому в случае двух посланников на пути запроса с включенной опцией восходящий поток увидит подсчет попыток, как считает второй посланник.По умолчанию — false. На этот заголовок не влияют флаг suppress_envoy_headers.

include_attempt_count_in_response

(bool) Определяет, должен ли быть включен заголовок x-envoy-try-count в ответе ниже по потоку. Установка этого параметра приведет к тому, что маршрутизатор переопределит любой существующий заголовок. значение, поэтому в случае двух посланников на пути запроса с включенной этой опцией нисходящий будет видеть подсчет попыток так, как его воспринимает посланник, ближайший от него по течению.По умолчанию — false. На этот заголовок не влияют флаг suppress_envoy_headers.

retry_policy

(config.route.v3.RetryPolicy) Указывает политику повтора для всех маршрутов на этом виртуальном хосте. Обратите внимание, что установка запись на уровне маршрута будет иметь приоритет над этой конфигурацией и будет обработана независимо (например: значения не наследуются).

hedge_policy

(config.route.v3.HedgePolicy) Указывает политику хеджирования для всех маршрутов на этом виртуальном хосте.Обратите внимание, что установка запись на уровне маршрута будет иметь приоритет над этой конфигурацией и будет обработана независимо (например: значения не наследуются).

per_request_buffer_limit_bytes

(UInt32Value) Максимальное количество байтов, которые будут буферизированы для повторных попыток и затенения. Если установлено, а ограничение для маршрута не установлено, фактически буферизованные байты будут минимальными. значение этого и слушателя per_connection_buffer_limit_bytes.

Enum config.route.v3.VirtualHost.TlsRequirementType

[протокол config.route.v3.VirtualHost.TlsRequirementType]

НЕТ

(ПО УМОЛЧАНИЮ) ⁣Нет требования TLS для виртуального хоста.

EXTERNAL_ONLY

⁣Внешние запросы должны использовать TLS. Если запрос внешний, а не при использовании TLS будет отправлено 301 редирект с указанием клиенту использовать HTTPS.

ALL

⁣Все запросы должны использовать TLS.Если запрос не использует TLS, 301 редирект будет отправлено клиенту с указанием использовать HTTPS.

config.route.v3.Route

[config.route.v3.Route proto]

Маршрут — это как спецификация того, как соответствовать запросу, так и указание того, что делать. следующий (например, перенаправление, пересылка, перезапись и т. д.).

 {
  "имя": "...",
  "соответствие": "{...}",
  "маршрут": "{...}",
  "перенаправить": "{...}",
  "direct_response": "{...}",
  "метаданные": "{...}",
  "декоратор": "{...} ",
  "typed_per_filter_config": "{...}",
  "request_headers_to_add": [],
  "request_headers_to_remove": [],
  "response_headers_to_add": [],
  "response_headers_to_remove": [],
  "трассировка": "{...}",
  "per_request_buffer_limit_bytes": "{...}"
}
 
имя

(строка) Имя маршрута.

соответствие

(config.route.v3.RouteMatch, ТРЕБУЕТСЯ ) Параметры сопоставления маршрутов.

маршрут

(конфиг.route.v3.RouteAction) Маршрутизировать запрос в некоторый восходящий кластер.

Должен быть установлен точно один из route, redirect, direct_response.

перенаправление

(config.route.v3.RedirectAction) Вернуть перенаправление.

Должен быть установлен точно один из route, redirect, direct_response.

direct_response

(config.route.v3.DirectResponseAction) Вернуть произвольный HTTP-ответ напрямую, без проксирования.

Должен быть установлен точно один из route, redirect, direct_response.

метаданные

(config.core.v3.Metadata) Поле метаданных можно использовать для предоставления дополнительной информации о маршруте. Его можно использовать для настройки, статистики и ведения журнала. Метаданные должны находиться в пространстве имен фильтра, которому они понадобятся. Например, если метаданные предназначены для фильтра маршрутизатора, имя фильтра должно быть указано как envoy.filters.http.роутер .

декоратор

(config.route.v3.Decorator) Декоратор для согласованного маршрута.

typed_per_filter_config

( повторяется map ) Поле typed_per_filter_config может использоваться для указания конкретного маршрута конфигурации для фильтров. Ключ должен соответствовать имени фильтра, например envoy.filters.http.buffer для буферного фильтра HTTP. Использование этого поля — фильтр специфический; см. документацию по фильтру HTTP для если и как это используется.

трассировка

(config.route.v3.Tracing) Наличие объекта определяет, будет ли конфигурация трассировки диспетчера соединений переопределяется этим конкретным экземпляром маршрута.

per_request_buffer_limit_bytes

(UInt32Value) Максимальное количество байтов, которые будут буферизированы для повторных попыток и затенения. Если установлено, фактически буферизованные байты будут минимальным значением этого и слушатель per_connection_buffer_limit_bytes.

config.route.v3.WeightedCluster

[config.route.v3.WeightedCluster proto]

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

 {
  «кластеры»: [],
  "общий вес": "{...} ",
  "runtime_key_prefix": "..."
}
 
кластеров

( повторяется config.route.v3.WeightedCluster.ClusterWeight, ТРЕБУЕТСЯ ) Определяет один или несколько восходящих кластеров, связанных с маршрутом.

total_weight

(UInt32Value) Задает общий вес для всех кластеров. Сумма всех весов кластера должна равняться этому значение, которое должно быть больше 0. По умолчанию 100.

runtime_key_prefix

(строка) Задает префикс ключа времени выполнения, который должен использоваться для создания ключи времени выполнения, связанные с каждым кластером.Когда runtime_key_prefix указан, маршрутизатор будет искать веса, связанные с каждым восходящим потоком. кластер под ключом runtime_key_prefix + «.» + cluster [i] .name где cluster [i] обозначает запись в поле массива кластеров. Если среда выполнения ключ для кластера не существует, значение, указанное в файл конфигурации будет использоваться в качестве веса по умолчанию. См. Документацию среды выполнения, чтобы узнать, как имена ключей сопоставляются с базовой реализацией.

config.route.v3.WeightedCluster.ClusterWeight

[протокол config.route.v3.WeightedCluster.ClusterWeight]

 {
  "имя": "...",
  "cluster_header": "...",
  "масса": "{...}",
  "metadata_match": "{...}",
  "request_headers_to_add": [],
  "request_headers_to_remove": [],
  "response_headers_to_add": [],
  "response_headers_to_remove": [],
  "typed_per_filter_config": "{...}",
  "host_rewrite_literal": "..."
}
 
имя

(строка) Можно указать только одно из name и cluster_header .Имя вышестоящего кластера. Кластер должен существовать в конфигурация менеджера кластера.

вес

(UInt32Value) Целое число от 0 до total_weight. Когда запрос соответствует маршруту, выбор восходящего кластера определяется его весом. Сумма весов по всем записи в массиве кластеров должны составлять в сумме значение total_weight, которое по умолчанию равно 100.

metadata_match

(config.core.v3.Metadata) Необязательные критерии соответствия метаданных конечной точки, используемые подсистемой балансировки нагрузки подмножества. Только конечные точки в восходящий кластер с метаданными, соответствующими тому, что задано в этом поле, будет рассматриваться для Балансировка нагрузки. Обратите внимание, что это будет объединено с тем, что предоставлено в RouteAction.metadata_match, с ценности здесь имеют приоритет. Имя фильтра должно быть указано как envoy.lb .

typed_per_filter_config

( повторяется map ) Поле per_filter_config может использоваться для предоставления взвешенных для конкретного кластера конфигурации для фильтров.Ключ должен соответствовать имени фильтра, например envoy.filters.http.buffer для буферного фильтра HTTP. Использование этого поля — фильтр специфический; см. документацию по HTTP-фильтру если и как это используется.

host_rewrite_literal

(строка) Указывает, что во время пересылки заголовок хоста будет заменен на это значение.

config.route.v3.RouteMatch

[config.route.v3.RouteMatch proto]

 {
  "приставка": "... ",
  "дорожка": "...",
  "safe_regex": "{...}",
  "connect_matcher": "{...}",
  "деликатный случай": "{...}",
  "runtime_fraction": "{...}",
  "заголовки": [],
  "параметры_запроса": [],
  "grpc": "{...}",
  "tls_context": "{...}",
  "dynamic_metadata": []
}
 
префикс

(строка) Если указано, маршрут является правилом префикса, что означает, что префикс должен соответствует началу заголовка : path .

Должен быть установлен точно один из prefix, path, safe_regex, connect_matcher.

путь

(строка) Если указано, маршрут является правилом точного пути, что означает, что путь должен точно соответствовать заголовку : path после удаления строки запроса.

Должен быть установлен точно один из prefix, path, safe_regex, connect_matcher.

safe_regex

(type.matcher.v3.RegexMatcher) Если указано, маршрут является правилом регулярного выражения, означающим, что регулярное выражение должно соответствовать заголовку : path после удаления строки запроса.Весь путь (без строки запроса) должен соответствовать регулярному выражению. Правило не будет соответствовать, если только подпоследовательность заголовка : путь соответствует регулярному выражению.

Должен быть установлен точно один из prefix, path, safe_regex, connect_matcher.

connect_matcher

(config.route.v3.RouteMatch.ConnectMatcher) Если это используется как сопоставление, сопоставление будет соответствовать только запросам CONNECT. Обратите внимание, что это не будет соответствовать запросам CONNECT в стиле обновления HTTP / 2. (WebSocket и т.п.), поскольку они нормализованы в Envoy как HTTP / 1.1 стиль обновления. Это единственный способ сопоставить запросы CONNECT для HTTP / 1.1. Для HTTP / 2, где расширенные запросы CONNECT могут иметь путь, сопоставители путей будут работать, если есть путь. Обратите внимание, что в Envoy поддержка CONNECT в настоящее время считается альфа-версией.

Должен быть установлен точно один из prefix, path, safe_regex, connect_matcher.

case_sensitive

(BoolValue) Указывает, что сопоставление префикса / пути должно производиться с учетом регистра. По умолчанию правда.Игнорируется для сопоставления safe_regex.

runtime_fraction

(config.core.v3.RuntimeFractionalPercent) Указывает, что маршрут должен дополнительно соответствовать ключу времени выполнения. Каждый раз маршрут считается за матч, он также должен подпадать под процент совпадений, указанный это поле. Для некоторой дроби N / D выбирается случайное число в диапазоне [0, D). Если число <= значение числителя N, или, если ключ отсутствует, значение по умолчанию значение, маршрутизатор продолжает оценивать оставшиеся критерии соответствия.Runtime_fraction конфигурацию маршрута можно использовать для постепенного внедрения изменений маршрута без полной код / ​​конфигурация развертывается. Дополнительную документацию см. В документации по смещению трафика.

Примечание

Разбор этого поля реализован таким образом, что могут быть представлены данные ключа времени выполнения. как протокол FractionalPercent, представленный как JSON / YAML, а также может быть представлен как целое число с предположением, что значение является целым процентом от 100. Для Например, поиск ключа времени выполнения, возвращающий значение «42», будет анализироваться как FractionalPercent числитель которого 42, а знаменатель СТО.Это сохраняет устаревшую семантику.

параметры_запроса

( повторяется config.route.v3.QueryParameterMatcher) Определяет набор параметров запроса URL, по которым должен выполняться маршрут. соответствие. Маршрутизатор проверит строку запроса из заголовка path по всем указанным параметрам запроса. Если количество указанных параметры запроса не равны нулю, все они должны соответствовать заголовку path строка запроса для совпадения.

grpc

(config.route.v3.RouteMatch.GrpcRouteMatchOptions) Если указано, будут сопоставлены только запросы gRPC. Роутер проверит что в заголовке типа содержимого есть application / grpc или один из различных application / grpc + values.

tls_context

(config.route.v3.RouteMatch.TlsContextMatchOptions) Если указано, контекст tls клиента будет сопоставлен с заданным варианты совпадения.

dynamic_metadata

( повторяется типа.matcher.v3.MetadataMatcher) Определяет набор динамических сопоставителей метаданных, по которым должен соответствовать маршрут. Маршрутизатор будет проверять динамические метаданные на соответствие всем указанным сопоставителям динамических метаданных. Если количество указанных динамических сопоставителей метаданных не равно нулю, все они должны соответствовать динамические метаданные для совпадения.

config.route.v3.RouteMatch.TlsContextMatchOptions

[протокол config.route.v3.RouteMatch.TlsContextMatchOptions]

 {
  "представил": "{...} ",
  "проверено": "{...}"
}
 
представлено

(BoolValue) Если указано, маршрут будет соответствовать тому, представлен ли сертификат или нет. Если не указано, статус представления сертификата (истина или ложь) не будет учитываться при сопоставлении маршрута.

проверено

(BoolValue) Если указано, маршрут будет соответствовать тому, подтвержден ли сертификат. Если не указан, статус проверки сертификата (истина или ложь) не будет учитываться при сопоставлении маршрутов.

config.route.v3.CorsPolicy

[config.route.v3.CorsPolicy proto]

 {
  "allow_origin_string_match": [],
  "allow_methods": "...",
  "allow_headers": "...",
  "expose_headers": "...",
  "max_age": "...",
  "allow_credentials": "{...}",
  "filter_enabled": "{...}",
  "shadow_enabled": "{...}"
}
 
allow_origin_string_match

( повторяется type.matcher.v3.StringMatcher) Задает шаблоны строк, соответствующие разрешенным источникам.Происхождение разрешено, если любое из совпадение сопоставителей строк.

allow_methods

(строка) Задает содержимое заголовка access-control-allow-methods .

max_age

(строка) Задает содержимое заголовка access-control-max-age .

allow_credentials

(BoolValue) Указывает, разрешает ли ресурс учетные данные.

filter_enabled

(config.core.v3.RuntimeFractionalPercent) Определяет% запросов, для которых включен фильтр CORS.

Если ни включен , filter_enabled , ни shadow_enabled не указаны, CORS фильтр будет включен для 100% запросов.

Если runtime_key — указано, Envoy будет искать ключ времени выполнения, чтобы получить процент запросов для фильтрации.

shadow_enabled

(конфиг.core.v3.RuntimeFractionalPercent) Определяет% запросов, для которых политики CORS будут оцениваться и отслеживаться, но не принудительно.

Это поле предназначено для использования, когда filter_enabled и enabled выключены. Один из тех поля должны явно отключить фильтр, чтобы этот параметр вступил в силу.

Если указан runtime_key, Envoy будет искать ключ времени выполнения, чтобы получить процент запросов, для которых он будет оценивать и отследите Origin запроса, чтобы определить, действителен ли он, но не применяет никаких политик.

config.route.v3.RouteAction

[config.route.v3.RouteAction proto]

 {
  "cluster": "...",
  "cluster_header": "...",
  "weighted_clusters": "{...}",
  "cluster_not_found_response_code": "...",
  "metadata_match": "{...}",
  "prefix_rewrite": "...",
  "regex_rewrite": "{...}",
  "host_rewrite_literal": "...",
  "auto_host_rewrite": "{...}",
  "host_rewrite_header": "...",
  "host_rewrite_path_regex": "{...}",
  "тайм-аут": "{...}",
  "idle_timeout": "{...} ",
  "retry_policy": "{...}",
  "request_mirror_policies": [],
  "приоритет": "...",
  "rate_limits": [],
  "include_vh_rate_limits": "{...}",
  "hash_policy": [],
  "корс": "{...}",
  "max_grpc_timeout": "{...}",
  "grpc_timeout_offset": "{...}",
  "upgrade_configs": [],
  "internal_redirect_policy": "{...}",
  "internal_redirect_action": "...",
  "max_internal_redirects": "{...}",
  "hedge_policy": "{...}",
  "max_stream_duration": "{...}"
}
 
кластер

(строка) Указывает восходящий кластер, в который должен быть направлен запрос к.

Должен быть установлен точно один из кластеров, cluster_header, weighted_clusters.

weighted_clusters

(config.route.v3.WeightedCluster) Для данного маршрута можно указать несколько восходящих кластеров. В запрос направляется в один из восходящих кластеров на основе весов назначается каждому кластеру. Видеть разделение трафика для получения дополнительной документации.

Должен быть установлен точно один из cluster, cluster_header, weighted_clusters.

cluster_not_found_response_code

(config.route.v3.RouteAction.ClusterNotFoundResponseCode) Код состояния HTTP, используемый, когда настроенный кластер не найден. Код ответа по умолчанию — 503 Служба недоступна.

metadata_match

(config.core.v3.Metadata) Необязательные критерии соответствия метаданных конечной точки, используемые подсистемой балансировки нагрузки. Только конечные точки в восходящем кластере с метаданными, соответствующими тому, что установлено в этом поле, будет считаться для балансировки нагрузки. При использовании weighted_clusters метаданные будут объединены со значениями при условии, что имеет приоритет.Имя фильтра должно быть указано как envoy.lb .

prefix_rewrite

(строка) Указывает, что во время пересылки соответствующий префикс (или путь) должен быть поменял местами с этим значением. Эта опция позволяет внедрять URL-адреса приложений по пути, отличному от путей, представленных на уровне обратного прокси. Фильтр маршрутизатора будет поместите исходный путь перед перезаписью в заголовок x-envoy-original-path.

Только один из prefix_rewrite или regex_rewrite может быть уточнено.

Внимание

Обратите особое внимание на использование завершающих слэшей в значение префикса соответствия маршрута. Удаление префикса из пути требует нескольких маршрутов для обработки всех случаев. Например, перезапись / prefix на / и / prefix / etc на / etc не может быть выполнена за один раз Маршрут, как показано в следующих записях конфигурации:

 - совпадение:
    префикс: "/ префикс /"
  маршрут:
    prefix_rewrite: "/"
- соответствие:
    префикс: "/ префикс"
  маршрут:
    prefix_rewrite: "/"
 

Имея указанные выше записи в конфигурации, запросы к / префиксу будут разделены на /, в то время как запросы к / prefix / etc будут разделены на / etc .

regex_rewrite

(type.matcher.v3.RegexMatchAndSubstitute) Указывает, что во время пересылки части пути, соответствующие узор следует переписать, допустив даже замену захвата группы из шаблона в новый путь, как указано при перезаписи строка подстановки. Это полезно, чтобы разрешить пути к приложениям. переписан таким образом, чтобы учитывались сегменты с переменным содержанием, например идентификаторы. Фильтр маршрутизатора поместит исходный путь таким, каким он был перед перезаписью в заголовок x-envoy-original-path.(. *?) один (. *) $ в паре со строкой замены \ 1two \ 2 заменит только первое вхождение на , преобразование пути / xxx / one / yyy / one / zzz в / xxx / two / yyy / one / zzz .

  • Шаблон (? I) / xxx / в паре со строкой подстановки / yyy / будет выполнять сопоставление без учета регистра и преобразовывать путь / aaa / XxX / bbb в / ааа / ггг / bbb .

  • host_rewrite_literal

    (строка) Указывает, что во время пересылки заголовок хоста будет заменен на это значение.

    Может быть установлен только один из host_rewrite_literal, auto_host_rewrite, host_rewrite_header, host_rewrite_path_regex.

    auto_host_rewrite

    (BoolValue) Указывает, что во время пересылки заголовок хоста будет заменен на имя хоста вышестоящего хоста, выбранного менеджером кластера. Этот опция применима только тогда, когда кластер назначения для маршрута имеет введите strict_dns или logic_dns . Установка этого в true с другим кластером типы не имеет никакого эффекта.

    Может быть установлен только один из host_rewrite_literal, auto_host_rewrite, host_rewrite_header, host_rewrite_path_regex.

    host_rewrite_path_regex

    (type.matcher.v3.RegexMatchAndSubstitute) Указывает, что во время пересылки заголовок хоста будет заменен на результат подстановки регулярного выражения, выполненной для значения пути с удалением запроса и фрагмента. / (.+) /.+$ » замена: \ 1

    Перепишет заголовок хоста на envoyproxy.io с учетом пути /envoyproxy.io/some/path .

    Может быть установлен только один из host_rewrite_literal, auto_host_rewrite, host_rewrite_header, host_rewrite_path_regex.

    тайм-аут

    (Продолжительность) Задает тайм-аут восходящего потока для маршрута. Если не указано, значение по умолчанию — 15 с. Этот простирается между точкой, в которой весь нисходящий запрос (т.е. конец потока) был обработано и когда ответ восходящего потока был полностью обработан. Значение 0 будет отключить тайм-аут маршрута.

    idle_timeout

    (Продолжительность) Задает тайм-аут простоя для маршрута. Если не указано, тайм-аут простоя для каждого маршрута отсутствует, хотя диспетчер соединений stream_idle_timeout по-прежнему будет применяться. Значение 0 полностью отключит тайм-аут простоя маршрута, даже если настроен тайм-аут простоя потока диспетчера соединений.

    Тайм-аут простоя отличается от тайм-аута, который обеспечивает верхнюю границу о времени отклика восходящего потока; idle_timeout вместо этого ограничивает сумму времени, когда поток запроса может простаивать.

    После декодирования заголовка тайм-аут простоя будет применяться к нисходящему потоку и события восходящего запроса. Каждый раз, когда событие кодирования / декодирования для заголовков или данные обрабатываются для потока, таймер будет сброшен. Если тайм-аут срабатывает, поток завершается с кодом ошибки 408 Request Timeout, если нет заголовок ответа восходящего потока был получен, в противном случае сброс потока происходит.

    Если действие перегрузки «envoy.overload_actions.reduce_timeouts» настроен, этот тайм-аут масштабируется в соответствии со значением для HTTP_DOWNSTREAM_STREAM_IDLE.

    retry_policy

    (config.route.v3.RetryPolicy) Указывает, что у маршрута есть политика повтора. Обратите внимание, что если это установлено, он будет иметь приоритет над политикой повтора на уровне виртуального хоста (например: политики не объединяются, большая часть внутренних становится принудительной политикой).

    request_mirror_policies

    ( повторяется config.route.v3.RouteAction.RequestMirrorPolicy) Указывает, что у маршрута есть политики зеркального отображения запросов.

    приоритет

    (config.core.v3.RoutingPriority) Опционально указывает приоритет маршрутизации.

    rate_limits

    ( повторяется config.route.v3.RateLimit) Задает набор конфигураций ограничения скорости, которые могут быть применены к маршрут.

    include_vh_rate_limits

    (BoolValue) Указывает, должен ли фильтр ограничения скорости включать скорость виртуального хоста пределы.По умолчанию, если для маршрута настроены ограничения скорости, виртуальный хост rate_limits не применяется к запрос.

    Это поле устарело. Используйте vh_rate_limits

    hash_policy

    ( повторяется config.route.v3.RouteAction.HashPolicy) Задает список политик хеширования, используемых для балансировки нагрузки хеширования кольца. Каждый политика хеширования оценивается индивидуально, и объединенный результат используется для направить запрос. Метод комбинирования является детерминированным, так что идентичные списки политик хеширования будут давать один и тот же хеш.Поскольку хеш политика проверяет определенные части запроса, она может не создать хэш (т.е. если хешированный заголовок отсутствует). Если (и только если) все настроено политики хеширования не могут генерировать хеш, хеш не будет создан для маршрут. В этом случае поведение такое же, как если бы политики хеширования не использовались. были указаны (т.е. балансировщик нагрузки кольцевого хэша выберет случайный бэкэнд). Если в хэш-политике для атрибута «терминал» установлено значение «истина», и хеш уже сгенерирован, хеш возвращается немедленно, игнорирование остальной части списка политик хеширования.

    cors

    (config.route.v3.CorsPolicy) Указывает, что у маршрута есть политика CORS.

    max_grpc_timeout

    (Продолжительность) Устарело grpc_timeout_header_max Если присутствует, и запрос является запросом gRPC, используйте Заголовок grpc-timeout, или его значение по умолчанию (бесконечность) вместо тайм-аут, но ограничить применяемый тайм-аут до максимального значения, указанного здесь. Если настроено как 0, максимально допустимый тайм-аут для Запросы gRPC бесконечны.Если не настроен вообще, заголовок grpc-timeout не используется. и время ожидания запросов gRPC истекло, как и любых других запросов, использующих тайм-аут или значение по умолчанию. Это можно использовать для предотвращения неожиданных тайм-аутов восходящего запроса из-за потенциально длинных промежутки времени между запросом gRPC и ответом в режиме потоковой передачи gRPC.

    grpc_timeout_offset

    (Продолжительность) Устарело grpc_timeout_header_offset. Если присутствует, Envoy скорректирует тайм-аут, предоставляемый заголовком grpc-timeout , вычитая предоставленная продолжительность из заголовка.Это полезно для того, чтобы Envoy мог установить свой глобальный тайм-аут должен быть меньше, чем крайний срок, установленный вызывающим клиентом, что делает его больше вероятно, что Envoy обработает тайм-аут вместо отмены вызова клиентом. Смещение будет применяться только в том случае, если предоставленное grpc_timeout больше, чем смещение. Этот гарантирует, что смещение будет только уменьшать тайм-аут и никогда не устанавливать его на 0 (что означает бесконечность).

    upgrade_configs

    ( повторяется config.route.v3.RouteAction.UpgradeConfig)

    internal_redirect_policy

    (config.route.v3.InternalRedirectPolicy) Если присутствует, Envoy будет пытаться следовать ответу восходящего перенаправления вместо проксирования ответ на нисходящий поток. Определен ответ восходящего перенаправления по redirect_response_codes.

    internal_redirect_action

    (config.route.v3.RouteAction.InternalRedirectAction)

    max_internal_redirects

    (UInt32Value) Внутреннее перенаправление обрабатывается, если количество предыдущих внутренних перенаправлений, которые обнаруженный нижестоящий запрос ниже этого значения, и internal_redirect_action установлен на HANDLE_INTERNAL_REDIRECT В случае, когда нисходящий запрос отбрасывается между несколькими маршрутами посредством внутреннего перенаправления, первый маршрут, который достигает этого порога или имеет internal_redirect_action установлен в PASS_THROUGH_INTERNAL_REDIRECT передаст перенаправление обратно в нисходящий поток.

    Если не указано, будет выполнено не более одного перенаправления.

    hedge_policy

    (config.route.v3.HedgePolicy) Указывает, что у маршрута есть политика хеджирования. Обратите внимание, что если это установлено, он будет иметь приоритет над политикой хеджирования на уровне виртуального хоста (например: политики не объединяются, большая часть внутренних становится принудительной политикой).

    max_stream_duration

    (config.route.v3.RouteAction.MaxStreamDuration) Задает максимальную продолжительность потока для этого маршрута.

    config.route.v3.RouteAction.RequestMirrorPolicy

    [config.route.v3.RouteAction.RequestMirrorPolicy proto]

    Маршрутизатор может дублировать трафик от одного кластера к другому. Электрический ток реализация по принципу «выстрелил и забыл», что означает, что Envoy не будет ждать, пока теневой кластер ответить перед возвратом ответа от основного кластера. Вся нормальная статистика собраны для теневого кластера, что делает эту функцию полезной для тестирования.

    Во время теневого копирования заголовок хоста / полномочий изменяется таким образом, что добавляется — тень . Это полезно для регистрации. Например, cluster1 становится cluster1-shadow .

    Примечание

    Теневое копирование не запускается, если первичный кластер не существует.

     {
      "cluster": "...",
      "runtime_fraction": "{...}",
      "trace_sampled": "{...}"
    }
     
    кластер

    (строка, ТРЕБУЕТСЯ ) Определяет кластер, на который будут зеркалироваться запросы.Кластер должен существуют в конфигурации менеджера кластера.

    runtime_fraction

    (config.core.v3.RuntimeFractionalPercent) Если не указано, все запросы к целевому кластеру будут зеркалироваться.

    Если указано, это поле имеет приоритет над полем runtime_key , и запросы также должны попадают под процент совпадений, указанный в этом поле.

    Для некоторой дроби N / D выбирается случайное число в диапазоне [0, D).Если число <= значение числителя N, или, если ключ отсутствует, значение по умолчанию значение, запрос будет зеркальным.

    trace_sampled

    (BoolValue) Определяет, следует ли производить выборку диапазона трассировки. По умолчанию true.

    config.route.v3.RouteAction.HashPolicy

    [протокол config.route.v3.RouteAction.HashPolicy]

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

     {
      "header": "{...}",
      "cookie": "{...}",
      "connection_properties": "{...}",
      "query_parameter": "{...}",
      "filter_state": "{...}",
      "Терминал": "..."
    }
     
    cookie

    (config.route.v3.RouteAction.HashPolicy.Cookie) Политика хеширования файлов cookie.

    Должен быть установлен точно один из заголовка, cookie, connection_properties, query_parameter, filter_state.

    connection_properties

    (config.route.v3.RouteAction.HashPolicy.ConnectionProperties) Хэш-политика свойств подключения.

    Должен быть установлен точно один из заголовка, cookie, connection_properties, query_parameter, filter_state.

    query_parameter

    (config.route.v3.RouteAction.HashPolicy.QueryParameter) Политика хеширования параметров запроса.

    Должен быть установлен точно один из заголовка, cookie, connection_properties, query_parameter, filter_state.

    filter_state

    (config.route.v3.RouteAction.HashPolicy.FilterState) Политика хеширования состояния фильтра.

    Должен быть установлен точно один из заголовка, cookie, connection_properties, query_parameter, filter_state.

    терминал

    (bool) Флаг, который закорачивает хэш-вычисление. Это поле содержит «Резервный» стиль конфигурации: «если политика терминала не работает, возврат к остальной части списка политик », это экономит время, когда терминал политика работает.

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

    спецификатор

    терминал

    Заголовок A

    правда

    Заголовок B

    ложь

    Заголовок C

    ложь

    Процесс generateHash завершается, если политика «заголовок A» генерирует хеш, как это окончательная политика.

    config.route.v3.RouteAction.HashPolicy.Cookie

    [config.route.v3.RouteAction.HashPolicy.Cookie proto]

    Envoy поддерживает два типа привязки файлов cookie:

    1. Пассивный. Envoy принимает файл cookie, который присутствует в заголовке файлов cookie, и хеши от его значения.

    2. Создано. Envoy генерирует и устанавливает cookie с истечением срока действия (TTL) по первому запросу клиента в его ответе клиенту, в зависимости от конечной точки, на которую отправляется запрос.Тогда клиент представляет это при следующем и всех последующих запросах. Хеш этого достаточно, чтобы гарантировать, что эти запросы будут отправлены в тот же конечная точка. Файл cookie создается путем хеширования источника и порты и адреса назначения, чтобы несколько независимых HTTP2 потоки в одном и том же соединении будут независимо получать одинаковые cookie, даже если они поступают к Посланнику одновременно.

     {
      "имя": "...",
      "ttl": "{...}",
      "дорожка": "..."
    }
     
    имя

    (строка, ТРЕБУЕТСЯ ) Имя файла cookie, который будет использоваться для получения хеш-ключа.Если cookie отсутствует, а указанный ниже ttl не установлен, хеш не будет произведено.

    ttl

    (Продолжительность) Если указано, cookie с TTL будет сгенерирован, если cookie нет. Если TTL присутствует и равен нулю, сгенерированный файл cookie будет быть файлом cookie сеанса.

    путь

    (строка) Имя пути для файла cookie. Если здесь не указан путь, нет пути будет установлен для файла cookie.

    конфиг.route.v3.RouteAction.HashPolicy.FilterState

    [config.route.v3.RouteAction.HashPolicy.FilterState proto]

    ключ

    (строка, ТРЕБУЕТСЯ ) Имя объекта в параметре filterState для каждого запроса, которое является Объект Envoy :: Http :: Hashable. Если нет данных, связанных с ключом, или сохраненный объект не является Envoy :: Http :: Hashable, хэш не будет создан.

    config.route.v3.RouteAction.UpgradeConfig

    [конфиг.route.v3.RouteAction.UpgradeConfig proto]

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

     {
      "upgrade_type": "...",
      "включено": "{...}",
      "connect_config": "{...}"
    }
     
    upgrade_type

    (строка, ТРЕБУЕТСЯ ) Имя этого обновления без учета регистра, e.грамм. «Веб-сокет». Для каждого типа обновления, представленного в upgrade_configs, запросы с Обновление: [upgrade_type] будет проксироваться вверх по течению.

    включен

    (BoolValue) Определяет, доступны ли обновления на этом маршруте. По умолчанию true.

    connect_config

    (config.route.v3.RouteAction.UpgradeConfig.ConnectConfig) Конфигурация для отправки данных в восходящем направлении в виде полезной нагрузки необработанных данных. Это используется для Запросы CONNECT при пересылке полезной нагрузки CONNECT как необработанного TCP.Обратите внимание, что в Envoy поддержка CONNECT в настоящее время считается альфа-версией.

    config.route.v3.RouteAction.UpgradeConfig.ConnectConfig

    [протокол config.route.v3.RouteAction.UpgradeConfig.ConnectConfig]

    Конфигурация для отправки данных в восходящем направлении в виде полезной нагрузки необработанных данных. Это используется для Запросы CONNECT или POST при пересылке полезной нагрузки запроса как необработанного TCP.

     {
      "proxy_protocol_config": "{...}",
      "allow_post": "..."
    }
     
    proxy_protocol_config

    (конфиг.core.v3.ProxyProtocolConfig) Если присутствует, заголовок протокола прокси будет добавлен к полезной нагрузке CONNECT, отправляемой в восходящем направлении.

    allow_post

    (bool) Если установлено, маршрут также позволит пересылать полезные данные POST как необработанный TCP.

    config.route.v3.RetryPolicy

    [config.route.v3.RetryPolicy proto]

    Обзор архитектуры

    HTTP retry.

     {
      "retry_on": "...",
      "num_retries": "{...}",
      "per_try_timeout": "{...} ",
      "per_try_idle_timeout": "{...}",
      "retry_priority": "{...}",
      "retry_host_predicate": [],
      "retry_options_predicates": [],
      "host_selection_retry_max_attempts": "...",
      "retriable_status_codes": [],
      "retry_back_off": "{...}",
      "rate_limited_retry_back_off": "{...}",
      "retriable_headers": [],
      "retriable_request_headers": []
    }
     
    retry_on

    (строка) Задает условия, при которых происходит повторная попытка. Это то же самое задокументированы условия для x-envoy-retry-on и х-посланник-повтор-грпк-на.

    num_retries

    (UInt32Value) Задает допустимое количество повторных попыток. Этот параметр не является обязательным и по умолчанию 1. Это те же условия, которые задокументированы для х-посланник-макс-повторов.

    per_try_timeout

    (Продолжительность) Определяет ненулевое время ожидания восходящего потока для каждой попытки повторной попытки (включая начальную попытку). Этот параметр не является обязательным. Те же условия, задокументированные для x-envoy-upstream-rq-per-try-timeout-ms применяется.

    Примечание

    Если не указано иное, Envoy будет использовать глобальный таймаут маршрута для запроса. Следовательно, при использовании 5xx на основе политика повтора, запрос, время ожидания которого истекло, не будет повторяться в качестве общего бюджета времени ожидания был бы истощен.

    per_try_idle_timeout

    (Продолжительность) Определяет тайм-аут простоя восходящего потока для каждой попытки повторной попытки (включая начальную попытку). Этот Параметр является необязательным, и если он отсутствует, таймаут простоя для каждой попытки отсутствует.Семантика per попробуйте тайм-аут простоя похожи на таймаут простоя маршрута и таймаут простоя потока оба выполняются диспетчером HTTP-соединений. Разница в том, что этот тайм-аут простоя применяется маршрутизатором для каждой отдельной попытки и, таким образом, после того, как все предыдущие фильтры run, в отличие от до , все предыдущие фильтры выполнялись для других таймаутов простоя. Этот тайм-аут полезен в случаях, когда общий тайм-аут запроса ограничен количеством повторных попыток и per_try_timeout, но есть желание обеспечить постепенный прогресс каждой попытки.Отметим также, что аналогичные to per_try_timeout, этот тайм-аут простоя не начинается до тех пор, пока оба запроса не будут получены маршрутизаторах и получено соединение пула соединений. В отличие от per_try_timeout, таймер простоя продолжает работать после того, как ответ начинает передаваться обратно нижестоящему клиенту. Это гарантирует, что данные ответа продолжают поступать без использования одного из HTTP таймауты простоя диспетчера соединений.

    retry_priority

    (config.route.v3.RetryPolicy.RetryPriority) Определяет реализацию RetryPriority, которая используется для определения распределение нагрузки по приоритетам, используемым для повторных попыток. Ссылаться на повторите попытку настройки плагина для получения более подробной информации.

    retry_host_predicate

    ( повторяется config.route.v3.RetryPolicy.RetryHostPredicate) Определяет коллекцию RetryHostPredicates, которая будет использоваться при выборе хоста для повторных попыток. Если какой-либо из предикатов отклоняет хост, выбор хоста будет повторяться.Обратитесь к настройке плагина повторной попытки для получения дополнительной информации. Детали.

    retry_options_predicates

    ( повторяется config.core.v3.TypedExtensionConfig) Предикаты параметров повтора, которые будут применены перед повторной попыткой запроса. Эти предикаты разрешить настройку поведения запроса между повторными попытками. при наличии встроенных расширений]

    host_selection_retry_max_attempts

    (int64) Максимальное количество попыток выбора хоста перед отказом, при котором точка, на которую будет перенаправлен последний выбранный хост.Если не указано, по умолчанию будет повторная попытка один раз.

    retriable_status_codes

    ( повторяется uint32) Коды состояния HTTP, которые должны инициировать повторную попытку в дополнение к тем, которые указаны в retry_on.

    retry_back_off

    (config.route.v3.RetryPolicy.RetryBackOff) Задает параметры, которые управляют отключением экспоненциальной повторной попытки. Этот параметр является необязательным, и в этом случае базовый интервал по умолчанию составляет 25 миллисекунд или, если он установлен, текущее значение вверх по течению.base_retry_backoff_ms параметр времени выполнения. Максимальный интервал по умолчанию — 10 раз. базовый интервал. Документация для x-envoy-max-retries описывает алгоритм отката Envoy.

    rate_limited_retry_back_off

    (config.route.v3.RetryPolicy.RateLimitedRetryBackOff) Определяет параметры, которые управляют используемой стратегией отката повторных попыток когда скорость запроса ограничена вышестоящим сервером. Сервер может вернуть заголовок ответа, например Retry-After или X-RateLimit-Reset to предоставить клиенту обратную связь о том, как долго ждать перед повторной попыткой.Если настроена, эта стратегия отката будет использоваться вместо стратегия экспоненциального отката по умолчанию (настроена с использованием retry_back_off ) всякий раз, когда ответ включает совпадающие заголовки.

    config.route.v3.RetryPolicy.RetryBackOff

    [config.route.v3.RetryPolicy.RetryBackOff proto]

     {
      "base_interval": "{...}",
      "max_interval": "{...}"
    }
     
    base_interval

    (Продолжительность, ТРЕБУЕТСЯ ) Определяет базовый интервал между повторными попытками.Этот параметр является обязательным и должен быть больше чем ноль. Значения менее 1 мс округляются до 1 мс. См. X-envoy-max-retries для обсуждения Envoy алгоритм отката.

    max_interval

    (Продолжительность) Задает максимальный интервал между попытками. Этот параметр не является обязательным, но должен быть больше или равно base_interval , если установлено. По умолчанию в 10 раз больше base_interval . См. Обсуждение x-envoy-max-retries алгоритма отката Envoy.

    config.route.v3.RetryPolicy.RateLimitedRetryBackOff

    [config.route.v3.RetryPolicy.RateLimitedRetryBackOff proto]

    Стратегия повторной попытки отката, которая применяется, когда скорость восходящего сервера ограничена. запрос.

    Для данной конфигурации:

     rate_limited_retry_back_off:
      reset_headers:
      - имя: Retry-After
        формат: СЕКУНДЫ
      - имя: X-RateLimit-Reset
        формат: UNIX_TIMESTAMP
      max_interval: "300 с"
     

    Будет применяться следующий алгоритм:

    1. Если ответ содержит заголовок Retry-After , его значение должно быть включено форма 120 (целое число, которое представляет количество секунд до подождите, прежде чем повторить попытку).Если да, то это значение используется как интервал отсрочки.

    2. В противном случае, если ответ содержит заголовок X-RateLimit-Reset его значение должно быть в форме 1595320702 (целое число, представляющее момент времени, в который следует повторить попытку, как временная метка Unix в секундах). Если так, текущее время вычитается из этого значения, и результат используется как интервал отсрочки.

    3. В противном случае Envoy будет использовать значение по умолчанию. экспоненциальный откат стратегия.

    Независимо от того, какой формат используется, если результирующий интервал отсрочки превышает max_interval он отбрасывается и следующий заголовок в reset_headers пробовал. Если для маршрута настроен тайм-аут запроса, он будет дальше ограничить продолжительность выполнения запроса.

    Чтобы предотвратить повторные попытки множества клиентов в один и тот же момент времени, добавлен джиттер. к интервалу отсрочки, поэтому итоговый интервал определяется следующим образом: случайный (интервал, интервал * 1.5) .

    Внимание

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

     {
      "reset_headers": [],
      "max_interval": "{...}"
    }
     
    max_interval

    (Продолжительность) Определяет максимальный интервал отсрочки, который допускает Envoy. Если сброс заголовок содержит интервал длиннее, чем этот, тогда он будет отброшен и следующий заголовок будет испробован.По умолчанию 300 секунд.

    config.route.v3.HedgePolicy

    [config.route.v3.HedgePolicy proto]

    Обзор архитектуры хеджирования HTTP-запросов

    .

     {
      "hedge_on_per_try_timeout": "..."
    }
     
    hedge_on_per_try_timeout

    (bool) Указывает, что хеджированный запрос должен быть отправлен, когда истечет время ожидания попытки. Это означает, что будет произведена повторная попытка без сброса исходного запроса, в результате чего несколько восходящих запросов останутся на лету.Первый успешно завершенный запрос будет возвращен вызывающему.

    • В любой момент клиенту будет возвращен успешный ответ (т. Е. Отсутствие каких-либо условий повторной попытки).

    • Перед тайм-аутом для каждой попытки ответ об ошибке (для условий повторной попытки) будет повторяться немедленно или возвращаться клиенту если больше не осталось попыток.

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

    Примечание. Для того, чтобы это сработало, у вас должна быть RetryPolicy, которая повторяет как минимум один код ошибки и указывает максимальное количество попыток.

    По умолчанию false.

    config.route.v3.RedirectAction

    [протокол config.route.v3.RedirectAction]

     {
      "https_redirect": "...",
      "scheme_redirect": "...",
      "host_redirect": "...",
      "port_redirect": "...",
      "path_redirect": "...",
      "prefix_rewrite": "...",
      "regex_rewrite": "{...} ",
      "response_code": "...",
      "strip_query": "..."
    }
     
    https_redirect

    (bool) Часть URL-адреса схемы будет заменена на «https».

    Когда происходит перенаправление схемы, применяются следующие правила:
    1. Если исходная схема URI http и порт явно установлено значение : 80 , порт будет удален после перенаправления

    2. Если исходная схема URI https и порт явно установлено значение : 443 , порт будет удален после перенаправления

    Может быть установлен только один из https_redirect, scheme_redirect.

    scheme_redirect

    (строка) Часть схемы URL-адреса будет заменена на это значение.

    Когда происходит перенаправление схемы, применяются следующие правила:
    1. Если исходная схема URI http и порт явно установлено значение : 80 , порт будет удален после перенаправления

    2. Если исходная схема URI https и порт явно установлено значение : 443 , порт будет удален после перенаправления

    Может быть установлен только один из https_redirect, scheme_redirect.

    host_redirect

    (строка) Хост-часть URL-адреса будет заменена на это значение.

    port_redirect

    (uint32) Значение порта URL-адреса будет заменено этим значением.

    path_redirect

    (строка) Часть пути URL-адреса будет заменена этим значением. Обратите внимание, что строка запроса в path_redirect переопределит строка запроса запроса и не будет удалена.

    Например, у нас есть следующие маршруты:

    • соответствие: {путь: «/ старый-путь-1»} перенаправление: {path_redirect: «/ new-path-1»}

    • соответствие: {путь: «/ старый-путь-2»} перенаправление: {path_redirect: «/ new-path-2», strip-query: «true»}

    • соответствие: {путь: «/ старый-путь-3»} перенаправление: {path_redirect: «/ new-path-3? foo = 1», strip_query: «true»}

    1. если URI запроса — «/ old-path-1? Bar = 1», пользователи будут перенаправлены на «/ new-path-1? Bar = 1»

    2. , если URI запроса — «/ old-path-2? Bar = 1», пользователи будут перенаправлены на «/ new-path-2»

    3. , если URI запроса — «/ old-path-3? Bar = 1», пользователи будут перенаправлены на «/ new-path-3? Foo = 1»

    Можно установить только одно из path_redirect, prefix_rewrite, regex_rewrite.

    prefix_rewrite

    (строка) Указывает, что во время перенаправления совпавший префикс (или путь) следует поменять местами на это значение. Эта опция позволяет динамически создавать URL-адреса перенаправления. на основании запроса.

    Может быть установлен только один из path_redirect, prefix_rewrite, regex_rewrite.

    regex_rewrite

    (type.matcher.v3.RegexMatchAndSubstitute) Указывает, что во время перенаправления части пути, соответствующие узор следует переписать, допустив даже замену захвата группы из шаблона в новый путь, как указано при перезаписи строка подстановки.(. *?) один (. *) $ в паре со строкой замены \ 1two \ 2 заменит только первое вхождение на , преобразование пути / xxx / one / yyy / one / zzz в / xxx / two / yyy / one / zzz .

  • Шаблон (? I) / xxx / в паре со строкой подстановки / yyy / будет выполнять сопоставление без учета регистра и преобразовывать путь / aaa / XxX / bbb в / ааа / ггг / bbb .

  • Можно установить только одно из path_redirect, prefix_rewrite, regex_rewrite.

    response_code

    (config.route.v3.RedirectAction.RedirectResponseCode) Код состояния HTTP для использования в ответе перенаправления. Ответ по умолчанию код — MOVED_PERMANENTLY (301).

    strip_query

    (bool) Указывает, что во время перенаправления запрашиваемая часть URL-адреса будет удалить. Значение по умолчанию — false.

    Перечисление config.route.v3.RedirectAction.RedirectResponseCode

    [конфиг.route.v3.RedirectAction.RedirectResponseCode proto]

    ПЕРЕМЕЩЕН ВСЕГДА

    (ПО УМОЛЧАНИЮ) ⁣Перемещен навсегда Код состояния HTTP — 301.

    НАЙДЕНО

    ⁣Найден код состояния HTTP — 302.

    SEE_OTHER

    ⁣См. Другой код состояния HTTP — 303.

    TEMPORARY_REDIRECT

    ⁣Код состояния HTTP для временного перенаправления — 307.

    PERMANENT_REDIRECT

    ⁣Код состояния HTTP для постоянного перенаправления — 308.

    config.route.v3.Decorator

    [config.route.v3.Decorator proto]

     {
      "операция": "...",
      "распространять": "{...}"
    }
     
    операция

    (строка, ТРЕБУЕТСЯ ) Имя операции, связанное с запросом, совпадающим с этим маршрутом. Если трассировка включено, эта информация будет использоваться в качестве имени диапазона, сообщаемого для этого запроса.

    Примечание

    Для входящих (входящих) запросов или исходящих (исходящих) ответов это значение может быть переопределено. заголовком операции x-envoy-decorator-operation.

    распространить

    (BoolValue) Следует ли передать украшенные детали другой стороне. По умолчанию это правда.

    config.route.v3.Tracing

    [config.route.v3.Tracing proto]

     {
      "client_sampling": "{...}",
      "случайная выборка": "{...}",
      "total_sampling": "{...}",
      "custom_tags": []
    }
     
    client_sampling

    (type.v3.FractionalPercent) Целевой процент запросов, управляемых этим диспетчером HTTP-соединений, которые будут принудительно выполнены отслеживается, если x-client-trace-id заголовок установлен.Это поле является прямым аналогом переменной времени выполнения. «Tracing.client_sampling» в диспетчере HTTP-соединений. По умолчанию: 100%

    random_sampling

    (type.v3.FractionalPercent) Целевой процент запросов, управляемых этим диспетчером HTTP-соединений, которые будут случайным образом выбирается для генерации трассировки, если не запрашивается клиентом или не принудительно. Это поле прямой аналог переменной времени выполнения «tracing.random_sampling» в Диспетчер HTTP-соединений.По умолчанию: 100%

    total_sampling

    (type.v3.FractionalPercent) Целевой процент запросов, управляемых этим диспетчером HTTP-соединений, которые будут отслеживаться после того, как были применены все другие выборочные проверки (ориентированные на клиента, принудительное отслеживание, случайные выборка). Это поле служит верхним пределом общей настроенной частоты дискретизации. Для Например, установка client_sampling на 100%, но total_sampling на 1% приведет только к 1% клиентских запросов с соответствующими заголовками для принудительной трассировки.Это поле является прямым аналог переменной времени выполнения «tracing.global_enabled» в Диспетчер HTTP-соединений. По умолчанию: 100%

    custom_tags

    ( повторяется type.tracing.v3.CustomTag) Список настраиваемых тегов с уникальным именем тега для создания тегов для активного диапазона. Он вступит в силу после слияния с соответствующей конфигурацией. настроен в диспетчере HTTP-соединений. Если настроены два тега с одинаковым именем каждый в диспетчере HTTP-соединений и на уровне маршрута, настроенный здесь принимает приоритет.

    config.route.v3.VirtualCluster

    [config.route.v3.VirtualCluster proto]

    Виртуальный кластер — это способ определения правила сопоставления регулярных выражений с определенные важные конечные точки, так что статистика создается явно для совпадающие запросы. Причина, по которой это полезно, заключается в том, что при выполнении сопоставление префикса / пути Envoy не всегда знает, что приложение считает конечной точкой. Таким образом, Envoy не может в целом испускать статистику для каждой конечной точки.Однако часто системы очень критичны. конечные точки, по которым они хотят получать «идеальную» статистику. Виртуальный кластер статистика идеальна в том смысле, что она передается в нисходящем направлении. сторона, так что они включают сбои на уровне сети.

    Документация по статистике виртуального кластера.

    Примечание

    Виртуальные кластеры — полезный инструмент, но мы не рекомендуем настраивать виртуальный кластер для каждая конечная точка приложения. Это нелегко в обслуживании, а также согласование и вывод статистики платный.

     {
      "заголовки": [],
      "имя": "..."
    }
     
    имя

    (строка, ТРЕБУЕТСЯ ) Задает имя виртуального кластера. Также имя виртуального кластера как имя виртуального хоста используются при выдаче статистики. Статистические данные выдаются фильтр маршрутизатора и описаны здесь.

    config.route.v3.RateLimit

    [протокол config.route.v3.RateLimit]

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

     {
      "сцена": "{...}",
      "disable_key": "...",
      "действия": [],
      "limit": "{...}"
    }
     
    этап

    (UInt32Value) Относится к этапу, установленному в фильтре. Только конфигурация ограничения скорости применяется к фильтрам с тем же номером стадии. Номер этапа по умолчанию: 0.

    Примечание

    Фильтр поддерживает диапазон от 0 до 10 включительно для номеров этапов.

    disable_key

    (строка) Ключ, который должен быть установлен во время выполнения для отключения этой конфигурации ограничения скорости.

    действия

    ( повторяется config.route.v3.RateLimit.Action, ТРЕБУЕТСЯ ) Список действий, которые должны применяться для этой конфигурации ограничения скорости. Порядок имеет значение, поскольку действия обрабатываются последовательно, а дескриптор состоит из добавления записей дескриптора в этой последовательности. Если действие не может добавить запись дескриптора, дескриптор не создается для конфигурация. Дополнительную документацию см. В разделе «Действия по компоновке».

    limit

    (config.route.v3.RateLimit.Override) Необязательное переопределение лимита, добавляемое к дескриптору, создаваемому этим конфигурация ограничения скорости. Если значение переопределения недействительно или не может быть разрешено из метаданных переопределения не предусмотрено. См. Дополнительную информацию в разделе «Отмена ограничения скорости».

    config.route.v3.RateLimit.Action

    [config.route.v3.RateLimit.Action proto]

     {
      "source_cluster": "{...} ",
      "destination_cluster": "{...}",
      "request_headers": "{...}",
      "удаленный_адрес": "{...}",
      "generic_key": "{...}",
      "header_value_match": "{...}",
      "dynamic_metadata": "{...}",
      "метаданные": "{...}",
      "расширение": "{...}"
    }
     
    source_cluster

    (config.route.v3.RateLimit.Action.SourceCluster) Ограничение скорости для исходного кластера.

    Должен быть установлен точно один из source_cluster, destination_cluster, request_headers, remote_address, generic_key, header_value_match, dynamic_metadata, metadata, extension.

    destination_cluster

    (config.route.v3.RateLimit.Action.DestinationCluster) Ограничение скорости для целевого кластера.

    Должен быть установлен точно один из source_cluster, destination_cluster, request_headers, remote_address, generic_key, header_value_match, dynamic_metadata, metadata, extension.

    remote_address

    (config.route.v3.RateLimit.Action.RemoteAddress) Ограничение скорости для удаленного адреса.

    Должен быть установлен точно один из source_cluster, destination_cluster, request_headers, remote_address, generic_key, header_value_match, dynamic_metadata, metadata, extension.

    generic_key

    (config.route.v3.RateLimit.Action.GenericKey) Ограничение скорости для универсального ключа.

    Должен быть установлен точно один из source_cluster, destination_cluster, request_headers, remote_address, generic_key, header_value_match, dynamic_metadata, metadata, extension.

    dynamic_metadata

    (config.route.v3.RateLimit.Action.DynamicMetaData) Ограничение скорости для динамических метаданных.

    Внимание

    Это поле устарело и заменено на поле метаданных

    .

    Должен быть установлен точно один из source_cluster, destination_cluster, request_headers, remote_address, generic_key, header_value_match, dynamic_metadata, metadata, extension.

    метаданные

    (config.route.v3.RateLimit.Action.MetaData) Ограничение скорости для метаданных.

    Должен быть установлен точно один из source_cluster, destination_cluster, request_headers, remote_address, generic_key, header_value_match, dynamic_metadata, metadata, extension.

    extension

    (config.core.v3.TypedExtensionConfig) Расширение дескриптора ограничения скорости. См. Документацию по расширениям дескриптора ограничения скорости.

    Подсказка

    У этой категории расширений есть следующие известные расширения:

    Должен быть установлен точно один из source_cluster, destination_cluster, request_headers, remote_address, generic_key, header_value_match, dynamic_metadata, metadata, extension.

    config.route.v3.RateLimit.Action.GenericKey

    [config.route.v3.RateLimit.Action.GenericKey proto]

    К дескриптору добавляется следующая запись дескриптора:

     ("generic_key", "")
     
     {
      "descriptor_value": "... ",
      "descriptor_key": "..."
    }
     
    descriptor_value

    (строка, ТРЕБУЕТСЯ ) Значение для использования в записи дескриптора.

    descriptor_key

    (строка) Необязательный ключ для использования в записи дескриптора. Если не установить его по умолчанию на «generic_key» в качестве ключа дескриптора.

    config.route.v3.QueryParameterMatcher

    [протокол config.route.v3.QueryParameterMatcher]

    Сопоставление параметров запроса обрабатывает строку запроса заголовка request: path. как список разделенных амперсандами ключей и / или элементов ключ = значение.

     {
      "имя": "...",
      "string_match": "{...}",
      "present_match": "..."
    }
     
    имя

    (строка, ТРЕБУЕТСЯ ) Задает имя ключа, который должен присутствовать в запрошенном путь — строка запроса.

    string_match

    (type.matcher.v3.StringMatcher) Указывает, должно ли значение параметра запроса совпадать со строкой.

    Может быть установлен только один из string_match, present_match.

    present_match

    (bool) Указывает, должен ли присутствовать параметр запроса.

    Может быть установлен только один из string_match, present_match.

    config.route.v3.InternalRedirectPolicy

    [протокол config.route.v3.InternalRedirectPolicy]

    Обзор архитектуры внутреннего перенаправления

    HTTP.

     {
      "max_internal_redirects": "{...}",
      "redirect_response_codes": [],
      "предикаты": [],
      "allow_cross_scheme_redirect": "... "
    }
     
    max_internal_redirects

    (UInt32Value) Внутреннее перенаправление не обрабатывается, если только количество предыдущих внутренних перенаправлений, которые обнаруженный нижестоящий запрос ниже этого значения. В случае, когда нисходящий запрос отбрасывается между несколькими маршрутами посредством внутреннего перенаправления, первый маршрут, который достигает этого порога или не устанавливает internal_redirect_policy передаст перенаправление обратно в нисходящий поток.

    Если не указано, будет выполнено не более одного перенаправления.

    redirect_response_codes

    ( повторяется uint32) Определяет, какие коды ответа восходящего потока могут запускать внутреннее перенаправление. Если не указано, только 302 будет рассматриваться как внутреннее перенаправление. Допустимые значения только 301, 302, 303, 307 и 308. Любые другие коды будут проигнорированы.

    предикаты

    ( повторяется config.core.v3.TypedExtensionConfig) Определяет список предикатов, которые запрашиваются, когда считается, что ответ восходящего потока для запуска внутреннего перенаправления по всем остальным критериям.Любой предикат в списке может отклонить перенаправление, в результате чего ответ будет передан нижестоящему.

    Подсказка

    У этой категории расширений есть следующие известные расширения:

    allow_cross_scheme_redirect

    (bool) Разрешить внутреннему перенаправлению следовать целевому URI с другой схемой, чем значение х-форвард-прото. По умолчанию — false.

    Факторы, влияющие на пиковую силу удара во время футбольных заголовков, и их значение для смягчения травм головы

    Abstract

    Документально подтверждено, что до 22% всех футбольных травм приходится на сотрясения мозга.Отчасти это происходит из-за того, что игроки намеренно используют голову для направления мяча во время игры. Чтобы обеспечить более полное понимание травм головы у футболистов, в этом исследовании было охарактеризовано влияние четырех характеристик футбольного мяча (размер, давление накачивания, масса, скорость) на результирующую пиковую силу удара, поскольку она связана с возможностью возникновения нейрофизиологических изменений. Всего было проведено шестьсот испытаний футбольных мячей размеров 4 и 5, а также нового легкого футбольного мяча.Сила удара измерялась с помощью силовой пластины, а скорость мяча определялась с помощью захвата движения. Эти данные использовались вместе с анализом размеров, чтобы связать силу удара с размером, массой, скоростью и давлением мяча. Разумное снижение допустимых параметров мяча привело к снижению пиковой силы удара на 19,7%. Корректировка параметров шариковых может снизить высокий кумулятивный пик поступательного ускорения футбол спортсмен вниз в предварительно определенном безопасный низкий диапазон нагрузок. Кроме того, было отмечено, что поглощение воды футбольными мячами может привести к образованию масс, которые существенно увеличивают силу удара и быстро превышают предел веса NCAA для игры.Требуются дополнительные исследования, чтобы определить, позволят ли различные характеристики футбольного мяча футболистам избежать стойкого нейрофизиологического дефицита или какие дополнительные вмешательства могут потребоваться, и обсуждаются юридические последствия этих данных.

    Образец цитирования: Auger J, Markel J, Pecoski DD, Leiva-Molano N, Talavage TM, Leverenz L, et al. (2020) Факторы, влияющие на пиковую силу удара во время футбольных заголовков, и их значение для смягчения травм головы.PLoS ONE 15 (10): e0240162. https://doi.org/10.1371/journal.pone.0240162

    Редактор: Серджио А. Усече, Университет Валенсии, ИСПАНИЯ

    Поступила: 21.11.2019; Принята к печати: 16 сентября 2020 г .; Опубликовано: 16 октября 2020 г.

    Авторские права: © 2020 Auger et al. Это статья в открытом доступе, распространяемая в соответствии с условиями лицензии Creative Commons Attribution License, которая разрешает неограниченное использование, распространение и воспроизведение на любом носителе при условии указания автора и источника.

    Доступность данных: Все соответствующие данные загружены в репозиторий исследований Университета Пердью (PURR) и общедоступны по следующему URL-адресу: https://purr.purdue.edu/publications/3565/1.

    Финансирование: Два мяча, протестированных в этом исследовании, были подарены EIR Soccer. Спонсор не имел никакого отношения к дизайну исследования, сбору и анализу данных, принятию решения о публикации или подготовке рукописи.

    Конкурирующие интересы: Два мяча, протестированных в этом исследовании, были подарены EIR Soccer.Это не влияет на нашу приверженность политике PLOS ONE в отношении обмена данными и материалами.

    1 Введение

    Футбол — самый популярный вид спорта в мире, в котором участвуют более 265 миллионов игроков профессионального и любительского уровня по всему миру, и было документально подтверждено, что до 22% всех травм в этом виде спорта составляют сотрясения мозга [1–4 ]. Отчасти это происходит из-за того, что игроки намеренно используют голову для направления мяча во время игры [3]. Футболист обычно видит до 12 заголовков в течение одной игры [5].За один сезон профессиональный футболист выполняет в среднем 800 ударов головой, не считая тех, которые выполняются во время тренировки. Несколько исследований уже показали, что частота сотрясений мозга в футболе сопоставима, а в некоторых случаях превышает таковую в футболе и хоккее [2, 5–9]. Более того, предыдущие исследования показали, что более 70% футболистов, получивших сотрясение мозга, не осознавали, что они получили сотрясение мозга в течение сезона [6, 10].

    Следует отметить, что официальный диагноз сотрясения мозга не требуется спортсменам для выявления существенных изменений в структуре и функциях мозга, которые можно обнаружить с помощью ряда инструментов оценки [11–17].Недавняя работа предполагает, что некоторые аспекты кумулятивного воздействия являются основным фактором риска в развитии патологических нейрофизиологических изменений, накопленных в течение сезона в контактных видах спорта [11, 16, 18–20], и что воздействия, превышающие 50 г, могут быть особенно опасными [21].

    Предыдущие исследования показали, что скорость мяча и соотношение масс между мячом и игроком являются важными параметрами при классификации потенциального риска травмы [22–24]. Согласно Своду правил мужского и женского футбола NCAA на 2016-2017 годы, Правило 2, подраздел 2.1, футбольный мяч должен иметь окружность 68,6–71,1 см, диапазон давления 0,61–1,12 бар (8,8–16,2 фунта на кв. Дюйм), вес в пределах 396,9–453,6 г в начале игры и может весить до 474,9. г в результате водопоглощения и использования [25]. Точно так же Правила игры ФИФА 2015-2016, Правило 2, допускают футбольный мяч с окружностью 68-70 см, диапазоном давления 0,59-1,08 бар (8,5-15,6 фунта на кв. Дюйм) и весом от 410 до 10 бар. 450 г в начале игры без верхнего предела веса мяча в результате водопоглощения и использования [26].Правила и положения могут варьироваться в зависимости от возрастной группы. Например, в США футбольные мячи размера 4 обычно требуются в возрасте до 12 лет [27].

    Цель этого исследования состояла в том, чтобы охарактеризовать влияние параметров футбольного мяча (размер, давление накачивания, масса, скорость) на результирующую пиковую силу удара и сопоставить ее с вероятностью получения травмы. Анализ размеров служил для разработки прогнозного уравнения, включающего исследуемые параметры. Затем был использован анализ чувствительности, чтобы установить вклад этих параметров в пиковую силу удара и выделить наиболее важные факторы.На основе этих выводов будут даны рекомендации для дальнейшей работы, которая может привести к повышению безопасности и снижению риска травм для футболистов.

    2 Теория

    2.1 Размерный анализ

    Анализ размеров был проведен с максимальной ударной силой в качестве выходного сигнала, и четыре наиболее важных входных параметра были приняты как давление накачивания ( p ), масса ( м ), диаметр ( d ) и скорость на входе ( v ). Предполагая, что мы зафиксировали все соответствующие параметры, мы можем утверждать, что, (1)

    Для уравнения (1) было пять физических переменных, выраженных в трех независимых физических единицах массы, длины и времени, обозначенных буквами M, L и T соответственно.Теорема Бакингема Пи утверждает, что уравнение (1) может быть преобразовано в эквивалентное безразмерное соотношение, имеющее только два безразмерных параметра [28]. Для этого исследования были выбраны м , d , v , чтобы обеспечить независимые физические единицы, и впоследствии безразмерный выходной параметр, Π o , был выражен как, (2) а входной параметр Π i можно записать как, (3)

    Таким образом, уравнение (1) можно переформулировать как (4)

    Предполагается, что это соотношение следует промежуточной асимптотике и поэтому принимает вид [28].Если все соответствующие параметры, влияющие на пиковую силу удара, были включены, то натуральный логарифм переменных Π дает, (5) что позволяет определить коэффициенты B и β из линейной регрессии экспериментальных данных. После определения этих коэффициентов уравнение для максимальной ударной силы имеет вид (6)

    3 метода

    3.1 Экспериментальные параметры

    Данные были собраны для шести футбольных мячей; два размера 4, два размера 5 и два новых «легких» мяча, подаренных EIR Soccer (далее размер 4.5 на этикетку производителя на шаре). Размер 4 и размер 5 были футбольными мячами Adidas Starlancer с той же типичной конструкцией шестиугольника / пятиугольника мозаичной панели. Диапазоны давления, указанные производителем, напечатаны на каждом шаре, и для мячей размером 4, 4,5 и 5 они составляли 0,50-0,70 бар (7,3-10,2 фунта на кв. Дюйм), 0,60-0,80 бар (8,7-11,6 фунта на кв. Дюйм) и 0,50-0,70. бар (7,3-10,2 фунта на кв. дюйм) соответственно. Стоит отметить, что спецификации производителя по давлению намного уже, чем и находятся на нижнем уровне правил игры.Футбольный мяч каждого размера прошел испытания при четырех различных давлениях: 0,27, 0,55, 0,83 и 1,10 бар (4, 8, 12 и 16 фунтов на кв. Дюйм). Было включено испытание под давлением 0,27 бара (4 фунта на квадратный дюйм) для проверки каждого футбольного мяча при давлении ниже стандартного производственного давления. Для каждого футбольного мяча, подвергаемого тестированию, измеряли размер и массу при каждом давлении.

    3.2 Процедура удаления ног и сбор данных

    Система захвата движения со встроенной силовой пластиной ws, используемая для получения данных для этого эксперимента (рис. 1).По каждому футбольному мячу исследователь наносил удары ногой с подъема стопой в подходах по десять штук, от малой до высокой в ​​каждом подходе, с расстояния примерно 2 метра от силовой пластины. Нестандартные удары, приводящие к рикошету или неправильным угловым траекториям, повторялись до тех пор, пока не была получена чистая перпендикулярная траектория. После каждой серии из десяти ударов давление футбольного мяча проверяли с помощью манометра и при необходимости регулировали для поддержания правильного уровня давления для испытания.Эту процедуру повторяли для 50 испытаний каждого размера шара при каждом давлении; 200 ударов на размер мяча, всего 600 ударов.

    Рис. 1. Экспериментальная установка, используемая для каждого удара футбольного мяча.

    Вертикально установленная силовая пластина собирала данные о силе удара с помощью сенсорного приемника PASCO Xplorer GLX , подключенного к портативному компьютеру с программным обеспечением PASCO Capstone [29]. Камера, установленная на перекладине над силовой пластиной, фиксировала ударное движение для расчета скорости мяча.

    https://doi.org/10.1371/journal.pone.0240162.g001

    3.3 Измерение силы удара

    Данные о силе удара были собраны с использованием PASCO Force Plate (PASCO, Roseville, CA, USA), установленной вертикально на металлической задней пластине с распорными балками с обеих сторон (Рис. 1). Стенд имел жесткую конструкцию, на которой была установлена ​​силовая пластина, чтобы уменьшить любой измерительный шум из-за гашения вибрационного движения.

    PASCO Force Plate выдает нормальную силу удара и, в сочетании с сенсорным приемником PASCO Xplorer GLX , может регистрировать с частотой 2 кГц [29].Перед каждым набором испытаний силовая пластина была подключена и тарирована на нулевой выходной сигнал, чтобы устранить любой шум покоя. Силовая пластина и датчик-приемник были подключены непосредственно к компьютеру, на котором запущено программное обеспечение PASCO Capstone для сбора данных. Положительный триггер был установлен на 4 Н, что вызвало окно сбора данных 40,0 мс (5,0 мс после запуска и 35,0 мс перед запуском), чтобы гарантировать измерение всей волны отклика каждого удара. Затем для идентификации и индексации пиковой силы удара для каждой формы волны удара использовался специальный сценарий MATLAB [30].

    3.4 Измерение скорости

    Установленная наверху видеокамера собирала кадры со скоростью 240 кадров в секунду, когда футбольный мяч приближался к силовой пластине, деформацию против силовой пластины и траекторию выхода футбольного мяча (рис. 1). Стационарная измерительная линейка на контрастирующем фоне использовалась в качестве ориентира для расстояния в каждом видеоклипе. Для каждого испытания видеоматериалы были разделены на отдельные кадры, чтобы можно было определить расстояние и скорость движения для входящих и исходящих траекторий.

    3.5 Испытания на погружение в воду

    Был проведен эксперимент с погружением, чтобы изучить возможность увеличения массы во время 90-минутной продолжительности игры. Согласно Сводке правил футбола NCAA на 2016–2017 годы, стандартный футбольный мяч «не должен быть больше 16 унций и не менее 14 унций» в начале игры и не может «превышать 16,75 унции, даже если он влажный и использованный» [25 ]. В пересчете на граммы футбольный мяч должен весить от 396,9 до 453,6 грамма в начале игры и не может превышать 474 грамма.9 грамм от водопоглощения или использования во время игры. Правила игры ФИФА на 2015-2016 гг. Не содержат никаких заявлений относительно ограничений на увеличение веса из-за водопоглощения. Все три размера футбольных мячей были накачаны до 0,55 бар (8 фунтов на кв. Дюйм), чтобы соответствовать техническим характеристикам производителя, а также нижнему пределу спецификаций NCAA и FIFA. Футбольные мячи взвешивали на весах в начале эксперимента, а затем погружали до средней линии мяча. С 15-минутными интервалами в течение 90-минутного периода три футбольных мяча взвешивались и вращались.

    3.6 Анализ чувствительности

    Метод

    Коттера был использован для выполнения анализа чувствительности вклада вышеупомянутых входных параметров в прогнозное уравнение из анализа размеров, чтобы выделить наиболее важные параметры, влияющие на пиковую силу удара [31, 32]. Диапазон значений для каждого параметра был основан на допустимых правилах игры в футбол на профессиональном уровне (размер 5) и значениях, полученных из литературы (Таблица 1). Эти данные предоставили высокие и низкие значения, используемые для метода Коттера.Минимальная скорость соответствует измеренным в поле скоростям вбрасывания, а максимальная скорость соответствует измеренным в поле ударам по воротам.

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

    4 Результаты

    4.1 Физические характеристики футбольных мячей

    Размер и масса каждого шара при каждом давлении были измерены трижды и зарегистрировано среднее значение (таблица 2). Несмотря на то, что при переходе от шара размера 4 к мячу размера 5 масса увеличилась на 11%, масса шара размера 4,5 была постоянно меньше массы шара размера 4.

    4,2 Ударные силы

    Временные ряды силы были собраны с пластины силы для каждого удара, обеспечивая пиковую силу удара, продолжительность удара и импульс.Диапазоны данных пиковой силы удара и продолжительности удара для шара размером 4 (для всех испытанных давлений) составляли 201-4419 Н и 0,0055-0,017 с, соответственно; для шара размером 4,5: 355-4641 Н и 0,0045-0,017 с соответственно; а для шара размером 5: 196-4667 Н и 0,0055-0,017 с соответственно (рис. 2).

    Рис. 2. Два образца ударных силовых волн.

    Первый был взят из футбольного мяча 4-го размера, накачанного до давления 27,6 кПа и доставленного со скоростью 4,57 м / с. Второй был взят из мяча 5-го размера, накачанного до давления 34.5 кПа со скоростью 14,6 м / с.

    https://doi.org/10.1371/journal.pone.0240162.g002

    Удары с более высокой скоростью приводят к более высокой пиковой силе удара при всех давлениях. Футбольные мячи размеров 4 и 4,5 показали одинаковые тенденции между скоростью и силой удара при повышенном давлении; повышенное давление накачивания футбольного мяча соответствовало увеличению пиковой силы удара во всем диапазоне скоростей. Средняя пиковая сила удара по всем испытаниям в выбранном диапазоне скоростей продемонстрировала, что снижение давления накачивания шара для всех размеров привело к уменьшению пиковой силы удара (Таблица 3).Особо следует отметить, что легкий мяч размером 4,5 показал более низкие средние пиковые силы удара во всем диапазоне давлений. Диаметр футбольного мяча стандартного размера 4 и размера 5, хотя и имеет меньший вес, чем оба стандартных размера, мог способствовать этой наблюдаемой разнице. Учитывая профессиональный футбольный мяч размера 5, давление накачивания мяча 1,10 бар (16 фунтов на квадратный дюйм) дает среднюю пиковую силу удара 3606 Н. Давление накачивания мяча 0,55 бар (8 фунтов на квадратный дюйм) дает среднюю пиковую силу удара 2895 Н ; снижение средней пиковой силы удара на 20% для того же диапазона скоростей 14-17 м / с.

    4.3 Испытания на погружение в воду

    Первоначальные наблюдения показали, что большая часть водопоглощения произошла в первые 15 минут погружения, при этом футбольные мячи размером 4, 4,5 и 5 увеличились в массе на 16,3%, 5,7% и 22,3% соответственно (Таблица 4).

    4.4 Размерный анализ

    Линейная зависимость между логарифмически преобразованными безразмерными переменными была продемонстрирована для всех размеров мяча и давления наддува (рис. 3) с использованием уравнений 2 и 3 ( R 2 = 0.94). Соответствующее уравнение для пиковой силы оказалось следующим: (7)

    Рис. 3. Натуральный логарифм o (Сила) по сравнению с и всех 600 точек данных.

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

    https://doi.org/10.1371/journal.pone.0240162.g003

    4.5 Анализ чувствительности

    Анализ чувствительности в обоих случаях (без и с диапазоном массы водопоглощения) показал, что наиболее важным фактором, влияющим на пиковую силу удара, была скорость мяча, при этом давление накачивания близко к порогу чувствительности 1/ n p = 0.25. (Рис. 4 и 5). Для массы индекс чувствительности был ниже 1/ n p при S = ​​0,12 без учета водопоглощения (рис. 4). При учете увеличенного диапазона масс из-за водопоглощения индекс чувствительности увеличивается до S = 0,219 и превосходит индекс чувствительности к давлению накачки S = ​​0,204 (рис. 5).

    Рис. 4. Анализ чувствительности метода Коттера с учетом диапазона масс 0,3969–0,4797 кг, диапазона диаметров 0,2041–0,2208 м, давления в воздухе между 58.6 и 111,7 кПа, а диапазон скоростей 15-30 м / с.

    Самым важным параметром была скорость мяча, но следует отметить, что давление мяча имело значение чувствительности, близкое к критическому порогу 0,25.

    https://doi.org/10.1371/journal.pone.0240162.g004

    Рис. 5. Анализ чувствительности метода Коттера с учетом диапазона значений повышенной водопоглощающей способности для футбольного мяча 5-го размера профессионального уровня.

    Водопоглощение делает массу вторым по важности параметром.

    https://doi.org/10.1371/journal.pone.0240162.g005

    5 Обсуждение

    Защитное оборудование существует для футбола, но оно не получило широкого распространения и не подвергалось надлежащей клинической проверке в качестве профилактической меры для снижения риска ЧМТ от повторяющихся ударов головой. Некоторые защитные повязки на голову продемонстрировали ослабление предельной силы, но еще не продемонстрировали доказанного снижения неврологических нарушений в результате событий ускорения головы [24, 34, 35].Важно отметить, что разработка защитного снаряжения и лучшее понимание механизмов, с помощью которых повторная травма головы вызывает неврологические изменения, требует тщательной характеристики сил, возникающих при контакте с головой. Таким образом, цель этого исследования состояла в том, чтобы охарактеризовать влияние параметров футбольного мяча (размер, давление в инфляции, масса) по разбросу скоростей на результирующую пиковую силу удара и корреляцию с поступательным ускорением, поскольку оно связано с возможностью получения травмы.

    Анализ чувствительности полученного уравнения для максимальной силы удара показал, что, как и ожидалось, скорость удара футбольного мяча является наиболее важным фактором (рис. 4). Однако скорость мяча не обязательно контролируется во время игры, и ограничение скорости мяча в игре было бы непрактичным. Если рассматривать разумно контролируемые параметры, то снижение внутреннего давления обеспечивает наибольшую «доходность» при уменьшении пиковой силы удара (Таблица 3). Для типичных скоростей шара снижение давления с 1.От 10 бар (16 фунтов на квадратный дюйм) до 0,55 бар (8 фунтов на квадратный дюйм) снижает пиковую силу удара почти на 20%.

    Испытания погружением в воду показали, что футбольные мячи быстро впитывают воду и увеличиваются в массе (Таблица 4). В течение 15 минут после погружения футбольный мяч размера 5 уже превысил верхний предел веса в 474,8 г, разрешенный правилами NCAA [25]. Принимая во внимание эти значения, анализ чувствительности, учитывающий больший диапазон масс из-за водопоглощения, показал, что индекс чувствительности для массы превосходит индекс чувствительности к давлению накачки и находится прямо на пороге чувствительности 1/ n p (рис. 5).Оцениваемый диапазон масс представляет собой идеальный случай экстремального воздействия воды, а фактические условия окружающей среды при постоянной игре могут ограничивать уровень удержания воды. Однако эти результаты показывают, что масса футбольного мяча действительно увеличивается во время воздействия воды и, если ее не проверять постоянно, может привести к увеличению массы сверх допустимых пределов.

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

    Исследование Svaldi et al. парная функциональная МРТ с мониторингом удара головой для отслеживания изменений цереброваскулярной реактивности (CVR) в течение сезона школьного футбола [36]. Спортсмены-футболисты из двух школ (n = 14; возраст 15-17 лет) были охарактеризованы как «высокая нагрузка» или «низкая нагрузка» в соответствии с кумулятивным PLA (группа с кумулятивным PLA с высокой нагрузкой: 25-й процентиль = 4514.7 г, 50-й процентиль = 5614,9 г, 75-й процентиль = 12313,0 г, среднее общее количество совпадений = 200,3; средний PLA на попадание = 39,5 г; Кумулятивная группа PLA с низкой нагрузкой: 25-й процентиль = 2424,6 г, 50-й процентиль = 2930,0 г, 75-й процентиль = 3800,2 г, среднее общее количество попаданий = 84,1, среднее количество попаданий = 36,3 г). Измерения CVR у спортсменов с высокой нагрузкой продемонстрировали значительное снижение CVR всего мозга и регионов по сравнению с предсезонным тестированием, которое сохранялось как минимум через 3–4 месяца после прекращения воздействия (рис. 6).Напротив, у спортсменов с низкой нагрузкой не наблюдалось значительных изменений CVR, по сравнению с предсезонным тестированием, ни на одном последующем сеансе наблюдения в любой интересующей разделенной области мозга [36]. Следовательно, изменения CVR у спортсменов, занимающихся спортом на столкновение, являются функцией кумулятивной нагрузки. Отсюда следует, что любые контролируемые изменения, приводящие к переходу ранее назначенного спортсмена с высокой нагрузкой в ​​диапазон с низкой нагрузкой, также соответствуют заметному снижению риска нейрофизиологического ущерба.

    Рис 6.Группы Свальди и др. «Высокая нагрузка» и «Низкая нагрузка» из футбольного сезона (процентили высокой нагрузки: 25-е = 4515 г, 50-е = 5615 г, 75-е = 12313 г; процентили низкой нагрузки: 25-е = 2425 г, 50-е места. = 2930 г, 75-й = 3800 г) [36].

    Постсезонная корректировка группы высоких нагрузок: снижение на 19,7% при снижении внутреннего давления с 1,10 бар (16 фунтов на кв. Дюйм) до 0,55 бар (8 фунтов на кв. Дюйм), снижение на 7,1% при уменьшении размера шара размером 5, 0,55 бар (8 фунтов на кв. Дюйм) до размер 4,5, шар 0,55 бар (8 фунтов на квадратный дюйм) (таблица 3) и уменьшение количества ударов на 20% в зависимости от среднего PLA на одно попадание (скорректированные процентили высокой нагрузки: 25-й = 2463 г, 50-й = 3063 г, 75-й = 6718 г. ).

    https://doi.org/10.1371/journal.pone.0240162.g006

    Используя данные, полученные здесь, и сильную регрессию между безразмерными параметрами, снижение PLA на 19,7% может произойти за счет снижения инфляционного давления с 1,10 бар (16 фунт / кв. дюйм) до 0,55 бар (8 фунт / кв. дюйм), дальнейшее снижение на 7,1% в результате уменьшения размера шара размером 5, 0,55 бар (8 фунтов на кв. дюйм) до шара размером 4,5, 0,55 бар (8 фунтов на кв. дюйм) (Таблица 3), и 20% -ное сокращение количества попаданий на основе средней PLA каждого события удара для каждого игрока.Корректировки с высокой нагрузкой дали 25-й процентиль = 2463 г, 50-й процентиль = 3063 г и 75-й процентиль = 6718 г. Это служит демонстрацией того, что если бы эти корректировки игрового процесса применялись на протяжении сезона, значительная часть спортсменов с высокой нагрузкой попала бы в идентифицированный гораздо более безопасный диапазон с низкой нагрузкой. Использование этих данных для улучшения конструкции футбольных головных уборов могло бы дополнительно обеспечить дополнительное сокращение совокупного количества PLA, с которым футболист сталкивается в течение всего сезона.

    Основываясь на результатах Свальди и др., [36], уменьшение совокупного PLA в результате снижения давления в шаре, уменьшения размера шара и общего уменьшения количества ударов может позволить существенное количество ранее обозначенных высоких нагрузок. спортсменов должны перейти к более безопасному диапазону обозначений низкой нагрузки, что означает снижение риска накопления стойких изменений в структуре или функциях мозга (рис. 6).

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

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

    В условиях влажной окружающей среды футбольные мячи следует исключать из игры для новых, сухих футбольных мячей, чтобы предотвратить поглощение воды сверх допустимого предела увеличения веса в соответствии с футбольными правилами NCAA. После первых 15 минут погружения в воду футбольный мяч размера 5 уже превысил допустимую прибавку в весе, указанную в футбольных правилах NCAA (Таблица 4). Удержание воды на футбольном мяче также может быть решено на уровне производителя. Стандарты сертификации футбольных мячей на водонепроницаемость должны гарантировать, что производители будут производить футбольные мячи, которые могут сохранять адекватную водонепроницаемость в течение всей продолжительности игры (90 минут), не подвергаясь поглощению массы сверх установленных ограничений по весу.Представленные здесь рекомендации ни в коем случае не являются исчерпывающими и основаны на предварительных результатах этого исследования. Например, можно добиться аналогичного снижения совокупной нагрузки за счет уменьшения давления в футбольном мяче и применения строгих правил практики и управления игрой в отношении количества разрешенных ударов головой. Необходимы дальнейшие следственные работы, чтобы обеспечить достаточную поддержку для внесения каких-либо существенных изменений в игровой процесс.

    В будущей работе системы измерения с более высоким разрешением позволят получить более точные данные.Все удары ногами выполнялись с использованием типичного подъема ногой, чтобы обеспечить больший контроль угла траектории футбольного мяча. Опора на человеческий фактор для каждого удара добавляла уровень вариативности с точки зрения управления траекторией футбольного мяча. Однако при таком коротком расстоянии перемещения и покадровой аппроксимации скорости изменения угла траектории никогда не были настолько экстремальными, чтобы вызвать значительные различия в измерении скорости. При пройденном расстоянии и захвате видео с частотой кадров 240 кадров в секунду, измерение скорости показало ошибку менее 4%.Изучение баланса количества движения и баланса момента количества движения модели физиологии головы и шеи позволит сравнить PLA центра масс головы с сезонными данными, полученными из систем мониторинга ударов головы. Внутриигровой набор типичных уровней накачивания мяча может служить подтверждением такой модели. Общая цель — снизить риск черепно-мозговой травмы, особенно кумулятивных долгосрочных последствий, и создать более безопасную и устойчивую игровую среду, которую можно определить количественно.

    Ссылки

    1. 1. Ковассин Т., Сваник CB, Sachs ML. Эпидемиологические соображения сотрясения мозга у межвузовских спортсменов. Прикладная нейропсихология. 2003. 10 (1): 12–22. pmid: 12734071
    2. 2. Барнс BC, Купер Л., Киркендалл Д.Т., Макдермотт Т.П., Джордан Б.Д., Гаррет В.Е. История сотрясений мозга у элитных футболистов мужского и женского пола. Американский журнал спортивной медицины. 1998. 26 (3): 433–438. pmid: 9617409
    3. 3. Родригес А.С., Ласмар Р.П., Карамелли П.Влияние футбольного заголовка на структуру и функции мозга. Границы неврологии. 2016; 7.
    4. 4. com F. Fifa Big Count 2006: 270 миллионов человек, занимающихся футболом; 2007. Доступно по адресу: http://www.fifa.com/media/news/y=2007/m=5/news=fifa-big-count-2006-270-million-people-active-football-529882.html. .
    5. 5. Леви ML, Kasasbeh AS, Baird LC, Amene C, Skeen J, Marshall L. Сотрясения мозга в футболе: текущее понимание. Мировая нейрохирургия. 2012. 78 (5): 535–544.pmid: 22120567
    6. 6. Делани Дж. С., Лакруа В. Дж., Леклерк С., Джонстон К. М.. Сотрясения мозга среди университетских футболистов и футболистов. Клинический журнал спортивной медицины. 2002. 12 (6): 331–338. pmid: 12466687
    7. 7. Delaney JS. Травмы головы, поступающие в отделения неотложной помощи США с 1990 по 1999 год для хоккея с шайбой, футбола и футбола. Клинический журнал спортивной медицины. 2004. 14 (2): 80–87. pmid: 15014341
    8. 8. Гессель Л.М., Филдс С.К., Коллинз К.Л., Дик Р.В., Комсток Р.Д.Сотрясения мозга среди спортсменов средней школы и университетских университетов США. Журнал спортивной подготовки. 2007. 42 (4): 495–503. pmid: 18174937
    9. 9. Келли Дж. П., Розенберг Дж. Х. Диагностика и лечение сотрясения мозга в спорте. Неврология. 1997. 48 (3): 575–580. pmid:

      29

    10. 10. Taha Z, Hassan MHA, Hasanuddin I. Аналитическое моделирование футбольного заголовка. Садхана. 2015; 40 (5): 1567–1578.
    11. 11. Кёрте И.К., Николс Э., Триподис Ю., Шульц В., Ленер С., Игбиноба Р. и др.Нарушение когнитивных функций у юных спортсменов, подвергающихся повторяющимся ударам головы. J Neurotrauma. 2017; 34 (16): 2389–2395. pmid: 28381107
    12. 12. Talavage TM, Nauman EA, Leverenz LJ. Роль медицинской визуализации в перехарактеризации легкой травмы головного мозга с использованием юношеского спорта в качестве лаборатории. Границы неврологии. 2016; 6. pmid: 26834695
    13. 13. Байлес Дж. Э., Петраглиа А. Л., Омалу Б. И., Науман Э., Талаваге Т. Роль субконтузии в повторяющихся легких травмах головного мозга.Журнал нейрохирургии. 2013. 119 (5): 1235–1245. pmid: 23971952
    14. 14. Matser EJT, Kessels AG, Lezak MD, Jordan BD, Troost J. Нейропсихологические нарушения у футболистов-любителей. ДЖАМА. 1999. 282 (10): 971–973. pmid: 10485683
    15. 15. О’Кейн Дж. У., Спикер А., Леви М. Р., Нерадилек М., Полиссар Н. Л., Шифф М. А.. Сотрясение мозга среди девушек-футболистов из средних школ. JAMA Pediatrics. 2014. 168 (3): 258–264. pmid: 24446018
    16. 16. Бридлав К.М., Бридлав Е.Л., Робинсон М., Пул В.Н., Кинг-младший, Розенбергер П. и др.Обнаружение нейрокогнитивных и нейрофизиологических изменений в результате субконкуссионных ударов среди спортсменов-футболистов средней школы. Спортивная подготовка и спортивное здравоохранение. 2014. 6 (3): 119–127.
    17. 17. Аббас К., Шенк Т.Э., Пул В.Н., Бридлав Е.Л., Леверенц Л.Дж., Науман Е.А. и др. Изменение сети режима по умолчанию у спортсменов-футболистов средней школы из-за повторяющихся субконкуссионных легких травм головного мозга: исследование функциональной магнитно-резонансной томографии в состоянии покоя. Связь мозга.2015; 5 (2): 91–101. pmid: 25242171
    18. 18. Гускевич К.М., Михалик Дж.П., Шанкар В., Маршалл С.В., Кроуэлл Д.Х., Олиаро С.М. и др. Измерение ударов головы у футболистов студенческого футбола: взаимосвязь между биомеханикой удара головой и острым клиническим исходом после сотрясения мозга. Нейрохирургия. 2007. 61 (6): 1244–1253. pmid: 18162904
    19. 19. Talavage TM, Nauman EA, Breedlove EL, Yoruk U, Dye AE, Morigaki KE и др. Функционально-обнаруженное когнитивное нарушение у футболистов средней школы без клинически диагностированного сотрясения мозга.Журнал нейротравмы. 2014. 31 (4): 327–338. pmid: 20883154
    20. 20. Маккуен Э., Свальди Д., Бридлав К., Краз Н., Каммиски Б., Бридлав Е.Л. и др. Женщины-футболистки университетского класса испытывают более сильное кумулятивное воздействие головы, чем их сверстницы из старшей школы. Журнал биомеханики. 2015. 48 (13): 3720–3723. pmid: 26329462
    21. 21. Свальди Д.О., Джоши К., Маккуен Э.С., Music JP, Hannemann R, Leverenz LJ и др. Накопление значительных событий ускорения предсказывает изменения цереброваскулярной реактивности у спортсменок-футболистов средней школы.Визуализация мозга и поведение. Под давлением.
    22. 22. Королева Р.М., Вайнхольд П.С., Киркендалл Д.Т., Ю. Б. Теоретическое исследование влияния свойств мяча на силу удара в футбольном заголовке. Медицина и наука в спорте и физических упражнениях. 2003. 35 (12): 2069–2076.
    23. 23. Наунхейм Р.С., Бейли П.В., Стандевен Дж., Нойбауэр Дж.С., Льюис Л.М., Генин Г.М. Линейное и угловое ускорение головы при движении футбольного мяча. Медицина и наука в спорте и физических упражнениях. 2003. 35 (8): 1406–1412.
    24. 24. Брольо ИП, Ю Ю.Г., Брольо М.Д., Продам ТЦ. Эффективность футбольных головных уборов. Журнал спортивной подготовки. 2003. 38 (3): 220–224. pmid: 14608431
    25. 25. Андрес К., Фергюсон А. Правила мужского и женского футбола NCAA 2016 и 2017; 2016.
    26. 26. ФИФА. Правила игры 2015/2016; 2015.
    27. 27. Футбол USY. Правила игры; 2017. Доступно по адресу: http://www.usyouthsoccer.org/coaches/PolicyonPlayersandPlayingRules/.
    28. 28. Barenblatt GI. Масштабирование. Кембриджские тексты по прикладной математике. Издательство Кембриджского университета; 2003.
    29. 29. Научный П. ПАСКО; 2016 г. Доступно по адресу: https://www.pasco.com/.
    30. 30. MATLAB. версия R2016b. MathWorks Inc .; 2016.
    31. 31. Коттер SC. Общий метод смешивания для симметричных факторных экспериментов. Журнал Королевского статистического общества, серия B (методологический). 1974; п. 267–276.
    32. 32. Шафф М.М., Гор JP, Науман EA. Модель теории смесей переноса жидкости и растворенных веществ в микрососудистом русле нормальных и злокачественных тканей. Ii: анализ чувствительности факторов, калибровка и проверка. Журнал математической биологии. 2013. 67 (6-7): 1307–1337. pmid: 23108729
    33. 33. Коидзуми А., Хонг С., Сакамото К., Сасаки Р., Асаи Т. Исследование силы удара на современные футбольные мячи. Разработка процедур. 2014; 72: 423–428.
    34. 34. Наунхейм Р.С., Райден А., Стандевен Дж., Генин Г., Льюис Л., Томпсон П. и др.Снижает ли футбольный головной убор удар головой при ударе футбольного мяча? Академическая неотложная медицина. 2003. 10 (1): 85–90. pmid: 12511322
    35. 35. Эльбин Р.Дж., Битти А., Ковассин Т., Шац П., Хайдман А., Контос А.П. Предварительное исследование нейрокогнитивных функций и симптомов после футбольного матча у спортсменов, носящих защитные футбольные повязки на голову. Исследования в области спортивной медицины. 2015; 23 (2): 203–214. pmid: 25666112
    36. 36. Svaldi DO, McCuen EC, Joshi C, Robinson ME, Nho Y, Hannemann R, et al.Изменения цереброваскулярной реактивности у бессимптомных спортсменок, связанные с участием в футболе в старших классах. Визуализация мозга и поведение. 2017; 11 (1): 98–112. pmid: 26809358

    паровых коллекторов и отводов

    Разминка

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

    • Термический удар — когда трубопровод нагревается так быстро, что расширение не контролируется, создавая напряжения в трубопроводе и вызывая большие движения на опорах трубопровода.
    • Заполнение — Если внезапное снижение давления пара, вызванное большой внезапно приложенной нагрузкой, может привести к затягиванию котловой воды в трубопровод. Это не только плохо для работы установки, котел часто может перейти в «блокировку», и потребуется некоторое время, чтобы вернуть котел в рабочее состояние.
    • Вытекающая вода также может вызвать гидроудары в трубопроводе.

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

    Однако на более крупных предприятиях скорость прогрева трудно контролировать с помощью главного запорного клапана. Это связано с тем, что основной запорный клапан предназначен для обеспечения хорошей изоляции; у него плоское седло, что означает, что вся сила, прилагаемая при повороте маховика, действует непосредственно на седло, обеспечивая, таким образом, хорошее уплотнение под давлением. Это также означает, что клапан не охарактеризован и пропускает примерно 80% своей мощности за первые 10% своего движения.

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

    Пример регулирующего клапана, установленного после главного запорного клапана котла, показан на рисунке 3.8.4.

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

    В этот момент таймер импульсов медленно открывает регулирующий клапан в течение заранее определенного периода времени.Такое расположение также имеет то преимущество, что оно не требует рабочей силы (если котел не нагревается от холода) в течение периода прогрева котла, который может происходить в сумеречные часы.

    Тема ввода котлов в эксплуатацию регулируется директивами HSE в Великобритании.

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

    Предотвращение повышения давления в одном котле другого

    Из BS 2790, раздел 8.8.3.

    Если два или более котла подключены к общему коллектору, в дополнение к главному запорному клапану котла в паропроводе должен быть включен второй клапан, и этот клапан должен быть заблокирован в закрытом положении.Это обеспечивает лучшую защиту списанного котла, когда он изолирован от заголовка дистрибутива.

    Если в паропроводе не установлен отдельный обратный клапан, один из двух запорных клапанов должен иметь устройство невозврата.

    Целью данного раздела Британского стандарта является обеспечение безопасных условий работы при отключении котла для ремонта или проверки.

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

    Многие случаи нестабильности двухконтурных установок вызываются таким образом. Главные запорные клапаны со встроенными обратными клапанами, как правило, меньше страдают от этого явления. В качестве альтернативы подпружиненные дисковые обратные клапаны могут обеспечивать демпфирующий эффект, который имеет тенденцию уменьшать проблемы, вызванные колебаниями (рисунок 3.8.5).

    BS 2790 устанавливает, что на этой линии должен быть установлен обратный клапан вместе с главным запорным клапаном, в качестве альтернативы главный запорный клапан должен включать встроенный обратный клапан.

    Обзор балансировки нагрузки внешнего HTTP (S)

    | Google Cloud

    В этом документе представлены концепции, которые необходимо понять для настройки Внешняя балансировка нагрузки HTTP (S) Google Cloud.

    HTTP (S) Load Balancing — это глобальная нагрузка уровня 7 на основе прокси. балансировщик, который позволяет запускать и масштабировать свои услуги по всему миру за единый внешний IP-адрес. Внешняя балансировка нагрузки HTTP (S) распределяет Трафик HTTP и HTTPS на серверные ВМ, размещенные на Compute Engine и Google Kubernetes Engine (GKE).

    Внешняя балансировка нагрузки HTTP (S) реализована на Google Front Ends (GFE). GFE распределены по всему миру и работают вместе, используя глобальную сеть Google и Плоскость управления. На уровне Premium GFE предлагают балансировку нагрузки в нескольких регионах, направление трафика на ближайший работоспособный сервер, имеющий емкость и завершение HTTP (S) трафика как можно ближе к вашим пользователям. Со стандартным Уровень, балансировка нагрузки обрабатывается на региональном уровне.

    На этой странице описывается архитектура автономного внешнего балансировщика нагрузки HTTP (S).Если вы хотите опубликовать свои приложения в GKE в Интернете, мы рекомендуем использовать встроенный GKE Ingress для внешних Балансировка нагрузки HTTP (S).

    Архитектура

    Следующие ресурсы определяют внешний балансировщик нагрузки HTTP (S):

    • Правило внешней переадресации определяет внешний IP-адрес, порт, и глобальный целевой HTTP (S) прокси. Клиенты используют IP-адрес и порт для подключиться к балансировщику нагрузки.

    • Целевой HTTP (S) прокси получает запрос от клиента.В Прокси-сервер HTTP (S) оценивает запрос, используя карту URL-адресов для передачи трафика. решения о маршрутизации. Прокси-сервер также может аутентифицировать связь, используя SSL-сертификаты.

    • Для балансировки нагрузки HTTPS целевой прокси-сервер HTTPS использует SSL-сертификаты для подтверждения своей личности клиентам. Цель Прокси-сервер HTTPS поддерживает документированные количество SSL-сертификатов.

    • Прокси-сервер HTTP (S) использует карту URL для определения маршрутизации на основе атрибутов HTTP (таких как путь запроса, файлы cookie или заголовки).На основе решения о маршрутизации прокси-сервер пересылает клиентские запросы на определенные серверные службы или серверные сегменты. Карта URL-адресов может указывать дополнительные действия, такие как отправка переадресации клиентам.

    • Бэкэнд-служба или бэкэнд-сегмент распределяет запросы по работоспособному бэкэнды.

    • Один или несколько бэкэндов должны быть подключены к бэкэнд-службе или бэкэнду ведро.

    • Проверка состояния периодически контролирует готовность вашего бэкэнды.Это снижает риск того, что запросы могут быть отправлены на серверные ВМ, которые не может обслужить запрос.

    • Брандмауэр для ваших бэкэндов для приема зондов проверки работоспособности.

    Правила переадресации и адреса

    Правила экспедирования направлять трафик по IP-адресу, порту и протоколу на балансировку нагрузки конфигурация, состоящая из целевого прокси, карты URL и одного или нескольких бэкэндов Сервисы.

    Каждое правило переадресации предоставляет один IP-адрес, который можно использовать в записях DNS для вашего приложения.Балансировка нагрузки на основе DNS не требуется. Вы можете указать используемый IP-адрес или разрешить Cloud Load Balancing назначьте один для вас.

    • Правило пересылки для балансировщика нагрузки HTTP может ссылаться только на порты TCP 80 и 8080.
    • Правило пересылки для балансировщика нагрузки HTTPS может ссылаться только на TCP-порт. 443.

    Тип правила переадресации и IP-адрес, требуемый внешними балансировщиками нагрузки HTTP (S), зависит от на каком уровне сетевых служб балансировщик нагрузки в.

    • Премиум уровень:

    • Стандартный уровень:

    Полный список протоколов, поддерживаемых балансировкой нагрузки HTTP (S). правила пересылки, см. Балансировщик нагрузки Особенности.

    Целевые прокси

    Целевые прокси завершают HTTP (S) подключения от клиентов. Одно или несколько правил переадресации напрямую трафик к целевому прокси, и целевой прокси сверяется с картой URL для определить, как направлять трафик на серверные ВМ.

    Не полагайтесь на прокси-сервер для сохранения случая запроса или заголовка ответа имена.Например, заголовок ответа Server: Apache / 1.0 может появиться в клиент как сервер : Apache / 1.0 .

    Целевые типы прокси Заголовки, добавленные прокси Поддерживаются пользовательские заголовки Поддерживается Cloud Trace
    Глобальный HTTP,
    Глобальный HTTPS
    Прокси-серверы устанавливают заголовки HTTP-запроса / ответа следующим образом:
    • Через: 1.1 google (запросы и ответы)
    • X-Forwarded-Proto : [http | https] (только запросы)
    • X-Cloud-Trace-Context : / ; (только запросы)
      Содержит параметры для Cloud Trace.
    • X-Forwarded-For : [,] , (см. заголовок X-Forwarded-For) (только запросы)

    Когда балансировщик нагрузки выполняет HTTP-запрос, балансировщик нагрузки сохраняет Заголовок хоста исходного запроса.

    Балансировщик нагрузки добавляет два IP-адреса, разделенных одной запятой, в X-Forwarded-For заголовок в следующем порядке:

    • IP-адрес клиента, который подключается к балансировщику нагрузки
    • IP-адрес правила пересылки балансировщика нагрузки

    Если во входящем запросе отсутствует заголовок X-Forwarded-For , эти два IP-адреса — это полное значение заголовка:

      X-Forwarded-For: , 
      

    Если запрос включает заголовок X-Forwarded-For , балансировщик нагрузки сохраняет предоставленное значение перед , :

      X-Forwarded-For: , , 
      
    Внимание: Балансировщик нагрузки не проверяет никакие предшествующие IP-адреса. , в этом заголовке.Предыдущий IP адреса могут содержать другие символы, включая пробелы.

    При запуске программного обеспечения обратного прокси-сервера HTTP на серверных модулях балансировщика нагрузки программное обеспечение может добавить один или оба следующих IP-адреса в конец Заголовок X-Forwarded-For :

    • IP-адрес внешнего интерфейса Google (GFE), подключенного к серверной части. Эти IP-адреса находятся в диапазонах 130.211.0.0/22 ​​ и 35.191.0.0/16 .

    • IP-адрес самой серверной системы

    Таким образом, восходящий процесс после серверной части вашего балансировщика нагрузки может получить X-Forwarded-For заголовок формы:

      <существующие- значения>, ,   
      
    Примечание: Для интернет-сетей NEG запросы от балансировщика нагрузки поступают с другого IP-адреса. диапазоны.Для получения дополнительной информации см. Аутентификация. Запросы.
    Поддержка протоколов HTTP / 3 и QUIC

    HTTP / 3 — это интернет-протокол нового поколения. Он построен поверх QUIC, a протокол разработан на основе оригинального Google QUIC) ( gQUIC ) протокол. HTTP / 3 поддерживается между внешним балансировщиком нагрузки HTTP (S), Cloud CDN и клиентов.

    Конкретно:

    • IETF QUIC — это протокол транспортного уровня, который обеспечивает контроль перегрузки, аналогичный в TCP и является эквивалентом безопасности SSL / TLS для HTTP / 2, с улучшенными представление.
    • HTTP / 3 — это уровень приложения, созданный поверх IETF QUIC, и он полагается на QUIC. для обработки мультиплексирования, контроля перегрузки и повторных попыток.
    • HTTP / 3 позволяет быстрее инициировать клиентское соединение, устраняет необходимость в очереди блокирует мультиплексированные потоки и поддерживает миграцию соединения, когда изменяется IP-адрес клиента.
    • HTTP / 3 влияет на соединения между клиентами и балансировщиком нагрузки, а не соединения между балансировщиком нагрузки и его бэкэндами.
    • Соединения
    • HTTP / 3 используют протокол управления перегрузкой BBR.

    Включение HTTP / 3 на внешнем балансировщике нагрузки HTTP (S) может улучшить время загрузки веб-страницы, уменьшить повторная буферизация видео и повышение пропускной способности соединений с более высокой задержкой.

    Настройка HTTP / 3

    Вы можете явно включить поддержку HTTP / 3 для внешнего балансировщика нагрузки HTTP (S), настройка quicOverride на ВКЛЮЧИТЬ . В будущем HTTP / 3 будет включен по умолчанию для всех внешних клиентов балансировки нагрузки HTTP (S).

    Клиенты, которые не поддерживают HTTP / 3 или gQUIC, не согласовывают HTTP / 3 связь.Вам не нужно явно отключать HTTP / 3, если у вас нет выявили сломанные или более старые реализации клиента.

    Внешний балансировщик нагрузки HTTP (S) предоставляет три режима настройки HTTP / 3, как показано на следующая таблица.

    quicOverride value Поведение
    НЕТ

    HTTP / 3 и Google QUIC не рекламируются клиентам.

    Примечание. Это может измениться в будущем, и HTTP / 3 будет рекламироваться. клиентам по умолчанию.

    ВКЛЮЧИТЬ

    Клиентам рекламируется поддержка HTTP / 3 и Google QUIC. HTTP / 3 — это рекламируется с более высоким приоритетом. Клиенты, поддерживающие оба протоколам следует отдавать предпочтение HTTP / 3, а не Google QUIC.

    Примечание: TLS 0-RTT (также известный как TLS Early Data ) неявно поддерживается когда клиент согласовывает Google QUIC, но в настоящее время поддерживается при использовании HTTP / 3.

    ВЫКЛЮЧИТЬ Явно отключает рекламу HTTP / 3 и Google QUIC для клиентов.

    Чтобы явно включить (или отключить) HTTP / 3, выполните следующие действия.

    Консоль: HTTPS

    Примечание: Настройка согласования HTTP / 3 в настоящее время не поддерживается на целевом устройстве. прокси и должны быть настроены путем редактирования конфигурации балансировщика нагрузки.
    1. В консоли Google Cloud перейдите на страницу Балансировка нагрузки .

      Перейти к балансировке нагрузки

    2. Выберите внешний балансировщик нагрузки HTTP (S), который нужно изменить.

    3. Щелкните Конфигурация внешнего интерфейса .

    4. Выберите интерфейсный IP-адрес и порт, которые вы хотите отредактировать. Чтобы отредактировать HTTP / 3 конфигурации, IP-адрес и порт должны быть HTTPS (порт 443).

    Включить HTTP / 3

    1. Выберите раскрывающийся список БЫСТРОЕ согласование .
    2. Чтобы явно включить HTTP / 3 для этого интерфейса, выберите Включено .
    3. Если у вас есть несколько правил внешнего интерфейса, представляющих IPv4 и IPv6, убедитесь, что чтобы включить HTTP / 3 для каждого правила.

    Отключить HTTP / 3

    1. Выберите раскрывающийся список БЫСТРОЕ согласование .
    2. Чтобы явно отключить HTTP / 3 для этого интерфейса, выберите Отключено .
    3. Если у вас есть несколько правил внешнего интерфейса, представляющих IPv4 и IPv6, убедитесь, что для отключения HTTP / 3 для каждого правила.

    gcloud: HTTPS

    Перед запуском этой команды необходимо создать ресурс сертификата SSL для каждого сертификата.

     gcloud compute target-https-proxies создает  HTTPS_PROXY_NAME  \
         --Глобальный \
         --quic-override =  QUIC_SETTING 
     

    Замените QUIC_SETTING одним из следующих:

    • НЕТ (по умолчанию): позволяет Google контролировать согласование QUIC

      В настоящее время при выборе НЕТ QUIC отключен.К выбрав эту опцию, вы разрешаете Google автоматически включать Согласование QUIC и HTTP / 3 в будущем для этого балансировщика нагрузки. В облачной консоли этот параметр называется Автоматически. (По умолчанию) .

    • ENABLE : рекламирует HTTP / 3 и Google QUIC клиентам

    • ВЫКЛЮЧИТЬ : не рекламирует HTTP / 3 или Google QUIC клиентам

    API: HTTPS

    ЗАПИСЬ https: //www.googleapis.com / v1 / compute / projects /  PROJECT_ID  / global / targetHttpsProxies /  TARGET_PROXY_NAME  / setQuicOverride
    
    {
      "quicOverride":  QUIC_SETTING 
    }
     

    Замените QUIC_SETTING одним из следующих:

    • НЕТ (по умолчанию): позволяет Google контролировать согласование QUIC

      В настоящее время при выборе НЕТ QUIC отключен. К выбрав эту опцию, вы разрешаете Google автоматически включать Согласование QUIC и HTTP / 3 в будущем для этого балансировщика нагрузки.В облачной консоли этот параметр называется Автоматически. (По умолчанию) .

    • ENABLE : рекламирует HTTP / 3 и Google QUIC клиентам

    • ВЫКЛЮЧИТЬ : не рекламирует HTTP / 3 или Google QUIC клиентам

    Как согласовывается HTTP / 3

    Когда HTTP / 3 включен, балансировщик нагрузки объявляет об этой поддержке клиентам, позволяя клиентам, поддерживающим HTTP / 3, пытаться установить соединения HTTP / 3 с балансировщиком нагрузки HTTPS.

    • Правильно реализованные клиенты всегда возвращаются к HTTPS или HTTP / 2, когда они не удается установить соединение QUIC.
    • Клиенты, поддерживающие HTTP / 3, используют свои кэшированные предварительные знания о поддержке HTTP / 3 чтобы сэкономить ненужные поездки туда и обратно в будущем.
    • Из-за этого отката включение или отключение QUIC в балансировщике нагрузки не нарушать способность балансировщика нагрузки подключаться к клиентам.

    Поддержка объявлена ​​в Alt-Svc Заголовок ответа HTTP.Если HTTP / 3 настроен как ВКЛЮЧИТЬ на ресурс targetHttpsProxy внешнего балансировщика нагрузки HTTP (S), ответы от внешний балансировщик нагрузки HTTP (S) включает следующее значение заголовка alt-svc :

    alt-svc: h4 = ": 443"; ma = 25

    , h4-29 = ": 443"; ma = 25

    , h4-T051 = ": 443"; ma = 25

    , h4-Q050 = ": 443"; ma = 25

    , h4-Q046 = ": 443"; ma = 25

    , h4-Q043 = ": 443"; ma = 25

    , quic = ": 443"; ma = 25

    ; v = "46,43"
    Примечание. Заголовок Alt-Svc объявляет несколько версий HTTP / 3 для поддержки более ранние версии, которые используются некоторыми клиентами (например,грамм. х4-29 ), а также варианты Google QUIC ( h4-Q050 ), которые также используются. Более старые версии обоих со временем протоколы могут быть удалены из объявления Alt-Svc .

    Если HTTP / 3 был явно установлен на ВЫКЛЮЧИТЬ , ответы не включают заголовок ответа alt-svc .

    Когда у вас включен QUIC на балансировщике нагрузки HTTPS, некоторые обстоятельства могут заставьте вашего клиента вернуться к HTTPS или HTTP / 2 вместо согласования QUIC.К ним относятся следующие:

    • Когда клиент поддерживает версии HTTP / 3, несовместимые с Версии HTTP / 3, поддерживаемые балансировщиком нагрузки HTTPS.
    • Когда балансировщик нагрузки обнаруживает, что трафик UDP заблокирован или ограничен скоростью таким образом, чтобы предотвратить работу HTTP / 3 (QUIC).
    • Клиент вообще не поддерживает HTTP / 3 и поэтому не пытается согласовать соединение HTTP / 3.

    Когда соединение возвращается к HTTPS или HTTP / 2 из-за этих обстоятельств, мы не считаем это отказом балансировщика нагрузки.

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

    URL сопоставления

    URL-карт определяют шаблоны соответствия для Маршрутизация запросов к соответствующим серверным службам на основе URL. По умолчанию сервис определен для обработки любых запросов, которые не соответствуют указанному хосту правило или правило сопоставления пути. В некоторых ситуациях, например пример балансировки нагрузки в нескольких регионах, вы можете не определять никаких правил URL и полагаться только на службу по умолчанию.Для маршрутизации запросов карта URL-адресов позволяет разделить ваши трафик, исследуя компоненты URL для отправки запросов различным наборам бэкэнды.

    SSL сертификаты

    Transport Layer Security (TLS) — это протокол шифрования, используемый в SSL. сертификаты для защиты сетевых коммуникаций.

    Google Cloud использует сертификаты SSL для обеспечения конфиденциальности и безопасности клиента. к балансировщику нагрузки. Если вы используете балансировку нагрузки на основе HTTPS, вы должны установите один или несколько SSL-сертификатов на целевой HTTPS-прокси.

    Для получения дополнительной информации о сертификатах SSL см .:

    SSL-политики

    Политики

    SSL дают вам возможность для управления функциями SSL, с которыми согласовывается балансировщик нагрузки HTTPS. Клиенты HTTPS.

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

    Серверные службы и сегменты

    Внешний балансировщик нагрузки HTTP (S) может иметь серверные службы и внутренние сегменты.

    Серверные службы обеспечивают настройку информация для балансировщика нагрузки. Балансировщики нагрузки используют информацию в серверная служба для направления входящего трафика на один или несколько подключенных серверных модулей. В качестве примера, показывающего, как настроить балансировщик нагрузки с серверной частью службы и серверной части Compute Engine см. в разделе Настройка внешнего балансировщика нагрузки HTTP (S) с серверная часть Compute Engine.

    бэкэнд-сегментов направляют входящий трафик в облачное хранилище ведра. Для примера, показывающего, как добавить ведро в балансировщик нагрузки, см. Настройка балансировщика нагрузки с серверной частью ведра.

    Если вы хотите настроить внешний балансировщик нагрузки HTTP (S), используя HTTP / 2 с Google Kubernetes Engine Ingress или с помощью gRPC и HTTP / 2 с Ingress, см. HTTP / 2 для балансировки нагрузки с Ingress.

    В следующей таблице указаны функции серверной части, поддерживаемые Балансировка нагрузки HTTP (S).

    Поддерживаемые серверные ВМ на серверной службе Поддерживает серверные сегменты Поддерживает Google Cloud Armor поддерживает Cloud CDN Поддерживает IAP
    Группы экземпляров Зональные NEG Интернет-сети Бессерверные NEG

    при использовании Премиум уровня

    Для получения дополнительной информации см .:

    Проверки здоровья

    Каждая внутренняя служба определяет проверку работоспособности для внутренних экземпляров.

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

    • 130.211.0.0/22 ​​
    • 35.191.0.0/16

    Внешние балансировщики нагрузки HTTP (S) используют глобальное состояние здоровья чеки.

    Для получения дополнительной информации о проверках работоспособности см .:

    Протокол к бэкэндам

    При настройке серверной службы для внешнего балансировщика нагрузки HTTP (S) вы установить протокол, который серверная служба использует для связи с серверной частью.Вы можете выбрать HTTP, HTTPS или HTTP / 2. Балансировщик нагрузки использует только протокол что вы укажете. Балансировщик нагрузки не переключается на один из другого протоколы, если он не может согласовать подключение к бэкэнду с указанный протокол.

    Если вы используете HTTP / 2, вы должны использовать TLS. HTTP / 2 без шифрования не работает поддерживается.

    Хотя это и не требуется, рекомендуется использовать проверку работоспособности, протокол соответствует протоколу серверной службы. Например, HTTP / 2 проверка работоспособности наиболее точно проверяет подключение HTTP / 2 к серверным модулям.

    Использование gRPC с приложениями Google Cloud

    gRPC — это фреймворк с открытым исходным кодом. для удаленных вызовов процедур. Он основан на стандарте HTTP / 2. Примеры использования для gRPC включают следующее:

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

    Чтобы использовать gRPC с приложениями Google Cloud, необходимо прокси-сервер сквозные запросы по HTTP / 2.Для этого с помощью внешнего балансировщика нагрузки HTTP (S):

    1. Настройте балансировщик нагрузки HTTPS.
    2. Включите HTTP / 2 в качестве протокола от балансировщика нагрузки к серверным модулям.

    Балансировщик нагрузки согласовывает HTTP / 2 с клиентами как часть подтверждения SSL путем с использованием расширения ALPN TLS.

    Балансировщик нагрузки все еще может согласовывать HTTPS с некоторыми клиентами или принимать небезопасный HTTP-запросы на внешнем балансировщике нагрузки HTTP (S), который настроен на использование HTTP / 2 между балансировщиком нагрузки и внутренними экземплярами.Эти HTTP или HTTPS запросы преобразуются балансировщиком нагрузки для проксирования запросов через HTTP / 2 к внутренним экземплярам.

    Вы должны включить TLS на своих серверах. Для получения дополнительной информации см. Шифрование из балансировщик нагрузки на серверные ВМ.

    Если вы хотите настроить внешний балансировщик нагрузки HTTP (S), используя HTTP / 2 с Google Kubernetes Engine Ingress или с помощью gRPC и HTTP / 2 с Ingress, см. HTTP / 2 для балансировки нагрузки с Ingress.

    Для получения информации об устранении неполадок с HTTP / 2 см. Устранение проблем с HTTP / 2 на сервере.

    Для получения информации об ограничениях HTTP / 2 см. Ограничения HTTP / 2.

    Правила межсетевого экрана

    Внутренние экземпляры должны разрешать подключения из следующих источников:

    • Балансировщик нагрузки Google Front End (GFE) для всех запросов, отправляемых на ваш бэкэнды
    • Зонды для проверки работоспособности

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

    • На порт назначения для каждой проверки работоспособности серверной службы.

    • Например, серверная часть группы: определяется сопоставлением между серверной частью именованный порт службы и номера портов, связанные с этим именованным портом в каждой группе экземпляров. В номера могут варьироваться в зависимости от группы экземпляров, назначенных одной и той же серверной службе.

    • для GCE_VM_IP_PORT NEG backends: к номерам портов конечные точки.

    Правила брандмауэра реализуются на уровне экземпляра ВМ, а не на Прокси GFE. Вы не можете использовать правила брандмауэра Google Cloud для предотвращения трафик от балансировщика нагрузки.Вы можете использовать Google Cloud Armor для этого.

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

    Для внешних балансировщиков нагрузки HTTP (S) в следующей таблице указаны проверка работоспособности и диапазоны источников запроса:

    Диапазон источников проверки работоспособности Диапазон источников запросов GFE
    • 130.211.0.0 / 22
    • 35.191.0.0/16
    Источник трафика GFE зависит от типа серверной части:
    • Группы экземпляров, зональные NEG ( GCE_VM_IP_PORT ) и NEG с гибридным подключением ( NON_GCP_PRIVATE_IP_PORT ):
      • 130.211.0.0/22 ​​
      • 35.191.0.0/16
    • Интернет-сети ( INTERNET_FQDN_PORT, и ИНТЕРНЕТ_IP_ПОРТ ):
      • 34.96.0.0 / 20
      • 34.127.192.0/18
    • БЕССЕРВЕРНАЯ NEG и серверные сегменты: Google производственная сеть обрабатывает маршрутизацию пакетов.
    Важно: Убедитесь, что пакеты из полной проверки работоспособности разрешены. диапазоны. Если ваше правило брандмауэра разрешает пакеты только из подмножества диапазонов, вы можете увидеть сбои проверки работоспособности, потому что балансировщик нагрузки не может общаться со своими бэкэндами.Это вызывает ответы HTTP 502.

    Исходные IP-адреса для клиентских пакетов

    Исходный IP-адрес для пакетов с точки зрения серверной части — , а не . Внешний IP-адрес Google Cloud балансировщика нагрузки. В других словами, есть два TCP-соединения:

    • Соединение 1, от исходного клиента к балансировщику нагрузки (GFE):

      • Исходный IP-адрес: исходный клиент (или внешний IP-адрес, если клиент находится за NAT или прокси-сервером прямого доступа).
      • IP-адрес назначения: IP-адрес вашего балансировщика нагрузки.
    • Подключение 2, от балансировщика нагрузки (GFE) к внутренней виртуальной машине или конечной точке:

      • IP-адрес источника: IP-адрес в одном из диапазонов, указанных в Правила межсетевого экрана.

      • IP-адрес назначения: внутренний IP-адрес внутренней виртуальной машины или контейнер в сети виртуального частного облака (VPC).

    Обратный путь

    Google Cloud использует специальные маршруты, не определенные в вашем VPC сеть для проверок работоспособности.Для получения дополнительной информации см. Пути возврата балансировщика нагрузки.

    Как работают соединения в балансировке нагрузки HTTP (S)

    Внешняя балансировка нагрузки HTTP (S) — это служба, реализованная многими прокси-серверами, называемыми Google Front Ends (GFE). Не существует только одного прокси. На премиум-уровне один и тот же глобальный внешний IP-адрес объявляется из разных точек присутствия, и трафик направляется в ближайший к клиенту GFE.

    В зависимости от того, где находятся ваши клиенты, несколько GFE могут инициировать HTTP (S) подключения к вашим бэкэндам.Пакеты, отправленные из GFE, имеют исходные IP-адреса из того же диапазона, что и проверяющие работоспособность: 35.191.0.0/16 и 130.211.0.0/22 ​​.

    Примечание: Для интернет-сетей NEG запросы от балансировщика нагрузки поступают с другого IP-адреса. диапазоны. Для получения дополнительной информации см. Аутентификация. Запросы.

    В зависимости от конфигурации серверной службы протокол, используемый каждым GFE для подключение к вашим серверным модулям может быть HTTP, HTTPS или HTTP / 2. Если HTTP или HTTPS, Версия HTTP — HTTP 1.1. HTTP keepalive включен по умолчанию, как указано в спецификация HTTP 1.1. GFE использует тайм-аут поддержки активности 600 секунд, и вы не можете это настроить. Однако вы можете настроить запрос / ответ тайм-аут, задав тайм-аут серверной службы. Для получения дополнительной информации см. таймауты и повторные попытки.

    HTTP-сообщения поддержки активности пытаются эффективно использовать один и тот же сеанс TCP; тем не мение, нет никаких гарантий. Хотя они тесно связаны между собой, HTTP keepalive и TCP idle тайм-аут — это не одно и то же.

    Количество HTTP-подключений и TCP-сеансов зависит от количества GFE подключаются, количество клиентов, подключающихся к GFE, протокол к бэкэнды, и где бэкэнды развернуты.

    Для получения дополнительной информации см. Как балансировка нагрузки HTTP (S) работает в руководстве по решениям: Оптимизация емкости приложений с глобальной нагрузкой Балансировка.

    Связь клиента с балансировщиком нагрузки

    • Клиенты могут связываться с балансировщиком нагрузки с помощью HTTP 1.1 или HTTP / 2 протокол.
    • При использовании HTTPS современные клиенты по умолчанию используют HTTP / 2. Это контролируется на клиенте , а не на балансировщике нагрузки HTTPS.
    • Вы не можете отключить HTTP / 2, изменив конфигурацию при загрузке. балансир. Однако вы можете настроить некоторые клиенты для использования HTTP 1.1. вместо HTTP / 2. Например, для curl используйте параметр --http1.1 .
    • HTTP (S) Load Balancing поддерживает ответ HTTP / 1.1 100 Continue .

    Полный список протоколов, поддерживаемых балансировкой нагрузки HTTP (S). правила пересылки, см. Балансировщик нагрузки Особенности.

    Открытые порты

    Внешние балансировщики нагрузки HTTP (S) — это балансировщики нагрузки обратного прокси. Загрузка балансировщик завершает входящие соединения, а затем открывает новые соединения из балансировщик нагрузки на серверные ВМ. Эти балансировщики нагрузки реализованы с использованием Прокси-серверы Google Front End (GFE) по всему миру.

    GFE имеют несколько открытых портов для поддержки других служб Google, работающих на та же архитектура.Чтобы увидеть список некоторых портов, которые могут быть открыты на GFE, см. Правило переадресации: Порт технические характеристики. Могут быть и другие открытые порты для других сервисов Google, работающих на GFE.

    Запуск сканирования порта на IP-адресе балансировщика нагрузки на основе GFE бесполезен с точки зрения аудита по следующим причинам:

    • Сканирование порта (например, с помощью Nmap ) обычно не ожидает пакета ответа или пакет TCP RST при выполнении зондирования TCP SYN.GFE отправят SYN-ACK пакеты в ответ на SYN-зонды для различных портов, если ваш балансировщик нагрузки использует IP-адрес уровня Premium. Однако GFE отправляют пакеты только на ваш бэкэнды в ответ на пакеты, отправленные на IP-адреса вашего балансировщика нагрузки и порт назначения, настроенный в его правиле переадресации. Пакеты отправлены на разные IP-адреса балансировщика нагрузки или IP-адрес вашего балансировщика нагрузки на порт, не настроенный в вашем правиле переадресации, не приводит к пакетам отправляется на серверную часть вашего балансировщика нагрузки.GFE реализуют функции безопасности, такие как Google Cloud Armor. Даже без Конфигурация Google Cloud Armor, инфраструктура Google и GFE обеспечивают эшелонированная защита от DDoS-атак и SYN-флуда.

    • На пакеты, отправленные на IP-адрес вашего балансировщика нагрузки, может ответить любой GFE в парке Google; однако сканирование IP-адреса балансировщика нагрузки и комбинация портов назначения опрашивает только один GFE на TCP-соединение. IP-адрес вашего балансировщика нагрузки не назначен отдельное устройство или система.Таким образом, сканирование IP-адреса нагрузки на основе GFE балансировщик не сканирует все GFE в парке Google.

    Имея это в виду, ниже приведены несколько более эффективных способов аудита безопасность ваших бэкэнд-инстансов:

    • Аудитор безопасности должен проверить конфигурацию правил пересылки для конфигурация балансировщика нагрузки. Правила пересылки определяют пункт назначения порт, для которого ваш балансировщик нагрузки принимает пакеты и пересылает их в серверные части.Для балансировщиков нагрузки на основе GFE каждое внешнее перенаправление правило может ссылаться только на один целевой TCP порт. Для внешних балансировщиков нагрузки HTTP (S), использующих TCP-порт 443, UDP-порт 443 используется, когда соединение обновлено до QUIC (HTTP / 3).

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

    Прекращение TLS

    Балансировщик нагрузки HTTPS завершает TLS в местах, которые распределены глобально, чтобы минимизировать задержку между клиентами и нагрузкой балансир. Если вам требуется географический контроль над тем, где завершается TLS, вы следует использовать Google Cloud Балансировка сетевой нагрузки вместо этого, и прекратить TLS на серверных ВМ, расположенных в регионах, подходящих для вашего потребности.

    Таймауты и повторные попытки

    HTTP (S) Load Balancing имеет два разных типа тайм-аутов:

    • Настраиваемый тайм-аут серверной службы HTTP , который представляет время, в течение которого балансировщик нагрузки ожидает, пока серверная часть не вернет полный ответ HTTP.Значение по умолчанию для тайм-аута серверной службы — 30 секунд. Полный диапазон разрешенных значений тайм-аута: 1-2 147 483 647 секунд.

      Рассмотрите возможность увеличения этого тайм-аута в любом из следующих случаев:

      • Вы ожидаете, что серверная часть будет дольше возвращать ответы HTTP.
      • Вы видите ответ HTTP 408 с jsonPayload.statusDetail client_timed_out .
      • Соединение обновлено до WebSocket.

    Например, практическое значение тайм-аута для внешних балансировщиков нагрузки HTTP (S) равно 1 день (86400 секунд). Обратите внимание, что такие события, как перезапуск GFE, могут вызвать сеансы завершаются раньше этого тайм-аута.

    Для трафика WebSocket, отправляемого через балансировщик нагрузки, таймаут серверной службы интерпретируется как максимальная сумма времени, в течение которого соединение WebSocket может оставаться открытым, независимо от того, бездействует оно или нет. Для получения дополнительной информации см. Настройки серверной службы.

    Примечание. Тайм-аут серверной службы не является тайм-аутом простоя HTTP (поддержки активности). Это возможно, что ввод и вывод (IO) из серверной части заблокированы из-за медленный клиент (например, браузер с медленным соединением). Это время ожидания не засчитывается по таймауту серверной службы.
    • Тайм-аут сеанса TCP , значение которого фиксировано и составляет 10 минут (600 секунд). Этот тайм-аут сеанса иногда называют тайм-аутом поддержки активности или простоя, и его значение не может быть изменено путем изменения серверной службы.Вы должны настройте программное обеспечение веб-сервера, используемое вашими бэкэндами, так, чтобы его поддержка активности таймаут превышает 600 секунд, чтобы предотвратить закрытие соединений преждевременно серверной частью. Этот тайм-аут не применяется к WebSockets.

    В этой таблице показаны изменения, необходимые для изменения тайм-аутов поддержки активности для общее программное обеспечение веб-сервера:

    Балансировщик нагрузки повторяет неудачные запросы GET при определенных обстоятельствах, например, когда истекло время ожидания серверной службы.Не удалось повторить попытку POST запросы. Повторные попытки ограничены двумя попытками. Только повторные запросы создать одну запись в журнале для окончательного ответа.

    GFE не пытается повторить попытку, если более 80% внутренних экземпляров нездоровый. Если в группе есть один серверный экземпляр и соединение сбой этого внутреннего экземпляра, процент неработоспособных внутренних экземпляров составляет 100%, поэтому GFE не будет повторять запрос. Для получения дополнительной информации см. Ведение журнала и мониторинг балансировки нагрузки HTTP (S).

    Протокол WebSocket поддерживается Ingress.

    Обработка незаконных запросов и ответов

    Внешний балансировщик нагрузки HTTP (S) блокирует как клиентские запросы, так и ответы серверной части от достичь серверной части или клиента, соответственно, по ряду причин. Некоторые причины строго для соответствия HTTP / 1.1, а другие — во избежание неожиданных данные, передаваемые на серверные ВМ или от них. Ни одну из проверок нельзя отключить.

    Балансировщик нагрузки блокирует следующее для HTTP / 1.1 соответствие:

    • Не удалось проанализировать первую строку запроса.
    • В заголовке отсутствует разделитель : .
    • Заголовки или первая строка содержат недопустимые символы.
    • Длина содержимого не является допустимым числом, или существует несколько заголовки длины содержимого.
    • Имеется несколько ключей кодирования передачи или есть нераспознанные передавать значения кодировки.
    • Тело без фрагментов и длина содержимого не указана.
    • Куски тела невозможно разобрать.Это единственный случай, когда некоторые данные достигает серверной части. Балансировщик нагрузки закрывает соединения с клиентом и бэкэнд, когда он получает неразборчивый кусок.

    Балансировщик нагрузки блокирует запрос, если выполняется одно из следующих условий:

    • Общий размер заголовков запроса и URL-адреса запроса превышает предел максимального запроса размер заголовка для внешней балансировки нагрузки HTTP (S).
    • Метод запроса не разрешает тело, но запрос имеет его.
    • Запрос содержит заголовок Upgrade , а заголовок Upgrade не используется для включения соединений WebSocket.
    • Версия HTTP неизвестна.

    Балансировщик нагрузки блокирует ответ серверной части, если выполняется одно из следующих правда:

    • Общий размер заголовков ответа превышает предел максимального ответа размер заголовка для внешней балансировки нагрузки HTTP (S).
    • Версия HTTP неизвестна.

    Распределение трафика

    Когда вы добавляете группу внутренних экземпляров или NEG в серверную службу, вы укажите режим балансировки , который определяет метод измерения внутренней нагрузки и целевая мощность.Внешняя балансировка нагрузки HTTP (S) поддерживает две балансировки режимы:

    • RATE , например, для групп или NEG, является целевым максимальным количеством запросов (запросов) в секунду (RPS, QPS). Целевой максимальный RPS / QPS может быть превышено, если все серверные ВМ работают на полную или превышающую мощность.

    • ИСПОЛЬЗОВАНИЕ — это внутреннее использование виртуальных машин в группе экземпляров.

    Прежде чем интерфейс Google (GFE) отправит запросы в серверные экземпляры, GFE оценивает, какие серверные экземпляры могут принимать запросы.Этот оценка мощности производится заранее, а не одновременно с запросами. прибытие. GFE периодически получают информацию о доступной емкости и соответствующим образом распределять входящие запросы.

    Что означает емкость , частично зависит от режима балансировки. Для СТАВКА режиме, это относительно просто: GFE точно определяет, сколько запросов он может назначить в секунду. UTILIZATION балансировка нагрузки более сложна: нагрузка балансировщик проверяет текущее использование экземпляров, а затем оценивает запрос нагрузка, которую может обработать каждый экземпляр.Эта оценка меняется со временем по мере того, как использование и модели трафика меняются.

    Оба фактора — оценка мощности и упреждающее назначение — влияют на распределение по экземплярам. Таким образом, Cloud Load Balancing ведет себя в отличие от простого балансировщика нагрузки с циклическим перебором, который распределяет запросы ровно 50:50 между двумя экземплярами. Вместо этого используется балансировка нагрузки Google Cloud. пытается оптимизировать выбор экземпляра серверной части для каждого запроса.

    Для получения дополнительной информации см. Пробки. распределение.

    Дополнительные сведения о режимах балансировки см. В разделе «Балансировка». режим.

    Как распределяются запросы

    Распределение трафика: регионально или глобально, зависит от того, уровень сетевых служб уже используется.

    Для премиум-уровня:

    • Google объявляет IP-адрес вашего балансировщика нагрузки со всех точек присутствие по всему миру. Каждый IP-адрес балансировщика нагрузки является глобальным произвольным.
    • Если вы настраиваете серверную службу с серверной частью в нескольких регионах, Google Внешние интерфейсы (GFE) пытаются направить запросы к работоспособному внутреннему экземпляру группы или NEG в регионе, ближайшем к пользователю.Подробная информация о процессе задокументировано на этой странице.

    Для стандартного уровня:

    • Google рекламирует IP-адрес вашего балансировщика нагрузки из точек присутствия связанный с регионом правила переадресации. Балансировщик нагрузки использует региональный внешний IP-адрес.

    • Вы можете настроить серверные ВМ в том же регионе, что и правило переадресации. Процесс, описанный здесь, по-прежнему применяется, но GFE направляют запросы только на здоровые серверные ВМ в этом одном регионе.

    Процесс распределения запроса:

    Режим балансировки и выбор цели определяют бэкенд заполненность с точки зрения каждой зональной GCE_VM_IP_PORT NEG, зональной группы экземпляров, или зона региональной группы экземпляров. Затем выполняется распределение внутри зоны. с последовательным хешированием.

    Балансировщик нагрузки использует следующий процесс:

    1. Внешний IP-адрес правила переадресации объявляется граничными маршрутизаторами на границы сети Google.В каждом объявлении указывается следующий переход к Система балансировки нагрузки уровня 3/4 (Maglev) максимально приближена к пользователю.
    2. Системы Maglev проверяют исходный IP-адрес входящего пакета. Они направить входящий запрос в системы Maglev, которые гео-IP Google системы определяют как можно ближе к пользователю.
    3. Системы Maglev направляют трафик во внешний интерфейс Google (GFE) первого уровня. GFE первого уровня завершает TLS, если требуется, а затем направляет трафик на GFE второго уровня в соответствии с этим процессом:
      1. Карта URL-адресов выбирает внутреннюю службу.
      2. Если серверная служба использует группу экземпляров или GCE_VM_IP_PORT Серверы NEG, GFE первого уровня предпочитают GFE второго уровня, которые расположен в или рядом с регионом, который содержит группу экземпляров или NEG.
      3. Для серверных сегментов и серверных служб с гибридными NEG, без сервера NEG и интернет-NEG, GFE первого уровня выбирают GFE второго уровня в подмножество регионов, так что время приема-передачи между двумя GFE равно сведены к минимуму.

        Предпочтение GFE второго уровня не является гарантией и может динамически изменяться в зависимости от состояния и обслуживания сети Google.

        GFE второго уровня осведомлены о статусе проверки работоспособности и фактическом внутреннем интерфейсе использование емкости.

    4. GFE второго уровня направляет запросы к серверным модулям в зонах в пределах своего область.
    5. Для уровня Premium иногда GFE второго уровня отправляют запросы на серверные ВМ. в зонах разных регионов.Такое поведение называется перетекание .
    6. Перелива регулируется двумя принципами:

    • Перетекание возможно, когда все серверные ВМ известны второму уровню GFE работают на пределе своих возможностей или работают нездорово.
    • GFE второго уровня содержит информацию для здорового, доступного бэкенды в зонах другого региона.

    GFE второго уровня обычно конфигурируются для обслуживания подмножества серверные локации.

    Переливное поведение не исчерпывает все возможные Google Cloud зоны. Если вам нужно направить трафик от бэкендов в определенном зоны или всего региона, необходимо установить емкость масштабатора до нуля. Настройка серверных ВМ на отказ проверки работоспособности не гарантирует, что GFE второго уровня распространяется на серверные ВМ в зонах другого региона.

  • При распределении запросов на бэкенды GFE работают в зональном уровень.

    При небольшом количестве запросов в секунду GFE второго уровня иногда предпочитать одну зону в регионе другим зонам. Это предпочтение нормально и ожидаемо. Распределение по зонам в регионе не станет равным, пока балансировщик нагрузки не получит больше запросов в секунду.

  • Сходство сеанса

    Сходство сеанса обеспечивает максимальную попытку отправить запросы от конкретного клиента к один и тот же бэкэнд, пока он исправен и имеет емкость, согласно настроенному режиму балансировки.

    Google Cloud HTTP (S) Load Balancing предлагает три типа сеанса близость:

    • НЕТ. Сходство сеанса не установлено для балансировщика нагрузки.
    • Сходство IP-адреса клиента отправляет запросы с одного и того же IP-адреса клиента на тот же сервер.
    • Сродство сгенерированных файлов cookie устанавливает клиентский cookie при первом запросе, а затем отправляет запросы с этим файлом cookie на тот же сервер.

    При использовании привязки сеанса мы рекомендуем режим балансировки RATE , а не чем ИСПОЛЬЗОВАНИЕ .Сходство сеанса лучше всего работает, если вы установите режим балансировки запросам в секунду (RPS).

    Поддержка WebSocket

    Балансировщики нагрузки

    Google Cloud на основе HTTP (S) имеют встроенную поддержку Протокол WebSocket, когда вы используете HTTP или HTTPS в качестве протокола для бэкэнда. Балансировщику нагрузки не требуется настройка для прокси-сервера WebSocket. соединения.

    Примечание. HTTP / 2 не поддерживается.

    Протокол WebSocket обеспечивает полнодуплексный канал связи между клиенты и серверы.Запрос HTTP (S) инициирует канал. Для подробную информацию о протоколе см. в RFC 6455.

    Когда балансировщик нагрузки распознает запрос WebSocket Upgrade от клиент HTTP (S), за которым следует успешный ответ Upgrade от серверной части например, балансировщик нагрузки проксирует двунаправленный трафик для продолжительность текущего подключения. Если серверный экземпляр не возвращает При успешном ответе Upgrade балансировщик нагрузки закрывает соединение.

    Тайм-аут для соединения WebSocket зависит от настраиваемого бэкэнда таймаут службы балансировщика нагрузки, который по умолчанию составляет 30 секунд. Этот тайм-аут применяется к соединениям WebSocket независимо от того, находятся ли они в использовать.

    Сходство сеанса для WebSockets работает так же, как и для любого другого запроса. Для получения информации см. Сеанс. близость.

    HTTP / 2 макс. Одновременных потока

    HTTP / 2 SETTINGS_MAX_CONCURRENT_STREAMS параметр описывает максимальное количество потоков, которые принимает конечная точка, инициирован партнером.Значение, объявленное клиентом HTTP / 2 для Балансировщик нагрузки Google Cloud фактически бессмыслен, потому что нагрузка балансировщик не инициирует потоки клиенту.

    В случаях, когда балансировщик нагрузки использует HTTP / 2 для связи с сервером которая работает на виртуальной машине, балансировщик нагрузки учитывает SETTINGS_MAX_CONCURRENT_STREAMS значение, объявленное сервером. Если значение объявляется ноль, балансировщик нагрузки не может пересылать запросы на сервер, и это может привести к ошибкам.

    Ограничения HTTP / 2

    • HTTP / 2 между балансировщиком нагрузки и экземпляром может потребовать значительно больше TCP-подключений к экземпляру, чем HTTP (S). Пул соединений, оптимизация, которая уменьшает количество этих соединений с HTTP (S), является в настоящее время недоступно с HTTP / 2.
    • HTTP / 2 между балансировщиком нагрузки и серверной частью не поддерживает запуск Протокол WebSocket через один поток соединения HTTP / 2 (RFC 8441).
    • HTTP / 2 между подсистемой балансировки нагрузки и серверной частью не поддерживает принудительную передачу данных на сервер.
    • частота ошибок gRPC и объем запросов не отображаются в Google Cloud API или Cloud Console. Если конечная точка gRPC возвращает ошибку, журналы балансировщика нагрузки и данные мониторинга сообщают HTTP «OK 200» код ответа.

    Что дальше

    .

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *