最近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
使用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，則判斷之前的一個數據包未收到。