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

篇1

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

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

1 HTTP協(xié)議

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第七，TCP連接釋放。

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

如果在以上過程中的某一步出現(xiàn)錯誤，那么產(chǎn)生錯誤的信息將返回到客戶端，由顯示屏輸出。對于用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。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上采用客戶/服務器模型，包括兩個組成部分，分別為FTP服務器、FTP客戶端。其中FTP服務器用來存儲文件，用戶可以使用FTP客戶端通過FTP協(xié)議訪問位于服務器上的資源。FTP使用20和21這兩個端口，如果采用主動模式，那么數(shù)據(jù)傳輸端口就是20；如果采用被動模式，數(shù)據(jù)傳輸端口就是21。

FTP提供以下功能：

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

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

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

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

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

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

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

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

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

參考文獻：

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

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

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

篇2

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

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

需求分析

3.1用戶需求分析

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

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

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

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

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

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

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

3.2 業(yè)務流分析

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

4. 系統(tǒng)設計

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

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

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

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

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

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

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

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

篇3

關鍵詞：Adhoc網(wǎng)絡；AODV；DSR

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

一、前言

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

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

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

（一）OPNET Modeler仿真建模原理

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

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

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

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

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

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

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

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

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

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

四、結(jié)論

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

參考文獻：

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

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

篇4

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

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

對于HTTP 2.0的競爭提案

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

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

國家安全局的后門

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

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

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

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

修補SSL、TLS中的安全漏洞

當前，SSL、TLS的數(shù)據(jù)包有可能被截取和操縱，黑客可以對SSL、TLS通信進行有效的攻擊。通信過程中的每一個數(shù)據(jù)包中包含起核心作用的消息認證碼（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值，黑客很難有所作為。當然，仍然無法確定這些方法是否已經(jīng)足以防止情報機構(gòu)的嗅探，但是這起碼修補了已知的安全漏洞。而對于互聯(lián)網(wǎng)工程任務組來說，HTTP 2.0是否應該完全采用加密的形式，這一最具爭議的話題仍然會再出現(xiàn)在議程上。

去除性能缺陷

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

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

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

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

而HTTP 2.0中很多工作不再需要TCP協(xié)議來承擔，或者更確切地說，HTTP 2.0將接管這些任務，例如數(shù)據(jù)幀的優(yōu)先級設定將確定數(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建立的是服務器與瀏覽器之間相互通信的數(shù)據(jù)流。從長遠來看，Google并不打算取代TCP，而是希望將QUIC融入到TCP中。我們可以預期從HTTP 1.1到HTTP 2.0的切換是非常順利的，用戶需要做的只是更新瀏覽器以支持HTTP 2.0，在瀏覽器支持HTTP 2.0的情況下將自動向服務器發(fā)出請求，并開啟一個煥然一新的互聯(lián)網(wǎng)。

篇5

要

萬維網(wǎng)WWW(World Wide web)并非某種特殊的計算機網(wǎng)絡。萬維網(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是一個應用層協(xié)議，它使用TCP的80端口連接進行可靠的傳送。TCP/IP是用于網(wǎng)絡的一組通信協(xié)議，包括TCP（Transmission Control Protocol）協(xié)議和IP（Internet Protocol）協(xié)議。

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

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

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

關鍵詞：萬維網(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

總體設計 14

略……

7

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

略……

8

結(jié)

論 37

參考文獻 39

附件1

英文翻譯原文（英文） 40

附件2

英文翻譯中文 45

：13000多字

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

300元

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

篇6

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

 

【關鍵詞】Android；HttpClient；MySQL；JSP

1.引言

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

 

當下比較流行的數(shù)據(jù)傳輸方式主要有XML和JSON兩種方式，由于HTTP協(xié)議是從WWW服務器傳輸超文本到本地瀏覽器的傳送協(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é)議、支持服務器等。[3]

 

3.HttpClient在Android中的應用

3.1 工作原理

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

（2）服務器接收客戶端請求，并將響應信息返回客戶端；

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

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

服務器端采用JSP技術，通過利用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）生成響應的請求信息；

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

 

（4）解析返回信息。

關鍵代碼如下：

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

 

參考文獻

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

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

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

篇7

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

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

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

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

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

1 SDK架構(gòu)

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

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

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

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

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

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

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

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

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

篇8

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

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

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

篇9

關鍵詞:服務器推送技術；實時Web應用；HTML5；WebSocket協(xié)議；HTTP協(xié)議

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

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

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

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

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

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

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

篇10

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

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

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

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

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

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

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

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

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