http 請(qǐng)求方式

• 通常, http 請(qǐng)求的方式有三分鐘, GET, POST, HEAD. POST 和 GET 方法是用于數(shù)據(jù)發(fā)送的.
  PSOT: 它將發(fā)送的數(shù)據(jù)單獨(dú)放在一個(gè)流中進(jìn)行, 這樣的好處是是數(shù)據(jù)不會(huì)出現(xiàn)在 URL, 相對(duì)安全.
  GET: 他將要發(fā)送的數(shù)據(jù)直添加在網(wǎng)址后面, 例如: www.licheng.com.cn?username="liCheng"&passWord="123456", 優(yōu)點(diǎn)操作較為簡單, 但是數(shù)據(jù)信息也暴露出來了.
  HEAD: 這個(gè)是請(qǐng)求資源的元數(shù)據(jù)的方法. 具體使用沒有遇到過, 不做詳解.

HTTP和服務(wù)器交互的不同方法

• URL (Uniform Resoure Locator) 全球資源定位器, 我們可以理解為描述一個(gè)網(wǎng)絡(luò)上面的資源, 通過 GET, POST, PUT, DELETE 就是對(duì)應(yīng)著對(duì)這個(gè)資源, 查, 改, 增, 刪. 四個(gè)操作.
• GET 一般用于查詢/獲取資源信息, POST 一般用于更新用戶信息.

socket 編程簡述

• 它是基于TCP/IP, 這個(gè)是可以連通網(wǎng)絡(luò)上不同計(jì)算機(jī)之間通訊的管道, 把一個(gè)數(shù)據(jù)從 管道 A端口 扔出來, 那么可以從 B 端口出來 (也可以是 C, D, F...... 這些端口冒出來).管道的端口的唯一性通過倆個(gè)因素可以確定, 機(jī)器的 IP 地址和程序使用的端口號(hào).
• socket 可以支持?jǐn)?shù)據(jù)的發(fā)送和接收, 它會(huì)定義一種稱為套接字的變量, 發(fā)動(dòng)數(shù)據(jù)時(shí)首先創(chuàng)建套接字, 然后使用該套接字的sendto等方法對(duì)準(zhǔn)某個(gè) IP /端口進(jìn)行數(shù)據(jù)發(fā)送: 接收端也會(huì)首先創(chuàng)建套接字, 然后將套接字和 IP /端口號(hào)綁定在一起, 所有發(fā)向此端口的數(shù)據(jù)會(huì)被該套接字的recv等函數(shù)讀出. 就像讀取文件中的數(shù)據(jù)一樣.
• TCP / IP 的socket 提供三種類型的套接字:流式套接字, 數(shù)據(jù)報(bào)式套接字, 原始套接字.
  客戶端編程步驟:
  1: 價(jià)值套接字庫, 創(chuàng)建套接字 (WSASrartup()/socket)
  2: 向服務(wù)器發(fā)出鏈接請(qǐng)求 (connect())
  3: 和服務(wù)器端進(jìn)行通信 (send()/recv())
  4: 關(guān)閉套接字, 關(guān)閉加載的套接字庫(closeSocket()/WSACleanup)
• 常用第三方庫: Asyncsoket
  ASIHTTO代碼原理, 異步請(qǐng)求的原理, 異步請(qǐng)求最大數(shù)目, 為什么只能這么多?
  ASIHTTPRequest 是一個(gè)簡易使用的類庫, 通過包裝 CFNetwork API 來簡化和服務(wù)器端的通訊, 他編寫的語言是 Objective-C 能夠應(yīng)用于Mac OS X and iPhone 平臺(tái)的應(yīng)用程序.
  異步: 請(qǐng)求通過實(shí)踐觸發(fā) -> 服務(wù)器處理 (這是瀏覽器仍然可以做其他事情) -> 處理完畢這個(gè)數(shù)量是可以跟 cpu 有關(guān)的, 并發(fā)性取決于cpu 的核數(shù), 每個(gè)核只能只能同時(shí)處理一個(gè)任務(wù), 如果按照 http 來算就是四個(gè)請(qǐng)求, 但是cup 是搶占式的資源, 所以一般來說并發(fā)量是要根據(jù)任務(wù)的耗時(shí)和cpu的繁忙度來計(jì)算, 4個(gè)左右只是經(jīng)驗(yàn)值,你開10個(gè)耗時(shí)短的任務(wù)和4個(gè)耗時(shí)長的任務(wù)效率是不一樣的.

JSONKit, SBJSON, TouchJSON 和原生的區(qū)別?

• JSONKit, SDJSON, TouchJSON (性能從左往右,越來越差)

App需要加載大量的數(shù)據(jù), 但是服務(wù)器卡住了怎么辦.

• 設(shè)置請(qǐng)求超時(shí)
• 給用戶提示請(qǐng)求超時(shí)
• 根據(jù)用戶操作再次請(qǐng)求數(shù)據(jù)

HTTP的通信, 發(fā)送請(qǐng)求, 接收響應(yīng), 包含了哪些內(nèi)容. OC 是怎么實(shí)現(xiàn)的.

• 請(qǐng)求行: 包含了請(qǐng)求方法, 請(qǐng)求資源路徑, HTTP協(xié)議版本
  GET/XXServer/resources/images/1.jpg HTTP/1.1
• 請(qǐng)求: 包含了對(duì)客戶端的環(huán)境描述, 客戶端請(qǐng)求主機(jī)地址等信息.
  ? Host: 192.168.1.105:8080 // 客戶端想訪問的服務(wù)器主機(jī)地址
  ? User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9) Firefox/30.0
  // 客戶端的類型，客戶端的軟件環(huán)境
  ? Accept: text/html, / // 客戶端所能接收的數(shù)據(jù)類型
  ? Accept-Language: zh-cn // 客戶端的語言環(huán)境
  ? Accept-Encoding: gzip // 客戶端支持的數(shù)據(jù)壓縮格式
  請(qǐng)求體：客戶端發(fā)給服務(wù)器的具體數(shù)據(jù)，比如文件數(shù)據(jù)
  ? OC中請(qǐng)求NSURLRequest
• 發(fā)送給服務(wù)器的請(qǐng)求包含：
  ? 請(qǐng)求行： 包含了請(qǐng)求方法退渗、請(qǐng)求資源路徑、HTTP協(xié)議版本
  ? 請(qǐng)求頭： 對(duì)客戶端的環(huán)境描述走诞、客戶端請(qǐng)求的主機(jī)地址等信息
  ? 請(qǐng)求體： 客戶端發(fā)給服務(wù)器的具體數(shù)據(jù)
  ? 默認(rèn)超時(shí)時(shí)常：60s
• 響應(yīng)：
  ? 狀態(tài)行：包含了HTTP協(xié)議版本、狀態(tài)碼蛤高、狀態(tài)英文名稱 HTTP/1.1 200 OK
  ? 響應(yīng)頭：包含了對(duì)服務(wù)器的描述蚣旱、對(duì)返回?cái)?shù)據(jù)的描述
  ? Server: Apache-Coyote/1.1 // 服務(wù)器的類型
  ? Content-Type: image/jpeg // 返回?cái)?shù)據(jù)的類型
  ? Content-Length: 56811 // 返回?cái)?shù)據(jù)的長度
  ? Date: Mon, 23 Jun 2014 12:54:52 GMT // 響應(yīng)的時(shí)間
  ? 實(shí)體內(nèi)容：服務(wù)器返回給客戶端的具體數(shù)據(jù)，比如文件數(shù)據(jù)
  ? OC中響應(yīng)用NSURLRespose：返回給客戶端的回應(yīng)包含：
  ? 狀態(tài)行 ： 包含了HTTP協(xié)議版本戴陡、狀態(tài)碼塞绿、狀態(tài)英文名稱
  ? 響應(yīng)頭 ： 包含了對(duì)服務(wù)器的描述、對(duì)返回?cái)?shù)據(jù)的描述
  ? 實(shí)體內(nèi)容：服務(wù)器返回給客戶端的具體二進(jìn)制數(shù)據(jù)
  ? 常用屬性： expectedContentLength （下載時(shí)返回文件的長度） , suggestedFilename（建議保存的文件名）

http 的 post 和 get 區(qū)別聯(lián)系, 實(shí)踐中如何選擇他們

區(qū)別聯(lián)系圖

知道 TCP / UDP 嗎, 二者的區(qū)別聯(lián)系,

TCP / UDP 區(qū)別聯(lián)系

• UDP: 是用戶數(shù)據(jù)報(bào)協(xié)議: 主要用在實(shí)時(shí)性要求高對(duì)質(zhì)量相對(duì)較弱的地方, 當(dāng)時(shí)面對(duì)高質(zhì)量的路線是不容易丟包除非是一些擁堵條件, 如流媒體
• TCP: 是傳輸控制協(xié)議: 是面連接的, 那么運(yùn)行環(huán)境必然要求其可靠性不可丟包有良好的擁塞控制機(jī)制, 如 http ftp telnet 等

三次握手和四次揮手

• 三次握手的實(shí)現(xiàn)
  ? 第一次握手: 建立連接時(shí), 客戶端發(fā)送同步序列號(hào)到服務(wù)器,等待服務(wù)器確認(rèn).
  ? 第二次握手: 服務(wù)器收手同步序列號(hào)編號(hào),確認(rèn)也發(fā)送一個(gè)同步序列號(hào)編號(hào)+確認(rèn)標(biāo)示, 服務(wù)器進(jìn)入接受狀態(tài).
  ? 第三次握手:客戶端接收服務(wù)器發(fā)送的包,并像服務(wù)端發(fā)送確認(rèn)標(biāo)示, 隨后鏈接成功.
  注意: 是在鏈接成功之后在進(jìn)行數(shù)據(jù)的傳輸?shù)?
• 四次揮手
  ? 第一次: 客戶端給服務(wù)器發(fā)送一個(gè)結(jié)束標(biāo)志的報(bào)文.
  ? 服務(wù)器手到報(bào)文后, 像客戶端發(fā)送一個(gè)確認(rèn)的序列號(hào), 同事通知自己響應(yīng)的程序: 對(duì)方要求關(guān)閉程序.
  ? 第三次:服務(wù)器向客戶端發(fā)送一個(gè)帶有結(jié)束標(biāo)記的報(bào)文.
  ? 第四次: 客戶端收到報(bào)文后, 像服務(wù)器發(fā)送一個(gè)確認(rèn)序號(hào), 鏈接關(guān)閉.

分析 JSON, XML 的區(qū)別, JSON, XML 解析方式的底層是怎么處理的.

• JSON 和 XML 的區(qū)別
  ? 可讀性: 相差不大, XML 的可讀性較好
  ? 可擴(kuò)展性: 都有比較良好的擴(kuò)展性
  ? 編碼難易程度: JSON 的要簡單一些
  ? 解碼難以成都: JSON 難度幾乎沒有, XML 需要考慮子節(jié)點(diǎn)和父節(jié)點(diǎn).
  ? 數(shù)據(jù)體積: JSON 體積小, 速度快
  ? 數(shù)據(jù)交互: JSON 和 javeScript 更加方便, 更容易解析處理, 有更好的數(shù)據(jù)交互.
  ? 數(shù)據(jù)描述: XML 描述性比較好
  ? 傳輸?shù)乃俣? JSON 的比較快.
• JSON底層原理
  ? 遍歷字符串中的字符串, 根據(jù)特殊的字符進(jìn)行區(qū)分. 比如:"[]","{}",":".最后把字符串變成字典, 字典里面有,字典,數(shù)組,或者就是鍵值對(duì).
• XML底層的原理
  ? XML 解析的方式有兩種: DOM 解析和 SAX 解析.
  ? DOM 采用建立樹形結(jié)構(gòu)的方式訪問 XML 文檔, SAX 采用的時(shí)間模型.
  ? DOM 把 XML 文檔轉(zhuǎn)化問一個(gè)包含其內(nèi)容的樹, 并可以對(duì)樹進(jìn)行遍歷.
  ? 使用 DOM 解析器的時(shí)候需要處理整個(gè) XML 文檔, 所以對(duì)性能和內(nèi)存的要求比較高.
  ? SAX 在解析 XML 文檔的時(shí)候可以出發(fā)乙烯利的時(shí)間, 當(dāng)發(fā)現(xiàn)給定的 tag 的時(shí)候, 他可以激活一個(gè)回調(diào)方法, 告訴該方法制定的標(biāo)簽已經(jīng)找到.
  ? SAX 對(duì)內(nèi)存的要求通常比較低, 因?yàn)樗岄_發(fā)人員來決定自己處理的 tag. 特別是當(dāng)開發(fā)人員只需要處理文檔中所包含的部分?jǐn)?shù)據(jù)時(shí), SAX 這種擴(kuò)展能力得到了更好的提現(xiàn).
  補(bǔ)充: 其他解析方式還有自定義二進(jìn)制解析, 就是按照字節(jié)去解析, 電話會(huì)談就是這樣, 還可以是字符串之間特殊符號(hào)來接的數(shù)據(jù), 將此數(shù)據(jù)用特殊符號(hào)可以分割成所用的數(shù)據(jù).

HTTP 和 SCOKET 通信的區(qū)別, SCOKET 連接相關(guān)庫, TCP, UDP 的連接方法, HTTP 的幾種常用方式.

• http 是客戶端用 http 協(xié)議進(jìn)行請(qǐng)求, 發(fā)送請(qǐng)求時(shí)需要封裝 http 請(qǐng)求頭, 并綁定請(qǐng)求數(shù)據(jù), 服務(wù)器一般有web服務(wù)器配合. http 請(qǐng)求方式為客戶端主動(dòng)發(fā)起請(qǐng)求, 服務(wù)端才能給響應(yīng), 一次請(qǐng)求完畢后就斷開連接, 節(jié)省資源. 服務(wù)器不能主動(dòng)給客戶端響應(yīng) (除非采取 http 長連接技術(shù)). iPhone 中主要使用的類是 NSUrlConnection.
  ? socket 是客戶端跟服務(wù)器直接使用 socket "套接字" 進(jìn)行來接, 并沒有規(guī)定連接之后斷開, 所以客戶端和服務(wù)器保持通道連接, 雙方都可以主動(dòng)發(fā)送數(shù)據(jù). 一般在游戲開發(fā)中或者股票開發(fā)這種要求及時(shí)性很強(qiáng)嬪妾保持發(fā)送數(shù)據(jù)量比較大的場合使用. 主要使用的類是 CFSocketRef

通信底層原理 (OSI, Open System Interconnectio, 七層模型)

• OSI簡介: OSI 采用了分層的結(jié)構(gòu)化技術(shù), 共分為七層, 物理層, 數(shù)據(jù)粘結(jié)層, 網(wǎng)絡(luò)層, 傳輸層, 會(huì)話層, 表示層和應(yīng)用層,
  ? 物理層: 主要是定義物理設(shè)備標(biāo)準(zhǔn), 比如: 網(wǎng)線的接口類型, 光纖的接口類型, 各種傳輸介質(zhì)的傳輸速率等. 它的主要作用是傳輸比特流 (就是由 1, 0 轉(zhuǎn)化成電流的強(qiáng)弱來進(jìn)行傳輸,到達(dá)目的后再轉(zhuǎn)化成 1, 0 , 也就是我們經(jīng)常說的數(shù)模轉(zhuǎn)換和莫屬轉(zhuǎn)換). 這一層的數(shù)據(jù)叫做比特.
  ? 數(shù)據(jù)鏈路層: 定義了如何讓格式化數(shù)據(jù)進(jìn)行傳輸, 以及如何控制對(duì)物理介質(zhì)的訪問. 這一層通常還提供檢測(cè)和糾正, 確保數(shù)據(jù)的可靠傳輸.
  ? 網(wǎng)絡(luò)層: 不用地理位置的網(wǎng)絡(luò)中的倆個(gè)主機(jī)系統(tǒng)之間提供鏈接和路徑選擇. Internet 的發(fā)展使得從世界各個(gè)站點(diǎn)訪問的用戶大大增大, 而網(wǎng)絡(luò)層真實(shí)管理這種鏈接的層.
  ? 傳輸層: 定義了一些傳輸數(shù)據(jù)的協(xié)議和端口號(hào) (WWW端口80等), 比如: TCP (傳輸控制協(xié)議, 傳輸效率低, 可靠性強(qiáng), 用在傳輸可靠性要求高, 數(shù)據(jù)量大的數(shù)據(jù)), UDP (用戶數(shù)據(jù)報(bào)協(xié)議, 和 TCP 恰恰相反, 用于傳輸可靠性要求不高, 數(shù)據(jù)量小, QQ 兩天就是采用這種方式傳輸?shù)?. 主要是件從下層接受的數(shù)據(jù)進(jìn)行分段和傳輸, 到達(dá)目的地址之后在進(jìn)行重組. 常常吧這一層數(shù)據(jù)叫做段.
  ? 會(huì)話層: 通過傳輸層 (端口號(hào): 傳輸端口和接受端口) 建立數(shù)據(jù)傳輸?shù)耐? 主要在你的系統(tǒng)之間發(fā)起會(huì)話或者接受會(huì)話請(qǐng)求.(設(shè)備之間相互認(rèn)識(shí)可以使IP也可以是 MAC 或者是主機(jī)名)
  ? 表示層: 可確保一個(gè)系統(tǒng)的應(yīng)用層發(fā)送的信息可以被另一個(gè)系統(tǒng)的應(yīng)用層讀取. 例如, PC 程序與另一臺(tái)計(jì)算機(jī)進(jìn)行通訊, 其中一臺(tái)計(jì)算機(jī)使用擴(kuò)展二一時(shí)進(jìn)制交換嗎 (EBCDIC), 而另一臺(tái)這是用美國信息交換標(biāo)準(zhǔn)碼 (ASCII) 來標(biāo)示相同的字符. 如果有必要的話.表示層會(huì)通過使用一種通格式來實(shí)現(xiàn)多種數(shù)據(jù)格式之間的轉(zhuǎn)換.
  ? 應(yīng)用層: 是最靠近用戶的OSI層. 這一層為用戶的應(yīng)用程序 (例如電子郵件, 文件傳輸和終端仿真) 提供網(wǎng)絡(luò)服務(wù).

設(shè)計(jì)一套大文件(比如三百兆的視頻)的下載方案

• NSURLSession
• 支持?jǐn)帱c(diǎn)下載, 自動(dòng)記錄停止下載時(shí)斷點(diǎn)的位置
• 遵守使用NSURLSessionDownloadDelegate協(xié)議
• 使用 NSURLSession 下載大文件, 被下載文件會(huì)被自動(dòng)寫入沙盒臨時(shí)文件夾 tmo 中
• 下載完畢, 通常需要將已下載文件移動(dòng)其他位置 (tmp文件夾中的數(shù)據(jù)被定時(shí)刪除), 通常是cache文件夾中.
• 下載步驟

設(shè)置下載任務(wù)task的為成員變量

 @property (nonatomic, strong) NSURLSessionDownloadTask *task;

獲取NSURLSession對(duì)象

NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:[[NSOperationQueue alloc] init]];

初始化下載任務(wù)任務(wù)

self.task = [session downloadTaskWithURL:（此處為下載文件路徑URL）];

實(shí)現(xiàn)代理方法

/*每當(dāng)寫入數(shù)據(jù)到臨時(shí)文件的時(shí)候猜欺，就會(huì)調(diào)用一次該方法位隶，通常在該方法中獲取下載進(jìn)度/
-(void)URLSession:(NSURLSession )session downloadTask: (NSURLSessionDownloadTask )downloadTask didWriteData:(int64_t)bytesWritten totalBytesWritten:(int64_t)totalBytesWritten totalBytesExpectedToWrite:(int64_t)totalBytesExpectedToWrite
{

 // 計(jì)算下載進(jìn)度
 CGFloat progress = 1.0 * totalBytesWritten / totalBytesExpectedToWrite;
}

/*任務(wù)終止時(shí)調(diào)用的方法拷窜，通常用于斷點(diǎn)下載/
-(void)URLSession:(NSURLSession )session downloadTask:(NSURLSessionDownloadTask )downloadTask didResumeAtOffset:(int64_t)fileOffset expectedTotalBytes:(int64_t)expectedTotalBytes
{

 //fileOffset：下載任務(wù)中止時(shí)的偏移量
}

/*遇到錯(cuò)誤的時(shí)候調(diào)用开皿，error參數(shù)只能傳遞客戶端的錯(cuò)誤/
-(void)URLSession:(NSURLSession )session task:(NSURLSessionTask )task didCompleteWithError:(NSError *)error
{ }

/*下載完成的時(shí)候調(diào)用，需要將文件剪切到可以長期保存的文件夾中/
-(void)URLSession:(NSURLSession )session downloadTask:(NSURLSessionDownloadTask )downloadTask didFinishDownloadingToURL:(NSURL *)location
{

 //生成文件長期保存的路徑
 NSString *file = [[NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) lastObject] stringByAppendingPathComponent:downloadTask.response.suggestedFilename];
 //獲取文件句柄
 NSFileManager *fileManager = [NSFileManager defaultManager];
 //通過文件句柄篮昧，將文件剪切到文件長期保存的路徑
 [fileManager moveItemAtURL:location toURL:[NSURL fileURLWithPath:file] error:nil];
}

操作任務(wù)狀態(tài)

/*開始/繼續(xù)下載任務(wù)/
[self.task resume];

/*暫停下載任務(wù)/
[self.task suspend];

HTTP協(xié)議的特點(diǎn), 關(guān)于 HTTP 請(qǐng)求 GET 和 POST 的區(qū)別?

• HTTP 協(xié)議的特點(diǎn)
  -HTTP 超文本傳輸協(xié)議, 是短連接, 是客戶端主動(dòng)發(fā)送請(qǐng)求, 服務(wù)器做出響應(yīng), 服務(wù)器響應(yīng)之后斷開鏈接.
• HTTP是一個(gè)屬于應(yīng)用層面向?qū)ο蟮膮f(xié)議, HTTP有兩類報(bào)文, 請(qǐng)求報(bào)文和響應(yīng)報(bào)文.
  -HTTP請(qǐng)求報(bào)文: 一個(gè) HTTP 請(qǐng)求報(bào)文有請(qǐng)求頭行, 請(qǐng)求頭, 空行和請(qǐng)求數(shù)據(jù)
  -HTTP響應(yīng)報(bào)文: 有三個(gè)部分組成: 狀態(tài)行, 消息報(bào)頭, 響應(yīng)正文.

幾十聊天 App 不會(huì)采用的網(wǎng)絡(luò)傳輸方式

A, UDP
B, TCP
C, HTTP
D, FTP

參考答案: D
理由: FTP是文件傳輸協(xié)議, 是 File Transfer Protocol 的簡稱, 他的作用是用來控制互聯(lián)網(wǎng)上面的文件的雙向傳輸,所以不是. UDP 是面向無連接的傳輸層協(xié)議, 只管發(fā), 不管收到?jīng)]收到: TCP 是面向連接的, 可靠的傳輸層協(xié)議: HTTP 是超文本傳輸協(xié)議, 對(duì)于應(yīng)用層. HTTP 就是基于 TCP 的.

XMPP介紹以及優(yōu)缺點(diǎn)

• XMPP (Extensible Messaging and Presence Protocol), 是一種以 XML 為基礎(chǔ)的開放式試試幾十通訊協(xié)議, 是由互聯(lián)網(wǎng)工程工作小組(IETF)通過的互聯(lián)網(wǎng)標(biāo)準(zhǔn). 簡單的說, XMPP 就是一種協(xié)議, 一種規(guī)定. 就是說, 在網(wǎng)絡(luò)上傳東西, 要簡歷鏈接, TCP/ IP 連接, 建立后再傳東西, 而 XMPP 就是規(guī)定你穿的東西的格式. XMPP 是基于XML的協(xié)議. 優(yōu)點(diǎn)開放:
  XMPP 協(xié)議是自由, 開放, 公開的, 并且易于了解. 而且在客戶端, 服務(wù)器, 組件, 源碼庫等方面, 都已經(jīng)各自有多種實(shí)現(xiàn). 標(biāo)準(zhǔn):
  互聯(lián)網(wǎng)工程工作小組(IETE)已經(jīng)將 JAbber 的核心 XML 流協(xié)議以 XMPP 之名, 真實(shí)列為認(rèn)可的試試通信及 Presence 技術(shù). 而 XMPP 的技術(shù)規(guī)格已被定義在RFC 3920 及 RFC 3921. 任何 IM 供應(yīng)商在遵循 XMPP 協(xié)議下, 都可與Google Talk 實(shí)現(xiàn)連接. 證實(shí)可用: 第一個(gè) Jabber(現(xiàn)在XMPP)技術(shù)是Jeremie Miller 在1998 年開發(fā)的, 現(xiàn)在已經(jīng)相當(dāng)穩(wěn)定: 數(shù)以百計(jì)的開發(fā)者為 XMPP 技術(shù)努力著. 今日的互聯(lián)網(wǎng)上有數(shù)以萬計(jì)的 XMPP 服務(wù)器訊做, 數(shù)百萬計(jì)的冷門使用XMPP事實(shí)傳訊軟件.
  分散式:
  XMPP 網(wǎng)絡(luò)的架構(gòu)和點(diǎn)子郵件十分相似: XMPP 核心協(xié)議通信方式是先創(chuàng)建一個(gè) stream, XMPP 以 TCP 傳遞 XML 數(shù)據(jù)流, 沒有中央服務(wù)器. 任何人都可以運(yùn)行自己的 XMPP 服務(wù)器, 四個(gè)人及組織能掌控他們的實(shí)時(shí)傳訊體驗(yàn).
  安全:
  任何 XMPP 協(xié)議的服務(wù)器可以獨(dú)立與公共的 XMPP網(wǎng)絡(luò)(列如在企業(yè)內(nèi)部網(wǎng)), 而使用 SASL 及 TLS 等技術(shù)的可靠安全性, 已自帶于核心 XMPP 技術(shù)規(guī)格中.
  可擴(kuò)展:
  XML 命名空間的威力可使任何人在核心協(xié)議的基礎(chǔ)上的定制化的功能: 為了維護(hù)通透性, 參加你的擴(kuò)展由 XMPP標(biāo)準(zhǔn)基金會(huì).
  彈性佳:XMPP除了可用在實(shí)時(shí)通訊的應(yīng)用程序, 還能用在網(wǎng)絡(luò)管理, 內(nèi)容供稿, 協(xié)同工具, 文件共享, 游戲, 學(xué)那層系統(tǒng)監(jiān)控等.
  多樣性:
  用 XMPP 協(xié)議來建造以及部署時(shí)應(yīng)用程序及服務(wù)的公司及開源代碼計(jì)劃分布在各種領(lǐng)域: 用 XMPP 技術(shù)開發(fā)軟件, 資源及支持的來源是多樣,使得你不會(huì)限于"綁架"的困境.
• 缺點(diǎn)
  數(shù)據(jù)負(fù)荷太重:
  隨著通常超過70%的 XMPP 協(xié)議的服務(wù)器的數(shù)據(jù)流量的存在和近 60% 的被重復(fù)轉(zhuǎn)發(fā), XMPP 協(xié)議目前擁有一個(gè)大型架空中的存在的數(shù)據(jù)提供給多個(gè)收件人. 新的議定書正在研究, 以減輕這個(gè)問題.
  沒有二進(jìn)制數(shù)據(jù):
  XMPP 協(xié)議傳輸?shù)姆绞奖痪幋a為一個(gè)單一的長的XML文件, 因此無法提供修改二進(jìn)制數(shù)據(jù). 因此, 文件傳輸協(xié)議一樣使用外部的 HTTP. 如果不可避免, XMPP 協(xié)議還提供了帶編碼的文件傳輸?shù)乃袛?shù)據(jù)使用的Base64. 至于其他二進(jìn)制數(shù)據(jù)加密會(huì)話 (encrypted conversation) 或者圖形圖標(biāo) (grapic icons) 以嵌入式使用相同的方法.