第393章 痛击西雅图 (2/4)

实现的？很简单，他只是在cix联盟的数据中心更新了一段小小的程序。

    这段代码本身没有任何问题，它不会影响整個美利坚数据交换网络的运作。

    但是，当交互中心的服务器接收到来自导航者浏览器的数据请求时，它就会故意忽略这些反馈。

    用户使用浏览器上网时，他们每次点击鼠标，或者打开一个新的网页，都需要向终端服务器发送访问请求。

    本来在这个过程中，浏览器只是起到一个工具作用，真正的指令执行是由网页那一端负责。

    也就是互联网公司或者建立网站的这个组织，他们的服务器会对用户的请求做出反馈。

    但是信息在传递的过程中需要中转，比如isp运营商负责将用户的指令，通过遍布北美的线路来传送给互联网公司。

    而因为同一根线路中传递的数据量非常庞大，所以为了将每一道指令都准确的传递给目标。

    这些从用户端发出的请求指令都带有识别号码，比如ip地址、当前所使用的软件识别串号、目标指向等等。

    通俗的说这些识别码就相当于身份证，isp运营商可以根据这些信息把数据传送给对应的接收方。

    同理，从网站服务器那里返回的数据，也是一样的工作模式。

    而这些识别码中有一组数据，所代表的就是用户当前正在使用哪一款软件。

    发现问题了吗？交互中心其实可以准确的识别出，每一道信息它所来自的应用软件。

    根据联邦法律规定，软件公司的产品在上架时，都会被分配这样的识别号。

    同时这也是电信委员会的要求，主要目的还是为了数据的传递效率考虑。

    这些软件的识别号，就像书籍版号一样，独立且唯一。

    所以现在问题很简单了，cix联盟的数据中心只要忽略掉，所有来自导航者浏览器的指令请求就可以了。

    用户的指令可以发出，但却不会被传递。于是当浏览器长时间收不到反馈后，就会跳出崩溃的提示页面。

    这就是来自迪恩的反制手段，既然你从源头上掐灭我，那我就从终端抹除你的痕迹。

    一个杜绝了对方的新用户增长，一个直接让对方的软件失效。

    啧，这波就是魔法对轰啊。

    至于谁的手段更狠，那就属于仁者见仁、智者见智了。

    当然迪恩不可能完全瘫痪掉导航者浏览器，那样太明显，也会给自己找麻烦。

    所以交换中心更新的代码，只会隔段时间才启用一次，并且地点也不固定。

    现在是弗吉尼亚的用户出现了问题，再过半小时可能就换到了纽约。

    主打一个随机性，微软就是想查都得费点时间。

    再说了总得留点缓冲时间给用户下载网景浏览器，一刀切之后只会适得其反。

    有对比才有伤害，导航者的不定时抽风只会让网景浏览器更加受欢迎。

    毕竟微软能干涉的只是让计算

本章未完，请点击下一页继续阅读