httpd協定概述

HTTPD協定詳解

http簡介

HTTP：全稱為HyperText  Transfer Protocol（超文本傳輸協定），是目前網際網路使用最多最廣泛的一種協定。在早期的HTTP協定版本（http/0.9）中，http服務僅支援二進制（ASCII）的純文字檔案。而在http/0.9以後的版本中，http協定可以支援MIME機制，使得http協定可以支援多種格式的文本檔案，例如視訊、圖像、語音等等。進而豐富了http協定的發展。

什麼是MIME？

MIME：全稱是Mulitpurpose  Internet  Mail Extension,多用途郵件擴充，MIME是一種協定，早期應用于郵件系統，後來該協定也被應用到了浏覽器當中，是以至今我們打開某個網頁時，可以出現多種格式的文本資訊。這是因為MIME引進了base64編碼機制，它能夠将非文本資訊（如二進制格式的資料）在傳輸前重新編碼為文本格式，接收方能夠用相反的機制将其還原為原來的格式，并且可以調用相應的程式來打開此檔案。

什麼是URI和URL？

我們在打開某一個頁面時，常常看到有圖檔、視訊及文檔等資訊，我們把這樣每一個資訊叫做一個資源或者也可以稱作一個web對象。多個資源或者web對象就組成了一個html格式的頁面。 而我們常常打開浏覽器時，在浏覽器上面需要輸入網址，才可以通路那個頁面的資源。這個網址就是我們常說的URL。

URL：全稱Uniform  Record  Locator，統一資源定位符，它不僅定義了資源，還明确指定了資源所在的位置。

URL通常由以下三部分組成：

a、方案（其實簡單的了解就是我們常說的通路協定，如http、ftp等）

b、存放資源的主機位址（主機名或ip，有時也包括端口号）

c、資源的具體路徑（檔案名或目錄）

如http://www.baidu.com/a/a.html這就是一個URL。其中方案為http，主機為www.baidu.com，資源路徑為/a/a.html。

有時候我們也會常常看到URI，那麼URI是什麼呢？它和URL是什麼關系？

URI：全稱Uniform Record  Indentifier，全局統一資源辨別符，它籠統地定義了資源且是全局的，不限于用戶端和伺服器端，雖然URI也是用來定義資源的，但是它的定義是抽象的，而URL是具體的定義了這個資源的所在位置，是以URL是URI的子對象或者是子集。

但是我們常常在點選某個頁面時，浏覽器上面顯示的不是以.html為字尾的URL，而是以.php為字尾的URL。這是什麼原因造成的呢？

這是因為在我們的web伺服器上面存的并不是html格式的檔案，而是一些腳本檔案，當用戶端發起請求時，web伺服器會調用某個協定來執行這些腳本，這些腳本執行完畢後，就會生成一個html格式的文檔，web伺服器在将生成的HTML格式的文檔傳回給用戶端。這就是我們為什麼看到的是一個html格式的文檔，而浏覽器上面顯示的就是以.php為字尾的URL。而這種腳本檔案是通過PHP語言來實作的。而這種機制就是動态網頁的實作機制。

對于動态網頁來說，既包括靜态内容也包括動态内容。

靜态内容一般指的是圖檔等資訊，這些靜态内容是直接存在伺服器是上的。

動态内容需要通過腳本來執行，是以一般的，隻有動态内容才會運作腳本，靜态内容不會。

在有些時候，我們打開某個網頁會很快，但打開其他的頁面時會很稍微慢一點，這是為什麼呢？

這是在http/1.0以後，由于增加了緩存機制，是以當我們第一次打開某個網頁時，web伺服器會将這個URL緩存在本地，是以第二次打開網頁時明顯要比第一次快些。是以，建議大家不要随便清理緩存，這樣會導緻網頁加載速度比較慢哦！

http的封包格式

由于http是基于tcp協定的，是以在建立http會話的過程中，會經曆過三次握手和四次斷開。是以，當用戶端發起時，伺服器必須對該請求給予響應。http協定的端口号是80

http封包的請求格式

<method>  <request-URI>  <version>

<headers>    

<entity-body>

http封包的響應格式

<version> <status>  <reason-phrase>

<headers>

其中<method>表示為請求的方法。一般常用的方法有GET、POST、HEAD、DELETE、PUT等等。

<request-URI>表示請求的URI位址。

<version>表示http協定的版本号。

<headers>表示http的首部資訊。首部資訊一般有多行，每一行使用name:value的形式顯示。

<entity-body>表示的是封包主體，封包主體分為請求封包主體和響應封包主體。

<status>表示的是響應封包的狀态碼。

<reason-phase>:用來描述響應的結果或者了解成用來描述狀态碼的文本資訊。

http協定版本

http0.9：隻能傳輸html文檔；

http1.0：支援多媒體資料的處理，保持連接配接。有緩存功能；

http1.1：支援更多的請求方法，更加精細的緩存控制，支援持久連接配接；

http的請求方法

http的請求方法大概有如下這些：

GET、HEAD、PUT、POST、DELETE、OPTIONS、TRACE等等。常用的請求方法及其功能有如下幾種：

請求的方法類型	該方法的用途
GET	請求擷取一個資源，該資源需要伺服器發送。
HEAD	和GET方法相似，隻不過服務不需要發送資源，隻傳回響應首部資訊。
PUT	與GET方法相反，用于上傳資訊，向伺服器寫入文檔。用于釋出系統。
POST	支援HTML表單送出，表單中有使用者填入的資料，這些資料會上傳至伺服器，并存儲到某個位置。
DELETE	請求删除URL指向的資源。
OPTIONS	探測伺服器端對某資源所支援的請求方法。
TRACE	追蹤資源所經過的代理、防火牆和網關。

http的響應狀态碼

http的狀态碼主要分為這幾類：

1xx:表示純資訊。

2xx:表示成功狀态碼（例如：200、201、202...）

        200：表示ok，響應成功。

3xx:表示重定向類的狀态碼（例如301，302，304），表示該資源不在此處，重定向到其他伺服器或其他位置去了。

        301：Moved  Permanebtly，表示永久重定向。在響應封包中使用"Location:URL"的方式來指定該資源所在的位置，然後在向該資源現在所在的伺服器發起請求。以後用戶端在請求該資源時，直接請求Location中指定資源的位置，不在向本伺服器發起請求，這就是所謂的永久重定向。

        302：Found，表示臨時重定向。在響應封包中使用"Location:URL"的方式來指定該資源臨時存放的位置，然後在向該資源現在所在的位置發起請求。當用戶端下次請求該資源時，仍然向本伺服器發起請求。由于是臨時重定向，是以資源位置并不是固定的。

        304：Not modify，資源沒有被修改，用于http條件式緩存機制中。

4xx:表示用戶端錯誤類狀态碼（例如403，404）。

        401：伺服器端拒絕用戶端請求，說明請求時需要提供使用者名和密碼。

        403：Forbidden，請求被伺服器拒絕。可能由于沒有權限導緻的。

        404：Not Found，伺服器端無法找到請求的URL，該資源可能不在該伺服器上。

        405：Method Not Allow，不允許使用此方法來請求響應的URL。

5xx:表示伺服器端錯誤類狀态碼。

        500：Internet Server Error，伺服器内部錯誤。

        502：Bad Gateway，代理伺服器從上遊收到一條僞響應。

        503：Service  Unavailable，伺服器此時無法提供服務，但是将來可能有用。

http封包首部

http的封包首部包括：通用封包首部、請求封包首部、響應封包首部這三大類。

通用首部：通用首部既可以用于請求封包首部中又可以用于響應封包首部中。

        Connection：定義C/S之間關于請求/響應的有關選項；

        Via：顯示了封包經過的中間節點（代理或網關）；

        Cache-Control：緩存訓示；

        Pragma ：另一種随封包傳送訓示的方式，但并不專用于緩存；

請求封包首部

       Cilent-IP：請求端IP；

       Host：請求的主機名和端口号，在虛拟主機環境下用于不同的虛拟主機；

       Referer：指明了請求目前資源的原始資源的URL，即目前資源從哪個URL跳轉過來的。

       User-Agent：使用者代理，用戶端使用什麼工具發出的請求；

       Accept首部：使用者标明客戶自己更傾向于支援使用的能力；

       Accept：指明伺服器能發送哪些媒體類型；

       Accept-Charset：用戶端支援使用的字元集；

       Accept-Encoding：用戶端支援使用的編碼方式；

       Accept-Language：用戶端支援使用的語言；

       條件請求首部：

       Expect：允許用戶端列出某請求要求伺服器的行為；

       If-Modified-Since：是否在指定的時間以來修改過此資源；

       If-None-Match

       跟安全相關的請求首部：

       Authorization：用戶端送出給服務端的認證資料，如賬号和密碼及認證算法；

       Cookie：用戶端發送給伺服器端身份辨別,這樣伺服器端就可以判斷該用戶端之前是否通路過。

       Cookie2

代理請求首部：

       Max-Forword ：在通往後端伺服器的路徑上，将請求轉發給其他代理或網關的最大次數-與TRACE方法一同使用

       Proxy-Authorization ：與Authorization首部相同，但這個首部是在與代理進行認證時使用的

       Proxy-Connection ：與Connection首部相同，但這個首部是在與代理建立連接配接時使用的

響應封包首部：

       Age：響應持續的時間

       Server：向用戶端标明伺服器程式名稱和版本

       public：伺服器支援某資源的請求方法清單

       協商首部：

       Accept-Ranges：對目前資源來講，伺服器所能夠接受的範圍類型；

       Vary： 伺服器檢視的其他首部的清單，可能會使響應發生變化；也就是說，這是一個首部清單，伺服器會根據這些首部的内容挑選出最合适的資源版本發送給用戶端。

        跟安全相關的響應首部

        Proxy-Authenticate 來自代理伺服器對用戶端的質詢清單；

        Set-Cookie：伺服器端在某用戶端第一次請求時發給的令牌；

        Set-Cookie2：

        WWW-Authenication：質詢，即要求用戶端提供賬号和密碼；

        實體首部：

        Location：資源的新位置；

        Allow：允許對此資源使用的請求方法；

        内容首部：

        Content-Encoding：      實體使用的編碼方式

        Content-Language：     實體所使用的語言

        Content-Length：           實體的長度或尺寸

        Content-type ：              實體的類型

        Content-Range：           實體的位元組範圍

        Content-Location：       資源實際所處的位置

        緩存首部：

        ETag：與實體有關的實體标簽；

        Expires：實體内容過期标簽；

        Last-Modified：實體内容上一次的修改時間；

例如：請求封包：

GET / HTTP/1.1

Host: www.xsl.com

Connection: keep-alive

響應封包：

HTTP/1.1 200 OK

X-Powered-By: PHP/5.2.17

Vary: Accept-Encoding,Cookie,User-Agent

Cache-Control: max-age=3, must-revalidate

Content-Encoding: gzip

Content-Length: 6931

上面兩個封包的第一行通常稱為“起始行（start  line）”；後面的标簽格式内容稱作為首部域（Header field），每個首部域都有名稱（name）和值（value）組成，有多個值可以使用逗号隔開。另外，響應封包通常還有一個稱作為body的資訊主體，即響應給用戶端的内容。

web伺服器的工作流程 

web伺服器是如何工作的呢？

web伺服器的主要操作：

1、建立連接配接---接受或拒絕用戶端的連接配接請求

2、接受請求---通過網絡讀取HTTP請求封包

3、處理資源---解析請求封包并作出相應的動作

4、通路資源---通路請求封包中的相應資源

5、建構響應---使用正确的首部生成HTTP響應封包

6、發送響應---向用戶端發送生成的響應封包

7、記錄日志---把已經完成的HTTP事務記錄進日志檔案

Web伺服器處理請求的幾種架構：

1、單線程web伺服器(Single-threaded web servers)

此種架構方式中，web伺服器隻生成一個程序或線程，是以一次隻處理一個請求，結束後讀取并處理下一個請求。在某請求處理過程中，其它所有的請求将被忽略，是以，在并發請求較多的場景中将會出現嚴重的必能問題。

2、多程序/多線程web伺服器

此種架構方式中，web伺服器生成多個程序或線程并行處理多個使用者請求，程序或線程可以按需或事先生成。有的web伺服器應用程式為每個使用者請求生成一個單獨的程序或線程來進行響應，不過，一旦并發請求數量達到成千上萬時，多個同時運作的程序或線程将會消耗大量的系統資源。

3、I/O多路複用web伺服器

為了能夠支援更多的并發使用者請求，越來越多的web伺服器正在采用多路複用的架構——同步監控所有的連接配接請求的活動狀态，當一個連接配接的狀态發生改變時(如資料準備完畢或發生某錯誤)，将為其執行一系列特定操作；在操作完成後，此連接配接将重新變回暫時的穩定态并傳回至打開的連接配接清單中，直到下一次的狀态改變。由于其多路複用的特性，程序或線程不會被空閑的連接配接所占用，因而可以提供高效的工作模式。這種結構下，一個線程處理多個請求。

4、多路複用多線程web伺服器

将多程序和多路複用的功能結合起來形成的web伺服器架構，其生成多個線程，每一個線程響應多個請求。避免了讓一個程序服務于過多的使用者請求，并能充分利用多CPU主機所提供的計算能力。由于一個程序生成多個線程，這些生成的線程之間的資源是共享的，是以會産生資源。