任何新兴网络技术的引进都会在某种不同方面的影响网络的基础建设，小到微不足道，大到地球破碎。同样，在当今网络中，Ajax是一个更具有破坏性的新网络技术。为了减少你对将来网络的吃惊，本文列出了10件你需要知道的关于Ajax的知识。
让我们看一组幻灯片，对于Ajax，什么是每一个网络专家都需要知道的。
1）Ajax是一个想法，而不仅仅是一个缩略词
尽管Ajax通常被拼写为“异步JavaScript和XML”，但这个全称不完全合适，因为它过分简化了这门技术的历史和实现核心。更确切地，Ajax包含了一种思想，这种思想认为网络应用可以退出传统的以服务器端为中心的重复发送-等待循环方式来建立。Ajax使网络应用转向更有影响的、连续的，而且渐进式的更新。Ajax为用户优先的体验网络应用提供了更丰富、更好的交互性。这个优势也意味着需要网络专家更多的网络控制和安全监视，潜在地，服务器和网络改造也是这样。
2）这确实都与JavaScript有关
Ajax的应用是用JavaScript写的，通常基于XMLHttpRequest对象来通信，这个XMLHttpRequest对象是通过万维网协议过程进行的。由于像大多的网络技术一样，它现在只是一个特定的工业标准，因此在不同浏览器中实现的显著差别还是可以找到的。不管有没有广泛的工业支持，它也可能使用其它的数据传输机制，包括传统的框架和image-cookie方法，以及Flash或java中二进制桥的使用。
无论开发者使用哪种传输方法，Ajax都将JavaScript在网络应用中提升到了一个前所未有的重要地位。现在JavaScript对重要的数据收集、数据通信、消费机制都有影响，所以它不再被认为是没有重大作用的二级网络技术。
认为JavaScript技术有毒的开发者们试图使用工具或框架产生其它的语言如java（如谷歌网络工具）来避免使用这种语言，或者在组件或标签后隐藏代码（例如.Net和Ruby）。然而最终，JavaScript仍会在应用中。最好是理解并学会直接使用它，因为只要你使用Ajax，你就使用了很多的JavaScript。
Ajax是内嵌在网络中的，所以坏代码对网络管理员和开发者来说意味着大量的故障修理，底线是鼓励好的、有网络意识的编码。用于其他语言的具有同样组织的“规则和工具”——代码规范、测试机制和源码控制也必须应用于JavaScript，以此来确保Ajax的可支持性和健壮性。
3）XML是不需要的
尽管缩略词中有“x”，但是Ajax并不需要XML。XMLHttpRequest对象可以传输任意的文本格式。对于很多Ajax开发者来说，作为一种数据格式JavaScript对象符号甚至是纯JavaScript代码段更有意义，因为JavaScript是消费环境。有的开发者喜欢以纯文本或HTML代码段做为网页的输入，也有的使用像不太著名的YAML标记语言或逗号分隔值这样的数据格式。
当然，使用XML是可能的也是应当的，只是不是必需的。XMLHttpRequest对象不支持使用二进制格式上传文件，但是考虑到Flash使用一种叫做活动消息格式（Action Message Format）的二机制格式，所以在Ajax应用中也可能很快地找到类似的性质。你应该知道网络中的哪种机制正在被网络淘汰，因为淘汰的不总是XML，也要确保能够分析出这些机制的性能和安全性。
4）为HTTP请求的增加做好准备
对网络管理员来说，支持Ajax应用最明显的问题是结构化编程方式使网络应用的使用从只有几百KB的某些不频繁响应的程序组变为更多连续的小型HTTP请求交换。这意味着网络绑定的网页和应用服务器会发现他们比以前更繁忙。Ajax将为服务器和网络应用做些什么取决于这些应用是如何建立的——开发者们一定要明白他们使用的应用间的网络冲突。
5）仔细地优化Ajax请求
网络应用应该坚持发送更少的数据、更少的发送次数的网络传输规则。但是这也不是说这种规则被开发者们广泛地遵循。对网络来说很幸运的是， Ajax响应的HTTP压缩可以减少响应尺寸，并且在所有现代的浏览器中都支持。但是由于动态压缩的额外开销，如果响应相对较小速度也不会改变太多。这也就是说，对网络管理员来说在服务器端打开压缩机制是明智的，但是需要明白的是，使用Ajax应用不会比使用传统的网络应用获得的更多。
我们一般使用缓存来减少发送数据的次数。但是，尽管由浏览器提供的特定假设不会在同一段时间里再次获取URL，大多数的Ajax实现还是公开敌视缓存。许多Ajax开发人员不是使用缓存，而是通过头设置或URL的唯一性来积极地战胜缓存。
用JavaScript写的客户端Ajax缓存使得对付缓存成为可能，但是大多数的Ajax库不执行这样的功能。网络专家应该为开发者们展示缓存的好处，因为Ajax使用缓存的好处要比使用压缩多得多。
6）认识到两个连接限制
Ajax应用向同一个URL发送两个同步的连接是受HTTP限制的。这是HTTP协议的设计方式，不是什么浏览器问题或浏览器限制。好消息是，它使许多Ajax开发者远离了服务器的突然崩溃，尽管微软的Internet Explorer 8被认为在这种限制之外运行得很好。非正式的Ajax应用可能是麻烦的，随着浏览器不断地改变规则，网络管理员们应该随时关注提出请求的数量，跟应用开发者们一起避免像快速投票（fast polling）或长期持有连接这样的设计模式。
7）小心响应顺序
在传统的网络应用中，TCP/IP通信协议的网络影响——如HTTP响应接收的缺乏秩序，通常不被开发者和使用者所注意。基础单元、HTML文件在其他对象之前被接收，接着就触发请求。任何接下来的请求都触发整个新的基础文件，从而保证顺序。Ajax将这种固有的顺序摒除了，但是，由于这样，基于一定顺序的应用需要一个响应队列。但Ajax框架并不始终理解这个相关网络。因此，再一次地确认Ajax应用的开发者们了解这些相关的网络级别。
8）理解“层8”纠错的影响
多年来，用户们一直都是通过重载页面或按“后退按钮”来纠正网络传输质量。简而言之，用户这样做有助于减轻网络问题，因为错误一般发生在预期的页面绘制之间。但是，通过Ajax应用错误不再那么明显。可糟糕的是，由于简单的、动画的GIF旋转循环提供的正确的请求状态信息很少，用户经常将错误误传。
开发者们很烦恼，因为许多库在认识到发生了超时时不再响应，一定发生重试，而且服务器错误和数据错误会突然出现。因为JavaScript检测显示的通信和代码错误很少出现在客户端，所以（使用户）无忧的无知是一种规范。为了使管理员正确地使用Ajax，更多的应用级监控是必需的。
9）旧的安全威胁被二次曝光
如果你听信专家的，Ajax可能会显现得产生更多的攻击页面，但是事实是它不会比传统的网络应用开发环境更不安全，因为传送给可信任的服务器的HTTP输入——头消息、检索字符串和消息体是一样的。如果在你的网络开发组可信任的客户端代码和输入数据不被暗地里禁止，那么Ajax将会使事情朝着那个方向推进。
跨站点脚本（XSS）不是在Ajax中的一个新的脆弱点，它只是在JavaScript中更常见，尤其当应用允许使用规定（state）数据时。
跨站点请求伪造物也不是在Ajax中的新现象，但是如果应用开发者们不适当地检查在Ajax应用中的HTTP 引用（原文如此）头和管理session，将是为伪造物们开了门，尽管可能现在更糟糕了。
黑客，像开发者们一样，现在更感兴趣于使用和滥用增加了潜在漏洞的JavaScript。网络专家们应该确定开发者们意识到了即使客户端代码在适当的位置混乱也可能被利用，所以不管是不是Ajax数据输入始终都要被过滤和杀毒。
10） 遵守相同的起始地址做为保护
在安全的积极方面，JavaScript的SOP（同一起始地址策略）被完全地强迫应用在基于XMLHttpRequest的Ajax应用中。这个策略确保了脚本不能跟自己发行的以外的域进行通话。从开发者的观点，这也是让人非常烦恼的，因为这意味着来自ajaxref.com的网页服务不能跟来自www.ajaxref.com的URL进行通话，尽管这是同一台服务器上的，但它们不是同一个域。DNS匹配跟这个没关系，这是用于SOP的字符串检查。
SOP也会严重的束缚开发者在客户端努力进行网络服务的能力。显然，最好的方法是在服务器端使用代理来响应发送给其他服务器的请求并将这些结果组合起来。但是许多Ajax开发者们试图打破这个同一起始地址的限制。使用《script》标签来代替XMLHttpRequest对象作为传输引入了危险的信任假设，而且导致了关注整个Ajax安全的开始。
现在，随着像FireFox3和IE8这样使用自己的跨域请求工具的浏览器的出现，更多的麻烦肯定即将来临。像Java的安全砂箱概念的情况似的，SOP限制被引进只是避免开发者们破坏安全。绕过这些安全措施要极为谨慎。
最后，请明确你的需求，注意你想要的是什么。
通过Ajax，丰富的应用界面工具集将赢得一个项目，但是坏的配管系统可能会搞垮它。如果一个丰富的Ajax应用的约定在偶尔很脆弱的网络环境中传输，那么用户会对察觉到应用的不稳定感到很失望，尽管它有华而不实的界面。为了实现桌面式的品质，网络专家们必须关于特定的网络和安全原理对Ajax开发者们进行培训，并且提供一个固定且连续的监控传输平台，这个平台包含JavaScript机能和来自用户感觉的网络性能的客户端检测。用户们看到的丰富的网络应用通常使用正常——例如像那些来自Google的网络应用，如果不这样将是冒险的努力。
