1 El proceso de una solicitud de red
Por lo general, mostramos una página correspondiente después de una solicitud web de menos de un segundo después de ingresar una URL en el navegador y presionar Enter. De hecho, un proceso de solicitud web tan completo tiene que seguir varios pasos:
El primer paso: DNS resuelve la dirección IP;
El segundo paso: protocolo de enlace de tres vías TCP para establecer una conexión;
Paso 3: si es HTTPS, también se requiere un certificado de firma de verificación de apretón de manos TLS;
Paso 4: el cliente inicia una solicitud HTTP
Paso 5: el servidor responde a las solicitudes HTTP
Paso 6: el navegador del cliente recibe el contenido y analiza html, css, js
Paso 7: el navegador muestra la página
Proceso de IP de resolución de 2 DNS
DNS (Sistema de nombres de dominio) se denomina "Sistema de nombres de dominio". Es un sistema de nombres de servicios de computadora y red organizado en una jerarquía de dominio. Se utiliza en redes TCP / IP. El servicio que proporciona se utiliza para convertir nombres de host y nombres de dominio. Trabajar para la dirección IP. El proceso es probablemente así:
El primer paso: llame al método correspondiente a través de la clase java.net.InetAddress para verificar si existe su propia caché, porque hay un procesamiento de caché de segundo nivel de DNS en el sistema Android.
Paso 2: Si java.net.InetAddress no está en caché, verifique el caché DNS de la máquina virtual para determinar si existe. Este es el caché de segundo nivel.
Paso 3: si la dirección IP no se puede resolver después del almacenamiento en caché, leerá la resolución del archivo Hosts local.
Paso 4: Si la resolución de nombre de dominio no se puede completar en la máquina local a través de lo anterior, el sistema solo puede solicitar el sistema de servicio de resolución de nombre de dominio en el área local para su análisis, como la red del campus. Si la red del operador está conectada, el servidor de resolución de nombre de dominio local es el local Operadores regionales para prestar servicios.
Paso 5: Si el servidor de resolución de nombre de dominio local no ha completado la resolución, entonces el servidor de resolución de nombre de dominio local iniciará una solicitud de resolución al servidor de nombre de dominio raíz. El servidor de nombres de dominio raíz devuelve las direcciones genéricas de dominio de nivel superior (gTLD) del dominio buscado, como: .com, .cn, .org, .edu, etc.
Paso 6: el servidor de resolución de nombre de dominio local inicia una solicitud al servidor de gTLD.
Paso 7: el servidor de gTLD recibe la solicitud iniciada por el servidor de nombres de dominio local y encuentra el servidor de nombres del servidor de nombres correspondiente al nombre de dominio de acuerdo con el nombre de dominio que debe resolverse. Normalmente, este servidor de nombres es el servidor de nombres que usted registró. El servidor del proveedor de servicios de nombres de dominio asumirá la tarea de resolución de nombres de dominio.
Paso 8: el servidor de nombres busca la dirección IP correspondiente al nombre de dominio y devuelve la dirección IP junto con el tiempo de vida (Time To Live, TTL) al servidor de nombres de dominio local.
Paso 9: el servidor de nombres de dominio local almacena en caché los resultados resueltos, y el tiempo de caché está controlado por el tiempo TTL.
Paso 10: Devuelva el resultado de la resolución al usuario. El sistema del usuario almacenará en caché la dirección IP y el tiempo de caché será controlado por el TTL. En este punto, finaliza el proceso de análisis.
3 protocolo de enlace de tres vías TCP
El llamado apretón de manos de tres vías (Apretón de manos de tres vías) se refiere a cómo rastrear la cantidad de datos enviados cada vez para negociar para sincronizar la transmisión y recepción del segmento de datos, el número de confirmaciones de datos y la transmisión y recepción de datos determinada de acuerdo con la cantidad de datos recibidos Cuándo se cancelará el contacto y se establecerá una conexión virtual después de la finalización.
El primer apretón de manos: el cliente envía el segmento de solicitud de conexión, establece SYN (Sincronizar números de secuencia, número de secuencia de sincronización) a 1 y establece un seq = x, (Número de secuencia, número de secuencia) (x está determinado por el sistema operativo Generado por una determinada regla, puede considerarse como un número aleatorio) para enviar este mensaje ( SYN = 1 seq = x ) al servidor. En este punto, el cliente ingresa al estado enviado sincronizado SYN_SEND , esperando que el servidor confirme .
Segundo apretón de manos: después de que el servidor recibe el segmento de solicitud SYN del cliente, si acepta establecer una conexión, necesita una confirmación ACK (número de confirmación, carácter de confirmación) para este segmento SYN, establecer ack = x + 1 y, al mismo tiempo, También envíe información de solicitud SYN, establezca SYN en 1, seq = y. El servidor coloca toda la información anterior en un segmento de mensaje ( ACK = 1 ack = x + 1, SYN = 1 seq = y ) y la envía al cliente al mismo tiempo. En este momento, el servidor ingresa al estado recibido sincrónico SYN_RECV ;
El tercer apretón de manos: el cliente recibe el segmento SYN + ACK del servidor y envía una confirmación de confirmación al servidor, es decir, una confirmación ACK, establece un reconocimiento en y + 1 y envía un segmento ACK al servidor ( ACK = 1 ack = y + 1 ), tanto el cliente como el servidor ingresan al estado conectado ESTABLECIDO y completan tres apretones de manos.
Ejemplo de mijo:
El primer apretón de manos: el cliente dijo: Hola, hola, ¿puedes oírme?
El segundo apretón de manos: El servidor dijo: Hola, puedo escuchar, ¿puedes oírme?
El tercer apretón de manos: el cliente dijo: también puedo oírte hablar
Después de confirmar que se han escuchado a través del diálogo, pueden comenzar a hablar entre ellos ...
¿Por qué usar tres apretones de manos en lugar de dos?
Ahora suponga que se produce una situación anormal durante el establecimiento de la conexión: el primer segmento de solicitud de conexión enviado por el cliente no se pierde, sino que permanece en algunos nodos de la red durante mucho tiempo, de modo que se retrasa hasta cierto punto después de que se libera la conexión. Solo tomó tiempo llegar al servidor. Originalmente era un segmento que debería haberse invalidado, pero el servidor recibió esta solicitud de conexión no válida. No sabía que se trataba de una solicitud no válida, por lo que erróneamente pensó que el cliente emitió una nueva solicitud de conexión, por lo que Se envía un segmento de confirmación al cliente y se establece una conexión entre ellos. Suponemos que no se usa el apretón de manos de tres vías, entonces la relación de conexión se establecerá en este momento.
Debido a que el cliente no ha enviado una solicitud para establecer una conexión, no ignorará la confirmación del servidor y no enviará datos al servidor, pero el servidor cree que la conexión se ha establecido y ha estado esperando que el cliente envíe los datos. El servidor desperdiciará recursos.
Por lo tanto, el apretón de manos de tres vías puede prevenir efectivamente el fenómeno anterior. Cuando el tercer apretón de manos, el cliente no enviará una confirmación a la confirmación del servidor, porque el servidor no recibe la confirmación, entenderá que el cliente no solicitó realmente establecer una conexión.
4 cuatro olas
Lo opuesto al apretón de manos de tres vías es la onda de cuatro vías (Four-Way Wavehand), lo que significa que cuando se desconecta una conexión TCP, el waver puede ser el cliente o el servidor. Se envían un total de 4 paquetes entre ellos para confirmar la desconexión de la conexión Abierto, el proceso es el siguiente:
La primera ola de la mano: el Host A envía un segmento de mensaje desconectado, establece FIN (Número de finalización) en 1 y establece un seq = u (u es el último número de bytes transmitido el último +1 ) a este mensaje ( FIN = 1 seq = u ) Después del envío, el host A ingresa al estado de espera de terminación 1 FIN_WAIT_1 .
Segunda ola: el host B recibe el segmento FIN del host A, y necesita ACK este segmento, establecer ack = u + 1 y traer el número de secuencia seq = v, el host B enviará lo anterior Toda la información se envía de vuelta al host A en un segmento de mensaje ( ACK = 1 ack = u + 1 seq = v ). En este momento, el host B ingresa al estado de espera de cierre CLOSE_WAIT . Cuando el host A recibe la solicitud de confirmación del host B , el host A ingresará al estado de espera de terminación 2 FIN_WAIT_2 , esperando que el host B envíe un mensaje de liberación de conexión , en este momento el host B también puede enviar datos normales al host A.
Tercera ola: si el Host B ha enviado todos los últimos datos y no hay más datos para enviar, enviará un mensaje de liberación de conexión al Host A, establezca FIN en 1 y seleccione seq = w y ACK para confirmar Configure ack = u + 1 para enviar el mensaje de liberación ( FIN = 1 seq = w, ACK = 1 ack = u + 1 ). En este momento, el host B ingresa el estado de confirmación final LAST_ACK .
Cuarta ola: después de recibir el mensaje de liberación, el host A necesita enviar una confirmación final, establecer ack en w + 1, y traer el número de secuencia seq = u + 1, y enviar el segmento de mensaje al host B ( ACK = 1 ack = w + 1 seq = u + 1 ), en este momento, el host A ingresa el estado de espera de tiempo TIME_WAIT , en este momento, la conexión TCP no se desconecta inmediatamente, sino después de 2 * MSL (la vida útil más larga del segmento, generalmente 2 Minutos, para garantizar que no se volverán a crear nuevas conexiones con la misma dirección y puerto durante este período), el bloque de control de transmisión se revoca y se ingresa al estado CERRADO . Durante este tiempo, cuando el host B recibe la confirmación final del host A , ingresará inmediatamente al estado cerrado CERRADO y revocará el bloque de control de transmisión . En este punto, las cuatro manos agitadas de TCP están completas.
Ejemplo de mijo:
La primera ola: A dijo: he terminado, voy a callarme y no quiero decir nada.
La segunda ola: B dijo: Lo recibí y supe que había terminado, pero todavía tengo algo que decir.
Después de que B también fastidiara las palabras ...
Saludó por tercera vez: B dijo: He terminado de hablar y tengo que callarme.
La cuarta ola: A dijo: lo recibí y sabía que lo había terminado, pero A no estaba tranquilo. Después de esperar un período de tiempo (2 ciclos de vida máximos de mensajes), realmente no escuché nada, sabía que debía irme B recibió a A y supo que había terminado de hablar, e inmediatamente se fue.
¿Por qué hay un apretón de manos de tres vías cuando está conectado, pero cuatro ondas cuando está cerrado?
TCP es un modo dúplex completo, lo que significa que cuando el host A envía un segmento FIN , le dice al host B que se han enviado mis datos y que no se envían más datos. En este momento, cuando el host B devuelve el segmento ACK , significa que ya sabe que el host A no tiene datos para enviar, pero no es el código que el B principal no tiene datos para enviar, por lo que en este momento el host B aún puede enviar datos al host A. Cuando el host Cuando B también envió el segmento de mensaje FIN , esta vez significa que el host B no tiene datos para enviar, y le dirá al host A que no tengo datos para enviar. Luego, cada uno interrumpirá esta conexión TCP .
5 TLS apretón de manos
Idea básica del protocolo SSL / TLS
El primer paso: el cliente solicita la clave pública del servidor;
Paso 2: el servidor devuelve un certificado de confianza que contiene la clave pública;
El tercer paso: el cliente verifica el certificado para determinar la clave pública, y utiliza la clave pública para usar el cifrado asimétrico para negociar en privado. Cómo generar una clave de conversación (el cifrado asimétrico tiene baja eficiencia pero alta seguridad, por lo que la clave pública del servidor solo se usa para el cifrado " Dialog Key " en sí) ;
El cuarto paso: el servidor recibe el resultado descifrado después de la negociación, y la comunicación entre las dos partes utiliza un método de cifrado simétrico para generar una clave de conversación (el cifrado simétrico tiene una alta eficiencia y reduce el tiempo de comunicación) .
El proceso detallado del apretón de manos de cuatro vías.
El primer apretón de manos: el cliente envía una solicitud de comunicación cifrada ( ClientHello ) al servidor , proporcionando la siguiente información:
Admite la versión de versión de protocolo más alta, como: TLS1.2
Lista de conjuntos de cifrado compatibles: algoritmo de autenticación de identidad, algoritmo de intercambio de claves, algoritmo de cifrado simétrico y resumen de mensajes
Lista de métodos de compresión de algoritmos de compresión compatibles para la transmisión de compresión de información posterior
Número aleatorio random_C, utilizado para generar la clave de conversación más tarde
Extensiones de campo de extensión, parámetros relacionados con algoritmos y protocolos compatibles y otra información auxiliar, etc.
El segundo apretón de manos: el servidor responde a la solicitud después de recibir la solicitud del cliente ( server_hello + server_certificate + sever_hello_done ) (si el servidor también requiere que el cliente proporcione un certificado, como el escudo U en la banca en línea, incluirá uno más aquí Artículos):
server_hello : el servidor devuelve el resultado de la información negociada, incluida la siguiente información:
Versión del protocolo
Confirme para usar el conjunto de cifrado
Método de compresión de elección
Número aleatorio random_S, utilizado para generar claves de conversación más tarde
Extensiones de campo de extensión, parámetros relacionados con algoritmos y protocolos compatibles y otra información auxiliar, etc.
server_certificates : certificados configurados en el lado del servidor con claves públicas
server_hello_done : notifica al cliente que la información ha sido enviada
El tercer apretón de manos: después de recibir la respuesta del servidor, el cliente verificará el certificado devuelto. Si el certificado no es emitido por una autoridad confiable, o el nombre de dominio en el certificado es inconsistente con el nombre de dominio real, o el certificado ha sido revocado, o el certificado ha expirado, se mostrará una advertencia al visitante para elegir si continúa la comunicación. Si no hay ningún problema con el certificado, el cliente continúa enviando información al servidor ( client_key_exchange + change_cipher_spec + encrypted_handshake_message (Finalizado) ) (Si el servidor requiere que el cliente también retire el certificado, como el U-shield en la banca por Internet, luego envíe el certificado y su Información relacionada):
client_key_exchange : calcule un número aleatorio pre_master y use la clave pública extraída del certificado para cifrar la transmisión mediante cifrado asimétrico
(El cliente ha dominado el método de cálculo de la clave de conversación en este momento: enc_key = Fuc (random_C, random_S, pre_master))
change_cipher_spec : indica que las comunicaciones posteriores utilizarán la clave y el algoritmo de cifrado negociado por ambas partes para la comunicación cifrada
encrypted_handshake_message : notifique el final del protocolo de enlace, combine con el valor hash de todo el contenido de la comunicación anterior y otra información relevante para generar un dato para que el servidor lo verifique
El cuarto apretón de manos: el servidor recibe el pre_master cifrado pasado por el cliente y lo descifra con la clave privada, y también calcula la clave de conversación mediante enc_key = Fuc (random_C, random_S, pre_master), y luego devuelve el mensaje al cliente ( change_cipher_spec + encrypted_handshake_message (Finalizado) ):
change_cipher_spec : indica que las comunicaciones posteriores utilizarán la clave y el algoritmo de cifrado negociado por ambas partes para la comunicación cifrada
encrypted_handshake_message : notifique el final del apretón de manos, combínelo con el valor hash de todo el contenido de la comunicación anterior y otra información relevante para generar un dato, que el cliente utiliza para la verificación
En este punto, toda la fase de apretón de manos TLS ha terminado. A continuación, la comunicación entre el cliente y el servidor es el protocolo HTTP ordinario, pero el contenido se cifra utilizando la clave de sesión.
