這篇文章主要介紹了java語(yǔ)言常用的通信協(xié)議有哪些,具有一定借鑒價(jià)值,需要的朋友可以參考下。希望大家閱讀完這篇文章后大有收獲。下面讓小編帶著大家一起了解一下。
成都創(chuàng)新互聯(lián)公司是一家專業(yè)從事成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)的網(wǎng)絡(luò)公司。作為專業(yè)網(wǎng)站制作公司,成都創(chuàng)新互聯(lián)公司依托的技術(shù)實(shí)力、以及多年的網(wǎng)站運(yùn)營(yíng)經(jīng)驗(yàn),為您提供專業(yè)的成都網(wǎng)站建設(shè)、網(wǎng)絡(luò)營(yíng)銷推廣及網(wǎng)站設(shè)計(jì)開發(fā)服務(wù)!以下分享幾種java語(yǔ)言常用的通信協(xié)議及協(xié)議性能的比較
1.RMI
RMI調(diào)用與設(shè)想的一樣,RMI理所當(dāng)然是最快的,在幾乎所有的情況下,它的毫?xí)r都是最少的。特別是在數(shù)據(jù)結(jié)構(gòu)復(fù)雜,數(shù)據(jù)量大的情況下,與其他協(xié)議的差距尤為明顯。為了充分發(fā)揮RMI的性能,另外做了測(cè)試類,不使用Spring,用原始的RMI形式(繼承UnicastRemoteObject對(duì)象)提供服務(wù)并遠(yuǎn)程調(diào)用,與Spring對(duì)POJO包裝成的RMI進(jìn)行效率比較。結(jié)果顯示:兩者基本持平,Spring提供的服務(wù)還稍快些。初步認(rèn)為,這是因?yàn)镾pring的代理和緩存機(jī)制比較強(qiáng)大,節(jié)省了對(duì)象重新獲取的時(shí)間。
2.Hessian
Hessian調(diào)用caucho公司的resin服務(wù)器號(hào)稱是最快的服務(wù)器,在java領(lǐng)域有一定的知名度。Hessian做為resin的組成部分,其設(shè)計(jì)也非常精簡(jiǎn)高效,實(shí)際運(yùn)行情況也證明了這一點(diǎn)。平均來(lái)看,Hessian較RMI要慢20%左右,但這只是在數(shù)據(jù)量特別大,數(shù)據(jù)結(jié)構(gòu)很復(fù)雜的情況下才能體現(xiàn)出來(lái),中等或少量數(shù)據(jù)時(shí),Hessian并不比RMI慢。Hessian的好處是精簡(jiǎn)高效,可以跨語(yǔ)言使用,而且協(xié)議規(guī)范公開,我們可以針對(duì)任意語(yǔ)言開發(fā)對(duì)其協(xié)議的實(shí)現(xiàn)。目前已有實(shí)現(xiàn)的語(yǔ)言有:java, c++, .net, python, ruby。還沒(méi)有delphi的實(shí)現(xiàn)。另外,Hessian與WEB服務(wù)器結(jié)合非常好,借助WEB服務(wù)器的功能,在處理大量用戶并發(fā)訪問(wèn)時(shí)會(huì)有很大優(yōu)勢(shì),在資源分配,線程排隊(duì),異常處理等方面都可以由成熟的WEB服務(wù)器保證。而RMI本身并不提供多線程的服務(wù)器。而且,RMI需要開防火墻端口,Hessian不用。
3.Burlap
Burlap與Hessian都是caucho公司的開源產(chǎn)品,只不過(guò)Hessian采用二進(jìn)制的方式,而Burlap采用xml的格式。測(cè)試結(jié)果顯示,Burlap在數(shù)據(jù)結(jié)構(gòu)不復(fù)雜,數(shù)據(jù)量中等的情況下,效率還是可以接受的,但如果數(shù)據(jù)量大,效率會(huì)急劇下降。平均計(jì)算,Burlap的調(diào)用毫?xí)r是RMI的3倍。我認(rèn)為,其效率低有兩方面的原因,一個(gè)是XML數(shù)據(jù)描述內(nèi)容太多,同樣的數(shù)據(jù)結(jié)構(gòu),其傳輸量要大很多;另一方面,眾所周知,對(duì)xml的解析是比較費(fèi)資源的,特別對(duì)于大數(shù)據(jù)量情況下更是如此。
4.HttpInvoker
HttpInvoker是SpringFramework提供的JAVA遠(yuǎn)程調(diào)用方法,使用java的序列化機(jī)制處理對(duì)象的傳輸。從測(cè)試結(jié)果看,其效率還是可以的,與RMI基本持平。不過(guò),它只能用于JAVA語(yǔ)言之間的通訊,而且,要求客戶端和服務(wù)端都使用SPRING框架。另外,HttpInvoker 并沒(méi)有經(jīng)過(guò)實(shí)踐的檢驗(yàn),目前還沒(méi)有找到應(yīng)用該協(xié)議的項(xiàng)目。
5.web service
本次測(cè)試選用了apache的AXIS組件作為WEB SERVICE的實(shí)現(xiàn),AXIS在WEB SERVICE領(lǐng)域相對(duì)成熟老牌。為了僅測(cè)試數(shù)據(jù)傳輸和編碼、解碼的時(shí)間,客戶端和服務(wù)端都使用了緩存,對(duì)象只需實(shí)例化一次。但是,測(cè)試結(jié)果顯示,web service的效率還是要比其他通訊協(xié)議慢10倍。如果考慮到多個(gè)引用指向同一對(duì)象的傳輸情況,web service要落后更多。因?yàn)镽MI,Hessian等協(xié)議都可以傳遞引用,而web service有多少個(gè)引用,就要復(fù)制多少份對(duì)象實(shí)體。Web service傳輸?shù)娜哂嘈畔⑦^(guò)多是其速度慢的原因之一,監(jiān)控發(fā)現(xiàn),同樣的訪問(wèn)請(qǐng)求,描述相同的數(shù)據(jù),web service返回的數(shù)據(jù)量是hessian協(xié)議的6.5倍。另外,WEB SERVICE的處理也很毫?xí)r,目前的xml解析器效率普遍不高,處理xml <-> bean很毫資源。從測(cè)試結(jié)果看,異地調(diào)用比本地調(diào)用要快,也從側(cè)面說(shuō)明了其毫?xí)r主要用在編碼和解碼xml文件上。這比冗余信息更為嚴(yán)重,冗余信息占用的只是網(wǎng)絡(luò)帶寬,而每次調(diào)用的資源耗費(fèi)直接影響到服務(wù)器的負(fù)載能力。(MS的工程師曾說(shuō)過(guò),用WEB SERVICE不能負(fù)載100個(gè)以上的并發(fā)用戶。)測(cè)試過(guò)程中還發(fā)現(xiàn),web service編碼不甚方便,對(duì)非基本類型需要逐個(gè)注冊(cè)序列化和反序列化類,很麻煩,生成stub更累,不如spring + RMI/hessian處理那么流暢簡(jiǎn)潔。而且,web service不支持集合類型,只能用數(shù)組,不方便。
感謝你能夠認(rèn)真閱讀完這篇文章,希望小編分享java語(yǔ)言常用的通信協(xié)議有哪些內(nèi)容對(duì)大家有幫助,同時(shí)也希望大家多多支持創(chuàng)新互聯(lián),關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,遇到問(wèn)題就找創(chuàng)新互聯(lián),詳細(xì)的解決方法等著你來(lái)學(xué)習(xí)!
網(wǎng)站標(biāo)題:java語(yǔ)言常用的通信協(xié)議有哪些-創(chuàng)新互聯(lián)
鏈接分享:http://www.rwnh.cn/article46/igehg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供定制開發(fā)、網(wǎng)站營(yíng)銷、小程序開發(fā)、網(wǎng)站維護(hù)、App開發(fā)、面包屑導(dǎo)航
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容