關於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（如Google網路工具）來避免使用這種語言，或者在組件或標籤後隱藏代碼（例如.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的網路應用，如果不這樣將是冒險的努力。