建站
咨詢
售后
建站咨詢
新聞中心
TCP是一種可靠的協(xié)議，在網(wǎng)絡(luò)交互的過程中，由于TCP報文是封裝在IP協(xié)議中的，IP協(xié)議的無連接特性導(dǎo)致其可能在交互的過程中丟失，在這種情況下，TCP協(xié)議如何保障其傳輸?shù)目煽啃阅兀?/p>
創(chuàng)新互聯(lián)公司科技有限公司專業(yè)互聯(lián)網(wǎng)基礎(chǔ)服務(wù)商，為您提供雙線服務(wù)器托管，高防服務(wù)器租用，成都IDC機(jī)房托管，成都主機(jī)托管等互聯(lián)網(wǎng)服務(wù)。
T C P通過在發(fā)送數(shù)據(jù)報文時設(shè)置一個超時定時器來解決這種問題，如果在定時器溢出時還沒有收到來自對端對發(fā)送報文的確認(rèn)，它就重傳該數(shù)據(jù)報文。
關(guān)于TCP重傳
TCP有重傳是正常的機(jī)制，為了保障數(shù)據(jù)傳輸可靠性。只是局域網(wǎng)環(huán)境，網(wǎng)絡(luò)質(zhì)量有保障，因為網(wǎng)絡(luò)問題出現(xiàn)重傳應(yīng)該極低;互聯(lián)網(wǎng)或城域網(wǎng)環(huán)境，線路復(fù)雜(可以想象下城市地下管網(wǎng)，錯綜復(fù)雜的電線桿等)，網(wǎng)絡(luò)質(zhì)量不好保障，重傳出現(xiàn)概率較高。
TCP有重傳，也不一定是網(wǎng)絡(luò)層面的問題。也可能是接收端不存在，接收端receive buffer滿了，應(yīng)用程序有異常鏈接未正常關(guān)閉等等等。
TCP/IP相關(guān)
排查網(wǎng)絡(luò)問題，要掌握TCP/IP原理，真相都在一個一個的數(shù)據(jù)包里。以下是和TCP重傳比較關(guān)鍵的幾個參數(shù)。
建立TCP鏈接時的參數(shù)
TCP重傳類型
超時重傳
在請求包發(fā)出去的時候，開啟一個計時器，當(dāng)計時器達(dá)到時間之后，沒有收到ACK，則就進(jìn)行重發(fā)請求的操作，一直重發(fā)直到達(dá)到重發(fā)上限次數(shù)或者收到ACK。
快速重傳
當(dāng)接收方收到的數(shù)據(jù)包是不正常的序列號，那么接收方會重復(fù)把應(yīng)該收到的那一條ACK重復(fù)發(fā)送，這個時候，如果發(fā)送方收到連續(xù)3條的同一個序列號的ACK，那么就會啟動快速重傳機(jī)制，把這個ACK對應(yīng)的發(fā)送包重新發(fā)送一次。具體可以參考：
常見問題與措施
單臺機(jī)器或單個應(yīng)用機(jī)器tcp重傳
可能是鏈接的服務(wù)器或端口無法訪問
多臺機(jī)器或多個應(yīng)用同時tcp重傳
可能是網(wǎng)絡(luò)抖動
查看網(wǎng)絡(luò)區(qū)域埋點，查看網(wǎng)絡(luò)設(shè)備報警，看是否有區(qū)域網(wǎng)絡(luò)抖動2區(qū)域網(wǎng)絡(luò)沒問題的話?？梢杂贸Ｒ妴栴}：的方法縮小排查范圍
帶寬跑滿
1、查看主機(jī)監(jiān)控
不常見問題
1 網(wǎng)絡(luò)設(shè)備端口或光模塊異常等導(dǎo)致包checksum失敗 2 網(wǎng)絡(luò)路由收斂抖動 3 主機(jī)網(wǎng)絡(luò)驅(qū)動有bug，網(wǎng)絡(luò)設(shè)備有bug等
如何監(jiān)控
使用tsar -tcp -C 可以監(jiān)控到tcp的retran屬性也即是重傳次數(shù)。
tsar --tcp -C | sed 's/:/_/g;s/=/ /g' | xargs -n 2
感興趣的朋友可以直接執(zhí)行以下監(jiān)控腳本獲取tcp相關(guān)的狀態(tài)監(jiān)控數(shù)據(jù)，適用于open-falcon。
案例實踐
（1）在遇到丟包重傳的機(jī)器上抓包并使用wireshark 分析該包，注意因為重傳不是時刻都有的，所以抓包命令是要持續(xù)執(zhí)行以便捕捉到重傳的包。使用wireshark打開tcpdump的結(jié)果，在搜索框里入手tcp.analysis.retransmission 得到如下結(jié)果：
圖1 表明服務(wù)端發(fā)生了三次重傳動作。
（2）由于包比較多，我們可以使用wireshark的追蹤流功能獲取重傳相關(guān)的tcp流。
圖二 追蹤流–>TCP流 可以得到重傳相關(guān)的數(shù)據(jù)包
圖三 可以看出客戶端和服務(wù)端的請求與應(yīng)答。
（3）解析重傳
特別需要說明的是：
NO 67,68 client端由于某些原因沒有收到正確的包數(shù)據(jù)，向server端發(fā)送dup ack，參考基礎(chǔ)知識提到的快速重傳
NO.68和NO.69之間的時間差200ms(關(guān)注time那一列，其他都是相差小于1ms)，server等待超時，于是重傳。
NO 73-74是client端發(fā)送了一個fin包并主動關(guān)閉連接。
這個案例僅僅發(fā)生一次，沒有復(fù)現(xiàn)，通過抓包解析出來分析沒有得到明確的結(jié)論。
小結(jié)
本文總結(jié)自己工作過程中遇到的TCP重傳問題的解決過程 ，側(cè)重于大致的解決問題的思路與具體的實踐，理論知識偏少，大家有興趣的可以多查閱相關(guān)文章以便深入了解tcp的工作機(jī)制。
分享文章：詳解TCP重傳機(jī)制
文章起源：http://www.dlmjj.cn/article/dhsjchj.html
