Комментарии 118
Итого: создаем свой протокол, чтобы узнать, что не надо создавать свой протокол. Но забавно )
поле протокола в заголовке - 8 бит. 256 туда не влезет.
Как понять, что человек статью не читал и пулей полез в комменты, когда увидел какую-то "ошибку"
Иногда полезно почитать спецификации (на протокол IP они идеально написаны в RFC). И тогда не придётся заниматься экспериментами. Если у вас *nix - можно ещё глянуть в /etc/protocols (или в другие RFC), и снять ещё пачку вопросов. И уже потом перейти к практическим тестам - что именно пройдёт в локалке, а что в интернете.
Кто теперь читает маны, или эти, как их, RFC? )
Дядь, я маны не читаю, я их пишу (с)
(а теперь и RFC)
Любой вменяемый разработчик сетевого софта. Чтобы потом не оказаться вот как в этой статье.
Не, я понимаю, "если не изучать физику - мир полон магии", но чёрт возьми.
Да и остался неотвеченным вопрос, почему Linux не обругал 256 в syscall, если библиотека не напортачила.
man 2 socketint socket(int domain, int type, int protocol);// https://github.com/rust-lang/socket2/blob/master/src/sys/unix.rs#L869
pub(crate) fn socket(family: c_int, ty: c_int, protocol: c_int) -> io::Result<Socket> {
syscall!(socket(family, ty, protocol))
}int напрямую в syscall
Понятно, что не uint8_t. Либо нет валидации, либо для каких-то нестандартных нужд разрешен расширенный диапазон (каких?).
ps: да, библиотека не напортачила. :)
А зачем ограничивать в API? Вот представьте, завтра выйдет какой-нибудь IPv7, или даже расширение для IPv6, позволяющее больше (так как более половины в 8 битах уже зарегистрированы) - а теперь API во всем мире не сможет это поддержать?
API - в интерфейсе или реализации? Про интерфейс спору нет, а реализация есть сейчас и поддерживает только v4, v6. Если будет расширение, то его придется добавлять в ядро.
Именно так. Порты вон ограничили в sockets API 16 битами - а теперь, когда их недостаёт (постоянная ситуация в толстых системах), приходится извращаться через множество IP на интерфейсе.
Да все очень просто. На уровне API это значение вполне допустимо т.к. стек не обязательно должен быть TCP/IP. На уровне кода там скорее всего простое преобразование типов INT в UINT8. А делать валидацию параметров на случай когда юзер с головой не дружит никто не обязан.
Так ведь вернул EINVAL же?
Running the server I quickly noticed that Linux does not allow binding a raw socket to protocol 0—Some invalid protocol numbers like 256 worked.
Без заглядывания в дампы syscall-ов в его подпапках, по тексту спойлер с результатами - это MacOS. Вторая половина текста и цитата про 256 - Linux.
В Linux у него влезло
А socket() принимает int. Или вы предлагаете читать RFC по случаю и без, чтобы знать, что там под капотом?
в оригинале - в логах tcpdump на гите, все пакеты имеют "bad cksum", потому что автор решил не считать контрольную сумму, а сделать ее равной нулю. удивительно, что до aws такое дошло
В следующей статье надо поэкспериментировать с Ethertype, чтобы понять, какие пакеты свитчи пропускают, а какие нет.
В следующей статье надо поэкспериментировать с Ethertype, чтобы понять, какие пакеты свитчи пропускают, а какие нет.
Думаю свитчи пропускают все пакеты, за исключением ситуаций с битым crc и с учётом особенностей настройки vlan
Вообще неправильно. Свитчи не пропускают пакеты. Вообще. Они пропускают (коммутируют) кадры.
Свитчи не пропускают пакеты. Вообще. Они пропускают (коммутируют) кадры.
Это смотря какие. Некоторые вообще только с фреймами работают. Всё зависит от страны происхождения пакета.
/s
Не свитчи, а коммутаторы!
То есть, два собеседника выше, употребившие именно «свитчи», тебя не смутили?
Они не душнили по поводу пакеты-кадры.
Понятно. А что заставило тебя считать, будто я не знаю слово «коммутатор»? То, что слово «коммутируют» я взял в скобки?
Я не вижу в его комментариях ничего, что говорило бы о том, что он полагает, что ты не знаешь слово "коммутатор", извините за обилие "что".
Транспортных протоколов несколько больше, чем TCP и UDP.
Никто не запрещает написать свой, не похожий ни на что. Нужен только обработчик этого протокола, чтобы ОС знала, что делать с байтами, полученными с сетевого интерфейса.
Никто не запрещает и сырые IP пакеты ловить. Или филтрьом firewall слать пакеты с нужным кодом протокла в свой usersapce. Даже вполне быстро будет.
Главное ещё чтобы через NAT провайдера пролезло.
Да это даже не самое главное. На моей памяти всего у пары провайдеров были серые IP. Обычно -- белый. Другой разговор, что частенько "для безопасности пользователей" могут на файерволе что-нибудь намутить.
У мобильных операторов белых IP не припомню, других провайдеров не имею.
AWS - на интерфейсе EC2 виртуалки всегда серый IP. Вот сейчас глянул на одну машинку - 172.31.28.50/20. Они унифицировали таким образом часть внутренних механизмов. На входе-выходе Интернета работает NAT (в широком смысле (*1)) для этого адреса. Свойства этого NAT (насколько он умеет лезть внутрь транслируемых протоколов) я не проверял, но должно быть расписано. А так как AWS это реально первый по PR и один из основных по толщине, его, мягко говоря, надо принимать во внимание.
(*1) Некоторые вендоры делят терминологию на NAT, который меняет только адреса хостов, и PAT, который ещё и порты меняет. Не 100% поддерживаю, но в сложных случаях надо иметь в виду.
В OpenStack совершенно точно можно виртуалку подключить напрямую в external network, но это неудобно - никакого DHCP в этом режиме не предусмотрено, а значит адрес интерфейсу придётся задавать скриптом инициализации (если уметь) или даже с системной консоли.
Поэтому вариант с серым IP на интерфейсе и 1:1 NAT на виртуальном роутере попросту удобнее.
Тут у AWS другое. Вот сравниваю с Vultr: у него по умолчанию (я ничего особого не просил) напрямую белый IP, роздан отдельным механизмом (параметры виртуалки, которые можно прочитать спец. тулзой). Что мешало так же другим сделать? Наверно, ничего. А вот то, что у AWS целая /20 (хоть и 172.чего-то) это показательно: входной NAT может разбрасывать один внешний IP на разные внутренние. У него это зовётся subnet для VPC, и применён даже для одиночного хоста.
AWS несколько иная история в отличие от обычных ISP, потому что AWS перекладывает ответственность за трафик на пользователя. Весь стек TCP/IP почти никак не блокируется так, чтобы пользователь не мог разблокировать его. А собственный транспорт как раз будет частью этого стека, хоть и неродной.
Плюс старое оборудование, которое просто дропает неизвестные ему протоколы.
Что касается DO и брандмауэра. А вы не пробовали просто не ассайнить файерволл дроплету?
Все это, как мне кажется, и объясняет, почему подавляющее большинство новых протоколов живут на уровне приложений. Вместо того чтобы бодаться с ОС и файрволлами, инженеры просто строят поверх чего-то, что уже работает. Например, QUIC — это фактически новый транспортный протокол, но он катается на UDP и избегает всей этой возни.
Нет, не поэтому. А именно по той причине, к которой автор догадками подобрался в конце статьи, но прямо так и не озвучил/не понял - это проблема миддлбоксов. То есть, машины посередине в сети могут отбрасывать пакеты с неизвестными им типами - особенно это будут делать файрволы, и конечно же, NAT-ы. Они ведь не знают, как натить какой-то новый протокол. Но и без натов никакой гарантии нет - вон, определение MTU в свое время сломали большинству интернета бездумными копипастами настроек файрволов про блокирование всего ICMP. Так что теперь в ходу костыли типа MSS fix. И это с известным протоколом - люди просто не читают документацию, как автор статьи - что уж говорить о неизвестных...
Просто узлы "на пути" ничего отбрасывать не должны, так как существует довольномго много протоколов их модификаций.
Хорошее, годное требование! Я с ним полностью согласен! Его даже стандарты предписывают соблюдать!
Один только нюанс: на практике это не работает (они отбрасывают). И я в предыдущем комменте даже сокращенно описал, почему. Могу еще короче с чуть другой стороны - увы, в интернете нет тоталитарного диктатора, который запретил бы им так делать.
У нас тут с некоторых пор кое-какие (кхе-кхе) узлы даже обычные TCP/UDP дропают.
Про protocol=0 очень хорошо написано в man 7 ip - https://man7.org/linux/man-pages/man7/ip.7.html
Про SOCK_RAW - отлично написно в man 7 raw - https://man7.org/linux/man-pages/man7/raw.7.html - и да, RAW не означает что вы будете ловить весь трафик. Вам дадут только тот протокол к которому вы привязали сокет
Если же вы хотите влезть на совсем-совсем низкий уровень - вам нужен AF_PACKET + SOCK_RAW - смотрите man 7 packet - https://man7.org/linux/man-pages/man7/packet.7.html
NAT полагается на порты
Даже не близко. Если бы это было правдой, у вас бы не работал например ping через NAT. А он работает. SNAT/DNAT с подменой порта это один из механизмов, но механизмы могут быть и намного проще, например просто подмена IP источника или получателя, и в такую настройку пролезет любой протокол.
SNAT/DNAT это линуксизмы, за которые в приличном сообществе предписывают рот с мылом вымыть. В стандартах описаны совсем другие термины для NAT/NAPT.
Когда сообщество перестанет полагаться на предписанное, а начнет полагаться на реалии - тогда и станет приличным. А пока мылом сами можете употреблять по обозначенному назначению.
Вот как раз приличное сообщество полагается на предписанное стандартами, а то и пишет их - да, "реалии" это Cisco, Juniper, Huawei и множество других. А линукс ваш - студенческая поделка, тем более с таким подходом к стабильности ABI.
На этой студенческой поделке добрая половина интернета держится, если не больше. А вовсе не на цисках.
Не надо путать оконечные сервера (где поделку допиливают и поддерживают корпорации) с роутингом/натом. В последнем роль поделки выше хомячкового колхоза не поднимается.
Медицина тут, увы, совершенно бессильна.
Зачем медицине пытаться оживить труп пингвина? Они даже RFC на Netlink оказались не в состоянии актуализировать. Все крупные вендоры уже давно всё поняли, и там, где студенческой поделки не избежать, ей предлагается роль исключительно запускалки - например, в любом проекте на DPDK. Дурачки ведутся на хайп "линукс! швабода!", профессионалы же всё понимают.
А, я понял, болезный, ты застрял в начале нулевых. Вопросов более не имею, медицина тут всё так же бессильна.
Точняк, DPDK с VPP это ж начало нулевых! И XDP на eBPF тоже пытается похоронить убогого SNAT/DNAT-старичка видимо тоже еще в начале нулевых. Действительно, медицина в твой адрес бессильна.
Что ж, придется разжевать: не в частностях, мой хороший, в целом.
XDP на eBPF тоже пытается похоронить убогого SNAT/DNAT-старичка
Звучит это утверждение примерно так же, как утверждение "pon пытается похоронить ip", хотя любая аналогия слегонца прихрамывает. Эти вещи в несколько разных плоскостях находятся.
Ну давай, расскажи мне, которого именно на такие задачи последние годы нанимали (иногда с требованиями буквально "сделай conntrack"). Вот та херовина, в которой есть дебильнейшие понятия SNAT/DNAT - зовись она iptables, или xt, или еще что угодно из этой зоны заражения - от неё любой вменяемый вендор пытается уйти на что-то более адекватное, как только прочухает тему.
Коим боком здесь терминология, спросит неискушенный человек со стороны? Разумеется, впрямую никак (что и дает повод недалеким буратинам орать, как в этом треде) - это лишь просто симптом из разряда "как вы яхту назовёте", иллюстрирующий стиль мышления авторов (и некритичных применятелей), который уже и будет определять хорошесть/долгосрочность технологии. В стандартах RFC нет никаких SNAT/DNAT, и любому хорошему инженеру с высшим образованием понятно, почему, и как скоро это местечковое понятие отомрёт.
Ставлю лет на 20, никак не меньше
И это никак не зависит от того, на сколько твоя ненависть к snat/dnat обоснована (или от его "хорошести", если угодно). Я, в общем, и сам был бы не против (без фанатизма), чтобы snat/dnat исчез, но этого не будет в ближайшие годы, как бы это кому нравилось или не нравилось. Так что, всё таки, прибереги мыло для себя, инженер с высшим образованием, можешь им рамочку с дипломом помыть.
Я, единственно, хочу уточнить - у тебя персонально к snat/dnat ненависть, или все-таки к conntrack в том виде, в котором он существует?
Они даже RFC на Netlink оказались не в состоянии актуализировать.
IETF RFC на netlink - нинужен. По-нормальному его надо уже давно перекинуть в status=historic. Это внутренний линуксовый механизм, зачем на него общеинтернетовский стандарт?
Или ты думаешь, что его могли сделать кросс-вендорским и применить, например, на OS X, как у автора статьи? Что-то слабо верится.
Все крупные вендоры уже давно всё поняли, и там, где студенческой поделки не избежать
Я согласен с плачем на conntrack, он местами ужасен, но дальше ты перегинаешь. Альтернативы умолчательным серверу приложений или не сильно крупному сетевому серверу (или ещё пачке применений) ещё очень долго не будет.
Просто менять IP не хватит, иначе нельзя было бы делать 2 пинга одновременно, сейчас оно работает только потому что у пинга есть идшники.
Кароч в общем виде на уровне ip nat не реализовать, он должен знать конкретные реализации всех протоколов которые хочет пробрасывать.
Помоему это достаточно очевидно, что NAT-а на сетях провейдеров предназначены только для трансляции ICMP, UDP и TCP. Слышал, что некоторые NAT-ы умеют в IPsec, но это не точно.
К сожалению, в современном мире возможность использовать все фичи IP протокола доступна не только лишь всем, а только тем кто располагает глобально маршрутизируемыми IP адресами. Но и это условие не является достаточным. Облачные провайдеры частенько прогоняют через NAT весь трафик независимо от каких адресов он исходит и требуется ли трасляция. Некоторые гоняют трафик через "прозрачные" сетевые экраны (маршрутизатор без маршрутизации) и тут тоже могут быть затыки с нестандартным protocol number.
С другой стороны, в локальной сети можно творить всё что угодно. :)
Но может ли иметь смысл, вообще, реализация своего протокола для каких-то узких, ограниченных, специфических случаев? Типа, не надо кросс-платформенности, не надо NAT, фаерволлов, маршрутизаторов, интернета, гарантий доставки пакетов (хотя UDP ж и так не гарантирует?) - вот есть какая-то унутренняя сеть, которую мы считаем абсолютно надёжной, и надо зачем-то выжать из неё всю возможную производительность, можно ли этого достичь, выбросив из протокола оверхед на всё вышеперечисленное? Или TCP/UDP хватит всем? Я пытался как-то задать этот вопрос этому, как их... высокочастотному трейдеру?... думал, может, им надо, они ж и каналы отдельные до биржи прокладывают специально для себя, и всё такое. Но понят я не был - собеседник посмотрел с недоумением: "Аа? Чоа? Протоколы?... Ну, TCP, UDP... Чо ещё-то?..."
Не только имеет, но и делают - например, DCTCP, модификация TCP для датацентров. Или в каком-нибудь IoT свои протоколы. Понятно, это как раз те случаи, где набор подсетей контролируемый единой администрацией, в отличие от большого Интернета, где все вышеозвученные проблемы есть.
высокочастотному трейдеру?... думал, может, им надо, они ж и каналы отдельные до биржи прокладывают специально для себя, и всё такое. Но понят я не был - собеседник посмотрел с недоумением: "Аа? Чоа? Протоколы?...
Так надо было технаря, непосредственно работающего на низком уровне, спрашивать, а не этих финансовых дураков.
Проблема своего протокола ещё в том, что вам для него придётся или драйвер писать или к raw socket-ам обращаться (по крайней мере на *nix). Второе требует повышения привилегий для всех приложений, которые будут его использовать.
Серверные NIC умеют в offload всего и вся (почти) по стеку TCP, UDP. Даже TLS. Если процессора с запасом, то разницы не заметите. А если как Netflix гоняете трафик, то будете еще пропускную способность каналов памяти высчитывать.
Вообще вопрос здравый, но не думаю, что результат будет.
Смысл есть, но и проблем много. Tcp и udp довольно старые и при этом не сказать, что идеальные протоколы. Например механика контроля соединения tcp при работе в локалке с большим потоком данных избыточен, но и отсутствие контроля доставки udp может напрягать.
Но почти всегда просто делают что-то поверх udp.
А всякие TCP_NODELAY, «квик-квак» и пр. разве не спасают?
Нет. Вот, например, вам надо быстрое восстановление после разрывов. У TCP время на восстановление (то есть когда стороны сделают очередной повтор и на него придёт ACK) не меньше, чем время лежания. Не было линка 20 секунд - восстановление передачи по TCP уже после восстановления линка не меньше 20. И при этом он ещё и будет разгоняться с минимальной скорости, 1 пакет (или даже 1 пакет минимального MTU) за один RTT. Если передача шла быстрее - ещё несколько секунд на разгон. Это намеренное поведение для "доброжелательности" в общем Internet, обосновано наукой.
Теперь у вас свой ДЦ. Вы сами рулите политикой загрузки каналов. Вы знаете, что будет нормально, если повторы будут идти каждые полсекунды, ваши каналы выдержат. Вы можете объяснить это уровню TCP в ядре? Нет, не можете, у вас нет ручек, которые для этого можно было бы покрутить: вас лишили их намеренно.
А над этим уровнем логики ещё два: первый на скорость разгона на максимум возможного и второй, наоборот, на её смягчение (смотреть по словам, например, Reno, Vegas, NewReno, хотя есть и аналоги поновее). Они могут не соответствовать поведению сети вашего ДЦ - и опять у вас маловато ручек для настройки (хотя тут уже в Linux можно грузить свои модули... их ещё писать надо).
QUIC как раз работает поверх UDP. Но с ним свои заморочки. Невыключаемый TLS - в условиях ДЦ вообще нафиг не нужен. Все коннектятся каждый раз на один и тот же входной порт, один ядерный сокет обрабатывает это, редирект можно сделать только позже. (Подозреваю, что уже есть где-то хаки с разделением в зависимости от отправителя. ChatGPT говорит "Since Linux 4.1, SO_REUSEPORT supports attaching a BPF program to a socket group using SO_ATTACH_REUSEPORT_CBPF or SO_ATTACH_REUSEPORT_EBPF. This allows custom logic to determine which socket in a group should receive the datagram." Claude - про tproxy module. Хм.)
Свои протоколы никто не будет писать потому, что их ещё биржа должна поддержать при этом. А вот свои реализации TCP\IP стека на FPGA - это часто явление.
думал, может, им надо, они ж и каналы отдельные до биржи прокладывают специально для себя, и всё такое. Но понят я не был - собеседник посмотрел с недоумением: "Аа? Чоа? Протоколы?... Ну, TCP, UDP... Чо ещё-то?..."
Зависит от рельефа местности. Полный оверхед Ethernet+IPv4+UDP это 54 байта. Где-то свои пакеты сильно толще, там переход на свой транспорт поверх "тёмного" волокна будет дороже всей прибыли. Где-то тоньше, там или страдают, или стараются сделать что-то другое.
Я в схожей задаче использовал транспорт типа надёжной доставки (то есть повторяет пока не получит ACK) с сильно лимитированным временем между повторами (не как TCP, где до единиц минут - норма) поверх UDP. В датаграммах могли собираться несколько сообщений целевого уровня, что спасало от оверхеда инкапсуляции. Точного средства не помню, помню дух реализации, и таких пара десятков точно есть. Фактически они и сделали свой протокол, на том же уровне, что TCP. Только за счёт этого кто-то не сильно в теме, как ваш собеседник, мог не понять и не назвать ключевую деталь.
По факту, строить что угодно поверх UDP это путь для подавляющего большинства самопальных разработок. И не только, см. QUIC. У этого есть свои проблемы, но уже на больших масштабах.
Позанудствую: Дарвин вообще не похож на BSD ни в каком месте. Но да, имеет сателлит совместимости с системными вызовами BSD, как еще много других для совместимости много с чем. И сетевой стек местами наследует алгоритмы и структуры данных из BSD.
А статья годная.
Ну как, именно по совместимости он и похож на BSD во многих местах. Причем это ведь не эмуляция / чисто в сокетах (как можно было бы сказать про винду), проще было прямо код из BSD и брать, и они и брали - те же sysctl, kqueue, файрволы... Да даже в стыренных утилитах натыкаешься на проблемы, которые в самих BSD уже двадцать лет как пофиксили, гг.
Доходит только первый пакет ...
Остальные не нужны ...
Кому это может быть нужно ...
Мой внутренний параноик окончательно проснулся, ну да, это уже было - <a href="https://habr.com/ru/articles/168607/">пакет смерти</a>, но тогда шумиха быстро утихла. Почему-то сразу вспомнилась оголтелая борьба с хуавеем, с чего бы это вдруг, неужто боятся что проект "интернет судного дня" накроется медным тазом?
А тут ещё и ipv6 пошёл в массы ...
Да, чудны дела твои... В свое время всем, кто претендовал на звание Advanced User рассказывали про содержимое файла /etc/protocols поясняя что там, и зачем это нужно. А нужно было, хотя бы потому что IP-сети тогда совсем не были безальтернативны. Наоборот, сети на IPX были куда как более в фаворе. А тем, кто хотел Network Administrator еще и про ether-type и зачем нужно оно. Да много еще всякого в сетевых стеках хватает. Например 4addr в 802.11.
Да, конечно - стоило бы еще упомянуть RFC1700 как документ, имеющий непосредственное отношение к данной статье.
Наоборот, сети на IPX были куда как более в фаворе.
А я когда-то писал свой двухмодульный "проксер", чтобы осуществить побег через Novell-маршрутизатор, который маршрутизировал только IPX/SPX, в другую подсеть, где параллельно на машинах был и TCP/IP. Все для того, чтобы попасть в интернет, так как в моей подсети TCP/IP не было. :) Хоть и однопотоковый, но схема работала. :)
История из разряда "покататься по странам с по-своему нарисованноым паспортом", понятно что против устоявшейся флоры транспортного уровня не пойдешь, но очень приятно осознавать, что узлы "относительно" адекватно реагируют на такие вещи, хотя чтобы реализовать эту схему на полную катушку, думаю можно просто инкапсулировать этот протокол в нормальные пакеты, а потом у себя, после дмз, раскрыть обратно и работать на своём иноземном протоколе
мира и добра. Для понимания всего нужна отбросить привычные рамки и вернутся к нулям и еденичкам при передачи информации забуть новые нмодные обвязки с сделать нова забытое старое но на современном инструменте ии может мы не знаем не видели как не видя слона данные ходят по всему электро сетям по воздуху и может скрыто по кабелям и о чуда скорость передачи вырастит в огромных масштабах и никто не помешает в обмене информацией. Так как сейчас провайдер лезть в трафик. И решает за нас
Статья интересная и такие опыты очень крутые, НО: сетевую диаграмму, приложенную в начале статьи, вообще нельзя считать на 100% корректной и тем более публиковать ВО ВСЕХ учебниках по сетям. Просто пропущен канальный уровень, на котором ходят кадры (идентифицирующиеся при помощи MAC-адресов). Нельзя такую схему рисовать в учебниках для сетевиков. Иначе все начнут думать, что после сетевого уровня с IP адресами сразу же идет физический (провода, беспроводная связь вроде WI-Fi и тд).
Похоже, вы не считали иронию.
идентифицирующиеся при помощи MAC-адресов
А это не специфика Ethernet и т.п.? Какие мак адреса в SLIP или PPP?
Это диаграмма уровней TCP/IP согласно IETF, где OSI уровни 1-2 объединены и 5-7 - тоже, их различие для них несущественно. Можете эту схему увидеть в RFC791 или RFC1122. Да, для того, кто воспитан на OSI схеме, кажется, что тут что-то не так.
(Разумеется, в полном варианте обе схемы не всегда корректны, потому что туннелирование вводит инверсию порядка уровней в месте стыка сторон туннеля. Но это отдельная тема.)
Отличный проект для лабораторной работы в Вузе!
Эксперимент — межконтинентальный.
Нет :)
Что я поняла: Поездка удалась, с этим как-то связано IPv6
Что я запомнила: Существуют протоколы, они как-то связаны с передачей от сервера клиенту.
Зачем я это читала: Зацепил заголовок, а еще я думала, что я умная и пойму как устроен интернет.
Выводы: может быть в другой раз, а может и не стоит забивать творческую головушку дизайнера всякими пустяками)
Все равно спасибо за статью)
Не хотела никого обидеть комментарием, скорее пыталась в самоиронию, наверное стоило сформулировать так:
Как дизайнеру, мне было сложно. Но теперь я хотя бы представляю IPv6 как супер-скоростную дорогу для пакетов, по которой могут проехать даже выдуманные протоколы… правда всё равно предпочитаю, чтобы эту дорогу проектировали вы, а я просто катаюсь 😃 Автору спасибо за попытку просветить даже таких гуманитариев, как я!
Пс: Коровка из символов просто прелесть, забрала)
Хотел заметить, что кроме TCP и UDP есть еще SCTP, RDP, UDPlite.
Но потом проверил таблицу возможных протоколов IPv4, так она почти полностью забита уже:
Что будет, если не использовать TCP или UDP?