震惊!某 游戏 奖金上亿赛事观战竟卡成PPT，周六无法开启 游戏 ，玩家们竟这样说?
适应了!
不得不以一个UC式的开头来吐槽笔者上周末的遭遇，笔者与久未相见的朋友兴冲冲地准备开个两人黑，但朋友受不了反复出现的老问题，扭头玩起了更老的 游戏 DNF。
作为一名经验丰富且久经考验的dota2战士，我熟知各类紧急抢救操作，随意试玩机器人模式可以解决这个老问题，可我朋友只是个周末玩家而已。
为什么我的眼里常含泪水，只因为我对这服务器恨得深沉，当我死了，我一定要带走这垃圾服务器。爱从来不需要理由，就像诗人艾青对祖国深沉的爱一样与生俱来。但恨却比爱显得更加感情激烈，可以有没来由的爱，却从来没有无来由的恨。
我真的无奈于这服务器，无法直面这惨淡的周末时光。
一 CALL ME DAD
为什么服务器是爸爸，对，说的就是你，Dota2的服务器。
The Server is the Man!
其实，早在上世界九十年代，国外的 游戏 爱好者便开始搭建服务器提供收费 游戏 服务，是最早的 游戏 开发商，运行商和获利者。
但对早年的国内大部分 游戏 玩家而言，服务器或者说另类的主机是一个较为虚幻的概念，大部分的 游戏 只能称之为联网 游戏 ，或者干脆就是简单的联机 游戏 ，真正让大家对于服务器拥有概念的是大型网络 游戏 ”(MMOG)的浮出水面，使得 游戏 直接联入互联网，激发了大家强烈的互动情绪。
诸多即时战略 游戏 的出现更是加深了这一认知。
我想要和别人一起玩，
这成为玩家心中的呼声。
正是在这股思潮的鼓动之下，使得多人在线 游戏 成为了大家心中的宠儿，自然包括我们的dota。在2005年，6.01版发布不久， IceFrog成为dota主要的地图程序员，负责包括 游戏 的执行和平衡的测试在内的任何工作。
在2003年《魔兽争霸III：冰封王座》之后，暴雪公司正式宣布了《魔兽世界》的开发计划，之前就已经秘密开发了数年之久。魔兽世界于2004年年中在北美公开测试，2004年11月开始在美国发行，中国大陆亦已于2005年6月正式收费运营。
服务器这一概念才开始深入人心，普通玩家才开始走进服务器。
服务器正是为了解决大型多人在线 游戏 产生的诸多问题而生，而延迟，或者说网络同步正是它要解决的问题之一。
在虚拟世界中，保证 游戏 的一致性是一个基本前提。通俗的说就是虚拟世界中的事实，当多人玩家一起玩 游戏 时，看上去他们确实像是在共享同一个虚拟世界，在同一个世界中游玩。比如在一个FPS 游戏 中，大家的延迟都很高，A、B两个玩家同时发现了对方，并向对方射击，如果没有很好的同步机制，那么A的屏幕上显示B还没有开枪就被击杀，而B的屏幕上显示A还没有开枪就被击杀，这就出现了不一致的问提。
OK，这让我们回到开头，让我们来了解为什么dota2的服务器是玩家们的爸爸，而在dota1中我们却很少遇到卡顿情况，反而碰到的大多是挂比们。
原因是两者采取的处理延迟的方式不一样而已，他们采用了不同的 游戏 同步模式。一个是帧同步，另一个是状态同步。当然实际应用下来很复杂，这里只是简单介绍而已。
其实在早期的DOTA或者说WAR3中，严格意义上是没有服务器这一概念的，类似的只有主机这一说法，但主机并不满足服务器这一严格定义。在这里感谢来源于网上的图片与相关资料，只做引用，以向大众简单介绍为主。
什么是帧同步?
一般War3/星际等采用，基于指令驱动各个客户端自计算逻辑。服务端只管分发指令，每个客户端根据完整的规则运算整个战场。
简单来说，就是所有的事自己管，所有的数据都有自己的数据完成，网络传输的仅仅是指令而已，既是玩家的操作指令，由自己的电脑完成计算并呈现出来，具体下来。其实你只是在看一场由自己计算机演算好的视频而已。
这样对网的要求仅仅只是稳定而已，它并不需要巨大的流量，你的电脑将会自己计算完成一切，自然作弊也很简单，数据处理几乎由你自己完成，哪里不能作弊开挂呢?
那什么是状态同步?
大部分MMORPG的主要实现方式，具体下来，服务器负责计算大部分的 游戏 过程，并且转送这些计算的结果，客户端仅仅负责发送玩家的操作，以及表现收到的 游戏 结果。服务器是一个运行 游戏 的专用主机，用于裁定世界模拟， 游戏 规则，玩家输入处理。客户端是一个连接到 游戏 服务器的计算机。客户端和服务器之间，通过相互以高频率发送小数据包来交互。客户端从服务器接收到世界的当前状态，并且根据这些状态更新，生成输出视频、音频内容，进而呈现在玩家面前。
简单来说，对于我们的电脑而言，上面的dota2客户端虽然也承担 游戏 逻辑的模拟，只处理些不太重要的逻辑计算。因此更像是素材收集库，大号的电视机，显示器。我们只知道我们自己的事，其他的东西全在服务器身上。
1 网络完善状态好，不仅要稳定还要快速
因为服务器和客户端需要进行所有的数据交互和同步，导致网络流量大。所以涉及到的网络问题一旦发生波动，不管是哪一方，影响都特别巨大。
2 服务器压力大，卡顿时直接闪现
前文中已经提到，服务器负责处理大部分的 游戏 逻辑计算，因此，大部分的 游戏 处理过程都是由服务器完成，再将数据传送回客户端呈现，因此服务器出了一点问题，直接导致我们的体验很差，直接GG。
3 地狱火问题，单位数量越多越卡
这只是一个小问题，笔者早年曾经遇到过，单位越多同步的数据量越大，当单位越多时，往往会越卡，本来尚能接受的 游戏 流畅程度瞬间下滑。早年服务器脆弱时，几乎很清楚可以看见这个问题，几个地狱火一砸，卡顿明显，现在基本已经消失。
正是如此导致网络延迟处理起来特别的麻烦，即使是专业人员也得花时间来排除，然而这并不能成为理由。
二 完美和V社的糊涂账
完美的支持者说，明明先登国外协调服务器，红字完美可不背锅，再说了，国际服有时不也登不上嘛，国际间网络影响啦。
V社的支持者说，国服可比外服崩的常见多了，再说了，每周六的必卡，不定期卡顿，这个锅也能放到V社身上?
争吵无益于解决任何问题。
结果一团乱麻，受伤的只有想玩 游戏 的我们。
作为拥有这个星球最高 游戏 奖金赛事的dota2，实在不应该如此没有牌面，很显然的一点，当年这款用户成熟度极高，赛事层出不穷的顶级 游戏 产品，始终没有迎来如同当年一样灿烂的未来。
很难想象，这是一款几乎与英雄联盟同时推出的 游戏 ，作为继任者的dota2，最正版毫无争议的完成品，但是在用户的数量上，从一开始DOTA与《英雄联盟》在用户上的并驾齐驱，到了后来《英雄联盟》完完全全的甩开了“继承者”的DOTA2。
从 游戏 人数上来说，dota2并没有完成它转化老玩家和吸引新玩家的 历史 使命，在这两项大考上都交出了不及格的答卷，建立于辉煌之上却最终只能偏距一隅。笔者很幸运也是2012就能接触玩到dota2，但一直一来体验真的糟糕，多少次满怀期待却因为服务器最终无奈GG，最终在13年ti3结束才最终得以享受流畅的 游戏 ，真的是一把辛酸泪。
V社和完美可以称得上是天生的合作者，各怀心思，却又不谋而合。
完美试图通过对dota2的支持完成自身电竞版图的构成，在电竞这一未来大势面前发出自己的声音，真正的盈利对完美来说并不重要，从财报来看，坚挺的老端游和全新的手游，甚至不断发展的影视事业这些才是完美的经济增长点。
其次，对于V社手中的steam，完美同样抱有期待，作为最想代理的产品，代理steam可不再是赔钱赚吆喝那么简单了。
但完美到底愿意花多少心思在dota2上，我们不得而知，毕竟，办事和努力办事就在努力两字上了。
但从V社角度来看，没有比完美更好的背锅侠和小弟了，steam通过曲线救国的方式走进了玩家心中。
完美代理了DOTA2，但是所有用户是通过Steam下载，只是一开始使用一下完美的账号，后面完全是通过Steam账号，所有的用户数据基本都在V社手里，发生了什么也只能求靠远在大洋彼岸的V社工程师。当初V社选择制作dota2也是想到了借助其广大的用户基数推广steam平台，在中国它成功了，而且是相当的成功，普通玩家通过这个平台了解到了更多的 游戏 。
双方的目的都达到了，那么到底谁该为土豆服务器买单呢?
steam素来以服务器质量过硬而享誉盛名，可为什么在dota2的服务器上偏偏和育碧一样呢?完美在业内同样拥有声誉，技术实力同样不容小觑，开发的 游戏 也是一个赛一个的精致，可为啥连相当成熟的服务器技术方案都解决和实施不好呢?
完美真的甘愿顶着骂名，而V社也继续选择合作，甚至在CSGO之后将steam中国也交给了他们，显然对完美信任有加。
三 无奈的玩家
玩家有多喜爱这个 游戏 ，就有多讨厌这个不时抽风的服务器。
这个顽疾几乎是伴随着dota2而生，几乎是每一个玩家的切身之痛，它就好像是一个dota2上无可奈何的瘤子，吸着玩家们宝贵的时间，吸着玩家们最珍贵的耐心，消磨着玩家们不断积攒下来的最真挚对dota2的热爱。
年年高涨的奖金证明了玩家们的爱，笔者从有余力开始就没有断过支持，因为玩饰品真的上瘾，没够。即使是笔者的不少云玩家朋友也依然贡献了不少，年年不曾缺席的他们依然会看着直播，不忙的时候来把dota。可有时这糟糕的观战也让人感到难受。
观战问题真的延续有很长一阵时间了，眼看本土TI将至，中国地区的预选赛也即将开打，那什么来宽慰一直在支持的玩家们呢?
答应我，起码观战不要PPT，好吗?
这真的是一个简单的要求。
WWW的核心——HTTP协议
众所周知，Internet的基本协议是TCP/IP协议，目前广泛采用的FTP、Archie Gopher等是建立在TCP/IP协议之上的应用层协议，不同的协议对应着不同的应用。<BR> WWW服务器使用的主要协议是HTTP协议，即超文体传输协议。由于HTTP协议支持的服务不限于WWW，还可以是其它服务，因而HTTP协议允许用户在统一的界面下，采用不同的协议访问不同的服务，如FTP、Archie、SMTP、NNTP等。另外，HTTP协议还可用于名字服务器和分布式对象管理。
2.1 HTTP协议简介
HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。
HTTP协议的主要特点可概括如下：
1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。
由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
2.2 HTTP协议的几个重要概念
1.连接(Connection)：一个传输层的实际环流，它是建立在两个相互通讯的应用程序之间。
2.消息(Message)：HTTP通讯的基本单位，包括一个结构化的八元组序列并通过连接传输。
3.请求(Request)：一个从客户端到服务器的请求信息包括应用于资源的方法、资源的标识符和协议的版本号
4.响应(Response)：一个从服务器返回的信息包括HTTP协议的版本号、请求的状态(例如“成功”或“没找到”)和文档的MIME类型。
5.资源(Resource)：由URI标识的网络数据对象或服务。
6.实体(Entity)：数据资源或来自服务资源的回映的一种特殊表示方法，它可能被包围在一个请求或响应信息中。一个实体包括实体头信息和实体的本身内容。
7.客户机(Client)：一个为发送请求目的而建立连接的应用程序。
8.用户代理(User agent)：初始化一个请求的客户机。它们是浏览器、编辑器或其它用户工具。
9.服务器(Server)：一个接受连接并对请求返回信息的应用程序。
10.源服务器(Origin server)：是一个给定资源可以在其上驻留或被创建的服务器。
11.代理(Proxy)：一个中间程序，它可以充当一个服务器，也可以充当一个客户机，为其它客户机建立请求。请求是通过可能的翻译在内部或经过传递到其它的服务器中。一个代理在发送请求信息之前，必须解释并且如果可能重写它。
代理经常作为通过防火墙的客户机端的门户，代理还可以作为一个帮助应用来通过协议处理没有被用户代理完成的请求。
12.网关(Gateway)：一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。
网关经常作为通过防火墙的服务器端的门户，网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。
13.通道(Tunnel)：是作为两个连接中继的中介程序。一旦激活，通道便被认为不属于HTTP通讯，尽管通道可能是被一个HTTP请求初始化的。当被中继的连接两端关闭时，通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通讯时通道被经常使用。
14.缓存(Cache)：反应信息的局域存储。
2.3 HTTP协议的运作方式
HTTP协议是基于请求／响应范式的。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为，统一资源标识符、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理(UA)和源服务器(O)之间通过一个单独的连接来完成(见图2-1)。
图2-1
当一个或多个中介出现在请求／响应链中时，情况就变得复杂一些。中介由三种：代理(Proxy)、网关(Gateway)和通道(Tunnel)。一个代理根据URI的绝对格式来接受请求，重写全部或部分消息，通过URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理，作为一些其它服务器的上层，并且如果必须的话，可以把请求翻译给下层的服务器协议。一个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如：防火墙等)或者是中介不能识别消息的内容时，通道经常被使用。 图2-2
上面的图2-2表明了在用户代理(UA)和源服务器(O)之间有三个中介(A,B和C)。一个通过整个链的请求或响应消息必须经过四个连接段。这个区别是重要的，因为一些HTTP通讯选择可能应用于最近的连接、没有通道的邻居，应用于链的终点或应用于沿链的所有连接。尽管图2-2是线性的，每个参与者都可能从事多重的、并发的通讯。例如，B可能从许多客户机接收请求而不通过A，并且／或者不通过C把请求送到A，在同时它还可能处理A的请求。
任何针对不作为通道的汇聚可能为处理请求启用一个内部缓存。缓存的效果是请求／响应链被缩短，条件是沿链的参与者之一具有一个缓存的响应作用于那个请求。下图说明结果链，其条件是针对一个未被UA或A加缓存的请求，B有一个经过C来自O的一个前期响应的缓存拷贝。
图2-3
在Internet上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP 80，但其它的端口也是可用的。但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。HTTP只预示着一个可靠的传输。
以上简要介绍了HTTP协议的宏观运作方式，下面介绍一下HTTP协议的内部操作过程。
首先，简单介绍基于HTTP协议的客户/服务器模式的信息交换过程，如图2-4所示，它分四个过程，建立连接、发送请求信息、发送响应信息、关闭连接。
图2-4
在WWW中，“客户”与“服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。WWW服务器运行时，一直在TCP80端口(WWW的缺省端口)监听，等待连接的出现。
下面，讨论HTTP协议下客户/服务器模式中信息交换的实现。 1.建立连接 连接的建立是通过申请套接字(Socket)实现的。客户打开一个套接字并把它约束在一个端口上，如果成功，就相当于建立了一个虚拟文件。以后就可以在该虚拟文件上写数据并通过网络向外传送。
2.发送请求
打开一个连接后，客户机把请求消息送到服务器的停留端口上，完成提出请求动作。
HTTP/1.0 请求消息的格式为：
请求消息=请求行(通用信息|请求头|实体头) CRLF[实体内容]
请求 行=方法 请求URL HTTP版本号 CRLF
方 法=GET|HEAD|POST|扩展方法
U R L=协议名称+宿主名+目录与文件名
请求行中的方法描述指定资源中应该执行的动作，常用的方法有GET、HEAD和POST。不同的请求对象对应GET的结果是不同的，对应关系如下：
对象 GET的结果
文件 文件的内容
程序 该程序的执行结果
数据库查询 查询结果
HEAD——要求服务器查找某对象的元信息，而不是对象本身。
POST——从客户机向服务器传送数据，在要求服务器和CGI做进一步处理时会用到POST方法。POST主要用于发送HTML文本中FORM的内容，让CGI程序处理。
一个请求的例子为：
GET http://networking.zju.edu.cn/zju/index.htm HTTP/1.0
头信息又称为元信息，即信息的信息，利用元信息可以实现有条件的请求或应答 。
请求头——告诉服务器怎样解释本次请求，主要包括用户可以接受的数据类型、压缩方法和语言等。
实体头——实体信息类型、长度、压缩方法、最后一次修改时间、数据有效期等。
实体——请求或应答对象本身。
3.发送响应
服务器在处理完客户的请求之后，要向客户机发送响应消息。
HTTP/1.0的响应消息格式如下：
响应消息=状态行(通用信息头|响应头|实体头) CRLF 〔实体内容〕
状 态 行=HTTP版本号 状态码 原因叙述
状态码表示响应类型
1×× 保留
2×× 表示请求成功地接收
3×× 为完成请求客户需进一步细化请求
4×× 客户错误
5×× 服务器错误
响应头的信息包括：服务程序名，通知客户请求的URL需要认证，请求的资源何时能使用。
4.关闭连接
客户和服务器双方都可以通过关闭套接字来结束TCP/IP对话
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）