1) Ajax là một ý tưởng, không phải là cụm từ Ajax tuy đã được giải thích rõ ràng là viết tắt của cụm từ Asynchronous JavaScript and XML nhưng tên đầy đủ này vẫn không hoàn toàn thích hợp vì nó đơn giản hóa quá mức lịch sử của công nghệ cũng như những tùy chọn bổ sung nằm trong chính bản thân nó. Chính xác hơn, Ajax bao gồm ý tưởng trong đó các ứng dụng web có thể được xây dựng để chọn trong số vòng lặp “post-wait-repeat” được sử dụng trong các ứng dụng Web trình chủ. Ajax cho phép các ứng dụng web chuyển một cách liên tục và mềm dẻo hơn, nhưng việc update lại tăng lên. Nó cung cấp cho người dùng một phương pháp phong phú và khả năng tương tác tốt hơn với những gì nằm bên dưới ứng dụng Web. Để được thành phần này thì các chuyên gia về mạng càng phải thực hiện nhiều công việc trong kiểm tra và giám sát bảo mật cần thiết cũng như khả năng tiềm ẩn sự biến đổi của mạng và máy chủ. 2) Thực sự tất cả theo JavaScript Các ứng dụng Ajax được viết theo ngôn ngữ JavaScript và thường dựa vào đối tượng XMLHttpRequest để thực hiện việc truyền thông, cách làm này sẽ tạo ra đường đi của nó thông qua việc xử lý World Wide Web. Cũng giống như các công nghệ Web khác, công nghệ Ajax lúc này cũng chỉ là một chuẩn công nghệ đặc biệt, những điểm khác nhau nổi bật có thể phát hiện thấy trong các bổ sung vào các trình duyệt khác nhau của nó. Ajax có thể sử dụng các cơ chế truyền tải dữ liệu khác – có hoặc không có sự hỗ trợ rộng rãi trong CNTT – với các ứng dụng Ajax, như frame truyền thống và các phương pháp image-cookie cũng như sử dụng các cầu binary để liên kết với Flash hoặc Java Không quan tâm đến phương pháp truyền tải được sử dụng bởi các chuyên gia phát triển, Ajax đã làm cho JavaScript trở nên quan trọng hơn bên trong một ứng dụng web so với những gì nó làm được trước đây. JavaScript lúc này hiện nắm giữ vai trò sưu tập các dữ liệu quan trọng, truyền thông và hoạt động, chính vì vậy nó có thể được coi như một công nghệ web lớp thứ hai không có các tác động nghiêm trọng. Các chuyên gia phát triển phần mềm cho rằng công nghệ JavaScript mang tính độc và muốn né tránh ngôn ngữ này bằng một công cụ hoặc framework tạo nó từ một ngôn ngữ khác như Java (Google Web Toolkit là một ví dụ), hoặc dấu các thành phần code ẩn hoặc các tag (như với .Net hoặc Ruby). Mặc dù vậy JavaScript vẫn là một ứng dụng. Việc tìm hiểu ứng ngôn ngữ này và nắm được nó một cách trực tiếp sẽ giúp bạn rất nhiều vì nếu muốn sử dụng Ajax thì bạn sẽ sử dụng đến rất nhiều JavaScript. 3) Không cần đến XML Mặc dù có chữ “X” trong nhóm từ của Ajax nhưng thực sự nó không cần đến XML. Đối tượng XMLHttpRequest có thể truyền tải bất kỳ một định dạng văn bản nào. Với nhiều chuyên gia phát triển phần mềm Ajax, ký hiệu đối tượng JavaScript (JavaScript Object Notation) hoặc thậm chí các đoạn mã JavaScript thô cũng tạo ra nhiều ý nghĩa như một định dạng dữ liệu, cho rằng JavaScript là môi trường chi phối. Với đầu vào trực tiếp trong các tài liệu, các chuyên gia phát triển phần mềm khác có thể sử dụng văn bản thô hoặc các đoạn HTML. Vẫn còn một số thành phần khác sử dụng các định dạng dữ liệu như vậy như ngôn ngữ markup YAML ít được biết đến. Rõ ràng hoàn toàn có thể và hợp lý để sử dụng XML, nhưng Ajax vẫn không yêu cầu bắt buộc. Sử dụng các định dạng nhị phân cho việc upload các file vẫn không được hỗ trợ bởi đối tượng XMLHttpRequest, nhưng nên cần biết rằng Flash sử dụng một định dạng nhị phân được gọi là Action Message Format, chính vì vậy các tính năng tương tự như vậy sẽ một sớm một chiều có trong các ứng dụng của Ajax. Bạn nên biết định dạng nào đang được sử dụng trên mạng vì nó không phải lúc nào cũng là XML, và cũng bảo đảm bạn có thể phân tích định dạng cho vấn đề hiệu suất và bảo mật. 4) Kế hoạch cho việc tăng các request HTTP Vấn đề nổi cộm nhất đối với các quản trị mạng trong việc hỗ trợ các ứng dụng Ajax là mẫu lập trình kiến trúc đã thay đổi vấn đề sử dụng mạng của các ứng dụng web từ việc như xử lý khối, sự phản ứng không liên tục với hàng trăm KB đến sự thay đổi mang tính liên tục trong các đáp trả HTTP nhỏ hơn. Điều này có nghĩa rằng Web và các máy chủ ứng dụng có thể bận rộn hơn trước rất nhiều. Những gì Ajax sẽ thực hiện với mạng và máy chủ của bạn phụ thuộc vào cách ứng dụng được thiết kế như thế nào, hãy bảo đảm cho các chuyên gia phát triển ứng dụng hiểu được sự ảnh hưởng của các ứng dụng của họ với mạng như thế nào. 5) Tối ưu hóa các yêu cầu Ajax một cách thận trọng Các ứng dụng web nên gắn với trong việc phân phối mạng đó là gửi ít dữ liệu. Tuy vậy điều này không có nghĩa rằng nguyên lý này cần phải tuân theo một cách rộng rãi bởi các chuyên gia phát triển phần mềm. Một ưu điểm cho mạng, việc nén HTTP cho các đáp trả của Ajax có thể giảm được kích thước và được hỗ trợ trong nhiều trình duyệt hiện đại. Tuy vậy vì overhead của file nén mang tính động nên tốc độ có thể không được cải thiện nhiều nếu các đáp trả tương đối nhỏ. Điều này có nghĩa rằng các quản trị viên mạng nên cho phép nén trên máy chủ Web, nhưng họ cần phải hiểu được rằng với các ứng dụng Ajax thì hiệu suất của việc này không lớn bằng các ứng dụng web trước kia. Để gửi dữ liệu ít đi, chúng ta thường sẽ sử dụng đến vấn đề caching. Tuy vậy hầu hết các bổ sung của Ajax đều có thể là thù địch của caching với một giả định là các trình duyệt mà không liên quan đến các re-fetching URL trong cùng một session. Thay cho làm việc với caching thì nhiều chuyên gia phát triển Ajax lại thủ tiêu caching thông qua thiết lập header hoặc URL đơn nhất. Hoàn toàn có thể nhắm đến các vấn đề caching với Ajax cache ở trình khách được viết bằng JavaScript, nhưng hầu hết các thư viện của Ajax lại không bổ sung tính năng như vậy. Các chuyên gia về mạng nên giới thiệu cho các nhà phát triển về lợi ích của caching vì Ajax có thể sẽ mang lại nhiều lợi ích từ vấn đề này hơn nén. 6) Thừa nhận về sự hạn chế two-connection Các ứng dụng Ajax bị hạn chế bởi HTTP đối với hai kết nối đồng thời với cùng một URL. Đây chính là cách giao thức HTTP được thiết kế, không bị hạn chế. Tuy nhiên có nhiều chuyên gia phát triển phần mềm Ajax vẫn xa lầy vào một máy chủ một cách tình cờ dẫu cho Internet Explorer 8 của Microsoft được hỗ trợ để thực hiện vượt ra khỏi các hạn chế này. Một số ứng dụng không hay của Ajax có thể có vấn đề và với các trình duyệt đang thay đổi, các quản trị mạng cần phải nắm bắt được số lượng các yêu cầu tạo ra và làm việc với các chuyên gia phát triển ứng dụng để tránh sử dụng các mẫu thiết kế như poll hoặc các kết nối trợ giúp dài. 7) Xem xét đến thứ tự xử lý Với các ứng dụng web truyền thống, sự ảnh hưởng truyền thông TCP/IP (như việc thiếu thứ tự đáp trả HTTP nào sẽ được nhận) nhìn chung không được chú ý. Tài liệu HTML được nhận trước các đối tượng khác và sau đó nó sẽ kích hoạt yêu cầu. Bất kỳ một yêu cầu xảy ra sau đều kích hoạt một tài liệu mới hoàn toàn, do đó vẫn bảo đảm được thứ tự. Tuy nhiên Ajax lại không hề sử dụng đến việc phân định thứ tự như vậy chính vì vậy sự phụ thuộc của một ứng dụng theo đúng thứ tự cần đến một hàng đợi xử lý. Ajax framework cũng không nhất quán thừa nhận mối quan tâm này. Chính vì vậy cần phải bảo đảm cho các chuyên gia phát triển ứng dụng Ajax hiểu được vấn đề này. 8) Thừa nhận sự ảnh hưởng của việc loại trừ sửa lỗi "Layer 8" Một vài năm trở lại đây, người dùng đã khắc phục chất lượng trong việc phân phối Web bằng cách reloading các trang hoặc nhất nút Back. Đơn giản, người dùng thực hiện như vậy để giúp giảm các vấn đề về mạng vì lỗi thường xuất hiện tại các thời điểm giữa các page paint. Tuy vậy với Ajax, lỗi ứng dụng lại không hiển nhiên như vậy. Người dùng thường bị báo sai về các lỗi vì vòng quay GIF động cung cấp quá ít thông tin về trạng thái đúng của yêu cầu. Các chuyên gia phát triển phần mềm là những người thiệt nhiều nhất vì nhiều thư viện không có hiệu quả trong việc thừa nhận các timeouts đó xảy ra, những lần retry phải xuất hiện, máy chủ và các lỗi dữ liệu ngày càng nhiều. Các chuẩn đoán JavaScript hiển thị việc truyền thông và các lỗi mã ít khi đúng trên phía trình khách, chính vì vậy mà người dùng thường không hay biết. Do đó cần phải có nhiều kiểm tra mức ứng dụng được yêu cầu cho các quản trị viên để hỗ trợ Ajax một cách hợp lý. 9) Những mối đe dọa về bảo mật cũ lại xuất hiện lần thứ hai Nếu bạn lắng nghe các chuyên gia, thì Ajax có thể gây tăng thêm bề mặt tấn công nhưng quả thực nó không kém an toàn hơn các môi trường phát triển ứng dụng web truyền thống nào vì các đầu vào HTTP đến trình chủ tin cậy đều có cùng các header, chuỗi truy vấn và body văn bản. Tuy nhiên nếu mã trình khách được tin tưởng hoàn toàn và nhập vào dữ liệu không được ngăn chặn trong nhóm phát triển web thì Ajax có thể gây ra những vấn đề về bảo mật tương tự như các ứng dụng web truyền thống. Cross-site scripting (XSS) không phải là lỗ hổng mới trong Ajax; nó là một lỗi chung, đặc biệt nếu một ứng dụng nào đó cho phép dữ liệu trạng thái được điều chỉnh với JavaScript. Đầu vào HTML cần được không cho phép trong hầu hết các trường hợp và HTTP Only Cookies nên được áp dụng ngay lập tức để giảm việc tấn công cookie và các tấn công khác thông qua XSS. Cũng vậy Cross Site Request Forgery cũng không phải là một lỗi mới của Ajax, nhưng nếu các chuyên gia phát triển ứng dụng của bạn không kiểm tra HTTP Referer (sic) header và quản lý session đúng cách bên trong các ứng dụng Ajax thì có thể để hổng vấn đề này. Các Hacker, cũng giống như các chuyên gia phát triển phần mềm hiện đang rất quan tâm đến việc sử dụng và lạm dụng JavaScript, điều đó càng làm tăng thêm các lỗ hổng tiềm tàng. Các chuyên gia về mạng nên bảo đảm cho chuyên gia phần mềm biết được rằng mã trình khách có thể bị thay đổi, vì vậy các dữ liệu đầu vào luôn cần được lọc và xem xét. 10) Vấn đề về chính sách cùng gốc Một mặt “positive” (mang tính ưu điểm) về bảo mật, các chính sách cùng gốc của JavaScript sẽ vẫn có hiệu lực trong ứng dụng Ajax sử dụng XMLHttpRequest. Chính sách này bảo đảm cho các kịch bản đó không liên kết với các miền bên ngoài. Từ quan điểm của các chuyên gia phát triển phần mềm, điều này có thể khá bực mình vì nó có nghĩa rằng các trang đó được đáp ứng, ví dụ là từ ajaxref.com lại không thể liên kết với URL được host trên www.ajaxref.com; thậm chí nếu nó nằm trên cùng một máy chủ thì cũng không cùng chính xác miền. DNS tương đương không có vấn đề ở đây; nó là một string-check được sử dụng bởi SOP. SOP sẽ làm vướng khả năng của các chuyên gia phát triển trong việc thực hiện một số cố gắng cho dịch vụ Web trên phía trình khách. Rõ ràng phương pháp tốt nhất là sử dụng proxy trên máy chủ để đưa ra các yêu cầu đến máy chủ khác và kết hợp các kết quả. Tuy vậy, nhiều chuyên gia phát triển phần mềm Ajax lại cố gắng ngắt các hạn chế cùng gốc. Việc sử dụng
