TCP, будучи отслеживающим состояние, должен требовать, чтобы последующие пакеты достигли того же сервера. (Без сохранения состояния) HTTP работает поверх TCP, а CDN могут использовать anycast.
Так как же TCP работает с Anycast? Что делать, если синхронизация и подтверждение идут на разные серверы? Я думаю, что слышал, что у Google есть какое-то решение для этого, но я не уверен.
Пожалуйста, ответьте как для IPv4, так и для IPv6, если есть разница.
Это одна из тех многих проблем, к которым можно подойти по-разному. Самый простой подход - игнорировать это и надеяться на лучшее. Пока маршрутизация не меняет промежуточное соединение, все будет в порядке. Но когда маршрутизация действительно изменится, это приведет к разрыву всех соединений, на которые повлияло изменение маршрутизации. Другие ответы уже углубляются в этот подход.
Другой подход - отслеживать, куда направляются соединения. Если пакет маршрутизируется на неправильный POP, CDN может туннелировать пакет на правильный POP для дальнейшей обработки. Это приводит к дополнительным накладным расходам, клиент столкнется с увеличенной задержкой, как только это произойдет. Эта увеличенная задержка будет сохраняться в течение всего времени существования соединения. Но это, вероятно, лучше для взаимодействия с пользователем, чем обрыв соединения.
С точки зрения потребления полосы пропускания накладные расходы не очень значительны, потому что они влияют только на пакеты в одном направлении, и это, как правило, направление с наименьшим использованием полосы пропускания.
Отслеживание может выполняться на уровне подключения или путем отслеживания предпочтительного протокола POP для обслуживания каждого индивидуального IP-адреса клиента. Наиболее очевидной структурой данных для отслеживания соединений будет распределенная хеш-таблица.
Если клиент поддерживает MPTCP, есть другое решение, которое можно использовать. Как только соединение будет установлено, сервер откроет другой подпоток, используя одноадресный IP-адрес. Если такой подпоток успешно установлен, то соединение может пережить изменение маршрутизации произвольного адреса, просто используя одноадресный адрес в течение оставшегося времени жизни соединения.
В принципе, все вышеперечисленные подходы будут одинаковыми для IPv4 и IPv6. Но на практике некоторые решения могут не работать на IPv4 из-за нехватки IP-адресов.
Например, подход MPTCP требует, чтобы каждый сервер имел общедоступный IP-адрес для нормальной работы. В большой настройке балансировки нагрузки может быть слишком много серверов, чтобы каждому назначить общедоступный IP-адрес. Кроме того, создание нового подпотока не может быть инициировано сервером, если клиент находится за NAT, что часто случается с IPv4. Это означает, что вместо этого серверу придется отправить одноадресный IP-адрес в качестве опции поверх начального подпотока и позволить клиенту инициировать дополнительный подпоток.
Я не знаю, какой из вышеперечисленных подходов использовался CDN.
Он работает лучше, чем вы ожидаете, особенно для сеансов TCP, которые обычно довольно недолговечны, например, генерируемые HTTP-клиентами.
Anycast предполагает, что топология сети не изменится в течение сеанса, и если она изменится, маловероятно, что другая конечная точка внезапно окажется ближе, чем та, которая согласовала сеанс. Протокол приложения должен обрабатывать такого рода действия по отключению / повторному подключению.
Сети CDN очень хорошо работают на Anycast, поскольку вся их бизнес-модель - это короткие сеансы TCP со значительной однонаправленной передачей по сети. вне их сети. Если поток ACK попадает в другое место, а не в конечную точку, для которой он первоначально согласовывался, соединение для этого ресурса зависнет.
Anycast лучше всего описать как схему маршрутизации «один к ближайшему» и обычно работает, когда BGP (протокол пограничного шлюза) объявляет IP-адреса назначения из нескольких источников, в результате чего пакеты маршрутизируются на ближайший из перечисленных IP-адресов назначения.
Таким образом, в широком смысле anycast используется только для определения того, к какому серверу подключаться, и в этом нет ничего, что делало бы его неподходящим для TCP или сетей с отслеживанием состояния.
Основной вариант использования anycast - это сети доставки контента (CDN), которые обычно имеют недолговечные соединения и / или соединения без сохранения состояния - как и следовало ожидать при доставке большого количества небольших статических веб-страниц. В этом варианте использования предположение anycast о том, что топология сети останется неизменной, по крайней мере, в течение всего сеанса, является довольно безопасным предположением, учитывая короткую продолжительность типичного сеанса и минимальные последствия того, что это предположение станет ложным - худший случай. , сеанс завершается ошибкой в середине, и пользователь перезагружает веб-страницу.
Недостатком использования anycast для более длительных сеансов или для использования, которое нетерпимо к сбоям, является то, что топология сети с большей вероятностью изменится в течение более длительного периода времени, и в этом случае соединение будет тихо прервано. (Всплывающее переключение.) Как вы упомянули в своем вопросе, Google (и другие) работают над собственными методами решения этой проблемы, но пока все они закрыты и секретны.
Итак, ответ на ваш вопрос о том, как anycast работает с TCP, на самом деле состоит в том, что он работает нормально, если только топология сети не изменится ... если топология изменится, она [потенциально] сломается.
Есть интересная презентация здесь (предупреждение, pdf) с реальными данными об использовании anycast, включая некоторые долгоживущие сеансы, и может показаться, что в реальном мире «всплывающее переключение» (когда топология сети изменяется в середине сеанса и разрывает соединение) очень необычный опыт - в одном наборе данных с 683 204 сеансами и 23 795 сеансами продолжительностью более 10 минут только 4 сеанса были переключены.