总结:那些热门的开源游戏服务器框架,还不看你就out了
作为一名业内资深的游戏开发人员,经常会遇到实习的新同事在工作中会问到这样的问题:
工作中到底有哪些开源游戏服务器框架,该去值得学习呢?
囊括到nodejs 、java、C#、golang 、c++、python 等技术栈有各种各样的游戏框架。
本文给大家总结了一些github上star和fork比较常用的且有一定数量的较为完整的框架做了一个说明,大家可以往下看。
地址: https://githubcom/cloudwu/skynet
基于此引擎开发的游戏众多,很多棋牌小企业在用,例如简悦的 陌陌争霸 、 食物战争 等等很多产品
地址: https://githubcom/NetEase/pomelo
一花科技等棋牌在用
地址: https://githubcom/ketoo/NoahGameFrame
代表作全民无双
地址: https://githubcom/kbengine/kbengine
已经被电魂网络收购
地址: https://githubcom/egametang/ET
经过产品验证并且教程比较完善
地址: https://githubcom/topfreegames/pitaya
zooba appstroe排行很高的moba、吃鸡类游戏
但是,像c++类的框架对新手要求较高。
亦或者nodejs类框架性能确实差一些,毕竟它是针对io密集型。
阿博自己的话使用的是pitaya这套框架。毕竟支持分布式使用的技术比较新,也经过各种验证。 其他的就先不做评价,留着给大家发表一下意见。
毕竟,只要适合自己的才是最好的。
是的不
1技术实现:
现在最火爆的《王者荣耀》就是用Unity3D开发的,暴雪的《炉石传说》客户端也是用Unity3D开发的,《神庙逃亡》、《球球大作战》等等都是用U3D开发的,这些游戏有多火爆我这里就不再说。
2跨平台
Unity3D支持PC、移动、主机三大不同的平台。
3商业授权:
Unity个人版是免费的,只有当年盈利超过10万美元才需要购买专业版的授权。
4重构:
Unity使用面向组件开发模式,可能游戏的整个逻辑需要重新用C#重新写。但是资源都是可以沿用原来项目的。
服务端的不属于Unity的范围。可以参考一些成熟的服务端框架。
一、偏向不同
1、u3d:Unity3D适合开发手游,UE4更适合对于动画,美术感兴趣的设计师。
2、ue4:Unity3D侧重轻量级的开发,偏向于移动端,所以在手游方面的开发是非常强大的,现在市面上有很多手游都是基于Unity3D开发的。
二、优势不同
1、u3d:这种标准将使3D更容易结合到网络浏览器、手机浏览器等其它应用程序中,使3D图像能够更广泛地普及,从而促进对更快的处理器和图形芯片的需求。
2、ue4:UE4的渲染效果算得上是一流的,给玩家的用户体验更好,比如端游《绝地求生大逃杀》和手游《和平精英》就是用UE4开发的。
三、劣势不同
1、u3d:即使通过特定程序能够打开,也是以牺牲大量编辑修改功能作为代价,尤其是三维文件一般都体积巨大,无法通过互联网传播、浏览。
2、ue4:ue4每一次迭代都会随之附加大量的新功能与新插件,很难全部掌握UE4的所有功能的应用方式。虽然有意思吹捧的意味,但是过多的功能会使得新手学习时出现选择困难,导致真正学得下去的人少之又少。
一直用Http用多了 复习一下基础
Unity通讯一般分为2类
Http : 应用层 Unity内置的UnityWebRequest类进行通信(之前写过一个分发器垃圾框架)用于交互量比较小
Socket:传输层 比较底层 实现TCP/UDP 用于频繁的通信
这个是基于TCP 和IP传输不同消息
这个是三种常见的网络层次划分
基本数据单位为帧
主要的协议:以太网协议
基本数据单位为IP数据报;
IP协议(Internet Protocol,因特网互联协议)
ICMP协议(Internet Control Message Protocol,因特网控制报文协议)
ARP协议(Address Resolution Protocol,地址解析协议)
RARP协议(Reverse Address Resolution Protocol,逆地址解析协议)
包含的主要协议:TCP协议(Transmission Control Protocol,传输控制协议)、UDP协议(User Datagram Protocol,用户数据报协议)
数据传输基本单位为报文
包含的主要协议:
FTP(文件传送协议)、Telnet(远程登录协议)、DNS(域名解析协议)、SMTP(邮件传送协议),POP3协议(邮局协议),HTTP协议(Hyper Text Transfer Protocol)。
分配给用户上网使用的网际协议
目前IPv4多 比如19216811
新的IPv6(因为IPv4数量不够分配)如3ffe:3201:1401:1280:c8ff:fe4d:db39:1984。
Internet最基本的协议
TCP负责发现传输的问题,一有问题就发出信号,要求重新传输,直到所有数据安全正确地传输到目的地。
可靠的协议 通过三次握手建立的面向连接通信协议
3次握手 四次挥手 实习生常考
TCP连接建立过程(三次握手):
1首先Client端发送连接请求报文
2Server段接受连接后回复ACK报文,并为这次连接分配资源。
3Client端接收到ACK报文后也向Server段发生ACK报文,并分配资源,这样TCP连接就建立了。
TCP连接断开过程(四次挥手):
1Client端发起中断连接请求(FIN报文)
2Server端接到FIN报文后,发送ACK服务器还有消息没发完让Client待命,Client端就进入FIN_WAIT,继续等待Server端的FIN报文
3Server端确定数据已发送完成,则向Client端发送FIN报文,
4Client端收到FIN报文后发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传,Server端收到ACK后 关闭,Client等待了2MSL后依然没有收到回复客户端也关闭
SYN:"synchronize"请求同步标志;;ACK:"acknowledge"确认标志";FIN:"Finally"结束标志。
为什么要三次握手?
防止因为网卡导致Sever收到多次Client请求 建立N个监听 造成资源浪费
为什么要四次挥手?
自己不请求直接关闭 但是服务器还能给你发数据 服务器浪费资源 而且客户端也会强行接收
使用TCP的协议:FTP(文件传输协议)、Telnet(远程登录协议)、SMTP(简单邮件传输协议)、POP3(和SMTP相对,用于接收邮件)、HTTP协议等。
面向无连接的通讯协议
UDP通讯时不需要接收方确认,属于不可靠的传输 会丢包
UDP与TCP位于同一层,但它不管数据包的顺序、错误或重发
主要用于面向查询---应答的程序
每个UDP报文分UDP报头和UDP数据区两部分
UDP报头由4个域组成,其中每个域各占用2个字节
(1)源端口号;
(2)目标端口号;
(3)数据报长度;
(4)校验值。
使用UDP协议包括:TFTP(简单文件传输协议)、SNMP(简单网络管理协议)、DNS(域名解析协议)、NFS、BOOTP。
超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议
HTTP协议特点:
简单快速 灵活 无连接 无状态 支持B/S(浏览器/服务器)及C/S(客户端/服务器)模式。
URL
和服务器有一些频繁的交互 用http时不时请求 叫轮询 效率低下
soket可以理解为插座 插头接上了可以保持通信
端口:
每个Socket连接都是从一台计算机网卡的一个端口连接到另外一台计算机网卡的某个端口。
IP是房子的话 端口就是门
TCP端口和UDP端口相互独立 如TCP255端口 和UDP255端口 不冲突
周知端口
范围从0到1023,其中80端口分配给WWW服务,21端口分配给FTP服务等。
浏览器的地址栏里输入一个网址的时候是不必指定端口号的,因为在默认情况下WWW服务的端口是“80”。
网络服务是可以使用其他端口号的 比如 网址:8080
但是有些系统协议使用固定的端口号,它是不能被改变的,比如139 端口专门用于NetBIOS与TCP/IP之间的通信,不能手动改变。
自己开发时尽量不要使用1024之下的端口,可能会与系统端口冲突。
服务端:
创建socket对象
bind:绑定IP地址和端口
listen:开始监听绑定的IP地址和端口,等待客户端的连接
accept:如果有客户端发起连接,通过accept接受连接请求,连接成功后会复制一个socket出来用于和当前接受连接的客户端进行通信。(服务端最初创建的那个socket只是用来监听并建立连接用的,实际和客户端通信并不是最初的socket,而是在accept这一步会自动创建一个新的socket出来和客户端通信。)
read/write:使用新的socket读写数据
close:关闭socket,如果关闭的是服务端的监听socket,则无法接收新的连接,但是已经创建的和客户端的连接不会被关闭。
客户端:
创建socket对象
connect:连接服务端,连接成功后系统会自动分配端口
read/write:连接成功后,就可以进行数据的读写了,这里读写使用的socket还是第一步创建的socket对象。
close:关闭连接。
如果收到了长度为0的数据,则代表远程socket关闭了连接。
服务器:
创建socket对象
bind:绑定IP和端口,用于接收数据(注意这里绑定完就可以直接接收数据了,并不需要等待连接)
read/write:读写数据
客户端:
创建socket对象
read/write:读写数据,不需要先建立连接,直接给对应的IP+端口发送数据即可。
由于没有建立连接以及连接的保障,UDP在传输效率上会很高
UDP有一个功能是TCP所不具备的,那就是广播功能(UDP可以将消息发送到在同一广播网络上的每个主机 CS、魔兽争霸局域网对战)。
HTTP/HTTPS(比http更安全):小游戏 网页 间歇性发送链接 偶尔延迟。
TCP长连接: 卡牌游戏 某些mmo 客户端和服务器都可以独立发包 偶尔延迟
UDP:动作游戏 mmo 枪战 客户端和服务器都可以独立发包 无法接受延迟
可以混合使用你的MMO客户端也许首先使用HTTP去获取上一次的更新内容,然后使用UDP跟游戏服务器进行连接。
现在也有kcp 就是tcp和udp结合 快速安全可靠
简单直接的长连接
可靠的信息传输
数据包的大小没有限制
坑多 断线检测、慢速客户端响应阻塞数据包,对开放连接的各种dos攻击,阻塞和非阻塞IO模型
丢包会有阻塞机制(一般是重发 tcp相反) 所以手机游戏ping跳1000就这个原因
只使用一个socket进行通信
快速
基于数据包构建
灵活 多种方式处理延迟
很多东西没有要自己构建
不可靠
丢包
客户端直接开始进行计算而不等待服务端确认是一种典型的隐藏延迟的技术(容易被抓包篡改)。
我们到底是使用TCP还是UDP取决于我们能否隐藏延迟。
比如TCP 在棋牌 卡牌游戏 卡1S无所谓 在动作游戏moba游戏就很致命
可靠的UDP/kcp和TCP不一样,要去实现一个特殊的阻塞控制,而且还要保证可靠性,也可以使用许多支持可靠通信的UDP库,但是库一般为了通用会降低某种新能,自己根据项目情况写可以发挥到极致
如果不知道用什么就TCP
目前Unet这个功能在Unity应该会分为3个阶段开发
1 完成点对点数据同步,基于UDP的P2P可靠与不可靠网络。
2 提供服务器版本库,可以自行开发独立于Unity的服务器版本(非Headless模式)
3 提供分区架构负载均衡版本的服务器
目前版本截至53位置相当于 阶段1中
仅仅提供点对点的同步功能,还缺少主机切换,验证服功能等,基于互联网匹配同步的版本需要使用Unity Cload完成。
阶段2的时候就应该可以自行通过Unet库开发服务器管理,机器人AI,等一些脱离Unity的本地版本
阶段3的时候就是一个能适应MMO项目的服务器
目前阶段2大概要Unity6公布
至于阶段3遥遥无期中
Roadmap可以见:
Unity - 产品蓝图
找Net那部分就是了
0条评论