1、HTTP: HyperTextTransfer Protocol: 超文本傳輸協議
超鏈接：
Web:
http/0.9:僅純文本(超鏈接)， ASCII，
HTML：HyperTextMark Language 超文本標記語言
<h2>Title</h2>標籤：定義字符的顯示屬性
2、Browser: 瀏覽器，也就是客戶端代理的一種
3、網絡上提供的網頁成千上百，對於客戶端來講怎樣去識別這兩個不同的文本呢？
名字一樣？但確實不同的文本，僅靠文件名來辨別是不合適的。
1.1.1.1： web, a.html
2.2.2.2: web, a.html
4、URI: UniformResource Indentifier, 全局範圍內，包括且不僅限於互聯網
統一：路徑格式上的統一
URI的子對象URL：UniformResource Locator 互聯網資源的統一表示格式
標識獲取資源的協議以及路徑等，簡單來講格式如下：
protocol://HOST:port/path/to/file
http://www.menger51.com/download/linux.tar.gz
5、web資源：http://www.menger51.com/logo.gif
多個資源很可能被整合爲一個html文檔
web資源的另一種說法也可以稱之爲web對象：
HTML文檔就是可以實現將分散在多臺服務器上的資源整合成一個頁面，並可以讓瀏覽器顯示的。
這些對象可以來自非同一臺服務器，但是可以在同一個HTML頁面中展現。
6、如何訪問資源呢？資源訪問的手段是不一樣的，http0.9協議可以從服務器端到本地，http1.0之後引入了更多的方法也可以從本地到服務器。
常用的HTTP方法：
GET
http/1.0: PUT, POST, DELETE, HEAD
put 和DELETE是一組相對應的方法，put是從遠程服務器直接獲取文件到本地的，DELETE則是在遠程服務器上刪除文件的。
而post和get則是另外一組相對應的機制，get是從遠程的服務器獲取文檔到本地瀏覽器展示的不是簡單的文件傳輸，是一種超文本文件傳輸，而post則是通過表單提交數據到服務器上去。對於服務器來講，哪一種方法最安全?都不安全，因爲它們都允許在服務器端操作一些東西，get最爲安全
7、HTTP1.0最大的改進之處在於引進了MIME機制。
1)MIME: Multipurpose Internet MailExtension, 多用途互聯網郵件擴展
lips:
SMTP: Simple Mail Transmission Protocol, 簡單郵件傳輸協議，只能傳輸純文本
但是現在貌似都可以傳輸類似MP3等多媒體的二進制文件，爲什麼呢？就是因爲引入了MIME機制。
2)MIME: 將非文本數據在傳輸前重新編碼爲文本格式，接收方能夠用相反的方式將其重新還原爲原來的格式，還能夠調用相應的程序來打開此文件
Base64編碼機制
3) http協議的元數據，記住，協議是有元數據的，在協議首部，明確添加首部類型：
瀏覽器內部或者通過接口調用插件，去解析對應MIME的文檔從而進行展現給用戶
p_w_picpath/jpeg
4)插件的出現，推動了動態效果的展示
Java開發-----> Applet插件------>JRE運行環境，展現動態效果
5)動態網頁：服務器端存儲的文檔非HTML格式，而是編程語言開發的腳本，腳本接受參數之後在服務器運行一次，運行完成之後會生成HTML格式的文檔，把生成的文檔發給客戶端；
思考：WEB服務器可以幫忙執行這些腳本嗎？
執行腳本和WEB服務器沒有半毛錢的關係，WEB服務器需要調用額外的工具來實現，比如，在某web服務器上建立了index.php或者index.jsp的文檔
客戶端去請求後綴爲.php或者.jsp等擴展名之類的文檔時，WEB服務器不會理解響應，WEB服務可能是通過某種協議，某種外在的配置，某種連接協議，去調用一個額外的運行程序，比如去調用PHP的解釋器，讓PHP的解釋器去運行運行index.php，運行之後會生成結果，結果自身會被格式化成HTML文檔；把生成的文檔再發給WEB服務器。通過協議返回給WEB服務器，WEB服務器再返回給客戶端。
web --> procotol --> php (運行index.php)
小結：執行腳本的過程和WEB服務器沒關係，因爲WEB服務器只是一個HTTP服務器，它並不負責處理動態內容。
WEB服務器是一個具體的應用，只要是一個具體應用就是一個具體的軟件，這個軟件就應該在用戶空間，這個進程一定在用戶空間，用戶所能夠訪問的網頁文檔在什麼地方存放着？文檔都在磁盤上存放，因此當客戶端向服務器發起請求的時候，請求先到達內核空間，爲什麼呢？因爲客戶端的請求一定是通過網絡協議過來的，協議工作在什麼位置？tcp/ip在什麼地方工作？在內核裏面，所以客戶端的請求首先到達內核，內核空間接收到用戶請求以後，通過在內核的tcp/ip協議棧當中通過各種路由機制等，發現用戶訪問的是本機80端口的套接字，怎麼辦？
WEB服務一旦啓動以後，一定會監聽在tcp的80端口上，於是內核就將這個請求通過套接字轉給外部的WEB服務器了，於是執行流程就從內核空間到了用戶空間；WEB服務器發現用戶訪問的是一個文件，以Index.html爲例，此時服務器端就重新陷入內核，重新轉換爲內核模式，到磁盤上把index.html把文件加載過來，內核找到此文件以後再返回給用戶空間，就到了WEB服務器了，WEB服務器發現文件取出來了，就可以響應客戶端了，再通過套接字，通過網絡的tcp/ip協議棧最終響應客戶端；
WEB服務響應簡圖
8、根據上圖，如果用戶請求的是一個動態網頁會發生什麼情況呢？通過其他協議，啓動另外一個進程，這個進程一定是一個解釋器，bash--->bash解釋器 PHP--->PHP解釋器；通過協議把文檔傳遞給解釋器，或者說解釋器自身可以訪問文檔也是可以的，於是將這個請求讀取到解釋器，而後執行一遍，將執行結果返回給WEB服務器；WEB服務器將返回結果通過網絡協議再傳給用戶。
注意：進程的啓動、創建、銷燬都是系統的資源開銷；一個客戶端是無所的，當成千上萬個客戶端呢?10000個用戶請求同時到達我們的服務器，我們的服務器是不是要啓動10000個這樣的進程，可想而知，一個機器上運行10000個進程會怎麼樣呢？
一個進程消耗20MB內存，10000*20MB=200000MB
9、http/1.0引入了一種重要的機制，緩存機制
10、HTTP格式報文
(1)ip首部裏面包含
sourceip源Ip也就是客戶端ip
destinationip 目標ip 也就是服務器端ip
(2)TCP首部包含
sourcePort 源端口
destinationPort 目標端口
(3)HTTP首部
GET/1.html
host:www.menger51.com(爲虛擬主機提供準備的)
小結：HTTP報文包括兩種。1、請求報文 2、響應報文
(4)請求報文語法：
<method> <request-URL><version> #起始行
<headers> #報文首部
#空白行是必須的，無論是請求還是響應
<entity-body> #請求主體
(5)響應報文語法：
<version> <status><reason-phrase> #起始行
<headers> #報文首部
#空白行是必須的，無論是請求還是響應
<entity-body> #響應主體
(6)HTTP協議訪問5類狀態代碼:
1xx: 純信息
2xx: “成功”類的信息 (200, 201,202)
3xx：重定向類的信息 (301永久重定向, 302臨時重定向, 304沒有發生任何改變)
4xx: 客戶端錯誤類的信息 (404)
5xx：服務器端錯誤類的信息
(7)請求報文：
GET / HTTP/1.1
Host: www.menger51.com
Connection: keep-alive
(8)響應報文：
HTTP/1.1 200 OK
X-Powered-By: PHP/5.3.37
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的信息主體，即響應給客戶端的內容。
11、Web服務器的主要操作
1)、建立連接——接受或拒絕客戶端連接請求；
2)、接收請求——通過網絡讀取HTTP請求報文；
3)、處理請求——解析請求報文並做出相應的動作；
4)、訪問資源——訪問請求報文中相關的資源；
5)、構建響應——使用正確的首部生成HTTP響應報文；
6)、發送響應——向客戶端發送生成的響應報文；
7)、記錄日誌——當已經完成的HTTP事務記錄進日誌文件；
5s: 10張 p_w_picpath圖片, 10 個css文件, 5個html頁面一個網頁總共有25個資源，這25個資源都是需要，逐個的去請求；每一個資源都是單獨請求，單獨傳輸的；
所以打開一個web頁面，可能是需要發起N次請求的。
12、http是屬於tcp的協議，因此每一個TCP的建立都需要: 三次握手獲取資源，資源拿到以後還需要四次斷開連接；25個資源，握三次獲取一個，再斷開；握三次獲取一個，再斷開，如此反覆；服務器端需要消耗非常多的資源來響應一個用戶的HTTP請求，所以我們說服務器壓力很大，當然了，客戶端也很着急哈！客戶端不管你壓力大不大，對吧?手機沒搶到，怎麼辦？孩子網上的作業無法按時提交，怎麼辦？這些都是非常讓人鬱悶的哦！
所以，如果用戶請求的是一個靜態內容，以圖片爲例，無論網站打開幾次，圖片一般是不會改變的，那怎麼辦呢？將這些內容先給緩存起來不就可以了？
所以瀏覽器大多數都支持本地緩存的。
瀏覽器刷新的小祕密：打開一個網頁，網頁內容下載到本地以後，第二次再打開速度就會非常快，因爲很多的靜態內容都是從本地的緩存中返回的。
那應不應該經常去刷新頁面呢？
刷新頁面意味着什麼？無論本地緩存存不存在，都要去重新下載一次這個文件的，所以沒事的時候不要亂刷新哦！當然了刷新可以有助於及時更新頁面。
現在可以弄明白，一些清理垃圾的軟件，說您的電腦上有多少垃圾，其實很多都是緩存的內容罷了；尤其是現在比較流行的智能手機上，沒事清理一下垃圾，第二次打開一個網頁的時候，會發現多了很多的流量出來；
所以，大家一定要弄懂，這些瀏覽器的緩存是爲加速訪問網站而專門設計的；想讓他失效讓其刷新一下即可，不需要去清理垃圾，那不是垃圾，那是加速你的系統訪問的速度的。
是一種加速手段。
當然了，如果你訪問的是一些，哈哈，你懂的，清理一下還是很有意義的。
13、http/1.1引入了兩種比較重要的功能：
(1)增強了緩存的功能
(2)長連接機制好處：讓同一個客戶端訪問同一個資源請求的時候，儘可能縮短時間，也降低服務器端資源佔用率
壞處：當服務器端併發量巨大無比的時候，後面來的客戶端恐怕就很難再建立連接了，但大多數情況下，只要你的服務器端的訪問量沒有大到無與倫比的地步，那麼使用長連接，可以顯著的提高服務器性能。
再者，如果使用長連接，客戶端建立連接以後再也不斷開了，那麼帶來的直接後果是什麼？
客戶端不斷的請求資源，請求完第一個請求第二個等等如此反覆請求，請求了十天十夜；那也就意味着這個連接要建立十天十夜，後面的用戶要永遠處於等待狀態嗎？
所以服務器端，也有限制，限定1、定義空閒超時時間 2、定義最多隻能請求多少次，也就是一個客戶端可以建立多少連接數
14、Web服務器處理併發連接請求的架構方式
1)、單線程web服務器(Single-threadedweb servers) 此種架構方式中，web服務器一次處理一個請求，結束後讀取並處理下一個請求。在某請求處理過程中，其它所有的請求將被忽略，因此，在併發請求較多的場景中將會出現嚴重的必能問題。 2)、多進程/多線程web服務器 此種架構方式中，web服務器生成多個進程或線程並行處理多個用戶請求，進程或線程可以按需或事先生成。有的web服務器應用程序爲每個用戶請求生成一個單獨的進程或線程來進行響應，不過，一旦併發請求數量達到成千上萬時，多個同時運行的進程或線程將會消耗大量的系統資源。 3)、I/O多路複用web服務器 爲了能夠支持更多的併發用戶請求，越來越多的web服務器正在採用多種複用的架構——同步監控所有的連接請求的活動狀態，當一個連接的狀態發生改變時(如數據準備完畢或發生某錯誤)，將爲其執行一系列特定操作；在操作完成後，此連接將重新變回暫時的穩定態並返回至打開的連接列表中，直到下一次的狀態改變。由於其多路複用的特性，進程或線程不會被空閒的連接所佔用，因而可以提供高效的工作模式。 4)、多路複用多線程web服務器 將多進程和多路複用的功能結合起來形成的web服務器架構，其避免了讓一個進程服務於過多的用戶請求，並能充分利用多CPU主機所提供的計算能力。 5)代理 Web代理服務器工作於web客戶端和web服務器之間，它負責接收來自於客戶端的http請求，並將其轉發至對應的服務；而後接收來自於服務端的響應，並將響應報文回送至客戶端。
小結：實際上WEB服務器是一種c/s架構的模型，只不過有時候也稱之爲b/s架構，c指的是客戶端代理程序client agent，最著名的莫過於瀏覽器browser了，除了瀏覽器之外還有robot機器人，spider--網絡蜘蛛--搜索引擎
服務器端是s程序 server
client發起---->request請求報文--->server
server構建報文--->response---->client
因此就有了請求報文和響應報文。
思考：1、客戶端請求的是什麼樣的報文，靠什麼來標記呢？
靠URL來標記用戶請求的資源
2、請求資源在什麼地方向服務器傳遞呢？
通過報文的首部，報文首部明確說明 get什麼？post什麼？等，因此報文格式很關鍵，請求報文有請求報文的格式，響應報文有響應報文的格式。
3、HTTP method 資源的獲取方法
get head pos t put delete trace options connection
4、HTTP狀態碼 略
5、server操作 server模型
以Apache的httpd爲例MPM
1)prefork模型
2)worker模型
3)event模型
6、常用客戶端瀏覽器
client：
IE
Firefox
chrome
opera
Safari
server：
Apache-->httpd
IIS
nginx
lighttpd
thttpd嵌入式平臺
7、應用程序服務器
IIS
tomcat(Apache)
WebSphere(IBM,jsp,commodity)
WebLogic(BEAoracle收購)
Jboss(RedHat)