計算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)

OSI七層模型 TCP/IP四層模型 五層模型

image

七層模型：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應(yīng)用層

TCP/IP四層模型：網(wǎng)絡(luò)接口層、網(wǎng)絡(luò)層、傳輸層、應(yīng)用層

image

各層協(xié)議

網(wǎng)絡(luò)層：IP、ARP、RARP（后兩個在OSI中認(rèn)為在數(shù)據(jù)鏈路層，在TCP/IP協(xié)議中被認(rèn)為在網(wǎng)絡(luò)層）

傳輸層：TCP、UDP

應(yīng)用層：HTTP、DNS、FTP、SMTP、POP3、TELNET

基于TCP的應(yīng)用層協(xié)議有：HTTP、HTTPS、FTP（文件傳輸協(xié)議）、SMTP（發(fā)送電子郵件）、POP3（接收電子郵件)、TELNET（遠(yuǎn)程登陸協(xié)議）

基于UDP的應(yīng)用層協(xié)議有：TFTP（簡單文件傳輸協(xié)議）、SNMP（簡單網(wǎng)絡(luò)管理協(xié)議）、NTP（網(wǎng)絡(luò)時間協(xié)議）

基于TCP和UDP的應(yīng)用層協(xié)議有：DNS

簡單了解

FTP

FTP協(xié)議的客戶機(jī)與服務(wù)器之間需要建立兩個連接， 一個用于控制數(shù)據(jù)傳輸（端口21）， 一個用于數(shù)據(jù)傳輸（端口20）。數(shù)據(jù)連接主要用于數(shù)據(jù)傳輸，完成文件內(nèi)容的傳輸?？刂七B接主要用于傳輸FTP控制命令和服務(wù)器的回送消息

TFTP

在UDP之上上建立一個類似于FTP的但僅支持文件上傳和下載功能的傳輸協(xié)議，所以它不包含F(xiàn)TP協(xié)議中的目錄操作和用戶權(quán)限等內(nèi)容

SNMP

SNMP用于網(wǎng)絡(luò)設(shè)備的管理。SNMP的工作方式：管理員需要向設(shè)備獲取數(shù)據(jù)，所以SNMP提供了“讀”操作；管理員需要向設(shè)備執(zhí)行設(shè)置操作，所以SNMP提供了“寫”操作；設(shè)備需要在重要狀況改變的時候，向管理員通報事件的發(fā)生，所以SNMP提供了“Trap”操作

Get:讀取網(wǎng)絡(luò)設(shè)備的狀態(tài)信息 Set：遠(yuǎn)程配置設(shè)備參數(shù) Trap:管理站及時獲取設(shè)備的重要信息

NTP

用于網(wǎng)絡(luò)時間同步的協(xié)議，使網(wǎng)絡(luò)中的計算機(jī)時鐘同步到UTC，再配合各個時區(qū)的偏移調(diào)整就能實現(xiàn)精準(zhǔn)同步對時功能

五層模型

• 物理層：解決如何在連接各種計算機(jī)的傳輸媒體上傳輸數(shù)據(jù)比特流，而不是指具體的傳輸媒體。

• 數(shù)據(jù)鏈路層（數(shù)據(jù)幀：Frame）：

  • 在物理層提供的服務(wù)基礎(chǔ)上，數(shù)據(jù)鏈路層在通信的實體間建立數(shù)據(jù)鏈路連接

  • 不同的網(wǎng)絡(luò)類型，發(fā)送數(shù)據(jù)的機(jī)制不同，數(shù)據(jù)鏈路層就是將數(shù)據(jù)包封裝成能夠在不同網(wǎng)絡(luò)傳輸?shù)膸?/p>

  • 采用差錯控制與流量控制方法，使有差錯的物理線路變成無差錯的數(shù)據(jù)鏈路（只進(jìn)行差錯檢驗，但不糾錯，如果檢測到錯誤就丟棄該幀）

• 網(wǎng)絡(luò)層（數(shù)據(jù)包：Packet）：把傳輸層傳遞下的數(shù)據(jù)報封裝成分組（負(fù)責(zé)選擇最佳路線、規(guī)劃IP地址）

  • 通過路由選擇算法為分組通過通信子網(wǎng)選擇最合適的路徑

    • 路由器查看數(shù)據(jù)包目標(biāo)IP地址，根據(jù)路由表為數(shù)據(jù)包選擇路徑。路由表中的類目可以人工添加（靜態(tài)路由）也可以動態(tài)生成（動態(tài)路由）

• 傳輸層（數(shù)據(jù)段：Segment）：建立、管理和維護(hù)端到端的連接

  • 向用戶提供端到端服務(wù)，透明地傳送報文

  • 提供進(jìn)程間的通用數(shù)據(jù)傳輸服務(wù)，傳輸層向高層屏蔽下層數(shù)據(jù)通信的細(xì)節(jié)

• 應(yīng)用層（報文：Message）：提供用戶接口，特指能夠發(fā)送網(wǎng)絡(luò)流量的程序（為應(yīng)用程序提供服務(wù)）

OSI中其他兩層的作用：

• 表示層：處理兩個通信系統(tǒng)間信息交換的表示方式，包括數(shù)據(jù)格式變換、數(shù)據(jù)加密與解密、數(shù)據(jù)壓縮與恢復(fù)等功能

• 會話層：建立會話，通信的應(yīng)用程序之間建立、維護(hù)和釋放面向用戶的連接（通信的應(yīng)用程序之間建立會話，需要傳輸層建立1個或多個連接，netstat -n 查看）

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

三個基本問題

• 封裝成幀

每個鏈路層協(xié)議都規(guī)定了幀數(shù)據(jù)部分的長度限制——最大傳輸單元 MTU（Maximum Transfer Unit）

幀首部和幀尾部包含許多必要的控制信息（比如幀號，不是只包含控制字符）

控制字符SOH放在第一幀的最前面（Start Of Header，首部），控制字符EOT放在最后一幀的最后面（End Of Transmission，尾部）

• 透明傳輸

發(fā)送端的數(shù)據(jù)鏈路層在數(shù)據(jù)中出現(xiàn)控制字符“SOH”和“EOT”的前面插入一個轉(zhuǎn)移字符“ESC”

• 差錯檢測

循環(huán)冗余編碼（CRC）

向網(wǎng)絡(luò)層提供的服務(wù)

• 無確認(rèn)的無連接服務(wù)

• 有確認(rèn)的無連接服務(wù)

• 有確認(rèn)的面向連接服務(wù)（需要在幀傳輸之前建立數(shù)據(jù)鏈路，也需要在幀傳輸結(jié)束后釋放數(shù)據(jù)鏈路）

MAC尋址

MAC地址被燒入每個以太網(wǎng)網(wǎng)卡中（MAC地址全球唯一）

ARP協(xié)議，IP地址 ? MAC地址

RARP協(xié)議，MAC地址 ? IP地址

為什么有MAC地址，還需要IP地址？

• 雖然設(shè)備的MAC地址唯一，但是設(shè)備不是固定在一個地方的，它很有可能是要移動的，所以無法知道它具體的位置。

• 并且如果直接用MAC地址進(jìn)行尋址，如果網(wǎng)絡(luò)規(guī)模比較大的話，交換機(jī)需要保存所有的MAC地址，很不現(xiàn)實

MAC地址類似于身份證號，IP地址（有定位功能）類似于你家在哪，或者你當(dāng)前住在哪里。當(dāng)需要找你的時候，首先通過IP尋址，縮小范圍，然后通過MAC地址準(zhǔn)確定位到你

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

IP協(xié)議作用

• 尋址和路由選擇

• 分段與重組（不同類型網(wǎng)絡(luò)所規(guī)定的最大傳輸單元MTU不同）

• IP地址和MAC地址的轉(zhuǎn)換，將不同格式的物理地址（即，MAC地址）轉(zhuǎn)換為統(tǒng)一的IP地址

傳輸層

TCP和UDP的區(qū)別、特點(diǎn)

TCP的主要特點(diǎn)

• 面向連接（也就是說，利用TCP通信的兩臺主機(jī)首先要經(jīng)歷一個建立連接的過程，等到連接建立后才開始傳輸數(shù)據(jù)）

• 具有可靠性（校驗和、重傳控制、序號標(biāo)識、滑動窗口、確認(rèn)應(yīng)答實現(xiàn)可靠傳輸。如丟包時的重發(fā)控制，還可以對次序亂掉的分包進(jìn)行順序控制）

• 全雙工通信通信方式

• 流量控制（“滑動窗口”的方式）

• 擁塞控制

• 每一條TCP連接只能是點(diǎn)對點(diǎn)的（一對一）

• 面向字節(jié)流

UDP的主要特點(diǎn)

• 無連接（所謂全雙工，半雙工，單工是指面向連接時才有的說法，所以UDP沒有此說法）

• 無擁塞控制（會以盡可能快的速度傳輸）

• 支持一對一、一對多、多對一和多對多的交互通信

• 面向報文

• 首部開銷小，8個字節(jié)（只有四個字段：源端口、目的端口、長度、檢驗和）（TCP首部20個字節(jié)）

采用TCP，一旦發(fā)生丟包，TCP會將后續(xù)的包緩存起來，等前面的包重傳并接收到后再繼續(xù)發(fā)送，延時會越來越大

UDP對實時性要求較為嚴(yán)格的情況下，采用自定義重傳機(jī)制，能夠把丟包產(chǎn)生的延遲降到最低，盡量減少網(wǎng)絡(luò)問題對游戲性造成影響，使用場景：語音通話、直播

區(qū)別總結(jié)

• TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接

• TCP提供可靠的服務(wù)。通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復(fù)，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付

• UDP具有較好的實時性，工作效率比TCP高，適用于對高速傳輸和實時性有較高的通信或廣播通信。

• 每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對一，一對多，多對一和多對多的交互通信

• TCP對系統(tǒng)資源要求較多，UDP對系統(tǒng)資源要求較少。

TCP協(xié)議采用哪些機(jī)制保證數(shù)據(jù)的可靠傳輸

• 數(shù)據(jù)分割，對數(shù)據(jù)段進(jìn)行編號

• 校驗和

• 接時的三次握手和斷開時的四次揮手

• 超時重傳

• 擁塞控制

• 流量控制

如何實現(xiàn)流量控制

流量控制：點(diǎn)對點(diǎn)通信量的控制。TCP支持根據(jù)接收端的處理能力，來決定發(fā)送端的發(fā)送速度

在TCP報文段首部中有一個16位窗口長度，當(dāng)接收端接收到發(fā)送方的數(shù)據(jù)后，在應(yīng)答報文ACK中就將自身緩沖區(qū)的剩余大小，放入16窗口大小中。這個大小隨數(shù)據(jù)傳輸情況而變，窗口越大，網(wǎng)絡(luò)吞吐量越高，而一旦接收方發(fā)現(xiàn)自身的緩沖區(qū)快滿了，就將窗口設(shè)置為更小的值通知發(fā)送方。如果緩沖區(qū)滿，就將窗口置為0，發(fā)送方收到后就不再發(fā)送數(shù)據(jù)，但是需要定期發(fā)送一個窗口探測數(shù)據(jù)段，使接收端把窗口大小告訴發(fā)送端。

注：16位的窗口大小最大能表示65535個字節(jié)（64K），但是TCP的窗口大小最大并不是64K。在TCP首部中40個字節(jié)的選項中還包含了一個窗口擴(kuò)大因子M，實際的窗口大小就是16為窗口字段的值左移M位。每移一位，擴(kuò)大兩倍

如何實現(xiàn)擁塞控制

擁塞：如果網(wǎng)絡(luò)非常擁堵，此時再發(fā)送數(shù)據(jù)就會加重網(wǎng)絡(luò)負(fù)擔(dān)，那么發(fā)送的數(shù)據(jù)段很可能超過了最大生存時間也沒有到達(dá)接收方，就會產(chǎn)生大量丟包問題，從而進(jìn)行大量的超時重傳，嚴(yán)重影響傳輸

擁塞控制：TCP在傳輸時盡可能快的將數(shù)據(jù)傳輸，并且避免擁塞造成的一系列問題。是可靠性的保證，同時也是維護(hù)了傳輸?shù)母咝?/p>

擁塞控制目的：為了防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，避免網(wǎng)絡(luò)中的路由器、鏈路過載

擁塞控制過程：TCP發(fā)送將維護(hù)一個擁塞窗口的狀態(tài)變量，該變量隨著網(wǎng)絡(luò)擁塞程度動態(tài)變化，通過滿開始、擁塞避免等算法減小網(wǎng)絡(luò)擁塞的發(fā)生

• 慢開始（指數(shù)增長）

• 擁塞避免（線性增長）

• 快重傳

• 快恢復(fù)

TCP的幾個狀態(tài)

• SYN表示建立連接，

• FIN表示關(guān)閉連接，

• ACK表示響應(yīng)，

• PSH表示有數(shù)據(jù)傳輸，

• RST表示連接重置

三次握手

過程

• 第一次握手：Client將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client 進(jìn)入syn_sent狀態(tài)，等待Server確認(rèn)

• 第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請求建立連接，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1,隨機(jī)產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請求，Server進(jìn)入syn_rcvd狀態(tài)

• 第三次握手：Client收到確認(rèn)后，檢查ack=J+1,ACK是否為1，如果正確則將標(biāo)志位ACK為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進(jìn)入established狀態(tài)，完成三次握手，隨后Client和Server之間可以開始傳輸數(shù)據(jù)了

為什么是三次

• 為了實現(xiàn)可靠數(shù)據(jù)傳輸， TCP 協(xié)議的通信雙方， 都必須維護(hù)一個序列號， 以標(biāo)識發(fā)送出去的數(shù)據(jù)包中， 哪些是已經(jīng)被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 并確認(rèn)對方已經(jīng)收到了序列號起始值的必經(jīng)步驟

• 如果只是兩次握手， 至多只有連接發(fā)起方的起始序列號能被確認(rèn)， 另一方選擇的序列號則得不到確認(rèn)

兩次握手只能保證單向連接是暢通的

只有經(jīng)過第三次握手，才能確保雙向都可以接收到對方的發(fā)送的數(shù)據(jù)

• 第一次握手：服務(wù)端知道自己接受、對方發(fā)送沒問題

• 第二次握手：客戶端知道自己接受、發(fā)送、對方接受和發(fā)送沒問題

• 第三次握手：服務(wù)端知道自己發(fā)送沒問題，對方接受沒問題

四次揮手

過程

• Client發(fā)送一個FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入fin_wait_1狀態(tài)

• Server收到FIN后，發(fā)送一個ACK給Client，確認(rèn)序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進(jìn)入Close_wait狀態(tài)。此時TCP連接處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有要發(fā)送的數(shù)據(jù)了，但服務(wù)端若發(fā)送數(shù)據(jù)，則客戶端仍要接收

• Server發(fā)送一個FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入Last_ack狀態(tài)

• Client收到FIN后，Client進(jìn)入Time_wait狀態(tài)，接著發(fā)送一個ACK給Server，確認(rèn)序號為收到序號+1，Server進(jìn)入Closed狀態(tài)，完成四次揮手

為什么是四次

保證服務(wù)端數(shù)據(jù)發(fā)送完

由于TCP連接是全雙工的，因此，每個方向都必須要單獨(dú)進(jìn)行關(guān)閉，這一原則是當(dāng)一方完成數(shù)據(jù)發(fā)送任務(wù)后，發(fā)送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有數(shù)據(jù)流動了，即不會再收到數(shù)據(jù)了，但是在這個TCP連接上仍然能夠發(fā)送數(shù)據(jù)，直到這一方向也發(fā)送了FIN。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動關(guān)閉，而另一方則執(zhí)行被動關(guān)閉

TIME-WAIT的作用

MSL 是 MaximumSegmentLifetime 英文的縮寫，中文可以譯為“報文最大生存時間”

• 為了保證客戶端發(fā)送的最后一個ack報文段能夠到達(dá)服務(wù)器

  • 因為這最后一個ack確認(rèn)包可能會丟失，然后服務(wù)器就會超時重傳第三次揮手的fin信息報，然后客戶端再重傳一次第四次揮手的ack報文

• 在第四次揮手后，經(jīng)過2msl的時間足以讓本次連接產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失，這樣下一次新的連接中就肯定不會出現(xiàn)舊連接的報文段了

應(yīng)用層

瀏覽器輸入URL后，按下回車會發(fā)生什么

• 瀏覽器查找域名的IP地址（DNS協(xié)議）

  • 瀏覽器會從主機(jī)的Hosts文件中查看是否有該域名和IP地址的映射；

  • 如果Hosts文件沒有，瀏覽器會查看自己的緩存；

  • 當(dāng)上面兩個方法都行不通時，只能去請求DNS服務(wù)器來獲取IP地址；

• 瀏覽器與目標(biāo)服務(wù)器建立TCP連接

  • 獲取到IP地址后，建立TCP連接、三次握手；（TCP協(xié)議）

  • 確認(rèn)連接后發(fā)送一個HTTP請求報文；（HTTP協(xié)議）

  • 服務(wù)器處理請求，并對請求做出響應(yīng)；

  • 瀏覽器收到服務(wù)器響應(yīng)，得到html代碼；

• html頁面的解析與渲染

HTTP和HTTPS的區(qū)別

• https協(xié)議需要到CA（Certificate Authority，證書頒發(fā)機(jī)構(gòu)）申請證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用

• http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的 SSL/TLS（TLS是基于SSL的）加密傳輸協(xié)議（https的加密機(jī)制是一種共享密鑰加密和公開加密并用的混合加密機(jī)制）

• http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443

• http的連接很簡單，是無狀態(tài)的。Https協(xié)議是由SSL/TLS+Http協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。(無狀態(tài)的意思是其數(shù)據(jù)包的發(fā)送、傳輸和接收都是相互獨(dú)立的。無連接的意思是指通信雙方都不長久的維持對方的任何信息。)

HTTP明文傳輸帶來的風(fēng)險：

• 竊聽風(fēng)險：第三方可以獲取通信內(nèi)容

• 篡改風(fēng)險：第三方可以修改通信內(nèi)容

• 冒充風(fēng)險：第三方可以冒充他人身份參與通信

HTTPS加密過程

• 客戶端給服務(wù)器發(fā)送一個請求，包括協(xié)議版本號、隨機(jī)數(shù)，以及客戶端支持的加密算法

• 服務(wù)器確認(rèn)雙方使用的加密方法，并給出一個服務(wù)器產(chǎn)生的隨機(jī)數(shù)和CA證書給客戶端，內(nèi)容包括：證書的發(fā)布機(jī)構(gòu)、有效期、所有者、簽名以及公鑰等

• 客戶端對發(fā)來的公鑰進(jìn)行真?zhèn)涡ｒ?，如果有效，生成一個新的隨機(jī)數(shù)，并使用CA證書中的公鑰，加密這個隨機(jī)數(shù)，發(fā)送給服務(wù)器

• 服務(wù)器使用自己的私鑰，獲取客戶端發(fā)送的隨機(jī)數(shù)

• 客戶端和服務(wù)器根據(jù)約定的加密方法，使用前面的三個隨機(jī)數(shù)，生成“對話密鑰”，用來加密接下來的整個對話過程

細(xì)節(jié)過程：

image

整體過程：

[圖片上傳失敗...(image-61368b-1601180318144)]

為什么客戶端和服務(wù)端都需要發(fā)送一個Finish報文

Finish報文是對至今全部報文的整體校驗值（也就是HASH值）。當(dāng)客戶端把這個值通過得到的公鑰進(jìn)行加密的時候，服務(wù)器得到之后對其進(jìn)行解密，然后再對全部報文進(jìn)行一個HASH求值。如果這個值跟解密得到的值相等的話，那么說明客戶端時可信賴的

同樣的，服務(wù)器發(fā)送這也的一個整體校驗值，用來客戶端驗證服務(wù)器是否是真正要進(jìn)行通信的那一個

綜上：Finish報文用來校驗雙方的身份

為什么使用三個隨機(jī)數(shù)

• 向前安全性。加入隨機(jī)參數(shù)，使得：即使現(xiàn)在所有密鑰都泄露了，歷史消息也不會被破解

• 增加隨機(jī)性

  • 不管是客戶端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會每次都一樣。

  • SSL 的協(xié)議默認(rèn)不信任每個主機(jī)都能產(chǎn)生完全隨機(jī)的數(shù)，如果只使用一個偽隨機(jī)的數(shù)來生成秘鑰，就很容易被破解。

  • 通過使用三個隨機(jī)數(shù)的方式，增加了自由度，一個偽隨機(jī)可能被破解，但是三個偽隨機(jī)就很接近于隨機(jī)了，因此可以使用這種方法來保持生成秘鑰的隨機(jī)性和安全性

數(shù)據(jù)傳輸需要用對稱加密的原因

非對稱加密的加解密效率是非常低的

對稱加密算法

• DES

• AES

非對稱加密算法

• RSA

• DSA

HTTP請求有哪些

GET和POST的區(qū)別

• GET請求時冪等的（冪等的意味著對同一個URL的多個請求應(yīng)用返回同樣的結(jié)果）

• GET在瀏覽器回退時是無害的，而POST會再次提交請求

• GET請求會被瀏覽器主動cache，而POST不會，除非手動設(shè)置

• GET請求只能進(jìn)行url編碼，而POST支持多種編碼方式

PUT和POST的區(qū)別

冪等性：一個冪等操作的特點(diǎn)就是其任意多次執(zhí)行所產(chǎn)生的影響均與依次一次執(zhí)行的影響相同（一次和多次請求某一個資源應(yīng)該具有同樣的副作用）

POST方法不是冪等的

PUT方法具有冪等性

• PUT請求：如果兩個請求相同，后一個請求會把第一個請求覆蓋掉。（所以PUT用來改資源）

• Post請求：后一個請求不會把第一個請求覆蓋掉。（所以Post用來增資源）

HTTP狀態(tài)碼

服務(wù)器返回的 響應(yīng)報文 中第一行為狀態(tài)行，包含了狀態(tài)碼以及原因短語，用來告知客戶端請求的結(jié)果

• 100 Continue ：表明到目前為止都很正常，客戶端可以繼續(xù)發(fā)送請求或者忽略這個響應(yīng)

• 200 OK 請求成功，響應(yīng)消息返回所請求的對象

• 204 No Content ：請求已經(jīng)成功處理，但是返回的響應(yīng)報文不包含實體的主體部分。一般在只需要從客戶端往服務(wù)器發(fā)送信息，而不需要返回數(shù)據(jù)時使用

• 206 Partial Content ：表示客戶端進(jìn)行了范圍請求。響應(yīng)報文包含由 Content-Range 指定范圍的實體內(nèi)容

• 301 Moved Permanently 永久性重定向，請求對象已永久遷移

• 302 表示臨時重定向。請求對象暫時遷移

• 400 Bad Request ：請求報文中存在語法錯誤

• 403 Forbidden 拒絕訪問。服務(wù)器理解請求客戶端的請求，但是拒絕執(zhí)行此請求（一般是沒有權(quán)限訪問此網(wǎng)站）

• 404 Not Found 服務(wù)器上不存在所請求的對象

• 500 Internal Server Error ：服務(wù)器內(nèi)部錯誤，無法完成請求

• 502 Bad Gateway 錯誤的網(wǎng)關(guān)

重定向和轉(zhuǎn)發(fā)的區(qū)別

• 請求次數(shù)，定向是瀏覽器向服務(wù)器發(fā)送一個請求并收到響應(yīng)后再次向一個新地址發(fā)出請求，轉(zhuǎn)發(fā)是服務(wù)器收到請求后為了完成響應(yīng)跳轉(zhuǎn)到一個新的地址；重定向至少請求兩次，轉(zhuǎn)發(fā)請求一次；

• 地址欄，重定向地址欄會發(fā)生變化，轉(zhuǎn)發(fā)地址欄不會發(fā)生變化

• 跳轉(zhuǎn)限制，重定向可以跳轉(zhuǎn)到任意URL，轉(zhuǎn)發(fā)只能跳轉(zhuǎn)本站點(diǎn)資源

• 發(fā)生行為不同，重定向是客戶端行為，轉(zhuǎn)發(fā)是服務(wù)器端行為

• 是否共享數(shù)據(jù)，重定向兩次請求不共享數(shù)據(jù)，轉(zhuǎn)發(fā)一次請求共享數(shù)據(jù)

無效鏈接

• 死鏈接（Dead Links）指的是無效鏈接，也就是那些不可到達(dá)的鏈接。通俗地理解是以前可以通過點(diǎn)擊這個鏈接到達(dá)網(wǎng)站頁面，后續(xù)可能由于網(wǎng)站遷移、改版或操作不當(dāng)?shù)仍颍沟面溄又赶虻哪繕?biāo)頁面不存在而無法訪問所遺留的鏈接，即稱為死鏈接。

• 訪問死鏈接時，一般會出現(xiàn)“抱歉，您所訪問的頁面不存在”的提示信息或者 404 狀態(tài)頁面。

HTTP常見首部行

請求報文

• Host：請求的目標(biāo)域名和端口號

• User-agent：向服務(wù)器發(fā)送瀏覽器的版本、系統(tǒng)、應(yīng)用程序信息

• Cookie：當(dāng)前域名下的cookie數(shù)據(jù)

• Accept-language：向服務(wù)器聲明客戶機(jī)接收的語言版本

• Connection：告訴服務(wù)器采用什么連接方式

響應(yīng)報文

• Date：服務(wù)器發(fā)送資源時的服務(wù)器時間

• Server：HTTP服務(wù)器的應(yīng)用程序信息

• Location：重定向，讓客戶端跳轉(zhuǎn)到新的URL進(jìn)行訪問

• Last-Modified：服務(wù)器發(fā)來的當(dāng)前資源的最后一次修改時間，如果下一次請求時，服務(wù)器上當(dāng)前資源的修改時間比這個大（更晚），就返回新的資源內(nèi)容

• Content-Length：消息實體的傳輸長度

• Content-Type：響應(yīng)體的媒體資源類型（比如html類型，UTF-8編碼等等

HTTP不同版本的區(qū)別

HTTP 1.0

• 默認(rèn)短連接（每次發(fā)請求都要新建一個 TCP連接，然后進(jìn)行三次握手，Connection: close）

HTTP 1.1

• 默認(rèn)長連接（一次TCP連接可以多次請求，Connection: keep-alive）

• 增加connection header，（該header用來說明客戶端與服務(wù)器端TCP的連接方式）

• 新增了五種請求方法：PUT、DELETE、CONNECT、TRACE、OPTIONS

• 增加更多的緩存策略（如：Entity tag，If-Match）

• 支持?jǐn)帱c(diǎn)續(xù)傳

• 錯誤狀態(tài)碼增多（新增24個）

• 新增HOST請求頭（用來實現(xiàn)虛擬主機(jī)技術(shù)）

  • 一個IP地址可以對應(yīng)多個域名。所以通過HOST（指定請求服務(wù)器的域名/IP地址和端口號）可以確定具體訪問站點(diǎn)

HTTP 2.0

• 解析基于二進(jìn)制，解析錯誤少，更高效（HTTP/1.X解析基于文本）

  • 幀對數(shù)據(jù)進(jìn)行順序標(biāo)識；因為有了序列，服務(wù)器可以并行的傳輸數(shù)據(jù)

• 多路復(fù)用，降低開銷（一次TCP連接可以處理多個請求）

  • 每一組請求和響應(yīng)，都會綁定到一個數(shù)據(jù)流，這個數(shù)據(jù)流會有個唯一的ID來標(biāo)識。然后數(shù)據(jù)流內(nèi)的請求和響應(yīng)就會被切分成多個幀，在對每個幀進(jìn)行二進(jìn)制編碼，同時這個幀會攜帶數(shù)據(jù)流的ID，那么客戶端或者服務(wù)端就可以通過這個ID來判斷新到達(dá)的幀是屬于哪個數(shù)據(jù)流的

• 首部壓縮

  • 通過HPACK算法來對首部進(jìn)行壓縮。大概原理是在客戶端和服務(wù)端維護(hù)靜態(tài)字典和動態(tài)字典。字典中的key為整數(shù)，value 為常見的首部的鍵值對，或者是頭部的名稱

• 服務(wù)端推送

  • 服務(wù)器可以對客戶端的一個請求發(fā)送多個響應(yīng)。換句話說，除了對最初請求的響應(yīng)外，服務(wù)器還可以向客戶端推送額外資源，而無需客戶端明確地請求

HTTP協(xié)議是無狀態(tài)的 和 Connection: keep-alive的區(qū)別

無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。從另一方面講，打開一個服務(wù)器上的網(wǎng)頁和你之前打開這個服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系。（上一次的請求對這次的請求沒有任何影響，服務(wù)端也不會對客戶端上一次的請求進(jìn)行任何記錄處理）

HTTP是一個無狀態(tài)的面向連接的協(xié)議，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無連接）

從HTTP/1.1起，默認(rèn)都開啟了Keep-Alive，保持連接特性，簡單地說，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接

Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。

網(wǎng)頁的緩存技術(shù)

• Cookie

• Session

• localStorage

• sessionStorage

Session 和 Cookie的區(qū)別

前提：由于HTTP協(xié)議是無狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時，就需要用某種機(jī)制來識具體的用戶

比如你用瀏覽器訪問淘寶網(wǎng)登錄了，按道理說，你就可以查看自己賬號購物車?yán)锏膶氊惲斜砹?，但假設(shè)不用cookie與session等技術(shù)保存用戶的信息，http是不知道你對淘寶網(wǎng)的多次請求是同一個人的

相同點(diǎn)

cookie和session都是用來跟蹤瀏覽器用戶身份的會話方式

不同點(diǎn)

• cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上

• session 默認(rèn)被存在在服務(wù)器的一個文件里（不是內(nèi)存）

• session 可以放在 文件、數(shù)據(jù)庫、或內(nèi)存中都可以

• 重點(diǎn)：session 的運(yùn)行依賴 session id，而 session id 是存在 cookie 中的，也就是說，如果瀏覽器禁用了 cookie ，同時 session 也會失效（但是可以通過其它方式實現(xiàn)，比如在 url 中傳遞 session_id）

• cookie不是很安全，別人可以分析存放在本地的COOKIE并進(jìn)行COOKIE欺騙，考慮到安全應(yīng)當(dāng)使用session

• session會在一定時間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會比較占用你服務(wù)器的性能，考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE

• 單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點(diǎn)最多保存20個cookie

cookie也可以保存用戶的用戶名和密碼

當(dāng)我們登錄網(wǎng)站勾選保存用戶名和密碼的時候，一般保存的都是cookie，將用戶名和密碼的cookie保存到硬盤中，這樣再次登錄的時候瀏覽器直接將cookie發(fā)送到服務(wù)端驗證，直接username和password保存到客戶端

注意

• “session存放在哪里：服務(wù)器端的內(nèi)存中。”指的是Tomcat保存session的方式。對于PHP而言是保存在文件中

• session刪除情況：超時、程序調(diào)用HttpSession.invalidate()、程序關(guān)閉；

• session不會因為瀏覽器的關(guān)閉而刪除。但是存有session ID的cookie的默認(rèn)過期時間是會話級別。也就是用戶關(guān)閉了瀏覽器，那么存儲在客戶端的session ID便會丟失

禁用cookie

如果客戶端禁用了cookie，通常有兩種方法實現(xiàn)session而不依賴cookie：

• URL重寫，就是把sessionId直接附加在URL路徑的后面

• 表單隱藏字段。就是服務(wù)器會自動修改表單，添加一個隱藏字段，以便在表單提交時能夠把session id傳遞回服務(wù)器

Session id分布式負(fù)載均衡問題

• session ticket

session id缺點(diǎn)：往往只保留在一臺服務(wù)器上，所以，如果客戶端的請求發(fā)到另一臺服務(wù)器，就無法恢復(fù)對話

為了解決上述問題，出現(xiàn)了Session ticket

客戶端不再發(fā)送session ID，而是發(fā)送一個服務(wù)器在上一次對話中發(fā)送過來的session ticket。這個session ticket是加密的，只有服務(wù)器才能解密，其中包括本次對話的主要信息，比如對話密鑰和加密方法（此外還包括比如：有效期、壓縮算法等）。當(dāng)服務(wù)器收到session ticket以后，解密后就不必重新生成對話密鑰了

• redis/memcached

cookie存一個key，具體信息存在數(shù)據(jù)庫里，可以用memcached/redis這些基于內(nèi)存的key-value存儲來加速

• IP哈希

每個請求按訪問IP的hash結(jié)果分配，這樣每個訪客固定訪問一個后端服務(wù)器，可以解決session的問題

ARP協(xié)議過程

• 首先，每個主機(jī)都會有自己的ARP緩存區(qū)中建立一個ARP列表，以表示IP地址和MAC地址之間的對應(yīng)關(guān)系

• 當(dāng)源主機(jī)要發(fā)送數(shù)據(jù)時，首先檢測ARP列表中是否對應(yīng)IP地址的目的主機(jī)的MAC地址如果有，則直接發(fā)送數(shù)據(jù)。如果沒有，就向本網(wǎng)段的所有主機(jī)發(fā)送ARP數(shù)據(jù)包，內(nèi)容:我是IP地址，mac地址，誰是IP地址，mac?

• 當(dāng)本網(wǎng)絡(luò)的所有主機(jī)收到該ARP數(shù)據(jù)包時，首先檢查數(shù)據(jù)包中的IP地址是否是自己的IP地址，如果不是，則忽略該數(shù)據(jù)包。如果是，則首先從數(shù)據(jù)包中取出源主機(jī)的IP和mac地址寫入到ARP列表中，如果以存在，則覆蓋。然后將自己的mac地址寫入arp響應(yīng)包中，告訴源主機(jī)自己是它想要找的mac地址

• 源主機(jī)收到ARP響應(yīng)包后，將目的主機(jī)的IP和mac地址寫入arp列表，并利用此信息發(fā)送數(shù)據(jù)

• 如果源主機(jī)一直沒有收到arp響應(yīng)數(shù)據(jù)包，表示arp查詢失敗

DNS協(xié)議過程

image

• 操作系統(tǒng)會先檢查自己本地的hosts文件是否有這個網(wǎng)址映射關(guān)系，如果有，就先調(diào)用這個IP地址映射，完成域名解析

• 如果hosts里沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網(wǎng)址映射關(guān)系，如果有，直接返回，完成域名解析

• 如果hosts與本地DNS解析器緩存都沒有相應(yīng)的網(wǎng)址映射關(guān)系，首先會找TCP/ip參數(shù)中設(shè)置的首選DNS服務(wù)器，在此我們叫它本地DNS服務(wù)器，此服務(wù)器收到查詢時，如果要查詢的域名，包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機(jī)，完成域名解析，此解析具有權(quán)威性

• 如果要查詢的域名，不由本地DNS服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個IP地址映射，完成域名解析，此解析不具有權(quán)威性

• 如果本地DNS服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù)本地DNS服務(wù)器的設(shè)置（是否設(shè)置轉(zhuǎn)發(fā)器）進(jìn)行查詢，如果未用轉(zhuǎn)發(fā)模式，本地DNS就把請求發(fā)至13臺根DNS，根DNS服務(wù)器收到請求后會判斷這個域名(.com)是誰來授權(quán)管理，并會返回一個負(fù)責(zé)該頂級域名服務(wù)器的一個IP。本地DNS服務(wù)器收到IP信息后，將會聯(lián)系負(fù)責(zé).com域的這臺服務(wù)器。這臺負(fù)責(zé).com域的服務(wù)器收到請求后，如果自己無法解析，它就會找一個管理.com域的下一級DNS服務(wù)器地址(qq.com)給本地DNS服務(wù)器。當(dāng)本地DNS服務(wù)器收到這個地址后，就會找qq.com域服務(wù)器，重復(fù)上面的動作，進(jìn)行查詢，直至找到www.qq.com主機(jī)

• 如果用的是轉(zhuǎn)發(fā)模式，此DNS服務(wù)器就會把請求轉(zhuǎn)發(fā)至上一級DNS服務(wù)器，由上一級服務(wù)器進(jìn)行解析，上一級服務(wù)器如果不能解析，或找根DNS或把轉(zhuǎn)請求轉(zhuǎn)至上上級，以此循環(huán)。不管是本地DNS服務(wù)器用是是轉(zhuǎn)發(fā)，還是根提示，最后都是把結(jié)果返回給本地DNS服務(wù)器，由此DNS服務(wù)器再返回給客戶機(jī)

遞歸查詢

image

迭代查詢

image

DNS

DNS域名解析時用UDP

DNS區(qū)域傳送時用TCP

DNS的規(guī)范規(guī)定了2種類型的DNS服務(wù)器，一個叫主DNS服務(wù)器，一個叫輔助DNS服務(wù)器。在一個區(qū)中主DNS服務(wù)器從自己本機(jī)的數(shù)據(jù)文件中讀取該區(qū)的DNS數(shù)據(jù)信息，而輔助DNS服務(wù)器則從區(qū)的主DNS服務(wù)器中讀取該區(qū)的DNS數(shù)據(jù)信息。當(dāng)一個輔助DNS服務(wù)器啟動時，它需要與主DNS服務(wù)器通信，并加載數(shù)據(jù)信息，這就叫做區(qū)傳送（zone transfer）。 這種情況下，使用TCP協(xié)議

Ping時，用到了哪些協(xié)議

• DNS協(xié)議，通過DNS協(xié)議，將ping后接的域名轉(zhuǎn)換為ip地址。（DNS使用的傳輸層協(xié)議是UDP）

• ARP協(xié)議，通過ARP解析服務(wù)，由ip地址解析出MAC地址，以在數(shù)據(jù)鏈路層傳輸。

• ICMP協(xié)議，ping是為了測試另一臺主機(jī)是否可達(dá)，發(fā)送一份ICMP回顯請求給目標(biāo)主機(jī)，并等待ICMP回顯應(yīng)答。（ICMP用于在ip主機(jī)、路由器間傳遞網(wǎng)絡(luò)是否通暢、主機(jī)是否可達(dá)等控制信息）

擴(kuò)展

網(wǎng)絡(luò)類型

按照不同的劃分依據(jù)

地理位置

局域網(wǎng)、城域網(wǎng)、廣域網(wǎng)、個人網(wǎng)

傳輸介質(zhì)

有線網(wǎng)、光纖網(wǎng)、無線網(wǎng)

拓?fù)浣Y(jié)構(gòu)

星型結(jié)構(gòu)、環(huán)形結(jié)構(gòu)、總線型結(jié)構(gòu)

透明傳輸

透明傳輸：傳輸?shù)膬?nèi)容從源到目的過程中，底層協(xié)議不對業(yè)務(wù)數(shù)據(jù)內(nèi)容做任何改變。從上層角度看，似乎就是一個透明的管道，什么都可以傳（無論是什么報文都可以傳輸）

非透明傳輸：底層協(xié)議要對傳輸內(nèi)容有限制或者修改（某些特殊字符不能傳輸）

URL

URL(Uniform Resource Locator) 地址用于描述一個網(wǎng)絡(luò)上的資源，基本格式如下：

<pre spellcheck="false" class="md-fences md-end-block ty-contain-cm modeLoaded" lang="" cid="n700" mdtype="fences" style="box-sizing: border-box; overflow: visible; font-family: var(--monospace); font-size: 0.9em; display: block; break-inside: avoid; text-align: left; white-space: normal; background-image: inherit; background-position: inherit; background-size: inherit; background-repeat: inherit; background-attachment: inherit; background-origin: inherit; background-clip: inherit; background-color: rgb(248, 248, 248); position: relative !important; border: 1px solid rgb(231, 234, 237); border-radius: 3px; padding: 8px 4px 6px; margin-bottom: 15px; margin-top: 15px; width: inherit; color: rgb(51, 51, 51); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">schema://host[:port]/path/.../[?query-string][#anchor]</pre>

• scheme： 指定低層使用的協(xié)議，eg：http，https，ftp，…

• host： HTTP服務(wù)器的IP地址或者域名

• port#： HTTP服務(wù)器的默認(rèn)端口是80，這種情況下端口號可以省略；如果使用了別的端口，必須指明，例如： http://www.cnblogs.com:8080/

• path：訪問資源的路徑

• query-string：發(fā)送給http服務(wù)器的數(shù)據(jù)

• anchor： 錨