2020 Autumn Recruitment_TCP / Conocimiento del protocolo IP (notas)

Modelo OSI de red

El modelo de interconexión de sistemas abiertos (modelo OSI) tiene 7 capas en total.
7. Capa de aplicación, 6. Capa de expresión, 5. Capa de sesión, 4. Capa de transporte, 3. Capa de red, 2. Capa de enlace de datos, 1. Capa física

El modelo de red se divide en varios niveles

Cuatro niveles: capa de aplicación, capa de transporte (TCP, UDP), capa de red (IP), capa de interfaz de red (socket).

La relación entre el protocolo TCP y el protocolo IP

En el modelo de red, el protocolo TCP está ubicado en la capa de transporte, el protocolo IP está ubicado en la capa de red y la capa de transporte está ubicada una capa por encima de la capa de red.
El protocolo TCP proporciona principalmente un método de transmisión de datos confiable entre dos computadoras en una conexión de red; el protocolo IP especifica la ruta (la llamada ruta de transmisión) a través de la cual llegar a la otra computadora y transmite el paquete de datos a la otra parte, es decir, la ruta la manera.
El extremo emisor agrega el encabezado a través de cada capa y el extremo receptor elimina el encabezado a través de cada capa.
La capa de transporte (protocolo TCP) divide los datos (mensaje HTTP) recibidos de la capa de aplicación y los reenvía a la capa de red después de marcar el número de serie y el número de puerto en cada mensaje; agregando la función en la capa de red (protocolo IP) La dirección MAC del destino de la comunicación se reenvía a la capa de enlace.

La diferencia entre TCP y UDP

	TCP	UDP
fiabilidad	de confianza	No fidedigno
Conectividad	Orientado a la conexión	no conectado
Mensaje	Orientado al flujo de bytes (ilimitado)	Orientado a mensajes (reservando los límites del mensaje)
eficacia	Baja eficiencia de transmisión	Alta eficiencia de transmisión
Dúplex	Full duplex (punto a punto)	Uno a uno, uno a muchos, muchos a muchos
control de flujo	Tener	No
Control de congestion	Tener	No

¿Por qué TCP es más confiable que UDP?

TCP está orientado a la conexión y establece una conexión confiable a través de un protocolo de enlace de tres vías; UDP no tiene conexión.

• La razón principal para el uso del protocolo de enlace de tres vías para las conexiones TCP: para evitar la confusión causada por las inicializaciones repetidas de la conexión en el pasado, para evitar que las dos partes que se comunican utilizando el protocolo TCP establezcan una conexión incorrecta;
• Los números de serie iniciales de las partes que se comunican se pueden inicializar mediante el protocolo de enlace de tres vías;
• Discutir la posibilidad de establecer una conexión con otro apretón de manos;

¿Por qué el proceso de protocolo de enlace de tres vías TCP es tres veces en lugar de dos o cuatro veces?

Dos imágenes en movimiento: comprenda a fondo el protocolo de enlace de tres vías de TCP y el
TCP de onda de cuatro vías por qué el proceso de protocolo de enlace de tres vías en lugar de dos (versión de solución positiva) de
cuatro vías:

1. El cliente envía una solicitud de sincronización SYN al servidor;
2. El servidor devuelve un ACK al cliente para confirmar la sincronización;
3. El servidor envía una solicitud de sincronización SYN al cliente;
4. El cliente devuelve un ACK al servidor para confirmar la sincronización.

Obviamente, el segundo y tercer apretón de manos en el apretón de manos de cuatro vías son todos enviados por el servidor al cliente, por lo que pueden simplificarse en un apretón de manos de tres vías para mejorar la eficiencia de establecer una conexión.

Tres procesos de apretón de manos:

1. El cliente envía una solicitud de sincronización SYN al servidor;
2. El servidor devuelve un ACK al cliente para confirmar la sincronización y envía una solicitud de sincronización SYN;
3. El cliente devuelve un ACK al servidor para confirmar la sincronización.

Para lograr una transmisión de datos confiable, ambas partes en el protocolo TCP deben mantener un número de secuencia para identificar cuál de los paquetes de datos enviados ha sido recibido por la otra parte ( si la parte que envía el mensaje de solicitud no recibe la confirmación ACK de la otra parte, El mensaje de solicitud se retransmitirá con el tiempo hasta que reciba la confirmación ACK de la otra parte. El valor inicial del número de secuencia de estos mensajes de solicitud retransmitidos es el mismo. Si hay un mensaje de solicitud que llega después de un retraso, No se recibirá repetidamente ).
El proceso del protocolo de enlace de tres vías es un paso necesario para que las partes comunicantes se informen entre sí del valor inicial del número de serie y confirmen que la otra parte ha recibido el valor inicial del número de serie. Si solo hay dos apretones de manos, como máximo solo se puede confirmar el número de secuencia inicial del iniciador de la conexión, y no se puede confirmar el número de secuencia seleccionado por la otra parte.

¿Cómo garantiza TCP una transmisión fiable? (Centrarse en el proceso de transmisión)

La base de una transmisión confiable TCP / IP es el protocolo de ventana deslizante y el protocolo ARQ (solicitud de repetición automática) continuo, con control de flujo y control de congestión, de manera que todo el proceso de transmisión garantiza:

1. El canal de transmisión no produce errores;
2. No importa qué tan rápido el remitente envíe datos, el receptor siempre tiene tiempo para procesar los datos recibidos (garantía por acuse de recibo acumulado, retransmisión de tiempo de espera, control de flujo, control de congestión, etc.).

¿Cómo confirmar? -> Protocolo ARQ continuo

¿Cómo confirma el remitente qué paquetes deben retransmitirse?

Detener el protocolo de espera : el remitente dejará de enviar cada vez que se envía un paquete (iniciará un temporizador al mismo tiempo) y esperará a que la otra parte confirme; el receptor confirmará al remitente después de recibir el mensaje, y el remitente no lo ha recibido después de un período de tiempo. El mensaje se retransmite después de la confirmación (retransmisión de tiempo de espera); el remitente enviará el siguiente paquete después de recibir la confirmación.
Protocolo de ventana deslizante : El remitente y el receptor mantienen la ventana de envío y la ventana de recepción respectivamente.Cada vez que el remitente recibe un acuse de recibo, desliza la ventana de envío hacia adelante un segmento. El receptor generalmente adopta un método de confirmación acumulativa.
Protocolo ARQ continuo : el remitente mantiene una ventana y cualquier segmento dentro de la ventana se puede enviar de forma continua sin esperar a que la otra parte lo confirme. El receptor generalmente utiliza acuses de recibo acumulativos y envía acuses de recibo acumulativos al último segmento que llega en secuencia, lo que indica que se ha confirmado la recepción de todos los segmentos hasta este segmento.
(Ventajas: alta utilización del canal, fácil de implementar, incluso si se pierde el reconocimiento devuelto por el receptor, no es necesario retransmitirlo; desventajas: se pierde un segmento en el medio de la ventana y se requieren los segmentos posteriores al segmento perdido en la ventana Reenviar, porque el segmento intermedio se pierde, el segmento siguiente no se puede confirmar)

La diferencia entre control de flujo y control de congestión

Control de flujo: cuando el receptor es demasiado tarde para procesar los datos del remitente, puede pedirle al remitente que reduzca la velocidad de envío para evitar la pérdida de paquetes.
Control de congestión: reduce la transmisión de datos cuando la red está congestionada. (Mantenga una ventana de congestión cwnd, cwnd = min (rwnd, cwnd); algoritmo de control de congestión: inicio lento, evitación de congestión, retransmisión rápida y recuperación rápida) El
control de congestión es un proceso global que involucra a todos los hosts, todas las redes, Y todos los factores relacionados con la reducción del rendimiento de la red. Por el contrario, el control de flujo es a menudo el control del tráfico de punto a punto, que es un proceso de extremo a extremo . Lo que debe hacer el control de flujo es suprimir la velocidad a la que el extremo emisor envía datos para que el extremo receptor pueda recibirlos.

time_wait estado

La duración de time_wait es la duración más larga de los dos segmentos de mensaje.
Cuando el cliente o servidor se cierra (Ctrl + C) primero, entrará en el estado time_wait.
efecto:

1. Asegúrese de que el último mensaje ACK enviado por el cliente pueda llegar al servidor;
2. Todos los segmentos de mensajes generados durante la duración de esta conexión desaparecerán de la red, por lo que el mensaje de solicitud de la conexión anterior no aparecerá en la nueva conexión.

La relación entre el paquete pegajoso TCP TCP y HTTP, en qué tipo de transmisión se puede basar HTTP

La razón principal es que TCP se transmite en forma de flujo de bytes y no hay límite de mensaje. (El problema de los paquetes adhesivos se puede resolver con programas. Por ejemplo, al leer mensajes HTTP, generalmente se usa /r/ncomo una marca de salto de línea para cada línea del mensaje. Las líneas en blanco se /r/nusan para distinguir el encabezado del mensaje del cuerpo del mensaje. La longitud del cuerpo del mensaje puede basarse en el encabezado. Se obtiene la longitud del contenido del campo, para que se pueda leer un mensaje HTTP completo)

Paquetes pegajosos TCP, desempaquetado y soluciones, causas y soluciones de pérdida de paquetes

Paquetes pegajosos TCP, desempaquetado y soluciones, causas y soluciones de pérdida de paquetes

¿Qué pasó al ingresar la URL a la carga de la página?

Preguntas de entrevista clásicas de front-end: ¿Qué sucedió desde la entrada de URL hasta la carga de la página?
Generalmente se divide en los siguientes procesos:

1. Resolución de DNS: el proceso de encontrar qué máquina tiene los recursos que necesita.
2. Conexión TCP: el protocolo HTTP utiliza TCP como su protocolo de capa de transporte. Cuando TCP tiene un cuello de botella, HTTP también se verá afectado.
3. Enviar solicitud HTTP
4. El servidor procesa la solicitud y devuelve un mensaje HTTP.
5. El navegador analiza la página renderizada
6. Fin de la conexión

La relación entre TCP y HTTP, ¿en qué transmisión se puede basar HTTP?

¡La diferencia entre TCP y Http! Entiendo, no se confunda!
TCP se encuentra en la capa de transporte del modelo de red, es el protocolo de la capa de transporte, que define la especificación de la transmisión de datos y el modo de conexión; HTTP se encuentra en la capa de aplicación del modelo de red, Es un protocolo de capa de aplicación que define las especificaciones del contenido de datos a transmitir. El protocolo HTTP se basa en el protocolo TCP, es decir, los datos en el protocolo HTTP se transmiten utilizando el protocolo TCP (puerto predeterminado 80), por lo que el soporte HTTP también debe ser compatible con TCP.

HTTP / 3 en realidad se basa en UDP ¿Qué ha experimentado el protocolo HTTP a lo largo de los años? (Describe el proceso de desarrollo técnico de HTTP / 1, HTTP / 2, HTTP / 3)
HTTP también se puede transmitir según el protocolo QUIC (HTTP / 3, el protocolo QUIC se basa en el protocolo UDP).
Google desarrolló un protocolo QUIC basado en el protocolo UDP y lo usó en HTTP / 3. HTTP / 3 se llamaba anteriormente HTTP-over-QUIC. De este nombre, también podemos encontrar que la mayor transformación de HTTP / 3 es usarlo. QUIC.

La diferencia entre GET y POST

GET: obtener recursos; POST: transferir el cuerpo de la entidad.

Primero concluyamos que no existe una diferencia sustancial entre los métodos GET y POST, pero el formato del mensaje es diferente.
GET y POST son solo dos métodos de solicitud en el protocolo HTTP, mientras que el protocolo HTTP es un protocolo de capa de aplicación basado en TCP / IP. No importa GET o POST, se utiliza el mismo protocolo de capa de transporte, por lo que no hay diferencia en la transmisión .

En el formato del mensaje, cuando no hay ningún parámetro, la mayor diferencia es el nombre del método de la primera línea:

• La primera línea del mensaje de solicitud del método POST es así POST /uri HTTP/1.1 \r\n
• El mensaje de solicitud de método GET es la primera línea de GET /uri HTTP/1.1 \r\n
  sí, sin argumentos cuando su diferencia son solo los primeros caracteres de mensajes diferentes.

¿Cuál es la diferencia entre mensajes con parámetros? En la convención, los parámetros del método GET deben colocarse en la URL y los parámetros del método POST deben colocarse en el cuerpo.
Ahora sabemos que los dos métodos son esencialmente conexiones TCP, no hay diferencia, es decir, si no sigo las especificaciones, está bien. Podemos escribir parámetros en la URL y luego usar POST en el método; también podemos escribir parámetros en el Cuerpo y luego usar GET en el método. Por supuesto, esto requiere soporte de servidor.

La diferencia más intuitiva es que GET incluye los parámetros en la URL y POST pasa los parámetros a través del cuerpo de la solicitud . Los parámetros transmitidos en la URL para las solicitudes GET tienen una longitud limitada, mientras que POST no tiene ninguna limitación. Para el tipo de datos del parámetro, GET solo acepta caracteres ASCII, mientras que POST no tiene restricciones. GET es menos seguro que POST, porque los parámetros están expuestos directamente en la URL, por lo que no se puede utilizar para transmitir información confidencial. (Desde el punto de vista de la transmisión, POST y GET son inseguros. Debido a que HTTP se transmite en texto sin formato en la red, siempre que el paquete se capture en el nodo de la red, el mensaje de datos se puede obtener por completo. Para una transmisión segura, solo se requiere cifrado. Eso es HTTPS.)

La relación entre HTTP y HTTPS

¿Comprende los protocolos HTTP y HTTPS en diez minutos?
Existen los siguientes problemas en HTTP general:

• La información solicitada se transmite en texto sin formato, que es fácil de interceptar mediante escuchas;
• La integridad de los datos no ha sido verificada y se puede alterar fácilmente;
• Sin verificar la identidad de la otra parte, existe el peligro de suplantación de identidad.

Protocolo HTTPS (HyperText Transfer Protocol over Secure Socket Layer): Generalmente entendido como HTTP + SSL (Secure Socket Layer) / TLS (Transport Layer Security), la identidad del servidor se verifica a través de un certificado SSL, y es la comunicación entre el navegador y el servidor. Cifrado. (El predecesor de TLS es SSL)

HTTPS es una versión segura del protocolo HTTP. La transmisión de datos del protocolo HTTP es en texto plano y no es segura. HTTPS utiliza el protocolo SSL / TLS para el cifrado.
HTTP y https utilizan diferentes métodos de conexión, y el puerto predeterminado es diferente, http es 80, https es 443.

¿Por qué es seguro el protocolo https? -> HTTPS utiliza el protocolo SSL (Secure Socket Layer) / TLS (Transport Layer Security) para el cifrado, la autenticación y la protección de la integridad.
Proceso de conexión https ssl -> generalmente HTTP se comunica directamente con TCP. Cuando se usa SSL, evoluciona para comunicarse con SSL primero y luego comunicarse con SSL y TCP.

Cómo determinar que el servidor recibió la solicitud correctamente

• El mensaje de respuesta devuelto es 200 OK.
• Devolver 5xx significa que es un error interno del servidor.
• Un retorno de 4xx indica que se trata de un error del cliente, como un error de sintaxis en el mensaje de solicitud, sin permiso para acceder a los recursos y sin recursos encontrados.

Conexión y canalización persistentes (canalización), conexión corta y conexión larga (conexión persistente)

La característica más notable de las conexiones HTTP es que cada solicitud enviada por el cliente requiere que el servidor envíe una respuesta y, una vez finalizada la solicitud, la conexión se libera activamente. El proceso desde el establecimiento de una conexión hasta el cierre de una conexión se denomina "conexión".

• En HTTP 1.0, cada solicitud del cliente requiere que se establezca una conexión separada. Una vez procesada la solicitud, la conexión se libera automáticamente. (Conexión corta)
• En HTTP 1.1, se pueden procesar varias solicitudes en una conexión y se pueden superponer varias solicitudes, sin esperar a que una solicitud finalice antes de enviar la siguiente. (Conexión larga / conexión persistente)

Envío de solicitudes HTTP de forma canalizada: varias solicitudes se envían simultáneamente al mismo tiempo sin esperar una respuesta una por una, lo que es más rápido que una conexión persistente.
El mecanismo de canalización debe completarse a través de una conexión persistente. Solo HTTP / 1.1 es compatible con esta tecnología (HTTP / 1.0 no es compatible), y solo se pueden canalizar los requisitos GET y HEAD, mientras que POST tiene restricciones. Además, el mecanismo de canalización no debe activarse cuando se crea la conexión por primera vez, porque la otra parte (servidor) no necesariamente admite la versión HTTP / 1.1 del protocolo.

En el caso de una conexión larga, cuando se abre una página web, la conexión TCP utilizada para transmitir datos HTTP entre el cliente y el servidor no se cerrará. Si el cliente vuelve a acceder a la página web en el servidor, seguirá utilizando esta. Conexión establecida. Keep-Alive no mantendrá la conexión de forma permanente, tiene un tiempo de mantenimiento que se puede configurar en diferentes software de servidor (como Apache). Para lograr una conexión persistente, tanto el cliente como el servidor deben admitir la conexión persistente.
Las conexiones largas y cortas del protocolo HTTP son esencialmente las conexiones largas y cortas del protocolo TCP.