當前位置：首頁 > 人文社科 > 生活经验 >内容正文

生活经验

HTTP简介

發布時間：2023/11/27 生活经验 25 豆豆

生活随笔收集整理的這篇文章主要介紹了 HTTP简介小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

HTTP簡介

1.HTTP概述

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用于從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。它是一種請求/響應式的協議，客戶端在于服務器建立連接后，就可以向服務器端發送URL請求，這種請求被稱為HTTP請求，服務器端在接收到請求之后會做出響應，稱為HTTP響應。

HTTP是一個基于TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。

客戶端與服務器端在HTTP下的交互過程如下圖所示：

HTTP協議的特點：

（1）支持客戶端（瀏覽器就是一直web客戶端）/服務器端模式。

（2）簡單快速：客戶端向服務器端發送請求服務時，只需要傳送請求方式和路徑。常用的請求方式有GRT和POST等，每種方式規定了客戶端與服務器聯系的類型不同。由于HTTP比較簡單，使得HTTP服務器的程序規模較小，因而通信速度很快。

（3）靈活：HTTP允許傳輸任意類型的數據，正在傳輸的數據類型由Content-Type加以標記。

（4）無狀態：HTTP是無狀態協議。無狀態是值協議對于事物處理沒有記憶能力，如果后續處理需要前面的信息，則HTTP必須重傳，這可能導致每次連接傳送的數據量增大。

（5）支持B/S及C/S模式。

2.URL地址

　　在Internet上的web服務器中，每一個網頁文件都會用一個用于唯一標識其他位置的訪問標記符。這個訪問標記符被稱為URL（Uniform Resource Locator,統一資源定位符）。

　　在一個URL中，通常包含Web服務器的主機名、端口號、資源名以及所使用的網絡協議。例如：

http://www.itheima.com:80/idex.htmlhttp:表示傳輸數據所使用的協議
www.itheima.com：表示請求的服務主機名
80：表示請求的端口號
index.html:表示要請求的資源名稱

例：http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

從上面的URL可以看出，一個完整的URL包括以下幾部分：
　　1.協議部分：該URL的協議部分為“http：”，這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"后面的“//”為分隔符；

　　2.域名部分：該URL的域名部分為“www.aspxfans.com”。一個URL中，也可以使用IP地址作為域名使用；

　　3.端口部分：跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。端口不是一個URL必須的部分，如果省略端口部分，將采用默認端口；

　　4.虛擬目錄部分：從域名后的第一個“/”開始到最后一個“/”為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”；

　　5.文件名部分：從域名后的最后一個“/”開始到“？”為止，是文件名部分，如果沒有“?”,則是從域名后的最后一個“/”開始到“#”為止，是文件部分，如果沒有“？”和“#”，那么從域名后的最后一個“/”開始到結束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用默認的文件名；

　　6.錨部分：從“#”開始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分；

　　7.參數部分：從“？”開始到“#”為止之間的部分為參數部分，又稱搜索部分、查詢部分。本例中的參數部分為“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，參數與參數之間用“&”作為分隔符。

（原文：http://blog.csdn.net/ergouge/article/details/8185219?）

URI和URL的區別

（原文：http://www.cnblogs.com/ranyonsue/p/5984001.html）

URI，是uniform resource identifier，統一資源標識符，用來唯一的標識一個資源。

Web上可用的每種資源如HTML文檔、圖像、視頻片段、程序等都是一個來URI來定位的
URI一般由三部組成：
①訪問資源的命名機制
②存放資源的主機名
③資源自身的名稱，由路徑表示，著重強調于資源。

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明了如何locate這個資源。

URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上，特別是著名的Mosaic。
采用URL可以用一種統一的格式來描述各種信息資源，包括文件、服務器的地址和目錄等。URL一般由三部組成：
①協議(或稱為服務方式)
②存有該資源的主機IP地址(有時也包括端口號)
③主機資源的具體地址。如目錄和文件名等

URN，uniform resource name，統一資源命名，是通過名字來標識資源，比如mailto:java-net@java.sun.com。

URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI?；\統地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL。這是因為 URI 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

在Java的URI中，一個URI實例可以代表絕對的，也可以是相對的，只要它符合URI的語法規則。而URL類則不僅符合語義，還包含了定位該資源的信息，因此它不能是相對的。
在Java類庫中，URI類不包含任何訪問資源的方法，它唯一的作用就是解析。
相反的是，URL類可以打開一個到達資源的流。

3.HTTP請求消息

　　在HTTP中，一個完整的請求消息由請求行、請求頭、空行和實體內容組成。

（1）HTTP請求行

GET  /day08_02/1.html  HTTP/1.1GET：請求方式
day08_02/1.html：請求資源路徑
HTTP/1.1：通信使用的協議版本注意：請求行中的每個部分都需要用空格分割，最后要以回車換行結束

請求方式：Get（默認）? POST? DELETE? HEAD? OPTIONS TRACE? PUT和CONNECT八種。

（1）GET：請求獲取行的URI所標示的資源；明文傳輸不安全，數據量有限，不超過1kb　　

? ? ? ?GET是最常見的一種請求方式，當客戶端要從服務器中讀取文檔時，當點擊網頁上的鏈接或者通過在瀏覽器的地址欄輸入網址來瀏覽網頁的，使用的都是GET方式。GET方法要求服務器將URL定位的資源放在響應報文的數據部分，回送給客戶端。使用GET方法時，請求參數和對應的值附加在URL后面，利用一個問號（“?”）代表URL的結尾與請求參數的開始，傳遞參數長度受限制。例如，/index.jsp?id=100&op=bind,這樣通過GET方式傳遞的數據直接表示在地址中，所以我們可以把請求結果以鏈接的形式發送給好友。以用google搜索domety為例，Request格式如下：

?（原文：https://www.cnblogs.com/lauhp/p/8979393.html）

  //請求行
 1 GET /search?hl=zh-CN&source=hp&q=domety&aq=f&oq= HTTP/1.1  
//請求頭信息，因為GET請求沒有正文  
 2 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,   
 3 application/msword, application/x-silverlight, application/x-shockwave-flash, */*    
 4 Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>    
 5 Accept-Language: zh-cn    
 6 Accept-Encoding: gzip, deflate    
 7 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)    
 8 Host: <a href="http://www.google.cn">www.google.cn</a>    
 9 Connection: Keep-Alive    
10 Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g;   
11 NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-  
12 FxlRugatx63JLv7CWMD6UB_O_r   
//空行
//因為GET沒有正文，所以下面為空（實體內容）

可以看到，GET方式的請求一般不包含”請求內容”部分，請求數據以地址的形式表現在請求行。地址鏈接如下：

<a href="http://www.google.cn/search?hl=zh-CN&source=hp&q=domety&aq=f&oq=">http://www.google.cn/search?hl=zh-CN&source=hp&q=domety&aq=f&oq=</a>

地址中”?”之后的部分就是通過GET發送的請求數據，我們可以在地址欄中清楚的看到，各個數據之間用”&”符號隔開。顯然，這種方式不適合傳送私密數據。另外，由于不同的瀏覽器對地址的字符限制也有所不同，一般最多只能識別1024個字符，所以如果需要傳送大量數據的時候，也不適合使用GET方式。

（2）POST:?向指定資源提交數據，請求服務器進行處理（如提交表單或上傳文件）；暗文傳輸，安全。數據量沒有限制。

? ? ? POST方法將請求參數封裝在HTTP請求數據中，以名稱/值的形式出現，可以傳輸大量數據，這樣POST方式對傳送的數據大小沒有限制，而且也不會顯示在URL中。還以上面的搜索domety為例，如果使用POST方式的話，格式如下：

   //請求首行
 1 POST /search HTTP/1.1    
   //請求頭信息
 2 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,   
 3 application/msword, application/x-silverlight, application/x-shockwave-flash, */*    
 4 Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>    
 5 Accept-Language: zh-cn    
 6 Accept-Encoding: gzip, deflate    
 7 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)    
 8 Host: <a href="http://www.google.cn">www.google.cn</a>    
 9 Connection: Keep-Alive    
10 Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g;   
11 NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-  
12 FxlRugatx63JLv7CWMD6UB_O_r    
13 //?這里是空行
   //POST有請求正文
14 hl=zh-CN&source=hp&q=domety

? ? ?以看到，POST方式請求行中不包含數據字符串，這些數據保存在”請求內容”部分，各數據之間也是使用”&”符號隔開。POST方式大多用于頁面的表單中。因為POST也能完成GET的功能，因此多數人在設計表單的時候一律都使用POST方式，其實這是一個誤區。GET方式也有自己的特點和優勢，我們應該根據不同的情況來選擇是使用GET還是使用POST。

? ? ? 在實際開發中，通常都會使用POST方法發送請求，其原因：

第一：POST傳輸的數據大小無限制。由于GET請求方式是通過請求參數傳遞數據的，因此最多可傳遞1KB的數據。而POST請求防暑，是通過實體傳遞數據的，因此傳遞數據的大小沒有限制。

第二：POST比GET請求方式更安全。由于GET請求方式的參數信息都會在URL地址欄中明文顯示，而POST請求方式傳遞的參數隱藏在實體內容中，用戶是看不到的，因此，POST比GET請求方式更安全。

（2）HTTP請求消息頭

　　在HTTP請求消息中，在請求行之后變身若干個請求消息頭。請求消息頭主要用于向服務器端傳遞附加消息，例如，客戶端可以接收的數據類型、壓縮方法、語言以及發送請求的超鏈接所屬頁面的URL地址等信息。

　　從上面請求消息頭可以看出，每個請求消息頭都由一個頭字段名稱和一個值構成的，頭字段名稱和值之間用（：）和空格分割，在每個請求消息頭之后使用一個回車換行符標志結束。

　　需要注意的是，頭字段名稱不區分大小寫，但習慣上將單詞的第一個字母大寫。

　　當瀏覽器發送請求給服務其時，根據功能需求的不同，發送的請求消息頭也不相同。

 1 Accept:瀏覽器可接受的MIME類型，告訴服務器客戶端能接收什么樣類型的文件。
 2 Accept-Charset: 瀏覽器通過這個頭告訴服務器，它支持哪種字符集
 3 Accept-Encoding:瀏覽器能夠進行解碼的數據編碼方式，比如gzip 
 4 Accept-Language:瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時要用到。 可以在瀏覽器中進行設置。
 5 Host:初始URL中的主機和端口 
 6 Referrer:包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面 
 7 Content-Type:內容類型。告訴服務器瀏覽器傳輸數據的MIME類型，文件傳輸的類型   application/x-www-form-urlencoded
 8 If-Modified-Since: Wed, 02 Feb 2011 12:04:56 GMT利用這個頭與服務器的文件進行比對，如果一致，則從緩存中直接讀取文件。
 9 User-Agent:瀏覽器類型.
10 Content-Length:表示請求消息正文的長度 
11 Connection:表示是否需要持久連接。如果服務器看到這里的值為“Keep -Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接 
12 Cookie:這是最重要的請求頭信息之一 (在講會話時解析)
13 Date：Date: Mon, 22 Aug 2011 01:55:39 GMT請求時間GMT

4.HTTP響應消息

　　當服務器收到瀏覽器請求后，會收到響應消息給客戶端。一個完整的響應消息包括響應狀態行、響應消息頭和實體內容。

?（1）HTTP響應狀態行

HTTP/1.1 200 OKHTTP1.1：通信使用的協議版本（200是狀態碼）
OK：狀態描述，說明客戶請求成功
注意：請求行中的每個部分都需要空格分割，最后需要以回車換行結束

HTTP狀態碼

當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收并顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文為HTTP Status Code。狀態代碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。

1xx：指示信息--表示請求已接收，繼續處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進行更進一步的操作。
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。
5xx：服務器端錯誤--服務器未能實現合法的請求。

常見狀態代碼、狀態描述的說明如下。

- 200?OK：客戶端請求成功。
- 400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。
- 401 Unauthorized：請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用。
- 403 Forbidden：服務器收到請求，但是拒絕提供服務。
- 404?Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
- 500?Internal Server Error：服務器發生不可預期的錯誤。
- 503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間后可能恢復正常，舉個例子：HTTP/1.1 200 OK（CRLF）。

?（2）HTTP響應消息頭

 1 Location: http://www.it315.org/index.jsp指示新的資源的位置，通常和302/307一起使用，完成請求重定向
 2 Server:apache tomcat指示服務器的類型
 3 Content-Encoding: gzip服務器發送的數據采用的編碼類型
 4 Content-Length: 80 告訴瀏覽器正文的長度
 5 Content-Language: zh-cn服務發送的文本的語言
 6 Content-Type: text/html; charset=GB2312服務器發送的內容的MIME類型
 7 Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT文件的最后修改時間
 8 Refresh: 1;url=http://www.it315.org指示客戶端刷新頻率。單位是秒
 9 Content-Disposition: attachment; filename=aaa.zip指示客戶端下載文件
10 Set-Cookie:SS=Q0=5Lb_nQ; path=/search服務器端發送的Cookie
11 Expires: -1
12 Cache-Control: no-cache (1.1)  
13 Pragma: no-cache   (1.0)  表示告訴客戶端不要使用緩存
14 Connection: close/Keep-Alive   
15 Date: Tue, 11 Jul 2000 18:23:51 GMT