計算機網絡體系結構

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

image

七層模型：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層

TCP/IP四層模型：網絡接口層、網絡層、傳輸層、應用層

image

各層協議

網絡層：IP、ARP、RARP（后兩個在OSI中認為在數據鏈路層，在TCP/IP協議中被認為在網絡層）

傳輸層：TCP、UDP

應用層：HTTP、DNS、FTP、SMTP、POP3、TELNET

基于TCP的應用層協議有：HTTP、HTTPS、FTP（文件傳輸協議）、SMTP（發送電子郵件）、POP3（接收電子郵件)、TELNET（遠程登陸協議）

基于UDP的應用層協議有：TFTP（簡單文件傳輸協議）、SNMP（簡單網絡管理協議）、NTP（網絡時間協議）

基于TCP和UDP的應用層協議有：DNS

簡單了解

FTP

FTP協議的客戶機與服務器之間需要建立兩個連接， 一個用于控制數據傳輸（端口21）， 一個用于數據傳輸（端口20）。數據連接主要用于數據傳輸，完成文件內容的傳輸。控制連接主要用于傳輸FTP控制命令和服務器的回送消息

TFTP

在UDP之上上建立一個類似于FTP的但僅支持文件上傳和下載功能的傳輸協議，所以它不包含FTP協議中的目錄操作和用戶權限等內容

SNMP

SNMP用于網絡設備的管理。SNMP的工作方式：管理員需要向設備獲取數據，所以SNMP提供了“讀”操作；管理員需要向設備執行設置操作，所以SNMP提供了“寫”操作；設備需要在重要狀況改變的時候，向管理員通報事件的發生，所以SNMP提供了“Trap”操作

Get:讀取網絡設備的狀態信息 Set：遠程配置設備參數 Trap:管理站及時獲取設備的重要信息

NTP

用于網絡時間同步的協議，使網絡中的計算機時鐘同步到UTC，再配合各個時區的偏移調整就能實現精準同步對時功能

五層模型

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

• 數據鏈路層（數據幀：Frame）：

  • 在物理層提供的服務基礎上，數據鏈路層在通信的實體間建立數據鏈路連接

  • 不同的網絡類型，發送數據的機制不同，數據鏈路層就是將數據包封裝成能夠在不同網絡傳輸的幀

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

• 網絡層（數據包：Packet）：把傳輸層傳遞下的數據報封裝成分組（負責選擇最佳路線、規劃IP地址）

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

    • 路由器查看數據包目標IP地址，根據路由表為數據包選擇路徑。路由表中的類目可以人工添加（靜態路由）也可以動態生成（動態路由）

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

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

  • 提供進程間的通用數據傳輸服務，傳輸層向高層屏蔽下層數據通信的細節

• 應用層（報文：Message）：提供用戶接口，特指能夠發送網絡流量的程序（為應用程序提供服務）

OSI中其他兩層的作用：

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

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

數據鏈路層

三個基本問題

• 封裝成幀

每個鏈路層協議都規定了幀數據部分的長度限制——最大傳輸單元 MTU（Maximum Transfer Unit）

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

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

• 透明傳輸

發送端的數據鏈路層在數據中出現控制字符“SOH”和“EOT”的前面插入一個轉移字符“ESC”

• 差錯檢測

循環冗余編碼（CRC）

向網絡層提供的服務

• 無確認的無連接服務

• 有確認的無連接服務

• 有確認的面向連接服務（需要在幀傳輸之前建立數據鏈路，也需要在幀傳輸結束后釋放數據鏈路）

MAC尋址

MAC地址被燒入每個以太網網卡中（MAC地址全球唯一）

ARP協議，IP地址 ? MAC地址

RARP協議，MAC地址 ? IP地址

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

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

• 并且如果直接用MAC地址進行尋址，如果網絡規模比較大的話，交換機需要保存所有的MAC地址，很不現實

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

網絡層

IP協議作用

• 尋址和路由選擇

• 分段與重組（不同類型網絡所規定的最大傳輸單元MTU不同）

• IP地址和MAC地址的轉換，將不同格式的物理地址（即，MAC地址）轉換為統一的IP地址

傳輸層

TCP和UDP的區別、特點

TCP的主要特點

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

• 具有可靠性（校驗和、重傳控制、序號標識、滑動窗口、確認應答實現可靠傳輸。如丟包時的重發控制，還可以對次序亂掉的分包進行順序控制）

• 全雙工通信通信方式

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

• 擁塞控制

• 每一條TCP連接只能是點對點的（一對一）

• 面向字節流

UDP的主要特點

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

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

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

• 面向報文

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

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

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

區別總結

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

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

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

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

• TCP對系統資源要求較多，UDP對系統資源要求較少。

TCP協議采用哪些機制保證數據的可靠傳輸

• 數據分割，對數據段進行編號

• 校驗和

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

• 超時重傳

• 擁塞控制

• 流量控制

如何實現流量控制

流量控制：點對點通信量的控制。TCP支持根據接收端的處理能力，來決定發送端的發送速度

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

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

如何實現擁塞控制

擁塞：如果網絡非常擁堵，此時再發送數據就會加重網絡負擔，那么發送的數據段很可能超過了最大生存時間也沒有到達接收方，就會產生大量丟包問題，從而進行大量的超時重傳，嚴重影響傳輸

擁塞控制：TCP在傳輸時盡可能快的將數據傳輸，并且避免擁塞造成的一系列問題。是可靠性的保證，同時也是維護了傳輸的高效性

擁塞控制目的：為了防止過多的數據注入到網絡中，避免網絡中的路由器、鏈路過載

擁塞控制過程：TCP發送將維護一個擁塞窗口的狀態變量，該變量隨著網絡擁塞程度動態變化，通過滿開始、擁塞避免等算法減小網絡擁塞的發生

• 慢開始（指數增長）

• 擁塞避免（線性增長）

• 快重傳

• 快恢復

TCP的幾個狀態

• SYN表示建立連接，

• FIN表示關閉連接，

• ACK表示響應，

• PSH表示有數據傳輸，

• RST表示連接重置

三次握手

過程

• 第一次握手：Client將標志位SYN置為1，隨機產生一個值seq=J，并將該數據包發送給Server，Client 進入syn_sent狀態，等待Server確認

• 第二次握手：Server收到數據包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1,隨機產生一個值seq=K，并將該數據包發送給Client以確認連接請求，Server進入syn_rcvd狀態

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

為什么是三次

• 為了實現可靠數據傳輸， TCP 協議的通信雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 并確認對方已經收到了序列號起始值的必經步驟

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

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

只有經過第三次握手，才能確保雙向都可以接收到對方的發送的數據

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

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

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

四次揮手

過程

• Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入fin_wait_1狀態

• Server收到FIN后，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進入Close_wait狀態。此時TCP連接處于半關閉狀態，即客戶端已經沒有要發送的數據了，但服務端若發送數據，則客戶端仍要接收

• Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入Last_ack狀態

• Client收到FIN后，Client進入Time_wait狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入Closed狀態，完成四次揮手

為什么是四次

保證服務端數據發送完

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

TIME-WAIT的作用

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

• 為了保證客戶端發送的最后一個ack報文段能夠到達服務器

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

• 在第四次揮手后，經過2msl的時間足以讓本次連接產生的所有報文段都從網絡中消失，這樣下一次新的連接中就肯定不會出現舊連接的報文段了

應用層

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

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

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

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

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

• 瀏覽器與目標服務器建立TCP連接

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

  • 確認連接后發送一個HTTP請求報文；（HTTP協議）

  • 服務器處理請求，并對請求做出響應；

  • 瀏覽器收到服務器響應，得到html代碼；

• html頁面的解析與渲染

HTTP和HTTPS的區別

• https協議需要到CA（Certificate Authority，證書頒發機構）申請證書，一般免費證書較少，因而需要一定費用

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

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

• http的連接很簡單，是無狀態的。Https協議是由SSL/TLS+Http協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。(無狀態的意思是其數據包的發送、傳輸和接收都是相互獨立的。無連接的意思是指通信雙方都不長久的維持對方的任何信息。)

HTTP明文傳輸帶來的風險：

• 竊聽風險：第三方可以獲取通信內容

• 篡改風險：第三方可以修改通信內容

• 冒充風險：第三方可以冒充他人身份參與通信

HTTPS加密過程

• 客戶端給服務器發送一個請求，包括協議版本號、隨機數，以及客戶端支持的加密算法

• 服務器確認雙方使用的加密方法，并給出一個服務器產生的隨機數和CA證書給客戶端，內容包括：證書的發布機構、有效期、所有者、簽名以及公鑰等

• 客戶端對發來的公鑰進行真偽校驗，如果有效，生成一個新的隨機數，并使用CA證書中的公鑰，加密這個隨機數，發送給服務器

• 服務器使用自己的私鑰，獲取客戶端發送的隨機數

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

細節過程：

image

整體過程：

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

為什么客戶端和服務端都需要發送一個Finish報文

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

同樣的，服務器發送這也的一個整體校驗值，用來客戶端驗證服務器是否是真正要進行通信的那一個

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

為什么使用三個隨機數

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

• 增加隨機性

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

  • SSL 的協議默認不信任每個主機都能產生完全隨機的數，如果只使用一個偽隨機的數來生成秘鑰，就很容易被破解。

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

數據傳輸需要用對稱加密的原因

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

對稱加密算法

• DES

• AES

非對稱加密算法

• RSA

• DSA

HTTP請求有哪些

GET和POST的區別

• GET請求時冪等的（冪等的意味著對同一個URL的多個請求應用返回同樣的結果）

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

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

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

PUT和POST的區別

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

POST方法不是冪等的

PUT方法具有冪等性

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

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

HTTP狀態碼

服務器返回的 響應報文 中第一行為狀態行，包含了狀態碼以及原因短語，用來告知客戶端請求的結果

• 100 Continue ：表明到目前為止都很正常，客戶端可以繼續發送請求或者忽略這個響應

• 200 OK 請求成功，響應消息返回所請求的對象

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

• 206 Partial Content ：表示客戶端進行了范圍請求。響應報文包含由 Content-Range 指定范圍的實體內容

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

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

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

• 403 Forbidden 拒絕訪問。服務器理解請求客戶端的請求，但是拒絕執行此請求（一般是沒有權限訪問此網站）

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

• 500 Internal Server Error ：服務器內部錯誤，無法完成請求

• 502 Bad Gateway 錯誤的網關

重定向和轉發的區別

• 請求次數，定向是瀏覽器向服務器發送一個請求并收到響應后再次向一個新地址發出請求，轉發是服務器收到請求后為了完成響應跳轉到一個新的地址；重定向至少請求兩次，轉發請求一次；

• 地址欄，重定向地址欄會發生變化，轉發地址欄不會發生變化

• 跳轉限制，重定向可以跳轉到任意URL，轉發只能跳轉本站點資源

• 發生行為不同，重定向是客戶端行為，轉發是服務器端行為

• 是否共享數據，重定向兩次請求不共享數據，轉發一次請求共享數據

無效鏈接

• 死鏈接（Dead Links）指的是無效鏈接，也就是那些不可到達的鏈接。通俗地理解是以前可以通過點擊這個鏈接到達網站頁面，后續可能由于網站遷移、改版或操作不當等原因，使得鏈接指向的目標頁面不存在而無法訪問所遺留的鏈接，即稱為死鏈接。

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

HTTP常見首部行

請求報文

• Host：請求的目標域名和端口號

• User-agent：向服務器發送瀏覽器的版本、系統、應用程序信息

• Cookie：當前域名下的cookie數據

• Accept-language：向服務器聲明客戶機接收的語言版本

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

響應報文

• Date：服務器發送資源時的服務器時間

• Server：HTTP服務器的應用程序信息

• Location：重定向，讓客戶端跳轉到新的URL進行訪問

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

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

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

HTTP不同版本的區別

HTTP 1.0

• 默認短連接（每次發請求都要新建一個 TCP連接，然后進行三次握手，Connection: close）

HTTP 1.1

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

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

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

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

• 支持斷點續傳

• 錯誤狀態碼增多（新增24個）

• 新增HOST請求頭（用來實現虛擬主機技術）

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

HTTP 2.0

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

  • 幀對數據進行順序標識；因為有了序列，服務器可以并行的傳輸數據

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

  • 每一組請求和響應，都會綁定到一個數據流，這個數據流會有個唯一的ID來標識。然后數據流內的請求和響應就會被切分成多個幀，在對每個幀進行二進制編碼，同時這個幀會攜帶數據流的ID，那么客戶端或者服務端就可以通過這個ID來判斷新到達的幀是屬于哪個數據流的

• 首部壓縮

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

• 服務端推送

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

HTTP協議是無狀態的 和 Connection: keep-alive的區別

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

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

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

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

網頁的緩存技術

• Cookie

• Session

• localStorage

• sessionStorage

Session 和 Cookie的區別

前提：由于HTTP協議是無狀態的協議，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識具體的用戶

比如你用瀏覽器訪問淘寶網登錄了，按道理說，你就可以查看自己賬號購物車里的寶貝列表了，但假設不用cookie與session等技術保存用戶的信息，http是不知道你對淘寶網的多次請求是同一個人的

相同點

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

不同點

• cookie數據存放在客戶的瀏覽器上，session數據放在服務器上

• session 默認被存在在服務器的一個文件里（不是內存）

• session 可以放在 文件、數據庫、或內存中都可以

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

• cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙，考慮到安全應當使用session

• session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能，考慮到減輕服務器性能方面，應當使用COOKIE

• 單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie

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

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

注意

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

• session刪除情況：超時、程序調用HttpSession.invalidate()、程序關閉；

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

禁用cookie

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

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

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

Session id分布式負載均衡問題

• session ticket

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

為了解決上述問題，出現了Session ticket

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

• redis/memcached

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

• IP哈希

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

ARP協議過程

• 首先，每個主機都會有自己的ARP緩存區中建立一個ARP列表，以表示IP地址和MAC地址之間的對應關系

• 當源主機要發送數據時，首先檢測ARP列表中是否對應IP地址的目的主機的MAC地址如果有，則直接發送數據。如果沒有，就向本網段的所有主機發送ARP數據包，內容:我是IP地址，mac地址，誰是IP地址，mac?

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

• 源主機收到ARP響應包后，將目的主機的IP和mac地址寫入arp列表，并利用此信息發送數據

• 如果源主機一直沒有收到arp響應數據包，表示arp查詢失敗

DNS協議過程

image

• 操作系統會先檢查自己本地的hosts文件是否有這個網址映射關系，如果有，就先調用這個IP地址映射，完成域名解析

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

• 如果hosts與本地DNS解析器緩存都沒有相應的網址映射關系，首先會找TCP/ip參數中設置的首選DNS服務器，在此我們叫它本地DNS服務器，此服務器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具有權威性

• 如果要查詢的域名，不由本地DNS服務器區域解析，但該服務器已緩存了此網址映射關系，則調用這個IP地址映射，完成域名解析，此解析不具有權威性

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

• 如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。不管是本地DNS服務器用是是轉發，還是根提示，最后都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機

遞歸查詢

image

迭代查詢

image

DNS

DNS域名解析時用UDP

DNS區域傳送時用TCP

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

Ping時，用到了哪些協議

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

• ARP協議，通過ARP解析服務，由ip地址解析出MAC地址，以在數據鏈路層傳輸。

• ICMP協議，ping是為了測試另一臺主機是否可達，發送一份ICMP回顯請求給目標主機，并等待ICMP回顯應答。（ICMP用于在ip主機、路由器間傳遞網絡是否通暢、主機是否可達等控制信息）

擴展

網絡類型

按照不同的劃分依據

地理位置

局域網、城域網、廣域網、個人網

傳輸介質

有線網、光纖網、無線網

拓撲結構

星型結構、環形結構、總線型結構

透明傳輸

透明傳輸：傳輸的內容從源到目的過程中，底層協議不對業務數據內容做任何改變。從上層角度看，似乎就是一個透明的管道，什么都可以傳（無論是什么報文都可以傳輸）

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

URL

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

<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： 指定低層使用的協議，eg：http，https，ftp，…

• host： HTTP服務器的IP地址或者域名

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

• path：訪問資源的路徑

• query-string：發送給http服務器的數據

• anchor： 錨