當前位置:首頁 » 網頁前端 » web服務限制
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

web服務限制

發布時間: 2022-08-22 21:34:54

⑴ webservice怎樣限制客戶端同一個入口

webservice相互的通訊是建立在協議的基礎上的, 但同一個容器的的webservice可以通過傳遞對象實例來進行通訊,比如在tomcat中的RequestDispatcher介面. 但跨平台的通訊,需要用到協議,現在主流的都是SOAP,實質是個xml文本消息. SOAP定義了服務埠,參數類型,處理方法.還有編碼方式.這都是進行通訊必不可少的,web service是管道過濾器模型,雖然不限制過濾器的實現方式,但是管道要求明確定義在兩個過濾器之間傳輸的數據類型.比如&name=zhang&pass=123456這個name是什麼?pass又是什麼?,字面上看name就是用戶名,pass就是密碼,但是這是你的理解,機器可不會認為name就是用戶名, 機器是死的,參數類型和名稱是由服務的WSDL限制死的,另外還有編碼.你所用的編碼機器不一定認識,同樣的編碼,在另一種編碼環境下,可能就是亂碼,這在中文數據交換上經常出現,你看到亂碼了,表示出錯了,但機器不認為出錯了,機器不是人,你不認得亂碼,但是機器認得,在機器里非亂碼和亂碼都是正常的01組合,這樣一個編碼的原因,你的name=zhang到了伺服器,經過不同的編碼可能收到的信息就不是name=zhang了所以直接通訊是不行的,必須要有協議,而這個協議就是SOAP.

⑵ 如何限制客戶端對WebService的訪問

如何設置能限制某個IP某一時間段的訪問次數是一個讓人頭疼的問題,特別面對惡意的ddos攻擊的時候。其中CC攻擊(Challenge Collapsar)是DDOS(分布式拒絕服務)的一種,也是一種常見的網站攻擊方法,攻擊者通過代理伺服器或者肉雞向向受害主機不停地發大量數據包,造成對方伺服器資源耗盡,一直到宕機崩潰。
cc攻擊一般就是使用有限的ip數對伺服器頻繁發送數據來達到攻擊的目的,nginx可以通過HttpLimitReqMol和HttpLimitZoneMole配置來限制ip在同一時間段的訪問次數來防cc攻擊。
HttpLimitReqMol用來限制連單位時間內連接數的模塊,使用limit_req_zone和limit_req指令配合使用來達到限制。一旦並發連接超過指定數量,就會返回503錯誤。
HttpLimitConnMol用來限制單個ip的並發連接數,使用limit_zone和limit_conn指令
這兩個模塊的區別前一個是對一段時間內的連接數限制,後者是對同一時刻的連接數限制

文章目錄
1 HttpLimitReqMol 限制某一段時間內同一ip訪問數實例
2 HttpLimitZoneMole 限制並發連接數實例
3 nginx白名單設置
HttpLimitReqMol 限制某一段時間內同一ip訪問數實例
http{
...

#定義一個名為allips的limit_req_zone用來存儲session,大小是10M內存,
#以$binary_remote_addr 為key,限制平均每秒的請求為20個,
#1M能存儲16000個狀態,rete的值必須為整數,
#如果限制兩秒鍾一個請求,可以設置成30r/m

limit_req_zone $binary_remote_addr zone=allips:10m rate=20r/s;
...
server{
...
location {
...

#限制每ip每秒不超過20個請求,漏桶數burst為5
#brust的意思就是,如果第1秒、2,3,4秒請求為19個,
#第5秒的請求為25個是被允許的。
#但是如果你第1秒就25個請求,第2秒超過20的請求返回503錯誤。
#nodelay,如果不設置該選項,嚴格使用平均速率限制請求數,
#第1秒25個請求時,5個請求放到第2秒執行,
#設置nodelay,25個請求將在第1秒執行。

limit_req zone=allips burst=5 nodelay;
...
}
...
}
...

⑶ Web伺服器怎樣解除禁用

你可以手動連接,同時記著更新伺服器列表。一般情況下eMule啟動後會自動連上伺服器的,可能是你的伺服器列表近期沒有更新的緣故。 WEB伺服器禁用,是你沒有啟用而已。一般情況下不用啟用。如果你要啟用,在「選項」→「WEB伺服器」中設置啟用。

⑷ 我用Web伺服器架設,會有人數訪問限制嗎

以下回答 純手寫 絕對原創 版權歸HKHK366所有 未經允許禁止轉載

如果你用APACHE就沒有限制了
如果是WIN XP 是用IIS建設只能10個訪問 有限制 但是微軟推出了突破限制的補丁 你可以上微軟網站上下載

如果你是WIN 2000或者WIN2003 是用IIS就不會有限制

總結如下 IIS不穩定漏洞多 我都是用APACHE這個沒限制 速度快 跨平台
或者也可以用NETBOX這個簡單易學 支持ASP 而APACHE向支持ASP 或者PHP必須得安裝相應組件

回答完畢

完全原創 禁止轉載 版權歸HKHK366

——HK帝國知識團

⑸ web伺服器怎麼限制後綴名的主機訪問

首先把路由器的web管理埠調整為其他非80埠,比如8000
其次在路由器的靜態映射或者虛擬伺服器功能里,把外部80埠映射到主機192.168.0.101的80埠
如果映射後依然無法從外網訪問web伺服器,最好能電話客服,確認一下小區寬頻是否屏蔽外部網路對內部網路的埠訪問
***
第三層的區域網?只有前兩層是那種橋接類型並且不限制埠的網路,你才能通過公網ip正常訪問到自己的路由器。否則需要前2級路由器的許可權,並做相同的映射或者dmz轉發,這個恐怕不現實吧。咨詢客服吧,看看能否解決。
這個與花生殼無關的。你可以用公網ip來直接訪問自己的伺服器看看能否通連。

⑹ web伺服器可能會存在哪些問題拜託各位了 3Q

當前的虛擬主機主要分為三類流量限制: 一:流量限制 就是直接限制網路流量,這種限制通常是最嚴厲的一種流量限制,10個g的流量大體支持50人在線以內.當月流量超過後,在一個月內網站都不能正常訪問了,解決辦法是升級空間或加大流量! 二:CPU限制 CPU限制看起來沒有限IIS或網路流量,但由於每一個程序運行都需要一定的CPU配額,也是變相的流量限制,通常網頁顯示在線過多都是由於CPU限額過小引起的!通過刷新或15秒後可以得到暫時的正常運行,通常1%的CPU限額相當於20個IIS連接!這對於論壇空間很重要,論壇的CPU限額一旦過小就會不能正常運行! 三:IIS限制 IIS限制是現在用的最多的,也是被大多用戶或主機商認可,是唯一寬松的流量限制,通常20個IIS就相當於1%CPU佔用! 總而言之,虛擬主機實際上沒有不限流量的,總的可以分為以上三種方式,您如何選擇,要看您的需要,如果您的程序佔用CPU很少,是優化的程序可以選擇限CPU的,這樣您的在線就可以得到最大的發揮,如果您是初學者,或是論壇用戶,或網站程序中有BBS,選擇IIS限制或直接流量限制是一個好的選擇! 關於同時連接數與在線人數問題的詳解 很多用戶對連接數的概念認識都很模糊,現介紹如下: 1、瀏覽者訪問站點,必需與站點通過TCP協議,建立連接。這個連接在從伺服器上讀取信息時存在,讀取結束時,一般即自動關閉。所以,當一個頁面已經完全地顯示在客戶端的顯示器上時,使用的連接也許已經關閉了。 2、每個瀏覽者,訪問某站點時,可能會佔用1——3個連接,這是由計算機自動處理的,這樣做的目的是為了加快速度。 相關問題:所以,對於連接數為30的基礎型主機而言,有時只能十幾個人訪問,就不足為怪了。 3、論壇中統計的在線人數,是以某一時間段內訪問論壇的活動人數為標準的,與連接數應無關系。比如動網論壇,默認好象是40分鍾內(?記不清了)的活動人數。也許論壇顯示某用戶還在線,但該用戶由於不(正)在讀取論壇中頁面,所以也就不會佔用連接數。 相關問題: (1)所以,只要瀏覽者對論壇的訪問不過於集中,不會在某一時間點超出最大同時連接數,則論壇中統計的在線人數,會大大超出空間允許的最大同時連接數。 (2)某些用戶為了顯示論壇的人氣,可以在調大論壇統計在線人數的時間范圍(動網論壇提供此功能),甚至可以將一天內所有瀏覽你站點的人,都算作在線人數。 4、雖然伺服器中可以規定每個站點的最大連接數,但同時也存在伺服器的總計最大連接數。所以,即使規定用戶站點的最大連接數為不限,當伺服器達到了最大連接數時,仍不能訪問站點。而伺服器的最大連接數一般在1000——2000。 相關問題: 這就是為什麼服務商敢於開出不限連接數的主機,本質上不是無限連接數的。 5、現在的主機服務中,有些服務商利用許多人對上述概念模糊,而誤導消費者,所以購主機者應謹慎從事 了解什麼是IIS連接數 IIS連接數指並發連接數,什麼意思呢? 要分幾種情況:(以100M空間50人在線為例) A用戶單點下載你的文件,結束後正常斷開,這些連接是按照瞬間計算的,就是說你50人的網站瞬間可以接受同時50個點下載 B用戶打開你的頁面,就算停留在頁面沒有對伺服器發出任何請求,那麼在用戶打開一面以後的20分鍾內也都要算一個在線,就是說你50人的網站20分鍾內可以接受不同用戶打開50個頁面 C上面B的情況用戶繼續打開同一個網站的其他頁面,那麼在線人數按照用戶最後一次點擊(發出請求)以後的20分鍾計算,在這個20分鍾內不管用戶怎麼點擊(包括新窗口打開)都還是一人在線。 D當你的頁面內存在框架(Iframe),那麼每多一個框架就要多一倍的在線!因為這相當於用戶同一時間向伺服器請求了多個頁面。 E當用戶打開頁面然後正常關閉瀏覽器,用戶的在線人數也會馬上清除。 然後了解什麼是論壇在線人數。 論壇在線只是計算一定時間內的活動用戶數。 這里的時間用戶可以自己設定,動網論壇默認為40分鍾的相對准確值。 根據上面的說明,顯然論壇在線和IIS連接數的概念不同 為什麼會出現IIS連接數和論壇在線不符合的情況? 現具體分析如下: 1:您使用了插件版論壇或者美化版論壇! 現在的插件很垃圾,不但占伺服器資源,而且會使論壇運行變慢(沒有插件可以快一倍以上),同時很佔在線人數,有的插件調用很多框架,少則2、3個,多則4、5個!甚至有在線播放音樂,這樣一個人在線就相當與很多人在線!而美化版論壇因為使用大量的圖片,也同樣比標准版論壇佔用IIS數量大。 2:您的網站是主頁+論壇的形式! 這樣主頁和論壇要爭奪你的在線人數! 3:你的論壇內部有播放器! 一個人在線,然後他在線播放音樂,就佔二個人在線! 4:你的論壇內部存在框架形式的網頁! 每一個框架,就多一倍的在線! 5:你的論壇設置在線時間過小! 動網默認為40分鍾,因為論壇在線只是計算一定時間內的活動用戶數,當您設定的時間較小的時候,看起來論壇在線的人數就自然少了! 6:你的空間存在多個論壇! 有的客戶在一個空間里上傳多個論壇,如BBSBBS1BBS2等等等等 毫無疑問,這樣個論壇也是要爭奪再線人數的! 7:你的論壇圖片等文件被人盜鏈! 比如:你的論壇有張圖片文件,被粘貼(注意是粘貼不是上傳)到別的論壇! 別的論壇的用戶在瀏覽該文件的時候也算一個在線人數! 尤其是LOGO連接的時候注意,一定要對方把您的LOGO上傳到他的空間! 8:你的空間上放有下載文件! 如果用戶用網路螞蟻類的軟體,每一個線程就表示一個在線,非常厲害! —————————————————————————————————— 解決辦法: 1:去掉垃圾的插件版,用標准版! 2:盡量不要採用框架的形式製作頁面! 3:不要放任何的音樂、電影、下載! 4:防止盜連情況的發生! 5:升級購買支持更多在線人數的空間!

⑺ go原生web伺服器怎麼限制groutine數量

在數量中設置限制。go原生web伺服器是一種運行代碼的伺服器、
1、首先用戶可以在伺服器中可以更改groutine數量。
2、其次如果用戶感覺groutine數量過多時可以在界面中的數量限制欄中輸入groutine。
3、再填寫出該代碼能夠出現的最大數量即可。

⑻ 如何限制web伺服器的HTTP頭部傳輸的最大許可時間

有的網站會在伺服器運行一段時間後down掉,有很多原因可能造成這種現象:比如tomcat堆和非堆內存設置不足,程序沒能釋放內存空間造成內存溢出,或者某些進程一直運行沒能釋放,造成cup資源大量消耗。但除了程序本身的原因,還有可能是客服端訪問造成(當然這個客戶端也包含如蜘蛛軟體等搜索引擎),如果伺服器和客戶端建立的是長鏈接(可以用」netstat -a」命令查看網路訪問信息),這就需要對http響應頭的connection做一定的設置。

在http1.1中request和reponse header中都有可能出現一個connection頭欄位,此header的含義是當client和server通信時對於長鏈接如何進行處理。在http1.1中,client和server都是默認對方支持長鏈接的, 如果client使用http1.1協議,但又不希望使用長鏈接,則需要在header中指明connection的值為close;如果server方也不想支持長鏈接,則在response中也需要明確說明connection的值為close。

不論request還是response的header中包含了值為close的connection,都表明當前正在使用的tcp鏈接在請求處理完畢後會被斷掉。以後client再進行新的請求時就必須創建新的tcp鏈接了。

HTTP Connection的close設置允許客戶端或伺服器中任何一方關閉底層的連接雙方都會要求在處理請求後關閉它們的TCP連接。

如何在程序中設置:可以在過濾器中加入:response.setHeader(「connection」, 「close」);

以下內容來自: HTTP Keep-Alive詳解

HTTP Keep Alive
HTTP Keep-Alive 很大程序上被誤解了,下面介紹一下它在HTTP/1.0和HTTP/1.1版本下是如何工作的,以及其在JAVA中的運行原理。
HTTP是一個請求<->響應模式的典型範例,即客戶端向伺服器發送一個請求信息,伺服器來響應這個信息。在老的HTTP版本中,每個請求都將被創建一個新的客戶端->伺服器的連接,在這個連接上發送請求,然後接收請求。這樣的模式有一個很大的優點就是,它很簡單,很容易理解和編程實現;它也有一個很大的缺點就是,它效率很低,因此Keep-Alive被提出用來解決效率低的問題。

HTTP/1.0
在HTTP/1.0版本中,並沒有官方的標准來規定Keep-Alive如何工作,因此實際上它是被附加到HTTP/1.0協議上,如果客戶端瀏覽器支持Keep-Alive,那麼就在HTTP請求頭中添加一個欄位 Connection: Keep-Alive,當伺服器收到附帶有Connection: Keep-Alive的請求時,它也會在響應頭中添加一個同樣的欄位來使用Keep-Alive。這樣一來,客戶端和伺服器之間的HTTP連接就會被保持,不會斷開(超過Keep-Alive規定的時間,意外斷電等情況除外),當客戶端發送另外一個請求時,就使用這條已經建立的連接

HTTP/1.1
在HTTP/1.1版本中,官方規定的Keep-Alive使用標准和在HTTP/1.0版本中有些不同,默認情況下所在HTTP1.1中所有連接都被保持,除非在請求頭或響應頭中指明要關閉:Connection: Close ,這也就是為什麼Connection: Keep-Alive欄位再沒有意義的原因。另外,還添加了一個新的欄位Keep-Alive:,因為這個欄位並沒有詳細描述用來做什麼,可忽略它

Not reliable(不可靠)

HTTP是一個無狀態協議,這意味著每個請求都是獨立的,Keep-Alive沒能改變這個結果。另外,Keep-Alive也不能保證客戶端和伺服器之間的連接一定是活躍的,在HTTP1.1版本中也如此。唯一能保證的就是當連接被關閉時你能得到一個通知,所以不應該讓程序依賴於Keep-Alive的保持連接特性,否則會有意想不到的後果

Keep-Alive和POST

在HTTP1.1細則中規定了在一個POST消息體後面不能有任何字元,還指出了對於某一個特定的瀏覽器可能並不遵循這個標准(比如在POST消息體的後面放置一個CRLF符)。而據我所知,大部分瀏覽器在POST消息體後都會自動跟一個CRLF符再發送,如何解決這個問題呢?根據上面的說明在POST請求頭中禁止使用Keep-Alive,或者由伺服器自動忽略這個CRLF,大部分伺服器都會自動忽略,但是在未經測試之前是不可能知道一個伺服器是否會這樣做。

以下內容來自: http://liugong.blog.163.com/blog/static/178272375201141344312315/
HTTP無狀態協議和Connection:Keep-Alive容易犯的誤區

名詞解釋:
HTTP無狀態:無狀態是指協議對於事務處理沒有記憶能力,伺服器不知道客戶端是什麼狀態。從另一方面講,打開一個伺服器上的網頁和你之前打開這個伺服器上的網頁之間沒有任何聯系
如果你要實現一個購物車,需要藉助於Cookie或Session或伺服器端API(如NSAPI and ISAPI)記錄這些信息,請求伺服器結算頁面時同時將這些信息提交到伺服器
當你登錄到一個網站時,你的登錄狀態也是由Cookie或Session來「記憶」的,因為伺服器並不知道你是否登錄
優點:伺服器不用為每個客戶端連接分配內存來記憶大量狀態,也不用在客戶端失去連接時去清理內存,以更高效地去處理WEB業務
缺點:客戶端的每次請求都需要攜帶相應參數,伺服器需要處理這些參數

Keep-Alive:參考另外一篇文章HTTP Keep-Alive 詳解

容易犯的誤區:
1、HTTP是一個無狀態的面向連接的協議,無狀態不代表HTTP不能保持TCP連接,更不能代表HTTP使用的是UDP協議(無連接)
2、從HTTP/1.1起,默認都開啟了Keep-Alive,保持連接特性,簡單地說,當一個網頁打開完成後,客戶端和伺服器之間用於傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個伺服器上的網頁,會繼續使用這一條已經建立的連接
3、Keep-Alive不會永久保持連接,它有一個保持時間,可以在不同的伺服器軟體(如Apache)中設定這個時間

以下內容來自:http://www.l99.com/EditText_view.action?textId=446020&src=
Keep-Alive簡介及在Tomcat中配置

Keep-Alive功能使客戶端到伺服器端的連接持續有效,當出現對伺服器的後繼請求時,Keep-Alive功能避免了建立或者重新建立連接。市場上 的大部分Web伺服器,包括iPlanet、IIS和Apache,都支持HTTP Keep-Alive。對於提供靜態內容的網站來說,這個功能通常很有用。但是,對於負擔較重的網站來說,這里存在另外一個問題:雖然為客戶保留打開的連 接有一定的好處,但它同樣影響了性能,因為在處理暫停期間,本來可以釋放的資源仍舊被佔用。當Web伺服器和應用伺服器在同一台機器上運行時,Keep-Alive功能對資源利用的影響尤其突出。 此功能為HTTP 1.1預設的功能,HTTP 1.0加上Keep-Alive header也可以提供HTTP的持續作用功能。
Keep-Alive: timeout=5, max=100
timeout:過期時間5秒(對應httpd.conf里的參數是:KeepAliveTimeout),max是最多一百次請求,強制斷掉連接
就是在timeout時間內又有新的連接過來,同時max會自動減1,直到為0,強制斷掉。
Tomcat中的相關設置,在server.xml 中的Connector 元素中。
keepAliveTimeout:
此時間過後連接就close了,單位是milliseconds
maxKeepAliveRequests:

最大長連接個數(1表示禁用,-1表示不限制個數,默認100個。一般設置在100~200之間).

maxKeepAliveRequests=」1″就可以避免tomcat產生大量的TIME_WAIT連接,從而從一定程度上避免tomcat假死。

<Connector executor=」tomcatThreadPool」
port=」80″ protocol=」HTTP/1.1″
connectionTimeout=」60000″
keepAliveTimeout=」15000″
maxKeepAliveRequests=」1″
redirectPort=」443″
maxHttpHeaderSize=」8192″ URIEncoding=」UTF-8″ enableLookups=」false」 acceptCount=」100″ disableUploadTimeout=」true」/>‍有的網站會在伺服器運行一段時間後down掉,有很多原因可能造成這種現象:比如tomcat堆和非堆內存設置不足,程序沒能釋放內存空間造成內存溢出,或者某些進程一直運行沒能釋放,造成cup資源大量消耗。但除了程序本身的原因,還有可能是客服端訪問造成(當然這個客戶端也包含如蜘蛛軟體等搜索引擎),如果伺服器和客戶端建立的是長鏈接(可以用」netstat -a」命令查看網路訪問信息),這就需要對http響應頭的connection做一定的設置。

在http1.1中request和reponse header中都有可能出現一個connection頭欄位,此header的含義是當client和server通信時對於長鏈接如何進行處理。在http1.1中,client和server都是默認對方支持長鏈接的, 如果client使用http1.1協議,但又不希望使用長鏈接,則需要在header中指明connection的值為close;如果server方也不想支持長鏈接,則在response中也需要明確說明connection的值為close。

不論request還是response的header中包含了值為close的connection,都表明當前正在使用的tcp鏈接在請求處理完畢後會被斷掉。以後client再進行新的請求時就必須創建新的tcp鏈接了。

HTTP Connection的close設置允許客戶端或伺服器中任何一方關閉底層的連接雙方都會要求在處理請求後關閉它們的TCP連接。

如何在程序中設置:可以在過濾器中加入:response.setHeader(「connection」, 「close」);

以下內容來自: HTTP Keep-Alive詳解

HTTP Keep Alive
HTTP Keep-Alive 很大程序上被誤解了,下面介紹一下它在HTTP/1.0和HTTP/1.1版本下是如何工作的,以及其在JAVA中的運行原理。
HTTP是一個請求<->響應模式的典型範例,即客戶端向伺服器發送一個請求信息,伺服器來響應這個信息。在老的HTTP版本中,每個請求都將被創建一個新的客戶端->伺服器的連接,在這個連接上發送請求,然後接收請求。這樣的模式有一個很大的優點就是,它很簡單,很容易理解和編程實現;它也有一個很大的缺點就是,它效率很低,因此Keep-Alive被提出用來解決效率低的問題。

HTTP/1.0
在HTTP/1.0版本中,並沒有官方的標准來規定Keep-Alive如何工作,因此實際上它是被附加到HTTP/1.0協議上,如果客戶端瀏覽器支持Keep-Alive,那麼就在HTTP請求頭中添加一個欄位 Connection: Keep-Alive,當伺服器收到附帶有Connection: Keep-Alive的請求時,它也會在響應頭中添加一個同樣的欄位來使用Keep-Alive。這樣一來,客戶端和伺服器之間的HTTP連接就會被保持,不會斷開(超過Keep-Alive規定的時間,意外斷電等情況除外),當客戶端發送另外一個請求時,就使用這條已經建立的連接

HTTP/1.1
在HTTP/1.1版本中,官方規定的Keep-Alive使用標准和在HTTP/1.0版本中有些不同,默認情況下所在HTTP1.1中所有連接都被保持,除非在請求頭或響應頭中指明要關閉:Connection: Close ,這也就是為什麼Connection: Keep-Alive欄位再沒有意義的原因。另外,還添加了一個新的欄位Keep-Alive:,因為這個欄位並沒有詳細描述用來做什麼,可忽略它

Not reliable(不可靠)

HTTP是一個無狀態協議,這意味著每個請求都是獨立的,Keep-Alive沒能改變這個結果。另外,Keep-Alive也不能保證客戶端和伺服器之間的連接一定是活躍的,在HTTP1.1版本中也如此。唯一能保證的就是當連接被關閉時你能得到一個通知,所以不應該讓程序依賴於Keep-Alive的保持連接特性,否則會有意想不到的後果

Keep-Alive和POST

在HTTP1.1細則中規定了在一個POST消息體後面不能有任何字元,還指出了對於某一個特定的瀏覽器可能並不遵循這個標准(比如在POST消息體的後面放置一個CRLF符)。而據我所知,大部分瀏覽器在POST消息體後都會自動跟一個CRLF符再發送,如何解決這個問題呢?根據上面的說明在POST請求頭中禁止使用Keep-Alive,或者由伺服器自動忽略這個CRLF,大部分伺服器都會自動忽略,但是在未經測試之前是不可能知道一個伺服器是否會這樣做。

以下內容來自: http://liugong.blog.163.com/blog/static/178272375201141344312315/
HTTP無狀態協議和Connection:Keep-Alive容易犯的誤區

名詞解釋:
HTTP無狀態:無狀態是指協議對於事務處理沒有記憶能力,伺服器不知道客戶端是什麼狀態。從另一方面講,打開一個伺服器上的網頁和你之前打開這個伺服器上的網頁之間沒有任何聯系
如果你要實現一個購物車,需要藉助於Cookie或Session或伺服器端API(如NSAPI and ISAPI)記錄這些信息,請求伺服器結算頁面時同時將這些信息提交到伺服器
當你登錄到一個網站時,你的登錄狀態也是由Cookie或Session來「記憶」的,因為伺服器並不知道你是否登錄
優點:伺服器不用為每個客戶端連接分配內存來記憶大量狀態,也不用在客戶端失去連接時去清理內存,以更高效地去處理WEB業務
缺點:客戶端的每次請求都需要攜帶相應參數,伺服器需要處理這些參數

Keep-Alive:參考另外一篇文章HTTP Keep-Alive 詳解

容易犯的誤區:
1、HTTP是一個無狀態的面向連接的協議,無狀態不代表HTTP不能保持TCP連接,更不能代表HTTP使用的是UDP協議(無連接)
2、從HTTP/1.1起,默認都開啟了Keep-Alive,保持連接特性,簡單地說,當一個網頁打開完成後,客戶端和伺服器之間用於傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個伺服器上的網頁,會繼續使用這一條已經建立的連接
3、Keep-Alive不會永久保持連接,它有一個保持時間,可以在不同的伺服器軟體(如Apache)中設定這個時間

以下內容來自:http://www.l99.com/EditText_view.action?textId=446020&src=
Keep-Alive簡介及在Tomcat中配置

Keep-Alive功能使客戶端到伺服器端的連接持續有效,當出現對伺服器的後繼請求時,Keep-Alive功能避免了建立或者重新建立連接。市場上 的大部分Web伺服器,包括iPlanet、IIS和Apache,都支持HTTP Keep-Alive。對於提供靜態內容的網站來說,這個功能通常很有用。但是,對於負擔較重的網站來說,這里存在另外一個問題:雖然為客戶保留打開的連 接有一定的好處,但它同樣影響了性能,因為在處理暫停期間,本來可以釋放的資源仍舊被佔用。當Web伺服器和應用伺服器在同一台機器上運行時,Keep-Alive功能對資源利用的影響尤其突出。 此功能為HTTP 1.1預設的功能,HTTP 1.0加上Keep-Alive header也可以提供HTTP的持續作用功能。
Keep-Alive: timeout=5, max=100
timeout:過期時間5秒(對應httpd.conf里的參數是:KeepAliveTimeout),max是最多一百次請求,強制斷掉連接
就是在timeout時間內又有新的連接過來,同時max會自動減1,直到為0,強制斷掉。
Tomcat中的相關設置,在server.xml 中的Connector 元素中。
keepAliveTimeout:
此時間過後連接就close了,單位是milliseconds
maxKeepAliveRequests:

最大長連接個數(1表示禁用,-1表示不限制個數,默認100個。一般設置在100~200之間).

maxKeepAliveRequests=」1″就可以避免tomcat產生大量的TIME_WAIT連接,從而從一定程度上避免tomcat假死。

<Connector executor=」tomcatThreadPool」
port=」80″ protocol=」HTTP/1.1″
connectionTimeout=」60000″
keepAliveTimeout=」15000″
maxKeepAliveRequests=」1″
redirectPort=」443″
maxHttpHeaderSize=」8192″ URIEncoding=」UTF-8″ enableLookups=」false」 acceptCount=」100″ disableUploadTimeout=」true」/>

⑼ 如何在webService中實現IP限制

使用Request.UserHostAddress可獲得遠程主機IP
然後可以使用switch(Request.UserHostAddress)...
對你想過濾的IP進行相應處理!
如果只想讓本地程序調用,可用Request.IsLocal判斷。

⑽ web service限制訪問域名

你的是伺服器還是虛擬主機呢,伺服器是可以做的,有些虛擬主機面板上面有這一些功能簡單設置一下就好。