一、带宽和传输速率的定义
1)带宽(Bandwidth)
带宽是指通信信道或网络链路在单位时间内能够传输的最大数据量,通常以比特每秒(bps)为单位进行度量。带宽是衡量网络传输能力的重要指标,反映了网络或通信系统在特定时间内的最大吞吐量。
1. 物理带宽:指通信信道本身的传输能力,由硬件设备和物理介质决定。
2. 逻辑带宽:指在网络协议层面上的传输能力,受网络配置和协议限制。
3. 有效带宽:指实际可用的带宽,考虑了网络拥塞、延迟等影响因素后的传输能力。
2)传输速率(Transmission Rate)
传输速率是指实际传输过程中数据的传输速度,通常也以比特每秒(bps)为单位表示。传输速率反映了用户在使用网络时的实际体验,它不仅取决于带宽,还受到多种因素的影响。
1. 理论传输速率:指在理想条件下,通信信道能够达到的最大传输速度。
2. 实际传输速率:指在实际使用中,由于各种因素的影响,通信信道能够达到的传输速度。
二、带宽和传输速率的公式及换算
1. 带宽的计算公式
2. 带宽的基本计算公式为:
[ \text{带宽} = \frac{\text{数据量}}{\text{传输时间}} ]
其中,数据量以比特(bit)为单位,传输时间以秒(s)为单位,带宽的结果则以比特每秒(bps)表示。该公式适用于简单的点对点传输场景,用于计算单次传输的平均带宽。
3.数据量的单位转换
在实际应用中,带宽通常以千比特每秒(kbps)、兆比特每秒(Mbps)或吉比特每秒(Gbps)为单位。常见的单位转换关系如下:
1 kbps = 1000 bps
1 Mbps = 1000 kbps = 1,000,000 bps
1 Gbps = 1000 Mbps = 1,000,000 kbps = 1,000,000,000 bps
4.频率与带宽的关系
在无线通信中,带宽与频率密切相关。根据奈奎斯特定理(Nyquist Theorem),带宽与信号的最高频率成正比。具体公式为:
[ \text{带宽} = 2 \times \text{最高频率} ]
这意味着,更高的频率可以支持更大的带宽,从而实现更快的数据传输。
1. 香农公式:香农公式(Shannon-Hartley Theorem)提供了更精确的带宽计算方法,尤其适用于有噪声干扰的通信信道。香农公式为:[ C = B \log_2 (1 + \frac{S}{N}) ]
其中:
( C ) 是信道容量(即最大带宽),单位为bps。
( B ) 是信道带宽,单位为Hz。
( S ) 是信号功率。
( N ) 是噪声功率。
香农公式表明,信道容量不仅取决于带宽,还与信噪比(Signal-to-Noise Ratio, SNR)密切相关。信噪比越高,信道容量越大;反之亦然。
2.传输速率的计算公式
传输速率的计算公式为:
[ \text{传输速率} = \frac{\text{实际传输的数据量}}{\text{实际传输的时间}} ]
其中,实际传输的数据量以比特(bit)为单位,实际传输的时间以秒(s)为单位,传输速率的结果也以比特每秒(bps)表示。
3.理论传输速率与实际传输速率的区别
理论传输速率:指在理想条件下,通信信道能够达到的最大传输速度。它等于带宽,假设没有其他因素影响。
实际传输速率:指在实际使用中,由于各种因素的影响,通信信道能够达到的传输速度。实际传输速率通常低于理论传输速率,因为存在网络拥塞、延迟、协议开销等因素。
三、带宽和传输速率的区别
1)定义上的区别
带宽 是一个理论上的最大值,表示通信信道的最大传输能力。它反映了网络或通信系统的潜在传输能力。
传输速率 是实际传输过程中的表现,反映了用户在使用网络时的实际体验。它不仅取决于带宽,还受到多种因素的影响。
2)影响因素的不同
带宽 主要由硬件设备、物理介质、网络拓扑结构等决定。例如,光纤通常具有较高的带宽,而铜线的带宽较低。
传输速率 受到更多因素的影响,包括但不限于:网络拥塞:当网络流量超过网络容量时,会导致数据包丢失、延迟增加和传输速率下降。
延迟(Latency):指数据从发送端到接收端所需的时间。高延迟会显著降低实际传输速率。
协议开销:网络协议本身也会占用一定的带宽资源,如TCP/IP协议的头部信息。
硬件设备:路由器、交换机等设备的处理能力和传输速度会影响传输速率。
应用程序需求:不同应用程序对带宽的需求差异很大,如视频流媒体需要较高的带宽,而电子邮件则相对较低。
3)实际应用场景中的区别
家庭宽带:假设用户购买了一个100 Mbps的宽带套餐,理论上可以达到100 Mbps的下载速度。但在实际使用中,由于网络拥塞、延迟等因素,实际网速可能只有80 Mbps甚至更低。此外,如果多个设备同时使用同一宽带连接,每个设备的网速会进一步下降。
企业级网络:在企业环境中,带宽和传输速率的关系更为复杂。企业通常需要处理大量的数据传输,如云存储、视频会议等。
为了保证高效的数据传输,企业需要考虑以下几个方面:
带宽需求评估:根据业务需求评估所需的带宽,如视频会议可能需要较高的带宽,而文件传输则相对较低。
网络拓扑优化:设计合理的网络拓扑结构,如采用星型拓扑结构可以提高带宽利用率。
QoS策略:通过QoS(Quality of Service)策略优先处理关键业务,确保重要数据的传输质量。
负载均衡:通过负载均衡技术分散网络流量,避免单点拥塞。
移动网络:移动网络(如4G/5G)是带宽和传输速率关系的另一个重要场景。移动网络的带宽和传输速率受多种因素影响,包括基站密度、频谱资源、用户数量等。以5G为例,其高频段(如毫米波频段)可以提供极高的带宽和传输速率,但也面临信号覆盖范围小的问题。因此,5G网络需要更密集的基站部署和先进的波束成形技术来保证良好的用户体验。
综上所述,带宽和传输速率是两个密切相关的概念,但它们有着不同的含义和计算方式。带宽是一个理论上的最大值,表示通信信道的最大传输能力,而传输速率是实际传输过程中的表现,反映了用户在使用网络时的实际体验。带宽是传输速率的上限,但实际传输速率还取决于网络拥塞、延迟、协议开销等多种因素的综合作用。带宽和传输速率的公式及换算方法包括基础公式、频率与带宽的关系以及香农公式等,提供了从简单到复杂的多种计算方法。理解这些公式和换算方法,有助于我们在实际应用中准确评估和优化网络资源。在未来的发展中,随着5G、光纤宽带等新技术的普及,带宽和传输速率将进一步提升,推动信息技术的发展和应用。掌握带宽和传输速率的关系及其计算方法,有助于我们在复杂多变的网络环境中做出更明智的选择,优化资源配置,满足不同应用场景的需求。
前言
这节讲座里,我们将从游戏服务器发展的简单历程出发,鸟瞰一下目前大多数的游戏服务器架构。
这里尽可能的避免陷入细节的技术问题,而是从技术进化的结果状态,反推原始问题是什么。希望能通过这个过程,解释清楚游戏服务器是在解决什么问题,痛点到底在哪里。
一、早期网游服务器
蛮荒时期的游戏服务器框架我们一笔带过,那时的游戏服务器和一个小Web服务没有区别。
蛮荒时代的服务器只负责存储玩家账号、数据、转发场景内其他玩家的行为。很多移动、使用技能等关键逻辑在服务器上根本没有。随意就能用变速齿轮改变游戏速度。
从《传奇》的时代开始,游戏服务器就不再是简单的上传存档、下载存档、访问页面而已。游戏服务器内部出现了游戏逻辑,既能用于同步每个玩家看到的世界,又能让逻辑与客户端分离,避免早期的网络游戏那种毫无防范的逻辑体系(对外挂防御能力为0)。
如图,客户端通过某种形式验证登陆以后,就和服务器通过TCP直接相连了。这种服务器的承载能力不高,但那时在游戏逻辑上也务求简化,把负载减少到极致。
· 例如:1、玩家看不到怪物的血量,或者只能看到正在打的怪物的血量。2、地图有格子的概念,每个格子只能有一个单位,极大限制了同屏人数。
由于逻辑尽量简化,虽然这时的服务器逻辑服务都是单进程单线程的,但是也足够表现交互的感受。
这种架构奇怪的地方是处理网络连接数据传输的压力和逻辑处理的压力在同一个服务器上(存储模块可能也在同一个进程),就算逻辑处理压力为0,承载人数也高不到哪去。
虽然这时的游戏服务器设计很简陋,但是网游第一次给了玩家真实世界的感受。单服人数不足的问题可以靠开多组服务器实现,所以曾经出现了几百上千组服务器的辉煌时代。
二、早期游戏服务器的改进版本
当开发者们有了初步经验以后,新作品的开发,自然而然的过渡到了如下的形式:
游戏逻辑服务依然是在一台服务器上,单进程(逻辑处理本身肯定是在一个线程中,可以有子线程负责内网通信)。但是我们自然的想到,存储负载和网络连接负载可以从逻辑服上拆出来。
连接服务器负责把客户端和服务器之间的消息转化为服务器之间的消息,可以顺便做一些加解密的工作。
这一点小改动极大提高了单服连接人数的上限。但是玩家要求提高了,空出来的性能很快被丰富的游戏系统吃掉了。
由于连接服务器本身没有时序性,很容易做分布式的(其实大部分游戏还是只用一个连接服),存储服务不要求高实时性,高峰期存盘间隔可以稍长一些,不会对游戏服造成影响。
三、成熟形态的服务器框架
逻辑服务器的负载均摊方法一:按照功能划分多个服务器进程
逻辑服务器的负载均摊方法二:按照场景划分多个服务器进程
对游戏服务器历史有了基本了解后,成熟形态的游戏服务器很容易理解。简单来说,就是把逻辑服务器单个进程的压力分摊到多个服务器。
难点在逻辑的设计上,要像做手术一样把本来是一体的功能切开,并抽象出若干个API来保持联系(服务器之间是TCP连接)。
在分解时,要找联系相对最薄弱的环节入手,比如场景和场景之间分开、单独抽出聊天服务、组队服务、好友服务。
无论如何分解,最终结果只能是有限个服务。而且分解的越细,开发难度就越大。因为跨服务器逻辑是把简单的同步逻辑变成了异步Callback逻辑,而且容易出现时序问题等不易测试的问题。
单个场景服务几乎是无法分解的。分解单个场景难度巨大以至于出现了BigWorld引擎来专门的解决场景分割问题,后面会谈到。
这种成熟形态的游戏服务器已经能满足现实中99%的频繁交互类网游需求,是大型MMO端游、页游的主流形式。
当然有实力的公司在这个基础上会做很多改动,实现动态开辟副本、相位技术等等,但是万变不离其宗,其本质和上图没有什么区别。
附:开房间式的网络游戏
开房间式的网络游戏也是游戏的一个重要分支,英雄联盟、DOTA、很多手游例如皇室战争、王者荣耀等等。
这种游戏房间之间几乎没有交互,只有大厅内有交互,可以理解为原始形态的游戏服务器的平行扩展。
房间式游戏扩展难度较小,只是需要根据玩家数量动态扩展游戏房间的数量、服务器数量。很像网站的架构。
这种游戏架构最最适合放在云平台上,设计合理的话,它可能遇到的问题和大型网站几乎一模一样。不需要特别的讨论它们。
只是,毕竟游戏不都是开房间的玩法。
小结:游戏服务器框架特点
1、真正的数据都在内存中,数据库性能不那么重要
· 注:很多大型游戏采用了共享内存,避免宕机时损失过大。
2、单CPU性能比CPU数量重要的多。
3、目前有很多游戏,特别是手游,使用Redis读写代替内存读写,甚至也有用Mongo的。
4、开新服、旧区合服的情况,非常适合云平台。
五、先进服务器框架
· 先进服务器框架1 BigWorld
BigWorld引擎的代表作:
· 中国:《天下贰 》《天下叁》等等数十款,网易对BigWorld的实用化贡献很大。
· 国际:《魔兽世界》早期版本,《坦克世界》,《战争雷霆》
BigWorld的核心理念,要回到上面讲过的场景分割问题。
BigWorld利用平面切分的原理,将场景划分为小块,不同的块可以运行在不同的服务器上。而且块的划分是动态的,根据玩家密集程度、数量动态调整块的大小。。
具体技术上,使用了Actor模型,要求每个对象都是独立的Entity,对象之间只能通过消息协作,严格限制对象之间的直接交互。
后来随着手游的崛起、端游的衰落、网游玩法向多元化发展,这一系列的变化,导致BigWorld引擎很快就衰落了。
BigWorld引擎从曾经的大红大紫,到现在的无人问津,反映出游戏服务器技术的发展趋势。BigWorld的强制Actor模型,实际上是牺牲了开发效率,换取了服务器可扩展性。
理论上单服承载人数可以达到百万级别。但是游戏的业务逻辑的修改很频繁,开发效率低下是游戏设计师不能承受之重。
这种架构天生就是为云计算准备的,而且单个物理机承载量十分有限,每个游戏大区都需要大量实体机。
如果BigWorld成功…… 可惜的是,它和实际市场的发展趋势背道而驰了。
游戏开发相比电商系统,项目规模小几个数量级,但是相对的,迭代速度要快几倍。项目之间如果类型不同或是玩法有差异,能复用的代码并不多。
聊聊十万行代码。游戏服务器开发速度受美术资源制作速度、客户端开发速度制约。近几年我猜测服务器方面并不会有大的技术革新。
游戏开发未来的趋势是多元化、低门槛化、大众化。很长一段时间内BigWorld这种大怪兽级别的引擎不会再崛起。
分布式框架的崛起时间点,无论如何,也在VR技术成熟之后了。
· 先进服务器框架2、Skynet
Skynet是新兴的一种通用型服务器框架(完全开源),它游走在传统不易分布服务器和分布式服务器之间。
它是一种泛用型框架,不仅能很好的作为游戏服务器框架使用,而且用来搭建HTTP服务也具有惊人的性能(几百行代码的简单HTTP实现,能达到nginx 60%的性能)。
矛盾的是,由于它对脚本虚拟机做了一些重要的Hack,导致它完全绑定在了Lua这一种语言上。
Skynet原理阐述:
把服务抽象为微服务,一个系统内可以建立成千上万个微服务,Skynet调度m个线程(m=CPU核心数)、处理n个微服务各自的事件。
由于n个微服务在同一个进程内,可以达到0延迟的内部通信(极端情况下无拷贝)
同时Lua虚拟机又提供了沙盒机制,微服务之间的Lua逻辑代码不会有任何干扰,必要的时候又可以在C语言层面、Lua沙盒之外共享数据。
由于服务本身有良好的隔离性,可以较为方便的把服务部署到多物理机上(考虑到性能问题,不能像BigWorld那样任意部署)。
Skynet这种架构已经在Lua体系的游戏公司内大量使用(以网易系为代表),悄无声息的渗透到其他公司里。(和Lua语言当年的情况有点像,是金子总会发光的。)
六、先进服务器框架3、以Go语言为主的其他框架
Go语言的goroutine特性,给游戏开发者带来巨大的想象空间。
在Go语言的基础上,很容易出现更好的房间式游戏框架、类似Skynet的框架、改进型的传统框架。
但是可以大胆预测,最终实现的效果不会超过erlang、skynet这类框架的范围。这是因为游戏业务本身的特性决定的。
结束语
本文简要探讨了十几二十年来,主流服务器框架的发展脉络,以MMO-RPG这种最具代表性的网游类型为主(同时MMO对服务器架构的挑战也是最大的),兼谈到一些其他类型的游戏。由于游戏类型多种多样,各个国家和地区的开发商所偏好的架构方式也大有不同,文中难免挂一漏万,但不太影响整体脉络,也不影响对网游服务器的核心问题的总结——逻辑拆分。
Copyright © 2013-2022 idca.cn. All Rights Reserved. IDCA 版权所有 湖南冬邦云互联科技有限公司 湘ICP备13011493号-2
《中华人民共和国增值电信业务经营许可证》B1-20214635 湘公网安备43020002000199