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：[e-mail]
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	服務器收到的請求是其無法支持的版本（早期版本）

 

 

　　今天更新到這里，最近准備期末考，考完會好好寫學習筆記，一起加油～～～