Comments 49
Согласен, что электронная почта сильно устарела, но пока меня просят вручную вносить домены контрагентов в белые списки, так как они не способны сами нормально настроить сервера, переход на более сложные системы, чем связка PTR+SPF+DKIM+DMARC видится мне туманным...
Смысл-то как раз в том, чтобы перейти на более простые системы, в которых системные проблемы того же SMTP решены архитектурно и не требуют сложного администрирования.
Впрочем, SMTP скорее нужно просто забыть и для более-менее официального обмена перейти на государственный мессенджер с аутентификацией отправителя и получателя.
Возможно, на замену SMTP придут проекты вроде mnm is not mail, который кратко упомянули в статье. Но опять же непонятно, что будет с массовым внедрением.
К сожалению, прошло то время, когда внедрение чего-то происходило на энтузиазме комьюнити, особенно если речь идет о технологиях, которые для адекватного использования должны покрывать абсолютное большинство пользователей.
Сейчас для массового использования необходима некая политическая воля. Было бы хорошо вообще на уровне ООН :)
К IPv6 претензии не совсем понятны, если расширить заголовки IPv4 на любое количество, даже на 1 бит, то мы опять получаем новый протокол требующий замены оборудования(из-за аппаратной поддержки, где вопрос не решить прошивкой). Судить же, достигнута ли цель IPv6 заменить IPv4 по мне так рано, это будет возможно только когда кончатся адреса в IPv4. Пока что любой другой протокол будет иметь схожие проблемы. Но даже без этого мы имеем статистику, в районе 40% пользователей в гугл ходят по новому протоколу и эта цифра растет приблизительно на 5% в год. Очень вероятно, что через 12 лет минимум и 20 лет максимум про ipv4 мы будем вспоминать только в старых локальных сетях.
Думаю, что на IPv4 можно сидеть еще долго – есть NAT, при этом адреса регулярно высвобождаются и их перепродают. Но возможно, ускорят миграцию инициативы регуляторов – некоторые уже требуют переходить на IPv6.
Проблема NAT в том что два узла находящихся за NAT не могут без костылей соединится друг с другом. А это сейчас как никогда актуально так как уже достаточно востребована видео связь. В условиях когда видеопотоку надо приодолеть 2 или даже 4 NAT (в вашем WiFi роутере он скорей всего тоже включён) связь идёт не напрямую а через сервер который имеет внешний IP. Этим сервером кто-то владеет и обслуживает и у него не бесконечные ресурсы чтобы обслуживать видеопотоки всего интернета и в какой то момент он начинает лагать.
В то же время есть отличная технология 6to4 которая позволяет провайдеру или его пользователям подключить IPv6 используя внешний IPv4 провайдера. IPv4 адрес провайдера становится частью адреса IPv6 подсети и указывает на какой узел сети IPv4 надо слать ответный пакет если он покидает IPv6 сеть.
> Проблема NAT в том что два узла находящихся за NAT
> не могут без костылей соединится друг с другом.
> А это сейчас как никогда актуально так как уже
> достаточно востребована видео связь.
> В условиях когда видеопотоку надо приодолеть
> 2 или даже 4 NAT
Это проблема не только NAT.
Сейчас и в IPv4 не все могут друг с другом соединятья даже внутри одной сети без NAT.
Например, браузеры друг к другу подключиться до сих пор не могут. И это на третьем-то десятке лет их развития.
Придумали, было, для этого какую-то технологию WebRTC, но радости-то с неё мало. В ней всё-равно браузеры напрямую друг к другу не могут подключиться - им приходится для этого использовать всё-равно промежуточные серверы. И в чём тогда радость таких соединений, если находящимя даже в одной сети без NAT браузерам всё-равно для соединения друг с другом требуются дополнительные прокси-подобные сервера...
А ведь для прямого подключения одного браузера к другому всего-то в них надо наваять примерно пару основных дел:
Дело 1:
Браузер_1 у себя джаваскриптом запускает сервер командой типа:
listen(port, callback);
Дело 2:
Браузер_2 у себя джаваскриптом подключается к этому серверу командой типа:
connect(ip, callback);
А сейчас все эти придумки с WebRTC напоминают историю про то, как в старых книжках 90-х годов по программированию в Windows для создания всего лишь пустого окна надо было прочитать страниц 5 текста о том, как это окно создать. Только через некоторое время вместо всех этих долгих страниц команд создания окна наконец-то придумали для открытия окна простые команды типа msgbox title, text и им подобные, не менее простые. Может быть такой же эволюционный путь пройдёт и система соединения браузеров друг с другом.
Лет 7-8 назад читал, что Китай хочет пойти другим путём и прилумали ipv9, но за это время я больше о этим протоколе не слышал. Пользую ipv6 с 2012 года и наблюдаю за его развитием - трудности есть как с софтом, так и с человеческим фактором. Новые железки поддерживают ipv6, старые рано или поздно заменятся. Провайдеры так же постепенно внедряют поддержку ipv6. Из замеченых мной плюсов:
бесплатный белый ipv6 для любого устройства локальной сети (это не отменяет необходимость фаервола и других систем/мер безопасности)
в эпоху тотальной блокировки/замедления сайтов регуляторами - ресурсы в ipv6 пока доступны без ограничений
более прямая и гибкая маршрутизация - при замере скорости из Питера в Австралию ipv6 оказался почти в 2 раза быстрее (там очень низкая скорость была, порядка 4 мегабит по ipv4 против 8 по ipv6). В более цивилизованых Европейских странах ipv6 незначительно медленнее, но порядок скоростей выше и возможно трафик измерителей скорости попадает под qos/cos правила. У меня сомнения, что во Франции и Англии каналы связи ограничены 30 мегабитами, в то время, как до Хельсинки я получил порядка 400мегабит на отдачу и 800 на приём.
Лёгкость автонастройки - у меня иногда на клиентских машинах отваливается dhcp клиент, но при этом ipv6 полнофункционален. У меня настроены 2 шлюза в ipv6 через разных провайдеров и выбор маршрута происходит автоматически к примеру Google идёт через Голландию, а Yandex через Швецию :) И отсюда ещё одна плюшка - англоязычная реклама в YouTube меньше бесит, чем Русская :)))
из сложностей - людям непривычна цифовая запись адреса ipv6, но это дело привычки и решается с помощью dns.
Какая ирония.
Так я скажу прямо: чтобы приходилось поменьше чинить интернет, его нужно поменьше ломать. Поменьше строить своими руками решений, позволяющих «блокировать VPN-протоколы и Telegram».
Рынок не сопротивлялся, когда государство заставило ставить всех СОРМ, потом СОРМ-2, затем СОРМ-3, когда придумало блокировки сайтов, когда устанавливало всем «Ревизоры» — а это большие затраты на установку и экскплуатацию.
А вы не подскажете, кто такой этот рынок, который должен был, но «не сопротивлялся» (из текста по вашей ссылке)? Кто конкретно подразумевается? Я всегда думал, что такие вопросы — общегражданского характера, и недоумеваю, причём тут рынок.
Один чувак, который при совке был, типа, крупный администратор и знал систему изнутри, рассказывал, что была такая чума — эксплуатировать заводы в хвост и в гриву. Они, помимо того, для чего, собственно, заводы и нужны, занимались примерно всем: от строительства жилфонда (!!!) и собственных больниц до организации досуга (не того). И не корпоративы проводить, как сейчас, а строить и обслуживать целую загородную «турбазу» (как это тогда называлось). Просто чтобы организовать что-то хорошее, нужен хороший организатор, а зачем их искать, если есть директор завода, который худо-бедно наладил выпуск продукции? Пусть как Рабинович — ложится и выполняет за всех план. Директора тогда в разделе прибылей официально не участвовали, а возможности для воровства, по сравнению с нынешними, были сильно ограничены, поэтому к соцнагрузке они относились как собака к консервной банке, привязанной к хвосту: нравится не очень, а куда деваться.
Вот мне текст чем-то напомнил этот рассказ. Заменяем заводы на «рынок», и пусть он, значит, борется против власти и против цензуры. Пока граждане сидят по своим диванам.
бездействие многих участников рынка вызывает большое удивление
Удивительно, правда? Так и представляю, как мой провайдер кабельного Интернета в 2005 (тогда ещё их можно было назвать «участниками») вместо бездействия пошёл на баррикады!
И правда позорище. Силами таких вот выродков связность сети и разрушается. Спасибо что сообщили - своих героев страна должна знать.
Позвольте высказаться... ИМХО для того чтобы "починить" Интернет нужна машина времени.
Современный интернет возник эволюционно и он просто вырос. Перерос стадию достижения популярности и перешел в фазу "монетизации популярности". Крупные игроки вытесняют мелких и уже нельзя сделать стартап в гараже и заработать лярд, а только продать его за условный лям и долю в прибыли. Так что поиск технических средство почему Фейсбук был возможен тогда, а не сейчас - бесперспективен. Дело в экономике...
Деньги, как универсальный регулятор, ведут систему не туда. Она уничтожает Интернет, а не протоколы.
Вроде бы очень простая парадигма: Обмен телеграммами, заполнил адресную часть, вписал передаваемые данные и отправил.
Вот какие тут могут быть подводные камни?
Камень номер один: Пока передается пакет, интерфейс занят для всех остальных, что приводит к большим задержкам на коммутацию (сравните с теоретической задержкой на коммутацию синхронной сети).
Костыль: Ограничили размер пакета (до 53 байт в АТМ) или ввели спец символы для служебных данных (SpaceWire) и другое. Увеличение размера буферного ОЗУ.
Камень номер два: Заголовок нельзя сделать большим, это сильно влияет на КПД процесса передачи (Время заполнения, отношение размера заголовка к размеру полезных данных). В настоящее время до 20% производительности вычислительной системы расходуется на работу с пакетным трафиком. Появились проблемы с нехватной числа IP адресов. Выполнять создание заголовка необходимо каждый раз, даже если передать требуется одно слово, что катастрофически снижает производительность для интерактивных приложений.
Костыль: Объявить «фичей» и смириться — решения проблемы нет.
Камень номер 3: На самом нижнем уровне не прописаны механизмы структурирования передаваемых данных и приходится фиксировать (создавать стандарты) различных протоколов, как итог около 700 различных протоколов. Часть из протоколов обязаны поддерживать коммутаторы, что делает их дорогими и медленными (сложность анализа протокола).
Костыль: Объявить «фичей» и смириться — решения проблемы нет.
Камень номер 4: Пакетная сеть по своей природе является асинхронной, а значит всегда есть вероятность, что сумма информационных потоков предназначенных для конкретного выхода будет больше его физической пропускной способности. Увеличение размера буфера памяти никак не поможет. Для больших скоростей передачи данных и вообще невозможна буферизация, попробуйте буферизовать суммарный поток в 100Тбит в секунду (посчитайте параметры требуемого ОЗУ). Пакетная сеть теряет стабильность после загрузки больше 25% от суммарной производительности и начинаются потери.
Костыль: Хорошего решения нет. В рамках решения проблемы в протокол введено постепенное наращивание скорости, что эквивалентно ограничению реальной пропускной способности сети (заканчились данные для передачи, а максимальная скорость еще не достигнута). Была предпринята попытка решить проблему: Программно определяемая сеть (SDN), но похоже технология тоже «мертворожденная».
Это самые простые «камушки» и теперь вопрос:
Может легче пристрелить эту «лошадь», чем обвешивать ее бесконечным набором «костылей»?
а если не пакетами то чем?
Мой вариант решения проблемы: habr.com/ru/post/512652
За год есть какой-то прогресс, кроме тероретизирований?
Ну хоть какие-то документы/исследования?
После беглого прочтения статьи и комметариев кажется, что вы «переизобретаете» TDM, который давно используется, сегодня даже на терабитных скоростях, но имеет свою кучу недостатков, начиная со сложности определения тайм-слотов, заканчивая маршрутизацией т.к. за пределами PSTN и тому подобного SONET суметь правильно и вовремя выделить нужное из условных 4х400G потоков данных уже само по себе нетривиальное занятие.
И вопросы таблиц маршрутизации никуда чудестным образом из TDM сети не исчезают, а, наоборот, проявляются еще сильнее, т.к. знать о одном уровне соседей и метриках уже недостаточно для (оптимальной) маршрутизации, значит должны быть routing ноды, которые видят всю(или часть) сеть. Как у вас с этим?
Ну и ваш, так сказать, презерватив — это не теория, а гипотеза.
После беглого прочтения статьи и комметариев кажется, что вы «переизобретаете» TDM
Правильнее сказать, что это сильно продвинутая версия TDM. Удалось решить основные проблемы, которые не позволяли оптимально применять TDM в вычислительной технике:
1. Произвольная скорость канала.
2. Передача данных без предварительного создания канала (можно передавать сразу).
3. Утилизация всего зарезервированной, но в данный момент не используемой пропускной способности канала.
суметь правильно и вовремя выделить нужное из условных 4х400G
Согласен чуть более сложная структура данных, но современные полупроводниковые технологии данного «усложнения» (с точки зрения чиса транзисторов) даже не почуствуют. Да и только кажется, что это сложно. Самое главное, данная сеть черезвычайно хорошо конвейеризуется, те за счет коротких цепочек логики от одного выхода триггера, до входа другого, позволяет получать большие тактовые частоты коммутатора (время коммутации канала стремится ко времени работы FIFO соединяющего два клоковых домена).
И по поводу скоростей, речь идет про десятки и сотни Тбит в секунду с временем коммутации в единицы нс при степени утилизации физического канала более 90%. Может ли пакетная коммутация похвастаться такими уровнями?
И вопросы таблиц маршрутизации
Нет таблиц маршрутизаии, при создании канала адресная информация в каждом коммутаторе расходуется для выбора номера исходящего физического интерфейса. Адресация относительная.
это не теория, а гипотеза
Статья содержит достаточную информацию, для постановки ТЗ исследовательского проекта (например на основе FPGA), все алгоритмы описаны в достаточной степени, то что не конкретизировано не является принципиальным и может быть реализовано в произвольном варианте.
В настоящее время идут переговоры с представителями фирмы, являющейся одним из мировых лидеров в коммуникационном оборудовании. Данную компанию заинтересовал проект распределенной памяти на основе Синхронной иерархии (https://habr.com/ru/post/577810/ ).
Вот да, SONET и прочее красиво только на бумаге, в реальности тоже самое получается - только в профиль, но дороже
Хоронили плезиосинхронные сети, порвали 7 баянов. Спасибо, но нет. Старые связисты, с которых песок сыпется, проиграли по всем фронтам (включая передачу голоса). Пакетная передача данных позволяет дёшево сделать быстро.
Вы предлагаете сделать за нереально дороже чуть-чуть лучше. А ethernet вместо этого накинет ещё десяток 25G линков и всё станет сильно лучше, чем накручивание поверх E1 ещё одного плезиосинхронного анахронизма.
По стоимости ничем не отличается от пакетной сети, при этом качественно решает проблему цифровой связи (все заморочки с точной синхронизацией и протоколами ее соблюдения решены). Структура построения канала достаточно простая и первые два уровня OSI и вообще взяты у современных сетей передачи данных.
А ethernet вместо этого накинет ещё десяток 25G линков
Вот как раз это и невозможно, после начнутся проблемы с буферизацие данных (скорость и размер буферного ОЗУ для выравнивания мгновенно требуемой и реально предоставляемой скоростью передачи данных). Центральный процессор, банально «захлебнется» в трафике, ведь каждый пакет нужно обработать (создать и проанализировать заголовой). Нет «накинуть» то можно, но так не блещущий коэффициент использования будет уже совсем печальным.
Предлагаю возможность «накинуть» еще не десяток а тысячи 25G линков и при этом гарантировать время коммутации на уровне единиц нс.
Что по времени коммутации может предложить пакетная коммутация — сотни нс даже для самой быстрой реализации (InfiniBand). Такая задержка не позволяет построить действительно конкурентноспособную распределенную память, на передачу пакета уходит больше времени чем на чтение из локальной оператичной памяти.
В предлагаемой (Синхроннная иерархия) сети время коммутации единицы нс, стабильно малое время доставки (сопоставимо с временем распространения сигнала в кабелях связи), теоретический максимум.
Хоронили плезиосинхронные сети, порвали 7 баянов
Это поверхностный взгляд на проблему, недостойный инженера ))
Вы в курсе, что никто трафик черкз CPU не гонит уже лет 20 как?
Про тысячи линков. У вас ресурсов современных FPGA хватит хоть с десяток 25G-линий адекватно реализовать и связать?
Сказки — это уровень недостойный инженера.
Вы в курсе, что никто трафик черкз CPU не гонит уже лет 20 как?
никто этого никогда не делал, думаю это будет отдельный чиплет
Про тысячи линков. У вас ресурсов современных FPGA хватит хоть с десяток 25G-линий адекватно реализовать и связать?
Десяток линий это на дешевых FPGA можно сделать (там примерно стольно и есть если говорить по Xilinx)
Вот так примерно будет выглядеть процессорный интерфейс будущего: servernews.ru/1029015 (это только тесты). Есть еще видео презентации где демонстрируется печать световодов в теле печатной платы, те на печатной плете уже не будет медных проводников, только залитая оптика соединяющая отдельные микросхемы.
Сказки — это уровень недостойный инженера.
Укажите конкретное высказывание, которое не реализуемо на современном техническом уровне. Понимаю, что трудно воспринимать что то новое, но и бросать голословные утверждения нехорошо.
Stratix10 — дешевая FPGA?
Пока что бросаете высказывания вы, а вся индустрия не в курсе, кроме «одного из лидеров в коммуникационном оборудовании».
Я выбирал тестовую плату с микросхемой от Xilinx, там больше 20 интерфейсов — цена в России 300 долларов.
Насколько я понимаю все Ваша возражения строятся на предположении, что если «за границей» этого нет то и нам не нужно?
Да этот подход типичен для российской научной бюрократии, тебе не выделят гранд на исследования если, то чем ты будешь заниматься не имеет «индекса цитирования». Именно так все наши научные сследования и проводятся (гипербола).
Получают грант, потом переписывают результат из уже произведенных зарубежных работ и пишут вывод: У нас неполучилось, но и за рубежем тоже ничего не получилось )))
Прошу еще раз в чем конкретно претензия? Что не осуществимо, где в моей статье есть технически невыполнимое обещание и в чем оно технически не выполнимо?
Причём тут, вообще, «за границей»?
Вы понимаете, что уровень развития технологий сейчас таков, что ничего локально сделать не выйдет, а вы наоборот ёрничаете про несостоятельность «индексов цитирования» и грантоедство?
В вашей статье полно обещаний, которые непонят что дадут.
Можете подробнее рассказать как ваша локальная адресация будет работать в сети хоть из 100 узлов с динамической топологией, когда локально для узла Х следующие, допустим, 2 хопа есть, а потом свзязь к узлу Y оборвалась? Кто решает куда пойдет трафик? На каком основании? Я, если что, представляю как это сейчас работает в проериетарных TDM и гибкости уровня пакетной передачи там и близко нет. Поэтому всё движется в сторону IP даже в изначально PDH сетях, в окружающем мире.
Технически выполнимо всё, вопрос денег и смысла.
что ничего локально сделать не выйдет,
Даже и не пытаюсь — ищу тех у кого океан денег и они еще могут создать альянс по типу USB, PCI и прочих.
Можете подробнее рассказать как ваша локальная адресация будет работать
1. Этап создание маршрута (в данном случае адрес). Выполняется отдельной службой (сейчас называется DNS). Если нет необходимости выходить за пределы какого то устройства (например датчик в станке, он не должен выходить в сеть и подключается строго к плате управления или к ее резервной копии), то просто прописывается по умолчанию в конфигурационных данных список путей (адресов).
2. При необходимости создать канал, датчик отправляет в качестве адреса первый из имеющихся путей. Если за рассчетное время (получается вместе с адресом, поскольку оно поддается рассчету и гарантированно стабильно) нет ответа от адресата (если нет сервиса отправки ошибки у промежуточных коммутаторов), то в канал отправляется символ закрыть канал и выбирается следующий адрес из списка и так по кругу, пока не будет установлена связь.
Это самый простой сценарий.
Если происходит обрыв связи, данные не доставлены (будет известно за удвоенное время доставки), то также закрываем канал и выбираем следующий адрес.
Список адресов (путей) может быть очень обширным и для больших систем может постоянно корректироваться в процессе работы, даже без запроса от пользователя (автоматическая балансировка нагрузки)
TDM и гибкости уровня пакетной передачи
То что разработал сочетает в себе все варианты сетей передачи данных
1. Синхронный — если отправляет строго по времени по одному символу.
2. Фреймовый отправляет по времени, но не один символ а буфер целиком (максимальный размер буфера может указываться тем же DNS — у него собраны все данные о промежуточных коммутаторах)
3. Пакетный — отправляем с использованием не задействованной пропускной способности все данные из буфера в тот момент когда есть неиспользуемая пропускная способность и есть данные для передачи. Данный режим может вызывать потерю данных в данном конкретном канале, если где то будет перегружен физический канал и локальный буфер заполнен. Такой тип канала является самым оперативным и предназначен для передачи коротких сообщений (размер не больше элементарного буфера коммутатора) на расстояние где время передачи мало и есть возможность дождаться ответа, о том что данные переданы (по факту асинхронный режим).
Пример использования: Запрос на изменение памяти в распределенной памяти суперкомпьютера, время цикла первые десятки наносекунд в кубе со стороной 3 метра (1000 процессоров).
изначально PDH сетях
PDH сети сгубила заносчивость связистов, типа жрите что дают, альтернативы нет. Вот и создали альтернативу, фиговенькую, но что бы убить телефонные компании хватило. Даже авральный АТМ не спас ситуацию. Большой бюджет развращает инженера не меньше чем большая власть чиновника.
По деньгам даже дешевле чем для сравнимой по производительности пакетной системы. При этом предлагается практически не ограниченное развитие, скорости и задержки передачи на два порядка лучше про надежность вообще не говорю. Самое главное, это единый интерфейс от дверного свонка до планетарных линий связи (космос тоже). Для всех вариантов применения от бытовухи, до супер надежных промышленных систем. Данная сеть позволит создать электронное отражение нашего мира (об этом много говорят, но уровень производительности современных сетей не позволяет получить приемлемый результат)
Ближайший ко мне коммутатор с 48 25G линками имеет на борту одинокий весьма скромный зеон, у которого память имеет пропускную способность около 50 гигабит/с. Как вы думаете, сколько данных видит центральный процессор во время коммутации двух террабит?
у которого память имеет пропускную способность около 50 гигабит/с.
При чем тут память процессора, никто в это «бутылочное горлышко» лезть и не собирается. Это всеравно что сразу похоронить весь проект. Это кэш-когерентная система с последовательной консистентностью для всех процессоров в системе, пусть их будет даже миллиард. Время доступа будет записить только от физических размеров системы (физическая длина кабеля ограничивает). Данные записываются строго в кэш, причем словами по 4096 бит, как например в HBM. Часть данных будут предназначаться другому процессору, для таких скоростей и задержек коммтации выгоднее соединения с ближайшими соседами, чем с относительно далеким коммутатором (до него
просто кабелем примерно столько же времени как и для чтения данных локальной DDR)
Вы сказали:
Центральный процессор, банально «захлебнется» в трафике, ведь каждый пакет нужно обработать (создать и проанализировать заголовой).
Я вам отвечаю: центральный процессор давным-давно не имеет отношения к коммутации пакетов на оборудовании.
https://opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf
Вот примерно то же самое на ASIC'ах. control plane настраивает правила, отправляет в dataplane, дальше оно фигачится на скорости среды.
Современные коммутаторы стараются делать cut-through во все поля. Если не лезет из-за микробёрста, значит, потери. IP никогда не обещал looseless delivery.
У DC-grade коммутатора на 25G и 28 портов буффер - 24Мб. Вполне хватает для microbursts, а больше задержки, скорее, портят, чем помогают.
https://www.extremenetworks.com/product/slx-9140/#tech-specs
центральный процессор давным-давно не имеет отношения к коммутации пакетов на оборудовании.
На оборудовании да, на компьютере еще как, встречал оценки в 20% производительности уже на 1G.
А обработка протокола TCP/IP
традиционно выполняется программно на центральном процессоре сервера. Нагрузка
на него значительно возросла при появлении 10 GE. Восстановление порядка получаемых
пакетов, интенсивный обмен с памятью и обработка прерываний в высокоскоростных
сетях привели к тому, что процессор должен выделять больше времени для работы
с сетью, чем с приложениями. По приблизительным оценкам на обработку 1 bps сетевых
данных требуется 1 Hz частоты процессора. К примеру, ресурсы CPU, работающего
на частоте 20 GHz, будут полностью потрачены на обслуживание дуплексного канала
10 GE.
По поводу
дальше оно фигачится на скорости среды.тоже не все однозначно, есть такой параметр как число пакетов в секунду (по факту это число заголовков которые коммутатор может проанализировать) и тут встречаются числа меньшие чем пропускная способность коммутационной матрицы, а это значит данный сервис совсем не бесплатен и просто так прибавить не получится.
Согласен ASIC для простых задач «рулит».
IP никогда не обещал looseless delivery
Во многих приложениях это насущная необходимость и пообещать и заплатить за это придется.
28 портов буфер — 24Мб
те буфер может предотвратить потерю данных в случае если все 27 портов отправляют пакеты в один порт в течении 344 мкс, а если число каналов будет 256 (infiniBand) и скорости от 400G и вот уже не хватает и приходится изобретать «толстое дерево» и прочие костыли.
Да, обработка сети на хосте требует процессорного времени. В зависимости от того, что вы делаете (свитчинг или TLS) требования по процессору разные; но требовать 20ГГц на 10Гбит линк - это смешно. У меня в лабе старинный R320 выдаёт 40Гбит на одиноком зеоне забытого поколения.
Все приличные 10Г+ сетевухи давно берут на себя часть нагрузки (считать CRC, собирать tcp и т.д.).
Если вы поверх этого накртутите TLS, то картинка станет сильно хуже, вам потребуется толстенная коробка, чтобы TLS'ить 40Гбит. Там надо либо ставить SSL accelerator, либо скейлить ядра.
В целом, я не понимаю вашей любви к плезиосинхронности. Вот, например, у меня один сервер фигачит 10Гбит в одину толстую tcp, потому что с него качается бэкап базы данных размером 200Тб.
А рядом сервер фигачит 20Гбит, потому что на нём запущено несколько тысяч контейнеров, которые "что-то там делают". Как вы будете разруливать сетевые соединения для (условных) 2000 контейнеров? Каждому 64 килобита выдадите?
В целом, я не понимаю вашей любви к плезиосинхронности.
Тут все просто, для проектирования суперкомпьютеров требуется объединить много процессоров и эффективная степень распараллеливания напрямую зависит от времени на передачу данных. Время передачи данных зависит от скорости и задержки передачи.
Есть факт, в настоящее время нельзя создать полноценную распределенную память (производительность отстает на 2 порядка от локальной памяти) и виновата в этом сеть. Рапределенная память это фактически ключ к высокой производительности.
Каждому 64 килобита выдадите
Сколько запросят столько и выдам, да еще и маршруты будут оптимальными (загрузить сеть равномерно).
Спасибо!
А теперь вопрос: вот я написал сайт. допустим, это будущий убийца netflix. И на каждого клиента мне нужно 5 мегабит на видеопоток, плюс чуть-чуть для control.
Итак, я запускаю ./netflix_killer. В это время мой коллега запускает рекламную баннерную кампанию.
Сколько я должен запросить? Ну, для начала резерв на 1 клиента. 5 мегабит.
Теперь, внезапно, кто-то кликнул на рекламу и мне уже нужно 10 мегабит. А потом мне нужно 20Гбит. Но тут группа товарищей поыткавшись между видео ушла. И мне опять нужно 5 мегабит.
И как в вашем волшебном мирке выглядит оракул, способный предсказать сколько мне нужно трафика в NZ, а сколько в SG?
Программа DNS собирает данные о загруженности сети и начинает перенаправлять и возможно даже изменять скорость менее приоритетных потоков, так что бы сеть была загружена равномерно.
Да случайность загрузки присутствует и в этой сети, но она носит «низкочастотный характер» и приводит к отказу в создании канала, а не в потере данных с последующим увеличением трафика, для повторной передачи потерянных пакетов уже существующих каналов.
Окей, то есть на сервере мы пишем код, который пытается эстимейтить нужную полосу, ждёт, когда ему пришлют добро на передачу данных и пересылает данные. Допустим, у нас умеренно нагруженный сервер (nginx), 20 тысяч соединений в секунду. Нам надо обрабатывать 20 тысяч попыток расширить канал. В секунду. Вместе с повторными попытками в случае неудачи. И сообщением о том, что канал больше не нужен.
Мне почему-то кажется, что по CPU это не будет отличаться от обычного TCP, которое делает SYN, присылает ACK, подстраивает размер окна и обрабатывает отказы в доставке (как с помощью RED так и по факту congestion), а в финале выполняет ритуал FIN/FIN ACK. И там и там масса двигающихся деталей, требующих много телодвижений.
Вот, скажите, ваш предлагаемый протокол, как он будет себя вести на магистральном линке? У вас 80 000 клиентов инициирует открытие тысячу каналов по 64 байта в секунду. А потом иницирует закрытие.
Вот ближайший рутер на IP такую фигню прокачает и не заметит. А у вас?
Нам надо обрабатывать 20 тысяч попыток расширить канал.
Скорее будет выглядеть так:
— канал это ячейка в адресном пространстве (один канал, один адрес). По функционалу FIFO
— решил создать новый канал, записал по данному адресу символ запроса на создание канала, прочитал адрес из списка возможных альтернатив и записал его в нужный адрес, таким образом записал все нужные параметры. По факту это запись данных в кэшируемую память. Создание канала это несколько команд mov.
Выполнять попытки соединеия может и сама «сетевая карта», скорее всего так и будет и вот почему. Если подразумевается механизм оптимизации (выравнивания нагрузки на сеть), то эхто желательно делать прозрачно от пользователя, а значит на выгоднее это делать на уровне «сетевой карты», да и перебор адресов задача очень простая и не сильно сложная даже для процессора. Делать это нужно не каждый раз при отправке данных, а только при создании канала.
— Отправил часть данных, как решается вопрос с детектированием переполнения нет так уж важно. Можно читать по другому адресу параметры, можно переключить задачу до момента пока буфер не освободится (как для виртуальной памяти).
— Периодически читаешь из другого канала ответы на передаваемые данные.
Канал не расширяется — нужно новое соединение с новой службой (объектом сервисом) просто создаешь новый канал. Исчезла потребность записал символ удалить канал и канала нет.
Канал это монопольное строго последовательное соединение одного передатчика и одного и больше приемников.
Вот ближайший рутер на IP такую фигню прокачает и не заметит. А у вас?
не сказал бы — у не сильно дорогих коммутаторов число пакетв в секунду примерно в этом диапазоне. Да и если это будут TCP IP а не просто отправка «в никуда» пакета с данными в 64 байте сомневаюсь. А если в соседний порт (тоже 100G) коммутатора вливается такой же поток, то совсем сомневаюсь.
Дла предлагаемого алгоритма и 100 бит символа 100G физического канала создание канала и передачи 64 байт и закрытие канала потратится 7 нс. Если такое происходит 80 миллионов раз в секунду, то будет занято чуть больше половины физической пропускной способности сети (если запрос на создание канала не защищать дополнительным избыточным кодом, если защищать будет 0.8 от пропускной способности не критично).
Вы несёте ахинею. Любой маршрутизатор с 10G+ на борту уже давно маршрутизирует с line speed, потому что маршрутизацию делает тот же асик, что и коммутацию. Просунуть 10000 /32 через BGP - это уже интересная задача, но если просунули, дальше это реальный честный line speed.
А вот для того, чтобы ваши сомнения развеять, возьмите любой современный aggreation/core уровень и поиграйтесь.
Понятно вы не рассматриваете работу компьютера генерирующего эти запросы. Просто передача пакетов собранных из многих входов в одит магистральный выход? Тогда это тривиальная задача (если данные приходят равномерно и размера буфера хватит для хранения всех запросов).
А если данные приходят сразу из всех физических каналов, один за другим и размер передаваемых данных даже в течении 1 мс (цикл) существенно больше размера буфера?
Синхронная система ограничена некоторым числом элементарных буферов, предположим это те же самые 24 Мб (у нас же одинаковое число транзисторов).
Для 100 бит символа — 1 буфер 500 бит (5 символов размер запроса). Всего 48000 элементарных каналов можно одновременно создать.
Считаем что никто дальше по сети не занимается подобной работой (не занимает ресурс сети).
Все 80000 клиентов начинают сразу передавать данные (худший случай -все в один момент) и занимают все 48000 каналов. Итого 48000 создадут каналы и начнут передавать данные (пока не обсуждаем скорость которую они запросят) 32000 пользователей получат отказ в создании канала. Все неудачники могут попробовать создать канал с альтернативным маршрутом (для пакетной сети оперативное создание альтернативного маршрута затруднительно), считаем что такого маршрута нет и все 32000 одновременно отправят второй запрос на создание канала. За это время часть данных из 48000 каналов будет передана и некоторые из этих запросов будут удовлетворены дальше все повторится, до момента пока все запросы будут удовлетворены (сколько будет израсходовано пропускной способности входящих каналов не считаю).
Следующий раз данные могут передаваться через мс от момента предыдущей передачи или ровно по таймеру (все 80 тысяч сразу). Если от момента передачи, то моменты запроса канало постепенно «расползутся» по времени равномерно и дефицита коммутационных буферов наблюдаться не будет.
Пакетная коммутация сможет справиться с такой нагрузкой только в том случае если объем данных пересылаемых за 1 мс не превышает объема буфера (а то и его половины если данные передаются раз в мс, но не гарантированно что ровно через мс после предыдущих — четная мс в конце нечетная в начале интервала). Если превысит, то могут начаться различные события, зависящие от времени за которое приходит ответ.
Если отправлять пакет без получения уведомления и повторной передачи, то данные будут пропадать самым не предсказуемым образом.
Спасибо за объяснение, я понял, что современные сети не работают. Пойду попрошу выключить core-маршрутизаторы, мне в интернетах рассказали, что данные будут пропадать самым не предсказуемым образом, а надо делать совсем не так.
Как только переделаем два терабита аплинков, так напишем.
Кстати про голос и вообще комично, при скоростях передачи в 1G и выше не могут качественно передать голос для которого и 64к очень много? Про видео это ладно, хотя тоже позорище. Репортаж по телевизору, а там всесто кореспондента тпру-му-пу.
Вот ответьте мне, что вы выберете гарантированно установленное соединение (пусть и озможно не сразу) с равномерным потоком или неравномерный поток с непредсказумым прерыванием соединением от 100мс и до нескольких секунд.
Проблема существует, но ее все занесли в раздел «фича» и терпят из-за отсутствия решения.
Сейчас переведут сотовые телефоны полностью в пакетный режим и в общую сеть и там тоже будем слушать эти тпру-му.
Последний раз, когда я пользовался плезиосинхронной системой, она стоила примерно $300/месяц за 1.5Мбит/c. Переход на гигабитную оптику (в тот самый момент) обошёлся в $500, при месячной цене в $200/месяц (за оный гигабит). Цены для бизнеса, без каких-либо домашних хомячков.
Если вы мне предложите канал в 10 мегабит с гарантированным каналом, или гигабит с коммутацией за те же деньги... Ну вы поняли.
А вот каким образом вы сделаете плезиосинхронные системы дешевле - это вопрос интересный.
Сколько вы хотите за 28-портовый неблокирующий 25Гбит плезиосинхронный коммутатор?
Мне удалось избавиться от требования к прецизионности тактовой частоты и упростить многие алгоритмы. Схемотехника хорошо конвейеризовывается, значит проблем с достижением высоких частот не будет.
С хорошей вероятностью цена на сеть и оборудование присоединения упадет еще на пару порядков, если вообще не станет бесплатной. Без нее нельзя будет жить в новом обществе.
Подводя итог:
Не смотря на то, что плезиосинхронные системы проиграли конкуренцию IP, не смотря на то, что вы не знаете сколько будет стоить оборудование, вы уверены, что оно будет дешевле, чем маршрутизаторы и победит IP.
Спасибо, я услышал ваше мнение. Мне потребуется некоторое время, чтобы оценить его авторитетность, я вам напишу, когда прийду к какому-то заключению.
А ещё, мне почему то кажется что Rutel под своей технологией подразумевает замену всего стека -- буквально "L1-L7" ака "L1-L4" что выглядит во крайней мере странно и спорно -- а по факту нереалистично.
Он там межу делом упомянул GSM -- так он минимум 10 лет полностью пакетный за пределами "базовой станции" -- те коммутируются каналы только между абонентом и БС, дальше исключительно SIP,. злые кодеки-вокакодеры типа G.729 с полосой ниже нижнего и ОКС-7 на стыке.
Вообще эти все изменения хочется сделать из-за смены культуры. Это все равно что жить в советской квартире, хочется сделать капремонт, умный дом, робот пылесос сяоми
А интернету много лет. Его делали гики, компы были медленные как и соединение, все было открыто, институты так между собой связывались(хотя вообще задумывался как военная секретная наработка лол). Тогда для всякой утехи сразу создавался свой протокол: http ftp smtp rtmp gopher webdav и прочие. Общались просто и без излишеств.
Сейчас нам нужен низкий пинг(QUIC), у всех быстрый интернет, все коммерциализируется FAANG, ой пардон MAANG, всем нужен БРАУЗЕР чтобы смотреть СОЦСЕТИ, что за ftp smtp вы тычете? электронная почта нужна только для подтверждений всяких, никто ею по прямому назначению не пользуется (разве что кооперативная). Сейчас мобильность, ты постоянно онлайн, для 100% онлайнизации разве что VR гарнитуры не хватает. Все сидят в телефонах куда не посмотри. Игры стриминг соцсети.
А от на децентрализацию мода это ближе к Тору. Тут надо предоставить себе политический компас. Есть интернет коммунистический и капиталистический :) (сейчас догадайтесь какой у нас интернет). Создаём метавселенную где за нами шпионят, лезет государство, нами торгуют. Тоесть прям как реальный мир интернет стал. Киберпанк..... Но всегда есть тихое местечко, где можно посмотреть кое что, и купить кое какой порошочек.
(http://nerohelp.info/5422-dpg-open-compute-project.html ). Без этой технологии никой виртуальной реальности, никаких больших серверов.
Вот такая технология связи позволяет все это получить:
habr.com/ru/post/577810 и habr.com/ru/post/512652
Как «починить» интернет