Detaillierte JavaScript-Analyse von Netzwerkanforderungen und Remote-Ressourcen

Dieser Artikel vermittelt Ihnen relevantes Wissen über Javascript, in dem hauptsächlich Probleme im Zusammenhang mit Netzwerkanforderungen und Remote-Ressourcen vorgestellt werden, einschließlich ursprungsübergreifender Ressourcenfreigabe, Preflight-Anforderungen, Fetch-API usw. Das Folgende ist: Werfen wir einen Blick darauf, ich hoffe, es hilft alle.

[Verwandte Empfehlungen: Javascript-Video-Tutorial, Web-Frontend]

1. Die Geburt von Ajax

Im Jahr 2005 schrieb Jesse James Garrett einen Artikel „Ajax – Ein neuer Ansatz für Webanwendungen“. "In diesem Artikel wird eine Technologie namens Ajax (Asynchronous JavaScript+XML, also asynchrones JavaScript+XML) beschrieben. Bei dieser Technik wird eine Anfrage nach zusätzlichen Daten an den Server gesendet, ohne dass die Seite aktualisiert wird, was zu einer besseren Benutzererfahrung führt. Garrett erklärt, wie diese Technologie das traditionelle Click-and-Wait-Modell verändert, das seit der Geburt des Webs besteht.
Die Schlüsseltechnologie, die Ajax auf die historische Bühne gebracht hat, ist das XMLHttpRequest (XHR)-Objekt. Vor der Einführung von XHR bietet eine sinnvolle Schnittstelle zum Senden von Serveranfragen und zum Erhalten von Antworten. Diese Schnittstelle kann asynchron zusätzliche Daten vom Server abrufen, was bedeutet, dass Benutzer Daten abrufen können, ohne die Seite aktualisieren zu müssen. Nachdem Sie Daten über das XHR-Objekt abgerufen haben, können Sie DOM-Methoden verwenden, um die Daten in die Webseite einzufügen.
Die XHR-Objekt-API gilt im Allgemeinen als schwierig zu verwenden, und die Fetch-API wurde nach ihrer automatischen Geburt schnell zu einem moderneren alternativen Standard für XHR. Die Fetch-API unterstützt zukünftige Versprechen und Service-Threads (Service-Worker) und hat sich zu einem äußerst leistungsstarken Standard entwickelt Web-Entwicklungstool.

2. Cross-Origin-Ressourcenfreigabe

Eine wesentliche Einschränkung der Ajax-Kommunikation über XHR ist die Cross-Origin-Sicherheitsrichtlinie. Standardmäßig kann XHR nur auf Ressourcen in derselben Domäne zugreifen wie die Seite, die die Anfrage initiiert hat. Diese Sicherheitsbeschränkung verhindert bestimmtes böswilliges Verhalten. Allerdings müssen Browser auch den legalen Cross-Origin-Zugriff unterstützen.
Cross-Origin Resource Sharing (CORS, Cross-Origin Resource Sharing) definiert, wie Browser und Server eine Cross-Origin-Kommunikation erreichen. Die Grundidee von CORS besteht darin, benutzerdefinierte HTTP-Header zu verwenden, damit Browser und Server einander verstehen und bestimmen können, ob eine Anfrage oder Antwort erfolgreich sein oder fehlschlagen soll.
Für einfache Anfragen wie GET- oder POST-Anfragen gibt es keine benutzerdefinierten Header und der Anfragetext ist vom Typ Text/Plain. Solche Anfragen haben beim Senden einen zusätzlichen Header namens Origin. Der Origin-Header enthält die Quelle (Protokoll, Domänenname, Port) der Seite, die die Anfrage sendet, damit der Server bestimmen kann, ob er darauf antworten soll.
Moderne Browser unterstützen CORS nativ über das XMLHttpRequst-Objekt. Dieses Verhalten wird automatisch ausgelöst, wenn versucht wird, auf Ressourcen aus verschiedenen Quellen zuzugreifen. Um Anfragen an Quellen in verschiedenen Domänen zu senden, können Sie ein Standard-XHR-Objekt verwenden und eine absolute URL an die open()-Methode übergeben, wie zum Beispiel:

let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
	if(xhr.readyState == 4){
		if((xhr.status >= 200 && xhr.status <p>Domänenübergreifende XHR-Objekte ermöglichen den Zugriff auf die Eigenschaften „status“ und „statusText“. Erlauben Sie synchrone Anfragen aus Sicherheitsgründen. Bedenken Sie, dass domänenübergreifende XHR-Objekte auch einige zusätzliche Einschränkungen mit sich bringen. </p>

• kann setRequestHeader() nicht zum Festlegen benutzerdefinierter Header verwenden;

• die Methode getAllResponseHeaders() gibt immer eine leere Zeichenfolge zurück;

• oder domänenübergreifende Anforderungen verwenden alle dieselbe Schnittstelle. Daher ist es am besten, beim Zugriff auf lokale Ressourcen relative URLs und beim Zugriff auf Remote-Ressourcen absolute URLs zu verwenden. Dadurch können Nutzungsszenarien klarer unterschieden und Probleme mit Headern oder Cookies vermieden werden eingeschränkter Zugang zu Informationen.

3. Preflight-Anfrage

CORS verwendet einen Serverüberprüfungsmechanismus namens Preflight-Anfrage, der die Verwendung benutzerdefinierter Header, anderer Methoden als GET und POST sowie verschiedener Inhaltstypen des Anforderungstexts ermöglicht. Beim Senden einer Anfrage mit einer der oben genannten erweiterten Optionen wird zunächst eine Preflight-Anfrage an den Server gesendet. Diese Anfrage wird mit der OPTIONS-Methode gesendet und enthält die folgenden Header:

Origin: das gleiche wie eine einfache Anfrage;

• Access-Control-Request-Method: die Methode, die Sie verwenden möchten;

• Access-Control-Request-Header: (optional) Eine durch Kommas getrennte Liste zu verwendender benutzerdefinierter Header

• 4. Fetch-API

Die Fetch-API kann alle Aufgaben des XMLHttpRequest-Objekts ausführen, ist jedoch einfacher zu verwenden , verfügt über eine modernere Benutzeroberfläche und kann in Web-Tools wie Web Workern verwendet werden. XMLHttpRequest kann asynchron sein, während die Fetch-API asynchron sein muss.

1. Versandanforderung

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得到了所有主流浏览器的支持。

六、JavaScript思维导图

【相关推荐：javascript视频教程、web前端】

Das obige ist der detaillierte Inhalt vonDetaillierte JavaScript-Analyse von Netzwerkanforderungen und Remote-Ressourcen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!