Основу интернета составляют тысячи как удачных, так и спорных технологий. Некоторые из них получили распространение едва ли не случайно.
Недавно на Hacker News развернулась оживленная дискуссия на эту тему. Резиденты рассказали, что они бы поменяли в архитектуре современного интернета.
Мы решили разобрать основные моменты и обсудить их на Хабре.
Известная тема с IP
Есть мнение, что значительная часть проблем в работе всемирной сети связана с адресами IPv4. Этот протокол был экспериментальным, его изначально задумывали как временное решение, но он «вырвался за пределы лаборатории».
В результате сегодня мы имеем дело с истощением пула адресов, который оказался не готов к росту пользовательской базы и количества вычислительных устройств. В то же время с IPv4 связан ряд других моментов — например, сложность агрегирования маршрутов и обработки заголовков пакетов. Несколько резидентов Hacker News убеждены, что переход на IPv6 исправит эти недостатки. Протокол нового поколения расширит адресное пространство с 32 до 128 бит и оптимизирует работу с данными. IPv6 использует многоадресные группы для передачи широковещательных пакетов и имеет технологию QoS — она определяет пакеты, чувствительные к задержке.
Хотя не все участники дискуссии были настроены оптимистично. По мнению некоторых, менять нужно сам протокол IPv6. Еще в 2018 году инженеры из Ратгерского университета объявили протокол нового поколения «мертвым». Они посчитали, раз технология не получила признания за прошедшие двадцать лет, то ждать этого уже нет смысла. Проблема в том, что IPv6 пытается решить сразу множество недостатков предшественника. Это тормозит внедрение протокола — процесс может растянуться еще на десять лет. В то же время его комплексная реализация привела к усложнению связанных с ним систем. Инженеры до сих пор находят баги в микропрограммах маршрутизаторов.
Один из участников дискуссии высказал мнение, что трудностей с массовой адаптацией можно было избежать, если бы проблемы IPv4 решались последовательно. Для начала стоило сфокусироваться на вопросе истощения адресов IPv4. По мнению инженера, внедрение версии протокола с одним или двумя дополнительными октетами прошло бы значительно быстрее.
Вопросы к системе доменных имен
Вторая технология, которую энтузиасты предлагают изменить, — это DNS. Систему разрабатывали в 80-х годах, и в то время безопасность не была основным приоритетом. У неё есть проблемы с аутентификацией и доверием. Многие из них решает протокол DNSSEC, минимизирующий вероятность атаки с подменой DNS-адресов. Однако более серьезное испытание связано с работой протокола динамической маршрутизации BGP. Он нужен для обмена информаций о доступности сетей и часто становится причиной «утечек маршрутов».
Резиденты HN говорят, что заменили бы текущую систему DNS децентрализованным протоколом. Справедливости ради стоит заметить, что работа в этом направлении уже идет. Так, инженеры из Швейцарской высшей технической школы Цюриха представили архитектуру SCION — о ней мы рассказывали в прошлый раз. Их коллеги разрабатывают модель Named Data Networking (NDN). Идея в том, чтобы заменить цифровую адресацию TCP/IP иерархическими именами.
Есть и проекты на базе блокчейнов. Например, некоторые разработчики предлагают защищать пару «домен — DNS» с помощью метода распределённого вычисления хеша. Есть и аналогичный проект, при этом он совместим с текущей системой доменных имен. В любом случае оба этих решения пока не получили широкого распространения, и с ними работают группы энтузиастов.
Дополнения к «базовым» технологиям
В контексте дискуссии также отмечают необходимость замены HTTP. В то же время можно встретить мнение, что вместо разработки его альтернатив [которые скорее всего будет использовать горстка организаций], все-таки стоит сконцентрироваться на модернизации HTTP. Например, сделать его модульным и добавлять к нему «подпротоколы». В этом случае получится реализовать механизмы типа http/imap или http/ftp поверх HTTP для обратной совместимости со старыми клиентами.
Под «раздачу» также попала электронная почта. Протокол SMTP впервые был описан в начале 80-х (RFC 821). Сегодня email страдает от проблемы спама и выступает оружием в руках киберпреступников — примерно треть кибератак начинается с фишинга. В связи с этим пользователи предлагают добавить шифрование и аутентификацию отправителя по умолчанию. Так, один энтузиаст представил проект MNM. Он расширяет функциональность электронных писем, параллельно обеспечивая безопасность коммуникаций. Сообщения распространяются только внутри ограниченного круга адресатов, а пользователи сами выбирают маршруты.
Какие технологии, на ваш взгляд, нужно модифицировать в первую очередь?
В нашем блоге на Хабре:
В корпоративном блоге у нас на сайте:
Комментарии (48)
jershell
28.11.2021 15:43+5К IPv6 претензии не совсем понятны, если расширить заголовки IPv4 на любое количество, даже на 1 бит, то мы опять получаем новый протокол требующий замены оборудования(из-за аппаратной поддержки, где вопрос не решить прошивкой). Судить же, достигнута ли цель IPv6 заменить IPv4 по мне так рано, это будет возможно только когда кончатся адреса в IPv4. Пока что любой другой протокол будет иметь схожие проблемы. Но даже без этого мы имеем статистику, в районе 40% пользователей в гугл ходят по новому протоколу и эта цифра растет приблизительно на 5% в год. Очень вероятно, что через 12 лет минимум и 20 лет максимум про ipv4 мы будем вспоминать только в старых локальных сетях.
KatbertW
28.11.2021 18:22Думаю, что на IPv4 можно сидеть еще долго – есть NAT, при этом адреса регулярно высвобождаются и их перепродают. Но возможно, ускорят миграцию инициативы регуляторов – некоторые уже требуют переходить на IPv6.
ivan386
29.11.2021 01:05+3Проблема NAT в том что два узла находящихся за NAT не могут без костылей соединится друг с другом. А это сейчас как никогда актуально так как уже достаточно востребована видео связь. В условиях когда видеопотоку надо приодолеть 2 или даже 4 NAT (в вашем WiFi роутере он скорей всего тоже включён) связь идёт не напрямую а через сервер который имеет внешний IP. Этим сервером кто-то владеет и обслуживает и у него не бесконечные ресурсы чтобы обслуживать видеопотоки всего интернета и в какой то момент он начинает лагать.
В то же время есть отличная технология 6to4 которая позволяет провайдеру или его пользователям подключить IPv6 используя внешний IPv4 провайдера. IPv4 адрес провайдера становится частью адреса IPv6 подсети и указывает на какой узел сети IPv4 надо слать ответный пакет если он покидает IPv6 сеть.
FotoHunter
29.11.2021 07:26+1Лет 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.
dartraiden
28.11.2021 15:53+25Статья о том, как починить интернет в блоге компании, поставляющей оборудование для поломки связности (например, их решение применяется в Белоруссии/Беларуси для блокировки не нравящихся власти ресурсов).
Какая ирония.
Так я скажу прямо: чтобы приходилось поменьше чинить интернет, его нужно поменьше ломать. Поменьше строить своими руками решений, позволяющих «блокировать VPN-протоколы и Telegram».
SShtole
28.11.2021 17:54+2Рынок не сопротивлялся, когда государство заставило ставить всех СОРМ, потом СОРМ-2, затем СОРМ-3, когда придумало блокировки сайтов, когда устанавливало всем «Ревизоры» — а это большие затраты на установку и экскплуатацию.
А вы не подскажете, кто такой этот рынок, который должен был, но «не сопротивлялся» (из текста по вашей ссылке)? Кто конкретно подразумевается? Я всегда думал, что такие вопросы — общегражданского характера, и недоумеваю, причём тут рынок.
Один чувак, который при совке был, типа, крупный администратор и знал систему изнутри, рассказывал, что была такая чума — эксплуатировать заводы в хвост и в гриву. Они, помимо того, для чего, собственно, заводы и нужны, занимались примерно всем: от строительства жилфонда (!!!) и собственных больниц до организации досуга (не того). И не корпоративы проводить, как сейчас, а строить и обслуживать целую загородную «турбазу» (как это тогда называлось). Просто чтобы организовать что-то хорошее, нужен хороший организатор, а зачем их искать, если есть директор завода, который худо-бедно наладил выпуск продукции? Пусть как Рабинович — ложится и выполняет за всех план. Директора тогда в разделе прибылей официально не участвовали, а возможности для воровства, по сравнению с нынешними, были сильно ограничены, поэтому к соцнагрузке они относились как собака к консервной банке, привязанной к хвосту: нравится не очень, а куда деваться.
Вот мне текст чем-то напомнил этот рассказ. Заменяем заводы на «рынок», и пусть он, значит, борется против власти и против цензуры. Пока граждане сидят по своим диванам.бездействие многих участников рынка вызывает большое удивление
Удивительно, правда? Так и представляю, как мой провайдер кабельного Интернета в 2005 (тогда ещё их можно было назвать «участниками») вместо бездействия пошёл на баррикады!
acc0unt
29.11.2021 00:45+2И правда позорище. Силами таких вот выродков связность сети и разрушается. Спасибо что сообщили - своих героев страна должна знать.
MAXH0
28.11.2021 18:01Позвольте высказаться... ИМХО для того чтобы "починить" Интернет нужна машина времени.
Современный интернет возник эволюционно и он просто вырос. Перерос стадию достижения популярности и перешел в фазу "монетизации популярности". Крупные игроки вытесняют мелких и уже нельзя сделать стартап в гараже и заработать лярд, а только продать его за условный лям и долю в прибыли. Так что поиск технических средство почему Фейсбук был возможен тогда, а не сейчас - бесперспективен. Дело в экономике...
Деньги, как универсальный регулятор, ведут систему не туда. Она уничтожает Интернет, а не протоколы.
Rutel_Nsk
28.11.2021 18:38Может нужно не просто протокол поменять, а вообще отказаться от пакетной коммутации.
Вроде бы очень простая парадигма: Обмен телеграммами, заполнил адресную часть, вписал передаваемые данные и отправил.
Вот какие тут могут быть подводные камни?
Камень номер один: Пока передается пакет, интерфейс занят для всех остальных, что приводит к большим задержкам на коммутацию (сравните с теоретической задержкой на коммутацию синхронной сети).
Костыль: Ограничили размер пакета (до 53 байт в АТМ) или ввели спец символы для служебных данных (SpaceWire) и другое. Увеличение размера буферного ОЗУ.
Камень номер два: Заголовок нельзя сделать большим, это сильно влияет на КПД процесса передачи (Время заполнения, отношение размера заголовка к размеру полезных данных). В настоящее время до 20% производительности вычислительной системы расходуется на работу с пакетным трафиком. Появились проблемы с нехватной числа IP адресов. Выполнять создание заголовка необходимо каждый раз, даже если передать требуется одно слово, что катастрофически снижает производительность для интерактивных приложений.
Костыль: Объявить «фичей» и смириться — решения проблемы нет.
Камень номер 3: На самом нижнем уровне не прописаны механизмы структурирования передаваемых данных и приходится фиксировать (создавать стандарты) различных протоколов, как итог около 700 различных протоколов. Часть из протоколов обязаны поддерживать коммутаторы, что делает их дорогими и медленными (сложность анализа протокола).
Костыль: Объявить «фичей» и смириться — решения проблемы нет.
Камень номер 4: Пакетная сеть по своей природе является асинхронной, а значит всегда есть вероятность, что сумма информационных потоков предназначенных для конкретного выхода будет больше его физической пропускной способности. Увеличение размера буфера памяти никак не поможет. Для больших скоростей передачи данных и вообще невозможна буферизация, попробуйте буферизовать суммарный поток в 100Тбит в секунду (посчитайте параметры требуемого ОЗУ). Пакетная сеть теряет стабильность после загрузки больше 25% от суммарной производительности и начинаются потери.
Костыль: Хорошего решения нет. В рамках решения проблемы в протокол введено постепенное наращивание скорости, что эквивалентно ограничению реальной пропускной способности сети (заканчились данные для передачи, а максимальная скорость еще не достигнута). Была предпринята попытка решить проблему: Программно определяемая сеть (SDN), но похоже технология тоже «мертворожденная».
Это самые простые «камушки» и теперь вопрос:
Может легче пристрелить эту «лошадь», чем обвешивать ее бесконечным набором «костылей»?
tzlom
28.11.2021 19:28+2а если не пакетами то чем?
Rutel_Nsk
28.11.2021 19:40-1Плезиохронные каналы передачи данных. Развитие технологии PDH.
Мой вариант решения проблемы: habr.com/ru/post/512652
fougasse
28.11.2021 20:34+1За год есть какой-то прогресс, кроме тероретизирований?
Rutel_Nsk
28.11.2021 21:01Хорошая теория, она как целый (в нужный момент) презерватив, позволяет избежать многих проблем. Вот небыло ее (теории) в момент создания компьютерной сети… )))
fougasse
28.11.2021 21:13Ну хоть какие-то документы/исследования?
После беглого прочтения статьи и комметариев кажется, что вы «переизобретаете» TDM, который давно используется, сегодня даже на терабитных скоростях, но имеет свою кучу недостатков, начиная со сложности определения тайм-слотов, заканчивая маршрутизацией т.к. за пределами PSTN и тому подобного SONET суметь правильно и вовремя выделить нужное из условных 4х400G потоков данных уже само по себе нетривиальное занятие.
И вопросы таблиц маршрутизации никуда чудестным образом из TDM сети не исчезают, а, наоборот, проявляются еще сильнее, т.к. знать о одном уровне соседей и метриках уже недостаточно для (оптимальной) маршрутизации, значит должны быть routing ноды, которые видят всю(или часть) сеть. Как у вас с этим?
Ну и ваш, так сказать, презерватив — это не теория, а гипотеза.
Rutel_Nsk
29.11.2021 03:18После беглого прочтения статьи и комметариев кажется, что вы «переизобретаете» TDM
Правильнее сказать, что это сильно продвинутая версия TDM. Удалось решить основные проблемы, которые не позволяли оптимально применять TDM в вычислительной технике:
1. Произвольная скорость канала.
2. Передача данных без предварительного создания канала (можно передавать сразу).
3. Утилизация всего зарезервированной, но в данный момент не используемой пропускной способности канала.суметь правильно и вовремя выделить нужное из условных 4х400G
Согласен чуть более сложная структура данных, но современные полупроводниковые технологии данного «усложнения» (с точки зрения чиса транзисторов) даже не почуствуют. Да и только кажется, что это сложно. Самое главное, данная сеть черезвычайно хорошо конвейеризуется, те за счет коротких цепочек логики от одного выхода триггера, до входа другого, позволяет получать большие тактовые частоты коммутатора (время коммутации канала стремится ко времени работы FIFO соединяющего два клоковых домена).
И по поводу скоростей, речь идет про десятки и сотни Тбит в секунду с временем коммутации в единицы нс при степени утилизации физического канала более 90%. Может ли пакетная коммутация похвастаться такими уровнями?И вопросы таблиц маршрутизации
Нет таблиц маршрутизаии, при создании канала адресная информация в каждом коммутаторе расходуется для выбора номера исходящего физического интерфейса. Адресация относительная.это не теория, а гипотеза
Статья содержит достаточную информацию, для постановки ТЗ исследовательского проекта (например на основе FPGA), все алгоритмы описаны в достаточной степени, то что не конкретизировано не является принципиальным и может быть реализовано в произвольном варианте.
В настоящее время идут переговоры с представителями фирмы, являющейся одним из мировых лидеров в коммуникационном оборудовании. Данную компанию заинтересовал проект распределенной памяти на основе Синхронной иерархии (https://habr.com/ru/post/577810/ ).
Gem
30.11.2021 05:39Вот да, SONET и прочее красиво только на бумаге, в реальности тоже самое получается - только в профиль, но дороже
amarao
28.11.2021 21:40+1Хоронили плезиосинхронные сети, порвали 7 баянов. Спасибо, но нет. Старые связисты, с которых песок сыпется, проиграли по всем фронтам (включая передачу голоса). Пакетная передача данных позволяет дёшево сделать быстро.
Вы предлагаете сделать за нереально дороже чуть-чуть лучше. А ethernet вместо этого накинет ещё десяток 25G линков и всё станет сильно лучше, чем накручивание поверх E1 ещё одного плезиосинхронного анахронизма.
Rutel_Nsk
29.11.2021 03:46Нашел решение всех проблем которые были присущи плезиохронным каналам и надеюсь на «реинкарнацию» забытой технологи.
По стоимости ничем не отличается от пакетной сети, при этом качественно решает проблему цифровой связи (все заморочки с точной синхронизацией и протоколами ее соблюдения решены). Структура построения канала достаточно простая и первые два уровня OSI и вообще взяты у современных сетей передачи данных.А ethernet вместо этого накинет ещё десяток 25G линков
Вот как раз это и невозможно, после начнутся проблемы с буферизацие данных (скорость и размер буферного ОЗУ для выравнивания мгновенно требуемой и реально предоставляемой скоростью передачи данных). Центральный процессор, банально «захлебнется» в трафике, ведь каждый пакет нужно обработать (создать и проанализировать заголовой). Нет «накинуть» то можно, но так не блещущий коэффициент использования будет уже совсем печальным.
Предлагаю возможность «накинуть» еще не десяток а тысячи 25G линков и при этом гарантировать время коммутации на уровне единиц нс.
Что по времени коммутации может предложить пакетная коммутация — сотни нс даже для самой быстрой реализации (InfiniBand). Такая задержка не позволяет построить действительно конкурентноспособную распределенную память, на передачу пакета уходит больше времени чем на чтение из локальной оператичной памяти.
В предлагаемой (Синхроннная иерархия) сети время коммутации единицы нс, стабильно малое время доставки (сопоставимо с временем распространения сигнала в кабелях связи), теоретический максимум.Хоронили плезиосинхронные сети, порвали 7 баянов
Это поверхностный взгляд на проблему, недостойный инженера ))fougasse
29.11.2021 08:52Вы в курсе, что никто трафик черкз CPU не гонит уже лет 20 как?
Про тысячи линков. У вас ресурсов современных FPGA хватит хоть с десяток 25G-линий адекватно реализовать и связать?
Сказки — это уровень недостойный инженера.
Rutel_Nsk
29.11.2021 09:23Вы в курсе, что никто трафик черкз CPU не гонит уже лет 20 как?
никто этого никогда не делал, думаю это будет отдельный чиплетПро тысячи линков. У вас ресурсов современных FPGA хватит хоть с десяток 25G-линий адекватно реализовать и связать?
Десяток линий это на дешевых FPGA можно сделать (там примерно стольно и есть если говорить по Xilinx)
Вот так примерно будет выглядеть процессорный интерфейс будущего: servernews.ru/1029015 (это только тесты). Есть еще видео презентации где демонстрируется печать световодов в теле печатной платы, те на печатной плете уже не будет медных проводников, только залитая оптика соединяющая отдельные микросхемы.Сказки — это уровень недостойный инженера.
Укажите конкретное высказывание, которое не реализуемо на современном техническом уровне. Понимаю, что трудно воспринимать что то новое, но и бросать голословные утверждения нехорошо.fougasse
29.11.2021 09:39Stratix10 — дешевая FPGA?
Пока что бросаете высказывания вы, а вся индустрия не в курсе, кроме «одного из лидеров в коммуникационном оборудовании».
Rutel_Nsk
29.11.2021 09:56Эти дорогие.
Я выбирал тестовую плату с микросхемой от Xilinx, там больше 20 интерфейсов — цена в России 300 долларов.
Насколько я понимаю все Ваша возражения строятся на предположении, что если «за границей» этого нет то и нам не нужно?
Да этот подход типичен для российской научной бюрократии, тебе не выделят гранд на исследования если, то чем ты будешь заниматься не имеет «индекса цитирования». Именно так все наши научные сследования и проводятся (гипербола).
Получают грант, потом переписывают результат из уже произведенных зарубежных работ и пишут вывод: У нас неполучилось, но и за рубежем тоже ничего не получилось )))
Прошу еще раз в чем конкретно претензия? Что не осуществимо, где в моей статье есть технически невыполнимое обещание и в чем оно технически не выполнимо?fougasse
29.11.2021 11:29Причём тут, вообще, «за границей»?
Вы понимаете, что уровень развития технологий сейчас таков, что ничего локально сделать не выйдет, а вы наоборот ёрничаете про несостоятельность «индексов цитирования» и грантоедство?
В вашей статье полно обещаний, которые непонят что дадут.
Можете подробнее рассказать как ваша локальная адресация будет работать в сети хоть из 100 узлов с динамической топологией, когда локально для узла Х следующие, допустим, 2 хопа есть, а потом свзязь к узлу Y оборвалась? Кто решает куда пойдет трафик? На каком основании? Я, если что, представляю как это сейчас работает в проериетарных TDM и гибкости уровня пакетной передачи там и близко нет. Поэтому всё движется в сторону IP даже в изначально PDH сетях, в окружающем мире.
Технически выполнимо всё, вопрос денег и смысла.
Rutel_Nsk
29.11.2021 12:09что ничего локально сделать не выйдет,
Даже и не пытаюсь — ищу тех у кого океан денег и они еще могут создать альянс по типу USB, PCI и прочих.Можете подробнее рассказать как ваша локальная адресация будет работать
1. Этап создание маршрута (в данном случае адрес). Выполняется отдельной службой (сейчас называется DNS). Если нет необходимости выходить за пределы какого то устройства (например датчик в станке, он не должен выходить в сеть и подключается строго к плате управления или к ее резервной копии), то просто прописывается по умолчанию в конфигурационных данных список путей (адресов).
2. При необходимости создать канал, датчик отправляет в качестве адреса первый из имеющихся путей. Если за рассчетное время (получается вместе с адресом, поскольку оно поддается рассчету и гарантированно стабильно) нет ответа от адресата (если нет сервиса отправки ошибки у промежуточных коммутаторов), то в канал отправляется символ закрыть канал и выбирается следующий адрес из списка и так по кругу, пока не будет установлена связь.
Это самый простой сценарий.
Если происходит обрыв связи, данные не доставлены (будет известно за удвоенное время доставки), то также закрываем канал и выбираем следующий адрес.
Список адресов (путей) может быть очень обширным и для больших систем может постоянно корректироваться в процессе работы, даже без запроса от пользователя (автоматическая балансировка нагрузки)TDM и гибкости уровня пакетной передачи
То что разработал сочетает в себе все варианты сетей передачи данных
1. Синхронный — если отправляет строго по времени по одному символу.
2. Фреймовый отправляет по времени, но не один символ а буфер целиком (максимальный размер буфера может указываться тем же DNS — у него собраны все данные о промежуточных коммутаторах)
3. Пакетный — отправляем с использованием не задействованной пропускной способности все данные из буфера в тот момент когда есть неиспользуемая пропускная способность и есть данные для передачи. Данный режим может вызывать потерю данных в данном конкретном канале, если где то будет перегружен физический канал и локальный буфер заполнен. Такой тип канала является самым оперативным и предназначен для передачи коротких сообщений (размер не больше элементарного буфера коммутатора) на расстояние где время передачи мало и есть возможность дождаться ответа, о том что данные переданы (по факту асинхронный режим).
Пример использования: Запрос на изменение памяти в распределенной памяти суперкомпьютера, время цикла первые десятки наносекунд в кубе со стороной 3 метра (1000 процессоров).изначально PDH сетях
PDH сети сгубила заносчивость связистов, типа жрите что дают, альтернативы нет. Вот и создали альтернативу, фиговенькую, но что бы убить телефонные компании хватило. Даже авральный АТМ не спас ситуацию. Большой бюджет развращает инженера не меньше чем большая власть чиновника.
По деньгам даже дешевле чем для сравнимой по производительности пакетной системы. При этом предлагается практически не ограниченное развитие, скорости и задержки передачи на два порядка лучше про надежность вообще не говорю. Самое главное, это единый интерфейс от дверного свонка до планетарных линий связи (космос тоже). Для всех вариантов применения от бытовухи, до супер надежных промышленных систем. Данная сеть позволит создать электронное отражение нашего мира (об этом много говорят, но уровень производительности современных сетей не позволяет получить приемлемый результат)
amarao
29.11.2021 12:18Ближайший ко мне коммутатор с 48 25G линками имеет на борту одинокий весьма скромный зеон, у которого память имеет пропускную способность около 50 гигабит/с. Как вы думаете, сколько данных видит центральный процессор во время коммутации двух террабит?
Rutel_Nsk
29.11.2021 12:31у которого память имеет пропускную способность около 50 гигабит/с.
При чем тут память процессора, никто в это «бутылочное горлышко» лезть и не собирается. Это всеравно что сразу похоронить весь проект. Это кэш-когерентная система с последовательной консистентностью для всех процессоров в системе, пусть их будет даже миллиард. Время доступа будет записить только от физических размеров системы (физическая длина кабеля ограничивает). Данные записываются строго в кэш, причем словами по 4096 бит, как например в HBM. Часть данных будут предназначаться другому процессору, для таких скоростей и задержек коммтации выгоднее соединения с ближайшими соседами, чем с относительно далеким коммутатором (до него
просто кабелем примерно столько же времени как и для чтения данных локальной DDR)amarao
29.11.2021 12:40Вы сказали:
Центральный процессор, банально «захлебнется» в трафике, ведь каждый пакет нужно обработать (создать и проанализировать заголовой).
Я вам отвечаю: центральный процессор давным-давно не имеет отношения к коммутации пакетов на оборудовании.
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
Rutel_Nsk
29.11.2021 14:23центральный процессор давным-давно не имеет отношения к коммутации пакетов на оборудовании.
На оборудовании да, на компьютере еще как, встречал оценки в 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 и вот уже не хватает и приходится изобретать «толстое дерево» и прочие костыли.amarao
29.11.2021 14:28Да, обработка сети на хосте требует процессорного времени. В зависимости от того, что вы делаете (свитчинг или TLS) требования по процессору разные; но требовать 20ГГц на 10Гбит линк - это смешно. У меня в лабе старинный R320 выдаёт 40Гбит на одиноком зеоне забытого поколения.
Все приличные 10Г+ сетевухи давно берут на себя часть нагрузки (считать CRC, собирать tcp и т.д.).
Если вы поверх этого накртутите TLS, то картинка станет сильно хуже, вам потребуется толстенная коробка, чтобы TLS'ить 40Гбит. Там надо либо ставить SSL accelerator, либо скейлить ядра.
В целом, я не понимаю вашей любви к плезиосинхронности. Вот, например, у меня один сервер фигачит 10Гбит в одину толстую tcp, потому что с него качается бэкап базы данных размером 200Тб.
А рядом сервер фигачит 20Гбит, потому что на нём запущено несколько тысяч контейнеров, которые "что-то там делают". Как вы будете разруливать сетевые соединения для (условных) 2000 контейнеров? Каждому 64 килобита выдадите?
Rutel_Nsk
29.11.2021 14:47В целом, я не понимаю вашей любви к плезиосинхронности.
Тут все просто, для проектирования суперкомпьютеров требуется объединить много процессоров и эффективная степень распараллеливания напрямую зависит от времени на передачу данных. Время передачи данных зависит от скорости и задержки передачи.
Есть факт, в настоящее время нельзя создать полноценную распределенную память (производительность отстает на 2 порядка от локальной памяти) и виновата в этом сеть. Рапределенная память это фактически ключ к высокой производительности.Каждому 64 килобита выдадите
Сколько запросят столько и выдам, да еще и маршруты будут оптимальными (загрузить сеть равномерно).
amarao
29.11.2021 15:04Спасибо!
А теперь вопрос: вот я написал сайт. допустим, это будущий убийца netflix. И на каждого клиента мне нужно 5 мегабит на видеопоток, плюс чуть-чуть для control.
Итак, я запускаю ./netflix_killer. В это время мой коллега запускает рекламную баннерную кампанию.
Сколько я должен запросить? Ну, для начала резерв на 1 клиента. 5 мегабит.
Теперь, внезапно, кто-то кликнул на рекламу и мне уже нужно 10 мегабит. А потом мне нужно 20Гбит. Но тут группа товарищей поыткавшись между видео ушла. И мне опять нужно 5 мегабит.
И как в вашем волшебном мирке выглядит оракул, способный предсказать сколько мне нужно трафика в NZ, а сколько в SG?
Rutel_Nsk
29.11.2021 15:43Производительность выделяется по мере запросов, если есть возможность то выделяется. Для создания нового потока не требуется никакого дополнительного времени (поток создается за удвоенное время требуемое на передачу данных от источника к приемнику). Передача данных возможна сразу за передачей запроса на создания канала, можно сказать что первые данные уже содержатся в запросе на создание канала.Можно даже задействовать несколько путей сразу и в момент когда понятно, что канал создан, удалить все остальные. Для пользователя несколько попыток создать канал не будут заметны. Вот если канал требуется для высокочастотного сервиса, то канал создается в момент его запуска и прекращается с выключением сервиса.
Программа DNS собирает данные о загруженности сети и начинает перенаправлять и возможно даже изменять скорость менее приоритетных потоков, так что бы сеть была загружена равномерно.
Да случайность загрузки присутствует и в этой сети, но она носит «низкочастотный характер» и приводит к отказу в создании канала, а не в потере данных с последующим увеличением трафика, для повторной передачи потерянных пакетов уже существующих каналов.
amarao
29.11.2021 15:52Окей, то есть на сервере мы пишем код, который пытается эстимейтить нужную полосу, ждёт, когда ему пришлют добро на передачу данных и пересылает данные. Допустим, у нас умеренно нагруженный сервер (nginx), 20 тысяч соединений в секунду. Нам надо обрабатывать 20 тысяч попыток расширить канал. В секунду. Вместе с повторными попытками в случае неудачи. И сообщением о том, что канал больше не нужен.
Мне почему-то кажется, что по CPU это не будет отличаться от обычного TCP, которое делает SYN, присылает ACK, подстраивает размер окна и обрабатывает отказы в доставке (как с помощью RED так и по факту congestion), а в финале выполняет ритуал FIN/FIN ACK. И там и там масса двигающихся деталей, требующих много телодвижений.
Вот, скажите, ваш предлагаемый протокол, как он будет себя вести на магистральном линке? У вас 80 000 клиентов инициирует открытие тысячу каналов по 64 байта в секунду. А потом иницирует закрытие.
Вот ближайший рутер на IP такую фигню прокачает и не заметит. А у вас?
Rutel_Nsk
29.11.2021 17:03Нам надо обрабатывать 20 тысяч попыток расширить канал.
Скорее будет выглядеть так:
— канал это ячейка в адресном пространстве (один канал, один адрес). По функционалу FIFO
— решил создать новый канал, записал по данному адресу символ запроса на создание канала, прочитал адрес из списка возможных альтернатив и записал его в нужный адрес, таким образом записал все нужные параметры. По факту это запись данных в кэшируемую память. Создание канала это несколько команд mov.
Выполнять попытки соединеия может и сама «сетевая карта», скорее всего так и будет и вот почему. Если подразумевается механизм оптимизации (выравнивания нагрузки на сеть), то эхто желательно делать прозрачно от пользователя, а значит на выгоднее это делать на уровне «сетевой карты», да и перебор адресов задача очень простая и не сильно сложная даже для процессора. Делать это нужно не каждый раз при отправке данных, а только при создании канала.
— Отправил часть данных, как решается вопрос с детектированием переполнения нет так уж важно. Можно читать по другому адресу параметры, можно переключить задачу до момента пока буфер не освободится (как для виртуальной памяти).
— Периодически читаешь из другого канала ответы на передаваемые данные.
Канал не расширяется — нужно новое соединение с новой службой (объектом сервисом) просто создаешь новый канал. Исчезла потребность записал символ удалить канал и канала нет.
Канал это монопольное строго последовательное соединение одного передатчика и одного и больше приемников.Вот ближайший рутер на IP такую фигню прокачает и не заметит. А у вас?
не сказал бы — у не сильно дорогих коммутаторов число пакетв в секунду примерно в этом диапазоне. Да и если это будут TCP IP а не просто отправка «в никуда» пакета с данными в 64 байте сомневаюсь. А если в соседний порт (тоже 100G) коммутатора вливается такой же поток, то совсем сомневаюсь.
Дла предлагаемого алгоритма и 100 бит символа 100G физического канала создание канала и передачи 64 байт и закрытие канала потратится 7 нс. Если такое происходит 80 миллионов раз в секунду, то будет занято чуть больше половины физической пропускной способности сети (если запрос на создание канала не защищать дополнительным избыточным кодом, если защищать будет 0.8 от пропускной способности не критично).
amarao
29.11.2021 17:08Вы несёте ахинею. Любой маршрутизатор с 10G+ на борту уже давно маршрутизирует с line speed, потому что маршрутизацию делает тот же асик, что и коммутацию. Просунуть 10000 /32 через BGP - это уже интересная задача, но если просунули, дальше это реальный честный line speed.
А вот для того, чтобы ваши сомнения развеять, возьмите любой современный aggreation/core уровень и поиграйтесь.
Rutel_Nsk
29.11.2021 17:59Ответил, что синхронная сеть выполнит эту задачу без каких либо затруднений и займет это от 0.6 до 0.8 и результатом будет отправка данных с подтверждением доставки.
Понятно вы не рассматриваете работу компьютера генерирующего эти запросы. Просто передача пакетов собранных из многих входов в одит магистральный выход? Тогда это тривиальная задача (если данные приходят равномерно и размера буфера хватит для хранения всех запросов).
А если данные приходят сразу из всех физических каналов, один за другим и размер передаваемых данных даже в течении 1 мс (цикл) существенно больше размера буфера?
Синхронная система ограничена некоторым числом элементарных буферов, предположим это те же самые 24 Мб (у нас же одинаковое число транзисторов).
Для 100 бит символа — 1 буфер 500 бит (5 символов размер запроса). Всего 48000 элементарных каналов можно одновременно создать.
Считаем что никто дальше по сети не занимается подобной работой (не занимает ресурс сети).
Все 80000 клиентов начинают сразу передавать данные (худший случай -все в один момент) и занимают все 48000 каналов. Итого 48000 создадут каналы и начнут передавать данные (пока не обсуждаем скорость которую они запросят) 32000 пользователей получат отказ в создании канала. Все неудачники могут попробовать создать канал с альтернативным маршрутом (для пакетной сети оперативное создание альтернативного маршрута затруднительно), считаем что такого маршрута нет и все 32000 одновременно отправят второй запрос на создание канала. За это время часть данных из 48000 каналов будет передана и некоторые из этих запросов будут удовлетворены дальше все повторится, до момента пока все запросы будут удовлетворены (сколько будет израсходовано пропускной способности входящих каналов не считаю).
Следующий раз данные могут передаваться через мс от момента предыдущей передачи или ровно по таймеру (все 80 тысяч сразу). Если от момента передачи, то моменты запроса канало постепенно «расползутся» по времени равномерно и дефицита коммутационных буферов наблюдаться не будет.
Пакетная коммутация сможет справиться с такой нагрузкой только в том случае если объем данных пересылаемых за 1 мс не превышает объема буфера (а то и его половины если данные передаются раз в мс, но не гарантированно что ровно через мс после предыдущих — четная мс в конце нечетная в начале интервала). Если превысит, то могут начаться различные события, зависящие от времени за которое приходит ответ.
Если отправлять пакет без получения уведомления и повторной передачи, то данные будут пропадать самым не предсказуемым образом.
amarao
29.11.2021 18:02Спасибо за объяснение, я понял, что современные сети не работают. Пойду попрошу выключить core-маршрутизаторы, мне в интернетах рассказали, что данные будут пропадать самым не предсказуемым образом, а надо делать совсем не так.
Как только переделаем два терабита аплинков, так напишем.
Rutel_Nsk
29.11.2021 18:19Работают, но с заиканиями в голосовом и видео трафике.
Кстати про голос и вообще комично, при скоростях передачи в 1G и выше не могут качественно передать голос для которого и 64к очень много? Про видео это ладно, хотя тоже позорище. Репортаж по телевизору, а там всесто кореспондента тпру-му-пу.
Вот ответьте мне, что вы выберете гарантированно установленное соединение (пусть и озможно не сразу) с равномерным потоком или неравномерный поток с непредсказумым прерыванием соединением от 100мс и до нескольких секунд.
Проблема существует, но ее все занесли в раздел «фича» и терпят из-за отсутствия решения.
Сейчас переведут сотовые телефоны полностью в пакетный режим и в общую сеть и там тоже будем слушать эти тпру-му.
amarao
29.11.2021 20:19Последний раз, когда я пользовался плезиосинхронной системой, она стоила примерно $300/месяц за 1.5Мбит/c. Переход на гигабитную оптику (в тот самый момент) обошёлся в $500, при месячной цене в $200/месяц (за оный гигабит). Цены для бизнеса, без каких-либо домашних хомячков.
Если вы мне предложите канал в 10 мегабит с гарантированным каналом, или гигабит с коммутацией за те же деньги... Ну вы поняли.
А вот каким образом вы сделаете плезиосинхронные системы дешевле - это вопрос интересный.
Сколько вы хотите за 28-портовый неблокирующий 25Гбит плезиосинхронный коммутатор?
Rutel_Nsk
29.11.2021 20:39Про цену ничего сказать не могу — не знаю сколько стоит разработка и производство микросхем, но технологии используемые а плезиохронной системе не являются дрогими. Но есть один момент — если сеть станет универсальной, то она будет примерно как сейчас USB (то есть почти бесплатно).
Мне удалось избавиться от требования к прецизионности тактовой частоты и упростить многие алгоритмы. Схемотехника хорошо конвейеризовывается, значит проблем с достижением высоких частот не будет.
С хорошей вероятностью цена на сеть и оборудование присоединения упадет еще на пару порядков, если вообще не станет бесплатной. Без нее нельзя будет жить в новом обществе.
amarao
29.11.2021 21:19Подводя итог:
Не смотря на то, что плезиосинхронные системы проиграли конкуренцию IP, не смотря на то, что вы не знаете сколько будет стоить оборудование, вы уверены, что оно будет дешевле, чем маршрутизаторы и победит IP.
Спасибо, я услышал ваше мнение. Мне потребуется некоторое время, чтобы оценить его авторитетность, я вам напишу, когда прийду к какому-то заключению.
Gem
30.11.2021 06:21А ещё, мне почему то кажется что Rutel под своей технологией подразумевает замену всего стека -- буквально "L1-L7" ака "L1-L4" что выглядит во крайней мере странно и спорно -- а по факту нереалистично.
Он там межу делом упомянул GSM -- так он минимум 10 лет полностью пакетный за пределами "базовой станции" -- те коммутируются каналы только между абонентом и БС, дальше исключительно SIP,. злые кодеки-вокакодеры типа G.729 с полосой ниже нижнего и ОКС-7 на стыке.
gameplayer55055
28.11.2021 23:45+1Вообще эти все изменения хочется сделать из-за смены культуры. Это все равно что жить в советской квартире, хочется сделать капремонт, умный дом, робот пылесос сяоми
А интернету много лет. Его делали гики, компы были медленные как и соединение, все было открыто, институты так между собой связывались(хотя вообще задумывался как военная секретная наработка лол). Тогда для всякой утехи сразу создавался свой протокол: http ftp smtp rtmp gopher webdav и прочие. Общались просто и без излишеств.
Сейчас нам нужен низкий пинг(QUIC), у всех быстрый интернет, все коммерциализируется FAANG, ой пардон MAANG, всем нужен БРАУЗЕР чтобы смотреть СОЦСЕТИ, что за ftp smtp вы тычете? электронная почта нужна только для подтверждений всяких, никто ею по прямому назначению не пользуется (разве что кооперативная). Сейчас мобильность, ты постоянно онлайн, для 100% онлайнизации разве что VR гарнитуры не хватает. Все сидят в телефонах куда не посмотри. Игры стриминг соцсети.
А от на децентрализацию мода это ближе к Тору. Тут надо предоставить себе политический компас. Есть интернет коммунистический и капиталистический :) (сейчас догадайтесь какой у нас интернет). Создаём метавселенную где за нами шпионят, лезет государство, нами торгуют. Тоесть прям как реальный мир интернет стал. Киберпанк..... Но всегда есть тихое местечко, где можно посмотреть кое что, и купить кое какой порошочек.
Rutel_Nsk
29.11.2021 03:52Самое главное, из не решенных и давно назревших задач, дезагрегация оперативной памяти
(http://nerohelp.info/5422-dpg-open-compute-project.html ). Без этой технологии никой виртуальной реальности, никаких больших серверов.
Вот такая технология связи позволяет все это получить:
habr.com/ru/post/577810 и habr.com/ru/post/512652
geolaz
Согласен, что электронная почта сильно устарела, но пока меня просят вручную вносить домены контрагентов в белые списки, так как они не способны сами нормально настроить сервера, переход на более сложные системы, чем связка PTR+SPF+DKIM+DMARC видится мне туманным...
Furriest
Смысл-то как раз в том, чтобы перейти на более простые системы, в которых системные проблемы того же SMTP решены архитектурно и не требуют сложного администрирования.
Впрочем, SMTP скорее нужно просто забыть и для более-менее официального обмена перейти на государственный мессенджер с аутентификацией отправителя и получателя.
KatbertW
Возможно, на замену SMTP придут проекты вроде mnm is not mail, который кратко упомянули в статье. Но опять же непонятно, что будет с массовым внедрением.
Furriest
К сожалению, прошло то время, когда внедрение чего-то происходило на энтузиазме комьюнити, особенно если речь идет о технологиях, которые для адекватного использования должны покрывать абсолютное большинство пользователей.
Сейчас для массового использования необходима некая политическая воля. Было бы хорошо вообще на уровне ООН :)