Ping с наших израильских узлов (AS206446, CLOUD LEASE) в Петах-Tikve и Нетании отправляет ICMP-запросы и фиксирует время кругового обхода. Типичные RTT с этих точек: Тель-Авив–Франкфурт ~52–60 мс, до Амстердама ~58–66 мс, до Лондона ~62–70 мс, до Парижа ~55–63 мс, до Нью-Йорка ~128–138 мс, до Дубая ~25–35 мс, до Сингапура ~145–165 мс. Эти базовые значения предполагают чистую кабельную маршрутизацию по ёмкости FLAG или SEA-ME-WE без перегрузки на израильском международном шлюзе.

Одновременный запуск ping с обоих израильских узлов полезен для подтверждения согласованности. Оба узла находятся в одном AS и столичном районе, поэтому значимо различающиеся RTT между ними до одной цели будут указывать на локальное различие маршрутизации — например, один узел использует другой аплинк-транзитный путь — а не на географическое различие. На практике результаты из Петах-Tikva и Нетании отличаются не более чем на 2–4 мс для большинства направлений.

Ограничение скорости ICMP на транзитных маршрутизаторах распространено на путях из Израиля в направлении Европы, особенно на береговых станциях подводных кабелей, где несколько операторов агрегируют трафик. Если ping из Израиля показывает более высокое RTT, чем ожидалось, а TCP-проверка на том же хосте завершается с ожидаемой скоростью, разница обусловлена ICMP-обработкой, а не реальной перегрузкой пути. Повышенное RTT ICMP на одном конкретном хопе в MTR-трассировке без последующих потерь подтверждает это.

Интернет-инфраструктура Израиля сконцентрирована в столичном районе Тель-Авива, где расположены основные IXP-объекты страны, дата-центры и операторские узлы. IIX (Israel Internet Exchange) управляет основной пиринговой инфраструктурой, используемой внутренними провайдерами, контент-провайдерами и CDN-PoP. ISUOG служит вторичной точкой обмена трафиком. Обе расположены в коридоре столичного района Тель-Авива, где физически размещена большая часть израильской операторской и хостинговой инфраструктуры. Петах-Тиква и Нетания — два города, в которых расположены наши узлы-зонды — находятся примерно в 15 км друг от друга и оба попадают в эту столичную концентрацию.

Международная связность из Израиля выходит практически исключительно через подводные кабели. Кабельные системы FLAG и SEA-ME-WE выходят на берег в Хайфе и Тель-Авиве, обеспечивая основную ёмкость в направлении Европы через Средиземное море. Вторичный путь проходит по суше через Египет через Синайский полуостров. Путь Тель-Авив–Франкфурт занимает около 50–60 мс на хорошо маршрутизированной кабельной ёмкости. Тель-Авив–Лондон — около 60–68 мс. Тель-Авив–Нью-Йорк — около 125–135 мс через трансатлантический кабель. Эти RTT конкурентоспособны с южноевропейскими локациями, помещая Израиль в пределах полезного диапазона европейской CDN-инфраструктуры.

Крупные израильские операторы включают Bezeq International (AS8551), управляющий основной внутренней фиксированной магистралью, Partner Communications (AS12400), HOT Telecom (AS5486) и Cellcom. Коммерческий рынок провайдеров и хостинга обслуживается дополнительными провайдерами, включая CLOUD LEASE (AS206446), который является хостом обоих наших узлов-зондов. AS206446 — поставщик облачного хостинга и колокации с присутствием в Петах-Tikve и Нетании, оба обслуживаются через израильскую внутреннюю магистраль с транзитом к IIX и международным шлюзам.

Израиль имеет один из самых высоких средних скоростей фиксированного широкополосного доступа в регионе, обусловленный широким развёртыванием оптоволокна и конкурентными ценами на провайдерские услуги. Израильский рынок необычно хорошо связан для своего географического положения — близость к Европе через подводный кабель и активное участие в IIX означает, что многие европейские CDN-edge обслуживают Израиль с задержкой, сопоставимой с тем, что видят южноевропейские пользователи. Akamai, Cloudflare и AWS поддерживают edge-PoP в районе Тель-Авива.

Мы управляем двумя узлами-зондами в Израиле — одним в Петах-Tikve и одним в Нетании — оба через CLOUD LEASE (AS206446). Наличие двух узлов в одном AS и столичном районе означает, что результаты обычно согласованны, однако одновременный запуск обоих подтверждает, что ни один из узлов не имеет локальной аномалии маршрутизации. Для целей с Anycast или GeoDNS оба узла должны возвращать идентичные или близкоидентичные результаты, учитывая их географическую близость и общий аплинк.