TCP 與 UDP 的對(duì)比見問(wèn)題三。

1.3 網(wǎng)絡(luò)層

在 計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行通信的兩個(gè)計(jì)算機(jī)之間可能會(huì)經(jīng)過(guò)很多個(gè)數(shù)據(jù)鏈路，也可能還要經(jīng)過(guò)很多通信子網(wǎng)。網(wǎng)絡(luò)層的任務(wù)就是選擇合適的網(wǎng)間路由和交換結(jié)點(diǎn)， 確保數(shù)據(jù)及時(shí)傳送。 在發(fā)送數(shù)據(jù)時(shí)，網(wǎng)絡(luò)層把運(yùn)輸層產(chǎn)生的報(bào)文段或用戶數(shù)據(jù)報(bào)封裝成分組和包進(jìn)行傳送。在 TCP/IP 體系結(jié)構(gòu)中，由于網(wǎng)絡(luò)層使用 IP 協(xié)議，因此分組也叫 IP 數(shù)據(jù)報(bào) ，簡(jiǎn)稱 數(shù)據(jù)報(bào)。

這里要注意：不要把運(yùn)輸層的“用戶數(shù)據(jù)報(bào) ”和網(wǎng)絡(luò)層的“ IP 數(shù)據(jù)報(bào)”弄混。另外，無(wú)論是哪一層的數(shù)據(jù)單元，都可籠統(tǒng)地用“分組”來(lái)表示。

這里強(qiáng)調(diào)指出，網(wǎng)絡(luò)層中的“網(wǎng)絡(luò)”二字已經(jīng)不是我們通常談到的具體網(wǎng)絡(luò)，而是指計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)模型中第三層的名稱.

互聯(lián)網(wǎng)是由大量的異構(gòu)（heterogeneous）網(wǎng)絡(luò)通過(guò)路由器（router）相互連接起來(lái)的。互聯(lián)網(wǎng)使用的網(wǎng)絡(luò)層協(xié)議是無(wú)連接的網(wǎng)際協(xié)議（Internet Protocol）和許多路由選擇協(xié)議，因此互聯(lián)網(wǎng)的網(wǎng)絡(luò)層也叫做網(wǎng)際層或IP層。

1.4 數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層(data link layer)通常簡(jiǎn)稱為鏈路層。兩臺(tái)主機(jī)之間的數(shù)據(jù)傳輸，總是在一段一段的鏈路上傳送的，這就需要使用專門的鏈路層的協(xié)議。 在兩個(gè)相鄰節(jié)點(diǎn)之間傳送數(shù)據(jù)時(shí)，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來(lái)的 IP 數(shù)據(jù)報(bào)組裝成幀，在兩個(gè)相鄰節(jié)點(diǎn)間的鏈路上傳送幀。每一幀包括數(shù)據(jù)和必要的控制信息（如同步信息，地址信息，差錯(cuò)控制等）。

在接收數(shù)據(jù)時(shí)，控制信息使接收端能夠知道一個(gè)幀從哪個(gè)比特開始和到哪個(gè)比特結(jié)束。這樣，數(shù)據(jù)鏈路層在收到一個(gè)幀后，就可從中提出數(shù)據(jù)部分，上交給網(wǎng)絡(luò)層。
控制信息還使接收端能夠檢測(cè)到所收到的幀中有無(wú)差錯(cuò)。如果發(fā)現(xiàn)差錯(cuò)，數(shù)據(jù)鏈路層就簡(jiǎn)單地丟棄這個(gè)出了差錯(cuò)的幀，以避免繼續(xù)在網(wǎng)絡(luò)中傳送下去白白浪費(fèi)網(wǎng)絡(luò)資源。如果需要改正數(shù)據(jù)在鏈路層傳輸時(shí)出現(xiàn)差錯(cuò)（這就是說(shuō)，數(shù)據(jù)鏈路層不僅要檢錯(cuò)，而且還要糾錯(cuò)），那么就要采用可靠性傳輸協(xié)議來(lái)糾正出現(xiàn)的差錯(cuò)。這種方法會(huì)使鏈路層的協(xié)議復(fù)雜些。

1.5 物理層

在物理層上所傳送的數(shù)據(jù)單位是比特。

物理層(physical layer)的作用是實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異， 使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡(luò)的具體傳輸介質(zhì)是什么?！巴该鱾魉捅忍亓鳌北硎窘?jīng)實(shí)際電路傳送后的比特流沒(méi)有發(fā)生變化，對(duì)傳送的比特流來(lái)說(shuō)，這個(gè)電路好像是看不見的。

在互聯(lián)網(wǎng)使用的各種協(xié)中最重要和最著名的就是 TCP/IP 兩個(gè)協(xié)議。現(xiàn)在人們經(jīng)常提到的TCP/IP并不一定單指TCP和IP這兩個(gè)具體的協(xié)議，而往往表示互聯(lián)網(wǎng)所使用的整個(gè)TCP/IP協(xié)議族。

1.6 總結(jié)一下

上面我們對(duì)計(jì)算機(jī)網(wǎng)絡(luò)的五層體系結(jié)構(gòu)有了初步的了解，下面附送一張七層體系結(jié)構(gòu)圖總結(jié)一下。

二 ?TCP 三次握手和四次揮手(面試?？?

為了準(zhǔn)確無(wú)誤地把數(shù)據(jù)送達(dá)目標(biāo)處，TCP協(xié)議采用了三次握手策略。

2.1 TCP 三次握手漫畫圖解

如下圖所示，下面的兩個(gè)機(jī)器人通過(guò)3次握手確定了對(duì)方能正確接收和發(fā)送消息(圖片來(lái)源：《圖解HTTP》)。

簡(jiǎn)單示意圖：

• 客戶端–發(fā)送帶有 SYN 標(biāo)志的數(shù)據(jù)包–一次握手–服務(wù)端
• 服務(wù)端–發(fā)送帶有 SYN/ACK 標(biāo)志的數(shù)據(jù)包–二次握手–客戶端
• 客戶端–發(fā)送帶有帶有 ACK 標(biāo)志的數(shù)據(jù)包–三次握手–服務(wù)端

2.2 為什么要三次握手?

三次握手的目的是建立可靠的通信信道，說(shuō)到通訊，簡(jiǎn)單來(lái)說(shuō)就是數(shù)據(jù)的發(fā)送與接收，而三次握手最主要的目的就是雙方確認(rèn)自己與對(duì)方的發(fā)送與接收是正常的。

第一次握手：Client 什么都不能確認(rèn)；Server 確認(rèn)了對(duì)方發(fā)送正常，自己接收正常

第二次握手：Client 確認(rèn)了：自己發(fā)送、接收正常，對(duì)方發(fā)送、接收正常；Server 確認(rèn)了：對(duì)方發(fā)送正常，自己接收正常

第三次握手：Client 確認(rèn)了：自己發(fā)送、接收正常，對(duì)方發(fā)送、接收正常；Server 確認(rèn)了：自己發(fā)送、接收正常，對(duì)方發(fā)送、接收正常

所以三次握手就能確認(rèn)雙發(fā)收發(fā)功能都正常，缺一不可。

2.3 第2次握手傳回了ACK，為什么還要傳回SYN？

接收端傳回發(fā)送端所發(fā)送的ACK是為了告訴客戶端，我接收到的信息確實(shí)就是你所發(fā)送的信號(hào)了，這表明從客戶端到服務(wù)端的通信是正常的。而回傳SYN則是為了建立并確認(rèn)從服務(wù)端到客戶端的通信?！?/p>

SYN 同步序列編號(hào)(Synchronize Sequence Numbers) 是 TCP/IP 建立連接時(shí)使用的握手信號(hào)。在客戶機(jī)和服務(wù)器之間建立正常的 TCP 網(wǎng)絡(luò)連接時(shí)，客戶機(jī)首先發(fā)出一個(gè) SYN 消息，服務(wù)器使用 SYN-ACK 應(yīng)答表示接收到了這個(gè)消息，最后客戶機(jī)再以 ACK(Acknowledgement）消息響應(yīng)。這樣在客戶機(jī)和服務(wù)器之間才能建立起可靠的 TCP 連接，數(shù)據(jù)才可以在客戶機(jī)和服務(wù)器之間傳遞。

2.5 為什么要四次揮手

斷開一個(gè) TCP 連接則需要“四次揮手”：

• 客戶端-發(fā)送一個(gè) FIN，用來(lái)關(guān)閉客戶端到服務(wù)器的數(shù)據(jù)傳送
• 服務(wù)器-收到這個(gè) FIN，它發(fā)回一 個(gè) ACK，確認(rèn)序號(hào)為收到的序號(hào)加1 。和 SYN 一樣，一個(gè) FIN 將占用一個(gè)序號(hào)
• 服務(wù)器-關(guān)閉與客戶端的連接，發(fā)送一個(gè)FIN給客戶端
• 客戶端-發(fā)回 ACK 報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1

任何一方都可以在數(shù)據(jù)傳送結(jié)束后發(fā)出連接釋放的通知，待對(duì)方確認(rèn)后進(jìn)入半關(guān)閉狀態(tài)。當(dāng)另一方也沒(méi)有數(shù)據(jù)再發(fā)送的時(shí)候，則發(fā)出連接釋放通知，對(duì)方確認(rèn)后就完全關(guān)閉了TCP連接。

舉個(gè)例子：A 和 B 打電話，通話即將結(jié)束后，A 說(shuō)“我沒(méi)啥要說(shuō)的了”，B回答“我知道了”，但是 B 可能還會(huì)有要說(shuō)的話，A 不能要求 B 跟著自己的節(jié)奏結(jié)束通話，于是 B 可能又巴拉巴拉說(shuō)了一通，最后 B 說(shuō)“我說(shuō)完了”，A 回答“知道了”，這樣通話才算結(jié)束。

上面講的比較概括，推薦一篇講的比較細(xì)致的文章：https://blog.csdn.net/qzcsu/article/details/72861891

三 TCP,UDP 協(xié)議的區(qū)別

可以參考：https://blog.csdn.net/JineD/article/details/113527707

UDP 在傳送數(shù)據(jù)之前不需要先建立連接，遠(yuǎn)地主機(jī)在收到 UDP 報(bào)文后，不需要給出任何確認(rèn)。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用于即時(shí)通信），比如： QQ 語(yǔ)音、 QQ 視頻 、直播等等

TCP 提供面向連接的服務(wù)。在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送結(jié)束后要釋放連接。 TCP 不提供廣播或多播服務(wù)。由于 TCP 要提供可靠的，面向連接的傳輸服務(wù)（TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會(huì)有三次握手來(lái)建立連接，而且在數(shù)據(jù)傳遞時(shí)，有確認(rèn)、窗口、重傳、擁塞控制機(jī)制，在數(shù)據(jù)傳完后，還會(huì)斷開連接用來(lái)節(jié)約系統(tǒng)資源），這一難以避免增加了許多開銷，如確認(rèn)，流量控制，計(jì)時(shí)器以及連接管理等。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多，還要占用許多處理機(jī)資源。TCP 一般用于文件傳輸、發(fā)送和接收郵件、遠(yuǎn)程登錄等場(chǎng)景。

四 ?TCP 協(xié)議如何保證可靠傳輸

1. 應(yīng)用數(shù)據(jù)被分割成 TCP 認(rèn)為最適合發(fā)送的數(shù)據(jù)塊。
2. TCP 給發(fā)送的每一個(gè)包進(jìn)行編號(hào)，接收方對(duì)數(shù)據(jù)包進(jìn)行排序，把有序數(shù)據(jù)傳送給應(yīng)用層。
3. 校驗(yàn)和： TCP 將保持它首部和數(shù)據(jù)的檢驗(yàn)和。這是一個(gè)端到端的檢驗(yàn)和，目的是檢測(cè)數(shù)據(jù)在傳輸過(guò)程中的任何變化。如果收到段的檢驗(yàn)和有差錯(cuò)，TCP 將丟棄這個(gè)報(bào)文段和不確認(rèn)收到此報(bào)文段。
4. TCP 的接收端會(huì)丟棄重復(fù)的數(shù)據(jù)。
5. 流量控制： TCP 連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)。當(dāng)接收方來(lái)不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率，防止包丟失。TCP 使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。 （TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制）
6. 擁塞控制： 當(dāng)網(wǎng)絡(luò)擁塞時(shí)，減少數(shù)據(jù)的發(fā)送。
7. ARQ協(xié)議： 也是為了實(shí)現(xiàn)可靠傳輸?shù)模幕驹砭褪敲堪l(fā)完一個(gè)分組就停止發(fā)送，等待對(duì)方確認(rèn)。在收到確認(rèn)后再發(fā)下一個(gè)分組。
8. 超時(shí)重傳： 當(dāng) TCP 發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段。

4.1 ARQ協(xié)議

自動(dòng)重傳請(qǐng)求（Automatic Repeat-reQuest，ARQ）是OSI模型中數(shù)據(jù)鏈路層和傳輸層的錯(cuò)誤糾正協(xié)議之一。它通過(guò)使用確認(rèn)和超時(shí)這兩個(gè)機(jī)制，在不可靠服務(wù)的基礎(chǔ)上實(shí)現(xiàn)可靠的信息傳輸。如果發(fā)送方在發(fā)送后一段時(shí)間之內(nèi)沒(méi)有收到確認(rèn)幀，它通常會(huì)重新發(fā)送。ARQ包括停止等待ARQ協(xié)議和連續(xù)ARQ協(xié)議。

停止等待ARQ協(xié)議

停止等待協(xié)議是為了實(shí)現(xiàn)可靠傳輸?shù)模幕驹砭褪敲堪l(fā)完一個(gè)分組就停止發(fā)送，等待對(duì)方確認(rèn)（回復(fù)ACK）。如果過(guò)了一段時(shí)間（超時(shí)時(shí)間后），還是沒(méi)有收到 ACK 確認(rèn)，說(shuō)明沒(méi)有發(fā)送成功，需要重新發(fā)送，直到收到確認(rèn)后再發(fā)下一個(gè)分組。

在停止等待協(xié)議中，若接收方收到重復(fù)分組，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)。

優(yōu)缺點(diǎn)：

• 優(yōu)點(diǎn)： 簡(jiǎn)單
• 缺點(diǎn)： 信道利用率低，等待時(shí)間長(zhǎng)

1) 無(wú)差錯(cuò)情況:

發(fā)送方發(fā)送分組,接收方在規(guī)定時(shí)間內(nèi)收到,并且回復(fù)確認(rèn).發(fā)送方再次發(fā)送。

2) 出現(xiàn)差錯(cuò)情況（超時(shí)重傳）:

停止等待協(xié)議中超時(shí)重傳是指只要超過(guò)一段時(shí)間仍然沒(méi)有收到確認(rèn)，就重傳前面發(fā)送過(guò)的分組（認(rèn)為剛才發(fā)送過(guò)的分組丟失了）。因此每發(fā)送完一個(gè)分組需要設(shè)置一個(gè)超時(shí)計(jì)時(shí)器，其重傳時(shí)間應(yīng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長(zhǎng)一些。這種自動(dòng)重傳方式常稱為 自動(dòng)重傳請(qǐng)求 ARQ 。另外在停止等待協(xié)議中若收到重復(fù)分組，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)。連續(xù) ARQ 協(xié)議 可提高信道利用率。發(fā)送維持一個(gè)發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可連續(xù)發(fā)送出去，而不需要等待對(duì)方確認(rèn)。接收方一般采用累積確認(rèn)，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，表明到這個(gè)分組位置的所有分組都已經(jīng)正確收到了。

3) 確認(rèn)丟失和確認(rèn)遲到

• 確認(rèn)丟失 ：確認(rèn)消息在傳輸過(guò)程丟失。當(dāng)A發(fā)送M1消息，B收到后，B向A發(fā)送了一個(gè)M1確認(rèn)消息，但卻在傳輸過(guò)程中丟失。而A并不知道，在超時(shí)計(jì)時(shí)過(guò)后，A重傳M1消息，B再次收到該消息后采取以下兩點(diǎn)措施：1. 丟棄這個(gè)重復(fù)的M1消息，不向上層交付。 2. 向A發(fā)送確認(rèn)消息。（不會(huì)認(rèn)為已經(jīng)發(fā)送過(guò)了，就不再發(fā)送。A能重傳，就證明B的確認(rèn)消息丟失）。
• 確認(rèn)遲到 ：確認(rèn)消息在傳輸過(guò)程中遲到。A發(fā)送M1消息，B收到并發(fā)送確認(rèn)。在超時(shí)時(shí)間內(nèi)沒(méi)有收到確認(rèn)消息，A重傳M1消息，B仍然收到并繼續(xù)發(fā)送確認(rèn)消息（B收到了2份M1）。此時(shí)A收到了B第二次發(fā)送的確認(rèn)消息。接著發(fā)送其他數(shù)據(jù)。過(guò)了一會(huì)，A收到了B第一次發(fā)送的對(duì)M1的確認(rèn)消息（A也收到了2份確認(rèn)消息）。處理如下：1. A收到重復(fù)的確認(rèn)后，直接丟棄。2. B收到重復(fù)的M1后，也直接丟棄重復(fù)的M1。

連續(xù)ARQ協(xié)議

連續(xù) ARQ 協(xié)議可提高信道利用率。發(fā)送方維持一個(gè)發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對(duì)方確認(rèn)。接收方一般采用累計(jì)確認(rèn)，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，表明到這個(gè)分組為止的所有分組都已經(jīng)正確收到了。

優(yōu)缺點(diǎn)：

• 優(yōu)點(diǎn)： 信道利用率高，容易實(shí)現(xiàn)，即使確認(rèn)丟失，也不必重傳。
• 缺點(diǎn)： 不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。 比如：發(fā)送方發(fā)送了 5條 消息，中間第三條丟失（3號(hào)），這時(shí)接收方只能對(duì)前兩個(gè)發(fā)送確認(rèn)。發(fā)送方無(wú)法知道后三個(gè)分組的下落，而只好把后三個(gè)全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來(lái)重傳已經(jīng)發(fā)送過(guò)的 N 個(gè)消息。

4.2? 滑動(dòng)窗口和流量控制

TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來(lái)得及接收。 接收方發(fā)送的確認(rèn)報(bào)文中的窗口字段可以用來(lái)控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

4.3 擁塞控制

在某段時(shí)間，若對(duì)網(wǎng)絡(luò)中某一資源的需求超過(guò)了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞。這種情況就叫擁塞。擁塞控制就是為了防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣就可以使網(wǎng)絡(luò)中的路由器或鏈路不致過(guò)載。擁塞控制所要做的都有一個(gè)前提，就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷。擁塞控制是一個(gè)全局性的過(guò)程，涉及到所有的主機(jī)，所有的路由器，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。相反，流量控制往往是點(diǎn)對(duì)點(diǎn)通信量的控制，是個(gè)端到端的問(wèn)題。流量控制所要做到的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來(lái)得及接收。

為了進(jìn)行擁塞控制，TCP 發(fā)送方要維持一個(gè) 擁塞窗口(cwnd) 的狀態(tài)變量。擁塞控制窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)變化。發(fā)送方讓自己的發(fā)送窗口取為擁塞窗口和接收方的接受窗口中較小的一個(gè)。

TCP的擁塞控制采用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復(fù)。在網(wǎng)絡(luò)層也可以使路由器采用適當(dāng)?shù)姆纸M丟棄策略（如主動(dòng)隊(duì)列管理 AQM），以減少網(wǎng)絡(luò)擁塞的發(fā)生。

• 慢開始： 慢開始算法的思路是當(dāng)主機(jī)開始發(fā)送數(shù)據(jù)時(shí)，如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡(luò)，那么可能會(huì)引起網(wǎng)絡(luò)阻塞，因?yàn)楝F(xiàn)在還不知道網(wǎng)絡(luò)的符合情況。經(jīng)驗(yàn)表明，較好的方法是先探測(cè)一下，即由小到大逐漸增大發(fā)送窗口，也就是由小到大逐漸增大擁塞窗口數(shù)值。cwnd初始值為1，每經(jīng)過(guò)一個(gè)傳播輪次，cwnd加倍。
• 擁塞避免： 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間RTT就把發(fā)送放的cwnd加1.
• 快重傳與快恢復(fù)：
  在 TCP/IP 中，快速重傳和恢復(fù)（fast retransmit and recovery，F(xiàn)RR）是一種擁塞控制算法，它能快速恢復(fù)丟失的數(shù)據(jù)包。沒(méi)有 FRR，如果數(shù)據(jù)包丟失了，TCP 將會(huì)使用定時(shí)器來(lái)要求傳輸暫停。在暫停的這段時(shí)間內(nèi)，沒(méi)有新的或復(fù)制的數(shù)據(jù)包被發(fā)送。有了 FRR，如果接收機(jī)接收到一個(gè)不按順序的數(shù)據(jù)段，它會(huì)立即給發(fā)送機(jī)發(fā)送一個(gè)重復(fù)確認(rèn)。如果發(fā)送機(jī)接收到三個(gè)重復(fù)確認(rèn)，它會(huì)假定確認(rèn)件指出的數(shù)據(jù)段丟失了，并立即重傳這些丟失的數(shù)據(jù)段。有了 FRR，就不會(huì)因?yàn)橹貍鲿r(shí)要求的暫停被耽誤。 　當(dāng)有單獨(dú)的數(shù)據(jù)包丟失時(shí)，快速重傳和恢復(fù)（FRR）能最有效地工作。當(dāng)有多個(gè)數(shù)據(jù)信息包在某一段很短的時(shí)間內(nèi)丟失時(shí)，它則不能很有效地工作。

五 在瀏覽器中輸入url地址 ->> 顯示主頁(yè)的過(guò)程(面試?？?

百度好像最喜歡問(wèn)這個(gè)問(wèn)題。

打開一個(gè)網(wǎng)頁(yè)，整個(gè)過(guò)程會(huì)使用哪些協(xié)議？

上圖有一個(gè)錯(cuò)誤，請(qǐng)注意，是OSPF不是OPSF。 OSPF（Open Shortest Path First，ospf）開放最短路徑優(yōu)先協(xié)議,是由Internet工程任務(wù)組開發(fā)的路由選擇協(xié)議

總體來(lái)說(shuō)分為以下幾個(gè)過(guò)程:

1. DNS解析
2. TCP連接
3. 發(fā)送HTTP請(qǐng)求
4. 服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文
5. 瀏覽器解析渲染頁(yè)面
6. 連接結(jié)束

具體可以參考下面這篇文章：

• https://segmentfault.com/a/1190000006879700

六 狀態(tài)碼

301 和 302 ?

七 各種協(xié)議與HTTP協(xié)議之間的關(guān)系

一般面試官會(huì)通過(guò)這樣的問(wèn)題來(lái)考察你對(duì)計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)體系的理解。

圖片來(lái)源：《圖解HTTP》

八 HTTP長(zhǎng)連接,短連接

在HTTP/1.0中默認(rèn)使用短連接。也就是說(shuō)，客戶端和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問(wèn)的某個(gè)HTML或其他類型的Web頁(yè)中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個(gè)Web資源，瀏覽器就會(huì)重新建立一個(gè)HTTP會(huì)話。

而從HTTP/1.1起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性。使用長(zhǎng)連接的HTTP協(xié)議，會(huì)在響應(yīng)頭加入這行代碼：

Connection:keep-alive

在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，客戶端再次訪問(wèn)這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接需要客戶端和服務(wù)端都支持長(zhǎng)連接。

HTTP協(xié)議的長(zhǎng)連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長(zhǎng)連接和短連接。

—— 《HTTP長(zhǎng)連接、短連接究竟是什么？》

九 HTTP是不保存狀態(tài)的協(xié)議,如何保存用戶狀態(tài)?

HTTP 是一種不保存狀態(tài)，即無(wú)狀態(tài)（stateless）協(xié)議。也就是說(shuō) HTTP 協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。那么我們保存用戶狀態(tài)呢？Session 機(jī)制的存在就是為了解決這個(gè)問(wèn)題，Session 的主要作用就是通過(guò)服務(wù)端記錄用戶的狀態(tài)。典型的場(chǎng)景是購(gòu)物車，當(dāng)你要添加商品到購(gòu)物車的時(shí)候，系統(tǒng)不知道是哪個(gè)用戶操作的，因?yàn)?HTTP 協(xié)議是無(wú)狀態(tài)的。服務(wù)端給特定的用戶創(chuàng)建特定的 Session 之后就可以標(biāo)識(shí)這個(gè)用戶并且跟蹤這個(gè)用戶了（一般情況下，服務(wù)器會(huì)在一定時(shí)間內(nèi)保存這個(gè) Session，過(guò)了時(shí)間限制，就會(huì)銷毀這個(gè)Session）。

在服務(wù)端保存 Session 的方法很多，最常用的就是內(nèi)存和數(shù)據(jù)庫(kù)(比如是使用內(nèi)存數(shù)據(jù)庫(kù)redis保存)。既然 Session 存放在服務(wù)器端，那么我們?nèi)绾螌?shí)現(xiàn) Session 跟蹤呢？大部分情況下，我們都是通過(guò)在 Cookie 中附加一個(gè) Session ID 來(lái)方式來(lái)跟蹤。

Cookie 被禁用怎么辦?

最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的后面。

十 Cookie的作用是什么?和Session有什么區(qū)別？

Cookie 和 Session都是用來(lái)跟蹤瀏覽器用戶身份的會(huì)話方式，但是兩者的應(yīng)用場(chǎng)景不太一樣。

Cookie 一般用來(lái)保存用戶信息 比如①我們?cè)?Cookie 中保存已經(jīng)登錄過(guò)得用戶信息，下次訪問(wèn)網(wǎng)站的時(shí)候頁(yè)面可以自動(dòng)幫你登錄的一些基本信息給填了；②一般的網(wǎng)站都會(huì)有保持登錄也就是說(shuō)下次你再訪問(wèn)網(wǎng)站的時(shí)候就不需要重新登錄了，這是因?yàn)橛脩舻卿浀臅r(shí)候我們可以存放了一個(gè) Token 在 Cookie 中，下次登錄的時(shí)候只需要根據(jù) Token 值來(lái)查找用戶即可(為了安全考慮，重新登錄一般要將 Token 重寫)；③登錄一次網(wǎng)站后訪問(wèn)網(wǎng)站其他頁(yè)面不需要重新登錄。Session 的主要作用就是通過(guò)服務(wù)端記錄用戶的狀態(tài)。 典型的場(chǎng)景是購(gòu)物車，當(dāng)你要添加商品到購(gòu)物車的時(shí)候，系統(tǒng)不知道是哪個(gè)用戶操作的，因?yàn)?HTTP 協(xié)議是無(wú)狀態(tài)的。服務(wù)端給特定的用戶創(chuàng)建特定的 Session 之后就可以標(biāo)識(shí)這個(gè)用戶并且跟蹤這個(gè)用戶了。

Cookie 數(shù)據(jù)保存在客戶端(瀏覽器端)，Session 數(shù)據(jù)保存在服務(wù)器端。

Cookie 存儲(chǔ)在客戶端中，而Session存儲(chǔ)在服務(wù)器上，相對(duì)來(lái)說(shuō) Session 安全性更高。如果要在 Cookie 中存儲(chǔ)一些敏感信息，不要直接寫入 Cookie 中，最好能將 Cookie 信息加密然后使用到的時(shí)候再去服務(wù)器端解密。

十一 HTTP 1.0和HTTP 1.1的主要區(qū)別是什么?

HTTP1.0最早在網(wǎng)頁(yè)中使用是在1996年，那個(gè)時(shí)候只是使用一些較為簡(jiǎn)單的網(wǎng)頁(yè)上和網(wǎng)絡(luò)請(qǐng)求上，而HTTP1.1則在1999年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請(qǐng)求中，同時(shí)HTTP1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議。 主要區(qū)別主要體現(xiàn)在：

1. 長(zhǎng)連接 : 在HTTP/1.0中，默認(rèn)使用的是短連接，也就是說(shuō)每次請(qǐng)求都要重新建立一次連接。HTTP 是基于TCP/IP協(xié)議的,每一次建立或者斷開連接都需要三次握手四次揮手的開銷，如果每次請(qǐng)求都要這樣的話，開銷會(huì)比較大。因此最好能維持一個(gè)長(zhǎng)連接，可以用個(gè)長(zhǎng)連接來(lái)發(fā)多個(gè)請(qǐng)求。HTTP 1.1起，默認(rèn)使用長(zhǎng)連接 ,默認(rèn)開啟Connection： keep-alive。 HTTP/1.1的持續(xù)連接有非流水線方式和流水線方式 。流水線方式是客戶在收到HTTP的響應(yīng)報(bào)文之前就能接著發(fā)送新的請(qǐng)求報(bào)文。與之相對(duì)應(yīng)的非流水線方式是客戶在收到前一個(gè)響應(yīng)后才能發(fā)送下一個(gè)請(qǐng)求。
2. 錯(cuò)誤狀態(tài)響應(yīng)碼 :在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。
3. 緩存處理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires來(lái)做為緩存判斷的標(biāo)準(zhǔn)，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來(lái)控制緩存策略。
4. 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用 :HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能，HTTP1.1則在請(qǐng)求頭引入了range頭域，它允許只請(qǐng)求資源的某個(gè)部分，即返回碼是206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。

十二 URI和URL的區(qū)別是什么?

• URI(Uniform Resource Identifier) 是統(tǒng)一資源標(biāo)志符，可以唯一標(biāo)識(shí)一個(gè)資源。
• URL(Uniform Resource Location) 是統(tǒng)一資源定位符，可以提供該資源的路徑。它是一種具體的 URI，即 URL 可以用來(lái)標(biāo)識(shí)一個(gè)資源，而且還指明了如何 locate 這個(gè)資源。

URI的作用像身份證號(hào)一樣，URL的作用更像家庭住址一樣。URL是一種具體的URI，它不僅唯一標(biāo)識(shí)資源，而且還提供了定位該資源的信息。

十三 HTTP 和 HTTPS 的區(qū)別？

1. 端口 ：HTTP的URL由“http://”起始且默認(rèn)使用端口80，而HTTPS的URL由“https://”起始且默認(rèn)使用端口443。
2. 安全性和資源消耗： HTTP協(xié)議運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無(wú)法驗(yàn)證對(duì)方的身份。HTTPS是運(yùn)行在SSL/TLS之上的HTTP協(xié)議，SSL/TLS 運(yùn)行在TCP之上。所有傳輸?shù)膬?nèi)容都經(jīng)過(guò)加密，加密采用對(duì)稱加密，但對(duì)稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對(duì)稱加密。所以說(shuō)，HTTP 安全性沒(méi)有 HTTPS高，但是 HTTPS 比HTTP耗費(fèi)更多服務(wù)器資源。
   • 對(duì)稱加密：密鑰只有一個(gè)，加密解密為同一個(gè)密碼，且加解密速度快，典型的對(duì)稱加密算法有DES、AES等；
   • 非對(duì)稱加密：密鑰成對(duì)出現(xiàn)（且根據(jù)公鑰無(wú)法推知私鑰，根據(jù)私鑰也無(wú)法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對(duì)對(duì)稱加密速度較慢，典型的非對(duì)稱加密算法有RSA、DSA等。

建議

非常推薦大家看一下 《圖解HTTP》 這本書，這本書頁(yè)數(shù)不多，但是內(nèi)容很是充實(shí)，不管是用來(lái)系統(tǒng)的掌握網(wǎng)絡(luò)方面的一些知識(shí)還是說(shuō)純粹為了應(yīng)付面試都有很大幫助。下面的一些文章只是參考。大二學(xué)習(xí)這門課程的時(shí)候，我們使用的教材是 《計(jì)算機(jī)網(wǎng)絡(luò)第七版》（謝希仁編著），不推薦大家看這本教材，書非常厚而且知識(shí)偏理論，不確定大家能不能心平氣和的讀完。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-694516.html

到了這里，關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)——OSI與TCP/IP各層的結(jié)構(gòu)與功能,都有哪些協(xié)議?的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！