分析：這個CASE比較有意思，我在用科來分析數據包的時候發現服務器的重傳率非常高，普遍達到12%以上，如下圖，一個450K的內容，花了整整1分3秒種才接收完畢，重傳率高達12%，這也上上圖墨綠色客戶端接收時間超長的原因
由此我判斷，要麼是服務器自身問題，要麼是線路問題導致丟包；那麼如何做進一步判斷呢？
步驟1：我嘗試在電信線路下面嘗試打開該網站發現也是異常緩慢！似乎應該理解爲和線路無關？
步驟2：使用best trace 追蹤該IP：66.116.220.181 www.beishuo.net
發現服務器地址位於 美國的一家opentransfer的廠家 既然是國外的服務器，那麼經驗上看應該是線路導致重傳的機率更大了。到這裏還是無法判斷
步驟3：使用代理服務器來排除服務器故障：我使用一個位於日本的代理服務器嘗試訪問66.116.220.181 www.beishuo.net
得到HTTPWATCH截圖；發現速度非常快，並且沒有丟包，那麼就排除是服務問題造成的丟包了，從而把網站打開慢的問題歸結於線路問題
很多人認爲到此事情就結束了，然而該網站打開慢還有第二個原因：如下圖，我發現在移動和電信下不用代理打開的時候有一個translate.google.com的翻譯JS以及一個google的圖片無法加載：
我使用httpwatch初步判斷是translate.google.com的一個翻譯js無法加載，這裏顯示加載了96秒還是沒有響應
分析：我們通過科來簡單看下出現了什麼問題：
點開數據包標籤 過濾google 發現能夠客戶能解析到google域名的IP 但是根本無法和谷歌服務器建立連接，每次會話連接都以客戶端三次SYN後結束
點開TCP會話；過濾google 我們發現客戶端從11：56分開始，總共發起了13次和谷歌的會話，每次都用不同的端口號發起會話3個SYN，一共持續到12：03分結束，然後服務器根本沒有響應
我們來看下網頁源碼：開發人員在網頁一開頭就調用了一個谷歌翻譯的JS文件；並在隨後的Body做了一個list元素，調用了google的一個圖片元素；然後網頁就需要在幾分鐘以後連接超時後才能完全載入，並且還無法使用google翻譯的JS和圖片
而如果使用代理服務器那麼情況將是：該JS（一共3個元素）最先打開，並且很快載入了，如下圖
很多人很疑惑，說 爲什麼這幾個JS不加載整個頁面就無法打開呢？
HTTP1.1協議目前最多就同時支持3條TCP下載數據流，如果不釋放或者會話超時，剩下的內容是不會並行下載的，這也是該協議的一個缺陷。而代碼編寫者一開始就引用了3個google元素，無法下載造成會話超時。
至此該問題得到定位：國外出口線路丟包嚴重再加上谷歌的JS插件（並且位於網頁頭部共3個元素） 無法加載，超時後，才能加載剩餘內容造成的網頁打開異常緩慢
解決方法：考慮到這是一個外貿網站，該問題也就在國內出現，開發者或者國內用戶我們建議×××使用
，並且建議谷歌翻譯JS插件放到網頁尾部，以加快頁面打開速度