TCP/IP協(xié)議族
TCP/IP 的分層管理
TCP/IP 協(xié)議族里重要的一點就是分層为肮。TCP/IP 協(xié)議族按層次分別分為以下 4 層：應(yīng)用層唁桩、傳輸層涛碑、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層渊鞋。分層的好處:各層之間的接口部分規(guī)劃好之后，每個層次內(nèi)部的設(shè)計就能夠自由改動了类早。
應(yīng)用層：應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時通信的活動媚媒。
TCP/IP 協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)嗜逻。比如涩僻，F(xiàn)TP（File Transfer Protocol，文件傳輸協(xié)議）和 DNS（Domain Name System，域名系統(tǒng)）服務(wù)就是其中兩類逆日。HTTP 協(xié)議也處于該層嵌巷。
傳輸層：傳輸層對上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺計算機之間的數(shù)據(jù)傳輸室抽。
在傳輸層有兩個性質(zhì)不同的協(xié)議：TCP（Transmission Control Protocol搪哪，傳輸控制協(xié)議）和 UDP（User Data Protocol，用戶數(shù)據(jù)報協(xié)議）坪圾。
網(wǎng)絡(luò)層：（又名網(wǎng)絡(luò)互連層）網(wǎng)絡(luò)層用來處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包晓折。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過怎樣的路徑（所謂的傳輸路線）到達對方計算機兽泄，并把數(shù)據(jù)包傳送給對方漓概。
與對方計算機之間通過多臺計算機或網(wǎng)絡(luò)設(shè)備進行傳輸時，網(wǎng)絡(luò)層所起的作用就是在眾多的選項內(nèi)選擇一條傳輸路線病梢。
鏈路層（又名數(shù)據(jù)鏈路層胃珍，網(wǎng)絡(luò)接口層）：
用來處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)蜓陌、硬件的設(shè)備驅(qū)動觅彰、NIC（Network Interface Card，網(wǎng)絡(luò)適配器钮热，即網(wǎng)卡）填抬，及光纖等物理可見部分（還包括連接器等一切傳輸媒介）。硬件上的范疇均在鏈路層的作用范圍之內(nèi)隧期。
TCP/IP 通信傳輸流
利用 TCP/IP 協(xié)議族進行網(wǎng)絡(luò)通信時痴奏，會通過分層順序與對方進行通信。發(fā)送端從應(yīng)用層往下走厌秒，接收端則往應(yīng)用層往上走读拆。如下以HTTP為例：
1.首先作為發(fā)送端的客戶端在應(yīng)用層（HTTP 協(xié)議）發(fā)出一個想看某個 Web 頁面的 HTTP 請求。
2.為了傳輸方便鸵闪，在傳輸層（TCP 協(xié)議）把從應(yīng)用層處收到的數(shù)據(jù)（HTTP 請求報文）進行分割檐晕，并在各個報文上打上標記序號及端口號后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。
3.在網(wǎng)絡(luò)層（IP 協(xié)議）蚌讼，增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層辟灰。這樣一來，發(fā)往網(wǎng)絡(luò)的通信請求就準備齊全了篡石。
4.接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)芥喇，按序往上層發(fā)送，一直到應(yīng)用層凰萨。當(dāng)傳輸?shù)綉?yīng)用層继控，才能算真正接收到由客戶端發(fā)送過來的 HTTP請求械馆。
發(fā)送端在層與層之間傳輸數(shù)據(jù)時，每經(jīng)過一層時必定會被打上一個該層所屬的首部信息武通。反之霹崎，接收端在層與層傳輸數(shù)據(jù)時，每經(jīng)過一層時會把對應(yīng)的首部消去冶忱。這種把數(shù)據(jù)信息包裝起來的做法稱為封裝（encapsulate）尾菇。
TCP三次握手
HTTP持久鏈接
為解決上述 TCP 連接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接（HTTP Persistent Connections囚枪，也稱為 HTTP keep-alive 或HTTP connection reuse）的方法派诬。持久連接的特點是，只要任意一端沒有明確提出斷開連接链沼，則保持 TCP 連接狀態(tài)千埃。
HTTP管線化
管線化技術(shù)出現(xiàn)后，不用等待響應(yīng)亦可直接發(fā)送下一個請求忆植。
這樣就能夠做到同時并行發(fā)送多個請求放可，而不需要一個接一個地等待響應(yīng)了。
與挨個連接相比朝刊，用持久連接可以讓請求更快結(jié)束耀里。而管線化技術(shù)則比持久連接還要快。請求數(shù)越多拾氓，時間差就越明顯冯挎。
使用Cookie的狀態(tài)管理
保留無狀態(tài)協(xié)議這個特征的同時又要解決類似的矛盾問題，于是引入了 Cookie 技術(shù)咙鞍。Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入 Cookie 信息來控制客戶端的狀態(tài)房官。
Cookie 會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie续滋。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時翰守，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出去。
服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后疲酌，會去檢查究竟是從哪一個客戶端發(fā)來的連接請求蜡峰，然后對比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息朗恳。
1.請求報文（沒有 Cookie 信息的狀態(tài)）
GET /reader/ HTTP/1.1
Host: hackr.jp
*首部字段內(nèi)沒有Cookie的相關(guān)信息
2. 響應(yīng)報文（服務(wù)器端生成 Cookie 信息）
HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed,
10-Oct-12 07:12:20 GMT＞
Content-Type: text/plain; charset=UTF-8
3. 請求報文（自動發(fā)送保存著的 Cookie 信息）
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724
為 Cookie 服務(wù)的首部字段
Cookie 的工作機制是用戶識別及狀態(tài)管理湿颅。Web 網(wǎng)站為了管理用戶的狀態(tài)會通過 Web 瀏覽器，把一些數(shù)據(jù)臨時寫入用戶的計算機內(nèi)粥诫。接著當(dāng)用戶訪問該Web網(wǎng)站時油航，可通過通信方式取回之前發(fā)放的Cookie。
Set-Cookie
當(dāng)服務(wù)器準備開始管理客戶端的狀態(tài)時怀浆，會事先告知各種信息谊囚。下面的表格列舉了 Set-Cookie 的字段值怕享。
注：Cookie 的 secure 屬性用于限制 Web 頁面僅在 HTTPS 安全連接時，才可以發(fā)送 Cookie秒啦。發(fā)送 Cookie 時，指定 secure 屬性的方法（Set-Cookie: name=value; secure）搀玖，以上例子僅當(dāng)https://www.example.com/（HTTPS）安全連接的情況下才會進行 Cookie 的回收余境。也就是說，即使域名相同灌诅， http://www.example.com/（HTTP）也不會發(fā)生 Cookie 回收行為芳来。當(dāng)省略 secure 屬性時，不論 HTTP 還是HTTPS猜拾，都會對 Cookie 進行回收即舌。
狀態(tài)碼
HTTP支持的方法
HTTP的缺點
- 通信使用明文（不加密），內(nèi)容可能會被竊聽
- 不驗證通信方的身份挎袜，因此有可能遭遇偽裝
- 無法證明報文的完整性顽聂，所以有可能已遭篡改
HTTPS（HTTP+ 加密 + 認證 + 完整性保護=HTTPS）
HTTP 協(xié)議中沒有加密機制，但可以通過和 SSL（Secure Socket Layer盯仪，安全套接層）或TLS（Transport Layer Security紊搪，安全層傳輸協(xié)議）的組合使用，加密 HTTP 的通信內(nèi)容全景。
用 SSL建立安全通信線路之后耀石，就可以在這條線路上進行 HTTP通信了。與 SSL組合使用的 HTTP 被稱為 HTTPS（HTTPSecure爸黄，超文本傳輸安全協(xié)議）或 HTTP over SSL滞伟。
HTTPS 并非是應(yīng)用層的一種新協(xié)議。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協(xié)議代替而已炕贵。
通常梆奈，HTTP 直接和 TCP 通信。當(dāng)使用 SSL時称开，則演變成先和 SSL通信鉴裹，再由 SSL和 TCP 通信了。簡言之钥弯，所謂 HTTPS径荔，其實就是身披SSL協(xié)議這層外殼的 HTTP。
SSL是獨立于 HTTP 的協(xié)議脆霎，所以不光是 HTTP 協(xié)議总处，其他運行在應(yīng)用層的 SMTP 和 Telnet 等協(xié)議均可配合 SSL協(xié)議使用【χ耄可以說 SSL是當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)鹦马。
查明對手證書
雖然使用 HTTP 協(xié)議無法確定通信方胧谈，但如果使用 SSL則可以。SSL不僅提供加密處理荸频，而且還使用了一種被稱為證書的手段菱肖，可用于確定方。
證書由值得信任的第三方機構(gòu)頒發(fā)旭从，用以證明服務(wù)器和客戶端是實際存在的稳强。另外，偽造證書從技術(shù)角度來說是異常困難的一件事和悦。所以只要能夠確認通信方（服務(wù)器或客戶端）持有的證書退疫，即可判斷通信方的真實意圖。
加密方法
SSL采用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式（非對稱加密）鸽素。
近代的加密方法中加密算法是公開的褒繁，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性馍忽。
加密和解密都會用到密鑰棒坏。沒有密鑰就無法對密碼解密，反過來說遭笋，任何人只要持有密鑰就能解密了俊抵。如果密鑰被攻擊者獲得，那加密也就失去了意義坐梯。
對稱秘鑰加密
加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common keycrypto system）徽诲，也被叫做對稱密鑰加密。
以共享密鑰方式加密時必須將密鑰也發(fā)給對方吵血』烟妫可究竟怎樣才能安全地轉(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時蹋辅，如果通信被監(jiān)聽那么密鑰就可會落入攻擊者之手辛萍，同時也就失去了加密的意義酿傍。另外還得設(shè)法安全地保管接收到的密鑰鳖谈。
非對稱加密（公開秘鑰加密）
公開密鑰加密使用一對非對稱的密鑰军俊。一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key）褒傅。顧名思義弃锐，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發(fā)布殿托，任何人都可以獲得霹菊。公鑰加密，私鑰解密
使用公開密鑰加密方式支竹，發(fā)送密文的一方使用對方的公開密鑰進行加密處理旋廷，對方收到被加密的信息后鸠按，再使用自己的私有密鑰進行解密。利用這種方式饶碘，不需要發(fā)送用來解密的私有密鑰目尖，也不必擔(dān)心密鑰被攻擊者竊聽而盜走。以目前的技術(shù)扎运，想要用公鑰進行解密是異常困難瑟曲，就目前的技術(shù)是不太現(xiàn)實的
混合加密機制（對稱加密與非對稱加密結(jié)合的方式）
非對稱加密與對稱加密相比，處理速度要慢很多绪囱，所以采用混合加密的方式测蹲，在交換密鑰環(huán)節(jié)使用公開密鑰加密方式莹捡，之后的建立通信交換報文階段則使用共享密鑰加密方式鬼吵。
這其中其實還存在問題!那就是你如何證明公開沒要本身的真實性。因為在公開秘鑰傳輸?shù)倪^程中篮赢，可能真正的公開秘鑰已經(jīng)被攻擊者替換掉了齿椅。為了解決上述問題，可以使用由數(shù)字證書認證機構(gòu)（CA启泣，Certificate Authority）和其相關(guān)機關(guān)頒發(fā)的公開密鑰證書涣脚。
服務(wù)器會將這份由數(shù)字證書認證機構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端，以進行公開密鑰加密方式通信寥茫。公鑰證書也可叫做數(shù)字證書或直接稱為證書遣蚀。接到證書的客戶端可使用數(shù)字證書認證機構(gòu)的公開密鑰，對那張證書上的數(shù)字簽名進行驗證纱耻，一旦驗證通過芭梯，客戶端便可明確兩件事：一，認證服務(wù)器的公開密鑰的是真實有效的數(shù)字證書認證機構(gòu)弄喘。二玖喘，服務(wù)器的公開密鑰是值得信賴的。
此處認證機關(guān)的公開密鑰必須安全地轉(zhuǎn)交給客戶端蘑志。使用通信方式時累奈，如何安全轉(zhuǎn)交是一件很困難的事，因此急但，多數(shù)瀏覽器開發(fā)商發(fā)布版本時澎媒，會事先在內(nèi)部植入常用認證機關(guān)的公開密鑰。
HTTPS安全通信機制
步驟 1： 客戶端通過發(fā)送 Client Hello 報文開始 SSL通信波桩。報文中包含客戶端支持的 SSL的指定版本旱幼、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟 2： 服務(wù)器可進行 SSL通信時突委，會以 Server Hello 報文作為應(yīng)答柏卤。和客戶端一樣冬三，在報文中包含 SSL版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的缘缚。
步驟 3： 之后服務(wù)器發(fā)送 Certificate 報文勾笆。報文中包含公開密鑰證書。
步驟 4： 最后服務(wù)器發(fā)送 Server Hello Done 報文通知客戶端桥滨，最初階段的 SSL握手協(xié)商部分結(jié)束窝爪。
步驟 5： SSL第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報文作為回應(yīng)齐媒。報文中包含通信加密中使用的一種被稱為 Pre-mastersecret 的隨機密碼串蒲每。該報文已用步驟 3 中的公開密鑰進行加密。
步驟 6： 接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報文喻括。該報文會提示服務(wù)器邀杏，在此報文之后的通信會采用 Pre-master secret 密鑰加密。
步驟 7： 客戶端發(fā)送 Finished 報文唬血。該報文包含連接至今全部報文的整體校驗值望蜡。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報文作為判定標準拷恨。
步驟 8： 服務(wù)器同樣發(fā)送 Change Cipher Spec 報文脖律。
步驟 9： 服務(wù)器同樣發(fā)送 Finished 報文。
步驟 10： 服務(wù)器和客戶端的 Finished 報文交換完畢之后腕侄，SSL連接就算建立完成小泉。當(dāng)然，通信會受到 SSL的保護冕杠。從此處開始進行應(yīng)用層協(xié)議的通信微姊，即發(fā)送 HTTP 請求。
步驟 11： 應(yīng)用層協(xié)議通信拌汇，即發(fā)送 HTTP 響應(yīng)柒桑。
步驟 12： 最后由客戶端斷開連接。斷開連接時噪舀，發(fā)送 close_notify 報文魁淳。上圖做了一些省略，這步之后再發(fā)送 TCP FIN 報文來關(guān)閉與 TCP的通信与倡。
SSL 和 TLS
IETF 以 SSL3.0 為基準界逛，后又制定了 TLS1.0、TLS1.1 和TLS1.2纺座。TSL是以 SSL為原型開發(fā)的協(xié)議息拜，有時會統(tǒng)一稱該協(xié)議為 SSL。當(dāng)前主流的版本是 SSL3.0 和 TLS1.0。
SSL 速度慢嗎
SSL的慢分兩種少欺。一種是指通信慢喳瓣。另一種是指由于大量消耗CPU 及內(nèi)存等資源，導(dǎo)致處理速度變慢赞别。和使用 HTTP 相比畏陕，網(wǎng)絡(luò)負載可能會變慢 2 到 100 倍。針對速度變慢這一問題仿滔，并沒有根本性的解決方案惠毁！所以我們不是所有請求都是用HTTPS，如果是非敏感信息則使用 HTTP 通信崎页，只有在包含個人信息等敏感數(shù)據(jù)時鞠绰，才利用 HTTPS 加密通信。
下圖中說明了從僅使用服務(wù)器端的公開密鑰證書（服務(wù)器證書）建立 HTTPS 通信的整個過程飒焦。
HTTP2.0,SPDY,WebSocket
HTTP/2.0 的目標是改善用戶在使用 Web 時的速度體驗蜈膨。由于基本上都會先通過 HTTP/1.1 與 TCP 連接，
Google 在 2010 年發(fā)布了 SPDY（取自 SPeeDY荒给，發(fā)音同 speedy）丈挟，其開發(fā)目標旨在解決 HTTP 的性能瓶頸刁卜，縮短 Web 頁面的加載時間（50%）志电。
WebSocket，即 Web 瀏覽器與 Web 服務(wù)器之間全雙工通信標準蛔趴。當(dāng)時籌劃將 WebSocket 作為 HTML5 標準的一部分挑辆，而現(xiàn)在它卻逐漸變成了獨立的協(xié)議標準。WebSocket 通信協(xié)議在 2011 年 12 月 11 日孝情，被 RFC 6455 - The WebSocket Protocol 定為標準鱼蝉。
錯誤不足之處或相關(guān)建議歡迎大家評論指出，謝謝箫荡！如果覺得內(nèi)容可以的話麻煩喜歡（?）一下魁亦。您的支持是我最大的動力。
