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

前言

不管是 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地址