HTTP協議（1）------->資源和URL

 

1.前言

 

　　最近在研究http，但願結合書本，對網上資料進行整合，用「人話」聊聊這個玩意兒～

　　計劃用近十篇文章，詳盡的說清楚如下一些問題：

1. URL和資源、HTTP報文是什麼東西？
2. HTTP是怎樣進行連接管理的？
3. HTTP有什麼結構（web服務器、代理、緩存、網關、HTTP-NG）？
4. 識別、認證和安全問題（客戶端的識別、cookie機制、基本認證機制、摘要認證）是怎麼作的？
5. HTTP的編碼和國際化的問題
6. 內容的發佈和分發（web主機託管、發佈系統、重定向與負載均衡、日誌使用與跟蹤）是怎麼運行的？

　　廢話就很少說了，這一章主要作一個簡單概述HTTP，而後講明白第一個問題！

 

2.  HTTP：web基礎

 

　　HTTP的做用就是把遍及全世界的web服務器上的信息（文本文件、HTML頁面、mpeg電影、音頻文件...資源）迅速搬遷到web瀏覽器(客戶端)上去。簡單作了個圖，可看出，http也就是一個數據傳輸協議，橋樑的做用。

Fig1. HTTP,Client,Server

 　　有幾個概念要弄清楚：

1. MIME type：  HTTP會給每一種要經過web瀏覽器的對象打上MIME類型的數據格式標籤;瀏覽器會根據不一樣的MIME類型來決定如何處理這個對象。
2. URI:  (Uniform Resource Identifier)統一資源標識符;世界範圍內惟一標識而且定位信息資源，有兩種形式：URL與URI;
3. URL：  (Uniform Resource Locator)統一資源定位符；（例如：https://www.cnblogs.com/Mairr/ 這就是一個URL啦！）
4. URN：  (Uniform Resource Name)統一資源名稱;（還在試用階段，如今仍是用URL，因此咱們會不加以區分URI和URL，直接認爲是同一個東西，其實URL只是URI的子集）

 

2.1  URL與資源

 

2.1.1  瀏覽互聯網的資源

 

　　舉個例子，咱們是怎麼經過URL瀏覽互聯網上的資源的，好比：https://pic.cnblogs.com/avatar/1194681/20171108220649.png

　　URL三連：　　怎麼作？（方案http://）---->在哪呢？（服務器位置pic.cnblogs.com）---->什麼東西？（資源路徑/avatar/1194681/20171108220649.png）;因此URL找到網上資源是經過上述三步完成的（方案---->主機---->路徑）。固然，方案不止是時HTTP一種，好比文件傳輸協議（FTP）、流視頻傳輸協議（rtsp）...

 

2.1.2  URL的語法

 

　　講的這麼專業，其實也就是URL三連嘛～

1. URL的方案----->使用什麼協議（HTTP，FTP、SMTP（郵件的傳輸協議））
2. 服務器的位置----->能夠經過主機名：www.cctv.com,也能夠經過IP地址加端口號：161.58.228.45:80（我隨便寫的一個，別介意）
3. 路徑

　　要說明的是URL分爲絕對URL和相對URL，剛纔聊的都是絕對URL。而相對URL只是一小個片斷會以基礎的URL完成轉換！以下圖所示：

 　　下面作個常見方案方式的總結，方便本身之後回看用～

方案	描述
http	超文本傳輸協議方案，除了沒有用戶名和密碼外其餘與通用的URL格式相符。若是省略了端口，就默認爲80。格式 http//<host>:<port>/<path>
https	與http基本同樣，惟一區別是https使用了SSL（安全套接層），SSL爲HTTP鏈接提供了端到端的加密機制。語法與http一致，默認端口號爲443。
ftp	文件傳輸協議URL能夠用來從FTP服務器上下載/上傳文件，而且獲取FTP服務器上的目錄結構。基本格式： ftp：//<user>:<password>@<host>:<port>/<path>
mailto	E-Mail地址傳輸協議，基本格式：mailto：<RFC-822-addr-spec>;示例： mailto：joe@joes-hardware.com
rtsp，rtspu	RTSP URL，是能夠經過實時流傳輸協議解析音頻、視頻的媒體資源標識符。基本格式： rtsp：//<user>:<password>@<host>:<port>/<path>
files	files表示指定主機（本地磁盤、網絡文件系統、）上能夠直接訪問的文件。若是省略主機名則表示本地主機;基本格式：files：//<host>/<path>
news	方案news用來訪問一些特定的文章或新聞組，他有一個獨特的性質：news URL自己不足對資源進行定位。基本格式： news:<newsgroup>
telnet	telnet用於訪問交互式業務。他表示的並非對象自身，而是可經過telnet協議訪問的交互時應用程序（資源）。基本格式：telnet：//<user>:<password>@<host>:<port>/

 

2.2  HTTP報文

 

2.2.1 web的結構組件

 

　　HTTP報文就是HTTP應用程序之間發送的數據。以前介紹了2個web應用程序（瀏覽器、服務器），他們之間如何相互發送報文來實現基本事物處理。接下來先簡單介紹（後面幾篇文章會很詳細的說明白）其餘的幾個比較重要的應用程序：

　　（1） 代理：位於客戶端與服務器之間的HTTP中間實體。代理用來接收全部客戶端的HTTP請求，並將請求轉發給服務器（可能會對請求修改以後進行轉發）。此外，代理還能夠對請求和響應進行過濾（好比，病毒檢測，未成年人不能看的東西也要濾掉！！！）。

 　　（2） 緩存：HTTP的倉庫，使經常使用頁面的副本能夠保存在離客戶端更近的地方。web緩存（Web cache）或者服務器緩存（proxy cache）是一種特殊的HTTP代理服務器，能夠將通過代理傳送的經常使用文檔複製保存起來。下一個請求同一文檔的客戶端就能夠享受副本的服務了。

　　（3） 網關（gateway）：一種特殊的服務器。

　　（4） 隧道（tunnel）：對HTTP通訊報文進行盲目轉發的特殊代理。HTTP隧道的一種常見用途是經過HTTP連接承載加密安全套接字層（SSL，Secure Sockets Layer）流量，這樣的SSL流量就能夠穿過只容許Web流量經過的防火牆了。

　　（5） agent代理：發起自動HTTP請求的半智能Web客戶端。用戶agent代理（簡稱：agent代理）是表明用戶發起的HTTP請求的客戶端程序。全部發布Web請求的應用程序都是HTTP Agent代理。例如：web瀏覽器就是一種HTTP Agent代理。

 

2.2.2  報文流和報文組成

 

　　（1） 報文流

　　報文是HTTP應用程序之間發送的數據塊。這些數據塊以一些文本形式的元信息（meta-information）開頭，描述了報文內容和含義，後面跟着可選的數據部分。HTTP使用「流入」和「流出」來描述事務處理的方向。報文流入源端服務器，工做完成後流回用戶的Agent代理中。HTTP報文像流水通常向下流動。以下圖所示：

　　(2) 報文的組成

　　每條報文包含一條來自客戶端的請求或者服務器端的響應。他們由三個部分組成：對報文進行描述的起始行、包含屬性的首部塊、包含主體部分。報文的主體是一個可選的數據塊。與起始行和首部不一樣的是主體能夠包含文本或者二進制數據，也能夠爲空。

　　報文分爲請求報文和響應報文。下面是格式：

請求報文格式	響應報文格式
<method> <request-URL> <version>	<version> <status> <reason-phrase>
<headers>	<headers>
<entity-body>	<entity-body>

　　下面是對各個部分的簡單描述：

• 方法（method）：客戶端對服務器資源執行的動做。如GET，HEAD，POST。
• 請求URL（request-URL）：命名了所請求的資源路徑。
• 版本（version）：報文所使用的HTTP版本，格式：HTTP/<major>.<minor>;其中，major是主版本號，minor是次版本號;都是整數。
• 狀態碼（status-code）：這三位數字描述請求過程當中所發生的狀況。（成功/出錯等）
• 緣由短語（reason-phrase）：數字狀態碼的可讀版本，包含行終止序列以前的全部文本。
• 首部（header）：能夠有0個或者多個首部，每一個首部包含一個名字，後面跟着一個冒號（：），而後是一個可選的空格，接着是一個值，最後一個CRLF（回車換行）。
• 實體的主體部分（entity-body）:實體的主體部分包含一個由任意數據組成的數據塊。並非全部報文都包含實體的主體部分，有時，報文只是以一個CRLF結束（後面文章會介紹實體）。

　　下面展現兩個請求和響應的報文demo：

 

2.2.3  報文的經常使用方法和狀態碼

 

 　　（1） 報文的經常使用方法

• GET：請求服務器發送某個資源;
• HEAD：與GET方法很相似，可是服務器在響應中只返回首部;
• PUT：與GET相反，PUT方法向服務器寫入文檔;
• POST：向服務器發送表單（html...）;
• TRACE：客戶端發送的請求可能要穿過防火牆、代理、網關...TRACE方法容許客戶端在最終將請求發送給服務器時，查看它變成的樣子;
• OPTIONS：OPTIONS方法請求WEB服務器告知其支持的各類功能。
• DELETE：請服務器刪除請求URL所指定的資源。

 

　　（2） 狀態碼

　　HTTP分爲5類狀態碼，這裏作一個簡單總結：（比較重要的狀態碼，後邊更新的文章會詳細介紹）

• 100～199---->信息性狀態碼

100	Continue	受到請求初始部分，請客戶端繼續。
101	Switching Protocols	服務器正在根據客戶端指定，將協議切換成Update首部所列的協議

•  200～299---->成功狀態碼

200	OK	請求沒問題，實體的主體部分包含了所請求的資源
201	Created	已建立對象的URL
202	Accepted	請求已被接受，但服務器還未對其執行任何動做
203	Non-Authoritative Information	實體首部包含的信息不是來源於源服務器，而是來自資源副本的一部分。
204	No Content	沒有實體的主體部分
205	Reset Content	另外一個用於瀏覽器代碼
206	Partial Content	成功執行了一個部分或者Range（範圍）的請求

•  300～399---->重定向狀態碼 （比較重要）

300	Multiple Choices	返回這個狀態碼時會返回一個選項列表;供客戶端選擇其須要的文檔頁碼/內容。
301	Moved Permenently	請求的URL已經被移除時使用。響應的Location首部中應該包含該資源如今所處的URL
302	Found	客戶端使用首部給出的URL臨時定位資源。未來的請求仍應使用老的URL
303	See Other	告訴客戶端應該使用另外一個URL來獲取資源。
304	Not Modified	資源未被修改。帶有這個狀態碼的響應不該該包含實體的主體部分。
305	Use Proxy	必須經過代理來訪問資源
306	（未使用）	當前未使用
307	Temporary Redirect	臨時定位資源。未來的請求應該使用老的URL

• 400～499：客戶端錯誤狀態碼

400	Bad request	告知客戶端它發送了一個錯誤的請求
401	Unauthorized	與適當的首部一塊兒返回，客戶端在獲取對資源的訪問權以前，對本身進行認證。
402	Payment Required	（已保留，可是未使用）
403	Forbidden	請求被服務器拒絕。
404	Not Found	服務器沒法找到一個請求的URL
405	Method Not Allowed	發起請求中帶有所請求的URL不支持的方法。
406	Not Acceptable	客戶端能夠指定參數來講明他們願意接收什麼類型的實體。
407	proxy Authentication Required	對資源進行認證的代理服務器
408	Request Timeout	客戶端請求完成時間過長，服務器能夠回送狀態碼關閉連接
409	Conflict	請求衝突
410	Gone	服務器曾經擁有這個資源
411	Length Required	服務器要求在請求報文中包含Content-Lenth首部時使用。
412	Precondition Failed	條件請求，條件失敗時候使用
413	Request Entity Too Large	客戶端發送實體主體部分比服務器可以處理的大。
414	Request URL Too Long	客戶端發送請求的URL比服務器可以處理的要長。
415	Unsupported Media Type	服務器沒法理解或者沒法支持客戶端請求
416	Requested Range Not Satisfiable	請求報文所請求資源不在指定範圍，吃範圍無效或者沒法知足
417	Exception Failed	服務器沒法知足請求的首部包含的指望

• 500～599：服務器錯誤狀態碼

500	Internal Server Error	服務器遇到一個妨礙爲請求提供服務的錯誤
501	Not Implemented	客戶端發起請求超出服務器的能力範圍
502	Bad' Gateway	做爲代理或者網關使用的服務器從請求響應連接上收到一條僞響應
503	Sevice Unacailable	服務器暫時沒法爲請求提供服務（未來能夠）
504	Gateway TimeOut	響應來自網關或者代理，在等待另外一服務器對其請求進行響應時超時了
505	HTTP Version Not Suppported	服務器收到的請求是其沒法支持的版本（早期版本）

 

 

　　今天更新到這裏，最近準備期末考，考完會好好寫學習筆記，一塊兒加油～～～