네트워크 요청 및 원격 리소스에 대한 JavaScript 상세 분석-JS 튜토리얼-php.cn

이 기사에서는 javascript에 대한 관련 지식을 제공합니다. 주로 원본 간 리소스 공유, 실행 전 요청, Fetch API 등을 포함하여 네트워크 요청 및 원격 리소스와 관련된 문제를 소개합니다. 살펴보겠습니다. 도움이 되기를 바랍니다. 모든 사람.

네트워크 요청 및 원격 리소스에 대한 JavaScript 상세 분석

[관련 권장사항: javascript 비디오 튜토리얼, web front-end]

1. Ajax의 탄생

2005년 Jesse James Garrett은 "Ajax - A New Approach to Web Application"이라는 글을 썼습니다. " , 이 기사에서는 Ajax(Asynchronous JavaScript+XML, 즉 비동기 JavaScript+XML)라는 기술에 대해 설명합니다. 이 기술에는 페이지를 새로 고치지 않고 서버에 추가 데이터 요청을 보내 더 나은 사용자 경험을 제공하는 방법이 포함됩니다. Garrett은 이 기술이 웹 탄생 이후 지속되어 온 전통적인 클릭 후 대기 모델을 어떻게 바꾸는지 설명합니다.
Ajax를 역사적 단계로 끌어올린 핵심 기술은 XMLHttpRequest(XHR) 객체입니다. XHR이 등장하기 전에는 주로 숨겨진 창이나 인라인 창을 사용하는 일부 블랙 기술을 통해 Ajax 스타일 통신을 구현해야 했습니다. XHR은 서버 요청을 보내고 응답을 받기 위한 합리적인 인터페이스를 제공합니다. 이 인터페이스는 서버에서 비동기적으로 추가 데이터를 얻을 수 있습니다. 즉, 사용자는 페이지를 새로 고치지 않고도 데이터를 얻을 수 있습니다. XHR 객체를 통해 데이터를 얻은 후 DOM 메서드를 사용하여 데이터를 웹 페이지에 삽입할 수 있습니다.
XHR 객체 API는 일반적으로 사용하기 어려운 것으로 간주되며, Fetch API는 자동 탄생 이후 빠르게 XHR에 대한 보다 현대적인 대체 표준이 되었습니다. Fetch API는 미래의 약속과 서비스 스레드(서비스 작업자)를 지원하며 매우 강력한 도구가 되었습니다. 웹 개발 도구.

2. 교차 출처 리소스 공유

XHR을 통한 Ajax 통신의 주요 제한 사항은 교차 출처 보안 정책입니다. 기본적으로 XHR은 요청을 시작한 페이지와 동일한 도메인의 리소스에만 액세스할 수 있습니다. 이 보안 제한은 특정 악의적인 동작을 방지합니다. 그러나 브라우저는 합법적인 교차 출처 액세스도 지원해야 합니다.
Cross-Origin Resource Sharing(CORS, Cross-Origin Resource Sharing)은 브라우저와 서버가 Cross-Origin 통신을 달성하는 방법을 정의합니다. CORS의 기본 아이디어는 사용자 정의 HTTP 헤더를 사용하여 브라우저와 서버가 서로를 이해하여 요청이나 응답이 성공할지 실패할지 결정하는 것입니다.
GET 또는 POST 요청과 같은 간단한 요청의 경우 사용자 정의 헤더가 없으며 요청 본문은 텍스트/일반 유형입니다. 이러한 요청에는 전송 시 Origin이라는 추가 헤더가 있습니다. Origin 헤더에는 요청을 보내는 페이지의 소스(프로토콜, 도메인 이름, 포트)가 포함되어 있어 서버가 이에 대한 응답을 제공할지 여부를 결정할 수 있습니다.
최신 브라우저는 기본적으로 XMLHttpRequst 개체를 통해 CORS를 지원합니다. 이 동작은 다양한 소스의 리소스에 액세스하려고 할 때 자동으로 트리거됩니다. 다른 도메인의 소스에 요청을 보내려면 표준 XHR 개체를 사용하고 다음과 같이 절대 URL을 open() 메서드에 전달할 수 있습니다.

let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
	if(xhr.readyState == 4){
		if((xhr.status >= 200 && xhr.status <p>교차 도메인 XHR 개체는 status 및 statusText 속성에 대한 액세스를 허용합니다. 보안상의 이유로 동기 요청을 허용합니다. 도메인 간 XHR 개체에도 몇 가지 추가 제한 사항이 적용된다는 점을 고려하세요. </p>

로그인 후 복사

setRequestHeader()를 사용하여 사용자 정의 헤더를 설정할 수 없습니다.
쿠키를 보내고 받을 수 없습니다.
getAllResponseHeaders() 메서드는 동일한 도메인이므로 항상 빈 문자열을 반환합니다. 또는 교차 도메인 요청은 모두 동일한 인터페이스를 사용하므로 로컬 리소스에 액세스할 때는 상대 URL을 사용하고 원격 리소스에 액세스할 때는 절대 URL을 사용하는 것이 가장 좋습니다. 정보에 대한 접근이 제한적입니다.

CORS는 실행 전 요청이라는 서버 확인 메커니즘을 사용하여 사용자 정의 헤더, GET 및 POST 이외의 방법, 다양한 요청 본문 콘텐츠 유형을 사용할 수 있습니다. 위의 고급 옵션 중 하나와 관련된 요청을 보낼 때 실행 전 요청이 먼저 서버로 전송됩니다. 이 요청은 OPTIONS 메소드를 사용하여 전송되며 다음 헤더를 포함합니다.

Origin: 단순 요청과 동일

Access-Control-Request-Method: 사용하려는 메소드; Access-Control-Request -Headers: (선택 사항) 사용할 사용자 정의 헤더의 쉼표로 구분된 목록
4. Fetch API
fetch() 메소드는 메인 페이지 실행 스레드, 모듈, 작업자 스레드를 포함한 전역 범위에 노출됩니다. 이 메소드를 호출하면 브라우저가 지정된 URL로 요청을 보냅니다.
1. 발송 요청
fetch()에는 필수 매개변수 입력이 하나만 있습니다. 대부분의 경우 이 매개변수는 리소스를 얻기 위한 URL이며 이 메소드는 날짜를 반환합니다.

let r = fetch('/bar');console.log(r);//Promise<pending></pending>

로그인 후 복사

URL的格式（相对路径、绝对路径等）的解释与XHR对象一样。
请求完成、资源可用时，期约会解决一个Response对象，这个对象是API的封装，可以通过它取得相应资源。获取资源要使用这个对象的属性和方法，掌握响应的情况并将负载均衡转为有用的形式。
2、读取响应
读取响应内容的最简单方式是取得纯文本格式的内容，只要用到text()方法。这个方法返回一个期约，会解决为取得资源的完整内容。
3、处理状态码和请求失败
Fetch API 支持通过Response的status和statusText属性检查响应状态。成功获取响应的请求通常会产生值为200的状态码。
4、常见Fetch请求模式

发送JSON数据
在请求体中发送参数
发送文件
加载Blob文件
发送跨域请求
中断请求

五、websocket

套接字websocket的目标是通过一个长时连接实现与服务器全双工、双向的通信。在JavaScript中创建websocket时，一个HTTP请求会发送到服务器以初始化连接。服务器响应后，连接使用HTTP中的Upgrade头部从HTTP协议切换到websocket协议，这意味着websocket不能通过标准HTTP服务器实现，而必须使用支持该协议的专有服务器。
因为websocket使用了自定义协议，所以URL方案稍有变化，不能再使用http://或https://，而要使用ws://和wss://。前者是不安全的连接，后者是安全连接。在执行websocket URL时，必须包含URL方案，因为将来有可能再支持其他方案。
使用自定义协议而非HTTP协议的好处是，客户端与服务器质检可以发送非常少的数据，不会对HTTP造成任何负担。使用更小的数据包让websocket非常适合宽带和延迟问题比较明显的移动应用。使用自定义协议的缺点是，定义协议的时间比定义JavaScript API的时间要长，websocket得到了所有主流浏览器的支持。