TCP/IP 連線疑難排解

試用虛擬助理 - 其可協助您快速找出並修正常見 Active Directory 複寫問題。

適用於： 支援的 Windows 用戶端和 Windows Server 版本

本文提供疑難解答 TCP/IP 連線錯誤的完整指南。

徵兆和分析

您可能會在應用層級遇到連線問題，或可能會遇到逾時錯誤。 以下是一些常見的案例：

• 與資料庫伺服器的應用程式連線
• SQL 逾時錯誤
• BizTalk 應用程式逾時錯誤
• 遠端桌面通訊協定 （RDP） 失敗
• 檔案共用存取失敗
• 一般連線能力

當懷疑網路相關問題時，建議您收集網路封包擷取。 您可以篩選此擷取來識別有問題的 TCP 連線，並判斷失敗的原因。

在疑難解答過程中，您可能會在網路擷取中遇到 TCP RESET，這可能表示網路問題。

TCP 簡介

TCP 的特點是連線導向且可靠的通訊協定。 它會透過交握程序確保可靠性。 TCP 會話會以三向交握起始，後面接著數據傳輸，最後結束四向交握。

• 傳送者和接收者同意關閉會話的四向關閉，稱為正常關閉。 這會由 TCP 標頭中的 FIN 旗標識別為 1。

• 在四向關閉之後，機器會在釋放埠之前等候 4 分鐘（預設）。 這稱為TIME_WAIT狀態。 在此TIME_WAIT狀態期間，可以處理 TCP 連線的任何暫止封包。 一旦TIME_WAIT狀態完成，就會釋放配置給聯機的所有資源。

• TCP 重設是突然關閉的工作階段，導致立即釋放已配置的資源，並清除所有連線資訊。 這會由 TCP 標頭中的 RESET 旗標識別為 1。 在來源和目的地上同時收集的網路追蹤可協助您判斷流量的流程，並識別失敗點。

下列各節概述 RESET 可能發生的案例。

透過網路遺失封包

當 TCP 對等傳送封包而不接收回應時，對等會重新傳輸數據。 如果沒有回應，會話會以 ACK RESET 結尾，表示應用程式會認可交換的數據，但因為封包遺失而關閉連線。

來源和目的地同時進行網路追蹤可以驗證此行為。 在來源端，您可以看到重新傳輸的封包。 在目的地端，這些封包不存在。 此案例表示來源與目的地之間的網路裝置正在卸除封包。

案例 1：初始 TCP 交握期間的封包遺失

如果初始 TCP 交握因為封包捨棄而失敗，預設會重新傳輸 TCP SYN 封包三次。

注意

重新傳輸 TCP SYN 封包的次數可能會根據 OS 而有所不同。 這是由 TCP 全域參數下的 MAX SYN Retransmissions 值決定，您可以使用 命令netsh int tcp show global來檢視此值。

假設具有IP位址10.10.10.10.1的來源電腦透過TCP埠445連線到IP位址為10.10.10.10.2的目的地。 以下是來源計算機上所收集網路追蹤的螢幕快照，其中顯示初始 TCP 交握，其中 TCP SYN 封包會傳送，然後由來源重新傳輸，因為未收到來自目的地的回應。

在目的地上收集的網路追蹤中看到的相同 TCP 交談會顯示目的地未收到上述封包。 這表示 TCP SYN 封包已透過中繼網路卸除。

如果 TCP SYN 封包到達目的地，但目的地沒有回應，請確認連線的 TCP 連接埠是否處於目的地電腦上的 LISTENING 狀態。 這可以在命令 netstat -anob的輸出中檢查。

如果埠正在接聽，但仍沒有回應，則 Windows 篩選平臺 （WFP） 可能會有下降。

案例 2：TCP 連線建立後數據傳輸期間的封包遺失

在建立 TCP 連線之後傳送的數據封包透過網路卸除的情況下，TCP 預設會重新傳輸封包五次。

假設具有IP位址192.168.1.62的來源電腦已透過TCP埠445與IP位址192.168.1.168.1.2的目的地電腦建立連線。 來源計算機正在傳送正在重新傳輸五次的數據（SMB 交涉封包），如下所示。 從目的地沒有響應之後，來源計算機會傳送 ACK-RST 以關閉此 TCP 連線。

來源 192.168.1.62 側追蹤：

您不會看到上述任何封包到達目的地。

您必須洽詢內部網路小組來調查來源與目的地之間的不同躍點，並檢查是否有任何躍點可能導致封包捨棄。

TCP 標頭中的參數不正確

當網路中的中繼裝置修改封包時，就會發生此行為，導致接收端的 TCP 拒絕它們。 例如，TCP 序號可能會改變，或者中繼裝置可能會重新執行已修改 TCP 序號的封包。

來源和目的地上的同時網路追蹤有助於識別 TCP 標頭的任何修改。

首先，比較來源和目的地追蹤，以偵測封包中的任何變更，或代表來源到達目的地的新封包是否存在。

在這種情況下，我們建議從內部網路小組尋求協助，以識別任何修改或重新執行封包至目的地的裝置。 常見的罪魁禍首包括 Riverbed 裝置或 WAN 加速器。

應用層級重設

當您判斷重設不是因為封包捨棄、參數不正確或封包修改而造成的時（如透過網路追蹤識別），您就可以得出結論，問題為應用層級重設。

應用層級重設的特點是通知 （ACK） 旗標設定為 1，以及重設 （R） 旗標。 這表示伺服器認可封包的接收，但因為某些原因不接受連線。 當接收封包的應用程式在數據中發現無法接受的內容時，通常會發生此問題。

在下面的螢幕快照中，您可以觀察到來源和目的地的封包都相同，且不會修改或卸除。 不過，目的地會將明確重設傳送至來源。

來源端追蹤：

目的地端追蹤：

當 TCP SYN 封包傳送出去時，也可能會發生 ACK+RST 標幟的 TCP 封包。TCP SYN 封包是由來源電腦起始，以在特定埠上建立連線。 不過，如果目的地伺服器因為任何原因而不想接受封包，伺服器會以 ACK+RST 封包回應。

在這種情況下，調查導致重設的應用程式必須了解連線重設的原因（由埠號碼識別）。

注意

上述資訊與從 TCP 觀點重設而非 UDP 有關。 UDP 是無連線通訊協定，而且封包會不合理地傳送。 因此，使用 UDP 作為傳輸通訊協定時，不會觀察到重新傳輸或重設。 不過，UDP 會利用ICMP作為錯誤報告通訊協定。 當 UDP 封包傳送到目的地未列出的埠時，目的地會立即回應 ICMP「無法連線的目的地主機：無法連線的埠」訊息。

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

在 TCP/IP 連線問題的疑難解答期間，您可能會在網路追蹤中觀察到電腦收到封包，但不會回應它們。 這可能表示目的地伺服器網路堆疊的卸除。

若要判斷本機 Windows 防火牆是否卸載封包，請使用下列命令，在機器上啟用 Windows 篩選平臺 （WFP） 的稽核。

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

然後，您可以檢閱安全性事件記錄檔，以識別特定 TCP 連接埠和 IP 位址上的封包捨棄，以及相關聯的 WFP 篩選識別碼。

接下來，執行會產生wfpstate.xml檔案的命令netsh wfp show state。

您可以使用記事本開啟此檔案，並篩選事件記錄檔中找到的標識碼（例如，範例事件中的2944008）。 結果會顯示與封鎖連線之篩選標識符相關聯的防火牆規則名稱。