Как переданный одному из узлов работает с tcp?
TCP, будучи с сохранением информации, должен потребовать, чтобы последующие пакеты достигли того же сервера. Выполнения HTTP (Не сохраняющие состояние) сверху TCP, и CDN's могут использовать передачу любому из узлов.
Таким образом, как TCP работает с передачей любому из узлов? Что, если syn и ack переходят к различным серверам? Я думаю, что услышал, что Google имеет некоторое решение этого, но я не уверен.
Ответьте и за IPv4 и за IPv6, если существует какое-либо различие.
Это одна из тех многочисленных проблем, к решению которой можно подходить по-разному. Самый простой подход - игнорировать его и надеяться на лучшее. До тех пор, пока маршрутизация не изменит среднее соединение, все будет хорошо. Но когда маршрутизация все же изменится, она разорвет все те соединения, на которые повлияет изменение маршрутизации. Другие ответы уже углубляются с этим подходом.
Другой подход заключается в отслеживании того, куда маршрутизируются соединения. Если пакет маршрутизируется к неправильному POP, CDN может туннелировать пакет к правильному POP для дальнейшей обработки. Это действительно приводит к дополнительным накладным расходам, клиент будет испытывать повышенную задержку, как только это произойдет. Эта повышенная задержка будет сохраняться в течение всего срока действия соединения. Но это, скорее всего, лучше для пользователя, чем прерванное соединение.
С точки зрения потребления полосы пропускания, накладные расходы не очень значительны, потому что они влияют только на пакеты в одном направлении, и это, как правило, направление с наименьшим использованием полосы пропускания.
Отслеживание может осуществляться на уровне соединения или с помощью отслеживания, который является предпочтительным POP для обслуживания IP-адреса каждого отдельного клиента. Наиболее очевидной структурой данных для отслеживания соединений была бы распределенная хэш-таблица
Если клиент поддерживает MPTCP, есть другое решение, которое можно было бы использовать. Как только соединение будет установлено, сервер откроет еще один подток, используя одноадресный IP-адрес. Если такое подпотоковое соединение успешно установлено, то соединение может пережить изменение маршрутизации адреса anycast, просто используя адрес unicast на оставшееся время жизни соединения.
В принципе, все вышеперечисленные подходы будут одинаковыми для IPv4 и IPv6. Но на практике некоторые решения могут не работать так же хорошо для IPv4 из-за недостатка IP-адресов.
Например, подход MPTCP требует, чтобы каждый сервер имел публичный IP-адрес для хорошей работы. При большой балансировке нагрузки может быть слишком много серверов для присвоения каждому из них публичного IP-адреса. Кроме того, установка нового подтока не может быть инициирована сервером, если клиент находится за NAT, что часто бывает в случае IPv4. Это означает, что сервер должен будет вместо этого отправить одноадресный IP-адрес как опцию над начальным подпотоком и позволить клиенту инициировать дополнительное подпотоков.
Я не знаю, какой из вышеперечисленных подходов был использован CDNs.
.Она работает лучше, чем вы ожидали, особенно для TCP сессий, которые обычно довольно кратковременны, как те, которые генерируются HTTP клиентами.
Anycast предполагает, что топология сети не будет меняться в течение сеанса, и если она все же изменится, маловероятно, что другая конечная точка внезапно окажется ближе к той, с которой сеанс был согласован. Прикладной протокол должен обрабатывать такие действия по отключению/восстановлению связи.
CDN очень хорошо работают на Anycast, так как вся их бизнес-модель - это кратковременные TCP-сессии со значительным однонаправленным сетевым переносом из своей сети. Если ACK-поток заканчивается где-то в другом месте, кроме конечной точки, для которой он изначально согласовывался, соединение будет зависнуть для этого одного актива.
Anycast лучше всего описывать как схему маршрутизации "от одного к другому", и обычно это работает, когда BGP (Border Gateway Protocol) объявляет IP-адреса назначения из нескольких источников, в результате чего пакеты маршрутизируются к ближайшему из IP-адресов назначения, перечисленных в списке. Итак, в широком смысле, anycast используется только для того, чтобы выяснить, к какому серверу подключаться. в нем нет ничего, что делает его непригодным для TCP, или для работы в сети.
Основным случаем использования anycast являются CDN (Content Delivery Networks - сети доставки контента), которые, как правило, имеют кратковременные и/или не имеющие постоянного соединения - как и следовало ожидать при доставке большого количества небольшого, статического содержимого веб-страницы. В этом случае, предположение anycast о том, что топология сети останется неизменной, по крайней мере, на протяжении всего сеанса, является достаточно безопасным, учитывая короткую продолжительность типичного сеанса, а также минимальные последствия того, что это предположение становится ложным - в худшем случае, сеанс не удаётся в середине, и пользователь перезагружает веб-страницу.
Недостатком использования anycast для более длинных сеансов или для использования, которое не терпит сбоев, является то, что топология сети с большей вероятностью изменится в течение более длительного периода времени, и в этом случае соединение будет беззвучно прервано. (Pop-switching.) Как вы упоминаете в вашем вопросе, Google (и другие) работают над проприетарными методами решения этой проблемы, но пока это всё проприетарно и секретно.
Так что ответ на ваш вопрос о том, как работает anycast с TCP, на самом деле заключается в том, что он работает просто отлично, если только топология сети не изменится... если топология изменится, то она [потенциально] разорвётся.
Здесь есть интересная презентация (предупреждение, pdf) с реальными данными об использовании anycast, включая некоторые долгоживущие сессии, и кажется, что в реальном мире "переключение поп-трансляций" (когда топология сети меняется в середине сессии и разрывает соединение) - это очень редкий опыт - в одном наборе данных 683 204 сессии, и 23 795 сессий длиннее 10 минут, только в 4 сессиях переключение поп-трансляций происходит.
.