完整的HTTP請求會經歷以下過程
當我們在瀏覽器的位址列輸入 www.linux178.com ，然後回車，回車這一瞬間到看到頁面到底發生了什麼呢？
以下過程僅是個人理解：
Http 的header會給我們的請求包裝，比如AF中經常設定的可接受的Accept（text/html） --》域名解析，根據域名找到伺服器的IP --> 發起TCP的3次握手 --> 建立TCP連線後發起http請求 --> 伺服器響應http請求，瀏覽器得到html程式碼 --> 瀏覽器解析html程式碼，並請求html程式碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給使用者
每次都請求都會經過 客戶端的應用層（http協議）--> 客戶端的傳輸層（tcp或udp協議） -->客戶端的網路層（ip協議） --> 客戶端的鏈路層（網絡卡，路由器等） --> ------------------經過dns解析，穿越多個isp（網際網路服務提供商，移動，聯通，電信等），各種資料交換，找到了伺服器------------------- 伺服器的鏈路層 -->伺服器的網路層 -->伺服器的傳輸層 -->伺服器的應用層。 這個請求完成了。
伺服器響應 與請求相反，倒過來看即可。
關於HTTP協議可以參考以下：
HTTP協議漫談 http://kb.cnblogs.com/page/140611/
HTTP協議概覽 http://www.cnblogs.com/vamei/archive/2013/05/11/3069788.html
以下就是上面過程的一一分析，我們就以Chrome瀏覽器為例：
1.域名解析（DNS解析）
首先Chrome瀏覽器會解析 www.linux178.com 這個域名（準確的叫法應該是主機名）對應的IP地址。怎麼解析到對應的IP地址？
① Chrome瀏覽器 會首先搜尋瀏覽器自身的DNS快取（快取時間比較短，大概只有1分鐘，且只能容納1000條快取），看自身的快取中是否有www.linux178.com 對應的條目，而且沒有過期，如果有且沒有過期則解析到此結束。
注：我們怎麼檢視Chrome自身的快取？可以使用 chrome://net-internals/#dns 來進行檢視
② 如果瀏覽器自身的快取裡面沒有找到對應的條目，那麼Chrome會搜尋作業系統自身的DNS快取,如果找到且沒有過期則停止搜尋解析到此結束.
注：怎麼檢視作業系統自身的DNS快取，以Windows系統為例，可以在命令列下使用 ipconfig /displaydns 來進行檢視
③ 如果在Windows系統的DNS快取也沒有找到，那麼嘗試讀取hosts檔案（位於C:\Windows\System32\drivers\etc），看看這裡面有沒有該域名對應的IP地址，如果有則解析成功。
④ 如果在hosts檔案中也沒有找到對應的條目，瀏覽器就會發起一個DNS的系統呼叫，就會向本地配置的首選DNS伺服器（一般是電信運營商提供的，也可以使用像Google提供的DNS伺服器）發起域名解析請求（通過的是UDP協議向DNS的53埠發起請求，這個請求是遞迴的請求，也就是運營商的DNS伺服器必須得提供給我們該域名的IP地址），運營商的DNS伺服器首先查詢自身的快取，找到對應的條目，且沒有過期，則解析成功。如果沒有找到對應的條目，則有運營商的DNS代我們的瀏覽器發起迭代DNS解析請求，它首先是會找根域的DNS的IP地址（這個DNS伺服器都內建13臺根域的DNS的IP地址），找打根域的DNS地址，就會向其發起請求（請問www.linux178.com這個域名的IP地址是多少啊？），根域發現這是一個頂級域com域的一個域名，於是就告訴運營商的DNS我不知道這個域名的IP地址，但是我知道com域的IP地址，你去找它去，於是運營商的DNS就得到了com域的IP地址，又向com域的IP地址發起了請求（請問www.linux178.com這個域名的IP地址是多少?）,com域這臺伺服器告訴運營商的DNS我不知道www.linux178.com這個域名的IP地址，但是我知道linux178.com這個域的DNS地址，你去找它去，於是運營商的DNS又向linux178.com這個域名的DNS地址（這個一般就是由域名註冊商提供的，像萬網，新網等）發起請求（請問www.linux178.com這個域名的IP地址是多少？），這個時候linux178.com域的DNS伺服器一查，誒，果真在我這裡，於是就把找到的結果傳送給運營商的DNS伺服器，這個時候運營商的DNS伺服器就拿到了www.linux178.com這個域名對應的IP地址，並返回給Windows系統核心，核心又把結果返回給瀏覽器，終於瀏覽器拿到了www.linux178.com 對應的IP地址，該進行一步的動作了。
注：一般情況下是不會進行以下步驟的
如果經過以上的4個步驟，還沒有解析成功，那麼會進行如下步驟（以下是針對Windows作業系統）：
⑤ 作業系統就會查詢NetBIOS name Cache（NetBIOS名稱快取，就存在客戶端電腦中的），那這個快取有什麼東西呢？凡是最近一段時間內和我成功通訊的計算機的計算機名和Ip地址，就都會存在這個快取裡面。什麼情況下該步能解析成功呢？就是該名稱正好是幾分鐘前和我成功通訊過，那麼這一步就可以成功解析。
⑥ 如果第⑤步也沒有成功，那會查詢WINS 伺服器（是NETBIOS名稱和IP地址對應的伺服器）
⑦ 如果第⑥步也沒有查詢成功，那麼客戶端就要進行廣播查詢
⑧ 如果第⑦步也沒有成功，那麼客戶端就讀取LMHOSTS檔案（和HOSTS檔案同一個目錄下，寫法也一樣）
如果第八步還沒有解析成功，那麼就宣告這次解析失敗，那就無法跟目標計算機進行通訊。只要這八步中有一步可以解析成功，那就可以成功和目標計算機進行通訊。
看下圖抓包截圖：
Linux虛擬機器測試，使用命令 wget www.linux178.com 來請求，發現直接使用chrome瀏覽器請求時，干擾請求比較多，所以就使用wget命令來請求，不過使用wget命令只能把index.html請求回來，並不會對index.html中包含的靜態資源（js、css等檔案）進行請求。
抓包分析：
① 號包，這個是那臺虛擬機器在廣播，要獲取192.168.100.254（也就是閘道器）的MAC地址，因為區域網的通訊靠的是MAC地址，它為什麼需要跟閘道器進行通訊是因為我們的DNS伺服器IP是外圍IP，要出去必須要依靠閘道器幫我們出去才行。
② 號包，這個是閘道器收到了虛擬機器的廣播之後，迴應給虛擬機器的迴應，告訴虛擬機器自己的MAC地址，於是客戶端找到了路由出口。
③ 號包，這個包是wget命令向系統配置的DNS伺服器提出域名解析請求（準確的說應該是wget發起了一個DNS解析的系統呼叫），請求的域名www.linux178.com,期望得到的是IP6的地址（AAAA代表的是IPv6地址）
④ 號包，這個DNS伺服器給系統的響應，很顯然目前使用IPv6的還是極少數，所以得不到AAAA記錄的
⑤ 號包，這個還是請求解析IPv6地址，但是www.linux178.com.leo.com這個主機名是不存在的，所以得到結果就是no such name
⑥ 號包，這個才是請求的域名對應的IPv4地址（A記錄）
⑦ 號包，DNS伺服器不管是從快取裡面，還是進行迭代查詢最終得到了域名的IP地址，響應給了系統，系統再給了wget命令，wget於是得到了www.linux178.com的IP地址，這裡也可以看出客戶端和本地的DNS伺服器是遞迴的查詢（也就是伺服器必須給客戶端一個結果）這就可以開始下一步了，進行TCP的三次握手。
2.發起TCP的3次握手
拿到域名對應的IP地址之後，User-Agent（一般是指瀏覽器）會以一個隨機埠（1024 < 埠 < 65535）向伺服器的WEB程式（常用的有httpd,nginx等）80埠發起TCP的連線請求。這個連線請求（原始的http請求經過TCP/IP4層模型的層層封包）到達伺服器端後（這中間通過各種路由裝置，區域網內除外），進入到網絡卡，然後是進入到核心的TCP/IP協議棧（用於識別該連線請求，解封包，一層一層的剝開），還有可能要經過Netfilter防火牆（屬於核心的模組）的過濾，最終到達WEB程式（本文就以Nginx為例），最終建立了TCP/IP的連線。
如下圖：
1） Client首先發送一個連線試探，ACK=0 表示確認號無效，SYN = 1 表示這是一個連線請求或連線接受報文，同時表示這個資料報不能攜帶資料，seq = x 表示Client自己的初始序號（seq = 0 就代表這是第0號包），這時候Client進入syn_sent狀態，表示客戶端等待伺服器的回覆
2） Server監聽到連線請求報文後，如同意建立連線，則向Client傳送確認。TCP報文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到對方下一個報文段的第一個資料位元組序號是x+1，同時表明x為止的所有資料都已正確收到（ack=1其實是ack=0+1,也就是期望客戶端的第1個包），seq = y 表示Server 自己的初始序號（seq=0就代表這是伺服器這邊發出的第0號包）。這時伺服器進入syn_rcvd，表示伺服器已經收到Client的連線請求，等待client的確認。
3） Client收到確認後還需再次傳送確認，同時攜帶要傳送給Server的資料。ACK 置1 表示確認號ack= y + 1 有效（代表期望收到伺服器的第1個包），Client自己的序號seq= x + 1（表示這就是我的第1個包，相對於第0個包來說的），一旦收到Client的確認之後，這個TCP連線就進入Established狀態，就可以發起http請求了。
看抓包截圖：
⑨ 號包 這個就是對應上面的步驟 1）
⑩ 號包 這個對應的上面的步驟 2）
號包 這個對應的上面的步驟 3）
TCP 為什麼需要3次握手？
舉個例子：
假設一個老外在故宮裡面迷路了，看到了小明，於是就有下面的對話：
老外： Excuse me，Can you Speak English?
小明： yes 。
老外： OK,I want ...
在問路之前，老外先問小明是否會說英語，小明回答是的，這時老外才開始問路
2個計算機通訊是靠協議（目前流行的TCP/IP協議）來實現,如果2個計算機使用的協議不一樣，那是不能進行通訊的，所以這個3次握手就相當於試探一下對方是否遵循TCP/IP協議，協商完成後就可以進行通訊了，當然這樣理解不是那麼準確。
為什麼HTTP協議要基於TCP來實現？
目前在Internet中所有的傳輸都是通過TCP/IP進行的，HTTP協議作為TCP/IP模型中應用層的協議也不例外，TCP是一個端到端的可靠的面向連線的協議，所以HTTP基於傳輸層TCP協議不用擔心資料的傳輸的各種問題。
3.建立TCP連線後發起http請求
進過TCP3次握手之後，瀏覽器發起了http的請求（看第包），使用的http的方法 GET 方法，請求的URL是 / ,協議是HTTP/1.0
以上的報文是HTTP請求報文。
那麼HTTP請求報文和響應報文會是什麼格式呢？
起始行：如 GET / HTTP/1.0 （請求的方法 請求的URL 請求所使用的協議）
頭部資訊：User-Agent Host等成對出現的值
主體
不管是請求報文還是響應報文都會遵循以上的格式。
那麼起始行中的請求方法有哪些種呢？
GET: 完整請求一個資源 （常用）
HEAD: 僅請求響應首部
POST：提交表單 （常用）
PUT: (webdav) 上傳檔案（但是瀏覽器不支援該方法）
DELETE：(webdav) 刪除
OPTIONS：返回請求的資源所支援的方法的方法
TRACE: 追求一個資源請求中間所經過的代理（該方法不能由瀏覽器發出）
那什麼是URL、URI、URN？
URI Uniform Resource Identifier 統一資源識別符號
URL Uniform Resource Locator 統一資源定位符
格式如下： scheme://[username:[email protected]]HOST:port/path/to/source
http://www.magedu.com/downloads/nginx-1.5.tar.gz
URN Uniform Resource Name 統一資源名稱
URL和URN 都屬於 URI
為了方便就把URL和URI暫時都通指一個東西
請求的協議有哪些種？
有以下幾種：
http/0.9: stateless
http/1.0: MIME, keep-alive (保持連線), 快取
http/1.1: 更多的請求方法，更精細的快取控制，持久連線(persistent connection) 比較常用
下面是Chrome發起的http請求報文頭部資訊
其中
Accept 就是告訴伺服器端，我接受那些MIME型別
Accept-Encoding 這個看起來是接受那些壓縮方式的檔案
Accept-Lanague 告訴伺服器能夠傳送哪些語言
Connection 告訴伺服器支援keep-alive特性
Cookie 每次請求時都會攜帶上Cookie以方便伺服器端識別是否是同一個客戶端
Host 用來標識請求伺服器上的那個虛擬主機，比如Nginx裡面可以定義很多個虛擬主機
那這裡就是用來標識要訪問那個虛擬主機。
User-Agent 使用者代理，一般情況是瀏覽器，也有其他型別，如：wget curl 搜尋引擎的蜘蛛等
條件請求首部：
If-Modified-Since 是瀏覽器向伺服器端詢問某個資原始檔如果自從什麼時間修改過，那麼重新發給我，這樣就保證伺服器端資源
檔案更新時，瀏覽器再次去請求，而不是使用快取中的檔案
安全請求首部：
Authorization: 客戶端提供給伺服器的認證資訊；
什麼是MIME？
MIME（Multipurpose Internet Mail Extesions 多用途網際網路郵件擴充套件）是一個網際網路標準，它擴充套件了電子郵件標準，使其能夠支援非ASCII字元、二進位制格式附件等多種格式的郵件訊息，這個標準被定義在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 由RFC 822轉變而來的RFC 2822，規定電子郵件標準並不允許在郵件訊息中使用7位ASCII字符集以外的字元。正因如此，一些非英語字元訊息和二進位制檔案，影象，聲音等非文字訊息都不能在電子郵件中傳輸。MIME規定了用於表示各種各樣的資料型別的符號化方法。 此外，在全球資訊網中使用的HTTP協議中也使用了MIME的框架，標準被擴充套件為網際網路媒體型別。
MIME 遵循以下格式：major/minor 主型別/次型別 例如：
| 1 2 3 4 5 |