Ajax 작동 방식에 대한 심층 분석

이 기사는 주로 Ajax의 심층 해부학의 작동 원리를 소개합니다. 편집자는 그것이 꽤 좋다고 생각하므로 이제 공유하고 참고로 제공하겠습니다. 편집자를 따라가서 살펴보자

1. ajax 기술의 배경

ajax 기술의 인기가 구글의 활발한 홍보에 힘입은 것은 부정할 수 없다. 바로 ajax 기술의 강력한 홍보 때문이다. Google Earth, Google 제안 및 Gmail에 의해 광범위한 응용 프로그램이 Ajax의 인기를 낳았습니다. 이는 또한 Microsoft를 매우 당혹스럽게 만듭니다. 왜냐하면 Microsoft는 1997년 초에 Ajax의 핵심 기술을 개발했고, 1999년 IE5가 출시되었을 때 XmlHttpRequest 개체를 지원하기 시작했고 Microsoft는 이미 Ajax를 사용하기 시작했기 때문입니다. MSDN 웹 사이트 메뉴의 일부 응용 프로그램과 같은 일부 제품에서 사용됩니다. 불행하게도 마이크로소프트는 알 수 없는 이유로 Ajax의 핵심 기술을 발명한 이후 그 잠재력을 깨닫지 못하고 개발, 홍보하지 못하고 보류해 버렸다. 저는 개인적으로 이것이 매우 이상하다고 생각합니다. 왜냐하면 Microsoft의 자원과 전략적 비전으로 인해 Ajax 기술의 전망을 볼 수 없어야 하기 때문입니다. 유일한 설명은 당시 주요 경쟁자가 Netscape의 실종으로 인해 마비되고 느려졌다는 것입니다. 결국 마이크로소프트에 대한 IBM의 전략적 실수 등 거대 기업들도 낮잠을 자고 있다. Ajax에서 현재 경쟁업체인 Google의 선두 위치를 차지하게 된 것은 바로 이러한 실수 때문이었습니다. 사실 Ajax 기술에 대한 Google의 리더십은 나중에 Ajax의 결함에 대해 언급할 때 논의될 것입니다. 이제 Microsoft는 이 문제를 인식하고 ajax 분야에서도 따라잡기 시작했습니다. 예를 들어 자체 ajax 프레임워크 아틀라스를 출시하고 .NET 2.0에서 비동기 콜백을 구현하기 위한 인터페이스, 즉 ICallBack 인터페이스도 제공했습니다. . 그렇다면 Microsoft가 Ajax에서 뒤처지는 것에 대해 왜 그렇게 긴장합니까? 이제 Ajax 기술의 심오한 의미를 분석해 보겠습니다.

2. Ajax 기술의 중요성

우리 모두는 일상적인 개발에서 Ajax를 어느 정도 접하거나 적용하고 있습니다. Ajax 기술의 중요성에 있어서 우리가 가장 주목하는 것은 의심할 여지 없이 사용자 개선입니다. 경험. 그러나 컴퓨터와 인터넷의 미래 발전 추세를 결합해 보면 Ajax 기술이 어떤 측면에서는 이러한 추세를 대표한다는 것을 알 수 있습니다. 왜 이런 말을 하는가? 우리는 컴퓨터의 출현 이후 데스크톱 소프트웨어가 항상 절대적인 지배적 위치를 점해 왔지만 인터넷의 출현과 성공으로 인해 이 모든 것에 미묘한 변화가 일어났다는 것을 알고 있습니다. 상당수의 사람들은 조만간 데이터와 컴퓨터 소프트웨어가 데스크톱에서 인터넷으로 이동할 것이라고 믿고 있습니다. 즉, 미래의 컴퓨터는 부피가 큰 하드 드라이브를 버리고 인터넷에서 직접 데이터와 서비스를 얻을 수 있을 것입니다. 제가 대학에 다닐 때 한 교수님이 우리에게 수업을 하시면서 그런 시나리오를 상상하신 적이 있습니다. , 컴퓨터 바탕 화면에는 중복된 소프트웨어와 프로그램이 없지만 IE는 하나만 있을 것입니다. 오늘날과 아직 거리가 멀고 해결해야 할 문제가 여전히 많은 것 같지만 이것은 하나의 문제가 아니라고 생각합니다. 꿈이지만 조만간 실현될 현실이다. 글쎄요, 가장 큰 문제는 인터넷 연결이 불안정하다는 것입니다. 아무도 자신의 컴퓨터가 서버에서 데이터를 다운로드하는 것을 보고 싶어하지 않습니다. 그러면 ajax가 이 문제를 해결합니까? 문제를 해결하면 문제를 가릴 뿐이며 서버와 클라이언트 사이의 버퍼 역할을 하여 사용자가 서비스 중단이 없다고 생각하도록 속입니다. 정확하게 말하면 Ajax는 서버에서 데이터를 다운로드하는 속도를 높이지는 않지만 기다리는 시간을 덜 답답하게 만들어줍니다. 하지만 이것만으로도 엄청난 충격과 충격을 주기에 충분했고 실제로 데스크톱 소프트웨어에 큰 영향을 미쳤습니다. 예를 들어 Outlook Express와 Gmail을 비교해 보겠습니다. 전자는 일반적인 데스크톱 소프트웨어이고 후자는 ajax로 구현된 B/S 모드입니다. 실제로 후자는 전자를 서서히 대체하고 있습니다. Gmail은 이메일을 보내고 받을 때 Outlook Express와 거의 동일한 기능을 갖추고 있으며 클라이언트 프로그램을 설치할 필요가 없습니다. 이것이 바로 마이크로소프트가 Ajax의 영향을 그토록 두려워하는 주된 이유 중 하나이며, 얼마 전 실시한 조사에서 마이크로소프트는 향후 10년 내 구글을 주요 경쟁자로 꼽았다. 물론 이러한 변화로 인해 모든 데스크톱 소프트웨어가 제거되는 것은 아닙니다. 기존 브라우저 중 어느 것도 PhotoShop과 같은 데스크톱 프로그램과 같은 복잡한 이미지를 처리할 수 없습니다. 그러나 우리는 그 영향력과 영향을 무시할 수 없습니다.

3. ajax 이름에 대하여

ajax의 정식 명칭은 Asynchronous JavaScript와 XML인데, 그 중 Asynchronous는 비동기를 뜻하는데, 이는 전통적인 웹 개발에서 사용하는 동기 방식과 다릅니다.

4. 동기화 및 비동기에 대하여

비동기 전송은 문자 중심 전송이고, 동기 전송은 비트 중심 전송이며, 단위는 수신자와 발신자가 필요합니다. 전송할 때 시계는 일관됩니다.

구체적으로 비동기 전송은 비트를 작은 그룹으로 나누어 전송합니다. 일반적으로 각 그룹은 8비트 문자로 구성되며, 전송 과정에서 수신자와 송신자의 클럭이 일치할 필요는 없습니다. 즉, 보내는 당사자는 받는 당사자가 언제 도착할지 알지 못한 채 언제든지 이러한 그룹을 보낼 수 있습니다. 가장 확실한 예 중 하나는 컴퓨터 키보드와 호스트 간의 통신입니다. 키를 누르면 8비트 ASCII 코드가 사용자의 입력에 따라 언제든지 호스트로 전송됩니다. 내부 하드웨어는 언제든지 입력된 문자를 수신할 수 있어야 합니다. 이는 일반적인 비동기 전송 프로세스입니다. 비동기 전송의 잠재적인 문제는 수신자가 데이터가 언제 도착할지 모른다는 것입니다. 데이터를 감지하고 응답하기 전에 첫 번째 비트가 전달되었습니다. 마치 뒤에서 누군가가 갑자기 나타나 말을 걸어오는 것과 같으며, 반응할 시간도 없고 처음 몇 마디도 놓칠 수 없습니다. 따라서 정보의 각 비동기 전송은 수신자에게 데이터가 도착했음을 알리는 시작 비트로 시작됩니다. 이는 수신자가 전송이 끝날 때 데이터 비트를 응답하고 수신하고 캐시할 수 있는 시간을 제공하며 정지 비트는 종료를 나타냅니다. 이 정보 전송의. 관례적으로 유휴(데이터를 전송하지 않는) 회선은 실제로 이진수 1을 나타내는 신호를 전달합니다. 스텝 전송의 시작 비트는 신호를 0으로 만들고, 나머지 비트는 전송된 데이터 정보에 따라 신호를 변경합니다. 마지막으로 정지 비트는 신호를 다시 1로 변경하여 다음 시작 비트가 도착할 때까지 유지됩니다. 예를 들어, 키보드의 숫자 "1"은 8비트 확장 ASCII 인코딩에 따라 "00110001"을 전송합니다. 동시에 8비트 비트 앞에 시작 비트와 정지 비트를 추가해야 합니다. 따를 것입니다.

동시에 전송되는 비트 패킷은 훨씬 더 큽니다. 각각 고유한 시작 비트와 정지 비트를 사용하여 각 문자를 독립적으로 보내는 대신 이를 결합하여 함께 보냅니다. 우리는 이러한 조합을 데이터 프레임 또는 간단히 프레임이라고 부릅니다.

　데이터 프레임의 첫 번째 부분에는 동기화 문자 세트가 포함되어 있습니다. 이는 앞서 언급한 시작 비트와 유사한 비트의 고유한 조합으로 프레임이 도착했음을 수신자에게 알리는 데 사용되지만 수신자가 샘플링 속도는 비트 도착 속도와 일치하므로 송신 및 수신 당사자가 동기화됩니다.

　프레임의 마지막 부분은 프레임 끝 표시입니다. 동기화 문자와 마찬가지로 앞서 언급한 정지 비트와 유사한 고유한 비트 문자열이기도 하며 다음 프레임이 시작되기 전에 예정된 다른 데이터가 없음을 나타내는 데 사용됩니다.

동기 전송은 일반적으로 비동기 전송보다 훨씬 빠릅니다. 수신자는 각 문자를 시작하고 중지할 필요가 없습니다. 프레임 동기화 문자가 감지되면 다음 데이터가 도착할 때 이를 수신합니다. 또한 동기 전송의 오버헤드도 상대적으로 작습니다. 예를 들어, 일반적인 프레임에는 500바이트(즉, 4000비트)의 데이터가 있을 수 있으며, 여기에는 100비트의 오버헤드만 포함될 수 있습니다. 이때 추가된 비트는 전체 전송 비트 수를 2.5% 증가시키며, 이는 비동기 전송의 25% 증가에 비해 훨씬 작은 수치이다. 데이터 프레임의 실제 데이터 비트 수가 증가함에 따라 오버헤드 비트의 비율도 그에 따라 감소합니다. 그러나 데이터 비트가 길수록 데이터를 캐시하는 데 필요한 버퍼가 커지므로 프레임 크기가 제한됩니다. 또한 프레임이 클수록 전송 매체를 차지하는 연속 시간이 길어집니다. 극단적인 경우에는 다른 사용자가 너무 오래 기다리게 만들 수 있습니다.

동기화와 비동기성의 개념을 이해한 후에는 Ajax가 비동기식 요청 방법을 사용하는 이유를 더 명확하게 이해해야 합니다. 예를 들어, 귀하의 집이 위치한 지역사회가 어떤 사정으로 인해 단수에 직면한 경우, 관련 부서에서는 두 가지 계획을 발표했습니다. 하나는 영업 시간 이후에 단수를 완전히 중단하는 것입니다. 두 번째는 10시간 동안 물을 완전히 차단하지 않는 방법인데, 이 10시간 동안 물이 완전히 차단되지는 않지만, 10시간 후에는 유량이 이전보다 훨씬 적어지게 됩니다. 당신이라면 선택하시겠습니까? 분명히 후자인 것 같습니다.

5. Ajax에 포함된 기술

Ajax가 새로운 기술이 아니라 여러 가지 원천 기술의 조합이라는 것은 누구나 알고 있습니다. 이는 다음과 같은 기술로 구성됩니다.

1. CSS와 XHTML을 사용하여 표현합니다.

2. 상호 작용 및 동적 표시를 위해 DOM 모델을 사용합니다.

3. XMLHttpRequest를 사용하여 서버와 비동기적으로 통신합니다.

4. 자바스크립트를 사용하여 바인딩하고 호출합니다.

위 기술 중 XmlHttpRequest 객체를 제외한 다른 모든 기술은 웹 표준을 기반으로 하며 널리 사용됩니다. 비록 XMLHttpRequest는 아직 W3C에서 채택되지 않았지만 이미 거의 모든 주요 브라우저에서 표준이 되었기 때문입니다. 현재는 지원합니다.

6. Ajax 원리와 XmlHttpRequest 객체

Ajax의 원리는 단순히 XmlHttpRequest 객체를 통해 서버에 비동기 요청을 보내고, 서버에서 데이터를 얻은 다음, javascript를 사용하여 DOM을 작동하고 페이지를 업데이트하는 것입니다. . 가장 중요한 단계는 서버에서 요청 데이터를 얻는 것입니다. 이 과정과 원리를 이해하려면 XMLHttpRequest에 대한 이해가 필요합니다.

　XMLHttpRequest는 ajax의 핵심 메커니즘으로 IE5에서 처음 도입되었으며 비동기 요청을 지원하는 기술입니다. 간단히 말해서, JavaScript는 사용자를 차단하지 않고 적시에 서버에 요청하고 응답을 처리할 수 있습니다. 새로 고침 효과를 얻지 못합니다.

이제 XMLHttpRequest부터 시작하여 어떻게 작동하는지 살펴보겠습니다.

먼저 XMLHttpRequest 객체의 속성을 살펴보겠습니다.

해당 속성은 다음과 같습니다.

1. onreadystatechange 상태가 변경될 때마다 트리거되는 이벤트에 대한 이벤트 핸들러입니다.

2. responseText 서버 프로세스에서 반환된 데이터의 문자열 형식입니다.

3. responseXML 서버 프로세스에서 반환된 DOM 호환 문서 데이터 개체입니다.

4. status 일반적인 404(찾을 수 없음) 및 200(준비) 등 서버에서 반환된 숫자 코드

5. status 상태 코드와 함께 제공되는 텍스트 문자열 정보

6. readyState 개체 상태 값

　　0(Uninitialized) 객체가 생성되었으나 초기화되지 않았습니다(open 메소드가 아직 호출되지 않음)
　　1(Initialized) 객체가 생성되었으나 send 메소드가 아직 호출되지 않았습니다
　　2( 데이터 전송) 전송 메소드를 호출했지만 현재 상태와 http 헤더를 알 수 없습니다
　　3 (데이터 전송 중) 데이터의 일부가 수신되었습니다. 응답과 http 헤더가 불완전하므로 가져오는 중 오류가 발생합니다.

　　4 (완료) 이때 responseXml과 responseText를 전달하면 완전한 응답 데이터를 얻을 수 있습니다.

그러나 브라우저 간의 차이로 인해 XMLHttpRequest를 생성합니다. 객체에는 다른 방법이 필요할 수 있습니다. 이러한 차이는 주로 IE와 다른 브라우저 사이에 반영됩니다. 다음은 XMLHttpRequest 객체를 생성하는 비교적 표준적인 방법입니다.

function CreateXmlHttp() {

    //非IE浏览器创建XmlHttpRequest对象
    if (window.XmlHttpRequest) {
        xmlhttp = new XmlHttpRequest();
    }

    //IE浏览器创建XmlHttpRequest对象
    if (window.ActiveXObject) {
        try {
            xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
        }
        catch (e) {
            try {
                xmlhttp = new ActiveXObject("msxml2.XMLHTTP");
            }
            catch (ex) { }
        }
    }
}

function Ustbwuyi() {

    var data = document.getElementById("username").value;
    CreateXmlHttp();
    if (!xmlhttp) {
        alert("创建xmlhttp对象异常！");
        return false;
    }

    xmlhttp.open("POST", url, false);

    xmlhttp.onreadystatechange = function () {
        if (xmlhttp.readyState == 4) {
            document.getElementById("user1").innerHTML = "数据正在加载...";
            if (xmlhttp.status == 200) {
                document.write(xmlhttp.responseText);
            }
        }
    }
    xmlhttp.send();
}

위와 같이 함수는 먼저 XMLHttpRequest의 전체 상태를 확인하고 완료(readyStatus=4), 즉 데이터가 전송되었는지 확인합니다. 그런 다음 서버 설정에 따라 요청 상태를 쿼리합니다. 모든 것이 준비되면(상태=200) 다음 필수 작업을 수행합니다.

XmlHttpRequest의 두 가지 방법인 open과 send에 대해 open 방법은 다음을 지정합니다.

a. 서버에 제출된 데이터 유형, 즉 post 또는 get.

b, URL 주소를 요청하고 매개변수를 전달했습니다.

c. 전송 방법, false는 동기, true는 비동기를 의미합니다. 기본값은 true입니다. 비동기 통신 모드(true)인 경우 클라이언트는 서버의 응답을 기다리지 않고, 동기 모드(false)인 경우 클라이언트는 다른 작업을 수행하기 전에 서버가 메시지를 반환할 때까지 기다려야 합니다. 실제 필요에 따라 동기화 방법을 지정해야 합니다. 일부 페이지에서는 여러 요청이 발행되거나 심지어 구성, 계획 및 형성되는 대규모, 고강도 요청이 발생할 수 있으며 후자는 이전 요청을 덮어씁니다. . 물론 동기화 방법을 지정해야 합니다.

Send 메소드는 요청을 보내는 데 사용됩니다.

　XMLHttpRequest의 작업 흐름을 알면 XMLHttpRequest가 서버에 요청을 보내는 데 완전히 사용되고 그 역할은 이것으로 제한되어 있지만 그 역할은 전체 Ajax 구현의 핵심이라는 것을 알 수 있습니다. two 요청을 하고 요청에 응답하는 프로세스입니다. 이는 전적으로 클라이언트측 기술입니다. XMLHttpRequest는 서버와 클라이언트 간의 통신 문제를 처리하므로 이것이 매우 중요합니다.

이제 우리는 Ajax의 원리를 어느 정도 이해할 수 있을 것 같습니다. 우리는 서버를 일반 텍스트 스트림을 반환하는 데이터 인터페이스로 생각할 수 있습니다. 물론 이 텍스트 스트림은 XML 형식, HTML, Javascript 코드 또는 단순한 문자열일 수 있습니다. 이때 XMLHttpRequest는 서버에서 이 페이지를 요청하고 서버는 텍스트 결과를 페이지에 기록합니다. 이는 클라이언트가 결과를 비동기적으로 얻은 후 직접 작성하지 않는다는 점입니다. 페이지에 표시되지만 먼저 자바스크립트로 처리된 다음 페이지에 표시됩니다. Magicajax 등과 같이 현재 널리 사용되는 많은 Ajax 컨트롤은 DataSet과 같은 다른 데이터 유형을 반환할 수 있으며 본질적으로 둘 사이에는 큰 차이가 없습니다.

7. ajax의 장점

기본적으로 모든 사람은 Ajax가 우리에게 제공하는 이점에 대해 깊이 이해하고 있습니다. 여기서는 몇 가지 사항에 대해 간략하게 설명하겠습니다.

1. 가장 큰 요점은 페이지가 그렇지 않다는 것입니다. 페이지가 서버와 통신하여 사용자에게 매우 좋은 경험을 제공합니다.

　 2. 비동기 모드를 사용하여 사용자 작업을 방해하지 않고 서버와 통신하고 더 빠른 응답 기능을 갖습니다.

　 3. 기존에 서버에서 부담하던 작업 중 일부를 클라이언트로 이관하여 클라이언트의 유휴 용량을 활용하여 처리할 수 있어 서버 및 대역폭의 부담을 줄이고 공간 및 광대역 임대 비용을 절약할 수 있습니다. 그리고 서버의 부담을 줄이기 위해 ajax의 원칙은 "요청 시 데이터를 가져오는 것"인데, 이는 중복된 요청과 응답으로 인해 발생하는 서버의 부담을 최소화할 수 있습니다.

4. 표준화되고 널리 지원되는 기술을 기반으로 플러그인이나 작은 프로그램을 다운로드할 필요가 없습니다.

8. Ajax의 단점

이제 Ajax의 단점에 집중하겠습니다. 왜냐하면 우리 대부분은 일반적으로 사용자 경험 개선과 같이 Ajax가 제공하는 이점에 관심을 기울이기 때문입니다. Ajax로 인한 단점은 무시되었습니다.

　아래에 설명된 ajax의 결함은 모두 이로 인한 것입니다.

1. Ajax는 뒤로 버튼을 종료하여 브라우저의 뒤로 메커니즘을 파괴합니다. 뒤로 버튼은 표준 웹 사이트의 중요한 기능이지만 JavaScript에서는 제대로 작동하지 않습니다. 이는 ajax로 인해 발생하는 심각한 문제입니다. 사용자가 이전 작업으로 돌아가서 취소하려는 경우가 많기 때문입니다. 그렇다면 이 문제에 대한 해결책은 없을까? 대답은 '예'입니다. Gmail에서 사용되는 ajax 기술이 이 문제를 해결한다는 것을 알고 있습니다. 그러나 이는 ajax 메커니즘을 변경하는 것이 아닙니다. 이렇게 하려면 숨겨진 IFRAME을 만들거나 사용하여 사용자가 기록에 액세스하기 위해 뒤로 버튼을 클릭할 때 페이지의 변경 사항을 재현하면 됩니다. (예를 들어 사용자가 Google Maps에서 다시 클릭하면 숨겨진 IFRAME에서 검색한 다음 검색 결과를 Ajax 요소에 반영하여 애플리케이션 상태를 당시의 상태로 복원합니다.)

그러나 이 문제는 문제를 해결할 수는 있지만 이로 인해 발생하는 개발 비용은 매우 높으며 이는 Ajax 프레임워크에서 요구하는 빠른 개발에 반합니다. 이는 ajax로 인한 매우 심각한 문제입니다.

2. 보안 문제

기술은 IT 기업에 새로운 보안 위협을 가져오기도 합니다. Ajax 기술은 기업 데이터에 대한 직접적인 채널을 구축하는 것과 같습니다. 이를 통해 개발자는 이전보다 더 많은 데이터와 서버 로직을 실수로 노출할 수 있습니다. Ajax 로직은 클라이언트 측 보안 스캐닝 기술에서 숨겨질 수 있으므로 해커가 원격 서버에서 새로운 공격을 생성할 수 있습니다. 또한 Ajax는 크로스 사이트 스크립팅 공격, SQL 주입 공격, 자격 증명 기반 보안 취약점과 같은 일부 알려진 보안 약점을 피하는 것도 어렵습니다.

3. 검색 엔진에 대한 지원이 상대적으로 약합니다.

4. 프로그램의 예외 메커니즘을 제거했습니다. 적어도 현재 관점에서 볼 때 ajax.dll 및 ajaxpro.dll과 같은 ajax 프레임워크는 프로그램의 예외 메커니즘을 파괴합니다. 이 문제에 대해서는 개발 과정에서 접한 적이 있는데, 확인해보니 인터넷상에 관련 소개가 거의 없는 것 같습니다. 나중에 Ajax와 전통적인 양식 제출 모드를 사용하여 데이터 조각을 삭제하는 실험을 직접 수행했는데... 이는 디버깅에 큰 어려움을 가져왔습니다.

5. 이 외에도 URL의 원래 의도와 리소스 위치를 위반하는 등의 몇 가지 다른 문제가 있습니다. 예를 들어, 제가 여러분에게 URL 주소를 제공한다면, Ajax 기술이 사용된다면 URL 주소 아래에 보이는 것과 이 URL 주소 아래에 보이는 것이 다를 수도 있습니다. 이는 자원 포지셔닝의 원래 의도에 어긋납니다.

6. 일부 휴대용 장치(예: 휴대폰, PDA 등)는 현재 Ajax를 잘 지원하지 않습니다. 예를 들어 모바일 브라우저에서 Ajax 기술을 사용하여 웹 사이트를 열면 현재는 지원하지 않습니다. , 이 문제는 우리와 관련이 없습니다.

9. 여러 ajax 프레임워크

현재 우리가 주로 사용하는 ajax 프레임워크에는 ajax.dll, ajaxpro.dll, Magicajax.dll 및 Microsoft의 아틀라스 프레임워크가 포함됩니다. 두 프레임워크 Ajax.dll과 Ajaxpro.dll 사이에는 큰 차이가 없지만, Magicajax.dll은 캡슐화 측면에서 더 강력합니다. 예를 들어 앞서 말했듯이 ajax는 모든 문자열을 반환합니다. .magicajax는 그것을 캡슐화합니다. 하지만 이 기능은 우리에게 큰 편리함을 가져다 줄 수 있습니다. 예를 들어, 페이지에 목록이 있고 목록의 데이터가 지속적으로 변경되는 경우 Magicajax를 사용하여 이를 처리할 수 있습니다. 업데이트된 목록 컨트롤은 Magicajax 컨트롤 내에 배치되고 업데이트 간격은 페이지 로드에서 정의됩니다. atlas의 원리는 Magicajax의 원리와 유사합니다. 그러나 주의가 필요한 한 가지 사실은 이러한 프레임워크가 IE만 지원하고 브라우저 호환성을 다루지 않는다는 것입니다. 디컴파일 도구를 사용하여 코드를 살펴보면 이를 알 수 있습니다.

이러한 프레임워크 외에도 가장 일반적으로 사용되는 방법은 xmlHttpRequest 객체를 직접 생성하는 것입니다. 이 방법은 이전 프레임워크보다 더 유연합니다. 또한 여기서는 aspnet2.0과 함께 제공되는 비동기 콜백 인터페이스에 대해서도 언급하고 싶습니다. ajax와 마찬가지로 로컬 새로 고침을 수행할 수도 있지만 해당 구현은 실제로 xmlhttprequest 개체를 기반으로 합니다. 물론 이것은 Microsoft의 경쟁 전략입니다.

10.Ajax 예시

사용자 이름이 등록되었는지 확인합니다.

두 가지 방법

　　1 ajax.dll

　　2 xmlhttprequest 객체를 직접 작성합니다

10 ajax에서 흔히 발생하는 몇 가지 오류

　　1. 구성 문제

　pageload

11. 프런트엔드 부분은 백그라운드에서 호출되는 메소드에서 호출됩니다...

위 내용은 Ajax 작동 방식에 대한 심층 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!