http協(xié)議的運(yùn)作方式(編輯修改稿)
2024-08-31 09:21 本頁面
【文章內(nèi)容簡介】 對(duì)服務(wù)器來講，更增加了瞬間負(fù)載?！ ★@然，造成這個(gè)問題的關(guān)鍵是服務(wù)器對(duì)HTTP協(xié)議的 處理方式，一次請(qǐng)求就要建立一個(gè)連接，在網(wǎng)頁上充滿了多個(gè)較小的圖象文件的時(shí)候，那么服務(wù)器和客戶程序之間的大部分工作是用于建立連接，而真正用于傳遞數(shù) 據(jù)的工作卻很輕松。因此，更好的利用現(xiàn)有連接，減少建立連接的消耗，就需要能在一次連接中回應(yīng)多個(gè)請(qǐng)求。，而 下一代HTTP協(xié)議：HTTPNG更增加了有關(guān)會(huì)話控制、豐富的內(nèi)容協(xié)商等方式的支持，來提供更高效率的連接。 除了針對(duì)每次請(qǐng)求都建立一個(gè)新進(jìn)程的處理方式之外，HTTP守護(hù)進(jìn)程也能使用其他的方式處理多個(gè)請(qǐng)求，例如使用多線程，或者使用異步方式在不同請(qǐng)求之間 進(jìn)行切換，就能在一個(gè)進(jìn)程內(nèi)處理多個(gè)請(qǐng)求。雖然比起建立新進(jìn)程來講，這樣消耗的處理器資源略微減少，但是并不能從根本上消除并發(fā)訪問帶來的處理器資源不足 的問題。一般使用線程和異步方式的程序較為復(fù)雜，不能很容易擴(kuò)充對(duì)新特性的支持，并有可能因?yàn)槌绦騼?nèi)部要自己進(jìn)行同步等原因也會(huì)造成資源消耗。使用這些方 式，雖然對(duì)處理靜態(tài)的網(wǎng)頁有好處，但對(duì)于執(zhí)行CGI程序，仍然要?jiǎng)?chuàng)建子進(jìn)程進(jìn)行處理。因此，大部分運(yùn)行在Unix上的守護(hù)程序仍然使用多進(jìn)程的方式，這種 方式簡單卻有效?！ 〖词箤?duì)于使用多進(jìn)程方式進(jìn)行處理的Web服務(wù)器，也有不同的處理方式。Unix系統(tǒng)中提供了超級(jí)服務(wù)器進(jìn)程 inetd，因此簡單的Web服務(wù)器可以使用inetd來啟動(dòng)真正的Web服務(wù)器。然而，inetd效率不高，使用inetd的服務(wù)器不能用作高負(fù)載的服 務(wù)器系統(tǒng)，因此高負(fù)載的Web服務(wù)器，本身來監(jiān)聽客戶連接請(qǐng)求，并負(fù)責(zé)啟動(dòng)子進(jìn)程真正處理客戶的請(qǐng)求?！ ∪绻x擇的服務(wù)器程序的確需要使用inetd來啟動(dòng)，可以選擇與inetd功能相同，但效率更高的超級(jí)服務(wù)器進(jìn)程tcpserver，它可以比inetd更高效的啟動(dòng)服務(wù)進(jìn)程。HTTP（HyperTextTransferProtocol）是超文本傳輸協(xié)議的縮寫，它用于傳送WWW方式的數(shù)據(jù)，關(guān)于HTTP協(xié)議的詳細(xì)內(nèi)容請(qǐng)參考RFC2616。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型?？蛻舳讼蚍?wù)器發(fā)送一個(gè)請(qǐng)求，請(qǐng)求頭包含請(qǐng)求的方法、URI、協(xié)議版本、以及包含請(qǐng)求修飾符、客戶信息和內(nèi)容的類似于MIME的消息結(jié)構(gòu)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，相應(yīng)的內(nèi)容包括消息協(xié)議的版本，成功或者錯(cuò)誤編碼加上包含服務(wù)器信息、實(shí)體元信息以及可能的實(shí)體內(nèi)容。通 常HTTP消息包括客戶機(jī)向服務(wù)器的請(qǐng)求消息和服務(wù)器向客戶機(jī)的響應(yīng)消息。這兩種類型的消息由一個(gè)起始行，一個(gè)或者多個(gè)頭域，一個(gè)只是頭域結(jié)束的空行和可 選的消息體組成。HTTP的頭域包括通用頭，請(qǐng)求頭，響應(yīng)頭和實(shí)體頭四個(gè)部分。每個(gè)頭域由一個(gè)域名，冒號(hào)（:）和域值三部分組成。域名是大小寫無關(guān)的，域 值前可以添加任何數(shù)量的空格符，頭域可以被擴(kuò)展為多行，在每行開始處，使用至少一個(gè)空格或制表符。通用頭域通用頭域包含 請(qǐng)求和響應(yīng)消息都支持的頭域，通用頭域包含CacheControl、Connection、Date、Pragma、Transfer Encoding、Upgrade、Via。對(duì)通用頭域的擴(kuò)展要求通訊雙方都支持此擴(kuò)展，如果存在不支持的通用頭域，一般將會(huì)作為實(shí)體頭域處理。下面簡單 介紹幾個(gè)在UPnP消息中使用的通用頭域。CacheControl頭域CacheControl指定請(qǐng)求和響應(yīng)遵 循的緩存機(jī)制。在請(qǐng)求消息或響應(yīng)消息中設(shè)置CacheControl并不會(huì)修改另一個(gè)消息處理過程中的緩存處理過程。請(qǐng)求時(shí)的緩存指令包括no cache、nostore、maxage、maxstale、minfresh、onlyifcached，響應(yīng)消息中的指令包括 public、private、nocache、nostore、notransform、mustrevalidate、proxy revalidate、maxage。各個(gè)消息中的指令含義如下：Public指示響應(yīng)可被任何緩存區(qū)緩存。Private指示對(duì)于單個(gè)用戶的整個(gè)或部分響應(yīng)消息，不能被共享緩存處理。這允許服務(wù)器僅僅描述當(dāng)用戶的部分響應(yīng)消息，此響應(yīng)消息對(duì)于其他用戶的請(qǐng)求無效。nocache指示請(qǐng)求或響應(yīng)消息不能緩存nostore用于防止重要的信息被無意的發(fā)布。在請(qǐng)求消息中發(fā)送將使得請(qǐng)求和響應(yīng)消息都不使用緩存。maxage指示客戶機(jī)可以接收生存期不大于
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1