逐步指南:使用 Microsoft Exchange Server 2003 SP2 部署 Windows Mobile 裝置

了解 Direct Push 技術

發佈日期: 2006 年 12 月 22 日

Direct Push 技術使用 Exchange ActiveSync 將 Windows Mobile 裝置上的資料與 Microsoft Exchange 伺服器上的資料保持同步。因而不再需要仰賴 SMS 進行通知。

Direct Push 技術

Direct Push 包含兩部分:一部份存在裝置上 (用戶端),另一部份存在 Exchange Server SP2 郵件伺服器上。下列清單說明這項技術的這些部分:

  • 含 MSFP 的 Windows Mobile 裝置。裝置上的 ActiveSync 技術管理著 Direct Push 與 Exchange 伺服器的通訊。它會與伺服器建立 HTTP 或 HTTPS 連線並維持一段指定的時間,然後在等候伺服器回應時進入睡眠狀態。伺服器以狀態予以回應,指出有收到新項目,或是沒有任何新項目到達。裝置接著會傳送同步處理要求或另一個 Direct Push 要求。發生這些情況的速率完全是根據 OEM 或業者設定的參數,以及業者網路和客戶公司網路上的閒置 HTTP 或 HTTPS 連線可維持多久來進行動態調整。

  • Exchange Server 2003 Service Pack 2。這個版本的 Exchange Server 包含一個 Direct Push 元件,可增強 Exchange ActiveSync 基礎結構來支援手動和排定的同步處理。Exchange Server 使用透過 IP 的通知,在資訊一到達伺服器就馬上將電子郵件、連絡人、行事曆和工作更新傳遞給裝置。

當伺服器上的資料發生變更時,該些變更會經由 Direct Push 所使用的持續 HTTP 或 HTTPS 連線傳輸給裝置。行動業者網路中的逾時值會識別在沒有活動的狀態下,將維持多久的持續連線。

為了防止此連線在進行各項更新之間逾時,裝置會在伺服器回應時重新發出要求。此種定時的傳輸就稱為「活動訊號」。維持伺服器連線以進行 Direct Push 的正是活動訊號,每個活動訊號都會警示伺服器裝置已經準備好可以接收資料了。

Direct Push 程序

Direct Push 流量看起來像是對網際網路網站花很長一段時間發出要求的小型 HTTP 要求。Microsoft 建議使用安全通訊端層 (SSL) 來加密封包內容,如此一來,Direct Push 流量就難以透過探查被識別出來。

下列步驟提供 Direct Push 程序的概觀:

  1. 用戶端對 Exchange 伺服器發出 HTTP 訊息,稱為 ping 要求,要求伺服器報告在指定的一段時間內發生在使用者信箱內的任何變更。

    在 ping 要求中,用戶端指定 Exchange 應該監視變更的資料夾。這些資料夾通常是收件匣、行事曆、連絡人和工作。

  2. Exchange 在收到這項要求時,會監視指定的資料夾,直到發生下列其中一種情況為止:

    • 時間限制到期。時間限制是由網路路徑中最短的逾時所決定。

      若發生此情況,Exchange 會發出 HTTP 200 OK 回應給用戶端。

    • 其中一個資料夾中發生變更,例如郵件抵達。

      若發生此情況,Exchange 會對要求發出回應,並識別發生變更的資料夾。

  3. 用戶端透過下列其中一種方式對 Exchange 伺服器的回應予以反應:

    • 若收到 HTTP 200 OK 回應指出未發生任何錯誤,它便重新發出 ping 要求。

    • 若收到 HTTP 200 OK 以外的回應,它會對每個發生變更的資料夾發出同步處理要求。當同步處理完成時,它便重新發出 ping 要求。

    • 若未在指定的時間內收到 Exchange 伺服器的回應,它便縮短 ping 要求中的時間間隔,然後重新發出要求。

Direct Push 動態調整

在上述的 Direct Push 程序期間,裝置會先等候連續往返,之後才嘗試調整需要將伺服器連線保持開啟狀態的時間量。伺服器在傳送 OK 給用戶端之前所需等候個人資訊管理員 (PIM) 變更或新郵件抵達的時間量,就稱為活動訊號間隔。

活動訊號間隔是由用戶端指定,並且是作為 ping 要求的一部分傳送。活動訊號是以預設的速率開始。用戶端上的 Direct Push 演算法接著會動態調整活動訊號間隔,以便在不超過逾時值的情況下,維持活動訊號間的最大時間。該項調整是以網路狀況,以及業者和公司網路上的閒置 HTTP 或 HTTPS 連線可維持多久時間,還有一些業者可以指定的設定為依據。

為了決定最佳的活動訊號間隔,演算法會保存 ping 要求的記錄。如果 ping 要求收到回應,則演算法會增加間隔。如果在間隔的最後還是沒有收到任何回應,用戶端就會判定網路已逾時,並縮短間隔。

藉著使用這套演算法,用戶端終可判斷出在行動網路和公司防火牆間最久的可能閒置連線時間。

下圖顯示在典型的 Direct Push 通訊期間,用戶端與 Exchange 伺服器之間是如何調整活動訊號間隔。

Cc182234.direct_push(zh-tw,TechNet.10).gif

網站內容

本圖中的「T」表示時間的進展。

下列步驟說明通訊的過程,當中的數字與圖中的數字相對應:

  1. 用戶端經由網際網路對 Exchange 伺服器喚醒並發出 HTTP 要求,然後進入睡眠狀態。

    為了讓工作階段保持作用狀態,要求會指出活動訊號間隔,也就是伺服器在傳送 OK 給用戶端之前應該等候個人資訊管理員 (PIM) 變更或新郵件抵達的時間量。在此圖中,活動訊號間隔為 15 分鐘。

  2. 因為活動訊號間隔期間並沒有任何郵件抵達,所以伺服器傳回 HTTP 200 OK。

    在本例中,因為業者網路或公司網路無法維持長存的 HTTP 連線,所以回應遺失了,用戶端因而完全沒收到回應。

    Cc182234.note(zh-tw,TechNet.10).gif 附註:

    如果連線被前端 Exchange 伺服器關閉,裝置將通知結束的工作階段,並馬上重新連線。

    如果連線被後端 Exchange 伺服器關閉,則裝置不會通知結束的工作階段,並會等到活動訊號間隔結束才重新連線。

  3. 用戶端在活動訊號間隔結束時再加 1 分鐘 (共 15 + 1 = 16 分鐘) 後喚醒。

    Cc182234.note(zh-tw,TechNet.10).gif 附註:

    裝置等候連續往返,之後才嘗試調整活動訊號間隔。演算法中有個調整元件可以將指定的遞增值變更為其他值。

    如果此連續往返並沒有收到伺服器的回應,它便會發出一個存留時間較短的要求 (8 分鐘)。

    在本例中,因為活動訊號在最後一次 ping 期間並沒有增加,所以活動訊號遂變為最小的活動訊號值 (8 分鐘)。

  4. 因為活動訊號間隔期間並沒有任何郵件抵達,所以伺服器傳回 HTTP 200 OK。

  5. 伺服器回應喚醒用戶端。由於連線在間隔期間並沒有逾時,於是用戶端判定網路至少能支援此時間長度的閒置連線。

    如果這是連續往返,則用戶端會判定它可增加下一個要求的間隔時間。

Direct Push 對網路和 Exchange 伺服器的影響

設定活動訊號的演算法也會將無線傳送的位元組減至最低,並充分利用電池壽命。

實作資料壓縮將可減少在前端伺服器與用戶端間傳送的封包大小。不過,耗用的頻寬量,以及它是否會影響使用者的資料方案主要視下列因素而定:

  • 使用者選擇同步處理的內容,例如不只是預設資料夾。

  • 信箱內和行動裝置上變更的資料量。

變更 Direct Push 設定的影響

為了幫助您在 Direct Push 期間維持適當的裝置效能,Microsoft 建議針對不同的 Direct Push 設定不同的值。

活動訊號間隔

活動訊號間隔是由行動業者在裝置上設定的。使用 30 分鐘的活動訊號間隔對電池壽命和頻寬的耗用皆有正面的影響。當允許 Direct Push 工作階段存留較長的時間時 (例如 30 分鐘),HTTP 的往返就比較少,收送的資料也比較少,還有裝置耗用的電源也較少。

過短的活動訊號間隔雖可讓使用者永遠處於最新狀態,卻會因為不斷 ping 伺服器而縮短電池壽命。

最小活動訊號

如果活動訊號低於最小活動訊號等級的裝置要求與 Exchange 伺服器建立連線,伺服器會記錄一個事件,向系統管理員指明 Direct Push 無法運作。

Exchange 工作階段

若要讓裝置資訊保持最新狀態,同時盡可能維持長久的電池壽命,Exchange 伺服器工作階段持續時間必須稍微大於最大活動訊號設定。如果伺服器工作階段比較短,它可能會到達閒置逾時,而致使它中斷工作階段。結果可能會造成郵件要等到用戶端重新連線後才可以傳遞,並且使用者可能有很長一段時間都無法同步處理。

防火牆逾時

網路閒置連線逾時表示在 TCP 連線建立完成之後,允許連線在沒有流量的情況下存留的時間長度。

防火牆工作階段間隔的設定必須能夠允許活動訊號間隔和公司工作階段間隔自由通訊。如果防火牆關閉工作階段,那麼郵件就要等到用戶端重新連線後才可以傳遞,並且使用者可能有很長一段時間都無法同步處理。藉著將防火牆工作階段逾時設為等於或大於行動業者網路上的閒置逾時時間,防火牆就不會關閉工作階段。

下面列出應該如何設定防火牆閒置連線逾時:

  • 業者必須將傳出防火牆上的閒置連線逾時設為 30 分鐘。

  • 公司也必須將他們傳入防火牆上的逾時設為 30 分鐘。

Web 伺服器、網路安全性應用裝置和系統網路堆疊都有幾個以時間為基礎的閥值,這些閥值的用意在於將它們與測試不足或惡意用戶端相隔離。您可以在不危害網路安全性的情況下,安全地增加閒置連線逾時設定。

在 Direct Push 的案例中,連線的閒置是介於提出 HTTP 要求時,與活動訊號間隔過期時或當伺服器在發生變更時 (例如收到郵件時) 回應要求之間發生的。Direct Push 對其工作階段的長度不會做任何假設;無論活動訊號間隔是一分鐘或三十分鐘,都會迅速傳遞電子郵件。

增加閒置連線逾時通常並不會增加或減少攻擊的風險。下表顯示一些攻擊的例子,並說明如何使用其他設定來減輕攻擊風險。

DoS 威脅

減輕攻擊風險

DoS 攻擊是因無法完成信號交換 (在建立 TCP 連線時私下進行) 而引起的。攻擊者試圖建立大量部分開啟的 TCP 連線。

增加閒置連線逾時與此類的攻擊無關。

必須完成 TCP 信號交換的時限與 Windows TCP/IP 堆疊所控制的閥值是不同的。

DoS 攻擊對 IIS 發動的方式是透過開啟大量 TCP 連線,但從不在任何連線上發出 HTTP 要求。

增加閒置連線逾時與此類的攻擊無關。

IIS 會要求用戶端在中斷連線之前一段特定的時間內提交完整格式的 HTTP 要求,來緩和此項威脅。IIS 管理主控台內 [連線逾時] 設定的名稱很容易造成誤解;TCP 連線是在超出 [連線逾時] 值 (預設為 120 秒) 時關閉。

攻擊者建立大量 TCP 連線,在所有連線上發出 HTTP 要求,但從不取用回應。

增加閒置連線逾時與此類的攻擊無關。

這項威脅可藉由上個案例設定的相同逾時加以緩和。IIS 中的 [連線逾時] 定義著用戶端必須在 TCP 連線建立完成後發出第一個要求的時限,或是在 HTTP 存留案例中發出後續要求的時限。

顯示: