圖解TCP/IP協(xié)議
本文通過(guò)圖來(lái)梳理TCP-IP協(xié)議相關(guān)知識(shí)。TCP通信過(guò)程包括三個(gè)步驟：建立TCP連接通道，傳輸數(shù)據(jù)，斷開(kāi)TCP連接通道。如圖1所示，給出了TCP通信過(guò)程的示意圖。
圖1主要包括三部分：建立連接、傳輸數(shù)據(jù)、斷開(kāi)連接。
1)建立TCP連接很簡(jiǎn)單，通過(guò)三次握手便可建立連接。
2)建立好連接后，開(kāi)始傳輸數(shù)據(jù)。TCP數(shù)據(jù)傳輸牽涉到的概念很多：超時(shí)重傳、快速重傳、流量控制、擁塞控制等等。
3)斷開(kāi)連接的過(guò)程也很簡(jiǎn)單，通過(guò)四次握手完成斷開(kāi)連接的過(guò)程。
三次握手建立連接
三次握手建立連接的首要目的是確保傳輸?shù)目煽啃?，這也是TCP和UDP的關(guān)鍵區(qū)別。而確保可靠性的手段就是建立握手，其中用到了同步序列號(hào)。只有同步了序列號(hào)才有可靠的傳輸，TCP協(xié)議的許多特性都是依賴序列號(hào)實(shí)現(xiàn)的，比如流量控制、消息丟失后的重發(fā)等等，這也是三次握手中的報(bào)文被稱為SYN（Synchronize Sequence Numbers）。
第一次握手：客戶端發(fā)送syn包(seq=x)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn);
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN(ack=x+1)，同時(shí)自己也發(fā)送一個(gè)SYN包(seq=y)，即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài);
第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=y+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
握手過(guò)程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開(kāi)始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。
傳輸數(shù)據(jù)
a.超時(shí)重傳
超時(shí)重傳機(jī)制用來(lái)保證TCP傳輸?shù)目煽啃?。每次發(fā)送數(shù)據(jù)包時(shí)，發(fā)送的數(shù)據(jù)報(bào)都有seq號(hào)，接收端收到數(shù)據(jù)后，會(huì)回復(fù)ack進(jìn)行確認(rèn)，表示某一seq號(hào)數(shù)據(jù)已經(jīng)收到。發(fā)送方在發(fā)送了某個(gè)seq包后，等待一段時(shí)間，如果沒(méi)有收到對(duì)應(yīng)的ack回復(fù)，就會(huì)認(rèn)為報(bào)文丟失，會(huì)重傳這個(gè)數(shù)據(jù)包。
b.快速重傳
接受數(shù)據(jù)一方發(fā)現(xiàn)有數(shù)據(jù)包丟掉了。就會(huì)發(fā)送ack報(bào)文告訴發(fā)送端重傳丟失的報(bào)文。如果發(fā)送端連續(xù)收到標(biāo)號(hào)相同的ack包，則會(huì)觸發(fā)客戶端的快速重傳。比較超時(shí)重傳和快速重傳，可以發(fā)現(xiàn)超時(shí)重傳是發(fā)送端在傻等超時(shí)，然后觸發(fā)重傳;而快速重傳則是接收端主動(dòng)告訴發(fā)送端數(shù)據(jù)沒(méi)收到，然后觸發(fā)發(fā)送端重傳。
c.流量控制
這里主要說(shuō)TCP滑動(dòng)窗流量控制。TCP頭里有一個(gè)字段叫Window，又叫Advertised-Window，這個(gè)字段是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)。于是發(fā)送端就可以根據(jù)這個(gè)接收端的處理能力來(lái)發(fā)送數(shù)據(jù)，而不會(huì)導(dǎo)致接收端處理不過(guò)來(lái)。 滑動(dòng)窗可以是提高TCP傳輸效率的一種機(jī)制。
d.擁塞控制
滑動(dòng)窗用來(lái)做流量控制。流量控制只關(guān)注發(fā)送端和接受端自身的狀況，而沒(méi)有考慮整個(gè)網(wǎng)絡(luò)的通信情況。擁塞控制，則是基于整個(gè)網(wǎng)絡(luò)來(lái)考慮的?？紤]一下這樣的場(chǎng)景：某一時(shí)刻網(wǎng)絡(luò)上的延時(shí)突然增加，那么，TCP對(duì)這個(gè)事做出的應(yīng)對(duì)只有重傳數(shù)據(jù)，但是，重傳會(huì)導(dǎo)致網(wǎng)絡(luò)的負(fù)擔(dān)更重，于是會(huì)導(dǎo)致更大的延遲以及更多的丟包，于是，這個(gè)情況就會(huì)進(jìn)入惡性循環(huán)被不斷地放大。試想一下，如果一個(gè)網(wǎng)絡(luò)內(nèi)有成千上萬(wàn)的TCP連接都這么行事，那么馬上就會(huì)形成“網(wǎng)絡(luò)風(fēng)暴”，TCP這個(gè)協(xié)議就會(huì)拖垮整個(gè)網(wǎng)絡(luò)。為此，TCP引入了擁塞控制策略。擁塞策略算法主要包括：慢啟動(dòng)，擁塞避免，擁塞發(fā)生，快速恢復(fù)。
四次握手?jǐn)嚅_(kāi)連接
第一次揮手：主動(dòng)關(guān)閉方發(fā)送一個(gè)FIN，用來(lái)關(guān)閉主動(dòng)方到被動(dòng)關(guān)閉方的數(shù)據(jù)傳送，也就是主動(dòng)關(guān)閉方告訴被動(dòng)關(guān)閉方：我已經(jīng)不會(huì)再給你發(fā)數(shù)據(jù)了(當(dāng)然，在fin包之前發(fā)送出去的數(shù)據(jù)，如果沒(méi)有收到對(duì)應(yīng)的ack確認(rèn)報(bào)文，主動(dòng)關(guān)閉方依然會(huì)重發(fā)這些數(shù)據(jù))，但此時(shí)主動(dòng)關(guān)閉方還可以接受數(shù)據(jù)。
第二次揮手：被動(dòng)關(guān)閉方收到FIN包后，發(fā)送一個(gè)ACK給對(duì)方，確認(rèn)序號(hào)為收到序號(hào)+1(與SYN相同，一個(gè)FIN占用一個(gè)序號(hào))。
第三次揮手：被動(dòng)關(guān)閉方發(fā)送一個(gè)FIN，用來(lái)關(guān)閉被動(dòng)關(guān)閉方到主動(dòng)關(guān)閉方的數(shù)據(jù)傳送，也就是告訴主動(dòng)關(guān)閉方，我的數(shù)據(jù)也發(fā)送完了，不會(huì)再給你發(fā)數(shù)據(jù)了。
第四次揮手：主動(dòng)關(guān)閉方收到FIN后，發(fā)送一個(gè)ACK給被動(dòng)關(guān)閉方，確認(rèn)序號(hào)為收到序號(hào)+1，至此，完成四次揮手。
如果您是開(kāi)發(fā)者，或者對(duì)本篇文章感興趣，請(qǐng)關(guān)注本人，后續(xù)會(huì)更新更多相關(guān)文章！敬請(qǐng)期待！
