溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了Wireshark TS FTP傳輸失敗問題如何解決的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇Wireshark TS FTP傳輸失敗問題如何解決文章都會有所收獲，下面我們一起來看看吧。
用戶反饋說當與外部客戶端進行 FTP 傳輸時，可以成功登錄，但無法傳輸任何數據。總之 FTP 傳輸失敗，需要來弄清楚到底發生了什么。
跟蹤文件基本信息如下：
λ capinfos FTPFinal.pcap File name: FTPFinal.pcap File type: Wireshark/tcpdump/... - pcap File encapsulation: Ethernet File timestamp precision: microseconds (6) Packet size limit: file hdr: 65535 bytes Packet size limit: inferred: 69 bytes Number of packets: 44 File size: 3710 bytes Data size: 3555 bytes Capture duration: 34.493422 seconds First packet time: 2007-03-22 04:37:11.513913 Last packet time: 2007-03-22 04:37:46.007335 Data byte rate: 103 bytes/s Data bit rate: 824 bits/s Average packet size: 80.80 bytes Average packet rate: 1 packets/s SHA256: 36512b444dacb061e0d8a661923f1323d0c778131bedaa7bbd5b2ab810e9a09f RIPEMD160: 3e14f2dd481632867eba14503a24e92b316b5caf SHA1: 771e45893504af381de89ba6b047b5cd3fa554fd Strict time order: True Number of interfaces in file: 1 Interface #0 info: Encapsulation = Ethernet (1 - ether) Capture length = 65535 Time precision = microseconds (6) Time ticks per second = 1000000 Number of stat entries = 0 Number of packets = 44 λ
跟蹤文件在 linux 上通過 tcpdump 所捕獲，數據包數量并不多，只有 44 個，長度截斷為 69 字節，文件數據大小 3555 字節，捕獲時長 34.49 秒，平均速率 824 bps。
專家信息如下，可以看到 Warning 信息包括很多數據分段未被捕獲，同時也有很多的(疑似)重傳、(疑似)快速重傳以及(疑似)虛假重傳等問題，需要進一步實際分析。
眾所周知，FTP 有主動和被動兩種工作模式，而在有防火墻的網絡環境中，經常會因為安全策略出現訪問失敗問題。如果排除了 FTP 主動和被動、防火墻安全策略等常見的可能性問題之外，那么剩下的就要專項分析了，就像這個特殊的案例。
數據包初步信息如下，為一條 FTP 控制連接，在 No.15 之后出現了大量的告警信息。既然與 TCP Seq Num 相關，那么轉到專用視圖上。
首先是 TCP 三次握手，此處有個明顯問題的是SYN 數據包的 ACK 有數值，非 0，Wireshark 也會有明顯提示 [The acknowledgment number field is nonzero while the ACK flag is not set] 。雖然有些小問題，但此處未影響 TCP 三次握手的建立。
No.4 - No.15 正常的控制交互，Request - Response 。
主要分析如下：
No.15 客戶端 Request 數據包，Seq Num 為 70，Next Seq Num 為 94，同時 ACK Num 213 期望收到服務器 Seq 213 的數據包；
No.16 服務器 Response 數據包，Seq Num 為 213，但 Ack Num 為 97，不同于 No.15 的 94意思是服務器可能收到了客戶端發送的 Seq 70，Next Seq 94 和 Seq 94，Next Seq 97 的兩個 TCP 分段，因此 No.16 ACK Num 為 97；此處只是疑似捕獲時丟失了客戶端發送的后一個 3 字節的分段（Seq 94，Next Seq 97 ），所以提示 TCP ACKed unseen segment ；
No.17 客戶端發出的 ACK 數據包 Seq Num 為 94，此處和 No.16 的期望 97 無法對應上，同時客戶端 No.15 ACK 期望收到 Seq 213，No.16 Seq Num 也為 213，但是客戶端并不認可 No.16 數據包，因此 No.17 ACK Num 仍為 213；
問題貌似出現在服務器發送的 No.16 數據包上，需要繼續展開部分字段輔助判斷，譬如 IP ID。
可以看到客戶端 No.15、No.17、No.19 ...... IP ID 是逐步遞增的，意味著客戶端并沒有發送過 Seq 94，Next Seq 97 的 TCP 分段，因此對于服務器，上述分析 2 中的結論并不正確（可能收到了客戶端發送的 Seq 70，Next Seq 94 和 Seq 94，Next Seq 97 的兩個 TCP 分段）。
那么具體問題是什么呢？讓我們做一個假設，客戶端數據包在傳輸過程中發生了變化，額外多出來了 3 個字節，是否符合問題現象。
服務器側，收到了 No.15 Seq Num 70，Next Seq Num 97，ACK Num 213的數據包，所以回復了 No.16 Seq Num 213，ACK Num 97的數據包；
客戶端側，收到了 No.16 Seq Num 213，ACK Num 97，由于 ACK Num 的異常（不同于 94），客戶端實際忽略了該數據包，產生一個 No.17 ACK 數據包，ACK Num 仍然為 213；
服務器側，收到了 No.17 Seq Num 94，Next Seq Num 97，ACK Num 213的數據包，之后由于 No.16 發生超時重傳，重新發送了 No.18 Seq Num 213，ACK Num 97的數據包；
客戶端側，由于 No.15 超時，產生了重傳，所以重新發送了 No.19 Seq Num 70，Next Seq Num 94，ACK Num 213的數據包；
服務器側，收到了 No.19 Seq Num 70，Next Seq Num 97，ACK Num 213的數據包，回復了 No.20 Seq Num 243，ACK Num 97的數據包；
之后由于客戶端 -> 服務器傳輸方向上，持續的 94 -> 97 多出 3 個字節，問題持續。
總之，問題可能出現在中間傳輸路徑上的設備，可能是 NAT 或是防火墻等設備，增加了客戶端從未發送的 3 個額外字節，所以服務器回復的 ACK 也增加了 3 個字節，造成一系列連續問題。
關于“Wireshark TS FTP傳輸失敗問題如何解決”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“Wireshark TS FTP傳輸失敗問題如何解決”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
