一抑月、問題背景
OA系統(tǒng)部署完畢，小范圍上線使用后豫喧，收到用戶反饋石洗，說是通過消息對話框或者其他一些涉及文件上傳如審批的模塊，上傳文件速度非常慢紧显，2M的文件上傳要幾分鐘讲衫，幾十兆的文件基本就失敗了。
客戶OA 系統(tǒng) web端地址： https://oa.example.com
文件上傳鏈路：
用戶 -----> https://oa.example.com:443? ---- >客戶網(wǎng)絡(luò)設(shè)備(NAT)----> 外部反向代理 outer_nginx_vip:443? -------> 文件服務(wù)A ---->內(nèi)部反向代理? inner_nginx_vip:80 ----> 文件服務(wù)B ----> mongoDB
二孵班、問題排查
客戶網(wǎng)絡(luò)是電信 100M帶寬涉兽。
我用賬號測試在公司網(wǎng)絡(luò)（電信網(wǎng)）涉及文件上傳的地方都測試上傳了，沒問題篙程。
另一位同事也做了測試沒問題枷畏，但是如果用筆記本連公司wifi（移動網(wǎng)），就能復(fù)現(xiàn)這個問題虱饿。
這個問題并不是所有用戶都有反饋拥诡，只有一定比例的用戶，說明并不是全局性的氮发。
1. 初步認(rèn)為文件上傳過程中 移動/聯(lián)通/電信之間的轉(zhuǎn)網(wǎng)導(dǎo)致上傳速度慢
分別用 在移動/電信網(wǎng)絡(luò)下渴肉， tracert? oa.example.com? 沒發(fā)現(xiàn)有什么問題，在移動網(wǎng)絡(luò)下測試電信地址折柠，經(jīng)過的路由當(dāng)然要多宾娜，說明不了什么批狐，而且反饋的客戶本身使用電信網(wǎng)絡(luò)的也不少扇售，所以排除這個原因前塔。
2. 可能是服務(wù)器時間同步、OA系統(tǒng)文件模塊問題
2.1. 發(fā)現(xiàn)代理服務(wù)器承冰、文件服務(wù)器和數(shù)據(jù)服務(wù)器之間有幾十秒的時間差华弓，于是搭建內(nèi)網(wǎng)ntp服務(wù)器，將所有服務(wù)器全部同步一遍困乒，然后將反向代理寂屏、文件服務(wù)相關(guān)工程，文件存儲相關(guān)數(shù)據(jù)庫全部重啟一遍娜搂，問題依然存在
2.2.? 測試上傳幾個文件迁霎，跟蹤文件上傳日志，從nginx反向代理日志到文件服務(wù)工程日志百宇，沒發(fā)現(xiàn)有什么問題
2.2.? 不經(jīng)客戶外網(wǎng)接入設(shè)備考廉，直接通過與內(nèi)網(wǎng)OA 服務(wù)器同一個網(wǎng)段的Windows服務(wù)器，將域名oa.example.com 寫hosts解析到 nginx_vip 上傳文件携御，非巢粒快
說明不是OA系統(tǒng)文件模塊本身問題。
3. 因為是有一定概率出現(xiàn)問題啄刹，懷疑問題出在客戶網(wǎng)絡(luò)設(shè)備的負(fù)載均衡器上
客戶方網(wǎng)絡(luò)人員于是將 NAT 映射的內(nèi)網(wǎng)地址從 nginx_vip 改為 nginx01_ip涮坐，測試發(fā)現(xiàn)問題依然存在，問題不在這里誓军。
4. 在內(nèi)網(wǎng)服務(wù)器上搭建其他服務(wù)袱讹，將端口映射出去，測試文件上傳
4.1 在 nginx01 服務(wù)器上使用nexus搭建一個web服務(wù)昵时，將 8081端口映射到 oa.example.com廓译，通過登錄 http:// oa.example.com:8081測試文件上傳。
那么债查， 這個服務(wù)經(jīng)過的 客戶網(wǎng)絡(luò)設(shè)備跟OA文件服務(wù)是相同的非区。
測試發(fā)現(xiàn)，不同用戶上傳盹廷，有人快征绸，有人慢/失敗俄占；同一個用戶某天快管怠，某天慢/失敗。
4.2. 將內(nèi)網(wǎng)的? nginx01 缸榄、db01 兩臺服務(wù)器的 22 端口分別臨時映射到 oa.example.com渤弛，通過 ssh? username@oa.example.com 直接SSH 遠(yuǎn)程到內(nèi)網(wǎng)服務(wù)器
使用 SSH 客戶端工具通過 sftp直接上傳文件，發(fā)現(xiàn) 幾十k的小文件可以甚带，幾兆她肯、幾十兆的文件上傳一會佳头，就直接中斷了，不只是慢晴氨，而是直接失敗
5.? 懷疑客戶接入層網(wǎng)絡(luò)設(shè)備中使用了ECMP康嘉，且某條鏈路有問題
測試用nexus上傳文件發(fā)現(xiàn)一個非常詭異的現(xiàn)象：在家里通過vpn接入客戶網(wǎng)絡(luò)，大小文件籽前，上傳一定成功亭珍；如果直接通過公網(wǎng)，會某天成功枝哄，某天會失敗肄梨。
這就很讓人不可思議了，開始懷疑接入設(shè)備對接收的請求報文挠锥，使用了某種調(diào)度算法峭范，當(dāng)來源不變，調(diào)度走的鏈路不變瘪贱，而來源ip是其中一個因子纱控。
家里寬帶的出口公網(wǎng)ip，每天都是變化的菜秦，對客戶接入設(shè)備而言可以理解為 源ip變了甜害，那么請求報文被調(diào)度走的鏈路可能不一樣。
當(dāng)某天在家通過瀏覽器上傳失敗時球昨，改為接口調(diào)用命令行接口調(diào)用上傳：
curl -v -u username:password --upload-file file.zip http://oa.example.com:8081/repository/test/ file.zip
在家里Windows電腦上執(zhí)行失敗尔店，但是登錄我的一臺云主機(jī)執(zhí)行同樣的命令是成功的。
我們做了如下測試：
nexus 文件上傳主慰， http協(xié)議
SSH? 文件上傳嚣州，sftp協(xié)議
OA 文件上傳，http協(xié)議
通過上述測試共螺，不管使用什么協(xié)議该肴，都有失敗的概率，那么底層問題應(yīng)該出在tcp上藐不。
當(dāng)然在做nexus 匀哄、sftp文件OA系統(tǒng)文件上傳時間，同時開啟了客戶端Wireshark抓包雏蛮，抓包條件為 ip.host == xx.xx.xx.xx
xx.xx.xx.xx 為 oa.example.com 的公網(wǎng)ip
當(dāng)文件上傳慢/失敗時涎嚼，有大量的 亂序、丟包挑秉，從而導(dǎo)致tcp層的大量的重傳法梯，進(jìn)而導(dǎo)致文件上傳慢/失敗。
當(dāng)文件上傳正常時犀概，亂序立哑、丟包是偶現(xiàn)夜惭，影響不大。
三刁憋、 客戶網(wǎng)絡(luò)設(shè)備問題排查
從上面測試結(jié)果看滥嘴，基本可以確認(rèn)問題出在客戶的接入網(wǎng)絡(luò)設(shè)備上了木蹬。
通過跟客戶網(wǎng)絡(luò)人員逐層設(shè)備抓包測試至耻，發(fā)現(xiàn)問題可能是負(fù)載和匯聚直接互聯(lián)的接口，兩個一組聚合镊叁，協(xié)商出了問題尘颓。
注： 深信服網(wǎng)絡(luò)設(shè)備上，可以直接通過設(shè)備的管理界面晦譬，設(shè)置抓包參數(shù)開啟抓包疤苹，生成抓包文件，用wireshark分析敛腌。
負(fù)載? 和 匯聚層? 卧土，負(fù)載模式下，2X2? 有4條線路
當(dāng)關(guān)閉 鏈路3時像樊，原來上傳有問題尤莺，上傳都o(jì)k了，通過公網(wǎng)上傳100M左右的文件也很快了生棍，這也解釋了問什么一定概率的用戶文件上傳失敗了颤霎。
四、問題處理反思
一開始就應(yīng)該開啟wireshark 抓包涂滴，就能知道文件上傳慢友酱、失敗是因為 底層tcp報文 大量的 亂序、丟包和重傳柔纵，這樣就不用做那么多后面的文件上傳測試了缔杉。
當(dāng)然，如果沒有那么多的鏈路段測試搁料，客戶網(wǎng)絡(luò)人員不會如此配合壮吩，畢竟經(jīng)過這些測試之后，問題都指向了接入層網(wǎng)絡(luò)設(shè)備加缘，跟上層應(yīng)用沒有關(guān)系鸭叙！
五、參考
Nexus REST and Integration API
https://help.sonatype.com/repomanager3/integrations/rest-and-integration-api
Wireshark網(wǎng)絡(luò)抓包(一)——數(shù)據(jù)包拣宏、著色規(guī)則和提示
https://www.cnblogs.com/strick/p/6261463.html
Wireshark網(wǎng)絡(luò)抓包(二)——過濾器
https://www.cnblogs.com/strick/p/6261915.html
Wireshark網(wǎng)絡(luò)抓包(三)——網(wǎng)絡(luò)協(xié)議
https://www.cnblogs.com/strick/p/6262284.html
Wireshark網(wǎng)絡(luò)抓包(四)——工具
https://www.cnblogs.com/strick/p/6344486.html
