MTR Test from Israel
2 nodes in Netanja, Petach Tikwa · IIX Tel Aviv
Israel — 2 Nodes
從以色列進行 MTR 路由追蹤
從我們以色列節點的 MTR,從 AS206446 向目標執行持續逐跳延遲和丟包測量。來自佩塔提夸或內坦亞的 CLOUD LEASE 流量,在到達 IIX 或國際閘道之前,先通過以色列上游過境業者出境。從以色列到歐洲的國際路徑走海底電纜——FLAG 或 SEA-ME-WE——通常透過特拉維夫或海法的著陸站,然後再透過地中海 PoP 向前過境。
從以色列到法蘭克福目標的典型 MTR:AS206446 內的 1–2 跳增加 1–3 ms,然後跳至以色列國際閘道約 5–8 ms,再通過賽普勒斯或埃及的電纜段增加 20–30 ms,再到達中歐過境抵達法蘭克福總計約 55–62 ms。電纜段跳的大幅延遲躍升是預期的,考慮到地理距離——這不是擁塞,而是數千公里海底電纜上的物理傳播延遲。
從兩個以色列節點到同一目標的 MTR 對路徑比較很有用。兩個節點在同一都會區和 AS,因此它們之間分歧的 MTR 路徑,將表明 AS206446 在多個上游過境業者上進行負載均衡。若一個節點顯示明顯更快的路徑,表明某個過境選擇與目標對等更好——這對於選擇哪個節點作為以色列可達性測試的主要參考很有用。
以色列網路基礎設施
以色列的網際網路基礎設施集中在特拉維夫都會區,全國主要的 IX 設施、資料中心和電信業者機房均位於此。IIX(以色列網際網路交換中心)運營主要對等互連架構,供國內 ISP、內容供應商和 CDN PoP 使用。ISUOG 作為次要 IX。兩者均位於特拉維夫都會走廊,以色列電信業者和主機代管基礎設施的大部分均實體設於此。我們的探測節點所在的佩塔提夸和內坦亞,兩城市相距約 15 公里,均在此都會集中區內。
以色列的國際連線幾乎完全透過海底電纜出境。FLAG 和 SEA-ME-WE 電纜系統在海法和特拉維夫上岸,透過地中海提供前往歐洲的主要容量。次要路徑透過西奈半島的埃及陸上路由。特拉維夫至法蘭克福的路徑在路由良好的電纜容量上約 50–60 ms。特拉維夫至倫敦約 60–68 ms。特拉維夫至紐約透過跨大西洋電纜約 125–135 ms。這些 RTT 與南歐位置相當,使以色列在歐洲 CDN 基礎設施的有用範圍內。
主要以色列電信業者包括運營主要國內固定線路骨幹的 Bezeq International(AS8551)、Partner Communications(AS12400)、HOT Telecom(AS5486)和 Cellcom。商業 ISP 和主機代管市場由包括 CLOUD LEASE(AS206446)在內的其他業者服務,CLOUD LEASE 託管我們兩個探測節點。AS206446 是在佩塔提夸和內坦亞有存在的雲端主機代管和主機代管業者,兩者都透過以色列國內骨幹連接,並向 IIX 和國際閘道進一步過境。
以色列的固定線路平均寬頻速度在該地區最高,由廣泛的光纖部署和競爭性的 ISP 定價驅動。以色列市場的對等互連狀況對其地理位置而言異常良好——透過海底電纜靠近歐洲,以及積極參與 IIX,意味著許多歐洲 CDN 邊緣以與南歐使用者相當的延遲服務以色列。Akamai、Cloudflare 和 AWS 均在特拉維夫地區維護邊緣 PoP。
我們在以色列運營兩個探測節點——一個在佩塔提夸,一個在內坦亞——均透過 CLOUD LEASE(AS206446)。在同一 AS 和都會區有兩個節點,意味著結果通常一致,但同時執行兩者可確認沒有任何節點有本地路由異常。對於有 Anycast 或 GeoDNS 的目標,鑑於兩個節點的地理接近性和共享上游,兩者應返回相同或幾乎相同的結果。