共用方式為


流量加速

Front Door 可最佳化從使用者至原點伺服器的流量路徑。 本文說明如何將流量從使用者路由傳送到 Front Door 和原點。

重要

Azure Front Door (傳統) 將於 2027 年 3 月 31 日遭到淘汰。 為了避免任何服務中斷,請務必在 2027 年 3 月之前,將 Azure Front Door (傳統) 設定檔移轉至 Azure Front Door 標準或進階層。 如需詳細資訊,請參閱 Azure Front Door (傳統版) 淘汰

Front Door 可最佳化從使用者至後端伺服器的流量路徑。 本文說明如何將流量從使用者路由傳送到 Front Door,以及從 Front Door 路由傳送至後端。

選取要求的 Front Door 邊緣位置 (任一傳播)

在全球許多國家/地區中,Front Door 有超過 150 個邊緣位置或網路節點 (PoP)。 每個 Front Door PoP 皆可為任何要求提供流量。

若流量路由傳送至 Azure Front Door 邊緣位置,DNS (網域名稱系統) 和 HTTP (超文字傳輸通訊協定) 流量皆會使用任一傳播。 任一傳播可讓使用者要求透過最少的網路躍點,到達最近的邊緣位置。 此結構可充分發揮分割 TCP 的效益,為使用者提供較佳的來回行程時間。

Front Door 會將其邊緣位置分類為主要及後援。 外圈的邊緣位置較接近使用者,可減少延遲。 發生問題時,內圈的邊緣位置可進行外圈邊緣位置的容錯移轉。

外圈是所有流量的偏好目標,但仍需要內圈來處理外圈的流量溢位。 Front Door 提供的各前端主機或網域皆會獲派主要和後援 VIP (虛擬網際網路通訊協定位址),該位址由內圈和外圈邊緣位置所宣告。

Front Door 結構可確保使用者的要求一律會到達最近的 Front Door 邊緣位置。 若偏好的 Front Door 邊緣位置狀況不良,所有流量便會自動移至下一個最近的邊緣位置。

連線至 Front Door 邊緣位置 (分割 TCP)

分割 TCP \(英文\) 是一個可降低延遲與 TCP 問題的技術,能將會產生較高來回時間的連線分割成較小的片段。

分割 TCP 可讓用戶端的 TCP 連線終止於靠近使用者的 Front Door 邊緣位置內。 系統會建立不同於原點的 TCP 連線,而該個別連線可能會有較長的來回時間 (RTT)。

下圖說明不同地理位置的三位使用者如何連線至靠近其位置的 Front Door 邊緣位置。 Front Door 與歐洲原點則維持較長程的連線:

圖表說明 Front Door 如何使用與使用者最接近 Front Door 邊緣位置的簡短 TCP 連線,以及與來源建立較長的 TCP 連線。

建立 TCP 連線時,用戶端與伺服器間需要 3 至 5 趟往返。 Front Door 結構可改善建立連線的效能。 透過使用者與 Front Door 邊際位置間的「短程連線」,連線在 3 至 5 趟短程 (而非 3 至 5 趟長程) 的來回行程便能完成,進而可降低延遲。 Front Door 邊緣位置與原點間的「長程連線」可預先建立,並重複用於其他使用者要求,節省連線時間。 建立 SSL/TLS (傳輸層安全性) 連線時,分割 TCP 的效果便會加乘,因為有更多趟來回行程以保護連線安全。

分割 TCP 可讓用戶端的 TCP 連線終止於靠近使用者的 Front Door 邊緣位置內。 系統會建立不同於後端的 TCP 連線,而該個別連線可能會有較長的來回時間 (RTT)。

下圖說明不同地理位置的三位使用者如何連線至靠近其位置的 Front Door 邊緣位置。 Front Door 與歐洲後端則維持較長程的連線:

此圖說明 Front Door 如何使用短 TCP 連線到最接近使用者的 Front Door 邊緣位置,以及與後端的較長 TCP 連線。

建立 TCP 連線時,用戶端與伺服器間需要 3 至 5 趟往返。 Front Door 結構可改善建立連線的效能。 透過使用者與 Front Door 邊際位置間的「短程連線」,連線在 3 至 5 趟短程 (而非 3 至 5 趟長程) 的來回行程便能完成,進而可降低延遲。 Front Door 邊緣位置與後端間的「長程連線」可預先建立,並重複用於其他使用者要求,節省連線時間。 建立 SSL/TLS (傳輸層安全性) 連線時,分割 TCP 的效果便會加乘,因為有更多趟來回行程以保護連線安全。

下一步