為什麼php,jsp很少用於遊戲服務端的開發？

01-28

我最近想了一下，大部分的遊戲服務端框架都是用c++(C++嵌入python或者lua),Java，Golang等實現的。為什麼很少用php,jsp來實現的。
比如一個怪物攻擊的部分，遊戲服務端用C++實現或者用嵌入的腳本語言實現或者用Java，Golang實現。

下面是偽代碼

如果怪物看到玩家距離&>30米處

不攻擊，繼續巡邏

如果怪物看到玩家距離&<=30米處
準備發動攻擊，追擊玩家

如果怪物看到玩家距離&<=5米處
對玩家發動攻擊

我想了想用php或者jsp等頁面腳本同樣也可以實現類似等等遊戲服務端的功能，為什麼遊戲很少用呢？

記得看過一篇訪談遊戲開發團隊的新聞，開發者談到，當時他們也是用php實現了遊戲服務端的功能，但是運行後發現性能不行，所以把遊戲服務端換成用C++來實現。我搜索了一下相關問題，有人回答說，項目用什麼語言，取決於開發成員對語言的熟悉度，哪種語言熟悉用哪種。遊戲服務端的語言選擇也是這樣。（對於這個回答，我表示懷疑。）

有人回答是因為長連接短連接的問題造成的。

有朋友回答：

為什麼PHP和C在online game中在通訊層面會共存這兩種語言？

這個問題的根本在於，實際業務的要求，比如以下兩種應用場景：

用戶登錄、用戶驗證、用戶充值介面（尤其是充值介面，更多的是類似支付寶這種平台對己方API的調用），這種場景用web語言更加合適；

需要Socket長連接的業務場景，比如聊天、同屏戰鬥、組隊副本等，這些場景試用編譯型語言更加合適；

我搜索了一下長連接和短連接的知識

Socket長連接和短連接的區別是

短連接的操作步驟是：

建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接

長連接的操作步驟是：

建立連接——數據傳輸...（保持連接）...數據傳輸——關閉連接

短連接多用於操作頻繁，點對點的通訊，而且連接數不能太多的情況。

每個TCP連接的建立都需要三次握手，每個TCP連接的斷開要四次握手。

如果每次操作都要建立連接然後再操作的話處理速度會降低，所以每次操作後，下次操作時直接發送數據就可以了，不用再建立TCP連接。例如：資料庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，頻繁的socket創建也是對資源的浪費。

短連接：web網站的http服務一般都用短連接。因為長連接對於伺服器來說要耗費一定的資源。像web網站這麼頻繁的成千上萬甚至上億客戶端的連接用短連接更省一些資源。試想如果都用長連接，而且同時用成千上萬的用戶，每個用戶都佔有一個連接的話，可想而知伺服器的壓力有多大。所以並發量大，但是每個用戶又不需頻繁操作的情況下需要短連接。總之：長連接和短連接的選擇要根據需求而定。

我的理解是

在遊戲場景中，遊戲客戶端和遊戲服務端長時間存在著大量頻繁的數據交換，所以需要socket長連接，保證數據不斷的傳輸。而如果是用php,jsp實現遊戲服務端，php本質是用c socket實現的http協議，在這個運行環境下運行的php 腳本語言。而jsp是用java socket實現的http協議，在這個運行環境下運行jsp語言。http是短連接，每次客戶端收到服務端的數據就會斷開。如果是用在遊戲場景中，遊戲客戶端和遊戲服務端長時間存在著大量頻繁的數據交換，在這種情況下，http短連接每次收到數據就要斷開，然後下次得到數據又要重新連接在一起，這種斷開再次連接需要耗費大量的時間和cpu 內存資源導致了 http協議很少用於遊戲服務端的開發，或者說是php,jsp很少用於遊戲服務端的開發，是因為這些頁面技術用的是socket短連接，不勝任遊戲頻繁的數據交換的要求。

問題1：

總結下來，想問問，到底是「項目用什麼語言，取決於開發成員對語言的熟悉度，哪種語言熟悉用哪種。遊戲服務端的語言選擇也是這樣。」還是「長連接和短連接在長時間遊戲客戶端和遊戲服務端頻繁交換數據上的優劣導致」還是其他原因導致php,jsp很少用於遊戲服務端的開發？

問題2：

在遊戲場景中，遊戲客戶端和遊戲服務端長時間存在著大量頻繁的數據交換。是因為socket短連接得到數據之後，關閉下次要數據，又要重新連接，導致在這種情況下，socket 長連接比socket短連接性能更好嗎？

在這應用場景下，頻繁斷開重新連接是導致socket短連接不如socket長連接
性能的主要原因嗎？而這個原因是造成上述提到的遊戲團隊因為php在遊戲服務端性能不佳，在遊戲服務端換成c++來實現的原因嗎？

問題好長，沒全部看完~

問題1：

到底是「項目用什麼語言，取決於開發成員對語言的熟悉度，哪種語言熟悉用哪種。遊戲服務端的語言選擇也是這樣。」還是「長連接和短連接在長時間遊戲客戶端和遊戲服務端頻繁交換數據上的優劣導致」還是其他原因導致php,jsp很少用於遊戲服務端的開發？

短連接就導致了某些遊戲根本無法使用http協議進行通訊，這個「某些」中就包括了人民群眾喜聞樂見的arpg，因此導致了使用php和jsp進行伺服器開發的團隊有著局限性。弱交互（棋牌類）遊戲還是可以使用http 加輪詢來實現。當然可能一輩子就只能做弱交互的了（大部分手游就是這樣）。

問題2：

在遊戲場景中，遊戲客戶端和遊戲服務端長時間存在著大量頻繁的數據交換。是因為socket短連接得到數據之後，關閉下次要數據，又要重新連接，導致在這種情況下，socket 長連接比socket短連接性能更好嗎？

http照樣可以設置為keep-alive來保留底層的tcp連接，因此不是這個原因，不過http協議需要傳送和解析一個不需要的協議頭，這點肯定是會有影響的，但是沒做個benchmark test也沒了解過具體的差別。

總之~感覺socket還是網遊伺服器的主流~

題主需要明確幾個概念：

1： php 是腳本語言和c，c++不是一個語言層次，其運行在對應的腳本語言解釋器上面

2：遊戲服務端包含很多東西，語言只是一部分

結論：採用什麼技術和你開發的遊戲類型有很大關係。

社交遊戲：

首先有很多網頁以及社交遊戲是用 web 開發技術開發的，例如爬牆看這個：

http://www.slideshare.net/wooga/redis-to-the-rescue

這個公司分享了很多社交遊戲開發的技術。

這類web技術就是 php ， ruby on rails， http等技術的。

棋牌：

那麼題主想問的是實時交互比較強的遊戲開發技術：

例如棋牌可以採用xmpp技術參考這個：

Chesspark Design Details Part 1: Why XMPP?

採用im 聊天伺服器搭建的遊戲後端

mmorpg:

如果是mmorpg這類，對性能要求很高，自然一般都是c++, java，這一套技術是從quake開始就養成習慣的，不過服務端也可以用腳本，常用就是 lua python腳本，php 作為腳本語言確實沒有在這個領域有什麼應用。

http://fabiensanglard.net/

因此採用任何技術一方面根據前人的經驗，另一方面根據自己遊戲的需求。

高實時 quake 方案

回合棋牌 xmpp 方案

社交 web方案

從上面也可以看出來網路遊戲對實時性的要求決定了採用什麼網路技術。

服務端開發需要一整套方案，而採用什麼腳本語言，例如 php 還是 lua 還是python 只是方案的一部分。

伺服器對網路實時性的處理能力是底層架構決定的即基於 http協議，還是基於udp，或者基於tcp 或者基於 xmpp，這個能力和上層腳本關係不大，除非整個伺服器都是腳本實現的，例如 lua實現的 prosody xmpp伺服器。

我來說一下個人感覺吧...

一種語言被開發出來之後，肯定有其優勢有其劣勢.這是沒辦法避免的，在某種需求下，在性能或者開發成本上，都肯定有最優語言.（java是面向對象的，而erlang是面向函數的，這種基礎的設定肯定會導致不同的語言特性）

不同類型的遊戲對於通訊和邏輯運算的性能、內存需求都可能不一樣，只不過java，c++這樣的語言綜合性能比較好，適應性強，所以大多用這樣的語言來開發.php和jsp開發的遊戲我相信肯定有，只不過不適用於絕大部分遊戲而已，所以非常非常少見.

至於開發遊戲應該選擇哪種語言，應該是在滿足當前遊戲需求的情況下，找自己熟悉的那一個.

關於socket長鏈接和短鏈接.

現在絕大部分遊戲都是長鏈接了，一個是因為當前網路環境越來越好，足以支撐長鏈接通訊了，另一個是，在相同語言處理相同的請求下，短鏈接消耗的性能天然就要高一些（比如每次通訊都要判斷這個消息是哪個玩家發出來的，而長鏈接一個玩家一次登陸正常情況下只會保持一個鏈接，這個socket是跟玩家一直是關聯起來的，只需要登陸的時候綁定一次）

http協議的短鏈接遊戲還是有很多的，之前很多網頁遊戲就是用的http，只不過，在網路環境越來越好，在需求越來越複雜的情況下，短鏈接的遊戲會越來越少.

所以歸根結底，選擇用哪種語言是因為它在當前需求下，在團隊能力內，它是最優的.

十多年前就是用cgi jsp 等寫頁游的啊。

還有當時的網路社區，比如第九城市這樣的都是cgi寫的吧

要考慮歷史的進程啊。

因為網路遊戲如果要求實時性越強，對服務端的要求越高。（這個需要自己動手去體會一下不同遊戲類型多個客戶端不同步的各種問題）如果只是回合制，PHP和JSP都沒問題，採用輪詢就行了。

還有一般遊戲服務端採用的有兩種協議可以選擇：TCP和UDP。在以前UDP並不成熟，很容易出現斷線，外掛等情況，這幾年由於unity的普及，還有一些新解決方案的誕生，很多遊戲才開始使用UDP。

但是在以前要求實時性強，基於TCP的時候。PHP和JSP是完全滿足不了需求的，PHP到了後來出現swoole和workerman這種高性能框架出現才可以的，總不能讓以前的網路遊戲項目等到swoole和workerman這種高性能框架出現。JSP如果採用JAVA是可以的，JAVA很久以前就可以了。

C和C++做服務端性能好，但是對開發人員要求高，開發時間成本高。一般會嵌入lua做腳本來輔助開發。但是總體成本還是太高了。

JAVA和C#是完全沒問題，特別是C#，性能和內存回收一定也不遜色C++，而且對開發人員要求也不高。

node.js和php也可以，node.js是這幾年興起，php在Swoole出現之後也開始可以了。

簡單一句話，PHP在swoole和workerman這種高性能框架出現之前是不可以的，因為性能不夠。

我們現在就是在用PHP做遊戲後端，底層是我基於swoole寫的框架，單個16核伺服器能抗2W在線。

PHP能不能開發遊戲伺服器呢?我可以很肯定地說,能.

比如 Minecraft Pocket Edition 的伺服器端就是用PHP實現.

遊戲強調實時交互,跟即時通訊有共同點.

所以可以看看PHP能不能用來開發即時通訊軟體,答案是能.

方案有哪些?我知道的就有Swoole,WorkerMan,ReactPHP.

這幾個東西底層都依賴C實現的PHP擴展(PECL).

比如Swoole依賴Swoole擴展,WorkerMan和ReactPHP依賴event(libevent)擴展.

這些PECL擴展的共同點都是利用了操作系統提供的非同步非阻塞機制如Linux的epoll,所以能輕鬆維持大量的連接.

比如用 Swoole 起一個 swoole_websocket_server 服務:

監聽 request 事件就能處理HTTP.

監聽 open 和 message 事件就能處理WebSocket.

監聽 connect 和 receive 事件就能處理TCP(支持MQTT).

監聽 packet 事件就能處理UDP.

HTTP/WebSocket/TCP在連接關閉時,都會觸發 close 事件.

在Swoole提供的這些事件的回調函數里,你可以用PHP寫你的邏輯.因為Swoole提供了非同步的HTTP/WebSocket/Redis/MySQL客戶端和定時器,你可以輕鬆用PHP寫出非阻塞的代碼.又因為Swoole提供了一套多進程架構,所以不用擔心多核利用的問題.Swoole甚至還貼心的實現了心跳檢測和日誌記錄的功能,讓PHP開發者能夠專註於開發業務邏輯.

雖然PHP也有Swoole這些好東西,但為什麼少有公司用PHP開發遊戲伺服器呢?很簡單,因為網路遊戲開發成本高,風險大,說不定很多沒什麼技術實力,財力也不夠的小公司,都不知道從哪裡搞來一套人家的代碼,然後二次開發上線運營,而這些代碼可能大多數都用傳統的C/C++實現.

比如說蘑菇街開源的C++實現的即時通訊軟體TeamTalk,因為跟網易泡泡有版權糾紛,最後也有始無終了.

不過我相信,隨著Node.js SocketIO和PHP Swoole這類支持腳本開發的框架的成熟,以後會有越來越多的公司使用腳本語言來開發即時通訊和遊戲伺服器.畢竟腳本語言開發成本低,部署成本低,運維也容易.

補充:

且不說Swoole,就說國內的WorkerMan和國外的ReactPHP,因為後兩者完全是用PHP實現的非同步框架,底層擴展使用了PHP早就有的sockets/streams/pcntl(多進程)/event(libevent).所以就算沒有WorkerMan和ReactPHP,也可以自己用PHP寫一個非同步框架維持大量連接.比如Minecraft Pocket Edition就是一個既沒有用到WorkerMan,也沒有用到ReactPHP,完全自己用PHP及其支持的底層擴展開發的Minecraft伺服器端.Swoole性能上有優勢,比如Swoole內置的全部協議支持都是用C實現,所以解包封包的速度要優於PHP實現的WorkerMan和ReactPHP.

可能是我太年輕了，不過印象中jsp不是做網頁的嘛，不好做遊戲吧。。

現實中用PHP和Java的都有的，遊戲伺服器的語言選擇並不是能不能做導致的，主要是人和技術積累決定的，試從歷史角度分析一下。

最早90年代還沒網路遊戲的時候，做單機遊戲都是用的c++。

到了2000年代的MMORPG時代，做網遊伺服器的還是之前做單機的那幫人，自然順便就用c++了。當然c++開發效率成問題，還有穩定性的原因有人就引進了lua。

2010年以後隨著社交遊戲的興起，再後來手機遊戲火的不像話，大量做網站出身的加入了遊戲行業，基本上是之前熟悉什麼就用什麼，而且社交遊戲跟MMORPG相比沒那麼強的實時性，對性能的要求也不高，於是出現Java，PHP，Python，erlang等等百花齊放的局面。

所以目前的情況應該是有技術積累的大公司多用c++/lua，大公司出來的原班人馬也有較大可能繼續c++/lua，其他的就各有各的選擇了。總之語言選擇不是個核心問題，能找到人趕緊把東西做出來才是關鍵。

頁游用php的多了去了

如樓主所說:以前的網站響應都是一次請求一個連接,頻繁的連接速度很慢的.

現在http2.0了,改進的就是網頁和伺服器之間建立的是長久連接,直到網頁關閉.不過:字元串式數據比二進位數據處理的慢,還是個問題.

一答案

php,jsp包括Java不適合密集計算和頻繁資料庫寫操作的網路遊戲環境，外在表現為實時用戶網路響應緩慢。

二答案

毫不猶豫採用IOCP，且它自含了寶貴的動態負載均衡系統，適合低成本實時高性能網路遊戲的開發。

jsp是什麼鬼？那個不是用來渲染html頁面的么？所以題主是想問網路遊戲為什麼不用html頁面來交互通訊？

因為html不僅包含數據還有內容呈現，而遊戲並不需要用html呈現，即使是網頁遊戲也極少採用html來呈現遊戲內容（一般採用flash或者html5），遊戲只需要純數據的交互。

另外http並不等於html，在http上也可以傳輸json,xml,binary格式的數據，所以用http作為網路遊戲的傳輸層協議也是可以的，但是http沒法讓伺服器向客戶端主動推送，要做推送的話需要客戶端進行長輪詢，這導致了http的性能不佳，所以一般網路遊戲不會選用http來通信，只有html 5遊戲會採用。

最後用php開發網頁遊戲後端是有的，但是用php並沒有什麼額外的好處，因為遊戲不需要php的頁面渲染功能，php的最大優勢發揮不出來，其他方面又比較弱，除非開發人員只會php，否則沒有什麼特別的理由要選用php。