前言

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

概要

網路知識我做了 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：要求用隧道協議連線代理\n持久連線節省通訊量\n管線化實現並行傳送多個請求，而不需要一個接一個等響應

2.2 HTTP1.1 和HTTP1.0的區別

可擴充套件性：定義Via頭域，增加版本號的支援

快取

增加對快取的重啟用機制：使用ETag頭域描述一個資源

增加Cache-Control頭域支援可擴充套件的指令集

頻寬優化：允許請求資源的某部分，而不是整個資源

長連線

HTTP/1.0只支援瀏覽器與伺服器保持短暫的連線，瀏覽器的每次請求都要建立一個新的連線。

而HTTP/1.1允許在一個TCP連線上可以傳送多個HTTP請求和響應。HTTP/1.1協議的持續連線有兩種方式，即非流水線方式和流水線方式

非流水線方式的特點是，客戶在收到前一個響應後才能發出下一個請求；

流水線方式的特點是，客戶在收到HTTP的響應報文之前就能接著傳送新的請求報文

2.3 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.4 電腦訪問網頁的過程

用到的協議：DNS、HTTP、OSPF、IP、ARP

過程描述

DNS把域名解析成對應的IP

傳送一次請求，伺服器返回一個永久重定向響應，這樣瀏覽器就知道要訪問的正確網址

傳送請求html的請求，這個連線過程基於TCP/IP三次握手四次揮手的，建立連線

伺服器返回一個html響應

瀏覽器根據渲染引擎解析返回的html響應，呈現內容

繼續傳送內嵌在html檔案其他資源的請求，比如css、js、圖片資源等

載入整個頁面

2.5 Ping

同網段

主機A要去Ping主機B， 主機A會封裝兩層報文，主機A先檢查自己MAC地址中是否有B的MAC地址，如果沒有就向外傳送一個ARP廣播包

交換機收到這個ARP後，會檢查在交換機中是否包含B的MAC地址，如果有就直接返回給A；如果沒有就向所有埠傳送ARP，該網段的主機的MAC如果與B的MAC地址不同就丟棄，如果主機B收到了該ARP就馬上返回相同格式的ARP

這時主機A已經有了B的MAC地址，就把B的MAC地址封裝到ICMP報中，向主機B傳送一個回顯請求

主機B收到該報文後，知道是主機A的一個回顯請求，就會返回一個相同格式的報文。這樣就完成了同一個網段的Ping的過程

不同網段

主機A要去Ping一個不同網段的主機C，主機A會去找閘道器轉發

如果主機A不知道閘道器的MAC地址，就會發送一個ARP廣播一下，這樣就知道了閘道器的MAC地址

閘道器收到主機A的ICMP報文，根據上面的目的IP，會去查詢路由表，找到一個出口指標，給主機C傳送一個ICMP報文

如果閘道器不知道主機C的MAC地址，就會給閘道器內所有的主機發送一個ARP，從而找到主機C的MAC地址

主機C收到主機A的報文就會給主機A傳送一個回顯請求。這樣就完成了不同網段的Ping的請求

2.6 路由器與交換機的區別

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

2.7 websocket

全雙工通訊

特點

推送功能：支援伺服器向客戶端推送資料的推送功能

減少通訊量：一直保持連線

HTTP連線建立後，需要完成一次握手動作

握手—請求：用到HTTP的upgrade欄位告知伺服器通訊協議發生變化

握手—響應：對於之前的請求返回狀態碼101 switching protocols

成功握手確立WebSocket連線之後，通訊不再使用HTTP的資料幀，而採用WebSocket獨立的資料幀

3. HTTPS協議

3.1 HTTP缺點

通訊使用明文可能會被竊聽

解決方式

通訊加密。SSL和TLS組合使用

內容加密

不驗證通訊方身份就可能遭遇偽裝

解決方式：查明對手的證書

無法證明報文完整性，可能已遭篡改

數字簽名，MD5並不可靠，應用HTTPS

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

4. TCP協議

4.1 三次握手

傳送端髮帶SYN標誌的資料包給對方。

接收端收到後，回傳一個帶有SYN/ACK標誌的資料包以示傳達確認資訊。

最後，傳送端再回傳一個帶ACK標誌的資料包，代表“握手”結束

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

4.2 四次揮手

客戶端A傳送一個FIN，用來關閉客戶A到伺服器B的資料傳送。

伺服器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將佔用一個序號。

伺服器B關閉與客戶端A的連線，傳送一個FIN給客戶端A。

客戶端A發回ACK報文確認，並將確認序號設定為收到序號加1。

4.3 流量控制

TCP接收端對傳送端傳送多少位元組的資料進行控制，防止接收端處理不及而丟失資料

傳送視窗的大小是受到接收視窗的控制的。

傳送視窗必須根據接收端的大小及時調整發送視窗的大小，這個機制保證了每次TCP傳輸的資料量都是接收端可以及時處理的。

4.4 差錯控制

保證接收端接收的資料是完整未受損傷的，是可靠性的重要保證。

主要使用校驗和、確認、超時重傳這三個工具進行差錯控制。

4.5 擁塞控制

擁塞視窗

傳送方的視窗大小是接收視窗與擁塞視窗中的較小值。

擁塞視窗的大小又取決於網路的擁塞狀況。

擁塞策略

慢開始

擁塞避免

擁塞檢測

擁塞控制流程

由於剛開始不清楚網路的擁塞情況，所以會首先採用慢開始演算法，開始階段，視窗大小由1指數增大，直到視窗大小到達門限值。

視窗大小到達門限值後，就開始執行擁塞避免演算法，之後視窗值按照線性規律增大，直到出現超時或者到達最大的視窗大小值。

這個時候，會開始執行擁塞檢測演算法，也就是把門限值變為視窗大小的一半，之後繼續執行擁塞避免演算法，視窗大小按照線性規律增大。