摘要
本文**《go web程式設計》一書，覺得說的比較好，特轉過來收藏。
我們平時瀏覽網頁的時候,會開啟瀏覽器，輸入**後按下回車鍵，然後就會顯示出你想要瀏覽的內容。在這個看似簡單的使用者行為背後，到底隱藏了些什麼呢？
對於普通的上網過程，系統其實是這樣做的：瀏覽器本身是乙個客戶端，當你輸入url的時候，首先瀏覽器會去請求dns伺服器，通過dns獲取相應的網域名稱對應的ip，然後通過ip位址找到ip對應的伺服器後，要求建立tcp連線，等瀏覽器傳送完http request（請求）包後，伺服器接收到請求包之後才開始處理請求包，伺服器呼叫自身服務，返回http response（響應）包；客戶端收到來自伺服器的響應後開始渲染這個response包裡的主體（body），等收到全部的內容隨後斷開與該伺服器之間的tcp連線。
圖3.1 使用者訪問乙個web站點的過程
乙個web伺服器也被稱為http伺服器，它通過http協議與客戶端通訊。這個客戶端通常指的是web瀏覽器(其實手機端客戶端內部也是瀏覽器實現的)。
web伺服器的工作原理可以簡單地歸納為：
乙個簡單的http事務就是這樣實現的，看起來很複雜，原理其實是挺簡單的。需要注意的是客戶機與伺服器之間的通訊是非持久連線的，也就是當伺服器傳送了應答後就與客戶機斷開連線，等待下一次請求。
url和dns解析
我們瀏覽網頁都是通過url訪問的，那麼url到底是怎麼樣的呢？
url(uniform resource locator)是「統一資源定位符」的英文縮寫，用於描述乙個網路上的資源, 基本格式如下
scheme://host[:port#]/path/.../[?query-string][#anchor]scheme 指定低層使用的協議(例如：http, https, ftp)host http伺服器的ip位址或者網域名稱port# http伺服器的預設埠是80，這種情況下埠號可以省略。如果使用了別的埠，必須指明，例如 訪問資源的路徑query-string 傳送給http伺服器的資料anchor 錨
dns(domain name system)是「網域名稱系統」的英文縮寫，是一種組織成域層次結構的計算機和網路服務命名系統，它用於tcp/ip網路，它從事將主機名或網域名稱轉換為實際ip位址的工作。dns就是這樣的一位「翻譯官」，它的基本工作原理可用下圖來表示。
圖3.2 dns工作原理
更詳細的dns解析的過程如下，這個過程有助於我們理解dns的工作模式
在瀏覽器中輸入www.qq.com網域名稱，作業系統會先檢查自己本地的hosts檔案是否有這個**對映關係，如果有，就先呼叫這個ip位址對映，完成網域名稱解析。
如果hosts裡沒有這個網域名稱的對映，則查詢本地dns解析器快取，是否有這個**對映關係，如果有，直接返回，完成網域名稱解析。
如果hosts與本地dns解析器快取都沒有相應的**對映關係，首先會找tcp/ip引數中設定的首選dns伺服器，在此我們叫它本地dns伺服器，此伺服器收到查詢時，如果要查詢的網域名稱，包含在本地配置區域資源中，則返回解析結果給客戶機，完成網域名稱解析，此解析具有權威性。
如果要查詢的網域名稱，不由本地dns伺服器區域解析，但該伺服器已快取了此**對映關係，則呼叫這個ip位址對映，完成網域名稱解析，此解析不具有權威性。
如果用的是**模式，此dns伺服器就會把請求**至上一級dns伺服器，由上一級伺服器進行解析，上一級伺服器如果不能解析，或找根dns或把轉請求轉至上上級，以此迴圈。不管是本地dns伺服器用是是**，還是根提示，最後都是把結果返回給本地dns伺服器，由此dns伺服器再返回給客戶機。
圖3.3 dns解析的整個流程
所謂 遞迴查詢過程 就是 「查詢的遞交者」 更替, 而 迭代查詢過程 則是 「查詢的遞交者」不變。
舉個例子來說，你想知道某個一起上法律課的女孩的**，並且你偷**了她的**，回到寢室告訴乙個很仗義的哥們兒，這個哥們兒二話沒說，拍著胸脯告訴你，甭急，我替你查(此處完成了一次遞迴查詢，即，問詢者的角色更替)。然後他拿著**問了學院大四學長，學長告訴他，這姑娘是xx系的；然後這哥們兒馬不停蹄又問了xx系的辦公室主任助理同學，助理同學說是xx系yy班的，然後很仗義的哥們兒去xx系yy班的班長那裡取到了該女孩兒**。(此處完成若干次迭代查詢，即，問詢者角色不變，但反覆更替問詢物件)最後，他把號碼交到了你手裡。完成整個查詢過程。
通過上面的步驟，我們最後獲取的是ip位址，也就是瀏覽器最後發起請求的時候是基於ip來和伺服器做資訊互動的。
http協議詳解
http協議是web工作的核心，所以要了解清楚web的工作方式就需要詳細的了解清楚http是怎麼樣工作的。
http協議是無狀態的，同乙個客戶端的這次請求和上次請求是沒有對應關係，對http伺服器來說，它並不知道這兩個請求是否來自同乙個客戶端。為了解決這個問題， web程式引入了cookie機制來維護連線的可持續狀態。
http協議是建立在tcp協議之上的，因此tcp攻擊一樣會影響http的通訊，例如比較常見的一些攻擊：syn flood是當前最流行的dos（拒絕服務攻擊）與ddos（分布式拒絕服務攻擊）的方式之一，這是一種利用tcp協議缺陷，傳送大量偽造的tcp連線請求，從而使得被攻擊方資源耗盡（cpu滿負荷或記憶體不足）的攻擊方式。
http請求包（瀏覽器資訊）
我們先來看看request包的結構, request包分為3部分，第一部分叫request line（請求行）, 第二部分叫request header（請求頭）,第三部分是body（主體）。header和body之間有個空行，請求包的例子所示:
http協議定義了很多與伺服器互動的請求方法，最基本的有4種，分別是get,post,put,delete。乙個url位址用於描述乙個網路上的資源，而http中的get, post, put, delete就對應著對這個資源的查，改，增，刪4個操作。我們最常見的就是get和post了。get一般用於獲取/查詢資源資訊，而post一般用於更新資源資訊。
通過fiddler抓包可以看到如下請求資訊:
圖3.4 fiddler抓取的get資訊
圖3.5 fiddler抓取的post資訊
我們看看get和post的區別:
我們可以看到get請求訊息體為空，post請求帶有訊息體。
get提交的資料會放在url之後，以?分割url和傳輸資料，引數之間以&相連，如editposts.aspx?name=test1&id=123456。post方法是把提交的資料放在http包的body中。
get提交的資料大小有限制（因為瀏覽器對url的長度有限制），而post方法提交的資料沒有限制。
get方式提交資料，會帶來安全問題，比如乙個登入頁面，通過get方式提交資料時，使用者名稱和密碼將出現在url上，如果頁面可以被快取或者其他人可以訪問這台機器，就可以從歷史記錄獲得該使用者的賬號和密碼。
http響應包（伺服器資訊）
我們再來看看http的response包，他的結構如下：
http/1.1 200 ok //狀態行server: nginx/1.0.8 //伺服器使用的web軟體名及版本date:date: tue, 30 oct 2012 04:14:25 gmt //傳送時間content-type: text/html //伺服器傳送資訊的型別transfer-encoding: chunked //表示傳送http包是分段發的connection: keep-alive //保持連線狀態content-length: 90 //主體內容長度//空行 用來分割訊息頭和主體
response包中的第一行叫做狀態行，由http協議版本號， 狀態碼， 狀態訊息 三部分組成。
狀態碼用來告訴http客戶端,http伺服器是否產生了預期的response。http/1.1協議中定義了5類狀態碼， 狀態碼由三位數字組成，第乙個數字定義了響應的類別
我們看下面這個圖展示了詳細的返回資訊，左邊可以看到有很多的資源返回碼，200是常用的，表示正常資訊，302表示跳轉。response header裡面展示了詳細的資訊。
圖3.6 訪問一次**的全部請求資訊
http協議是無狀態的和connection: keep-alive的區別
無狀態是指協議對於事務處理沒有記憶能力，伺服器不知道客戶端是什麼狀態。從另一方面講，開啟乙個伺服器上的網頁和你之前開啟這個伺服器上的網頁之間沒有任何聯絡。
http是乙個無狀態的面向連線的協議，無狀態不代表http不能保持tcp連線，更不能代表http使用的是udp協議（面對無連線）。
從http/1.1起，預設都開啟了keep-alive保持連線特性，簡單地說，當乙個網頁開啟完成後，客戶端和伺服器之間用於傳輸http資料的tcp連線不會關閉，如果客戶端再次訪問這個伺服器上的網頁，會繼續使用這一條已經建立的tcp連線。
keep-alive不會永久保持連線，它有乙個保持時間，可以在不同伺服器軟體（如apache）中設定這個時間。
請求例項
圖3.7 一次請求的request和response
上面這張圖我們可以了解到整個的通訊過程，同時細心的讀者是否注意到了一點，乙個url請求但是左邊欄裡面為什麼會有那麼多的資源請求(這些都是靜態檔案，go對於靜態檔案有專門的處理方式)。
這個就是瀏覽器的乙個功能，第一次請求url，伺服器端返回的是html頁面，然後瀏覽器開始渲染html：當解析到html dom裡面的連線，css指令碼和js指令碼的鏈結，瀏覽器就會自動發起乙個請求靜態資源的http請求，獲取相對應的靜態資源，然後瀏覽器就會渲染出來，最終將所有資源整合、渲染，完整展現在我們面前的螢幕上。
網頁優化方面有一項措施是減少http請求次數，就是把盡量多的css和js資源合併在一起，目的是儘量減少網頁請求靜態資源的次數，提高網頁載入速度，同時減緩伺服器的壓力。
HTTP協議簡介
現在web發展如火如荼，web開發人員也越來越多，但有幾個對支援web的http協議有了解呢？底層協議基礎不紮實，高層應用是很難做到極致的。帶著好奇心，開始學習吧！http hypertext transfer protocol 即超文字傳輸協議，是瀏覽器和伺服器之間互相通訊的一種約定，通過網際網路...
HTTP協議 簡介
全稱為超文字傳輸協議 hypertext transfer protocol 設計之初是為了將超文字標記語言 html 文件從web伺服器傳送到客戶端的瀏覽器。現在http的作用已不侷限於html的傳輸。url url示例 解釋 scheme 指定低層使用的協議 例如 http,https,ftp ...
HTTP 協議簡介
下面是對 http 協議的一些總結 客戶端發起連線 客戶端傳送請求 伺服器響應請求 伺服器關閉連線 乙個請求訊息是由請求行 請求頭欄位 乙個空行和訊息主體構成。如 host www.google.com請求訊息的第一行就是請求行。它指明使用的請求方法 資源標示符 和 http 版本。如 請求方法用來...