本文整理了一些TCP/IP協(xié)議簇中需要必知必會(huì)的十大問題，既是面試高頻問題，又是程序員必備基礎(chǔ)素養(yǎng)。

一、TCP/IP模型

TCP/IP協(xié)議模型(Transmission Control Protocol/Internet Protocol)，包含了一系列構(gòu)成互聯(lián)網(wǎng)基礎(chǔ)的網(wǎng)絡(luò)協(xié)議，是Internet的核心協(xié)議。

基于TCP/IP的參考模型將協(xié)議分成四個(gè)層次，它們分別是鏈路層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。下圖表示TCP/IP模型與OSI模型各層的對(duì)照關(guān)系。

3. 什么時(shí)候應(yīng)該使用TCP?

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

4. 什么時(shí)候應(yīng)該使用UDP?

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

七、DNS

DNS(Domain Name System，

• 第一次握手： 建立連接。客戶端發(fā)送連接請(qǐng)求報(bào)文段，將SYN位置為1，Sequence Number為x;然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn);
• 第二次握手： 服務(wù)器收到SYN報(bào)文段。服務(wù)器收到客戶端的SYN報(bào)文段，需要對(duì)這個(gè)SYN報(bào)文段進(jìn)行確認(rèn)，設(shè)置Acknowledgment Number為x+1(Sequence Number+1);同時(shí)，自己自己還要發(fā)送SYN請(qǐng)求信息，將SYN位置為1，Sequence Number為y;服務(wù)器端將上述所有信息放到一個(gè)報(bào)文段(即SYN+ACK報(bào)文段)中，一并發(fā)送給客戶端，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài);
• 第三次握手： 客戶端收到服務(wù)器的SYN+ACK報(bào)文段。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報(bào)文段，這個(gè)報(bào)文段發(fā)送完畢以后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。

為什么要三次握手?

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

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

但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來(lái)數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。

采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接?！?/p>

2. 四次揮手

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

從圖中可以看出，B進(jìn)行了三次流量控制。第一次把窗口減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最后減到 rwnd = 0 ，即不允許發(fā)送方再發(fā)送數(shù)據(jù)了。這種使發(fā)送方暫停發(fā)送的狀態(tài)將持續(xù)到

2. 快重傳和快恢復(fù)

(1) 快重傳

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

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

顯然，接收方不能確認(rèn)M4，因?yàn)镸4是收到的失序報(bào)文段。根據(jù) 可靠傳輸原理，接收方可以什么都不做，也可以在適當(dāng)時(shí)機(jī)發(fā)送一次對(duì)M2的確認(rèn)。

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

快重傳算法還規(guī)定，發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段M3，而不必 繼續(xù)等待M3設(shè)置的重傳計(jì)時(shí)器到期。

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

(2) 快恢復(fù)

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

當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)，就執(zhí)行“乘法減小”算法，把慢開始門限ssthresh減半。

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

新聞標(biāo)題：TCP/IP，你必知必會(huì)的十個(gè)問題
當(dāng)前路徑：http://jinyejixie.com/news13/104163.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號(hào)、軟件開發(fā)、網(wǎng)站導(dǎo)航、域名注冊(cè)、網(wǎng)站設(shè)計(jì)公司、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)