Presentar las redes Ethernet.

  Presentar el TCP/IP.

  Describir una red de transporte.

  La configuración del IP.

  Algunos conceptos y descripciones precisas para entender el acceso a una red Ethernet.

 

 

Uno con leche ,gracias.

 

Cuando a finales de los 80, las mesas de trabajo de las empresas de todo el mundo estaban ya dotadas de sus modernos PCs, empezaba a ser molesto tener que pasar la información de un PC a otro mediante disquetes.

Si, Fue horrible. Muy poca capacidad: Entre 360k y 1400 K. Fijaros que son Ks y no Ms Lentos hasta aburrir y con una desagradable tendencia a corromperse y perder la información. [/fancy-ul] [/three-fourth][margin value=»20″ /]

Así que hubo que inventar las redes locales (LAN o Local Area Network) que permitieran intercambiar información  y compartir recursos, como discos comunes, impresoras Láser (Carísimas entonces) y a ser posible alejar de la mesa de trabajo las impresoras matriciales habituales entonces, cuyo ruido al imprimir por impacto, podía producir severos problemas psiquiátricos.

Surgieron las primeras propuestas y protocolos de transmisión de datos en red, como Banyan Vines, SPX de Novell y Netbios de Microsoft, que proliferaron como setas tras un chaparrón.

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, que estoy seguro os será familiar, porque si tienes un PC de sobremesa, es casi seguro que te conectes mediante uno, y cuyo absurdo nombre es 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 quede establecida una topo logia 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, siempre hubo clases)

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.
 

 

Por entonces las universidades yanquis ya estaban usando una solución de código abierto (No propietaria) 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 un departamento de defensa americano  llamado DARPA y se llamaba, quizás os suene, TCPIP.

El protocolo se desarrolló en plena guerra fría, pensando que el malvado enemigo podía volarnos de un bombazo, cualquiera de los centros neurálgicos de una red de mando. Si poníamos muchos centros de mando, al enemigo le bastaba con fabricar muchas bombas para dejarte sin centro de mando (Y era mucho más barato fabricar más bombas que más centros de mando)

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 nos volaban medio país.

El resultado ha sido, 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.

Gracias a Dios, 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 denodados esfuerzos de algunas marcas por impedirlo, y además, es de mi marca favorita: Gratis.

TCPIP 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.  Si cogéis cualquier manual al respecto os hablara inmediatamente de  los 7 niveles OSI de comunicaciones y de….., pasar directamente, que son unos pelmas.

Lo importante es que tengáis la idea de que en TCPIP 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 con los detalles (Pocos, lo prometo).

Como a priori, no sabemos la longitud del mensaje que se va a enviar de un punto a otro, se montó un sistema de transporte de paquetes. Esto es, 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 (Y los últimos niveles OSI de marras).

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.[/fancy-ul] [/three-fourth][margin value=»20″ /]

 

Para poder realizar todas estas funciones, cada uno de los nodos que se conectan a una red TCPIP 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 o Mac, en contraríes algo como esto:

Donde 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 en el rango de tu subred. No me atrevo a abusar de vuestra paciencia, disertando sobre cómo se determina tu subred, pero a grandes rasgos, si tu red es parecida a la de arriba, significa que 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 (Enseguida volvemos).

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ú anterior 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 cable, 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 parecida a estas de las imágenes, Arduino, incluido y será el tema de la próxima sesión.

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 (No tantos, no tantos) 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 y los fijos no.

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

Haced la prueba escribid esa dirección en vuestro navegador y veréis como os lleva a Google, porque en realidad cuando escribís una dirección en vuestro navegador, hay servicio subterráneo llamado DNS 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 ¿No?

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.
 

 

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.
 

Los que van a por nota se pueden estar preguntando, si no sería mas sencillo poner un servidor físico para cada servicio IP y dejarnos de líos.

Y la respuesta es, naturalmente, que los servidores son caros y aprovecharlos bien suele ahorrar mucha tela. [/fancy-ul] [/three-fourth][margin value=»20″ /]

 

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 TCIP 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 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 por eso quizás nunca hayas oído hablar de ello) 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^16*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.[/fancy-ul] [/three-fourth][margin value=»20″ /]

 

Por último, comentaros que tanto Windows como Mac OSX y Linux, soportan ya de forma nativa el TCPIP 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 TCPIP para poder establecer comunicación con Internet.

En la próxima sesión empezaremos a utilizar un Shield Ethernet para conectarnos a Internet, y necesitaremos conocer algunos de los conceptos que aquí hemos esbozado y nos evitaremos irlos contando en pildorillas sueltas, en medio de un programa. Siempre tiene más sentido cuando se presentan por sí mismos.
 

 

Hemos presentado el protocolo TCPIP.

Vimos conceptos laterales pero ineludibles en este mundo, como las redes Ethernet, las direcciones IP o MAC, los puertos, los DNS, DHCP y NAT.

Vimos porque la norma IPv4 está llegando a su final y hablamos de las ventajas de su futura substituta IPv6.