最近ES遇到discover總是失敗問題，ping主節點和node節點正常，抓包發現了大量的retransmission、tcp out of order、dup ack問題。

最近ES遇到discover總是失敗問題，ping主節點和node節點正常，抓包發現了大量的retransmission、tcp out of order、dup ack問題。

Explanation

看到其餘人也遇到過：https://community.pega.com/knowledgebase/articles/troubleshooting-elasticsearch-performance-tcp-network-analysis

The example screen below shows the Wireshark network analysis tool with a filter on a specific port that is trying to attempt the index request for the example case W-xxxx. No corresponding packet information is being received by Node1, the primary indexing node. Therefore, the root cause of the problem appears to be at the network layer, where some of the packets are not being transmitted successfully.

TCP報文之-tcp dup ack 、tcp Out-of-Order

from:https://blog.csdn.net/chenfengdejuanlian/article/details/53761004

使用WireShark抓包，選擇TCP報文，TCP是一種安全的協議，在網絡出現情況時也能安全穩定的傳輸數據，可是在網絡出現問題時tcp報文中會有不少中狀況致使報文重傳或者是重組。如今就在報文中遇到的幾個問題來詳細說明一下。 
WireShark出現的常見提示 
TCP Out_of_Order的緣由分析： 
通常來講是網絡擁塞，致使順序包抵達時間不一樣，延時太長，或者包丟失，須要從新組合數據單元，由於他們多是由不一樣的路徑到達你的電腦上面。 
TCP Retransmission緣由分析： 
很明顯是上面的超時引起的數據重傳。 
TCP dup ack XXX#X緣由分析： 
就是重複應答#前的表示報文到哪一個序號丟失，#後面的是表示第幾回丟失。 
tcp previous segment not captured緣由分析 
意思就是報文沒有捕捉到，出現報文的丟失。 
下面就詳細的報文進行分析： 

1221：seq:8321,ack:18292,len:0， 
全部下一條報文的應該是seq：18292，ack：8321，可是在1230報文段出現報文丟失，該報文seq：27392，ack：8321，因此出現了報文的丟失， 
全部在1232到1238都是爲了補全seq從18292到27392的報文段。 

1439顯示報文丟失seq:53800,ack:9765 
1438 seq:51200,:ack:9765,len:1300 
因此1439的seq應該是51200+1300=52500，可是1439直接到了53800因此出現丟包狀況，在1440從新發送52500到53800的數據包。 

1587的意思是出現丟包了，未收到以前的數據包，也要進行重傳或者重組，1586的ack=211249，也就是要求server端下次發送seq=211249的包，結果 1587發送的數據包seq=212261.說明server端收到過client端發送的數據包ack=212261，則判斷以前的一個數據包未收到。