如何讓用戶接入伺服器

❶ 如何連接伺服器

1、從伺服器商後台獲得：

1、IP

2、遠程埠（一般默認3389）

3、賬號

4、密碼

2、下載iis7伺服器管理工具：iis7伺服器管理工具

1、找到WIN 添加剛才獲取到的信息，先勾選，也可以滑鼠右鍵 點打開

2、如果你的伺服器是LINUX的，也可以用上面的方法鏈接伺服器

❷ 怎樣才能同時讓多個用戶遠程桌面到該伺服器上

1、首先在計算機-管理中添加需要添加的N個用戶，然派稿碰後把這些用戶歸屬於某一個本地組敬拿（如組名為User）。 2、要設置自定義終端服務連接許可權， 請執行以下操作步驟： （1）. 單擊開始，指向程序，指向管理工具，然後單擊終端服務配置。 （2）. 打開連接文件夾。 （3）. 右鍵單擊連接 (RDP-TCP)，然後單擊屬性。 （4）塵談. 在許可權選項卡上，添加需要訪問此連接的組（User）。 （5）. 單擊確定。

❸ 域用戶如何加入域，如何登陸伺服器

1、再電腦桌面上找到搜索系統，直接搜索「控制面板亂瞎好」。

❹ 內網用戶連接遠程域伺服器

看一下如何把下面的工作站加入到域。
由於從網路安全性考慮，盡量少的使用域管理員帳號，所以先在域控制器上建立一個委派帳號，登陸到域控制器，運行「dsa.msc」，出現「AD用戶和計算機」管理控制台:
先來新建一個用戶，展開「demo.com」，在「Users」上擊右鍵，點「新建」-「用戶」:
然後出現一個新建用戶的向導，在這里，我新建仔嘩了一個名為「swg」的用戶，並且把密碼設為「永不過期」。

這樣點嘩戚高「下一步」，直到完成，就可以完成用戶的創建。然後在「demo.com」上點擊右鍵，先擇「委派控制」:
就會出現一個「委派控制向導」:
點擊「下一步」:
點擊中間的「添加」按鈕，並輸入剛剛創建的「swg」帳號:
然後點「確定」:
再點「下一步」:
選擇「將計算機加入到域」，然後點「下一步」:
最後是一個信息核對畫面，要是沒有什麼問題的話，直接點「完成」就可以了。
接下來轉到客戶端，看看怎麼把XP進來，在實驗中採用的客戶端操作系統是Windows XP專業版，需要大家注意的是Windows XP 的Home版由於針對的是家庭用戶，所以不能加入域亂尺，大家別弄錯了喲，我們先來設置一下這台XP的網路:
計算機名:TestXP
IP:192.168.5.5
子網掩碼:255.255.225.0
DNS伺服器:192.168.5.1，
設置完網路以後，在「我的電腦」上擊右鍵，選「屬性」，點「計算機名」。
在這里把「隸屬於」改成域，並輸入:「demo.com」，並點確定，這是會出現如下畫面:
輸入剛剛在域控上建的那個「swg」的帳號，點確定就可以進入伺服器起系統

如此循環，有幾台電腦要使用到與伺服器，就建立幾個賬戶。。。重復上邊的伺服器和客戶端的用戶添加就可以了。。。

PS：伺服器2003操作系統為例， 客戶端WINDOWSXP為例

❺ 客戶端如何連接伺服器

客戶端通過終端（終端有下載的軟體，包括瀏覽器也屬於終端），通過一個埠，連接到伺服器指定的埠。伺服器會監聽這個埠，如何有這個埠的應用訪問，則和終端用戶交互，從而達到客戶端連接伺服器的作用。

❻ 如何讓手機能連接到我們的伺服器啊

首先打開「運行」，輸入:services.msc 找到裡面的wireless Zero Configeration 把禁用改成啟動，然後網上鄰居→屬性→無線網路連接→屬性→無線網路配置里的「WINdows配置睜汪我的無線網路連接屬性」這欄打鉤。

❼ 自建權威DNS-如何讓用戶就近接入

引子：
外網DNS是用戶訪問網站的第一道門，如果外網DNS調度不準確，會出現跨網，跨地域等問題，調度問題是外網DNS關注的首要問題。如何讓用戶就近接入？有沒有好的設置方法可供參考？

調度問題直觀的表現是VIEW設置多少個，ACL是否匹配正確。ACL設置一般企業會采購IPIP庫的結果，國內基本可以得到正確的結果，海外的IPIP歸屬地也不會有很大的波動。如果請求能正常到達要訪問的權威伺服器，看似就萬事大吉了。但是在觀察業務數據的時候，發現問題並沒有那麼簡單。

這是一個演變的過程，按照改進的過程敘述。
第一步：國內一般的方法是華北，華東，華南，三個地域建ns。海外選擇離業務近的點建ns。中國和海外的ns設置不同的地址。自建權威伺服器注冊到DNS服務商。按照地域順序往後排序。每個view配置相同的ns。認為DNS解析會按照最近的NS來請求。
問題：
前兩台NS會收到很多訪問的請求，用戶的來源IP和之前給這個NS設定的覆蓋范圍也不一致，其他的NS請求量相對低。和用戶分布的趨勢不符合。
如果這樣的話，即使分了ACL，也沒有達到多個NS覆蓋多個的問題。用戶域名請求的時間仍舊很高。那麼local DNS不是應該像很多NS同時發請求，然後選擇一個就近的接入，以後就按照這個NS來請求嗎？
當然不會，這樣用戶還需要在不同的NS上隨機挑選，這樣更加增加了local DNS的請求時間。

local DNS第一次解析域名的時候，ns的地址是由.com權威提供的，本地遞歸DNS最終是緩存權威DNS上的ns記錄。.com權威提供的方式是通過glue記錄。在注冊域名的時候，需要額外填寫。
glue記錄是非常容易忽略的一個問題，應該搭建常規的DNSserver並不是必須的選項，因此常常會忽略，我也是在注意到問題之後，才發現對glue記錄並不慧早好了解。
加入睜旦沒有glue記錄，local DNS拿到了請求之後，還要在詢問NS地址是什麼，
查看 www..com 的glue記錄：
請求命令：
dig www..com

位於返回請求的ADDITIONAL SECTION中。

實驗驗證一下第一次請求的過程：
先來看一下請求前鉛的TTL值

第二次遞減：

第三次遞減：

變為0:

重新開始請求：

看下對應的抓包過程：
第一次請求的過程：

A.root-servers.net198.41.0.4美國
E.root-servers.net192.203.230.10美國
分別像這幾個根存問結果：
首先像 J.root-servers.net192.58.128.30美國 詢問，
給伺服器回復了 *.gtld-servers.net的地址 .com頂級域

com回復之後，繼續往下看：

com回復了的ns

本地遞歸DNS最終是緩存權威DNS上的NS記錄。

如果想實現按照NS調度，不同的View應該配置不同的NS地址，用戶請求從com得到請求之後，再去查詢NS ，就會按照NS配置的地址到想讓他去的NS解析了。不足之處，第一次因為從glue拿地址，所以第一次沒有辦法實現智能解析

minimal-responses
如果是yes，當產生響應的時候，伺服器將只會按照需要將記錄添加到authority和additional的數據部分。（例如，delegations，negative responses）。這樣會改善伺服器的性能。默認值為no。

❽ 各位大神，怎樣讓手機客戶端能快速連接到推送伺服器

一、消息推送基礎
消息推送，就是在互聯網上通過定期傳送用戶需要的信息來減少信息過載的一項新技術。推送技術通過自動傳送信息給用戶，來減少用於網路上搜索的時間。它根據用戶的興趣來搜索、過濾信息，並將其定期推給用戶，幫助用戶高效率地發掘有價值的信息
當我們開發需要和伺服器交互的移動應用時，基本上都需要和伺服器進行交互，包括上傳數據到伺服器，同時從伺服器上獲取數據。
一般情況下，客戶端與伺服器之間枝逗通訊客戶端是主動的，但這就存在一個問題就是一旦伺服器數據有更新或者伺服器要下發通知給客戶端只能等客戶端連接的時候才能實現。這種方式使消息失去了實時性。
如何使客戶端能夠實時的收到伺服器的消息和通知，總體來說有兩種方式，第一種是客戶端使用Pull（拉）的方式，就是隔一段時間就去伺服器上獲取一下信息，看是否有更新的信息出現。第二種就是 伺服器使用Push（推送）的方式，當伺服器端有新信息了，則把最新的信息Push到客戶端上。這樣，客戶端就能自動的接收到消息。 
雖然Pull和Push兩種方式都能實現獲取伺服器端更新信息的功能，但是明顯來說Push方式比Pull方式更優越。因為Pull方式更費客戶端的網路流量，更主要的是費電量，還需要我們的程序不停地去監測服務端的變化。  
二、幾種常見的解決方案實現原理
1）輪詢(Pull)方式：客戶端定時向伺服器發送詢問消息，一旦伺服器有變化則立即同步消息。
2）SMS(Push)方式：通過攔截SMS消息並且解析消息內容來了解伺服器的命令，但這種方式一般用戶在經濟上很難承受。
3）持久連接(Push)方式：客戶端和伺服器之間建立長久連接，這樣就可以實現消息的及時行和實時性。
三、消息推送解決方案概述
A、C2DM雲端推送方案
在Android手機平台上，Google提供了C2DM（Cloudto Device Messaging）服務。Android Cloud to Device Messaging (C2DM)是一個用來幫助開發者從伺服器型搭判卜改向Android應用程序發送數據的服務。該服務提供了一個簡單的、輕量級的機制，允許伺服器可以通知移動應用程序直接與伺服器進行通信，以便於從伺服器獲取應用程序更新和用戶數據。
該方案存在的主要問題是C2DM需要依賴於Google官方提供的C2DM伺服器，由於國內的網路環境，這個服務經常不可用。
B、MQTT協議實現Android推送
採用MQTT協議實現Android推送功能也是一種解決方案。MQTT是一個輕量級的消息發布/訂閱協議，它是實現基於手機客戶端的消息推送伺服器的理想解決方案。
wmqtt.jar 是IBM提供的MQTT協議的實現。我們可以從這里（https://github.com/toku/AndroidPushNotificationsDemo）下載該項目的實例代碼，並且可以找到一個採用php書寫的伺服器端實現（https://github.com/toku/PhpMQTTClient）。
C、RSMB實現推送功能
Really Small Message Broker (RSMB) ，是一個簡單的MQTT代理，同樣由IBM提供，其查看地址是：http://www.alphaworks.ibm.com/tech/rsmb。預設打開1883埠，應用程序當中，它負責接收來自伺服器的消息並將其轉發給指定的移動設備。SAM是一個針對MQTT寫的PHP庫。我們可以從這個http://pecl.php.net/package/sam/download/0.2.0地址下載它.
D、XMPP協議實現Android推送
Google官方的C2DM伺服器底層也是採用XMPP協議進行的封裝。XMPP(可擴展通訊和表示協議)是基於可擴展標記語言（XML）的協議，它用於即時消息（IM）以及在線探測。這個協議可能最終允許網際網路用戶向網際網路上的其他任何人發送即時消息。
androidpn是一個基於XMPP協議的java開源Android push notification實現。它包含了完整的客戶端和伺服器端。但也存在一些不足之處：
1） 比如時間過長時，就再也收不到推送的信息了。
2）性能上也不夠穩定。
3）如果將消息從伺服器上推送出去，就不再管理了，不管消息是否成功到達客戶端手機上。
如果我們要使用androidpn，則還需要做大量的工作，需要理解XMPP協議、理解Androidpn的實現機制，需要調試內部存在的BUG。
E、使用第三方平台
目前國內、國外有一些推送平台可供使用，但是涉及到收費問題、保密問題、服務質量問題、擴展問題等等，又不得不是我們望而卻步。
四、消息推送完美方案
綜合以上論述，在建立Android消息推送方面可謂方案多多，但每一款方案都有其優缺點。但無論如何，還是自己搭建一個推送平台是上策。因為你有、他有不如自己有。
舉個例子，在搭建自有推送平台上建議使用《某某Android消息推送組件》。該組不僅可以拿來即用，並且還可以提供源碼以便擴展，實現自己的特殊需求。
A、推送原理
Android消息推送組件基於XMPP協議實現Android推送。XMPP（可擴展通訊和表示協議）是基於可擴展標記語言（XML）的協議，它用於即時消息（IM）以及在線探測。這個協議可能最終允許網際網路用戶向網際網路上的其他任何人發送即時消息。