前言：中文期刊網精心挑選了http協議范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。

http協議范文1

程序實現過程：

1.分析鏈接關系（限于篇幅，這里只介紹對錨標記〈a〉的分析）。

在html中〈a〉標記的基本語法為：〈a href=″...″ name=″...″ target=″...″〉。其中參數href的值就是欲獲取的url值。

2.下載。

在http協議中常用的請求方法有兩種：get和post。本實現使用get方法。最簡化的get請求包如下：

get /index.htm http/1.1

“/index.htm”表示客戶端欲下載的文件路徑；“http/1.1”表示協議版本。

程序生成get請求包，在成功連接對應web服務器的80或其它端口后，使用基于tcp協議的同步模式套接字發送請求包并等待返回信息。

服務器將返回一個應答包，大致如下：

http/1.0 200 ok

...

[數據...]

第一行是應答信息。如果成功，服務器將返回“http/1.0 200 ok”。

第三行是一個空行，用以分隔http包頭和包體(數據)。

第四行開始就是以字節流的方式返回的數據。

如果使用http，則與上述有兩點不同。

第一， 連接時應連接服務器，而不是連接web服務器。

第二，在生成請求包時，下載文件的url必須寫全url。對上例而言，請求應為“get netsport/index.htm http/1.1”，而不是“get /index.htm http/1.1”。

具體程序和類(程序使用delphi3.0編制)：

1.初始化winsock。

procedure tform1.formcreate(sender: tobject);

var

wversionrequired: word;

wsdata: twsadata;

begin

ismultithread:=true;

//置″支持多線程″為″真″

wversionrequired:=makeword(2，0);

case wsastartup(wversionrequired，wsdata) of //初始化winsock

wsasysnotready :

application.messagebox(′網絡系統未準備′，′信息′，mb_ok);

wsavernotsupported :

application.messagebox(′未提供網絡接口′，′信息′，mb_ok);

wsaeinval :

application.messagebox(′網絡版本不被支持′，′信息′，mb_ok);

end;

end;

2.文件下載線程。

tdownfilethread = class(tthread)

private

fileurl:string;

//記錄文件的url

protected

procedure execute; override;

public constructor create(url:string);

end;

constructor tdownfilethread.create(url:string);

begin

fileurl:=url;

freeonterminate:=true;

inherited create(false);

end;

procedure tdownfilethread.execute;

var

mysocket:tsocket; myclient:tsockaddr;

recvbuf:array [0..332] of char; mycmdstr:string;

ptemp:pchar;

myhandle，index_ch，reccount，i:integer;

begin //創建本地socket

mysocket:=socket(af_inet，sock_stream，0);

if (mysocket=socket_error) then begin

application.messagebox(′初始化失敗！′，′信息′，mb_ok);

exit;

end; //生成連接主機的結構

myclient.sin_family:=af_inet;

myclient.sin_port:=htons(connectedport);

// connectedport：全局變量，記錄連接端口號

strpcopy(recvbuf，getserverip(fileurl));

// getserverip(fileurl)：返回服務器的ip

myclient.sin_addr.s_addr:=inet_addr(recvbuf); //連接服務器

if (connect(mysocket，myclient，sizeof(myclient))〈〉0) then begin

closesocket(mysocket);

exit;

end; //發請求

if (q_useproxy=0) then

mycmdstr:=′get ′＋extracturlpath(fileurl)＋′ http/1.1′

//extracturlpath(fileurl)返回相對url

else mycmdstr:=′get ′＋fileurl＋′ http/1.1′;//使用寫全url

strpcopy(recvbuf，mycmdstr);

i:=length(mycmdstr);

recvbuf[i]:=＃13; inc(i); recvbuf[i]:=＃10; inc(i);

recvbuf[i]:=＃13; inc(i); recvbuf[i]:=＃10; inc(i);

recvbuf[i]:=＃0;

send(mysocket，recvbuf，i，0);

//發送請求讀返回數據

reccount:=recv(mysocket，recvbuf，sizeof(recvbuf)－1，0); //判斷是否成功

i:=0;

while i〈10 do begin

i:=i＋1;

// ′http/1.0 200 ok′是成功標志

if ((recvbuf[i]=′ ′) and (recvbuf[i＋1]=′2′) and (recvbuf[i＋2]=′0′)

and (recvbuf[i＋3]=′0′) and (recvbuf[i＋4]=′ ′)) then i:=200;

end;

if i〈〉200 then begin closesocket(mysocket); exit; end;

//得到數據起始位置

ptemp:=strpos(recvbuf，＃13＋＃10＋＃13＋＃10)＋4;

index_ch:=ptemp－recvbuf;

//建立下載目錄

try forcedirectories(extractfilepath(getfillocalpath(fileurl)));

except

end; //創建文件

deletefile(getfillocalpath(fileurl));

myhandle:=filecreate(getfillocalpath(fileurl)); //如果未接收完則繼續

while (reccount〈〉0) do

begin

filewrite(myhandle，recvbuf[index_ch] ，reccount－(index_ch));

index_ch:=0;

reccount:=recv(mysocket，recvbuf，sizeof(recvbuf)－1，0);

end; //關閉文件句柄和套接字

fileclose(myhandle);

http協議范文2

關鍵詞：Photoshop；選區；教學方法

中圖分類號：G642 文獻標識碼：A 文章編號：1009-3044（2015）22-0087-02

隨著多媒體在教育培訓領域、電子出版領域、娛樂領域、咨詢服務領域、多媒體網絡通信領域等領域的全面應用，作為圖形、圖像的主要處理軟件Photoshop被廣泛使用。各大高校也相繼開設了《Photoshop》這門課程。《Photoshop》是一門操作、性實踐性都十分強的學科。學習內容豐富，涉及到的基本概念、知識點也偏多，基本工具十分豐富。在教學過程中讓學生掌握基本操作，模仿書本做出一些圖例只是 Photoshop 的初級教學目標，而更高層次的教學目標是充分調動學生的學習積極性，發揮學生的主動性和想象力，讓他們根據已掌握的知識、技能創造性地設計出有創意的作品，培養他們的實踐能力和終身學習思想。但對于沒有接觸過圖像處理軟件的學生來說，要在短時間內熟練掌握并靈活運用軟件并不容易。因此要使學生學好這門課，不但要從軟件使用的角度來考慮教學，更要從學生易于掌握、靈活使用的角度來考慮如何教好這門課程，特別要考慮如何激發學生濃厚的學習興趣，培養學生的創造力、想象力及美感等綜合素質[1]。結合自己的教學經驗，對教學中遇到的一些問題提出自己的一點想法跟大家探討。

1 Photoshop中橢圓選區或圓選區的選擇

如圖1所示圖片，我們如何使用橢圓選框工具選取杯子的杯口橢圓。要畫出一個跟杯口一樣大的橢圓幾乎要嘗試很多次，有沒快速準確的方法一次畫成呢？這就是要讓同學思考的問題，通過任務驅動學生積極思考。提示學生使用參考線和橢圓公式。經過一段時間的思考絕大部分同學是沒有找出答案的。然后開始再開始講解，學生勢必認真聽講。

第五部，視圖菜單下，清除參考線。

通過實例探討、思考、講解，鍛煉了學生獨立思考的能力。

2 photoshop中圖像下的調整與圖層下的調整圖層的區別

在對講解調整圖像的色彩時，講解了圖像菜單下的調整下的各個菜單命令，在對圖層講解時，圖層下有新建調整圖層，在該菜單下的命令選項與圖像菜單下的調整下的各個菜單命令相同。同一個圖像我們使用上面2種操作都能得到一樣的效果。兩種操作有什么區別？這個問題拋給同學，讓他們進行討論。通常調整圖層的講解是在圖像調整的后面，通過這個問題可以讓同學對圖像調整進行復習，也加上了對調整圖層的影響。使用圖像調整是直接在圖像的圖層上對圖像進行修改調整，原始圖像的信息不被保留，這種操作只有一個圖層如圖4。使用調整圖層調整時所用的調整信息都在調整圖層上，原圖像的信息沒有被改變，需要還原圖像，只需要刪除調整圖層或隱藏調整圖層即可，如圖5所示。

3 在教學工程中給出實例操作的詳細步驟

要快速掌握photoshop的使用技巧，需要通過大量的實踐操作練習，如果每個例子都讓同學自己看書操作，一定會花費很多時間。給出詳細的操作步驟很有必要。例如：實際操作講解；半身照照片背景顏色替換：

S1：文件->打開->第一講/證件照.jpg；

S2： 鼠標右擊背景圖層->復制背景圖層；

S3：選擇復制的背景圖層->圖像->調整->顏色替換；對話框中，顏色容差調整為200，替換顏色選取藍色；

S4：選擇副本->添加矢量蒙版->前景色和背景色進行替換->前景色為黑色；

S5：調整畫筆大小->對不需要遮擋部分；

S6：調整副本亮度為24，對比度為6。

把學習的重點放在具體實例的制作過程上，命令的使用盡量不單獨講解和單獨練習，而是把要學習的命令融入到一個個生動的具體案例中，既講理論，又講實踐，深入淺出，通俗易懂，可增強對教學內容的理解與記憶，還可使學生形成科學的思維模式。實例教學法可通過典型例子，將學生帶入特定事件使學生在獨立思考或集體協作的狀態下，進一步提高其識別、分析和解決某一具體問題的能力，進而培養學生的自主學習能力、溝通能力、職業能力和協作精神，提高學生的綜合素質[2]。

4 結束語

Photoshop圖像處理是一門很生動有趣的課程，學生的學習積極性很高；只要通過正確的教學方法，一定能引導學生把這門課程給學習好。

參考文獻：

http協議范文3

關鍵詞：DHCP服務器；網絡參數；Packet Tracer

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2014）22-5178-02

DHCP（Dynamic Host Configuration Protocol）是基于客戶機/服務器模式，用來為網絡客戶機提供動態網絡參數配置的協議[1]。其中DHCP服務器需要負責地址池及相關IP信息的申請和分配管理，要求能夠響應網絡主機的配置請求，并返回網絡ID、子網掩碼、默認網關、DNS服務器等網絡參數給客戶機，在DHCP協議實現中有著重要的作用。DHCP服務器既可以使用專用的服務器，也可以由路由器來完成相關的IP地址分配。文章中探討的是如何使用路由器來完成DHCP服務器的功能，以及跨網段時相關路由器的設置，并在Packet Tracer環境下完成了相應配置的仿真實現。

1 網絡需求分析

實驗要求對于兩臺路由器所連接的六個子網進行連接，并要求在路由器上進行DHCP服務器的配置，來滿足各子網中主機對于IP地址的動態請求。根據設計要求，設計了如圖1所示的網絡拓撲結構。

其中路由器1與路由器2分屬于172.16.0.0/24和192.168.1.0/24網絡，每個網絡又劃分出三個虛擬局域網（VLAN）[2]，共六個子網：Vlan15、Vlan25、Vlan35、Vlan10、Vlan20、Vlan30。根據實際網絡容量需求，可以在路由器上使用應用802.1q協議的單臂路由[3]，并采用VLSM[4]技術來劃分子網。各子網相關配置要求如表1所示：

2 配置實現

作為Cisco公司的一款網絡學習軟件，Packet Tracer能夠有效地模擬網絡運行環境，進行相關的網絡設計、配置及故障排查等，尤其為路由器和交換機的學習提供了優秀的平臺。在設計中選擇路由器2作為DHCP服務器，在路由器1上設置“路由助手”，來滿足各子網的IP地址請求。

在路由器2上，對于各子網的有效地址池（包括保留地址）、默認網關、DNS服務器累進行配置。以Vlan10的配置為例，可以在路由器的全局配置模式下，使用如下命令實現：

為了能夠對于非直連網絡內的主機進行IP地址請求響應，除了要保證網絡的通暢連接之外，需要在作為網關的路由器1上設置“路由助手”，其IP helper address指向相連的路由器2（DHCP服務器）。

路由器1采用802.1q協議，對于Vlan15的相關配置如下：

3 測試

在各主機可以進行測試，如選擇屬于Vlan15的PC7，在命令提示符下使用“ipconfig /all”命令，可以查看當前通過DHCP得到的相關網絡信息：

PC1和PC7都成功使用DHCP，自動完成了相關網絡信息的配置。

在PC1中，使用“ping”命令進行與PC7的連接測試，得到如下響應：

4 小結

本次測試在Packet Tracer環境下，順利實現了DHCP協議的配置，完成了不同網絡中主機對于IP地址及相關網絡參數的自動分配，進行了作為DHCP服務器的路由器及相關路由器的設置，對于網絡設計的測試、網絡架構的模擬實現以及DHCP在教學與研究中的應用都可以提供很好的借鑒。

參考文獻：

[1] Droms， R..Dynamic Host Configuration Protocol[J]. RFC 2131， March 1997.

[2] McPherson， D. and B. Dykes.VLAN Aggregation for Efficient IP Address Allocation[J] .RFC 3069， February 2001.

http協議范文4

關鍵詞：HTTP；HTTP協議；服務器

中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2012)02-0282-03

1 HTTP協議介紹

1.1 HTTP協議

HTTP（超文本傳輸協議）是一個基于請求與響應模式的、無狀態的、應用層的協議，常基于TCP的連接方式。絕大多數的Web開發，都是構建在HTTP協議之上的Web應用。本程序實現的是一個輕量級的web服務器。【1】

1.2 HTTP組成

HTTP請求由三部分組成，分別是：請求行、消息報頭、請求正文。

1)請求行以一個方法符號開頭，以空格分開，后面跟著請求的URI和協議的版本，格式如下：Method Request-URI HTTP-Version CRLF。其中Method表示請求方法；Request-URI是一個統一資源標識符；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字符）。

2）HTTP響應由三個部分組成，分別是：狀態行、消息報頭、響應正文。

狀態行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF，其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述。狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種

可能取值：【2】

1xx：指示信息--表示請求已接收，繼續處理。

2xx：成功--表示請求已被成功接收、理解、接受。

3xx：重定向--要完成請求必須進行更進一步的操作。

4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。

5xx：服務器端錯誤--服務器未能實現合法的請求。

常見狀態代碼、狀態描述、說明：

200 OK//客戶端請求成功

400 Bad Request//客戶端請求有語法錯誤，不能被服務器所理解

401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用

403 Forbidden//服務器收到請求，但是拒絕提供服務

404 Not Found//請求資源不存在，eg：輸入了錯誤的URL

500 Internal Server Error //服務器發生不可預期的錯誤

503 Server Unavailable//服務器當前不能處理客戶端的請求，一段時間后，可能恢復正常

HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對于請求消息，開始行就是請求行，對于響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。

3）請求正文。

2 HTTPSVR程序功能

2.1工作原理

建立在請求/響應模式(Request/Response)上：一個客戶端與服務器建立連接后，客戶端向Web服務器發出一個HTTP請求行；Web服務器在收到有效的請求后，返回一個狀態行或多個響應標題、一個空白行和相關文檔。HTTP協議使用的端口號，通常為80。

2.2工作流程圖

HTTPSVR的信息交換過程，它分四個過程：建立連接、發送請求信息、獲取服務器響應狀態、關閉連接。其中較為復雜的過程是:發送請求信息、獲取服務器響應狀態。【3】如圖1所示：

圖1工作流程圖

1）建立連接：連接的建立是通過申請套接字(Socket)實現的。客戶打開一個套接字并把它約束在一個端口上，如果成功，就相當于建立了一個虛擬文件。以后就可以在該虛擬文件上寫數據并通過網絡向外傳送。

2）發送請求：打開一個連接后，客戶機把請求消息送到服務器的停留端口上，完成提出請求動作。

3）發送響應：服務器在處理完客戶的請求之后，要向客戶機發送響應消息。

4）關閉連接：客戶和服務器雙方都可以通過關閉套接字來結束TCP/IP對話。

3 HTTPSVR程序分析

基于HTTPSVR所用到的類進行分析：

1）CGenPage類(genpage.h/.cpp):這是通用設置的屬性對話框，是UI的一部分，設置屬性中的一般屬性，其中包括：服務器視圖界面的列表顯示、訪問日志、圖標顯示三個屬性。

2）CHitDoc類(http.h/.cpp):這是http響應類，處理客戶端請求的URL地址，并且進行本地地址轉化，指向服務器資源目錄。

3）CHitDoc(httpDoc.h/.cpp):這是mfc的doc視圖主類。

4）CHttpSvrApp(httpsvr.h/.cpp):這是處理web服務器的初始化，包括訪問目錄、登錄日志、HTTP端口的設置、文件的保存等。

5）CHttpSvrView(httpview.h/.cpp)：這是UI中的日志列表控件，主要是客戶登錄服務器的訪問的記錄和錯誤記錄的顯示，包括文件的路徑，用戶登錄時間，用戶訪問次數等。

6）CListenSocket(listen.h/.cpp)：這是監聽套接字的拓展類，用于創建服務器在端口（默認80端口）上的監聽套接字。

7）CNamePage(namepage.h/.cpp)：這是一般屬性中的Server Name屬性頁，是UI的一部分，其中包括服務器名稱的設置和端口的設置，而服務器名稱有默認和指定的兩種情況。

8）CNoRootDlg(NoRoot.h/.cpp)：這是服務器地址屬性設置對話框，是UI的一部分。在此部分中，如果URL不存在則會彈出此對話框，讓我們輸入正確的URL地址。

9）CRequestSocket(reqsock.h/.cpp)：這是服務器的主要功能實現部分，包括接受、發送數據，并且支持cgi的動態生成頁面，詳細的功能有：接收請求，對http請求報文進行解析，根據請求內容構造響應報文。

10）CRequest(Request.h/.cpp)：實現保存上一次web請求的內容。

11）CRootPage(RootPage.h/.cpp)：這是一般屬性中Root Dir對話框，是UI的一部分。在此部分我們可以對服務器的資源根目錄進行設置，同時也可以重置為默認的根目錄G：\WebPages。

12）CasyncSocket(AsyncSock.h /.cpp):這是異步非阻塞類，它的Create()函數，除了創建了一個SOCKET以外，使用WSAAsyncSe? lect()將這個SOCKET與該窗口對象關聯，以讓該窗口對象處理來自Socket的事件(消息)，然而CSocketWnd收到Socket事件之后，只是簡單地回調CAsyncSocket::OnReceive() CAsyncSocket::OnSend()，CAsyncSocket::OnAccept()，CAsyncSocket::OnConnect()等虛函數。所以CAsyncSocket的派生類，只需要在這些虛函數里添加發送和接收的代碼。

使用CAsyncSocket時，如果使用Create缺省創建socket，則所有網絡I/O都是異步操作，進行有關網絡數據傳輸時需要用到以下函數：OnAccept、OnClose、OnConnect、OnOutOfBandData、OnReceive、OnSend。【4】

4 HTTPSRV服務器程序分析流程

4.1執行函數

服務器程序分析首先在MFC中的文件APPMODULE.CPP的_tWinMain函數處開始執行，執行該文件的return AfxWinMain函數。

4.2客戶端鏈接服務器

在服務器程序中由AfxWinMain函數負責建立工作線程pWinThread，此線程對HttpSvr進行初始化工作，接著調用HttpSvr.cpp文件中的BOOL CHttpSvrApp::InitInstance方法對WEB服務器進行初始化，然后運行線程的主函數，最后在THRDCORE.CPP文件中運行int CWinThread::Run函數，開始HTTP服務器的循環。在循環中，首先通過CListenSocket::OnAccept( int nErrorCode )函數生成CRe? questSocket類，將其設置用于監聽8080端口。監聽到連接請求時，Accept函數創建新的套接字pRequest并返回句柄，AsyncSelect函數監聽8080端口的FD_READ和FD_CLOSE兩個事件，當傳入FD_READ事件時，準備接收，并且觸發OnReceive()函數，如果傳入FD_WRITE事件，發送數據的時候，OnSend()函數就會觸發。設置端口為8080，將web服務文件夾地址Root Dir指向root所在地址。此時顯示結果如圖2所示。

圖2鏈接服務器

4.3請求客戶

一旦有數據到達時，執行ReqSock.cpp中的void CRequestSocket::OnReceive(int nErrorCode)函數。程序代碼將傳輸控制層上傳的數據包存放在請求和應答報文的緩沖區m_buf中。

接下來在ReqSock.cpp文件中，根據響應狀態m_reqStatus的不同，使用swich語句對接收到的數據包進行不同的響應處理。當瀏覽窗口發送第一個數據包時，響應狀態m_reqStatus被設置為REQ_REQUEST，之后，對請求數據包的每一行進行處理，根據http的協議使用ProcessLine方法對m_pRequest進行初始化，完成以上操作之后，當請求狀態m_reqStatus == REQ_DONE，調用判斷StartRe? sponse方法來構造應答報文，運行AsyncSelect( FD_WRITE | FD_CLOSE )函數，之后其調用void CRequestSocket::OnSend(int nError? Code)方法將緩存m_buf的應答報文發送給客戶端。【5】

5結論

該文通過對基于HTTP協議服務器程序以及瀏覽器與服務器的交互過程的分析，熟悉了HTTP協議的服務工作流程，對運用Winsock編程來逐步解析HTTP協議的服務器程序的核心部分有更深層次的了解。在本程序中是通過多線程與異步操作的理論的方法來實現多個客戶端同時訪問的處理，同時熟悉了多線程的創建過程以及異步操作理論，了解了各個線程間是如何協作的。

不足的是，本實例程序實現的只是一個輕量級的服務器，它的分析過程相對比較簡單。但是只要熟悉了基于HTTP協議服務器創建的基本原理，將來就能在此基礎上實現功能更加強大的服務器。

參考文獻：

[1]葉強.超文本傳輸協議-HTTP/1.0[J].科技情報開發與經濟,2004(8):66-68.

[2] Fielding R, Gettys J, Mogul J, Frystyk H. RFC 2068 Hypertext Transfer Protocol-HTTP/1.1. MIT/LCS, UC Irvine,1997(1):37-38.

[3]蔡皖東. HTTP協議的傳輸機制與超文本鏈的研究[J].微電子學與計算機,1997(4):53-55.

http協議范文5

引言

控制網絡一般指以控制“事物對象”為特征的計算機網絡系統，簡稱Infranet(infrastructure network)，它處在企業網（Intranet）的底層，構成了整個企業網的基礎。近些年來，在控制網絡中采用了現場總線（Field Bus）和工業以太網（Ethernet）兩種技術。出現這種情況主要有兩個原因：第一，目前存在多種現場總線標準，不同的標準采用完全不同的通信協議，也就是說現場總線的開放性不夠；第二，以太網雖然能夠解決開放性的問題，并具備成本低廉、技術成熟等優點，但由于以太網最初是被設計用于以資源共享為目的的計算機局域網，因此在實時性和可靠性上暫時還不能完全滿足工業控制的要求。事實上，目前一個較大規模的控制網絡往往綜合采用了這兩種技術。在現場層，由于強調實時性、可靠性和安全性，常采用現場總線技術；在監控管理層，考慮到采用不同標準的控制網段之間的集成以及與高層企業信息網絡的集成，一般采用以太網技術。現場層的現場總線控制系統FCS（Field Control System）或其它設備級輕質網絡通過網關或嵌入式HTTP服務器與高層以太網相連。這樣，不僅采用不同協議的控制網段能夠實現互聯，而且各個控制網段能方便地與高層企業信息網互通，從而最終實現企業網的管控一體化和對現場設備的Internet遠程監控。通過以上分析可以看出，控制網絡中的網關或嵌入式HTTP服務器起著連接現場層和監迭管理層的作用，因此它是整個控制網絡的關鍵設備。

網關或嵌入式HTTP服務器與傳統的嵌入式系統相比，有一些不同的特性。傳統的嵌入式系統是面向應用、有一些不同的特性。傳統的嵌入式系統是面向應用、面向產品的，強調成本和高效設計系統，因此本質上不具備通用性和可移植性。網關或嵌入式HTTP服務器由于處在現場層和監控管理層的中間，因此它與具體應用和產品是一種弱耦合的關系。同時，技術發展的趨勢是：硬件成本越來越低，功能越來越強，越來越多的芯片和板卡具備“平臺”的特點，適用于多種應用場合。嵌入式實時操作系統（Embedded Real Time Operationg System）的發展更是為嵌入式軟件提供了一個通用的軟件平臺。綜上所述，在網關或嵌入式HTTP服務器設計中，考慮通過選用適合的硬件和嵌入式實時操作系統，使整個系統具備相當的通用性和可移植性。對于連接不同的設備級輕質網絡或不同的應用，只需要通過更換硬件模塊和對代碼作最小的修改即可實現。

1 基于Linux的嵌入式HTTP服務器的結構

為了實現設計目標，嵌入式HTTP服務器一般應采用功能較強的能用PC、工業PC、或高檔MPU作為硬件平臺，嵌入式實時操作系統作為軟件平臺進行平發。硬件平臺應具備以太網口和一個或多個通信模塊，比如RS232、RS485、CAN通信卡等。嵌入式實時操作系統實現了TCP/IP等網絡協議，并提供實時任務、進程管理、內存管理、文件系統、API等功能。

Linux操作系統是一種多進程，多用戶的通用操作。由于它具備免費、源碼公開、內核可裁減、支持多線程、網絡功能強大、設計精巧、性能穩定的特點，因此近年它也被廣泛用到嵌入式系統的設計中。一個應用于嵌入式系統的Linux經過裁減和重新編譯后只包括進程管理、內存管理、文件系統、若干個驅動程序和實用的函數等。

下面以本人參與的轉子秤控制系統為例來說明一個基于Linux的嵌入式HTTP服務器的結構。轉子秤是水泥工業中的關鍵計量喂料設備，一條大型的生產線需要許多臺轉子秤，對轉子秤的控制涉及到重量、轉速、溫度、一氧化碳含量等若干個參量。由于現場環境的高噪聲、高粉塵、高電磁干擾，無法在現場配備鍵盤、顯示器、觸摸屏等人機交互設備，無法在現場實現對設備的監控和維護。同時，一條生產線有多臺轉子秤，為每臺轉子秤配備人機交互設備也是不經濟的。為此，考慮為整個系統設計一個嵌入式HTTP服務器，各轉子秤控制器與嵌入式HTTP服務器用CAN總線相連。通過嵌入式HTTP服務器實現對整個系統的在線監控和遠程監控。在嵌入式HTTP服務器的設計中，選用研祥公司PC104總線的486X嵌入式CPU卡作為硬件平臺，該板卡是具有128MB的在板ROM、CF卡接口和以太網接口等。選擇該板卡的原因是PC104總線的功能擴展模塊非常豐富，通過選擇不同的模塊很容易就支持多種總線。軟件平臺方面，選用Linux2.0內核并對它作適當裁減。整個嵌入式HTTP服務器的結構簡圖如圖1所示。

2 基于Linux的嵌入式HTTP服務器的設計

工控領域的嵌入式HTTP服務器應該具備如下基本功能。

①實時數據。實時數據主要包括系統運行過程中設備的各種狀態信息。嵌入式HTTP服務器將實時數據以網頁形式到Internet上，且動態實時刷新。客戶可以通過瀏覽器訪問這些實時信息。

②參數設置。參數包括運行參數和設備狀態參數，如各種初始值、常數等。嵌入式HTTP服務器接收到客戶提交的參數設備請求后，執行參數寫入操作。

③遠程實時控制。遠程實時控制允許遠程用戶在線地控制系統中的相應執行機構，比如電機、電磁閥等。嵌入式HTTP服務器接收到遠方客戶提交的控制操作請求后，將下發控制命令驅動監控系統中相應的執行機構。

④訪問級別設置和權限認證。只有權限不低于要求訪問級別的客戶，經嵌入式HTTP服務器認證后，方可進行其權限范圍內的監控操作。

3 主要實現技術

3.1 超文本傳輸協議

HTTP協議是一個面向事務、無狀態的應用層協議。在傳輸層，HTTP協議使用請求（request）/響應（response）模型。一次簡單的HTTP事務包括以下過程。首先，客戶（瀏覽器）發起和建立一條到服務器的TCP連接。然后，客戶發送一個HTTP請求到服務器，請求包含方法、URI、協議版本和一個類MIME報文。服務器解析HTTP請求后，給出相應的HTTP響應，響應包括協議版本、狀態碼、解釋狀態碼的簡短短語和一個類MIME報文。最后，釋放TCP連接。Linux操作系統為用戶提供了稱為BSD Socket的網絡編程接口。利用其中的TCP套接口函數，可以非常方便地實現HTTP協議。

HTTP1.0為每一次HTTP請求/響應建立一條新的TCP連接，由于建立一條TCP連接要經歷3次握手，因此效率不高。HTTP1.1提出了可持續性連接的概念。HTTP1.1只建立一次TCP連接，而重復地使用它傳送一條素的請求/響應消息，減少了額外開銷。在嵌入式HTTP服務器中，一般使用HTTP1.1協議。HTTP1.1協議的細節請參考RFC2616。

3.2 通用網關接口CGI

參數設置和遠程控制功能都是通過CGI（通用網關接口）程序和表單實現的。CGI使用HTML表單向Web服務器發送信息。基本語法如下：

<FORM METHOD=get/post ACTION=URL></FORM>

其中，METHOD屬性指定將數據傳送到Web服務器的方法。輸入方法有兩種：GET和POST。ACTION屬性定義要對表單數據進行處理的CGI腳本的URL。

CGI的工作流程是首先由瀏覽器將用戶輸入的數據傳遞給Web服務器，Web服務器根據接收到的數據設置環境變量并啟動CGI腳本，CGI腳本從環境變量中讀取所需要的數據并進行相應處理，最后使用STDOUT輸出HTML形式的結果文件，經Web服務器送回瀏覽器，最終顯示給用戶。傳統的CGI程序與服務器代碼分開，是一個符號CGI標準的可執行文件，并儲存在CF卡等存儲設備上，一般用腳本語言編寫。考慮到嵌入式HTTP服務器要求速度快，功能和代碼都盡可能精簡的特點，可以把原先由可執行文件完成的功能用C函數實現，放在服務器代碼內部，并直接從HTTP請求報文接收數據。與傳統CGI程序相比，這種方法具備如下特點：

*不需要標準輸入，CGI函數可以直接獲取到瀏覽器送來的信息；

*不需要標準輸出，CGI函數可以直接將數據送回給瀏覽器；

*不需要環境變量，CGI和Web服務器在同一程序中實現，不需要環境變量來交換信息。

3.3 自定義標記

要在網頁中顯示工控系統中大量的實時數據，常規方法是將HTML代碼直接集成到程序代碼中，或者反之將C程序代碼集成到HTML標記語言中。這兩種方法均要求開發人員對HTML標記語言的語法細節非常熟悉。網頁或程序結構的單方面調整都將導致整個系統全盤修改，系統不具備靈活性與可擴展性。HTML的精髓在于該語言的“標記”性，各種不同標記的具體含義是由服務器和瀏覽器進行解析。因此，當現有標記不能滿足新的應用需求時，可以自行定義新的標記，只需服務器將自定義標記解析為標準標記，然后傳送給瀏覽器即可。在本項目中，主要的實時數據轉速、重量、一氧化碳含量等狀態信息，可以定義相應的標記。服務器中解析相應標記的函數同樣用C語言來實現。運行時，當客戶端發出查看某實時網頁的請求后，嵌入式HTTP服務器將相應的網頁文件從電子盤加載到內存進行逐項解析。當辨識出自定義標記后，就調用相應的函數。該函數返回該標記對應的當前值，并置換HTML文件流中的自定義標記。最后，嵌入式HTTP服務器將解析結果發送給客戶端。實時網頁的設計與相應的HTTP服務器處理程序得以分離，處于一種弱耦合關聯狀態。這樣，網頁界面的調整不會影響HTTP服務器的程序設計，HTTP服務器程序的修改也與網頁界面設計無關，整個嵌入式HTTP服務器具備靈活性和可擴展性。

3．4 多線程

最初的進程定義包含程序、資源及其執行三部分，其中程序通常指代碼，資源通常包括 內存資源、I/O資源、信號處理等，而程序的執行指執行上下文，這一部分后來發展為線程。在線程的概念出現以前，為了減小進程切換的開銷，操作系統設計者逐漸修改正進程的概念，允許將進程所占有的資源從其主體剝離出來，允許某些進程共離享一部分資源，例如文件、信號、數據內存、甚至代碼，這就是輕質進程的概念。Linux內核的2.0.x版本就已經實現了輕質進程。應用程序可以通過一個統一的clone()系統調用接口，用不同的參數指定創建輕質進程還是普通進程。在內核中，clone()調用經過參數傳遞和解釋后會調用do_fork()，這個核內函數同時也是fork、vfork()系統調用的最終實現。在do_fork()中，不同的flone_flags將導致不同的行為。在LinuxThreads中，使用（CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND）參數調用clone()創建“線程”，表示共享內存、共享文件系統、共享文件描述符表，以及共享信號處理方式。Linux操作系統下，已經實現基于輕質進程的符號POSIX1003.C標準的線程庫LinuxThreads。

在傳統的Unix服務器程序設計中，為了使服務器具備并發處理連接的能力，通常采用父進程處理連接，并調用fork（）創建子進程來處理用戶請求的方法。這種方法的缺點是進程創建慢，耗費資源，進程切換開銷大，進程之間通信比較困難等，不適用對資源、速度有要求的嵌入式系統。因此，在嵌入式HTTP服務器的開發中使用線程的方法。利用LinuxThreads提供的pthread_create()等函數派生出線程，也即輕質進程來處理多個HTTP請求。

4 工作流程和代碼設計

4．1工作流程

嵌入式HTTP服務器程序開始運行時，主進程首先創建一個接口，并和主機地址綁定到一起，隨后置為被動監聽狀態，等待客戶端連接請求的到來。分別用函數socket()創建一個接口，bind()綁定地址，listen()監聽，accept()接收來完成。當建立一個TCP連接后，函數accept()返回一個新的套接口描述符，主進程就創建一個新的子線程（輕質進程）處理這個新的連接。

子線程用于處理每具體的HTTP請求。子線程首先解析用戶的HTTP請求。當用戶請求一個網頁時，子線程查找文件系統。如果該網頁文件存在，且通過權限認證，就把它從CF卡讀入內存并掃描，發現有自定義標記則調用相應函數進行處理，最后把結果返回給瀏覽器；否則給一個簡單的出錯消息。當用戶是上傳數據時，子線程調用相應函數讀取數據進行處理，并返回處理結果給瀏覽器。

4．2 代碼設計

在嵌入式HTTP服務器的代碼設計中，考慮到代碼的移植性和擴展性，利用C語言實現了面向對象風格的代碼結構。代碼主要由兩上數據結構request_inf和response_inf以及其上一組操作函數組成。

結構request_inf和response_inf分別用來保存HTTP請求報文和響應報文的所有信息。在結構定義時，應根據具體應用特點設計結構包含的成分。

嵌入式HTTP服務器的函數包括通用函數、CGI函數和自定義標記處理函數等，其中通用函數是一些與HTTP1.1協議有關的函數。

（1）通用函數

*void prase_request_line(char *,struct *request_inf)

該函數用來解析HTTP請求報文的請求行（Request_Line），并把相應信息存放在結構request_inf中。其中，對請求行中URI部分的解析包括兩種情況。如果用戶請求一個網頁，則獲取文件路徑、文件類型；如果用戶要求上傳數據，則把數據放在一個字符數組中。然后將文件路徑和類型，或者指向該數組的指針、方法、版本號信息都放入結構request_inf中。

*void prease_general_header(char*,struct*request_inf)

該函數用來解析HTTP請求報文的調用首部（General_Header）。之所以把此函數與函數prase_request_line()分開，是考慮到程序的修植性和擴展性。請求行和通用首部是請求報文中的不同部分，不不同的場合下，要求解析的信息可能存在差導師。同時，這樣也能使程序結構更清楚。比如，本項目要從通用首部解析字段Keep_Alive。該字段指明一個最長的時間或最大請求數目，在此范圍內可以保持TCP連接不被釋放（即前文提到的HTTP1.1的持續連接特性，persistent connection）。

*void prase_request_header(char*,struct*request_inf)

void prase_entity_header(char*,struct*request_inf)

HTTP請求報文的請求頭部用來說明瀏覽器的一些信息，實體頭部則用來說明請求報文中可能存在的實體主體信息。本項目實際上并不需要使用這兩個函數來獲取相關信息，但考慮到程序的擴展性和移植性，此處仍然把它列出來，它們是兩個空函數。

*send_status_line(int fd,struct *response_inf)

此函數用來產生一個HTTP響應報文的狀態行（Status_line）。狀態行包括三部分內容，即HTTP版本、狀態碼以及解釋狀態碼的簡單短語。這些信息預先放在結構response_inf中。

*send_general_header(int fd,struct*response_inf)

send_response_header(int fd,struct*response_inf)

send_entity_header(int fd,struct*response_inf)

這三個函數分別用來產生HTTP響應報文的通用首部、響應首部（Response_header）和實體首部。嵌入式HTTP服務器是一個瘦服務器，功能非常簡單。因此HTTP響應報文的通用首部、響應首部和實體首部中的可選字段許多是不需要的，還有許多是固定不變的，例如Last_modified和Content_type字段。Last_modified字段指出資源上次被修改的時間并由接收方解釋。如果接收方已有此資源的拷貝，但此拷貝比Last-Modified域所指定的要舊，那該拷貝就是過期的。由于網頁文件中含有自定義標記，具有實時性，所以此字段根本沒有含有Content_type字段指出實體的媒體類型，本項目中的嵌入式HTTP服務器被設計成只支持HTML類型，因此該字段的內容總是Content_type=text/html。有關服務器和資源的所有標題域信息都被放入結構response_inf中。

*send_white_line(int fd)

http協議范文6

關鍵詞：B/S；信息推送；Websocket

引言

隨著Web 2.0時代的到來，B/S（Browser/Server）構架的應用越來越廣泛。在B/S構架的應用中，瀏覽器與服務器之間的通信采用HTTP（HyperText Transfer Protocol，超文本傳輸協議）協議。而HTTP協議中，所有的通信都必須由瀏覽器發起，服務器進行響應，這就是“請求-回復（Request-Response）”模式。因此，在B/S構架的應用中，服務器無法自主的向瀏覽器發送信息。但隨著B/S應用越來越復雜，功能越來越多，客戶所期望的用戶體驗越來越好，越來越多的B/S應用希望服務器能自主的向瀏覽器發送信息，甚至期望達到瀏覽器與服務器之間實時的雙向通信。這就需要B/S構架中能夠實現信息的推送（Web Push）。

1 傳統的信息推送方式

傳統的B/S構架中，由于HTTP協議的限制，服務器不能主動發起通信，因此要實現類似于服務器推送信息的效果只能采用一些變通的方法。傳統的信息推送一般采取如下幾種方式實現：定期輪詢（Periodic Polling）、長輪詢（Long Polling）和流（Streaming）。

1.1 定期輪詢

由瀏覽器每隔一段時間主動向服務器發送一次請求，然后根據服務器的返回數據來獲得獲得服務器希望推送給瀏覽器的信息。這種方式下，輪詢的時間間隔比較難控制，時間間隔太長，瀏覽器不能及時的獲得服務器需要推送的信息，信息交流不及時，用戶體驗變差；而如果時間間隔太短，則瀏覽器將頻繁的與服務器進行數據通信，導致服務器負載增大。特別是當服務器無需推送信息的時候，瀏覽器仍舊會定期的與服務器進行通信，從而浪費大量的網絡帶寬和資源。

1.2 長輪詢

當瀏覽器向服務器發送請求后，如果服務器有信息需要推送，則立刻回應這個請求，否則，先保持這個連接一段時間，直到服務器有數據需要推送或者連接時間過期為止；瀏覽器在收到服務器的回應后，將立刻向服務器再次發出新的請求，并等待服務器的回應。這種方式可以減少瀏覽器與服務器之間的無效通信，從而提高效率，減少系統負擔。但當服務器更新頻繁時，也就和定期輪詢之間沒有本質的差別了。

1.3 流

瀏覽器通過一個隱藏的窗口（比如iframe）向服務器發出一個長連接的請求，服務器接收到這個請求后，做出回應并不斷更新連接狀態，從而保證服務器與瀏覽器之間的連接不過期，進而實現服務器將信息推送給瀏覽器的功能。這種方式在并發數較大的情況下，服務器將會消耗大量的系統資源。

1.4 傳統推送方式的不足

雖然上述幾種方法均能在傳統的B/S構架中實現，但這這些方法很明顯的存在著一些弊端：1、定期輪詢可能會導致較高的延時，服務器信息不能實時的被推送到瀏覽器；2、長輪詢或流需要使用到一些特定的編程模型或方案，如Comet；3、會帶來許多擴展性問題；4、較高的帶寬成本和系統資源開銷；5、對跨域環境的支持比較有限。

2 基于Websocket協議的信息推送方式

Websocket協議是HTML5提供的一種瀏覽器與服務器之間進行雙向通信的技術。通信雙方在完成一次簡單的握手操作之后，就建立起一條快速通道，然后利用這個通道可以進行雙向通信，自然也就可以實現信息的推送。

2.1 Websocket協議簡介

Websocket協議是獨立的基于TCP的協議，與HTTP協議之間唯一的聯系僅是在瀏覽器與服務器的握手階段。

2.1.1 瀏覽器發出握手請求

首先瀏覽器以標準的HTTP Get方式向服務器發出握手請求，在請求的頭信息中加入了Websocket協議所需要的一些信息。示例如下：

GET /WSHandler.ashx HTTP/1.1

Connection：Upgrade

Host：localhost：1550

Origin：http：//localhost：1550

Sec-WebSocket-Key：A3IIMlEc9ARZWlO9ShrePw==

Sec-WebSocket-Version：13

Upgrade：websocket

2.1.2 服務器響應握手請求

服務器在獲得這些頭信息后，經過處理，以HTTP方式進行回復，回復時也在頭信息的部分加入了Websocket協議所需要的信息。示例如下：

HTTP/1.1 101 Switching Protocols

Upgrade： Websocket

Sec-WebSocket-Accept： lJYdhpEDwO4BMgu0meIY94nJIYs=

Connection： Upgrade

經過這樣的一個握手過程之后，瀏覽器與服務器之間就建立起了一條TCP通道。

2.1.3 數據幀

在Websocket協議中，數據使用一系列的幀來傳輸。基本幀協議定義了帶有操作碼（opcode）的幀類型、負載長度、和用于“擴展數據”與“應用數據”及它們一起定義的“負載數據”的指定位置。由于采用了幀，Websocket協議不需要像HTTP協議那樣發送大量的頭信息，從而大大降低了對網絡帶寬的要求。

2.1.4 Websocket URIs

Websocket協議定義了兩種URI，分別是普通的ws-URI和安全的wss-URI。這兩種URI均遵循ABNF語法格式，和普通的HTTP協議的URI非常相似。其格式如下：

ws-URI：ws：//host[：port]/path[？query]

wss-URI：wss：//host[：port]/path[？query]

其中ws-URI的默認端口為80，wss-URI的默認端口為443。

2.2 Websocket協議的優勢

相對與傳統的信息推送方式，Websocket協議有著諸多的優點：1、支持SSL，安全性高；2、整體性能高，無論是服務器的負載還是網絡帶寬的成本都大大降低；3、默認采用80或443端口進行數據傳輸，一般不會被封堵；4、可以支持跨域連接；5、在W3C中定義了Javascript API，客戶端編程更加方便。

2.3 Websocket協議存在的問題

當然，Websocket協議也存在一些問題：1、Websocket協議的標準化進程尚未完成，API可能會發生變化，開發應用尚存在一些風險；2、目前僅部分瀏覽器支持Websocket協議，如IE10之前的IE瀏覽器均不支持；3、也不是所有的服務器軟件都支持Websocket，比如.NET 4.5開始支持Websocket協議，但必須運行在Windows 8或Windows Server 2012平臺上才行。

2.4 Websocket在應用中的解決方案

結合Websocket協議的優缺點，我們可以在設計B/S構架的應用時，將實時部分功能和非實時部分功能進行分離，實時性要求強的功能使用Websocket協議實現，而其他功能仍舊使用傳統的HTTP協議實現。這樣的兩種方式能在互不干擾的情況下，發揮出各自的優勢，合理利用資源。同時也更便于升級現有的B/S系統，降低成本，提高效率，優化用戶體驗。

3 Websocket協議在B/S應用中的具體實現

在某訂單處理流程中，用戶希望瀏覽器能實時反映出訂單狀態的變化。原有系統此部分的功能采用基于iframe的流方式實現，雖然基本達到了實時反應訂單狀態變化的需求，但系統開銷很大。因此嘗試使用Websocket協議來進行優化。

3.1 服務器的實現

服務器運行平臺為Windows Server 2012，安裝有.NET 4.5和Microsoft Websockets。在中通過增加一個自定義的HTTP Handler就可以接受瀏覽器發出的Websocket連接請求并實現與瀏覽器進行通信。

public class WSHandler ： IhttpHandler， IReadOnlySessionState {

public void ProcessRequest（HttpContext context） {

if （context.IsWebSocketRequest） {

context.AcceptWebSocketRequest（new WSOrderHandler（））；

}

}

}

public class WSOrderHandler ： WebSocketHandler {

private static WebSocketCollection m_sessions = new WebSocketCollection（）；

private string m_username；

public WSOrderHandler（） { m_username = ...； }

public override void OnOpen（） { m_sessions.Add（this）； }

public override void OnMessage（string message） { ... }

public override void OnClose（） { m_sessions.Remove（this）； }

}

服務器如果需要向所有瀏覽器發送廣播消息，可以通過WSOrderHandler對象中的靜態成員m_sessions的Broadcast（）方法來實現；服務器如果只需向指定瀏覽器發送消息，則需先在m_sessions中找到符合要求的session，然后調用Send（）方法。

3.2 瀏覽器的實現

瀏覽器直接使用W3C所規定的Websocket Javascript API進行開發。首先創建一個Websocket連接。

var wbConnect = new WebSocket（'ws：//.../WSHandler.ashx'）；

然后定義onopen、onclose、onmessage、onerror等事件處理函數。

wbConnect.onopen = function （evt） { ... }；

wbConnect.onclose = function （evt） { ... }；

wbConnect.onmessage = function （evt） { ... }；

wbConnect.onerror = function （evt） { ... }；

最后，如果瀏覽器需要發送消息給服務器，則可以通過調用wbConnect.Send（）方法實現。

3.3 最終效果

基于以上過程，整個改動涉及的代碼量并不多，完全不影響原有系統的其他功能。且在實際運行后，在用戶體驗不變的情況下，服務器的資源消耗情況大幅改善，取得預期的效果。

4 結束語

Websocket協議雖然尚處在不斷完善的階段，但其在實時應用中的巨大優勢已經展露無遺。即使是普通的B/S應用，也能通過使用Websocket協議達到降低系統負載、減少網絡成本、優化用戶體驗的作用。相信隨著Websocket協議的進一步完善，將會有越來越多的瀏覽器和服務器支持Websocket協議，也將會有更多的B/S應用采用Websocket協議。

參考文獻

[1] IETF. The WebSocket Protocol[S/OL]. http：///html/rfc6455.

[2] Paul Batum，Stefan Schackow. Building real-time web apps with WebSockets using IIS， and WCF[R/OL]. http：///events/BUILD/BUILD2011/SAC-807T.

[3] 秦久明. Web服務推送技術的研究與實現[J]. 福建電腦，2012，12：65-66+53.