鍊路問題？高防連結逾時

一、問題簡述

某使用者回報安徽電話經常出現連結高防IP逾時的情況，判斷是安徽電信連結高防存在鍊路問題，期望我們協助解決。

二、問題分析

1、網絡測試

使用者在存在有問題的用戶端上協助執行ping以及mtr，從MTR上看，用戶端就出現丢包，是本地用戶端網絡的問題。但是這個丢包率其實很低，同時TCP協定是有重傳機制的，理論上不會出現明顯連結中斷。

2、進一步進行分析抓包

使用者回報了2個抓包，發現了2個場景：

2.1、用戶端直接連接配接負載均衡也會出現問題

1. 

   問題原因：分析這個封包看到，這個用戶端的request ，是過了15S再次發出的。由于負載均衡的預設keepalive的時間為15S的。，如果超過15S，就斷開連結了，導緻通信有問題。

解決方法：建議在負載均衡的控制台調整到最長60S觀察下的。

2.2、用戶端連結高防出現問題

如圖為7月29日11:44:23到7月29日12:46:33的抓包。

但是與高防IP的443端口的通信，在7月29日12:23:13 之後就沒有了，而給的日志是 時間是7月29日12:44:11 這個很詭異。

繼續分析封包，理論上當時在抓包，所有的通信都會保留在封包中，同時用戶端的報錯日志為：

最終定位是由于用戶端的原因，查詢dns的請，如下圖存在dns劫持。對應的cname被劫持到了一個海外的位址。

同時查詢與IP位址的通信全部逾時了。

最終的結論為由于該域名對應的cname位址被劫持了，導緻與服務端通信異常。

3、處理建議

A、最終用戶端修改dns位址為223.5.5.5 223.6.6.6 然後觀察的

B、最終用戶端綁定HOST到 高防IP上進行使用的。

C、修改域名解析為A記錄，然後使用的。

3個方法，影響面不一樣，可以進行評估下選擇。

最終通過聯系營運商重新整理dns緩存後解決。

三、總結

這個問題能夠分析出來有2個核心點：

1、抓包時抓取了所有的封包，而非與高防IP進行通信的封包。不是說有問題都是表面看到的。

2、熟悉以及了解HTTP的通信全過程