AJAX 비동기 및 동기

동기화는 계속하기 전에 반환 결과를 기다려야 합니다. 비동기식은 일반적으로 비동기식 결과를 모니터링해야 합니다.
동기화는 직선으로 된 대기열이고, 비동기화는 대기열에 있지 않으며 각각 고유한 방식으로 진행됩니다.

1. 동기식과 비동기식의 차이점은 무엇인가요?

동기: 요청 제출 -> 서버 처리 대기 -> 처리 및 반환 후 클라이언트 브라우저는 이 기간 동안 아무 작업도 수행할 수 없습니다.

비동기: 요청이 이벤트에 의해 트리거됩니다. 이것은 브라우저가 여전히 할 수 있는 일입니다. 다른 일을 하세요) ->Processed

2. 어떤 상황에서 사용되나요?

1. 한마음: 지금은 한 가지 일만 할 수 있고, 다른 일은 다음 일을 계속하기 전에 현재 일이 완료될 때까지 기다려야 합니다.

2. 마음이 편치 않은 경우: 동시에 여러 가지 작업을 할 수 있습니다. 왼손은 스페이스바를 누르고, 오른손은 계속 마우스를 칠 수 있으며, 눈은 동시에 화면을 봐야 합니다. 매우 어렵습니다.

Ajax는 요청을 보낼 때 동기식과 비동기식으로 구분됩니다.

비동기식 전송 방법이 가장 일반적으로 사용되며 사용자에게 서버 검색으로 인한 시간 지연을 방지합니다. 비동기 전송 중에는 뒤에서 조용히 발생하며 사용자는 기다리는 느낌을 주지 않고 하던 일을 계속할 수 있습니다. 전송되는 데이터의 양이 많으면 서버 검색 시간이 길어지지만 사용자는 이를 알지 못합니다. 사용자는 여전히 페이지 작업에 집중하고 서버가 무엇을 했는지 알지 못합니다. 사용자에게 좋은 경험이 되었습니다.

비동기 전송 방식은 페이지가 로드되는 순간과 같습니다. 동기 요청이 발생한 후 브라우저는 서버가 검색을 완료하고 결과를 반환할 때까지 기다립니다. 이때 마우스는 대기 모양으로 바뀌어 사용자에게 요청이 아직 응답되지 않았음을 상기시켜 줍니다. 사용자는 아무것도 할 수 없습니다. 잠깐... 사용자는 이미 수정 페이지가 로드되기를 기다리는 데 익숙하지만 Ajax에서 요청을 동기화하는 시간은 일반적으로 전체 페이지를 로드하는 시간보다 길지 않지만 이것이 얼마나 고통스러운지 알아야 합니다. 아무것도 하지 않고 그냥 수동적으로 기다리기만 하면 됩니다. 따라서 이 동기 요청은 주의해서 사용해야 합니다...

이 시점에서 우리는 질문을 던져야 합니다. 비동기 요청이 너무 좋은데 왜 비동기 요청을 사용하지 않는 걸까요? 동기식 요청을 하지 마세요. 하하, 그런 상황이 발생한다면, 이 단계의 요청 결과가 다음 요청의 전제가 됩니다. 감각. 그렇다면 동기 요청을 사용해야 한다고 생각하시나요, 아니면 비동기 요청을 사용해야 한다고 생각하시나요? 당연히 요청을 동기화하여 다음 단계를 더욱 의미있게 만들기 위해 사랑하는 사용자들을 잠시 기다려 보는 것은 어떨까요?

동기 요청과 비동기 요청에는 각각의 용도가 있습니다. 좋고 나쁨의 구분은 없습니다. 단지 적절하게 사용되는지 여부의 문제일 뿐입니다

장점:
기존 웹 애플리케이션에서는 사용자가 양식(Form)을 작성하고 양식을 제출할 때 웹 서버에 요청을 보낼 수 있습니다. 서버는 들어오는 양식을 수신하고 처리한 다음 새 웹 페이지를 반환합니다. 이 접근 방식은 두 페이지의 HTML 코드 대부분이 동일한 경우가 많기 때문에 대역폭을 많이 낭비합니다. 각 애플리케이션 상호 작용에는 서버에 요청을 보내야 하므로 애플리케이션의 응답 시간은 서버의 응답 시간에 따라 달라집니다. 이로 인해 기본 앱보다 응답성이 훨씬 떨어지는 사용자 인터페이스가 생성됩니다.

이와 달리 AJAX 애플리케이션은 필요한 데이터만 서버에 보내고 검색할 수 있습니다. 이는 SOAP 또는 기타 XML 기반 웹 서비스 인터페이스를 사용하고 클라이언트에서 JavaScript를 사용하여 서버의 응답을 처리합니다. 서버와 브라우저 간에 교환되는 데이터가 적기 때문에 결과적으로 더 반응성이 뛰어난 애플리케이션을 볼 수 있습니다. 동시에 요청을 수행하는 클라이언트 시스템에서 많은 처리 작업이 완료될 수 있으므로 웹 서버의 처리 시간도 단축됩니다.

Ajax를 사용하는 가장 큰 장점은 전체 페이지를 업데이트하지 않고도 데이터를 유지할 수 있다는 것입니다. 이를 통해 웹 애플리케이션은 사용자 작업에 더 빠르게 응답하고 네트워크를 통해 변경되지 않은 정보를 보내는 것을 방지할 수 있습니다. Ajax에는 브라우저 플러그인이 필요하지 않지만 사용자가 브라우저에서 JavaScript를 실행할 수 있도록 허용해야 합니다. DHTML 애플리케이션과 마찬가지로 Ajax 애플리케이션도 다양한 브라우저와 플랫폼에서 엄격하게 테스트되어야 합니다. Ajax가 성숙해짐에 따라 Ajax 사용을 단순화하는 일부 프로그램 라이브러리도 나왔습니다. 마찬가지로, JavaScript를 지원하지 않는 사용자에게 대체 기능을 제공하기 위해 또 다른 보조 프로그래밍 기술이 등장했습니다.

Ajax 사용에 대한 주요 비판은 브라우저 뒤로 버튼의 정상적인 동작을 깨뜨릴 수 있다는 것입니다. 동적으로 업데이트되는 페이지의 경우 브라우저는 기록에서 정적 페이지만 기억할 수 있으므로 사용자는 이전 페이지 상태로 돌아갈 수 없습니다. 완전히 읽힌 페이지와 동적으로 수정된 페이지의 차이는 매우 미미합니다. 사용자는 종종 뒤로 버튼을 클릭하여 이전 작업을 취소할 수 있기를 원하지만 Ajax 애플리케이션에서는 이것이 불가능합니다. 이렇게 하세요. 그러나 개발자는 이 문제를 해결하기 위해 다양한 방법을 고안해 냈으며, 그 중 대부분은 사용자가 기록에 액세스하기 위해 뒤로 버튼을 클릭할 때 페이지의 변경 사항을 재현하기 위해 숨겨진 IFRAME을 만들거나 사용하는 것입니다. (예를 들어 사용자가 Google 지도에서 다시 클릭하면 숨겨진 IFRAME에서 검색한 다음 검색 결과를 Ajax 요소에 반영하여 애플리케이션 상태를 당시의 상태로 복원합니다.)

          관련 사항은 다음과 같습니다. 동적 페이지 업데이트를 사용하면 사용자가 특정 상태를 즐겨찾기에 저장하기가 어렵습니다. 이 문제에 대한 솔루션도 등장했습니다. 대부분은 URL 조각 식별자(종종 앵커라고 함, URL에서 # 다음 부분)를 사용하여 추적을 유지하고 사용자가 지정된 애플리케이션 상태로 돌아갈 수 있도록 합니다. (많은 브라우저에서는 JavaScript가 앵커를 동적으로 업데이트할 수 있도록 허용하므로 Ajax 애플리케이션이 표시된 콘텐츠를 업데이트하는 동안 앵커를 업데이트할 수 있습니다.) 이러한 솔루션은 뒤로 버튼을 지원하지 않는 것과 관련된 많은 논쟁도 해결합니다. Ajax를 개발할 때 네트워크 대기 시간(사용자 요청과 서버 응답 사이의 시간)을 신중하게 고려해야 합니다. 사용자에게 명확한 응답을 제공하지 않거나[5], 데이터를 제대로 미리 읽지 않거나[6], XMLHttpRequest를 부적절하게 처리하면[7] 사용자가 보고 싶지 않고 이해할 수 없는 지연된 느낌을 받게 됩니다. ]. 일반적인 솔루션은 시각적 구성 요소를 사용하여 시스템이 백그라운드 작업을 수행하고 데이터와 콘텐츠를 읽고 있음을 사용자에게 알리는 것입니다.如 일부 휴대용 장치(휴대폰, PDA 등)는 JavaScript로 만들어진 Ajax 엔진을 지원할 수 없습니다. JavaScript의 호환성 및 디버그는 모두 AJAX의 브러시 없는 새로 고침 과부하로 인해 페이지 변경이 새로고침 및 명확하지 않습니다. 다시 로드하면 사용자에게 문제가 발생하기 쉽습니다. 사용자는 현재 데이터가 새로운 것인지 또는 업데이트되었는지 확실하지 않습니다. 기존 솔루션에는 관련 위치에 대한 프롬프트, 데이터 업데이트가 포함됩니다. 영역 디자인이 더 명확해지고 이후에 사용자 프롬프트가 제공됩니다. 데이터 업데이트; 스트리밍 미디어 지원은 FLASH 및 Java 애플릿만큼 좋지 않습니다.