2005년 Jesse James Garrett은 Ajax(Asynchronous JavaScript+XML) 기술이라는 애플리케이션을 설명하는 "Ajax - 웹 애플리케이션에 대한 새로운 접근 방식"이라는 기사를 썼습니다. 이 기술에는 페이지를 새로 고치지 않고 서버에 추가 데이터 요청을 보내 더 나은 사용자 경험을 제공하는 방법이 포함됩니다. Garrett은 이 기술이 웹 탄생 이후 지속되어 온 전통적인 클릭 후 대기 모델을 어떻게 바꾸는지 설명합니다.
Ajax를 역사적 무대로 끌어올린 핵심 기술은 XMLHttpRequest(XHR) 객체입니다. XHR이 등장하기 전에는 주로 숨겨진 창이나 인라인 창을 사용하는 일부 블랙 기술을 통해 Ajax 스타일 통신을 구현해야 했습니다. XHR은 서버 요청을 보내고 응답을 받기 위한 합리적인 인터페이스를 제공합니다. 이 인터페이스는 서버에서 비동기적으로 추가 데이터를 얻을 수 있습니다. 즉, 사용자는 페이지를 새로 고치지 않고도 데이터를 얻을 수 있습니다. XHR 객체를 통해 데이터를 얻은 후 DOM 메서드를 사용하여 데이터를 웹 페이지에 삽입할 수 있습니다.
XHR 객체 API는 일반적으로 사용하기 어려운 것으로 간주되며, Fetch API는 자동 탄생 이후 빠르게 XHR에 대한 보다 현대적인 대체 표준이 되었습니다. Fetch API는 예약된 약속과 서비스 스레드(서비스 작업자)를 지원하며 매우 강력한 웹이 되었습니다. 개발 도구.
XHR을 통한 Ajax 통신의 주요 제한 사항은 Cross-Origin 보안 정책입니다. 기본적으로 XHR은 요청을 시작한 페이지와 동일한 도메인의 리소스에만 액세스할 수 있습니다. 이 보안 제한은 특정 악의적인 동작을 방지합니다. 그러나 브라우저는 합법적인 교차 출처 액세스도 지원해야 합니다.
CORS(교차 원본 리소스 공유)는 브라우저와 서버가 원본 간 통신을 구현하는 방법을 정의합니다. CORS의 기본 아이디어는 사용자 정의 HTTP 헤더를 사용하여 브라우저와 서버가 서로를 이해하여 요청이나 응답이 성공할지 실패할지 결정하는 것입니다.
GET 또는 POST 요청과 같은 간단한 요청의 경우 사용자 정의 헤더가 없으며 요청 본문은 text/plain 유형입니다. 이러한 요청에는 전송 시 Origin이라는 추가 헤더가 있습니다. Origin 헤더에는 요청을 보내는 페이지의 소스(프로토콜, 도메인 이름, 포트)가 포함되어 있어 서버가 이에 대한 응답을 제공할지 여부를 결정할 수 있습니다.
최신 브라우저는 기본적으로 다른 출처의 리소스에 액세스하려고 할 때 자동으로 트리거되는 XMLHttpRequst 개체를 통해 CORS를 지원합니다. 다른 도메인의 원본으로 요청을 보내려면 표준 XHR 객체를 사용하고 절대 URL을 open() 메서드에 전달할 수 있습니다. 예:
let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
if(xhr.readyState == 4){
if((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){
경고(xhr.reaponseText);
}또 다른{
Alert("요청이 실패했습니다:"+xhr.status);
}
}};xhr.open("get","http://www.nezha.con/page/",true);xhr.send(null); 도메인 간 XHR 객체는 status 및 statusText 속성에 대한 액세스를 허용합니다. 또한 도메인 간 XHR 개체에 대한 동기화 요청도 보안상의 이유로 몇 가지 추가 제한 사항을 적용하도록 허용합니다.
setRequestHeader()를 사용하여 사용자 정의 헤더를 설정할 수 없습니다.
getAllResponseHeaders() 메서드
는
동일한 도메인 요청과 교차 도메인 요청 모두에 사용되므로
항상 빈 문자열을 반환합니다.로컬 리소스 액세스 원격 리소스에 액세스할 때 상대 URL과 절대 URL을 사용하면 사용 시나리오를 보다 명확하게 구분하고 로컬 리소스에 액세스할 때 헤더 또는 쿠키 정보에 대한 액세스가 제한되는 문제를 피할 수 있습니다.
CORS는 실행 전 요청이라는 서버 확인 메커니즘을 사용하여 사용자 지정 헤더, GET 및 POST 이외의 메서드, 다양한 요청 본문 콘텐츠 유형을 사용할 수 있도록 합니다. 위의 고급 옵션 중 하나와 관련된 요청을 보낼 때 실행 전 요청이 먼저 서버로 전송됩니다. 이 요청은 OPTIONS 메소드를 사용하여 전송되며 다음 헤더를 포함합니다.
Origin: 단순 요청과 동일:
Access-Control-
Request-Headers: (선택 사항) 쉼표 -사용자 정의 헤더 목록을 사용하기 위해 값을 구분합니다.
Fetch API는 XMLHttpRequest 개체의 모든 작업을 수행할 수 있지만 사용하기 쉽고 인터페이스가 더 현대적이며 다음과 같은 웹 도구에서 사용할 수 있습니다. 웹 작업자 스레드. XMLHttpRequest는 비동기식을 선택할 수 있지만 Fetch API는 비동기식이어야 합니다.
fetch() 메소드는 메인 페이지 실행 스레드, 모듈 및 작업자 스레드를 포함하여 전역 범위에 노출됩니다. 이 메소드를 호출하면 브라우저가 지정된 URL로 요청을 보냅니다.
1. 파견요청
fetch()에는 필수 매개변수 입력이 하나만 있습니다. 대부분의 경우 이 매개변수는 리소스를 얻기 위한 URL이며 이 메서드는 promise를 반환합니다:
let r = fetch('/bar');console.log(r);//Promise<pending> URL 형식(상대 경로) , 절대 경로 등)은 XHR 객체와 동일하게 해석됩니다.
요청이 완료되고 리소스를 사용할 수 있게 되면 응답 개체가 처리됩니다. 이 개체는 해당 리소스를 얻을 수 있는 API의 캡슐화입니다. 이 개체의 속성과 메서드를 사용하여 리소스를 얻고, 응답을 이해하고, 로드 밸런싱을 유용한 형식으로 변환합니다.
2. 응답을 읽으십시오. 응답 내용을 읽는 가장 간단한 방법은 일반 텍스트 형식으로 내용을 얻는 것입니다. text() 메소드를 사용하면 됩니다. 이 메서드는 리소스의 전체 콘텐츠를 검색하는 것을 확인하는 약속을 반환합니다.
3. 상태 코드 및 요청 실패 처리
Fetch API는 Response의 status 및 statusText 속성을 통해 응답 상태 확인을 지원합니다. 응답을 성공적으로 얻은 요청은 일반적으로 값이 200인 상태 코드를 생성합니다.
4. 일반적인 가져오기 요청 모드:
JSON 데이터 보내기,
요청 본문에 매개변수 보내기,
파일 보내기
, Blob 파일 로드
, 도메인 간 요청 보내기,
요청 중단
소켓 웹소켓의 목표는 전이중 및 2- 장기 연결을 통해 서버와 통신하는 방식입니다. JavaScript로 웹소켓을 생성하면 연결을 초기화하기 위해 HTTP 요청이 서버로 전송됩니다. 서버가 응답한 후 연결은 HTTP의 업그레이드 헤더를 사용하여 HTTP 프로토콜에서 웹소켓 프로토콜로 전환됩니다. 이는 웹소켓이 표준 HTTP 서버를 통해 구현될 수 없지만 이 프로토콜을 지원하는 독점 서버를 사용해야 함을 의미합니다.
websocket은 커스텀 프로토콜을 사용하기 때문에 URL 방식이 약간 변경되었습니다. http://나 https://는 더 이상 사용할 수 없고, ws://와 wss://를 사용해야 합니다. 전자는 안전하지 않은 연결이고 후자는 보안 연결입니다. 웹소켓 URL을 실행할 때, 향후 추가 체계가 지원될 수 있으므로 URL 체계를 포함해야 합니다.
HTTP 프로토콜 대신 사용자 정의 프로토콜을 사용하면 클라이언트와 서버가 HTTP에 부담을 주지 않고 매우 적은 양의 데이터를 보낼 수 있다는 장점이 있습니다. 더 작은 데이터 패킷을 사용하면 대역폭 및 대기 시간 문제가 중요한 모바일 애플리케이션에 웹소켓이 이상적입니다. 사용자 정의 프로토콜을 사용할 때의 단점은 Websocket이 모든 주요 브라우저에서 지원되는 것보다 프로토콜을 정의하는 데 시간이 더 걸린다는 것입니다.
