Как улучшить TCP/IP для межпланетной глобальной сети?

Задний план

Это ближайшее будущее. После большой мировой войны и ограниченного обмена ядерными ударами народы Земли объединились в несколько блоков. Угроза новой войны и совокупный ущерб планете подстегивают огромные частные инвестиции в колонизацию космоса. Плавающие колонии окружают Землю и околоземные орбиты Солнца. Терраформирование Марса началось. Большой спрос на ресурсы за пределами Земли привел к тому, что добыча полезных ископаемых на астероидах распространилась по всей Солнечной системе.

В космосе возникло множество фракций. Ни у одной фракции нет достаточно ресурсов, чтобы построить систему связи, охватывающую всю внутреннюю Солнечную систему, особенно учитывая, что стоимость развертывания узлов связи высока (ракеты дороги). Конкурирующие фракции решают разработать совместную систему коммуникаций по образцу Интернета, в которой ни одна фракция не может доминировать.

Проблема

Набор протоколов Интернета (со слоями Link , Internet и Transport ) хорошо работает на Земле, где статические компьютеры соединены друг с другом кабелями. Кабели обеспечивают почти мгновенную связь, а проводные соединения редко меняются. В межпланетном масштабе возникают две основные проблемы.

  • Редкие соединения : Кабели на земле дешевы, но спутниковые тарелки, работающие на расстоянии AU, стоят больших денег, поэтому количество соединений, которые может иметь каждый узел, ограничено. Кроме того, соединения могут быть заблокированы в зависимости от положения относительно планет и солнца. Два узла могут не общаться часами или днями одновременно. Важно отметить, что большая часть разрушения запланирована из-за легко предсказуемых характеристик вращения и орбиты. Хороший набор протоколов будет иметь встроенную возможность оптимизировать физический путь передачи от узла к узлу, чтобы обеспечить доставку данных туда, куда они направляются, как можно быстрее, и чтобы двусторонняя связь не прерывалась без необходимости.

  • Задержка — время прохождения сообщения от одной стороны пояса астероидов до другой составляет около 45 минут. От Земли до Марса при максимальном сближении около 3 минут. Это важно, когда речь идет о рукопожатии TCP/IP или SSL. Протоколы должны минимизировать потребность в двусторонней связи без ущерба для безопасности. Кроме того, если пакеты в одном и том же TCP-сеансе шли двумя разными маршрутами из точки A в точку B; на Земле это незначительная разница во времени, но в космосе они могут прибыть с разницей в минуты или даже часы.

Техническое задание

Какой минимальный набор изменений вы можете внести в набор протоколов TCP/IP, чтобы оптимизировать его работу в межпланетных сетях?

Цель состоит в том, чтобы оптимизировать надежность, пропускную способность и свести к минимуму ненужные задержки.

Ноты

  • В настоящее время человечество ограничено внутренней Солнечной системой (за пределами пояса астероидов). Однако разработанный протокол должен быть расширяемым, по крайней мере, до пояса Койпера с временем ожидания до 10 часов.
  • Этот вопрос касается уровней канала передачи данных, IP и транспорта; предположим, что физический уровень работает нормально.
  • Вот отчет по протоколам космической связи , правда это для околоземного космоса. Вот обсуждение некоторых проблем с межпланетными сообщениями.
Я просто хочу отметить, что скорость света уже вызывает проблемы с задержкой здесь, на Земле. При наилучшем возможном соединении связь между США и Австралией не может быть лучше, чем около 150 мс, потому что именно столько времени требуется свету, чтобы пройти ~ 26 000 миль. Это мучительно медленно для некоторых приложений, таких как видеоигры FPS или прямые трансляции.
В последнем предложении вашего вопроса содержится гораздо лучшая информация, чем мы могли бы предложить.
(1) Обмен стеками компьютерных наук находится по адресу cs.stackexchange.com . (2) Это активная область исследований; начните со статьи Википедии о Межпланетном Интернете и перейдите по ссылкам. (3) Консультативный комитет по системам космических данных (CCSDS) , «состоящий из крупнейших космических агентств мира» (Википедия), координирует усилия.
Знаете ли вы, что я не только обожаю дирижабли, но и изучаю компьютеры? Во всяком случае, в разделе « Проблемы » говорится о проблемах на физическом уровне, но в конце вопроса вы говорите, что физический уровень работает нормально. Так что это сейчас?
Возможный дубликат: Обмен информацией в космосе (Полное раскрытие: принятый ответ принадлежит мне).
Слишком коротко для ответа, IP по сети с квантовой запутанностью.
Разве это не то, чем занимается сеть дальнего космоса НАСА?
@Renan Нет, сеть Deep Space Network предназначена для обеспечения полного обзора неба НАСА при вращении Земли. Он состоит из трех наземных станций, расположенных на расстоянии 120° друг от друга, что обеспечивает непрерывную связь.
@Schwern См. worldbuilding.meta.stackexchange.com/questions/6621/… для обсуждения точных и неточных наук. Другой - точная наука, так что это не дубликат.
Как работала электронная почта по коммутируемым линиям? Связь была дорогой, а задержка была высокой (из-за ожидания редких сообщений, а не из-за того, что сама линия была медленной). Ваш типичный почтовый сервер будет подключаться к нескольким другим почтовым серверам один раз в день, чтобы отправить все электронные письма этого дня, IIUC.
Это должно быть TCP ? Смогли бы вы обойтись чем-то, что не требует так много циклов, например, UDP или даже пользовательский протокол?
Хм, не относится к вопросу, но важно: связь на основе лазера. Тщательно размещенные и откалиброванные (действительно маленькие и, следовательно, несколько доступные по цене) спутники должны быть выбраны. Тем более, что он снижает задержку между двумя ссылками.
Кое-что для рукопожатий SSL и т. д.: используйте PGP (или аналогичный) для ВСЕГО! Таким образом, вам нужен только доверенный «индекс открытого ключа», и вы можете начать отправлять вещи всем, прикрепив свой открытый ключ.
@immibis Это зависит. Корпоративная электронная почта в основном использовала UUPC, часто напрямую подключаясь к модемам вашего почтового провайдера, вместо того, чтобы вообще использовать Интернет. Но для личной электронной почты вы часто подключаетесь к Интернету или, по крайней мере, к Интернету TCP/IP через SLIP или PPP, а затем используете протоколы на основе TCP, такие как IMAP, для получения почты и SMTP для ее отправки. Или даже через Telnet к ящику, где у вас есть оболочка для запуска интерактивного почтового клиента. Если вы возвращаетесь к 80-м годам, то вы набрали номер прямо в ящик, где у вас есть оболочка для запуска клиента.
@abarnert Это был риторический вопрос.

Ответы (10)

Очевидным ответом на устойчивые к задержкам сети является промежуточное хранение.

При использовании TCP, когда маршрутизатор получает пакет, он немедленно отправляет его следующему узлу или, если не может, отклоняет его и отправляет обратно сообщение об ошибке.

При использовании протокола с промежуточным хранением, когда маршрутизатор получает пакет, он ищет его в следующий раз, когда он ожидает, что сможет связаться со следующим узлом (возможно, выбирая из множества возможных вариантов в зависимости от того, насколько велик пакет, каков его размер). теги QoS говорят и т. д.) и сохраняет его до тех пор.

Store-and-forward восходит к SMTP, NNTP, UUCP и другим протоколам, существовавшим до общедоступного Интернета. До 1994 года, если ваша компания хотела иметь внешнюю электронную почту, это обычно означало, что ваш сервер подключался к вашему провайдеру два раза в день через UUCP и отправлял и получал все исходящие и входящие сообщения. Но современным DTN нужно что-то более детальное, чем «отправлять все на один хост два раза в день». (Кроме того, эти протоколы предназначены для сетей с нечастым подключением, но с малой задержкой при подключении, поэтому они выполняют намного более шумное рукопожатие, чем вам нужно для часто подключаемых, но с высокой задержкой.)

Между тем, промежуточное хранение на уровне крошечных IP-пакетов не так уж и полезно, поэтому вы добавляете способ для приложений определять пакеты из нескольких пакетов. Затем вы можете маршрутизировать, QoS и управлять перегрузкой целых пакетов (так что в идеале, когда вы случайно отправляете домой видео 4K вместо SD, время ожидания на вашем локальном маршрутизаторе истекает, вместо того, чтобы тратить всю пропускную способность и половину вашего интернет-провайдера). до падения). В качестве дополнительного преимущества пакеты могут быть достаточно большими, чтобы вы могли позволить себе такие функции безопасности, как маршрутизация на основе удостоверений, что также может быть важно для DTN.

Очевидный способ сделать все это — определить оверлейную сеть маршрутизации поверх UDP, очень похоже на то, как (после BitTorrent) сетки P2P работают как оверлей поверх UDP. (За исключением того, что, в отличие от типичной сетки P2P, вам нужен некоторый интеллект, поэтому вы не просто повторяете пакеты UDP с экспоненциальной задержкой и автоматической настройкой сетки, а вместо этого сохраняете программируемые расписания в своей таблице маршрутизации, потому что многие вещи будут предсказуемы. — не отскакивайте от этого лунного спутника в течение следующих 3 часов, потому что он заблокирован Луной…)

В последний раз я смотрел на это около десяти лет назад, и самым современным был экспериментальный протокол в RFC 5050 . С тех пор, вероятно, были успехи, и я, возможно, не все помню в точности.

Существует еще один RFC, предназначенный для сетей со сверхвысокой задержкой: RFC 2549 (IP через авиаперевозчиков) .
@TED ​​Я собирался сказать то же самое, но вижу, ты меня опередил. RFC2549 в основном все, что вам нужно :-)
Однако Store-and-Forward не работает для «живых» потоков, которые вам все равно могут понадобиться.
FWIW, RFC 5050 по-прежнему является самой новой версией протокола Bundle; новая седьмая версия в настоящее время находится в процессе превращения в RFC .
Искренне взволнован перспективой того, что мы действительно можем в конечном итоге использовать 2549 в один прекрасный день.
@TED: Если говорить более серьезно, некоторые ребята на самом деле внедрили RFC2549, а также изменения и настройки, которые им пришлось внести в сетевой стек Linux (я думаю, это то, что они использовали, возможно, это была одна из BSD). он работает с чрезвычайно длинными задержками пути, вероятно, имеет большое значение для этого вопроса.
@JörgWMittag Единственная проблема заключается в том, что они не добавили в протокол избыточность или проверку ошибок, что приводит к высокой потере пакетов при отправке эхо-запросов ICMP через IPoAC.
@TED ​​Это было бы отлично, к сожалению, носитель в RFC распространяется только в определенной среде, о которой известно, что она не присутствует в межпланетном пространстве в достаточных количествах.
Не потребует ли это также перезаписи BGP ?
Итак, космические цыплята наконец-то нашли применение?!

НАСА уже немного подумало об этом и разработало концепцию под названием «DTN» или Delay-Tolerant-Networking . По сути, он проверяет, возможно ли подключение к следующему «переходу» или станции, а затем отправляет данные. Если он недоступен, он сохраняет его в локальной памяти до тех пор, пока соединение снова не установится. Это может работать вместе или отдельно от традиционного TCP/IP.

Что касается инфраструктуры, я представляю масштабное решение, включающее ряд больших тарелок, разнесенных по планете так, чтобы по крайней мере одна из них всегда имела связь с данным местом или планетой. Эти тарелки действуют как мосты к остальной части Солнечной системы, передавая огромные объемы данных своим получателям по мере того, как соединения становятся доступными. Объединив их в сеть, они могут автоматически переносить его с одного блюда на другое по мере необходимости.

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

Что вы хотели бы сделать, так это сообщить сети, что вам нужна определенная информация, и загрузить ее с ближайшего узла, у которого есть эта информация. Таким образом, вы сможете быстрее получить информацию, если кто-то уже использовал эту информацию ранее. Примером текущей реализации этого является IPFS (межпланетная файловая система).

Он работает как гигантский рой битторрентов в том смысле, что он загружает необходимую информацию от ближайших пиров, у которых есть информация. Это уменьшает дублированный трафик по перегруженным/дорогим ссылкам и сокращает время, необходимое для получения необходимой информации.

Какой минимальный набор изменений вы можете внести в набор протоколов TCP/IP, чтобы оптимизировать его работу в межпланетных сетях?

Я немного удивлен, что никто еще этого не сказал, но вы бы не использовали ни TCP, ни UDP. Это не работает. Идея любого уровня живой связи за пределами околоземной орбиты неразумна. Путешествие до Луны туда и обратно составляет 2,6 с. У нас есть проводное подключение к Интернету, которое становится довольно изворотливым в суровую погоду, поэтому я действительно испытал скорость интернета, когда пакеты ICMP требовали более 2 с для передачи туда и обратно, и я могу сказать вам, что Интернет практически непригоден для эти условия.

Лучшее путешествие туда и обратно, на которое вы можете надеяться, между Марсом или Меркурием 6 минут 24 секунды и 6 метров соответственно. Следующее самое интересное место за пределами Марса — Юпитер, и ваше лучшее время в пути туда и обратно составляет более часа (69 минут 47 секунд).

Была упомянута сеть, устойчивая к сбоям/задержкам. DTN может подойти для орбитальных или, возможно, даже для сетевых подключений Земля-Луна, но помимо этого вы будете использовать что-то еще.

Межпланетные сетевые соединения не будут активными. На самом деле, у вас не будет постоянного подключения, не говоря уже о прямом подключении к любому планетарному интернету, кроме вашего собственного. Вы отправляете пакет с запросом очень конкретной информации и получаете ответную передачу через несколько или более минут, в рамках того, что вам приходится делить радиочастотный спектр со всеми остальными в Солнечной системе. Передача будет разбита на «пакеты», но не на пакеты в смысле TCP — больше похоже на пакеты в старом понимании Фидонета. Вместо повторного запроса данных вы просто повторите свой запрос, указав только те блоки данных, которые были потеряны или искажены; протоколы будут разработаны таким образом, чтобы иметь предсказуемую структуру данных, чтобы вы могли запрашивать только неверные данные.

Некоторые данные будут передаваться непрерывно, некоторые будут доступны через транспондер, а некоторые будут передаваться по какому-то расписанию.

Будет некоторая локальная синхронизация, хотя и не весь интернет. Википедия и другие большие базы данных, например, будут синхронизироваться локально. Обновления будут запрашиваться с указанной меткой времени, чтобы передавать только текущие данные синхронизации.

Связь в межпланетной сети больше походила бы на старую систему телетайпа, чем на старую систему BBS.

@Hobbamok напомнил мне, что микроволновая передача будет использоваться для прямой связи между поселениями, аванпостами и Землей. Вполне возможно, что лазер также будет использоваться там, где это уместно. Это сведет на нет проблему необходимости делить полосу пропускания между остальной частью Солнечной системы.

FidoNet является отличным примером. Я думал об UUCP и NNTP, но большинство из тех же причин, по которым FidoNet был лучше для небольших, но широко связанных операторов в 80-х годах, будут верны и в межпланетном будущем.
Но между тем, с небольшими изменениями, ваш Fido-подобный протокол может быть туннелирован через UDP точно так же, как и сам Fido. И это означает, что IPv7 UDP служит лингва-франка для соединения разнообразного набора протоколов более низкого уровня с разнообразным набором протоколов прикладного уровня (или пакетов протоколов где-то посередине) без необходимости реализации всего декартова продукта.
+1 за первое предложение. Мы бы использовали не TCP (или UDP), а что-то другое. Может и похоже, но не совсем то же самое.
Почему ВСЕ придерживаются радиоволн? В цивилизации, достаточно развитой, чтобы колонизировать планеты, что может помешать нам использовать точно откалиброванные лазерные линии связи? Гораздо меньшее время передачи, гораздо меньше шума и почти ОТСУТСТВИЕ энергопотребления по сравнению
@Hobbamok Я большой поклонник как лазера, так и микроволновки, поэтому я должен был включить это в свой пост. Я согласен с тем, что скорость передачи будет намного выше, что для выполнения той же работы требуется значительно меньшая мощность передачи, и, будучи в основном двухточечным, он не имеет ограничения, связанного с необходимостью делить частоты со всеми остальными в сети. Солнечная система. Спасибо что подметил это.
@Hobbamok, потому что эти опасения меркнут по сравнению с проблемой задержки.
@ilkkachu да, вот почему ЛАЗЕРЫ! или вы пытаетесь сказать мне, что свет в вакууме будет иметь большую задержку, чем радиоволны? [и в то время как в очень маленьких системах преобразование в свет является значительным временным фактором, этот сценарий является полной противоположностью]
@Hobbamok, насколько я знаю, лазеры ограничены скоростью света, как и радиоволны.
@ilkachu да, они есть. Теперь погуглите обе скорости (в вакууме) пожалуйста
@Hobbamok Они оба будут 3 x 10 ^ 8 м / с, не так ли?
@ Mr47 да, спасибо, что исправили мое неверное предположение, у них действительно одинаковая скорость. Я бы по-прежнему предпочитал лазеры для любой коммуникационной сети, где это возможно, поскольку вам нужно гораздо меньше энергии, если вы можете направлять свой поток информации. Но часть о скорости была неправильной, я думал, что радио каким-то образом похоже на звуковые волны.

Наименьший набор изменений, который вы можете сделать, это переключение с TCP/IP на UDP/IP. Самая большая проблема с TCP заключается в том, что ему необходимо проверить отправителя, чтобы убедиться, что пакет прибыл. Если это занимает 10 часов в одну сторону, то потребуется 20 часов, чтобы узнать, что сообщение, которое вы отправили, прибыло, и нужно ли вам повторно отправлять пакеты.

При использовании UDP этот этап проверки игнорируется. Если я хочу отправить сообщение, я могу отправить его за долю секунды. Если этого не произойдет, человек, который запрашивает данные, просто запросит их снова. Мне не нужно поддерживать соединение в течение 20 с лишним часов, просто чтобы убедиться, что сообщение пришло.

Вам также потребуется аутентифицировать и зашифровать свои данные с помощью общего ключа, который необходимо будет определить заранее, подобно ключу SSH, потому что динамическое шифрование было бы слишком неэффективным.

Добавлено -Редактировать: вопрос касается надежности, пропускной способности и низкой задержки. Вы просто не можете иметь их все. Если вам нужна надежность и высокая пропускная способность, вы не получите низкую задержку, а если вам нужна высокая пропускная способность и низкая задержка, она не будет надежной. Это треугольник, в котором вы можете максимизировать только два из трех. Если предполагается, что ваш физический уровень работает нормально, то использование UDP и перенос остальной логики на прикладной уровень даст вам лучшие результаты. Отсутствие рукопожатия и проверки означает, что у вас будет минимально возможная задержка, а пропускная способность и надежность в конечном итоге будут зависеть от вашего оборудования.

Правда в том, что ни один протокол не будет использоваться. Протоколы гарантируют разные вещи и служат разным целям. Если у вас есть удаленная база/зонд, связь с которой занимает 10 часов, вы не хотите ждать более 20 часов, чтобы увидеть прямую видеотрансляцию (рукопожатие, передача пакетов и гарантия заказа съедят все ваше время). Вы собираетесь использовать UDP, чтобы получить видео как можно быстрее (10 часов). Точно так же, если вы передаете файл, вам нужна надежность, и это может быть добавлено на уровне протокола (существует множество вариантов UDP или просто TCP) или на уровне приложения. Наконец, если вы хотите передавать огромные объемы данных, вы хотите доставлять их физически,

« Если этого не произойдет, человек, который запрашивает данные, просто запросит их снова » — подождите, разве это не просто TCP снова? UDP не может заменить TCP. UDP с доморощенными правилами повторной передачи для обеспечения надежности, упорядочения и проверки ошибок, вероятно, будет работать намного хуже, чем TCP.
@Bergi Нет. Повторные передачи не преобразуют UDP в TCP. Одним из фундаментальных свойств TCP является установление соединения , и нет смысла устанавливать соединение с задержкой в ​​несколько часов.
@Bergi Разница в том, что в UDP логика повторных попыток находится на уровне приложения, а не на транспортном уровне (4-уровневая модель, а не 7-уровневая OSI). TCP имеет смысл для приложений, которые не хотят заново изобретать это колесо, и будут оплачивать дополнительные накладные расходы на трехэтапное рукопожатие и разрыв 4-х пакетов в обмен на то, что позволяют коду TCP отслеживать неудобные биты. С 20-часовой задержкой эти накладные расходы были бы контрпродуктивными.
@maaartinus Конечно, повторная передача - не единственная функция, которая отделяет TCP от UDP, я только что выбрал это из ответа. Но что, если я хочу отправить большой (возможно, бесконечный) контент, который не помещается в один UDP-пакет? Если мне нужен межпланетный протокол с функциями TCP, «использовать UDP» — это не ответ.
@Bergi Что бы вы ни хотели, вы не хотите тратить 30 на установление TCP-соединения. Какой-нибудь надежный UDP или другой протокол будет работать намного лучше, чем TCP. Я сам написал ответ, уточняя это.
@MontyHarder «Выполнить логику протокола на прикладном уровне» не является ответом на вопрос «как бы выглядел протокол для XY». ОП ищет протокол, который не требует от всех изобретать велосипед. Если вы говорите, что трехстороннее рукопожатие для установления сеанса является единственным недостатком TCP, безусловно, есть способ избежать этого, не возвращаясь к UDP. См., например, QUIC или RUPD.
@Bergi Берги Я не говорил, что это единственный недостаток TCP. Я сказал, что это недостаток; «нарушитель сделки». Как указывает maaartinus, вам потребуется 30 часов только для того, чтобы открыть сокет, прежде чем вы сможете начать перемещение данных. Но я отвечал на ваше утверждение, что это «снова просто TCP», указывая на некоторые различия. Межпланетный протокол передачи (IPTP) должен быть разработан с нуля, чтобы отправлять много данных, а затем ждать, чтобы услышать, что было пропущено, прежде чем отправлять отдельные недостающие блоки, а не все после последнего ACK.
@MontyHarder Да, «снова просто TCP» было преувеличением. Я в основном оспариваю, что IPTP будет просто UDP или даже просто UDP с повторной передачей. Как вы сказали, его нужно переделывать с нуля.
@Bergi Многие люди разработали протоколы, лежащие поверх UDP, поверх которых можно накладывать другие протоколы. Например, RTMFP был сетевым протоколом для сетей P2P, который предоставлял интерфейс, подобный TCP-сокету, для приложения (хотя только для Flash Player в выпущенной версии), но под прикрытием использовал сокеты UDP. Почему? Потому что это позволяет написать ее как библиотеку пользовательского режима, которую можно добавить в любое приложение, вместо того, чтобы создавать ее как драйвер/службу и требовать специальных разрешений. UDP не слишком сильно мешает, поэтому вы можете использовать его, как если бы это был необработанный IP.
@Bergi Но я думаю, вы правы, что в ответе должно быть сказано, что вы будете строить поверх UDP, какие функции TCP вы создадите и как вы будете делать их иначе, чем TCP и т. д., а не просто что-то поверх UDP.
@abarnert Я знаю, я сам так делал :-) С UDP очень просто работать.

Кэширование

Загрузка от первого лица новой Игры Престолов занимает 20 часов. После этого копия сохраняется на кэширующем сервере, а второму человеку требуется всего несколько секунд.

Кэширование сохраняет результаты запросов локально, поэтому в первый раз оно работает медленно, пока получает информацию, но намного быстрее, поскольку она уже есть для дальнейших запросов. Сервер хранит только X объемов данных, поэтому самые старые запросы удаляются из конца очереди по мере ее заполнения.

Конечным результатом является то, что наиболее распространенные запросы хранятся локально и выполняются намного быстрее, а данных передается намного меньше.

Кэширование не помогает уменьшить RTT или количество циклов, необходимых для рукопожатия.
Нет, это не так, но проблемы с рукопожатием уже обсуждались, поэтому не было смысла давать этот ответ, если только я не хотел повторить всех остальных. На самом деле потребуется целый ряд изменений, необходимых для того, чтобы заставить его работать, важной частью которого будет встряхивание рук и кэширование.
Итак, вам нужен уровень HTTP поверх TCP? Да, это будет работать для передачи гипердокументов, но не для других приложений TCP.
Хотя обширное кэширование было бы необходимо, оно НЕ помогает ни с одним из вопросов OP.

Вам нужно изменить способ настройки вашей интернет-архитектуры, чтобы иметь кэширование целых веб-сайтов.

Нет причин беспокоиться о длительных простоях в Интернете, кроме как в виде сообщений, отправляемых с планеты на планету. Если у Интернета есть время простоя 20 часов только для загрузки списка веб-страниц и еще 20 часов для загрузки одной страницы, люди просто не будут этого делать.

Если вы хотите, чтобы люди пользовались Интернетом, каждой колонии нужны собственные серверы для хранения содержимого сети, которое они хотят видеть. Когда колонист подключается к сети, он общается только с локальным сервером. Локальные серверы обмениваются данными через спутниковую сеть, отправляя обновления другим колониям, которые загружают обновления. Таким образом, просмотр веб-страниц занимает секунды, даже если новости могут быть давностью несколько часов, что в любом случае ничего не поделаешь. Этот процесс отправки обновлений означает, что сеть децентрализована, а поскольку локальные компьютеры не обмениваются данными напрямую с Интернетом, трафик значительно сокращается. Если компьютеры взаимодействуют напрямую с Интернетом, маршрутизаторы не смогут обрабатывать весь трафик, особенно если они сохраняют пакеты во время простоя.

Когда серверы обмениваются данными, все пакеты отправляются одновременно, и соединение не поддерживается. Этот протокол работает с идеей хранения пакетов, предложенной другими ответами.

Если у вас есть несколько путей маршрутизации, по которым могут быть отправлены сообщения, каждый маршрутизатор на пути отправляет пакеты по всем доступным путям, а принимающий компьютер берет первый полученный и игнорирует дубликаты. Если пакет поврежден, он ожидает прибытия дубликата. Если через пару часов он получил только поврежденные пакеты или пакеты не пришли, он снова запрашивает пакеты.

Сообщения могут использовать другой протокол. Сообщения отправляются с сервера одной колонии непосредственно на целевой сервер, а не на какие-либо другие серверы в сети. Когда принимающий сервер получает сообщение, он отправляет сообщение на компьютер, который его получает.

С помощью этих методов серверы не могут позволить себе такую ​​роскошь, как открытие и закрытие портов. Они всегда должны следить за обновлениями, чтобы ничего не пропустить.

Преимущества этой конструкции:

Меньше компьютеров, отправляющих пакеты через межпланетные маршрутизаторы, значительно сокращаются круговые поездки, сервер всегда получает сообщение как можно быстрее, не требуется рукопожатие, несколько путей маршрутизации означают, что сеть может выдержать потерю нескольких спутников, почти мгновенная связь с локальным сервером , возможность отправлять обновления вместо того, чтобы их запрашивал клиент, отдельный протокол обмена сообщениями (никакие другие колонии не видят ваше сообщение для другой колонии).

То есть у каждой колонии своя сеть, а между ними интернет? А, вот как это уже работает сегодня.
@Bergi Некоторые особенности этой сети: каждая колония хранит свой собственный Интернет, пакеты отправляются по нескольким различным путям для избыточности из-за неэффективного характера запроса пакетов, а поскольку Интернет хранится на сервере клона, запросы почти мгновенные.
" Это собственный интернет " - но это локальная сеть, а не интернет , и вполне вероятно, что многие услуги в ней недоступны, например, когда вы хотите вести дела с другой колонией.
@Bergi Может быть, мой ответ был недостаточно ясен, у каждой колонии есть свой сервер / база данных, с которых люди в колонии загружают страницы. Например, когда кто-то заходит в SE и отвечает на вопрос, ответ отправляется с сервера колонии на все серверы на серверах других колоний, которые обновляют свои базы данных, чтобы показать, что на этой странице появился новый ответ. При такой настройке загрузка страницы происходит мгновенно, но если кто-то в другой колонии выполнит действие, произойдет задержка, прежде чем вы его увидите.
«Интернет» — это не отдельная база данных/сервер, его успех зависит от того, что каждый может настроить свой собственный сервер. Кто платит за каждую вторую колонию, в которой размещается копия моего сервиса? Кажется, это не масштабируется.
Кроме того, более серьезная проблема заключается в том, что каждое приложение (например, SE) теперь станет распределенным приложением, и их гораздо сложнее кодировать. Некоторые функции требуют синхронизации (например, вы удаляете свой вопрос, я публикую на него ответ, из разных колоний - одна система не позволяет удалить, потому что ответ уже есть, другая не дает размещать, потому что он был удален, что значит кого-то из третьей колонии видите?). В распределенной базе данных очень сложно добиться согласованности .
@Bergi OP сказал: «Ни у одной фракции нет достаточных ресурсов для создания системы связи, охватывающей всю внутреннюю солнечную систему ... Конкурирующие фракции решают разработать совместную систему связи, смоделированную в Интернете, где ни одна фракция не может быть доминирующей. У каждой колонии в Интернете есть только те страницы, которые она хочет. Если никто в колонии не заходит на example.com, нет причин использовать место для хранения этого веб-сайта. Думайте об этом как об очень динамичной системе кэширования, в которой кэш колонии периодически обновляется новыми данными, и колония отправляет новые данные другим колониям.
+1. Эта концепция была использована в фильме Джо Холдемана Forever Free.

Пропускная способность

Вы не указали, какая у вас пропускная способность.

Вы можете транслировать абсолютно тонны дополнительной информации, если у вас есть дополнительная пропускная способность. Например, межпланетный netflix вы можете транслировать 15 минут из 30 наиболее похожих фильмов вместе с фильмом, который вы смотрите, когда он подходит к концу, поэтому вы можете выбрать другой фильм для просмотра и сразу же начать его просмотр. То же самое может относиться ко всем видам данных.

Прогноз

Вы можете добавить к этому предсказание, аналогично тому, как работает Chrome, чтобы переходить по вероятным ссылкам, чтобы ускорить загрузку, если пользователь нажмет на них. Вам нужно будет добавить все эти данные в пакет. Вместо того, чтобы загружать домашнюю страницу Википедии, запрос к Википедии может предсказать, что вы, вероятно, просмотрите, и транслировать весь сайт или краткое изложение каждой страницы.

Бластинг данных

Вы также можете сделать что-то вроде взрыва данных из 90-х, когда информация будет отображаться на высокой скорости, а публика будет снимать ее на видео и воспроизводить в замедленном темпе, чтобы прочитать. Постоянно транслируйте все виды информации и кэшируйте ее, если это необходимо. Даже при низкой пропускной способности любые запасные «циклы» могут быть использованы для того, чтобы втиснуть дополнительную информацию.

Удаленное выполнение

Удаленное выполнение — это возможность отправить небольшую программу, которую можно выполнить на земле.

Например, вы хотите сыграть с кем-нибудь в межзвездные шахматы на спутнике Юпитера Ио. Вместо того, чтобы отправлять ход только для того, чтобы через 45 минут узнать, что это был недопустимый ход, потому что вы забыли, что находитесь под шахом, было бы быстрее, если бы небольшая шахматная программа была загружена и выполнена как на Земле, так и на Ио. Затем, когда сделан недопустимый ход, его можно проверить или изменить без необходимости его отправки.

Это похоже на проверку на стороне клиента в Javascript, когда вы пытаетесь отправить форму, чтобы подписаться на что-то, и забываете заполнить свой адрес электронной почты, он попросит вас заполнить его перед отправкой формы вместо того, чтобы отправить ее и получить ошибка обратно.

Другим примером этого является запрос клиентом информации о положении Земли на определенную дату. Вместо того, чтобы отправлять запрос и через 45 минут получать ответ, они могут вместо этого получить небольшую исполняемую программу, которая рассчитает это за них.

Кэширование

Очевидно, кэширование данных для повторного использования локально, но в более широком масштабе, размещение серверов на разных планетах/спутниках и кэширование на каждой из них. Например, большие новостные сайты будут популярны ежедневно, поэтому они будут распределяться и кэшироваться между всеми местоположениями. Другие данные также будут кэшироваться и храниться на основе просмотров. Это очень похоже на то, как работает складская система Amazon — товары, которые люди могут купить, автоматически распределяются по складам с использованием алгоритмов, которые предсказывают, что люди купят товары, что экономит время доставки.

Я полагаю, что одним из ключевых моментов, на который следует обратить внимание, является смена парадигмы, необходимая для развития Интернета. На самом деле это не вопрос того , как мы доставляем веб-страницы и текущий опыт работы в Интернете , это скорее вопрос о том, как бы выглядела всемирная паутина, если бы задержка была безумно высокой . . Вы бы переучили своих инженеров-программистов и переписали бы все свои инструменты, и Интернет был бы в основном основан на приложениях, вы, вероятно, загрузили бы приложение BBC News и обновили его автоматически каждое утро из локального кеша, либо загрузив весь сайт, или просто просматривая весь сайт локально из кеша.

IPTP (протокол межпланетной передачи)

IPTP — это двунаправленный протокол «точка-точка» с промежуточным хранением и высокой отказоустойчивостью.

Каналы IPTP определяются между планетами таким образом, что в любой момент времени на одной планете или на орбите вокруг нее находится ровно один передатчик, передающий потоковые данные на любой заданный массив приемников на другой. (Активный передатчик будет меняться по мере вращения планеты и спутников вокруг нее.) Этот поток должен иметь возможность мультиплексировать большое количество различных подпотоков данных (поступающих из множества различных источников в исходном планетарном Интернете), которые сами по себе будут быть поставлены в очередь в буферах для фактической передачи.

Весь поток будет разбиваться на «блоки» размера, соответствующего качеству канала, каждый из которых индивидуально закодирован с использованием исправления ошибок Рида-Соломона, а дополнительные блоки «четности» будут передаваться периодически, позволяя восстановить блоки, которые превышен порог исправления ошибок кода RS, используемого для этого блока. (IPTP позволяет изменять размер этого блока в зависимости от условий.) Каждый блок должен сохраняться на передающей стороне до тех пор, пока от получателя не будет получено подтверждение блока (BACK).

Для дополнительной надежности после передачи серии «строк» ​​(N блоков данных плюс блок четности XOR этих блоков данных) передается «строка четности» (создана путем XOR вместе соответствующих блоков в M последовательных строк). В конце группы (называемой «главой») из L страниц, состоящих из M строк и N столбцов, находится «страница четности» (создана путем операции XOR вместе соответствующих блоков на всех страницах). Вся глава (L+1)(M+1)(N+1)блоков должна использовать один и тот же размер блока и кодировку RS, но последующие главы могут изменить размер блока, а также значения L, M и N, как того требуют условия. Как правило, L, M и N будут больше, когда потребуется повторно отправить меньшее количество блоков.

Внутри главы подпотоки должны быть собраны в порядке приоритета, чтобы свести к минимуму количество блоков, несущих данные двух или более разных приоритетов. Приоритет передачи блока равен подпотоку самого высокого уровня приоритета, который он содержит.

Перед каждой главой находится заголовок, определяющий эти параметры. [Целевая группа по межпланетным передачам сообщает, что будущие версии IPTP могут расширить систему паритета до «книг» из K таких глав, (K+1)(L+1)(M+1)(N+1)каждая из которых будет включать блоки. IPTPv1 определяет K=1 без четности, поэтому в книге только одна глава.]

Метаданные «BACK» должны быть отправлены обратно от приемника к передатчику, чтобы подтвердить целые главы, а также диапазоны блоков внутри главы. Любые неподтвержденные блоки, предшествующие последнему подтверждённому блоку, должны быть переданы повторно. Решение о повторной передаче не должно приниматься до тех пор, пока не будет получена и декодирована вся «книга», поскольку блоки четности, строки, страницы (и главы), позволяющие полностью реконструировать BACK, еще не будут обработаны. Поскольку сам BACK занимает один или несколько блоков для BACK, всегда будет что-то для BACK, создавая неявное «поддержание активности» между узлами.

Метаданные (включая, помимо прочего, указанные выше BACK) имеют наивысший уровень приоритета для подпотоков и поэтому всегда должны быть первыми в книге/главе после заголовка протокола. Детали других соображений QoS все еще определяются IPTTF.

Как только поток данных реконструирован на принимающей стороне, он может быть демультиплексирован в подпотоки, каждый из которых отправляется в желаемое место назначения в планетарном Интернете.

Паритет XOR, правда?
Я думаю, что ОП больше интересовало, как работает маршрутизация, кэширование и работа с задержкой, а не то, какое обнаружение/исправление ошибок используется на канальном уровне.
Да, четность XOR. Это быстро и с возможностью параллелизма, что является обязательным условием для протокола, которому приходится иметь дело с метрикой проходящих через него данных. Обратите внимание, что отдельные блоки используют внутренние коды Рида-Соломона, но эти отдельные блоки могут быть переданы отдельным процессорам для исправления ошибок на уровне подблоков. Только те блоки, которые не могут быть исправлены кодами RS, будут нуждаться в дополнительной четности из схем KxLxMxN.
Кэширование также объясняется здесь. Весь поток данных, идущий с планеты A на B, должен быть кэширован до тех пор, пока он не будет восстановлен.
Должно быть, я упустил это во всех разговорах о страницах, главах и книгах. Где упоминается кеширование?
@Bergi Берги Я полагаю, что мог бы немного конкретизировать часть подтверждения Блока.

Капитальный ремонт — самое маленькое разумное изменение

  • При задержке в 10 часов вы, конечно же, не захотите устанавливать какое-либо соединение , так как только для этого требуется три пакета, что означает потерю 30 часов .
  • TCP-подобное управление перегрузкой не имеет смысла. Для максимальной эффективности вы хотите, чтобы ваши блюда были направлены именно на ту сторону, с которой вы общаетесь. Это верно как для отправителя, так и для получателя (будет либо фиксированная настройка, например «это блюдо связывается с Плутоном», либо заранее установленное расписание). Это устраняет любые перегрузки на самом канале . Ссылка всегда будет работать с фиксированной скоростью, если только она не нарушена.
  • Поскольку стоимость передачи намного выше стоимости хранения, каждый отправленный пакет также будет храниться до подтверждения (много часов спустя).

Я предполагаю, что надежный UDP приближается к тому, что необходимо. В любом случае, вы можете забыть об использовании сети для просмотра или чего-то подобного. Это будет больше похоже на SMTP. Вы отправляете сообщение, и оно будет доставлено, возможно, с задержкой на много часов из-за повторной передачи. У вас может быть некоторое взаимодействие клиент-сервер, но это будет больше похоже на запрос книги из библиотеки, чем на HTTP.

+1 за упоминание РУДП, -1 за второй пункт. Да, были бы отдельные ссылки между колониями вместо широковещательной передачи (ОП уже установил, что канальный уровень работает нормально), но нет, это не позволяет избежать перегрузок. В какой-то момент вы израсходовали доступную пропускную способность вашего канала, независимо от того, на каком физическом уровне он находится. Вы не перепутали "затор" со "столкновением"?
@Bergi Берги, я не уверен в формулировке, но нет. На канале точка-точка такого не будет. Отправитель будет отправлять с фиксированной скоростью, не будет потери пакетов, связанной с перегрузкой, не будет блокировки новых подключений (поскольку соединений не будет вообще, а пропускная способность останется прежней — вопреки тому, что Википедия говорит о перегрузке . Конечно, будут очереди и задержки, но на другом уровне. Обратите внимание, что в этом масштабе времени это может (и, вероятно, будет) даже регулироваться с помощью динамического ценообразования . Это не контроль перегрузки, подобный TCP.
Да, физический отправитель будет иметь фиксированную скорость - это пропускная способность. Но если несколько клиентов попытаются использовать это соединение для отправки данных, они могут захотеть отправить больше данных, чем способно это соединение. (Что также может происходить динамически в любом месте маршрутизируемой сети). Так что да, вы можете использовать очередь вместо отбрасывания пакетов, но в конечном итоге это перегрузка. Возможно, вы сможете гарантировать, что никакие пакеты не будут отброшены, но в какой-то момент клиентам потребуется отправлять меньше данных (чтобы не увеличивать очередь до бесконечности) или выбрать другой маршрут — управление перегрузкой.
@Bergi Берги, я согласен и отредактировал свой ответ. Будет перегрузка в сети, только не на ссылке. Поскольку ссылка намного дороже, чем хранилище, все будет поставлено в очередь. Отбрасывания пакетов не будет (за некоторыми исключениями), но будет динамическая маршрутизация, ранжирование и ценообразование.
@maaartinus Если вы все сделаете правильно, у вас все еще есть форма контроля перегрузки, просто она сильно отличается от той, что используется в TCP. Вы не можете допустить, чтобы очередь на межпланетном канале стала слишком длинной (даже при сложной TOS), поэтому вам необходимо оказать давление на внутрипланетную сеть, которая будет ставить в очередь или отклонять пакеты до того, как они попадут туда, и, в идеале, протолкнуть это все обратно к исходный хост. Когда вы пытаетесь отправить слишком большое сообщение, вы обычно сразу получаете сообщение об ошибке.
@maaartinus Кроме того, вы можете сделать контроль перегрузки более обнаруживаемым, а не чисто реактивным: приложение может видеть, что оно не может отправить ваше видео, и всплывающие параметры, чтобы пользователь мог решить (или проконсультироваться с его конфигурацией для заранее определенных правил) , чтобы переключиться на массовый, чтобы видео в конечном итоге прибыло примерно через 8 дней, или перейти к следующему тарифному классу, или отменить. Это еще больше отличается от того, что делает TCP, но, вероятно, еще более полезно.
@abarnert Согласен, но ... Я написал, что «управление перегрузкой, подобное TCP, не имеет смысла» и «устраняет любую перегрузку на самой ссылке ». Вы не согласны? В сети есть заторы (о которых я забыл в первой версии). +++Предварительное открытие — интересный момент. Нечто подобное, вероятно, произойдет внутри: когда ваш компьютер захочет отправить пакет, предназначенный для Плутона, он спросит у местного межпланетного отправителя, прежде чем даже пытаться. Вероятно, он отправит данные отправителю непосредственно перед передачей.
Как улучшить TCP/IP для межпланетной глобальной сети?
СпросиСетьПолитика конфиденциальности1y, 0v