openstack 之~keystone之HTTP協議

時間 2019-11-18

標籤 openstack keystone http 協議欄目 HTTP/TCP 简体版

原文原文鏈接

第一：爲何學習HTTP協議？

1.http協議就是通訊的雙方共同遵照的規則。無規矩不成方圓javascript

2.openstack中各組件是基於restful api通訊的，restful api能夠單純的理解爲一個url地址:http://www.cnblogs.com/ylqh/p/6295088.htmlhtml

於是無論研究openstack內的任何組件，都離不開http協議，要想成爲一名合格的openstack架構師或者openstack開發工程師，這是必經之路java

第二：用戶經過瀏覽器上網過程

用戶上網基於客戶端-服務端架構。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。python

1.保證web Server運行，Client運行瀏覽器軟件web

2.用戶在client的瀏覽器中輸入http://www.cnblogs.com/api

3.客戶端瀏覽器處理http://www.cnblogs.com/,發起查詢本地DNS操做，將www.cnblog.com解析爲42.121.252.58瀏覽器

　　　　（穿插）DNS的過程是這樣的：首先咱們知道咱們本地的機器上在配置網絡時都會填寫DNS，這樣本機就會把這個url發給這個配置的DNS服務器，若是可以找到相應的url則返回其ip，不然該DNS將繼續將該解析請求發送給上級DNS，整個DNS能夠看作是一個樹狀結構，該請求將一直髮送到根直到獲得結果。如今已經擁有了目標ip和端口號，這樣咱們就能夠打開socket鏈接了。緩存

4.客戶端瀏覽器發送http請求http://42.121.252.58/index.html (注意：80是web服務器的默認端口,index.html是默認的請求的資源)安全

5.服務端web服務收到該http的request請求頭，從請求頭中獲取客戶端的方法GET/POST.../index.html這個路徑，及客戶端請求的其餘相關信息服務器

6.服務端web服務根據取得的信息,回覆respone響應頭

響應頭中包含：

響應代碼：200表示成功，3xx表示重定向，4xx表示客戶端發送的請求有錯誤，5xx表示服務器端處理時發生了錯誤；

響應類型：由Content-Type指定；

以及其餘相關的Header；

一般服務器的HTTP響應會攜帶內容，也就是有一個Body，包含響應的內容，網頁的HTML源碼就在Body中，壓縮後返回給客戶端。

7.客戶端瀏覽器收到服務端發來的數據,解壓後解析html內容，用戶就看到網頁內容了

8.html內可能嵌套其餘的連接，比方說圖片、視頻、javascript腳本，flash等，客戶端瀏覽器會繼續發起http請求來獲取它們。這樣來自圖片和視頻的壓力就被分散到各個服務器，一個站點由無數個站點相互鏈接起來，就造成了World Wide Web，簡稱WWW。

綜上，其實就是一次http請求-響應的流程

第三：HTTP協議詳解

part1：http協議概述

協議是指計算機通訊網絡中兩臺計算機之間進行通訊所必須共同遵照的規定或規則，超文本傳輸協議(HTTP)是一種通訊協議，它容許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。

HTTP協議，即超文本傳輸協議(Hypertext transfer protocol)。是一種詳細規定了瀏覽器和萬維網(WWW = World Wide Web)服務器之間互相通訊的規則，經過因特網傳送萬維網文檔的數據傳送協議。

HTTP協議是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。

HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。

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

特色：

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

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

part2：http請求協議

根據HTTP標準，HTTP請求可使用多種請求方法。

請求格式：

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

瀏覽器發送給服務器的內容就這個格式的，若是不是這個格式服務器將沒法解讀！

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。

GET：請求指定的頁面信息，並返回實體主體

HEAD：相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭

POST：向指定的資源提交數據進行處理請求（提交表單或者上傳文件等）。數據被包含在請求體中。post請求可能會致使新的資源創建或已有的資源修改

HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

OPTIONS:容許客戶端查看服務器的性能

PUT：從客戶端向服務器傳送的數據取代指定的文檔內容

DELETE：請求服務器刪除指定的頁面

TRACE：回顯服務器收到的請求，主要用於測試或者診斷

CONNECT：HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。

詳細介紹get與post的

3.1：get請求

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

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

GET / HTTP/1.1　　　　　　　　　　GET請求，請求服務器路徑 http：//www.cnblog.com/,協議爲1.1
Host: www.cnblogs.com 　　　　　 請求主機名爲www.cnblogs.com;
Connection: keep-alive         客戶端支持的連接方式，保持一段時間的連接，默認爲3000ms；　　　　　　　　
Cache-Control: no-cache        設置網頁緩存的使用方法，no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8   告訴服務器，當前客戶端能夠接收的文檔類型，其實這裏包含*/*，就表示什麼均可以接收

Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36   與瀏覽器和OS相關的信息。有些網站會顯示用戶的系統版本和瀏覽器版本信息，這些都是經過獲取User-Agent頭信息而來的
Accept-Encoding: gzip, deflate, sdch   支持的壓縮格式。數據在網絡中傳遞時，可能服務器會把數據壓縮後再發送；
Accept-Language: zh-CN,zh;q=0.8     當前客戶端支持的語言，能夠在瀏覽器的工具口選項中找到語言相關信息
Cookie: AJSTAT_ok_times=2; __gads=ID=a8d50d555d273ea1:T=1471706765:S=ALNI_MYq_N5OuQbl1g04h0K_EB2dkbuDGg; CNZZDATA1257933522=462904915-1474644595-http%253A%252F%252Fzzk.cnblogs.com%252F%7C1474644595; Hm_lvt_88e110cc097c67c394f60bd3cf28fe1d=1480609307,1480690239; CNZZDATA3820487=cnzz_eid%3D769726809-1480609172-null%26ntime%3D1480690318; bdshare_firstime=1482637005632; sc_is_visitor_unique=rx9614694.1482854505.4BB3B56595534F38D9FB4F9D4E7F00A7.1.1.1.1.1.1.1.1.1; SyntaxHighlighter=python; .CNBlogsCookie=83971A2955426E5058FE012AA26E9962B77107E9131631A3CF4F83AF75841F628FE521A8EFD5884DB85BDE3AC07BE5744B4BED650DC98B7276B94E5B091D1D0915D9B882C3F06DFDF275FDC90343827300FA7160; _ga=GA1.2.1053365510.1445657028; CNZZDATA1684828=cnzz_eid%3D151763049-1485872317-null%26ntime%3D1485872337; __utma=226521935.1053365510.1445657028.1485873377.1485873377.1; __utmc=226521935; __utmz=226521935.1485873377.1.1.utmcsr=baidu|utmccn=(organic)|utmcmd=organic

3.2：post請求
(1) 數據不會出如今地址欄中
(2) 數據的大小沒有上限
(3) 有請求體
(4) 請求體中若是存在中文，會使用URL編碼！

<!DOCTYPE html>
<html>
<body>
<form method="post">
用戶名:<br>
<input type="text" name="username">
<br>
密碼:<br>
<input type="text" name="password">
<input type="submit" value="登陸">
</form>
</body>
</html>

咱們都知道Http協議中參數的傳輸是"key=value"這種簡直對形式的，若是要傳多個參數就須要用「&」符號對鍵值對進行分割。如"?name1=value1&name2=value2"，這樣在服務端在收到這種字符串的時候，會用「&」分割出每個參數，而後再用「=」來分割出參數值。

針對「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」，這樣服務端會把緊跟在「%」後的字節當成普通的字節，就是不會把它當成各個參數或鍵值對的分隔符。

POST請求是能夠有體的，而GET請求不能有請求體。

Referer: http://localhost:61070/untitled/post_test.html：請求來自哪一個頁面，例如你在博客園上點擊連接到了這裏，那麼Referer:http://www.cnbolgs.com；若是你是在瀏覽器的地址欄中直接輸入的地址，那麼就沒有Referer這個請求頭了；
Content-Type: application/x-www-form-urlencoded：表單的數據類型，說明會使用url格式編碼數據；url編碼的數據都是以「%」爲前綴，後面跟隨兩位的16進制。
Content-Length:49：請求體的長度，這裏表示13個字節。
username=‘張佔領’：請求體內容！

part4：響應協議

4.1：響應內容：

消息協議的版本、成功或者錯誤編碼、服務器信息、實體元信息以及必要的實體內容。根據響應類別的類別，服務器響應裏能夠含實體內容，但不是全部的響應都有實體內容

第一行爲狀態行：HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF

　　HTTP- Version表示HTTP版本，例如爲HTTP/1.1。Status- Code是結果代碼，用三個數字表示。Reason-Phrase是個簡單的文本描述，解釋Status-Code的具體緣由。Status-Code用於機器自動識別，Reason-Phrase用於人工理解。Status-Code的第一個數字表明響應類別，可能取5個不一樣的值。後兩個數字沒有分類做用。Status-Code的第一個數字表明響應的類別，後續兩位描述在該類響應下發生的具體情況，具體請參見：HTTP狀態碼

　　content-type: text/html 返回時文本格式、html文件

Server:Pycharm 5.0.4：服務器的版本信息
date: Wed, 01 Feb 2017 04:11:17 GMT：響應的時間，這可能會有8小時的時區差；
cache-control：private，must-revalidate 詳細介紹：

網頁的緩存是由HTTP消息頭中的「Cache-control」來控制的，常見的取值有private、no-cache、max-age、must-revalidate等，默認爲private。其做用根據不一樣的從新瀏覽方式分爲如下幾種狀況：

（1） 打開新窗口
值爲private、no-cache、must-revalidate，那麼打開新窗口訪問時都會從新訪問服務器。
而若是指定了max-age值，那麼在此值內的時間裏就不會從新訪問服務器，例如：
Cache-control: max-age=5(表示當訪問此網頁後的5秒內再次訪問不會去服務器)

（2） 在地址欄回車
值爲private或must-revalidate則只有第一次訪問時會訪問服務器，之後就再也不訪問。
值爲no-cache，那麼每次都會訪問。
值爲max-age，則在過時以前不會重複訪問。

（3） 按後退按扭
值爲private、must-revalidate、max-age，則不會重訪問，
值爲no-cache，則每次都重複訪問

（4） 按刷新按扭
不管爲什麼值，都會重複訪問

Cache-control值爲「no-cache」時，訪問此頁面不會在Internet臨時文章夾留下頁面備份。

View Code

Content-Type: text/html;charset=UTF-8：響應體使用的編碼爲UTF-8；
last-modified：Wed，01 Feb 2017 04:10:40 上次修改的時間
Content-Length: 209：響應體爲209字節

4.2：狀態碼

　　100: 客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者若是請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。

　　101: 服務器已經理解了客戶端的請求，並將經過Upgrade 消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade 消息頭中定義的那些協議。　　只有在切換新的協議更有好處的時候才應該採起相似措施。例如，切換到新的HTTP 版本比舊版本更有優點，或者切換到一個實時且同步的協議以傳送利用此類特性的資源。

　 200：請求成功，瀏覽器會把響應體內容（一般是html）顯示在瀏覽器中；

404：請求的資源沒有找到，說明客戶端錯誤的請求了不存在的資源；

500：請求資源找到了，但服務器內部出現了錯誤；

302：重定向，當響應碼爲302時，表示服務器要求瀏覽器從新再發一個請求，服務器會發送一個響應頭Location，它指定了新請求的URL地址；

304：若是客戶端發送了一個帶條件的 GET 請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。　　該響應必須包含如下的頭信息：　　Date，除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵照這些規則，那麼代理服務器以及客戶端能夠自行將 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的同樣），緩存機制將會正常工做。　　ETag 和/或 Content-Location，假如一樣的請求本應返回200響應。　　Expires, Cache-Control，和/或Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。　　假如本響應請求使用了強緩存驗證，那麼本次響應不該該包含其餘實體頭；不然（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其餘實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。　　假如某個304響應指明瞭當前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，而且重複發送不包含限制條件的請求。　　假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映全部在響應中被更新的字段的值。

4.3：其餘相應頭

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

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

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

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

詳解：

Expires是個好玩意，若是服務器上的網頁常常變化，就把它設置爲-1，表示當即過時。若是一個網頁天天凌晨1點更新，能夠把Expires設置爲次日的凌晨1點。

當HTTP1.1服務器指定CacheControl = no-cache時，瀏覽器就不會緩存該網頁。

舊式 HTTP 1.0 服務器不能使用 Cache-Control 標題。
因此爲了向後兼容 HTTP 1.0 服務器，IE使用Pragma:no-cache 標題對 HTTP 提供特殊支持。
若是客戶端經過安全鏈接 (https://)/與服務器通信，且服務器在響應中返回 Pragma:no-cache 標題，
則 Internet Explorer不會緩存此響應。注意：Pragma:no-cache 僅當在安全鏈接中使用時才防止緩存，若是在非安全頁中使用，處理方式與 Expires:-1相同，該頁將被緩存，但被標記爲當即過時
header經常使用指令
header分爲三部分：
第一部分爲HTTP協議的版本(HTTP-Version)；
第二部分爲狀態代碼(Status)；
第三部分爲緣由短語(Reason-Phrase)。

// fix 404 pages:   用這個header指令來解決URL重寫產生的404 header 
header('HTTP/1.1 200 OK');   

// set 404 header:   頁面沒找到
header('HTTP/1.1 404 Not Found');   

//頁面被永久刪除，能夠告訴搜索引擎更新它們的urls
// set Moved Permanently header (good for redrictions)   
// use with location header   
header('HTTP/1.1 301 Moved Permanently');  

// 訪問受限
header('HTTP/1.1 403 Forbidden');

// 服務器錯誤
header('HTTP/1.1 500 Internal Server Error');

// 重定向到一個新的位置
// redirect to a new location:   
header('Location: http://www.sina.com.cn);   

延遲一段時間後重定向
// redrict with delay:   
header('Refresh: 10; url=http://www.sina.com.cn');   
print 'You will be redirected in 10 seconds';   

// 覆蓋 X-Powered-By value
// override X-Powered-By: PHP:   
header('X-Powered-By: PHP/4.4.0');   
header('X-Powered-By: Brain/0.6b');   

// 內容語言 (en = English)
// content language (en = English)   
header('Content-language: en');   

//最後修改時間(在緩存的時候能夠用到)
// last modified (good for caching)   
$time = time() - 60; // or filemtime($fn), etc   
header('Last-Modified: '.gmdate('D, d M Y H:i:s', $time).' GMT');   

// 告訴瀏覽器要獲取的內容尚未更新
// header for telling the browser that the content   
// did not get changed   
header('HTTP/1.1 304 Not Modified');   

// 設置內容的長度 (緩存的時候能夠用到):
// set content length (good for caching):   
header('Content-Length: 1234');   

// 用來下載文件:
// Headers for an download:   
header('Content-Type: application/octet-stream');   
header('Content-Disposition: attachment; filename="example.zip"');   
header('Content-Transfer-Encoding: binary');   

// 禁止緩存當前文檔:
// load the file to send:readfile('example.zip');   
// Disable caching of the current document:   
header('Cache-Control: no-cache, no-store, max-age=0, must-revalidate');   
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');    

// 設置內容類型:
// Date in the pastheader('Pragma: no-cache');   
// set content type:   
header('Content-Type: text/html; charset=iso-8859-1');   
header('Content-Type: text/html; charset=utf-8');   
header('Content-Type: text/plain');   

// plain text file   
header('Content-Type: image/jpeg');    

// JPG picture   
header('Content-Type: application/zip');    

// ZIP file   
header('Content-Type: application/pdf');    

// PDF file   
header('Content-Type: audio/mpeg');    

// Audio MPEG (MP3,...) file   
header('Content-Type: application/x-shockwave-flash');    

// 顯示登陸對話框，能夠用來進行HTTP認證
// Flash animation// show sign in box   
header('HTTP/1.1 401 Unauthorized');   
header('WWW-Authenticate: Basic realm="Top Secret"');   
print 'Text that will be displayed if the user hits cancel or ';   
print 'enters wrong login data';?>

View Code

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.