无论您是游戏开发者、发行商，还是仅仅对了解游戏基础设施的现状感兴趣，本词汇表都将非常有价值。通过理解每个平台的优缺点，您可以确定最适合您特定需求和要求的平台。
探索比较，了解 Edgegap 在性能、可扩展性、定价、连接性等方面的表现。每个比较旨在清晰简明地概述 Edgegap 与其他平台之间的相似之处和不同之处，帮助您为您的多人游戏基础设施需求做出尽可能明智的选择。
浏览涵盖游戏服务器托管、编排、网络代码、玩家匹配和网络架构的定义。
基础设施与成本
与多人游戏服务器相关的机器、位置和定价模型。
云服务器是按运行时间计费的虚拟机。是什么驱动了游戏服务器的成本、为什么关机至关重要，以及按需、预留与抢占式实例的对比。
“吵闹的邻居”是指其负载可能会降低您的容器性能的租户。了解容器限制如何使您的比赛免受其干扰、避免它的代价是什么，以及为什么大型集群要进行共享。
网络出站流量（Network egress）是指离开服务商网络的数据。本文将探讨多人游戏中产生该流量的原因、为什么云服务商对其按量计费而裸金属服务器则将其包含在内，以及如何估算该流量。
vCPU 通常是一个硬件线程，而不是一个完整的核心。本文将介绍 vCPU 之间的差异、游戏服务器需要多少个 vCPU，以及按分钟计费和预留定价的对比。
裸金属服务器是以月度租用的整台物理机器。它在多人游戏中的成本是多少，与云服务器有何不同，以及在什么情况下适用。
托管与编排
游戏服务器是如何打包、启动、伸缩和关闭的。
Agones 在 Kubernetes 上运行专用游戏服务器。了解它如何保护实时对局、其运行涉及哪些内容，以及 KRAFTON 为《绝地求生》(PUBG) 准备了什么。
Docker 用于构建游戏服务器交付时所用的镜像。它与虚拟机的区别、在本地构建时需要注意的四个陷阱，以及为什么 WebAssembly 目前还无法取代它。
Kubernetes 实现了 Web 服务容器化的自动化。它在多玩家后端中的适用位置，以及每个地区和版本中自托管游戏服务器所需的配置。
专用服务器在没有玩家的情况下运行比赛。它与侦听服务器有何不同、每个引擎如何构建专用服务器，以及为什么项目规模会决定其成本。
冷启动是指等待新的游戏服务器容器准备好进行比赛的过程。这里将介绍冷启动过程中发生的事情、为什么启动时间会不一致，以及温池（warm pools）的成本。
多房间游戏服务器在单个进程中运行多个比赛。哪些网络代码支持它、回填如何填充房间、将其放置在何处，以及一场比赛的成本是多少。
一个容器运行一个游戏服务器以进行一场比赛。它隔离了什么，为什么端口映射会在首次部署时出错，日志和结果流向何处，以及如何循环使用。
弹性伸缩可根据需求增加和减少游戏服务器容量。本文将介绍策略如何做决定、为什么缩容是成本高昂的另一半，以及快速启动如何改变这一现状。
游戏服务器托管分为四个层级：机器、部署、编排和运营。这涉及服务器在何处运行、预留与按需使用，以及何时构建自己的服务器。
托管（Colocation）意味着共享基础设施。为什么与其他工作室的游戏服务器共享主机是安全的、为什么它成本更低，以及何时拥有自己的机架才划算。
无头服务器在没有渲染或音频的情况下运行游戏。当您剥离这些功能时会发生什么，为什么它适合放入容器，以及它是如何影响托管成本的。
“无服务器”对游戏服务器意味着什么：函数、单场比赛服务器或中继。该架构的组成部分、使其发挥作用的因素以及不适用的场景。
混合编排在统一控制平面下运行固定主机和云端上的游戏服务器。其工作原理包括溢出机制、基线规模估算以及与多云的对比。
暖池在比赛请求之前就准备好了游戏服务器。它容纳了什么、如何确定其规模，以及为什么按需使用会使其成为一个成本决定，而不是一项要求。
从部署到拆除，编排如何运行每场比赛。区域中心与单场比赛部署、固定容量与云容量的对比，以及为什么大多数游戏选择混合模式。
队列管理决定了您的游戏服务器运行在多少台主机上，以及运行在何处。保留队列与按需队列的对比，以及它如何与编排进行配合。
部署是指一个运行中的游戏服务器构建。它包含了什么、它是如何启动和停止的、构建是如何在不停机的情况下更新的，以及是什么决定了其成本。
玩家分组（Matchmaking，服务器浏览器，大厅，会话）
与比赛前玩家分组以及保持赛局席位已满相关的一切内容。
基于水平的比拼匹配机制会将水平相近的玩家分组，以保持比赛的竞争性。
服务器分配将已组建好的对局绑定到游戏服务器。它介于匹配系统和玩家之间，涉及占用服务器与启动服务器的区别，以及分配失败的原因。
服务器区域根据地理位置拆分您的匹配队列和机组。了解其费用开销、单场比赛的城市定位工作原理以及何时选择固定区域最划算。
匹配系统将玩家分组进行对局：它的结构如何、采用何种规则、运行需要什么，以及填充率如何影响托管成本。
Netcode
同步、数据传输、回滚以及对玩家在线体验的整体影响。
网络代码（Netcode）维持着多人游戏比赛的一致性。本文将介绍它的七个组成部分、每个部分所作出的妥协，以及为什么“糟糕的网络代码”往往其实是另一个层面的问题。
为什么主机迁移总是中断比赛、主机离开时需要移动什么、它的构建成本是多少，以及专用服务器是如何消除这一问题的。
同步失准（Desync）是指玩家看到的比赛画面与服务器不一致的情况。以下是它的两种类型、为什么提高 tick 率并不是解决办法，以及何时同步失准会成为一种作弊手段。
Tick rate（滴答率）是游戏服务器每秒重新计算比赛状态的次数，以赫兹（Hertz）为单位测量。
网络回弹（Rubberbanding）是指当服务器纠正预测错误的位置时发生的瞬间回退现象。本文将探讨其产生原因、为何它不仅是延迟问题，以及如何在服务器端减少这种现象。
回滚型网络代码（Rollback netcode）进行预测、倒回和重放。解析为什么延迟决定了每次修正的幅度，为什么游戏会混入输入延迟，以及其构建成本有多高。
客户端预测在服务器确认之前显示玩家的输入。它包含：预测的内容、对账如何重放输入，以及为什么延迟至关重要。
插值是在服务器更新之间绘制其他玩家。它有什么消耗，为什么 Source 引擎默认设置为 100 毫秒，以及游戏何时采用预测而不是插值。
Ping 是玩家与服务器之间的往返时间。它如何影响网络代码、为什么玩家之间的差距更为重要，以及开发人员可以控制什么。
网络架构
客户端、服务器和中继是如何连接的。
中继服务器在不托管比赛的情况下绕过 NAT 路由玩家。它能解决什么问题、哪些部分仍保持点对点连接、免费中继的成本，以及何时该转向其他方案。
客户端-服务器架构通过单一服务器路由每位玩家。这里将介绍游戏循环的工作原理、客户端为何进行预测与插值，以及该中心节点的成本。
点对点（P2P）多人游戏没有服务器托管费用。但它带来的代价是：连接失败、主机作弊、主机退游导致的对局丢失以及额外的技术支持成本。
跨平台游戏将主机、PC 和移动端玩家汇聚在同一场对局中。本文将探讨为什么点对点联机在此模式下显得吃力、为什么各平台版本必须保持一致，以及如何维持匹配队列的完整性。
玩家
与保持游戏活跃、运营游戏以及确保为玩家提供公平且极佳的在线体验相关的一切事务。
