Comments 33
Осталось понять, кто из крупных игроков эту идею протестировал, хотя бы, в тестовом режиме.
TCP был создан для другой цели
В те времена максимальный полёт фантазии о компьютерных сетях будущего укладывался в сюжет художественного фильма «Терминатор». Предугадать появление ЦОДов и особенно карманных мейнфреймов с мобильной планетарной связью (смартфонов) и тик-токеров, забивающих своим «творчеством» каналы связи, не мог никто.
TCP разрабатывался на средства министерства обороны США, и предназначен для сохранения связности сети в случае масштабной ядерной войны. «Отцы интернета» проектировали транспортный протокол с предварительной установкой соединения, повторным запросом данных в случае их потери, решением проблемы дублирования при получении 2 копий одного пакета, и гарантией целостности передаваемых данных с уведомлением отправителя о результатах передачи.
Все эти функции получилось увязать в протоколе, одинаково точно выполняющем возложенные на него задачи в разных средах, в условиях масштабной ядерной войны:
наземной проводной телефонной сети: ARPANet USA
подводных межконтинентальных кабелях связи: ARPANet overseas
мобильных радио-станциях PRNet (packet radio network) — дальнобойных Wi-Fi роутерах на колёсах, которые могли замещать собою (временно или постоянно) уничтоженную взрывом кабельную линию.
космических спутниках SATNet (Atlantic packet satellite network), поддерживающих связь между сегментами сети на разных континентах, физически изолированных войной друг от друга.
Протокол обеспечил связность на суше, под водой, в воздухе и космосе. Делал это надёжно, прозрачно, стабильно. Продолжает это делать 50 лет спустя на скоростях в миллионы раз быстрее. Отцы интернета, безусловно, справились на 5+.
Очень похоже на описание udp
Да, вот непонятно, нафига в статье сравнение с TCP, если описываются свойства UDP? Почему с ним не сравнить?
Но UDP же не даёт гарантированной доставки и управления потоком, а обсуждаемый протокол — даёт.
RDS даёт.
Что-то гуглятся только Russian Drift Series, Remote Desktop Services и Amazon Remote Database Services. Кажется, ничего из этого не является протоколом транспортного уровня...
Reliable Datagram Sockets (RDS) — протокол передачи данных, разработанный совместно корпорацией Oracle и компанией SilverStorm в 2006 году, основан на аппаратных возможностях шины передачи данных InfiniBand. Протокол предусматривает возможность доставки датаграмм без установки соединения, обеспечивает высокоскоростную передачу данных и низкий уровень задержек в поддержку аппаратных возможностей Infiniband.
Есть протокол QUIC на базе UDP, пока используется только в браузере Chrome
И почти все что описано в статье, есть в этом протоколе
Оптимизирована для максимальной пропускной способности при минимизации задержки.
Асинхронная работа. - т.е. в рамках одного подключения, может быть передано параллельно несколько сообщений.
Поддержка масштабирования на стороне приёма (RSS). - это тоже самое, что и получатель передает обратно гарантии для управления скоростью отправки сообщений.
он не расчитан на передачи терабайт на скоростях 100-400Gbps
там много интересных спецэффектов появляется
Нет. Вот даже близко нет.
Асинхронная работа. - т.е. в рамках одного подключения, может быть передано параллельно несколько сообщений.
Нет. В QUIC нет сообщений, там есть только неструктурированные байтовые потоки - аналог TCP.
Поддержка масштабирования на стороне приёма (RSS). - это тоже самое, что и получатель передает обратно гарантии для управления скоростью отправки сообщений.
Абсолютно нет. Receive Side Scaling - это аппаратная поддержка в сетевухах раскидывания входящих пакетов на разные ядра/CPU, например путем взятия хэша от адреса:порта. А описанные в статье гранты (а не гарантии) - это механизм flow control, схожий с размером окна. Совсем из другой оперы.
Оптимизирована для максимальной пропускной способности при минимизации задержки.
А это вообще маркетологическое блабла, за которым ничего конкретного не стоит.
Ну вот и сравнили, только плюсов внезапно стало в 2-3 раза меньше. Чет подозрительно это, когда такие перекошенные сравнения проводят...
Наконец, TCP предполагает, что пакеты будут приходить к получателю в том же порядке, в котором переданы отправителем, и непоследовательное прибытие пакетов означает их потерю.
Абсолютно неверно. Протокол TCP допускает что пакеты могут идти разными путями от отправителя к получателю, приходить в разнобой, теряться в пути и т.д.
Я бы не хотел, чтобы последовательно отправленные сообщения приходили вразнобой. Это ломает многие виды логики, требует переупорядочивания на прикладном уровне у получателя, усложняет отладку и тестирование, и вносит доп фактор непредсказуемости в работу системы.
В частности так случается постоянно когда у вас инфраструктура повышенной надежности из свичей, на уровене L2 в виде полносвязного графа. Классика — 4 свича которые соединены 2х2. Позволяет заменить свич без даунтайма.
Есть же Reliable Datagram Sockets давно. Почему с ним не сравнивается? Какие преимущества перед ним?
Этот протокол не поддерживает логическое "соединение". Из сего следует что это конкурент UDP, а потому его безграмотно сравнивать с TCP.
Ну да, если все ,что есть в ТСР не нужно.. а там есть гарантия доставки, то и первичное требование о гарантии доставки не важно, ну и да, автор текста не автор перевода, дискутировать тут не с кем. А то все очень интересно, а категоричность высказываний, противоречащая своим же требованиям даёт вопросы, а не ответы.
Вопрос почти в тему. 2023-й год на дворе, а голосовой траффик у н...ас в..сё ещё... перрриод...чески сссссс ла...гами и обрыв..ми. Неужели нельзя придумать какой-то особый протокол для уменьшения этих проблем? Почему бы не помечать пакеты голосовые пакеты и давать им больший приоритет? Даже вроде в IPv4 есть что-то про приоритет. Или отправлять голосовые пакеты двумя или, может, пятью размыми маршрутами, чтоб хоть одна копия пришла в вовремя и т.п.?
Оно всё уже давно придумано (хоть DSCP), но наличие на соответствующих участках сети поддерживающего оборудования и умеющих его настраивать админов - совсем другая песня.
Или отправлять голосовые пакеты двумя или, может, пятью размыми маршрутами, чтоб хоть одна копия пришла в вовремя и т.п.?
А это рецепт, как не устранить лаги, а наоборот создать их (и эхо), поскольку на разных маршрутах - разная задержка.
не понял вашей логики.
да, на разных каналах задержка разная, но так мы отправляем пакеты по всем каналам сразу.
скажем, три независимых канала, на каждом средняя задержка 50мс, но с вероятностью 10% есть проседание до неприемлемых 2000мс. если мы отправляем пакеты на всех трёх канала сразу и берём первый пришедший пакет, то вероятность получить 2000мс уже получается 0.1%, с чем вполне можно жить.
TCP — плохой вариант для дата-центров. Встречайте новый протокол Homa