Fundamentos previos al desarrollo de páginas webs
Para desarrollar webs, es necesario (o como mínimo altamente recomendable) tener una cierta “culturilla” que nos permitirá tener una visión global de cuál es el camino por el que usualmente pasan las páginas webs desde el momento en que se hace una petición hasta el momento en el que dicha petición es respondida.
Además, durante está 🐦vista de pájaro de 360 grados🐦, explicaremos mucha terminología además de responder algunas preguntas como, por ejemplo: ¿Qué es el protocolo HTTP? ¿Cómo acceder a las Dev Tools del browser? ¿Para qué sirven los códigos de estado de respuesta HTTP?, etc.
El lanzamiento de web inicialmente se basa en tres pilares que son: los documentos HTML, las URL y el protocolo HTTP.
📌 ️ — Aunque los veremos más a detalle, una web necesita de una
URLpara localizar las páginas/recursos,HTTPpara realizar la comunicación entre cliente y servidor yHTMLpara codificar (escribir) los documentos que se cargan en el navegador.
👩🏫Volver al menú del bootcamp de Front End👩🏫
1.1) ¿Qué es una URL? 🔝
Vamos a comenzar a explicar primeramente las URLs. Una URL (Uniform Resource Locator o Localizador de Recursos Uniforme), es una dirección única y específica que se asigna a cada uno de los recursos disponibles de la WWW (World Wide Web) o bien a un recurso de una red privada con la finalidad de que estos puedan ser localizados por el navegador y visitados por los usuarios.
1.3) Ejemplo de cómo realizar una petición a una URL 🔝
📌 Para ir a una URL es necesario realizar una petición a dicha
URL(no es necesario utilizar todas las partes que hemos visto en la anatomía de unaURL). Ya que, por ejemplo, cuando escribimos visitar al buscador Google escribimos en la barra de direcciones de nuestro sistema laURLhttps://www.google.es lo que finalmente nos llevará a su página web.
1.4) ¿Qué es un protocolo? 🔝
📌 ️ — Un protocolo es un conjunto de reglas/normas que se establecen en el proceso de comunicación entre dos sistemas.
Concretamente, cuando hablamos de comunicaciones de red, un protocolo es el conjunto de normas que rigen cómo los paquetes de comunicación se transmiten a través de la red.
En la sociedad actual ya estamos familiarizados con ellos y, es común, que uno se conecte a una red WIFI o envíe una imagen por bluetooth.
Imaginaos, por ejemplo, si en internet cada uno hiciera las cosas de una manera… Por ello, surgen los protocolos.
1.5) ¿Qué es una dirección IP? 🔝
Una IP es una dirección (etiqueta numérica) que identifica un dispositivo (habitualmente una computadora o un smartphone) en una red que utilice el protocolo IP (Internet Protocol).
📌 ️ — Las IPs son algo similar al DNI de las personas. Pero, en este caso, y (aunque con matices) vinculadas a un dispositivo en vez de a una persona física.
1.6) Tipos de IP: IPv4 vs IPv6 🔝
Dentro de las direcciones IP tenemos dos tipos:
- IPv4 (IP versión 4): direcciones que constan de cuatro números que van del 0 al 255, separados entre ellos por un punto. A excepción del primer bloque más a la izquierda de la IP, el cual podrá ir del 1 al 255. Un ejemplo de una
IPv4, podría ser: 192.168.1.1 - IPv6 (IP versión 6): Direcciones que se representan mediante a ocho grupos de 4 dígitos hexadecimales (está formado por los números del 0 al 9 y a partir del 10 en adelante se utilizan las letras A a la F) separados por el signo de dos puntos. Un ejemplo una
IPv6podría ser: 2620:0aba2:0d01:2042:0100:8c4d:d370:72b4
📌 ️ — Para los que os preguntéis de porque se produce un salgo de la versión 4 de IP a la 6, el motivo es que la versión
IPv5no transcendió más allá del ámbito experimental. Y, por lo tanto, nunca llegó a utilizarse como una versión del IP (Protocolo de Internet).
Además, el motivo por el que se creó el protocolo de IPv6, fue la falta de direcciones ya que se están acabando las IPv4.
La versión 4 de IP tiene un espacio de direcciones de 32 bits, en cambio, la versión 6 ofrece un espacio de 128 bits.
En la siguiente imagen, podemos apreciar la diferencia en la cantidad de bits (de 32 o 128) en función del tipo del IP (v4 o v6):
1.7) IPs privadas VS IPs públicas 🔝
Dentro de las IP tenemos dos tipos: IP privadas (o internas) e IP públicas (o externas).
Direcciones de IP privadas (o internas)
Son las IP que asignamos a todos los dispositivos que pertenezcan a una red privada. Un ejemplo de ello, es la red domestica de nuestras casas en la que conectamos nuestro portátil asignándole una IP en concreto, otra IP para nuestro móvil, otra IP para nuestra Tablet… La finalidad de estas IP es la de identificar a cada uno de estos dispositivos dentro de nuestra red privada.
Rangos de direcciones privadas
Para el uso privado la IANA (Internet Assigned Numbers Authority) que la entidad encarga de supervisar la asignación (es decir, como se reparten) a nivel global las direcciones IP. La IANA ha asignado varios rangos (concretamente 3 para ser exactos) de direcciones para utilizar con las redes privadas.
Las direcciones privadas pueden ser de 3 tipos en función del rango de IP sobre el que trabajen:
- Clase A:
10.0.0.0a la10.255.255.255son las utilizadas en redes (privadas) de un gran tamaño, en grandes compañías. Como, por ejemplo: la red privada de Google. - Clase B:
172.16.0.0a la172.31.255.255son las utilizadas en redes (privadas) de tamaño medio. Como por ejemplo una red privada de colegio/supermercado. - Clase C:
192.168.0.0a192.168.255.255son las utilizadas en redes (privadas) pequeñas. Como por ejemplo una red domestica de una casa.
📌 ️ — Por tanto, las IP dentro de estos rangos son consideradas como no direccionable, debido a que no es exclusiva. Lo que provoca que pueda ser usada por cualquier red privada sin problema.
Protocolo DHCP y diferencias entre IP estática VS IP dinámica
📌 ️ — DHCP = Dynamic Host Configuration Protocol cuya traducción sería algo así como Protocolo de Configuración Dinámica de Host
En las redes privadas, aunque cuando nos conectamos a un router podemos configurar nuestras IP como estáticas, es decir, fijas (que no cambian) y asignarlas nosotros de forma manual.
Aunque de esto, es decir, de la asignación de las IP, usualmente, se encarga el servidor DHCP ya que este, tiene la capacidad de asignar automáticamente direcciones IP reutilizables (que van cambiando) sin que el usuario tenga que hacer nada.
📌 ️ — Normalmente, en la actualidad los routers vienen configurados automáticamente con un servidor
DHCPactivado simplificando al máximo el proceso de asignación deIPs.
Pero ¿Qué significa que son reutilizables? Pues que tienen una determinada duración, es decir, que caducan en un determinado tiempo.
Si no tenemos una dirección IP asignada o bien ha caducado la dirección IP que teníamos asignada e intentamos volver a conectar con el router, el servidor DHCP nos proporcionará una IP (que puede o no ser la misma) pero no tiene por qué ser la misma, podría ser otra distinta.
Un ejemplo de un posible caso real, podría ser el de una persona que va a un hotel unos días y se conecta a un router vía WIFI. Una vez superado el tiempo asignado por el servidor DHCP, la IP caducará volviendo al servidor DHCP (se marca como libre en la base de datos que internamente tiene el DHCP) para que se pueda asignar a otro dispositivo y que así la red siempre tenga IPs disponibles.
Partes de una IP: Network Part VS Host Part
Para entender porque una red permite que se conecten más dispositivos o menos, es necesario entender que una dirección IPv4 consta de 4 bloques de 8 bits. Por lo que:
4 bloques X 8 bits = 32 bits
Estos 4 bloques de 8 bits, se pueden repartir de distintas formas en función del tipo de clase a la que pertenezca la IP ante la que nos encontramos.
- Network part (identificador de red): identifica de forma única la red.
- Host part (identificador de dispositivo): identifica al dispositivo dentro de una red.
📌 ️ — Aunque como mínimo cada uno de los bloques (Network part y Host part) deben tener 1 bloque de 8 bits para poder identificar dispositivos.
🎯Pregunta ¿A qué tipo de clase pertenece la siguiente IP?
Para saber cuál es mi dirección IP interna/privada abrimos el CMD y ejecutamos ipconfig:
En este caso en concreto, al ser una red doméstica, podemos ver que mi IP (192.168.1.42) es de tipo C.
Direcciones de IP públicas (o externas):
Son las nos proporciona nuestro proveedor de servicios de internet (ISP). Algunos ejemplos de proveedores pueden ser Jazztel, Movistar, Orange… cuando realizamos un contrato con ellos. Las IP públicas nos las asigna nuestro Proveedor de Servicios de Internet (ISP) nos permite que nuestro router tenga una dirección pública lo que supone que podrá comunicarse con otras IP públicas de internet. Además, conectaran dicho router a junto a una serie de infraestructuras de telecomunicaciones para que pueda realizar dichas comunicaciones con el exterior.
Las direcciones públicas, son todas la que no son direcciones IP privadas. De la misma forma que pasa con las privadas, pueden ser de distintos tipos en función del rango de IP sobre el que trabajen:
- Clase A:
1.0.0.0a126.255.255.255(con la excepción de las que pertenecen las lasIPprivadas10.0.0.0a la10.255.255.255). - Clase B:
128.0.0.0a191.255.255.255(con la excepción de las que pertenecen las lasIPprivadas172.16.0.0a la172.31.255.255). - Clase C:
192.0.0.0a223.255.255.255(con la excepción de las que pertenecen las lasIPprivadas192.168.0.0a192.168.255.255). - Clase D:
224.0.0.0a239.255.255.255. - Clase E:
240.0.0.0a254.255.255.255.
Para obtener mi IP externa/publica, realizamos lo siguiente:
En este caso, como mi IP (es 37.15.xxx.xxx) es una dirección de clase A.
Aunque existe otra opción mucho más sencilla sería la de visitar webs como cúal es mi IP lo que nos facilitará hasta cual es el proveedor de Internet (ISP)que tiene dicha IP:
En este caso, como mi IP (es 37.15.xxx.xxx) es una dirección de clase A.
📌 ️ — Por tanto, IP privadas son las que nos permiten comunicarnos con los dispositivos conectados a una red privada. En cambio, la IP publica son las que nos permiten lanzar nuestras peticiones hacía internet.
Por tanto, y a modo de resumen, los rangos de las IPs públicas y privadas que podemos usar son:
📌 ️ — Lo habitual cuando realizamos una comunicación hacía internet (rango de IP público) es el tener un dispositivo dentro de una red privada que realice las peticiones a nuestro router, para que finalmente, sea este el que se comuniqué con otro router de otra red privada.
1.8) ¿Qué es localhost? Hogar, dulce hogar… 🔝
La dirección IP 127.0.0.1 es la reservada para referirse a este equipo propio. Aunque puede ser cambiada por defecto es esa IP. Por tanto, cualquier ordenador que intente acceder a 127.0.0.1 estará intentado acceder a sí mismo. Por esta razón esta IP es conocida como IP de loopback (bucle invertido).
De ahí la mítica frase:
“There’s no place like… 127.0.0.1”
No hay nada mejor que…(casa) 127.0.0.1
O también la frase:
127.0.0.1 sweet 127.0.0.1
Hogar dulce hogar
Pero, si ya tenemos una IP asignada por el router para nuestro dispositivo
¿Para qué queremos tener otra IP?
Un equipo puede acceder a múltiples ocasiones a servicios o utilidades propias. Por ejemplo, a la hora de probar una página web que estemos creando es mejor que en vez de acceder sencillamente a un directorio con datos, use el equipo propio como si fuese internet. Accediendo a sí mismo como si fuera un cliente. Con ello, las pruebas de este equipo serán muchísimo más fiables.
📌 ️ — Aunque actualmente se sigue utilizando el protocolo IPv4, cuando finalmente empecemos a utilizar a la versión 6 de IP, la IP de localhost será
0:0:0:0:0:0:0:1que a su vez también se puede representar como::1
La dirección de loopback es una dirección IP especial que los hosts utilizan para dirigir el tráfico hacia ellos mismos.
La dirección loopback, es, por tanto, una dirección IP (también conocida como localhost) reservada específicamente para probar el funcionamiento de TCP/IP en un dispositivo.
De hecho, si intentamos acceder a localhost o en su defecto a la dirección IP IP 127.0.0.1 podemos ver que el navegador no nos responde:
Esto mensaje se produce debido a que aún no tentemos configurado un servidor (lo enseñaremos en su debido momento a lo largo del curso) pero si lo tuviéramos correctamente configurado podríamos ver algo así:
Lo que nos permitirá hacer un desarrollo de una forma más “real” que si abrimos los ficheros HTML directamente desde nuestro navegador.
1.9) Historia de internet y orígenes de la web (World Wide Web) 🔝
Presentando a ARPANET, la futura internet
La creación de la red Internet, es decir, lo que conocemos habitualmente como “internet” y de la web se basa inicialmente en los estudios realizados por el departamento de defensa estadounidense más conocido como DARPA (Defense Advanced Research Projects Agency). Concretamente, para el proyecto ARPANET (Advanced Research Projects Agency Network), que consistía en una red de computadores conectados en red utilizada para diferentes instituciones académicas y estatales.
📌 ️ — Esta agencia (DARPA), dependiente del Departamento de Defensa, nació en 1958 con el objetivo de desarrollar proyectos de tecnología militar en plena Guerra Fría. EE.UU. quería contrarrestar los avances de la antigua URSS.
En sus inicios en 1968 la red del proyecto ARPANET, contaba con 4 ordenadores que estaban distribuidos entre distintas universidades del país. Dos años más tarde, la red disponía de unos 40 ordenadores conectados. Tanto fue el crecimiento de la red que su sistema de comunicación se quedó obsoleto y posteriormente, se fueron creando nuevas redes.
📌 ️ — Su primer nodo fue creado en la Universidad de California en Los Ángeles, y constituyó la espina dorsal de Internet hasta el año 1990.
El primer mensaje enviado en Internet
El 29 de octubre de 1969 a las 22:30 horas, hora de California, en el Hall 3420 de UCLA Boelter Hall (Universidad de California, Los Ángeles), los investigadores establecieron la primera conexión entre dos ordenadores remotos en la red militar ARPANET de EE. UU.
📌 ️ — La primera transmisión remota de datos fue de una computadora en UCLA a otra computadora en el Instituto de Investigación de Stanford (ahora conocido como SRI International) en el otro lado de California.
El ingeniero Leonard Kleinrock acompañado por el estudiante Charley Kline (UCLA) intentan transmitir el texto “login” (inicio de sesión) a la computadora del Instituto de Investigación de Stanford. En lo que se conoce como la primera conexión entre dos ordenadores remotos en la red militar ARPANET de EE. UU (el precursor de la Internet actual).
Problemas con el envío del mensaje…
Justo después de enviar las letras “l” y “o”, hubo un problema en el sistema y este colapsó, haciendo que el primer mensaje enviado en Internet fuera “lo”. Más tarde, aproximadamente una hora después de recuperarse del bloqueo, el texto completo de “login” se envía con éxito.
BNN Technologies fue la compañía elegida para implementar esta red. Fue en esa época en que se propuso la creación del IMPs (Interface Message Processor) dedicados a recibir y redirigir paquetes de datos a los equipos correspondientes, es decir, una versión muy básica de lo que hoy conocemos como routers.
De hecho, inclusive si nos fijamos, podemos en la hoja de la transmisión aparece escrito lo un mensaje “Loaded op. program for BEN BARKER BBN” que nos confirma que el envío se realizó con IMPs (Interface Message Processor).
La noticia como os podéis imaginar fue un 💥💣️autentico bombazo💥💣️ lo que provocó que apareciera hasta en la prensa:
Creación de lo que actualmente conocemos como TCP/IP
📌 ️ — En aquellos años 60 y 70, aún no existía un modelo estándar de comunicaciones. Se necesitaba estudiar y planificar conceptos definitivos de diseño que normalizaran las comunicaciones ya que, en 1973, el futuro internet (
ARPANET) empezaba a crecer.
El nacimiento del Transmission Control Protocol (TCP) o Protocolo de Control de Transmisión, se realiza entre los años 1973 y 1974 por Vint Cerf y Robert Kahn.
Paralelamente, los desarrolladores de UNIX decidieron apostar fuerte por este protocolo (TCP/IP) y lo adoptan realizando mejoras sobre este, cediendo su uso a universidades, organismos públicos, e incluso proporcionando el código fuente.
📌 ️ — Finalmente,
TCP/IPse convirtió en el estándar de comunicaciones dentro de las redes informáticas (actualmente seguimos utilizando dicho protocolo).
Entre 1974 y 1982 se crearon gran cantidad de redes entre las que destacaron:
- Telenet (1974): Versión comercial de
TCP/IP. - Usenet (1979): Sistema abierto centrado en el e-mail y que aún funciona.
- Bitnet (1981): Unía las universidades americanas usando sistemas IBM.
- Eunet (1982): Unía Reino Unido, Escandinavia y Holanda.
En aquel momento el mundo de las redes era un poco caótico, a pesar de que ARPANET seguía siendo el “estándar”, es decir, el centro de Internet mundial. EN 1982, ARPANET adoptó el protocolo TCP/IP y en aquel momento se creó Internet.
📌 ️ — El término web no toma su nombre en los orígenes de internet, en aquel entonces se utilizaba para tal efecto el término de
malla(en referencia a una arquitectura que utilizan las redes). El nombre dewebse popularizo con el paso del tiempo.
1.10) Navegadores y nacimiento de la WWW (World Wide Web) 🔝
En 1985, Internet ya era una tecnología establecida, aunque conocida por unos pocos afortunados, pero aún no era lo suficientemente accesible.
En la CERN (Consejo Europeo para la Investigación Nuclear) trabajaba con miles de científicos de todo el mundo. Estos científicos, generaban miles de informes, documentos, diseños… que estaban distribuidos por ordenadores de todo el mundo. Desgraciadamente, estos científicos se encontraban con el problema de que no podían compartir dicha información con otros científicos.
Por todo ello, finalmente, se produce el gran paso y el 6 de agosto de 1991 Berners-Lee (que trabajaba en la CERN como ingeniero de software) crea NeXTcube como el primer servidor web del mundo para la CERN.
📌 ️ — Nos podemos hacer a la idea de los sistemas de seguridad que tenía la web observando la pegatina con la advertencia: “This machine is a server DO NOT POWER IT DOWN!!” (“Esta máquina es un servidor ¡No lo apagues!”). ¡Y es que, si alguien hubiese apagado ese ordenador se habría cargado la World Wide Web, literalmente!
El sitio creado por Tim Berners-Lee todavía no tenía ningún gráfico de computadora o multimedia, estaba completamente basado en texto.
Más tarde, ya en la década de 1990, concretamente a partir de 1991, tras la creación del primer servidor, estás tecnologías fueron evolucionado lo suficiente, empezaron a expandirse y se introduzco el primer navegador del mundo World Wide Web creado también por Berners-Lee.
Ejemplo del navegador World Wide Web (WWW):
La World Wide Web — comúnmente conocida como WWW, W3, o la Web — es un sistema interconectado de páginas web públicas accesibles a través de internet. La Web no es lo mismo que el Internet: la Web es una de las muchas aplicaciones construidas sobre Internet.
📌 ️ — El gran avance de Berners-Lee fue unir hipertexto e Internet. Su objetivo era el intercambio de datos entre los miles de científicos que trabajaban en el Centro Europeo de Física Nuclear de Ginebra, (Suiza).
Por cierto, todavía está operativa la primera web del mundo. Si buscamos en Google: ‘info cern ch’ nos mostrará lo siguiente:
📌 ️ — Tal y como podéis observar, la primera web actual, era muy similar a un fichero
readme.txt(léeme.txt) actual.
Aunque antes de 1993 se lanzaron algunos navegadores, no fue hasta este año 1993 donde se empezó a popularizar su uso primeramente mediante navegador Mosaic, que permitió acceder con mayor naturalidad a la WWW.
Años después, ya en 1995, se lanza al mercado el navegador Netscape.
A partir de entonces, Internet comenzó a crecer más rápido que otro medio de comunicación, convirtiéndose en lo que hoy todos conocemos.
Para que os hagáis una idea, os dejo una imagen que muestra como era Google en su primera versión 😵💫¡Ese logo hace daño a los ojos!😵💫
Finalmente, os dejo el interesantísimo documental “La guerra de los navegadores” que pertenece a la serie La verdadera historia de la Internet creado por la productora Discovery Channel. Os aconsejo su visualización para coger más contexto sobre los orígenes de la web:
🎥 La guerra de los navegadores — Discovery Channel🎥:
1.11) Protocolo HTTP: el modelo cliente-servidor con petición y respuesta 🔝
📌 ️ — HTTP = HyperText Transfer Protocol
El modelo HTTP tiene 2 capas de software cliente y servidor. ES MUY IMPORTANTE, no confundir con dos máquinas, sino dos capas de software, ya que pueden estar:
- En una misma máquina: por ejemplo, cuando realizamos el desarrollo de una web.
- En máquinas diferentes: por ejemplo, cuando realizamos una consulta/petición a una web.
Independientemente de si ambas capas están en una misma máquina o no, la capa del cliente (client) envía una solicitud (HTTP Request) para que finalmente la capa del servidor (server) responda a dicha solicitud (con una HTTP Response).
📌 ️ — La capa de cliente solamente puede realizar solicitudes (
HTTP Request) y la capa de servidor solamente puede enviar respuestas (HTTP Response).La petición/solicitud (o en inglés
request) es la localización de un recurso oURLen concreto. Por ejemplo, cuando queremos realizar una búsqueda visitamos www.google.esLa respuesta (o en inglés
response) es la encarga de enviar al cliente (en este caso en navegador) la respuesta que nos ha devuelto el servidor tras realizar la petición (request).
HTTPha trabajado con la web desde sus orígenes e a ido pasando por distintas versiones a lo largo de su vida, en la actualidad estamos trabajando sobre la versión 3.0 deHTTP:
1.12) Presentando a HTTPs y explicando las diferencias respecto al protocolo HTTP 🔝
Si miramos las capas con las que trabaja el protocolo HTTP podemos ver que tenemos IP (para realizar comunicaciones de red), TCP (para realizar el transporte) y, por encima de todo ello, HTTP.
En cambio, si analizamos al protocolo HTTPS (o HyperText Transfer Protocol Secure) podemos ver es idéntico HTTP pero que este añade una capa más dentro del transporte de la petición, y justamente encima de la capa TCP, la capa SSL/TSL.
Dentro de HTTPS se puede trabajar sobre el protocolo TSL (o Transport Layer Security) o su antecesor, SSL (Secure Sockets Layer). Ambos protocolos, tienen como finalidad evitar que la información pueda ser interceptada. Para ello, los datos generados en dichas comunicaciones son encriptados para que así se pueda asegurar la transmisión de datos de forma segura.
📌 ️ — Por tanto, 🔓
HTTP🔓 = trabaja con los protocolosTCPeIP.En cambio, 🔐
HTTPS🔐 = trabaja con los protocolosSSL/TSL,TCPeIP. Por lo que, la “S” deHTTPSse “traduce” en “Seguro” protegiendo dichas comunicaciones de lecturas no autorizadas.
Hasta hace pocos años, la gran mayoría de peticiones se realizaban por HTTP, pero desde que Google decidió marcar a las páginas HTTP como “no seguras” fue el punto y aparte para la adopción y finalmente su extensión por toda la comunidad del protocolo HTTPS.
Para saber si una web es 🔐segura🔐, es decir, trabaja con HTTPS realizamos lo siguiente:
1.13) Principales utilidades de las herramientas de desarrollador (Dev Tools) del browser 🔝
La respuesta a una petición puede ser distinta en función de muchos factores como, por ejemplo:
- Que no exista el recurso o la
URLsobre la que hacemos dicha solicitud, lo que según la convención devolverá un 404 (Not found). - Que el recurso sí que exista, pero el usuario no tenga autorización para acceder a dicho recurso, lo que según la convención devolverá un 401 (Unauthorized).
- Que el servidor tardé demasiado en responder a dicha solicitud, lo que según la convención devolverá 408 (Request Timeout).
Independientemente de si recibimos el recurso o no, el servidor nos va a responder y dicha respuesta (Response) viene acompañada de un HTTP Status Code.
Vamos a ver un ejemplo real de una petición. Para ello, abrimos el navegador, pulsamos botón derecho y finalmente hacemos clic sobre Inspeccionar:
Con ello, abrimos el inspector de navegador (más conocido por la comunidad como Dev Tools) que actualmente incluyen todos los navegadores web modernos y el cual nos proporciona un conjunto de herramientas enfocadas hacía los desarrolladores.
Este inspector nos permite entre otras cosas:
- Inspeccionar los archivo de la web (como documentos
HTML, hojas de estiloCSS, archivosJavaScript, etc.) e inclusive modificar algunas propiedades directamente en nuestra página web 🔥“en caliente”🔥 para ver cómo afectan a nuestra web. Por ejemplo, vamos a cambiar el color de fondo de Google:
- Cambiar a las distintas resoluciones (desktop, mobile, tablet…) para poder analizar el comportamiento de nuestra web en distintos dispositivos. Y, por ejemplo, comprobar si nuestra web se ve distinta en función del tipo de dispositivos en función de su resolución.
Por ejemplo, en este caso, hemos seleccionado la versión para iPad Mini:
- Identificar si se producen errores en nuestro código o si se imprimen mensajes por consola:
- Verificar si tenemos la cache activada o desactivada:
📌 ️ — El almacenamiento en caché web, tiene como objetivo almacenar datos/recursos que nos envía el servidor como respuesta con la finalidad de evitar tener que volver a cargarlos por cada petición que realicemos. La finalidad de todo esto es su reutilización futura de las peticiones al servidor produciendo con ello un aumento en la velocidad de carga del sitio web.
Cuando se desarrolla código se aconseja desactivar la caché con la finalidad de asegurarnos de que tenemos actualizada la web al 100 %. O, en caso contrario, trabajar sobre una ventana privada.
Para abrir una ventana privada realizamos lo siguiente:
Para saber si cuando hacemos una llamada los archivos están “cacheados” o no, realizamos lo siguiente:
- Mostrar que recursos ha solicitado la petición, cuanto tiempo han tardado en cargarse, etc.
1.14) Códigos de estado de respuesta HTTP (HTTP Status Codes) 🔝
Seguimos en las Dev Tools, concretamente, nos situamos sobre la ventana de Network y seleccionamos el fichero de tipo documento con nombre www.google.es:
También existe un pequeño “tip” (truco) que nos ofrece la posibilidad de filtrar los ficheros que se cargan en función en función del tipo:
Dentro de este apartado, una vez situados sobre el documento, vamos a ir al apartado Headers:
Si nos fijamos vemos que, en este caso, la respuesta nos devuelve el Status Code200, lo que significa que todo está OK, es decir, que la request ha funcionado como esperábamos y que ha tenido éxito.
📌 ️ — Toda petición
HTTPgenera un código de respuesta independientemente de si se responde con un recurso o con un error.
Los códigos de estado HTTP (HTTP Status Code) como el que acabamos de ver en dicha petición, están formados por 3 dígitos XXX. Aunque, los 3 dígitos son importantes, ya que entre todos nos permiten identificar de forma muy específica el tipo de respuesta ante la que nos encontramos.
Pese a ello, el número más importante de todos es el de más a la izquierda Xxx ya que es el que nos permite identificar de forma muy genérica a que grupo de respuestas pertenece el tipo de respuesta ante el que nos encontramos.
Las categorías mediante a las cuales podemos identificar (Xxx) a un grupo de respuesta son:
- INFORMATIONAL: Respuestas informativas (
100–199) - SUCCESS: Respuestas satisfactorias (
200–299) - REDIRECTION: Redirecciones (
300–399) - CLIENT ERROR: Errores del cliente (
400–499) - SERVER ERROR: Errores de servidor (
500–599)
Los siguientes dos números xXX nos permiten identificar concretamente sobre que código de respuesta HTTP en concreto nos encontramos. Por ejemplo, dentro de la subcategoría de errores de cliente (CLIENT ERROR) (400–499) algunos de los errores específicos (4xx) pueden ser:
- 400 → Bad Request
- 403 → Forbidden
- 404 →Not Found
- 408 → Request Timeout
¿Nos podríamos llegar a saltar esta convención (la de los códigos de Status Code) cuando desarrollamos en el Back? Sí, pero solamente cuando estemos desarrollando desde el lado que responde a la petición (en este caso desde el servidorBackEnd de Google). Y desde allí, por ejemplo, sí que podríamos definir que cuando nuestro servidor debería de mostrar un código de respuesta 200 (que significa OK) ya que la web nos ha cargado correctamente, nos devolviera un 404 (que significa Not Found) incluso cuando devuelva el recurso, etc. Esto no tendría sentido ya que nos estaríamos pasando a la torera la convención de Status Code y la estaríamos aplicando incorrectamente lo que en un futuro puede provocar confusiones entre los desarrolladores que tengan que realizar el mantenimiento de la aplicación.
Aunque lo entenderemos mejor en el siguiente apartado, ya que es un tema bastante complejo. La responsabilidad de tomar una decisión sobre el tipo de código de respuesta (Status Code) que nos responde una petición en una determinada situación se encargan las aplicaciones del lado de BackEnd que han desarrollado los desarrolladores (en el caso los de Google) encargados del BackEnd (o en determinadas situaciones el propio browser) y que pueden estar definidas en distintos tipos de arquitecturas (como APIs REST, MVC, etc.) la cual ha sido implementada por el arquitecto de software basándose en una serie de requisitos y necesidades definidos por la compañía.
1.15) Introducción a los métodos de una petición HTTP (o HTTP request methods) 🔝
En el punto anterior, hemos visto que cuando hacemos una petición (request), la respuesta (response) a dicha petición nos retornará siempre un código de respuesta (Status Code).
Pero no hemos hablado de que cuando realizamos una request necesitamos indicar además de la URL que “atacamos” el verbo que vamos a utilizar. En este apartado, vamos a detenernos a hablar sobre los métodos HTTP. Por tanto, estos verbos (los HTTP request verbs) también forman parte de la petición (request) a un servidor desde el lado cliente.
📌 ️ — Los métodos de una petición HTTP (HTTP request methods), son también conocidos como: verbos HTTP (HTTP request verbs) o métodos HTTP (Methods HTTP).
1.16) ¿Cómo sé qué tipo de petición HTTP estoy realizando? ¿Y cómo sé que verbos trabaja? Ejemplo con Google 🔝
En cada petición HTTP, concretamente, nada más empezar la primera línea de la request nos encontramos el método HTTP utilizado durante dicha petición.
📌 ️ — En una gran mayoría de páginas, la primera petición a una página se hace hacía su página inicial. Y, por tanto, en una gran parte de las veces utilizamos
GETcomo métodoHTTPpara obtener la página inicial.
Para identificar ante qué tipo de petición nos encontramos tenemos que ir a la primera línea de un mensaje de petición y ver que verbo (también conocido como método) se está utilizando.
Si vamos a las Dev Tools del navegador (en mi caso estoy utilizando Firefox Develop Edition), abrimos el aparatado de Network y lanzamos una petición, podemos ver que se pide el fichero del directorio raíz con / y, que, posteriormente esta petición (request) internamente será la responsable de desencadenar tantas peticiones (requests) como necesite:
Por ejemplo, si el documento HTML tiene una imagen (como pasa con el logo de Google) podemos ver que esa imagen se solicita al servidor mediante a otra petición:
No en todos los navegadores se visualizarán igual las requests, por ejemplo, si utilizamos Brave, veremos que se nos visualizará de la siguiente manera:
En este caso, al cargar Google, el primer método que es ejecuta es el GET (cuando escribimos https://www.google.es/) que es el encargado de realizar la petición. En principio, GET se utiliza para solicita un recurso. En este caso, el recurso que se solicita el documento de tipo HTML.
Además, del tipo de petición que realizamos (GET, POST, GET, PUT…), podemos ver varias cosas más cómo por ejemplo: la versión HTTP sobre la que trabaja la petición HTTP/3, KB de transferencia, etc.
De hecho, si realizamos lo siguiente, inclusive podemos ver los detalles al completo de la petición que acabamos de realizar:
También, podemos activar el check de raw, para presentar la petición tal y como la envía el protocolo HTTP en su versión 3. En este caso (de ahí su nombre raw = cruda):
La petición que hemos lanzado, finalmente es respondida por el servidor de Google generado una respuesta que podemos ver en la parte inmediatamente superior, concretamente en el apartado de Request Headers:
Si nos fijamos, al hacer esa petición a https://www.google.com esa petición al ser hacía Google una web tan grande internamente ha generado muchas llamadas para realizar cosas internamente distintos tipos GET, POST…
1.17) Ejemplo con petición a la API de Chuck 🔝
En cambio, si realizamos una petición a cualquier página que no tenga la magnitud de Google. Como, por ejemplo, una API chiquitita como la de Chuck Norris que es más permisiva con las peticiones:
Y atacamos al end point (una de las URLs de una API o un BackEnd que responden a una petición): https://api.chucknorris.io/jokes/random podemos observar que nos devolverá una frase aleatoria en un JSON:
Pero vemos que el nivel de peticiones que se realiza nuestra request es mucho menor que en el caso anterior con Google.
O quizás sea que 👊Chuck👊 nos está observando y no quiere que haya más peticiones…
1.18) Partes de una request / response 🔝
En la siguiente imagen podemos ver las principales partes de una comunicación HTTP (request+response):
Si analizamos más a detalle la estructura, podemos ver que es la siguiente:
La primera línea de un mensaje de petición siempre empieza con un verbo HTTP (también se le conoce como método HTTP). Los verbos definen la acción que se quiere realizar sobre el recurso y, en parte, también la manera de realizar dicha petición.
1.19) Tipos de verbos HTTP (GET/POST/DELETE, PUT…) 🔝
📌 ️ — Los verbos (si se utilizan según la convención) nos permiten “identificar/indicar” que tipo de acción se quiere realizar sobre un recurso.
GET, POST, DELETE, PUT… El utilizar un tipo de verbo u otro, dependerá básicamente de lo que queramos hacer en el servidor:
Los verbos más comunes y sus usos más habituales son:
- GET: se utiliza para solicitar un recurso.
- POST: se utiliza para crear un recurso.
- PUT: se utiliza para actualizar/reemplazar un recurso al completo.
- PATCH: se utiliza para actualizar/reemplazar solamente una parte de un recurso.
- DELETE: se utiliza para eliminar un recurso.
📌 ️ — Existen otros métodos, pero estos que acabamos de ver son los más comunes.
Cada uno de estos métodos HTTP, posee unas ciertas características y peculiaridades que harán que utilicemos uno u otro en función de lo que queramos hacer aunque también tienen similitudes.
1.20) Diferencias entre los verbos GET y POST 🔝
📌 ️ — Los dos métodos más utilizados sin duda alguna son
GETyPOST.
Vamos a ver un ejemplo en el que se aprecian las diferencias de trabajar con ellos:
Si queremos enviar los datos de un formulario con una contraseña no es aconsejable que utilizaremos GET, ya que estos serán accesibles desde la URL, en cambio, si utilizamos POST, los datos viajarán internamente no pudiendo ser vistos desde la URL.
Además, aunque enviáramos unos datos que no tuvieran una relevancia transcendental (como por ejemplo el ID de un producto), y por tanto, no existirá problema en mostrarlos en la pantalla. En determinadas situaciones, además, existe un motivo estético ya que no es agradable ver una URLs como la del siguiente GET:
1.21) Si nosotros solamente estamos haciendo peticiones ¿Quién define estos métodos (GET, POST…)? 🔝
El que nosotros utilicemos un tipo de método u otro (GET, POST, GET, PUT…) dependerá de la persona (los arquitectos o los desarrolladores de software) que realiza el desarrollo o el mantenimiento de la aplicación que está corriendo dentro en el lado del servidor sobre el que queremos realizar nuestras peticiones.
Dicho desarrollador, definirá una serie de end points(las URLs de un API o un BackEnd que responden a una petición) que aceptaran un tipo de HTTP verbs que permitirán realizan peticiones al servidor desde el cliente. Si intentamos atacar a algo que tiene un end point o no utilizamos el HTTP request verbs correspondiente, los end points no serán repuestos y nos aparecerá un 404 Not found o bien serán redireccionados.
1.22) Ejemplo de diálogo HTTP que hacemos desde el cliente 🔝
Lo que internamente el cliente (el navegador) a petición de nosotros como usuarios realiza es lo siguiente:
- Obtener un recurso con el
URLhttp://www.google.es/ - Abrir una conexión al host http://www.google.com/, puerto 80 que es el puerto por defecto para
HTTP. - Se envía un mensaje del siguiente estilo siguiente:
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: nombre-cliente
[Línea en blanco]En mi caso en concreto, lanzando la petición a https://www.google.es, el mensaje en RAW (que hemos sacado desde las Dev Tools un poco más arriba) es el siguiente:
GET / HTTP/3
Host: www.google.es
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Alt-Used: www.google.es
Connection: keep-alive
Cookie: CONSENT=YES+srp.gws-20220127–0-RC3.es+FX+210; NID=511=ZEMQqbT02AX5uS9yRcVSvBRcfraCag5IBaGt2bLpIWFrlbHXiXBMg0ITIw5BJ — 9zrs6adADHi2nw3mMoK2iTvIOyvIYFIqpFyjS1tDBNTZC8m_MA05ppXEuw9sJFxZNiRiFP_HmPUurO8ujt6IyVKMd0RBztSdvWrofQcN8MsE; 1P_JAR=2022–02–02–23; ANID=AHWqTUk1iCYJx6CL67X2sNSu1h1Sr-7d17TTGGGq2EEikiu-VzyqC8JdF3PQlofQ
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
TE: trailers4. La respuesta del servidor está formada por encabezados seguidos del recurso solicitado, en el caso de una página web:
HTTP/1.1 200 OK
Date: Fri, 31 Dec 2003 23:59:59 GMT
Content-Type: text/html
Content-Length: 1221<html>
<body>
<h1> Página principal de tuHost</h1>
(Contenido)
.
.
.
<body>
</html>
En mi caso en concreto (lanzando la petición a https://www.google.es), el mensaje en RAW (que hemos sacado desde las Dev Tools un poco más arriba) es el siguiente:
HTTP/3 200 OK
date: Thu, 03 Feb 2022 01:03:20 GMT
expires: -1
cache-control: private, max-age=0
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=31536000
content-encoding: br
server: gws
content-length: 34477
x-xss-protection: 0
x-frame-options: SAMEORIGIN
set-cookie: 1P_JAR=2022-02-03-01; expires=Sat, 05-Mar-2022 01:03:20 GMT; path=/; domain=.google.es; Secure; SameSite=none
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"Ya hemos visto una petición completa de GET con el protocolo HTTP/3.
1.23) ¿Cómo realizar peticiones RAW desde el navegador? 🔝
Si abrimos el browser Firefox Developer Edition y, por ejemplo, realizamos dos peticiones diferentes en dos pestañas distintas. Una a Google, y la otra al end point de la API de Chuck sobre el que ya estamos trabajando.
Podemos editar y volver a enviar la petición que habíamos realizando anteriormente en Google. Para ello, copiamos el Raw del end point de Chuck, y finalmente, lo pegamos en la pestaña y realizamos la request:
Si analizamos lo que hemos realizado, podemos ver que hemos lanzado una petición desde la pestaña de Google hacía la API de Chuck. Es decir, lo que usualmente hace el nuestro navegador por nosotros
De hecho, si vamos a response, podemos ver inclusive la respuesta:
1.24) Realizando peticiones desde Postman 🔝
Postman es un programa muy popular que poder utilizar como alternativa al browser para realizar pruebas de peticiones a APIs, WebServices, etc. Es muy utilizado tanto por testers QA (Quality Assurance) como por desarrolladores (tanto del Front End como del Back End).
📌 ️ — ¡Tal y como dice en su página web, es usado por cerca de 17 millones de developers!
Postman, nos permite realizar peticiones de forma muy similar a lo que hemos realizado anteriormente con el navegador. En el ejemplo anterior, el cliente era el propio browser, y en este caso, el cliente sería Postman.
📌 ️ — Uno de los principales beneficios de Postman, es que nos permite permite guardar peticiones de forma sencilla para realizarlas a futuro, o poder pasarlas a otro developer.
Para realizar su instalación vamos a su web oficial, seleccionamos el sistema operativo correspondiente e instalamos el programa con el típico siguiente, siguiente… y finalmente pulsamos sobre finalizar.
Una vez instalado, vamos a realizar lo mismo que hemos realizado en la petición anterior, pero esta vez desde Postman. Para ello, pulsamos sobre el +:
Seleccionamos el tipo de petición (en este gasto GET), y ponemos los datos del Request Header (en formato RAW) en la petición de Postman.
Vamos a ver un ejemplo:
Cuando pulsamos el botón de SEND, enviamos la request, y vemos que, en mi caso, la request que acabo de realizar me ha respondiendo correctamente con un Status Code 200 OK:
1.25) Modelo TCP/IP y Modelo OSI 🔝
Explicando el modelo OSI
El modelo TCP/IP y el modelo OSI tienen ciertas similitudes y a su vez grandes ciertas diferencias. En este apartado, vamos a explicar las diferencias entre ambos:
El modelo OSI, no es una arquitectura (como sí que lo es TCP/IP) sino un estándar de comunicación en el que se definen un conjunto de normas y se especifican una serie de protocolos e interfaces a implementar en cada capa. El modelo OSI, fue propuesto por la Organización Internacional para la Estandarización (ISO), creado en 1977 y, finalmente aprobado en 1984. Define los sistemas de comunicación para que dos dispositivos en red se comuniquen usando una serie de protocolos estándar. Y consta de 7 capas o niveles, en los que cada uno de ellos tiene una serie de responsabilidades para realizar la comunicación entre dispositivos.
📌 ️ — El modelo OSI (u Open Systems Interconnection), también es conocido como ISO/IEC 7498–1
OSI, por tanto, es una normativa (NO UNA ARQUITECTURA), que está formada por siete capas en la que se define las diferentes fases por las que deben pasar los datos para viajar de un dispositivo a otro sobre una red de comunicaciones.
Eso sí, no hay que confundir una normativa, con una arquitectura. El modelo OSI sería algo similar a una especie de buenas prácticas que definen los pasos que debemos seguir para realizar nuestras comunicaciones.
📌 ️ — En la actualidad, continúa siendo muy útil de cara a la resolución de diversos problemas de red. La finalidad por la que se crea el modelo ISO, es la de descomponer/dividir el proceso complejo de realizar comunicaciones en red en varios problemas más sencillos y asignar dichos problemas a las distintas capas, de forma que una capa no tenga que preocuparse por lo que hacen las demás.
🏹Como decían los Romanos, ante un problema, ¡Divide y vencerás!🏹
La dirección en la que se pasa por las distintas capas depende de si se transmiten o si se reciben datos.
El modelo OSI no es la definición de una topología ni un modelo de red en sí mismo. Tampoco especifica ni define los protocolos que se utilizan en la comunicación, ya que estos están implementados de forma independiente a este modelo. Lo que realmente hace OSI es definir la funcionalidad de ellos para conseguir un estándar.
1.26) Explicando el modelo TCP/IP 🔝
📌 ️ — Cuando hablamos de “Protocolo TCP/IP” nos estamos refiriendo al uso combinado del protocolo
TCPcon el protocoloIP. Aunque también hay otros protocolos involucrados en las comunicaciones basadas en este modelo. Por tanto,TCP/IPno es un protocolo, sino más bien un conjunto de protocolos.
Cuyos significando son:
- TCP = Transmisssion Control Protocol o Protocolo de Control de Transmisión
- IP = Internet Protocol, Protocolo de Internet o Protocolo
IP
📌 ️ —
TCP/IP=IP(nos permite obtener la dirección IP al a que envían los datos) +TCP(se encarga de la entrega de los datos una vez hallada la dirección IP)
📌 ️ — El protocolo
TCP/IPno es un protocolo, sino más bien un conjunto de protocolos que dicta las normas que permiten que los datos viajen por la red, desde su origen hasta su destino.
La arquitectura de TCP/IP está compuesta por distintas capas o niveles, concretamente está compuesto por 4 o 5 capas o niveles ya que TCP/IP tiene dos modelos alternativos:
- El modelo original de 4 capas:
- El modelo actualizado (separa la última capa del modelo en dos y cambia el nombre de la penúltima):
La dirección en la que recorremos dichas capas (igual que pasaba en el modelo ISO) depende principalmente del tipo de si somos el emisor o el receptor de los datos:
Pese a que el protocolo TCP/IP fue creado entre 1973 y 1974 y, por lo tanto, existe desde antes de que se creará el estándar OSI cuya creación se remonta a mediados de los 80.
Podemos afirmar que TCP/IP cumple con el estándar OSI. Ya que lo que realmente realiza no es saltarse unos niveles, sino que los agrupa “a su manera”, juntando varias de las capas del modelo OSI en una sola capa. Vamos a verlo de una forma más gráfica:
Si nos fijamos, podemos ver como:
La 4ª capa del protocolo TCP/IP, Application Layer o Capa de Aplicación, en el modelo TCP/IP corresponde a una combinación de: la 5ª capa Sesión, la 6ª capa Presentación y 7ª capa Aplicación del modelo OSI.
La 3ª capa del protocolo TCP/IP, Transport Layer o Capa de Transporte, en el modelo TCP/IP corresponde a la 4ª capa Transport Layer del modelo OSI.
La 2ª capa del protocolo TCP/IP, Internet Layer o Capa de Internet, en el modelo TCP/IP corresponde a la 3ª capa Network Layer del modelo OSI.
La 1ª capa del protocolo TCP/IP, Network Interface o Capa de Interfaz de red, en el modelo TCP/IP corresponde a una combinación de: la 2ª capa Sesión y la 1ª capa Physical Layer del modelo OSI.
📌 ️ — Por tanto, TCP/IP utiliza todas las capas, aunque absorbe algunas capas dentro de algunas de sus capas. Eso sí, a diferencia del modelo OSI, el modelo TCP/IP sí que define los protocolos a utilizar, como por ejemplo el HTTP, el TCP o UDP…
En cada una de estas capas vamos encapsulando, es decir, agregando contenido extra al que hemos recibido en la capa superior.
Y, por ejemplo, en la primera capa añadimos los datos (el contenido) del mensaje en nivel de aplicación, posteriormente, vamos a la siguiente capa nivel de transporte y añadimos el protocolo que utilicemos (TCP/UDP), internet, red…
Dependiendo del punto en el que nos encontremos en la encapsulación, podemos estar hablando de datos, segmentos, paquetes o marco.
En cada una de las capas de TCP IP se utiliza un protocolo o una red. Basándonos en la arquitectura TCP IP antigua (la de 4 capas), todos los protocolos perecen al conjunto de las 3 capas superiores. Y finalmente la última capa será la encargada de utiliza la red.
Para garantizar el intercambio fiable de datos entre dos equipos, se deben llevar a cabo varias funciones o procedimientos. Para clasificar estas funciones, se utiliza un modelo en capas (niveles) para agrupar funciones relacionadas e implementarlas. Las capas están jerarquizadas y cada una de ellas se construye sobre su predecesora. De esta manera cada capa debe ocuparse de su nivel inferior (solicita servicios) y del nivel superior (devuelve resultados).
Las capas de TCP son:
4 ª Capa — Application Layer o Capa de Aplicación
3ª Capa — Transport Layer o Capa de Transporte
2ª Capa — Internet Layer o Capa de Internet
1ª Capa — Network Interface Layer o Capa de interfaz de red
Por tanto, una vez vistas las características del protocolo TCP podemos concluir con el siguiente resumen:
- TCP/IP está enfocado en la transferencia (envió y recepción) de paquetes de información (datos).
- TCP/IP tiene 5 capas que recorremos de forma ascendente o descendente en función de si somos el que realiza la petición o el que la responde.
- Está enfocado a la comunicación bidireccional (origen-destino).
- Norma OSI
1.27) HTTP/2 y la capa de transportes TCP 🔝
Hasta el protocolo HTTP/2 (estando este incluido), HTTP trabaja con el protocolo TCP en la capa de transporte.
¿Qué es un segmento en TCP?
📌 ️ — La segmentación es el proceso de dividir un gran flujo de datos en partes más pequeñas. Esta funcionalidad permite que un host envíe o reciba un archivo de cualquier tamaño a través de una red de cualquier tamaño. Por ejemplo, si el ancho de banda de la red es de 1 Mbps y el tamaño del archivo es de 100 Mb, el anfitrión puede dividir el archivo en 100 o más partes. Una vez que una pieza se vuelve menor o igual al tamaño del ancho de banda de la red, se puede transferir fácilmente. El anfitrión de destino, al recibir todas las piezas, las vuelve a unir para reproducir el archivo original.
Se llama segmento TCP a los paquetes de bits que constituyen las unidades de datos del protocolo de transporte TCP
¿Cómo está estructurado un segmento TCP? Un segmento está estructurado de manera:
La forma la que se crean estos segmentos TCP es encapsulando los datos de tal manera que les va añadiendo un encabezado (Header):
Y de esta forma se preparan para ser enviados por la capa de transporte TCP.
La comunicación de esta forma se realiza gracias a una serie de bits que forman parte del segmento:
Vamos a detenernos a explicar el funcionamiento de esta capa de transporte:
Orientado a la conexión (connetion oriented):
📌 ️ — TCP, utiliza el saludo de 3 vías (SYN — SYN/ACK — ACK) también conocido como TCP three-way handshake (o apretón de manos por tres vías)
Significado de cada “apretón” que forma parte de “los apretones” (SYN — SYN/ACK — ACK) sería el siguiente:
- SYN = SYNchronize = “sincronizar”
- SYN/ACK = SYNchronize / ACKnowledgement = “sincronizar / confirmación”
- ACK = ACKnowledgement = “confirmación”
Si analizamos el proceso de conexión TCP paso a paso, el saludo de 3 vías haría lo siguiente:
- El Host A (client) envía un paquete TCP SYNchronize al Host B (server). Por lo que la aplicación de cliente habla primero.
- Host B (server) recibe con éxito el SYN de parte de Host A (client).
- Host B (server) envía un SYNchronize-ACKnowledgement al Host A (client).
- Host A (client) recibe el SYN-ACK de parte de Host B (server).
- Host A (client) envía un ACKnowledge a Host B (server).
- Host B (server) recibe el ACK (acuse de recibo, es decir, confirma la recepción del mensaje) de Host A (client).
Aunque lo podríamos llegar a resumir en 3 pasos:
- En la que un servidor está esperando una conexión y un cliente solicita una conexión al servidor enviando un segmento SYN.
- Una vez el servidor recibe el segmento, response con un segmento SYN-ACK
- Finalmente, el cliente confirma con un segmento ACK y se establece la conexión entre ellos.
¡Tras esto, ahora sí, empieza la comunicación de datos real!
Full duplex: Se refiere a un método de transmisión de datos que ocurre en dos direcciones al mismo tiempo. Una vez establecida la conexión, TCP transmitirá datos en modo full-duplex. Al mismo tiempo, el host A y el host B pueden transmitir segmentos TCP al mismo tiempo y confirmar los paquetes TCP recibidos.
¿Qué tipos alternativas tenemos?
Por ejemplo, una radio utiliza simplex:
Half duplex: uno recibe y otro envía un ejemplo de ello, es un walkie talkie:
En cambio, en la conexión full duplex la comunicación es en ambas direcciones:
Un ejemplo muy clásico de comunicación full duplex es el de dos personas manteniendo una conversación telefónica:
En el protocolo full-duplex, cada conexión representa dos sesiones de comunicación unidireccionales.
Si analizamos este caso, el segmento 2 se ha perdido, pero la transferencia continua hasta que el cliente se da cuenta que no ha llegado bien y lo reenvía de nuevo.
Por ello ¡TCP es full duplex!
Contiable (reliable) también conocido como flujo controlador (Flow controlled): Durante la comunicación la entrada de datos puede fallar. Por ello, TCP nos proporciona mecanismos para que podamos que la entrega de datos es confiable. Por tanto, TCP garantiza que los datos no se corrompan y se entreguen correctamente al nodo de destino (servidor).
Vamos a ver un ejemplo:
A) La primera situación que nos podemos encontrar es que se pierda un segmento durante su envío al servidor:
B) La segunda situación que nos podemos encontrar es que se pierda un segmento de confirmación durante su envío al cliente:
Por tanto, es confiable ya que si un segmento no llega correctamente se reenvía evitando así la perdida de los datos contenidos en este:
Termina la conexión:
- Paso 1 (FIN desde el cliente): Aunque el servidor también puede cerrar la conexión, en este caso, vamos a hablar del escenario en el que es la aplicación del cliente la que solicita el FINished (finalizado) de la conexión. Y dicho cliente, se queda esperando el ACK (la sincronización de confirmación) por parte del servidor.
- Paso 2 (ACK del servidor): tras recibir el segmento FIN por parte del cliente, el servidor responde enviando un segmento ACK (de confirmación) al remitente (cliente). Llegados a este punto, el cliente no puede enviar más datos al servidor, aunque aún si que los puede recibir.
- Paso 3 (FIN del servidor): ahora el proceso se invierte y es el servidor el que a su vez va a cerrar la conexión enviando un FINished (finalizado) de la conexión al cliente. E inmediatamente, el server, se queda esperando el ACK (la sincronización de confirmación) por parte del cliente.
- Paso 4 (ACK del cliente): finalmente, el cliente y tras recibir el FINished (finalizado) por parte del servidor cierra la conexión.
Por tanto, si analizamos una comunicación completa podemos ver que sería algo así:
1.28) HTTP/3 cambia la capa de transporte a UDP 🔝
Hasta ahora hemos hablado de aplicaciones cuyas peticiones se transportaban bajo la capa TCP. En cambio, en el protocolo HTTP/3 la capa de transporte utiliza cambia de TCP a UDP ¡Y lo cambia todo!:
1.29) ¿Qué es un dominio? 🔝
Un dominio es el nombre que se utiliza para acceder a una dirección IP sin tener que recordarla.
📌 ️ — La principal finalidad de esto es la de poder acceder a un servidor mediante a un nombre que es más fácil de recordar que una dirección IP
¿Os imagináis acceder a Google, Youtube o Facebook directamente desde una IP? Os aseguro que con lo grande que es internet sería caótico. Tendríamos que tener un libro similar al antiguo listado de teléfonos (también conocido como páginas amarillas) en el que buscar las IPs a las que accedemos:
📌 ️ — Dominio = nombre que asociamos a un IP con la finalidad de simplificar el acceso a una web. Ya que es mucho más sencillo recordad Google que una IP 142.250.185.3
Además, utilizar dominios nos permite cambiar la dirección IP a la que apunta al dominio sin que esto afecte a como accede el usuario a nuestra web.
Dentro de una URL, el dominio es la parte englobada entre las WWW y la extensión del dominio:
📌 Por ejemplo: la URL www.google.es utiliza el dominio google.es mediante a la IP 142.250.185.3
1.30) ¿Quién realiza la transformación entre el nombre de dominio a una IP pública (o viceversa)? El protocolo DNS 🔝
El encargado de que podamos utilizar URLs con dominios (como por ejemplo http://www.google.es) en vez de utilizar URLs con IPs (como por ejemplo 142.250.185.3) es DNS (Domain Name System).
1.31) ¿Cómo identifico la IP a la que apunta un dominio? 🔝
Una manera muy simple de saber cual es la IP de un dominio, es utilizar la CMD, concretamente hacer ping a dicho dominio:
Una alternativa a esto sería la de realizar una petición a Google con el inspector abierto y buscar la petición correspondiente. Un ejemplo de ello podría ser:
Aunque Google tiene varias IP reservadas ya que podemos acceder desde varias:
Si metemos la dirección IP publica 142.250.200.110 o bien la dirección de IP publica 142.250.185.3 podremos ver que ambas nos redirigen al mismo dominio a www.google.es. Vamos a verlo:
Que una IP nos permita ir a un dominio es realizar justamente el proceso inverso hacer el proceso inverso ya que el DNs está formado por un conjunto de tablas (domain/IP) y siempre que utilicemos una IP
DBG
Visualización de rutas
Usando tracert google.com, la ruta se puede rastrear desde el lado del cliente (su computadora) hasta el host (google.com).
Desde arriba, puede ver la ruta desde mi dispositivo 192.168.1.254hasta el enrutador 10.243.128.1, antes de pasar por el proveedor de servicios de Internet (ISP) ubicado en Portugal, y así sucesivamente.
También lo podríamos hacer con el comando nslookup que es una herramienta de línea de comandos, cuya finalidad es la de encontrar la dirección IP de un equipo determinado o realizar una búsqueda DNS inversa (es decir, encontrar el nombre de dominio de una determinada dirección IP).
Petición a dominio:
El proceso de solución de DNS supone convertir un nombre de servidor (como www.ejemplo.com) en una dirección IP compatible con el ordenador (como 192.168.1.1).
DNS supone convertir un nombre de servidor (como www.ejemplo.com) en una dirección IP compatible con el ordenador (como 192.168.1.1). Se da una dirección IP a cada dispositivo en Internet, y esa dirección será necesaria para encontrar el dispositivo apropiado de Internet, al igual que se usa la dirección de una calle para encontrar una casa concreta. Cuando un usuario quiere cargar una página, se debe traducir lo que el usuario escribe en su navegador web (ejemplo.com) a una dirección que el ordenador pueda entender para poder localizar la página web de ejemplo.com.
Cuando visitamos una web, usualmente utilizamos los dominios y no las direcciones públicas de IP.
1.14) Funcionamiento de una petición
El funcionamiento de una petición empieza cuando se lanza una petición por ejemplo a www.google.es desde el navegador de nuestro dispositivo (pc, smartphone, etc).
Como nuestro dispositivo tiene una IP privada en concreto y queremos acceder a una IP publica, al estar conectados a un router, se envía dicha petición al router pasándole la request y la IP privada de dicho dispositivo (con la finalidad de identificar posteriormente a quién se debe enviar la respuesta de la request cuando se reciba) para que sea el router el encargado de lanzar dicha petición hacía internet.
Una vez dicha petición es recibida por el router, será lanzada desde la IP pública del ROUTER (la que nos ha proporcionado nuestro Proveedor de Servicios de Internet (ISP) por ejemplo en mi caso Jazztell) hacía otra la IP pública (contratada por otro proveedor de servicios de Internet [ISP]) donde está alojado el servidor sobre el que queremos realizar la petición.
Finalmente, una vez el servidor recibe la petición, envía una respuesta hacía nuestra IP pública (la del router) para que finalmente sea el router el que la envíe al dispositivo identificado con la IP privada que ha realizado la petición. Para que ahora sí, podamos ver la respuesta en el navegador:
las que utilizamos para salir a internet (IP publica) y las que tenemos para comunicarnos con nuestra red privada (IP privada).
Una dirección IP pública es una dirección a la que se puede acceder directamente desde Internet y que su proveedor de servicios de Internet (ISP) asigna a su router de red. Su dispositivo personal tiene una IP privada que permanece oculta cuando se conecta a Internet por medio de la IP pública del router.
Utilizar una dirección IP pública para conectarse a Internet es como utilizar un apartado de correos para el correo postal, en vez de dar la dirección de su casa. Es un poco más seguro, pero mucho más visible.
El servicio de internet que contratamos es el único que tiene una IP publica, en cambio el resto de los dispositivos tienen una IP privada que una vez llegada al router cambia para poder tener comunicación con otros servidores.
¿Qué es un sitio web?
Un sitio web o website, es un conjunto de uno o varios recursos web alojados en el mismo dominio (IP o IP asociada a un dominio)
¿Qué es el hosting?
El conjunto de servicios en el que se incluye almacenamiento (en un disco duro), en algunas ocasiones también incluye el dominio, etc. Que nos ofrecen/proporcionan ciertas empresas para albergar el contenido de nuestras webs.
Por ejemplo:
Tipos de dominios
La extensión de nuestro dominio es un mecanismo/convención que si se ha aplicado correctamente nos puede permitir identificar ante qué tipo de web nos encontramos. Por ejemplo, si una web acaba de .es si ha aplicado bien la convención de dominios será una web española, en cambio, si una web acaba en .edu y también ha seguido las convenciones definidas, la web será una web educativa.
Dentro de los dominios (aunque pueden existir más tipos como subdominios, etc) de forma resumida, existen principalmente dos tipos de dominios que son:
generic Top Level Domain (gTLD): si lo traducimos al castellano sería algo así como Dominios de Nivel Superior genéricos. Tienen una longitud de 3 o más letras algunos ejemplos de ello son:
- .com (organicaciones comerciales) aunque es el que se utiliza habitualmente para la gran mayoría de webs
- .edu destinado a empresas de educación/formación
- .gov destinado a instituciones gubernamentales
- .org destinado a organizaciones. Por ejemplo, el dominio wikipedia.org al que accedemos mediante la URL https://www.wikipedia.org
Algunos de ellos como los .edu o .gov están restringidos únicamente para ciertas autoridades, en cambio, otros como el .com pese a estar pensado para una clase en particular de organizaciones actualmente son utilizados por la mayoría de ellos sin restricción alguna
country code Top Level Domain (ccTLD) que si lo traducimos al castellano sería algo así como Dominio de Nivel Superior de código de país. Vamos a ver unos ejemplos
