TCP/IP，你必知必會的十個問題

本文整理了一些TCP/IP協(xié)議簇中需要必知必會的十大問題，既是面試高頻問題，又是程序員必備基礎(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é)議分成四個層次，它們分別是鏈路層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。下圖表示TCP/IP模型與OSI模型各層的對照關(guān)系。

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

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

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

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

七、DNS

DNS(Domain Name System，

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

為什么要三次握手?

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

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

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

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

2. 四次揮手

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

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

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

(1) 快重傳

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

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

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

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

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

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

(2) 快恢復(fù)

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

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

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

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

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

廣告

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