摘要：今天總結(jié)下與網(wǎng)絡(luò)相關(guān)的知識，不是那么詳細，但是包含了我認為重要的所有點。概要網(wǎng)絡(luò)知識我做了個方面的總結(jié)，包括協(xié)議，協(xié)議，協(xié)議，協(xié)議，協(xié)議，，攻擊，其他協(xié)議?？缬蛎缃癖黄毡橛迷诰W(wǎng)絡(luò)中，例如等。擁塞窗口的大小又取決于網(wǎng)絡(luò)的擁塞狀況。

無論是 C/S 開發(fā)還是 B/S 開發(fā)，無論是前端開發(fā)還是后臺開發(fā)，網(wǎng)絡(luò)總是無法避免的，數(shù)據(jù)如何傳輸，如何保證正確性和可靠性，如何提高傳輸效率，如何解決會話管理問題，如何在網(wǎng)絡(luò)擁堵環(huán)境下采取措施。這些都是需要了解的。

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

網(wǎng)絡(luò)知識我做了 8 個方面的總結(jié)，包括DNS協(xié)議，HTTP協(xié)議，HTTPS協(xié)議，TCP協(xié)議，IP協(xié)議，TCP/IP，Web攻擊，其他協(xié)議。以下對這些內(nèi)容做一些簡單的總結(jié)，同時我也有完整的思維導(dǎo)圖，博客上不方便展示，若有需要，聯(lián)系我。

作用：提供域名到IP地址之間的解析服務(wù)?；蚰嫦驈腎P地址反查域名的服務(wù)

2.1 特點

無狀態(tài)

使用URI定義互聯(lián)網(wǎng)資源

HTTP方法

GET：獲取資源

POST:傳輸實體主體

PUT：傳輸文件

HEAD：獲得報文首部

DELETE：刪除文件

OPTIONS：詢問支持的方法

TRACE：追蹤路徑

CONNECT：要求用隧道協(xié)議連接代理

持久連接節(jié)省通信量

管線化實現(xiàn)并行發(fā)送多個請求，而不需要一個接一個等響應(yīng)

2.2 HTTP 報文

用于HTTP協(xié)議交互的信息稱為HTTP報文

請求報文

報文首部

請求行

請求首部字段

通用首部字段

實體首部字段

其他

空行

報文主體

響應(yīng)報文

報文首部

狀態(tài)行

響應(yīng)首部字段

通用首部字段

實體首部字段

其他

空行

報文主體

發(fā)送多種數(shù)據(jù)的多部分對象集合

MIME

multipart/form-data

內(nèi)容協(xié)商

服務(wù)器驅(qū)動協(xié)商

客戶端驅(qū)動協(xié)商

透明協(xié)商

2.3 HTTP狀態(tài)碼

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：服務(wù)器無法處理請求

400 Bad Request

401 Unauthorized

403 Forbidden

404 Not Found

5XX：服務(wù)器處理請求出錯

500 Internal Server Error

503 Service Unavailable

2.4 HTTP1.1 和HTTP1.0的區(qū)別

可擴展性：定義Via頭域，增加版本號的支持

緩存

增加對緩存的重激活機制：使用ETag頭域描述一個資源

增加Cache-Control頭域支持可擴展的指令集

帶寬優(yōu)化：允許請求資源的某部分，而不是整個資源

長連接

HTTP/1.0只支持瀏覽器與服務(wù)器保持短暫的連接，瀏覽器的每次請求都要建立一個新的連接。

而HTTP/1.1允許在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)。HTTP/1.1協(xié)議的持續(xù)連接有兩種方式，即非流水線方式和流水線方式。

非流水線方式的特點是，客戶在收到前一個響應(yīng)后才能發(fā)出下一個請求；

流水線方式的特點是，客戶在收到HTTP的響應(yīng)報文之前就能接著發(fā)送新的請求報文

2.5 Cookie與Session的區(qū)別

存取方式的不同

Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二進制數(shù)據(jù)，需求先進行編碼。Cookie中也不能直接存取Java對象。若要存儲略微復(fù)雜的信息，運用Cookie是比較艱難的。

Session中能夠存取任何類型的數(shù)據(jù)，包括而不限于String、Integer、List、Map等。Session中也能夠直接保管Java Bean乃至任何Java類，對象等，運用起來十分便當。能夠把Session看做是一個Java容器類。

隱私策略的不同

Cookie存儲在客戶端閱讀器中，對客戶端是可見的，客戶端的一些程序可能會窺探、復(fù)制以至修正Cookie中的內(nèi)容。

Session存儲在服務(wù)器上，對客戶端是透明的，不存在敏感信息泄露的風險。

有效期上的不同

Cookie的過期時間指定

Session依賴于名為JSESSIONID的Cookie，而Cookie JSESSIONID的過期時間默許為–1，只需關(guān)閉了瀏覽器該Session就會失效，因而Session不能完成信息永世有效的效果。

服務(wù)器壓力的不同

Cookie保管在客戶端，不占用服務(wù)器資源。假如并發(fā)閱讀的用戶十分多，Cookie是很好的選擇。關(guān)于Google、Baidu、Sina來說，Cookie或許是唯一的選擇。

Session是保管在服務(wù)器端的，每個用戶都會產(chǎn)生一個Session。假如并發(fā)訪問的用戶十分多，會產(chǎn)生十分多的Session，耗費大量的內(nèi)存。因而像Google、Baidu、Sina這樣并發(fā)訪問量極高的網(wǎng)站，是不太可能運用Session來追蹤客戶會話的。

瀏覽器支持的不同

Cookie是需要客戶端瀏覽器支持的。

假如客戶端瀏覽器不支持Cookie，需要運用Session以及URL地址重寫。

跨域支持上的不同

Cookie支持跨域名訪問，例如將domain屬性設(shè)置為“.biaodianfu.com”，則以“.biaodianfu.com”為后綴的一切域名均能夠訪問該Cookie?？缬蛎鸆ookie如今被普遍用在網(wǎng)絡(luò)中，例如Google、Baidu、Sina等。

Session則不會支持跨域名訪問。Session僅在他所在的域名內(nèi)有效。

2.6 電腦訪問網(wǎng)頁的過程

用到的協(xié)議：DNS、HTTP、OSPF、IP、ARP

過程描述

DNS把域名解析成對應(yīng)的IP

發(fā)送一次請求，服務(wù)器返回一個永久重定向響應(yīng)，這樣瀏覽器就知道要訪問的正確網(wǎng)址

發(fā)送請求html的請求，這個連接過程基于TCP/IP三次握手四次揮手的，建立連接

服務(wù)器返回一個html響應(yīng)

瀏覽器根據(jù)渲染引擎解析返回的html響應(yīng)，呈現(xiàn)內(nèi)容

繼續(xù)發(fā)送內(nèi)嵌在html文件其他資源的請求，比如css、js、圖片資源等

加載整個頁面

2.7 Ping

同網(wǎng)段

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

交換機收到這個ARP后，會檢查在交換機中是否包含B的MAC地址，如果有就直接返回給A；如果沒有就向所有端口發(fā)送ARP，該網(wǎng)段的主機的MAC如果與B的MAC地址不同就丟棄，如果主機B收到了該ARP就馬上返回相同格式的ARP

這時主機A已經(jīng)有了B的MAC地址，就把B的MAC地址封裝到ICMP報中，向主機B發(fā)送一個回顯請求

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

不同網(wǎng)段

主機A要去Ping一個不同網(wǎng)段的主機C，主機A會去找網(wǎng)關(guān)轉(zhuǎn)發(fā)

如果主機A不知道網(wǎng)關(guān)的MAC地址，就會發(fā)送一個ARP廣播一下，這樣就知道了網(wǎng)關(guān)的MAC地址

網(wǎng)關(guān)收到主機A的ICMP報文，根據(jù)上面的目的IP，會去查找路由表，找到一個出口指針，給主機C發(fā)送一個ICMP報文

如果網(wǎng)關(guān)不知道主機C的MAC地址，就會給網(wǎng)關(guān)內(nèi)所有的主機發(fā)送一個ARP，從而找到主機C的MAC地址

主機C收到主機A的報文就會給主機A發(fā)送一個回顯請求。這樣就完成了不同網(wǎng)段的Ping的請求

2.8 路由器與交換機的區(qū)別

路由器包含了交換機的功能，交換機主要的作用是擴展接口

2.9 確認訪問用戶身份的認證

basic認證

digest認證

ssl客戶端認證

基于表單認證

認證多半為基于表單認證

session管理及cookie應(yīng)用

2.10 websocket

全雙工通信

特點

推送功能：支持服務(wù)器向客戶端推送數(shù)據(jù)的推送功能

減少通信量：一直保持連接

HTTP連接建立后，需要完成一次握手動作

握手---請求：用到HTTP的upgrade字段告知服務(wù)器通信協(xié)議發(fā)生變化

握手---響應(yīng)：對于之前的請求返回狀態(tài)碼101 switching protocols

成功握手確立WebSocket連接之后，通信不再使用HTTP的數(shù)據(jù)幀，而采用WebSocket獨立的數(shù)據(jù)幀

3.1 HTTP缺點

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

解決方式

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

內(nèi)容加密

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

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

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

數(shù)字簽名，MD5并不可靠，應(yīng)用HTTPS

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

3.3 HTTPS是身披SSL外殼的HTTP

3.4 HTTP采用混合加密機制

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

3.6 SSL協(xié)議

慢

通信慢

由于大量消耗CPU及內(nèi)存等資源，導(dǎo)致處理速度變慢

SSL必須進行加密處理

4.1 傳輸層

4.2 作用

提供可靠的字節(jié)流服務(wù)

4.3 大塊數(shù)據(jù)分割成報文段(segment)

4.4 三次握手

發(fā)送端發(fā)帶SYN標志的數(shù)據(jù)包給對方。

接收端收到后，回傳一個帶有SYN/ACK標志的數(shù)據(jù)包以示傳達確認信息。

最后，發(fā)送端再回傳一個帶ACK標志的數(shù)據(jù)包，代表“握手”結(jié)束

握手某個階段中斷，TCP會以相同的順序發(fā)送相同的數(shù)據(jù)包

4.5 四次揮手

客戶端A發(fā)送一個FIN，用來關(guān)閉客戶A到服務(wù)器B的數(shù)據(jù)傳送。

服務(wù)器B收到這個FIN，它發(fā)回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將占用一個序號。

服務(wù)器B關(guān)閉與客戶端A的連接，發(fā)送一個FIN給客戶端A。

客戶端A發(fā)回ACK報文確認，并將確認序號設(shè)置為收到序號加1。

4.6 流量控制

TCP接收端對發(fā)送端發(fā)送多少字節(jié)的數(shù)據(jù)進行控制，防止接收端處理不及而丟失數(shù)據(jù)

發(fā)送窗口的大小是受到接收窗口的控制的。

發(fā)送窗口必須根據(jù)接收端的大小及時調(diào)整發(fā)送窗口的大小，這個機制保證了每次TCP傳輸?shù)臄?shù)據(jù)量都是接收端可以及時處理的。

4.7 差錯控制

保證接收端接收的數(shù)據(jù)是完整未受損傷的，是可靠性的重要保證。

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

4.8 擁塞控制

擁塞窗口

發(fā)送方的窗口大小是接收窗口與擁塞窗口中的較小值。

擁塞窗口的大小又取決于網(wǎng)絡(luò)的擁塞狀況。

擁塞策略

慢開始

擁塞避免

擁塞檢測

擁塞控制流程

由于剛開始不清楚網(wǎng)絡(luò)的擁塞情況，所以會首先采用慢開始算法，開始階段，窗口大小由1指數(shù)增大，直到窗口大小到達門限值。

窗口大小到達門限值后，就開始執(zhí)行擁塞避免算法，之后窗口值按照線性規(guī)律增大，直到出現(xiàn)超時或者到達最大的窗口大小值。

這個時候，會開始執(zhí)行擁塞檢測算法，也就是把門限值變?yōu)榇翱诖笮〉囊话?，之后繼續(xù)執(zhí)行擁塞避免算法，窗口大小按照線性規(guī)律增大。

5.1 網(wǎng)絡(luò)層

5.2 作用

把數(shù)據(jù)包傳送給對方

5.3 條件

IP地址和MAC地址

5.4 使用ARP協(xié)議憑借MAC地址進行通信

5.5 路由選擇

6.1 協(xié)議族

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

6.2 分層管理

應(yīng)用層

決定向用戶提供應(yīng)用服務(wù)時通信的活動。FTP、HTTP、DNS

傳輸層

對上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺計算機之間的數(shù)據(jù)傳輸。TCP、UDP

網(wǎng)絡(luò)層

處理網(wǎng)絡(luò)上流動的數(shù)據(jù)包

規(guī)定了通過怎樣的路徑到達對方計算機，并把數(shù)據(jù)包傳送給對方

數(shù)據(jù)鏈路層

處理連接網(wǎng)絡(luò)的硬件部分

6.3 通信傳輸流

發(fā)送端層與層之間傳輸數(shù)據(jù)，每經(jīng)過一層時必定會被打上一個該層所屬的首部信息

接收端在層與層傳輸數(shù)據(jù)時，每經(jīng)過一層時會把對應(yīng)的首部消去。

這種把數(shù)據(jù)信息包裝起來的做法稱為封裝

7.1 因輸出值轉(zhuǎn)移不完全引發(fā)的安全漏洞

跨站腳本攻擊XSS

SQL注入攻擊

OS命令注入攻擊

HTTP首部注入攻擊

郵件首部注入攻擊

目錄遍歷攻擊

遠程文件包含漏洞

7.2 因設(shè)置或設(shè)計上的缺陷引發(fā)的安全漏洞

強制瀏覽

不正確的錯誤消息處理

開放重定向

7.3 因會話管理疏忽引發(fā)的安全漏洞

會話劫持

會話固定攻擊

跨站點請求偽造(CSRF)

7.4 其他安全漏洞

密碼破解

點擊劫持

dos攻擊

后門程序

8.1 IGMP協(xié)議

組管理協(xié)議，它幫助多播路由器創(chuàng)建以及更新與每一個路由接口相連的忠實成員列表（就是與該路由接口連接頻率較高）。

8.2 ICMP協(xié)議

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

8.3 ARP協(xié)議

地址映射協(xié)議，可以把一個IP地址映射為MAC地址。

把IP數(shù)據(jù)報封裝成幀（以太網(wǎng)上對01串的分組定義）后才能通過物理網(wǎng)絡(luò)，這時就需要目的主機的MAC地址