什麼是超文字傳輸協議超文字傳輸協議功能

　　隨著現代通訊技術的發展,網路技術特別是基於TCP/IP 通訊協議的Web技術得到了廣泛的應用和普及。在TCP/IP 協議基礎上建立的HTTP 超文字傳輸協議、FTP 檔案傳輸協議、Telnet 遠端登陸協議以及SMTP 郵件協議等協議族構成了Web 技術的核心，隨著現代通訊技術的發展,網路技術特別是基於TCP/IP 通訊協議的Web技術得到了廣泛的應用和普及。在TCP/IP 協議基礎上建立的HTTP 超文字傳輸協議、FTP 檔案傳輸協議、Telnet 遠端登陸協議以及SMTP 郵件協議等協議族構成了Web 技術的核心呢？下面是小編整理的什麼是超文字傳輸協議，歡迎閱讀。

　　什麼是超文字傳輸協議

　　超文字傳輸協議一般指http

　　超文字傳輸協議***HTTP，HyperText Transfer Protocol***是網際網路上應用最為廣泛的一種網路協議。所有的WWW檔案都必須遵守這個標準。設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種通過計算機處理文字資訊的方法，並稱之為超文字***hypertext***,這成為了HTTP超文字傳輸協議標準架構的發展根基。Ted Nelson組織協調全球資訊網協會***World Wide Web Consortium***和網際網路工程工作小組***Internet Engineering Task Force ***共同合作研究，最終釋出了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1。

　　超文字傳輸協議技術架構

　　HTTP是一個客戶端和伺服器端請求和應答的標準***TCP***。客戶端是終端使用者，伺服器端是網站。通過使用Web瀏覽器、網路爬蟲或者其它的工具，客戶端發起一個到伺服器上指定埠***預設埠為80***的HTTP請求。***我們稱這個客戶端***叫使用者代理***user agent***。應答的伺服器上儲存著***一些***資源，比如HTML檔案和影象。***我們稱***這個應答伺服器為源伺服器***origin server***。在使用者代理和源伺服器中間可能存在多箇中間層，比如代理，閘道器，或者隧道***tunnels***。儘管TCP/IP協議是網際網路上最流行的應用，HTTP協議並沒有規定必須使用它和***基於***它支援的層。 事實上，HTTP可以在任何其他網際網路協議上，或者在其他網路上實現。HTTP只假定***其下層協議提供***可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。

　　通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定埠***預設是80埠***的TCP連線。HTTP伺服器則在那個埠監聽客戶端傳送過來的請求。一旦收到請求，伺服器***向客戶端***發回一個狀態行，比如"HTTP/1.1 200 OK"，和***響應的***訊息，訊息的訊息體可能是請求的檔案、錯誤訊息、或者其它一些資訊。

　　HTTP使用TCP而不是UDP的原因在於***開啟***一個網頁必須傳送很多資料，而TCP協議提供傳輸控制，按順序組織資料，和錯誤糾正。

　　通過HTTP或者HTTPS協議請求的資源由統一資源標示符***Uniform Resource Identifiers******或者，更準確一些，URLs***來標識。

　　超文字傳輸協議功能

　　HTTP協議***HyperText Transfer Protocol，超文字傳輸協議***是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，以及哪部分內容首先顯示***如文字先於圖形***等。

　　HTTP是客戶端瀏覽器或其他程式與Web伺服器之間的應用層通訊協議。在Internet上的Web伺服器上存放的都是超文字資訊，客戶機需要通過HTTP協議傳輸所要訪問的超文字資訊。HTTP包含命令和傳輸資訊，不僅可用於Web訪問，也可以用於其他因特網/內聯網應用系統之間的通訊，從而實現各類應用資源超媒體訪問的整合。

　　我們在瀏覽器的位址列裡輸入的網站地址叫做URL ***Uniform Resource Locator，統一資源定位符***。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級連結時，URL就確定了要瀏覽的地址。瀏覽器通過超文字傳輸協議***HTTP***，將Web伺服器上站點的網頁程式碼提取出來，並翻譯成漂亮的網頁。

　　超文字傳輸協議基礎

　　HTTP***HyperText Transport Protocol***是超文字傳輸協議的縮寫，它用於傳送WWW方式的資料，關於HTTP協議的詳細內容請參考RFC2616。HTTP協議採用了請求/響應模型。客戶端向伺服器傳送一個請求，請求頭包含請求的方法、URL、協議版本、以及包含請求修飾符、客戶資訊和內容的類似於MIME的訊息結構。伺服器以一個狀態行作為響應，響應的內容包括訊息協議的版本，成功或者錯誤編碼加上包含伺服器資訊、實體元資訊以及可能的實體內容。

　　通常HTTP訊息包括客戶機向伺服器的請求訊息和伺服器向客戶機的響應訊息。這兩種型別的訊息由一個起始行，一個或者多個頭域，一個指示頭域結束的空行和可選的訊息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號***:***和域值三部分組成。域名是大小寫無關的，域值前可以新增任何數量的空格符，頭域可以被擴充套件為多行，在每行開始處，使用至少一個空格或製表符。

　　通用頭域

　　通用頭域包含請求和響應訊息都支援的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴充套件要求通訊雙方都支援此擴充套件，如果存在不支援的通用頭域，一般將會作為實體頭域處理。下面簡單介紹幾個在UPnP訊息中使用的通用頭域：

　　1.Cache-Control頭域

　　Cache-Control指定請求和響應遵循的快取機制。在請求訊息或響應訊息中設定Cache-Control並不會修改另一個訊息處理過程中的快取處理過程。請求時的快取指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應訊息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各個訊息中的指令含義如下：

　　Public指示響應可被任何快取區快取。

　　Private指示對於單個使用者的整個或部分響應訊息，不能被共享快取處理。這允許伺服器僅僅描述當用戶的部分響應訊息，此響應訊息對於其他使用者的請求無效。

　　no-cache指示請求或響應訊息不能快取

　　no-store用於防止重要的資訊被無意的釋出。在請求訊息中傳送將使得請求和響應訊息都不使用快取。

　　max-age指示客戶機可以接收生存期不大於指定時間***以秒為單位***的響應。

　　min-fresh指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。

　　max-stale指示客戶機可以接收超出超時期間的響應訊息。如果指定max-stale訊息的值，那麼客戶機可以接收超出超時期指定值之內的響應訊息。

　　HTTP Keep-Alive

　　Keep-Alive功能使客戶端到伺服器端的連線持續有效，當出現對伺服器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連線。市場上的大部分Web伺服器，包括iPlanet、IIS和Apache，都支援HTTP Keep-Alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這裡存在另外一個問題：雖然為客戶保留開啟的連線有一定的好處，但它同樣影響了效能，因為在處理暫停期間，本來可以釋放的資源仍舊被佔用。當Web伺服器和應用伺服器在同一臺機器上執行時，Keep- Alive功能對資源利用的影響尤其突出。

　　KeepAliveTime 值控制 TCP/IP 嘗試驗證空閒連線是否完好的頻率。如果這段時間內沒有活動，則會發送保持活動訊號。如果網路工作正常，而且接收方是活動的，它就會響應。如果需要對丟失接收方敏感，換句話說，需要更快地發現丟失了接收方，請考慮減小這個值。如果長期不活動的空閒連接出現次數較多，而丟失接收方的情況出現較少，您可能會要提高該值以減少開銷。預設情況下，如果空閒連線 7200000 毫秒***2 小時***內沒有活動，Windows 就傳送保持活動的訊息。通常，1800000 毫秒是首選值，從而一半的已關閉連線會在 30 分鐘內被檢測到。 KeepAliveInterval 值定義瞭如果未從接收方收到保持活動訊息的響應，TCP/IP 重複傳送保持活動訊號的頻率。當連續傳送保持活動訊號、但未收到響應的次數超出 TcpMaxDataRetransmissions 的值時，會放棄該連線。如果期望較長的響應時間，您可能需要提高該值以減少開銷。如果需要減少花在驗證接收方是否已丟失上的時間，請考慮減小該值或 TcpMaxDataRetransmissions 值。預設情況下，在未收到響應而重新發送保持活動的訊息之前，Windows 會等待 1000 毫秒***1 秒***。 KeepAliveTime 根據你的需要設定就行，比如10分鐘，注意要轉換成MS。 XXX代表這個間隔值得大小。

　　2.Date頭域

　　Date頭域表示訊息傳送的時間，時間的描述格式由rfc822定義。例如，

　　3.Pragma頭域

　　Pragma頭域用來包含實現特定的指令，最常用的是

　　請求訊息

　　請求訊息的第一行為下面的格式：

　　MethodSPRequest-URISPHTTP-VersionCRLFMethod表示對於Request-URI完成的方法，這個欄位是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD應該被所有的通用WEB伺服器支援，其他所有方法的實現是可選的。GET方法取回由Request-URI標識的資訊。HEAD方法也是取回由Request-URI標識的資訊，只是可以在響應時，不返回訊息體。POST方法可以請求伺服器接收包含在請求中的實體資訊，可以用於提交表單，向新聞組、BBS、郵件群組和資料庫傳送訊息。

　　SP表示空格。Request-URI遵循URI格式，在此欄位為星號*******時，說明請求並不用於某個特定的資源地址，而是用於伺服器本身。HTTP-Version表示支援的HTTP版本，例如為HTTP/1.1。CRLF表示換行回車符。請求頭域允許客戶端向伺服器傳遞關於請求或者關於客戶機的附加資訊。請求頭域可能包含下列欄位Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴充套件要求通訊雙方都支援，如果存在不支援的請求頭域，一般將會作為實體頭域處理。

　　典型的請求訊息：

　　Host: download.*******.de

　　Accept: */*

　　Pragma: no-cache

　　Cache-Control: no-cache

　　User-Agent: Mozilla/4.04[en]***Win95;I;Nav***

　　Range: bytes=554554-

　　上例第一行表示HTTP客戶端***可能是瀏覽器、下載程式***通過GET方法獲得指定URL下的檔案。棕色的部分表示請求頭域的資訊，綠色的部分表示通用頭部分。

　　1.Host頭域

　　Host頭域指定請***的Intenet主機和埠號，必須表示請求url的原始伺服器或閘道器的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。

　　2.Referer頭域

　　Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許伺服器生成回退連結串列，可用來登陸、優化cache等。他也允許廢除的或錯誤的連線由於維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被髮送。如果指定的是部分uri地址，則此地址應該是一個相對地址。

　　3.Range頭域

　　Range頭域可以請求實體的一個或者多個子範圍。例如，

　　表示頭500個位元組：bytes=0-499

　　表示第二個500位元組：bytes=500-999

　　表示最後500個位元組：bytes=-500

　　表示500位元組以後的範圍：bytes=500-

　　第一個和最後一個位元組：bytes=0-0,-1

　　同時指定幾個範圍：bytes=500-600,601-999

　　但是伺服器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206***PartialContent***返回而不是以200***OK***。

　　4.User-Agent頭域

　　User-Agent頭域的內容包含發出請求的使用者資訊。

　　響應訊息

　　響應訊息的第一行為下面的格式：

　　HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF

　　HTTP-Version表示支援的HTTP版本，例如為HTTP/1.1。Status-Code是一個三個數字的結果程式碼。Reason-Phrase給Status-Code提供一個簡單的文字描述。Status-Code主要用於機器自動識別，Reason-Phrase主要用於幫助使用者理解。Status-Code的第一個數字定義響應的類別，後兩個數字沒有分類的作用。第一個數字可能取5個不同的值：

　　1xx:資訊響應類，表示接收到請求並且繼續處理

　　2xx:處理成功響應類，表示動作被成功接收、理解和接受

　　3xx:重定向響應類，為了完成指定的動作，必須接受進一步處理

　　4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行

　　5xx:服務端錯誤，伺服器不能正確執行一個正確的請求

　　響應頭域允許伺服器傳遞不能放在狀態行的附加資訊，這些域主要描述伺服器的資訊和Request-URI進一步的資訊。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴充套件要求通訊雙方都支援，如果存在不支援的響應頭域，一般將會作為實體頭域處理。

　　典型的響應訊息：

　　HTTP/1.0200OK

　　Etag:""

　　上例第一行表示HTTP服務端響應一個GET方法。棕色的部分表示響應頭域的資訊，綠色的部分表示通用頭部分，紅色的部分表示實體頭域的資訊。

　　1.Location響應頭

　　Location響應頭用於重定向接收者到一個新URI地址。

　　2.Server響應頭

　　Server響應頭包含處理請求的原始伺服器的軟體資訊。此域能包含多個產品標識和註釋，產品標識一般按照重要性排序。

　　實體資訊

　　請求訊息和響應訊息都可以包含實體資訊，實體資訊一般由實體頭域和實體組成。實體頭域包含關於實體的原資訊，實體頭包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允許客戶端定義新的實體頭，但是這些域可能無法被接受方識別。實體可以是一個經過編碼的位元組流，它的編碼方式由Content-Encoding或Content-Type定義，它的長度由Content-Length或Content-Range定義。

　　1.Content-Type實體頭

　　Content-Type實體頭用於向接收方指示實體的介質型別，指定HEAD方法送到接收方的實體介質型別，或GET方法傳送的請求介質型別

　　2.Content-Range實體頭

　　Content-Range實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在伺服器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式：

　　例如，傳送頭500個位元組次欄位的形式：

　　3.Last-modified實體頭

　　Last-modified實體頭指定伺服器上儲存內容的最後修訂時間。

　　例如，傳送頭500個位元組次欄位的形式：

　　運作方式

　　在WWW中，“客戶”與“伺服器”是一個相對的概念，只存在於一個特定的連線期間，即在某個連線中的客戶在另一個連線中可能作為伺服器。基於HTTP協議的客戶/伺服器模式的資訊交換過程，它分四個過程：建立連線、傳送請求資訊、傳送響應資訊、關閉連線。

　　HTTP協議是基於請求/響應正規化的。一個客戶機與伺服器建立連線後，傳送一個請求給伺服器，請求方式的格式為，統一資源識別符號、協議版本號，後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。伺服器接到請求後，給予相應的響應資訊，其格式為一個狀態行包括資訊的協議版本號、一個成功或錯誤的程式碼，後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容。

　　其實簡單說就是任何伺服器除了包括HTML檔案以外，還有一個HTTP駐留程式，用於響應使用者請求。你的瀏覽器是HTTP客戶，向伺服器傳送請求，當瀏覽器中輸入了一個開始檔案或點選了一個超級連結時，瀏覽器就向伺服器傳送了HTTP請求，此請求被送往由IP地址指定的URL。駐留程式接收到請求，在進行必要的操作後回送所要求的檔案。在這一過程中，在網路上傳送和接收的資料已經被分成一個或多個數據包***packet***，每個資料包包括：要傳送的資料;控制資訊，即告訴網路怎樣處理資料包。TCP/IP決定了每個資料包的格式。如果事先不告訴你，你可能不會知道資訊被分成用於傳輸和再重新組合起來的許多小塊。

　　許多HTTP通訊是由一個使用者代理初始化的並且包括一個申請在源伺服器上資源的請求。最簡單的情況可能是在使用者代理***UA***和源伺服器***O***之間通過一個單獨的連線來完成。

　　當一個或多箇中介出現在請求/響應鏈中時，情況就變得複雜一些。中介有三種：代理***Proxy***、閘道器***Gateway***和通道***Tunnel***。一個代理根據URI的絕對格式來接受請求，重寫全部或部分訊息，通過URI的標識把已格式化過的請求傳送到伺服器。閘道器是一個接收代理，作為一些其它伺服器的上層，並且如果必須的話，可以把請求翻譯給下層的伺服器協議。一個通道作為不改變訊息的兩個連線之間的中繼點。當通訊需要通過一箇中介***例如：防火牆等***或者是中介不能識別訊息的內容時，通道經常被使用。

　　報文格式

　　HTTP報文由從客戶機到伺服器的請求和從伺服器到客戶機的響應構成。請求報文格式如下：

　　請求行 - 通用資訊頭 - 請求頭 - 實體頭 - 報文主體

　　請求行以方法欄位開始，後面分別是 URL 欄位和 HTTP 協議版本欄位，並以 CRLF 結尾。SP 是分隔符。除了在最後的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關通用資訊頭，請求頭和實體頭方面的具體內容可以參照相關檔案。

　　應答報文格式如下：

　　狀態行 - 通用資訊頭 - 響應頭 - 實體頭 - 報文主體

　　狀態碼元由3位數字組成，表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述，狀態碼用來支援自動操作，而原因分析用來供使用者使用。客戶機無需用來檢查或顯示語法。有關通用資訊頭，響應頭和實體頭方面的具體內容可以參照相關檔案。

　　超文字傳輸協議工作原理

　　一次HTTP操作稱為一個事務，其工作過程可分為四步：

　　首先客戶機與伺服器需要建立連線。只要單擊某個超級連結，HTTP的工作就開始了。

　　建立連線後，客戶機發送一個請求給伺服器，請求方式的格式為：統一資源識別符號***URL***、協議版本號，後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。

　　伺服器接到請求後，給予相應的響應資訊，其格式為一個狀態行，包括資訊的協議版本號、一個成功或錯誤的程式碼，後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容。

　　客戶端接收伺服器所返回的資訊通過瀏覽器顯示在使用者的顯示屏上，然後客戶機與伺服器斷開連線。

　　如果在以上過程中的某一步出現錯誤，那麼產生錯誤的資訊將返回到客戶端，由顯示屏輸出。對於使用者來說，這些過程是由HTTP自己完成的，使用者只要用滑鼠點選，等待資訊顯示就可以了。

　　許多HTTP通訊是由一個使用者代理初始化的並且包括一個申請在源伺服器上資源的請求。最簡單的情況可能是在使用者代理和伺服器之間通過一個單獨的連線來完成。在Internet上，HTTP通訊通常發生在TCP/IP連線之上。預設埠是TCP 80，但其它的埠也是可用的。但這並不預示著HTTP協議在Internet或其它網路的其它協議之上才能完成。HTTP只預示著一個可靠的傳輸。

　　這個過程就好像我們打電話訂貨一樣，我們可以打電話給商家，告訴他我們需要什麼規格的商品，然後商家再告訴我們什麼商品有貨，什麼商品缺貨。這些，我們是通過電話線用電話聯絡***HTTP是通過TCP/IP***，當然我們也可以通過傳真，只要商家那邊也有傳真。