TCP-проверки с наших узлов в Петах-Tikve и Нетании (AS206446) выполняют SYN-ACK-рукопожатие с вашим хостом на указанном порту и измеряют время соединения. Это подтверждает доступность порта из израильской операторской инфраструктуры — полезно для проверки того, что порты приложений открыты для израильских пользователей, и для диагностики сообщений о проблемах с подключением из региона. TCP-проверки отражают реальные правила брандмауэра и поведение маршрутизации, в отличие от ICMP-ping.

Ожидаемые времена TCP-рукопожатия из Израиля: до целей в районе Франкфурта ~52–60 мс, до Амстердама ~58–66 мс, до Лондона ~63–70 мс, до восточного побережья США ~128–138 мс. Они отражают лежащий в основе RTT кабеля без штрафа за постановку в очередь. TCP-проверка, завершающаяся быстрее этих базовых значений, предполагает, что цель Anycast-маршрутизируется на локальный или региональный edge — например, сервис, фронтируемый Cloudflare, завершит TCP-рукопожатие локально на тель-авивском PoP менее чем за 5 мс.

Неудавшаяся TCP-проверка из Израиля при доступности порта из Европы обычно вызвана: брандмауэром или группой безопасности, блокирующей ближневосточные или не-ЕС ASN, GeoIP-политикой, ограничивающей израильское IP-пространство, или региональными ограничениями облачного провайдера. Сравнение с нашими турецкими и узлами ОАЭ помогает определить, является ли блокировка израильской специфической или применяется к более широкому диапазону ближневосточных IP.

Интернет-инфраструктура Израиля сконцентрирована в столичном районе Тель-Авива, где расположены основные 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 оба узла должны возвращать идентичные или близкоидентичные результаты, учитывая их географическую близость и общий аплинк.