客戶端訪問

Ⅰ 如何獲取客戶端訪問網站的IP地址

• request.getRemoteAddr()是獲得客戶端的ip地址。

• request.getRemoteHost()是獲得客戶端的主機名。

Ⅱ "客戶端訪問許可證"不明白

客戶端訪問許可是指在C\S模式的軟體中,允許客戶端同時連接伺服器的個數。
出現原因：這是因為Window Server 2003 不管理「用戶 CAL」。這就是說，即使許可證伺服器資料庫中有一個「用戶 CAL」，它在被使用時也不會減少。這樣就不會為了讓每個用戶都有一個有效的終端伺服器 (TS) CAL 而根據「最終用戶許可協議」(EULA) 的要求刪除管理員。在沒有使用「設備 CAL」的情況下，如果不是每個用戶都有一個「用戶 CAL」，就會違反 EULA。
解決方法如下：
1、在本計算機上執行：開始--運行--mstsc /v:（伺服器IP） /console <此命令是通過concle口進行連接>（這一步沒有解決我的問題，依然出現上述提示）
2、在登錄出問題的伺服器上， 單擊「開始」，指向「管理工具」，然後單擊「終端服務配置」；單擊「伺服器設置」，然後雙擊「授權模式」；將「授權模式」更改為「每用戶」，然後單擊「確定」。 以後就不會出現此類問題了。（簡單有效）

Ⅲ 客戶端訪問Web伺服器，如何實現Session。

session.setAttribute("這是key值",用戶對象)；把用戶登錄進去的信息存起來
session.getAttribute(「這裡面取的是上面那個key值，名字要一摸一樣」)；這個是取出來

Ⅳ 客戶端訪問不了伺服器

一般情況下，U8伺服器的網段必須與客戶端（用戶）一致，跨網段一般會出現不能訪問。因為一般分網段就是為了隔離某些東西，自然會將U8伺服器的數據服務和應用服務隔離了，並且伺服器後台服務所使用的埠比較多、設置起來是比較麻煩的。如果確實在區域網內需要有兩個網段，可以將這個U8伺服器裝兩個網卡，各在一個網段，但這樣做對伺服器性能和WIN2003SEVER後台設置有一些要求。這樣，兩個網段里的客戶端都可以訪問U8伺服器了，建議客戶端登錄時伺服器（即「登錄到」一欄）改用IP地址。

Ⅳ 從客戶端訪問伺服器全部過程概述 （有圖）

我是全棧工程師，用到前端web,後端php，和MYSQL資料庫，客戶端是伺服器解析的靜態頁面，用戶輸入請求，ajax通過http協議發送到後端，後端接收請求，然後遍歷資料庫，找到想要的答案，在返回給客戶端，用戶就可以看到答案了，以前都是B/S架構，現在都是C/S架構，方便維護，要是還不明白，私聊我，我給你寫代碼看，你就明白了

Ⅵ 客戶端訪問某www伺服器的全部過程描述

1、打開瀏覽器，輸入域名
2、DNS將域名轉換為IP
3、本地電腦連接遠程伺服器。
4、伺服器返回網頁數據
5、瀏覽先展現給用戶。

Ⅶ 客戶端請求訪問HTML頁面與訪問servlet有什麼異同

訪問html是伺服器不做處理，只是收到請求之後，將html傳輸給你的瀏覽器，瀏覽器進行解析，你和伺服器沒有進行交互的。
servlet是伺服器端運行的java代碼，你提交的東西到了伺服器端，可以進行處理，然後返回給你的瀏覽器。

很早以前就是純html的，所以人們只能看看新聞，因為是靜態的，不能交互。後來有了動態語言，比如jsp，php等。

Ⅷ 客戶端訪問伺服器

一般都開線程的，進程的開銷比線程要大
如果是socket程序，socket的非同步IO模型基本都是需要開多線程處理的

Ⅸ 客戶端瀏覽器訪問伺服器端的原理

當我們想瀏覽一個網站的時候，只要在瀏覽器的地址欄里輸入網站的地址就可以了，例如：www.microsoft.com，但是在瀏覽器的地址欄裡面出現的卻是： http://www.microsoft.com，你知道為什麼會多出一個「http」嗎？ 一、HTTP協議是什麼 我們在瀏覽器的地址欄里輸入的網站地址叫做URL(UniformResourceLocator，統一資源定位符)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web伺服器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。因此，在我們認識HTTP之前，有必要先弄清楚URL的組成,例如： http://www.microsoft.com/china/index.htm。它的含義如下： 1. http://：代表超文本傳輸協議，通知microsoft.com伺服器顯示Web頁，通常不用輸入； 2.www：代表一個Web(萬維網)伺服器； 3.Microsoft.com/：這是裝有網頁的伺服器的域名，或站點伺服器的名稱； 4.China/：為該伺服器上的子目錄，就好像我們的文件夾； 5.Index.htm：index.htm是文件夾中的一個HTML文件(網頁)。 我們知道，Internet的基本協議是TCP/IP協議，然而在TCP/IP模型最上層的是應用層(Applicationlayer)，它包含所有高層的協議。高層協議有：文件傳輸協議FTP、電子郵件傳輸協議SMTP、域名系統服務DNS、網路新聞傳輸協議NNTP和HTTP協議等。 HTTP協議(HypertextTransferProtocol，超文本傳輸協議)是用於從WWW伺服器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。這就是你為什麼在瀏覽器中看到的網頁地址都是以「 http://」開頭的原因。 自WWW誕生以來，一個多姿多彩的資訊和虛擬的世界便出現在我們眼前，可是我們怎麼能夠更加容易地找到我們需要的資訊呢？當決定使用超文本作為WWW文檔的標准格式後，於是在1990年，科學家們立即制定了能夠快速查找這些超文本文檔的協議，即HTTP協議。經過幾年的使用與發展，得到不斷的完善和擴展，目前在WWW中使用的是HTTP/1.0的第六版。 二、HTTP是怎樣工作的 既然我們明白了URL的構成，那麼HTTP是怎麼工作呢？我們接下來就要討論這個問題。 由於HTTP協議是基於請求/響應範式的(相當於客戶機/伺服器)。一個客戶機與伺服器建立連接後，發送一個請求給伺服器，請求方式的格式為：統一資源標識符(URL)、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。伺服器接到請求後，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括伺服器信息、實體信息和可能的內容。 許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源伺服器上資源的請求。最簡單的情況可能是在用戶代理和伺服器之間通過一個單獨的連接來完成。在Internet上，HTTP通訊通常發生在TCP/IP連接之上。預設埠是TCP80，但其它的埠也是可用的。但這並不預示著HTTP協議在Internet或其它網路的其它協議之上才能完成。HTTP只預示著一個可靠的傳輸。 這個過程就好像我們打電話訂貨一樣，我們可以打電話給商家，告訴他我們需要什麼規格的商品，然後商家再告訴我們什麼商品有貨，什麼商品缺貨。這些，我們是通過電話線用電話聯系(HTTP是通過TCP/IP)，當然我們也可以通過傳真，只要商家那邊也有傳真。 以上簡要介紹了HTTP協議的宏觀運作方式，下面介紹一下HTTP協議的內部操作過程。 在WWW中，「客戶」與「伺服器」是一個相對的概念，只存在於一個特定的連接

Ⅹ Android客戶端怎樣訪問服務WEB端

HttpClient 與 HttpURLConnection 共用SessionId

下面給出訪問伺服器的截圖，向後滑動有http協議那一章，裡面與源碼，例子來自android學習手冊，裡面有源碼。android學習手冊包含9個章節，108個例子，源碼文檔隨便看，例子都是可交互，可運行，源碼採用android studio目錄結構，高亮顯示代碼，文檔都採用文檔結構圖顯示，可以快速定位。360手機助手中下載,圖標上有貝殼：

HttpClient 與 HttpUrlConnection 是Android 中HTTP操作最常見的訪問方式。在一個應用程序中有時候會用到這兩種方式，如何能讓他們共用Cookie，讓客戶端訪問伺服器保持Session進行通信。

針對httpClient 和HttpUrlConnection 獲取和發送Cookie，主要是sessionID的共享。

httpClient獲取及發送Session 值：

[java] view plain print?

HttpPosthttpPost=newHttpPost(url);

//將SessionId發給伺服器

if(null!=mSESSIONID){

httpPost.setHeader("Cookie","SESSIONID="+mSESSIONID);

}

DefaultHttpClienthttpClient=newDefaultHttpClient();

httpResponse=httpClient.execute(httpPost);

if(httpResponse.getStatusLine().getStatusCode()==HttpStatus.SC_OK){

HttpEntityentity=httpResponse.getEntity();

CookieStoremCookieStore=httpClient.getCookieStore();

List<Cookie>cookies=mCookieStore.getCookies();

//這里是讀取指定Cookie的值

for(inti=0;i<cookies.size();i++){

if("SESSIONID".equals(cookies.get(i).getName())){

mSESSIONID=cookies.get(i).getValue();

break;

}

}

}

HttpPost httpPost = new HttpPost(url);

// 將SessionId發給伺服器
if(null != mSESSIONID){
httpPost.setHeader("Cookie", "SESSIONID=" + mSESSIONID);
}

DefaultHttpClient httpClient = new DefaultHttpClient();
httpResponse = httpClient.execute(httpPost);
if (httpResponse.getStatusLine().getStatusCode() == HttpStatus.SC_OK) {
HttpEntity entity = httpResponse.getEntity();

CookieStore mCookieStore = httpClient.getCookieStore();
List<Cookie> cookies = mCookieStore.getCookies();
//這里是讀取指定Cookie 的值
for (int i = 0; i < cookies.size(); i++) {
if ("SESSIONID".equals(cookies.get(i).getName())) {
mSESSIONID = cookies.get(i).getValue();
break;
}

}
}

在程序中保存上面的sessionId ，或用全局變數，或者SharedPreferences 保存，看這個sessionId 的會話時間及程序業務。

HttpUrlConnection獲取及發送Session 值：

[java] view plain print?

HttpURLConnectionurl_con=null;

URLurl=newURL(reqUrl);

url_con=(HttpURLConnection)url.openConnection();

//設置session

if(mSESSIONID!=null){

url_con.setRequestProperty("Cookie","JSESSIONID="+mSESSIONID);

}

...

StringcookieVal=con.getHeaderField("Set-Cookie");

//獲取session

if(cookieVal!=null){

StringmSESSIONID=cookieVal.substring(0,cookieVal.indexOf(";"));

}

HttpURLConnectionurl_con=null;

HttpURLConnection url_con = null;
URL url = new URL(reqUrl);
url_con = (HttpURLConnection) url.openConnection();
//設置session
if (mSESSIONID!= null) {
url_con.setRequestProperty("Cookie","JSESSIONID="+mSESSIONID);
}
...
String cookieVal =con.getHeaderField("Set-Cookie");
// 獲取session
if (cookieVal != null) {
StringmSESSIONID= cookieVal.substring(0, cookieVal.indexOf(";"));
}
HttpURLConnection url_con = null;

HttpURLConnection和HttpClient比較（Android）:

HttpURLConnection和HttpClient 都支持HTTPS協議、IPv6、以流的形式進行上傳和下載、配置超時時間、以及連接池等功能。

DefaultHttpClient和它的兄弟AndroidHttpClient都是HttpClient具體的實現類，它們都擁有眾多的API，而且實現比較穩定，bug數量也很少。但同時也由於HttpClient的API數量過多，使得我們很難在不破壞兼容性的情況下對它進行升級和擴展，所以目前Android團隊在提升和優化HttpClient方面的工作態度並不積極。

HttpURLConnection是一種多用途、輕量極的HTTP客戶端，使用它來進行HTTP操作可以適用於大多數的應用程序。雖然HttpURLConnection的API提供的比較簡單，但是同時這也使得我們可以更加容易地去使用和擴展它。不過在Android 2.2版本之前，HttpURLConnection一直存在著一些令人厭煩的bug。比如說對一個可讀的InputStream調用close()方法時，就有可能會導致連接池失效了。那麼我們通常的解決辦法就是直接禁用掉連接池的功能：

在Android 2.3版本中還增加了一些HTTPS方面的改進，現在HttpsURLConnection會使用SNI(Server Name Indication)的方式進行連接，使得多個HTTPS主機可以共享同一個IP地址。除此之外，還增加了一些壓縮和會話的機制。如果連接失敗，它會自動去嘗試重新進行連接。這使得HttpsURLConnection可以在不破壞老版本兼容性的前提下，更加高效地連接最新的伺服器。


在Android 4.0版本中，我們又添加了一些響應的緩存機制。當緩存被安裝後(調用HttpResponseCache的install()方法)，所有的HTTP請求都會滿足以下三種情況：

1.所有的緩存響應都由本地存儲來提供。因為沒有必要去發起任務的網路連接請求，所有的響應都可以立刻獲取到。
2.視情況而定的緩存響應必須要有伺服器來進行更新檢查。比如說客戶端發起了一條類似於 「如果/foo.png這張圖片發生了改變，就將它發送給我」 這樣的請求，伺服器需要將更新後的數據進行返回，或者返回一個304 Not Modified狀態。如果請求的內容沒有發生，客戶端就不會下載任何數據。
3.沒有緩存的響應都是由伺服器直接提供的。這部分響應會在稍後存儲到響應緩存中。


由於這個功能是在4.0之後的版本才有的，通常我們就可以使用反射的方式來啟動響應緩存功能。下面的示例代碼展示了如何在Android 4.0及以後的版本中去啟用響應緩存的功能，同時還不會影響到之前的版本：

[java] view plain print?

(){

try{

longhttpCacheSize=10*1024*1024;//10MiB

FilehttpCacheDir=newFile(getCacheDir(),"http");

Class.forName("android.net.http.HttpResponseCache")

.getMethod("install",File.class,long.class)

.invoke(null,httpCacheDir,httpCacheSize);

}catch(){

}

private void enableHttpResponseCache() {
try {
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
File httpCacheDir = new File(getCacheDir(), "http");
Class.forName("android.net.http.HttpResponseCache")
.getMethod("install", File.class, long.class)
.invoke(null, httpCacheDir, httpCacheSize);
} catch (Exception httpResponseCacheNotAvailable) {
}
}

你也應該同時配置一下你的Web伺服器，在HTTP響應上加入緩存的消息頭。

哪一種才是最好的？

在Android 2.2版本之前，HttpClient擁有較少的bug，因此使用它是最好的選擇。
而在Android 2.3版本及以後，HttpURLConnection則是最佳的選擇。它的API簡單，體積較小，因而非常適用於Android項目。壓縮和緩存機制可以有效地減少網路訪問的流量，在提升速度和省電方面也起到了較大的作用。對於新的應用程序應該更加偏向於使用HttpURLConnection。