• 鏈接: https://pan.baidu.com/s/1bp08VvT 密碼: nnyd

章節(jié)一：了解Web及網(wǎng)絡(luò)基礎(chǔ)

** 1.1 使用HTTP協(xié)議訪問web**

• 客戶端(client)：通過發(fā)送請(qǐng)求獲取服務(wù)器資源的web瀏覽器盗扇。

  
  
  Snip20170427_6.png
• WWW(World Wide Web,萬維網(wǎng))三項(xiàng)構(gòu)建技術(shù)

  • 把 SGML(Standard Generalized Markup Language,標(biāo)準(zhǔn)通用標(biāo)記語言)作為頁面的文本標(biāo) 記語言HTML(HyperText Markup Language,超文本標(biāo)記語言)琳拨。

  • 作 為文檔傳遞協(xié)議的 HTTP；

  • 指定文檔所在地址的 URL(Uniform Resource Locator,統(tǒng)一資源定位符)

TCP/IP協(xié)議

• 計(jì)算機(jī)與網(wǎng)絡(luò)要互相通信号俐，雙方就必須基于相同的方法，不同的硬件德澈，操作系統(tǒng)都需要一種規(guī)則祭刚，我們把這種規(guī)則稱之為協(xié)議（protocol）。

  
  
  TCP/IP協(xié)議群.png
• 互聯(lián)網(wǎng)相關(guān)聯(lián)的協(xié)議集合起來總稱為 TCP/IP好啰。也有說 法認(rèn)為,TCP/IP 是指 TCP 和 IP 這兩種協(xié)議。還有一種說法認(rèn)為,TCP/ IP 是在 IP 協(xié)議的通信過程中,使用到的協(xié)議族的統(tǒng)稱.

TCP/IP 分層管理

• 應(yīng)用層:
  • HTTP ,FTP, DNS（Domain Name System, 域名系統(tǒng)）
• 傳輸層

- 網(wǎng)絡(luò)層
 - ```網(wǎng)絡(luò)層用來處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包儿奶。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位坎怪。該層規(guī)定了通過怎樣的路徑(所謂的傳輸路線)到達(dá)對(duì) 方計(jì)算機(jī),并把數(shù)據(jù)包傳送給對(duì)方。 與對(duì)方計(jì)算機(jī)之間通過多臺(tái)計(jì)算機(jī)或網(wǎng)絡(luò)設(shè)備進(jìn)行傳輸時(shí),網(wǎng)絡(luò)層 所起的作用就是在眾多的選項(xiàng)內(nèi)選擇一條傳輸路線廓握。```
- 鏈路層（網(wǎng)絡(luò)接口層）
 - ```用來處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)嘁酿、硬件的設(shè)備驅(qū)動(dòng)隙券、NIC(Network Interface Card,網(wǎng)絡(luò)適配器,即網(wǎng)卡),及光纖等物理可見部分(還包括連接器等一切傳輸媒介)。硬件上的范疇 均在鏈路層的作用范圍之內(nèi)**```
![Snip20170427_8.png](http://upload-images.jianshu.io/upload_images/2319649-b459f8a15f50413b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
**與HTTP相關(guān)的IP,TCP,DNS協(xié)議**
- IP: 
   - 屬于網(wǎng)絡(luò)層闹司，不要和IP地址混淆娱仔，它是一種協(xié)議
   - 它的作用是把數(shù)據(jù)包傳送給對(duì)方。確保能傳遞準(zhǔn)確和成功的兩個(gè)重要條件是:IP地址和MAC地址游桩。
   - IP地址指的是節(jié)點(diǎn)分配地址牲迫，可變換，MAC地址基本不會(huì)更改

https://bbs.hupu.com/bxj
bbs.hupu.com/bxj就是指節(jié)點(diǎn)分配地址借卧，還是bxj是節(jié)點(diǎn)地址盹憎，希望有看到的朋友請(qǐng)指教

-  ARP 協(xié)議憑借 MAC 地址進(jìn)行通信
 ```IP 間的通信依賴 MAC 地址。在網(wǎng)絡(luò)上,通信的雙方在同一局域網(wǎng) (LAN)內(nèi)的情況是很少的,通常是經(jīng)過多臺(tái)計(jì)算機(jī)和網(wǎng)絡(luò)設(shè)備中轉(zhuǎn)才 能連接到對(duì)方铐刘。而在進(jìn)行中轉(zhuǎn)時(shí),會(huì)利用下一站中轉(zhuǎn)設(shè)備的 MAC 地址 來搜索下一個(gè)中轉(zhuǎn)目標(biāo)陪每。這時(shí),會(huì)采用 ARP 協(xié)議(Address Resolution Protocol)。ARP 是一種用以解析地址的協(xié)議,根據(jù)通信方的 IP 地址就
可以反查出對(duì)應(yīng)的 MAC 地址镰吵。

• 路由選擇
  在到達(dá)通信目標(biāo)前的中轉(zhuǎn)過程中,那些計(jì)算機(jī)和路由器等網(wǎng)絡(luò)設(shè)備 只能獲悉很粗略的傳輸路線檩禾。這種機(jī)制稱為路由選擇(routing),所以無論哪臺(tái)計(jì)算機(jī)或哪臺(tái)網(wǎng)絡(luò)設(shè)備都無法掌握全面的細(xì)節(jié)
• TCP協(xié)議位于網(wǎng)絡(luò)層，提供可靠的的字節(jié)流服務(wù)
  • 字節(jié)流服務(wù):將數(shù)據(jù)庫切割成報(bào)文段（segment）的單位數(shù)據(jù)疤祭，TCP 協(xié)議為了更容易傳送大數(shù)據(jù)才把數(shù)據(jù)分割盼产。
  • 可靠性:準(zhǔn)確的送達(dá)到對(duì)方
• 三次握手：確保數(shù)據(jù)傳輸?shù)目煽啃?/li>

回傳一個(gè)帶有 SYN/ACK 標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息。最后,發(fā)送 端再回傳一個(gè)帶 ACK 標(biāo)志的數(shù)據(jù)包,代表“握手”結(jié)束勺馆。
若在握手過程中某個(gè)階段莫名中斷,TCP 協(xié)議會(huì)再次以相同的順序 發(fā)送相同的數(shù)據(jù)包戏售。```
![Snip20170427_10.png](http://upload-images.jianshu.io/upload_images/2319649-b1dc99a585701d1d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
- DNS協(xié)議：提供通過域 名查找 IP 地址,或逆向從 IP 地址反查域名的服務(wù)侨核。
![Snip20170427_11.png](http://upload-images.jianshu.io/upload_images/2319649-3cb1df1be3307294.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
**HTTP與各種協(xié)議的關(guān)系**
![Snip20170427_12.png](http://upload-images.jianshu.io/upload_images/2319649-a97d224c2f734b04.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
```client發(fā)送URL請(qǐng)求，首先DNS會(huì)將解析對(duì)應(yīng)的IP地址蜈项，HTTP協(xié)議生成針對(duì)目標(biāo)服務(wù)器的HTTP請(qǐng)求報(bào)文芹关，TCP協(xié)議將報(bào)文割成文段，按序號(hào)分為多個(gè)數(shù)據(jù)包紧卒，可靠的發(fā)給對(duì)方（三次握手）侥衬，通過ARP協(xié)議解析IP地址的MAC地址，發(fā)給對(duì)方（IP協(xié)議）跑芳，此處會(huì)有通過路由中轉(zhuǎn)的過程轴总。服務(wù)器接收數(shù)據(jù)包，再以TCP協(xié)議按序號(hào)順序重組報(bào)文,HTTP解析報(bào)文博个，服務(wù)器處理內(nèi)容在以相同的方式向用戶進(jìn)行回傳

URI/URL

• URI（Uniform Resource Locator,統(tǒng)一資源定位符）
• URL 是URI的子集

• URL的格式:

  
  
  Snip20170427_13.png
• RFC(Request for Comments)HTTP協(xié)議技術(shù)的標(biāo)準(zhǔn)文檔

章節(jié)二:HTTP 協(xié)議用于客戶端和服務(wù)器端之間的通信

通過請(qǐng)求和響應(yīng)交換達(dá)成協(xié)議

• 請(qǐng)求報(bào)文：

  • 請(qǐng)求方法冬念、請(qǐng)求 URI、協(xié)議版本媒吗、可選的請(qǐng)求首部字
    段和內(nèi)容實(shí)體構(gòu)成的陨舱。

    
    
    Snip20170427_15.png

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

  • 請(qǐng)求內(nèi)容的處理結(jié)果以響應(yīng)的形式返回
    
    Snip20170427_17.png
    
    HTTP是一種不保存狀態(tài)

• HTTP 是一種不保存狀態(tài),即無狀態(tài)(stateless)協(xié)議。HTTP 協(xié)議 自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存共耍。

• 協(xié)議本身并不保留之前一切的請(qǐng)求或響應(yīng)報(bào)文的信息虑灰。這是為了更快地處理大量事務(wù),確保協(xié)議的可伸縮性,而特意把 HTTP 協(xié)議設(shè)計(jì)成 如此簡單的。

• 為了保持狀態(tài)痹兜，HTTP1.1引入Cookie概念穆咐。
  告知服務(wù)器意圖的 HTTP 方法

• GET :獲取資源
  GET 方法用來請(qǐng)求訪問已被 URI 識(shí)別的資源。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容字旭。也就是說,如果請(qǐng)求的資源是文本,那就保 持原樣返回;如果是像 CGI(Common Gateway Interface,通用網(wǎng)關(guān)接 口)那樣的程序,則返回經(jīng)過執(zhí)行后的輸出結(jié)果对湃。

• POST:傳輸實(shí)體主體
  POST 的功能與 GET 很相似,但 POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容。

• PUT :傳輸文件

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

• DELETE:刪除文件

但是,HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗(yàn)證機(jī) 制,所以一般的 Web 網(wǎng)站也不使用 DELETE 方法```
- OPTIONS 方法用來查詢針對(duì)請(qǐng)求 URI 指定的資源支持的方法。
- TRACE 方法 是讓 Web 服務(wù)器端將之前的請(qǐng)求通信環(huán)回給客戶端的 方法屈暗。
- CONNECT:要求用隧道協(xié)議連接代理
![Snip20170427_18.png](http://upload-images.jianshu.io/upload_images/2319649-54dac7e7aed8b5be.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
**HTTP長連接**
- 每次的請(qǐng)求都會(huì)造成無謂的 TCP 連接建立和斷開, 增加通信量的開銷
- HTT持久倡長連接只要任意一端沒 有明確提出斷開連接,則保持 TCP 連接狀態(tài)
- 管線化：持久連接使得多數(shù)請(qǐng)求以管線化(pipelining)方式發(fā)送成為可能斤儿。 從前發(fā)送請(qǐng)求后需等待并收到響應(yīng),才能發(fā)送下一個(gè)請(qǐng)求。管線化技術(shù) 出現(xiàn)后,不用等待響應(yīng)亦可直接發(fā)送下一個(gè)請(qǐng)求恐锦。
![管線化.png](http://upload-images.jianshu.io/upload_images/2319649-fffb37cccc128494.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
**使用 Cookie 的狀態(tài)管理**
- Cookie 技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 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ù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后,會(huì)去檢查究竟是從哪 一個(gè)客戶端發(fā)來的連接請(qǐng)求,然后對(duì)比服務(wù)器上的記錄,最后得到之前 的狀態(tài)信息

Cookie

• HTTP報(bào)文大致可分為報(bào)文首部一铅，報(bào)文主兩塊陕贮。通常,并不一定要有報(bào)文主體。

  
  
  報(bào)文結(jié)構(gòu).png
  
  
  報(bào)文結(jié)構(gòu)詳解.png
• 請(qǐng)求報(bào)文和響應(yīng)報(bào)文的組成
  • 請(qǐng)求行
    包含用于請(qǐng)求的方法,請(qǐng)求 URI 和 HTTP 版本潘飘。
  • 狀態(tài)行
    包含表明響應(yīng)結(jié)果的狀態(tài)碼,原因短語和 HTTP 版本肮之。
  • 首部字段
    包含表示請(qǐng)求和響應(yīng)的各種條件和屬性的各類首部掉缺。

編碼提升傳輸效率

• 報(bào)文
  • 基本單位：8位字節(jié)流
• 實(shí)體
  • 作為請(qǐng)求或響應(yīng)的有效載荷數(shù)據(jù)(補(bǔ)充項(xiàng))被傳輸,其內(nèi)容由實(shí) 體首部和實(shí)體主體組成。

壓縮傳輸內(nèi)容編碼

• 內(nèi)容編碼指明應(yīng)用在實(shí)體內(nèi)容上的編碼格式,并保持實(shí)體信息原樣壓縮戈擒。內(nèi)容編碼后的實(shí)體由客戶端接收并負(fù)責(zé)解碼眶明。
• 常用的內(nèi)容編碼格式:
  • gzip
  • compress(UNIX 系統(tǒng)的標(biāo)準(zhǔn)壓縮)
  • deflate(zlib)
  • identity(不進(jìn)行編碼)

分割發(fā)送的分塊傳輸編碼

• 分塊傳輸編碼
  在 HTTP 通信過程中,請(qǐng)求的編碼實(shí)體資源尚未全部傳輸完成之 前,瀏覽器無法顯示請(qǐng)求頁面。在傳輸大容量數(shù)據(jù)時(shí),通過把數(shù)據(jù)分割 成多塊,能夠讓瀏覽器逐步顯示頁面筐高，這種實(shí)體分塊功能稱為傳塊編碼
  
  分塊傳輸.png
• 分塊傳輸會(huì)將實(shí)體主體分為多個(gè)部分搜囱，每一部分用16進(jìn)制開標(biāo)記塊的大小，而實(shí)體主體的最后一塊會(huì)使用“0(CR+LF)”
• HTTP/1.1 中存在一種稱為傳輸編碼(Transfer Coding)的機(jī)制,它 可以在通信時(shí)按某種編碼方式傳輸,但只定義作用于分塊傳輸編碼中來標(biāo)記柑土。

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

• MIME(Multipurpose Internet Mail Extensions,多用途因特網(wǎng) 郵件擴(kuò)展)機(jī)制
  多部分對(duì)象集合包含的對(duì)象如下
• multipart/form-data
  在 Web 表單文件上傳時(shí)使用蜀肘。
• multipart/byteranges
  狀態(tài)碼 206(Partial Content,部分內(nèi)容)響應(yīng)報(bào)文包含了多個(gè)范 圍的內(nèi)容時(shí)使用。
• multipart/form-data
• multipart/byteranges

獲取部分內(nèi)容的范圍請(qǐng)求
內(nèi)容協(xié)商返回最合適的內(nèi)容

• 當(dāng)瀏覽器的 認(rèn) 為 或中文, 問相同 URI 的 Web 頁面時(shí), 會(huì)顯示對(duì)應(yīng)的 版或中文版的 Web 頁面稽屏。這樣的機(jī)制 為內(nèi)容協(xié)
• 請(qǐng)求報(bào)文中首部字段的判斷基準(zhǔn)
  • Accept
  • Accept-Charset
  • Accept-Language
  • Content-Language
• 內(nèi)容協(xié) 技術(shù)有以 3 種
  • 服務(wù)器 動(dòng)協(xié)商(Se e - i en Negotiation)
  • 客戶端 動(dòng)協(xié)商(Agent- i en Negotiation)
  • 明協(xié)商(T ans a ent Negotiation)

HTTP返回結(jié)果狀態(tài)碼

狀態(tài)碼的職 是當(dāng)客戶端向服務(wù)器端發(fā)送請(qǐng)求時(shí), 返回的請(qǐng)求 結(jié)果扮宠。借助狀態(tài)碼,用戶可以知道服務(wù)器端是正常 理了請(qǐng)求,還是出 現(xiàn)了 。

響應(yīng)的狀態(tài)碼.png

• 以3位數(shù)字和原因組成的短語叫做狀

  
  
  狀態(tài)類別.png

用單臺(tái)虛擬主機(jī)實(shí)現(xiàn)多個(gè)域名

• HTTP/1.1 許一 HTTP 服務(wù)器 建多個(gè) Web 站點(diǎn)
• 即使 理 面只有一 服務(wù)器,但只要使用 主機(jī)的功能, 可 以 想已具有多 服務(wù)器狐榔。
• 在相同的 IP 地 ,由于 主機(jī)可以 存多個(gè)不同主機(jī)名和域 名的 Web 網(wǎng)站,因此在發(fā)送 HTTP 請(qǐng)求時(shí), 在 Host 首部內(nèi)完整指 定主機(jī)名或域名的 URI坛增。

虛擬主機(jī)

通訊數(shù)據(jù)轉(zhuǎn)發(fā)程序:代理 網(wǎng)關(guān) 隧道

• 代理

  • 代理服務(wù)器最基本的行為就是接受客戶端發(fā)送給他的請(qǐng)求

    
    
    代理

  • 在 HTTP 通信過程中,可級(jí)聯(lián)多 代理服務(wù)器。請(qǐng)求和響應(yīng)的 發(fā) 會(huì)經(jīng)過數(shù) 一樣 接起來的代理服務(wù)器薄腻。 發(fā)時(shí),需要 加 Via 首部字段以標(biāo)記出經(jīng)過的主機(jī)信

    • 代理使用方法的兩種基類分類
      • 緩存代理

當(dāng)代理再 接 到對(duì)相同資源的請(qǐng)求時(shí),就可以不從源服務(wù)器那里 資源,而是將之前緩存的資源作為響應(yīng)返回轿偎。```

- 透明代理

發(fā)請(qǐng)求或響應(yīng)時(shí),不對(duì)報(bào)文做 何加工的代理 被 為透明代 理(Transparent Pro y)。 之,對(duì)報(bào)文內(nèi)容進(jìn)行加工的代理被 為 透明代理

• 網(wǎng)關(guān)

    - 網(wǎng)關(guān)的工作機(jī)制和代理十分相似。網(wǎng)關(guān)能使通信路上的服務(wù)器提供非HTTP協(xié)議的服務(wù)球碉。
    - 利用網(wǎng)關(guān)能提高通信的安全 ,因?yàn)榭梢栽诳蛻舳伺c網(wǎng)關(guān)之間的通 信 路上加密以確保 接的安全蜓斧。 如,網(wǎng)關(guān)可以 接數(shù)據(jù) ,使用 S L   查 數(shù)據(jù)。另外,在 Web   網(wǎng)站上進(jìn)行信用 結(jié) 時(shí),網(wǎng)
    關(guān)可以和信用 結(jié)   聯(lián)動(dòng)睁冬。
- 隧道
   ```隧道是在相隔甚遠(yuǎn)的客戶端和服務(wù)器之間進(jìn)行中轉(zhuǎn)的挎春，并保持雙方通訊鏈接的應(yīng)用程序。

 - 隧道可 要求建立起一 與其他服務(wù)器的通信 路, 時(shí)使用 SSL 等加密手段進(jìn)行通信豆拨。隧道的目的是確敝狈埽客戶端能與服務(wù)器進(jìn)行安全的 通信。
 - 隧道不會(huì)解析HTTP請(qǐng)求施禾，原樣轉(zhuǎn)給服務(wù)器脚线，隧道會(huì)在客戶端和服務(wù)器斷開連接時(shí)結(jié)束。

保存資源的緩存

• 緩存服務(wù)器的 在于利用緩存可 多 從源服務(wù)器 發(fā)資源弥搞。 因此客戶端可就 從緩存服務(wù)器上 資源,而源服務(wù)器也不 多 理相同的請(qǐng)求了邮绿。

HTTP 首部

HTTP報(bào)文首部

請(qǐng)求報(bào)文結(jié)構(gòu)

• 在請(qǐng)求中渠旁，HTTP報(bào)文由方法 URL HTTP版本 HTTP首部字段構(gòu)成。

  
  
  請(qǐng)求報(bào)文

響應(yīng)報(bào)文結(jié)構(gòu)

4種HTTP首部字段類型

• 通用首部字段
  • 請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的首部船逮。如協(xié)議版本號(hào)
• 請(qǐng)求首部字段
  • 從客戶端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部顾腊。 了請(qǐng)求的加內(nèi)容、客戶端信 挖胃、響應(yīng)內(nèi)容相關(guān) 先級(jí)等信 杂靶。
• 響應(yīng)首部字段
  • 從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部。 了響應(yīng)的 加內(nèi)容,也會(huì)要求客戶端 加 外的內(nèi)容信 冠骄。
• 實(shí)體首部字段
  • 對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部伪煤。 了資源內(nèi)容 更新時(shí)間等與實(shí)體有關(guān)的信 。
    HTTP 首部字段一覽

非HTTP/1.1首部字段

• 在 HTTP 協(xié)議通信交互中使用到的首部字段,不 于 RFC2616 中 定義的 47 種首部字段凛辣。還有 Cookie抱既、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段,它們的使用 也很高。
  這些 正式的首部字段 一 在 RFC4229 HTTP Header Field Registrations 中扁誓。

End-to-end首部 和 Hop by hop首部
HTTP/1.1通用首部字段

• Cache-Control
  通過指定首部字段 Cache-Control 的指令,就能 作緩存的工作機(jī)制防泵。指令的 數(shù)是可 的,多個(gè)指令之間通過“,”分 。首部字段,Cache-Control 的指令可用于請(qǐng)求及響應(yīng)時(shí)蝗敢。
  

  Cache-Control
  
  
  響應(yīng)緩存

• Connetion

  • 控制不在轉(zhuǎn)發(fā)給代理的首部字段

    • Connection: 不再發(fā)的首部字段

      
      
      Snip20170502_42.png
  • 管理持久鏈接
    • HTTP/1.1 之前的 HTTP 版本的 認(rèn) 接都是 持 接捷泞。為此, 如果想在 版本的 HTTP 協(xié)議上維持持 接, 需要指定 Connection 首部字段的值為 Keep-Alive。

• Date

  • 首部字段 Date 表明 建 HTTP 報(bào)文的日 和時(shí)間寿谴。

• Pragma

  • Pragma 是 HTTP/1.1 之前版本的 史 留字段,僅作為與 HTTP/1.0 的向后 容而定義锁右。
  • 該首部字段 于通用首部字段,但只用在客戶端發(fā)送的請(qǐng)求中⊙忍客 戶端會(huì)要求所有的中間服務(wù)器不返回緩存的資源咏瑟。
  • EG: Pragma:no-cache

• Trailer

  • 首部字段 Trailer 會(huì) 先說明在報(bào)文主體后記 了哪些首部字段。該 首部字段可應(yīng)用在 HTTP/1.1 版本分 編碼時(shí)痪署。

• Transfer - Encoding

  • 規(guī)定了報(bào)文主體采用的編碼方式

• Upgrade

  • 首部字段 Upgrade 用于檢 HTTP 協(xié)議及其他協(xié)議是否可使用更高 的版本進(jìn)行通信,其 數(shù)值可以用來指定一個(gè)完全不同的通信協(xié)議码泞。

• Via

  • 使用首部字段 Via 是為了 客戶端與服務(wù)器之間的請(qǐng)求和響應(yīng)報(bào) 文的 路 。

• Warning

請(qǐng)求首部字段
請(qǐng)求首部字段是從客戶端 服務(wù)器端發(fā)送請(qǐng)求報(bào)文中所使用的字 段,用于 請(qǐng)求的 加信 狼犯、客戶端信 余寥、對(duì)響應(yīng)內(nèi)容相關(guān)的 先級(jí) 等內(nèi)容。

• Accept
  Accept 首部字段可通知服務(wù)器,用戶代理能 理的 體 及 體 的相對(duì) 先級(jí)悯森。 可使用 type/subtype 這種形式,一 指定多種 體 宋舷。
  • 文本文件，圖片文件...
  • text/html, text/plain, text/css ...
  • q表示權(quán)重 0-1的小數(shù)瓢姻，默認(rèn)1肥缔，以分好；分割。 quality factor 質(zhì)量因數(shù)
• Accept-Charset
  • 首部字段可用來通知服務(wù)器用戶代理支持的字 及字 的相對(duì) 先順序续膳。另外,可一 指定多種字 改艇。與首部字 段 Accept 相同的是可用權(quán)重 值來表示相對(duì)先級(jí)。
  • 該首部字段應(yīng)用于內(nèi)容協(xié) 機(jī)制的服務(wù)器 動(dòng)協(xié) 坟岔。
• Accept-Encoding
  • 首部字段用來 知服務(wù)器用戶代理支持的內(nèi)容編 碼及內(nèi)容編碼的 先級(jí)順序谒兄。可一 指定多種內(nèi)容編碼
• Accept - Language
  • 首部字段 Accept-Language 用來 知服務(wù)器用戶代理能 理的自 然 (指中文或 文等),以及自然 的相對(duì) 先級(jí)社付〕衅＃可一 指定多種自然 。q表示權(quán)重
• Authorization
• Expect
  • 客戶端使用首部字段 Expect 來 知服務(wù)器, 望出現(xiàn)的某種特定 行為鸥咖。因服務(wù)器無法理解客戶端的 望作出回應(yīng)而發(fā)生 時(shí),會(huì)返回 狀態(tài)碼 417 E pectation Failed燕鸽。
• From
  • 首部字段 From 用來 知服務(wù)器使用用戶代理的用戶的 件地 。 通常,其使用目的就是為了顯示 引 等用戶代理的 人的 件聯(lián) 方式啼辣。使用代理時(shí),應(yīng) 可能包含 From 首部字段(但可 能會(huì)因代理不同,將 件地 記 在 User-Agent 首部字段內(nèi))啊研。
• Host
  • 首部字段 Host 會(huì) 知服務(wù)器,請(qǐng)求的資源所 的互聯(lián)網(wǎng)主機(jī)名和 端 。Host 首部字段在 HTTP/1.1 內(nèi)是 一一個(gè) 被包含在請(qǐng) 求內(nèi)的首部字段鸥拧。

為cookie服務(wù)的首部字段

HTTP的缺點(diǎn)

• HTTP的不足
  • 通信使用明文（不加密）党远，內(nèi)容可能會(huì)被竊聽
  • 不驗(yàn)證通信方的身份，因此有可能遇到偽裝
  • 無法驗(yàn)證報(bào)文的完整性富弦，所以有可能已遭篡改

加密策略

• 通信的加密
  一種方式就是講通信加密沟娱。HTTP協(xié)議中沒有加密機(jī)制但可以通 過和SSL(Secure Socket Layer,安全 接 )或TLS(Transport Layer Security,安全 協(xié)議)的 使用,加密 HTTP 的通信內(nèi)容。
• 內(nèi)容加密
  對(duì)HTTP報(bào)文內(nèi)容進(jìn)行加密

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

• HTTP協(xié)議非常簡單腕柜，但是存在各種隱患
  • 無法確定請(qǐng)求發(fā)送 目 的 Web 服務(wù)器是 是 實(shí)意圖返回 響應(yīng)的 臺(tái)服務(wù)器济似。有可能是已偽裝的 Web 服務(wù)器
  • 無法確定正在通信的對(duì)方是否具備訪問權(quán)限。
  • 無法判斷請(qǐng)求來自何方盏缤，出自誰手
  • 即使是無意義的請(qǐng)求也會(huì)照單全收砰蠢。

查看對(duì)手的證書

SSL.png

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

• HTTPS不是一種新的應(yīng)用層協(xié)議。只是HTTP部分通信接口用SSL和TLS

• HTTP 接和 TCP 通信蛾找。當(dāng)使用 SSL 時(shí), 變成先和 SSL 通信,再由 SSL 和 TCP 通信了。簡 之,所謂 HTTPS,其實(shí)就是 身 SSL 協(xié)議這 外 的 HTTP

  
  
  HTTPS