TCP-Checks von unseren Knoten in Petah Tikva und Netanya (AS206446) versuchen einen SYN-ACK-Handshake zu Ihrem Host auf dem angegebenen Port und messen die Verbindungszeit. Dies überprüft die Port-Erreichbarkeit von israelischer Carrier-Infrastruktur aus – nützlich für die Bestätigung, dass Anwendungsports für israelische Nutzer offen sind, und für die Diagnose gemeldeter Konnektivitätsprobleme aus der Region. TCP-Checks spiegeln tatsächliche Firewall-Regeln und Routing-Verhalten wider, im Gegensatz zu ICMP-basiertem Ping.

Erwartete TCP-Handshake-Zeiten aus Israel: zu Frankfurt-Region-Zielen ~52–60 ms, nach Amsterdam ~58–66 ms, nach London ~63–70 ms, zur US-Ostküste ~128–138 ms. Diese spiegeln den zugrunde liegenden Kabel-RTT ohne Warteschlangenverzögerung wider. Ein TCP-Check, der schneller als diese Basiswerte abschließt, deutet darauf hin, dass das Ziel über Anycast zu einem lokalen oder regionalen Edge geroutet wird – beispielsweise wird ein über Cloudflare geproxyter Dienst den TCP-Handshake lokal an einem Tel Aviv PoP in unter 5 ms abschließen.

Ein fehlgeschlagener TCP-Check aus Israel, wenn der Port von Europa aus erreichbar ist, wird typischerweise verursacht durch: eine Firewall oder Sicherheitsgruppe, die Nahost- oder Nicht-EU-ASNs blockiert, eine GeoIP-Policy, die israelischen IP-Raum einschränkt, oder regionale Einschränkungen von Cloud-Providern. Ein Vergleich mit unseren türkischen und UAE-Region-Knoten hilft festzustellen, ob der Block Israel-spezifisch ist oder für den breiteren Nahost-IP-Bereich gilt.

Israels Internetinfrastruktur konzentriert sich auf den Großraum Tel Aviv, wo sich die wichtigsten IX-Einrichtungen, Rechenzentren und Carrier Hotels des Landes befinden. IIX (Israel Internet Exchange) betreibt den primären Peering-Fabric, der von inländischen ISPs, Content-Providern und CDN-PoPs genutzt wird. ISUOG fungiert als sekundärer IX. Beide befinden sich im Metro-Korridor Tel Aviv, wo der Großteil der israelischen Carrier- und Hosting-Infrastruktur physisch untergebracht ist. Petah Tikva und Netanya – die beiden Städte, in denen unsere Probe-Knoten betrieben werden – liegen etwa 15 km voneinander entfernt und fallen beide in diese metro-konzentrierte Zone.

Internationale Konnektivität aus Israel verläuft fast ausschließlich über Seekabel. Die FLAG- und SEA-ME-WE-Kabelsysteme landen in Haifa und Tel Aviv und bieten primäre Kapazität in Richtung Europa durch das Mittelmeer. Ein sekundärer Pfad verläuft über Land via Ägypten durch den Sinai. Der Pfad Tel Aviv – Frankfurt beträgt auf gut gerouteter Kabelkapazität ungefähr 50–60 ms. Tel Aviv nach London liegt bei etwa 60–68 ms. Tel Aviv nach New York beträgt über transatlantisches Kabel ungefähr 125–135 ms. Diese RTTs sind mit südeuropäischen Standorten vergleichbar und platzieren Israel in einem nützlichen Latenzbereich zur europäischen CDN-Infrastruktur.

Zu den großen israelischen Carriern gehören Bezeq International (AS8551), der das inländische Festnetz-Backbone betreibt, Partner Communications (AS12400), HOT Telecom (AS5486) und Cellcom. Der kommerzielle ISP- und Hosting-Markt wird von weiteren Anbietern bedient, darunter CLOUD LEASE (AS206446), der beide unserer Probe-Knoten hostet. AS206446 ist ein Cloud-Hosting- und Colocation-Anbieter mit Präsenz in Petah Tikva und Netanya, beide angebunden über das israelische inländische Backbone mit anschließendem Transit zu IIX und internationalen Gateways.

Israel hat eine der höchsten durchschnittlichen Festnetz-Breitbandgeschwindigkeiten in der Region, angetrieben durch weitreichende Glasfaser-Deployments und wettbewerbsfähige ISP-Preise. Der israelische Markt ist für seinen geografischen Standort ungewöhnlich gut gepeert – die Nähe zu Europa über Seekabel und aktive Teilnahme am IIX bedeutet, dass viele europäische CDN-Edges Israel mit Latenz bedienen, die mit dem vergleichbar ist, was südeuropäische Nutzer sehen. Akamai, Cloudflare und AWS unterhalten alle Edge-PoPs in der Region Tel Aviv.

Wir betreiben zwei Probe-Knoten in Israel – einen in Petah Tikva und einen in Netanya – beide über CLOUD LEASE (AS206446). Da beide Knoten im selben AS und Großraum liegen, sind die Ergebnisse typischerweise konsistent, aber das gleichzeitige Ausführen beider bestätigt, dass keiner der Knoten eine lokale Routing-Anomalie aufweist. Für Ziele mit Anycast oder GeoDNS sollten beide Knoten identische oder nahezu identische Ergebnisse liefern, angesichts ihrer geografischen Nähe und des gemeinsamen Upstreams.