1、Unity 3d伺服器端用什麼 ?
簡單的邏輯可以在伺服器上判斷，但是涉及到物理引擎或者碰撞檢測什麼的就很難了，因為數據量大而且因為網路問題即時性也很差
2、unity3d採用什麼伺服器開發技術
首先,unity3d是一個游戲開發引擎,或者算是一個游戲開發平台,不是一項技術; 其次,unity3d在國外前幾年就在用
3、在unity3d中伺服器確定唯一一個客戶端？
你的理解是對的,一個ip只能一個player,而networkview你加了幾個就是幾個
4、unity3d生成的網頁形式直接上傳到伺服器為什麼不能打開？
在IIS上添加擴展名MIME類型，
MIME類型：application/octet-stream 擴展名：.unity3d 注意前面有個點
5、unity3d 網游伺服器端如何選擇
如果對樓主有幫助，給個採納好不，謝謝啦
Photon和KBEngineunity3d是最適用Unity3d游戲開發的兩個伺服器引擎，但它們還是有區別的，只有清楚地了解區別在哪才能正確使用，下面簡單描述下兩者的共同點和不同點。
語言
對於大部分的程序員語言簡直就是宗教信仰。
Photon使用C#開發，當然使用者也是用C#進行各類游戲功能開發。前後端同種語言，這對使用Unity3d游戲開發也有很大的好處。
KBEngine使用C++開發，邏輯開發是用python，也是很不錯很快速的。
開源與收費情況
Photon是Exit Games公司的產品，不開源，有好多種收費模式，官網上可以看到。開發階段可以用免費的license，後期可以看流量用戶活躍度來選擇付費模式。後續的支持，似乎是免費的，你可以選擇郵件或是到論壇發帖求助，當然是E文。
KBEngine是國人開發，開源免費，但從官網上並沒有看到商業使用的案例。有中文論壇，你可以在論壇上向開發者求助。
雖然兩者的模式不同，但作為一個Unity3d游戲開發者，我們最希望的其實是把游戲引擎當作一個安全穩定的黑箱。
操作系統
之前說了Photon使用C#開發很自然的，配套的工具也是使用C#，比如最重要的PhotonControl。所以開發環境和生產環境最好都是windows。
雖然在跨平台上有mono，在伺服器代碼部分是系統無關的，但是不管你信不信，我是不信它的一套窗體工具也能運行在Linux下。反正，官網說法是，開發和生產環境都是用windows。
KBEngine建議開發環境選擇Windows，生產環境選擇linux。畢竟你總不希望開一組伺服器打開9個Console窗體，一不小心把哪個點X了吧～
協議
Photon有自己的序列化反序列化方式，你也可以使用protobuf這類的來做應用層傳輸協議。
KBEngine在這方面表示不支持自定義協議，它幫你選擇了有效的方法來處理，如果你習慣了他規定的方式，會喜歡上的。
看法
在功能上，我毫無疑問地更喜歡KBEngine，腳本化和自動持久化是極富魅力的功能。而Photon幾乎沒做這方面的功能，可能和老外的觀念有關系。就目前我對兩者功能的理解看來，Photon其實是個和SuperSocket差不多的東西，而SS是作為輕量級伺服器框架存在的，Photon卻是說自己是Unity3d游戲引擎，除去提供的MMO示例代碼(未解讀)，沒看到什麼游戲引擎的魅力。
6、unity3d 怎麼請求java伺服器
只是負責驗證用戶名和密碼，驗證之後返回token，token是有有效時間的，在有效時間內，並沒有保持連接的必要，所以，這里的RequestResponse可以做成短連接（http請求響應模式），提升並發。如果超過了有效時間還沒有進入游戲，令牌失效，在登錄驗證時將被踢回重新獲取令牌。登錄伺服器和網關之間需要有一個固定的連接傳遞新生成的令牌。
7、unity3d伺服器怎麼給客戶端發數據
說的是什麼情況下的吖？如果是Linux C語言編程的話，可以用read,fread,recv,recvfrom等等函數來讀取伺服器發送的數據吖。
8、unity3d 做web游戲,伺服器怎麼發送模型給客戶端顯示出來？
就是網頁游戲吧，客戶端訪問你 的網站網頁時會要求他安裝UNITY3D WEB插件，完了你 的 網頁（包括裡面的模型等等）就會呈現在客戶端。 叫B/S瀏覽器/客戶端模式吧
還有的 是網路游戲c/s（伺服器/客戶端）模式，客戶下載你 的 應用文件（游戲文件），裡面就 包含了 模型，客戶運行游戲，當然是 有 模型顯示了 ，
至於要顯示什麼模型？！！！！！。。。。。。。。。。。。。。。。
9、怎麼配置linux伺服器的unity3d發布的web的沙盒安全機制
Apache 伺服器的安全特性
1、 採用選擇性訪問控制和強制性訪問控制的安全策略
從Apache 或Web的角度來講，選擇性訪問控制DAC（Discretionary Access Control）仍是基於用戶名和密碼的，強制性訪問控制MAC（Mandatory Access Control）則是依據發出請求的客戶端的IP地址或所在的域號來進行界定的。對於DAC方式，如輸入錯誤，那麼用戶還有機會更正，從新輸入正確的的密碼；如果用戶通過不了MAC關卡，那麼用戶將被禁止做進一步的操作，除非伺服器作出安全策略調整，否則用戶的任何努力都將無濟於事。
2、Apache 的安全模塊
Apache 的一個優勢便是其靈活的模塊結構，其設計思想也是圍繞模塊（Moles）概念而展開的。安全模塊是Apache Server中的極其重要的組成部分。這些安全模塊負責提供Apache Server的訪問控制和認證、授權等一系列至關重要的安全服務。
mod_access模塊能夠根據訪問者的IP地址（或域名，主機名等）來控制對Apache伺服器的訪問，稱之為基於主機的訪問控制。
mod_auth模塊用來控制用戶和組的認證授權（Authentication）。用戶名和口令存於純文本文件中。mod_auth_db和mod_auth_dbm模塊則分別將用戶信息（如名稱、組屬和口令等）存於Berkeley-DB及DBM型的小型資料庫中，便於管理及提高應用效率。
mod_auth_digest模塊則採用MD5數字簽名的方式來進行用戶的認證，但它相應的需要客戶端的支持。
mod_auth_anon模塊的功能和mod_auth的功能類似，只是它允許匿名登錄，將用戶輸入的E-mail地址作為口令。
SSL（Secure Socket Lager），被Apache所支持的安全套接字層協議，提供Internet上安全交易服務，如電子商務中的一項安全措施。通過對通訊位元組流的加密來防止敏感信息的泄漏。但是，Apache的這種支持是建立在對Apache的API擴展來實現的，相當於一個外部模塊，通過與第三方程序的結合提供安全的網上交易支持。
Apache伺服器的安全配置
Apache具有靈活的設置，所有Apache的安全特性都要經過周密的設計與規劃，進行認真地配置才能夠實現。Apache伺服器的安全配置包括很多層面，有運行環境、認證與授權設置等。Apache的安裝配置和運行示例如下：
1、以Nobody用戶運行
一般情況下，Apache是由Root 來安裝和運行的。如果Apache Server進程具有Root用戶特權，那麼它將給系統的安全構成很大的威脅，應確保Apache Server進程以最可能低的許可權用戶來運行。通過修改httpd.conf文件中的下列選項，以Nobody用戶運行Apache 達到相對安全的目的。
User nobody
Group# -1
2、ServerRoot目錄的許可權
為了確保所有的配置是適當的和安全的，需要嚴格控制Apache 主目錄的訪問許可權，使非超級用戶不能修改該目錄中的內容。Apache 的主目錄對應於Apache Server配置文件httpd.conf的Server Root控制項中，應為：
Server Root /usr/local/apache
3、SSI的配置
在配置文件access.conf 或httpd.conf中的確Options指令處加入Includes NO EXEC選項，用以禁用Apache Server 中的執行功能。避免用戶直接執行Apache 伺服器中的執行程序，而造成伺服器系統的公開化。Options Includes Noexec
4、阻止用戶修改系統設置
在Apache 伺服器的配置文件中進行以下的設置，阻止用戶建立、修改 .htaccess文件，防止用戶超越能定義的系統安全特性。AllowOveride None
Options None
Allow from all然後再分別對特定的目錄進行適當的配置。
5、改變Apache 伺服器的確省訪問特性
Apache 的默認設置只能保障一定程度的安全，如果伺服器能夠通過正常的映射規則找到文件，那麼客戶端便會獲取該文件，如http://local host/~ root/ 將允許用戶訪問整個文件系統。在伺服器文件中加入如下內容：order deny,ellow
Deny from all將禁止對文件系統的預設訪問。
6、CGI腳本的安全考慮
CGI腳本是一系列可以通過Web伺服器來運行的程序。為了保證系統的安全性，應確保CGI的作者是可信的。對CGI而言，最好將其限制在一個特定的目錄下，如cgi-bin之下，便於管理；另外應該保證CGI目錄下的文件是不可寫的，避免一些欺騙性的程序駐留或混跡其中；如果能夠給用戶提供一個安全性良好的CGI程序的模塊作為參考，也許會減少許多不必要的麻煩和安全隱患；除去CGI目錄下的所有非業務應用的腳本，以防異常的信息泄漏。
以上這些常用的舉措可以給Apache Server 一個基本的安全運行環境，顯然在具體實施上還要做進一步的細化分解，制定出符合實際應用的安全配置方案。
Apache Server基於主機的訪問控制
Apache Server默認情況下的安全配置是拒絕一切訪問。假定Apache Server內容存放在/usr/local/apache/share 目錄下，下面的指令將實現這種設置：Deny from all
Allow Override None則禁止在任一目錄下改變認證和訪問控制方法。
同樣，可以用特有的命令Deny、Allow指定某些用戶可以訪問，哪些用戶不能訪問，提供一定的靈活性。當Deny、Allow一起用時，用命令Order決定Deny和Allow合用的順序，如下所示：
1、 拒絕某類地址的用戶對伺服器的訪問權（Deny）
如：Deny from all
Deny from test.cnn.com
Deny from 204.168.190.13
Deny from 10.10.10.0/255.255.0.0
2、 允許某類地址的用戶對伺服器的訪問權（Allow）
如：Allow from all
Allow from test.cnn.com
Allow from 204.168.190.13
Allow from 10.10.10.0/255.255.0.0
Deny和Allow指令後可以輸入多個變數。
3、簡單配置實例：
Order Allow, Deny
Allow from all
Deny from www.test.com
指想讓所有的人訪問Apache伺服器，但不希望來自www.test.com的任何訪問。
Order Deny, Allow
Deny from all
Allow from test.cnn.com
指不想讓所有人訪問，但希望給test.cnn.com網站的來訪。
Apache Sever的用戶認證與授權
概括的講，用戶認證就是驗證用戶的身份的真實性，如用戶帳號是否在資料庫中，及用戶帳號所對應的密碼是否正確；用戶授權表示檢驗有效用戶是否被許可訪問特定的資源。在Apache中，幾乎所有的安全模塊實際上兼顧這兩個方面。從安全的角度來看，用戶的認證和授權相當於選擇性訪問控制。
建立用戶的認證授權需要三個步驟：
1、建立用戶庫
用戶名和口令列表需要存在於文件（mod_auth模塊）或資料庫（mod_auth_dbm模塊）中。基於安全的原因，該文件不能存放在文擋的根目錄下。如，存放在/usr/local/etc/httpd下的users文件，其格式與UNIX口令文件格式相似，但口令是以加密的形式存放的。應用程序htpasswd可以用來添加或更改程序：
htpasswd –c /usr/local/etc/httpd/users martin
-c表明添加新用戶，martin為新添加的用戶名，在程序執行過程中，兩次輸入口令回答。用戶名和口令添加到users文件中。產生的用戶文件有如下的形式：
martin:WrU808BHQai36
jane:iABCQFQs40E8M
art:FadHN3W753sSU
第一域是用戶名，第二個域是用戶密碼。
2、配置伺服器的保護域
為了使Apache伺服器能夠利用用戶文件中的用戶名和口令信息，需要設置保護域（Realm）。一個域實際上是站點的一部分（如一個目錄、文檔等）或整個站點只供部分用戶訪問。在相關目錄下的.htaccess文件或httpd.conf ( acces.conf ) 中的段中，由AuthName來指定被保護層的域。在.htaccess文件中對用戶文件有效用戶的授權訪問及指定域保護有如下指定：
AuthName 「restricted stuff」
Authtype Basic
AuthUserFile /usr/local/etc/httpd/users
Require valid-user
其中，AuthName指出了保護域的域名（Realm Name）。valid-user參數意味著user文件中的所有用戶都是可用的。一旦用戶輸入了一個有效的用戶/口令時，同一個域內的其他資源都可以利用同樣的用戶/口令來進行訪問，同樣可以使兩個不同的區域共用同樣的用戶/口令。
3、告訴伺服器哪些用戶擁有資源的訪問許可權
如果想將一資源的訪問許可權授予一組客戶，可以將他們的名字都列在Require之後。最好的辦法是利用組（group）文件。組的操作和標準的UNIX的組的概念類似，任一個用戶可以屬於一個和數個組。這樣就可以在配置文件中利用Require對組賦予某些許可權。如：
Require group staff
Require group staff admin
Require user adminuser
指定了一個組、幾個組或一個用戶的訪問許可權。
需要指出的是，當需要建立大批用戶帳號時，那麼Apache伺服器利用用戶文件資料庫將會極大地降低效率。這種情況下，最好採用資料庫格式的帳號文件，譬如 DBM資料庫格式的文件。還可以根據需要利用db格式（mod_auth_db）的數據文件，或者直接利用資料庫，如：mSQL（mod_auth_msql）或DBI兼容的資料庫（mod_auth_dbi）。