前言
如果沒(méi)有體系化的認(rèn)知，了解的信息越多也就越迷茫！如果對(duì)本質(zhì)的認(rèn)知就是錯(cuò)的，了解的信息越多偏差也就越大！信息絕對(duì)不等于認(rèn)知，互聯(lián)網(wǎng)碎片化信息究竟有多少價(jià)值需要認(rèn)真篩選
之前就想了解一下關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)方面的知識(shí)，網(wǎng)上搜來(lái)搜去就是那兩本書，一本是《HTTP權(quán)威指南》，這本書的厚度快趕上新華字典了；另一本是《TCP/IP講解，卷1》，看完之后，我就呵呵了！
最近看了上野宣（日本作家）寫的《圖解HTTP》，打算把書中的知識(shí)點(diǎn)簡(jiǎn)單的歸類總結(jié)一下，或者叫摘抄一下更為合理，方便自己后期復(fù)習(xí)。本來(lái)自己是搞移動(dòng)端的，可漸漸發(fā)現(xiàn)了瓶頸，如果想要在專業(yè)技術(shù)的道路上走的踏實(shí)，還是繞不開HTTP協(xié)議，繞不開更加系統(tǒng)和低層的計(jì)算機(jī)知識(shí)，大學(xué)的時(shí)候總覺(jué)得自己學(xué)的東西都太理論化，根本應(yīng)付不了實(shí)際的項(xiàng)目工程，最近的感觸卻完全相反，理論是可以指導(dǎo)實(shí)踐的，試想：如果大學(xué)也開通了廚師專業(yè)，大學(xué)肯定要從廚師的階級(jí)屬性、社會(huì)使命學(xué)起，甚至還要兼顧這個(gè)職業(yè)的歷史演變等，學(xué)的時(shí)候枯燥無(wú)味，感覺(jué)這跟新東方開學(xué)就給你發(fā)兩把菜刀直接顛勺的教學(xué)效率肯定不能比，現(xiàn)在想想感覺(jué)還是太嫩了，給自己不學(xué)習(xí)找理由已經(jīng)到了不惜要自暴自棄的地步了，加之社會(huì)總有說(shuō)大學(xué)生不如XX之類的新聞，搞得自己更是自行慚穢.....
算了，不扯了，直接上干貨吧，技多不壓身~
第一章 了解Web及網(wǎng)絡(luò)基礎(chǔ)
1.1 網(wǎng)絡(luò)基礎(chǔ) TCP/IP
TCP/IP協(xié)議族里可分為應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)層。
應(yīng)用層
應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)。TCP/IP協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)。比如FTP（File Transfer Protocol，文件傳輸協(xié)議）和DNS（Domain Name Sysytem，域名系統(tǒng)），HTTP協(xié)議也處于該層。
傳輸層
傳輸層對(duì)上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳輸。在傳輸層有兩個(gè)性質(zhì)不同的協(xié)議：TCP（Transmission Control Protocol，傳輸控制協(xié)議）和UDP（User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）。
網(wǎng)絡(luò)層
網(wǎng)絡(luò)層用來(lái)處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位，該層規(guī)定了通過(guò)怎樣的路徑（所謂的傳輸路線）到達(dá)對(duì)方計(jì)算機(jī)，比把數(shù)據(jù)包傳送給對(duì)方。
鏈路層（又名數(shù)據(jù)鏈路層，網(wǎng)絡(luò)接口層）
用來(lái)處理鏈接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū)動(dòng)、NIC（Network Interface Card，網(wǎng)絡(luò)適配器，即網(wǎng)卡），及光纖等物理可見(jiàn)的部分。
1.2 發(fā)送HTTP大體流程
1、客戶端在應(yīng)用層（HTTP協(xié)議）發(fā)出一個(gè)想看某個(gè)Web頁(yè)面的HTTP請(qǐng)求；
2、為了傳輸方便，在傳輸層（TCP協(xié)議）把從應(yīng)用層收到的數(shù)據(jù)（HTTP請(qǐng)求報(bào)文）進(jìn)行分割，并在各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層；
3、在網(wǎng)絡(luò)層（IP協(xié)議，Internet Protocol），增加作為通信目的地的MAC地址后轉(zhuǎn)發(fā)給鏈路層。這樣一來(lái)，發(fā)往網(wǎng)絡(luò)的通信請(qǐng)求就準(zhǔn)備齊全了；
4、接收端的服務(wù)器在鏈路層收到數(shù)據(jù)，按序往上層發(fā)送，一直到應(yīng)用層。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過(guò)來(lái)的HTTP請(qǐng)求。
1.3 與HTTP關(guān)系密切的協(xié)議：IP、TCP和DNS
負(fù)責(zé)傳輸?shù)腎P協(xié)議
按層次分，IP（Internet Protocol）網(wǎng)際協(xié)議位于網(wǎng)絡(luò)層，IP協(xié)議的作用是把各種數(shù)據(jù)包傳送給對(duì)方。而要保證確實(shí)傳送到對(duì)方那里，則需要滿足各類條件，其中兩個(gè)重要的條件是IP地址和MAC地址（Media Access Control Address）。
IP地址和MAC地址： 指明了節(jié)點(diǎn)被分配到的地址，MAC地址是指網(wǎng)卡所屬的固定地址，IP地址可以和MAC地址進(jìn)行配對(duì)。IP地址可變換，但MAC地址基本上不會(huì)更改。
使用ARP協(xié)議憑借MAC地址進(jìn)行通信
IP間的通信依賴MAC地址。在網(wǎng)路上通信雙方在同一局域網(wǎng)內(nèi)的情況很少，一般是經(jīng)過(guò)多臺(tái)計(jì)算機(jī)和網(wǎng)絡(luò)設(shè)備中轉(zhuǎn)才能連接到對(duì)方。而在進(jìn)行中轉(zhuǎn)時(shí)，會(huì)采用ARP協(xié)議（Address Resolution Protocol）。ARP是一種用以解釋地址的協(xié)議，根據(jù)通信方的IP地址就可以反查出對(duì)應(yīng)方的MAC地址。
確?？煽啃缘腡CP協(xié)議
按層次分，TCP位于傳輸層，提供可靠的字節(jié)流服務(wù)。所謂字節(jié)流服務(wù)是指為了方便傳輸，將大塊數(shù)據(jù)分割成以報(bào)文段為單位的數(shù)據(jù)包進(jìn)行管理。TCP協(xié)議為了更容易傳送大數(shù)據(jù)才把數(shù)據(jù)分割，而且TCP協(xié)議能夠確認(rèn)數(shù)據(jù)最終是否送達(dá)到對(duì)方。
TCP的三次握手：確保數(shù)據(jù)能到達(dá)目標(biāo)
1、發(fā)送端首先發(fā)送一個(gè)帶SYN（synchronize）標(biāo)志的數(shù)據(jù)包給對(duì)方；
2、接受端收到后，回傳一個(gè)帶有SYN/ACK（acknowledgement）標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)消息；
3、最后，發(fā)送端再回傳一個(gè)帶ACK標(biāo)志的數(shù)據(jù)包，代表“握手??”結(jié)束。
負(fù)責(zé)域名解析的DNS服務(wù)
DNS（Domain Name System）服務(wù)是和HTTP協(xié)議一樣位于應(yīng)用層的協(xié)議，他提供域名到IP地址之間的解析服務(wù)。例如把www.hackr.jp解析成對(duì)應(yīng)的IP地址20X.189.105.112
第二章 簡(jiǎn)單的HTTP協(xié)議
請(qǐng)求報(bào)文是由請(qǐng)求方法、請(qǐng)求URI（統(tǒng)一資源標(biāo)識(shí)符，URL：統(tǒng)一資源定位符）、協(xié)議版本、可選的請(qǐng)求收不字段和內(nèi)容實(shí)體構(gòu)成。
2.3 HTTP是不保存狀態(tài)的協(xié)議
HTTP是一種不保存狀態(tài)，即無(wú)狀態(tài)協(xié)議。HTTP協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存，不做持久化處理。所以為了保存狀態(tài)引入了cookie技術(shù)，后面細(xì)講。
2.4 告知服務(wù)器意圖的HTTP方法
1、GET：獲取資源；
2、POST：傳輸實(shí)體主體
3、PUT：傳輸文件
4、HEAD：獲得報(bào)文首部，告知通信狀態(tài)
5、DELETE：刪除文件
6、OPTIONS：詢問(wèn)支持的方法
7、TRACE：追蹤路徑
2.5 使用Cookie的狀態(tài)管理
Cookie會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie，當(dāng)下次客戶端再往該服務(wù)器發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入Cookie值后發(fā)送出去。服務(wù)器端根據(jù)客戶端發(fā)過(guò)來(lái)的cookie對(duì)比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。即：
- 1、請(qǐng)求報(bào)文（沒(méi)有Cookie信息的狀態(tài)）；
- 2、響應(yīng)報(bào)文（服務(wù)端生成Cookie信息）；
- 3、請(qǐng)求報(bào)文（自動(dòng)發(fā)送保存著的Cookie信息）。
web網(wǎng)站為了管理用戶的狀態(tài)會(huì)通過(guò)web瀏覽器，把一些數(shù)據(jù)臨時(shí)寫入用戶的計(jì)算機(jī)內(nèi)，接著當(dāng)用戶訪問(wèn)該web網(wǎng)站時(shí)，可通過(guò)通信方式取回之間發(fā)放的cookie；
Cookie屬性
第三章 返回結(jié)果的HTTP狀態(tài)碼以及Host
狀態(tài)碼
Host
第四章 確保Web安全的HTTPS
HTTP的缺點(diǎn)：
- 通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽(tīng)；
- 不驗(yàn)證通信方的身份，因此有可能遭遇偽裝；
- 無(wú)法證明報(bào)文的完整性，所以有可能已遭到篡改。
HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS
- 1、客戶端通過(guò)發(fā)送Client Hello報(bào)文開始SSL通信，報(bào)文中包含客戶端支持的SSL的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長(zhǎng)度等）；
- 2、服務(wù)器可進(jìn)行SSL通信時(shí)，會(huì)以Server Hello報(bào)文作為應(yīng)答，和客戶端一樣，在報(bào)文中包含SSL版本及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來(lái)的；
- 3、之后服務(wù)器發(fā)送Certificate報(bào)文，報(bào)文中包含公開密鑰證書；
- 4、最后服務(wù)器發(fā)送Server Hello Done報(bào)文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束；
- 5、SSL第一次握手結(jié)束后，客戶端以Client Key Exchange報(bào)文作為應(yīng)答，報(bào)文中包含通信加密中使用的一種被稱為Pre-mastersecret的隨機(jī)密碼串，該報(bào)文已用步驟3中的公開密鑰進(jìn)行加密；
- 6、接著客戶端繼續(xù)發(fā)送Change Cipher Spec報(bào)文，該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用Pre-master secret密鑰進(jìn)行加密；
- 7、客戶端發(fā)送Finished報(bào)文，該報(bào)文包含鏈接至今全部報(bào)文的整體校驗(yàn)值，這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn)；
- 8、服務(wù)器同樣發(fā)送Change Cipher Spec報(bào)文；
- 9、服務(wù)器同樣發(fā)送Finished報(bào)文；
- 10、服務(wù)器和客戶端的Finshed報(bào)文交換完畢后，SSL連接就算建立完成。當(dāng)然，通信會(huì)受到SSL的保護(hù)，從此處開始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP請(qǐng)求；
- 11、應(yīng)用層協(xié)議通信，即發(fā)送HTTP響應(yīng)；
- 12、最后由客戶端斷開連接，斷開連接時(shí)，發(fā)送close_notify報(bào)文，上圖做了一些省略，這步之后再發(fā)送TCP FIN報(bào)文來(lái)關(guān)閉與TCP的通信；
