寫在前面：
近期，博主在工作中碰到不少奇怪的的故障，有點身心俱疲，博客更新的進度也有些耽擱。
在這裏，分享其中一個案例。從解決方式上來回溯可能是什麼原因導致了這個問題，並回顧這裏面所蘊含的知識。
故障現象：
部分用戶反饋打開我方暴露在公網上的應用無法打開，瀏覽器提示檢查TLS、SSL相關設置。通過客戶端側的抓包查看，似乎是SSL建立連接存在問題。常見的SSL建立連接過程如下：
與抓包進行對比查看
可以明顯看到，SSL的協商沒能繼續完成。除此之外，我們可以看到，這裏出現了IP包分片的現象。
以此，我們考慮該故障這是否與IP分片、TCP分片有關。
進一步分析：
通過上面的分析，我們可以看到，本次客戶端與服務端進行TCP MSS協商，雙方提交的MSS值均爲1460
以此可以推測，加上20字節的IP包頭和20字節的TCP包頭，客戶端側與服務端側的MTU值爲1500，這也是MTU的常見數值。然而在故障的抓包中，針對分片的IP包，我們可以看到最大的IP包大小爲1476
這代表着數據包在傳輸過程中，被分片轉發了。
正常情況下，即使數據包被分片轉發，當抓包側拿到最後一個分片包後仍然能夠通過解讀關鍵位，解析該數據包。但故障數據包中，wireshark沒有解析到server hello done等，TLS交互過程中，關鍵位置位的數據包。我們以此懷疑，數據包在除了在轉發過程中被分片以外，還存在着數據包不完整的現象。我們順着這樣的思路，繼續分析下去.
我們繼續分析數據包，可以看到在客戶端側的抓包中，能夠看到這存在着數據包亂序的現象。
經過分析，對比本抓包中的數據包順序，正常的順序應該是9—》11—》12—》10—》14，數據包13是TCP RTO超時後進行的重傳。
點開數據包13，可以看到該數據包爲帶有TLS協商過程中標誌的，這些標誌位的置位代表着服務端完成了標準TLS協商過程中的2、3、4步。
之後，從數據包14的ACK No來看，客戶端也確認了完整收到了之前服務器端發過來的TCP數據包。在操作系統將數據包進行重組後，應該可以提交給應用側。
但之後比較奇怪的是，從數據包15來看，客戶端通過發送FIN包直接將連接斷開，這導致了SSL協商的失敗。
在分析第二組TLS協商過程中的抓包時，現象與剛纔的一組不同。在此作簡要解釋，如下圖：
客戶端在收到server hello done之後迴應了客戶端祕鑰等信息，但服務器端沒有響應，服務器端而是迴應了收到客戶端最開始發出的Client Hello。這第二組抓包表明，服務器端可能沒收到客戶端發出的認證信息，甚至服務器端可能沒有收到數據包26.我們從抓包中也可以看到，客戶端針對數據包26進行了重傳。
之後服務器將連接RST掉，這可能是由於在經過一次重試後，RTO時間超時。
這個現象與第一組包中，情況相似，在第一組數據包中，服務器端似乎沒有收到數據包9，這導致了客戶端針對數據包9進行了重傳，而之後客戶端將連接斷開，這可能也是由於TCP RTO超時。
通過分析這兩組交互，我們可以得出，雖然兩次交互結束的現象不同。但從數據包的現象來看，都是由於客戶端迴應的ACK沒有被服務器端收到，在第一次交互中，客戶端進行了重傳；在第二次交互中，客戶端與服務器端均進行了重傳。兩次的交互，區別在於第一次，客戶端的RTO時間先超時，客戶端將鏈接斷開。而第二次客戶端的RTO還未超時，所以客戶端發出了關於TLS的客戶端認證信息，而之後服務端的RTO超時，服務端將鏈接斷開。
RTO時間超時的可能有很多，可能是ACK包確實沒有被收到；也有可能是因爲數據包亂序，客戶端需要重組而導致等待確認數據包的時間邊長。其中ACK包沒有收到的現象，不禁讓我想起博主的《鍋來了！！！不要慌~~~》——那些你應該知道的知識（一）這篇文章，可能是由於IPS或WAF判斷爲重複ACK攻擊，導致數據包交互異常的現象。
這裏要講到RTO的超時時間，在TCP連接建立完成後，RTO時間是根據每一次TCP交互的RTT時間動態變化的，不是一個固定值。
解決問題：
我們通過，改小客戶端操作系統本地連接的MTU值，嘗試是否能夠解決該問題。
在windows客戶端中，修改方法如下
netsh interface ipv4 set subinterface "本地連接" mtu=1476 store=persistent
在這裏，根據前文的推測我們可以知道，路徑中MTU值爲1476，我們進行修改。
在這樣的修改完成後，我們可以推測，MTU=1476，MSS=1476-20-20=1436
在TLS協商過程中，當TCP負載大於1436時，會在操作系統層面，進行TCP分片。這將避免數據包在中間轉發的過程中發生分片。
最終經過驗證，通過這種方法，解決了該問題。
原因分析：
在正常的情況下，即使在數據包轉發的路徑上，因爲MTU不匹配，而導致在轉發過程中出現了IP數據包分片的現象，在接收端收到該數據包後，也會將數據包進行整合,提供給應用進行處理。
在本故障中，客戶端收到數據包爲分片的IP數據包，需要將數據包進行重組。同樣，由於TCP數據包存在亂序，客戶端需要等待理應先到達的數據包收到後，才能確認該數據包，這也增加了客戶端側等待的時間。在服務器側，同樣也可能存在相同的問題，甚至不排除因爲TCP亂序，而導致安全設備誤殺的可能性。
針對此故障，我們懷疑可能是中間運營商設備在處理分片數據包時，存在問題，可能導致TCP亂序現象的出現。我們將客戶端本地MTU改小，導致數據在客戶端側即進行分片，而不會在轉發路徑上分片，這有可能導致能夠解決該問題。
總結：
網絡工程師面對的環境錯綜複雜，很多環節也不是在我們的掌握範圍之內。很多情況下，只能通過蛛絲馬跡嘗試去解決問題，推測可能導致問題出現的原因。只有在平時多積累，不輕易放過任何一個現象中存在的疑問，才能在真正出現問題時，體現價值與能力。