1. 程式人生 > >Web基礎概念(http協議)

Web基礎概念(http協議)

目錄

HTTP和HTTPS

HTTP協議(HyperText Transfer Protocol,超文字傳輸協議):是一種釋出和接收 HTML頁面的方法。

HTTPS(Hypertext Transfer Protocol over Secure Socket Layer)簡單講是HTTP的安全版,在HTTP下加入SSL層。

SSL(Secure Sockets Layer 安全套接層)主要用於Web的安全傳輸協議,在傳輸層對網路連線進行加密,保障在Internet上資料傳輸的安全

Cookie、Session和瀏覽器的同源策略

HTTP請求方法(Get/Post)

序號   方法      描述
1     GET       Get長度限制為1024,特別快,不安全,在URL裡可見,URL提交引數以?分隔,多個引數用&連線,請求指定的頁面資訊,並返回實體主體。
2     HEAD      類似於get請求,只不過返回的響應中沒有具體的內容,用於獲取報頭
3     POST      長度一般無限制,由中介軟體限制,較慢,安全,URL裡不可見。請求的引數在資料包的請求body中
4     PUT       從客戶端向伺服器傳送的資料取代指定的文件的內容。
5     DELETE    請求伺服器刪除指定的頁面。
6     CONNECT   HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
7     OPTIONS   允許客戶端檢視伺服器的效能。
8     TRACE     回顯伺服器收到的請求,主要用於測試或診斷。

Get請求常見的URL編碼 

空格        %20 或 %A0 
'           %27      
"           %22       
#           %23   
%           %25    
&           %26          
*           %2A
+           %2B
,           %2C
-           %2D
/           %2F
\           %5C

get和post的區別

  • GET是從伺服器上獲取資料,POST是向伺服器傳送資料

  • GET請求引數顯示,都顯示在瀏覽器網址上,HTTP伺服器根據該請求所包含URL中的引數來產生響應內容,即“Get”請求的引數是URL的一部分。 例如: http://www.baidu.com/s?wd=Chinese

  • POST請求引數在請求體當中,訊息長度沒有限制而且以隱式的方式進行傳送,通常用來向HTTP伺服器提交量比較大的資料(比如請求中包含許多引數或者檔案上傳操作等),請求的引數包含在“Content-Type”訊息頭裡,指明該訊息體的媒體型別和編碼.

一次HTTP請求的過程

  1. 當用戶在瀏覽器的位址列中輸入一個URL並按回車鍵之後,瀏覽器會向HTTP伺服器傳送HTTP請求。HTTP請求主要分為“Get”和“Post”兩種方法。

  2. 當我們在瀏覽器輸入URL http://www.baidu.com 的時候,瀏覽器傳送一個Request請求去獲取 http://www.baidu.com 的html檔案,伺服器把Response檔案物件傳送回給瀏覽器。

  3. 瀏覽器分析Response中的 HTML,發現其中引用了很多其他檔案,比如Images檔案,CSS檔案,JS檔案。 瀏覽器會自動再次傳送Request去獲取圖片,CSS檔案,或者JS檔案。

  4. 當所有的檔案都下載成功後,網頁會根據HTML語法結構,完整的顯示出來了。

一次請求(Request)和回覆(Reply)的資料包

Request請求包

GET /test/  HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://www.baidu.com/index.php
Accept-Encoding: gzip, deflate, br
Accept-Language: zh,zh-CN;q=0.8,ar;q=0.6,zh-TW;q=0.4
Cookie: BAIDUID=AE4D1DA6B2D6689BB8C557B3436893E3:FG=1;BIDUPSID=AE4D1DA6B2D6689BB8C557B3436893E3; PSTM=1501466227;

1. GET            
   獲取當前主機該路徑下的資料
   HTTP/1.1是http協議的版本號

2. Host (主機和埠號)
Host:對應網址URL中的Web名稱和埠號,用於指定被請求資源的Internet主機和埠號,通常屬於URL的一部分。預設是80埠,如果是8080埠的話,則為: www.baidu.com:8080

3. Connection (連結型別)
Connection:表示客戶端與服務連線型別
    Client 發起一個包含 Connection:keep-alive 的請求,HTTP/1.1使用 keep-alive 為預設值。
    Server收到請求後:
        如果 Server 支援 keep-alive,回覆一個包含 Connection:keep-alive 的響應,不關閉連線;
        如果 Server 不支援 keep-alive,回覆一個包含 Connection:close 的響應,關閉連線。
    如果client收到包含 Connection:keep-alive 的響應,向同一個連線傳送下一個請求,直到一方主動關閉連線。
keep-alive在很多情況下能夠重用連線,減少資源消耗,縮短響應時間,比如當瀏覽器需要多個檔案時(比如一個HTML檔案和相關的圖形檔案),不需要每次都去請求建立連線。

4. Upgrade-Insecure-Requests (升級為HTTPS請求)
Upgrade-Insecure-Requests:升級不安全的請求,意思是會在載入 http 資源時自動替換成 https 請求,讓瀏覽器不再顯示https頁面中的http請求警報。
HTTPS 是以安全為目標的 HTTP 通道,所以在 HTTPS 承載的頁面上不允許出現 HTTP 請求,一旦出現就是提示或報錯。

5. User-Agent (瀏覽器名稱)

User-Agent:是客戶瀏覽器的名稱

6. Accept (傳輸檔案型別)
Accept:指瀏覽器或其他客戶端可以接受的MIME(Multipurpose Internet Mail Extensions(多用途網際網路郵件擴充套件))檔案型別,伺服器可以根據它判斷並返回適當的檔案格式。
舉例:
Accept: */*:表示什麼都可以接收。
Accept:image/gif:表明客戶端希望接受GIF影象格式的資源;
Accept:text/html:表明客戶端希望接受html文字。
Accept: text/html, application/xhtml+xml;q=0.9, image/*;q=0.8:表示瀏覽器支援的 MIME 型別分別是 html文字、xhtml和xml文件、所有的影象格式資源。
q是權重係數,範圍 0 =< q <= 1,q 值越大,請求越傾向於獲得其“;”之前的型別表示的內容。若沒有指定q值,則預設為1,按從左到右排序順序;若被賦值為0,則用於表示瀏覽器不接受此內容型別。
Text:用於標準化地表示的文字資訊,文字訊息可以是多種字符集和或者多種格式的;Application:用於傳輸應用程式資料或者二進位制資料。詳細請點選

7. Referer (頁面跳轉處)
Referer:表明產生請求的網頁來自於哪個URL,使用者是從該 Referer頁面訪問到當前請求的頁面。這個屬性可以用來跟蹤Web請求來自哪個頁面,是從什麼網站來的等。
有時候遇到下載某網站圖片,需要對應的referer,否則無法下載圖片,那是因為人家做了防盜鏈,原理就是根據referer去判斷是否是本網站的地址,如果不是,則拒絕,如果是,就可以下載;

8. Accept-Encoding(檔案編解碼格式)
Accept-Encoding:指出瀏覽器可以接受的編碼方式。編碼方式不同於檔案格式,它是為了壓縮檔案並加速檔案傳遞速度。瀏覽器在接收到Web響應之後先解碼,然後再檢查檔案格式,許多情形下這可以減少大量的下載時間。
舉例:Accept-Encoding:gzip;q=1.0, identity; q=0.5, *;q=0

如果有多個Encoding同時匹配, 按照q值順序排列,本例中按順序支援 gzip, identity壓縮編碼,支援gzip的瀏覽器會返回經過gzip編碼的HTML頁面。 如果請求訊息中沒有設定這個域伺服器假定客戶端對各種內容編碼都可以接受

9. Accept-Language(語言種類)
Accept-Langeuage:指出瀏覽器可以接受的語言種類,如en或en-us指英語,zh或者zh-cn指中文,當伺服器能夠提供一種以上的語言版本時要用到

10. Cookie (Cookie)
Cookie:瀏覽器用這個屬性向伺服器傳送Cookie。Cookie是在瀏覽器中寄存的小型資料體,它可以記載和伺服器相關的使用者資訊,也可以用來實現會話功能,以後會詳細講。

11. Accept-Charset(字元編碼)
Accept-Charset:指出瀏覽器可以接受的字元編碼。
舉例:Accept-Charset:iso-8859-1,gb2312,utf-8

    ISO8859-1:通常叫做Latin-1。Latin-1包括了書寫所有西方歐洲語言不可缺少的附加字元,英文瀏覽器的預設值是ISO-8859-1.
    gb2312:標準簡體中文字符集;
    utf-8:UNICODE 的一種變長字元編碼,可以解決多種語言文字顯示問題,從而實現應用國際化和本地化。
如果在請求訊息中沒有設定這個域,預設是任何字符集都可以接受。

12. Content-Type (POST資料型別)
Content-Type:POST請求裡用來表示的內容型別。
舉例:Content-Type = Text/XML; charset=gb2312:
指明該請求的訊息體中包含的是純文字的XML型別的資料,字元編碼採用“gb2312”。

Reply回覆包

HTTP/1.1 200 OK
Date: Fri, 05 Oct 2018 01:35:48 GMT
Server: Apache/2.4.23 (Win32) OpenSSL/1.0.2j PHP/5.4.45
X-Powered-By: PHP/5.4.45
Expires: Tue, 23 Jun 2009 12:00:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Content-Length: 5212
Connection: close
Content-Type: text/html;charset=utf-8

1. HTTP/1.1  200 OK

  • HTTP/1.1 是http版本號  
  • 200 OK 是狀態碼 

200 頁面正常
301,302 重定向
400 http協議錯誤     403 禁止訪問       404 頁面不存在
500 頁面的動態程式碼有錯誤         502 響應超時

2. Date: Fri, 05 Oct 2018 01:35:48 GMT  

   伺服器回覆資料時的日期和時間

3. Server: Apache/2.4.23 (Win32) OpenSSL/1.0.2j PHP/5.4.45

  伺服器的Web伺服器型別,中介軟體等

4. Content-Length: 5212

  回覆的資料包的長度
5. Connection: close

  連結型別,不支援長連結,所以關閉
6. Content-Type: text/html;charset=utf-8

  回覆的資料型別,html格式的,utf8編碼

HTTP認證

Basic基本認證

BASIC認證概述
當一個客戶端向HTTP伺服器進行資料請求時,如果客戶端未被認證,則HTTP伺服器將通過基本認證過程對客戶端的使用者名稱及密碼進行驗證,以決定使用者是否合法。客戶端在接收到HTTP伺服器的身份認證要求後,會提示使用者輸入使用者名稱及密碼,然後將使用者名稱及密碼以BASE64加密,加密後的密文將附加於請求資訊中, 如當用戶名為anjuta,密碼為:123456時,客戶端將使用者名稱和密碼用“:”合併,並將合併後的字串用BASE64加密為密文,並於每次請求資料時,將密文附加於請求頭(Request Header)中。HTTP伺服器在每次收到請求包後,根據協議取得客戶端附加的使用者資訊(BASE64加密的使用者名稱和密碼),解開請求包,對使用者名稱及密碼進行驗證,如果使用者名稱及密碼正確,則根據客戶端請求,返回客戶端所需要的資料;否則,返回錯誤程式碼或重新要求客戶端提供使用者名稱及密碼。
 
BASIC認證的過程
基本認證步驟:

  1. 客戶端訪問一個受http基本認證保護的資源。
  2. 伺服器返回401狀態,要求客戶端提供使用者名稱和密碼進行認證。(驗證失敗的時候,響應頭會加上WWW-Authenticate: Basic realm="請求域"。)(401 Unauthorized   WWW-Authenticate: Basic realm="WallyWorld")
  3. 客戶端將輸入的使用者名稱密碼用Base64進行編碼後,採用非加密的明文方式傳送給伺服器。Authorization: Basic xxxxxxxxxx.
  4. 伺服器將Authorization頭中的使用者名稱密碼解碼並取出,進行驗證,如果認證成功,則返回相應的資源。如果認證失敗,則仍返回401狀態,要求重新進行認證。

優點:
基本認證的一個優點是基本上所有流行的網頁瀏覽器都支援基本認證。基本認證很少在可公開訪問的網際網路網站上使用,有時候會在小的私有系統中使用(如路由器網頁管理介面)。後來的機制HTTP摘要認證是為替代基本認證而開發的,允許金鑰以相對安全的方式在不安全的通道上傳輸。
 
缺點:
雖然基本認證非常容易實現,但該方案建立在以下的假設的基礎上,即:客戶端和伺服器主機之間的連線是安全可信的。特別是,如果沒有使用SSL/TLS這樣的傳輸層安全的協議,那麼以明文傳輸的金鑰和口令很容易被攔截。該方案也同樣沒有對伺服器返回的資訊提供保護。現存的瀏覽器儲存認證資訊直到標籤頁或瀏覽器被關閉,或者使用者清除歷史記錄。HTTP沒有為伺服器提供一種方法指示客戶端丟棄這些被快取的金鑰。這意味著伺服器端在使用者不關閉瀏覽器的情況下,並沒有一種有效的方法來讓使用者登出。
 
特記事項:
1、Http是無狀態的,同一個客戶端對同一個realm內資源的每一個訪問會被要求進行認證。
2、客戶端通常會快取使用者名稱和密碼,並和authentication realm一起儲存,所以,一般不需要你重新輸入使用者名稱和密碼。
3、以非加密的明文方式傳輸,雖然轉換成了不易被人直接識別的字串,但是無法防止使用者名稱密碼被惡意盜用。雖然用肉眼看不出來,但用程式很容易解密。

Token認證