Red pide al navegador

El primero fue escrito en: 29 Marzo 2020

Recientemente, he aprendido un poco de conocimiento de la red; así que creo que lo que realmente se utiliza en combinación, para escribir un artículo;

ajax

Utilizamos el protocolo HTTP para el intercambio de datos y del lado del servidor,
la forma más común esajax

No hace falta decir que la definición y beneficios; un montón de Internet, no repetirlos;
no estamos hablando de la utilización de muchos artículos sobre el bastidor, protegiendo el contenido primario;
estaba pensando un poco de comprensión de cómo funciona un navegador específico;
estamos aquí para hacer una participación;

Ajax es hecho HTTPprotocolo de encapsulación;
inicia una petición HTTP, cuando el estado de la solicitud de cambio (readyState), se pasa a la aplicación del método;

Iniciar una solicitud

ajax construido por el navegador XMLHttpRequestpara generar;

let httpRequest = new XMLHttpRequest();
httpRequest.onreadystatechange = function() {
    if (httpRequest.readyState === XMLHttpRequest.DONE) {
        // Everything is good, the response was received.
    } else {
        // Not ready yet.
    }
};
// 请求方法 请求URL 是否异步
httpRequest.open('GET', 'http://www.example.org/some.file', true);
// 在send之前; open之后
httpRequest.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
httpRequest.send("name=value&anothername=" + encodeURIComponent('哈哈哈') + "&so=on");

Podemos ver que el código de operación

Abrir una solicitud para especificar la URL método de petición, solicitud, ya sea asíncrona
Después de configurar los encabezados de solicitud requerida para este paso antes de enviar, abrir
Transmisión de datos pueden ser cadenas de datos binarios pueden ser

Solicitud parámetro de codificación

OBTENER

httpRequest.send("name=value&anothername=" + encodeURIComponent('哈哈哈') + "&so=on");

Podemos observar que esta línea de código en el encodeURIComponentmétodo;
hay que codificar el nombre del parámetro y el valor; para evitar algunos de los problemas de los parámetros de transmisión;

¿Por qué nos codificar parámetros?

GET el modo de solicitud, los parámetros están codificados en la URL;
URL no puede aparecer en chino y algunos símbolos especiales
Tenemos que superar una serie de chino y símbolos especiales

Podemos imaginar, si no hay un parámetro de codificación así que lo que serían las consecuencias;

China luego, no se pasa la
Si el valor es 123&a=btal que no se convertirá en 123 a=b?

Para evitar codificar innecesaria estos problemas, tenemos nombre, por tanto, los parámetros, valores de los parámetros se codifican;
por supuesto, también un método correspondiente de decodificacióndecodeURIComponent

let plainText = 'h&123=12'
let encodedText = encodeURIComponent(plainText)
let decodedText = decodeURIComponent(encodedText)

ENVIAR

Cuando enviamos un POSTpedido, necesitamos establecer una cabecera de la solicitud Content-Type
para explicar qué tipo de datos que solicitamos formato.

datos comunes formatos de POST ha presentado

application / x-www forma urlencoded-conseguir-petición y que codifica los mismos efectos, sin embargo, una solicitud de datos es en el cuerpo;
transmisión multipart / form-data para grandes transacciones; tiene datos de límites de división;
application / json interfaz API REST para el formato más común de datos;
text / xml xml

POST de datos de solicitud de procesamiento de solicitudes, que es poner los datos 请求体en;
sin embargo, esto no quiere decir que no pueden enviar solicitud de URL codificada;
de hecho, todavía se puede añadir parámetros adicionales, pero en general, o para cumplir con las normas preceptivas;

Aceptar la solicitud

Anteriormente, hemos mencionado puede readyStatejuzgar el estado de la solicitud;
¿En qué estado tiene usted?

ENVIADO 0 (sin inicializar) o (solicitud no inicializado)
ABIERTO 1 (carga) o (conexión de servidor establecido)
HEADERS_RECEIVED 2 (cargado) o (solicitud recibida)
LOADING 3 (interactivo) o (solicitud de procesamiento)
HECHO 4 (completa) o (solicitud terminada y la respuesta está listo)

let httpRequest = new XMLHttpRequest();
httpRequest.onreadystatechange = function() {
    if (httpRequest.readyState === XMLHttpRequest.DONE) {
        // Everything is good, the response was received.
    } else {
        // Not ready yet.
    }

    if (httpRequest.status === 200) {
        var response = JSON.parse(httpRequest.responseText);
        // Perfect!
    } else {
        // There was a problem with the request.
        // For example, the response may have a 404 (Not Found)
        // or 500 (Internal Server Error) response code.
    }
};

A continuación tratamos de ejecutar el código;

Si abrimos el archivo html directamente en la carpeta;
a continuación, vamos a estar siguiendo una situación similar en la barra de direcciones

file:///C:/Users/ju/Desktop/ajax/test.html

En este caso, no podemos enviar datos;

Abrir devTool vamos a ver el siguiente mensaje de error

El acceso a XMLHttpRequest en 'http://www.example.org/some.file' de origen 'nulo' ha sido bloqueada por
la política CORS: cabecera No "Access-Control-Allow-Origin está presente en el recurso solicitado.

Este es el famoso navegador solicitudes entre dominios problema,
la solución de 跨域muchas maneras;

Entre dominios

跨域 Debido a la política del mismo origen del navegador causado;

¿Por qué tener varios dominios que?
¿Por qué navegador para hacerlo?
Entre dominios proporciona la base más segura;
Evitar que otras personas de petición maliciosa;

Por defecto, JavaScript al enviar peticiones Ajax, número de puerto dominio URL debe ser exactamente la misma y la página actual.
De lo contrario, se informará de la de dominios cruzados anomalías;

Así solución común por lo que lo que ah?

JSONP pero ahora con menos, el uso del navegador en algunos no hay etiquetas de restricciones entre dominios;
Nginx agente; los archivos de agente de un recurso estático;
El extremo posterior de la primera solicitud de modificación, el establecimiento Access-Control-Allow-Origin, etc.
开发时Utilizando webpack-dev-server(se utiliza http-proxy-middleware interna)

WebSocket

WebSocket sólo recientemente contactó;
acaba de hacer una pequeña demostración;

Aquí no me atrevería a cortar la basura; simple para hablar sobre algunos;

¿Por qué debería WebSocket

Primero de todo lo que sabe, el navegador envía una petición al servidor;
sin embargo, a su vez, los servidores pueden no tomar la iniciativa para el navegador envía una solicitud;

Por lo tanto, en ausencia websocketantes, manejamos la comunicación entre el navegador y el servidor;
sólo el uso de 轮询métodos;

El llamado 轮询es que cada visita durante algún tiempo sobre el servidor;
ver si hay lo que un nuevo mensaje;

Charla ejemplo: Cada cliente envía un mensaje al servidor;
Pero entonces, después de recibir el servidor de mensajes, y no directamente al otro mensaje se devuelve al cliente;

Pero sólo otro cliente a tiempo de sondeo, de nuevo devolver el mensaje;

Por lo tanto, se enfrentan con más usuarios, y los requisitos en tiempo real de datos es alta;
por ejemplo, la videoconferencia, y luego sondear es morir;

Entonces, ¿qué beneficia WebSocket

WebSocket la aparición de esta parte es resolver el problema;
WebSocket es el uso de TCPla conexión, después de establecer el contacto se puede mantener durante mucho tiempo;
reducir múltiples peticiones;

var ws = new WebSocket("wss://echo.websocket.org");

ws.onopen = function(evt) {
    console.log("Connection open ...");
    ws.send("Hello WebSockets!");
};

ws.onmessage = function(evt) {
    console.log("Received Message: " + evt.data);
    ws.close();
};

ws.onclose = function(evt) {
    console.log("Connection closed.");
};

Y XMLHttpRequestel código es similar;
sin embargo, onmessagepuede desencadenar varias veces;

Debido a que, recientemente aprendidas Carriles, el uso Action Cable, el paquete de NPM proporcionada por la
interacción del cliente y el servidor, no empiece a decir aquí;

Recomendamos nos fijamos en Ruan Yifeng WebSocket
tiene visión general clara y concisa;

Más tarde, ya que el trabajo de contacto, la esperanza de tener una mayor comprensión de WebSocket;