http簡介：
超文本的傳輸協議，
http協議是無狀態的,在非持久連接中客戶端每次對服務端進行資源請求都會進行三次握手,所以每次請求都是一相對服務器都是一個新的請求,所以服務器無法追蹤訪問者來源.
解決http無狀態的實現:
cookie :在客戶端向服務端第一次發送請求時,服務端會生成一個cookie(一段隨機的數據,此段數據能唯一的標識出客戶機),並將cookie發送個客戶端,客戶端保存在本地,每個cookie都有固定的作用範圍.在客戶端在非第一連接服務端時都會將適用於該服務器的cookie發送至服務端.所以服務端可以基於cookie識別出用戶的身份.
cookie可以分爲胖cookie與瘦cookie,
session :cookie會被關聯至session上
http的事務:
http一次請求一次響應對應一個事務。所以http的報文分爲兩種格式，請求報文（request），響應報文（response）
請求報文格式：
request報文
method: 請求方法，標明客戶端希望服務器對資源執行的動作
GET：從服務器獲取一個資源
HEAD：只從服務器獲取文檔的響應首部
POST：向服務器輸入數據，通常會再由網關程序繼續處理
PUT：將請求的主體部分存儲在服務器中，如上傳文件
DELETE：請求刪除服務器上指定的文檔
TRACE：追蹤請求到達服務器中間經過的代理服務器
OPTIONS：請求服務器返回對指定資源支持使用的請求方法
響應報文
response報文
status(狀態碼)：
1xx： 100-101 信息提示
2xx： 200-206 成功
200： 成功，請求數據通過響應報文的entity-body部分發送;OK
3xx： 300-305 重定向
301： 請求的URL指向的資源已經被刪除；但在響應報文中通過首部Location指明瞭資源現在所處的新位置； 永久重定向 Moved Permanently
302： 與301相似，但在響應報文中通Location指明資源現在所處臨時新位置; 臨時重定向Moved Temporarily
304： 客戶端發出了條件式請求，但服務器上的資源未曾發生改變，則通過響應此響應狀態碼通知客戶端； Not Modified
4xx： 400-415 錯誤類信息，客戶端錯誤
401： 需要輸入賬號和密碼認證方能訪問資源； Unauthorized
403： 請求被禁止； Forbidden
404： 服務器無法找到客戶端請求的資源； Not Found
5xx： 500-505 錯誤類信息，服務器端錯誤
500： 服務器內部錯誤； Internal Server Error
502： 代理服務器從後端服務器收到了一條僞響應，如無法連接到父網關； Bad Gateway
請求首部：
通用首部
Date: 報文的創建時間
Connection：連接狀態，如keep-alive, close
Via：顯示報文經過的中間節點（代理，網關）
Cache-Control：控制緩存，如緩存時長
MIME-Version:發送端使用的MIME版本
請求首部
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：最後一次修改的時間
擴展首部
沒講
http版本：
http/0.9 ：http協議的原型版本，僅支持簡單的資源交互，並不支持多媒體。或者說只能支持html超文本語言，而html 中只能存在超鏈接。
http/1.0 ：在原有的基礎上增加了http首部，http請求類型，以及MEMI機制
http/1.1 :增強了緩存功能
http/2.0 :
MEMI介紹：
MEMI稱爲多用途互聯網郵件擴展，MEMI可應將多媒體信息在傳輸時以文本的編碼進行傳輸，客戶端收到後進行逆操作，在傳輸數據時對傳輸的數據附加類型標記，從而實現了使用文本傳輸非文本。標記分爲主類型與次類型，
響應報文中的類型與請求的文件後綴有關。或者受響應報文中MEMI對文件類型的標示依據是文件的後綴。
類型：
主類型/次類型
major/minor
text/plain
text/html
text/css
image/jpeg
image/png
video/mp4
application/javascript
http的資源獲取：
web資源：
web資源可以理解成可以被http獲取到的文件，或者說被當成請求對象的資源。web資源可以被分爲靜態資源與動態資源，
http資源請求：
一個網頁可能需要進行多次請求，獲取 多個資源 ，但是最開始只獲取一個初始的html頁面。後續html文件中需要表現出來的文件，再次發起請求。
而且網頁上的資源不一定在自己的服務器上，也可以應用別人的服務器上的資源。可以通過盜鏈技術實現
訪問量計數：
網站的訪問量統計使用pv uv表示：
pv：pv統計的是頁面的訪問量，每次對頁面發送一次資源請求，即算作一次pv
uv：uv統計的是網站的訪客數，此判斷是基於cookie實現的，即一個cookie訪問了某網站，無論該客戶端訪問了多少頁面，發送了多少資源請求。都算作一次該網站的一次uv
資源定位：
web的資源定位通過URI技術進行實現，URI技術又分爲URL與URN
URI：統一資源標識符
URL：統一資源定位符
URL的組成部分:://:@:/;?#
schame:方案，訪問服務器以獲取資源時要使用哪種協議
user:用戶，某些方案訪問資源時需要的用戶名
password:密碼，用戶對應的密碼，中間用：分隔
Host:主機，資源宿主服務器的主機名或IP地址
port:端口,資源宿主服務器正在監聽的端口號，很多方案有默認端口號
path:相對於網站的根的路徑,根即是經有domortroot 或alias 進行映射後的地址 爲起始點，由一個/將其與前面的URL組件分隔,
params:參數，某些方案用這個組件來指定輸入的參數，參數爲名/值對，URL中可多含多個參數，用;分隔,對於動態頁面有效,即根據傳入的參數返回對應的頁面或返回的頁面中的某些特定內容.
query:查詢，某些方案會用這個組件傳遞參數以激活程序，如數據庫，用？與前面的參數項分隔,多個查詢用&分隔,當前傳遞的目標爲數據庫時,以鍵與值的方式出現如name=tom.
frag:片段,一小片或一部分資源的名字，即錨點,此組件在客戶端使用，用#分隔
URL分類:
相對URL,相對於當前資源的位置獲取下一個資源的位置,相對URL一般都是用在同站的資源引用上
絕對URL,完整的URL,一般使用在跨站引用上.
URN：統一資源命名符
資源訪問重定向：
url重定向。重定向可以實現負載均衡。重定向技術使用一種特殊的響應報文實現 。將客戶訪問的資源路徑並非是客戶端輸入的。但是可以訪問到該資源。 或者將客戶訪問的路徑替換成其他的路徑
服務器的路徑映射：
url的根就是 本地服務器的起始路徑。
實現方式
docroot
路徑別名
虛擬主機映射
用戶家目錄映射
請求響應模塊的分類：
單進程中單線程：在linux中進程與線程沒有絕對的界限，線程也在任務列隊中，該設計爲串行結構每次只能處理一個請求，後續的請求會進入排隊狀態。
多進程中單線程：並行啓動多個進程，每個線程中只有一個線程。每個進程響應一個請求，而不是一個用戶的請求，一個用戶獲取資源時可能發起多個請求，所以這些請求被多個進程處理 ，而不是一個京城處理一個用戶的所有請求。
複用IO：複用IO大多數基於事件驅動，一個進程內部維護一個事件監控器，監控多個IO，也可以基於進程中多線程，一個進程生成多個線程，每個線程處理一個請求。具體體現是一個進程可以響應多個請求
複用的多進程IO結構：啓動多個進程 ，每個進程響應N個請求
注：多進程之間進行切換會佔用造成大量的時間消耗，但是多進程中，其中一個進程崩潰不影響其他進程。
處理請求：
對請求報文進行分析，從而獲取請求的資源，請求的分析需要基於HTTP協議設定的規格。請求的元數據存放在http報文的頭部，也叫首部，
首部的構成格式：
操作數據的方法（上傳下載同步），資源的url，協議的版本
host 請求的主機名稱，及服務端的地址
完整http通信描述：
1. 客戶端發起tcp三次握手請求，服務端接受請求，或因客戶端不符合要求而拒絕三次握手請求。
2. 三次握手建立成功，客戶端發送資源獲取請求，服務端進行響應，具體響應需根據服務端的響應機制而定。響應可以有多種實現思路。
3. 對就收的資源請求進行處理，即解析客戶端發出的請求報文。判斷http報文的首部。資源的url，請求的本地主機地址等
4. 向內核發起申請，進程獲取需要需求的資源
5. 進程構建響應，服務端找到被客戶端需求的資源並且客戶端有權限對該資源進行訪問。將資源封裝爲一個響應報文。並對報文內部 的資源類型進行標識。也可能時資源重定向報文。
6. 發送報文，使用80 信道進行發送
7. 記錄日誌，以配置文件設定的格式將記錄記錄到日誌中