http connection lifecycle
1.0.0
Tabla de contenido
En la entrevista técnica o en cualquier otro lugar, una de las preguntas más frecuentes es ¿qué sucede cuando escribe una URL en el navegador? ¿Qué sucede detrás de escena cuando navegas por un sitio web? ¿Qué implica un ciclo de vida típico de una conexión HTTP? Responderé estas preguntas lo mejor que pueda.
Antes de profundizar en el proceso de conexión, repasemos el modelo OSI (modelo de interconexión de sistemas abiertos) básico. El modelo OSI es un modelo conceptual que estandariza la comunicación entre dos sistemas: uno donde se origina la solicitud (el cliente) y otro que atiende la solicitud y envía una respuesta (el servidor). La siguiente tabla muestra algunas de las características importantes de cada capa.
| No | Capa | Hardware | Función | Protocolos/Aplicaciones | Adiciones |
|---|---|---|---|---|---|
| 7 | Solicitud | Servidor/PC | Aplicaciones, interfaz de usuario | HTTP, SMTP, DNS | Encabezado L7 |
| 6 | Presentación | Servidor/PC | Maneja cambios de cifrado y sintaxis. | JPEG, MP3 | Encabezado L6 |
| 5 | Sesión | Servidor/PC | Autenticación, permisos, sesiones. | SCP, programación del sistema operativo | Encabezado L5 |
| 4 | Transporte | Cortafuegos | Entrega de extremo a extremo, control de errores | TCP, UDP | Encabezado L4 |
| 3 | Red | Enrutadores | Direccionamiento, enrutamiento y conmutación de red | IP | Encabezado L3 |
| 2 | Enlace de datos | interruptores | Dirección física, detección de errores, flujo. | Ethernet, retransmisión de trama | Encabezado/Tráiler L2 |
| 1 | Físico | cables | Bit transferido a través de la red física | EIA/AIT | Encabezado L1 |
Tan pronto como escriba la URL en el navegador y presione la tecla Intro/Retorno, el navegador (o cualquier cliente) analizará la URL [1] para extraer componentes importantes de ella. A continuación se proporciona una URL de ejemplo:
https://www.google.com/search?q=gatos
Aquí solo estamos buscando gatos en Google. De la URL anterior, https:// es el protocolo, google.com es el host en www (internet), /search es el parámetro de ruta y ?q=cats es el parámetro de cadena de consulta que indica que estamos consultando a Google sobre gatos [ 2].
Ahora que el navegador conoce el host al que intenta acceder, en este caso google.com , intentará obtener sus direcciones IP correspondientes. Dominios como ' .com' o ' .org' fueron creados para que podamos recordarlos fácilmente. Pero para que el navegador envíe la solicitud real a, digamos, google.com, necesita la dirección IP del host. La resolución DNS nos ayuda a obtener la información de la dirección IP para un nombre de dominio determinado. DNS reside en la capa de aplicación (L7) de la tabla anterior.
Pasos en la resolución de DNS:
$ ipconfig /displaydns en Windows o $ log stream --predicate 'process == "mDNSResponder"' --info en mac/linux..com , .org , etc. son nombres de dominio de nivel superior. El nombre de TLD luego devolverá la dirección IP de los servidores de nombres autorizados.$ dig google.com
; << >> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 180 IN A 172.217.164.174
;; AUTHORITY SECTION:
google.com. 60552 IN NS ns1.google.com.
google.com. 60552 IN NS ns2.google.com.
google.com. 60552 IN NS ns3.google.com.
google.com. 60552 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 60438 IN A 216.239.32.10
ns1.google.com. 58273 IN AAAA 2001:4860:4802:32::a
ns2.google.com. 60438 IN A 216.239.34.10
ns2.google.com. 131763 IN AAAA 2001:4860:4802:34::a
ns3.google.com. 163770 IN A 216.239.36.10
ns3.google.com. 60541 IN AAAA 2001:4860:4802:36::a
ns4.google.com. 75597 IN A 216.239.38.10
ns4.google.com. 60541 IN AAAA 2001:4860:4802:38::a
;; Query time: 13 msec
;; SERVER: 10.4.4.10#53(10.4.4.10)
;; WHEN: Mon Jun 24 12:20:50 PDT 2019
;; MSG SIZE rcvd: 303En cada capa del modelo OSI, la información se denomina PDU (Unidad de paquetes de datos). Por lo tanto, la información en la capa de aplicación se denomina PDU L7, mientras que la información en la capa de red se denomina PDU L3. En cada capa, se agrega un encabezado de capa correspondiente. El encabezado precede al cuerpo y contiene la dirección y otros datos necesarios para llegar al destino previsto. Por otro lado, los datos se pasan desde la capa superior hacia abajo. Los encabezados L4, L3 y L2 se muestran a continuación:
Antes de que el paquete se envíe a Internet para llegar finalmente al servidor de dominio de Google, primero debe enrutarse a través del enrutador. Siempre que un dispositivo necesita conectarse físicamente a otro dispositivo (en este caso, el enrutador local), necesita la dirección MAC (dirección de hardware) de ese dispositivo. Pero, ¿cómo sabe la máquina local que el enrutador es la ruta de salida predeterminada? Esta información se adquiere a través de la ruta predeterminada configurada por interfaz dentro de la máquina local. Puede verificar la ruta predeterminada usando el comando $ ifconfig .
La dirección IP se utiliza para localizar un dispositivo en la red, mientras que la dirección MAC se utiliza para identificar el dispositivo real. El protocolo ARP se utiliza para adquirir la dirección MAC del dispositivo, dado el conocimiento de la dirección IP. Aquí asumiremos que la máquina solicitante ya ha recibido una dirección IP (ya sea estáticamente o mediante el protocolo DHCP).
ARP reside en la capa de enlace de datos del modelo OSI. En este caso, el navegador web que se ejecuta en la máquina local se conectará al enrutador, que es una puerta de entrada a Internet.
arp -a .Luego, los paquetes se enrutan a la ruta predeterminada. Si no tiene una ruta predeterminada configurada, se enrutarán al enrutador. Puede verificar la ruta predeterminada usando el comando
route get default | grep gateway o netstat -rn en mac/linux o ipconfig en windows.
Por ejemplo, si está en una red 192.168.10.0/24 e intenta comunicarse con la red de Google en 172.217.164.174/24, por ejemplo, cuando el paquete llega al enrutador, el enrutador verificará la tabla de enrutamiento y decidirá cómo enrutar el tráfico a llegar a la red de destino. Por lo tanto, enviará el paquete a la puerta de enlace especificada para llegar al destino 172.217.164.174/24.
Conexión entre el cliente y el servidor; en este caso, su máquina local al servidor de Google realiza muchos saltos. Básicamente, cada salto es un enrutador a lo largo del camino hacia el destino. El enrutador aquí ayuda a que las solicitudes pasen de una red a otra. Cada dispositivo en camino tiene una dirección MAC (dirección de hardware) que es única a nivel mundial.
Ahora la máquina local crea una solicitud con el encabezado L7 (HTTP), el encabezado L4 (TCP), el encabezado L3 (IP), el encabezado L2 (ARP, direcciones MAC), el final L2 (secuencia de verificación de trama) y los datos reales. Cuando el enrutador recibe el paquete, lo desencapsula, modifica el encabezado/avance L2 y encapsula el paquete nuevamente.
El enrutador ahora lo recibe y comienza a decapsular. Mira el encabezado L2 y ve que la Mac de destino es para sí misma. Ahora elimina el encabezado L2 y ahora mira el encabezado L3 y comprende que la solicitud no es para sí mismo sino para el servidor de Google. Luego, el enrutador disminuye el valor TTL que se encuentra dentro del encabezado L3. El enrutador ahora busca en su tabla de enrutamiento todas las rutas posibles que los otros enrutadores habrían anunciado a este enrutador (a través de RIP o IGP) sobre cómo llegar al destino. Luego, un enrutador realiza ARP para obtener la dirección MAC del enrutador del siguiente salto si no tiene la dirección MAC en su caché.
Luego, el enrutador también agrega CRC que pasa al remolque L2. Esto ayuda al siguiente enrutador a saber que no se produjeron problemas en las rutas que provocaron que el paquete se corrompiera a través del cable. Si se ha corrompido, eliminará el marco.
En este caso, el enrutador modificó el encabezado L2 y el final L2 pero no tocó el encabezado L3 y, por lo tanto, no hay ningún encabezado encima de él.
Puerto de origen no. será un número de puerto efímero y el número de puerto de destino será 80.
TCP: servicio confiable y del mismo pedido. Lo primero que hará la máquina local es establecer un protocolo de enlace de tres vías con el servidor de Google ahora, ya que conoce la ruta al servidor. El establecimiento de la conexión ayuda a finalizar algunas variables de estado como el tamaño de MSS, el número de secuencia inicial, el tipo de ACK, el tamaño del búfer, etc.
En este caso, el puerto de origen y de destino en el encabezado TCP es de 16 bits, por lo que 2^16 es 65535. El puerto de origen se utiliza para identificar la aplicación cliente, mientras que el puerto de destino se utiliza para identificar el servicio o el demonio que se ejecuta en el servidor web.
El cliente (navegador web) selecciona cualquier puerto entre 49152 y 65535. Esto garantiza que no haya dos aplicaciones que utilicen el mismo puerto. La dirección del puerto junto con la dirección IP se denomina socket TCP. El puerto de destino es el puerto 80 en el paquete IP.
Comenzar la comunicación:
Con los tres pasos anteriores, el protocolo de enlace TCP es exitoso entre el cliente y el servidor y ambos han aceptado las reglas comunes para la transferencia de datos.
Después del protocolo de enlace TCP, se realiza el protocolo de enlace TLS si se conecta a un sitio web seguro. Con el protocolo de enlace TLS, el cliente y el servidor aceptan los términos comunes de comunicación segura.
A partir de ahora, la sesión TLS transmite los datos de la aplicación (HTTP) cifrados con la clave simétrica acordada.
El servidor procesa las solicitudes y devuelve una respuesta adecuada. Cuando la solicitud llega al servidor en el puerto 80 (HTTP) o el puerto 443 (HTTPS), un servidor web como Apache o Nginx escucha el puerto 443, maneja la conexión de la solicitud y la enruta a otro puerto efímero en el que está el servicio web. correr.
Cualquier cliente, servidor o proxy HTTP puede cerrar una conexión de transporte TCP en cualquier momento. Por ejemplo, cuando el cliente detecta que la transferencia de datos ha finalizado y ya no se requiere el canal de conexión abierto, envía una solicitud de cierre de conexión al servidor. La próxima vez que el cliente quiera comunicarse con el servidor, será necesario establecer una nueva conexión entre las dos máquinas.
| [1] | El estándar de URL |
| [2] | Componentes o URL |
