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

時間 2019-11-11

原文原文鏈接

前言

不管是 C/S 開發仍是 B/S 開發，不管是前端開發仍是後臺開發，網絡老是沒法避免的，數據如何傳輸，如何保證正確性和可靠性，如何提升傳輸效率，如何解決會話管理問題，如何在網絡擁堵環境下采起措施。這些都是須要了解的。html

今天總結下與網絡相關的知識，不是那麼詳細，可是包含了我認爲重要的全部點。若是想深刻了解的能夠參考《圖解HTTP[上野宣]》、《圖解TCP／IP（第5版）[竹下隆史]》以及計算機網絡相關教材。前端

概要

網絡知識我作了 8 個方面的總結，包括DNS協議，HTTP協議，HTTPS協議，TCP協議，IP協議，TCP/IP，Web攻擊，其餘協議。如下對這些內容作一些簡單的總結，同時我也有完整的思惟導圖，博客上不方便展現，如有須要，請關注微信公衆號永倫的小屋，後臺回覆網絡便可獲取。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 三次握手

發送端髮帶SYN標誌的數據包給對方。
接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。
最後，發送端再回傳一個帶ACK標誌的數據包，表明「握手」結束

握手某個階段中斷，TCP會以相同的順序發送相同的數據包瀏覽器

4.5 四次揮手

客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送。
服務器B收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1。和SYN同樣，一個FIN將佔用一個序號。
服務器B關閉與客戶端A的鏈接，發送一個FIN給客戶端A。
客戶端A發回ACK報文確認，並將確認序號設置爲收到序號加1。

4.6 流量控制

TCP接收端對發送端發送多少字節的數據進行控制，防止接收端處理不及而丟失數據
發送窗口的大小是受到接收窗口的控制的。
發送窗口必須根據接收端的大小及時調整發送窗口的大小，這個機制保證了每次TCP傳輸的數據量都是接收端能夠及時處理的。

4.7 差錯控制

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

4.8 擁塞控制

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