細說HTTP上篇

HTTP概述

 

        天天，都有數以億萬計的JPEG圖片、HTML頁面、文本文件、MPEG電影、WAV音頻文件、Java小程序和其餘資源在因特網上游弋。HTTP能夠從遍及全世界的Web服務器上將這些信息快速、便捷、可靠的搬移到人們桌面上的Web瀏覽器上去。

        HTTP，全稱Hyper Text Transport Protocal，即超文本傳輸協議，定義了瀏覽器如何向服務器請求文檔以及服務器怎樣把文檔傳送給瀏覽器，它是萬維網可以可靠的交換文件（包括文本，聲音，圖像等多種多媒體文件）的基礎。

 

起源 

        超文本傳輸協議的前身是Xanadu項目，超文本的概念是Ted Nelson在1960年代提出的。1989年，Tim Berners Lee在CERN擔任軟件諮詢師的時候，開發了一套程序，奠基了萬維網的基礎。1990年12月，超文本在CERN首次上線。1991年夏天，繼Telnet等協議以後，超文本轉移協議成爲了互聯網諸多協議的一份子。

 

特色 

        一、支持客戶/服務器模式。支持基本認證 和安全認證。

        二、 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

 

        三、靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

 

        四、HTTP 0.9和1.0使用非持續鏈接：限制每次鏈接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

HTTP 1.1使用持續鏈接：沒必要爲每一個web對象建立一個新的鏈接，一個鏈接能夠傳送多個對象。

 

        五、無狀態：HTTP協議是 無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。

 

 Web客戶端和服務器交互過程和模型

        客戶端/服務器(client/server)這個術語可追溯到上個千年(20世紀80年代)，表示經過網絡鏈接起來的我的計算機。客戶端/服務器也可用於描述兩個計算機程序的關係--客戶程序和服務器程序。客戶向服務器請求某種服務(好比請求一個文件或數據庫訪問)，服務器知足請求並經過網絡將結果傳送給客戶端。雖然客戶端和服務器程序可存在於同一臺計算機中，但它們一般都運行在不一樣計算機上。一臺服務器處理多個客戶端請求也是很常見的。

        最多見的Web客戶端就是瀏覽器了，一次請求/響應的模型以下圖所示：

        

        這裏須要說明的一點是，每次訪問一個靜態資源，好比一個html文件，一個png圖片或者一個文本文檔都會向服務器發出一個HTTP請求，每一個HTTP請求都會經歷上圖的請求/響應模型。好比咱們點開http://www.taobao.com/（淘寶網），咱們會往服務器發送成百上千個HTTP請求，收到來自客戶端的請求後，服務器會去尋找相應的資源，若是成功，就將對象，對象類型，對象長度以及其餘信息放在HTTP響應中發回客戶端。那麼問題來了，服務器怎麼去尋找相應的資源，憑據是什麼？

 

URL與資源

        URL是瀏覽器尋找信息時所須要的資源位置。經過URL，人類和應用程序才能找到使用並共享因特網上大量的數據資源。URL是人們對HTTP和其餘協議的經常使用訪問點：在瀏覽器中輸入一串URL，瀏覽器就會在幕後發送適當的協議報文來獲取人們所指望的資源。

 

URL的語法 

    大多數的URL方案的URL語法都創建在這個由9部分的通用格式上：

    <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

    幾乎沒有哪一個URL中包含了全部這些組件。URL最重要的3個部分是方案(scheme)、主機(host)和路徑(path)。

 

   

    目前常見的協議類型有不少種，經常使用的有http，https（更安全的http），mailto（郵件），ftp（文件傳輸），rtsp（音頻視頻），file，news，telnet等等

 

HTTP報文

        HTTP報文是在HTTP應用程序之間發送的數據塊。這些數據塊以一些文本形式的元信息開頭，這些信息描述了報文的內容和含義，後面跟着可選的數據部分。

 

報文的組成 

        HTTP報文是簡單的格式化數據塊。每一條報文都包含一條來自客戶端的請求，或者來自服務器的響應。它們有三個部分組成：對報文進行描述的起始行（start line）、包含屬性的首部塊（header），以及可選的、包含數據的主體部分（body）。

HTTP/1.0 200 OK            //起始行

Content-type:text/plain    //首部
Content-length:19          //首部  

Hi I'm a message!          //主體

報文的語法

 

    全部的HTTP報文能夠分爲兩類：請求報文(request message)和響應報文(response message)。請求報文會向服務器發送一個請求，響應報文會將結果返回個客戶端。

               

        請求報文的格式：

<method> <request-UTL> <version>
<headers>

<entity-body>

　　    響應報文格式：

<version> <status><reason-phrase>
<header>

<entity-body>

　　

下面是對格式中各部分的簡要描述

　　    一、方法(method)　　GET

　　　　    客戶端但願服務器對資源執行的動做。是一個單獨的詞，好比GET、HEAD或POST。

　　    二、請求的URL(request-URL)

　　　　    命名了全部請求資源，或者URL路徑組件的完整URL。若是直接與服務器進行對話，只要URL的路徑組件是資源的絕對路徑，一般就不會有什麼問題--服務器能夠假定　義本身是URL的主機/端口。

　　    三、版本(version)　　HTTP/1.1

　　　　   報文所使用的HTTP版本，其格式以下：

　　　　   HTTP/<major>.<minor>

　　　　   其中主要版本號(major)和次要版本號(minor)都是整數。　　

　　   四、狀態碼(status)

　　　　  這三個數字描述了請求過程當中所發生的狀況。每一個狀態碼的第一位數字都用於描述狀態的通常類別("成功"、"出錯"等)。

　　   五、緣由短語(reason-phrase)

　　　　  數字狀態碼的可讀版本，包含行終止序列以前的全部文本。緣由短語只是給人類看的，它不能說明什麼。客戶端依然採用狀態碼來判斷請求/響應是否成功！

　　　　  例如：HTTP/1.0 200 NOT OK 客戶端依然會當請求已成功處理。由於狀態碼是200。而緣由短語只是說明而已，這對於自定義擴展狀態碼仍是比較有用的。

　　   六、首部(header)

　　　　  能夠有0個或多個首部，每一個首部都包含一個名字，後面跟着一個冒號(:)，而後是一個可選的空格，接着是一個值，最後是一個CRLF。首部是由一個空行(CRLF)結束　的，表示了首部列表的結束和實體主體的開始。

　　    七、實體的主體部分(entity-body)

　　　　   實體的主體部分包含一個由任意數據組成的數據塊。並非全部的報文都包含實體的主體部分。如GET請求就不包含實體。