Office 365 的效能疑難排解規劃

您需要知道識別及修正 SharePoint、OneDrive、Exchange Online 或 商務用 Skype Online 與用戶端電腦之間延遲、停止回應和效能緩慢的步驟嗎？ 在您呼叫支援之前，本文可協助您針對 Office 365 效能問題進行疑難解答，甚至修正一些最常見的問題。

本文實際上是一個範例行動計劃，可讓您在效能問題發生時，用來擷取有關效能問題的寶貴數據。 本文也包含一些主要問題。

如果您不熟悉網路效能，而且想要制定長期計劃來監視用戶端計算機與 Office 365 之間的效能，請查看 Office 365 效能微調和疑難解答 - 管理員 和 IT 專業人員。

範例效能疑難解答行動計劃

此行動計劃包含兩個部分：準備階段和記錄階段。 如果您目前有效能問題，而且需要進行數據收集，您可以立即開始使用此計劃。

準備客戶端電腦

• 尋找可重現效能問題的用戶端電腦。 此電腦將在疑難解答期間使用。
• 請記下導致效能問題發生的步驟，讓您準備好進行測試。
• 安裝工具以收集和記錄資訊：
  • 安裝 Netmon 3.4 (或使用對等的網路追蹤工具) 。
  • 安裝免費的 HTTPWatch Basic 版本 (或使用對等的網路追蹤工具) 。
  • 使用螢幕錄製器或執行 Windows Vista 和更新版本隨附的步驟錄製器 (PSR.exe) ，以記錄您在測試期間所採取的步驟。

記錄效能問題

• 關閉所有無關的因特網瀏覽器。

• 啟動步驟錄製器或其他螢幕錄製器。

• 啟動 Netmon 擷取 (或網路追蹤工具) 。

• 輸入ipconfig /flushdns，從命令行清除客戶端電腦上的 DNS 快取。

• 啟動新的瀏覽器會話並開啟 HTTPWatch。

• 選擇性：如果您要測試 Exchange Online，請從 Office 365 管理控制台執行 Exchange 用戶端 效能分析器 工具。

• 重現造成效能問題的確切步驟。

• 停止 Netmon 或其他工具的追蹤。

• 在命令行中，輸入下列命令，然後按 ENTER，以執行 Office 365 訂用帳戶的追蹤路由：

  tracert <subscriptionname>.onmicrosoft.com
  

• 停止步驟錄製器並儲存影片。 請務必包含擷取的日期和時間，以及其是否示範良好或不良的效能。

• 儲存追蹤檔案。 同樣地，請務必包含擷取的日期和時間，以及其是否示範良好或不正確的效能。

如果您不熟悉如何執行本文所述的工具，請別擔心，因為我們接下來會提供這些步驟。 如果您習慣執行這種網路擷取，您可以跳 至如何收集基準，其中描述篩選和讀取記錄。

先排清 DNS 快取

為什麼？ 藉由清除 DNS 快取，您將以全新的平板開始測試。 藉由清除快取，您會將 DNS 解析程式內容重設為最新的專案。 請記住，排清不會移除 HOST 檔案專案。 如果您廣泛使用 HOST 檔案專案，您應該將這些項目複製到另一個目錄中的檔案，然後清空 HOST 檔案。

排清 DNS 解析程式快取

1. 開啟命令提示字元， (啟動>執行>cmd 或 Windows 金鑰>cmd) 。

2. 輸入下列命令，然後按 ENTER：

   ipconfig /flushdns
   

Netmon

Microsoft 的網路監視工具 (Netmon) 分析網路上計算機之間傳遞的封包 (網路流量) 。 藉由使用 Netmon 以 Office 365 追蹤流量，您可以擷取、檢視和讀取封包標頭、識別介入的裝置、檢查網路硬體上的重要設定、尋找卸除的封包，以及追蹤公司網路上計算機與 Office 365 之間的流量流程。 因為流量的實際主體已加密，也就是說，它會透過 SSL/TLS 在埠 443 上移動，所以您無法讀取所傳送的檔案。 相反地，您會取得封包所採用路徑的未篩選追蹤，以協助您追蹤問題行為。

請確定您目前未套用篩選。 相反地，請執行這些步驟，並在停止追蹤和儲存之前先示範問題。

安裝 Netmon 3.4 之後，請開啟工具並採取下列步驟：

取得 Netmon 追蹤並重現問題

1. 啟動 Netmon 3.4。 [開始] 頁面上有三個窗格：[最近的擷取]、[選取網络]，以及使用 Microsoft 網络監視器 3.4 的 使用者入門。請注意。 [選取網络] 面板也會提供您可以從中擷取的預設網路清單。 請確定已在此處選取網路卡。

2. 按兩下 [開始] 頁面頂端的 [ 新增 擷 取 ]。 這會在 [ 開始 ] 頁面索引標籤旁邊新增一個索引卷標，稱為 [擷 取 1]。

3. 若要進行簡單的擷取，請按下工具列上的 [ 開始 ]。

4. 重現呈現效能問題的步驟。

5. 按兩下 [停止>檔案另存>新檔]。 請記得提供時區的日期和時間，並提及其是否示範效能不佳或良好。

HTTPWatch

HTTPWatch 會以付費方式提供，以及免費版本。 免費的 Basic Edition 涵蓋此測試所需的一切。 HTTPWatch 會直接從瀏覽器視窗監視網路流量和頁面載入時間。 HTTPWatch 是以圖形方式描述效能的 Microsoft Edge 外掛程式。 您可以在 HTTPWatch Studio 中儲存及檢視分析。

執行 HTTPWatch 並重現問題

HTTPWatch 是瀏覽器外掛程式，因此在瀏覽器中公開工具對於每個版本的 Microsoft Edge 會稍有不同。 一般而言，您可以在 Microsoft Edge 瀏覽器的 [命令] 列下找到 HTTPWatch。 如果您在瀏覽器視窗中看不到 HTTPWatch 外掛程式，請按兩下 > [關於說明] 來檢查瀏覽器的版本，或在較新版本的 Microsoft Edge 中，按兩下齒輪符號和 About Edge。 若要啟動 [命令] 列 ，請以滑鼠右鍵按下 Microsoft Edge 中的功能表欄，然後按下 [ 命令] 列。

在過去，HTTPWatch 已與 [命令] 和 [總管] 列相關聯，因此，一旦安裝之後，即使重新啟動之後，還是不會立即看到圖示 () 檢查 [工具]，以及圖標的工具列。 請記住，您可以自訂工具列，並可將選項新增至工具列。

1. 在 Microsoft Edge 瀏覽器視窗中啟動 HTTPWatch。 它似乎停駐在該視窗底部的瀏覽器。 按兩下 [記錄]。

2. 重現與效能問題相關的確切步驟。 按兩下 HTTPWatch 中的 [ 停止 ] 按鈕。

3. 儲存 HTTPWatch 或 send by Email。 請記得為檔案命名，使其包含日期和時間資訊，以及您的 Watch 是否包含良好或不良效能的示範。

此螢幕快照來自 HTTPWatch 的 Professional 版本。 您可以在具有 Professional 版本的計算機上開啟基本版本中所擷取的追蹤，並在該處讀取。 您可以透過該方法，從追蹤取得額外的資訊。

問題步驟錄製器

步驟 Recorder 或 PSR.exe 可讓您在發生問題時記錄問題。 這是非常實用的工具，而且執行很簡單。

執行問題步驟錄製器 (PSR.exe) 來記錄您的工作

1. 請使用 [開始>執行> ] 類型 PSR.exe>確定]，或按兩下 [Windows 金鑰> 類型 ]PSR.exe> ，然後按 ENTER 鍵。

2. 當小型 PSR.exe 視窗出現時，按兩下 [ 開始記錄 ] 並重現重現效能問題的步驟。 您可以視需要按兩下[新增批注] 來新增 批注。

3. 當您完成步驟時，按兩下 [ 停止記錄 ]。 如果效能問題是頁面轉譯，請等候頁面轉譯，再停止錄製。

4. 按一下儲存。

系統會為您記錄日期和時間。 這會將您的 PSR 實時連結至 Netmon 追蹤和 HTTPWatch，並協助進行精確的疑難解答。 例如，PSR 記錄中的日期和時間可以顯示在 URL 的登入和流覽與管理網站的部分轉譯之間所經過的分鐘數。

讀取追蹤

您無法透過文章來教導其他人需要知道的網路和效能疑難解答一切。 獲得良好的效能會取得經驗，並了解網路的運作方式和通常的執行方式。 但您可以將常見問題清單四捨五入，並顯示工具如何讓您更輕鬆地排除最常見的問題。

如果您想要挑選技能來讀取 Office 365 網站的網路追蹤，沒有比定期建立頁面載入追蹤並獲得閱讀經驗更好的教師。 例如，當您有機會時，請載入 Office 365 服務並追蹤進程。 篩選 DNS 流量的追蹤，或搜尋 FrameData 以尋找您瀏覽的服務名稱。 掃描追蹤以瞭解服務載入時所發生的步驟。 這可協助您瞭解一般頁面載入的外觀，而在進行疑難解答時，特別是效能方面，將良好與不良追蹤進行比較可能會告訴您很多。

Netmon 會在 [顯示篩選] 字段中使用 Microsoft Intellisense。 Intellisense 或智慧型手機代碼完成是您在句點中輸入的訣竅，所有可用的選項都會顯示在下拉式選取方塊中。 例如，您擔心 TCP 視窗調整，您可以透過這種方式找到篩選 (的方式，例如 .protocol.tcp.window < 100) 。

Netmon 追蹤中可能會有許多流量。 如果您沒有讀取它們的經驗，您可能會在第一次開啟追蹤時不知所哩。 第一件事是將訊號與追蹤中的背景雜訊分開。 您已針對 Office 365 進行測試，而這就是您想要看到的流量。 如果您是用來巡覽追蹤，您可能不需要此清單。

用戶端與 Office 365 之間的流量會透過 TLS 傳輸，這表示流量主體將會加密，而且無法在一般 Netmon 追蹤中讀取。 您的效能分析不需要知道封包中信息的詳細資訊。 不過，它對於封包標頭及其包含的資訊非常感興趣。

取得良好追蹤的秘訣

• 瞭解客戶端電腦的 IPv4 或 IPv6 位址值。 您可以輸入 IPConfig ，然後按 ENTER，從命令提示字元取得此資訊。 瞭解此位址可讓您一目了然地指出追蹤中的流量是否直接牽涉到您的用戶端電腦。 如果有已知的 Proxy，請偵測它並取得其 IP 位址。

• 排清 DNS 解析程式快取，並盡可能關閉所有瀏覽器，但您執行測試的瀏覽器除外。 例如，如果您無法這麼做，如果支持人員使用某些瀏覽器型工具來查看用戶端電腦的桌面，請準備好篩選追蹤。

• 在忙碌的追蹤中，找出您使用的 Office 365 服務。 如果您之前從未或很少看過您的流量，這是將效能問題與其他網路雜訊分隔開來很有説明的步驟。 有幾種方式可以執行這項操作。 在測試之前，您可以直接針對特定服務的 URL 使用 ping 或 PsPing (ping outlook.office365.com 或 psping -4 microsoft-my.sharepoint.com:443，例如) 。 您也可以輕鬆地在 Netmon 追蹤中找到 ping 或 PsPing， (其行程名稱) 。 這可讓您開始尋找。

如果您只在問題發生時使用 Netmon 追蹤，那也沒關係。 若要自行調整方向，請使用 或 之類的ContainsBin(FrameData, ASCII, "office")ContainsBin(FrameData, ASCII, "outlook")篩選條件。 您可以從追蹤檔案記錄框架編號。 您可能也想要將 [ 框架摘要 ] 窗格向右卷動，並尋找 [交談標識符] 數據行。 有一個數位指出此特定交談的標識碼，您稍後也可以隔離記錄和查看。 請記得先移除此篩選條件，再套用任何其他篩選。

熟悉您的流量，並瞭解如何找出所需的資訊。 例如，瞭解如何判斷追蹤中的哪個封包具有您所使用 (Office 365 服務的第一個參考，例如 “Outlook”) 。

以 Office 365 Outlook Online 為例，流量的開頭如下：

• 具有相符 QueryID 之 outlook.office365.com 的 DNS 標準查詢和 DNS 回應。 請務必注意此回合的時間位移，以及全球 Office 365 全域 DNS 傳送名稱解析要求的位置。 在理想情況下，請盡可能在本機進行，而不是在世界各地的一半。

• 狀態報表已永久移 (301) 的 HTTP GET 要求

• RWS 流量，包括 RWS Connect 要求和 Connect 回復。 (這是為您建立連線的 Remote Winsock。)

• TCP SYN 和 TCP SYN/ACK 交談。 此交談中的許多設定都會影響您的效能。

• 接著一系列的 TLS：TLS 流量，也就是 TLS 交握和 TLS 憑證交談的發生位置。 (請記住，數據是透過SSL/TLS.)

流量的所有部分都很重要且已連線，但追蹤的一小部分包含效能疑難解答方面的重要資訊，因此我們將著重於這些區域。 此外，由於我們已完成足夠的 Office 365 Microsoft 效能疑難解答來編譯常見問題的前 10 名清單，因此我們將著重於這些問題，以及如何使用我們必須在下一步根除這些問題的工具。

如果您尚未安裝它們，下列矩陣會盡可能使用數個工具。 系統會提供安裝點的連結。 此清單包含一般網路追蹤工具，例如 Netmon 和 Wireshark，但使用任何您熟悉且習慣篩選網路流量的追蹤工具。 測試時，請記住：

• 關閉您的瀏覽器，並只使用一個執行中的瀏覽器進行測試 - 這會減少您所擷取的整體流量。 它可讓追蹤變得較不忙碌。
• 排清客戶端電腦上的 DNS 解析程式快取 - 這會在您開始擷取擷取時提供全新的平板，以取得更簡潔的追蹤。

常見問題

您可能會遇到的一些常見問題，以及如何在網路追蹤中找到這些問題。

TCP Windows 調整

可在 SYN - SYN/ACK 中找到。 舊版或過時的硬體可能不會利用 TCP 視窗調整。 如果沒有適當的 TCP 視窗調整設定，TCP 標頭中的預設 16 位緩衝區會以毫秒為單位填滿。 在用戶端收到已收到原始數據的認可，導致延遲之前，流量無法繼續傳送。

工具

• Netmon
• Wireshark

要尋找什麼

尋找網路追蹤中的 SYN - SYN/ACK 流量。 在 Netmon 中，使用篩選條件，例如 tcp.flags.syn == 1。 這個篩選條件在Wireshark中是相同的。

請注意，針對每個 SYN，都有一個來源埠 (SrcPort) 在相關通知 (SYN/ACK) 的目的地埠 (DstPort) 中相符的號碼。

若要查看網路連線所使用的 Windows 調整值，請先展開 SYN，然後再展開相關的 SYN/ACK。

TCP 空閒時間設定

在過去，大部分的周邊網路都是針對暫時性連線所設定，這表示閑置連線通常會終止。 Proxy 和防火牆可以在 100 到 300 秒內終止閑置的 TCP 會話。 這會對 Outlook Online 造成問題，因為它會建立並使用長期連線，不論連線是否處於閑置狀態。

當連線由 Proxy 或防火牆裝置終止時，不會通知用戶端，而嘗試使用 Outlook Online 表示用戶端電腦會在建立新連線之前，重複嘗試中斷連線。 您可能會在產品中看到停止回應、提示，或頁面載入效能變慢。

工具

• Netmon
• Wireshark

要尋找什麼

在 Netmon 中，查看來回時間的 [時間位移] 字段。 來回行程是用戶端將要求傳送至伺服器和接收回應之間的時間。 請檢查客戶端與輸出點之間的 (例如用戶端 --> Proxy) 或要 Office 365 (用戶端的用戶端 --> Office 365) 。 您可以在許多封包類型中看到這一點。

例如，Netmon 中的篩選條件可能看起來像 .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12是 ，或者在Wireshark 中為 ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12。

如果發生問題，預期會出現較長的時間位移，在此案例中 (Outlook Online) ，特別是在顯示應用程式數據傳遞的 TLS：TLS 封包 (例如，在 Netmon 中，您可以透過 .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data") 找到應用程式數據封包。 您應該會在會話中看到一段順暢的進度。 如果您在重新整理 Outlook Online 時看到長時間延遲，這可能是因為傳送高度重設所造成。

延遲/來回時間

延遲是一種量值，可視許多變數而改變很多，例如升級過時的裝置、將大量使用者新增至網路，以及網路連線上其他工作所耗用的整體頻寬百分比。

此網路規劃和 Office 365 頁面的效能微調提供 Office 365 頻寬計算機。

需要測量連線的速度，還是 ISP 連線的頻寬？ 試用此網站 (或類似它的網站) ： Speedtest 官方網站，或查詢您最愛的搜尋引擎以進行片語 速度測試。

工具

• 坪
• PsPing
• Netmon
• Wireshark

要尋找什麼

若要追蹤追蹤中的延遲，您將受益於在 Office 365 中記錄用戶端電腦IP位址和 DNS 伺服器的IP位址。 這是為了更輕鬆地進行追蹤篩選。 如果您透過 Proxy 連線，您將需要用戶端電腦 IP 位址、Proxy/輸出 IP 位址，以及 Office 365 DNS IP 位址，以簡化工作。

傳送至 outlook.office365.com 的 ping 要求會告訴您接收要求的數據中心名稱，即使 ping 可能 無法連線以傳送商標連續 ICMP 封包也一樣。 如果您使用 PsPing (免費工具來下載) ，以及特定埠 (443) ，而且可能使用 IPv4 (-4) 您會取得傳送封包的平均來回時間。 這適用於 Office 365 服務中的其他 URL， 例如 psping -4 yourSite.sharepoint.com:443。 事實上，您可以指定一些 Ping 來取得平均值的較大樣本，請嘗試類似 的 psping -4 -n 20 yourSite-my.sharepoint.com:443動作。

如果您在執行網路追蹤時載入執行速度緩慢的 Office 365 頁面，您應該篩選 Netmon 或 Wireshark 追蹤。DNS 這是我們要尋找的其中一個IP。

以下是篩選 Netmon 以取得 IP 位址 (，並查看 DNS 延遲) 的步驟。 此範例使用 outlook.office365.com，但也可以使用 SharePoint 租使用者 (hithere.sharepoint.com 的 URL，例如) 。

1. Ping URL ping outlook.office365.com ，並在結果中記錄傳送 Ping 要求之 DNS 伺服器的名稱和 IP 位址。
2. 開啟頁面的網路追蹤，或執行可提供效能問題的動作，或者，如果您在 ping 上看到高延遲，則網路會追蹤它。
3. 在 Netmon 中開啟追蹤並篩選 DNS (此篩選器也適用於 Wireshark，但會區分大小寫 -- dns) 。 因為您知道來自 Ping 的 DNS 伺服器名稱，所以您也可以在 Netmon 中更快速地篩選，如下所示： DNS AND ContainsBin(FrameData, ASCII, "namnorthwest")，這在 Wireshark dns 中看起來像這樣，而框架包含 “namnorthwest”。
   開啟回應封包，然後在 [Netmon 框架詳細 數據] 視窗中，按兩下 [DNS ] 展開以取得詳細資訊。 在 DNS 資訊中，您會發現要求在 Office 365 中前往的 DNS 伺服器 IP 位址。 在 PsPing 工具) (下一個步驟，您將需要此 IP 位址。 拿掉篩選，以滑鼠右鍵按兩下Netmon中的 DNS 回應 (畫面摘要>尋找交談>DNS) ，以並排查看 DNS 查詢和回應。
4. 在 Netmon 中，也請注意 DNS 要求與回應之間的時間位移數據行。 在下一個步驟中，容易安裝和使用 PsPing 工具非常方便，因為防火牆上通常會封鎖 ICMP，也因為 PsPing 以毫秒為單位輕鬆追蹤延遲。 在我們的案例中，PsPing 會完成位址和埠 (的 TCP 連線，以開啟埠 443) 。
5. 安裝 PsPing。
6. 開啟命令提示字元 (啟動 > 執行 > 類型 cmd 或 Windows 金鑰 > 類型 cmd) ，並將目錄變更為您安裝 PsPing 以執行 PsPing 命令的目錄。 在我的範例中，您可以看到我在 C 的根目錄上建立 'Perf' 資料夾。您可以針對快速存取執行相同的動作。
7. 輸入 命令，讓您針對先前 Netmon 追蹤中 Office 365 DNS 伺服器的 IP 位址進行 PsPing，包括埠號碼，例如 psping -n 20 132.245.24.82:445。 這會提供 20 Ping 的取樣，並在 PsPing 停止時平均延遲。

如果您要透過 Proxy 伺服器 Office 365，步驟會稍有不同。 首先，將 PsPing 移至您的 Proxy 伺服器，以取得 Proxy/輸出和返回的平均延遲值，然後在 Proxy 上執行 PsPing，或在具有直接因特網連線的計算機上執行 PsPing，以取得遺漏值， (Office 365 並返回) 。

如果您選擇從 Proxy 執行 PsPing，您會有兩毫秒的值：用戶端電腦到 Proxy 伺服器或輸出點，以及要 Office 365 的 Proxy 伺服器。 您已完成！ 不過，還是要記錄值。

如果您在另一部直接連線到因特網的用戶端計算機上執行 PsPing，也就是說，如果沒有 Proxy，您會有兩毫秒的值：用戶端電腦到 Proxy 伺服器或輸出點，以及用戶端電腦 Office 365。 在此情況下，將用戶端計算機的值減去 Proxy 伺服器或輸出點，從用戶端電腦的值減至 Office 365，而且您將會有從用戶端電腦到 Proxy 伺服器或輸出點，以及從 Proxy 伺服器或輸出點到 Office 365 的 RTT 編號。

不過，如果您可以在直接連線或略過 Proxy 的受影響位置中找到用戶端電腦，您可以選擇查看問題是否會從該處開始重現，並在之後使用它進行測試。

如 Netmon 追蹤所示，如果任何指定的會話中有足夠的毫秒，這些額外的毫秒可能會加起來。

如果您想要搜尋 132.245，請記得展開所有節點 (此) 的頂端有一個按鈕。

Proxy 驗證

這僅適用於您在進行 Proxy 伺服器時。 如果沒有，您可以略過這些步驟。 正常運作時，Proxy 驗證應該以毫秒為單位，以一致的方式進行。 您不應該在尖峰使用量期間看到間歇性不良的效能 (例如) 。

如果 Proxy 驗證已開啟，則每次您對 Office 365 進行新的 TCP 連線以取得資訊時，都必須在幕後通過驗證程式。 因此，例如，在 Outlook Online 中從 [行事曆] 切換至 [郵件] 時，您將會進行驗證。 在 SharePoint 中，如果頁面顯示來自多個網站或位置的媒體或數據，您將會針對轉譯數據所需的每個不同 TCP 連線進行驗證。

在 Outlook Online 中，每當您在行事曆與信箱之間切換，或 SharePoint 中的頁面載入速度變慢時，您可能會遇到載入速度緩慢的情況。 不過，這裏並未列出其他徵兆。

Proxy 驗證是您輸出 Proxy 伺服器上的設定。 如果造成 Office 365 效能問題，您必須洽詢您的網路小組。

工具

• Netmon
• Wireshark

要尋找什麼

每當必須啟動新的 TCP 會話、通常要向伺服器要求檔案或資訊，或提供資訊時，就會進行 Proxy 驗證。 例如，您可能會看到有關 HTTP GET 或 HTTP POST 要求的 Proxy 驗證。 如果您想要查看要在追蹤中驗證要求的框架，請將 [NTLMSSP 摘要] 資料行新增至 Netmon，並篩選 。.property.NTLMSSPSummary 若要查看驗證花費的時間長度，請新增 [時間差異] 資料行。

若要將數據行新增至 Netmon：

1. 以滑鼠右鍵按兩下 [描述] 之類的數據行。
2. 按兩下 [選擇資料行]。
3. 在清單中找出 NTLMSSP 摘要 和 時間差異 ，然後按兩下 [ 新增]。
4. 將新的數據行移到 [ 描述 ] 資料行之前或後方，讓您可以並排讀取它們。
5. 按一下確定。

即使您未新增數據行，Netmon 篩選器仍可運作。 但是，如果您可以看到您所處的驗證階段，則疑難解答會更容易。

尋找 Proxy 驗證的實例時，請務必研究存在NTLM挑戰或驗證訊息的所有畫面。 如有必要，請以滑鼠右鍵按下特定流量片段，然後尋找交談 > TCP。 請注意這些交談中的 Time Delta 值。

Proxy 驗證的四秒延遲，如Wireshark中所示。 前 一個顯示框架 數據行的 [時間差異] 是透過以滑鼠右鍵按兩下框架詳細數據中相同名稱的欄位，然後選取[新增為資料行] 來建立。

DNS 效能

名稱解析在盡可能接近客戶端的國家/地區時，最適合且最快速地運作。

如果 DNS 名稱解析正在進行，它可以在頁面載入中增加秒數。 在理想情況下，名稱解析會在100毫秒以下發生。 如果沒有，您應該進行進一步的調查。

工具

• Netmon
• Wireshark
• PsPing

要尋找什麼

分析 DNS 效能通常是網路追蹤的另一項作業。 不過，PsPing 也有助於將可能的原因傳入或傳出。

DNS 流量是以 TCP 和 UDP 要求為基礎，而且回應會清楚地標示標識碼，以協助比對特定要求與其特定回應。 例如，當 SharePoint 在網頁上使用網路名稱或 URL 時，您會看到 DNS 流量。 根據經驗法則，除了傳輸區域之外，大部分的流量都會透過UDP執行。

在 Netmon 和 Wireshark 中，可讓您查看 DNS 流量的最基本篩選就是 。dns 指定篩選時，請務必使用小寫。 請記得先排清 DNS 解析程式快取，再開始在用戶端電腦上重現問題。 例如，如果首頁的 SharePoint 頁面載入速度變慢，您應該關閉所有瀏覽器、開啟新的瀏覽器、開始追蹤、排清 DNS 解析程式快取，以及流覽至 SharePoint 網站。 一旦整個頁面解析之後，您應該停止並儲存追蹤。

您想要查看這裡的時間位移。 此外，將 Time Delta 數據行新增至 Netmon 可能很有説明，您可以完成下列步驟來執行此動作：

1. 以滑鼠右鍵按兩下 [描述] 之類的數據行。
2. 按兩下 [選擇資料行]。
3. 在清單中找出 時間差異 ，然後按兩下 [ 新增]。
4. 將新的數據行移到 [ 描述 ] 資料行之前或後方，讓您可以並排讀取這些數據行。
5. 按一下確定。

如果您發現感興趣的查詢，請考慮在框架詳細數據面板中以滑鼠右鍵按下該查詢，然後選擇 [ 尋找交談>DNS]，以將其隔離。 請注意，[網路交談] 面板會直接跳至其 UDP 流量記錄中的特定交談。

在Wireshark中，您可以建立 DNS 時間的數據行。 將追蹤 (或在Wireshark 中開啟追蹤) ，並依 dns篩選，或更實用地 dns.time開啟 。 按兩下任何 DNS 查詢，然後在顯示詳細資料的面板中展開 Domain Name System (response) 詳細資料。 您會看到時間 (的欄位，例如 [Time: 0.001111100 seconds] 這次以滑鼠右鍵按兩下，然後選取 [ 套用為數據行]。 這會為您提供 [時間 ] 數據行，以便更快速地排序追蹤。 按兩下新的資料行，依遞減值排序，以查看哪一個 DNS 呼叫花費最長的時間來解析。

在Wireshark中透過 (小寫) dns.time篩選的SharePoint流覽，其時間是從詳細數據變成資料行並以遞增方式排序。

如果您想要對 DNS 解析時間進行更多調查，請針對 TCP (所使用的 DNS 連接埠嘗試 PsPing， psping <IP address of DNS server>:53 例如，) 。 您仍然會看到效能問題嗎？ 如果您這樣做，則問題比您所遇到的 DNS 應用程式特定問題更可能是更廣泛的網路問題。 同樣地，值得一提的是，對 outlook.office365.com 的 ping 會告訴您 Outlook Online 的 DNS 名稱解析發生的位置 (例如，outlook-namnorthwest.office365.com) 。

如果問題看起來是 DNS 特定問題，可能需要連絡您的 IT 部門以查看 DNS 設定和 DNS 轉寄站，以進一步調查此問題。

Proxy 延展性

Office 365 中的 Outlook Online 等服務會授與用戶端多個長期連線。 因此，每個使用者可能會使用更多需要較長生命週期的連線。

工具

數學

要尋找什麼

沒有特定的網路追蹤或疑難解答工具。 相反地，它是以頻寬計算為基礎，並提供限制和其他變數。

TCP 最大區段大小

可在 SYN - SYN/ACK 中找到。 請在您所採取的任何效能網路追蹤中執行此檢查，以確保 TCP 封包已設定為可攜帶的最大數據量。

目標是要查看 1,460 個字節的 MSS 來傳輸數據。 如果您位於 Proxy 後方，或是使用 NAT，請記得從用戶端到 Proxy/輸出/NAT，以及從 Proxy/輸出/NAT 執行此測試，以 Office 365 以獲得最佳結果！ 這些是不同的 TCP 工作階段。

工具

Netmon

要尋找什麼

TCP 最大區段大小 (MSS) 是網路追蹤中三向交握的另一個參數，這表示您會在 SYN - SYN/ACK 封包中找到所需的數據。 MSS 相當簡單。

開啟您擁有的任何效能網路追蹤，並尋找您想知道的連線，或示範效能問題。

查看第二手追蹤嗎？ 請嘗試使用篩選條件來調整自己的方向。 在 Netmon 中，根據 URL 執行搜尋，例如 Containsbin(framedata, ascii, "sphybridExample")，記下框架編號。

在Wireshark中，使用類似的內容 frame contains "sphybridExample"。 如果您發現遠端 Winsock (RWS) 流量 (它可能會在 Wireshark) 中顯示為 [PSH， ACK]，請記住，RWS 連線在相關的 SYN - SYN/ACK 之前，很快就會看到，如先前所述。

此時，您可以記錄框架編號、卸除篩選，然後按兩下Netmon中 [網路交談] 視窗中的[ 所有流量 ] 來查看最接近的 SYN。

重要的是，如果您在追蹤時未收到任何IP位址資訊，在追蹤 (的一部分 sphybridExample-my.sharepoint.com尋找您的URL，例如) ， 會提供您要篩選的IP位址。

在您有興趣查看的追蹤中找出連線。 若要這麼做，您可以掃描追蹤、依IP位址篩選，或使用Netmon中的 [網路交談] 視窗選取特定的對話識別碼。 找到 SYN 封包之後，請在 [畫面格詳細數據] 面板的 [Netmon) ] 中展開 [TCP (]，或在 Wireshark) 中展開 [傳輸控制通訊協定 (] 。 展開 [TCP 選項] 和 [MaxSegmentSize]。 找出相關的 SYN-ACK 框架，然後展開 [TCP 選項] 和 [MaxSegmentSize]。 兩個值中較小的值會是您的最大區段大小。 在此圖片中，我使用 Netmon 中稱為 TCP 疑難解答的內建數據行。

內建資料行位於 [ 畫面格詳細數據 ] 面板的頂端。 (若要切換回您的一般檢視， 請再次按 兩下 [數據行]，然後選擇 [時區]。)

以下是Wireshark中經過篩選的追蹤。 MSS 值 () tcp.options.mss 有特定的篩選條件。 SYN、SYN/ACK、ACK 交握的框架會連結在Wireshark底部，相當於框架詳細數據 (因此框架47 ACK、46 SYN/ACK的連結、43 SYN) 的連結，讓這類工作更容易。

如果您需要檢查選擇 性通知 (此矩陣) 中的下一個主題，請勿關閉追蹤！

選擇性通知

可在 SYN - SYN/ACK 中找到。 在 SYN 和 SYN/ACK 中都必須回報為 [允許]。 選擇性通知 (的) 允許在封包或封包遺失時，更順暢地重新傳輸數據。 裝置可以停用這項功能，這可能會導致效能問題。

如果您位於 Proxy 後方，或是使用 NAT，請記得從用戶端到 Proxy/輸出/NAT，以及從 Proxy/輸出/NAT 執行此測試，以 Office 365 以獲得最佳結果！ 這些是不同的 TCP 工作階段。

工具

Netmon

要尋找什麼

選擇性通知 (的) 是 SYN-SYN/ACK 交握中的另一個參數。 您可以透過許多方式篩選 SYN - SYN/ACK 的追蹤。

藉由掃描追蹤、依IP位址篩選，或使用Netmon中的 [網络交談] 視窗按兩下 [交談標識符]，在追蹤中找出您感興趣的連線。 找到 SYN 封包之後，請在 [畫面格詳細數據] 區段中展開 [Netmon 中的 TCP] 或 [Wireshark 中的傳輸控制通訊協定]。 依序展開 [TCP 選項] 和 [檢視]。 找出相關的 SYN-ACK 框架和 [展開 TCP 選項] 及其 [對應] 字段。 在 SYN 和 SYN/ACK 中都允許使用特定的一個。。 以下是在 Netmon 和 Wireshark 中所見的一些一般值。

DNS 地理位置

在全球 Office 365 嘗試解析 DNS 呼叫的位置會影響您的連線速度。

在 Outlook Online 中，完成第一個 DNS 查閱之後，該 DNS 的位置將會用來連線到最接近的數據中心。 您將連線到 Outlook Online CAS 伺服器，該伺服器會使用骨幹網路來連線到資料儲存所在的數據中心 (dC) 。 這會比較快。

存取 SharePoint 時，旅行旅行的使用者會被導向至其使用中的數據中心-也就是其位置是以其 SPO 租使用者的主基底 (的 dC，因此，如果以美國為基礎的) ，則為美國 dC。

Lync Online 一次有多個 dC 的作用中節點。 針對 Lync 在線實例傳送要求時，Microsoft 的 DNS 會決定要求來自世界各地，並傳回 Lync Online 作用中之最接近區域 dC 的 IP 位址。

工具

• 坪
• PsPing

要尋找什麼

在大部分情況下，從用戶端 DNS 伺服器到 Microsoft DNS 伺服器的名稱解析要求，應該會導致 Microsoft DNS 傳回區域數據中心 (dC) 的 IP 位址。 這對您有何意義？ 如果您的總部位於印度加羅魯，但您在 美國 中旅行，當您的瀏覽器提出 Outlook Online 要求時，Microsoft 的 DNS 伺服器應該將 IP 位址交給 美國 中的數據中心 - 區域數據中心。 如果 Outlook 需要郵件，該數據會在數據中心之間跨越 Microsoft 的快速骨幹網路。

當名稱解析盡可能接近使用者位置時，DNS 的運作速度會最快。 如果您在歐洲，則想要前往歐洲的 Microsoft DNS，並在理想情況下 () 處理歐洲的數據中心。 歐洲用戶端移至 DNS 和美國資料中心的效能將會變慢。

針對 outlook.office365.com 執行 Ping 工具，以判斷您的 DNS 要求要路由傳送至世界各地。 如果您在歐洲，應該會看到類似 outlook-emeawest.office365.com 的回復。 在美洲，預期會像是 outlook-namnorthwest.office365.com。

在用戶端電腦上開啟命令提示字元， (透過啟動 > 執行 > cmd 或 Windows 金鑰 > 類型 cmd) 。 輸入 ping outlook.office365.com，然後按 ENTER 鍵。 請記住，如果您想要透過 IPv4 指定 ping，請指定 -4。 您可能無法從ICMP封包取得回復，但您應該會看到要求路由傳送至的 DNS 名稱。 如果您想要查看此連線的延遲號碼，請嘗試對 ping 傳回之伺服器的 IP 位址進行 PsPing。

Office 365 應用程式疑難解答

工具

• Netmon
• HTTPWatch
• 瀏覽器中的 F12 控制台

我們不會在此網路特定文章中討論應用程式特定疑難解答中使用的工具。 但您可以在此頁面上找到可用的資源。

相關文章

管理 Office 365 端點

Office 365 端點常見問題集 (機器翻譯)