[Bagu] Notas de revisión de ocho partes del reclutamiento de otoño de 2023 5 (Computer Network-CN)

Catálogo de ocho partes

HTTP

• 1.
  ¿Cuáles son los parámetros del protocolo HTTP?
  ¿Cuáles son los códigos de estado HTTP comunes?
  ¿Cuáles son los campos HTTP comunes?
  ¿Cuál es la diferencia entre OBTENER y POST?
  ¿Son seguros e idempotentes los métodos GET y POST?
  ¿Cuáles son los métodos de implementación del almacenamiento en caché HTTP?
  ¿Qué es el almacenamiento en caché forzado?
  ¿Qué es el almacenamiento en caché negociado?

• 2.
  ¿Cuáles son las ventajas de las características de la versión HTTP HTTP/1.1?
  ¿Cuáles son las desventajas de HTTP/1.1?
  ¿Cómo funciona HTTP/1.1?
  ¿Qué mejoras de rendimiento aporta HTTP/1.1 respecto a HTTP/1.0?
  ¿Qué optimizaciones se han realizado en HTTP/2?
  ¿Qué optimizaciones se han realizado en HTTP/3?
  ¿Cómo optimizar HTTP/1.1?
  ¿Dónde está la maravilla de HTTP/2?
  HTTP/3 está por llegar

• 3.
  ¿Cuáles son las diferencias entre otros protocolos HTTP y HTTPS?
  ¿Qué problemas resuelve HTTPS con HTTP?
  ¿Cómo establece HTTPS una conexión? ¿Cuál fue la interacción?
  ¿Cómo se garantiza la integridad de los datos de la aplicación HTTPS?
  ¿HTTPS es necesariamente seguro y confiable?
  Análisis del protocolo de enlace HTTPS RSA
  Análisis del protocolo de enlace HTTPS ECDHE
  HTTPS ¿Cómo optimizar?
  Dado que existe el protocolo HTTP, ¿por qué necesitamos RPC?
  Dado que existe el protocolo HTTP, ¿por qué necesitamos WebSocket?

tcp

• 1. Gestión de conexión:
  tcp / udp, 3 apretones de manos y 4 ondas, Socket
  3 apretones de manos (2 veces, 4 veces, número de secuencia, 1-3 perdidos)
  4 veces onda (2MSL, 1-4 perdidos, tiempo de espera, función, aprobado Más que menos, optimización, razones CLOSE_WAIT, keepalive)
  Socket (procesar, escuchar, aceptar, cerrar)
  Preguntas de entrevista de protocolo de enlace de tres vías TCP y onda de cuatro vías
  Análisis de captura de paquetes reales de TCP
  Cola de semiconexión TCP y cola de conexión completa
  Cómo entender ¿Protocolo de transmisión TCP orientado a bytes? (En comparación con UDP)
  ¿Por qué TCP tiene un número de secuencia de inicialización diferente cada vez que establece una conexión?
  ¿Se pueden establecer protocolos de enlace TLS y TCP al mismo tiempo en HTTPS?
  ¿TCP Keepalive y HTTP Keep-Alive son lo mismo?
  ¿Cuáles son los defectos de TCP?
  Si el servidor no escucha y el cliente inicia el establecimiento de la conexión, ¿qué pasará?
  ¿Se puede establecer una conexión TCP sin aceptación?

• 2. Transmisión confiable
  de mensajes SYN y ¿cuándo se descartarán?
  ¿Qué pasará si se recibe un paquete FIN desordenado en cuatro oleadas?
  ¿Qué sucede después de recibir SYN para una conexión TCP en estado TIME_WAIT?
  ¿Por qué tcp_tw_reuse está desactivado de forma predeterminada?
  ¿Cómo lograr una transmisión confiable basada en el protocolo UDP?
  ¿Pueden TCP y UDP usar el mismo puerto?
  ¿Cuál es la diferencia entre una conexión TCP, un corte de energía en un extremo y una falla del proceso?
  Después de desconectar el cable de red, ¿aún existe la conexión TCP original?
  Si se utiliza el protocolo TCP, ¿no se perderán los datos?
  ¿Puede TCP agitar cuatro veces en tres?
  ¿Cómo cambian los números de secuencia TCP y los números de acuse de recibo?

• 3. Ventana deslizante, control de flujo, control de congestión
  Retransmisión TCP, ventana deslizante, control de flujo, control de congestión
  ¿Cómo optimizar TCP? (Establecimiento de conexión, transmisión de datos)

Tabla de contenido

Como todos sabemos, existen alrededor de 5 niveles del examen de ingreso de posgrado OSI.
Entonces Bagu solo prueba HTTP en la capa de aplicación y TCP en la capa de transporte.
Es decir, la subred de recursos y la capa de transporte.
O la parte de principio a fin.

1. Capa de aplicación y HTTP

Algunas preguntas http

get/post (
obtener es obtener el recurso especificado, publicar es cargar el recurso y responder a la solicitud de recurso cargado
)

http y https (
Después del protocolo de enlace de tres vías TCP, se debe realizar el proceso de protocolo de enlace SSL/TLS. El número de puerto predeterminado de HTTPS es 443 y debe solicitar un certificado)
.

http 301 302 404 501 502 503 (
redireccionamiento 3xx y temporal permanente, error de cliente 4xx y el recurso no existe,
error de servidor 5xx y no abierto para negocios y error de proxy y red ocupada
)

La URL de entrada del navegador es idempotente (
el método GET es seguro, idempotente y almacenable en caché, mientras que el método post no es seguro e idempotente
) .

Las cookies de sesión deben usarse en todo momento (
las cookies no son muy seguras. Otros pueden analizar las cookies almacenadas localmente y realizar engaños de cookies. Teniendo en cuenta la seguridad, se debe usar la sesión. La sesión se guardará
en el servidor durante un cierto período de tiempo. Cuando A medida que aumenta el número de visitas, consumirá más rendimiento de su servidor. Para reducir el rendimiento del servidor, se deben utilizar cookies)
.

Ataque de inundación,
un ataque de denegación de servicio (DDoS) diseñado para agotar los recursos disponibles del servidor para que el servidor no pueda transmitir tráfico legítimo.
Al enviar repetidamente el paquete de solicitud de conexión inicial (SYN), el atacante derribará la computadora del servidor objetivo. Todos los puertos disponibles, lo que hace que el dispositivo de destino sea lento o incluso no responda al responder al tráfico legítimo
) .

¿Qué sucede cuando el navegador ingresa una URL?
¿Cómo recibir un paquete de solicitud HTTP?
¿Alguna vez has entendido la programación de sockets?
Para implementar un socket en el lado del servidor, ¿cómo crees que se debería implementar?

¿Cómo acelerar la página de entrada a la pantalla del navegador?
El servidor realiza el almacenamiento en caché (punto clave).
Durante el proceso de análisis de DNS, puede encontrar el archivo host en el resultado del análisis de URL.
Luego, las diferentes versiones del protocolo HTTP también tienen un impacto en la velocidad de solicitud de la página (HTTP2.0 es el formato de solicitud de marco). y luego se puede implementar en múltiples solicitudes HTTP a través de una conexión TCP)

¿Cómo utilizar el caché en el lado del servidor?
¿Qué estructura de datos LRU se utiliza?

Quiero implementar una función y una función para brindarle una parte de la memoria y cómo configurar su administración y asignación de memoria.

Principio de cifrado HTTPS (preguntado)

• HTTP tiene los siguientes problemas de seguridad:
  al utilizar texto sin formato para la comunicación, el contenido puede ser interceptado;
  al no verificar la identidad de la parte que se comunica, la identidad de la parte que se comunica puede disfrazarse;
  no se puede probar la integridad del mensaje y el mensaje puede ser manipulado.
  HTTPS no es un protocolo nuevo. En cambio, HTTP se comunica primero con SSL (Secure Sockets Layer) y luego SSL se comunica con TCP. En otras palabras, HTTPS utiliza un túnel para la comunicación.

Al utilizar SSL, HTTPS tiene cifrado (antiespionaje), autenticación (antienmascaramiento) y protección de integridad (antimanipulación).

1. Cifrado de clave simétrica
   El cifrado de clave simétrica utiliza la misma clave para cifrar y descifrar.
   Ventajas: Velocidad de cálculo rápida;
   Desventajas: No se puede transmitir de forma segura la clave a la parte que se comunica.

2. Cifrado de clave asimétrica
   El cifrado de clave asimétrica, también conocido como cifrado de clave pública (Public-Key Encryption), utiliza diferentes claves para el cifrado y descifrado.
   La clave pública está disponible para todos. Una vez que el remitente de la comunicación obtiene la clave pública del destinatario, puede usar la clave pública para cifrar. El destinatario usa la clave privada para descifrar el contenido de la comunicación después de recibirla.
   Además de usarse para cifrado, las claves asimétricas también se pueden usar para firmar. Debido a que otros no pueden obtener la clave privada, el remitente de la comunicación usa su clave privada para firmar y el receptor de la comunicación usa la clave pública del remitente para descifrar la firma y determinar si es correcta.
   Ventajas: la clave pública se puede transmitir al remitente de la comunicación de forma más segura;
   Desventajas: velocidad de operación lenta.

3. Método de cifrado utilizado por HTTPS
   Como se mencionó anteriormente, el método de cifrado de clave simétrica tiene una mayor eficiencia de transmisión, pero no puede transmitir de forma segura la clave secreta a la parte que se comunica. El cifrado de clave asimétrica puede garantizar la seguridad de la transmisión, por lo que podemos utilizar el cifrado de clave asimétrica para transmitir la clave secreta a la parte que se comunica.
   HTTPS utiliza un mecanismo de cifrado mixto, que utiliza la solución mencionada anteriormente:
   utiliza cifrado de clave asimétrica para transmitir la clave secreta requerida para el cifrado de clave simétrica para garantizar la seguridad;
   después de obtener la clave secreta, la comunicación se realiza mediante cifrado de clave simétrica para garantizar la eficiencia.

Certificación

• Las partes comunicantes se autentican mediante el uso de certificados.
• La Autoridad de Certificación Digital (CA, Autoridad de Certificación) es una organización de terceros que es confiable tanto para el cliente como para el servidor .
• El operador del servidor solicita una clave pública a la CA. Después de que la CA determine la identidad del solicitante, firmará digitalmente la clave pública aplicada, luego distribuirá la clave pública firmada y transferirá la clave pública a la CA. Las claves se colocan en el certificado de clave pública y se unen .
• Al comunicarse a través de HTTPS, el servidor envía el certificado al cliente. Después de que el cliente obtiene la clave pública, primero usa la firma digital para la verificación . Si la verificación pasa, puede comenzar la comunicación.

protección de integridad

• SSL proporciona funcionalidad de resumen de mensajes para protección de la integridad.
• HTTP también proporciona la función de resumen de mensajes MD5, pero no es seguro. Por ejemplo, después de que se manipula el contenido del mensaje, el valor MD5 se vuelve a calcular al mismo tiempo y el receptor de la comunicación no puede darse cuenta de que se ha producido la manipulación.
• La función de resumen de mensajes de HTTPS es segura porque combina cifrado y autenticación. Imagínese, después de que se manipula el mensaje cifrado, es difícil volver a calcular el resumen del mensaje porque el texto sin formato no se puede obtener fácilmente.

Desventajas de HTTPS

• Debido a que se requieren procesos como el cifrado y descifrado, la velocidad será más lenta;
• Hay tarifas elevadas por la autorización de certificados.

HTTP/1.1 nuevas características

Ver arriba para más detalles

El valor predeterminado es una conexión larga.
Admite canalizaciones.
Admite la apertura de múltiples conexiones TCP al mismo tiempo.
Admite hosts virtuales
. Se agregó el código de estado 100
para admitir la codificación de transferencia fragmentada.
Se agregó la edad máxima de instrucción de procesamiento de caché.

HTTP/2.0 y RPC (preguntado)

Defectos de HTTP/1.x
La implementación de HTTP/1.x es simple a expensas del rendimiento:
el cliente necesita usar múltiples conexiones para lograr simultaneidad y reducir la latencia;
los encabezados de solicitud y respuesta no están comprimidos, lo que genera tráfico de red innecesario;
no Admite una priorización efectiva de recursos, lo que resulta en una baja utilización de la conexión TCP subyacente.

Comparación GET y POST

GET se utiliza para obtener recursos, mientras que POST se utiliza para transferir el cuerpo de la entidad.

Tanto las solicitudes GET como POST pueden usar parámetros adicionales,
pero los parámetros GET aparecen en la URL como cadenas de consulta,
mientras que los parámetros POST se almacenan en el cuerpo de la entidad.
El hecho de que los parámetros POST se almacenen en el cuerpo de la entidad no significa que sea más seguro, porque aún se pueden ver a través de algunas herramientas de captura de paquetes (Fiddler).

seguridad

• Los métodos HTTP seguros no cambian el estado del servidor, lo que significa que solo es legible.
• El método GET es seguro, pero POST no lo es, porque el propósito de POST es transmitir el contenido del cuerpo de la entidad. Este contenido puede ser datos cargados por el usuario. Después de que la carga sea exitosa, el servidor puede almacenar estos datos en la base de datos. , por lo que el estado cambiará.
• Además de GET, los métodos seguros incluyen: HEAD y OPTIONS.
• Además de POST, los métodos inseguros incluyen PUT y DELETE.

Idempotencia

• Para los métodos HTTP idempotentes, el efecto de ejecutar la misma solicitud una y varias veces seguidas es el mismo, y el estado del servidor también es el mismo.
• En otras palabras, los métodos idempotentes no deberían tener efectos secundarios (excepto con fines estadísticos).
• Todos los métodos de seguridad también son idempotentes.
• Cuando se implementan correctamente, métodos como GET, HEAD, PUT y DELETE son idempotentes, mientras que el método POST no lo es.
• GET /pageX HTTP/1.1 es idempotente. Si se llama varias veces seguidas, el cliente recibirá el mismo resultado:

almacenable en caché

• Si desea almacenar en caché la respuesta, se deben cumplir las siguientes condiciones:
• El método HTTP del mensaje de solicitud en sí se puede almacenar en caché, incluidos GET y HEAD, pero PUT y DELETE no se pueden almacenar en caché y POST no se puede almacenar en caché en la mayoría de los casos.
• Los códigos de estado de los mensajes de respuesta se pueden almacenar en caché, incluidos: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414 y 501.
• El campo de encabezado Cache-Control del mensaje de respuesta no especifica el almacenamiento en caché.

2. Capa de transporte y TCP

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

Protocolo de enlace TCP de tres vías (por qué no cuatro veces, la última vez se puede adjuntar con datos)
Protocolo de enlace TCP de cuatro vías (¿comprende el último tiempo de espera)?

1. Protocolo de enlace de tres vías TCP:

   • Primer apretón de manos (SYN): el cliente envía un segmento TCP con un indicador SYN (número de secuencia de sincronización) al servidor, solicitando establecer una conexión.
   • Segundo protocolo de enlace (SYN+ACK): después de recibir la solicitud del cliente, el servidor responde con un segmento TCP con el bit de bandera SYN/ACK, lo que indica que acepta establecer una conexión.
   • Tercer apretón de manos (ACK): después de recibir la respuesta del servidor, el cliente envía un segmento TCP con el indicador ACK al servidor para confirmar que se ha establecido la conexión.

2. Protocolo de enlace de cuatro vías TCP:

   • Primera ola (FIN): cuando el cliente decide cerrar la conexión, envía un segmento TCP con el bit de bandera FIN (fin) al servidor, lo que indica que el cliente ya no enviará datos.
   • Segunda ola (ACK): después de recibir el FIN del cliente, el servidor envía un segmento TCP con el indicador ACK al cliente, lo que indica que ha recibido la solicitud de apagado del cliente.
   • La tercera ola (FIN): cuando el servidor determina que está listo para cerrar la conexión, envía un segmento TCP con el indicador FIN al cliente , lo que indica que el servidor ya no enviará datos.
   • La cuarta ola (ACK): ** Después de recibir el FIN del servidor, el cliente envía un segmento TCP con el indicador ACK al servidor, ** confirmando la recepción de la solicitud de apagado del servidor.

¿Por qué saludar cuatro veces en lugar de tres?

• Esto se debe a que al cerrar la conexión, es posible que tanto el cliente como el servidor aún tengan datos sin enviar, y es necesario asegurarse de que la otra parte haya completado la recepción de los datos antes de que la conexión pueda cerrarse de forma segura.
• Durante las cuatro oleadas, el segmento ACK de la última oleada (la cuarta oleada) se utiliza para confirmar que el cliente ha recibido la solicitud de apagado del servidor, en lugar de transmitir datos , para garantizar que ambas partes sepan que la otra parte ha La conexión se cerró.
• En pocas palabras, las cuatro ondas sirven para garantizar que ambas partes puedan cerrar la conexión de forma segura y confirmar que se ha recibido la solicitud de cierre de la otra parte.

¿ Por qué esperar a 2MSL ? Referirse a

• MSL es el tiempo máximo de supervivencia de un paquete. Es el tiempo más largo para que cualquier paquete sobreviva en la red. Los mensajes que excedan este tiempo serán descartados.

• El cliente espera 2MSL después de enviar el ACK para evitar la pérdida de paquetes.
  En este caso, el servidor nunca recibirá una respuesta del cliente, por lo que esta situación es similar a la situación de solo saludar tres veces. Si el servidor no recibe una respuesta, el servidor no puede saber si el cliente ha recibido la interrupción del servidor. Solicitud abierta.

• Si el cliente lo recibe, está bien, todos contentos, tanto el cliente como el servidor se desconectan, si el cliente no lo recibe, el cliente sigue ahí esperando estúpidamente a que el servidor siga enviando mensajes.
  El servidor no puede determinar si el cliente lo ha recibido. Esta situación en sí misma no es confiable. ¿No le sucedería esta situación a la llamada conexión TCP confiable? ¿No se reirían de ella?

• Por lo tanto, existe una situación en la que el cliente tiene que esperar 2MSL. Para garantizar que el último mensaje saludado del cliente pueda llegar al servidor, si se pierde el cuarto segmento del mensaje saludado,!

• ¡El servidor expirará y retransmitirá el tercer segmento del mensaje saludado! ! ! ! ! !

• Entonces, el cliente no ingresa CERRADO directamente, sino que mantiene TIME_WAIT (esperar 2MSL es TIME_WAIT) ¡y funciona! ! ! ,

• Al recibir la solicitud de tiempo de espera de la tercera ola del servidor y retransmisión para desconectarse, el cliente continuará enviando un mensaje de cuarta ola al servidor.

• Puede garantizar que la otra parte (servidor) reciba el mensaje de respuesta del cliente y, finalmente, el cliente y el servidor cierren la conexión correctamente. !

• Esperar 2MSL es para garantizar que los paquetes hayan caducado y evitar confusiones cuando se establezca la conexión la próxima vez .

¿Por qué no dos o cuatro veces?

• "Dos apretones de manos": no puede evitar el establecimiento de conexiones históricas, lo que provocará un desperdicio de recursos en ambas partes , y también es imposible sincronizar de manera confiable los números de serie de ambas partes ;
  "Cuatro apretones de manos": tres apretones de manos son los teóricos mínimo para un establecimiento de conexión confiable, y los dos del medio se pueden fusionar. Los apretones de manos se pueden fusionar , por lo que no es necesario utilizar más tiempos de comunicación. El último tercer apretón de manos puede transportar datos.

¿Por qué se requiere que el número de secuencia de inicialización sea diferente cada vez que se realiza una conexión TCP?

Hay dos razones principales:

• Para evitar que la siguiente conexión reciba mensajes históricos con la misma tupla de cuatro (aspecto principal);
• Por razones de seguridad, la otra parte evita que los mensajes TCP con el mismo número de secuencia falsificados por piratas informáticos sean recibidos por la otra parte;

A continuación, hablemos del primer punto en detalle.

• Supongamos que cada vez que se establece una conexión, los números de secuencia de inicialización del cliente y el servidor comienzan desde 0: el
  cliente y el servidor establecen una conexión TCP, el cliente envía un paquete de datos, la red lo bloquea y luego se agota el tiempo de espera. y retransmite el paquete de datos, en este momento el dispositivo servidor se apaga y reinicia, y la conexión previamente establecida con el cliente desaparece, por lo que se envía un mensaje RST al recibir el paquete de datos del cliente.
  Inmediatamente después, el cliente estableció una conexión con la misma tupla de cuatro que la
  conexión anterior con el servidor; después de que se estableció la nueva conexión, el paquete de datos bloqueado por la red en la conexión anterior llegó al servidor y el paquete de datos sucedió. to be El número de secuencia se encuentra dentro de la ventana de recepción del servidor, por lo que el servidor recibirá el paquete de datos normalmente, lo que provocará confusión en los datos.
• Se puede ver que si los números de secuencia de inicialización del cliente y del servidor son los mismos cada vez que se establece una conexión, es fácil que la siguiente conexión reciba mensajes históricos con la misma tupla de cuatro.
• Por lo tanto, diferentes números de secuencia de inicialización cada vez pueden evitar en gran medida que los mensajes históricos sean recibidos por la siguiente conexión con la misma tupla de cuatro. Tenga en cuenta que en gran medida no se puede evitar por completo ( porque el número de secuencia se ajustará. , entonces el mecanismo de marca de tiempo debe usarse para juzgar mensajes históricos ,)

¿Cómo se genera aleatoriamente el número de secuencia inicial ISN?

El ISN inicial se basa en un reloj, +1 cada 4 microsegundos y una revolución tarda 4,55 horas.

RFC793 menciona el algoritmo de generación aleatoria del número de secuencia de inicialización ISN: ISN = M + F (localhost, localport, remotohost, remotoport).

M es un temporizador que aumenta en 1 cada 4 microsegundos.
F es un algoritmo Hash que genera un valor aleatorio basado en la IP de origen, la IP de destino, el puerto de origen y el puerto de destino. Para garantizar que el mundo exterior no pueda calcular fácilmente el algoritmo Hash, utilizar el algoritmo MD5 es una mejor opción.
Se puede ver que el número aleatorio se incrementará según el temporizador del reloj y es básicamente imposible generar aleatoriamente el mismo número de secuencia de inicialización.

¿Se perdieron los apretones de manos 1-3?

primero

• Cuando el cliente agota el tiempo de espera y retransmite mensajes SYN 3 veces, dado que tcp_syn_retries es 3, se ha alcanzado el número máximo de retransmisiones, por lo que esperará un rato (el tiempo es el doble del último tiempo de espera). la respuesta del servidor Después del segundo protocolo de enlace (mensaje SYN-ACK), el cliente se desconectará.

la segunda vez

• Debido a que el segundo mensaje de protocolo de enlace contiene el mensaje de confirmación ACK del primer protocolo de enlace con el cliente, si el cliente no recibe el segundo protocolo de enlace durante mucho tiempo, el cliente puede pensar que su propio mensaje SYN (el primer protocolo de enlace) se ha perdido, por lo que el cliente activará el mecanismo de retransmisión de tiempo de espera y retransmitirá el mensaje SYN.
• Luego, debido a que el segundo protocolo de enlace contiene el mensaje SYN del servidor, cuando el cliente lo recibe, necesita enviar un mensaje de confirmación ACK al servidor (el tercer protocolo de enlace), para que el servidor piense que el mensaje SYN ha sido recibido por el cliente Recibido.
• Luego, si se pierde el segundo protocolo de enlace, el servidor no recibirá el tercer protocolo de enlace, por lo que activará el mecanismo de retransmisión de tiempo de espera y retransmitirá el mensaje SYN-ACK.
• Por lo tanto, cuando se pierde el segundo protocolo de enlace, tanto el cliente como el servidor retransmitirán: el
  cliente retransmitirá el mensaje SYN, que es el primer protocolo de enlace, y el número máximo de retransmisiones está determinado por el parámetro del kernel tcp_syn_retries; el servidor
  retransmitirá Mensaje SYN-ACK, es decir, el segundo protocolo de enlace, el número máximo de retransmisiones está determinado por el parámetro del kernel tcp_synack_retries.
• Proceso específico:
• • Cuando el cliente agota el tiempo de espera y retransmite el mensaje SYN una vez, dado que tcp_syn_retries es 1, se ha alcanzado el número máximo de retransmisiones, por lo que espera un rato (el tiempo es el doble del último tiempo de espera). respuesta del servidor. Después del segundo protocolo de enlace (mensaje SYN-ACK), el cliente se desconectará.
• • Cuando el servidor agota el tiempo de espera y retransmite el mensaje SYN-ACK dos veces, dado que tcp_synack_retries es 2, se ha alcanzado el número máximo de retransmisiones, por lo que esperará un rato (el tiempo es el doble del último tiempo de espera). para recibir el tercer apretón de manos del cliente (mensaje ACK), el servidor se desconectará.

la tercera vez

• Debido a que el ACK del tercer protocolo de enlace es un mensaje de confirmación para el SYN del segundo protocolo de enlace, cuando se pierde el tercer protocolo de enlace, si el lado del servidor no recibe el mensaje de confirmación durante mucho tiempo, se activará un restablecimiento del tiempo de espera. , retransmita el mensaje SYN-ACK hasta que se reciba el tercer protocolo de enlace o se alcance el número máximo de retransmisiones.
• Tenga en cuenta que el mensaje ACK no se retransmitirá. Cuando se pierda el ACK, la otra parte retransmitirá el mensaje correspondiente.
• Cuando el servidor agota el tiempo de espera y retransmite el mensaje SYN-ACK dos veces, dado que tcp_synack_retries es 2, se ha alcanzado el número máximo de retransmisiones, por lo que esperará un rato (el tiempo es el doble del último tiempo de espera). para recibir el tercer apretón de manos del cliente (mensaje ACK), el servidor se desconectará.

¿Cómo programar Socket para TCP?

El servidor y el cliente inicializan el socket y obtienen el descriptor del archivo;
el servidor llama a bind para vincular el socket a la dirección IP y al puerto especificados; el
servidor llama a listening para escuchar;
el servidor llama a aceptar y espera a que el cliente se conecte;
el cliente Llame a conectar para iniciar una solicitud de conexión a la dirección y el puerto del servidor;
el servidor acepta devuelve el descriptor de archivo del socket utilizado para la transmisión;
el cliente llama a escribir para escribir datos; el servidor llama a leer para leer datos;
cuando el cliente se desconecta Se llamará a cerrar, luego, cuando el lado del servidor lea los datos, leerá EOF. Después de procesar los datos, el lado del servidor llama a cerrar, lo que indica que la conexión está cerrada.
Lo que hay que tener en cuenta aquí es que cuando las llamadas al servidor aceptan, si la conexión es exitosa, se devolverá un socket con una conexión completa, que se utilizará para transmitir datos más adelante.

Por lo tanto, el socket de escucha y el socket realmente utilizado para transmitir datos son "dos" sockets, uno se llama socket de escucha y el otro se llama socket de conexión completa.

Una vez que se establece una conexión exitosa, ambas partes comienzan a leer y escribir datos a través de las funciones de lectura y escritura, como escribir en una secuencia de archivos.

¿Se puede establecer una conexión TCP sin aceptar?

• Respuesta: Sí.
• La llamada al sistema accpet no participa en el proceso de protocolo de enlace de tres vías de TCP. Solo es responsable de sacar un socket con una conexión establecida de la cola de conexión completa de TCP. La capa de usuario obtiene el socket con una conexión establecida a través del sistema accpet. llamar y puede leer y escribir el socket.

¿Se puede establecer una conexión TCP sin escuchar?

• Respuesta: Sí.
• El cliente puede conectarse a sí mismo para formar una conexión (autoconexión TCP), o dos clientes pueden enviarse solicitudes entre sí para establecer una conexión al mismo tiempo (TCP se abre al mismo tiempo). Estas dos situaciones tienen una cosa en común, es decir, no hay participación del servidor, es decir, sin escuchar, se puede establecer una conexión TCP.

Implementar una aplicación TCP, espera y enlace de socket y otros procesos (preguntado)

TCP (Protocolo de control de transmisión) es un protocolo de capa de transporte confiable y orientado a la conexión que se utiliza para transmitir datos de manera confiable a través de una red. La siguiente es una breve descripción del proceso básico y los principios relacionados de la aplicación TCP:

1. Cree un socket: una aplicación TCP primero necesita crear un socket, que es el punto final de la comunicación de la red . Se puede crear un socket llamando a la función de socket proporcionada por el sistema operativo , que devuelve un descriptor de archivo que identifica de forma única el socket.
2. Vincular el socket: antes de usar el socket, debe vincularlo a una dirección y un puerto locales . Esto permite que otras aplicaciones se comuniquen con el socket especificando la dirección y el puerto. Las operaciones de enlace se pueden realizar utilizando la función de enlace.
3. Escucha de solicitudes de conexión: si la aplicación actúa como servidor, necesita escuchar las solicitudes de conexión entrantes. Al llamar a la función de escucha, el socket se configura en modo de escucha y especifica la cantidad máxima de solicitudes de conexión que se pueden poner en cola para su procesamiento .
4. Aceptar solicitudes de conexión: una vez que un cliente inicia una solicitud de conexión, el servidor debe aceptar la solicitud. Al llamar a la función de aceptación, el servidor bloquea y espera hasta que un cliente se conecta correctamente. La función de aceptación devuelve un nuevo socket que se utiliza para comunicarse con el cliente .
5. Realizar transferencia de datos: una vez establecida la conexión, los datos se pueden transferir entre el servidor y el cliente. Las aplicaciones pueden enviar y recibir datos utilizando las funciones de envío y recepción . El protocolo TCP garantiza una transmisión confiable de datos, incluidos mecanismos como la segmentación de datos, el reensamblaje, el control de flujo y el control de congestión.
6. Cierre la conexión: cuando se completa la transferencia de datos o es necesario cerrar la conexión, se puede llamar a la función de cierre para cerrar el socket . Al cerrar la conexión, el protocolo TCP realizará cuatro procesos de agitación para garantizar que ambas partes hayan completado la transmisión de datos y acuerden cerrar la conexión.

3、Socket = http+tcp

modelo de E/S

Una operación de entrada normalmente consta de dos etapas:

• Espere a que los datos estén listos
• Copiar datos del kernel al proceso.

Para operaciones de entrada en un socket,

• El primer paso normalmente implica esperar a que lleguen datos de la red . Cuando llegan los datos esperados, se copian en algún búfer del kernel.
• El segundo paso es copiar los datos del búfer del kernel al búfer de la aplicación.

Unix tiene cinco modelos de E/S:
E/S de bloqueo, E/S
sin bloqueo
, multiplexación de E/S (selección y sondeo)
, E/S controladas por señal (SIGIO)
, E/S asíncrona (AIO)

Bloqueo de E/S

• El proceso de la aplicación se bloquea hasta que los datos se copian del búfer del núcleo al búfer del proceso de la aplicación .
  Cabe señalar que durante el proceso de bloqueo también se pueden ejecutar otros procesos de la aplicación , por lo que el bloqueo no significa que se bloquee todo el sistema operativo. Debido a que aún se pueden ejecutar otros procesos de aplicación, no se consume tiempo de CPU y la utilización de CPU de este modelo será relativamente alta.
  En la siguiente figura, recvfrom () se usa para recibir datos del Socket y copiarlos al búfer del proceso de aplicación. Aquí recvfrom() se considera una llamada al sistema.

E/S sin bloqueo

• Después de que el proceso de la aplicación ejecuta la llamada al sistema, el kernel devuelve un código de error. El proceso de la aplicación puede continuar ejecutándose, pero necesita ejecutar continuamente llamadas al sistema para saber si se completa la E/S. Este método se llama sondeo .
  Debido a que la CPU tiene que manejar más llamadas al sistema, la utilización de la CPU de este modelo es menor .

multiplexación de E/S

• Utilice select o poll para esperar datos y puede esperar a que cualquiera de los múltiples sockets sea legible. Este proceso se bloqueará, regresará cuando un socket sea legible y luego usará recvfrom para copiar los datos del kernel al proceso.
• Permite que un solo proceso maneje múltiples eventos de E/S. También conocido como E/S controlada por eventos, E/S controlada por eventos.
• Si un servidor web no tiene multiplexación de E/S, entonces cada conexión de Socket necesita crear un subproceso para su procesamiento. Si hay decenas de miles de conexiones simultáneas, será necesario crear la misma cantidad de subprocesos. En comparación con la tecnología multiproceso y multiproceso, la reutilización de E/S no requiere la sobrecarga de creación y conmutación de subprocesos del proceso, y la sobrecarga del sistema es menor.

E/S impulsadas por señal

• El proceso de aplicación utiliza la llamada al sistema sigaction, el kernel regresa inmediatamente y el proceso de aplicación puede continuar ejecutándose, lo que significa que el proceso de aplicación no se bloquea durante la fase de espera de datos. El kernel envía una señal SIGIO al proceso de la aplicación cuando llegan los datos. Después de que el proceso de la aplicación los recibe, llama a recvfrom en el controlador de señales para copiar los datos del kernel al proceso de la aplicación.
• En comparación con el método de sondeo de E/S sin bloqueo, la utilización de la CPU de E/S controladas por señales es mayor.

E/S de cruce de peatones

• El proceso de aplicación regresará inmediatamente al ejecutar la llamada al sistema aio_read. El proceso de aplicación puede continuar ejecutándose sin ser bloqueado. El kernel enviará una señal al proceso de aplicación después de que se completen todas las operaciones.
• La diferencia entre E/S asíncronas y E/S controladas por señales es que la señal de E/S asincrónicas es para notificar al proceso de aplicación que la E/S se ha completado, mientras que la señal de E/S controlada por señales es para notificar al proceso de aplicación que E/S puede iniciar .

Comparación de los cinco principales modelos de E/S

• E/S síncrona: el proceso de la aplicación se bloquea durante la etapa de copia de datos del búfer del núcleo al búfer del proceso de la aplicación (la segunda etapa).
• E/S asíncrona: el proceso de solicitud de la segunda fase no se bloqueará.
• Las E/S síncronas incluyen E/S de bloqueo, E/S sin bloqueo, multiplexación de E/S y E/S controladas por señal. La principal diferencia entre ellas está en la primera etapa.
• Las E/S sin bloqueo, las E/S controladas por señales y las E/S asíncronas no se bloquean en la primera fase.

multiplexación de E/S

select/poll/epoll son todas implementaciones específicas de multiplexación de E / S. select apareció primero, seguido de poll y luego epoll.

seleccionar

• select permite que una aplicación monitoree un conjunto de descriptores de archivos, esperando que uno o más descriptores estén listos para completar una operación de E/S.
• fd_set se implementa usando una matriz y el tamaño de la matriz se define usando FD_SETSIZE, por lo que solo puede escuchar descriptores menores que el número de FD_SETSIZE. Hay tres tipos de descriptores: conjunto de lectura, conjunto de escritura y conjunto de excepción, que corresponden a conjuntos de descriptores para condiciones de lectura, escritura y excepción, respectivamente.
• timeout es el parámetro de tiempo de espera. Llamar a select se bloqueará hasta que llegue un evento con un descriptor o el tiempo de espera exceda el tiempo de espera.
• El resultado devuelto de una llamada exitosa es mayor que 0, el resultado devuelto de un error es -1 y el resultado de retorno de un tiempo de espera es 0.

encuesta

• La función de encuesta es similar a la de seleccionar y también espera a que uno de un conjunto de descriptores esté listo.
• El descriptor en poll es una matriz de tipo pollfd. La definición de pollfd es la siguiente:

Comparar

1. Las funciones
   de selección y encuesta son básicamente las mismas , pero difieren en algunos detalles de implementación.
   La selección modificará el descriptor, pero la encuesta no ;
   el tipo de descriptor de selección se implementa mediante una matriz y el tamaño FD_SETSIZE por defecto es 1024, por lo que solo puede monitorear menos de 1024 descriptores de forma predeterminada.
   Si desea escuchar más descriptores, debe modificar FD_SETSIZE y luego volver a compilar; poll no tiene límite en la cantidad de descriptores;
   poll proporciona más tipos de eventos y la reutilización de descriptores es mayor que select .
   Si un hilo llama a seleccionar o sondear en un descriptor y otro hilo cierra el descriptor, el resultado de la llamada será incierto .
2. La selección de velocidad
   y el sondeo son relativamente lentos y cada llamada requiere copiar todos los descriptores del búfer del proceso de la aplicación al búfer del núcleo .
3. Portabilidad
   Casi todos los sistemas admiten la selección, pero sólo los sistemas más nuevos admiten la encuesta.

epoll_ctl()

• Se utiliza para registrar un nuevo descriptor en el kernel o cambiar el estado de un descriptor de archivo. Los descriptores registrados se mantendrán en un árbol rojo-negro en el kernel. A través de la función de devolución de llamada, el kernel agregará los descriptores preparados de E/S a una lista vinculada para su administración. El proceso puede llamar a epoll_wait() para completar el evento. descriptor.
• Como se puede ver en la descripción anterior, epoll solo necesita copiar el descriptor del búfer del proceso al búfer del núcleo una vez, y el proceso no necesita realizar una encuesta para obtener el descriptor de finalización del evento.
• epoll sólo funciona en el sistema operativo Linux.
  epoll es más flexible que select y poll y no tiene límite en el número de descriptores.
• epoll es más amigable para la programación de subprocesos múltiples. Si un subproceso llama a epoll_wait () y otro subproceso cierra el mismo descriptor, no causará situaciones inciertas como seleccionar y sondear.

Hay dos modos de activación para eventos de descriptor en el modo de trabajo epoll : LT (activador de nivel) y ET (activador de flanco).

1. Modo LT
   Cuando epoll_wait() detecta la llegada de un evento descriptor, notifica al proceso del evento. El proceso no necesita procesar el evento inmediatamente. El proceso será notificado nuevamente la próxima vez que se llame a epoll_wait(). Es el modo predeterminado y admite tanto bloqueo como no bloqueo.
2. 
   La diferencia entre el modo ET y el modo LT es que el proceso debe procesar el evento inmediatamente después de la notificación. La próxima vez que se llame a epoll_wait(), no se le notificará la llegada del evento.

Reduce en gran medida la cantidad de veces que el evento epoll se activa repetidamente, por lo que la eficiencia es mayor que la del modo LT. Solo se admite No-Blocking para evitar privar de tareas que procesan múltiples descriptores de archivos debido al bloqueo de operaciones de lectura/escritura en un identificador de archivo.

Escenarios de aplicación
Es fácil tener la ilusión de que usar epoll es suficiente. Tanto select como poll están desactualizados. De hecho, tienen sus propios escenarios de uso .

1. Seleccionar escenario de aplicación La precisión del parámetro de tiempo de espera
   de select es microsegundos , mientras que poll y epoll son milisegundos, por lo que select es más adecuado para escenarios con altos requisitos de tiempo real, como el control de reactores nucleares . select es más portátil y es compatible con casi todas las plataformas principales.
   

2. escenario de aplicación de encuesta
   La encuesta no tiene límite en el número máximo de descriptores . Si la plataforma lo admite y los requisitos en tiempo real no son altos , se debe utilizar encuesta en lugar de seleccionar.

3. El escenario de la aplicación epoll
   solo necesita ejecutarse en la plataforma Linux, hay una gran cantidad de descriptores que deben sondearse al mismo tiempo y estas conexiones son preferiblemente conexiones largas.
   Si necesita monitorear menos de 1000 descriptores al mismo tiempo, no es necesario usar epoll porque las ventajas de epoll no se pueden reflejar en este escenario de aplicación.
   Hay muchos cambios en el estado del descriptor que deben monitorearse y todos son de muy corta duración, por lo que no es necesario usar epoll.
   Debido a que todos los descriptores en epoll se almacenan en el kernel , cada vez que es necesario cambiar el estado del descriptor, se debe realizar una llamada al sistema a través de epoll_ctl(). Las llamadas frecuentes al sistema reducen la eficiencia .
   Y el descriptor de epoll se almacena en el kernel y no es fácil de depurar.

4. Otros protocolos en la capa de aplicación/transporte

Cálculo del retraso de transmisión (por Wangdao)

Funciones de la capa de presentación y la capa de sesión (por Wang Dao)

Capa de aplicación (por ciclado)

• El sistema de nombres de dominio
  DNS es una base de datos distribuida que proporciona servicios para la conversión entre nombres de host y direcciones IP. La base de datos distribuida aquí significa que cada sitio solo conserva su propia parte de los datos.
  Los nombres de dominio tienen una estructura jerárquica, de arriba a abajo: nombre de dominio raíz, nombre de dominio de nivel superior y nombre de dominio de segundo nivel.
  El DNS se puede transmitir mediante UDP o TCP y el número de puerto utilizado es 53. En la mayoría de los casos, DNS utiliza UDP para la transmisión, lo que requiere que tanto el solucionador de nombres de dominio como el servidor de nombres de dominio manejen los tiempos de espera y las retransmisiones para garantizar la confiabilidad. TCP se utilizará para la transmisión en dos casos:
  si la respuesta devuelta supera los 512 bytes (UDP solo admite un máximo de 512 bytes de datos).
  Transferencia de zona (la transferencia de zona es la transferencia de los datos modificados desde el servidor de nombres de dominio primario al servidor de nombres de dominio secundario).

• El protocolo de transferencia de archivos
  FTP utiliza TCP para conectarse, lo que requiere dos conexiones para transferir un archivo:
  Conexión de control: el servidor abre el puerto número 21 y espera la conexión del cliente. Después de que el cliente establece activamente una conexión, utiliza esta conexión para transmitir el comandos al servidor y transmite de vuelta la respuesta del servidor.
  Conexión de datos: se utiliza para transferir datos de un archivo.
  Dependiendo de si el servidor establece activamente la conexión de datos, FTP tiene dos modos: modo activo y pasivo: Modo
  activo: el servidor establece activamente una conexión de datos, donde el número de puerto del servidor es 20 y el número de puerto del cliente es aleatorio. pero debe ser mayor que 1024, porque 0 ~1023 es un número de puerto bien conocido.
  Modo pasivo: el cliente establece activamente una conexión de datos, en la que el número de puerto del cliente lo especifica el propio cliente y el número de puerto del servidor es aleatorio .
  El modo activo requiere que el cliente abra el número de puerto al servidor y es necesario configurar el firewall del cliente. El modo pasivo solo requiere un número de puerto abierto en el lado del servidor y no requiere una configuración de firewall en el lado del cliente. Pero el modo pasivo puede debilitar la seguridad en el lado del servidor porque se abren demasiados números de puerto.

• DHCP (Protocolo de configuración dinámica
  de host) proporciona un método de red plug-and-play y los usuarios ya no necesitan configurar manualmente las direcciones IP y otra información.
  El contenido de la configuración DHCP no es sólo la dirección IP, sino también la máscara de subred y la dirección IP de la puerta de enlace.
  El proceso de trabajo de DHCP es el siguiente:
  el cliente envía un mensaje Discover, la dirección de destino del mensaje es 255.255.255.255:67, la dirección de origen es 0.0.0.0:68, se coloca en UDP y el mensaje se transmite a la misma subred en todos los hosts. Si el cliente y el servidor DHCP no están en la misma subred, deberá utilizar un agente de retransmisión.
  Después de recibir el mensaje Discover, el servidor DHCP envía un mensaje de oferta al cliente, que contiene la información requerida por el cliente. Debido a que el cliente puede recibir información de múltiples servidores DHCP, el cliente debe elegir.
  Si el cliente selecciona la información proporcionada por un servidor DHCP, envía un mensaje de solicitud al servidor DHCP.
  El servidor DHCP envía un mensaje de confirmación para indicar que el cliente puede utilizar la información que se le proporciona en este momento.

• El protocolo de inicio de sesión remoto
  TELNET se utiliza para iniciar sesión en el host remoto y también se devuelve la salida del host remoto.
  TELNET puede adaptarse a muchas diferencias entre computadoras y sistemas operativos, como definiciones de caracteres de nueva línea para diferentes sistemas operativos.

• Protocolo de correo electrónico
  Un sistema de correo electrónico consta de tres partes: agente de usuario, servidor de correo y protocolo de correo electrónico.
  Los protocolos de correo electrónico incluyen protocolos de envío y protocolos de lectura. SMTP se usa comúnmente como protocolo de envío y POP3 e IMAP se usan comúnmente como protocolos de lectura.

1. SMTP
   SMTP sólo puede enviar códigos ASCII, mientras que las Extensiones de correo de Internet MIME pueden enviar archivos binarios. MIME no cambia ni reemplaza SMTP, pero aumenta la estructura del cuerpo del correo electrónico y define reglas de codificación no ASCII.
2. POP3
   La característica de POP3 es que mientras el usuario lea el correo electrónico del servidor, el correo electrónico se elimina. Pero la última versión de POP3 no puede eliminar correos electrónicos.
3. IMAP
   En el protocolo IMAP, los correos electrónicos del cliente y el servidor se mantienen sincronizados. Si los correos electrónicos no se eliminan manualmente, los correos electrónicos del servidor no se eliminarán. IMAP permite a los usuarios acceder a los correos electrónicos en el servidor en cualquier momento y en cualquier lugar.

• Proceso de solicitud de página web

1. Información del host de configuración de DHCP
   Suponiendo que el host no tiene una dirección IP ni otra información al principio, primero debe usar DHCP para obtenerla.
   El host genera un mensaje de solicitud DHCP y coloca el mensaje en un segmento UDP con el puerto de destino 67 y el puerto de origen 68.
   El segmento se coloca en un datagrama IP con una dirección IP de destino de transmisión (255.255.255.255) y una dirección IP de origen (0.0.0.0).
   El datagrama se coloca en una trama MAC con la dirección de destino FF:FF:FF:FF:FF:FF y se transmitirá a todos los dispositivos conectados al conmutador.
   Después de que el servidor DHCP conectado al conmutador recibe la trama de transmisión, la descompone continuamente hacia arriba para obtener el datagrama IP, el segmento UDP y el mensaje de solicitud DHCP, y luego genera un mensaje DHCP ACK, que contiene la siguiente información: dirección IP, DNS dirección IP del servidor, dirección IP del enrutador de puerta de enlace predeterminada y máscara de subred. El mensaje se coloca en un segmento de mensaje UDP, el segmento de mensaje UDP se coloca en un datagrama IP y, finalmente, en una trama MAC.
   La dirección de destino de esta trama es la dirección MAC del host solicitante. Debido a que el conmutador tiene capacidad de autoaprendizaje, después de que el host envió la trama de transmisión anterior, registró la entrada de la tabla de conmutación de la dirección MAC en su interfaz de reenvío, por lo que ahora el conmutador puede saber directamente qué dirección debe enviar y la interfaz envía la trama.
   Después de recibir la trama, el host la descompone continuamente para obtener mensajes DHCP. Luego configura su dirección IP, máscara de subred y dirección IP del servidor DNS e instala una puerta de enlace predeterminada en su tabla de reenvío de IP.

2. ARP resuelve la dirección MAC,
   el host genera un socket TCP a través del navegador y el socket envía una solicitud HTTP al servidor HTTP. Para generar este socket, el host necesita conocer la dirección IP correspondiente al nombre de dominio del sitio web.
   El host genera un mensaje de consulta DNS, que tiene el número de puerto 53, porque el número de puerto del servidor DNS es 53.
   El mensaje de consulta DNS se coloca en un datagrama IP cuya dirección de destino es la dirección IP del servidor DNS.
   El datagrama IP se coloca en una trama Ethernet, que se envía al enrutador de puerta de enlace.
   El proceso DHCP solo conoce la dirección IP del enrutador de puerta de enlace. Para obtener la dirección MAC del enrutador de puerta de enlace, se requiere el protocolo ARP.
   El host genera un mensaje de consulta ARP que contiene la dirección IP del enrutador de puerta de enlace, coloca el mensaje de consulta ARP en una trama Ethernet con una dirección de destino de transmisión (FF:FF:FF:FF:FF:FF) y envía la trama Ethernet a el conmutador, que reenvía la trama a todos los dispositivos conectados, incluido el enrutador de puerta de enlace.
   Después de recibir la trama, el enrutador de puerta de enlace descompone continuamente el mensaje ARP hacia arriba y descubre que la dirección IP que contiene coincide con la dirección IP de su interfaz, por lo que envía un mensaje de respuesta ARP, incluida su dirección MAC, de regreso al host.

3. DNS resuelve el nombre de dominio
   Después de conocer la dirección MAC del enrutador de puerta de enlace, puede continuar con el proceso de resolución de DNS.
   Después de recibir la trama Ethernet que contiene el mensaje de consulta DNS, el enrutador de puerta de enlace extrae el datagrama IP y determina el enrutador al que se debe reenviar el datagrama IP según la tabla de reenvío.
   Debido a que el enrutador tiene dos protocolos de enrutamiento: protocolo de puerta de enlace interior (RIP, OSPF) y protocolo de puerta de enlace exterior (BGP), las entradas de enrutamiento desde el enrutador de puerta de enlace al servidor DNS se han configurado en la tabla de enrutamiento.
   Después de llegar al servidor DNS, el servidor DNS extrae el mensaje de consulta DNS y busca en la base de datos DNS el nombre de dominio que se va a resolver.
   Después de encontrar el registro DNS, envíe un mensaje de respuesta DNS, coloque el mensaje de respuesta en un segmento UDP, luego colóquelo en un datagrama IP, reenvíelo al enrutador de puerta de enlace a través del enrutador y llegue al host a través del conmutador Ethernet.

4. Página de solicitud HTTP
   Con la dirección IP del servidor HTTP, el host puede generar un socket TCP, que se utilizará para enviar mensajes HTTP GET al servidor web.
   Antes de generar un socket TCP, se debe realizar un protocolo de enlace de tres vías con el servidor HTTP para establecer una conexión. Genere un segmento TCP SYN con el puerto de destino 80 y envíe el segmento al servidor HTTP.
   Después de recibir el segmento, el servidor HTTP genera un segmento TCP SYN ACK y lo envía de regreso al host.
   Una vez establecida la conexión, el navegador genera un mensaje HTTP GET y lo entrega al servidor HTTP.
   El servidor HTTP lee el mensaje HTTP GET del socket TCP, genera un mensaje de respuesta HTTP, coloca el contenido de la página web en el cuerpo del mensaje y lo envía de regreso al host.
   Después de recibir el mensaje de respuesta HTTP, el navegador extrae el contenido de la página web y luego procesa y muestra la página web.

Capa de transporte (por ciclo)

La capa de red solo envía el paquete al host de destino, pero la comunicación real no es el host sino el proceso en el host. La capa de transporte proporciona comunicación lógica entre procesos. La capa de transporte protege los detalles centrales de la capa de red subyacente de los usuarios de alto nivel, haciendo que la aplicación parezca como si hubiera un canal de comunicación lógico de extremo a extremo entre las dos entidades de la capa de transporte.

El protocolo de datagramas de usuario UDP (Protocolo de datagramas de usuario) no tiene conexión, se entrega tanto como sea posible, no tiene control de congestión y está orientado a mensajes (los mensajes pasados ​​por la aplicación no se fusionan ni dividen, solo agregan encabezados UDP), admitidos Uno Comunicación interactiva uno a uno, uno a muchos, muchos a uno y muchos a muchos.

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, control de congestión, proporciona comunicación full-duplex y está orientado a flujos de bytes (los mensajes transmitidos desde la capa de aplicación se consideran como bytes). flujos. Organice el flujo de bytes en bloques de datos de diferentes tamaños), y cada conexión TCP solo puede ser punto a punto (uno a uno).

Protocolo de enlace TCP de tres vías
Supongamos que A es el cliente y B es el servidor.
Primero, B está en estado ESCUCHAR, esperando la solicitud de conexión del cliente.
A envía un mensaje de solicitud de conexión a B, con SYN=1, ACK=0, y selecciona un número de secuencia inicial x.
B recibe el mensaje de solicitud de conexión y, si acepta establecer la conexión, envía un mensaje de confirmación de conexión a A, con SYN=1, ACK=1, el número de confirmación es x+1 y también selecciona un número de secuencia inicial y. .
Después de que A recibe el mensaje de confirmación de conexión de B, también envía una confirmación a B. El número de confirmación es y+1 y el número de secuencia es x+1.
Después de que B recibe la confirmación de A, se establece la conexión.

El motivo del protocolo de enlace de tres vías
: El tercer protocolo de enlace es para evitar que solicitudes de conexión no válidas lleguen al servidor y provoquen que el servidor abra la conexión incorrectamente.
Si la solicitud de conexión enviada por el cliente se atasca en la red, llevará mucho tiempo recibir la confirmación de conexión enviada por el servidor. Después de que el cliente espere un período de retransmisión de tiempo de espera, volverá a solicitar la conexión. Pero esta solicitud de conexión bloqueada eventualmente llegará al servidor. Si no se realiza el protocolo de enlace de tres vías, el servidor abrirá dos conexiones.
Si hay un tercer apretón de manos, el cliente ignorará la confirmación de conexión enviada más tarde por el servidor para la solicitud de conexión bloqueada y no realizará el tercer apretón de manos, por lo que la conexión no se volverá a abrir.

Las cuatro ondas de TCP
La siguiente descripción no analiza los números de secuencia y los números de confirmación, porque las reglas para los números de secuencia y los números de confirmación son relativamente simples. Y ACK no se analiza, porque ACK es 1 después de que se establece la conexión.
A envía un mensaje de liberación de conexión, FIN=1.
B envía una confirmación después de recibirla. En este momento, TCP está en un estado semicerrado. B puede enviar datos a A pero A no puede enviar datos a B.
Cuando B ya no necesita la conexión, envía un mensaje de liberación de conexión con FIN=1.
A envía una confirmación después de recibirla, ingresa al estado TIEMPO DE ESPERA y espera 2 MSL (tiempo máximo de supervivencia del mensaje) antes de liberar la conexión.
B libera la conexión después de recibir la confirmación de A.

El motivo de saludar cuatro veces:
después de que el cliente envió el mensaje de liberación de la conexión FIN, el servidor recibió el mensaje y entró en el estado CLOSE-WAIT. Este estado es para que el servidor envíe datos que aún no se han transferido . Una vez completada la transferencia, el servidor enviará un mensaje de liberación de conexión FIN.

El cliente TIME_WAIT
ingresa a este estado después de recibir el mensaje FIN del servidor. En este momento, no ingresa directamente al estado CERRADO, también necesita esperar el tiempo 2MSL establecido por el temporizador . Hay dos razones para hacer esto:
para garantizar que pueda llegar el último mensaje de confirmación. Si B no recibe el mensaje de confirmación enviado por A, reenviará el mensaje de solicitud de liberación de conexión y A espera un período de tiempo para manejar esta situación.
El propósito de esperar un período de tiempo es permitir que todos los paquetes generados durante la duración de esta conexión desaparezcan de la red, de modo que los paquetes de solicitud de conexión antiguos no aparezcan en la siguiente conexión nueva .

Transmisión confiable TCP

• TCP utiliza la retransmisión de tiempo de espera para lograr una transmisión confiable: si un segmento enviado no recibe confirmación dentro del período de tiempo de espera, entonces el segmento se retransmite.
• El tiempo que transcurre desde el envío de un segmento de mensaje hasta la recepción de la confirmación se denomina tiempo de ida y vuelta RTT, y el tiempo de ida y vuelta promedio ponderado RTTs

ventana deslizante tcp

• La ventana es parte del caché y se utiliza para almacenar temporalmente el flujo de bytes. El remitente y el receptor tienen cada uno una ventana. El receptor le dice al remitente el tamaño de su ventana a través del campo de ventana en el segmento TCP. El remitente establece su propio tamaño de ventana en función de este valor y otra información.
• Se permite enviar todos los bytes dentro de la ventana de envío y se permite recibir todos los bytes dentro de la ventana de recepción. Si el byte en el lado izquierdo de la ventana de envío ha sido enviado y confirmado, entonces deslice la ventana de envío una cierta distancia hacia la derecha hasta que el primer byte de la izquierda no sea enviado ni confirmado; el deslizamiento de la ventana de recepción es similar. Cuando los bytes en el lado izquierdo de la ventana hayan sido enviados, confirmados y entregados al host, deslice la ventana de recepción hacia la derecha.
• La ventana de recepción solo confirmará el último byte que llega en secuencia dentro de la ventana, por ejemplo, los bytes recibidos por la ventana de recepción son {31, 34, 35}, entre los cuales {31} llega en secuencia y {34, 35 } No, entonces sólo se confirma el byte 31. Después de que el remitente recibe el acuse de recibo de un byte, sabe que se han recibido todos los bytes anteriores a este byte.

Control de flujo TCP

• El control de flujo consiste en controlar la velocidad de envío del remitente para garantizar que el receptor tenga tiempo de recibir .
• El campo de ventana en el mensaje de confirmación enviado por el receptor se puede utilizar para controlar el tamaño de la ventana del remitente, afectando así la velocidad de envío del remitente. Establezca el campo de la ventana en 0 y el remitente no podrá enviar datos.

Control de congestión TCP

• Si la red está congestionada, los paquetes se perderán y el remitente continuará retransmitiendo, lo que provocará una mayor congestión en la red. Por lo tanto, cuando se produce congestión, se debe controlar la tarifa del remitente. Esto es muy similar al control de flujo, pero el punto de partida es diferente.
• El control de flujo es para permitir que el receptor reciba a tiempo, mientras que el control de congestión es para reducir el nivel de congestión de toda la red.
• TCP utiliza principalmente cuatro algoritmos para controlar la congestión: inicio lento, evitación de congestión, retransmisión rápida y recuperación rápida.
  El remitente necesita mantener una variable de estado llamada ventana de congestión (cwnd). Tenga en cuenta la diferencia entre la ventana de congestión y la ventana del remitente: la ventana de congestión es solo una variable de estado, y es la ventana del remitente la que realmente determina cuántos datos el el remitente puede enviar.
  Para facilitar la discusión, se hacen las siguientes suposiciones:
  el receptor tiene un buffer de recepción lo suficientemente grande, por lo que no ocurrirá control de flujo;
  aunque la ventana de TCP se basa en bytes, la unidad de tamaño de la ventana se establece como un segmento de mensaje.

1. Inicio lento y prevención de congestión
   La ejecución inicial del envío es un inicio lento. Sea cwnd = 1. El remitente solo puede enviar 1 segmento. Después de recibir la confirmación, cwnd se duplica, por lo que el número de segmentos que el remitente puede enviar es: 2 , 4, 8...
   Tenga en cuenta que el inicio lento duplicará el cwnd en cada ronda, lo que hará que el cwnd crezca muy rápido, lo que hará que la velocidad de envío del remitente crezca demasiado rápido y la posibilidad de congestión de la red sea mayor. Establezca un umbral de inicio lento ssthresh. Cuando cwnd> = ssthresh, se ingresa para evitar la congestión y solo cwnd aumenta en 1 en cada ronda.
   Si se agota el tiempo de espera, establezca ssthresh = cwnd / 2 y luego vuelva a ejecutar el inicio lento.

2. Retransmisión rápida y recuperación rápida
   : en el lado receptor, se requiere que cada vez que se reciba un segmento de mensaje, se reconozca el último segmento de mensaje ordenado recibido. Por ejemplo, se han recibido M1 y M2, y cuando se recibe M4, se debe enviar un acuse de recibo para M2.
   Del lado del remitente, si se reciben tres acuses de recibo duplicados, se sabe que el siguiente segmento se pierde, en este momento se realiza una retransmisión rápida y el siguiente segmento se retransmite inmediatamente. Por ejemplo, si se reciben tres M2, M3 se perderá y M3 se retransmitirá inmediatamente.
   En este caso, sólo se pierden segmentos individuales, no la congestión de la red. Por lo tanto, se realiza una recuperación rápida, configurando ssthresh = cwnd / 2, cwnd = ssthresh. Tenga en cuenta que en este momento se ingresa directamente para evitar la congestión.
   La velocidad de inicio lento y recuperación rápida se refiere al valor de configuración de cwnd, no a la tasa de crecimiento de cwnd. El cwnd de inicio lento se establece en 1 y el cwnd de recuperación rápida se establece en ssthresh.

5. OSI (red de enlace físico)

IP de capa de red (por Xiao Lin)

• IP está en la tercera capa, la capa de red, en el modelo de referencia TCP/IP.
• La función principal de la capa de red es realizar la comunicación entre hosts, también llamada comunicación de un extremo a otro.

¿Cuál es la relación entre la capa de red y la capa de enlace de datos?

• Algunos amigos no pueden distinguir la diferencia y la relación entre IP (capa de red) y MAC (capa de enlace de datos).
• De hecho, es fácil de distinguir: como sabemos anteriormente, la función de IP es la comunicación entre hosts, mientras que la función de MAC es lograr la comunicación entre dos dispositivos que están "directamente conectados", y IP es responsable de la comunicación entre Dispositivos "no conectados directamente" Transmisión de comunicación entre las dos redes.
• De hecho, lo mismo ocurre con la transmisión de paquetes de datos en la red: la dirección IP de origen y la dirección IP de destino no cambiarán durante el proceso de transmisión (premisa: no se utiliza ninguna red NAT), solo la dirección MAC de origen y la dirección MAC de destino siguen cambiando. .

Clasificación de direcciones IP

• En los primeros días de Internet, las direcciones IP abundaban, por lo que los informáticos diseñaron direcciones clasificadas.
  Las direcciones IP se clasifican en 5 tipos, a saber, Clase A, Clase B, Clase C, Clase D y Clase E.
• Entre ellas, las categorías A, B y C se dividen principalmente en dos partes, a saber, el número de red y el número de host. Esto es fácil de entender, por ejemplo, Xiaolin es el número 101, edificio 1, comunidad A, y usted es el número 101, edificio 1, comunidad B.
• ¿Cómo se calcula la cantidad máxima de hosts para direcciones de categoría A, B y C?
  El número máximo de hosts depende de la cantidad de dígitos en el número de host. Por ejemplo, el número de host de una dirección de Clase C ocupa 8 dígitos, luego el número máximo de hosts para una dirección de Clase C: los números de host son todos 1. Para especificar todos los hosts en una determinada red,
  use Para transmisión,
  el número de host es todo 0 y especifica una red.

¿Para qué se utilizan las direcciones de multidifusión?

• La multidifusión se utiliza para enviar paquetes a todos los hosts dentro de un grupo específico.
  Sigue siendo un ejemplo de clase. El profesor dijo: "Estudiantes de la última fila, vengan y resuelvan este problema de matemáticas". El profesor designó a los estudiantes de la última fila, que es el significado de multidifusión.
• Dado que la transmisión no puede penetrar el enrutamiento, si desea enviar el mismo paquete a otros segmentos de la red, puede utilizar la multidifusión que puede penetrar el enrutamiento.
• Los primeros cuatro dígitos de la dirección de Clase D utilizada por la multidifusión son 1110, lo que significa que es una dirección de multidifusión, y los 28 dígitos restantes son el número del grupo de multidifusión.
  Desde 224.0.0.0 ~ 239.255.255.255 son los rangos de multidifusión disponibles, los cuales se dividen en las siguientes tres categorías:
  224.0.0.0 ~ 224.0.0.255 son direcciones de multidifusión reservadas, que solo se pueden usar en la LAN y el enrutador no reenviarlos. de.
  224.0.1.0 ~ 238.255.255.255 son direcciones de multidifusión disponibles para los usuarios y se pueden utilizar en Internet.
  239.0.0.0 ~ 239.255.255.255 son direcciones de multidifusión de administración local, que la intranet puede usar internamente y solo son válidas dentro de un ámbito local específico.

Ventajas de la clasificación IP

• Cuando un enrutador o host resuelve una dirección IP, determinamos si el primer bit de la dirección IP es 0. Si es 0, es una dirección de Clase A y podemos encontrar rápidamente la dirección de red y la dirección del host.
  

El flujo de trabajo de resolución de nombres de dominio.
El navegador primero verifica si está en su caché. Si no está allí, solicita el caché del sistema operativo. Si no está allí, verifica los hosts del archivo de resolución de nombres de dominio local. Si todavía no existe, consulta al servidor DNS, el proceso es el siguiente:
el cliente primero enviará una solicitud DNS, preguntando cuál es la IP de www.server.com y la enviará al servidor DNS local (es decir , la dirección del servidor DNS completada en la configuración TCP/IP del cliente).
Después de que el servidor de nombres de dominio local recibe la solicitud del cliente, si se puede encontrar www.server.com en la tabla del caché, devolverá directamente la dirección IP. De lo contrario, el DNS local le preguntará a su servidor de nombres de dominio raíz: "Jefe, ¿puede decirme la dirección IP de www.server.com?" El servidor de nombres de dominio raíz es el nivel más alto. No se utiliza directamente para nombres de dominio. resolución, pero puede indicar un camino.
Después de que el DNS raíz recibe la solicitud del DNS local, encuentra que el sufijo es .com y dice: "El nombre de dominio www.server.com es administrado por la zona .com". Te daré el .com dirección del servidor de nombres de dominio de nivel superior. Puedes preguntar Solo pregúntalo. "
Después de que el DNS local recibe la dirección del servidor de nombres de dominio de nivel superior, inicia una solicitud y pregunta: "Chico, ¿puedes decirme la dirección IP de www.server.com? "
El servidor de nombres de dominio de nivel superior dijo: "Le daré la dirección del servidor DNS autorizado responsable del área www.server.com. Debería poder preguntarlo". El
DNS local luego se volvió para preguntar al servidor autorizado. Servidor DNS: "El tercer hijo, www.server ¿Cuál es la IP correspondiente a .com? "El servidor DNS autorizado de server.com es la fuente original de los resultados de la resolución de nombres de dominio. ¿Por qué se llama autoritativo? Es mi nombre de dominio lo que yo decido. Después de realizar la consulta, el servidor DNS autorizado le indicará al DNS local la dirección IP correspondiente
. XXXX.
Luego, el DNS local devuelve la dirección IP al cliente y el cliente establece una conexión con el objetivo.
En este punto, hemos completado el proceso de resolución de DNS. Ahora, para resumir, hice un dibujo de todo el proceso.

ARP

• Al transmitir un datagrama IP, después de determinar la dirección IP de origen y la dirección IP de destino, el siguiente salto del paquete de datos IP se determinará a través de la "tabla de enrutamiento" del host. Sin embargo, la siguiente capa debajo de la capa de red es la capa de enlace de datos, por lo que también necesitamos saber la dirección MAC del "siguiente salto".
• Dado que la dirección IP del siguiente salto se puede encontrar en la tabla de enrutamiento del host, la dirección MAC del siguiente salto se puede obtener mediante el protocolo ARP.
• Entonces, ¿cómo sabe ARP la dirección MAC de la otra parte?
• En pocas palabras, ARP determina la dirección MAC con la ayuda de dos tipos de paquetes, solicitud ARP y respuesta ARP.
  El host enviará una solicitud ARP mediante transmisión. Este paquete contiene la dirección IP del host que desea conocer la dirección MAC.
  Cuando todos los dispositivos en el mismo enlace reciben una solicitud ARP, descomprimirán el contenido del paquete de solicitud ARP. Si la dirección IP de destino en el paquete de solicitud ARP es consistente con su propia dirección IP, entonces el dispositivo enviará su propia dirección MAC. La dirección se introduce en un paquete de respuesta ARP y se devuelve al host.
  El sistema operativo generalmente almacena en caché la dirección MAC obtenida a través de ARP por primera vez, para que la próxima vez la dirección MAC correspondiente a la dirección IP se pueda encontrar directamente desde el caché.

¿Sabes qué es el protocolo RARP?

• El protocolo ARP utiliza una dirección IP conocida para encontrar una dirección MAC, mientras que el protocolo RARP es todo lo contrario: utiliza una dirección MAC conocida para encontrar una dirección IP. Por ejemplo, se utiliza a menudo cuando se conectan a la red pequeños dispositivos integrados, como servidores de impresoras.
  Por lo general, esto requiere configurar un servidor RARP y registrar la dirección MAC del dispositivo y su dirección IP en este servidor. Luego conecte el dispositivo a la red y luego:
  el dispositivo enviará un mensaje de solicitud "Mi dirección MAC es XXXX, dígame cuál debe ser mi dirección IP".
  Después de recibir este mensaje, el servidor RARP devuelve la información "el dispositivo con la dirección MAC es XXXX y la dirección IP es XXXX" al dispositivo.
  Finalmente, el dispositivo establece su propia dirección IP en función de la información de respuesta recibida del servidor RARP.

DHCP

• DHCP es muy común en nuestras vidas, nuestras computadoras suelen obtener direcciones IP de forma dinámica a través de DHCP, lo que ahorra en gran medida el tedioso proceso de asignación de información IP.
  A continuación, echemos un vistazo a cómo nuestra computadora obtiene IP mediante un proceso de 4 pasos.
  Permítanme explicarles primero: el proceso del cliente DHCP escucha el puerto número 68 y el proceso del servidor DHCP escucha el puerto número 67.

Estos 4 pasos:

• El cliente primero inicia un datagrama IP de un mensaje de descubrimiento DHCP (DHCP DISCOVER). Dado que el cliente no tiene una dirección IP y no conoce la dirección del servidor DHCP, utiliza comunicación de transmisión UDP y la dirección de destino de transmisión utilizada es 255.255. 255.255 (puerto 67) y utilice 0.0.0.0 (puerto 68) como dirección IP de origen. El cliente DHCP pasa el datagrama IP a la capa de enlace, que luego transmite la trama a todos los dispositivos de la red.
• Cuando el servidor DHCP recibe el mensaje de descubrimiento de DHCP, responde al cliente con un mensaje de oferta de DHCP (OFERTA DHCP). El paquete todavía utiliza la dirección de transmisión IP 255.255.255.255. La información del paquete transporta al servidor para proporcionar una dirección IP arrendable, una máscara de subred, una puerta de enlace predeterminada, un servidor DNS y un período de arrendamiento de la dirección IP.
• Después de recibir mensajes de oferta DHCP de uno o más servidores, el cliente selecciona un servidor y envía un mensaje de solicitud DHCP (DHCP REQUEST) al servidor seleccionado para responder y repetir los parámetros configurados.
• Finalmente, el servidor responde al mensaje de solicitud DHCP con un mensaje DHCP ACK y responde con los parámetros requeridos.
  Una vez que el cliente recibe el DHCP ACK, la interacción se completa y el cliente puede usar la dirección IP asignada por el servidor DHCP durante el período de arrendamiento.

Capa de red (por ciclo)

Enrutamiento (algoritmo, heterogéneo, protocolo, multidifusión) + reenvío (IPV4,6, IP móvil)

• Dado que la capa de red es el núcleo de toda Internet, debe mantenerse lo más simple posible. La capa de red hacia arriba solo proporciona servicios de datagramas interactivos simples, flexibles, sin conexión y de mejor esfuerzo.
  Utilizando el protocolo IP, se pueden conectar redes físicas heterogéneas para que la capa de red parezca una red unificada.

• Hay tres protocolos utilizados junto con el protocolo IP: (reenvío)
  Protocolo de resolución de direcciones ARP (Protocolo de resolución de direcciones)
  Protocolo de mensajes de control de Internet ICMP (Protocolo de mensajes de control de Internet)
  Protocolo de administración de grupos de Internet IGMP (Protocolo de administración de grupos de Internet)

• Versión de formato de datagrama IP (reenvío)
  : hay dos valores 4 (IPv4) y 6 (IPv6);
  longitud del encabezado: ocupa 4 bits, por lo que el valor máximo es 15. Un valor de 1 representa la longitud de una palabra de 32 bits, que es de 4 bytes. Dado que la longitud de la parte fija es de 20 bytes, este valor es al menos 5. Si la longitud del campo opcional no es un múltiplo entero de 4 bytes, se rellena con relleno final.
  Servicios Diferenciados: Se utilizan para obtener mejores servicios, generalmente no se utilizan.
  Longitud total: incluida la longitud del encabezado y la longitud de la parte de datos.
  Time to Live: TTL, que existe para evitar que datagramas que no se pueden entregar circulen por Internet. En unidades de saltos de enrutador, cuando el TTL es 0, el datagrama se descarta.
  Protocolo: indique qué protocolo se deben entregar los datos transportados para su procesamiento, como ICMP, TCP, UDP, etc.
  Suma de verificación del encabezado: debido a que la suma de verificación debe recalcularse cada vez que el datagrama pasa a través de un enrutador, la suma de verificación no incluye la parte de datos para reducir la carga de trabajo de cálculo.
  Identificación: Diferentes fragmentos de un mismo datagrama tienen el mismo identificador en el caso de que el datagrama sea demasiado largo y se produzca fragmentación.
  Desplazamiento del fragmento: junto con el identificador, utilizado en el caso de fragmentación. La unidad de desplazamiento del segmento es 8 bytes.

• Método de direccionamiento de direcciones IP (reenvío)
  El método de direccionamiento de direcciones IP ha pasado por tres etapas históricas:
  Clasificación
  Subredes
  Sin clasificar

1. La clasificación
   consta de dos partes, el número de red y el número de host. Las diferentes categorías tienen diferentes longitudes de números de red y son fijas.
   Dirección IP::= {<número de red>, <número de host>}
2. División de subred:
   divida la dirección IP de dos niveles en la dirección IP de tercer nivel tomando parte del campo del número de host como número de subred.
   Dirección IP::= {<número de red>, <número de subred>, <número de host>}
   Para utilizar una subred, se debe configurar una máscara de subred. La máscara de subred predeterminada de una dirección de Clase B es 255.255.0.0. Si la subred de la dirección de Clase B ocupa dos bits, entonces la máscara de subred es 11111111 11111111 11000000 00000000, que es 255.255.192.0.
   Tenga en cuenta que la existencia de la subred no es visible para las redes externas.
3. Sin clasificar
   El CIDR de direccionamiento sin clasificar elimina los conceptos de direcciones y subredes tradicionales de Clase A, Clase B y Clase C, y utiliza prefijos de red y números de host para codificar direcciones IP. La longitud del prefijo de red se puede cambiar según sea necesario.

• La capa de red ARP (reenvío) del Protocolo de resolución de direcciones
  implementa la comunicación entre hosts, mientras que la capa de enlace implementa la comunicación entre enlaces específicos. Por lo tanto, durante el proceso de comunicación, la dirección de origen y la dirección de destino del datagrama IP permanecen sin cambios, mientras que la dirección MAC cambia a medida que cambia el enlace.
  ARP implementa la obtención de la dirección MAC a partir de la dirección IP.
  Cada host tiene un caché ARP, que contiene la tabla de mapeo desde la dirección IP a la dirección MAC de cada host y enrutador en la red de área local.
  Si el host A conoce la dirección IP del host B, pero no hay ninguna asignación de la dirección IP a la dirección MAC en la caché ARP, el host A envía un paquete de solicitud ARP por difusión y el host B envía un paquete de respuesta ARP después de recibir el El host A es informado de su dirección MAC y luego escribe la asignación de la dirección IP del host B a la dirección MAC en su caché.

• Protocolo de mensajes de control de Internet ICMP (reenvío)
  ICMP está diseñado para reenviar datagramas IP de manera más eficiente y aumentar las posibilidades de una entrega exitosa. Está encapsulado en datagramas IP pero no es un protocolo de nivel superior.
  Los mensajes ICMP se dividen en mensajes de informe de errores y mensajes de consulta.

• VPN de red privada virtual (reenvío)
  Debido a la escasez de direcciones IP, la cantidad de direcciones IP que una organización puede solicitar es a menudo mucho menor que la cantidad de hosts que posee la organización. Y una organización no necesita conectar todos los hosts a Internet externo. Las computadoras dentro de la organización pueden usar direcciones IP (direcciones privadas) que solo son válidas dentro de la organización.
  Hay tres bloques de direcciones dedicados:
  10.0.0.0 ~ 10.255.255.255
  172.16.0.0 ~ 172.31.255.255
  192.168.0.0 ~ 192.168.255.255
  VPN utiliza la Internet pública como portador de comunicación entre las redes privadas de la organización. Privado significa que el host dentro de la organización solo se comunica con otros hosts de la organización; virtual significa que parece tener acceso a Internet público, pero en realidad no lo es.
  En la siguiente figura, la comunicación entre las ubicaciones A y B pasa a través de Internet. Si el host X en la ubicación A quiere comunicarse con el host Y en otra ubicación B, la dirección de origen del datagrama IP es 10.1.0.1 y la dirección de destino es 10.2 .0.3. El datagrama se envía primero al enrutador R1, que está conectado a Internet. R1 cifra los datos internos y luego vuelve a agregar el encabezado del datagrama. La dirección de origen es la dirección global del enrutador R1, 125.1.2.3, y el destino. La dirección es la dirección global del enrutador R2, 194.4.5.6. Después de recibir el datagrama, el enrutador R2 descifra la parte de datos y restaura el datagrama original. En este momento, la dirección de destino es 10.2.0.3 y se entrega a Y.

• Traducción de direcciones de red NAT (reenvío)
  Cuando un host dentro de una red privada usa una dirección IP local y desea comunicarse con un host en Internet, se puede usar NAT para convertir la IP local en una IP global.
  En el pasado, NAT asignaba direcciones IP locales e IP globales uno a uno, de modo que un máximo de n hosts en una red privada con n direcciones IP globales podían acceder a Internet al mismo tiempo. Para hacer un uso más eficaz de las direcciones IP globales, la tabla de traducción NAT comúnmente utilizada también utiliza el número de puerto de la capa de transporte, de modo que los hosts dentro de múltiples redes privadas compartan una dirección IP global. La NAT que utiliza números de puerto también se denomina NAPT de traducción de puertos y direcciones de red.

• La estructura del enrutador (enrutamiento)
  La función del enrutador se puede dividir en: enrutamiento y reenvío de paquetes.
  La estructura de reenvío de paquetes consta de tres partes: una estructura de conmutación, un conjunto de puertos de entrada y un conjunto de puertos de salida.

• El proceso de reenvío de paquetes del enrutador
  extrae la dirección IP D del host de destino del encabezado del datagrama y obtiene la dirección de red de destino N.
  Si N es una dirección de red conectada directamente a este enrutador, se realiza la entrega directa;
  si hay una ruta de host específica con la dirección de destino D en la tabla de enrutamiento, el datagrama se entrega al enrutador del siguiente salto especificado en la tabla;
  si Si hay una ruta a la red N en la tabla de enrutamiento, el datagrama se envía al enrutador del siguiente salto especificado en la tabla de enrutamiento;
  si hay una ruta predeterminada en la tabla de enrutamiento, el datagrama se envía al enrutador predeterminado especificado en la tabla de enrutamiento. ;
  Informar de error en el paquete de reenvío.

protocolo de enrutamiento

• Los protocolos de enrutamiento son adaptables y pueden ajustarse de manera adaptativa a medida que cambia el tráfico de la red y la topología.
  Internet se puede dividir en muchos sistemas autónomos (AS) más pequeños, y un AS puede utilizar un protocolo de enrutamiento diferente al de otros AS.
  Los protocolos de enrutamiento se pueden dividir en dos categorías principales:
  Enrutamiento dentro de sistemas autónomos: RIP y OSPF
  Enrutamiento entre sistemas autónomos: BGP

Capa de enlace de datos (por Wangdao)

Capa de enlace de datos (Por ciclo)

habilidades básicas

1. Encapsule en marcos:
   agregue encabezados y avances a los paquetes pasados ​​desde la capa de red para marcar el principio y el final del marco.
2. Transmisión transparente
   Transparente significa que algo realmente existente parece como si no existiera.
   Los marcos están delimitados por encabezados y avances . Si la parte de datos del marco contiene el mismo contenido que el encabezado y el avance, las posiciones inicial y final del marco se determinarán incorrectamente. Es necesario insertar caracteres de escape antes del contenido con el mismo comienzo y final en la parte de datos. Si aparece un carácter de escape en la parte de datos, agregue un carácter de escape antes del carácter de escape. Los datos originales se pueden restaurar después del procesamiento en el extremo receptor. El contenido transmitido de forma transparente en este proceso son caracteres de escape y los usuarios no son conscientes de la existencia de caracteres de escape.
3. Detección de errores
   La verificación de redundancia cíclica (CRC) se usa actualmente ampliamente en la capa de enlace de datos para detectar errores de bits.

Clasificación de canales

1. Canal de transmisión
   Comunicación uno a muchos, los datos enviados por un nodo pueden ser recibidos por todos los nodos en el canal de transmisión.
   Todos los nodos envían datos en el mismo canal de transmisión, por lo que se requieren métodos de control especiales de coordinación para evitar conflictos (los conflictos también se denominan colisiones).
   Hay dos métodos de control principales para la coordinación, uno es utilizar tecnología de multiplexación de canales y el otro es utilizar el protocolo CSMA/CD.
2. Canal punto a punto
   Comunicación uno a uno.
   Debido a que no habrá colisión, es relativamente simple y se controla mediante el protocolo PPP.

Tecnología de multiplexación de canales.

1. Multiplexación por división de frecuencia
   Todos los hosts en multiplexación por división de frecuencia ocupan diferentes recursos de ancho de banda de frecuencia al mismo tiempo.
2. Multiplexación por división de tiempo
   Todos los hosts en multiplexación por división de tiempo ocupan los mismos recursos de ancho de banda de frecuencia en diferentes momentos.
   Para la comunicación se utiliza multiplexación por división de frecuencia y multiplexación por división de tiempo.Durante el proceso de comunicación, el host siempre ocupará parte de los recursos del canal. Sin embargo, debido a la naturaleza de ráfagas de los datos de la computadora, no es necesario que el proceso de comunicación ocupe recursos del canal todo el tiempo sin permitir que otros usuarios los utilicen, por lo que la tasa de utilización del canal no es alta en estos dos métodos. .
3. La multiplexación por división de tiempo estadística
   es una mejora de la multiplexación por división de tiempo. La posición de cada usuario en el marco de multiplexación por división de tiempo no es fija. Mientras haya datos, se reúnen para formar un marco de multiplexación por división de tiempo estadístico y luego se envían.
4. Multiplexación por división de longitud de onda
   Multiplexación por división de frecuencia de la luz. Dado que la frecuencia de la luz es muy alta, se acostumbra expresar la portadora óptica utilizada en términos de longitud de onda en lugar de frecuencia.
5. La multiplexación por división de código
   asigna m chips de bits a cada usuario y todos los chips son ortogonales. Para dos chips cualesquiera y

Protocolo CSMA/CD

• CSMA/CD significa Detección de colisiones/acceso multipunto Carrier Sense.
• Acceso multipunto: significa que se trata de una red de bus y muchos hosts están conectados al bus de forma multipunto.
• Carrier Sense: Cada host debe monitorear constantemente el canal. Antes de enviar, si se detecta que el canal está en uso, se debe esperar.
• Detección de colisiones: durante la transmisión, si otro host está monitoreando el canal y enviando datos, significa que ha ocurrido una colisión. Aunque cada host ha monitoreado que el canal esté inactivo antes de enviar datos, aún pueden ocurrir colisiones debido al retraso en la propagación de las ondas electromagnéticas.

protocolo APP

• Los usuarios de Internet generalmente necesitan conectarse a un ISP antes de poder acceder a Internet. El protocolo PPP es el protocolo de capa de enlace de datos utilizado por la computadora del usuario para comunicarse con el ISP.

Dirección MAC

• La dirección MAC es una dirección de capa de enlace, de 6 bytes (48 bits) de longitud, que se utiliza para identificar de forma única el adaptador de red (tarjeta de red).
• Un host tiene tantas direcciones MAC como adaptadores de red. Por ejemplo, las computadoras portátiles generalmente tienen adaptadores de red inalámbricos y adaptadores de red cableados, por lo que tienen dos direcciones MAC.

Tipo de red

• 
  Red de área local La red de área local es un canal de transmisión típico. Su característica principal es que la red es propiedad de una unidad y su alcance geográfico y número de sitios son limitados .
  Existen principalmente tecnologías LAN como Ethernet, Token Ring, FDDI y ATM. Actualmente, Ethernet ocupa el mercado de LAN cableadas.
  Las redes de área local se pueden clasificar según la topología de la red:

• Ethernet
  Ethernet es una red de área local con topología en estrella.
  En los primeros días, se utilizaban concentradores para la conexión. El concentrador es un dispositivo de capa física que opera en bits en lugar de tramas. Cuando un bit llega a la interfaz, el concentrador lo regenera y amplifica su intensidad de energía, ampliando así la distancia de transmisión. de la red Envíe este bit a todas las demás interfaces. Si un concentrador recibe tramas de dos interfaces diferentes al mismo tiempo, se produce una colisión.

• LAN virtual VLAN La
  LAN virtual puede establecer grupos lógicos independientemente de la ubicación física. Solo los miembros de la misma LAN virtual recibirán información de transmisión de la capa de enlace.
  Las LAN virtuales se establecen mediante conexiones troncales VLAN, donde se configura una interfaz especial en cada conmutador como interfaz troncal para interconectar conmutadores VLAN. IEEE define un formato de trama Ethernet extendido 802.1Q, que agrega una etiqueta VLAN de encabezado de 4 bytes a la trama Ethernet estándar para indicar a qué LAN virtual pertenece la trama.

equipo de internet

• Switch
  El switch tiene capacidad de autoaprendizaje: aprende el contenido de la tabla de conmutación, que almacena la asignación de direcciones MAC a las interfaces.
  Debido a esta capacidad de autoaprendizaje, el conmutador es un dispositivo plug-and-play que no requiere que el administrador de la red configure manualmente el contenido de la tabla de conmutación.

Capa física (por ciclo)

forma de comunicacion

• Según la dirección de transmisión de información en la línea de transmisión, se divide en los siguientes tres métodos de comunicación:
• Comunicación simplex: transmisión unidireccional
• Comunicación semidúplex: transmisión alterna bidireccional
• Comunicación full-duplex: transmisión simultánea en ambas direcciones

modulación de paso de banda

• Las señales analógicas son señales continuas y las señales digitales son señales discretas.
• La modulación de paso de banda convierte señales digitales en señales analógicas.