一：http的由來：
OSI模型把網絡通信分成七層：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層，對於開發網絡應用人員來說，一般把網絡分成五層，這樣比較容易理解。這五層為：物理層、數據鏈路層、網絡層、傳輸層和應用層（最頂層），下面是一張網絡分層的圖片（來源於網絡）：
網絡中的計算機互相通信就是實現了層與層之間的通信，要實現層與層之間的通信，則各層都要遵守規則，這樣才能完成更好的通信， 我們就把它們之間遵守的規則就叫個“協議”，然而網絡上的五層之間遵守的協議不一樣，每層都有各自的協議。下面就由下至上的講述每層的協議
物理層：物理層是五層模型中的最底層，物理層為計算機之間的數據通信提供了傳輸媒體和互連設備，為數據傳輸提供了可靠的環境，媒體包括電纜、光纖、無線信道等，互連設備指是計算機和調制解調器之間的互連設備，如各種插頭、插座等。該層的作用是透明的傳輸比特流（即二進制流），為數據鏈路層提供一個傳輸原始比特流的物理連接
數據鏈路層：數據鏈路層是模型中的第2層，該層對接受到物理層傳輸過來的比特流進行分組，一組電信號構成的數據包，就叫做"幀"，數據鏈鏈路層就是來傳輸以"幀"為單位的數據包，把數據傳遞給上一層（網絡層），幀數據由兩部分組成：幀頭和幀數據，幀頭包括接受方物理地址（就是網卡的地址）和其他的網絡信息，幀數據就是要傳輸的數據體。數據幀的最長為1500字節，如果數據很長，就必須分割成多個幀進行發送。
網絡層：
該層通過尋址（尋址地址）來建立兩個節點之間的連接，大家都知道我們的電腦連接上網絡后都一個IP地址，我們可以通過IP地址來確定不同的計算機是否在同一個子網路。如果我們的電腦連接上網絡后就有兩種地址：物理地址和網絡地址（IP地址），網絡上的計算機要通信，必須要知道通信的計算機“在哪里”， 首先通過網絡地址來判斷是否處於同一個子網絡，然后再對物理地址（MAC）地址進行處理，從而准確確定要通信計算機的位置。
在網絡層中有我們熟悉的IP協議（即規定網絡地址的協議），目前廣泛采用的是IP協議第四版（IPv4）,這個版本規定，網絡地址由32位二進制位組成。我們可以自己配置IP地址也可以自動獲得的方式得到IP地址，Ip地址分成兩部分，前24位代表網絡，后8位代表主機號， 如192.168.254.1和192.168.254.2就處於同一個子網絡里，因為這兩個IP地址的前24位相同。
網絡層中以IP數據包的形式來傳遞數據，IP數據包也包括兩部分：頭（Head）和數據(Data)，IP數據包放進數據幀中的數據部分進行傳輸。
傳輸層：
通過MAC和IP地址，我們可以找到互聯網上任意兩台主機來建立通信。然而這里有一個問題，找到主機后，主機上有很多程序都需要用到網絡，比如說你在一邊聽歌和好用QQ聊天， 當網絡上發送來一個數據包時， 是怎么知道它是表示聊天的內容還是歌曲的內容的， 這時候就需要一個參數來表示這個數據包是發送給那個程序（進程）來使用的，這個參數我們就叫做端口號，主機上用端口號來標識不同的程序（進程），端口是0到65535之間的一個整數，0到1023的端口被系統占用，用戶只能選擇大於1023的端口。
傳輸層的功能就是建立端口到端口的通信，網絡層就是建立主機與主機的通信，這樣如果我們確定了主機和端口，這樣就可以實現程序之間的通信了。我們所說的Socket編程就是通過代碼來實現傳輸層之間的通信。因為初始化Socket類對象要指定IP地址和端口號。
在傳輸層有兩個非常重要的協議：UDP 協議和TCP協議
采用UDP協議話傳輸的就是UDP數據包，同樣UDP數據包也由頭和數據兩部分組成，頭部分主要標識了發送端口和接受端口，數據部分就是具體的內容信息。同樣UDP數據包是放入IP數據包中的"數據"部分，IP數據包再放入數據幀中在網絡上傳輸。
由於UDP協議的可靠性差（數據發送后無法確定對方是否收到），所以又定義了一個可靠性高的協議——TCP協議，TCP協議采取了握手的方式要確保對方收到了數據。
應用層：應用層是模型中的最頂層，是用戶與網絡的接口，該層通過應用程序來完成網絡用戶的應用需求。該層的數據放在TCP數據包的數據部分，該層定義了一個很重要的協議——Http協議，我們一般的Web開發都是基於應用層的開發， 所以后面專題將會和大家介紹下Http協議。
既然知道http是大家在應用層的一個協議比如我們瀏覽網頁什么的就是http應用IOS上層也是基於http的協議比較簡單些，效率高靈活的比較難。
二：HTTP協議如何工作
大家都知道一般的通信流程：首先客戶端發送一個請求(request)給服務器，服務器在接收到這個請求后將生成一個響應(response)返回給客戶端。
1. Request和Response的格式
Request格式：
HTTP請求行
（請求）頭
空行
可選的消息體
注：請求行和標題必須以<CR><LF> 作為結尾（也就是，回車然后換行）。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1 協議中，所有的請求頭，除Host外，都是可選的。
實例：
GET / HTTP/1.1
Host: gpcuster.cnblogs.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Mon, 25 May 2009 03:19:18 GMT
Response格式：
HTTP狀態行
（應答）頭
空行
可選的消息體
實例：
HTTP/1.1 200 OK
Cache-Control: private, max-age=30
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: Mon, 25 May 2009 03:20:33 GMT
Last-Modified: Mon, 25 May 2009 03:20:03 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 25 May 2009 03:20:02 GMT
Content-Length: 12173
消息體的內容（略）
2. 建立連接的方式
HTTP支持2中建立連接的方式：非持久連接和持久連接(HTTP1.1默認的連接方式為持久連接)。
1) 非持久連接
讓我們查看一下非持久連接情況下從服務器到客戶傳送一個Web頁面的步驟。假設該貝面由1個基本HTML文件和10個JPEG圖像構成，而且所有這些對象都存放在同一台服務器主機中。再假設該基本HTML文件的URL為：gpcuster.cnblogs.com/index.html。
下面是具體步騾:
1.HTTP客戶初始化一個與服務器主機gpcuster.cnblogs.com中的HTTP服務器的TCP連接。HTTP服務器使用默認端口號80監聽來自HTTP客戶的連接建立請求。
2.HTTP客戶經由與TCP連接相關聯的本地套接字發出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。
3.HTTP服務器經由與TCP連接相關聯的本地套接字接收這個請求消息，再從服務器主機的內存或硬盤中取出對象/somepath/index.html，經由同一個套接字發出包含該對象的響應消息。
4.HTTP服務器告知TCP關閉這個TCP連接(不過TCP要到客戶收到剛才這個響應消息之后才會真正終止這個連接)。
5.HTTP客戶經由同一個套接字接收這個響應消息。TCP連接隨后終止。該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析后發現其中有10個JPEG對象的引用。
6.給每一個引用到的JPEG對象重復步騾1-4。
上述步驟之所以稱為使用非持久連接，原因是每次服務器發出一個對象后，相應的TCP連接就被關閉，也就是說每個連接都沒有持續到可用於傳送其他對象。每個TCP連接只用於傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產生11個TCP連接。
2) 持久連接
非持久連接有些缺點。首先，客戶得為每個待請求的對象建立並維護一個新的連接。對於每個這樣的連接，TCP得在客戶端和服務器端分配TCP緩沖區，並維持TCP變量。對於有可能同時為來自數百個不同客戶的請求提供服務的web服務器來說，這會嚴重增加其負擔。其次，如前所述，每個對象都有2個RTT的響應延長——一個RTT用於建立TCP連接，另—個RTT用於請求和接收對象。最后，每個對象都遭受TCP緩啟動，因為每個TCP連接都起始於緩啟動階段。不過並行TCP連接的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。
在持久連接情況下，服務器在發出響應后讓TCP連接繼續打開着。同一對客戶/服務器之間的后續請求和響應可以通過這個連接發送。整個Web頁面(上例中為包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發送:甚至存放在同一個服務器中的多個web頁面也可以通過單個持久TCP連接發送。通常，HTTP服務器在某個連接閑置一段特定時間后關閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應后才發出新的請求。這種情況下，web頁面所引用的每個對象(上例中的10個圖像)都經歷1個RTT的延遲，用於請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，服務器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務器資源便閑置了。
HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發出一個請求，因而HTTP客戶可以一個接一個緊挨着發出各個引用對象的請求。服務器收到這些請求后，也可以一個接一個緊挨着發出各個對象。如果所有的請求和響應都是緊挨着發送的，那么所有引用到的對象一共只經歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久連接中服務器空等請求的時間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個RTT的響應延遲外，緩啟動延遲也比較小。其原因在於既然各個對象使用同一個TCP連接，服務器發出第一個對象后就不必再以一開始的緩慢速率發送后續對象。相反，服務器可以按照第一個對象發送完畢時的速率開始發送下一個對象。
3. 緩存的機制
HTTP/1.1中緩存的目的是為了在很多情況下減少發送請求，同時在許多情況下可以不需要發送完整響應。前者減少了網絡回路的數量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網絡應用的帶寬；HTTP用“驗證（validation）”機制來為此目的。
HTTP定義了3種緩存機制：
l Freshness allows a response to be used without re-checking it on the origin server, and can be controlled by both the server and the client. For example, the Expires response header gives a date when the document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response is fresh for.
l Validation can be used to check whether a cached response is still good after it becomes stale. For example, if the response has a Last-Modified header, a cache can make a conditional request using the If-Modified-Since header to see if it has changed.
l Invalidation is usually a side effect of another request that passes through the cache. For example, if URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will be invalidated.
4. 響應授權激發機制
這些機制能被用於服務器激發客戶端請求並且使客戶端授權。
詳細的信息請參考：RFC 2617: HTTP Authentication: Basic and Digest Access
- 5. 基於HTTP的應用
- 多線程下載
優點：
- 客戶端產生的密鑰只有客戶端和服務器端能得到
- 加密的數據只有客戶端和服務器端才能得到明文
- 客戶端到服務端的通信是安全的
- 服務器和客戶端交互：
-
- 身份認證
- cookie
- http請求的幾個方法：
- 我們經常會遇到這個問題GET和POST的區別
我們看看GET和POST的區別
1. GET提交的數據會放在URL之后，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.
2. GET提交的數據大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
3. GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。
4. GET方式提交數據，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數據時，用戶名和密碼將出現在URL上，如果頁面可以被緩存或者其他人可以訪問這台機器，就可以從歷史記錄獲得該用戶的賬號和密碼.
-
由於篇幅問題接下來再分章節介紹