應(yīng)用層協(xié)議：每個(gè)應(yīng)用層的都是為了解決某一類應(yīng)用問(wèn)題。而問(wèn)題的解決又必須通過(guò)位于不同主機(jī)中的多個(gè)應(yīng)用進(jìn)程之間的通信和協(xié)同工作來(lái)完成。應(yīng)用進(jìn)程之間必須遵守嚴(yán)格的規(guī)則。應(yīng)用層協(xié)議應(yīng)當(dāng)定義如下幾個(gè)：

• 應(yīng)用進(jìn)程之間交換的報(bào)文類型，如請(qǐng)求報(bào)文和響應(yīng)報(bào)文
• 報(bào)文中各個(gè)字段及其詳細(xì)描述
• 包含在字段中的信息的含義
• 進(jìn)程何時(shí)、如何發(fā)送報(bào)文，以及對(duì)報(bào)文進(jìn)行響應(yīng)的規(guī)則

1.HTTP協(xié)議
萬(wàn)維網(wǎng)使用統(tǒng)一資源定位符URL來(lái)標(biāo)志萬(wàn)維網(wǎng)上的各種文檔，并使每一個(gè)文檔在整個(gè)因特網(wǎng)的范圍內(nèi)具有唯一的標(biāo)識(shí)符URL；萬(wàn)維網(wǎng)客戶程序和服務(wù)器程序必須遵守嚴(yán)格的協(xié)議即HTTP協(xié)議。HTTP協(xié)議是一個(gè)應(yīng)用層協(xié)議，它使用TCP連接進(jìn)行可靠的傳送。另外為了提取顯示文檔，使用超文本標(biāo)記語(yǔ)言HTML
1.1 HTTP操作過(guò)程

1.2 用戶點(diǎn)擊firefox瀏覽器的某個(gè)頁(yè)面后觸發(fā)的事件

1. 瀏覽器分析鏈接指向頁(yè)面的URL
2. 向DNS請(qǐng)求解析URL對(duì)于的IP地址
3. 域名系統(tǒng)解析出IP地址
4. 瀏覽器與服務(wù)器建立TCP連接(服務(wù)器端的端口是80)
5. 瀏覽器發(fā)出Get文件命令
6. 服務(wù)器對(duì)Get請(qǐng)求作出相應(yīng),把文件index.html發(fā)送給瀏覽器
7. 釋放TCP鏈接
8. 瀏覽器顯示index.html中的所有文本信息

1.3 HTTP協(xié)議使用了面向連接的TCP作為傳輸層協(xié)議
保證了數(shù)據(jù)的可靠傳輸.HTTP不必考慮數(shù)據(jù)在傳輸過(guò)程中被丟棄后又怎樣被重傳.但是HTTP協(xié)議本身是無(wú)連接的.,也就是說(shuō)通信雙方在交換HTTP報(bào)文之前不需要先建立HTTP鏈接
HTTP協(xié)議是無(wú)狀態(tài)的,服務(wù)器不記得曾經(jīng)訪問(wèn)過(guò)的這個(gè)用戶.

1.4 HTTP1.0和HTTP1.1

• HTTP1.0的缺點(diǎn)：每請(qǐng)求一個(gè)文檔就要兩倍RTT的開銷。若一個(gè)主頁(yè)上有很多鏈接對(duì)象需要進(jìn)行連接，那么每一次連接下載都需要2*RTT時(shí)間。另一種開銷就是萬(wàn)維網(wǎng)客戶和服務(wù)器每一次建立新的TCP連接都要分配緩存和變量。使用不行TCP連接可以縮短響應(yīng)時(shí)間。

• HTTP1.1協(xié)議很好的解決了這個(gè)問(wèn)題。他使用了持續(xù)連接。萬(wàn)維網(wǎng)服務(wù)器在發(fā)送響應(yīng)后仍然在一段時(shí)間內(nèi)保持這條連接，是同一個(gè)客戶和該服務(wù)器可以繼續(xù)在這條連接上傳送后續(xù)的HTTP請(qǐng)求報(bào)文和響應(yīng)報(bào)文。

  HTTP1.1的持續(xù)連接有兩種工作方式。流水線和非流水線。

1.4 HTTP的報(bào)文結(jié)構(gòu)

• 請(qǐng)求報(bào)文
• 響應(yīng)報(bào)文

三個(gè)部分組成，兩種報(bào)文格式的區(qū)別就是開始行不同

1. 開始行，用于區(qū)分是請(qǐng)求報(bào)文（請(qǐng)求行）還是響應(yīng)報(bào)文（狀態(tài)行）
2. 首部行
3. 實(shí)體主體

請(qǐng)求報(bào)文的方法：
GET 請(qǐng)求獲取Request-URI所標(biāo)識(shí)的資源
POST 在Request-URI所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)
HEAD 請(qǐng)求獲取由Request-URI所標(biāo)識(shí)的資源的響應(yīng)消息報(bào)頭
PUT 請(qǐng)求服務(wù)器存儲(chǔ)一個(gè)資源，并用Request-URI作為其標(biāo)識(shí)
DELETE 請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源
TRACE 請(qǐng)求服務(wù)器回送收到的請(qǐng)求信息，主要用于測(cè)試或診斷
CONNECT 保留將來(lái)使用
OPTIONS 請(qǐng)求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項(xiàng)和需求

響應(yīng)報(bào)文的特點(diǎn)
第一行就是狀態(tài)行，包括三項(xiàng)內(nèi)容，即HTTP的版本，狀態(tài)碼，及結(jié)束語(yǔ)
1xx 表示通知信息，請(qǐng)求處理中
2xx 表示請(qǐng)求成功
3xx 表示重定向
4xx 表示客戶端差錯(cuò)
5xx 表示服務(wù)器差錯(cuò)

2. XMPP協(xié)議
XMPP 是一種很類似于http協(xié)議的一種數(shù)據(jù)傳輸協(xié)議，它的過(guò)程就如同“解包裝–〉包裝”的過(guò)程，用戶只需要明白它接受的類型，并理解它返回的類型，就可以很好的利用xmpp來(lái)進(jìn)行數(shù)據(jù)通訊。基于可擴(kuò)展標(biāo)記語(yǔ)言（XML）的協(xié)議
2.1XMPP的基本網(wǎng)絡(luò)結(jié)構(gòu)
客戶端 服務(wù)器 網(wǎng)關(guān)
通信能夠在這三者的任意兩個(gè)之間雙向發(fā)生。服務(wù)器同時(shí)承擔(dān)了客戶端信息記錄，連接管理和信息的路由功能。網(wǎng)關(guān)承擔(dān)著與異構(gòu)即時(shí)通信系統(tǒng)的互聯(lián)互通，異構(gòu)系統(tǒng)可以包括SMS（短信），MSN，ICQ等?；镜木W(wǎng)絡(luò)形式是單客戶端通過(guò)TCP/IP連接到單服務(wù)器，然后在之上傳輸XML。

2.2 XMPP工作原理

XMPP核心協(xié)議通信的基本模式就是先建立一個(gè)stream，然后協(xié)商一堆安全之類的東西，中間通信過(guò)程就是客戶端發(fā)送XML Stanza，一個(gè)接一個(gè)的。服務(wù)器根據(jù)客戶端發(fā)送的信息以及程序的邏輯，發(fā)送XML Stanza給客戶端。但是這個(gè)過(guò)程并不是一問(wèn)一答的，任何時(shí)候都有可能從一方發(fā)信給另外一方。通信的最后階段是關(guān)閉流，關(guān)閉TCP/IP連接。

2.3 關(guān)于通信原語(yǔ)細(xì)節(jié)的話就不總結(jié)了！大家可以參考這個(gè)人的。
http://blog.csdn.net/imyfriend/article/details/8584360