導(dǎo)語：如何才能寫好一篇http協(xié)議，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務(wù)員之家整理的十篇范文，供你借鑒。

篇1

關(guān)鍵詞：萬維網(wǎng)；WWW；http；FTP；Web服務(wù)器

WWW（World Wide Web，3W，Web）中文譯名為萬維網(wǎng)，環(huán)球信息網(wǎng)等。是歐洲核物理研究中心（CERN）為全球范圍的科學(xué)家利用Internet建立在客戶機/服務(wù)器模型之上，為了方便地進行通信、交流和查詢所建立的。Internet采用超文本和超媒體的信息組織方式，將信息的鏈接擴展到整個Internet上。萬維網(wǎng)是一個分布式的超媒體（Hypermedia）系統(tǒng)，它是超文本（Hypertext）系統(tǒng)的擴充，所謂超文本是包含指向其他文檔的鏈接文本，超文本是萬維網(wǎng)的基礎(chǔ)，在萬維網(wǎng)中，主要使用了兩個協(xié)議，分別是HTTP協(xié)議和FTP協(xié)議。

1 HTTP協(xié)議

超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）提供了訪問超文本信息的功能，是萬維網(wǎng)與Web服務(wù)器之間的通信協(xié)議，屬于應(yīng)用層。HTTP協(xié)議是用于分布式協(xié)作超文本信息系統(tǒng)的、通用的、面向?qū)ο蟮膮f(xié)議?？梢杂糜趥鬏敻鞣N超文本頁面和數(shù)據(jù)。

HTTP協(xié)議包括以下4個步驟：

第一，建立連接?？蛻舳讼蚍?wù)器發(fā)出建立連接HTTP報文的請求，服務(wù)端將響應(yīng)發(fā)送回客戶端，連接建立。

第二，發(fā)送請求。客戶端按照HTTP協(xié)議通過連接線路向服務(wù)端發(fā)送請求。

第三，給出應(yīng)答。服務(wù)器按照客戶端的要求給出應(yīng)答，將結(jié)果HTML文件返回給客戶端。

第四，關(guān)閉連接?？蛻舳私拥紿TTP報文請求后關(guān)閉連接。

HTTP協(xié)議是基于TCP/IP之上的協(xié)議，它不僅保證是否能夠正確傳輸超文本文檔，而且還要確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示等。通常HTTP報文消息包括客戶向服務(wù)器的請求報文和服務(wù)器向客戶的響應(yīng)報文。這兩種類型的報文消息由一個起始行，一個或者多個頭域，一個指示結(jié)束的空行和消息體組成。HTTP的報文結(jié)構(gòu)包括通用首部、請求首部、響應(yīng)首部、實體首部和實體主體五個部分。每個頭域由，和三部分組成。（注意：域名與大小寫無關(guān)，可以在域值前添加任何數(shù)量的空格符，可將萬維網(wǎng)的頭域擴展為多行。）

通用域名首部包含請求和響應(yīng)報文，其中的頭域還包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via等。對通用頭域的擴展要求通訊雙方都支持，如果存在不支持的通用頭域，一般將會作為實體處理。

一次HTTP操作其工作過程可分為以下幾步：

第一，瀏覽器分析鏈接指向頁面的URL。

第二，瀏覽器向DNS請求解析IP地址。

第三，域名系統(tǒng)DNS解析出微軟服務(wù)器的IP地址。

第四，瀏覽器與該服務(wù)器建立TCP鏈接。

第五，瀏覽器發(fā)出HTTP請求GET。

第六，服務(wù)器通過HTTP響應(yīng)把文件index.heml發(fā)送給瀏覽器。

第七，TCP連接釋放。

第八，瀏覽器將文件index.heml進行解釋，并將Web頁顯示給用戶。

如果在以上過程中的某一步出現(xiàn)錯誤，那么產(chǎn)生錯誤的信息將返回到客戶端，由顯示屏輸出。對于用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標(biāo)點擊，等待信息顯示就可以了。HTTP采用TCP作為運輸層協(xié)議，保證了數(shù)據(jù)的可靠傳輸，HTTP不需要考慮數(shù)據(jù)在傳輸過程中丟失后是怎樣重傳的，但是HTTP協(xié)議本身是無連接的，即通信雙方在交換HTTP報文之前不需要先建立HTTP鏈接。

2 FTP協(xié)議

文件傳輸協(xié)議（File Transfer Protocol，F(xiàn)TP）是因特網(wǎng)上使用最廣泛的文件傳輸協(xié)議，F(xiàn)TP運行在TCP上采用客戶/服務(wù)器模型，包括兩個組成部分，分別為FTP服務(wù)器、FTP客戶端。其中FTP服務(wù)器用來存儲文件，用戶可以使用FTP客戶端通過FTP協(xié)議訪問位于服務(wù)器上的資源。FTP使用20和21這兩個端口，如果采用主動模式，那么數(shù)據(jù)傳輸端口就是20；如果采用被動模式，數(shù)據(jù)傳輸端口就是21。

FTP提供以下功能：

第一，提供不同種類的主機系統(tǒng)之間的傳輸。

第二，使用戶對遠程服務(wù)器上的文件進行管理。

第三，提供文件共享能力。

另FTP還有兩種模式，主動方式Standard（PORT方式），被動方式Passive（PASV方式）。Standard模式下FTP客戶端發(fā)送PORT命令到服務(wù)器。Passive模式下FTP的客戶端發(fā)送PASV命令到FTP Server。

Port：FTP客戶端與服務(wù)器的21端口建立控制連接，用來傳輸控制信息，客戶端發(fā)送請求，通過控制連接發(fā)送給服務(wù)器端的控制進程。服務(wù)器通過自己的數(shù)據(jù)連接端口連接至客戶端的指定端口并發(fā)送數(shù)據(jù)。

FTP服務(wù)器在很多情況下是不支持PASV模式的，因為很多防火墻在設(shè)置時，是不允許接受外部發(fā)起連接的，因而位于防火墻后或內(nèi)網(wǎng)的客戶端無法穿過防火墻打開FTP服務(wù)器的高端端口，故許多內(nèi)網(wǎng)的客戶端不能用PORT模式登陸FTP服務(wù)器，造成無法連接。

文件交換協(xié)議（File Exchange Protoco，F(xiàn)XP）相當(dāng)于是FTP的控制器，也可以認(rèn)為FXP本身其實就是FTP的一個子集，使一個FTP客戶端控制兩個FTP服務(wù)器，在兩個服務(wù)器之間傳送文件。FTP協(xié)議的任務(wù)是使計算機將文件傳送至另一臺計算機，它與這兩臺計算機所處的位置、聯(lián)接的方式、是否使用相同的計算機操作系統(tǒng)均沒有關(guān)系。例如，兩臺計算機通過FTP協(xié)議連接，并且能夠成功地訪問Internet，用戶就可以使用FTP命令來傳輸文件。

其傳輸方式可分為兩大類：ASCII傳輸和二進制數(shù)據(jù)傳輸。

ASCII傳輸模式：若客戶端當(dāng)時正在拷貝的文件中包含的簡單ASCII碼，在機器上運行的是不同的操作系統(tǒng)，當(dāng)文件傳輸時，F(xiàn)TP協(xié)議通常會自動地調(diào)整文件的內(nèi)容以便于將文件“翻譯”成另一臺計算機存儲的文本文件格式，就是我們通常所說的翻譯。但是時常會有這樣的情況發(fā)生，用戶正在傳輸?shù)奈募牟皇俏谋疚募鼈兛赡苁浅绦?、?shù)據(jù)庫、字處理文件或者壓縮文件等信息。那么這時，ASCII傳輸模式則會消耗大量的時間、資源進行翻譯，與我們所希望的相去甚遠，于是，出現(xiàn)了第二種傳輸方式，二進制傳輸。

參考文獻：

[1] 沈紅，李愛華.計算機網(wǎng)絡(luò)（第二版）[M].清華大學(xué)出版社，2010.

[2] 謝希仁.計算機網(wǎng)絡(luò)（第5版）[M].電子工業(yè)出版社，2011.

作者簡介：周開強（1993―），男，黑龍江慶安人。

篇2

現(xiàn)實世界中的很多過程都具有多條線索同時動作的特性。Java語言的一大特性就是內(nèi)置對多線程的支持。多線程是指同時存在幾個執(zhí)行體，按幾條不同的執(zhí)行線索共同工作的情況，它使得編程人員可以很方便地開發(fā)出具有多線程功能、能同時處理多個任務(wù)的功能強大的應(yīng)用程序。一些同時運行的線程需要共享數(shù)據(jù)，因此每個線程就必須要考慮其它與它一起共享數(shù)據(jù)的線程的狀態(tài)與行為，這就是線程安全的問題。為了對Java多線程與線程安全機制進行研究與實踐，特此設(shè)計一個基于Http 協(xié)議的支持多線程斷點續(xù)傳的下載程序。此下載程序由下載任務(wù)模塊、設(shè)置模塊以及系統(tǒng)幫助模塊組成。通過Apache Jakarta Commons下的子項目HttpClient包對Http協(xié)議進行支持，從而下載服務(wù)器端的資源。程序提供多線程斷點續(xù)傳功能，在完成下載過程中使用多線程技術(shù)可以較大幅度地提高下載的速度。

關(guān)鍵詞：多線程；線程安全；斷點續(xù)傳

需求分析

3.1用戶需求分析

隨著Internet的發(fā)展，進入信息時代后快速獲得網(wǎng)絡(luò)共享資源成為很簡單的事情，人們對互聯(lián)網(wǎng)也有了很大的依賴性。人們甚至希望只輕松點擊鼠標(biāo)就可以得到自己想要的東西。比如，針對一些專業(yè)的論壇提供了很多相關(guān)資料以方便人們閱讀或了解；還有更多的人希望能過下載到他們喜歡聽得音樂、好看的圖片、喜歡的電影等等。也可以看出人們在上網(wǎng)時再也不單是打開瀏覽器來瀏覽網(wǎng)頁，越來越多的人們開始使用下載軟件來獲取資源。同時人們也更希望使用更新更快的下載軟件。

由于用戶下載需求的增大，也要求下載軟件能夠迅速完成對資源的下載。多線程程序設(shè)計可以很好的解決程序并發(fā)的問題。最恰當(dāng)?shù)谋扔骶褪怯脩魰械紺PU似乎同時出現(xiàn)在兩個地方，在下載軟件中應(yīng)用多線程技術(shù)可以理解為將一個下載任務(wù)分成若干份來完成，其中的并發(fā)控制將使下載的效率大大提高。

由于下載資源是一個過程，當(dāng)中用到的時間可能會很長。那么在很長的這段時間中很有可能會出現(xiàn)很多的意外情況使下載中斷或是停止，比如電源意外被切斷、網(wǎng)絡(luò)中斷、或是操作系統(tǒng)故障導(dǎo)致系統(tǒng)重新啟動。這些原因都會導(dǎo)致下載的中斷，但是當(dāng)用戶重新下載資源時發(fā)現(xiàn)原來下載的數(shù)據(jù)已經(jīng)消失你還是要回頭再來。斷點續(xù)傳就是用來解決這樣的問題的，它的任務(wù)是在下載任務(wù)停止時，記錄當(dāng)前下載的信息并且利用網(wǎng)絡(luò)協(xié)議中的一些重定向機制繼續(xù)完成下載任務(wù)而不必從頭再來。

隨著使用下載工具的時間的增長，用戶下載的資源越來越多，因此在下載列表中的項目也越來越多，越來越混亂，因此為了便于管理和用戶使用方便，用戶迫切希望下載工具具有下載文件分類的功能。

在下載任務(wù)的管理這一塊，用戶不僅希望下載工具具有下載一個一個資源的功能，而且具有批量下載有些相似的或有關(guān)聯(lián)的資源的功能。還有些特殊情況下，用戶在下載任務(wù)開始后由于種種原因希望放棄資源的下載，這就要求下載工具具有刪除任務(wù)的功能了。

為了對下載任務(wù)進行掌控，用戶往往具有設(shè)置下載任務(wù)的線程數(shù)，文件下載網(wǎng)址，文件下載存儲目錄和在下載過程中對下載任務(wù)的狀態(tài)進行監(jiān)控等功能需求。

鑒于某些軟件使用初學(xué)者甚至某些電腦初學(xué)者的實際情況，他們往往需要系統(tǒng)有一個格外的幫助文檔，使他們能夠更快、更好地學(xué)會使用斷點續(xù)傳下載軟件，提高效率。

3.2 業(yè)務(wù)流分析

多線程斷點續(xù)傳的業(yè)務(wù)流程：首先由用戶進入軟件系統(tǒng)，在新建任務(wù)中填寫必要的下載資源的相關(guān)屬性，比如相關(guān)資源下載地址URL、存儲路徑、以及下載線程數(shù)等。由軟件發(fā)送HTTP消息請求，然后服務(wù)器根據(jù)請求返回響應(yīng)消息。確認(rèn)無誤就可以啟動線程開始下載資源。將緩存中存儲的數(shù)據(jù)最終存儲到目的存儲路徑。此外，系統(tǒng)為用戶提供了一些對任務(wù)的基本操作，比如，停止、繼續(xù)、刪除等。

4. 系統(tǒng)設(shè)計

4.1 系統(tǒng)設(shè)計要點

隨著用戶下載需求的增大，用戶下載的資源越來越大，下載的過程也就越來越久，這就要求下載軟件能夠迅速完成對資源的下載，為了提高下載效率的問題，所以本系統(tǒng)采用多線程的方式來實現(xiàn)下載速率的提高。多線程的優(yōu)點之一是所有線程都可以訪問相同的全局變量和共享資源，它提供了程序設(shè)計的簡捷性與便利性，提高了對信息處理的并發(fā)度，但也帶來了數(shù)據(jù)的訛誤或線程得不到某一資源而被餓死（即死鎖）的可能性。為了避免這些現(xiàn)象的產(chǎn)生，線程在使用共享資源或?qū)ο笄氨仨毇@得一個約束訪問同步對象的權(quán)力，也就是通過同步的機制來控制這種權(quán)力的使用，這就是線程的安全問題。Http協(xié)議是互聯(lián)網(wǎng)中一個非常重要而且應(yīng)用十分頻繁的協(xié)議，所以本系統(tǒng)的設(shè)計是基于 Http協(xié)議的。長期以來，斷點續(xù)傳始終是困擾網(wǎng)蟲們的一大難題，眼看著已經(jīng)下載到99%的軟件，卻由于突然掉線而前功盡棄的那種沮喪恐怕人人都經(jīng)歷過，于是本系統(tǒng)采用斷點續(xù)傳的方式來設(shè)計。

本系統(tǒng)設(shè)計的基本目標(biāo)就是利用編寫一個時下流行的基于Http協(xié)議的多線程斷點續(xù)傳的程序來研究Java多線程與線程安全的機制。

4.2 系統(tǒng)總體功能結(jié)構(gòu)

通過對多線程斷點續(xù)傳下載軟件的需求分析并結(jié)合實際情況的分析，本系統(tǒng)由下載分類管理、任務(wù)管理、設(shè)置管理、系統(tǒng)幫助四個主模塊構(gòu)成。本系統(tǒng)的功能結(jié)構(gòu)圖如圖示：

其中下載文件的分類模塊主要是通過在新建下載任務(wù)時候設(shè)置下載文件的存儲目錄甚至新建一個存儲目錄的方式來實現(xiàn)。

下載任務(wù)的管理模塊主要有三個子模塊組成：新建下載任務(wù)模塊、批量完成下載任務(wù)模塊、刪除任務(wù)模塊。

在設(shè)置任務(wù)的管理模塊主要有兩個子模塊組成：在新建（批量）下載任務(wù)的時候進行任務(wù)的連接方面的配置模塊以及在現(xiàn)在過程中對下載任務(wù)的狀態(tài)進行監(jiān)視的模塊。

篇3

關(guān)鍵詞：Adhoc網(wǎng)絡(luò)；AODV；DSR

中圖分類號：TP393 文獻標(biāo)識碼：A 文章編號：1007-9599 (2012) 11-0000-02

一、前言

移動Adhoc網(wǎng)絡(luò)是未來技術(shù)，移動Adhoc網(wǎng)絡(luò)繼承了靈活、快速等特點，此外也有帶寬和電池能量、高度動態(tài)拓?fù)?、可擴展性和安全性差的問題。移動Adhoc網(wǎng)絡(luò)是一種不依賴于基礎(chǔ)設(shè)施的高移動性網(wǎng)絡(luò)，已廣泛應(yīng)用于災(zāi)難地區(qū)、犯罪跟蹤、應(yīng)急通信、軍事戰(zhàn)術(shù)應(yīng)用、緊急醫(yī)療服務(wù)等領(lǐng)域。

未來信息技術(shù)不容質(zhì)疑都是基于無線技術(shù)的?；A(chǔ)設(shè)施基礎(chǔ)蜂窩和移動網(wǎng)絡(luò)仍然是有限的需要，基礎(chǔ)設(shè)施，如基站，頻率分配。滿足用戶需求的各種方法進行了如頻率重用，聚類技術(shù)，分區(qū)技術(shù)，和不同的頻率分配的分配方案。特設(shè)的按需距離向量路由協(xié)議的多跳路由之間的參與使移動節(jié)點希望建立和保持一個特設(shè)的網(wǎng)絡(luò)。路由協(xié)議是基于距離矢量算法。但由于Adhocc網(wǎng)絡(luò)無線信道傳輸特性、節(jié)點位置不確定性引起的Adhoc網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)一直處于一種不穩(wěn)定的狀態(tài)，傳統(tǒng)的路由協(xié)議在Adhoc網(wǎng)絡(luò)不能適應(yīng)這些特征，因此Adhoc網(wǎng)絡(luò)中研究的熱點、重點就是路由協(xié)議。本文分析了二種Adhoc網(wǎng)絡(luò)中按需生成路由方式的典型協(xié)議：（1）AODV，就是無線自組網(wǎng)按需平面距離矢量路由協(xié)議，是無線mesh網(wǎng)絡(luò)中進行路由選擇的路由協(xié)議，它可以實現(xiàn)單播和多播路由。（2）DSR，就是動態(tài)源路由協(xié)議，是一個專門為多跳無線Adhoc網(wǎng)絡(luò)設(shè)計的簡單且高效的路由協(xié)議。所有的路由都是由路由協(xié)議動態(tài)地、自動地確定和維護，它提供快速反應(yīng)式服務(wù)，以便幫助確保數(shù)據(jù)分組的成功交付，即使在節(jié)點移動或者其他網(wǎng)絡(luò)狀況變化的條件下也是如此。

二、OPNET Modeler仿真環(huán)境

（一）OPNET Modeler仿真建模原理

本文中用來模擬Adhoc路由協(xié)議的是環(huán)境是OPNET Modeler 14.5，OPNET Modeler是業(yè)界領(lǐng)先、功能強大的網(wǎng)絡(luò)開發(fā)仿真軟件，支持各種類型的通信網(wǎng)絡(luò)和分布式系統(tǒng)模擬和仿真，使用模塊化設(shè)計和數(shù)學(xué)分析的建模方法，對各種網(wǎng)絡(luò)設(shè)施、通信鏈路和各層網(wǎng)絡(luò)協(xié)議來實現(xiàn)精確建模。

基于數(shù)據(jù)包，同時采用OPNET建模機制，模擬了實際的物理網(wǎng)絡(luò)數(shù)據(jù)包的流動，包括網(wǎng)絡(luò)設(shè)備內(nèi)部變化過程和網(wǎng)絡(luò)設(shè)備與設(shè)備間流動。同時采用OPNET離散事件驅(qū)動仿真機制，尤其，事件是指網(wǎng)絡(luò)狀態(tài)的變化，也就是說只有網(wǎng)絡(luò)狀態(tài)變化的時候，模擬機才會開始工作，而當(dāng)網(wǎng)絡(luò)狀態(tài)沒有進行更改的時間內(nèi)是不執(zhí)行任何計算，即被忽略執(zhí)行。

與此同時OPNET Modeler提供了一個良好的再次開發(fā)的接口：根據(jù)網(wǎng)絡(luò)環(huán)境和需要建立不同的協(xié)議仿真模型，仿真模型分為3層實現(xiàn)。進程模型在最底層，基于有限狀態(tài)機來描述；節(jié)點層在中間層，由相應(yīng)的協(xié)議模型組成，反映了設(shè)備的特點；網(wǎng)絡(luò)層在最上層，反映網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。3層模型和實際的網(wǎng)絡(luò)、設(shè)備、協(xié)議完全相互對應(yīng)，充分體現(xiàn)了網(wǎng)絡(luò)的相關(guān)性。

（二）網(wǎng)絡(luò)模型

我們使用一個靜態(tài)服務(wù)器與標(biāo)準(zhǔn)應(yīng)用程序模擬采取了20個移動節(jié)點，依次為0，1，…，19，所有節(jié)點隨機地分布在1000mx1000m大小的區(qū)域中，所有節(jié)點從服務(wù)器下載一個文件試圖為12000000字節(jié)。這些移動節(jié)點是隨機分布的，而且所有的移動節(jié)點配置是相同的。這個網(wǎng)絡(luò)場景中，任何移動節(jié)點可以直接通信，因此，不會產(chǎn)生終端被暴露或是終端被隱藏的問題。

對于移動節(jié)點的移動性，為此我們設(shè)置的三個重要參數(shù)：（1）速度10米/秒；（2）暫停時間0秒；（3）開始時間為10秒。此參數(shù)表明，所有節(jié)點單向移動速度10米/秒，暫停時間所有的移動節(jié)點不執(zhí)行任何計算，開始時間顯示活動開始10秒后啟動仿真的。

三、仿真結(jié)果及分析

網(wǎng)絡(luò)拓?fù)涓淖兊那闆r可以通過流動的節(jié)點來獲取，當(dāng)網(wǎng)路拓?fù)浒l(fā)生改變，路由會改變或查找路由，因此分組的轉(zhuǎn)發(fā)時間變長。為了定量對AODV與DSR進行比較，在此設(shè)置兩個相同的模擬仿真環(huán)境。每個仿真，只需要改變暫停時間設(shè)置，其他參數(shù)在過程中不用改變。

固定的20節(jié)點模型與移動20節(jié)點模型的平均端到端延遲進行比較，明顯是越增強節(jié)點移動性，網(wǎng)絡(luò)的平均端到端延遲變大，固定節(jié)點網(wǎng)絡(luò)中，因為路由變化不大，平均的網(wǎng)絡(luò)延遲幾乎是不變的，而在移動模型中，網(wǎng)絡(luò)的延遲隨著節(jié)點的頻繁移動，路由的不斷改變而變大。AODV的分組遞交率隨停頓時間的增加呈增大趨勢，DSR分組遞交率也隨停頓時間的增加而增大.且固定20節(jié)點模型與移動20節(jié)點模型的平均每路由發(fā)現(xiàn)時間，由于動態(tài)源路由協(xié)議的路由機制，在網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)穩(wěn)定的固定網(wǎng)絡(luò)中和網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)變化較快的Ad hoc網(wǎng)絡(luò)中，AODV的路由開銷隨停頓時間的增加呈減小趨勢，而DSR的路由開銷在停頓時間不斷增加的情況下則基本不變。

從仿真結(jié)果可以看出，如果從分組遞交率的情況來看這二個性能差異不大。在路由開銷情況來看，DSR路由開銷較小，主要AODV路由頻繁的交換握手消息導(dǎo)致路由開銷增加。而由于DSR使用源路由算法，每一個節(jié)點記住整個路由；而AODV采用逐跳路由的算法，每一個節(jié)點僅僅是記住下一跳，所以DSR報文開銷要大一些。

四、結(jié)論

本文介紹了兩種典型Adhoc網(wǎng)絡(luò)路由協(xié)議AODV和DSR，并通過OPNET Modeler在同樣的場景對這兩個路由協(xié)議進行仿真，并根據(jù)實驗數(shù)據(jù)來計算路由協(xié)議的性能指標(biāo)：平均端到端延遲性能參數(shù)和數(shù)據(jù)包的成功傳輸率，繪制出相應(yīng)的圖進行比較。在實驗中仿真場景中可以看到，DSR網(wǎng)絡(luò)性能指標(biāo)和AODV比較接近，是一種適用于中小型網(wǎng)絡(luò)結(jié)構(gòu)且網(wǎng)絡(luò)性能穩(wěn)定的路由協(xié)議；AODV是DSR和DSDV的組合，是一種適用于大規(guī)模網(wǎng)絡(luò)結(jié)構(gòu)且效率高、適應(yīng)性強的路由協(xié)議。

參考文獻：

[1]陳迪.無線Mesh網(wǎng)絡(luò)的Mac協(xié)議和路由協(xié)議研究與實現(xiàn)[D].南京郵電大學(xué),2012,2,1

[2]何磊,許立,劉澤國,范力旻.移動AdHoc網(wǎng)絡(luò)退避算法的改進與仿真研究[J].計算機仿真,2011,8,15

篇4

最好的例子是HTTP協(xié)議，這是一個負(fù)責(zé)調(diào)控瀏覽器和服務(wù)器之間通信的核心應(yīng)用協(xié)議。目前該協(xié)議的最新版本為1.1版，而這個所謂的最新版本只是在1999年進行了一些零星優(yōu)化，該協(xié)議的主要缺點皆沒有被修正，這樣落后的一個網(wǎng)絡(luò)協(xié)議，自然無法適應(yīng)目前的網(wǎng)絡(luò)應(yīng)用環(huán)境，也無法充分利用帶寬。

此外，使用HTTP 1.1協(xié)議處理通信數(shù)據(jù)的開銷龐大，將產(chǎn)生許多不必要的數(shù)據(jù)流量。因而，負(fù)責(zé)互聯(lián)網(wǎng)標(biāo)準(zhǔn)的開發(fā)和推動的互聯(lián)網(wǎng)工程任務(wù)組（Internet Engineering Task Force，簡稱IETF）自2012年以來，一直致力于改進這個互聯(lián)網(wǎng)的主要協(xié)議。目前，HTTP 2.0已經(jīng)基本準(zhǔn)備就緒，IETF希望能夠在2014年年底開始正式實施它，而相關(guān)的草案已于2013年8月開始進行測試。

對于HTTP 2.0的競爭提案

2012年，Google和微軟分別提交了自己的HTTP 2.0建議，Google開發(fā)的是早以聞名遐邇的SPDY協(xié)議，微軟與之競爭的則是HTTP Speed+Mobility，兩者之間的主要爭議在于HTTP 2.0是否應(yīng)該完全采用加密的形式。目前，雖然SPDY已經(jīng)被接受成為HTTP 2.0的基礎(chǔ)，但是IETF免除了SPDY強制性加密的規(guī)定，因為加密將增加設(shè)備的運算負(fù)擔(dān)，而對于移動設(shè)備來說，這意味著續(xù)航時間大受影響。另外，這還將要求所有的網(wǎng)站都要安裝加密證書，對于小型網(wǎng)站來說，加密證書的費用是一個不小的負(fù)擔(dān)。

就在HTTP 2.0整裝待發(fā)之時，愛德華·斯諾登披露的消息影響了該標(biāo)準(zhǔn)的計劃。2013年9月初，所有人都清楚地了解到美國國家安全局等情報機構(gòu)的所作所為，而更令人震驚的是他們竟然還可以攔截和竊取HTTPS的加密數(shù)據(jù)。加密專家布魯斯·施奈爾認(rèn)為，實際上美國政府已經(jīng)背叛了互聯(lián)網(wǎng)。因而，HTTP 2.0的安全問題成了人們關(guān)注的焦點，IETF必須根據(jù)斯諾登披露的信息重新評估該協(xié)議的安全性，并收集更多關(guān)于如何完善HTTP 2.0的加密功能以確保HTTP 2.0協(xié)議安全性的建議。

國家安全局的后門

現(xiàn)有的HTTPS加密是利用SSL和TLS協(xié)議來建立安全連接，這種非對稱加密包含一個公共和一個私有密鑰。首先，服務(wù)器發(fā)送一個經(jīng)過認(rèn)證的公共密鑰到瀏覽器，瀏覽器將檢查認(rèn)證證書的有效性，并使用服務(wù)器的密鑰將用于接下來加密通信數(shù)據(jù)的會話密鑰加密發(fā)送到服務(wù)器，服務(wù)器將使用與其公共密鑰對應(yīng)的私鑰來提取會話密鑰，并開始使用會話密鑰加密通信數(shù)據(jù)。接下來，服務(wù)器和瀏覽器之間就可以使用相同的會話密鑰來加密通信以做進一步的溝通。

然而，美國國家安全局之類的情報機構(gòu)可以截取全部的通信數(shù)據(jù)，并利用其權(quán)威或者其他的手段獲取服務(wù)器的私鑰，例如通過法庭的命令或者通過黑客手段，在擁有服務(wù)器私鑰的情況下，所有的數(shù)據(jù)都將是透明的。因此，有人建議在HTTP 2.0中部署不同的密鑰生成方法，正在開發(fā)中的TLS1.3加密協(xié)議將使用不需要交換密鑰的完全轉(zhuǎn)發(fā)保密（Perfect Forward Secrecy，簡稱PFS）技術(shù)。服務(wù)器和瀏覽器之間通過密碼系統(tǒng)產(chǎn)生一個對稱密鑰用于加密接下來的通信數(shù)據(jù)，密鑰將在會話結(jié)束之后被刪除。

不過，要確保PFS的安全，首先要求用于生成密鑰的加密方法必須是安全的。很多人懷疑，過去美國國家安全局一直積極致力于參與加密方法的研發(fā)是別有用心的，因為選擇一個掌握在自己手上的加密方法不難設(shè)置后門讓自己可以通行無阻。眾所周知，雙橢圓曲線確定性隨機比特生成器（dual elliptic curve deterministic random bit generator，縮寫Dual_EC_DRBG）是如何被植入后門的。因而，目前所有由美國國家標(biāo)準(zhǔn)技術(shù)研究所（National Institute of Standards and Technology，簡稱NIST）的曲線都是受到質(zhì)疑的，因而，由西蒙·約瑟夫松提交給IETF的一個名為25519的橢圓曲線，由于不是來自NIST，所以將有可能用于TLS 1.3。這樣一來，TLS 1.3應(yīng)該可以關(guān)上NSA的后門。

不過，光有一個新的TLS加密協(xié)議是不夠的，因為人們也同樣懷疑用于HTTPS的RC4加密方法中包含NAS留下的一個漏洞。RC4是TLS加密協(xié)議的一部分，根據(jù)相關(guān)的研究顯示，目前Web加密數(shù)據(jù)中約有50%使用此加密方法，因而，對于了解該漏洞的人來說，他們當(dāng)然不會在TLS 1.3中選擇使用RC4加密方法。遺憾的是，目前的Web安全應(yīng)用中具體使用什么安全協(xié)議是由服務(wù)器決定的，盡管Chrome和IE瀏覽器的最新版本都已經(jīng)支持當(dāng)前最新的TLS 1.2，但是大多數(shù)Web服務(wù)器仍然在使用過時的SSL 3.0和TLS 1.0，用戶也只能被迫使用這些過時的安全協(xié)議，而這些協(xié)議存在可以被黑客利用的漏洞已經(jīng)是公開的秘密。HTTP 2.0方案有可能要扭轉(zhuǎn)這一局面，也就是說，未來由瀏覽器來確定應(yīng)該使用哪一個安全協(xié)議，用戶可以指定使用什么樣的加密方法來保護HTTPS連接。

修補SSL、TLS中的安全漏洞

當(dāng)前，SSL、TLS的數(shù)據(jù)包有可能被截取和操縱，黑客可以對SSL、TLS通信進行有效的攻擊。通信過程中的每一個數(shù)據(jù)包中包含起核心作用的消息認(rèn)證碼（Message Authentication Code，簡稱MAC），MAC由會話密鑰和傳送的數(shù)據(jù)產(chǎn)生，接收者可以通過MAC確定收到的數(shù)據(jù)是否來自發(fā)送者，從而避免數(shù)據(jù)包被截取和操縱。但是目前使用的SSL、TLS采用所謂“MAC then encrypt”的方法進行處理，傳輸?shù)氖敲魑呐c明文的MAC值加密的結(jié)果，未加密的數(shù)據(jù)包內(nèi)容被用于生成MAC，這種方法早在1999年就已經(jīng)被證實是不可靠的。為此，作為對策，TLS的升級版本采用“Encrypt then MAC”的處理方法，這種方法傳輸?shù)氖敲芪呐c密文的MAC值，黑客很難有所作為。當(dāng)然，仍然無法確定這些方法是否已經(jīng)足以防止情報機構(gòu)的嗅探，但是這起碼修補了已知的安全漏洞。而對于互聯(lián)網(wǎng)工程任務(wù)組來說，HTTP 2.0是否應(yīng)該完全采用加密的形式，這一最具爭議的話題仍然會再出現(xiàn)在議程上。

去除性能缺陷

IETF成員同時需要考慮的問題是新的技術(shù)標(biāo)準(zhǔn)如何消除HTTP 1.1的性能缺陷。目前，解決這一問題的基礎(chǔ)是Google的SPDY協(xié)議，該協(xié)議將可以解決HTTP 1.1的結(jié)構(gòu)性缺陷，而Chrome、IE、Firefox和Opera這些瀏覽器的最新版本都已經(jīng)支持該協(xié)議，僅有蘋果公司的Safari瀏覽器暫時未能支持。

在HTTP 1.1協(xié)議中，服務(wù)器需要為網(wǎng)頁中的每個元素建立一個單獨的TCP連接，因此需要啟動多個并行連接，這將導(dǎo)致產(chǎn)生不必要的數(shù)據(jù)流量，并且很容易出現(xiàn)線頭阻塞（Head of Line Blocking，HOL），影響數(shù)據(jù)包的處理速度。因為數(shù)據(jù)包的處理總是按照既有的順序進行，而不論該請求是否出現(xiàn)問題或處理的時間是否太長。此外，HTTP連接是由客戶建立的，瀏覽器必須不斷地查詢網(wǎng)站以了解內(nèi)容是否發(fā)生了變化，而服務(wù)器本身不會自動發(fā)送更新內(nèi)容。

一個HTTP 2.0連接一旦被建立，那么它將在瀏覽器和服務(wù)器之間打開數(shù)據(jù)流通道來發(fā)送它們的數(shù)據(jù)包，數(shù)據(jù)可以在同一時間并行進行傳輸。與HTTP 1.1相比，HTTP 2.0實現(xiàn)了單個TCP連接的并行處理，這意味著服務(wù)器不再需要應(yīng)付大量的瀏覽器查詢，所以可以大幅度減輕服務(wù)器的負(fù)荷。而且，數(shù)據(jù)幀標(biāo)有優(yōu)先順序，解碼時瀏覽器或服務(wù)器可以相應(yīng)地調(diào)整順序，徹底地避免線頭阻塞的問題。此外，HTTP 2.0中服務(wù)器還可以將信息發(fā)送到瀏覽器，同時數(shù)據(jù)包報頭也得到了優(yōu)化。在HTTP 1.1中數(shù)據(jù)包報頭以未經(jīng)壓縮的文本形式傳輸，這使得報頭過大，同時在處理之前還需要轉(zhuǎn)換成二進制碼。而HTTP 2.0將報頭壓縮，以二進制代碼來發(fā)送它們，這除了減少了數(shù)據(jù)量之外，也減少了處理的等待時間（響應(yīng)時間）。

HTTP 1.1和TCP在許多方面是相關(guān)聯(lián)的，以并行處理的問題為例，HTTP 1.1中實際上是通過TCP協(xié)議來提供HTTP中缺少的功能，但是TCP為了完成這一功能必須建立大量的連接，還需要負(fù)責(zé)確定數(shù)據(jù)的序列并完成數(shù)據(jù)傳輸過程中的檢測和修復(fù)等工作，而這些工作都將產(chǎn)生一定的延遲。對于TCP連接來說，僅建立連接的過程中3個階段的握手就已經(jīng)增加了不少延遲。

而HTTP 2.0中很多工作不再需要TCP協(xié)議來承擔(dān)，或者更確切地說，HTTP 2.0將接管這些任務(wù)，例如數(shù)據(jù)幀的優(yōu)先級設(shè)定將確定數(shù)據(jù)包如何進行處理，不再需要TCP確定數(shù)據(jù)包的序列。因此，Google甚至建議使用基于更快但不那么可靠的用戶數(shù)據(jù)報協(xié)議（User Datagram Protocol，簡稱UDP）作為HTTP 2.0的傳輸協(xié)議。Google的快速UDP互聯(lián)網(wǎng)連接（Quick UDP Internet Connections，簡稱QUIC）正是基于UDP的，只是加入了糾正錯誤的機制。使用QUIC作為傳輸協(xié)議的話，TCP的錯誤檢測等操作將不再是必要的了，TCP最為尷尬的3次握手產(chǎn)生的延遲也將不會再是問題，因為HTTP 2.0建立的是服務(wù)器與瀏覽器之間相互通信的數(shù)據(jù)流。從長遠來看，Google并不打算取代TCP，而是希望將QUIC融入到TCP中。我們可以預(yù)期從HTTP 1.1到HTTP 2.0的切換是非常順利的，用戶需要做的只是更新瀏覽器以支持HTTP 2.0，在瀏覽器支持HTTP 2.0的情況下將自動向服務(wù)器發(fā)出請求，并開啟一個煥然一新的互聯(lián)網(wǎng)。

篇5

要

萬維網(wǎng)WWW(World Wide web)并非某種特殊的計算機網(wǎng)絡(luò)。萬維網(wǎng)是一個大規(guī)模的、聯(lián)機式的消息儲藏所，英文簡稱為Web。萬維網(wǎng)用鏈接的方法能非常方便地從因特網(wǎng)上的一個站點訪問另一個站點(也就是所謂的“鏈接到另一個站點”)，從而主動地按需獲取豐富的信息。

本程序是一個簡單易用、方便快捷的多頁面網(wǎng)頁瀏覽器。您可以通過它快速地鏈接到全球任何一個可瀏覽網(wǎng)站，瀏覽豐富的Web資源。

論文先介紹了程序編程語言Visual C++和面向?qū)ο缶幊痰母拍?，以?Microsoft Visual Studio 6.0開發(fā)環(huán)境。然后介紹了要完成這個軟件必須先了解WWW所用到的協(xié)議： HTTP和TCP/IP協(xié)議。HTTP的全稱是HyperText Transfer Protocol，即超文本傳輸協(xié)議。HTTP是一個應(yīng)用層協(xié)議，它使用TCP的80端口連接進行可靠的傳送。TCP/IP是用于網(wǎng)絡(luò)的一組通信協(xié)議，包括TCP（Transmission Control Protocol）協(xié)議和IP（Internet Protocol）協(xié)議。

要訪問網(wǎng)頁還得輸入它的URL（Uniform Resource Locator），即統(tǒng)一資源定位符。對于HTTP協(xié)議，URL的一般形式是：:/。默認(rèn)端口80通常省略。

當(dāng)我們了解以上內(nèi)容后，文章就開始介紹圍繞程序進行的一系列分析和設(shè)計。介紹程序有哪些功能，是如何實現(xiàn)的。

使用本軟件的時候，用戶只需要在地址欄輸入網(wǎng)址（URL），敲擊回車就可以連接精彩的網(wǎng)絡(luò)世界了。

關(guān)鍵詞：萬維網(wǎng) 網(wǎng)頁瀏覽器

HTTP TCP/IP URL

目

錄 IV

1

緒

論 1

2

系統(tǒng)平臺開發(fā)介紹 2

略……

3

MFC 編程 4

略……

4

HTTP與TCP/IP協(xié)議介紹 7

略……

5

需求分析和可行性研究 12

略……

6

總體設(shè)計 14

略……

7

詳細(xì)設(shè)計與函數(shù)實現(xiàn) 17

略……

8

結(jié)

論 37

參考文獻 39

附件1

英文翻譯原文（英文） 40

附件2

英文翻譯中文 45

：13000多字

有中英文摘要、目錄、參考文獻、程序包及運行文件

300元

另：有2100字的外文文獻及3300的中文翻譯

篇6

【摘要】雖然Android有SQLite的支持，但由于手機的硬件條件限制，很多數(shù)據(jù)庫并沒有直接運行在客戶端上，因此對遠程數(shù)據(jù)庫的訪問也是Android的必要技術(shù)。本文主要運用HttpClient組件，完成對遠程數(shù)據(jù)庫的訪問，實現(xiàn)Android客戶端對遠程服務(wù)器數(shù)據(jù)的調(diào)用及修改。

 

【關(guān)鍵詞】Android；HttpClient；MySQL；JSP

1.引言

雖然Android本身具有SQLite的支持，但SQLite數(shù)據(jù)只能進行簡單的CRUD操作，數(shù)據(jù)類型也不能太復(fù)雜和數(shù)據(jù)容量不能太大。[1]而訪問遠程數(shù)據(jù)庫的方法多種多樣，主要分為直接和間接兩種。直接訪問采用JDBC連接技術(shù)，但其安全性較低，間接方法主要通過客戶端向服務(wù)器發(fā)送請求，進而采用數(shù)據(jù)傳輸?shù)姆绞竭M行數(shù)據(jù)庫訪問。

 

當(dāng)下比較流行的數(shù)據(jù)傳輸方式主要有XML和JSON兩種方式，由于HTTP協(xié)議是從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議，使瀏覽器更加高效，[2]而HttpClient是支持HTTP協(xié)議的客戶端編程工具包，因此HttpClient組件為實現(xiàn)遠程數(shù)據(jù)庫的連接提供了更為便捷有效的方式。

 

2.HttpClient簡介

HttpClient是Apache Jakarta Common下的子項目，可以用來提供高效的、最新的、功能豐富的支持HTTP協(xié)議的客戶端編程工具包。它提供的主要的功能包括：實現(xiàn)了所有HTTP的方法（GET，POST，PUT，HEAD等）、支持自動轉(zhuǎn)向、支持HTTPS協(xié)議、支持服務(wù)器等。[3]

 

3.HttpClient在Android中的應(yīng)用

3.1 工作原理

（1）客戶端通過URL向服務(wù)器發(fā)送請求，建立連接；

（2）服務(wù)器接收客戶端請求，并將響應(yīng)信息返回客戶端；

（3）客戶端與服務(wù)器斷開連接。[4]

3.2 服務(wù)器端的開發(fā)

服務(wù)器端采用JSP技術(shù)，通過利用JavaBean使用JDBC完成數(shù)據(jù)庫連接，同時，使用Servlet實現(xiàn)數(shù)據(jù)傳輸功能。

3.3 手機客戶端的開發(fā)

Android集成了org.apache.http.client.HttpClient，可以直接實現(xiàn)簡單的htttp Get和Post操作。操作實現(xiàn)步驟如下：

 

（1）創(chuàng)建HttpClient客戶端對象；

（2）生成響應(yīng)的請求信息；

（3）使用execute方法發(fā)送HTTP GET（HTTP POST）請求，并返回HttpResponse對象，通過利用getStatusCode獲取返回碼以判斷請求是否發(fā)送成功（若返回碼為200，則成功）； 

 

（4）解析返回信息。

關(guān)鍵代碼如下：

public class ApacheHttpClient{

public String httpGet（String url） {

String response = null；

HttpClient httpclient = new DefaultHttpClient（）；

HttpGet httpGet = new HttpGet（url）；

HttpResponse httpResponse；

try{

httpResponse = httpclient.execute（httpGet）；

int statusCode = httpResponse.getStatusLine（）.getStatusCode（）；

if（statusCode==HttpStatus.SC_OK）{

response = EntityUtils.toString（httpResponse.getEntity（））；

}

else{

response = “返回碼：”+statusCode；

}

} catch （Exception e）{}

return response；

}

public String httpPost（String url，List params） throws Exception{

String response = null；

HttpClient httpclient = new DefaultHttpClient（）；

HttpPost httppost = new HttpPost（url）；

try{

httppost.setEntity（new UrlEncodedFormEntity（params，HTTP.UTF_8））；

HttpResponse httpResponse = httpclient.execute（httppost）；

int statusCode = httpResponse.getStatusLine（）.getStatusCode（）；

if（statusCode==HttpStatus.SC_OK）{

response = EntityUtils.toString （httpResponse.getEntity（））；

}

else {

response = “返回碼：”+statusCode；

}

}catch （Exception e）{}

return response；

}

}

4.結(jié)束語

本文在利用JavaBean工具類對數(shù)據(jù)庫進行操作的基礎(chǔ)上，通過使用Servlet進行數(shù)據(jù)的輸入輸出，并結(jié)合HttpClient組件傳送Http數(shù)據(jù)，順利實現(xiàn)了Android與遠程數(shù)據(jù)庫的間接訪問，同時也在一定程度上加強了對數(shù)據(jù)庫的安全性保護。未來HttpClient組件技術(shù)還將在Android手機平臺中越來越廣泛地得以應(yīng)用。

 

參考文獻

[1]李洋，殷云鵬，趙勇.基于Android的網(wǎng)絡(luò)數(shù)據(jù)存儲與訪問[J].中國科技信息，2013（08）：92-92.

[2]林汝澤，徐媛媛，方凱等.基于HTTP協(xié)議的Android手機數(shù)據(jù)同步實現(xiàn)[J].信息通信，2013（01）：96-96.

[3]徐婉珍.HttpClient組件及其在Android開發(fā)中的應(yīng)用探討[J].數(shù)字技術(shù)與應(yīng)用，2013（01）.

篇7

關(guān)鍵詞：UPnP；數(shù)字電視機頂盒：控制點；libupnp

中圖分類號：TP311 文獻標(biāo)識碼：A 文章編號：1009-3044（2013）01-0162-03

隨著越來越多的設(shè)備聯(lián)入網(wǎng)絡(luò)，對于共享設(shè)備以及共享設(shè)備提供的資源和服務(wù)的需求也越來越強烈，透明的訪問各種聯(lián)入網(wǎng)絡(luò)的資源也成為了一種非常復(fù)雜的任務(wù)。UPnP（Universal Plug and Play），通用即插即用。Microsoft公司稱“UPnP”將延伸到家庭中的每一個設(shè)備，它會成為個人電腦、應(yīng)用程序、智能設(shè)備集成工作所必需的框架、協(xié)議和接口標(biāo)準(zhǔn)。它是一種架構(gòu)在TCP/IP和HTTP技術(shù)之上的，分布式、開放的網(wǎng)絡(luò)結(jié)構(gòu)，以使得在聯(lián)網(wǎng)的設(shè)備間傳遞控制和數(shù)據(jù)。UPnP 技術(shù)實現(xiàn)了控制點、設(shè)備和服務(wù)之間通訊的支持，并且設(shè)備和相關(guān)服務(wù)的也使用XML（Xtensible Markup Language）定義并且公布出來。對于設(shè)備的描述，使用HTML（Hypertext Markup Language）表單表述設(shè)備控制界面。它既允許設(shè)備供應(yīng)商提供基于瀏覽器的用戶界面和編程控制接口，也允許開發(fā)人員定制自己的設(shè)備界面。

UPnP論壇成立于1999年10月18日，該組織目前已吸引超過200個在消費電子、家庭自動化、計算機、家電、計算機網(wǎng)絡(luò)和移動設(shè)備等領(lǐng)域的頂級供應(yīng)商的參與。UPnP技術(shù)在IP層以上，應(yīng)用層以下，所以與具體的物理接入手段和應(yīng)用無關(guān)。使用UPnP協(xié)議不需要設(shè)備驅(qū)動程序，因此使用UPnP建立的網(wǎng)絡(luò)是介質(zhì)無關(guān)的，它可以運行在幾乎所有的操作系統(tǒng)平臺之上，可以使用C，C++，JAVA和VB等開發(fā)語言，使得在辦公室、家庭和其他公共場所方便地構(gòu)建設(shè)備相互聯(lián)通的網(wǎng)絡(luò)環(huán)境[1-2]。

總之，使用UPnP，設(shè)備可以動態(tài)加入網(wǎng)絡(luò)，自動獲得一個IP地址，向其他設(shè)備公布它的能力或者獲知其他設(shè)備的存在和服務(wù)，所有這些過程都是自動完成的，此后設(shè)備能夠彼此直接通訊。

1 SDK架構(gòu)

Linux SDK for UPnP Devices（libupnp）是一個便攜的、可移植的UPnP的C語言開發(fā)包。為開發(fā)者建立符合UPnP設(shè)備體系規(guī)范的控制點、設(shè)備和橋提供了一套API和開源代碼。Libupnp使開發(fā)人員擺脫各種協(xié)議的細(xì)節(jié)，專心進行服務(wù)或者控制所需的具體開發(fā)。SDK各模塊之間的關(guān)系如圖1所示[3]。

1）Device/Control Point：客戶端或服務(wù)器程序運行在整個SDK的最頂層，實現(xiàn)一個特定服務(wù)的功能。例如，一個網(wǎng)關(guān)類的服務(wù)，服務(wù)器實現(xiàn)能夠用UPnP控制的“網(wǎng)絡(luò)使能”功能。

2）SDK API：SDK API從控制點或服務(wù)程序中提取出核心UPnP協(xié)議的細(xì)節(jié)并給應(yīng)用程序訪問功能提供統(tǒng)一的接口。這使得開發(fā)者免于SSDP，GENA和SOAP各種協(xié)議細(xì)節(jié)的煩惱。

3）SSDP：SSDP（SimpleService Discovery Protocol）模塊實現(xiàn)了簡單服務(wù)發(fā)現(xiàn)協(xié)議，提供UPnP的發(fā)現(xiàn)階段。該模塊允許控制點發(fā)送多播信息搜索網(wǎng)絡(luò)上的設(shè)備并接受應(yīng)答。

4）Mini Web Server：迷你Web服務(wù)器模塊處理標(biāo)準(zhǔn)HTTP GET請求，許多UPnP部分都用這種基本的HTTP請求服務(wù)。該模塊管理那些能用GET命令獲得的文檔地址，并實現(xiàn)了使用HTTP協(xié)議的實際數(shù)據(jù)流。迷你Web服務(wù)器模塊實現(xiàn)了HTTP/1.1的RANGE頭，允許一個遠程客戶端請求一個文件定的一片或者多片。

5）GENA：GENA模塊實現(xiàn)通用事件通知架構(gòu)，實現(xiàn)UPnP的事件部分。控制點使用該模塊訂閱和取消訂閱感興趣的服務(wù)，服務(wù)應(yīng)用程序從該模塊中接受訂閱和退訂消息并產(chǎn)生相應(yīng)的事件。

6）SOAP：SOAP（Simple Object Access Protocol）模塊實現(xiàn)簡單對象訪問協(xié)議，提供UPnP的控制部分?？刂泣c使用該模塊產(chǎn)生相應(yīng)的XML文檔來檢索一個服務(wù)的狀態(tài)表，服務(wù)器使用該模塊解碼控制請求并產(chǎn)生應(yīng)答。

7）HTTP：HTTP對接收信息的HTTP頭進行語法分析并構(gòu)建發(fā)送信息頭。該模塊能處理HTTP/1.0和HTTP/1.1頭，也支持HTTP/1.1F分塊編碼語法。

2 機頂盒作為控制器的設(shè)計和實現(xiàn)

篇8

電腦使用技巧：以win7系統(tǒng)為例，若用戶在使用電腦的時候想要設(shè)置電腦的桌面主題，只需在電腦桌面空白處右鍵單擊，在彈出的選項里點擊個性化，然后就可以選擇一個自己喜歡的主題了。

若用戶想要在電腦桌面添加天氣小工具，在電腦桌面空白處右鍵單擊后點擊小工具選項，打開后就可以看到天氣小工具了，點擊就可以選擇添加了。

在使用電腦的時候，若電腦出現(xiàn)卡頓的情況，用戶可以選擇清理一下電腦垃圾，或者說也可以直接將電腦關(guān)機重啟一下，相對來說也是比較方便的。

篇9

關(guān)鍵詞:服務(wù)器推送技術(shù)；實時Web應(yīng)用；HTML5；WebSocket協(xié)議；HTTP協(xié)議

中圖分類號：TP393文獻標(biāo)識碼：A文章編號：1009-3044(2012)16-3826-03

WebSocket Based Real Time Web Application Solution

WENG Zhao-song1,YI Ren-wei2,YAO Han-bin2

(1.Wuhan Construction Project Trading Center,Wuhan 430023,China;2.Wuhan Uinversity of Technology,Wuhan 430063,China)

Abstract: Due to the improving demands on instantaneity of web information, real-time web applications is beginning to cause wide spread interest, and a lot of real-time web applications based on server-push technology has been proposed and used widely. Though these solution are effective, all those solutions suffer from problems such as great resource consumption; there is much space for improve ment. This paper introduces two popular HTTP protocol based real-time web application solutions, that is, long polling based on Ajax and streaming based on Iframe, and analysis their weaknesses. With an in-depth study on WebSocket protocol in HTML5 standard, this paper proposes a WebSocket protocol based real-time web application solution, aiming at improving the service instantaneity on a large scale, and more efficiently using the network capacity and processing power of the server.

Key words: server-push;real-time application; HTML5;WebSocket protocol;HTTP protocol

基于HTTP協(xié)議的Web應(yīng)用已得到了十足的發(fā)展和應(yīng)用，成為人們獲取互聯(lián)網(wǎng)上海量信息的主要途徑。然而隨著信息時代的發(fā)展，人們開始對Web應(yīng)用提出了實時性要求，希望這些信息更新后能夠立即獲取到。對這項需求，多種實時Web應(yīng)用解決方案被提出，其中較為成功并廣泛應(yīng)用的包括：基于Ajax的長輪詢以及基于Iframe的流方式。基于這些解決方案，互聯(lián)網(wǎng)上涌現(xiàn)出了一系列實時應(yīng)用，如在線游戲、在線證券、設(shè)備監(jiān)控、RSS閱讀推送、郵件提示等等。

然而這些技術(shù)在廣泛運用的過程中也暴露出了大量的問題，如實現(xiàn)復(fù)雜、資源消耗大、實時性不高等，這些問題制約了實時Web應(yīng)用的性能。

隨著HTML5標(biāo)準(zhǔn)的發(fā)展，該標(biāo)準(zhǔn)中提出的一項名為WebSocket的通信協(xié)議得到了廣泛的關(guān)注。WebSocket可以在瀏覽器和服務(wù)器之間提供一條基于TCP連接的雙向通道，服務(wù)器和瀏覽器通過這個通道可以實現(xiàn)雙向通信。這種雙向通信能力使得利用WebSocket來構(gòu)建實時web應(yīng)用成為可能。

該文將在總結(jié)現(xiàn)有的兩種實時Web應(yīng)用方案的基礎(chǔ)上，提出一種基于WebSocket的解決方案，新的方案將在很大程度上解決傳統(tǒng)方案暴露出的問題。

1傳統(tǒng)實時Web應(yīng)用解決方案

在實時Web應(yīng)用出現(xiàn)之初，最簡單的實現(xiàn)方案是輪詢。所謂輪詢就是客戶端以一定的時間間隔向服務(wù)器端發(fā)出請求，以頻繁請求的方式來不斷刷新客戶端呈現(xiàn)的信息。這種方案缺乏靈活性，無論服務(wù)器端是否有信息更新，請求都會不斷被發(fā)送，頻繁的連接請求會給服務(wù)器端帶來巨大的處理壓力。所以這種方案逐漸被舍棄，進而發(fā)展出了基于Ajax的長輪詢方式和基于Iframe的流方式。這兩種方式都在原有輪詢的基礎(chǔ)做了改進，一定程度上克服了簡單輪詢的不足。

1.1基于Ajax的長輪詢方式和基于Iframe的流方式

篇10

網(wǎng)絡(luò)下載多面手：跨協(xié)議下載

如今，互聯(lián)網(wǎng)上的資源越來越豐富了，資源下載的途徑從最初的HTTP和FTP下載，拓展到BT及電驢等P2P下載方式，近年來更是出現(xiàn)了以迅雷為代表的明顯提高下載效率的P2SP下載。這時，傳統(tǒng)的直接連接某個單一下載資源服務(wù)器的做法已經(jīng)不能解決下載速度慢、下載服務(wù)器所需帶寬大等弊端。為了提高下載效率，“跨協(xié)議下載”的技術(shù)應(yīng)運而生。

目前，很多下載工具軟件都應(yīng)用了跨協(xié)議下載技術(shù)，但是對于它的定義和概念卻眾說紛紜，主要有以下兩種：

1　兼容多種下載協(xié)議：這是跨協(xié)議下載的“初級階段”，嚴(yán)格地講不算是真正意義上的跨協(xié)議下載，稱之為“多協(xié)議下載”可能更合適。它可以讓下載軟件從單一支持HTTP和FTP下載拓展到支持更多的協(xié)議(如MMS、RTSP、BT和電騾等)下載，其具代表性的軟件為較早版本的FlashGet。

2　從多個不同協(xié)議的下載源同時下載：這種定義的基礎(chǔ)是下載軟件已經(jīng)支持多種下載協(xié)議，當(dāng)使用其中一種協(xié)議下載時，下載軟件除了用該協(xié)議的鏈接下載文件，還會自動搜索其他三種協(xié)議的下載鏈接，以提高下載速度和成功率。例如，下載一個HTTP協(xié)議的文件時，下載軟件會自動搜索到BT或Emule甚至更多協(xié)議上的相同可用文件進行下載，大大提高了文件下載的效率和成功率，最具代表的是最新版的脫兔。

“跨協(xié)議下載”如何跨協(xié)議?

為何跨協(xié)議下載文件更加流暢且成功率高呢?這都是因為使用了多個下載源(包括不同協(xié)議的下載源)的緣故。使用支持跨協(xié)議下載的工具軟件下載時，軟件會自動進行以下工作：

1　點擊下載鏈接時，下載工具軟件首先連接下載工具軟件廠商的服務(wù)器將下載信息告知服務(wù)器。

2　如果服務(wù)器中存在該文件的相關(guān)信息，服務(wù)器就反饋更多的不同協(xié)議的下載源；如果沒有相關(guān)信息，就將本次下載源的地址上傳到服務(wù)器數(shù)據(jù)庫中存儲，便于以后更多用戶下載時使用。連接的過程中，由不同客戶端提供的不同下載協(xié)議的源地址，同時保存了下來，不斷豐富著服務(wù)器的文件庫。