The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Представлен SSH3, вариант протокола SSH, использующий HTTP/3"
Отправлено Аноним, 18-Дек-23 11:37 
> Это ваши домыслы.
> Я работал в провайдере и близок к кухням других провайдеров и никто
> тамим не промышлял.
> Если только сотовики и ещё некоторые отбитые на голову.

А вы там точно сетью занимались? Просто каждый провайдер меняет входящую пометку QoS на свою собственную.
- PCP находится в заголовке dot1q.
- DSCP находится в заголовке IP
Провайдер не принимает VLAN-тегированный трафик, если с ним явно не договорились. И не сохранит никакую пометку PCP внутри VLAN, если у вас только не строится интерконнект между вашими локациями по L1 или L2VPN. Опять же, это отдельные услуги. То же самое с DSCP, провайдер вырежет вашу пометку и вставит на ее место свою. Это вообще базовый принцип работы QoS.

QoS работает и применяется локально в одном сегменте, а на граничных коммутаторах и роутерах переписывается. Вы же не думаете, что если вы проставите DSCP 46 (Expedited Forwarding), провайдер вам поверит и будет трактовать ваш трафик как высокоприоритетный и завернет его поближе к VoIP-очередям. То же самое с Ethernet Flow Control. Все типы Pause-фреймов будут вырезаны.

> Так не бывает, СС всегда есть на передающей стороне.

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

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

Еще раз повторяю - нет! Есть СС, которые применяются на всей цепочке. DCTCP в Lossless-сети - это главный из них и самый популярный.
Вот обычные ECN, почитайте: https://www.juniper.net/documentation/us/en/software/junos/c...
Вот DCQCN: https://www.juniper.net/documentation/us/en/software/junos/t...

Сочетание DCB и QCN позволяет вам одновременно иметь:
- максимально возможную пропускную способность потока
- минимальные задержки
- низкую нагрузку на CPU на источнике и назначении.
Это происходит, потому что у вас потери пакетов возможны только в случае реальной перегрузки, а не потому что очередной алгоритм СС внутри протокола TCP таким образом окна себе меряет, щупая промежуточную сеть и её пропускную способность. Есть также 2 недостатка:
- оно работает только в рамках собственного сегмента сети, потому что QoS, который вы настроили, вы настроили для себя и провайдер вашей пометке не поверит
- оно требует настроить DCB и QCN на сети, и это не так-то сложно... думал я, пока не пообщался тут и не осознал, что, видимо, сложно. Люди не понимают ни что это, ни как это работает.

Такие вещи не в интернет-провайдерах делают, а в облачных провайдерах, где людям сервисы предоставляют. Внутренний TCP работает одним способом, а внешний, который пойдет в публичную сеть другим способом. На границе ставятся балансировщики нагрузки / прокси, которые терминируют TCP-сессии при переходе из внутреннего сегмента в транзитную сеть. Если этих проксей много, и транзитная сеть большая, из этих проксей строят то что в народе называют CDN. Это как бы норма, но это внешний сегмент. Неужели вы правда считаете, что нетфликс использует RACK-TLP для внутреннего обмена данными, для сетей хранения и всего такого? Ну так же не бывает...

Также я бы хотел напомнить, что обработка Selective ACK требует существенно больше ресурсов CPU отправителя нежели, когда их нет. Полагаться на них так сильно, как это делает RACK-TLP я бы постеснялся с точки зрения производительности того сервиса, который порождает поток. RACK-TLP хорош, когда есть CDN, которая терминировала сессии и её прокси сервера полностью взяли на себя удар по вопросам шифрования TLS. Вот тогда туда и SACK можно привесить. Главное чтобы оно не вредило сервисам бекенда.

Мой вам совет, купите себе дешевый Juniper и пару сетевок Mellanox и поиграйте со всем этим. На FreeBSD и на Windows это всё прекрасно работает, настраивается играючи (я про DCTCP). Только вам нужно будет настроить QoS на коммутаторе. Уверен у вас получится. =)

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру