前言

無論是 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地址

夯實基礎系列二：網絡知識總結