摘要：今天總結(jié)下與網(wǎng)絡(luò)相關(guān)的知識(shí)，不是那么詳細(xì)，但是包含了我認(rèn)為重要的所有點(diǎn)。概要網(wǎng)絡(luò)知識(shí)我做了個(gè)方面的總結(jié)，包括協(xié)議，協(xié)議，協(xié)議，協(xié)議，協(xié)議，，攻擊，其他協(xié)議。跨域名如今被普遍用在網(wǎng)絡(luò)中，例如等。擁塞窗口的大小又取決于網(wǎng)絡(luò)的擁塞狀況。

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

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

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

作用：提供域名到IP地址之間的解析服務(wù)。或逆向從IP地址反查域名的服務(wù)

2.1 特點(diǎn)

無狀態(tài)

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

HTTP方法

GET：獲取資源

POST:傳輸實(shí)體主體

PUT：傳輸文件

HEAD：獲得報(bào)文首部

DELETE：刪除文件

OPTIONS：詢問支持的方法

TRACE：追蹤路徑

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

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

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

2.2 HTTP 報(bào)文

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

請求報(bào)文

報(bào)文首部

請求行

請求首部字段

通用首部字段

實(shí)體首部字段

其他

空行

報(bào)文主體

響應(yīng)報(bào)文

報(bào)文首部

狀態(tài)行

響應(yīng)首部字段

通用首部字段

實(shí)體首部字段

其他

空行

報(bào)文主體

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

MIME

multipart/form-data

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

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

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

透明協(xié)商

2.3 HTTP狀態(tài)碼

1XX：接收的請求正在處理

2XX：請求正常處理完畢

200 OK

204 NoContent

206 Partial Content

3XX：需要進(jìn)行附加操作以完成請求

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ù)器處理請求出錯(cuò)

500 Internal Server Error

503 Service Unavailable

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

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

緩存

增加對緩存的重激活機(jī)制：使用ETag頭域描述一個(gè)資源

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

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

長連接

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

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

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

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

2.5 Cookie與Session的區(qū)別

存取方式的不同

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

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

隱私策略的不同

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

Session存儲(chǔ)在服務(wù)器上，對客戶端是透明的，不存在敏感信息泄露的風(fēng)險(xiǎn)。

有效期上的不同

Cookie的過期時(shí)間指定

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

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

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

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

瀏覽器支持的不同

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

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

跨域支持上的不同

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

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

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

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

過程描述

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

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

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

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

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

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

加載整個(gè)頁面

2.7 Ping

同網(wǎng)段

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

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

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

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

不同網(wǎng)段

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

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

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

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

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

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

路由器包含了交換機(jī)的功能，交換機(jī)主要的作用是擴(kuò)展接口

2.9 確認(rèn)訪問用戶身份的認(rèn)證

basic認(rèn)證

digest認(rèn)證

ssl客戶端認(rèn)證

基于表單認(rèn)證

認(rèn)證多半為基于表單認(rèn)證

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

2.10 websocket

全雙工通信

特點(diǎn)

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

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

HTTP連接建立后，需要完成一次握手動(dòng)作

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

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

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

3.1 HTTP缺點(diǎn)

通信使用明文可能會(huì)被竊聽

解決方式

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

內(nèi)容加密

不驗(yàn)證通信方身份就可能遭遇偽裝

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

無法證明報(bào)文完整性，可能已遭篡改

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

3.2 HTTP+加密+認(rèn)證+完整性保護(hù)=HTTPS

3.3 HTTPS是身披SSL外殼的HTTP

3.4 HTTP采用混合加密機(jī)制

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

3.6 SSL協(xié)議

慢

通信慢

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

SSL必須進(jìn)行加密處理

4.1 傳輸層

4.2 作用

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

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

4.4 三次握手

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

接收端收到后，回傳一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息。

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

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

4.5 四次揮手

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

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

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

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

4.6 流量控制

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

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

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

4.7 差錯(cuò)控制

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

主要使用校驗(yàn)和、確認(rèn)、超時(shí)重傳這三個(gè)工具進(jìn)行差錯(cuò)控制。

4.8 擁塞控制

擁塞窗口

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

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

擁塞策略

慢開始

擁塞避免

擁塞檢測

擁塞控制流程

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

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

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

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

5.2 作用

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

5.3 條件

IP地址和MAC地址

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

5.5 路由選擇

6.1 協(xié)議族

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

6.2 分層管理

應(yīng)用層

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

傳輸層

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

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

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

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

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

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

6.3 通信傳輸流

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

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

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

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

跨站腳本攻擊XSS

SQL注入攻擊

OS命令注入攻擊

HTTP首部注入攻擊

郵件首部注入攻擊

目錄遍歷攻擊

遠(yuǎn)程文件包含漏洞

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

強(qiáng)制瀏覽

不正確的錯(cuò)誤消息處理

開放重定向

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

會(huì)話劫持

會(huì)話固定攻擊

跨站點(diǎn)請求偽造(CSRF)

7.4 其他安全漏洞

密碼破解

點(diǎn)擊劫持

dos攻擊

后門程序

8.1 IGMP協(xié)議

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

8.2 ICMP協(xié)議

差錯(cuò)控制協(xié)議，彌補(bǔ)了IP協(xié)議沒有差錯(cuò)糾正機(jī)制以及差錯(cuò)報(bào)告的缺憾。

8.3 ARP協(xié)議

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

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