Как бы быстро он ни работал, ни один кэш-сервер не в состоянии сохранить все. Неизбежно наступает момент, когда какой-либо пользователь запрашивает отсутствующие в кэше данные, которые затем медленно передаются по Internet. Однако эту проблему можно смягчить посредством организации взаимодействия между несколькими кэш-серверами так, чтобы они могли получать информацию друг от друга. В RFC 2187 описан протокол кэширования Internet (Internet Cache Protocol, ICP) для организации иерархической структуры кэшей.
В иерархической (или многосвязной) структуре каждый кэш устанавливает отношения с другим кэшем. Отношения бывают двух типов: подчиненные и равноправные. При отсутствии запрошенного объекта кэш посылает запрос ICP о наличии требуемого объекта у какого-либо из равноправных кэшей. В случае его отсутствия и у равноправных кэшей запрос направляется вышестоящему серверу. Типичная иерархия кэшей показана на Рисунке 2.
Связывая кэш-серверы между собой, ICP порождает и некоторые проблемы. Одна из них состоит в том, что запросы ICP создают посторонний сетевой трафик. Чем больше кэш-серверов в группе, тем больше трафик. Как следствие, масштабируемость такого решения ограничена.
Другая проблема с ICP состоит в том, что со временем такие группы серверов оказываются избыточными. В конечном итоге у каждого из серверов в группе появляются свои копии часто запрашиваемых URL. По этой причине ICP постепенно вытесняется протоколом маршрутизации для группы кэш-серверов (Cache Array Routing Protocol, CARP), предложенным Microsoft.
В случае CARP кэш-серверы отслеживаются посредством «списка членства в группе», автоматически обновляемого с помощью функции Time-to-Live (TTL), регулярно проверяющей дееспособность активных серверов. Затем с помощью алгоритма хэширования определяется, кто из членов группы должен обслуживать запрос к конкретному URL.