一文把TCP/IP協(xié)議講絕了！

三、網(wǎng)絡(luò )層

1、IP協(xié)議

IP協(xié)議是TCP/IP協(xié)議的核心，所有的TCP，UDP，IMCP，IGMP的數據都以IP數據格式傳輸。要注意的是，IP不是可靠的協(xié)議，這是說(shuō)，IP協(xié)議沒(méi)有提供一種數據未傳達以后的處理機制，這被認為是上層協(xié)議：TCP或UDP要做的事情。

1.1 IP地址

在數據鏈路層中我們一般通過(guò)MAC地址來(lái)識別不同的節點(diǎn)，而在IP層我們也要有一個(gè)類(lèi)似的地址標識，這就是IP地址。

32位IP地址分為網(wǎng)絡(luò )位和地址位，這樣做可以減少路由器中路由表記錄的數目，有了網(wǎng)絡(luò )地址，就可以限定擁有相同網(wǎng)絡(luò )地址的終端都在同一個(gè)范圍內，那么路由表只需要維護一條這個(gè)網(wǎng)絡(luò )地址的方向，就可以找到相應的這些終端了。

A類(lèi)IP地址：0.0.0.0~127.0.0.0

B類(lèi)IP地址：128.0.0.1~191.255.0.0

C類(lèi)IP地址：192.168.0.0~239.255.255.0

1.2 IP協(xié)議頭

這里只介紹八位的TTL字段。這個(gè)字段規定該數據包在穿過(guò)多少個(gè)路由之后才會(huì )被拋棄。某個(gè)IP數據包每穿過(guò)一個(gè)路由器，該數據包的TTL數值就會(huì )減少1，當該數據包的TTL成為零，它就會(huì )被自動(dòng)拋棄。

這個(gè)字段的最大值也就是255，也就是說(shuō)一個(gè)協(xié)議包也就在路由器里面穿行255次就會(huì )被拋棄了，根據系統的不同，這個(gè)數字也不一樣，一般是32或者是64。

2、ARP及RARP協(xié)議

ARP是根據IP地址獲取MAC地址的一種協(xié)議。

ARP（地址解析）協(xié)議是一種解析協(xié)議，本來(lái)主機是完全不知道這個(gè)IP對應的是哪個(gè)主機的哪個(gè)接口，當主機要發(fā)送一個(gè)IP包的時(shí)候，會(huì )首先查一下自己的ARP高速緩存（就是一個(gè)IP-MAC地址對應表緩存）。

如果查詢(xún)的IP-MAC值對不存在，那么主機就向網(wǎng)絡(luò )發(fā)送一個(gè)ARP協(xié)議廣播包，這個(gè)廣播包里面就有待查詢(xún)的IP地址，而直接收到這份廣播的包的所有主機都會(huì )查詢(xún)自己的IP地址，如果收到廣播包的某一個(gè)主機發(fā)現自己符合條件，那么就準備好一個(gè)包含自己的MAC地址的ARP包傳送給發(fā)送ARP廣播的主機。

而廣播主機拿到ARP包后會(huì )更新自己的ARP緩存（就是存放IP-MAC對應表的地方）。發(fā)送廣播的主機就會(huì )用新的ARP緩存數據準備好數據鏈路層的的數據包發(fā)送工作。

RARP協(xié)議的工作與此相反，不做贅述。

3、ICMP協(xié)議

IP協(xié)議并不是一個(gè)可靠的協(xié)議，它不保證數據被送達，那么，自然的保證數據送達的工作應該由其他的模塊來(lái)完成。其中一個(gè)重要的模塊就是ICMP（網(wǎng)絡(luò )控制報文）協(xié)議。ICMP不是高層協(xié)議，而是IP層的協(xié)議。

當傳送IP數據包發(fā)生錯誤。比如主機不可達，路由不可達等等，ICMP協(xié)議將會(huì )把錯誤信息封包，然后傳送回給主機。給主機一個(gè)處理錯誤的機會(huì )，這也就是為什么說(shuō)建立在IP層以上的協(xié)議是可能做到安全的原因。

四、ping

ping可以說(shuō)是ICMP的最著(zhù)名的應用，是TCP/IP協(xié)議的一部分。利用“ping”命令可以檢查網(wǎng)絡(luò )是否連通，可以很好地幫助我們分析和判定網(wǎng)絡(luò )故障。

例如：當我們某一個(gè)網(wǎng)站上不去的時(shí)候。通常會(huì )ping一下這個(gè)網(wǎng)站。ping會(huì )回顯出一些有用的信息。一般的信息如下:

ping這個(gè)單詞源自聲納定位，而這個(gè)程序的作用也確實(shí)如此，它利用ICMP協(xié)議包來(lái)偵測另一個(gè)主機是否可達。原理是用類(lèi)型碼為0的ICMP發(fā)請求，受到請求的主機則用類(lèi)型碼為8的ICMP回應。

五、Traceroute

Traceroute是用來(lái)偵測主機到目的主機之間所經(jīng)路由情況的重要工具，也是最便利的工具。

Traceroute的原理是非常非常的有意思，它收到到目的主機的IP后，首先給目的主機發(fā)送一個(gè)TTL=1的UDP數據包，而經(jīng)過(guò)的第一個(gè)路由器收到這個(gè)數據包以后，就自動(dòng)把TTL減1，而TTL變?yōu)?以后，路由器就把這個(gè)包給拋棄了，并同時(shí)產(chǎn)生一個(gè)主機不可達的ICMP數據報給主機。主機收到這個(gè)數據報以后再發(fā)一個(gè)TTL=2的UDP數據報給目的主機，然后刺激第二個(gè)路由器給主機發(fā)ICMP數據報。如此往復直到到達目的主機。這樣，traceroute就拿到了所有的路由器IP。

六、TCP/UDP

TCP/UDP都是是傳輸層協(xié)議，但是兩者具有不同的特性，同時(shí)也具有不同的應用場(chǎng)景，下面以圖表的形式對比分析。

面向報文

面向報文的傳輸方式是應用層交給UDP多長(cháng)的報文，UDP就照樣發(fā)送，即一次發(fā)送一個(gè)報文。因此，應用程序必須選擇合適大小的報文。若報文太長(cháng)，則IP層需要分片，降低效率。若太短，會(huì )是IP太小。

面向字節流

面向字節流的話(huà)，雖然應用程序和TCP的交互是一次一個(gè)數據塊（大小不等），但TCP把應用程序看成是一連串的無(wú)結構的字節流。TCP有一個(gè)緩沖，當應用程序傳送的數據塊太長(cháng)，TCP就可以把它劃分短一些再傳送。

關(guān)于擁塞控制，流量控制，是TCP的重點(diǎn)，后面講解。

TCP和UDP協(xié)議的一些應用

什么時(shí)候應該使用TCP？

當對網(wǎng)絡(luò )通訊質(zhì)量有要求的時(shí)候，比如：整個(gè)數據要準確無(wú)誤的傳遞給對方，這往往用于一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協(xié)議，POP、SMTP等郵件傳輸的協(xié)議。

什么時(shí)候應該使用UDP？

當對網(wǎng)絡(luò )通訊質(zhì)量要求不高的時(shí)候，要求網(wǎng)絡(luò )通訊速度能盡量的快，這時(shí)就可以使用UDP。

七、DNS

DNS（Domain Name System，域名系統），因特網(wǎng)上作為域名和IP地址相互映射的一個(gè)分布式數據庫，能夠使用戶(hù)更方便的訪(fǎng)問(wèn)互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的IP數串。通過(guò)主機名，最終得到該主機名對應的IP地址的過(guò)程叫做域名解析（或主機名解析）。DNS協(xié)議運行在UDP協(xié)議之上，使用端口號53。

八、TCP連接的建立與終止

1、三次握手

TCP是面向連接的，無(wú)論哪一方向另一方發(fā)送數據之前，都必須先在雙方之間建立一條連接。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，連接是通過(guò)三次握手進(jìn)行初始化的。三次握手的目的是同步連接雙方的序列號和確認號并交換 TCP窗口大小信息。

第一次握手：建立連接?？蛻?hù)端發(fā)送連接請求報文段，將SYN位置為1，Sequence Number為x；然后，客戶(hù)端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認；

第二次握手：服務(wù)器收到SYN報文段。服務(wù)器收到客戶(hù)端的SYN報文段，需要對這個(gè)SYN報文段進(jìn)行確認，設置Acknowledgment Number為x+1（Sequence Number+1）；同時(shí)，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y；服務(wù)器端將上述所有信息放到一個(gè)報文段（即SYN+ACK報文段）中，一并發(fā)送給客戶(hù)端，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)； 

第三次握手：客戶(hù)端收到服務(wù)器的SYN+ACK報文段。然后將Acknowledgment Number設置為y+1，向服務(wù)器發(fā)送ACK報文段，這個(gè)報文段發(fā)送完畢以后，客戶(hù)端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。

為什么要三次握手？

為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤。

具體例子：“已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請求報文段并沒(méi)有丟失，而是在某個(gè)網(wǎng)絡(luò )結點(diǎn)長(cháng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達server。本來(lái)這是一個(gè)早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個(gè)新的連接請求。

于是就向client發(fā)出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。由于現在client并沒(méi)有發(fā)出建立連接的請求，因此不會(huì )理睬server的確認，也不會(huì )向server發(fā)送數據。但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來(lái)數據。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發(fā)生。例如剛才那種情況，client不會(huì )向server的確認發(fā)出確認。server由于收不到確認，就知道client并沒(méi)有要求建立連接?！?/p>

2、四次揮手

當客戶(hù)端和服務(wù)器通過(guò)三次握手建立了TCP連接以后，當數據傳送完畢，肯定是要斷開(kāi)TCP連接的啊。那對于TCP的斷開(kāi)連接，這里就有了神秘的“四次分手”。

第一次分手：主機1（可以使客戶(hù)端，也可以是服務(wù)器端），設置Sequence Number，向主機2發(fā)送一個(gè)FIN報文段；此時(shí)，主機1進(jìn)入FIN_WAIT_1狀態(tài)；這表示主機1沒(méi)有數據要發(fā)送給主機2了；

第二次分手：主機2收到了主機1發(fā)送的FIN報文段，向主機1回一個(gè)ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進(jìn)入FIN_WAIT_2狀態(tài)；主機2告訴主機1，我“同意”你的關(guān)閉請求；

第三次分手：主機2向主機1發(fā)送FIN報文段，請求關(guān)閉連接，同時(shí)主機2進(jìn)入LAST_ACK狀態(tài)；

第四次分手：主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段，然后主機1進(jìn)入TIME_WAIT狀態(tài)；主機2收到主機1的ACK報文段以后，就關(guān)閉連接；此時(shí)，主機1等待2MSL后依然沒(méi)有收到回復，則證明Server端已正常關(guān)閉，那好，主機1也可以關(guān)閉連接了。

為什么要四次分手？

TCP協(xié)議是一種面向連接的、可靠的、基于字節流的運輸層通信協(xié)議。TCP是全雙工模式，這就意味著(zhù)，當主機1發(fā)出FIN報文段時(shí)，只是表示主機1已經(jīng)沒(méi)有數據要發(fā)送了，主機1告訴主機2，它的數據已經(jīng)全部發(fā)送完畢了；但是，這個(gè)時(shí)候主機1還是可以接受來(lái)自主機2的數據；當主機2返回ACK報文段時(shí)，表示它已經(jīng)知道主機1沒(méi)有數據發(fā)送了，但是主機2還是可以發(fā)送數據到主機1的；當主機2也發(fā)送了FIN報文段時(shí)，這個(gè)時(shí)候就表示主機2也沒(méi)有數據要發(fā)送了，就會(huì )告訴主機1，我也沒(méi)有數據要發(fā)送了，之后彼此就會(huì )愉快的中斷這次TCP連接。

為什么要等待2MSL？

MSL：報文段最大生存時(shí)間，它是任何報文段被丟棄前在網(wǎng)絡(luò )內的最長(cháng)時(shí)間。原因有二：

· 保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉

· 保證這次連接的重復數據段從網(wǎng)絡(luò )中消失

第一點(diǎn)：如果主機1直接CLOSED了，那么由于IP協(xié)議的不可靠性或者是其它網(wǎng)絡(luò )原因，導致主機2沒(méi)有收到主機1最后回復的ACK。那么主機2就會(huì )在超時(shí)之后繼續發(fā)送FIN，此時(shí)由于主機1已經(jīng)CLOSED了，就找不到與重發(fā)的FIN對應的連接。所以，主機1不是直接進(jìn)入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時(shí)候，能夠保證對方收到ACK，最后正確的關(guān)閉連接。

第二點(diǎn)：如果主機1直接CLOSED，然后又再向主機2發(fā)起一個(gè)新連接，我們不能保證這個(gè)新連接與剛關(guān)閉的連接的端口號是不同的。也就是說(shuō)有可能新連接和老連接的端口號是相同的。一般來(lái)說(shuō)不會(huì )發(fā)生什么問(wèn)題，但是還是有特殊情況出現：假設新連接和已經(jīng)關(guān)閉的老連接端口號是一樣的，如果前一次連接的某些數據仍然滯留在網(wǎng)絡(luò )中，這些延遲數據在建立新連接之后才到達主機2，由于新連接和老連接的端口號是一樣的，TCP協(xié)議就認為那個(gè)延遲的數據是屬于新連接的，這樣就和真正的新連接的數據包發(fā)生混淆了。所以TCP連接還要在TIME_WAIT狀態(tài)等待2倍MSL，這樣可以保證本次連接的所有數據都從網(wǎng)絡(luò )中消失。

九、TCP流量控制

如果發(fā)送方把數據發(fā)送得過(guò)快，接收方可能會(huì )來(lái)不及接收，這就會(huì )造成數據的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來(lái)得及接收。

利用滑動(dòng)窗口機制可以很方便地在TCP連接上實(shí)現對發(fā)送方的流量控制。

設A向B發(fā)送數據。在連接建立時(shí)，B告訴了A：“我的接收窗口是rwnd=400”（這里的rwnd表示receiver window）。因此，發(fā)送方的發(fā)送窗口不能超過(guò)接收方給出的接收窗口的數值。請注意，TCP的窗口單位是字節，不是報文段。假設每一個(gè)報文段為100字節長(cháng)，而數據報文段序號的初始值設為1。大寫(xiě)ACK表示首部中的確認位ACK，小寫(xiě)ack表示確認字段的值ack。

從圖中可以看出，B進(jìn)行了三次流量控制。第一次把窗口減少到rwnd=300 ，第二次又減到了rwnd=100，最后減到rwnd=0，即不允許發(fā)送方再發(fā)送數據了。這種使發(fā)送方暫停發(fā)送的狀態(tài)將持續到主機B重新發(fā)出一個(gè)新的窗口值為止。B向A發(fā)送的三個(gè)報文段都設置了ACK=1，只有在A(yíng)CK=1時(shí)確認號字段才有意義。

TCP為每一個(gè)連接設有一個(gè)持續計時(shí)器（persistence timer）。只要TCP連接的一方收到對方的零窗口通知，就啟動(dòng)持續計時(shí)器。若持續計時(shí)器設置的時(shí)間到期，就發(fā)送一個(gè)零窗口控測報文段（攜1字節的數據），那么收到這個(gè)報文段的一方就重新設置持續計時(shí)器。

十、TCP擁塞控制

發(fā)送方維持一個(gè)擁塞窗口cwnd（congestion window）的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng)絡(luò )的擁塞程度，并且動(dòng)態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口。

發(fā)送方控制擁塞窗口的原則是：只要網(wǎng)絡(luò )沒(méi)有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發(fā)送出去。但只要網(wǎng)絡(luò )出現擁塞，擁塞窗口就減小一些，以減少注入到網(wǎng)絡(luò )中的分組數。

慢開(kāi)始算法：

當主機開(kāi)始發(fā)送數據時(shí)，如果立即所大量數據字節注入到網(wǎng)絡(luò )，那么就有可能引起網(wǎng)絡(luò )擁塞，因為現在并不清楚網(wǎng)絡(luò )的負荷情況。因此，較好的方法是 先探測一下，即由小到大逐漸增大發(fā)送窗口，也就是說(shuō)，由小到大逐漸增大擁塞窗口數值。

通常在剛剛開(kāi)始發(fā)送報文段時(shí)，先把擁塞窗口cwnd設置為一個(gè)最大報文段MSS的數值。而在每收到一個(gè)對新的報文段的確認后，把擁塞窗口增加至多一個(gè)MSS的數值。用這樣的方法逐步增大發(fā)送方的擁塞窗口cwnd ，可以使分組注入到網(wǎng)絡(luò )的速率更加合理。

每經(jīng)過(guò)一個(gè)傳輸輪次，擁塞窗口cwnd就加倍。一個(gè)傳輸輪次所經(jīng)歷的時(shí)間其實(shí)就是往返時(shí)間RTT。不過(guò)“傳輸輪次”更加強調：把擁塞窗口cwnd所允許發(fā)送的報文段都連續發(fā)送出去，并收到了對已發(fā)送的最后一個(gè)字節的確認。

另，慢開(kāi)始的“慢”并不是指cwnd的增長(cháng)速率慢，而是指在TCP開(kāi)始發(fā)送報文段時(shí)先設置cwnd=1，使得發(fā)送方在開(kāi)始時(shí)只發(fā)送一個(gè)報文段（目的是試探一下網(wǎng)絡(luò )的擁塞情況），然后再逐漸增大cwnd。

為了防止擁塞窗口cwnd增長(cháng)過(guò)大引起網(wǎng)絡(luò )擁塞，還需要設置一個(gè)慢開(kāi)始門(mén)限ssthresh狀態(tài)變量。慢開(kāi)始門(mén)限ssthresh的用法如下：

當 cwnd < ssthresh 時(shí)，使用上述的慢開(kāi)始算法。

當 cwnd > ssthresh 時(shí)，停止使用慢開(kāi)始算法而改用擁塞避免算法。

當 cwnd = ssthresh 時(shí)，既可使用慢開(kāi)始算法，也可使用擁塞控制避免算法。擁塞避免

擁塞避免

讓擁塞窗口cwnd緩慢地增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線(xiàn)性規律緩慢增長(cháng)，比慢開(kāi)始算法的擁塞窗口增長(cháng)速率緩慢得多。

無(wú)論在慢開(kāi)始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò )出現擁塞（其根據就是沒(méi)有收到確認），就要把慢開(kāi)始門(mén)限ssthresh設置為出現擁塞時(shí)的發(fā)送 方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd重新設置為1，執行慢開(kāi)始算法。

這樣做的目的就是要迅速減少主機發(fā)送到網(wǎng)絡(luò )中的分組數，使得發(fā)生擁塞的路由器有足夠時(shí)間把隊列中積壓的分組處理完畢。

如下圖，用具體數值說(shuō)明了上述擁塞控制的過(guò)程?，F在發(fā)送窗口的大小和擁塞窗口一樣大。

2、快重傳和快恢復

快重傳

快重傳算法首先要求接收方每收到一個(gè)失序的報文段后就立即發(fā)出重復確認（為的是使發(fā)送方及早知道有報文段沒(méi)有到達對方）而不要等到自己發(fā)送數據時(shí)才進(jìn)行捎帶確認。

接收方收到了M1和M2后都分別發(fā)出了確認?，F在假定接收方?jīng)]有收到M3但接著(zhù)收到了M4。

顯然，接收方不能確認M4，因為M4是收到的失序報文段。根據可靠傳輸原理，接收方可以什么都不做，也可以在適當時(shí)機發(fā)送一次對M2的確認。

但按照快重傳算法的規定，接收方應及時(shí)發(fā)送對M2的重復確認，這樣做可以讓發(fā)送方及早知道報文段M3沒(méi)有到達接收方。發(fā)送方接著(zhù)發(fā)送了M5和M6。接收方收到這兩個(gè)報文后，也還要再次發(fā)出對M2的重復確認。這樣，發(fā)送方共收到了接收方的四個(gè)對M2的確認，其中后三個(gè)都是重復確認。

快重傳算法還規定，發(fā)送方只要一連收到三個(gè)重復確認就應當立即重傳對方尚未收到的報文段M3，而不必繼續等待M3設置的重傳計時(shí)器到期。

由于發(fā)送方盡早重傳未被確認的報文段，因此采用快重傳后可以使整個(gè)網(wǎng)絡(luò )吞吐量提高約20%。

快恢復

與快重傳配合使用的還有快恢復算法，其過(guò)程有以下兩個(gè)要點(diǎn)：

當發(fā)送方連續收到三個(gè)重復確認，就執行“乘法減小”算法，把慢開(kāi)始門(mén)限ssthresh減半。

與慢開(kāi)始不同之處是現在不執行慢開(kāi)始算法（即擁塞窗口cwnd現在不設置為1），而是把cwnd值設置為 慢開(kāi)始門(mén)限ssthresh減半后的數值，然后開(kāi)始執行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線(xiàn)性增大。