前言

無論是 C/S 開發還是 B/S 開發，無論是前端開發還是後臺開發，網路總是無法避免的，資料如何傳輸，如何保證正確性和可靠性，如何提高傳輸效率，如何解決會話管理問題，如何在網路擁堵環境下采取措施。這些都是需要了解的。

今天總結下與網路相關的知識，不是那麼詳細，但是包含了我認為重要的所有點。如果想深入瞭解的可以參考《圖解HTTP[上野 宣]》、《圖解TCP／IP（第5版）[竹下隆史]》以及計算機網路相關教材。

概要

網路知識我做了 8 個方面的總結，包括DNS協議，HTTP協議，HTTPS協議，TCP協議，IP協議，TCP/IP，Web攻擊，其他協議。以下對這些內容做一些簡單的總結，同時我也有完整的思維導圖，部落格上不方便展示，若有需要，

細節

1. DNS 協議

作用：提供域名到IP地址之間的解析服務。或逆向從IP地址反查域名的服務

2. HTTP協議

2.1 特點

• 無狀態
• 使用URI定義網際網路資源
• HTTP方法
  • GET：獲取資源
  • POST:傳輸實體主體
  • PUT：傳輸檔案
  • HEAD：獲得報文首部
  • DELETE：刪除檔案
  • OPTIONS：詢問支援的方法
  • TRACE：追蹤路徑
  • CONNECT：要求用隧道協議連線代理
• 持久連線節省通訊量
• 管線化實現並行傳送多個請求，而不需要一個接一個等響應

2.2 HTTP 報文

• 用於HTTP協議互動的資訊稱為HTTP報文
• 請求報文
  • 報文首部
    • 請求行
    • 請求首部欄位
    • 通用首部欄位
    • 實體首部欄位
    • 其他
  • 空行
  • 報文主體
• 響應報文
  • 報文首部
    • 狀態行
    • 響應首部欄位
    • 通用首部欄位
    • 實體首部欄位
    • 其他
  • 空行
  • 報文主體
• 傳送多種資料的多部分物件集合
  • MIME
  • multipart/form-data
• 內容協商
  • 伺服器驅動協商
  • 客戶端驅動協商
  • 透明協商

2.3 HTTP狀態碼

• 1XX：接收的請求正在處理
• 2XX：請求正常處理完畢
  • 200 OK
  • 204 NoContent
  • 206 Partial Content
• 3XX：需要進行附加操作以完成請求
  • 301 Moved Permanenetly
  • 302 Found
  • 303 See Other
  • 304 Not Modified
  • 307 Temporary Redirect
• 4XX：伺服器無法處理請求
  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found
• 5XX：伺服器處理請求出錯
  • 500 Internal Server Error
  • 503 Service Unavailable

2.4 HTTP1.1 和HTTP1.0的區別

• 可擴充套件性：定義Via頭域，增加版本號的支援
• 快取
  • 增加對快取的重啟用機制：使用ETag頭域描述一個資源
  • 增加Cache-Control頭域支援可擴充套件的指令集
• 頻寬優化：允許請求資源的某部分，而不是整個資源
• 長連線
  • HTTP/1.0只支援瀏覽器與伺服器保持短暫的連線，瀏覽器的每次請求都要建立一個新的連線。
  • 而HTTP/1.1允許在一個TCP連線上可以傳送多個HTTP請求和響應。HTTP/1.1協議的持續連線有兩種方式，即非流水線方式和流水線方式。
    • 非流水線方式的特點是，客戶在收到前一個響應後才能發出下一個請求；
    • 流水線方式的特點是，客戶在收到HTTP的響應報文之前就能接著傳送新的請求報文

2.5 Cookie與Session的區別

• 存取方式的不同
  • Cookie中只能保管ASCII字串，假如需求存取Unicode字元或者二進位制資料，需求先進行編碼。Cookie中也不能直接存取Java物件。若要儲存略微複雜的資訊，運用Cookie是比較艱難的。
  • Session中能夠存取任何型別的資料，包括而不限於String、Integer、List、Map等。Session中也能夠直接保管Java Bean乃至任何Java類，物件等，運用起來十分便當。能夠把Session看做是一個Java容器類。
• 隱私策略的不同
  • Cookie儲存在客戶端閱讀器中，對客戶端是可見的，客戶端的一些程式可能會窺探、複製以至修正Cookie中的內容。
  • Session儲存在伺服器上，對客戶端是透明的，不存在敏感資訊洩露的風險。
• 有效期上的不同
  • Cookie的過期時間指定
  • Session依賴於名為JSESSIONID的Cookie，而Cookie JSESSIONID的過期時間默許為–1，只需關閉了瀏覽器該Session就會失效，因而Session不能完成資訊永世有效的效果。
• 伺服器壓力的不同
  • Cookie保管在客戶端，不佔用伺服器資源。假如併發閱讀的使用者十分多，Cookie是很好的選擇。關於Google、Baidu、Sina來說，Cookie或許是唯一的選擇。
  • Session是保管在伺服器端的，每個使用者都會產生一個Session。假如併發訪問的使用者十分多，會產生十分多的Session，耗費大量的記憶體。因而像Google、Baidu、Sina這樣併發訪問量極高的網站，是不太可能運用Session來追蹤客戶會話的。
• 瀏覽器支援的不同
  • Cookie是需要客戶端瀏覽器支援的。
  • 假如客戶端瀏覽器不支援Cookie，需要運用Session以及URL地址重寫。
• 跨域支援上的不同
  • Cookie支援跨域名訪問，例如將domain屬性設定為“.biaodianfu.com”，則以“.biaodianfu.com”為字尾的一切域名均能夠訪問該Cookie。跨域名Cookie如今被普遍用在網路中，例如Google、Baidu、Sina等。
  • Session則不會支援跨域名訪問。Session僅在他所在的域名內有效。

2.6 電腦訪問網頁的過程

• 用到的協議：DNS、HTTP、OSPF、IP、ARP
• 過程描述
  1. DNS把域名解析成對應的IP
  2. 傳送一次請求，伺服器返回一個永久重定向響應，這樣瀏覽器就知道要訪問的正確網址
  3. 傳送請求html的請求，這個連線過程基於TCP/IP三次握手四次揮手的，建立連線
  4. 伺服器返回一個html響應
  5. 瀏覽器根據渲染引擎解析返回的html響應，呈現內容
  6. 繼續傳送內嵌在html檔案其他資源的請求，比如css、js、圖片資源等
  7. 載入整個頁面

2.7 Ping

• 同網段
  1. 主機A要去Ping主機B， 主機A會封裝兩層報文，主機A先檢查自己MAC地址中是否有B的MAC地址，如果沒有就向外傳送一個ARP廣播包
  2. 交換機收到這個ARP後，會檢查在交換機中是否包含B的MAC地址，如果有就直接返回給A；如果沒有就向所有埠傳送ARP，該網段的主機的MAC如果與B的MAC地址不同就丟棄，如果主機B收到了該ARP就馬上返回相同格式的ARP
  3. 這時主機A已經有了B的MAC地址，就把B的MAC地址封裝到ICMP報中，向主機B傳送一個回顯請求
  4. 主機B收到該報文後，知道是主機A的一個回顯請求，就會返回一個相同格式的報文。這樣就完成了同一個網段的Ping的過程
• 不同網段
  1. 主機A要去Ping一個不同網段的主機C，主機A會去找閘道器轉發
  2. 如果主機A不知道閘道器的MAC地址，就會發送一個ARP廣播一下，這樣就知道了閘道器的MAC地址
  3. 閘道器收到主機A的ICMP報文，根據上面的目的IP，會去查詢路由表，找到一個出口指標，給主機C傳送一個ICMP報文
  4. 如果閘道器不知道主機C的MAC地址，就會給閘道器內所有的主機發送一個ARP，從而找到主機C的MAC地址
  5. 主機C收到主機A的報文就會給主機A傳送一個回顯請求。這樣就完成了不同網段的Ping的請求

2.8 路由器與交換機的區別

路由器包含了交換機的功能，交換機主要的作用是擴充套件介面

2.9 確認訪問使用者身份的認證

• basic認證
• digest認證
• ssl客戶端認證
• 基於表單認證
  • 認證多半為基於表單認證
  • session管理及cookie應用

2.10 websocket

• 全雙工通訊
• 特點
  • 推送功能：支援伺服器向客戶端推送資料的推送功能
  • 減少通訊量：一直保持連線
  • HTTP連線建立後，需要完成一次握手動作
    • 握手---請求：用到HTTP的upgrade欄位告知伺服器通訊協議發生變化
    • 握手---響應：對於之前的請求返回狀態碼101 switching protocols
  • 成功握手確立WebSocket連線之後，通訊不再使用HTTP的資料幀，而採用WebSocket獨立的資料幀

3. HTTPS協議

3.1 HTTP缺點

• 通訊使用明文可能會被竊聽
  • 解決方式
    • 通訊加密。SSL和TLS組合使用
    • 內容加密
• 不驗證通訊方身份就可能遭遇偽裝
  • 解決方式：查明對手的證書
• 無法證明報文完整性，可能已遭篡改
  • 數字簽名，MD5並不可靠，應用HTTPS

3.2 HTTP+加密+認證+完整性保護=HTTPS

3.3 HTTPS是身披SSL外殼的HTTP

3.4 HTTP採用混合加密機制

3.5 證明公開金鑰正確性的證書

3.6 SSL協議

• 慢
  • 通訊慢
  • 由於大量消耗CPU及記憶體等資源，導致處理速度變慢
  • SSL必須進行加密處理

4. TCP協議

4.1 傳輸層

4.2 作用

• 提供可靠的位元組流服務

4.3 大塊資料分割成報文段(segment)

4.4 三次握手

1. 傳送端髮帶SYN標誌的資料包給對方。
2. 接收端收到後，回傳一個帶有SYN/ACK標誌的資料包以示傳達確認資訊。
3. 最後，傳送端再回傳一個帶ACK標誌的資料包，代表“握手”結束

握手某個階段中斷，TCP會以相同的順序傳送相同的資料包

4.5 四次揮手

1. 客戶端A傳送一個FIN，用來關閉客戶A到伺服器B的資料傳送。
2. 伺服器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將佔用一個序號。
3. 伺服器B關閉與客戶端A的連線，傳送一個FIN給客戶端A。
4. 客戶端A發回ACK報文確認，並將確認序號設定為收到序號加1。

4.6 流量控制

• TCP接收端對傳送端傳送多少位元組的資料進行控制，防止接收端處理不及而丟失資料
• 傳送視窗的大小是受到接收視窗的控制的。
• 傳送視窗必須根據接收端的大小及時調整發送視窗的大小，這個機制保證了每次TCP傳輸的資料量都是接收端可以及時處理的。

4.7 差錯控制

• 保證接收端接收的資料是完整未受損傷的，是可靠性的重要保證。
• 主要使用校驗和、確認、超時重傳這三個工具進行差錯控制。

4.8 擁塞控制

• 擁塞視窗
  • 傳送方的視窗大小是接收視窗與擁塞視窗中的較小值。
  • 擁塞視窗的大小又取決於網路的擁塞狀況。
• 擁塞策略
  • 慢開始
  • 擁塞避免
  • 擁塞檢測
• 擁塞控制流程
  1. 由於剛開始不清楚網路的擁塞情況，所以會首先採用慢開始演算法，開始階段，視窗大小由1指數增大，直到視窗大小到達門限值。
  2. 視窗大小到達門限值後，就開始執行擁塞避免演算法，之後視窗值按照線性規律增大，直到出現超時或者到達最大的視窗大小值。
  3. 這個時候，會開始執行擁塞檢測演算法，也就是把門限值變為視窗大小的一半，之後繼續執行擁塞避免演算法，視窗大小按照線性規律增大。

5. IP協議

5.1 網路層

5.2 作用

• 把資料包傳送給對方

5.3 條件

• IP地址和MAC地址

5.4 使用ARP協議憑藉MAC地址進行通訊

5.5 路由選擇

6. TCP/IP

6.1 協議族

• IP、ICMP、DNS、TCP、FTP、HTTP、SNMP

6.2 分層管理

• 應用層
  • 決定向使用者提供應用服務時通訊的活動。FTP、HTTP、DNS
• 傳輸層
  • 對上層應用層，提供處於網路連線中的兩臺計算機之間的資料傳輸。TCP、UDP
• 網路層
  • 處理網路上流動的資料包
  • 規定了通過怎樣的路徑到達對方計算機，並把資料包傳送給對方
• 資料鏈路層
  • 處理連線網路的硬體部分

6.3 通訊傳輸流

• 傳送端層與層之間傳輸資料，每經過一層時必定會被打上一個該層所屬的首部資訊
• 接收端在層與層傳輸資料時，每經過一層時會把對應的首部消去。
• 這種把資料資訊包裝起來的做法稱為封裝

7. Web攻擊

7.1 因輸出值轉移不完全引發的安全漏洞

• 跨站指令碼攻擊XSS
• SQL注入攻擊
• OS命令注入攻擊
• HTTP首部注入攻擊
• 郵件首部注入攻擊
• 目錄遍歷攻擊
• 遠端檔案包含漏洞

7.2 因設定或設計上的缺陷引發的安全漏洞

• 強制瀏覽
• 不正確的錯誤訊息處理
• 開放重定向

7.3 因會話管理疏忽引發的安全漏洞

• 會話劫持
• 會話固定攻擊
• 跨站點請求偽造(CSRF)

7.4 其他安全漏洞

• 密碼破解
• 點選劫持
• dos攻擊
• 後門程式

8. 其他協議

8.1 IGMP協議

• 組管理協議，它幫助多播路由器建立以及更新與每一個路由介面相連的忠實成員列表（就是與該路由介面連線頻率較高）。

8.2 ICMP協議

• 差錯控制協議，彌補了IP協議沒有差錯糾正機制以及差錯報告的缺憾。

8.3 ARP協議

• 地址對映協議，可以把一個IP地址對映為MAC地址。
• 把IP資料報封裝成幀（乙太網上對01串的分組定義）後才能通過物理網路，這時就需要目的主機的MAC地址