1. 程式人生 > >www.beishuo.net 網站打開異常慢的原因

www.beishuo.net 網站打開異常慢的原因

科來數據包分析

現象:客戶投訴http://www.beishuo.net/ 網站在移動線路下打不開或者打開異常緩慢(墨綠色是服務器向客戶端發送數據的時間,顯得非常耗時)
技術分享
分析:這個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插件放到網頁尾部,以加快頁面打開速度

www.beishuo.net 網站打開異常慢的原因