Red informática (en proceso de aprendizaje-actualización continua)

1. Protocolo de siete capas OSI, protocolo de cuatro capas TCP / IP y protocolo de cinco capas

Protocolo de siete capas OSI

1. Capa de aplicación: proporciona servicios para aplicaciones específicas, como SMTP (correo electrónico), HTTP, DNS, etc. para la transmisión de datos.
2. Capa de presentación: convierta la información procesada por la aplicación a un formato adecuado para la transmisión por red
3. Capa de sesión: responsable de establecer y desconectar las conexiones de comunicación.
4. Capa de transporte: Los protocolos de esta capa incluyen principalmente TCP y UDP, que se utilizan para la transmisión de datos entre el host y el host.
5. Capa de red: el protocolo de esta capa es el protocolo IP, la gestión de direcciones y el enrutamiento.
6. Capa de enlace de datos: responsable de la comunicación y transmisión entre nodos a nivel físico
7. Capa física: responsable del intercambio entre flujos de 0 y 1 bit, niveles de voltaje y destellos de luz

Protocolo de cuatro capas TCP / IP

1. Capa de aplicación: las funciones de la capa de sesión, la capa de presentación y la capa de aplicación en el modelo de referencia OSI están todas integradas en el programa de aplicación.
2. Capa de transporte: TCP, protocolo UDP, proporciona una transmisión de datos confiable
3. Capa de red: protocolo IP, responsable de la gestión y el enrutamiento de direcciones
4. Capa de interfaz de red: utilice la capa de enlace de datos de Ethernet para la comunicación y el flujo de bits para la transmisión física

Protocolo de cinco capas

1. Capa de aplicación
2. Capa de transporte
3. Capa de red
4. Capa de enlace de datos
5. Capa fisica

Resumen del gráfico

Dos, TCP, UDP

Protocolo TCP

Protocolo TCP, también conocido como Protocolo de control de transmisión.
es:

• Protocolo de comunicación de capa de transporte confiable, orientado a la conexión y basado en flujo de bytes
• Divida el flujo de datos de la capa de aplicación en segmentos y transmítalos a la capa TCP del nodo de destino
• El paquete de datos tiene un número de secuencia, la otra parte enviará un ACK para confirmar si se recibe, de lo contrario será retransmitido
• Utilice la suma de comprobación para verificar si los datos son incorrectos durante la transmisión

Protocolo UDP

es:

• Un protocolo de comunicación de capa de transporte sin conexión, no confiable y basado en mensajes
• No mantiene el estado de la conexión y admite la transmisión simultánea del mismo mensaje a varios clientes
• El encabezado del paquete tiene solo 8 bytes, con menos sobrecarga adicional
• El rendimiento no se ajusta mediante el algoritmo de congestión, solo está limitado por la tasa de generación de datos, la tasa de transmisión y el rendimiento de la máquina
• Entrega con el mejor esfuerzo, la entrega confiable no está garantizada, no es necesario mantener tablas de estado de enlace complejas
• El protocolo UDP tiene una velocidad de transmisión más rápida que el protocolo TCP, porque agrega directamente el encabezado al mensaje transmitido desde la capa de aplicación y luego lo transmite a la capa IP inferior sin dividirse ni fusionarse.

La diferencia entre TCP y UDP

• Orientado a la conexión frente a orientado a la conexión: la transmisión de información TCP es establecer una conexión, pero UDP no necesita serlo, es adecuado para la transmisión de un punto a múltiples puntos
• Fiabilidad: TCP proporciona una garantía de fiabilidad a través del protocolo de enlace y el mecanismo de retransmisión, mientras que UDP puede perderse
• Orden: TCP utiliza números de secuencia para asegurar la entrega de los datos por orden. Las llegadas pueden estar desordenadas, pero TCP eventualmente ordenará, mientras que UDP no tiene orden.
• Velocidad: la velocidad de TCP es relativamente lenta, porque necesita establecer una conexión para garantizar la confiabilidad y el orden de los datos, por lo que se necesitan más operaciones adicionales. UDP es adecuado para aplicaciones sensibles a la velocidad, como medios de video en línea, transmisiones de TV, Juegos online multijugador, etc.
• Peso: TCP es pesado, UDP es liviano, lo que se refleja en el tamaño del encabezado de los datos de origen, TCP es 20 bytes y UDP es 8 bytes

Protocolo de enlace de tres vías TCP

Proceso de apretón de manos

• El primer apretón de manos: el cliente envía un segmento SYN (seq = x) al servidor
• El segundo saludo: el servidor envía un segmento SYN (seq = y) + ACK (ack = x + 1) al cliente
• El tercer apretón de manos: el cliente envía un segmento ACK (seq = y + 1) al servidor

¿Por qué hay un apretón de manos de tres vías? ¿No es dos o cuatro veces?

El primer apretón de manos es para solicitar el establecimiento de un canal de transmisión del cliente al servidor. El segundo apretón de manos es para confirmar que el canal de transmisión del cliente al servidor es normal y solicitar el establecimiento de un canal de transmisión del servidor al cliente. El tercer apretón de manos es para confirmar el servidor al cliente. El canal de transmisión final es normal. El protocolo de enlace de tres vías solo garantiza que los dos canales se puedan transmitir normalmente, dos veces menos y cuatro veces más.

El peligro oculto del primer tiempo de espera de protocolo de enlace-SYN de TCP

La causa
del problema Dado que el servidor recibió el SYN del cliente y no recibió la confirmación ACK al responder al SYN-ACK, el servidor continuará intentando enviar el paquete SYN-ACK hasta que se agote el tiempo de espera.
Para las medidas de protección SYN Flood
, después de que la cola SYN esté llena, envíe la Cookie SYN a través del parámetro tcp_syncookies.
Si la conexión es normal, el Cliente devolverá la Cookie SYN.
Una vez establecida la conexión directamente , el cliente
fallará. Envíe un mensaje de detección de Keep-Alive a la otra parte. Si continúa enviándolo para recibir la respuesta, habrá un intervalo de tiempo de Keep-Alive preestablecido. Si no hay respuesta dentro del tiempo especificado, la conexión terminará.

TCP saludó cuatro veces

Proceso de onda

• Primera ola: después de que el cliente termine de transmitir los datos, enviará un mensaje FIN al servidor para cerrar el canal de transmisión del cliente al servidor, y el cliente ingresará al estado FIN-WAIT-1
• La segunda ola: el servidor recibe el mensaje FIN enviado por el cliente, e inmediatamente responderá con un mensaje ACK para confirmar que el canal de transmisión del cliente al servidor está cerrado y el servidor entra en el estado CLOSE-WAIT
• La tercera ola: el servidor enviará un mensaje FIN al cliente después de transmitir los datos, y el servidor ingresará al estado LAST-ACK
• Cuarta oleada: el cliente recibe el mensaje FIN del servidor y responde con un mensaje ACK para confirmar que el canal de transmisión del servidor al cliente está cerrado. El cliente entra en el estado TIME-WAIT (2MSL) y luego El servidor entra en el estado CERRADO y el cliente espera el tiempo de 2MSL (MaximumSegmentLifetime) para entrar en el estado CERRADO.

¿Por qué hay un estado de TIEMPO DE ESPERA al agitar

Asegúrese de que haya suficiente tiempo para que la otra parte reciba el paquete ACK, que es exactamente 2MSL

¿Por qué saludar cuatro veces?

Debido a que la conexión TCP es un servicio full-duplex, tanto el remitente como el receptor necesitan un mensaje FIN y un mensaje ACK para cerrar el canal y confirmar que el canal está cerrado.

Las características y el propósito de TCP

La característica de TCP es que la transmisión es confiable. Si la transmisión es confiable, debe resolver los problemas de destrucción de datos, pérdida de paquetes, duplicación y secuencia de fragmentación desordenada.
TCP pasa suma de control, número de secuencia, respuesta de confirmación, control de retransmisión, administración de conexión y ventana Control y otros mecanismos para lograr una transmisión confiable

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

Mejore la confiabilidad a través del número de serie y la respuesta de confirmación

En TCP, cuando los datos del remitente llegan al host receptor, el host receptor devolverá un mensaje, que se denomina reconocimiento (ACK).
TCP utiliza un reconocimiento positivo (ACK) para garantizar una transmisión de datos confiable. Cuando el remitente lo envía Una vez recibidos los datos, el remitente esperará la respuesta de confirmación del receptor. Si se recibe la respuesta de confirmación, significa que el lote de datos enviados se ha enviado correctamente al extremo opuesto. Si la respuesta de confirmación no se recibe después de un período de tiempo, entonces Considerará si hay pérdida de paquetes durante la transmisión de datos y, en ese momento, el remitente volverá a transmitir. Como resultado, incluso si se produce una pérdida de paquetes, puede garantizar que los datos lleguen al extremo opuesto y logren una transmisión confiable.
Hay dos posibilidades de pérdida de paquetes en este momento:

• Pérdida de paquetes de datos: pérdida de paquetes debido a la congestión de la red durante el proceso de envío. En este caso, se volverá a enviar para garantizar que los datos puedan llegar al extremo receptor correctamente
• Confirmación de la pérdida de respuesta Después de que el extremo receptor recibe este lote de datos, y luego el extremo receptor envía un mensaje de regreso al extremo emisor, en este proceso, causa la pérdida de paquetes. En este caso, el remitente también retransmitirá, pero el receptor descartará los datos después de recibirlos, y luego el receptor devolverá un ACK.

Las funciones mencionadas anteriormente, como el procesamiento de respuesta de confirmación, el control de retransmisión y el control de repetición, pueden realizarse mediante números de serie. El remitente envía un paquete de datos (1 ~ 100), y cuando el receptor lo recibe, envía el número de secuencia que debe aceptar en el siguiente paso como respuesta de confirmación. De esta manera, TCP puede lograr una transmisión confiable a través del número de serie y el número de respuesta de confirmación.

Cómo determinar el tiempo de espera de retransmisión

El tiempo de espera de retransmisión se refiere al intervalo de tiempo específico para esperar la respuesta de confirmación antes de retransmitir los datos. Si la respuesta de confirmación no se recibe después de este tiempo, el remitente retransmitirá los datos. Entonces, ¿cómo se determina la duración específica de este tiempo de espera de retransmisión?

TCP requiere un alto rendimiento en cualquier entorno de red y debe mantener esta función independientemente de los cambios en la congestión de la red. Calcula el tiempo de ida y vuelta (RTT) de cada paquete y su desviación, y el tiempo de espera de retransmisión es un valor ligeramente mayor que esta suma.

Hay razones por las que el cálculo del tiempo de espera de retransmisión debe considerar tanto el tiempo de ida y vuelta como la desviación. Según el entorno de red, el tiempo de ida y vuelta del paquete de datos puede fluctuar mucho. Esto sucede porque los segmentos del paquete de datos llegan a través de diferentes líneas. El propósito de TCP / IP es incluso en este entorno También controle, trate de no desperdiciar el tráfico de la red

En los sistemas BSD Unix y Windows, el tiempo de espera está en unidades de 0,5 segundos (la desviación mínima es 0,5, por lo que el tiempo mínimo de retransmisión es de al menos 1 segundo). El tiempo de ida y vuelta no se conoce en el paquete de datos inicial, por lo que se repite El tiempo de espera de envío generalmente se establece en 6 segundos.

Una vez retransmitidos los datos, si no se recibe la respuesta de confirmación, se retransmitirá de nuevo. Sin embargo, el número de retransmisiones no puede ser ilimitado.Cuando se alcanza un cierto número de veces, la conexión se interrumpirá a la fuerza debido a la razón de la red o el par tiene un problema.

TCP envía datos en unidades de segmentos

Al establecer una conexión TCP, también se puede determinar la unidad de envío de paquetes de datos. También podemos llamarlo "Longitud máxima del mensaje" (MSS). Cuando TCP transmite una gran cantidad de datos, los datos se dividen y envían por el tamaño de MSS. La unidad de MSS también se utiliza para la retransmisión.

Entonces, ¿cómo se calcula este MSS? Se determina cuando el protocolo de enlace de tres vías TCP establece la conexión. Durante el primer protocolo de enlace, el cliente recomienda que el MSS se establezca en un determinado tamaño de longitud1, y durante el segundo protocolo de enlace, el servidor recomienda que el MSS se establezca en un determinado tamaño de longitud2. Finalmente, el tercer apretón de manos determina el menor de estos dos tamaños y envía datos.

Use el control de ventana para aumentar la velocidad

TCP toma 1 segmento como una unidad y cada segmento necesita recibir una respuesta de confirmación. Pero este método de transmisión tiene una desventaja. Es decir, cuanto mayor sea el tiempo de ida y vuelta del paquete, peor será el rendimiento de la comunicación.

En respuesta a los problemas anteriores, TCP introduce el concepto de ventana, que puede controlar la degradación del rendimiento de la red incluso en el caso de un tiempo de ida y vuelta largo. En este momento, la respuesta de confirmación ya no está en unidades de un segmento, sino en una unidad más grande. Esto acortará enormemente el tiempo de reenvío.

En el caso de recibir una respuesta de confirmación, deslice la ventana a la posición del número de serie en la respuesta de confirmación. De esta manera, se pueden enviar múltiples segmentos simultáneamente para mejorar el rendimiento de la comunicación. Este mecanismo también se denomina control de ventana deslizante.

Control de ventana y control de retransmisión

Hablando de esta ventana, el tamaño de la ventana es lo que a todos les importa ¿Quién decide el tamaño de la ventana? Está determinada por la capacidad del extremo receptor para procesar datos. Esto implica un 缓冲区concepto, la zona de amortiguación representa un lugar para almacenar temporalmente los datos enviados y recibidos. El remitente envía los datos al receptor, y cuando el receptor responde con una respuesta de confirmación, se agrega el tamaño del búfer restante, que es el tamaño de la ventana para la siguiente transmisión.

Para los datos en la ventana, después de que el remitente los envía, el remitente debe configurar un búfer para guardar estos datos. Se borrará del búfer hasta que se reciba la respuesta de confirmación correspondiente. Si no se recibe la respuesta de confirmación, los datos se guardarán Reenvío, aquí hay otro concepto involucrado 高速重发. Como mencionamos antes, si el remitente no recibe la respuesta de confirmación, se retransmitirá después del período de tiempo de espera de retransmisión. Pero aquí, será diferente. TCP Establecido, después de que se envíen los datos en la ventana, si la respuesta de confirmación enviada por el extremo receptor se recibe 3 veces, se activará la retransmisión. Este mecanismo es más eficiente que la gestión del tiempo de espera mencionada anteriormente.

Cuando la ventana está enviando datos, se pierde un paquete y los siguientes continuarán enviándose. Pero qué hacer si esta pieza se pierde. De hecho, cuando el extremo receptor no recibe los datos del número de secuencia que espera, confirmará los datos recibidos antes. Una vez que el remitente recibe una determinada respuesta de confirmación y recibe la misma respuesta de confirmación tres veces seguidas, se considera que el segmento de datos se ha perdido y necesita ser retransmitido.

Control de flujo

El remitente envía datos según su situación real. Pero, en determinadas circunstancias, es posible que se reciba un paquete de datos irrelevante y que se tarde algún tiempo en solucionar otros problemas. En condiciones de alta carga, el extremo receptor no puede recibir ningún dato. De esta manera, si el extremo receptor descarta los datos que deberían haberse recibido, activará el mecanismo de retransmisión del extremo remitente, lo que provocará un desperdicio injustificado de tráfico de red. Es necesario que exista un mecanismo para evitar que esto suceda.

TCP resuelve este problema mediante el control de flujo. La zona de amortiguamiento que mencionamos anteriormente está relacionada con este mecanismo. El extremo receptor tendrá un búfer para almacenar los datos que se procesarán. Cada vez que el extremo receptor reciba datos, colocará estos datos en este búfer y, luego, cuando responda a la respuesta de confirmación, se acumulará en el búfer restante. la talla de. La próxima vez, el remitente establecerá este tamaño en el tamaño de la ventana para enviar datos. Si el tamaño de la ventana es 0, el remitente no enviará datos.

Una vez transcurrido un tiempo de espera de retransmisión, si no se ha recibido la notificación de actualización de la ventana, el remitente enviará un paquete de detección de ventana.Estos datos contienen solo un byte para obtener la información más reciente sobre el tamaño de la ventana.

Control de congestion

TCP adopta el control de la ventana Incluso si la respuesta de confirmación ya no se envía en unidades de un segmento de datos, puede enviar una gran cantidad de paquetes de datos de forma continua. Sin embargo, si se envía una gran cantidad de datos al comienzo de la comunicación, también pueden surgir otros problemas. Debido a que la red informática es un entorno compartido, también puede estar congestionada debido a la comunicación entre otros hosts. Cuando la red está congestionada, se envía repentinamente una gran cantidad de datos en este momento, lo que es muy probable que provoque la paralización de toda la red. .

Para evitar que ocurra este problema, TCP usa un valor derivado de un algoritmo llamado inicio lento al comienzo de la comunicación para controlar la cantidad de datos enviados.

Para ajustar la cantidad de datos a enviar al remitente, se define un concepto llamado "ventana de congestión". Durante el inicio lento, configure el tamaño de la ventana en 1 segmento de datos (1MSS) para enviar datos, y luego el valor de la ventana de congestión será +1 para cada respuesta. Al enviar un paquete de datos, el tamaño de la ventana se compara con el tamaño de la ventana deslizante y se selecciona un valor menor para enviar una cantidad menor de datos.

Si la retransmisión adopta un mecanismo de tiempo de espera, entonces el valor inicial de la ventana de congestión se establece en 1 y luego se realizará la corrección de inicio lento retrógrado. Con el mecanismo anterior, la congestión de la red causada por el envío continuo de paquetes de datos al comienzo de la comunicación se puede reducir de manera efectiva y también se puede evitar la congestión de la red.

Sin embargo, con cada viaje de ida y vuelta del paquete, la ventana de congestión también aumentará con una función exponencial como 1, 2, 4, y el aumento de la congestión puede incluso causar congestión en la red. Para evitar esto, se introduce el concepto de válvula de arranque lento. Siempre que el valor de la ventana de congestión supere este umbral, el aumento se reducirá cada vez que se reciba una respuesta de confirmación.

Cuando se inicia la comunicación TCP, no se establece el umbral de inicio lento correspondiente. En su lugar, se establecerá en la mitad del tamaño de la ventana de congestión en el momento en que se agote el tiempo de espera de la retransmisión. Cuando el control de retransmisión de notificaciones se realiza mediante la respuesta de confirmación repetida, después de que el tamaño del umbral de inicio lento se establece en la mitad de la ventana actual, el tamaño predeterminado inicial de la ventana se establece en el umbral de inicio lento + el tamaño de 3 segmentos de datos.

Protocolo HTTP

Introducción

Cuando el usuario ingresa el URI de la página web a la que se accede en la barra de direcciones del navegador, el procesamiento HTTP comienza inmediatamente y HTTP usa el puerto 80 de manera predeterminada. Su mecanismo de trabajo es que el cliente establece una conexión TCP al puerto 80 del servidor, y luego solicita, responde y envía mensajes de datos en esta conexión TCP.

Hay dos versiones de HTTP de uso común, una es HTTP1.0 y la otra es HTTP1.1. En la 1.0, establecerá una conexión TCP cada vez que envíe un comando y una respuesta. A partir de la versión 1.1, permite enviar en una conexión TCP. Múltiples comandos y respuestas (mantener vivo), lo que reduce las operaciones de establecimiento y desconexión de la conexión TCP, mejorando así la eficiencia

Principales comandos HTTP y códigos de respuesta

Los principales comandos de HTTP

Comandos principales HTTP
OPCIONES	Opciones de configuración
OBTENER	Obtener los datos de la URL especificada
CABEZA	Obtenga solo la primera parte del documento
ENVIAR	Solicite al servidor que reciba el documento especificado por URI como información ejecutable
PONER	Solicitar al servidor que guarde los datos transmitidos por el cliente en el documento especificado por URI
ELIMINAR	Solicite al servidor que elimine la página especificada por el URI
RASTRO	Solicitar mensaje devuelto al cliente

Código de estado principal HTTP

1xx: el servidor es normal y puede continuar enviando solicitudes

2xx: procesado correctamente

200 Éxito: indica que la solicitud del cliente se procesa normalmente en el servidor.204
Sin contenido: la solicitud se procesó correctamente, pero no se devuelven
datos.206 Contenido parcial: la solicitud se procesó correctamente y el cliente solo necesita parte de los datos

3xx: Redirigir

El resultado de la respuesta 3xx indica que el navegador necesita realizar un procesamiento especial para manejarlo correctamente

301: Redirección permanente. Este código de estado indica que al recurso solicitado se le ha asignado un nuevo URI, y el URI al que el recurso se refiere actualmente se utilizará en el futuro. En otras palabras, si ha guardado el URI correspondiente al recurso como marcador, visitará directamente
302: Redireccionamiento temporal la próxima vez . Este código de estado indica que al recurso solicitado se le ha asignado un nuevo URI. Espero que el usuario (esta vez) Se puede acceder usando el nuevo URI

4xx: error del cliente

La respuesta 4xx indica que el cliente es la causa del error.

401 No autorizado: este código de estado indica que la solicitud enviada requiere información de autenticación que ha pasado la autenticación HTTP (autenticación BÁSICA, autenticación DIGEST).
403 Prohibido: este código de estado indica que el servidor deniega el acceso al recurso solicitado.
404 No encontrado: este código de estado indica que el recurso solicitado no se puede encontrar en el servidor.

5xx: error del servidor

La respuesta 5xx indica que ocurrió un error en el propio servidor

500 Error interno del servidor: este código de estado indica que se produjo un error en el servidor al ejecutar la solicitud.
503 Servicio no disponible: este código de estado indica que el servidor está sobrecargado temporalmente o se está apagando por mantenimiento, y la solicitud no se puede procesar ahora.

HTTPS para seguridad web

Cuáles son las desventajas de HTTP

La comunicación utiliza texto sin formato (no cifrado), el contenido puede ser escuchado

HTTP realiza la transmisión de datos entre sí después de que se establece la conexión TCP, pero durante el proceso de transmisión, estos contenidos están en texto plano, y tales paquetes de datos existen en Internet y se escuchan fácilmente.

La identidad de la parte comunicante no se verifica, por lo que es posible encontrar enmascaramiento

Cuando HTTP se está conectando, no determinará quién lo envió a la solicitud que recibe, solo necesita recibir la solicitud, procesarla y luego devolver la respuesta. En este caso, se puede encontrar un disfraz y cualquiera puede iniciar una solicitud. Lo anterior puede causar los siguientes peligros ocultos

• Es imposible determinar si el servidor web al que se envía la solicitud al destino es el que devolvió la respuesta de acuerdo con la intención real. Puede ser un servidor web disfrazado.
• Es imposible determinar si la respuesta devuelta al cliente es la que recibió la respuesta de acuerdo con sus verdaderas intenciones. Puede ser un cliente disfrazado
• No se puede determinar si la parte comunicante tiene derechos de acceso. Debido a que la información importante se almacena en algunos servidores web, solo quiero enviarla a usuarios específicos con la autoridad de comunicación
• No hay forma de determinar de dónde vino la solicitud o quién la hizo.
• Incluso las solicitudes sin sentido serán aceptadas en su totalidad. No se pueden prevenir los ataques Dos (Denegación de servicio) bajo solicitudes masivas

No se puede probar la integridad del mensaje, por lo que puede estar alterado

La denominada integridad se refiere a la precisión de la información. La falta de prueba de su integridad generalmente significa que es imposible juzgar si la información es precisa. También es posible que el contenido recibido sea incorrecto.

Debido a las deficiencias de HTTP anteriores, apareció HTTPS

HTTPS = HTTP + cifrado + autenticación + restricción de integridad
Solíamos ser HTTP + TCP, mientras que HTTPS es HTTP + SSL y TSL + TCP Para decirlo sin rodeos, HTTPS es HTTP con un shell SSL.

Tecnología de cifrado de clave pública para el intercambio mutuo de claves secretas

HTTPS utiliza un mecanismo de cifrado híbrido, es decir, un mecanismo de cifrado que combina cifrado de clave secreta compartida y cifrado de clave pública. El intercambio HTTPS de claves secretas entre el cliente y el servidor se divide en dos pasos:

• Utilice el cifrado de clave pública para intercambiar de forma segura la clave secreta utilizada en el cifrado de clave compartida posterior
• Bajo la premisa de garantizar que la clave secreta intercambiada sea segura, utilice el cifrado de clave secreta compartida para la comunicación
  

Certificado que acredite la corrección de la clave pública

De hecho, el método de cifrado de clave pública mencionado anteriormente también tiene fallas, lo que significa que la clave pública en sí misma no puede probar que es una clave pública genuina. Por ejemplo, cuando se prepara para establecer una comunicación de cifrado de clave pública con un determinado servidor, cómo demostrar que la clave pública recibida es la clave pública del servidor que se esperaba originalmente. Quizás durante la transmisión de la clave pública, la clave pública real haya sido reemplazada por el atacante.

Para resolver este problema, puede utilizar el certificado de clave pública de la autoridad de certificación del certificado digital y sus agencias relacionadas. La autoridad de certificación del certificado digital está en la posición de una organización de terceros en la que pueden confiar tanto el cliente como el servidor.

Proceso de verificación: el servidor enviará este certificado de clave pública emitido por la autoridad de certificación digital al cliente para la comunicación de cifrado de clave pública. El cliente que recibe el certificado será verificado a través de SSL. Si se pasa la verificación, se puede determinar que el par es auténtico y la clave pública del servidor es confiable.

Establecimiento HTTPS del proceso de conexión SSL

Tres, DNS

Cómo se aborda el DNS

1. El cliente envía una solicitud de consulta y almacena en caché la búsqueda en la computadora local. Si no la encuentra, enviará la solicitud al servidor dns.
2. Envíela primero al servidor dns local, y el local buscará en su propia área. Si la encuentra, de acuerdo con Este registro se analizará. Si no se encuentra, se buscará en la caché local.
3. El servidor local no encontrará la información consultada por el cliente y enviará la solicitud al servidor dns del nombre de dominio raíz.
4. El servidor de nombres de dominio raíz resolverá la solicitud del cliente. La parte del dominio raíz, que devuelve la dirección del servidor DNS del siguiente nivel contenida en la dirección del servidor DNS del cliente
5. El servidor DNS del cliente accede al servidor DNS del siguiente nivel según la información devuelta.
6. Este método recursivo uno Cerca del destino de la consulta, y finalmente obtener la información de IP correspondiente en el servidor con el nombre de dominio de destino
7. El servidor dns local del cliente devolverá el resultado de la consulta a nuestro cliente
8. El cliente accederá según la información de IP obtenida. Host de destino, complete el proceso de resolución