㈠ WAS http請求默認的響應時間是多少
WAS http請求默認的響應時間是多少的解答如下
默認超時時間是60秒,可以通過下面語句進行修改
HttpClient httpClient=new HttpClient();
httpClient.getHttpConnectionManager().getParams().setConnectionTimeout(1000 * 60); //鏈接超時60秒
httpClient.getHttpConnectionManager().getParams().setSoTimeout(1000 * 60); //讀取超時60秒
㈡ HttpWebRequest怎麼長連接
HTTP是無狀態的
也就是說，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話
HTTP1.1和HTTP1.0相比較而言，最大的區別就是增加了持久連接支持(貌似最新的 http1.0 可以顯示的指定 keep-alive),但還是無狀態的，或者說是不可以信任的。
如果瀏覽器或者伺服器在其頭信息加入了這行代碼
Connection:keep-alive
TCP連接在發送後將仍然保持打開狀態，於是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間，還節約了帶寬。
實現長連接要客戶端和服務端都支持長連接。
所謂長連接指建立SOCKET連接後不管是否使用都保持連接，但安全性較差，
所謂短連接指建立SOCKET連接後發送後接收完數據後馬上斷開連接，一般銀行都使用短連接
短連接：比如
http
的，只是連接、請求、關閉，過程時間較短
,
伺服器若是一段時間內沒有收到請求即可關
閉連接。
長連接：有些服務需要長時間連接到伺服器，比如
CMPP
，一般需要自己做在線維持。
最近在看
「
伺服器推送技術
」
，在
B/S
結構中，通過某種
magic
使得客戶端不需要通過輪詢即可以得到服務
端的最新信息（比如股票價格）
，這樣可
以節省大量的帶寬。
傳統的輪詢技術對伺服器的壓力很大，
並且造成帶寬的極大浪費。如果改用
ajax
輪詢，可以降低帶寬的負荷
（因為伺服器返回的不是完整頁面）
，
但是對伺服器
的壓力並不會有明顯的減少。
而推技術（
push
）可以改善這種情況。但因為
HTTP
連接
的特性（短暫，必須由客戶端發起）
，使得推技術的實現比較困難，常見的做法是通過延長
http
連接的壽
命
，
來實現
push
。
接下來自然該討論如何延長
http
連接的壽命
，
最簡單的自然是死循環法
：
【
servlet
代
碼
片
段
】
public
void
doGet(Request
req,
Response
res)
{
PrintWriter
out
=
res.getWriter();
……
正
常
輸
出
頁
面
……
㈢ 請教JAVA如何實現web下的長連接關鍵後台如何寫
之前在ITjob老師那邊講過常連接的設置可以在web容器中完成，下面是weblogic的場連接設置
一、進入services-JDBC Connection Pools->sysConfig，然後點Connections標簽，點
二、點Advanced Options的Show
三、把一下三個打勾保存
可能的原因：
Web伺服器與資料庫之間有一個安全防火牆，這個防火牆會定期檢查連接，如果某個連接長時間（30分鍾）沒有數據流過，就會被關閉。通過以上設置後保證了資料庫連接不會被斷開
㈣ 如何限制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」/>
㈤ 如何調整web請求等待時間
(1)wsdl文件全文：
我不知道為什麼，老傳不上去
(2)傳不了圖片，只好列出來了：<
action、actionCol、attribute_、attributeCol、configurationRequest、eventValue、eventValueCol、filters、identity、interval、login、loginResponse、loginResult、logout、logoutRespons、mainActions、metric、notification、objectId、objectType、objectTypeCol、objectTypes、parameter、parameterCol、parameters、relativeActions、retrieveConfiguration...
我出來的差不多才有一半類名。如果哪位能生成以上所有類的話，基本就是正確的思路了。
(3)應用中需要應用.dll其中類與web服務交互的代碼片段：只是簡單的登錄
Dim GdspClient As Object 'SoapMessageClient
Dim SubmitReq As Object 'SoapMessage
Dim SubmitRes As Object 'SoapMessage
Dim loginInput As New gssProxyXdr.Login '此處的gssProxyXdr就是生成的那個請求報文片段類activx dll工程生成的dll
Dim loginOut As loginResponse
Dim mOutput As New gssProxyXdr.loginResponse
Dim loginResult As gssProxyXdr.loginResult
Public Function Init(wsdlPath As String) As Boolean
On Error GoTo err:
Set GdspClient = CreateObject("MSSMO.SoapMessageClient")
Set SubmitReq = CreateObject("MSSMO.SoapMessage")
GdspClient.Connect wsdlPath, "statService", "statPort"
㈥ java web即時聊天如何保持長連接
一般web通訊都是在xmpp基礎上改的，開源的比如openfire、spark，都有源碼的，你可以借鑒一下。
㈦ 在web應用中session管理有幾種方式試用三種方式設置session超時時間，並分別簡述其優缺點
1、操作系統（System）：
步驟：開始——〉管理工具——〉Internet信息服務(IIS)管理器——〉網站——〉默認網站——〉右鍵「屬性」——〉主目錄——〉配置——〉選項——〉啟用會話狀態——〉會話超時（在這兒設置你要的超時時間，單位分鍾）。確定即可。
2、ASP.NET應用程序中Session過期時間的設置
在ASP.NET這樣的Web應用中，Session是用來保存用戶狀態的常用手段，不過由於伺服器內存空間是有限的，因此Session過期時間設置是很有必要的。在ASP.NET中怎麼設置Session的過期時間呢，很容易，修改web.config配置。
具體修改方法如下，在web.config中進行如下配置
<system.web>
<sessionState mode="InProc" timeout="30"/>
</system.web>
在這里指的是Session過期時間為30分鍾。也就是說30分鍾後假如當前用戶木有操作，那麼Session就會自動過期了。
3、在調出使用Session的cs頁中，Load事件里邊寫以下
Session.Timeout = 30;
4、Store session in asp.net state service
<sessionState cookieless="false" timeout="480" mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=sa;passWORD=" />
看一下，看你的程序是用到了哪種設置方式，把時間改成你要的時間就可以了。
㈧ 迪普設備如何WEB界面上修改系統時間
電腦啟動時,按DEL進入BIOS界面,選擇第一項進入 Standard CMOS Features,可以用方向鍵修改時間,修改好以後,按F10退出,選Y.
<↑> 向前移一項
<↓> 向後移一項
<←> 向左移一項
<→> 向右移一項
<Esc> 跳到退出菜單或者從子菜單回到主菜單 <+/PU> 增加數值或改變選擇項
<-/PD> 減少數值或改變選擇項
㈨ java怎樣在Web頁面中怎樣修改本地計算機的時間
應該不能吧，若想做到，必須和本計算機的系統連接起來，Windows早不是隨便寫一條程序就可以關機的時候了，現在Windows是分層次的，許可權不同，何況是用Java.
㈩ 調用webservice默認超時是多少
一.伺服器端設置
1、web.config配置，<system.web></system.web>裡面增加：<httpRuntime maxRequestLength="10240" appRequestQueueLimit="100" useFullyQualifiedRedirectUrl="true" executionTimeout="1200" />
2、擴大代理類的超時限制，默認是90秒
YourWebService yws = new YourWebService();
yws.Timeout = 1200000; //20分鍾
3、IIS屬性-網站 連接超時時間 1200秒
二.客戶端設置
1、修改 app.config 文件，添加如下代碼：
<httpRuntime executionTimeout="600" />
請求執行超時時間為600秒（默認為110秒）
2、設置 Web services 的 Timeout 屬性
對 XML Web services 的同步調用的超時（以毫秒為單位）。默認為 100000 毫秒。
lywSqCommon.sqsdData.GetData getData = new lywSqCommon.sqsdData.GetData();//GetData 為類名
getData.Timeout=700000;//單位為毫秒
指示 XML Web services 客戶端等待同步 XML Web services 請求完成的時間（以毫秒計）。
提示：如果將 Timeout 屬性設置為 Timeout.Infinite，則指示該請求無超時。即使 XML Web services 客戶端可以將 Timeout 屬性設置為無超時，Web 伺服器仍可以在伺服器端使請求超時。
系統將以上面兩項設置的最小者作為操作超時的時間長度。