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

篇1

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

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

1 HTTP協(xié)議

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

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

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

第二，發(fā)送請(qǐng)求?？蛻舳税凑誋TTP協(xié)議通過(guò)連接線路向服務(wù)端發(fā)送請(qǐng)求。

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

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

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

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

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

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

第二，瀏覽器向DNS請(qǐng)求解析IP地址。

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

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

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

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

第七，TCP連接釋放。

第八，瀏覽器將文件index.heml進(jìn)行解釋，并將Web頁(yè)顯示給用戶。

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

2 FTP協(xié)議

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

FTP提供以下功能：

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

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

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

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

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

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

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

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

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

參考文獻(xiàn)：

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

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

作者簡(jiǎn)介：周開(kāi)強(qiáng)（1993―），男，黑龍江慶安人。

篇2

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

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

需求分析

3.1用戶需求分析

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

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

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

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

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

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

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

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

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

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

4.1 系統(tǒng)設(shè)計(jì)要點(diǎn)

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

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

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

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

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

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

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

篇3

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

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

一、前言

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

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

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

（一）OPNET Modeler仿真建模原理

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

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

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

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

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

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

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

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

固定的20節(jié)點(diǎn)模型與移動(dòng)20節(jié)點(diǎn)模型的平均端到端延遲進(jìn)行比較，明顯是越增強(qiáng)節(jié)點(diǎn)移動(dòng)性，網(wǎng)絡(luò)的平均端到端延遲變大，固定節(jié)點(diǎn)網(wǎng)絡(luò)中，因?yàn)槁酚勺兓淮螅骄木W(wǎng)絡(luò)延遲幾乎是不變的，而在移動(dòng)模型中，網(wǎng)絡(luò)的延遲隨著節(jié)點(diǎn)的頻繁移動(dòng)，路由的不斷改變而變大。AODV的分組遞交率隨停頓時(shí)間的增加呈增大趨勢(shì)，DSR分組遞交率也隨停頓時(shí)間的增加而增大.且固定20節(jié)點(diǎn)模型與移動(dòng)20節(jié)點(diǎn)模型的平均每路由發(fā)現(xiàn)時(shí)間，由于動(dòng)態(tài)源路由協(xié)議的路由機(jī)制，在網(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的路由開(kāi)銷隨停頓時(shí)間的增加呈減小趨勢(shì)，而DSR的路由開(kāi)銷在停頓時(shí)間不斷增加的情況下則基本不變。

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

四、結(jié)論

本文介紹了兩種典型Adhoc網(wǎng)絡(luò)路由協(xié)議AODV和DSR，并通過(guò)OPNET Modeler在同樣的場(chǎng)景對(duì)這兩個(gè)路由協(xié)議進(jìn)行仿真，并根據(jù)實(shí)驗(yàn)數(shù)據(jù)來(lái)計(jì)算路由協(xié)議的性能指標(biāo)：平均端到端延遲性能參數(shù)和數(shù)據(jù)包的成功傳輸率，繪制出相應(yīng)的圖進(jìn)行比較。在實(shí)驗(yàn)中仿真場(chǎ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)性強(qiáng)的路由協(xié)議。

參考文獻(xiàn)：

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

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

篇4

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

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

對(duì)于HTTP 2.0的競(jìng)爭(zhēng)提案

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

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

國(guó)家安全局的后門

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

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

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

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

修補(bǔ)SSL、TLS中的安全漏洞

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

去除性能缺陷

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

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

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

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

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

篇5

要

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

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

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

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

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

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

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

HTTP TCP/IP URL

目

錄 IV

1

緒

論 1

2

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

略……

3

MFC 編程 4

略……

4

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

略……

5

需求分析和可行性研究 12

略……

6

總體設(shè)計(jì) 14

略……

7

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

略……

8

結(jié)

論 37

參考文獻(xiàn) 39

附件1

英文翻譯原文（英文） 40

附件2

英文翻譯中文 45

：13000多字

有中英文摘要、目錄、參考文獻(xiàn)、程序包及運(yùn)行文件

300元

另：有2100字的外文文獻(xiàn)及3300的中文翻譯

篇6

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

 

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

1.引言

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

 

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

 

2.HttpClient簡(jiǎn)介

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

 

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

3.1 工作原理

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

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

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

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

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

3.3 手機(jī)客戶端的開(kāi)發(fā)

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

 

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

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

（3）使用execute方法發(fā)送HTTP GET（HTTP POST）請(qǐng)求，并返回HttpResponse對(duì)象，通過(guò)利用getStatusCode獲取返回碼以判斷請(qǐng)求是否發(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é)束語(yǔ)

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

 

參考文獻(xiàn)

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

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

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

篇7

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

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

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

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

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

1 SDK架構(gòu)

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

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

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

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

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

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

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

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

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

篇8

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

若用戶想要在電腦桌面添加天氣小工具，在電腦桌面空白處右鍵單擊后點(diǎn)擊小工具選項(xiàng)，打開(kāi)后就可以看到天氣小工具了，點(diǎn)擊就可以選擇添加了。

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

篇9

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

中圖分類號(hào)：TP393文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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)上海量信息的主要途徑。然而隨著信息時(shí)代的發(fā)展，人們開(kāi)始對(duì)Web應(yīng)用提出了實(shí)時(shí)性要求，希望這些信息更新后能夠立即獲取到。對(duì)這項(xiàng)需求，多種實(shí)時(shí)Web應(yīng)用解決方案被提出，其中較為成功并廣泛應(yīng)用的包括：基于Ajax的長(zhǎng)輪詢以及基于Iframe的流方式?；谶@些解決方案，互聯(lián)網(wǎng)上涌現(xiàn)出了一系列實(shí)時(shí)應(yīng)用，如在線游戲、在線證券、設(shè)備監(jiān)控、RSS閱讀推送、郵件提示等等。

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

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

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

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

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

1.1基于Ajax的長(zhǎng)輪詢方式和基于Iframe的流方式

篇10

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

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

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

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

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

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

為何跨協(xié)議下載文件更加流暢且成功率高呢?這都是因?yàn)槭褂昧硕鄠€(gè)下載源(包括不同協(xié)議的下載源)的緣故。使用支持跨協(xié)議下載的工具軟件下載時(shí)，軟件會(huì)自動(dòng)進(jìn)行以下工作：

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

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