J001 Redes Ethernet y Protocolo TCP/IP

ADM

Las redes Ethernet
A finales de los 80, las mesas de todo el mundo había PCs, pero pasar la información de un PC a otro mediante disquetes, era lento, tedioso y se perdía información.

La llegada de las redes locales (LAN o Local Area Network) que permitían intercambiar información  y compartir recursos, como discos comunes, impresoras Láser y a ser posible alejar de la mesa de trabajo las ruidosas impresoras matriciales

Para las primeras redes surgieron las primeras propuestas y protocolos de transmisión de datos en red, como Banyan Vines, SPX de Novell y Netbios de Microsoft.

Después de mucho lío con las normas de conexión, se estandarizó un sistema de cables de acceso a la LAN (Local Area Network), llamado Ethernet, al que se conecta un PC mediante su conectro RJ45.

También se adoptó una conexión en estrella mediante HUBS o actualmente Switches, cuya labor era facilitar la conexión de los puestos a un concentrador ( HUB) y que en caso de rotura del cable, el propio sistema detectara el problema y reconectara la red local, dejando fuera al elemento problemático (Switch).

Además ofrecía la ventaja, para las grandes corporaciones de poder organizar las conexiones en armarios protegidos,  con capacidad de recablear fácilmente los puestos de trabajo
Al final quedó establecida una topologia de red Ethernet estandard que sigue en vigor hoy.

 

Cuando a mediados los 90, las redes locales dejaron de ser un problema técnico, porque ya funcionaban establemente, el problema empezó a ser, montar redes WAN (Wide Area Network) o redes de área extensa que permitieran interconectar las distintas oficinas de una empresa o incluso países para las grandes corporaciones (Aunque estas, ya disponían de sus líneas de comunicaciones a base de tirar de talonario)
Lo que ocurrió fue, sencillamente, que ninguno de los protocolos comerciales que hemos mencionado arriba tenían capacidad de escalarse para soportar adecuadamente el nuevo modelo WAN y poco menos que se vinieron abajo como un castillo de naipes.

Y además ya se estaba usando con éxito una alternativa viable en universidades y centros de investigación americanos.
 
Los protocolos de transporte TCP/IP
Por entonces en Estados Unidos, las universidades ya estaban usando una solución de código abierto con buenos resultados, que no tenía ese problema de escalabilidad y que permitía usarse en redes arbitrariamente grandes sin problemas, porque habían sido concebidas para eso.

Ese protocolo que había sido desarrollado inicialmente por el departamento de defensa americano llamado DARPA y se llamaba, TCP/IP.

El protocolo se desarrolló en plena guerra fría, pensando que el enemigo destruir, cualquiera de los centros neurálgicos de una red de mando. Si se ponía muchos centros de mando, al enemigo le bastaba con fabricar muchas bombas.

 
La solución fue… Que no hubiera un centro físico de mando y que cualquier nodo pudiera convertirse en uno. Por ello desarrollaron una red entre iguales, que podía adaptarse, aun si destruía medio país.

El resultado ha fue, que este diseño sin centro de poder, se presta de mil maravillas a la Internet moderna, y es un concepto clave, para entender porque ha podido crecer tanto y tan rápido; Gracias a que los militares desarrollaron las tecnologías precisas para esta contingencia… sin saberlo y con otro objetivo.

En pocos años TCPIP, barrió del mercado a las demás ofertas y hoy es la norma indiscutible de comunicaciones en redes LAN y WAN, a pesar de los esfuerzos de alguno por impedirlo, y además, es gratis.

TCP/IP viene de Transport Control Protocol / Internet Protocol, y está formado por digamos dos partes, el protocolo de transporte o TCP y el protocolo de Internet o IP. 

Lo importante es la idea de que en TCP/IP hay una parte que se encarga del transporte, un poco como el servicio postal, y otra parte que se encarga de dar sentido a los datos que recibes. Vamos algunos detalles.

A priori, no se sabe la longitud del mensaje que se va a enviar de un punto A a otro B.

Se monta un sistema de transporte de paquetes, es decir, los mensajes se trocean, en paquetes de tamaño fijo, se les añade cabeceras con la dirección de destino (De hecho, varias), el remitente, el número de paquetes que conforman el envío y varias cosas más propias de la gestión interna del protocolo de transporte.

Cuando envías un mensaje a través de la red Ethernet,  tus datos se encapsulan con cabeceras y colas para gestionar el envío y recepción de la información. Si además el protocolo de transporte es TCP, este añadirá sus propias cabeceras, con información pertinente, El IP repite la jugada y el Router Añade aún más envoltorios.
 

Afortunadamente el empaquetado y desempaquetado es automático y el usuario no llega ni a enterarse y aunque pudiera parecer que es un sistema que añade mucha sobrecarga al tráfico, la experiencia ha demostrado que es un sistema extraordinariamente eficaz, para transmitir información de forma confiable.

De ese modo si quieres enviar un sencillo email puede bastar con un paquete, pero si envías un vídeo  puedes requerir miles de ellos. Por eso el protocolo TCP dispone de las herramientas precisas para:

Partir el mensaje original en paquetes numerados de tamaño estándar de forma automática. (Un poco como sobres de correos estándar).

Rellenar la información postal del paquete para su transporte.

Gestionar el envío, transporte y recepción del paquete.

Reconstruir el envío original a partir de los paquetes individuales que se reciben en el destino.

Reclamar automáticamente cualquier paquete que se haya perdido y forzar su reenvío (Algo que estaría bien que correos copiase).

Pero cuando recibes el mensaje original, necesitas saber  qué hacer con él. De esto se encarga IP.

La idea básica, es un poco como el teléfono, que te garantiza que puedes hablar con Japón, basta con marcar el número. Pero, sorprendentemente, no te garantiza, que vayas a entender lo que te dicen. Son los protocolos de alto nivel IP, los que reconocen la norma del mensaje, el idioma, y te lo traducen a un modo que sea comprensible para ti.
 
Por supuesto solo son capaces de traducir un conjunto previamente pactado de protocolos, entre los que están:

HTTP, o Hyper Text Transfer Protocol, que seguro que os resulta familiar. Es una norma de presentación a base de un lenguaje llamado HTML ( Hyper Text Mark Up Lenguaje) que forma la base de la actual Internet.

HTTPS, lo mismo pero con un protocolo cifrado para asegurar la privacidad del intercambio de información (La S de HTTPS es de Secure)

FTP o File Transfer Protocol, Protocolo de transferencia de ficheros, para intercambiar ficheros entre dos puntos, aunque cada día se usa menos, porque el HTTP incluye un protocolo similar.

Protocolos adicionales estándard, de los que la mayor parte de los usuarios no son conscientes, pero que resultan vitales para el funcionamiento correcto del sistema, como DNS, DHCP, routing y similares, y otros menos conocidos fuera del mundo Linux como UDP,RCP o NFS.
 
Para poder realizar todas estas funciones, cada uno de los nodos que se conectan a una red TCP/IP debe cumplir con algunas normas.

La primera es que para acceder a TCP, tu adaptador de red tiene que tener un identificador único llamado dirección MAC, (Media Acces Control) que normalmente viene fijado en el hardware (Pero que en nuestros Arduinos pondremos a mano)

La segunda para acceder a una red IP, es tener una dirección IP única, de la forma A.B.C.D más una máscara de subred, que determina con quien puedes y no puedes hablar, y que de paso permite compartir el mismo cable e infraestructura de red a varias redes sin que se mezclen entre sí.

Si alguna vez habéis entrado a la configuración de la red en Windows en contrarás que la dirección IP está formada por 4 números desde 0x00 hasta 0xFF en hexadecimal o desde 0 hasta 255 en decimal, con excepción del 0 y el 255 que se usan para otras funciones.

Para unirte a una red local debes proporcionar una dirección IP valida, tu dirección IP debe ser del tipo 192.68.1.xx y no coincidir con otra que ya esté en uso.

Además deberás proporcionar tu Router por defecto, muy frecuentemente en redes domésticas se configura como 192.168.1.1, que es un especie de agente de reenvío para mensajes destinados a direcciones externas a tu red, por ejemplo a Internet y también conviene darle un servicio de DNS para resolver los nombres de dominio externos.

Si no estás muy versado en este tema, en general, es mejor que utilices un servicio DHCP para que te asigne datos válidos de configuración de tu red, eligiendo en el menú la opción: Obtener una dirección IP automáticamente.
 
Cuando se configura una red local es cada vez más frecuente elegir la opción de configuración automática mediante el servicio de DHCP, a condición claro está de que tal servicio exista en tu red.

DHCP significa Dynamic Host Control Protocol, o protocolo de control de nodo dinámico. Significa que cuando tú ordenador o teléfono despierta, levanta la mano pidiendo la vez y si el servicio existe, configura automáticamente la conexión a tu red de forma dinámica y sin intervención manual.

Si te conectas a Internet con un ADSL o conexión por fibra óptica, la probabilidad de que este protocolo configure tu conexión, tiende a la certeza.

Si vas a hacer pruebas, os aconsejo que primero anotéis los valores correctos en un papel y luego probéis, porque cualquier error os dejara desconectados de Internet.
 
Siempre que vayas a conectar un equipo a Internet o a tu red local, tendrás que rellenar una hoja de datos Arduino incluido.

Por último, nos queda el servicio de DNS. Seguramente hoy casi no conoces ningún número de teléfono de amigos o familiares. Y sin embargo hace unos años era habitual tener memorizados 20 o 30 teléfonos fijos. El motivo era que no podías marcar un teléfono sin conocer el número, y hoy sigue siendo verdad incluso con los teléfonos móviles, pero la diferencia es que tu teléfono celular guarda en memoria una lista privada con los nombres y números habituales.

Cuando tú eliges el nombre, el teléfono marca el número asociado y así tú te evitas tener que memorizarlos. Pero al utilizar listas privadas, se presentan ciertos problemas que es probable que hayas sufrido en alguna ocasión.
 
Para empezar si uno de tus contactos cambia de número, no te enteras hasta que él no te da su nuevo número. Y si cambias de teléfono el pasar tus contactos al nuevo teléfono, solía ser una peregrinación por el desierto, aunque últimamente ha mejorado bastante.
 
Con las direcciones de internet nos ocurre lo mismo. Su dirección física es una dirección IP que a nosotros nos cuesta recordar. Por ejemplo, si cada vez que vas a buscar algo tuvieras que teclear la dirección de Google, sería problemático, porque es fácil de olvidar: 

74.125.230.63
 
en realidad cuando se escribe una dirección en el navegador, hay servicio subterráneo llamado DNS (Domain Names Service) o servidor de nombres de dominio, que traduce el texto, que nos resulta natural y fácil de memorizar, por la dirección IP, que sería un asco tener que recordar o consultar en una libreta. Sin ese servicio es poco probable que Internet hubiera llegado muy lejos.

De hecho, si un servidor de Internet cambia de dirección física, por traslado o por cualquier otro motivo, basta con que actualice la dirección de la tabla y conserve el nombre. Ni siquiera te enterarás del cambio. Estaría bien poder hacer esos con los teléfonos.

Ahora que cada vez más móviles están permanentemente conectados a Internet, nos vendría bien un servicio de nombres telefónicos, de modo que escribiendo el nombre y apellidos de  alguien, el servicio buscara posibilidades próximas a ti, y te ofreciera opciones en caso de no encontrarlo o de encontrar varios.
 
Los Puertos TCP/IP
El protocolo IP se diseñó, con el concepto de cliente servidor en mente. Esto significa que unos equipos hacen de Servidores, prestan sus servicios a terceros bajos demanda, mientras que la mayor parte de los nodos (equipos) de la red son clientes que demandan atención y servicios.

El tipo de servicios que se demandan son variados y cambiantes, pero de algunos ya hemos hablado antes. Son, por ejemplo, DCHP o DNS, pero también Web Server, para mostrar las páginas web disponibles.

Habitualmente un mismo servidor físico, se destina a proporcionar varios servidores IP virtuales. No es raro que un mismo servidor actúe como Web Server y además proporcione servicios de DHCP y DNS, además de servidor de ficheros y tantos otros.
 

¿No sería mas sencillo poner un servidor físico para cada servicio IP y dejarnos de líos?

La respuesta es sí, pero los servidores son caros y hay aprovecharlos bien, ello suele ahorrar mucho dinero.

Por eso, se requiere una manera de que la máquina física decida con rapidez a cuál de sus servidores internos corresponde una petición IP determinada. 

Cada una de las peticiones IP que llegan vía Ethernet, llevan una propiedad que define exactamente esto, se llama puerto.

En TCP/IP se puede asignar un servicio a un número de puerto comprendido entre 0 y 2¹⁶ - 1, es decir entre 0 y 65.535; de este modo, un mensaje IP tiene una dirección IP que determina el nodo o equipo de la red a quien se destina y un puerto, que determina el servicio interno de ese equipo que debe responder a la petición.

Cuando se pone en marcha un servidor IP, se le asigna uno de estos puertos para que escuche peticiones. Es algo parecido a un buzón numerado, de forma que el servidor, pueda responder a quien se dirija a él.

Este número de buzón o de puerto tiende en muchos servicios a ser estándar, de modo que para ciertos servicios habituales no haya que imaginarse el puerto en que el servidor va a escuchar. Por ejemplo, lo normal en un servidor web es que escuche el puerto 80, de modo que un desconocido puede acceder a la página web que alberga.

Puertos normalizados al servicio habitual son:
21        FTP          Servicio de transferencia de ficheros
25        SMTP       Transporte de email
80        HTTP       Servidor Web
110      POP3        Recogida de correo

Es posible cambiar el puerto de escucha de un servidor, asignándole un puerto privado, pero conviene que entendáis que al hacerlo, solo quien conozca el puerto redirigido, podrá acceder al servidor (Lo que en ocasiones, es muy interesante por razones de seguridad).

El TCP/IP v6
El protocolo habitual TCPIP está en su versión 4, pero ya hace mucho que da señales claras de obsolescencia. El primer problema es que las direcciones son del tipo A.B.C.D.E, entre 0 y 255 lo que nos da:
255* 255* 255 *255 combinaciones = 4.228.250.625 o sea 4.200 millones de direcciones.

Aunque pueden parecer muchas, es evidente que hay muchas más maquinas conectadas a Internet en estos momentos que eso (El número de equipos conectados se estima sobre unos 5.000 millones y subiendo con rapidez).

¡Quieto ahí!,¿No dijimos al principio que cada nodo de Internet debe tener una dirección IP propia y diferente de las demás para evitar conflictos?, ¿Cómo puede conectarse 5 mil millones de chismes con 4.200 millones de direcciones y no chocar?

El truco está, precisamente, en los protocolos de alto nivel entre los que se encuentra uno, que nos resuelve la papeleta, el NAT (Network Address Translation o traducción de dirección de red) que se implementa en los Routers y que permite al Router suplantar tu identidad cuando haces peticiones a Internet.

El Router recibe tu petición, la efectúa en tu nombre y cuando recibe la respuesta te la entrega con un lacito como si nunca hubieras tenido un intermediario. Lo hace tan bien que probablemente no sabías ni que existía.

Y sabes más, en realidad lo hace no solo contigo, sino con todos y cada una de las peticiones de los nodos, o puestos, de tu red que pueden ser decenas, cientos o miles. De este modo toda la red con sus propias direcciones de red privadas, se enmascaran con una única dirección IP pública que es la única visible desde el exterior.

Por eso con un número limitado de direcciones públicas, pueden navegar miles de millones de direcciones privadas, de lo contrario, el crecimiento de Internet se hubiera frenado en seco hace años.

Para solventar este tipo de problemas y otros, se diseñó la nueva versión del protocolo que conocemos como IP v6 o IP6 y que está llamado a sustituir a IP4 en un plazo indeterminado por ahora.

IP6 usa direcciones de 8 grupos de 16 bits, con lo que las posibles direcciones son de:
2¹⁶ · 2¹⁶ · 2¹⁶· 2¹⁶ · 2¹⁶ · 2¹⁶ · 2¹⁶ ·2¹⁶  = 2¹⁶· 8 =2¹²⁸  = 3,4 · 10³⁸

Que naturalmente es un numerito que no hay calculadora que aguante. Si tenéis en cuenta que un billón en Europa es 10¹², entonces hablamos de algo más de unos 340 billones de billones de billones (y aquí, los decimales son más que las direcciones actuales disponibles).

Existen muchas otras consideraciones que recomienda la incorporación del protocolo IP en su versión 6 entre las que se cuentan:

Mayor posibilidad de definir seguridad en las comunicaciones y evitar historias de espionaje por parte de las administraciones públicas.

Garantizar la identidad de los nodos de una comunicación.

Mejoras importantes en la gestión de los routers y el tráfico, autentico cuello de botella actual en Internet y una de las razones de ser del nuevo protocolo.

Por último, comentar que tanto Windows como Mac OSX y Linux, soportan ya de forma nativa el TCP/IP v6, pero aún falta mucho por hacer en la adaptación de las redes públicas y que este va a ser un proceso lento y caro, pero que avanza poco a poco.

El motivo de contaros toda esta historia, es que en Arduino, vamos a trabajar con el protocolo IP4, y veremos cómo configurar varios de los datos correspondientes al TCP/IP para poder establecer comunicación con Internet.