HTTP協議和XMPP協議

應用程式層協議：每個應用程式層的都是為瞭解決某一類應用問題。而問題的解決又必須通過位於不同主機中的多個應用進程之間的通訊和協同工作來完成。應用進程之間必須遵守嚴格的規則。應用程式層協議應當定義如下幾個： 應用進程之間交換的報文類型，如請求報文和響應報文 報文中各個欄位及其詳細描述 包含在欄位中的資訊的含義 進程何時、如何發送報文，以及對報文進行響應的規則

1.HTTP協議
全球資訊網使用統一資源定位器URL來標誌全球資訊網上的各種文檔，並使每一個文檔在整個網際網路的範圍內具有唯一的標識符URL；全球資訊網客戶程式和伺服器程式必須遵守嚴格的協議即HTTP協議。HTTP協議是一個應用程式層協議，它使用TCP串連進行可靠的傳送。另外為了提取顯示文檔，使用超文字標記語言 (HTML)HTML
1.1 HTTP操作過程

1.2 使用者點擊firefox瀏覽器的某個頁面後觸發的事件 瀏覽器分析連結指向頁面的URL 向DNS請求解析URL對於的IP地址 網域名稱系統解析出IP地址 瀏覽器與伺服器建立TCP串連(伺服器端的連接埠是80) 瀏覽器發出Get檔案命令 伺服器對Get請求作出相應,把檔案index.html發送給瀏覽器 釋放TCP連結 瀏覽器顯示index.html中的所有文本資訊

1.3 HTTP協議使用了連線導向的TCP作為傳輸層協議
保證了資料的可靠傳輸.HTTP不必考慮資料在傳輸過程中被丟棄後又怎樣被重傳.但是HTTP協議本身是不需連線的.,也就是說通訊雙方在交換HTTP報文之前不需要先建立HTTP連結
HTTP協議是無狀態的,伺服器不記得曾經訪問過的這個使用者.

1.4 HTTP1.0和HTTP1.1 HTTP1.0的缺點：每請求一個文檔就要兩倍RTT的開銷。若一個首頁上有很多連結化物件需要進行串連，那麼每一次串連下載都需要2*RTT時間。另一種開銷就是全球資訊網客戶和伺服器每一次建立新的TCP串連都要分配緩衝和變數。使用不行TCP串連可以縮短回應時間。

HTTP1.1協議很好的解決了這個問題。他使用了持續串連。全球資訊網伺服器在發送響應後仍然在一段時間內保持這條串連，是同一個客戶和該伺服器可以繼續在這條串連上傳送後續的HTTP請求報文和響應報文。

HTTP1.1的持續串連有兩種工作方式。流水線和非流水線。

1.4 HTTP的報文結構 請求報文 響應報文

三個部分組成，兩種報文格式的區別就是開始行不同 開始行，用於區分是請求報文（請求行）還是響應報文（狀態行） 首部行 實體主體

請求報文的方法：
GET 請求擷取Request-URI所標識的資源
POST 在Request-URI所標識的資源後附加新的資料
HEAD 請求擷取由Request-URI所標識的資源的響應訊息前序
PUT 請求伺服器儲存一個資源，並用Request-URI作為其標識
DELETE 請求伺服器刪除Request-URI所標識的資源
TRACE 請求伺服器回送收到的請求資訊，主要用於測試或診斷
CONNECT 保留將來使用
OPTIONS 請求查詢服務器的效能，或者查詢與資源相關的選項和需求

響應報文的特點
第一行就是狀態行，包括三項內容，即HTTP的版本，狀態代碼，及結束語
1xx 表示通知資訊，請求處理中
2xx 表示請求成功
3xx 表示重新導向
4xx 表示用戶端差錯
5xx 表示伺服器差錯

2. XMPP協議
XMPP 是一種很類似於http協議的一種資料轉送協議，它的過程就如同“解封裝–〉封裝”的過程，使用者只需要明白它接受的類型，並理解它返回的類型，就可以很好的利用xmpp來進行資料通訊。基於可延伸標記語言 (XML)（XML）的協議
2.1XMPP的基本網路結構
用戶端 伺服器 網關
通訊能夠在這三者的任意兩個之間雙向發生。伺服器同時承擔了用戶端資訊記錄，串連管理和資訊的路由功能。網關承擔著與異構即時通訊系統的互聯互連，異構系統可以包括SMS（簡訊），MSN，ICQ等。基本的網路形式是單用戶端通過TCP/IP串連到單伺服器，然後在之上傳輸XML。

2.2 XMPP工作原理

XMPP核心協議通訊的基本模式就是先建立一個stream，然後協商一堆安全之類的東西，中間通訊過程就是用戶端發送XML Stanza，一個接一個的。伺服器根據用戶端發送的資訊以及程式的邏輯，發送XML Stanza給用戶端。但是這個過程並不是一問一答的，任何時候都有可能從一方發信給另外一方。通訊的最後階段是關閉流，關閉TCP/IP串連。

2.3 關於通訊原語細節的話就不總結了。大家可以參考這個人的。
http://blog.csdn.net/imyfriend/article/details/8584360