參考網頁
http://android.jobbole.com/85218/php
Http和Tcp/Ip
TCP/IP協議簇是一組不一樣層次上的多個協議的組合，一般被認爲是一個四層協議系統，與OSI的七層模型相對應
HTTP協議就是基於TCP/IP協議模型來傳輸信息的。html
(1). 鏈路層android
也稱做數據鏈路層或網絡接口層（在第一個圖中爲網絡接口層和硬件層），一般包括操做系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一塊兒處理與電纜（或其餘任何傳輸媒介）的物理接口細節。ARP（地址解析協議）和RARP（逆地址解析協議）是某些網絡接口（如以太網和令牌環 網）使用的特殊協議，用來轉換IP層和網絡接口層使用的地址。nginx
(2). 網絡層web
也稱做互聯網層（在第一個圖中爲網際層），處理分組在網絡中的活動，例如分組的選路。在TCP/IP協議族中，網絡層協議包括IP協議（網際協議），ICMP協議（Internet互聯網控制報文協議），以及IGMP協議（Internet組管理協議）。chrome
IP是一種網絡層協議，提供的是一種不可靠的服務，它只是儘量快地把分組從源結點送到目的結點，可是並不提供任何可靠性保證。同時被TCP和UDP使用。TCP和UDP的每組數據都經過端系統和每一箇中間路由器中的IP層在互聯網中進行傳輸。json
ICMP是IP協議的附屬協議。IP層用它來與其餘主機或路由器交換錯誤報文和其餘重要信息。瀏覽器
IGMP是Internet組管理協議。它用來把一個UDP數據報多播到多個主機。緩存
(3). 傳輸層tomcat
主要爲兩臺主機上的應用程序提供端到端的通訊。在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。
TCP爲兩臺主機提供高可靠性的數據通訊。它所作的工做包括把應用程序交給它的數據分紅合適的小塊交給下面的網絡層，確認接收到的 分組，設置發送最後確認分組的超時時鐘等。因爲運輸層提供了高可靠性的端到端的通訊，所以應用層能夠忽略全部這些細節。爲了提供可靠的服務，TCP採用了 超時重傳、發送和接收端到端的確認分組等機制。
UDP則爲應用層提供一種很是簡單的服務。它只是把稱做數據報的分組從一臺主機發送到另外一臺主機，但並不保證該數據報能到達另外一 端。一個數據報是指從發送方傳輸到接收方的一個信息單元（例如，發送方指定的必定字節數的信息）。UDP協議任何須需的可靠性必須由應用層來提供。
(4). 應用層
應用層決定了向用戶提供應用服務時通訊的活動。TCP/IP 協議族內預存了各種通用的應用服務。包括 HTTP，FTP（File Transfer Protocol，文件傳輸協議），DNS（Domain Name System，域名系統）服務。
★小結
TCP/IP協議簇是一組不一樣層次上的多個協議的組合，一般被認爲是一個四層協議系統，與OSI的七層模型相對應。上層到下層依次爲：
應用層
運輸層
網絡層
鏈路層（這裏已是物理層，涉及到硬件了）
HTTP、FTP、DNS（Domain Name System，域名系統）屬於應用層，TCP屬於運輸層，IP屬於網絡層，以太網屬於鏈路層。
★封裝-數據進入協議棧時的封裝過程
當應用程序用TCP傳送數據時，數據被送入協議棧中，而後逐個經過每一層直到被看成一串比特流送入網絡。其中每一層對收到的數據都要增長一些首部信息（有時還要增長尾部信息），該過程如圖所示。
★分用-以太網數據幀的分用過程
當目的主機收到一個以太網數據幀時，數據就開始從協議棧中由底向上升，同時去掉各層協議加上的報文首部。每層協議盒都要去檢查報文首部中的協議標識，以肯定接收數據的上層協議。這個過程稱做分用（Demultiplexing）。協議是經過目的端口號、源IP地址和源端口號進行解包的。
★封裝和分用：經過【數據進入協議棧時的封裝過程】和【以太網數據幀的分用過程】從TCP/IP模型的角度來理解了一次HTTP請求與響應的過程，更清晰的圖以下
爲何HTTP協議要基於TCP來實現？--HTTP協議屬於應用層協議，其須要基於運輸層的協議。TCP屬於運輸層協議，且可靠性強。因此HTTP協議選擇了TCP協議
目前在Internet中全部的傳輸都是經過TCP/IP進行的，HTTP協議做爲TCP/IP模型中應用層的協議也不例外，TCP是一個端到端的可靠的面向鏈接的協議，因此HTTP基於傳輸層TCP協議不用擔憂數據的傳輸的各類問題。
★★Http和Tcp/Ip總結
Tcp/Ip是一個協議族，是工程實踐中提煉出來的協議組合，能夠認爲是一個四層協議系統
四層從高到低：應用層（Http、Ftp、DNS）、運輸層（TCP）、網絡層（IP）、鏈路層（以太網）。
上層協議要依賴於下層的實現。
http協議在經過網絡傳輸數據的套路
應用（通常爲web應用）使用http協議傳輸數據，數據要經過tcp、ip層到達網絡（被看成一串比特流送入網絡）。數據從http應用（經過tcp層、ip層）到達網絡時變成一串比特流，中間經歷了每一層協議的封裝。經過網絡達到目的機器，又會從協議棧的底層到高層：鏈路層（之外網）到網絡層（ip層）到運輸層（tcp層）到應用層（http、ftp、dns），在這個過程當中比特流在每一層都會被解析（分用），最終以http響應的格式到底http應用（多是客戶端，好比瀏覽器、手機app應用，也多是服務器端，好比nginx服務器、tomcat服務器等）。
發送端發送時：層層封裝。
接收端接收後：層層解析。
HTTP協議
Http是什麼？
計算機經過網絡進行通訊的規則，是一個基於請求與響應，無狀態的，應用層的協議，常基於TCP/IP協議傳輸數據。目前任何終端（手機，筆記本電腦。。）之間進行任何一種通訊都必須按照Http協議進行，不然沒法鏈接。
四個基於：請求響應、無狀態、應用層、TCP/IP
請求與響應
客戶端發送請求，服務器端響應數據。
無狀態的
協議對於事務處理沒有記憶能力，客戶端第一次與服務器創建鏈接發送請求時須要進行一系列的安全認證匹配等，所以增長頁面等待時間，當客戶端向服務器端發送請求，服務器端響應完畢後，二者斷開鏈接，也不保存鏈接狀態，一刀兩斷！恩斷義絕！今後路人！下一次客戶端向一樣的服務器發送請求時，因爲他們以前已經遺忘了彼此，因此須要從新創建鏈接。
應用層
Http是屬於應用層的協議，配合TCP/IP使用。
TCP/IP
Http使用TCP做爲它的支撐運輸協議。HTTP客戶機發起一個與服務器的TCP鏈接，一旦鏈接創建，瀏覽器（客戶機）和服務器進程就能夠經過套接字接口訪問TCP。
針對無狀態的一些解決策略
有時須要對用戶以前的HTTP通訊狀態進行保存，好比執行一次登錄操做，在30分鐘內全部的請求都不須要再次登錄。因而引入了Cookie技術。
HTTP/1.1想出了持久鏈接（HTTP keep-alive）方法。其特色是，只要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態，在請求首部字段中的Connection: keep-alive即爲代表使用了持久鏈接。
還有不少其餘方案策略。
HTTP報文--HTTP報文是面向文本的，報文中的每個字段都是一些ASCII碼串，各個字段的長度是不肯定的。HTTP有兩類報文：請求報文和響應報文
Http請求報文
請求報文格式：請求命令（請求行）、請求頭、空行、請求體
一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成，下圖給出了請求報文的通常格式。
請求行
請求行分爲三個部分：請求方法、請求地址和協議版本。
請求方法
HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
最常的兩種GET和POST，若是是RESTful接口的話通常會用到GET、POST、DELETE、PUT。
請求地址
URL:統一資源定位符，是一種自願位置的抽象惟一識別方法。
組成：<協議>：//<主機>：<端口>/<路徑>
端口和路徑有時能夠省略（HTTP默認端口號是80）（路徑能夠省略是由於有時會有默認首頁）
以下例：
有時會帶參數，GET請求
協議版本
協議版本的格式爲：HTTP/主版本號.次版本號，經常使用的有HTTP/1.0和HTTP/1.1
請求頭部
請求頭部爲請求報文添加了一些附加信息，由「名/值」對組成，每行一對，名和值之間使用冒號分隔。
常見請求頭以下：
User-Agent舉例：各類瀏覽器、fiddler、網絡爬蟲等。
空行
請求頭部的最後會有一個空行，表示請求頭部結束，接下來爲請求數據，這一行很是重要，必不可少。
請求數據
可選部分，好比GET請求就沒有請求數據。
下面是一個POST方法的請求報文：
POST /index.php HTTP/1.1 請求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 請求頭
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
空行
username=aa&password=1234 請求數據
Http響應報文
響應報文格式--狀態行、響應頭部、空行以及響應數據
HTTP響應報文主要由狀態行、響應頭部、空行以及響應數據組成。
狀態行
由3部分組成，分別爲：協議版本，狀態碼，狀態碼描述。
其中協議版本與請求報文一致，狀態碼描述是對狀態碼的簡單描述，因此這裏就只介紹狀態碼。
狀態碼
狀態代碼爲3位數字。
1xx：指示信息--表示請求已接收，繼續處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進行更進一步的操做。
4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現。
5xx：服務器端錯誤--服務器未能實現合法的請求。
常見狀態碼舉例
響應頭部
與請求頭部相似，爲響應報文添加了一些附加信息
常見響應頭部以下
空行
空行告知客戶端響應頭結束，後面爲響應數據。
響應數據
用於存放須要返回給客戶端的數據信息。
下面是一個響應報文的實例
HTTP/1.1 200 OK 狀態行
Date: Sun, 17 Mar 2013 08:12:54 GMT 響應頭部
Server: Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 4393
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
空行
<html> 響應數據
<head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
http起始行中的請求方法
GET: 完整請求一個資源 （經常使用）
HEAD: 僅請求響應首部
POST：提交表單 （經常使用）
PUT: (webdav) 上傳
DELETE：(webdav) 刪除
OPTIONS：返回請求的資源所支持的方法的方法
TRACE: 追求一個資源請求中間所通過的代理
Spring框架的web包中的請求方法類--RequestMethod
public enum RequestMethod {
GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE
}
http幾種協議
http/0.9: stateless
http/1.0: MIME, keep-alive (保持鏈接), 緩存
http/1.1: 更多的請求方法，更精細的緩存控制，持久鏈接(persistent connection) 比較經常使用
什麼是MIME？--互聯網媒體類型
MIME（Multipurpose Internet Mail Extesions 多用途互聯網郵件擴展）是一個互聯網標準，它擴展了電子郵件標準，使其可以支持非ASCII字符、二進制格式附件等多種格式的郵件消息，這個標準被定義在 RFC 204五、RFC 204六、RFC 204七、RFC 204八、RFC 2049等RFC中。 由RFC 822轉變而來的RFC 2822，規定電子郵件標準並不容許在郵件消息中使用7位ASCII字符集之外的字符。正因如此，一些非英語字符消息和二進制文件，圖像，聲音等非文字消息都不能在電子郵件中傳輸。MIME規定了用於表示各類各樣的數據類型的符號化方法。此外，在萬維網中使用的HTTP協議中也使用了MIME的框架，標準被擴展爲互聯網媒體類型。
MIME 遵循如下格式：major/minor 主類型/次類型
例如：
image/jpg
image/gif
text/html
video/quicktime
appliation/x-httpd-php
appliation/json
HTTP協議有啥用？
技術上基於TCP/IP，是一套應用層面的網絡傳輸協議。
基於HTTP協議，能夠開發web服務器端，百度、阿里、360。
基於HTTP協議，能夠開發PC和手機端瀏覽器，各類產品：chrome、ie、Firefox、uc等各類瀏覽器。
基於HTTP協議，能夠開發各類PC客戶端應用：優化大師等，如今幾乎都是網絡應用。
基於HTTP協議，能夠開發各類手機app：同花順、微信、支付寶。
因此基於HTTP協議，能夠開發各類產品，只要產品符合HTTP協議便可。
=====================================================================
Chrome發起的http請求報文頭部信息舉例
字段含義說明
Accept 就是告訴服務器端，我接受那些MIME類型
Accept-Encoding 這個看起來是接受那些壓縮方式的文件
Accept-Lanague 告訴服務器可以發送哪些語言
Connection 告訴服務器支持keep-alive特性
Cookie 每次請求時都會攜帶上Cookie以方便服務器端識別是不是同一個客戶端
Host 用來標識請求服務器上的那個虛擬主機，好比Nginx裏面能夠定義不少個虛擬主機
那這裏就是用來標識要訪問那個虛擬主機。
User-Agent 用戶代理，通常狀況是瀏覽器，也有其餘類型，如：wget curl 搜索引擎的蜘蛛等
條件請求首部：If-Modified-Since 是瀏覽器向服務器端詢問某個資源文件若是自從什麼時間修改過，那麼從新發給我，這樣就保證服務器端資源
文件更新時，瀏覽器再次去請求，而不是使用緩存中的文件
安全請求首部：
Authorization: 客戶端提供給服務器的認證信息；
Chrome瀏覽器看到的響應頭信息舉例
字段含義說明
Connection 使用keep-alive特性
Content-Encoding 使用gzip方式對資源壓縮
Content-type MIME類型爲html類型，字符集是 UTF-8
Date 響應的日期
Server 使用的WEB服務器
Transfer-Encoding:chunked 分塊傳輸編碼 是http中的一種數據傳輸機制，容許HTTP由網頁服務器發送給客戶端應用（一般是網頁瀏覽器）的數據能夠分紅多個部分，分塊傳輸編碼只在HTTP協議1.1版本（HTTP/1.1）中提供
Vary 這個能夠參考（http://blog.csdn.net/tenfyguo/article/details/5939000）
X-Pingback 參考（http://blog.sina.com.cn/s/blog_bb80041c0101fmfz.html）