一、了解Web及網(wǎng)絡基礎

CERN，歐洲核子研究組織明肮，最先提出一種能讓遠隔兩地的研究者們共享知識的設想艺普。

1簸州、網(wǎng)絡基礎TCP/IP

通常使用的網(wǎng)絡實在TCP/IP協(xié)議族的基礎上運作的，而HTTP屬于它內(nèi)部的一個子集歧譬。

1.1TCP/IP協(xié)議族

image.png

1.2 TCP/IP的分層管理

TCP/IP協(xié)議族按照層次可分為四層：應用層岸浑、傳輸層、網(wǎng)絡層和數(shù)據(jù)鏈路層瑰步。
分層的好處：可以單獨的修改和替換某一個層次矢洲；設計也簡單了，只需要考慮自己需要實現(xiàn)的功能即可缩焦。

• 應用層
  決定了向用戶提供應用服務時通信的活動读虏。比如FTP（文件傳輸協(xié)議）、DNS（域名系統(tǒng)）和HTTP（超文本傳輸協(xié)議袁滥，也叫做超文本轉(zhuǎn)移協(xié)議）
• 傳輸層
  對上層應用層提供處于網(wǎng)絡連接中的兩臺計算機之間的數(shù)據(jù)傳輸盖桥。有TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報協(xié)議）
• 網(wǎng)絡層（網(wǎng)絡互聯(lián)層）
  用來處理在網(wǎng)絡上流動的數(shù)據(jù)包，數(shù)據(jù)包時網(wǎng)絡傳輸?shù)淖钚?shù)據(jù)單位题翻。該層規(guī)定了通過怎樣的路徑到達對方計算機揩徊，并把數(shù)據(jù)包 給對方。
• 鏈路層（數(shù)據(jù)鏈路層、網(wǎng)絡接口層）
  處理連接網(wǎng)絡的硬件部分塑荒。包括控制操作系統(tǒng)熄赡、硬件的設備驅(qū)動、NIC（網(wǎng)絡適配器齿税，即網(wǎng)卡）及光纖等物理課件部分彼硫。

1.3 TCP/IP通信傳輸流

image.png

發(fā)送端在層與層之間傳輸數(shù)據(jù)時，每經(jīng)過一層時必定會被打傷一個該層的所屬首部信息凌箕。反之乌助，在接收端在層與層傳輸數(shù)據(jù)時，每經(jīng)過一層時會把對應的首部消去陌知。

image.png

2、與HTTP關(guān)系密切的協(xié)議：IP仆葡、TCP和DNS

2.1 負責傳輸?shù)腎P協(xié)議

位于網(wǎng)絡層赏参，稱為網(wǎng)際協(xié)議。其作用是把各種數(shù)據(jù)包傳送給對方沿盅，依靠的兩個重要條件：IP地址和MAC地址把篓。
IP地址指明了節(jié)點被分配到的地址，MAC地址是指網(wǎng)卡所屬的固定地址腰涧。IP地址可變化韧掩，但是MAC地址不會。
使用ARP協(xié)議憑借MAC地址進行通信窖铡。ARP：解析地址協(xié)議疗锐，它能根據(jù)通信方的IP地址反查出對應的MAC地址。

image.png

2.2確钡吆铮可靠性的TCP協(xié)議

位于傳輸層关划，提供可靠的字節(jié)流服務。
TCP協(xié)議采用三次握手策略來保證可靠的字節(jié)流服務翘瓮。握手過程中使用了TCP的標志(flag)---SYN(synchronize)和ACK(acknowledgement).具體過程如下：
1贮折、發(fā)送端發(fā)送一個帶SYN標志的數(shù)據(jù)包給對方；
2春畔、接收端接收到后脱货，回傳一個帶有SYN/ACK標志的數(shù)據(jù)包表示確認信息

image.png

2.3 負責解析域名的DNS服務

image.png

2.4 總覽

image.png

URI：統(tǒng)一資源標識符

URL：統(tǒng)一資源定位符

二扣孟、簡單的HTTP協(xié)議

image.png

image.png

1每币、HTTP是不保存狀態(tài)的協(xié)議

HTTP是無狀態(tài)協(xié)議厌处，它自身是不會對請求和響應之間的通信狀態(tài)進行保存的。主要是為了更快的處理大量事務，確保協(xié)議的可伸縮性存筏。
為了解決這種無狀態(tài)，引入了Cookie技術(shù)颊艳，使用Cookie來管理狀態(tài)肾筐。

三、HTTP報文內(nèi)的HTTP信息

1娇斑、HTTP報文

用于HTTP協(xié)議交互的信息被稱為HTTP報文策添。請求的一方的報文被稱為請求報文，響應的一方的報文被稱為響應報文毫缆。
HTTP報文大致可分為報文首部和報文主體舰攒，兩者之間用一個空行劃分。不一定有報文主體悔醋。

2摩窃、編碼提升傳輸速率

2.1 報文主體和實體主體

報文：是HTTP通信中的基本單位，由8位字節(jié)流組成芬骄，通過HTTP通信傳輸猾愿。
實體：作為請求或響應的有效載荷數(shù)據(jù)（補充項）被傳輸，其內(nèi)容由實體首部和實體主體組成账阻。

四蒂秘、返回結(jié)果的HTTP狀態(tài)碼

1、狀態(tài)碼告知從服務器端返回的請求結(jié)果

2淘太、2XX 成功

2XX的響應結(jié)果表明請求被正常處理了姻僧。

• 200 OK
• 204 No Content
• 206 Partial Content
  該狀態(tài)碼表示客戶端進行了范圍請求规丽，而服務器成功執(zhí)行了這部分請求。

3撇贺、3XX重定向

3XX響應結(jié)果表明瀏覽器需要執(zhí)行某些特殊的處理以正確處理請求赌莺。

• 301 永久性重定向
• 302 臨時重定向
• 303

4、4XX客戶端錯誤

4XX的響應結(jié)果表明客戶端是發(fā)生錯誤的原因所在

• 400 Bad Request
  請求報文中存在語法錯誤
• 401
• 403 Forbidden
  對資源的請求被服務器拒絕了
• 404 Not Found
  服務器上無法找到請求的資源

5松嘶、5XX 服務器錯誤

5XX的響應結(jié)果表明服務器本身發(fā)生錯誤艘狭。

• 500
• 503
  服務器暫時處于超負荷運轉(zhuǎn)或者正在進行停機維護，現(xiàn)在無法請求翠订。

五巢音、與HTTP協(xié)作的Web服務器

六、HTTP首部

七尽超、確保Web安全的HTTPS

1官撼、HTTP的缺點

• 通信使用明文，內(nèi)容可能會被竊聽
• 不驗證通信方的身份似谁，因此有可能遭遇偽裝
• 無法證明報文的完整性歧寺，有可能已遭篡改

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

HTTP本身不具備加密的功能棘脐，所以發(fā)送的都是明文斜筐。

• TCP/IP是可能被竊聽的網(wǎng)絡
• 加密處理防止被竊聽
  主要的加密對象有：
  1、通信的加密
  HTTP和SSL（安全套接層）或TLS（安全層傳輸協(xié)議）的組合使用蛀缝，加密HTTP的通信內(nèi)容顷链。
  建立了安全通信線路后，就可以在這條線路上進行HTTP通信屈梁。與SSL組合的HTTP被稱為HTTPS嗤练。
  2、內(nèi)容加密
  將參與通信的內(nèi)容本身加密在讶，即將報文主體加密煞抬。

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

HTTP協(xié)議中請求和響應都不會對通信雙方進行確認，所以我們沒辦法確定發(fā)送方和接收方是否都是自己的构哺。主要在于：

• 任何人都可發(fā)起請求
• 查明對手的證書
  HTTP協(xié)議無法確定通信方革答，但是SSL可以，SSL不僅提供了加密處理曙强，而且還使用了一種被稱為證書的手段残拐，可用于確定方。

2碟嘴、HTTP+加密+認證+完整性保護=HTTPS

2.1 相互交換密鑰的公開密鑰加密技術(shù)

SSL采用一種公開密鑰加密的加密處理方式溪食。

• 共享密鑰加密
  加密和解密同用一個密鑰的方式被稱為共享密鑰加密，也被叫做對稱密鑰加密娜扇。任何人只要持有這個密鑰就可以解密內(nèi)容了错沃。但是又個問題栅组，共享密鑰加密必須將密鑰也發(fā)送給對方，所以只要攻擊者獲取到了該密鑰枢析，就能為所欲為玉掸。
• 使用兩把密鑰的公開密鑰加密
  公開密鑰加密使用的是非對稱加密。一把叫做私有密鑰登疗，另一把叫公開密鑰排截。
  使用公開密鑰加密方式嫌蚤，發(fā)送密文的一方使用對方的公開密鑰進行加密辐益，對方收到被加密的信息后，使用自己的私有密鑰解密脱吱。

私鑰和公鑰之間不會因為知道一個而推斷出另外一個智政；使用其中的一個密鑰對內(nèi)容加密后，基本上用該密鑰無法解密箱蝠，只能使用另一個密鑰解密续捂。

舉個例子：A和B要通信，A要發(fā)送一份資料給B
1宦搬、A手里的資料是x牙瓢；
2、B通過一些方法间校，產(chǎn)生了兩個密鑰B1和B2矾克，其中B1作為公鑰，B2作為私鑰
3憔足、B通過HTTP把自己的公鑰B1發(fā)送給了A
4胁附、A接收到了來自B的公鑰，然后使用該公鑰對x加密滓彰，并返回給了B
5控妻、B收到來自A的加密資料后，使用自己的私鑰B2解密揭绑。

2.2 HTTPS采用混合加密機制

HTTPS采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制弓候。

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

公開密鑰在傳輸過程中也會被替換掉，所以也沒辦法確定它是否還是原來的樣子他匪。
為了解決這個問題弓叛，可以使用由數(shù)字證書認證機構(gòu)（CA）和其他相關(guān)機關(guān)辦法的公開密鑰證書。數(shù)字證書認證機構(gòu)是一個第三方可信賴的機構(gòu)诚纸。
數(shù)字證書認證機構(gòu)業(yè)務流程： 服務器的運營人員向數(shù)字證書認證機構(gòu)提出公開密鑰的申請撰筷。數(shù)字證書認證機構(gòu)在判明提出申請者的身份后，會對已申請的公開密鑰做數(shù)字簽名畦徘，然后分配這個已簽名的公開密鑰毕籽，并將該公開密鑰放入公鑰證書后綁定在一起抬闯。
服務器會將這份由數(shù)字證書認證機構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端，以進行公開密鑰加密方式通信关筒。
接到證書的客戶端可使用數(shù)字證書認證機構(gòu)的公開密鑰溶握，對該證書上的數(shù)字簽名進行驗證，認證通過后蒸播，便可確認：1睡榆、服務器的公開密鑰是真實有效的數(shù)字證書認證機構(gòu)；2袍榆、服務器的公開密鑰匙值得信賴的胀屿。

3、HTTPS通信

1包雀、客戶端通過發(fā)送ClientHello報文開始SSL通信宿崭。報文中包含客戶端支持的SSL的制定版本、加密組件列表才写。
2葡兑、服務器可進行SSL通信時，會以Server Hello報文作為應答赞草。報文中包含SSL版本和加密組件讹堤。服務器中的加密組件內(nèi)容是從接收到的客戶端加密組件中篩選出來的。
3厨疙、服務器發(fā)送Certificate報文洲守。報文中包含公開密鑰證書。
4轰异、最后服務器發(fā)送Server Hello Done報文通知客戶端岖沛，最初階段的SSL握手協(xié)商部分結(jié)束
5、SSL第一次握手技術(shù)后搭独，客戶端以Client Key Exchange報文作為回應婴削。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密牙肝。
6唉俗、客戶端繼續(xù)發(fā)送加密組件（Change Cipher Spec）報文。該報文會提示服務器配椭，在此報文之后的通信會采用Pre-master secret密鑰加密虫溜。
7、客戶端發(fā)送Finished報文股缸。該報文包含連接至今全部報文的整體校驗值衡楞。
8、服務器同樣發(fā)送Change Cipher Spec報文敦姻。
9瘾境、服務器同樣發(fā)松Finished報文
10歧杏、Finished報文交換完畢后，SSL鏈接就算建立完成迷守。從此開始進行應用層協(xié)議通信犬绒，即發(fā)送HTTP請求。
11兑凿、應用層協(xié)議通信凯力，發(fā)送HTTP響應
12、由客戶端斷開鏈接礼华。發(fā)送close_notify報文
13咐鹤、發(fā)送TCP FIN報文來關(guān)閉與TCP的通信。

八卓嫂、確認訪問用戶身份的認證

這里的認證主要是為了區(qū)分訪問服務器的使用者的身份慷暂。
HTTP的認證方式有：

• BASIC認證（基本認證）
• DIGEST認證（摘要認證）
• SSL客戶端認證
• FormBase認證（表單認證）

1聘殖、BASIC認證（基本認證）

安全級別很低晨雳，這里認證的是用戶名和密碼。將用戶名和密碼用冒號連接起來后奸腺，以Base64方式編碼后發(fā)送給服務器餐禁。可以發(fā)現(xiàn)突照，這里并沒有做任何的加密處理帮非，所以很不安全。主要流程如下：
1讹蘑、客戶端發(fā)起請求
2末盔、服務器返回401，表示需要認證座慰；并返回認證方式BASIC
3陨舱、客戶端將用戶ID和密碼用冒號連接，然后Base64后返回給服務器
4版仔、認證通過游盲，則返回200

2、DIGEST認證（摘要認證）

它采用質(zhì)詢/響應的方式蛮粮，只不過DIGEST不會直接發(fā)送明文益缎。
質(zhì)詢/響應方式：一方A會發(fā)送認證要求給另一方B，B在接受到認證請求后然想，會根據(jù)接收到的質(zhì)詢碼生成響應碼莺奔，然后發(fā)送給A，A對此響應碼進行校驗即可变泄。
DIGEST的認證流程如下：
1令哟、客戶端發(fā)起請求
2熙卡、服務器返回401，并在響應首部字段Authorization里返回一個必須的質(zhì)詢碼字段nonce和必須的字段realm在励饵，以及其他的信息驳癌，如uri等
3、客戶端解析該質(zhì)詢碼役听，生成一個響應碼颓鲜，并返回給服務器，首部字段中包括username典予、realm甜滨、nonce、uri和response字段瘤袖，響應碼放在response里面
4衣摩、服務器接收到首部字段Authorization后，解析響應碼及其他認證信息捂敌，如果通過艾扮，則返回200

3、SSL客戶端認證

安全級別較高占婉。需要事先將客戶端證書發(fā)給客戶端泡嘴，且客戶端必須安裝此證書。
SSL認證流程如下：
1逆济、客戶端發(fā)起請求
2酌予、服務器需要認證時，會發(fā)送Certificate報文奖慌，要求客戶端提供證書
3抛虫、客戶端將證書信息以報文形式發(fā)送給服務器
4、服務器進行處理認證简僧，認證通過后建椰，領取證書內(nèi)的客戶端公開密鑰，進行HTTPS加密通信

不過一般客戶端認證采用的是雙因素認證涎劈，即結(jié)合另外一種認證方式進行認證广凸，最常用的是表單認證。因為SSL認證只能認證客戶端是合法的蛛枚，但是不能認證使用者就是用戶本人谅海，所以需要結(jié)合其他認證方式來確定用戶是否合法。

4蹦浦、FormBase認證（表單認證）

表單認證基本和BASIC認證相同扭吁，只不過表單認證采取了Cookie來管理，因為HTTP是無狀態(tài)的，所以采用Cookie來保證其有狀態(tài)性侥袜。
認證流程如下：
1蝌诡、客戶端發(fā)起請求，將用戶名和密碼放入實體中枫吧，發(fā)送給服務器浦旱，通常采用的是POST方法
2、服務器接收到請求后九杂，會發(fā)放一個SessionID颁湖，來作為用戶的身份識別
3、客戶端將接收到的SessionID作為Cookie保存在本地例隆，下次請求的時候甥捺，會默認帶上該SessionID。

不過镀层，這種方式如果處理不當镰禾，也會有被偽裝的風險，所以服務器可以通過對SessionID設置有效期來保證其安全性唱逢；為了防止跨站腳本攻擊（XSS）吴侦，事先可以在Cookie內(nèi)加上httponly屬性。

九惶我、基于HTTP的功能追加協(xié)議--WebSocket

有這么一種場景：在Facebook和Twitter等SNS網(wǎng)站上妈倔，幾乎能夠?qū)崟r觀察到海量用戶公開發(fā)布的內(nèi)容博投。當幾百绸贡、幾千萬的用戶發(fā)布內(nèi)容時，Web網(wǎng)站為了保存這些新增內(nèi)容在很短的時間內(nèi)就會發(fā)生大量內(nèi)容更新毅哗；相應的听怕，為了盡可能實時的顯示這些更新內(nèi)容，服務器上已有新內(nèi)容虑绵，就需要直接把那些內(nèi)容反饋到客戶端的界面上尿瞭。
針對這一現(xiàn)象，HTTP上肯定是完成不了的翅睛，因為HTTP只能是由客戶端發(fā)起請求声搁，它做響應，一次響應結(jié)束捕发，這次連接就會被關(guān)閉疏旨，下次還需要重新連接≡幔總之檐涝，HTTP標準由如下的瓶頸：
1、一條連接只能發(fā)送一個請求
2、請求只能從客戶端開始
3谁榜、請求/響應首部未經(jīng)壓縮就發(fā)送
4幅聘、發(fā)送冗長的首部
5、可任意選擇數(shù)據(jù)壓縮格式窃植，也可以不壓縮
針對這些瓶頸帝蒿，先后出現(xiàn)了Ajax、Comet等新技術(shù)巷怜。但是都不能很好的解決問題陵叽。Ajax采用輪詢，每隔一段時間就會自動請求一次丛版；Comet采用阻塞的辦法巩掺，客戶端的請求會被刮起在后臺，當有新內(nèi)容的時候才會返回页畦，這樣無疑會消耗更多的資源胖替。
而WebSocket可以解決這個問題。

1豫缨、WebSocket--全雙工通信

一旦客戶端和服務器建立了WebSocket協(xié)議的通信連接独令，之后所有的通信都依靠這個專用協(xié)議進行。通信過程中可互相發(fā)送任意格式的數(shù)據(jù)好芭。
通信連接是建立在HTTP基礎上的燃箭，一旦建立了連接，無論是客戶端還是服務器都可直接向?qū)Ψ桨l(fā)送報文舍败。
主要特點有：

• 推送功能
  服務器可直接向客戶端推送數(shù)據(jù)
• 減少通信量
  只要建立了WebSocket連接招狸，在斷開前，不用再次連接邻薯，可以直接發(fā)送想要發(fā)送的內(nèi)容裙戏。

2、WebSocket連接

image.png

如上圖所示寿羞，WebSocket的協(xié)議是ws猖凛，采用安全機制的是wss。