Paz en localhost e ilusiones rotas
Cuando estaba en la escuela, todo mi mundo era localhost. Incluso si instalaba algo como XAMPP y creaba un tablón de anuncios usando PHP, era un mundo que sólo funcionaba en mi computadora.
Cuando me uní a la empresa por primera vez, tuve la suerte de ser el principal responsable del mantenimiento del front-end. Era una página de administración basada en Quasar (Vue.js) y la dificultad de la tarea no era alta. Todo lo que tenía que hacer era corregir el error tipográfico o llamar a la API que mis mayores ya habían creado bien con axios.get() y mostrarla en la pantalla.
En ese momento, axios era como una varita mágica para mí. Aunque no conozco los principios complicados, simplemente ingresé la URL y los datos se recuperaron rápidamente. También tuve un pensamiento descarado: «No hay nada especial en la comunicación entre el front-end y el back-end, ¿verdad?»
Pero la paz no duró mucho. Esto se debe a que era un desarrollador «full-stack» de estilo de vida en una pequeña y mediana empresa que carecía de mano de obra.
Pronto llegó el momento en que tuve que crear mi propia API para una nueva función, en lugar de modificar la pantalla. Inicié un servidor usando Spring Boot, que aprendí rápidamente en YouTube, y envié una solicitud desde el front-end. Sin embargo, todo lo que apareció en mi pantalla fueron errores CORS rojos y errores Timeout, no datos.
«Funcionó bien cuando lo pasé como variable local, pero ¿por qué no puedo usar la red?»
Mover la variable A a la variable B en mi computadora (Localhost) fue un método seguro 100% garantizado. Pero el mundo fuera del cable LAN era diferente. Era como una intersección con un semáforo roto, y mis datos eran un camión circulando por esa carretera peligrosa. Todo este tiempo, simplemente estaba cargando el camión y enviándolo, pero no tenía idea de qué ruta tomaba el camión ni cómo estaba dividido.
Sistema de entrega en centro logístico digital
Ampliemos nuestra visión del mundo de “centro de logística digital”. Ahora tenemos que entregar los artículos (datos) fabricados en nuestra fábrica (computadora) a clientes (servidores) lejanos.
1. Paquete: Caja de envío estándar
No importa el tamaño de los datos que queramos enviar (por ejemplo, un vídeo de 1 GB), no se pueden enviar todos a la vez. Esto se debe a que las carreteras son estrechas y los camiones pequeños. Entonces cortamos los datos en pedazos muy pequeños y los colocamos en cajas estandarizadas. Este es un «Paquete».
2. IP (Protocolo de Internet): Dirección y navegación
¿Qué puedo hacer si solo tengo una caja? Necesitas saber adónde ir.
3. TCP/UDP: Diferencias en los métodos de entrega
Ahora tenemos que decidir a qué camión enviar las cajas.
[Verificación de código] La verdadera cara de HTTP es solo texto
El HTTP que utilizamos habitualmente es en realidad sólo el «contenido de la carta» transportado en un camión de reparto llamado TCP. Hablemos con el servidor Naver de la forma más primitiva (Socket) sin navegador ni biblioteca. Verás lo simple que es HTTP, solo un fragmento de texto.
import socket
# 1. Crear socket TCP (descolgar el telefono)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 2. Conectar al servidor Naver (223.130.195.200) por el puerto 80 (marcar)
# La IP de Naver puede cambiar (verificar con nslookup [www.naver.com](https://www.naver.com))
target_host = "[www.naver.com](https://www.naver.com)"
target_port = 80
sock.connect((target_host, target_port))
# 3. Redactar mensaje de solicitud HTTP (escribir lo que vas a decir)
# Forma mas cruda de una solicitud HTTP
request = "GET / HTTP/1.1rnHost: [www.naver.com](https://www.naver.com)rnrn"
# 4. Enviar (hablar)
sock.send(request.encode())
# 5. Recibir respuesta (escuchar)
response = sock.recv(4096)
print(response.decode())
# 6. Cerrar conexion (colgar)
sock.close()
Resultados de la ejecución (parcial):
HTTP/1.1 200 OK
Server: NWS
Date: Mon, 01 Jan 2024 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
...
<html>...</html>
Análisis: Esto es todo lo que sucede internamente cuando llamamos a axios.get().
HTTP no es una tecnología especial, es simplemente una promesa hecha de “intercambiar textos utilizando este protocolo (protocolo) cuando nos comunicamos”.
Compensación en la práctica: confiabilidad o velocidad
En la práctica, especialmente en el desarrollo back-end, llega un momento en el que hay que decidir entre TCP y UDP. (Por supuesto, la mayoría usa HTTP basado en TCP)
HTTP/3, que se pregunta con frecuencia en las preguntas de entrevistas recientes, es el producto de esta compensación. La Internet que utilizamos (HTTP/1.1, HTTP/2) se ha estado ejecutando en TCP. Porque los datos nunca deben destruirse.
Pero los tiempos han cambiado. La gente quiere ver vídeos 4K sin interrupciones. El meticuloso proceso de verificación de TCP (Handshake) y características como «Permanecer en línea (Bloqueo de encabezado de línea)» ahora se han vuelto frustrantes.
Eso pensó Google. «Oye, usemos UDP. Podemos solucionar las inquietudes a nivel de la aplicación. ¡Es importante enviarlo rápidamente!»
Este es el protocolo QUIC y es la base de HTTP/3. Es una tendencia de la tecnología moderna que abandonó la estabilidad incondicional (TCP) y eligió la velocidad abrumadora (UDP) incluso si eso significaba tomar algunos riesgos.
Cierre: imagina un camino invisible
Ahora sabemos cómo se dividen los datos (paquetes) y en qué camión (TCP/UDP) viajan.
Cuando falla una solicitud de API en el frontend, no piense simplemente: «¿Está muerto el servidor?» como antes. «Oh, ¿falló el protocolo de enlace de tres vías? ¿El enrutador descartó el paquete en el medio? ¿O el DNS no encontró la dirección?» Si puedes imaginar una capa de red como esta, ya no eres «solo un codificador»
Ahora, los productos de nuestra fábrica han llegado sanos y salvos al cliente. Pero, ¿cómo recibe un cliente este artículo, lo desempaqueta y lo muestra en la pantalla? ¿Cómo se mostrará en el navegador el código HTML que enviemos?
La próxima vez hablaremos sobre el destino final del desarrollo web, los principios de renderizado del navegador.