Apache httpd服務——HTTP協議

HTTP協議

​HTTP協議的版本有：http/0.9, http/1.0, http/1.1, http/2.0；HTTP協議是無狀態的，服務器無法持續追蹤客戶端的來源，解決HTTP協議無狀態的方法有Cookie和Session；一次訪問的過程請求(request)和響應(response)為HTTP事務

http請求報文

http響應報文

http報文

• request報文

<method> <request-URL> <version> <headers> <entity-body> 

• response報文

<version> <status> <reason-phrase> <headers> <entity-body> 

method: 請求方法，標明客戶端希望服務器對資源執行的動作

GET：從服務器獲取一個資源
HEAD：只從服務器獲取文檔的響應首部
POST：向服務器輸入數據，通常會再由網關程序繼續處理
PUT：將請求的主體部分存儲在服務器中，如上傳文件
DELETE：請求刪除服務器上指定的文檔
TRACE：追蹤請求到達服務器中間經過的代理服務器
OPTIONS：請求服務器返回對指定資源支持使用的請求方法

status：標記請求處理過程中發生的情況，如200，301, 302, 404, 502

200： 成功，請求數據通過響應報文的entity-body部分發送；OK
301： 請求的URL指向的資源已經被刪除；但在響應報文中通過首部Location指明了資源現在所處的新位置；Moved Permanently
302： 響應報文Location指明資源臨時新位置；Moved Temporarily
304： 客戶端發出了條件式請求，但服務器上的資源未曾發生改變，則通過響應此響應狀態碼通知客戶端；Not Modified
401： 需要輸入賬號和密碼認證方能訪問資源；Unauthorized
403： 請求被禁止；Forbidden
404： 服務器無法找到客戶端請求的資源；Not Found
500： 服務器內部錯誤；Internal Server Error
502： 代理服務器從后端服務器收到了一條偽響應，如無法連接到網關；Bad Gateway
503： 服務不可用，臨時服務器維護或過載，服務器無法處理請求
504： 網關超時

reason-phrase：狀態碼所標記的狀態的簡要描述

headers：每個請求或響應報文可包含任意個首部；每個首部都有首部名稱，后面跟一個冒號，而后跟一個可選空格，接着是一個值

entity-body：請求時附加的數據或響應時附加的數據

HTTP 首部字段

1. HTTP 首部字段包含的信息最為豐富。首部字段同時存在於請求和響應報文內，並涵蓋 HTTP 報文相關的內容信息。使用首部字段是為了給客服端和服務器端提供報文主體大小、所使用的語言、認證信息等內容；
2. 首部字段結構HTTP 首部字段是由首部字段名和字段值構成的，中間用冒號“:”分隔；
3. 字段值對應單個 HTTP 首部字段可以有多個值；
4. 報文首部中出現了兩個或以上具有相同首部字段名的首部字段時，在規范內尚未明確，根據瀏覽器內部處理邏輯的不同，優先處理的順序可能不同，結果可能並不一致。

• 通用首部:請求報文和響應報文兩方都會使用的首部

Date：報文的創建時間
Connection：連接狀態，如keep-alive, close
Via：顯示報文經過的中間節點（代理，網關）
Cache-Control：控制緩存，如緩存時長
MIME-Version：發送端使用的MIME版本
Warning：錯誤通知

• 請求首部:從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、請求內容相關優先級等信息

請求首部：
Accept：通知服務器自己可接受的媒體類型
Accept-Charset： 客戶端可接受的字符集
Accept-Encoding：客戶端可接受編碼格式，如gzip
Accept-Language：客戶端可接受的語言
Client-IP: 請求的客戶端IP
Host: 請求的服務器名稱和端口號
Referer：跳轉至當前URI的前一個URL
User-Agent：客戶端代理，瀏覽器版本

條件式請求首部：
Expect：允許客戶端列出某請求所要求的服務器行為
If-Modified-Since：自從指定的時間之后，請求的資源是否發生過修改
If-Unmodified-Since：與上面相反
If-None-Match：本地緩存中存儲的文檔的ETag標簽是否與服務器文檔的Etag不匹配
If-Match：與上面相反

安全請求首部：
Authorization：向服務器發送認證信息，如賬號和密碼
Cookie：客戶端向服務器發送cookie
Cookie2：用於說明請求端支持的cookie版本

代理請求首部：
Proxy-Authorization：向代理服務器認證

• 響應首部：從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息

信息性：
Age：從最初創建開始，響應持續時長
Server：服務器程序軟件名稱和版本
協商首部：某資源有多種表示方法時使用
Accept-Ranges：服務器可接受的請求范圍類型
Vary：服務器查看的其它首部列表
安全響應首部：
Set-Cookie：向客戶端設置cookie
Set-Cookie2: 以上面相似
WWW-Authenticate：來自服務器對客戶端的質詢列表

• 實體首部：針對請求報文和響應報文的實體部分使用的首部。補充了資源內
  容更新時間等與實體有關的的信息

​ Allow: 列出對此資源實體可使用的請求方法
Location：告訴客戶端真正的實體位於何處
Content-Encoding:對主體執行的編碼
Content-Language:理解主體時最適合的語言
Content-Length: 主體的長度
Content-Location: 實體真正所處位置
Content-Type：主體的對象類型，如text
緩存相關：
ETag：實體的擴展標簽
Expires：實體的過期時間
Last-Modified：最后一次修改的時間

• 擴展首部

Cookie

​HTTP 是一種無狀態協議。協議自身不對請求和響應之間的通信狀態進行保存。也就是說在 HTTP 這個級別，協議對於發送過的請求或響應都不做持久化處理。這是為了更快地處理大量事務，確保協議的可伸縮性，而特意把 HTTP 協議設計成如此簡單的。可是隨着 Web 的不斷發展，很多業務都需要對通信狀態進行保存。於是引入了 Cookie 技術。使用 Cookie 的狀態管理Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值后發送出去。服務器端發現客戶端發送過來的 Cookie 后，會去檢查究竟是從哪一個客戶端發來的連接請求，然后對比服務器上的記錄，最后得到之前的狀態信息

Set-cookie首部字段示例：

~]# curl -v pan.baidu.com
Set-Cookie: BAIDUID=0D82F2DA4E71EFDE069D8C6BC7D7F22E:FG=1; expires=Fri, 21-Jun-19 03:48:53 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

NAME=VALUE 賦予 Cookie 的名稱和其值,此為必需項
expires=DATE Cookie 的有效期，若不明確指定則默認為瀏覽器關閉前為止
path=PATH 將服務器上的文件目錄作為Cookie的適用對象，若不指定則默認為文檔所在的文件目錄
domain=域名 作為 Cookie 適用對象的域名，若不指定則默認為創建Cookie的服務器的域名
Secure 僅在 HTTPS 安全通信時才會發送 Cookie
HttpOnly 加以限制使 Cookie 不能被 JavaScript 腳本訪問

示例：查看cookie

~]# yum install httpd php -y
~]# vim /var/www/html/setcookie.php
<?php
setcookie("title","hello world")
?>
~]# vim /var/www/html/index.php
<?php
echo $_COOKIE["title"];
var_dump($_COOKIE);
?>
~]# systemctl start httpd

先訪問：http://192.168.0.7/setcookie.php

再訪問：http://192.168.0.7/index.php

顯示：

hello worldarray(1) { ["title"]=> string(11) "hello world" }

則說明cookie已經生效

一次完整的http請求處理過程

1. 解析請求：客戶通過FQDN訪問，先由DNS服務器解析為IP地址，返回給客戶端目標IP地址
2. 建立連接：接收連接請求
3. 接收請求：接收客戶端請求報文中對某資源的一次請求的過程
4. 處理請求：服務器對請求報文進行解析，並獲取請求的資源及請求方法等相關信息，根據方法，資源，首部和可選的主體部分對請求進行處理
5. 獲取資源：服務器獲取請求報文中請求的資源web服務器，即存放了web資源的服務器，負責向請求者提供對方請求的靜態資源，或動態運行后生成的資源
6. 構建響應報文：一旦Web服務器識別除了資源，就執行請求方法中描述的動作，並返回響應報文。響應報文中 包含有響應狀態碼、響應首部，如果生成了響應主體的話，還包括響應主體
7. 發送響應報文：Web服務器通過連接發送數據時也會面臨與接收數據一樣的問題。服務器可能有很多條到各個客戶端的連接，有些是空閑的，有些在向服務器發送數據，還有一些在向客戶端回送響應數據。服務器要記錄連接的狀態，還要特別注意對持久連接的處理。對非持久連接而言，服務器應該在發送了整條報文之后，關閉自己這一端的連接。對持久連接來說，連接可能仍保持打開狀態，在這種情況下，服務器要正確地計算Content-Length首部，不然客戶端就無法知道響應什么時候結束了
8. 記錄日志：最后，當事務結束時，Web服務器會在日志文件中添加一個條目，來描述已執行的事務

Apache HTTP Server介紹

​ 簡稱Apache，是Apache軟件基金會的一個開放源代碼的網頁服務器軟件，可以在大多數計算機操作系統中運行。由於其跨平台和安全性，被廣泛使用，是最流行的Web服務器軟件之一。它快速、可靠並且可通過簡單的API擴充，將Perl／Python等解釋器編譯到服務器中。

特性：

• 高度模塊化：core + modules
• DSO: Dynamic Shared Object 動態加/卸載
• MPM：multi-processing module多路處理模塊
• prefork：多進程I/O模型，每個進程響應一個請求，默認模型

一個主進程：生成和回收n個子進程，創建套接字，不響應請求

多個子進程：工作work進程，每個子進程處理一個請求；系統初始時，預先生成多個空閑進程，等待請求，最大不超過1024個

• worker：復用的多進程I/O模型,多進程多線程，IIS使用此模型

一個主進程：生成m個子進程，每個子進程負責生個n個線程，每個線程響應一個請求，並發響應請求：m*n

• event：事件驅動模型（worker模型的變種）

一個主進程：生成m個子進程，每個進程直接響應n個請求，並發響應請求：m*n，有專門的線程來管理這些keep-alive類型的線程，當有真實請求時，將請求傳遞給服務線程，執行完畢后，又允許釋放。這樣增強了高並發場景下的請求處理能力

• 虛擬主機：IP，Port，FQDN
• CGI：Common Gateway Interface，通用網關接口
• 反向代理
• 支持第三方模塊