目錄結構：
我們平時在瀏覽網頁的時候都是使用瀏覽器，輸入你想要的網站後回車，就會顯示出我們所想要的內容，看似這個簡單的用戶操作行爲的背後，Web的工作原理是怎樣的呢，到底隱藏了什麼？
對於傳統的上網流程，系統它是這麼做的：瀏覽器本身它是一個客戶端，當輸入URL地址的時候，瀏覽器首先會去請求DNS服務器，通過DNS查詢獲取相應的域名所對應的IP地址，然後通過這個映射的IP地址找到IP對應的服務器，並建立連接，等瀏覽器發送完HTTP Request(請求)包後，服務器接收到請求包之後纔開始處理，返回HTTP Response(響應)包，客戶端瀏覽器收到來自服務器的響應後就開始渲染這個Response包裏的主體(body)部分，等收到全部的內容後斷開與該服務器之間的連接
一個Web服務器也被稱爲HTTP服務器，它通過HTTP協議與客戶端通信，這個客戶端通常指的是Web瀏覽器(其實手機端客戶端內部也是瀏覽器實現的)
Web服務器的工作原理的簡單定義
一個簡單的HTTP事務就是這樣實現的，看上去很複雜，原理其實挺簡單，需要注意的是客戶機與服務器之間的通信是非持久連接的，也就是當服務器發送了應答後就與客戶機斷開連接，等待下一次請求
URL和DNS解析
我們瀏覽網頁都是通過URL訪問的，那麼URL到底是什麼樣的呢？
URL(Uniform Resource Locator)是“統一資源定位符”的英文縮寫，用於描述一個網絡上的資源，基本格式如下：
scheme://host[:port#]/path/.../[?query-string][#anchor]
DNS(Domain Name System)是“域名系統”的英文縮寫，是一種組織成域層次結構的計算機和網絡服務命名系統，它用於TCP/IP網絡，它從事將主機名或域名轉換爲實際IP地址的工作，DNS就是這樣的一位“翻譯官”，它的基本工作原理可用下圖表示：
DNS工作原理
更詳細的DNS解析的過程如下，這個過程有助於我們理解DNS的工作模式：
1).在瀏覽器中輸入www.qq.com域名，操作系統會先檢查自己本地的hosts文件是否有這個網絡映射關係，如果有，就先調用這個IP地址映射，完成域名解析
2).如果hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關係，如果有，直接返回，完成域名解析
3).如果hosts與本地DNS解析器緩存都沒有響應的網址映射關係，首先會找TCP/IP參數中設置的首選DNS服務器，再次我們叫它本地DNS服務器，此服務器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具有權威性
4).如果要查詢的域名，不由本地DNS服務器區域解析，但該服務器已緩存了此網址的映射關係，則調用這個IP地址映射，完成域名解析，此解析不具有權威性
5).如果本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置(是否設置轉發器)進行查詢，如果未用轉發模式，本地DNS就把請求發送至“根DNS服務器”，“根DNS服務器“收到請求後會判斷這個域名(.com)是誰來授權管理，並會返回一個負責該頂級域名服務器的一個IP，本地DNS服務器收到IP請求後，將會聯繫負責.com域的這臺服務器，這臺負責.com域的服務器收到請求後，如果自己無法解析，它就會找一個管理.com域的下一級DNS服務器地址(qixing318.com)給本地DNS服務器，當本地DNS服務器收到這個地址後，就會找qixing318.com域服務器，重複上面的動作，直至找到www.qixing318.com主機
6).如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把請求轉至上上級，以此循環，不管是本地DNS服務器用的是轉發，還是根提示，最後都是把結果返回給本地DNS服務器，因此DNS服務器再返回給客戶機
DNS解析的整個流程
所謂遞歸查詢過程就是”查詢的遞交者“ 更替，而 迭代查詢過程則是”查詢的遞交者“ 不變
舉個栗子來說，你想知道某個一起上法律課的女孩的電話，並且你偷偷拍了她的照片，回到寢室告訴一個很仗義的哥們兒，這個哥們兒二話沒說，拍着胸脯告訴你，甭急，我替你查(此處完成了一次遞歸查詢，即問詢者的角色更替)，然後他拿着照片問了學院大四學長，學長告訴他，這姑娘是xx系的；然後這哥們馬不停蹄又問了xx系的辦公室主任助理同學，助理同學說是xx系xx班的，然後很仗義的哥們去xx系yy班的班長哪裏取到了該女孩兒電話(此處完成若干次迭代查詢， 即問詢者角色不變，但反覆更替問詢對象)，最後他把號碼交到了你的手裏，完成整個查詢過程
通過上面的步驟，我們最後獲取的是IP地址，也就是瀏覽器最後發起請求的時候是基於IP來和服務器做信息交互的
HTTP協議詳解
HTTP協議是Web工作的核心，所以要了解清楚Web的工作方式就需要詳細的瞭解清楚HTTP是怎樣工作的
HTTP是一種讓Web服務器與瀏覽器（客戶端）通過Internet發送與接收數據的協議，它建議在TCP協議之上，一般採用TCP的80端口，它是一個請求、響應協議–客戶端發出一個請求，服務器響應這個請求
在HTTP中，客戶端總是通過建立一個連接與發送一個HTTP請求來發起一個事務，服務器不能主動去與客戶端聯繫，也不能給客戶端發出一個回調連接，客戶端與服務器端都可以提前終端一個連接，例如當瀏覽器下載一個文件時，你可以通過點擊“停止”鍵來中斷文件的下載，關閉與服務器的HTTP連接
HTTP協議是無狀態的，同一個客戶端的這次請求和上次請求是沒有對應關係，對HTTP服務器來說，它並不知道這兩個請求是否來自於同一個客戶端，爲了解決這個問題，Web程序引入了Cookie機制來維護連接的可持續狀態
HTTP協議是建立在TCP協議之上的，因此TCP攻擊一樣會影響HTTP的通訊，例如比較常見的一些攻擊：
SYN Flood是當前最流行的DoS（拒絕服務攻擊）與Ddos（分佈式拒絕服務攻擊）的方式之一，這是一種利用TCP協議缺陷，發送大量僞造的TCP連接請求，從而使得被攻擊方資源耗盡(CPU滿負荷或內存不足)的攻擊方式
HTTP請求包（瀏覽器信息）
我們先來看看Request包的結構，Request分爲三部分，第一部分叫Request line(請求行)，第二部分叫Request header(請求頭)，第三部分是body(主體)
header和body之間有個空行，請求包的例子如下：
| 方法 | 說明 |
|---|---|
| GET /domains/example/ HTTP/1.1 | 請求行：請求方法 請求URI HTTP協議/協議版本 |
| Host: www.qixing318.com | 服務器的主機名 |
| User-Agent: Mozilla/5.0(Windows NT 6.1)AppleWebkit/537.4(KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 | 客戶端瀏覽器信息 |
| Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 | 客戶端能接受的mine類型 |
| Accept-Encoding:gzip,deflate,sdcn | 是否支持流壓縮 |
| Accept-Charset:UTF-8,*;q=0.5 | 客戶端字符編碼集 |
| “\r\n\r\n” | 空行，用於分隔請求頭和消息體 |
| “\r\n\r\n” | 空行，消息體，請求資源參數，例如POST傳遞的參數 |
HTTP協議定義了很多與服務器交互的請求方法，最基本的有4種：GET, POST, PUT, DELETE，一個URL地址對於描述一個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應着對這個資源的**查、增、刪、改**4個操作，我們最常見的就是GET和POST了，GET一般用於獲取/查詢資源信息，而POST一般用於更新資源信息
通過fiddler抓包看到的請求信息
抓取的GET信息：
抓取的POST信息：
GET和POST的區別
1.我們可以看到GET請求消息體爲空，POST請求帶有消息體
2.GET提交的數據會放在URL之後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456，而POST提交的數據沒有限制
3.GET提交的數據大小有限制（因爲瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制
4.GET方式提交數據，會帶來安全問題，比如一個登陸頁面，通過GET方式提交數據時，用戶名和密碼將出現在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該用戶的賬號和密碼
HTTP響應包（服務器信息）
結構如下：
| 方法 | 說明 |
|---|---|
| HTTP/1.1 200 OK | 狀態行 |
| Server:nginx/1.0.8 | 服務器使用的WEB軟件名及版本 |
| Date:Date:Tue, 30 Oct 2014 12:32:23 GMT | 發送時間 |
| Content-Type:text/html | 服務器發送信息的類型 |
| Transfer-Encoding:chunked | 表示發送HTTP包是分段發的 |
| Connection:keep-alive | 保持連接狀態 |
| Content-:Length:90 | 消息主題內容長度 |
| \r\n | 空行，用來分隔消息頭和主體 |
| 消息體部分 |
Response包中的第一行叫做狀態行，由HTTP協議版本號，狀態碼，狀態消息三部分組成
狀態碼用來告訴HTTP客戶端，HTTP服務器是否產生了預期的Response，HTTP/1.1協議中定義了5類狀態碼，狀態碼由三位數字組成，第一個數字定義了響應的類別
1XX： 提示信息-表示請求已被成功接收，繼續處理
2XX： 成功-表示請求已被成功接收，理解，接受
3XX： 重定向-要完成請求必須進行更進一步的處理
4XX： 客戶端錯誤-請求有語法錯誤或請求無法實現
5XX：服務器端錯誤-服務器未能實現合法的請求
我們看下面這個圖展示了詳細的返回信息，左邊可以看到有很多的資源返回碼，200是常用的，表示正常信息，302表示跳轉，response header裏面展示了詳細的信息
HTTP協議是無狀態的和Connection:keep-alive的區別
無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態，從另一方面講，打開一個服務器上的網頁和你之前打開的服務器上的網頁之間沒有任何聯繫
HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議(但面對無連接)
從HTTP/1.1起，默認都開啓了Keep-Alive保持連接特性，簡單地說，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的TCP連接
Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同服務器軟件（如Apache）中設置這個時間
上面這張圖我們可以瞭解到整個的通訊過程，同時注意一點，一個URL請求但是左邊欄裏面爲什麼會有那麼多的資源請求(這些都是靜態文件，go對於靜態文件有專門的處理方式)
這個就是瀏覽器的一個功能，第一次請求url，服務器端返回的是html頁面，然後瀏覽器開始渲染HTML：當解析到HTML DOM裏面的圖片連接，css腳本和js腳本的連接，瀏覽器就會自動發起一個請求靜態資源的HTTP請求，獲取相對應的靜態資源，然後瀏覽器就會渲染出來，最終將所有資源整合、渲染，完整展現在我們面前的屏幕上
網頁優化方面有一項措施是減少HTTP請求次數，就是把儘量多的css和js資源合併在一起，目的是儘量減少網頁請求靜態資源的次數，提高網頁加載速度，同時減緩服務器的壓力
