HTTP協(xié)議
http協(xié)議是：是基于TCP/IP協(xié)議超文本傳輸協(xié)議，它是一個短連接。超文本是指由HTML標(biāo)簽語言編寫的能被瀏覽器識別并解析出頁面樣式的文本文件，超文本傳輸協(xié)議就是向服務(wù)器發(fā)起請求，服務(wù)器傳輸所請求的域名中的超文本文件，然后在客戶端通過瀏覽器識別解析。他們所遵循的就是http協(xié)議
輸入域名到展示的過程
1、域名解析
根據(jù)輸入的域名，解析出服務(wù)器的IP地址。域名解析的順序是反向的，從.com開始到www.結(jié)束
2、瀏覽器發(fā)起請求
在RequestHeader欄中可以看到瀏覽器發(fā)起的請求
GET / HTTP/1.1
GET表示一個讀取請求，將從服務(wù)器獲得網(wǎng)頁數(shù)據(jù)，/表示URL的路徑，URL總是以/開頭，/就表示主頁，最后的HTTP/1.1指示采用的HTTP協(xié)議版本是1.1。目前HTTP協(xié)議的版本就是1.1，但是有部分服務(wù)器也支持1.0版本，主要區(qū)別在于1.1版本允許多個HTTP請求復(fù)用一個TCP連接，以加快傳輸速度。
Host: www.baidu.com
表示請求的域名是www.baidu.com如果一臺服務(wù)器有多個網(wǎng)站，服務(wù)器就需要通過Host來區(qū)分瀏覽器請求的是哪個網(wǎng)站。
3、服務(wù)器響應(yīng)
在Response Header中點(diǎn)擊 view source 顯示服務(wù)器返回的原始響應(yīng)數(shù)據(jù)
HTTP響應(yīng)分為Header和Body兩部分（Body是可選項(xiàng)），我們在Network中看到的Header最重要的幾行如下：
HTTP/1.1 200 OK
200表示一個成功的響應(yīng)，后面的OK是說明。
如果返回的不是200，那么往往有其他的功能，例如：
????失敗的響應(yīng)有：
????◆404 Not Found：網(wǎng)頁不存在
????◆500 Internal Server Error：服務(wù)器內(nèi)部出錯
...等等...
Content-Type: text/html; charset=utf-8
Content-Type指示響應(yīng)的內(nèi)容，這里是text/html表示HTML文本。
注意：瀏覽器響應(yīng)的數(shù)據(jù)類型只能從content-type的值來判斷，而不是url地址中的文件后綴名
Content-Encoding: gzip
當(dāng)存在Content-Encoding時，Body數(shù)據(jù)是被壓縮的，最常見的壓縮方式是gzip，所以，看到Content-Encoding: gzip時，需要將Body數(shù)據(jù)先解縮，才能得到真正的數(shù)據(jù)。壓縮的目的在于減少Body的大小，加快網(wǎng)絡(luò)傳輸。
瀏覽器解析過程：
當(dāng)瀏覽器讀取到百度的HTML源碼后，它會解析HTML，顯示網(wǎng)頁，然后，根據(jù)HTML中的各種鏈接，再發(fā)送HTTP請求給百度服務(wù)
器，拿到相應(yīng)的圖片、視頻、Flash、JavaScript腳本、CSS等各種資
源，最終顯示出一個完整的完整。所以我們在Network下面能看到很多
額外的HTTP請求。
總結(jié)
步驟1：瀏覽器首先向服務(wù)器發(fā)送HTTP請求，請求包括：
方法：GET還是POST，GET僅請求資源，POST會附帶用戶數(shù)據(jù)；
路徑：/full/url/path；
域名：由Host頭指定：Host: www.sina.com
以及其他相關(guān)的Header；
如果是POST，那么請求還包括一個Body，包含用戶數(shù)據(jù)
步驟2：服務(wù)器向?yàn)g覽器返回HTTP響應(yīng)，響應(yīng)包括：
響應(yīng)代碼：200表示成功，3xx表示重定向，4xx表示客戶端發(fā)送的請求
有錯誤，5xx表示服務(wù)器端處理時發(fā)生了錯誤；
響應(yīng)類型：由Content-Type指定；
以及其他相關(guān)的Header；
通常服務(wù)器的HTTP響應(yīng)會攜帶內(nèi)容，也就是有一個Body，包含響應(yīng)的
內(nèi)容，網(wǎng)頁的HTML源碼就在Body中。
步驟3：如果瀏覽器還需要繼續(xù)向服務(wù)器請求其他資源，比如圖片，就再次發(fā)出HTTP請求，重復(fù)步驟1、2。
Web采用的HTTP協(xié)議采用了非常簡單的請求-響應(yīng)模式，從而大大簡化
了開發(fā)。當(dāng)我們編寫一個頁面時，我們只需要在HTTP請求中把HTML
發(fā)送出去，不需要考慮如何附帶圖片、視頻等，瀏覽器如果需要請求圖
片和視頻，它會發(fā)送另一個HTTP請求，因此，一個HTTP請求只處理
一個資源(此時就可以理解為TCP協(xié)議中的短連接，每個鏈接只獲取一
個資源，如需要多個就需要建立多個鏈接)
HTTP協(xié)議同時具備極強(qiáng)的擴(kuò)展性，雖然瀏覽器請求的 是 http://www.baidu.com 的首頁，但是百度在HTML中可以鏈接其他服務(wù)器 的資源，比如圖片或者視頻的url鏈接，從而將請求壓力分散到各個服務(wù)器上，并且，一個站點(diǎn)可以鏈接到 其他站點(diǎn)，無數(shù)個站點(diǎn)互相鏈接起來，就形成了World Wide Web，簡稱 WWW。
WSGI服務(wù)器
PythonWeb服務(wù)器網(wǎng)關(guān)接口（Python Web Server Gateway Interface，縮寫為WSGI)是Python應(yīng)用程序或框架和Web服務(wù)器之間的一種接口，已經(jīng)被廣泛接受, 它已基本達(dá)成它的可移植性方面的目標(biāo)。
當(dāng)我們使用Framework【開發(fā)框架】開發(fā)web應(yīng)用后，如何將web應(yīng)用和服務(wù)器聯(lián)系起來，讓服務(wù)器為客戶端提供服務(wù)是首要解決的問題，當(dāng)python的web架構(gòu)并不能匹配服務(wù)器時，就無法讓Server和Framework協(xié)同工作，但是WSGI服務(wù)器可以解決這個問題。
常見的WSGI服務(wù)器
uWSGI服務(wù)器
Tornado框架自帶的服務(wù)器
