〖Web〗-- http協議

【http協議】

1、什麼是web服務
　　瀏覽器與網頁服務端發起的請求與迴應（返回的是一堆字符串，瀏覽器去渲染生成頁面！）都是 標準的CS模式 ---- bs模式：客戶端用瀏覽器便可，服務端須要本身去寫

　　http協議是創建在TCP協議的基礎上完成通訊解析的。通訊雙方都應該遵循一致的規則，才能真正的完成通訊！

2、http協議

　　HTTP（hypertext transport protocol），即超文本傳輸協議。這個協議詳細規定了瀏覽器和萬維網服務器之間互相通訊的規則。

　　HTTP就是一個通訊規則，通訊規則規定了客戶端發送給服務器的內容格式，也規定了服務器發送給客戶端的內容格式。其實咱們要學習的就是這個兩個格式！客戶端發送給服務器的格式叫「請求協議」；服務器發送給客戶端的格式叫「響應協議」。

特色：

• HTTP叫超文本傳輸協議，基於請求/響應模式的！
• HTTP是無狀態協議。

URL：統一資源定位符，就是一個網址：協議名://域名:端口/路徑，例如：http://www.baidu.com

3、請求協議（瀏覽器---->server）

請求協議的格式以下：

請求首行；  // 請求方式 請求路徑 協議和版本，例如：GET /*** HTTP/1.1
請求頭信息；// 請求頭名稱:請求頭內容，即爲key:value格式，例如：Host:127.0.0.1：8080
空行；     // 用來與請求體分隔開
請求體。   // GET沒有請求體，只有POST有請求體。

瀏覽器發送給服務器的內容就這個格式的，若是不是這個格式服務器將沒法解讀！在HTTP協議中，請求有不少請求方法，其中最爲經常使用的就是GET和POST。不一樣的請求方法之間有不一樣的區別。

3.1 GET請求

　　HTTP默認的請求方法就是GET，GET的注意點：
    　　 * 沒有請求體
    　　 * 數據必須在1K以內！
    　　 * GET請求數據會暴露在瀏覽器的地址欄中

GET請求經常使用的操做：
       1. 在瀏覽器的地址欄中直接給出URL，那麼就必定是GET請求
       2. 點擊頁面上的超連接也必定是GET請求
       3. 提交表單時，表單默認使用GET請求，但能夠設置爲POST

 

GET /favicon.ico HTTP/1.1
Host: 127.0.0.1:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.104 Safari/537.36 Core/1.53.2669.400 QQBrowser/9.6.10990.400
Accept: */*
Referer: http://127.0.0.1:8080/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

 

GET /favicon.ico HTTP/1.1：GET請求，GET以後爲請求服務器路徑，協議爲1.1；

Host:127.0.0.1：8080；請求的主機名爲127.0.0.1；

*User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.104 Safari/537.36 Core/1.53.2669.400 QQBrowser/9.6.10990.400；與瀏覽器和OS相關的信息。有些網站會顯示用戶的系統版本和瀏覽器版本信息，這都是經過獲取User-Agent頭信息而來的；

 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8：告訴服務器，當前客戶端能夠接收的文檔類型，其實這裏包含了*/*，就表示什麼均可以接收；

Accept-Language: zh-CN,zh;q=0.8：當前客戶端支持的語言，能夠在瀏覽器的工具選項中找到語言相關信息；

Accept-Encoding: gzip, deflate，sdch;支持的壓縮格式。數據在網絡上傳遞時，可能服務器會把數據壓縮後再發送；

Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7：客戶端支持的編碼；

Connection: keep-alive：客戶端支持的連接方式，保持一段時間連接，默認爲3000ms；

Cookie: JSESSIONID=369766FDF6220F7803433C0B2DE36D98：由於不是第一次訪問這個地址，因此會在請求中把上一次服務器響應中發送過來的Cookie在請求中一併發送去過；這個Cookie的名字爲JSESSIONID。

注意：

 

（1）請求首行 GET/favicon.ico HTTP/1.1（請求方式，版本，信息<把一些信息暴露在網址信息上>）
（2）請求頭信息

　　referer：初始源鏈接地址，能夠經過查詢此信息來判斷點擊來自於哪裏，是否被盜鏈!
　　Cookie：理解爲容器或是字典，可放多組鍵值對，是從瀏覽器發送給服務端，而後服務端添加信息以後，再返回給瀏覽器

　　產生緣由:http協議是一個無狀態的協議！就衍生了cookie進行信息保存！

　　客戶端接收到服務端傳回的信息後，服務端會先和客戶端創建3000毫秒的連接，超時以後會斷開連接。
（3）空行
（4）請求體（請求的數據）----get請求（把信息所有放到url中<有數據限制>）請求體不存在
　　　　　　　　　　　　　　　post請求：把請求所有放在請求體中！沒有數據限制

　　HTTP無狀態：無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。從另外一方面講，打開一個服務器上的網頁和你以前打開這個服務器上的網頁之間沒有任何聯繫。
　  若是你要實現一個購物車，須要藉助於Cookie或Session或服務器端API（如NSAPI and ISAPI）記錄這些信息，瀏覽器請求服務器結算頁面時同時將這些信息提交到服務器。
當你登陸到一個網站時，你的登陸狀態也是由Cookie或Session來「記憶」的，由於服務器並不知道你是否登陸。

優勢：服務器不用爲每一個客戶端鏈接分配內存來記憶大量狀態，也不用在客戶端失去鏈接時去清理內存，以更高效地去處理WEB業務
缺點：客戶端的每次請求都須要攜帶相應參數，服務器須要處理這些參數

容易混淆的誤區：
一、HTTP是一個無狀態的面向鏈接的協議，無狀態不表明HTTP不能保持TCP鏈接，更不能表明HTTP使用的是UDP協議（無鏈接）
二、從HTTP/1.1起，默認都開啓了Keep-Alive，保持鏈接特性，簡單地說，當一個網頁打開完成後，客戶端和服務器之間用於傳輸
HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接
三、Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間

 

3.2 POST請求

　　(1). 數據不會出如今地址欄中
　　(2). 數據的大小沒有上限
　　(3). 有請求體
　　(4). 請求體中若是存在中文，會使用URL編碼！例：username=%E5%BC%A0%E4%B8%89&password=123

 

爲何要進行URL編碼

    咱們都知道Http協議中參數的傳輸是"key=value"這種簡直對形式的，若是要傳多個參數就須要用「&」符號對鍵值對進行分割。如"?name1=value1&name2=value2"，這樣在服務端在收到這種字符串的時候，會用「&」分割出每個參數，而後再用「=」來分割出參數值。
例如百度：python學習，獲得的地址：https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=0&rsv_idx=1&tn=baidu&wd=python%E5%AD%A6%E4%B9%A0&rsv_pq=f8ce5b8c00029684&rsv_t=8ff4UqR3obt9JH5N9ScDtqS0MyEzUISGGfLb2MOLTzNjYrnNI85Ek%2B4LV8w&rqlang=cn&rsv_enter=1&rsv_sug3=13&rsv_sug1=11&rsv_sug7=100&rsv_sug2=0&inputT=3203&rsv_sug4=6308

針對「name1=value1&name2=value2」咱們來講一下客戶端到服務端的概念上解析過程: 
  上述字符串在計算機中用ASCII嗎表示爲： 
  6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532。 
   6E616D6531：name1 
   3D：= 
   76616C756531：value1 
   26：&
   6E616D6532：name2 
   3D：= 
   76616C756532：value2 
   服務端在接收到該數據後就能夠遍歷該字節流，首先一個字節一個字節的吃，當吃到3D這字節後，服務端就知道前面吃得字節表示一個key，再想後吃，若是遇到26，說明從剛纔吃的3D到26子節之間的是上一個key的value，以此類推就能夠解析出客戶端傳過來的參數。

   如今有這樣一個問題，若是個人蔘數值中就包含=或&這種特殊字符的時候該怎麼辦。 
好比說「name1=value1」,其中value1的值是「va&lu=e1」字符串，那麼實際在傳輸過程當中就會變成這樣「name1=va&lu=e1」。咱們的本意是就只有一個鍵值對，可是服務端會解析成兩個鍵值對，這樣就產生了奇異。

如何解決上述問題帶來的歧義呢？解決的辦法就是對參數進行URL編碼 
   URL編碼只是簡單的在特殊字符的各個字節前加上%，例如，咱們對上述會產生奇異的字符進行URL編碼後結果：「name1=va%26lu%3D」，這樣服務端會把緊跟在「%」後的字節當成普通的字節，就是不會把它當成各個參數或鍵值對的分隔符。

 

 

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:zh-CN,zh;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:127.0.0.1:8080
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

 

POST請求是能夠有體的（編寫的網站標籤），而GET請求不能有請求體。

Referer: 網址：請求來自哪一個頁面，例如你在百度上點擊連接到了這裏，那麼Referer:http://www.baidu.com；若是你是在瀏覽器的地址欄中直接輸入的地址，那麼就沒有Referer這個請求頭了；

Content-Type:  是指表單的數據類型，說明會使用url格式編碼數據；url編碼的數據都是以「%」爲前綴，後面跟隨兩位的16進制。

Content-Length:13：請求體的長度，這裏表示13個字節。

keyword=hello：請求體內容！hello是在表單中輸入的數據，keyword是表單字段的名字。

 

Referer的應用

Referer請求頭是比較有用的一個請求頭，它能夠用來作統計工做，也能夠用來作防盜鏈。
統計工做：我公司網站在百度上作了廣告，但不知道在百度上作廣告對咱們網站的訪問量是否有影響，那麼能夠對每一個請求中的Referer進行分析，若是Referer爲百度的不少，那麼說明用戶都是經過百度找到咱們公司網站的。
防盜鏈：我公司網站上有一個下載連接，而其餘網站盜鏈了這個地址，例如在我網站上的index.html頁面中有一個連接，點擊便可下載JDK7.0，但有某我的的微博中盜鏈了這個資源，它也有一個連接指向咱們網站的JDK7.0，也就是說登陸它的微博，點擊連接就能夠從我網站上下載JDK7.0，這致使咱們網站的廣告沒有看，但下載的倒是我網站的資源。這時可使用Referer進行防盜鏈，在資源被下載以前，咱們對Referer進行判斷，若是請求來自本網站，那麼容許下載，若是非本網站，先跳轉到本網站看廣告，而後再容許下載。

 

4、響應協議（server端---->瀏覽器）

4.一、響應協議的格式以下：

　　響應首行：

　　響應頭信息：（不寫的話，不少都是默認的！）

　　空行：

　　響應體：html標籤主體內容

　　響應內容是由服務器發送給瀏覽器的內容，瀏覽器會根據響應內容來顯示。遇到<img src=''>會開一個新的線程加載，因此有時圖片多的話，內容會先顯示出來，而後圖片才一張張加載出來。

Request URL:http://127.0.0.1:8080/
Request Method:GET
Status Code:201 OK
Remote Address:127.0.0.1:8080
Referrer Policy:no-referrer-when-downgrade

 HTTP/1.1 201 OK：響應協議爲HTTP1.1，狀態碼爲200，表示請求成功，OK是對狀態碼的解釋

 Server:服務器的版本信息；

 Content-Type: text/html;charset=UTF-8：響應體使用的編碼爲UTF-8；

 Content-Length: 724：響應體爲724字節；

 Set-Cookie: 響應給客戶端的Cookie；

 Date: 響應的時間，這可能會有8小時的時區差；

4.2　狀態碼

響應頭對瀏覽器來講很重要，它說明了響應的真正含義。例如200表示響應成功了，302表示重定向，這說明瀏覽器須要再發一個新的請求。

• 200：請求成功，瀏覽器會把響應體內容（一般是html）顯示在瀏覽器中；
• 403：禁止！服務器拒絕了請求訪問。
• 404：請求的資源沒有找到，說明客戶端錯誤的請求了不存在的資源；
• 500：請求資源找到了，但服務器內部出現了錯誤；
• 302：重定向，當響應碼爲302時，表示服務器要求瀏覽器從新再發一個請求，服務器會發送一個響應頭Location，它指定了新請求的URL地址；
• 304：自上一次請求，網頁未修改！具體執行見下圖！！！
  

 

  當用戶第一次請求index.html時，服務器會添加一個名爲Last-Modified響應頭，這個頭說明了
  index.html的最後修改時間，瀏覽器會把index.html內容，以及最後響應時間緩存下來。當用戶第
  二次請求index.html時，在請求中包含一個名爲If-Modified-Since請求頭，它的值就是第一次請
  求時服務器經過Last-Modified響應頭髮送給瀏覽器的值，即index.html最後的修改時間，
  If-Modified-Since請求頭就是在告訴服務器，我這裏瀏覽器緩存的index.html最後修改時間是這個,
  您看看如今的index.html最後修改時間是否是這個，若是仍是，那麼您就不用再響應這個index.html
  內容了，我會把緩存的內容直接顯示出來。而服務器端會獲取If-Modified-Since值，與index.html
  的當前最後修改時間比對，若是相同，服務器會發響應碼304，表示index.html與瀏覽器上次緩存的相
  同，無需再次發送，瀏覽器能夠顯示本身的緩存頁面，若是比對不一樣，那麼說明index.html已經作了修
  改，服務器會響應200。

 

         

 

4.3　其餘響應頭

告訴瀏覽器不要緩存的響應頭：

• Expires: -1；
• Cache-Control: no-cache；
• Pragma: no-cache；

自動刷新響應頭，瀏覽器會在3秒以後請求http://www.baidu.com：

• Refresh: 3;url=http://www.baidu.com 

4.4　HTML中指定響應頭

在HTMl頁面中可使用<meta http-equiv="" content="">來指定響應頭，例如在index.html頁面中給出<meta http-equiv="Refresh" content="3;url=http://www.baidu.com">，表示瀏覽器只會顯示index.html頁面3秒，而後自動跳轉到http://www.baidu.com.