一文詳解HTTP協議

HTTP協議

在這裏插入圖片描述
http協議一般是由一個請求報文和一個迴應報文所組成。
一個HTTP請求報文由四個部分組成:請求行、請求頭部、空行、請求數據。
上圖所示,是請求報文的樣式:

一般是由:請求方法(post/get/head) 空格 統一資源標識符URI 空格  HTTP版本號  換行
         HTTP頭部結構
         空行
         請求數據

對應的我們可以看一段http報文:

POST /search HTTP/1.1  
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, 
application/msword, application/x-silverlight, application/x-shockwave-flash, */*  
Referer: http://www.google.cn/  
Accept-Language: zh-cn  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)  
Host: www.google.cn 
Connection: Keep-Alive  
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g; 
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r  

hl=zh-CN&source=hp&q=domety

可以看出HTTP頭部的格式由以下幾部分組成:

  • Host: 請求接受服務器的地址,可以IP或者域名
Host: www.google.cn
  • Referer:客戶機通過這個頭告訴服務器,它是從哪個資源來訪問服務器的(防盜鏈)。包含一個URL,用戶從該URL代表的頁面出發訪問當前請求的頁面。
Referer: http://www.google.cn/  
  • Accept Charset :通知服務器可以發送的編碼格式
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, 
application/msword, application/x-silverlight, application/x-shockwave-flash, */* 
  • User - Agent :發送請求的應用名稱
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld) 
  • Connection:指定與連接相關的屬性
Connection: Keep-Alive  ,表示長連接
  • Accept Language:通知服務器可以發送的語言
Accept-Language: zh-cn 
  • Accept Enconding:通知服務器可以發送的數據壓縮格式
Accept-Encoding: gzip, deflate 
  • Cookie:客戶機通過這個頭可以向服務器帶數據,這是最重要的請求頭信息之一。
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g; 
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r  

在這裏插入圖片描述
HTPP響應報文:
在這裏插入圖片描述
**協議版本:**HTTP1.0/1.1(提供長連接服務);
狀態碼:

  • 1** 請求已經收到繼續處理;
  • 2** 表示成功;
  • 3** 表示資源重定向;
  • 4** 表示客戶端請求出錯;
  • 5** 表示服務器端出錯;

常用狀態碼:

  • 200:客戶端請求成功,繼續;
  • 201:請求已經被實現,而且一個資源已經依據請求的需要而建立;
  • 202:已經接受請求,但請求並未處理完成;
  • 301:永久重定向;
  • 302:臨時重定向;
  • 304:未修改,服務器返回此狀態碼時,不會返回任何資源。客戶端通常會緩存已經訪問過的資源,通過提供一個頭信息指出客戶端希望只返回在指定日期之後修改的資源;
  • 400:客戶端語法有錯誤,服務器無法理解;
  • 403:服務器拒絕提供服務;
  • 404:客戶端請求資源不存在;
  • 408:請求超時;
  • 500:服務器內部錯誤;
  • 501:服務器不支持的請求;
  • 502:作爲網關或者代理服務器,從遠程服務器收到了一個無效響應;
  • 503:由於超載或者系統維護,服務器暫時無法處理客戶端的請求。
    響應頭部:
  • Sever:服務器應用軟件的名稱和版本;
  • Content-Type:響應正文的類型;
  • Content-Length:響應正文的長度;
  • Content-Charset:響應正文所使用的字符集編碼;
  • Content-Encoding:響應正文所使用的數據壓縮格式;
  • Content-Language:響應正文所使用的語言;
    在這裏插入圖片描述

詳解HTTP

HTTP與HTTPS

https其實HTTP協議和SSL協議加在一起的協議,端口號爲443,http端口號爲80.SSL協議可以爲基於TCP協議的一切應用層協議提供服務。

這裏拓展一下,基於TCP協議的應用層協議有FTP(文本傳輸協議,端口20或者21),talent(遠程連接協議, 端口號23),SMTP(郵件傳輸協議 25);
基於UDP的應用層協議主要TFTP(簡單文件傳輸協議,端口號爲69),DNS(域名解析協議),IP電話,流式多媒體通信。

SSL
主要提供數據加密,數據完整性,身份驗證機制來保證數據傳輸過程中的安全;

  • 數字簽名:通過非對稱的加密算法驗證對端的身份,私鑰加密,公鑰解密,如果能夠被髮送方的公鑰解開,接收方就可以認定這段消息是由發送方傳遞過來的;
  • 數據的加密:通過對稱加密,實現數據的加解密過程,對稱加密算法有AES,3DES,DES;利用對稱加密算法進行數據加密之前需要在通信兩端部署相同的密鑰。
  • 消息完整性驗證:利用摘要算法(也就是MAC算法),利用MAC算法,算出消息的MAC值,並將其加在消息之後一起傳送給接收方;接收方接到後,利用同樣的密鑰和MAC算法算出消息的MAC值,並和原消息進行比對,如果兩者一致,則說明報文沒有改變,否則則說明在傳輸過程中報文被修改,接收者將丟棄該報文;
  • 利用非對稱加密保證公鑰本身的安全:對稱加密算法和MAC算法都需要通信雙方擁有相同的鑰匙,因此SSL利用非對稱加密算法來保證通信雙方的公鑰安全,以保證第三方無法獲取該密鑰。原理是利用SSL服務器的公鑰加密加密密鑰,將加密後的密鑰發給SSL服務器,此時只有服務器可以用自己的私鑰解開該消息,得到對稱加密算法和MAC算法所需要的公鑰。(這裏非對稱加密算法有RSA算法);
  • 數字證書:那麼又有一個問題,我們怎麼保證SSL服務器的公鑰順利被客戶端拿到手呢?此時需要一個權威機構來下發這個公鑰,這個機構就是CA,CA簽發數字證書,裏面包含了用戶的公鑰以及其身份信息,並由CA保證其數字證書的真實性。

接下來看一下HTTPS協議完整流程:
在這裏插入圖片描述
總結:由於https協議需要申請CA證書,因此需要一定費用;但是對於HTTP的明文傳輸,https的安全性強;端口號http80,https443;http的連接很簡單,是無狀態的,https協議是SSL+http協議構建的,安全。

面試問題

URI和URL的關係?

**URI(uniform resource identifier)**統一資源標識符,用來標識唯一的一個資源,是一個通用的概念。

URI包括兩個子集:URN和URL

  1. URN標識名稱,通過描述資源的名字來標識資源,URN即使資源的位置發生變動,URN也不會變化;
  2. URL標識位置(地址),通過資源的位置來標識資源。基本的URL格式爲 “協議://IP地址/路徑和文件名”,如:ftp://ftp.is.co.za/rfc/rfc1808.txt
    URL對於我們而言,就是將URL輸入到瀏覽器地址欄上就可以訪問到對應資源。

HTTP版本

在HTTP/1.0中默認使用的是短鏈接,也就是說,瀏覽器和服務器每進行一次HTTP操作,就需要建立一次連接,但是任務結束,連接就會被中斷;如果客戶端瀏覽器訪問的某個HTML或者其他類型的Web頁中包含有其他的Web資源,如JS,圖像文件,CSS等,就會建立一個HTTP會話;

但從HTTP/1.1起,默認使用長連接,用以保持連接特性,使用長連接的HTTP協議,會有響應頭加入連接方式:Connection:keep-alive

在使用長連接的情況下,當一個網頁打開完成後,客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個服務器上的網頁,會繼續使用這一條已經建立的連接。keep-alive不會永久保持連接,他又一個保持的時間,可以在不同的服務器軟件中設定這個時間。

瀏覽器輸入一個網址,運行過程

1. 查詢DNS,獲取域名所對應的IP地址

1.1 檢查瀏覽器緩存,檢查本地hosts文件中是否有這個網址的映射,如果有,就調用這個IP地址映射,解析完成;
1.2 如果沒有,則查找本地DNS解析器緩存是否有這個網址的映射,如果有,就調用這個IP地址映射,解析完成;
1.3.如果沒有,則查找填寫或分配的首選DNS服務器,成爲本地DNS服務器(LDNS)。服務器接到查詢時,如果要查詢的域名包含在本地配置的區域資源中,返回解析結果,查詢結束,此結果具有權威性。如果要查詢的域名不由本地的DNS服務器區域解析,但服務器緩存了此網址的映射關係,返回解析結果,查詢結束,此結果不具有權威性;(LDNS一般在你的城市的某個角落,距離你不會很遠,並且這臺服務器的性能很好,一般都會緩存域名解析結果)
1.4如果本地DNS服務器也失敗:
如果採用轉發模式(迭代),本地DNS就把請求發送給13臺根DNS,根DNS服務器收到請求後,會判斷這個域名(如.com)是誰來授權管理,並返回一個頂級域名服務器的IP,本地DNS服務器收到頂級域名服務器的IP後,繼續向該頂級域名服務器IP發送請求,該服務器如果無法解析,則會找到負責這個域名的下一級DNS服務器(權限域名服務器)的IP給本地DNS服務器,循環往復直至查到映射,將解析結果返回到本地DNS服務器,再由本地DNS服務器返回解析結果,查詢完成。

採用遞歸:此DNS服務器就會把請求轉至上一級DNS服務器,如果上一級DNS服務器不能解析,則繼續向上請求,最終解析結果依次返回本地DNS服務器,本地DNS服務器在返回給客戶機,查詢完成。

2. 得到目標服務器的IP地址及端口號(http 80端口 https 443端口),會調用系統庫函數socket,請求一個TCP流套接字,客戶端向服務器發送HTTP請求報文;

2.1 應用層:客戶端發送HTTP請求報文;
2.2傳輸層:加入源端口,目的端口,建立連接,實際發送數據之前,三次握手客戶端和服務器建立起一個TCP連接;
2.3 網絡層:加入IP頭,路由尋址;
2.4 數據鏈路層: 加入frame頭,傳輸數據;
2.5 物理層:物理傳輸比特。

4. 服務端經過物理層-數據鏈路層-網絡層-傳輸層-應用層,解析請求報文,發送HTTP響應報文;

5. 四次揮手,關閉連接

6. 客戶端解析HTTP響應報文,瀏覽器顯示HTML。

在DNS解析過程中,會出現一個DNS劫持攻擊,因爲一個DNS輸入進去,瀏覽器首先會查本地緩存,進而查找主機的HOST文件緩存,黑客可以修改HOST文件裏面對應的IP地址,將其改成自己的,這樣就會跳轉到一個假的頁面。
效果:無法達到正確的界面,或者跳轉到一個假的網址界面。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章