Resumen de conocimiento de la red

Resumen de conocimientos de redes informáticas.

Modelo OSI de siete capas

• Capa de aplicación : usuarios de computadoras y la interfaz entre varias aplicaciones y la red, la función es proporcionar servicios directamente a los usuarios y completar varias tareas que los usuarios desean completar en la red. **Los protocolos de esta capa son: FTP (File Transfer Protocol), DNS (Domain Name Resolution Protocol), SMTP (Simple Mail Transfer Protocol), TELNET (TCP/IP Terminal Emulation Protocol), HTTP (Hypertext Transfer Protocol), HTTPS .

• Capa de presentación : ** Interpretar comandos y datos de la capa de aplicación, dar significados correspondientes a varias gramáticas y transmitirlos a la capa de sesión en un formato determinado. Se ocupa principalmente de la representación de la información del usuario, como la codificación, la conversión de formato de datos, el cifrado y descifrado, etc. **Los protocolos de esta capa son: LPP (Lightweight Presentation Protocol), XDP (External Data Presentation Protocol)

  • Procesamiento de formato de datos: negocie y establezca el formato de intercambio de datos y resuelva las diferencias en la representación del formato de datos entre varias aplicaciones.
  • Codificación de datos: maneja la conversión de conjuntos de caracteres y números.
  • Compresión y descompresión: reduce la cantidad de datos transferidos.
  • Cifrado y descifrado de datos: mejora la seguridad de la red.

• Capa de sesión: esta capa es la interfaz entre la aplicación de usuario y la red. Organiza y coordina la comunicación entre dos procesos de sesión y gestiona el intercambio de datos . Los usuarios pueden establecer sesiones en modos half-duplex, simplex y full-duplex. Al establecer una sesión, los usuarios deben proporcionar la dirección remota a la que desean conectarse, como xxx.com. Los protocolos de esta capa son: SSL (Secure Socket Layer Protocol), TLS (Transport Layer Security Protocol), RPC (Remote Procedure Call Protocol).

  • Simplex: Simplex significa que A solo puede enviar señales, B solo puede recibir señales y la comunicación es unidireccional.
  • Half-duplex: solo se produce una acción en un período de tiempo, ya sea enviando o recibiendo.
  • Full-duplex: significa que el conmutador también puede recibir datos mientras envía datos, y los dos están sincronizados.

• Capa de transporte: **Proporciona servicios de transmisión de datos de extremo a extremo y puede establecer una conexión lógica entre el host de envío y el host de destino en Internet, segmentar y volver a ensamblar datos de aplicaciones de capa superior y fusionarlos en un flujo de datos. ** Entre ellos, TCP y UDP están en esta capa.

• Capa de red : utilice la función de transmisión de datos sin errores entre nodos adyacentes proporcionados por la capa de enlace de datos y realice la conexión entre dos dispositivos de red a través de funciones de enrutamiento y retransmisión . Los protocolos de esta capa son: IP (IPV4, IPV6), ICMP, IGMP.

• Capa de enlace de datos : un enlace directo de datos punto a punto fiable. Sobre la base del flujo de bits proporcionado por la capa física, el control de errores, el control de flujo y otros métodos se utilizan para convertir la línea física con errores en un enlace de datos sin errores, es decir, para proporcionar un método confiable de transmisión de datos a través de el medio físico . Los protocolos de esta capa son: PPP (Point-to-Point Protocol), FR (Frame Relay), HDLC (General Data Link Control Protocol), ARP (Address Resolution Protocol), RARP.

  • Subcapa MAC (Media Access Control): resuelve el problema de la competencia multiusuario por los canales en una red compartida y completa el control de acceso al medio de la red.
  • Subcapa LLC (control de enlace lógico): establece y mantiene conexiones de red, realiza verificación de errores, control de flujo y control de enlace.

• Capa física : un enlace de datos punto a punto que no es necesariamente confiable. Utilice el medio de transmisión para proporcionar una conexión física para que la capa de enlace de datos realice la transmisión transparente del flujo de bits . El protocolo de esta capa es IEEE802.3.

Ventajas del modelo:

• Resuelve el problema de compatibilidad encontrado en la interconexión de redes heterogéneas.Distingue claramente los tres conceptos de servicio, interfaz y protocolo: el servicio describe qué funciones proporciona una determinada capa para la capa superior, y la interfaz describe cómo las utiliza la capa superior. El servicio de la capa inferior, el acuerdo implica cómo realizar el servicio de esta capa.
• Esto hace que cada capa sea altamente independiente, y no hay restricción en el protocolo utilizado por cada entidad en la red de interconexión, solo necesita brindar el mismo servicio hacia arriba y no cambiar la interfaz de la capa adyacente. Además, diferentes módulos funcionales de la red asumen diferentes responsabilidades, lo que reduce la complejidad del problema.Una vez que ocurre una falla en la red, la jerarquía se puede ubicar rápidamente para facilitar la búsqueda y la corrección de errores.

Protocolo de cuatro capas TCP/IP

• Capa de aplicación (capa de sesión, capa de presentación, capa de aplicación): el modelo TCP/IP combina las funciones de la capa de sesión y la capa de presentación en el modelo de referencia OSI en la capa de aplicación para su implementación. Proporciona a los usuarios un conjunto de aplicaciones de uso común, como correo electrónico, acceso a la transferencia de archivos, inicio de sesión remoto y más. La capa de aplicación introduce diferentes protocolos de capa de aplicación para diferentes aplicaciones de red.

  • Inicio de sesión remoto TELNET utiliza el protocolo TELNET para proporcionar una interfaz para registrarse en otros hosts de la red.
  • Las sesiones TELNET proporcionan terminales virtuales basados ​​en caracteres.
  • File Transfer Access FTP utiliza el protocolo FTP para proporcionar copia de archivos entre máquinas dentro de la red.

• Capa de transporte: **Proporciona comunicación entre aplicaciones para que las entidades pares en los hosts de origen y de destino puedan tener una sesión. **Sus características incluyen:

  • corriente formateada
  • Proporcione una transmisión confiable : el protocolo de la capa de transporte estipula que el extremo receptor debe devolver un acuse de recibo y, si se pierde el paquete, debe volver a enviarse.

  Esta capa define dos protocolos con diferente calidad de servicio: Protocolo de control de transmisión TCP (Protocolo de control de transmisión) y Protocolo de datagramas de usuario UDP (Protocolo de datagramas de usuario)

  • El protocolo TCP es un protocolo confiable y orientado a la conexión , que envía el flujo de bytes enviado por un host a otros hosts en Internet sin errores. **En el extremo emisor, es responsable de dividir el flujo de bytes transmitido por la capa superior en segmentos de mensaje y pasarlos a la capa inferior; en el extremo receptor, es responsable de volver a ensamblar el mensaje recibido y enviarlo a la capa superior capa. **El protocolo TCP también maneja el control de flujo de extremo a extremo para evitar que el receptor de recepción lenta no tenga suficiente búfer para recibir la gran cantidad de datos enviados por el remitente.
  • El protocolo UDP es un protocolo sin conexión y poco confiable , y es principalmente adecuado para ocasiones que no necesitan ordenar paquetes y controlar el flujo.

• Capa de red: el núcleo de todo el TCP/IP, la función es enviar paquetes a la red de destino o al host . Para enviar paquetes lo más rápido posible, puede ser necesario realizar la entrega de paquetes a lo largo de diferentes rutas simultáneamente. Por lo tanto, el orden de llegada de los paquetes puede ser diferente, lo que requiere que la capa superior clasifique los paquetes. Esta capa también define el formato y el protocolo del paquete, el protocolo IP.

  • Procese las solicitudes de transmisión de paquetes desde la capa de transporte : al recibir la solicitud, empaquete el paquete en un datagrama IP, complete el encabezado, seleccione una ruta a la máquina de destino y luego envíe el datagrama a la interfaz de red adecuada.
  • Procese los datagramas entrantes : primero verifique su legitimidad, luego enrute:
    • Si el datagrama ha llegado al sumidero, se elimina el encabezado.
    • Si el paquete de datos no ha llegado al destino, se reenvía el datagrama.
  • Manejar la ruta, el control de flujo, la congestión y otros problemas.

• Capa de interfaz de red (capa física, capa de enlace de datos): responsable de recibir datos IP y enviarlos a través de la red, o recibir tramas físicas de la red y extraer datagramas IP a la capa de red . De hecho, TCP/IP no describe realmente la implementación de esta capa, sino que solo requiere que pueda proporcionar una interfaz de acceso a su capa superior para transferir paquetes IP en ella.

Definición, capacidades y características de HTTP

• HTTP: Protocolo de transferencia de hipertexto, es decir, Protocolo de transferencia de hipertexto. Es un protocolo de nivel de aplicación, sin estado, basado en solicitudes y respuestas . A menudo se basa en el protocolo TCP/IP para transmitir datos. Es el protocolo de red más utilizado en Internet. Todos los archivos WWW deben cumplir con este estándar. La intención original de diseñar HTTP es proporcionar una forma de publicar y recibir páginas HTML.

• Características de HTTP

  • Simple: el formato básico del mensaje es encabezado+cuerpo, y la información del encabezado también es un formato de texto simple de clave-valor, que es fácil de entender.
  • Flexible y fácil de expandir: varios métodos de solicitud en el protocolo HTTP, URI/URL, código de estado, campos de encabezado, etc. no son fijos, lo que permite a los desarrolladores personalizar y expandir. Dado que HTTP funciona en la capa de aplicación, su capa inferior se puede cambiar a voluntad.
  • Amplia aplicación y multiplataforma.
  • sin conexión :
    • Cada acceso no tiene conexión, el servidor procesa los accesos en la cola de acceso uno por uno, cierra la conexión después de procesar uno y luego procesa el siguiente nuevo.
    • El significado de sin conexión es limitar cada conexión para procesar solo una solicitud. El servidor termina de procesar la solicitud del cliente y se desconecta después de recibir la respuesta del cliente.
  • apátrida :
    • Ventaja: el servidor no recordará el estado de HTTP, por lo que no se necesitan recursos adicionales para registrar la información de estado, lo que puede reducir la carga del servidor y utilizar más CPU y memoria para proporcionar servicios externos.
    • Desventaja: dado que el servidor no tiene capacidad de memoria, siempre debe verificar la información al realizar algunas operaciones relacionadas. Por ejemplo: iniciar sesión-"añadir carrito de la compra-"pedido-"liquidación-"pago, esta serie de operaciones necesita conocer la identidad del usuario, pero el servidor no sabe que estas operaciones están relacionadas. El caso más típico para solucionar este problema es el de las cookies: el estado del cliente se controla escribiendo la información de las cookies en los mensajes de petición y respuesta, lo que equivale a que el servidor envíe un sticker con los datos del cliente, que se traerá cuando el cliente lo solicite. el servidor más tarde Esta pegatina hará el truco.
  • Transmisión de texto claro :
    • Beneficios: la información en el proceso de transmisión es conveniente para leer previamente y se puede ver directamente a través de F12, lo que brinda una gran comodidad al trabajo de depuración.
    • Desventajas: fuga de información, nada de privacidad, muy inseguro. El problema de seguridad de HTTP se puede resolver introduciendo HTTPS de capa SSL/TLS.

• Tres características de HTTP1.1:

  • Conexión larga : cada vez que HTTP1.0 inicia una solicitud, se requiere una nueva conexión TCP (apretón de manos de tres vías), y es una solicitud en serie, lo que aumenta la sobrecarga de comunicación. Para resolver el problema de la conexión TCP, HTTP1.1 propone un método de comunicación de conexión larga: siempre que ninguno de los extremos solicite explícitamente desconectarse, se mantendrá el estado de la conexión TCP .
  • Transmisión de red de canalización : en la misma conexión TCP, el cliente puede enviar varias solicitudes. Siempre que se envíe la primera solicitud, la segunda solicitud se puede enviar sin esperar a que regrese, lo que puede reducir el tiempo de respuesta general. Aun así, el servidor aún responde a la primera solicitud primero en orden.Si la respuesta a la solicitud inicial es particularmente lenta, habrá muchas solicitudes esperando en línea más tarde, lo que provocará el bloqueo de la cabeza de la cola .
  • Bloqueo de cabeza de cola : cuando una solicitud enviada secuencialmente se bloquea por algún motivo, todas las solicitudes posteriores en cola también se bloquean, lo que hace que el cliente nunca solicite datos.

HTTP frente a HTTPS

la diferencia

• HTTP es un protocolo de transferencia de hipertexto, en el que la información se transmite en texto sin formato, y su conexión es simple y sin estado; HTTPS es un protocolo HTTP más SSL (Secure Sockets Layer), que puede realizar una transmisión cifrada y autenticación de identidad, que es mejor que Seguridad del protocolo HTTP.
• HTTP no verifica la identidad de la parte de la comunicación, la identidad de la parte de la comunicación puede estar disfrazada y la integridad del mensaje no puede probarse, y el mensaje puede ser alterado; HTTPS necesita solicitar un certificado de una CA para asegurar la identidad.
• HTTP y HTTPS usan métodos de conexión completamente diferentes, y los puertos también son diferentes, el primero es 80 y el segundo es 443.
• Las conexiones HTTPS consumen una gran cantidad de recursos del servidor, el almacenamiento en caché de la conexión no es tan eficiente como HTTP y los costos de tráfico son altos.
• La fase de negociación del protocolo HTTPS requiere mucho tiempo y afecta la velocidad de respuesta del sitio web, por lo que generalmente se usa divide y vencerás.12306 significa que la página de inicio usa HTTP y la información relevante del usuario usa HTTPS.

problema resuelto

HTTP es una transmisión de texto claro, por lo que existen los siguientes tres problemas:

• Riesgo de espionaje : el contenido de la comunicación se puede obtener en el enlace de comunicación.
• Riesgo de manipulación : colocación forzada de anuncios de spam, etc.
• Riesgo de suplantación : Es fácil hacerse pasar por otros sitios web.

HTTPS agrega el protocolo SSL/TLS entre las capas HTTP y TCP, lo que puede resolver bien los problemas anteriores:

• Cifrado de información: la información de interacción no puede ser robada.
• Mecanismo de verificación: El contenido de la comunicación no puede ser manipulado, y si es manipulado, no se puede mostrar normalmente.
• Certificado de Identidad: Demuestra que un sitio web es auténtico.

HTTP frente a TCP

• HTTP es un protocolo de capa de aplicación, que resuelve principalmente cómo empaquetar datos, mientras que el protocolo TCP es un protocolo de capa de transporte, que resuelve principalmente cómo se transmiten los datos en la red.
  • ¿Por qué necesitamos HTTP cuando hay TCP? Cuando transmitimos datos, solo podemos usar el protocolo TCP (capa de transporte), pero sin la capa de aplicación, los usuarios no pueden identificar el contenido de los datos. Si desea que los datos transmitidos sean significativos , debe utilizar el protocolo de capa de aplicación.
• HTTP está construido sobre el protocolo TCP.

El método específico de encriptación HTTPS

HTTPS no es un protocolo nuevo, pero permite que HTTP se comunique primero con SSL (Secure Sockets Layer) y luego con SSL y TCP . Es decir, HTTPS usa túneles para la comunicación.** Al usar SSL, HTTP tiene encriptación (anti-escuchas), autenticación (anti-masquerading) y protección de integridad (anti-manipulación). **

• Autenticación: use una autoridad de autenticación de certificado digital de terceros para autenticar a las partes que se comunican. Poner la clave pública del servidor en el certificado digital resuelve el riesgo de suplantación. Siempre que se confíe en el certificado, se confiará en la clave pública.

  • ¿Por qué necesito una autoridad de certificación de CA para emitir un certificado?

    • El protocolo HTTP se considera inseguro porque es fácil de ser monitoreado por oyentes y servidores falsos durante el proceso de transmisión, mientras que el protocolo HTTPS resuelve principalmente los problemas de seguridad en la transmisión de la red. Suponiendo que no haya una autoridad de certificación, cualquiera puede crear un certificado, lo que conducirá a un problema de ataque de intermediario : aunque el cliente inicia una solicitud HTTPS, el cliente no tiene idea de que su red ha sido interceptada y el contenido de la transmisión es completamente robado por el intermediario.

      

• Cifrado: cifrado híbrido de cifrado simétrico y cifrado asimétrico (el cifrado simétrico se usa para transmitir datos y el cifrado asimétrico se usa para intercambiar claves de sesión) . El cifrado asimétrico se usa para intercambiar claves de sesión antes de que se establezca la comunicación, y ya no se usa el cifrado asimétrico. en el futuro Durante el proceso de comunicación, los datos de texto sin formato se cifran utilizando la clave de sesión cifrada simétrica .

  • ¿Qué es el cifrado simétrico y el cifrado asimétrico?

    • El cifrado simétrico, también llamado cifrado de clave privada, se refiere a un algoritmo de cifrado que utiliza la misma clave secreta para el cifrado y el descifrado .
    • El cifrado asimétrico requiere dos claves: una clave pública y una clave privada, y estas dos aparecen en pares. Entre ellas, la clave pública está abierta al público y puede ser obtenida por todos, mientras que la clave privada no es pública.

  • ¿Por qué el cifrado híbrido?

    • El cifrado simétrico utiliza solo una clave secreta y la velocidad de cálculo es rápida. La clave secreta debe mantenerse en secreto y no se puede lograr el intercambio seguro de claves.
    • El cifrado asimétrico utiliza dos claves secretas: una clave pública y una clave privada. La clave pública se puede distribuir arbitrariamente mientras que la clave privada se mantiene en secreto, lo que resuelve el problema de seguridad del intercambio de claves.

  • ¿Por qué la transmisión de datos se cifra simétricamente?

    • La eficiencia de descifrado del cifrado asimétrico es muy baja y, por lo general, hay muchas interacciones de extremo a extremo en los escenarios de aplicaciones HTTP, y la eficiencia del cifrado asimétrico es inaceptable.
    • En HTTPS, solo el servidor guarda la clave privada, y un par de claves públicas y privadas solo pueden realizar el cifrado y descifrado unidireccional, por lo que el cifrado de transmisión de contenido en HTTPS es un cifrado simétrico.

  • ¿El proceso general de encriptación?

    • **Servidor de autenticación:** El navegador tiene una lista integrada de instituciones de CA de confianza y guarda los certificados de estas instituciones de CA. En la primera etapa, el servidor proporcionará un certificado de servidor certificado por la autoridad de CA. **Si la autoridad de CA que certifica el certificado del servidor existe en la lista de autoridades de CA de confianza del navegador y la información en el certificado del servidor es la misma que la sitio web que se está visitando actualmente (nombre de dominio, etc.), el navegador considera que el servidor es de confianza y obtiene la clave pública del servidor del certificado del servidor para procesos posteriores. ** De lo contrario, el navegador le pedirá al usuario que decida si continúa de acuerdo con la elección del usuario. Por supuesto, podemos administrar esta lista de instituciones de CA de confianza para agregar o eliminar las instituciones de CA en las que queremos confiar.
    • Negociar clave de sesión: el proceso de negociar también una clave privada de cifrado simétrico. Una vez que el cliente autentica el servidor y obtiene la clave pública del servidor, utiliza la clave pública para comunicarse con el servidor de forma cifrada y negocia dos claves de sesión, que son la clave de sesión del cliente utilizada para cifrar los datos enviados por el cliente al servidor, y La clave de sesión del servidor utilizada para cifrar los datos enviados desde el servidor al cliente. Partiendo de la premisa de que la clave pública del servidor existente puede cifrar la comunicación, la razón para negociar dos claves simétricas es que cifrado asimétrico es relativamente más complejo y el uso del cifrado simétrico durante la transmisión de datos puede ahorrar recursos informáticos. Además, la clave de sesión se genera aleatoriamente y cada negociación tendrá un resultado diferente, por lo que la seguridad es relativamente alta.
    • **Comunicación encriptada:** En este punto, tanto el cliente como el servidor tienen la clave de sesión para esta comunicación, y todos los datos HTTP transmitidos posteriormente serán encriptados por la clave de sesión. De esta forma, será difícil que otros usuarios de la red roben y alteren los datos transmitidos entre el cliente y el servidor, asegurando así la privacidad e integridad de los datos.

• Protección de integridad: SSL proporciona una función de resumen de mensajes para la protección de integridad. HTTP también proporciona la función de resumen de mensajes MD5, pero no es seguro. Esta función puede generar una "huella digital" única para los datos para verificar la integridad de los datos y resolver el riesgo de manipulación. Antes de enviar el texto sin formato, el cliente calculará la "huella digital" del texto sin formato a través del algoritmo de resumen. Al enviar, la "huella digital + texto sin formato" se cifrarán juntos en texto cifrado y se enviarán al servidor. Después de que el servidor descifra, use el mismo algoritmo de resumen para calcular el texto sin formato enviado y compare la "huella digital" que lleva el cliente con la "huella digital" calculada actualmente". Si son iguales, los datos están completos.

proceso SSL

El proceso SSL son los pasos específicos para establecer un canal seguro HTTPS:

• El cliente inicia la comunicación SSL mediante el envío de un mensaje Client Hello. El mensaje contiene la versión especificada de SSL compatible con el cliente, una lista de componentes de cifrado (algoritmo de cifrado utilizado, longitud de la clave, etc.)
• Cuando el servidor sepa que la comunicación SSL es posible, responderá con un mensaje de saludo del servidor. Al igual que el cliente, el mensaje contiene la versión SSL y los componentes de cifrado. El contenido de los componentes de cifrado del servidor se filtra de los componentes de cifrado del cliente recibidos. . Después de eso, se envía un mensaje de Certificado (clave pública y certificado) y, finalmente, el servidor envía un mensaje de Servidor Hello Done para notificar al cliente, y finaliza la fase inicial de la negociación del protocolo de enlace SSL.
• El cliente responde con un mensaje de intercambio de clave de cliente (que incluye una cadena de contraseña aleatoria Pre-masterSecret utilizada en el cifrado de comunicaciones), que se cifra con la clave pública anterior. Luego, el cliente continúa enviando el mensaje Change Ciper Spec, que le recuerda al servidor que la comunicación posterior a este mensaje se cifrará con la clave Pre-masterSecret. Finalmente, el cliente envía un mensaje Finalizar, que contiene el valor de verificación general de todos los mensajes conectados hasta el momento. El hecho de que el protocolo de enlace sea exitoso depende de si el servidor puede descifrar correctamente el mensaje.
• El servidor también envía un mensaje Cambiar especificación de cifrado y un mensaje Finalizado.

En general es:

• Intercambiar números de versión del protocolo SSL
• Seleccione un método de encriptación compatible con ambas partes de la comunicación
• Implementar autenticación de identidad en ambos extremos
• intercambio de llaves

Código de estado de respuesta HTTP

• 1xx (continuación): recién introducido en HTTP 1.1. El solicitante debe continuar realizando la solicitud y el servidor devuelve este código para indicar que ha recibido la primera parte de la solicitud y está esperando el resto.
• 2xx (éxito): un código de estado que indica que la solicitud se procesó correctamente.
• 3xx (Redirección): Se requieren más acciones para completar la solicitud. Estos códigos de estado se utilizan para la redirección y la dirección de solicitud subsiguiente (objetivo de redirección) se especifica en el campo Ubicación de esta respuesta.
• 4xx (Error de solicitud): Se produjo un error en la solicitud del cliente, lo que impidió que el servidor la procesara.
• 5xx (error del servidor): El servidor tiene un error o se presenta un estado anormal durante el procesamiento de la solicitud.También es posible que el servidor se dé cuenta de que el procesamiento de la solicitud no se puede completar con los recursos de hardware y software actuales.

reenvío y redirección

• La barra de direcciones de redirección cambia; la ruta de la barra de direcciones de reenvío no cambia
• La redirección puede acceder a los recursos en otros sitios; el reenvío solo puede acceder a los recursos del servidor actual
• La redirección son dos solicitudes y el objeto de solicitud no se puede usar para compartir datos; el reenvío es una solicitud y el objeto de solicitud se puede usar para compartir datos

mensaje HTTP

Un mensaje de solicitud HTTP consta de cuatro partes: línea de solicitud, encabezado de solicitud, línea en blanco y cuerpo de la solicitud .

• La línea de solicitud consta de tres partes: campo de método de solicitud, campo de URL y campo de versión del protocolo HTTP , separados por espacios. Los métodos de solicitud HTTP comúnmente utilizados son: GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE, CONNECT. Entre ellos, los primeros tres están disponibles en HTTP1.0 y los últimos cinco son HTTP1.1.
  • GET: **Este método se usa cuando el cliente quiere leer un recurso del servidor. **El método GET requiere que el servidor coloque el recurso ubicado por la URL en la parte de datos del mensaje de respuesta y lo envíe de vuelta al cliente. Cuando se usa el método GET, los parámetros de solicitud y los valores correspondientes se agregan a la URL, y se usa un signo de interrogación en inglés para representar el final de la URL y el comienzo de los parámetros de solicitud. Por ejemplo /página?tamaño=11&total=111
  • POST: **Este método se utiliza cuando el cliente proporciona información al servidor. **El método POST generalmente envía algunos datos de formulario, encapsula los parámetros de la solicitud en los datos de la solicitud HTTP y aparece en forma de nombre/valor, que puede transmitir una gran cantidad de datos.
  • HEAD: **Similar a GET, excepto que el servidor solo devuelve el encabezado de respuesta después de recibir la solicitud HEAD y no envía el contenido de la respuesta. **Cuando solo necesitamos verificar el estado de una determinada página, usar HEAD es muy eficiente, ya que el contenido de la página se omite durante la transmisión.
    • Comprender la situación de los recursos sin adquirir recursos (tipo juicio)
    • Vea si el objeto existe mirando el código de estado en la respuesta
    • Mirando el encabezado, pruebe si el recurso ha sido modificado
  • PUT: **Similar a POST, pero si dos solicitudes son iguales, la última solicitud sobrescribirá la primera. ** Generalmente se usa para modificar recursos.
  • ELIMINAR: Solicitar al servidor que elimine el recurso especificado por la URL de la solicitud, pero no necesariamente ejecutado, porque el servidor puede revocar la solicitud sin notificar al cliente.
  • OPCIONES: **Utilizado para obtener los métodos soportados por la URL actual. **Si la solicitud es exitosa, incluirá un encabezado llamado "Permitir" en el encabezado HTTP y el valor es el método admitido, como "GET, POST".
  • TRACE: permite al cliente ver cómo se ve la solicitud cuando finalmente la envía al servidor.
  • CONECTAR: use el servidor como trampolín, deje que el servidor reemplace al usuario para visitar otras páginas web y luego devuelva los datos al usuario.
• Encabezado de solicitud: consta de palabras clave y valores, un par por línea, y las palabras clave y los valores están separados por dos puntos. El encabezado de solicitud informa al servidor sobre la información solicitada por el cliente.Los encabezados de solicitud típicos son:
  • User-Agent: el tipo de navegador que realizó la solicitud
  • Aceptar: una lista de tipos de contenido de respuesta reconocibles por el cliente; el asterisco "*" se usa para agrupar tipos por rango, "/" indica que todos los tipos son aceptables y "tipo/*" indica que todos los subtipos del tipo tipo son aceptables
  • Accept-Language: El lenguaje natural aceptable para el cliente
  • Aceptar codificación: el formato de codificación y compresión aceptable para el cliente
  • Accept-Charset: juego de caracteres aceptable para las respuestas
  • Host: el nombre de host solicitado, lo que permite que varios nombres de dominio tengan la misma dirección IP, es decir, un host virtual
  • Conexión: modo de conexión (cerrar o keepalive)
  • Cookie: Almacenada en el campo de la extensión del cliente, envía la cookie perteneciente al dominio al servidor del mismo nombre de dominio;
  • Content-Length: cuántos bytes de datos están contenidos en el cuerpo de la entidad
  • Tipo de contenido: el tipo de archivo de la parte del cuerpo de la entidad
  • Fecha: La hora en que el servidor generó la respuesta.
• Solicite una línea en blanco: después de que el último encabezado de respuesta sea una línea en blanco, envíe un retorno de carro y un avance de línea para informar al servidor que no hay más encabezados de respuesta a continuación .
• Cuerpo de la solicitud: contiene un bloque de datos que consta de datos arbitrarios . No todos los mensajes tienen un cuerpo. Es el principal contenido de transmisión de HTTP.

La diferencia entre GET y POST

• Definición: El significado del método GET es solicitar la obtención de recursos del servidor , que pueden ser texto estático, páginas, imágenes y videos, etc. Por ejemplo, cuando abre un enlace, el navegador enviará una solicitud GET al servidor, y el servidor devolverá todo el texto y los recursos del enlace; el método POST es una operación inversa, enviando datos al recurso especificado por el URI , y los datos se colocan en el cuerpo. Por ejemplo, complete la información de registro en un enlace determinado y haga clic en enviar, el navegador ejecutará una solicitud POST, pondrá la información enviada en el cuerpo de la solicitud del mensaje y luego empalmará el encabezado de la solicitud POST y lo enviará al servidor a través de el protocolo TCP.
• Los parámetros de la solicitud GET se conservarán por completo en el historial del navegador, pero no los parámetros de POST; la solicitud GET se pasa a través de la URL, mientras que POST se coloca en el cuerpo de la solicitud; la solicitud GET se pasa en la URL El parámetro tiene una longitud limitada, POST no.
• El navegador almacenará activamente en caché las solicitudes GET, pero POST no.
• GET genera un paquete de datos TCP: el navegador envía el encabezado HTTP y los datos juntos, y el servidor responde con 200 ok; mientras que POST genera dos paquetes de datos: el navegador envía el encabezado primero, el servidor responde con 100 continuar, el navegador envía datos , y el servidor responde Responder con 200 ok. PD: No todos los navegadores POST envían dos paquetes de datos.

HTTP1.0 frente a HTTP1.1 frente a HTTP2 frente a HTTP3

• HTTP1.1 admite conexiones largas y procesamiento de solicitudes en canalización .
  • HTTP1.0 estipula que el navegador y el servidor solo mantienen una conexión corta. Cada solicitud del navegador debe establecer una conexión TCP con el servidor. El servidor desconecta inmediatamente la conexión TCP después de completar el procesamiento de la solicitud. El servidor no rastrea cada cliente y no registra la pregunta anterior.
  • HTTP1.1 admite conexiones largas y usa conexiones largas de forma predeterminada. Se pueden transmitir varias solicitudes y respuestas HTTP en la misma conexión TCP, y varias solicitudes y respuestas se pueden superponer y proceder simultáneamente. Y se han agregado más encabezados de solicitud y encabezados de respuesta (host), métodos, etc. (PUT, DELETE, CONNECT, TRACE, OPTIONS). Sin embargo, esta conexión persistente necesita agregar un nuevo encabezado de solicitud para ayudar a realizarla. Por ejemplo, cuando el valor de Connection es Keep-Alive, el cliente notifica al servidor para mantener la conexión después de devolver el resultado de esta solicitud; cuando el valor del encabezado de solicitud de conexión está cerrado, el cliente notifica al servidor Cerrar la conexión después de devolver el resultado de esta solicitud.
  • HTTP1.1 también permite que el cliente emita la siguiente solicitud sin esperar la devolución del resultado de la solicitud anterior, pero el servidor debe devolver los resultados de la respuesta en el orden en que se reciben las solicitudes del cliente para garantizar que el cliente pueda distinguir cada una. solicitud de contenido de respuesta.
• HTTP1.1 también proporciona encabezados de solicitud y encabezados de respuesta relacionados con la autenticación, la administración del estado y los mecanismos de caché, como el control de caché . HTTP1.1 agrega algunas funciones de caché nuevas basadas en 1.0. Cuando la antigüedad del objeto almacenado en caché excede Caducar, se convierte en un objeto obsoleto. El caché no necesita descartar el objeto obsoleto directamente, sino que lo reactiva (revalidación) con el servidor de origen.
• Campo de host HTTP1.1 recién agregado
  • HTTP1.0 cree que cada servidor está vinculado a una dirección IP única, por lo que la URL en el mensaje de solicitud no pasa el nombre de host (nombre de host). Pero con el desarrollo de la tecnología de host virtual, pueden existir múltiples hosts virtuales en un servidor físico y comparten la misma dirección IP.
  • Los mensajes de solicitud y de respuesta HTTP1.1 deben admitir el campo de encabezado de host para identificar el host, y si no hay un campo de encabezado de host en el mensaje de solicitud, se informará 400Bad Request .
• Optimización de ancho de banda para HTTP1.1
  • En HTTP1.0, hay algunos fenómenos de desperdicio de ancho de banda, por ejemplo, el cliente solo necesita una parte de un objeto, pero el servidor envía el objeto completo. Por ejemplo, el cliente solo necesita mostrar parte de un documento, o necesita admitir la reanudación del punto de interrupción al descargar un archivo grande, en lugar de tener que volver a descargar el archivo completo después de que ocurra una interrupción.
  • HTTP1.1 introduce el campo de encabezado de rango en el mensaje de solicitud, lo que permite solicitar solo una parte determinada del recurso . El campo de encabezado Content-Range en el mensaje de respuesta declara el valor de desplazamiento y la longitud del objeto devuelto. Si el servidor responde con el contenido de rango solicitado por el objeto, el código de respuesta es 206, lo que evita que Cache confunda la respuesta con un objeto completo.
  • Si el mensaje de solicitud contiene contenido de entidad relativamente grande, pero no está seguro de si el servidor puede aceptar la solicitud (por ejemplo, si tiene permiso), en este momento, si se envía precipitadamente una solicitud con una entidad grande, se desperdiciará ancho de banda si es rechazado. HTTP1.1 ha agregado un nuevo código de estado 100. **El cliente envía una solicitud con solo el campo de encabezado por adelantado. Si el servidor rechaza la solicitud debido a razones como permisos, devuelve un código de respuesta 401; si el servidor acepta la solicitud, enviará Si el código de respuesta es 100, el cliente puede continuar enviando una solicitud completa con entidades. **ps: HTTP1.0 no admite el código de respuesta 100, pero el cliente puede agregar el campo de encabezado Esperar en el mensaje de solicitud y establecer su valor en 100-continuar.
• HTTP1.1 también define 24 códigos de respuesta más. El 1xx recién agregado indica que el servidor ha aceptado parte de los datos y el solicitante debe continuar enviando la solicitud; también hay 409 (Conflicto) que indica que el recurso solicitado está en conflicto con el estado actual del recurso; 410 (Gone) indica que un recurso en el servidor se eliminó permanentemente.
• Cuello de botella de rendimiento HTTP1.1
  • Encabezado sin comprimir : El encabezado de respuesta de la solicitud se envía directamente sin compresión, cuanta más información del encabezado, mayor es la demora. Si envía varias solicitudes con encabezados grandes, provocará una gran sobrecarga del sistema.
  • Bloqueo de cabeza de línea : El servidor responde en el orden de las solicitudes, si el servidor responde lentamente o se bloquea una solicitud, el cliente no podrá obtener datos, lo que resultará en un bloqueo de cabeza de línea.
  • Configuración de prioridad restringida : si el navegador abre varias solicitudes para un nombre de dominio específico, si algunos recursos en la página web son más importantes que otros, esto aumentará el efecto de cola de los recursos: es decir, los recursos con alta prioridad se solicitan primero y primero se solicitan los recursos con alta prioridad, luego solicita un recurso con menor prioridad y el navegador no iniciará una nueva solicitud con menor prioridad durante el intervalo de tiempo para solicitar un recurso con mayor prioridad.
• HTTP2 se basa en HTTPS, por lo que la seguridad de HTTP2 está garantizada
  • Compresión de encabezado : HTTP2 comprimirá el encabezado. Si se envían varias solicitudes al mismo tiempo y sus encabezados son todos iguales o similares, HTTP2 comprimirá la parte repetida. El llamado algoritmo HPACK: mantenga una tabla de información de encabezado al mismo tiempo en el cliente y el servidor, todos los campos se almacenarán en esta tabla, se generará un número de índice y el mismo campo no se enviará en el futuro. solo se enviará el número de índice, que puede mejorar la aceleración.
  • Formato binario : a diferencia de los mensajes de texto sin formato en HTTP1.1, HTTP2 adopta el formato binario de manera integral.Tanto la información del encabezado como el cuerpo de los datos son binarios, y se denominan colectivamente marcos: marco de información del encabezado y marco de datos. Esto es muy amigable para la computadora.Al recibir el mensaje, no necesita convertir el texto sin formato en binario, sino que analiza directamente el mensaje binario, lo que aumenta la eficiencia de la transmisión de datos.
  • Flujo de datos : los paquetes HTTP2 no se envían en orden. Los paquetes de datos consecutivos en la misma conexión pueden pertenecer a diferentes respuestas. Por lo tanto, el paquete debe marcarse para indicar a qué respuesta pertenece. Cada datagrama de solicitud o respuesta se denomina flujo de datos, y cada flujo de datos está marcado con un número único, lo que estipula que el número de flujos de datos enviados por el cliente es impar y el número de flujos de datos enviados por el servidor es par . El cliente también puede especificar la prioridad del flujo de datos, y el servidor responderá primero a la solicitud con alta prioridad.
  • La multiplexación se utiliza para resolver el bloqueo de cabecera de línea : HTTP2 puede enviar simultáneamente varias solicitudes o respuestas en una conexión, en lugar de una correspondencia uno a uno en secuencia. Se elimina la respuesta en serie en HTTP1.1, por lo que no hay necesidad de esperar en la fila y no habrá problemas de bloqueo de cabeza de línea, lo que reduce la demora y mejora en gran medida la utilización de la conexión. Por ejemplo, en una conexión TCP, el servidor recibe dos solicitudes de los clientes A y B. Si encuentra que el proceso de procesamiento de A lleva mucho tiempo, responde a la parte procesada de la solicitud de A, luego responde a la solicitud de B, y luego responde a A después de completar Solicitar el resto.
  • Server push : HTTP2 también mejora en cierta medida el modo de trabajo tradicional de solicitud-respuesta: el servidor ya no responde de forma pasiva, sino que también puede enviar mensajes de forma activa al cliente. Por ejemplo, cuando el navegador solo solicita HTML, envía activamente recursos estáticos, como archivos JS y CSS, que pueden usarse para el cliente con anticipación para reducir la demora.
• El problema con HTTP2 es que varias solicitudes HTTP están multiplexando una conexión TCP. El protocolo TCP subyacente no sabe cuántas solicitudes HTTP hay, por lo que una vez que se produce la pérdida de paquetes, se activará el mecanismo de retransmisión TCP, de modo que en una conexión TCP Todos Las solicitudes HTTP deben esperar a que se retransmita el paquete perdido, lo que provoca el bloqueo. Y HTTP2 se basa en HTTPS, no solo tiene un protocolo de enlace TCP, sino también un protocolo de enlace TCP + TLS, que requiere dos procesos de retraso del protocolo de enlace.
• HTTP3 reemplaza el protocolo TCP en la capa inferior de HTTP con UDP para resolver el problema de pérdida de paquetes. A UDP no le importa el orden de las respuestas a las solicitudes ni la pérdida de paquetes. Incluso si se produce una pérdida de paquetes, no se bloquearán otras solicitudes. UDP es una transmisión no confiable, pero el protocolo QUIC basado en UDP puede lograr una transmisión confiable similar a TCP.
  • QUIC es un protocolo de capa de transporte de Internet de baja latencia basado en UDP desarrollado por Google. Tiene su propio conjunto de mecanismos de transmisión para garantizar la confiabilidad de la transmisión. Cuando se produce una pérdida de paquetes en un flujo, solo se bloquea este flujo y los demás flujos no se ven afectados.
  • La actualización de TLS3 omite la última versión 1.3 y el algoritmo de compresión de encabezado también se actualiza a QPack
  • Se necesitan seis interacciones para que HTTPS establezca una conexión (apretón de manos de tres vías y apretón de manos de tres vías TLS/1.3); QUIC combina directamente las seis interacciones anteriores de TCP y TLS/1.3 en tres, lo que reduce la cantidad de interacciones.

HTTP conexión larga y conexión corta

• HTTP1.0 usa una conexión corta (sin conexión) de forma predeterminada, es decir, cada vez que el navegador y el servidor responden a una solicitud, se establece una conexión TCP y la conexión finaliza una vez que se completa la solicitud. Si un HTML u otro tipo de página web a la que accede el navegador del cliente contiene otros recursos web, como archivos JavaScript, archivos de imagen, archivos CSS, etc., cuando el navegador encuentre dicho recurso web, creará sesiones HTTP. Obviamente, esto tiene el problema de que es una pérdida de tiempo establecer e interrumpir conexiones TCP varias veces.
• HTTP1.1 comenzó a usar una conexión larga para mantener las características de la conexión. Para usar una conexión larga, debe agregar Connection:keep-alive en el encabezado
• Ventajas y desventajas:
  • Las conexiones largas pueden ahorrar más operaciones de establecimiento y cierre de TCP, reducir el desperdicio y ahorrar tiempo. Para los clientes que solicitan recursos con frecuencia, las conexiones largas son más adecuadas. Pero el problema es que si la conexión larga no se ha cerrado, a medida que aumenta la cantidad de conexiones de clientes, tarde o temprano el servidor no podrá manejarlo, por lo que el servidor debe adoptar algunas estrategias, como cerrar algunas conexiones que tienen no ocurrió durante mucho tiempo Puede evitar que algunas conexiones maliciosas causen daños en el servicio en el servidor, o establecer la cantidad máxima de conexiones largas para cada cliente.
  • Las conexiones cortas son fáciles de administrar para el servidor y las conexiones existentes son conexiones útiles sin medios de control adicionales, pero si el cliente lo solicita con frecuencia, se desperdiciará tiempo y ancho de banda en las operaciones de establecimiento y cierre de TCP.
• Cuándo usar:
  • Las conexiones largas se utilizan principalmente para operaciones frecuentes y comunicaciones punto a punto, y el número de conexiones no debería ser demasiado.
  • Las conexiones cortas son adecuadas para situaciones en las que hay una gran cantidad de simultaneidad pero operaciones poco frecuentes.

Conocimientos relacionados con DNS

DNS utiliza el protocolo TCP o el protocolo UDP

DNS: El sistema de nombres de dominio es un servicio de Internet. Es una base de datos distribuida que asigna nombres de dominio y direcciones IP entre sí, lo que permite a las personas acceder a Internet de manera más conveniente. DNS utiliza el puerto 53 de TCP y UDP. Su función principal es traducir los nombres de dominio a direcciones IP, este proceso se denomina resolución de nombres de dominio DNS.

• DNS usa el protocolo TCP cuando realiza transferencias de zona y usa el protocolo UDP para la resolución de nombres de dominio

• Transferencia de zona: la especificación DNS especifica dos tipos de servidores DNS, uno se denomina servidor DNS primario y el otro se denomina servidor DNS secundario. En una zona, el servidor DNS principal lee la información de datos DNS de la zona desde su propio archivo de datos y el servidor DNS secundario lee la información de datos DNS de la zona desde el servidor DNS principal de la zona. Cuando se inicia un servidor DNS secundario, necesita comunicarse con el servidor DNS principal y cargar información de datos.

• Hay dos consideraciones principales al usar TCP para transferencias de zona:

  • El servidor DNS secundario consultará periódicamente (generalmente tres horas) al servidor de nombres de dominio principal para saber si los datos han cambiado. Si hay un cambio, se realizará una transferencia de zona para sincronizar los datos. La transferencia de zona usará TCP en lugar de UDP, porque la cantidad de datos transmitidos sincrónicamente es mucho mayor que la de una solicitud y respuesta (TCP puede enviar 1440 bytes a la vez).
  • TCP es una conexión fiable que garantiza la precisión de los datos.

• El protocolo UDP se utiliza para la resolución de nombres de dominio: el cliente consulta el servidor DNS por el nombre de dominio y el contenido devuelto generalmente no supera los 512 bytes, que pueden ser transmitidos por UDP. No es necesario pasar por el protocolo de enlace de tres vías de TCP, por lo que la carga en el servidor DNS será menor y la respuesta será más rápida.

secuestro de DNS

El secuestro de nombres de dominio resuelve el nombre de dominio del sitio web de destino en la dirección IP incorrecta atacando el servidor de resolución de nombres de dominio (DNS) o falsificando el servidor de resolución de nombres de dominio (DNS), de modo que el usuario no pueda acceder al sitio web de destino o deliberadamente o requiere maliciosamente que el usuario acceda a la IP especificada El propósito de la dirección (sitio web). El efecto es que no se puede acceder a una URL específica o se accede a una URL falsa .

Por un lado, el secuestro de nombres de dominio puede afectar la experiencia en línea del usuario. Los usuarios son llevados a sitios web falsos y no pueden navegar normalmente. Después de que se secuestra el nombre de dominio de un sitio web con una gran cantidad de usuarios, los efectos adversos continuarán. expandir; por otro lado, los usuarios pueden ser atraídos a sitios web falsos. El inicio de sesión y otras operaciones en el sitio web conducen a la fuga de datos privados.

Solución: si conoce la dirección IP de la comunicación, puede acceder directamente a ella a través de la dirección IP.

Envenenamiento de DNS

Dado que DNS utiliza el protocolo UDP para transmitir paquetes de consulta y respuesta, es un mecanismo de confianza simple. Para el paquete de datos de respuesta recibido, solo se confirman la dirección IP, el puerto y el ID de consulta aleatoria del paquete de consulta original, sin ningún análisis de la legalidad del paquete de datos. Si coincide, lo recibirá como un paquete de respuesta correcto, realizará la resolución de DNS y descartará todos los paquetes de respuesta posteriores, lo que permite al atacante hacerse pasar por el servidor DNS raíz y enviar un paquete de respuesta falsificado al servidor DNS local para contaminar de forma preventiva el servidor DNS local Almacenamiento en caché de DNS.

Cracking de envenenamiento de DNS, si hay datos en el caché de DNS local, entonces no tendrá éxito.

Análisis de Nombres de Dominio

Por ejemplo un nombre de dominio: www.hty.com

• Dominio de nivel superior (TLD): .com
• Nombre de dominio de subnivel (segundo nivel) (SLD): .hty, los usuarios pueden registrar este nivel de nombre de dominio
• Nombre de host (host): www, también conocido como nombre de dominio de tercer nivel, que es el nombre asignado por el usuario al servidor en su propio dominio, y puede ser asignado por el usuario de forma arbitraria.

Resolución de nombres de dominio DNS

• El navegador verifica su propio caché para ver si hay una regla correspondiente al nombre de dominio y lo devuelve directamente; de ​​lo contrario, verifique el archivo de hosts para ver si hay una regla correspondiente al nombre de dominio y, de ser así, use directamente la ip. dirección en el archivo de hosts.

• Si no hay un archivo de hosts, el navegador enviará una solicitud de DNS al servidor DNS local. El servidor DNS local generalmente lo proporciona el proveedor del servidor de acceso a la red local. Después de que la solicitud de DNS llega al servidor DNS local, el servidor DNS local primero consultará su registro de caché, si hay alguno, puede devolver directamente el resultado y, si no se puede encontrar, también consultará el servidor raíz DNS.

• Si hay un servidor de nombres de dominio raíz DNS, regresará, si no, le dirá al servidor DNS local, puede ir al servidor de dominio de nivel superior para continuar con la consulta y proporcionar la dirección del dominio de nivel superior servidor.

• El servidor DNS local continúa enviando solicitudes al servidor de dominio de nivel superior, es decir, el servidor de dominio .com Después de recibir la solicitud, el servidor de dominio .com no devolverá directamente la relación correspondiente entre el nombre de dominio y la dirección IP , pero dígale al servidor DNS local la dirección del servidor resuelto.

• Finalmente, el servidor DNS local envía una solicitud al servidor de resolución del nombre de dominio. En este momento, se puede recibir una relación correspondiente entre el nombre de dominio y la dirección IP. El servidor DNS local no solo devuelve la dirección IP al usuario. computadora, pero también guarda la relación correspondiente en el archivo de hosts.En el caché, para que la próxima vez que otros usuarios consulten, los resultados puedan devolverse directamente.

Consulta recursiva de consulta iterativa de DNS

La consulta del host al servidor de nombres de dominio local generalmente adopta una consulta recursiva : si el servidor de nombres de dominio local consultado por el host no conoce la dirección IP del nombre de dominio que se consulta, entonces el servidor de nombres de dominio local continuará enviando la consulta. solicitudes a otros servidores de nombres de dominio raíz como un mensaje de cliente DNS (continúe consultando el host), en lugar de permitir que el host realice la siguiente consulta por sí mismo. Por lo tanto, el resultado de la consulta que devuelve la consulta recursiva es la dirección IP que se va a consultar o se notifica un error que indica que no se puede consultar la dirección IP deseada.

**Consulta iterativa del servidor de dominio local al servidor de nombres de dominio raíz: **Cuando el servidor de nombres de dominio raíz recibe el mensaje de solicitud de consulta iterativa enviado por el servidor de nombres de dominio local, proporciona la dirección IP a consultar o le dice el servidor local para ir a Qué servidor de nombres consultar. Luego deje que el servidor local realice las consultas subsiguientes. El servidor de nombres de dominio raíz generalmente le dice al servidor de nombres de dominio local la dirección IP del servidor de nombres de dominio de nivel superior que conoce, y le pide al servidor de nombres de dominio local que consulte el dominio de nivel superior. nombre del servidor. El servidor de nombres de dominio de nivel superior proporciona la dirección IP o le dice al servidor local qué servidor de nombres de dominio autorizado (hty.com) debe consultar a continuación.

Qué sucede después de que el navegador ingresa la URL

1. El navegador resuelve el nombre de host del servidor a partir de la URL y lo convierte en una dirección IP (resolución de nombres de dominio DNS)

2. El navegador establece una conexión TCP con el servidor (apretón de manos de tres vías)

   • Después de obtener la dirección IP correspondiente al nombre de dominio, se iniciará una solicitud de conexión TCP al puerto 80 del programa del servidor WEB con un puerto aleatorio (1024-65535), y la solicitud de conexión ingresará a la pila de protocolos TCP/IP del kernel ( para identificar la solicitud), es posible pasar por el filtrado del cortafuegos Netfilter, finalmente llegar al programa WEB y finalmente establecer una conexión TCP/IP.

3. El navegador envía un mensaje de solicitud HTTP al servidor

4. El servidor analiza la solicitud y envía un mensaje de respuesta HTTP al navegador.

   • Después de que el lado del servidor recibe la solicitud, el servidor web (hablando con precisión, debería ser el servidor http) procesa la solicitud, como Apache, Ngnix (equilibrio de carga), IIS, etc. El servidor web analiza la solicitud del usuario, sabe qué archivos de recursos deben programarse y luego procesa la solicitud y los parámetros del usuario a través de los archivos de recursos correspondientes, llama a la información de la base de datos y finalmente devuelve el resultado al cliente del navegador a través del servidor web.

5. El navegador analiza el contenido de la respuesta.

6. Cierra la conexión TCP (cuatro ondas)

7. Renderizar la página (construir árbol DOM, árbol de reglas CSS)

Apretón de manos TCP de tres vías y onda de cuatro vías

Formato de mensaje TCP:

• Número de secuencia: el número de secuencia seq, que ocupa 32 bits, se utiliza para identificar el flujo de bytes enviado desde el origen TCP al destino, y se marca cuando el iniciador envía datos. El propósito es resolver el problema del desorden.
• Número de acuse de recibo: número de secuencia de acuse de recibo, que ocupa 32 bits, solo cuando la bandera de acuse de recibo es 1, el campo de número de secuencia de acuse de recibo es válido, la parte de acuse de recibo acuse de recibo = remitente seq + 1.
• Bits de bandera: 6 en total, a saber, URG, ACK, PSH, RST, SYN, FIN, etc.
  • URG: El puntero urgente es válido.
  • ACK: Confirma que el número de secuencia es válido.
  • PSH: el receptor debe entregar este mensaje a la capa de aplicación lo antes posible.
  • RST: restablecer la conexión.
  • SYN: Inicia una nueva conexión.
  • FIN: Liberar una conexión.
• Tamaño de ventana: control de flujo, utilizado para identificar sus propias capacidades de procesamiento

Apretón de manos de tres vías: establecer una conexión TCP

Una conexión TCP debe ser abierta de forma activa por una de las partes y de forma pasiva por la otra. El cliente que abre activamente la conexión antes del protocolo de enlace finaliza la fase CERRADA, y el servidor que se abre pasivamente también finaliza la fase CERRADA y entra en la fase LISTEN. Luego comience el apretón de manos de tres vías:

• Uno: Primero, el cliente envía un mensaje TCP al servidor.

  • El bit indicador es SYN = 1, ACK = 0, lo que indica que se solicita una nueva conexión;
  • El número de secuencia es seq = x; +
  • Entonces el cliente entra en la etapa SYN-SENT.

• Dos: después de que el servidor recibe el mensaje TCP del cliente, finaliza la fase LISTEN y devuelve un mensaje TCP.

  • Los bits de bandera son SYN = 1 y ACK = 1, lo que significa que se confirma que el número de serie de secuencia del mensaje del cliente es válido, el servidor normalmente puede recibir los datos enviados por el cliente y acepta crear una nueva conexión (que es decir, decirle al cliente que el servidor ha recibido sus datos);
  • El número de secuencia es seq = y, que indica el número de secuencia inicial del flujo de bytes enviado cuando el servidor actúa como remitente;
  • El número de confirmación es ack = x + 1, lo que significa que se recibe el cliente seq y su valor aumenta en 1 como el valor de su propio número de confirmación ack, y luego el servidor ingresa a la etapa SYN-RCVD.

• Tres: después de que el cliente recibe el mensaje TCP del servidor para confirmar la recepción de los datos, está claro que la transmisión de datos del cliente al servidor es normal y finaliza la etapa SYN-SENT. Y devolver el último mensaje TCP.

  • El bit indicador ACK = 1, lo que significa confirmar la recepción de la señal de que el servidor accede a conectarse (es decir, decirle al servidor que sé que ha recibido los datos que envié);
  • El número de serie es seq = x + 1, lo que significa que se recibe el número de confirmación del lado del servidor y su valor se usa como su propio valor de número de serie;
  • El número de confirmación es ack = y + 1, lo que significa que se recibe el número de serie del lado del servidor seq, y su valor se suma en 1 como el valor de su propio número de confirmación Ack;

  El cliente entra entonces en la fase EXTABLISHED (establecido). Después de que el servidor recibe el mensaje TCP "acuse de recibo de los datos del servidor" del cliente, está claro que la transmisión de datos del servidor al cliente es normal. Termina la etapa SYN-SENT y entra en la etapa ESTABLECIDO.

En el mensaje TCP transmitido por el cliente y el servidor, los valores del número de confirmación ack y el número de secuencia seq de ambas partes se calculan sobre la base de los valores seq y ack de cada uno, lo que garantiza la continuidad de la transmisión del mensaje TCP. Una vez que se pierde el mensaje TCP enviado por una determinada parte, el protocolo de enlace no puede continuar, para garantizar la finalización sin problemas del protocolo de enlace de tres vías.

Cuatro ondas: cerrar la conexión TCP

La conexión TCP es bidireccional y la liberación de la conexión debe ser liberada activamente por una parte y pasivamente por la otra parte. El cliente que libera activamente la conexión antes de agitar finaliza la fase ESTABLECIDA y comienza a agitar cuatro veces.

• Uno: El cliente quiere liberar la conexión y envía un mensaje TCP al servidor

  • El bit indicador es FIN = 1, lo que indica que se solicita la liberación de la conexión.
  • El número de secuencia es seq = u
  • Luego el cliente ingresa a la etapa FIN-WAIT-1, que es la etapa semicerrada. Y deje de enviar datos en la dirección del cliente al servidor (aún se pueden enviar mensajes de confirmación normales), pero el cliente aún puede aceptar datos del servidor.

• Dos: después de que el servidor recibe el mensaje TCP enviado por el cliente, sabe que el cliente desea liberar la conexión, luego el servidor finaliza la etapa ESTABLECIDA, ingresa a la etapa CLOST-WAIT (estado de espera cerrado) y devuelve un mensaje TCP

  • El bit de bandera es ACK = 1, lo que indica que se recibe la solicitud de liberación de la conexión enviada por el cliente.
  • número de secuencia seq = v
  • El número de confirmación es acuse de recibo = u + 1, lo que significa que en base a la recepción del mensaje del cliente, agregue 1 a su valor de secuencia de número de serie como el valor del número de confirmación acuse de recibo de este segmento del mensaje. Luego, el servidor comienza a prepararse para liberar la conexión del servidor al cliente.
  • Después de recibir el mensaje TCP del servidor, el cliente confirma que el servidor ha recibido la solicitud de liberación de conexión del cliente y luego el cliente finaliza la fase FIN-WAIT-1 y entra en la fase FIN-WAIT-2.

Las dos primeras oleadas no solo le permiten al servidor saber que el cliente desea liberar la conexión, sino que también le informan al cliente que el servidor sabe que desea liberar la conexión. Entonces se puede confirmar que la conexión del cliente al servidor está cerrada.

• Tres: después de que el servidor envía el mensaje de confirmación ACK, después de la etapa CERRADO-ESPERA, está listo para liberar la conexión del servidor al cliente y envía un mensaje TCP al cliente nuevamente.

  • Los bits de bandera son FIN, ACK, lo que significa que está listo para liberar la conexión (el ACK aquí no es un mensaje de confirmación para confirmar la recepción del mensaje del lado del servidor).
  • El número de secuencia es seq = w
  • El número de confirmación es acuse de recibo = u + 1, lo que significa que en base a la recepción del mensaje del cliente, agregue 1 a su valor de secuencia de número de serie como el valor del número de confirmación acuse de recibo de este segmento del mensaje.
  • Luego, el servidor finaliza la etapa CLOSE-WAIT y entra en la etapa LAST-ACK. Y deje de enviar datos en la dirección del servidor al cliente, pero el servidor aún puede recibir datos transmitidos desde el cliente.
  • La existencia de la etapa CLOST-WAIT es para asegurar que el servidor envíe un paquete de confirmación para avisar al cliente; para procesar los datos que no han sido procesados.

• Cuatro: el cliente recibe el mensaje TCP enviado desde el servidor, confirma que el servidor está listo para liberar la conexión, finaliza la etapa FIN-WAIT-2, ingresa a la etapa TIME-WAIT y envía un mensaje al servidor

  • El bit indicador es ACK, lo que significa que se ha recibido la señal de que el servidor está listo para liberar la conexión.
  • El número de secuencia es seq = u + 1, lo que significa que en base a la recepción del mensaje del lado del servidor, el valor de su número de confirmación ack se usa como el valor del número de secuencia de este segmento del mensaje.
  • El número de confirmación es ack = w + 1, lo que significa que, en función de la recepción del mensaje del lado del servidor, el valor de su número de serie seq + 1 se utiliza como valor del número de confirmación de este segmento del mensaje.

  Luego, el cliente comienza a esperar 2MSL en la fase TIME-WAIT . Después de recibir el mensaje TCP enviado por el cliente, el servidor finaliza la fase LAST-ACK y entra en la fase CLOSED. Esto confirma oficialmente el cierre de la conexión en la dirección servidor-cliente. Después de que el cliente espera 2MSL en la etapa TIEMPO-ESPERA, ingresa a la etapa CERRADO, completando así cuatro manos agitadas.

  Las últimas dos oleadas no solo le permiten al cliente saber que el servidor está listo para liberar la conexión, sino que también le permiten al servidor saber que el cliente sabe que está listo para liberar la conexión. Por lo tanto, se puede confirmar que la conexión del servidor al cliente está cerrada, completando así las "cuatro ondas".

  En el mensaje TCP transmitido entre el cliente y el servidor, los valores del número de confirmación ack y el número de secuencia seq de ambas partes se calculan sobre la base de los valores seq y ack de cada uno, lo que garantiza la coherencia de la transmisión del mensaje TCP una vez el mensaje TCP enviado por una determinada parte se pierde, no puede continuar con la onda, lo que garantiza la finalización sin problemas de las ondas de cuatro manos.

¿Por qué no dos o cuatro apretones de manos?

• Para evitar que el servidor abra algunas conexiones inútiles para aumentar la sobrecarga del servidor y evitar que el segmento de solicitud de conexión no válida se transmita repentinamente al servidor, lo que resulta en un error. Si solo hay dos protocolos de enlace, es equivalente a establecer una conexión después de que finaliza el segundo protocolo de enlace, entonces el servidor no puede confirmar si el cliente ha recibido su propia señal de sincronización.Si la señal que acepta la conexión se pierde por algún motivo, entonces el cliente y El número de serie inicial del servidor siempre es inconsistente, lo que resulta en la imposibilidad de conectarse (el cliente no puede saber si el servidor ha recibido la señal que desea conectar).
• En esencia, para lograr una transmisión de datos confiable, ambas partes en la comunicación TCP deben mantener un número de secuencia para identificar cuál de los paquetes de datos enviados ha recibido la otra parte. El proceso del protocolo de enlace de tres vías es un paso necesario para que ambas partes que se comunican se informen mutuamente sobre el valor inicial del número de serie y confirmen que la otra parte ha recibido el valor inicial del número de serie. Si solo hay dos apretones de manos, como máximo solo se puede confirmar el número de serie inicial del iniciador de la conexión, mientras que el número de serie de la otra parte no se puede confirmar.
• El apretón de manos de cuatro vías obviamente es innecesario, porque tres veces ya pueden garantizar la conexión. El segundo apretón de manos significa que el servidor ha recibido la solicitud del cliente y también significa que el servidor acepta conectarse con el cliente.

¿Qué debo hacer si hay pérdida de paquetes (pérdida de mensajes) en el protocolo de enlace de tres vías?

• Si el SYN enviado por el cliente al servidor se pierde y no llega, el cliente expirará periódicamente y retransmitirá hasta que reciba la confirmación del servidor.
  • En el protocolo TCP, cuando un determinado extremo está respondiendo a un conjunto de solicitudes, dentro de un cierto rango de tiempo, siempre que no reciba el paquete ACK de la respuesta, sin importar que la otra parte solicitada por sí mismo no lo haya recibido. , o la otra parte no lo ha recibido, se considera que se ha producido una pérdida de paquetes y se activa el mecanismo de retransmisión de tiempo de espera.
  • La retransmisión de SYN se intentará tres veces y los intervalos de tiempo son 5,8 s, 24 s, 48 ​​s
• Si el SYN + ACK enviado por el servidor al cliente se pierde y no llega:
  • El cliente piensa que el servidor no ha recibido lo que envió y continúa retransmitiendo periódicamente con un tiempo de espera.
  • El servidor cree que lo que ha enviado no se ha entregado y no ha recibido el ACK dentro del tiempo especificado, lo que provoca una retransmisión por tiempo de espera. Reenviará el paquete SYN + ACK después de esperar 3, 6 y 12 segundos.
• Si el ACK enviado por el cliente al servidor se pierde a la mitad y no llega al servidor. En este momento, el cliente cree que la conexión se ha establecido después de enviar el ACK e ingresa EXTABLISHED, pero el servidor todavía está en el estado SYN-RCVD porque no ha recibido el último paquete ACK.
  • Desde la perspectiva del servidor, el servidor pensará que el paquete SYN + ACK enviado por sí mismo se ha perdido y activará un mecanismo de retransmisión de tiempo de espera. **Si no ha tenido éxito, el servidor tendrá una configuración de tiempo de espera para la retransmisión de tiempo de espera, después del tiempo de espera, enviará un mensaje RTS al cliente y entrará en la etapa de CIERRE. **Esto se hace para evitar ataques de inundación SYN, momento en el que el cliente también debe cerrar la conexión.
    • Ataque de inundación SYN (ataque DoS): el atacante envía una gran cantidad de segmentos de mensajes TCP SYN sin completar el tercer protocolo de enlace. El servidor asigna recursos para una gran cantidad de conexiones semiabiertas, lo que eventualmente conduce al agotamiento de los recursos del servidor.
  • Si el servidor se encuentra en estado SYN-RCVD y recibe el paquete de datos efectivamente enviado por el cliente, considerará que se ha establecido la conexión y pasará al estado ESTABLECIDO. Cuando el cliente envía un paquete de datos en el estado ESTABLECIDO, llevará el número de secuencia de confirmación del ACK anterior, por lo que incluso si se pierde el paquete ACK respondido por el cliente, el servidor puede pasar el número de secuencia de confirmación del ACK en el paquete al recibir el paquete de datos Ingrese al estado ESTABLECIDO normalmente.

¿Por qué es tres veces dar la mano pero cuatro veces saludar?

• La razón por la que la conexión TCP solo necesita tres protocolos de enlace es: durante el segundo proceso de protocolo de enlace, el mensaje TCP enviado por el servidor al cliente utiliza SYN y ACK como indicadores SYN es un indicador de conexión de solicitud, lo que indica que el servidor acepta establecer una conexión; ACK Es un mensaje de confirmación, lo que significa decirle al cliente que el servidor ha recibido su mensaje de solicitud. El mensaje de establecimiento de conexión SYN y el mensaje de confirmación ACK se transmiten en el mismo protocolo de enlace, por lo que el protocolo de enlace de tres vías no es ni demasiado ni demasiado pequeño, solo para permitir que las dos partes se comuniquen entre sí.
• La razón por la que TCP necesita ondear cuatro veces al liberar la conexión es porque el mensaje de confirmación ACK y el mensaje de liberación de conexión FIN se transmiten en la segunda y tercera onda respectivamente. Esto se debe a que el servidor no puede liberar inmediatamente la conexión cuando recibe la solicitud de liberación de conexión del cliente, porque todavía hay datos necesarios para procesar, por lo que el servidor primero devuelve ACK para confirmar la recepción del mensaje y luego procesa los datos a través de CLOSE. -Etapa ESPERA Solo después de que la conexión esté lista para ser liberada, se puede devolver el mensaje de liberación de conexión FIN .

¿Por qué el cliente espera 2MSL en la fase TIME-WAIT?

Confirme si el servidor ha recibido el mensaje de confirmación ACK enviado por el cliente : cuando el cliente envía el mensaje de confirmación ACK final, no está seguro de que el servidor pueda recibir el mensaje. Por lo tanto, después de que el cliente envíe el mensaje de confirmación ACK, establecerá un temporizador con una duración de 2MSL. (MSL es el Maximum Segment Lifetime, el ciclo de vida máximo de un mensaje TCP durante la transmisión. 2MSL es el tiempo máximo que el mensaje FIN enviado por el servidor y el mensaje de confirmación ACK enviado por el cliente pueden permanecer válidos. 2MSL).

Debido a que el servidor no recibe el mensaje de confirmación ACK enviado por el cliente dentro de 1MSL, volverá a enviar un mensaje FIN al cliente.

• Si el cliente recibe el mensaje FIN del servidor nuevamente dentro de 2MSL, significa que el servidor no ha recibido el mensaje de confirmación ACK enviado por el cliente debido a varias razones, y el cliente envía un mensaje de confirmación ACK al servidor nuevamente. reiniciar el tiempo de 2MSL.
• Si el cliente no recibe el mensaje FIN del servidor dentro de 2MSL, significa que el servidor ha recibido el mensaje de confirmación ACK normalmente, y el cliente puede ingresar a la etapa CERRADO y completar cuatro manos agitadas.

** Deje que los paquetes TCP tardíos desaparezcan en la red. **Eso es para evitar que aparezca el segmento de solicitud de conexión no válida en esta conexión. Después de que el cliente envíe el último mensaje ACK, todos los segmentos de texto generados durante la duración de esta conexión pueden desaparecer de la red después de 2MSL, de modo que este mensaje antiguo no aparecerá en el siguiente segmento de solicitud de conexión nueva.

¿Qué tiene de malo la fase TIME-WAIT?

En un servidor TCP con muchas conexiones cortas simultáneas , cuando el servidor termine de procesar la solicitud, normalmente cerrará la conexión de forma activa y inmediata. En este escenario, una gran cantidad de sockets estarán en el estado TIME_WAIT. Si la simultaneidad del cliente continúa siendo alta, algunos clientes no podrán conectarse en este momento.

• La alta concurrencia permite que el servidor ocupe una gran cantidad de puertos al mismo tiempo en un corto período de tiempo , y los puertos van de 0 a 65535, que no son muchos, excluyendo los que usa el sistema y otros servicios, hay incluso quedan menos puertos.
• En este escenario, una conexión corta significa una conexión en la que "el tiempo de procesamiento comercial + transmisión de datos es mucho más corto que el tiempo de espera TIME-WAIT" .

¿Mecanismo de mantenimiento de TCP?

El mecanismo keep-alive es para juzgar si la otra parte está en línea o no. TCP no puede detectar conexiones desconectadas anormalmente. No existe una función keep-alive para las conexiones especificadas en la especificación TCP.

Implementación del mecanismo de mantenimiento de conexión TCP: a través del temporizador de mantenimiento de conexión, cuando se activa el temporizador, un extremo de la conexión enviará un mensaje de detección de mantenimiento de conexión y el otro extremo enviará un ACK como respuesta al recibir el mensaje. .

• tcp_keepalice_time: 7200, mantener vivo el tiempo, por defecto 7200s
• tcp_keepalice_intvl: 75, intervalo de mantenimiento activo, predeterminado 75 s
• tcp_keepalice_probes: 9, el número de sondas de mantenimiento, el valor predeterminado es 9 veces

El proceso del mecanismo keep-alive: el final de la conexión que activa la función keep-alive, y la conexión está inactiva dentro del tiempo de keep-alive, envía un mensaje de detección de keep-alive a la otra parte y restablece el keep-alive -Temporizador de actividad si se recibe una respuesta. Si no se recibe un mensaje de respuesta, envíe un mensaje de detección de actividad a la otra parte nuevamente después de un intervalo de tiempo de actividad. Si no se ha recibido el mensaje de respuesta, continúe hasta que se cumpla el número de el tiempo de envío alcanza el número de sondas de mantenimiento de actividad. En este momento, el otro host se confirmará como inalcanzable y la conexión se interrumpirá.

La diferencia y los escenarios de aplicación de TCP y UDP

Tanto TCP como UDP son protocolos de capa de transporte.

**Protocolo de datagramas de usuario UDP (Protocolo de datagramas de usuario) no tiene conexión, se entrega tanto como sea posible, sin control de flujo ni control de congestión, orientado a mensajes, admite uno a uno, uno a muchos, muchos a uno y Comunicación interactiva de muchos a muchos. **UDP no puede realizar control de flujo, control de congestión y otros métodos para evitar la congestión de la red cuando la red está congestionada. Además, si hay pérdida de paquetes durante la transmisión, UDP no es responsable de la retransmisión, incluso si el orden de llegada de los paquetes está fuera de orden, no hay función de corrección. Si necesita controlar estos comportamientos, debe entregarlo a la aplicación que implementa UDP para que lo maneje usted mismo. UDP solo proporciona las funciones básicas como un protocolo de capa de transporte.

Escenarios de aplicación UDP: la eficiencia es la prioridad y se requiere que la velocidad de comunicación de la red sea lo más rápida posible, pero la precisión no es muy alta y la calidad de la comunicación de la red no es alta. Por ejemplo: chat QQ, video en línea, VoIP (mensajería instantánea, requisitos de alta velocidad, pero la interrupción ocasional no es un gran problema y el mecanismo de retransmisión es completamente innecesario) y la transmisión, etc.

---

El protocolo de control de transmisión TCP (Protocolo de control de transmisión) está orientado a la conexión, proporciona una entrega confiable, tiene control de flujo y control de congestión, proporciona comunicación full-duplex y está orientado a flujos de bytes (los paquetes transmitidos desde la capa de aplicación se consideran como flujos de bytes, Organizar flujos de bytes en bloques de datos de tamaño desigual) . Cada conexión TCP solo puede ser punto a punto (uno a uno). TCP realiza varias funciones de control durante la transmisión de datos, puede realizar el control de retransmisión de paquetes perdidos y también puede realizar el control de secuencia en subpaquetes cuyo orden es fuera de servicio. Y esto es lo que UDP no tiene. Además, como protocolo orientado a la conexión, TCP envía datos solo cuando se confirma la existencia del par de comunicación , de modo que se puede controlar el desperdicio de tráfico de comunicación. TCP realiza una transmisión confiable a través de mecanismos como suma de verificación, número de secuencia y respuesta de confirmación, control de retransmisión, administración de conexión y control de ventana.

Escenarios de aplicación TCP: Escenarios que no requieren alta eficiencia pero sí alta precisión. Debido a que se requieren operaciones como la confirmación, retransmisión y clasificación de datos durante la transmisión, la eficiencia no es tan alta como UDP, como: transferencia de archivos, envío y recepción de correo electrónico. TCP se usa a menudo en algunas aplicaciones confiables, como HTTP, HTTPS, FTP (Protocolo de transferencia de archivos) y SMTP (Protocolo de transferencia de correo)

¿Cómo garantiza TCP una transmisión fiable?

TCP garantiza principalmente la confiabilidad a través de los siguientes métodos: ** suma de verificación, número de secuencia y respuesta de confirmación, retransmisión de tiempo de espera, administración de conexión, control de flujo y control de congestión. ** Entre ellos, los tres primeros pertenecen al control de errores.

• Suma de verificación: en el proceso de transmisión de datos, el segmento de datos enviado se trata como un número entero de 16 bits. Suma estos números enteros. Y el acarreo anterior no se puede descartar, el complemento se agrega después, y finalmente el checksum se obtiene invirtiendo.

Remitente: calcule la suma de verificación y complete la suma de verificación antes de enviar los datos.

Receptor: después de recibir los datos, calcule los datos de la misma manera y compare la suma de verificación con la del remitente.

​ Si la suma de verificación del receptor es inconsistente con la del remitente, los datos deben haberse transmitido incorrectamente. Sin embargo, la coherencia no significa que los datos deban transmitirse correctamente.

• Número de serie y respuesta de confirmación

  • Número de serie: cada byte de datos se numera durante la transmisión TCP, que es el número de serie.
    • El número de serie garantiza la confiabilidad (cuando los datos recibidos carecen de datos de un determinado número de serie, se puede detectar de inmediato)
    • Llegada de datos garantizada en secuencia de tiempo
    • Mejore la eficiencia, realice el envío de una confirmación varias veces y elimine los datos duplicados
  • Respuesta de reconocimiento: Durante el proceso de transmisión TCP, cada vez que el receptor recibe datos, dará una respuesta de reconocimiento al transmisor, es decir, enviará un mensaje ACK. El receptor confirmará los datos que llegan en orden, y cuando el bit de bandera ACK=1, confirmará que el campo de confirmación del encabezado es válido. Al confirmar, el valor del campo de confirmación indica que los datos anteriores a este valor han llegado en orden. Si el remitente recibe el mensaje de confirmación de los datos enviados, continuará transmitiendo la siguiente parte de los datos; y si no ha recibido el mensaje de confirmación después de esperar un cierto período de tiempo, iniciará el mecanismo de retransmisión.

• retransmisión de tiempo de espera

  • Cuando se envía el mensaje y el reconocimiento del receptor no se recibe dentro de un cierto período de tiempo, el remitente lo retransmitirá (por lo general, configura un reloj de alarma después de enviar el segmento del mensaje y retransmite si no se recibe respuesta cuando llegue el momento). pasar).

  • Dos casos: pérdida de paquetes de datos o pérdida de paquetes de reconocimiento

    

• Gestión de conexiones: protocolo de enlace de tres vías y protocolo de enlace de cuatro vías cuando se establece TCP

• Control de flujo: cuando el receptor no tiene tiempo para procesar los datos del remitente, puede solicitar al remitente que reduzca la velocidad de envío para evitar la pérdida de paquetes .

  • Causa: La velocidad a la que el receptor puede procesar datos es limitada. Si el remitente envía datos demasiado rápido, el búfer del receptor está lleno y el remitente continúa enviando, lo que provocará la pérdida de paquetes, lo que a su vez provocará una serie de pérdida de paquetes y retransmisión reacción en cadena.
  • Es un problema de punta a punta.

• Control de congestión: Reduzca la transmisión de datos cuando la red está congestionada.

  • Causa: si la red está muy congestionada, el envío de datos en este momento aumentará la carga de la red. Tal vez los datos enviados por el remitente excedan el tiempo de vida máximo y no lleguen al receptor, lo que provocará la pérdida de paquetes. Para introducir el mecanismo de inicio lento de TCP, primero se envía una pequeña cantidad de datos, similar a la búsqueda de rutas, y después de averiguar el estado actual de congestión de la red, se decide qué tan rápido transmitir los datos.
  • Evitar la inyección excesiva de datos en la red es un problema global.

Ventana deslizante en TCP (control de flujo)

Introducción

TCP es un protocolo dúplex, ambas partes en la conversación pueden recibir y enviar datos al mismo tiempo. Ambas partes de una sesión TCP mantienen una ventana de envío y una ventana de recepción . El tamaño de la ventana de recepción respectiva depende de las limitaciones de la aplicación, el sistema y el hardware (la tasa de transmisión TCP no puede ser mayor que la tasa de procesamiento de datos de la aplicación). Los requisitos de la ventana de envío respectiva dependen de la ventana de recepción notificada por el par, y los requisitos son los mismos.

La ventana deslizante resuelve el problema del control de flujo: si el extremo receptor y el extremo emisor procesan paquetes de datos a diferentes velocidades, ¿cómo hacer que las dos partes lleguen a un acuerdo ? Los datos almacenados en el extremo receptor se transmiten a la capa de aplicación, pero este proceso no es oportuno. Si la velocidad de envío es demasiado rápida, se producirá un desbordamiento de datos en el extremo receptor.

concepto de ventana

Los datos en el búfer de envío del remitente se pueden dividir en 4 categorías:

• 1. ACK enviado y recibido
• 2. ACK enviado pero no recibido
• 3. No enviado pero permitido enviar
• 4. No enviado pero no permitido enviar
• Tanto el 2 como el 3 pertenecen a la ventana de envío.

Los datos en caché del receptor se dividen en 3 categorías:

• 1. Recibido
• 2. No recibido pero listo para recibir
• 3. No recibido y no listo para recibir
• 2 de ellos pertenecen a la ventana de recepción

El tamaño de la ventana representa la cantidad de datos que el dispositivo puede procesar del par a la vez y luego pasarlos a la capa de aplicación. Los datos almacenados en caché y pasados ​​a la capa de aplicación no pueden estar desordenados, y el mecanismo de ventana lo garantiza.

mecanismo deslizante

• La ventana de envío solo moverá el límite izquierdo de la ventana de envío cuando se reciba la confirmación ACK de los bytes en la ventana de envío.
• La ventana de recepción solo se moverá al límite izquierdo si se reconocen todos los segmentos anteriores. Cuando no se reciben los bytes anteriores pero se reciben los bytes siguientes, la ventana no se moverá y no confirmará los bytes subsiguientes para garantizar que el extremo del par retransmita los datos.

Análisis en profundidad

• La conexión TCP se implementa a través de paquetes de datos y ACKs. Como tercero, podemos ver el proceso de envío de paquetes por ambas partes, pero el receptor no sabe qué envió el remitente antes de recibirlo, y el remitente no sabe qué envió el remitente. enviado antes de recibir el ACK. Saber si la otra parte lo recibe con éxito.
• El remitente no puede deslizar el dedo hacia la derecha sin recibir el ACK del receptor. Si el remitente envía ABCD, mientras el receptor no reciba A, no puede deslizarse, por lo que los dos no estarán desincronizados.
• El tamaño de la ventana no puede ser mayor que la mitad del espacio del número de serie, el propósito es evitar que las dos ventanas se superpongan. Por ejemplo, el tamaño total es 7 y el tamaño de cada ventana es 4. La ventana de recepción debe deslizarse por 4, pero solo quedan 3 números de secuencia.
• El remitente envía cuatro datos ABCD, y el receptor se desliza hacia la derecha después de recibir todos los datos, pero todos los paquetes ACK de respuesta se pierden, el remitente no recibe ningún ACK y ABCD se reenviará después del tiempo de espera, en este momento, el el receptor presiona la confirmación acumulada En principio, después de recibir ABCD, solo se reenviará el ACK de D, y el remitente se deslizará directamente después de recibirlo.

presentación dinámica

Primero, el extremo emisor envía cuatro paquetes de ABCD, pero AB se pierde y solo CD llega al extremo receptor.

El extremo receptor no recibe A, por lo que no responde el paquete ACK. El remitente retransmite ABCD, y todos llegan esta vez.

El extremo receptor obtiene A primero, envía el paquete ACK de A, pero lo pierde a la mitad; después de obtener B, de acuerdo con el principio de confirmación acumulativa, envía el paquete ACK de D, y luego la ventana del extremo receptor se desliza 4 bits. Después de obtener el CD nuevamente, responda dos paquetes ACK de D en sucesión.

El extremo emisor recibe el paquete ACK de D, lo que indica que la otra parte ha recibido los 4 paquetes, y la ventana del extremo emisor se desliza 4 bits. Se envían paquetes EFGH, donde se pierden paquetes G. Ahora el estado de toda la secuencia es: se ha enviado ABCD, se ha enviado EFGH pero no se ha confirmado y no se puede enviar IS.

El extremo receptor recibe E primero y envía un paquete ACK de E. Luego recibió F, envió F. De acuerdo con el principio de confirmación acumulativa: si no recibe G, aún envía F; si recibe H, aún envía F. Desafortunadamente, los paquetes ACK de las tres F se pierden.

El remitente recibe el paquete ACK de E, desplaza la ventana de envío un bit a la derecha y luego envía FGHI, donde F se pierde.

El extremo receptor obtiene I primero, pero no hay G, por lo que primero tiene que enviar el paquete ACK de F. Luego recibió paquetes de GH uno tras otro.

De acuerdo con la confirmación acumulativa, el extremo receptor envía dos paquetes I en sucesión, entre los cuales H corresponde a la pérdida. La ventana de recepción se desliza 4 bits hacia la derecha.

El remitente recibe el paquete ACK de I, desliza 4 bits hacia la derecha y no lo analizará más tarde.

Explicación detallada del control de congestión de TCP

Introducción

El control de congestión es para evitar la inyección excesiva de datos en la red, de modo que los enrutadores o enlaces en la red no se sobrecarguen. El control de la congestión tiene una premisa: la red puede soportar la carga de la red existente. El control de congestión es un proceso global que involucra a todos los hosts, enrutadores y todos los factores relacionados con la reducción del rendimiento de transmisión de la red.

En general, existen cuatro métodos para su realización: inicio lento (slow-start), evitación de congestión (congestion Avoidance), retransmisión rápida (retransmisión rápida) y recuperación rápida (recuperación rápida)

El remitente mantiene una variable de estado de la ventana de congestión cwnd. El tamaño de la ventana de congestión depende del grado de congestión de la red y cambia dinámicamente. El remitente hace que el tamaño de su ventana de envío sea igual al tamaño de la ventana de congestión. El principio para que el remitente controle la ventana de congestión es: mientras no haya congestión en la red, la ventana de congestión se ampliará para enviar más paquetes; si la red correspondiente está congestionada, la ventana de congestión será más pequeña para reducir la inyección en la red número de grupos.

Comienzo lento: crecer cwnd exponencialmente

• Cuando el host comienza a enviar datos, si se inyecta una gran cantidad de bytes de datos en la red inmediatamente, puede causar congestión en la red, porque no está claro qué tan cargada está la red. Por lo tanto, la mejor manera es enviar primero una pequeña porción de datos y detectarla primero, y aumentar gradualmente la ventana de envío de pequeña a grande. Por lo general, al comienzo del envío de un segmento de mensaje, primero establezca la ventana de congestión cwnd en un valor de MSS (máximo). Después de un reconocimiento para un nuevo segmento, aumente la ventana de congestión en un valor de MSS como máximo. El uso de este método para aumentar gradualmente la ventana de congestión cwnd del remitente puede hacer que la velocidad a la que se inyectan paquetes en la red sea más razonable.

  

  Cada vez que pasa una ronda, el cwnd de la ventana de congestión se duplica. El tiempo transcurrido en una ronda de transmisión es el tiempo de ida y vuelta RTT . Sin embargo, la ronda de transmisión enfatiza: los segmentos de mensaje permitidos por la ventana de congestión cwnd se envían continuamente y se ha recibido la confirmación del último byte enviado.

  El inicio lento no significa que la tasa de crecimiento de cwnd sea lenta, sino que cwnd = 1 cuando TCP comienza a enviar segmentos , por lo que el remitente solo envía un segmento al principio (el propósito es probar la congestión de la red), y luego Luego aumente gradualmente cwnd.

  Para evitar la congestión de la red provocada por un crecimiento excesivo de cwnd, también es necesario establecer una variable de estado ssthresh de umbral de inicio lento.

  • Cuando cwnd < ssthresh, se utiliza el algoritmo de inicio lento descrito anteriormente.
  • Cuando cwnd > ssthresh, deje de usar el algoritmo de inicio lento y use el algoritmo para evitar la congestión en su lugar.
  • Cuando cwnd = ssthresh, se puede usar el algoritmo de inicio lento o el algoritmo para evitar la congestión.

Algoritmo para evitar la congestión: de exponencial a lineal

• Deje que la ventana de congestión aumente lentamente, es decir, aumente la ventana de congestión cwnd del remitente en 1 cada vez que pase un tiempo de ida y vuelta RTT, en lugar de duplicarse, de modo que la ventana de congestión cwnd crezca lineal y lentamente, lo que es más lento que el crecimiento exponencial el ritmo del comienzo lento muchos.
• Independientemente de si se encuentra en la fase de inicio lento o en la fase de prevención de congestión, siempre que el remitente juzgue que la red está congestionada (la base es que el remitente no ha recibido un acuse de recibo ), el umbral de inicio lento ssthresh debe establecerse en la mitad del valor de la ventana del remitente cuando se produce una congestión (pero no menos de 2). Luego restablezca la ventana de congestión cwnd a 1 y ejecute el algoritmo de inicio lento. El propósito de hacer esto es reducir rápidamente la cantidad de paquetes enviados por el host a la red, de modo que el enrutador congestionado tenga tiempo suficiente para procesar la acumulación de paquetes en la cola.

retransmisión rápida

• Si el temporizador de tiempo de espera establecido por el remitente ha expirado pero no se ha recibido ningún reconocimiento, es probable que la red esté congestionada, lo que hace que el segmento se descarte en algún lugar de la red. En este momento, TCP reduce inmediatamente la ventana de congestión cwnd a 1, ejecuta el algoritmo de inicio lento y, al mismo tiempo, reduce a la mitad el umbral de inicio lento ssthresh. Este es el caso sin retransmisión rápida.

• El algoritmo de retransmisión rápida primero requiere que el receptor envíe una confirmación repetida inmediatamente cada vez que recibe un mensaje fuera de secuencia (para que el remitente sepa con anticipación que un segmento de mensaje no ha llegado a la otra parte), en lugar de esperar los datos para ser enviados por sí mismo y luego llevar la confirmación. Una vez que el remitente recibe tres acuses de recibo duplicados en sucesión, debe retransmitir inmediatamente el segmento de mensaje anterior que la otra parte no ha recibido, en lugar de esperar a que expire el temporizador de retransmisión establecido por el segmento de mensaje.

  

  Después de recibir M1 y M2, la parte receptora envió acuses de recibo respectivamente. Ahora suponga que la parte receptora no recibió M3 pero luego recibió M4. Obviamente, el receptor no puede confirmar M4. M4 es un segmento de mensaje fuera de secuencia. De acuerdo con el principio de transmisión confiable, el receptor no puede hacer nada o enviar un reconocimiento de M2 ​​en el momento adecuado. Pero el algoritmo de retransmisión rápida estipula: **El receptor debe enviar una confirmación repetida de M2 ​​a tiempo, para que el remitente pueda saber que el M3 que envió no ha llegado al receptor. **Debido a que el remitente retransmite los segmentos no reconocidos lo antes posible, el rendimiento de toda la red se puede aumentar en aproximadamente un 20 % después de adoptar la retransmisión rápida.

rápida recuperación

• Junto con la retransmisión rápida, también existe un algoritmo de recuperación rápida, cuyo proceso principal es:

  • Cuando el remitente recibe tres reconocimientos repetidos seguidos, ejecuta el algoritmo de reducción de multiplicación para reducir a la mitad el umbral de inicio lento ssthresh. Esto es para evitar la congestión de la red.
  • Dado que el remitente ahora piensa que la red probablemente no esté congestionada, la diferencia con el inicio lento es que el algoritmo de inicio lento no se ejecuta ahora (cwnd no está establecido en 1), pero cwnd está establecido en el mismo valor que el inicio lento actual umbral ssthresh, y ejecute el algoritmo para evitar la congestión (aumento aditivo), de modo que la ventana de congestión aumente lenta y linealmente.

• Algunas implementaciones de recuperación rápida aumentan el valor de la ventana de congestión cwnd al principio, que es igual a ssthresh + 3 X MSS. La razón de esto es que dado que el remitente ha recibido tres reconocimientos duplicados, indica que tres paquetes han salido de la red. Estos tres paquetes ya no consumen recursos de la red sino que se quedan en el buffer del receptor Se puede ver que la red no acumula paquetes sino que reduce tres paquetes. Por lo tanto, la ventana de congestión se puede ampliar adecuadamente.

• Cuando se usa el algoritmo de recuperación rápida, el algoritmo de inicio lento solo se usa cuando se establece la conexión TCP y se agota el tiempo de espera de la red. La adopción de un método de control de congestión de este tipo mejora significativamente el rendimiento de TCP.

• El receptor establece la ventana de recepción rwnd de acuerdo con su propia capacidad de recepción, escribe el valor de la ventana en el campo de la ventana en el encabezado TCP y lo envía al remitente. Por lo tanto, la ventana de recepción también se denomina ventana de notificación. Por lo tanto, desde la perspectiva del control de flujo del receptor sobre el emisor, la ventana de envío del emisor no debe exceder la ventana de recepción rwnd dada por la otra parte.

  • Límite superior de la ventana del remitente = Min [rwnd, cwnd]
  • Cuando rwnd < cwnd, la capacidad de recepción del receptor limita el valor máximo de la ventana del remitente.
  • Cuando cwnd < rwnd, es el valor máximo de la ventana de envío limitada por congestión de la red.

Problema de desempaquetado del paquete adhesivo TCP

origen

TCP es un protocolo orientado a flujo de bytes, que es una cadena de datos sin límites. La capa inferior de TCP no comprende el significado específico de los datos comerciales de la capa superior, dividirá los paquetes de acuerdo con la situación real del búfer TCP, por lo que, en términos comerciales, TCP puede dividir un paquete completo en varios paquetes. para la transmisión, y también hay Es posible encapsular múltiples paquetes pequeños en un paquete de datos grande y enviarlo.Este es el problema de TCP desempaquetar y pegar paquetes.

escena

Suponiendo que el cliente envía dos paquetes de datos D1 y D2 al servidor respectivamente, dado que la cantidad de bytes leídos por el servidor a la vez es incierta, puede haber las siguientes cinco situaciones:

• El servidor lee dos paquetes de datos independientes dos veces, que son D1 y D2 respectivamente, y no se pegan ni se desempaquetan.
• El servidor recibe dos paquetes de datos a la vez, y D1 y D2 están pegados, lo que se denomina paquete adhesivo TCP.
• El servidor lee dos paquetes de datos dos veces, la primera vez lee el paquete D1 completo y parte de D2, y la segunda vez lee el contenido restante del paquete D2, lo que se denomina desempaquetado de TCP.
• El servidor lee dos paquetes de datos dos veces, la primera vez lee parte del contenido del paquete D1 y la segunda vez lee el contenido restante del paquete D1 y todo el contenido del paquete D2.
• Si la ventana de recepción de TCP del servidor es muy pequeña, el servidor puede recibir los paquetes D1 y D2 varias veces y puede ocurrir un desempaquetado múltiple.

Causa de

• Los datos que se enviarán son más pequeños que el tamaño del búfer de envío de TCP, y TCP enviará los datos que se han escrito en el búfer varias veces a la vez, y se producirán paquetes adhesivos.
• Si los datos a enviar son más grandes que el espacio restante del búfer de envío de TCP, se producirá el desempaquetado.
• Si los datos a enviar son más grandes que MSS (tamaño máximo de mensaje), TCP los desempaquetará antes de la transmisión. La longitud del paquete TCP debe estar garantizada: la longitud del encabezado TCP> MSS

Paquete pegajoso y solución para desempacar

Dado que TCP no puede comprender los datos comerciales de la capa superior, la solución solo se puede resolver desde la pila de protocolos de aplicación de la capa superior.De acuerdo con la solución del protocolo principal en la industria:

• Longitud fija del mensaje : el remitente encapsula cada paquete de datos en una longitud fija (no suficiente para complementar con 0), de modo que cada vez que el receptor lee datos de una longitud fija en el búfer de recepción, dividirá naturalmente cada paquete de datos.
• Establezca el límite del mensaje : el servidor separa el contenido del mensaje del flujo de red de acuerdo con el límite del mensaje y agrega un carácter de retorno de carro y avance de línea al final del paquete para la segmentación, como el protocolo FTP.
• Divida el mensaje en un encabezado de mensaje y un cuerpo de mensaje : el encabezado del mensaje contiene la información de longitud total del mensaje. Al enviar cada dato, la longitud de los datos se envía juntos. Por ejemplo, los primeros 4 bits de los datos se especifican como la longitud de los datos, y la capa de aplicación se está procesando. En este momento, las posiciones de inicio y final de cada paquete se pueden juzgar de acuerdo con la longitud.

¿UDP tiene el problema de los paquetes pegajosos?

Para garantizar una transmisión confiable y reducir la sobrecarga adicional (se requiere verificación cada vez que se envía un paquete), TCP adopta la transmisión basada en flujo de bytes. La transmisión basada en flujo no considera que un mensaje sea una pieza, sino un límite de mensaje desprotegido ( límite de mensaje protegido: se refiere al protocolo de transmisión que transmite datos como un mensaje independiente en Internet, y el extremo receptor solo puede aceptar un mensaje independiente a la vez).

UDP está orientado a mensajes y tiene un límite de protección. El receptor solo acepta un mensaje independiente a la vez y no hay problema con los paquetes pegajosos.

protocolo IP

El protocolo IP (Protocolo de Internet, Protocolo de Internet) es un protocolo de capa de red en TCP/IP. El propósito de la aparición es mejorar la escalabilidad de la red y realizar la interconexión e intercomunicación de redes heterogéneas y de gran escala. De acuerdo con el principio de diseño de extremo a extremo, IP solo proporciona un servicio de transmisión de paquetes de datos sin conexión, poco confiable y de mejor esfuerzo para el host.

Reglas de reenvío para paquetes IP: cuando un enrutador reenvía un paquete IP, si la red de destino está directamente conectada al enrutador local, el paquete se entrega directamente al host de destino, lo que se denomina entrega directa; de lo contrario, el enrutador busca la información de enrutamiento a través de la tabla de enrutamiento y envía El paquete se reenvía al enrutador de siguiente salto especificado, lo que se denomina entrega indirecta. En la entrega indirecta, si hay una ruta a la red de destino en la tabla de enrutamiento, el enrutador envía el paquete de datos al enrutador del siguiente salto especificado en la tabla de enrutamiento; si no hay ruta, pero hay una ruta predeterminada en la tabla de enrutamiento. tabla de enrutamiento, el paquete de datos se envía al enrutador predeterminado indicado; si ninguno está presente, el paquete se descarta y se informa un error.

Cinco tipos de direcciones IP

Dirección de tipo A: el primer byte comienza con 0, los 7 bits restantes son la dirección de red y los últimos 3 bytes son la dirección del host. La dirección inicial es 1-126 y el rango es 1.0.0.1-126.225.255.254 La clase A está reservada para agencias gubernamentales.

• 10.0.0.0 a 10.255.255.255 son direcciones privadas (no utilizadas en Internet, direcciones utilizadas en la red de área local)
• 127.XXX es una dirección reservada para pruebas de bucle

Dirección de clase B: el primer byte comienza con 10, los primeros 2 bytes son la dirección de red y los últimos 2 bytes son la dirección del host. La dirección inicial es 128-191 y el rango es 128.0.0.1—191.255.255.254 La clase B se asigna a empresas medianas.

• 172.16.0.0—172.31.255.255 es una dirección privada
• 169.254.XX es una dirección reservada. Si su dirección IP se obtiene automáticamente, pero no ha encontrado un servidor DHCP disponible en la red. Se obtendrá una de las IP.
• 191.255.255.255 es la dirección de transmisión y no se utiliza para la asignación.

Dirección de clase C: el 1.er byte, el 2.º byte y el 3.er byte de una dirección de clase C son la dirección de red y el 4.º byte es la dirección del host. Además, los tres primeros dígitos del primer byte se fijan en 110. Intervalo de direcciones de clase C: 192.0.0.1—223.255.255.254 . 192.168.XX en direcciones Clase C es una dirección privada. Las direcciones de clase C son para uso personal.

Dirección de clase D: la dirección de clase D no distingue entre la dirección de red y la dirección de host, y los primeros cuatro dígitos de su primer byte se fijan en 1110. Intervalo de direcciones de clase D: 224.0.0.1—239.255.255.254 . Generalmente se utiliza para multidifusión.

Dirección de clase E: no distingue entre dirección de red y dirección de host, y los primeros cinco dígitos de su primer byte se fijan en 11110. Intervalo de direcciones de clase E: 240.0.0.1—255.255.255.254 . Generalmente se utiliza para experimentos.

Configuración de parámetros IP de la computadora

Dirección IP: cualquiera de 192.168.1.2-254 es aceptable

Máscara de subred: 255.255.255.0

• Se usa para proteger una parte de la dirección IP para distinguir entre el identificador de red y el host, y para indicar si la dirección IP está en una red de área local o en una red remota; se usa para dividir una red IP grande en varias pequeñas subredes.
• El uso de subredes es para reducir el despilfarro de IP. Con el desarrollo de Internet, se generan cada vez más redes. Algunas redes tienen tanto como cientos de redes, y tan solo unas pocas. Esto desperdiciará una gran cantidad de Direcciones IP, por lo que es necesario dividir la subred, el uso de la subred puede mejorar la eficiencia de las aplicaciones de red.

Puerta de enlace predeterminada: 192.168.1.1

• La puerta de enlace predeterminada es un dispositivo que conecta la subred a la red externa, generalmente un enrutador.Cuando una computadora envía información, determina si el host de destino está en la subred local a través de la máscara de subred de acuerdo con la dirección de destino de la información enviada. Si el destino Si el host está en la subred local, se puede enviar directamente. Si el destino no está en la subred local, la información se enviará a la puerta de enlace/enrutador predeterminado y el enrutador la reenviará a otras redes para buscar más a fondo el host de destino.

DNS o DNS común regional

protocolo ARP

**ARP significa Protocolo de resolución de direcciones. En el entorno Ethernet, la transmisión de datos depende de la dirección MAC en lugar de la dirección IP, y el protocolo ARP completa el trabajo de convertir la dirección IP conocida en la dirección MAC. **En la LAN, lo que realmente se transmite en la red es una trama, y ​​la trama contiene la dirección MAC del host de destino. En Ethernet, un host se comunica directamente con otro host y debe conocer la dirección MAC del host de destino.

Cada vez que un host tiene un datagrama IP para enviar a otro host, necesita conocer la dirección lógica (IP) del destinatario. Pero la dirección IP debe estar encapsulada en un marco para pasar a través de la red física . Esto significa que el remitente debe tener la dirección física (MAC) del destinatario, por lo que se debe realizar una asignación de dirección lógica a física. El protocolo ARP puede aceptar la dirección lógica del protocolo IP, asignarla a la dirección física correspondiente y luego enviar la dirección física a la capa de enlace de datos.

Método de mapeo ARP

mapeo estático

Cree manualmente una tabla ARP que asocie direcciones lógicas (IP) con direcciones físicas. Esta tabla ARP se almacena en cada máquina de la red. Por ejemplo, una máquina que conoce la dirección IP de su máquina pero no conoce su dirección física puede averiguar la dirección física correspondiente consultando la tabla ARP.

Hacerlo tiene ciertas limitaciones:

• Es posible que la máquina haya cambiado las NIC (adaptadores de red), lo que resultó en una nueva dirección física.
• En algunas redes de área local, cada vez que se enciende la computadora, su dirección física cambiará una vez.
• Las computadoras móviles se pueden mover de una red física a otra, provocando un cambio en la dirección física.

Para evitar estas situaciones, la tabla ARP debe mantenerse y actualizarse regularmente, lo que es muy problemático y afectará el rendimiento de la red.

mapeo dinámico

Cada vez que una máquina conoce la dirección lógica (IP) de otra máquina, puede utilizar el protocolo para averiguar la dirección física correspondiente. ARP implementa la asignación de direcciones lógicas a direcciones físicas y RARP implementa la asignación de direcciones físicas a direcciones lógicas.

proceso ARP

Solicitud ARP: cuando un host necesita averiguar la dirección física de otro host en la red, puede enviar un mensaje de solicitud ARP, que incluye la dirección MAC y la dirección IP del remitente y la dirección IP del receptor. Debido a que el remitente no conoce la dirección de recepción del receptor, esta consulta se transmite en la capa de red.

Respuesta ARP: cada host en la LAN aceptará y procesará el mensaje de solicitud ARP y luego verificará si la dirección IP del receptor es su propia dirección. Solo el host que haya verificado con éxito devolverá un mensaje de respuesta ARP. Este mensaje de respuesta contiene la dirección IP y la dirección física del destinatario. Este mensaje se envía directamente al solicitante del mensaje de solicitud de ARP en forma de unidifusión utilizando la dirección física del solicitante en el mensaje de solicitud de ARP recibido.

Extensión: cookie y sesión

cookie: Una pequeña porción de información de texto.El servidor no puede conocer la identidad del cliente solo a partir de la conexión de red, por lo que el servidor emite un pase al cliente. Cada vez que visite, debe traer su propio pase, para que el servidor pueda confirmar la identidad del cliente del pase. El servidor también puede modificar el contenido de la cookie según sea necesario.

session: session es un mecanismo utilizado por el servidor para registrar el estado del cliente.Es más simple de usar que las cookies y, en consecuencia, aumenta la presión de almacenamiento en el servidor. Se crea automáticamente cuando el usuario accede al servidor por primera vez (no se generarán recursos estáticos como el acceso puro a HTML e IMAGE).Si no se genera, puede usar request.getSession(true) para forzar la generación de la sesión Después de que se genera la sesión, siempre que el usuario continúe visitando, el servidor actualizará la última hora de acceso de la sesión y mantendrá la sesión. La sesión se destruirá de forma predeterminada si no se usa durante 30 minutos, y el tiempo se puede configurar a través de setMaxInactiveInterval.

¿Por qué debería haber una sesión?

Dado que el protocolo HTTP no tiene estado, el cliente envía una solicitud al servidor y luego el servidor devuelve una respuesta correspondiente, y luego la conexión se cerrará y no habrá relación entre los dos, es decir, el servidor no almacenará esta vez Para la información relevante solicitada, el servidor no puede saber si esta solicitud y la última solicitud son el mismo cliente cuando se realiza la solicitud nuevamente. Entonces necesitamos usar la sesión para registrar la información de esta conexión.

Cuando un cliente accede al servidor, puede actualizar continuamente entre varias páginas del servidor, conectarse repetidamente a la misma página o enviar información a una página. Con el registro de sesión, el servidor puede saber que este es el mismo cliente en el servidor. Complete estas acciones.

La diferencia entre cookie y sesión.

• La ubicación de almacenamiento es diferente:
  • La información de datos de la cookie se almacena en el navegador del cliente, y no es seguro que otros analicen la cookie local y la engañen.
  • La información de los datos de la sesión se almacena en el servidor, que es invisible para el cliente, y no hay riesgo de fuga de información confidencial.
• El ciclo de vida es diferente:
  • El ciclo de vida de una sesión es que el navegador se cierra y la sesión desaparece tan pronto como se cierra.
  • La cookie tiene un ciclo de vida preestablecido, o se retiene permanentemente en el archivo local.
• La capacidad de almacenamiento varía:
  • Los datos guardados por una sola cookie <= 4KB, y un sitio puede guardar hasta 20 cookies
  • No hay un límite superior para la sesión, pero por el bien del rendimiento del lado del servidor, no almacene demasiadas cosas en la sesión y configure el mecanismo de eliminación de la sesión.
• Almacenado de manera diferente:
  • Solo las cadenas ASCII se pueden guardar en cookies y deben codificarse como caracteres Unicode o datos binarios
  • Se puede almacenar cualquier tipo de datos en la sesión, incluidos, entre otros, cadenas, enteros, listas, mapas, etc.
• El período de validez es diferente:
  • Las propiedades de la cookie se pueden configurar a través del código para lograr el efecto de hacer que la cookie sea efectiva durante mucho tiempo.
  • La sesión se basa en la cookie de JSESSIONID, y el tiempo de caducidad de la cookie JSESSIONID es de forma predeterminada - 1. Mientras la ventana esté cerrada, la sesión no será válida, por lo que la sesión no puede lograr resultados efectivos a largo plazo.
• La presión del servidor es diferente:

  • Las cookies se almacenan en el lado del cliente y no ocupan recursos del servidor. Para sitios web con muchos usuarios simultáneos, las cookies son una buena opción.

  • La sesión se almacena en el lado del servidor y cada usuario generará una sesión. Si hay muchos usuarios accediendo al mismo tiempo, se generarán muchas sesiones y se consumirá mucha memoria.

idempotencia

**Idempotencia: significa que los resultados de una o varias solicitudes iniciadas por el usuario para la misma operación son coherentes y no habrá efectos secundarios debido a los múltiples clics. **En las cuatro operaciones de agregar, borrar, modificar y revisar, prestar especial atención a agregar o modificar . El resultado de la consulta no cambiará, y la eliminación solo se realizará una vez. El resultado de múltiples clics por parte del usuario es el mismo, y el resultado de la modificación es el mismo en la mayoría de los escenarios, el aumento aparecerá en el escenario de presentación repetida. Para los métodos de solicitud HTTP comunes, GET, PUT y DELETE son todos idempotentes, mientras que POST no lo es.

Comprender: flujo de trabajo del protocolo TCP/IP

• En el host de origen, la capa de aplicación envía un flujo de datos de la aplicación a la capa de transporte.
• En la capa de transporte, el flujo de datos de la capa de aplicación se divide en paquetes y se agrega un encabezado TCP para formar un segmento TCP, que se envía a la capa de red.
• Agregue un encabezado IP que incluya las direcciones IP del host de origen y destino al segmento TCP en la capa de red, genere un paquete de datos IP y envíe el paquete de datos IP a la capa de red.
• La capa de enlace carga el paquete de datos IP en la parte de datos de su marco MAC, agrega la dirección MAC y el encabezado del marco del host de origen y destino, y envía el marco MAC al host de destino o al enrutador IP de acuerdo con la dirección MAC de destino.
• En el host de destino, la capa de enlace elimina el encabezado de trama de la trama MAC y envía el paquete de datos IP a la capa de red.
• La capa de red verifica el encabezado IP, y si la suma de verificación en el encabezado es inconsistente con el resultado del cálculo, el paquete de datos IP se descarta; si el resultado del cálculo de la suma de verificación es consistente, el encabezado IP se elimina y el segmento TCP se envía a la capa de transporte.
• La capa de transporte verifica el número de secuencia para ver si es un paquete TCP correcto y luego verifica los datos del encabezado TCP. Si es correcto, enviará un mensaje de confirmación al host de origen; si es incorrecto o se pierde el paquete, solicitará al host de origen que vuelva a enviar la información.
• En el host de destino, la capa de transporte elimina el encabezado TCP y envía los paquetes secuenciados para formar el flujo de datos de la aplicación al programa de la aplicación. De esta forma, el flujo de bytes recibido por el host de destino desde el host de origen es como recibir el flujo de bytes directamente desde el host de origen.