Herramientas de diagnóstico de red

Es posible que se haya encontrado en alguna situación con problemas de conexión, ya sea hacia internet o en el interior de su propia red. En este tutorial se mostrarán algunas herramientas que le serán útiles para diagnosticar problemas que puedan surgir en su red.

Algunas de estas herramientas le serán muy conocidas, como por ejemplo ping o traceroute; otras puede que le resulten nuevas o que no las haya usado antes, como por ejemplo ncat y tshark.

Tabla de contenidos

1.- Conceptos básicos
  • Alias de IP: Permite asignar múltiples direcciones IP a una interfaz de red. La interfaz usará la misma dirección física para todas las direcciones IP.
  • ARP: Son las siglas de Address Resolution Protocol (Protocolo de Resolución de Direcciones). Es el protocolo que se encarga de emparejar las direcciones IP con direcciones físicas (MAC). Para ello envía un paquete ARP request a la dirección de difusión (broadcast) de la red, con la dirección IP por lo que se pregunta, y se espera un paquete de respuesta ARP reply con la dirección física. Para acelerar este proceso, cada host mantiene en memoria una tabla arp que relacionada las IP conocidas con sus respectivas MACs.
  • Dirección IP: Identificador numérico de un dispositivo dentro de una red TCP/IP.
  • ICMP: Son las siglas de Internet Control Message Protocol (Protocolo de control de Mensajes de Internet). Se usa para enviar mensajes de error o una respuesta eco informativa, como en el caso de ping o mtrace.
  • ISN: Son las siglas de Initial Sequence Number (Número Inicial de Secuencia). Los ISN son números, generados aleatoriamente, utilizados para ordenar y comparar paquetes.
  • MAC: Son las siglas de Media Access Control (Control de Acceso al Medio). Es un identificador hexadecimal que identifica de forma única a un dispositivo de red. También se le conoce como dirección física. La dirección MAC es independiente del protocolo usado.
  • MTU: Son las siglas de Maximum Transfer Unit (Unidad Máxima de Transmisión). Define el tamaño máximo de los paquetes de datos enviados a través del protocolo IP. El valor MTU para la mayoría de dispositivos de Internet es 1.472 bytes, aunque con tramas jumbo se puede llegar a 9.000 bytes.
  • Paquete SYN: Paquete que se utiliza en la creación de un socket para sincronizar los ISN, Initial Sequence Number (Número Inicial de Secuencia).
  • Paquete ACK: ACK son las siglas de acknoledgement (acuse de recibo). Es un paquete de confirmación de recepción.
  • Paquete RST: Es un paquete de anulación instantánea de la comunicación, es decir, no se precisa un paquete ACK de respuesta. En situaciones normales los paquetes RST se envían cuando no existe ningún demonio escuchando en el puerto al que intenta conectar el cliente.
  • TTL: Son las siglas de Time To Live (Tiempo de Vida). Es un valor numérico que define por cuantos nodos puede pasar un paquete antes de ser descartado. Conforme un paquete pasa por un nodo/router, se reduce en una unidad el valor de TTL. Si un nodo/router recibe un paquete con un valor TTL de 1, el router desecha el paquete. Al desechar el paquete, en función de como haya sido configurado el router, puede que envíe el mensaje TTL expired in transit a través del protocolo ICMP al host de origen.
  • Socket: Conexión TCP/IP.


2.- Nociones básicas sobre TCP/IP
Las direcciones IP permiten que los hosts de una red se encuentren y se comuniquen entre ellos, pero ¿cómo lo hacen? El proceso de creación de un socket, conexión TCP/IP, se produce en tres etapas: solicitud de conexión, confirmación de la conexión y la recepción de la confirmación.

En la primera etapa, solicitud de la conexión, el host que quiere iniciar el socket (host emisor) envía un paquete SYN al host con el que quiere comunicarse (host receptor). En la segunda etapa, confirmación de la conexión, el host receptor responde con un paquete ACK al host emisor, para indicar que está listo para comenzar la comunicación. En la última etapa, recepción de la confirmación, el host emisor devuelve un paquete ACK al host receptor, para informarle que ha recibido la confirmación de conexión y que va a comenzar a enviar datos. Una vez finalizada la comunicación, el host emisor cerrará la conexión con un paquete FIN.


3.- ping
Es la herramienta más utilizada para hacer una comprobación rápida del estado de la red. El uso, así como su interpretación es bastante sencillo, aunque ofrece multitud de opciones, algunas de las más interesantes son:

  • -c <número> Permite indicar el <número> de ping que quiere realizar. [+/-] Ver ejemplo.
  • -I <dirección IP> En caso de que su host tenga más de una dirección IP, ya sea por que tiene varios alias IP o varias interfaces de red, le permite indicar desde que dirección se lanzarán los pings. [+/-] Ver ejemplo.
  • -f Manda tantos paquetes como permita la conexión. Le será útil para poner a prueba su servidor frente a un ping flood, así como para comprobar que su política de iptables, que limita la cantidad de paquetes ICMP por segundo, funciona correctamente.
  • -t <número> Permite indicar el valor TTL de los paquetes ICMP enviados.

Sin al lanzar un ping a un servidor de Internet no obtiene respuesta, pruebe con otros ya que algunos servidores remotos bloquean activamente el tráfico ICMP y por tanto no responden a los pings. Si ha probado con varios host, y ninguno responde al ping es probable que su red no funcione correctamente.

4.- traceroute
Si puede hacer pings a los hosts de su intranet, pero no obtiene respuesta de los hosts de Internet, la herramienta traceroute le será de ayuda. La función de traceroute es determinar la ruta que se utiliza para llegar al destino indicado, para ello usan los mensajes TTL expired in transit para registrar los hosts por donde pasa.

A continuación veremos un ejemplo de como el comando ping se podría usar para trazar la ruta hasta un hosts destino cualquiera, para lo cual iremos aumentando en uno el valor TTL del ping hasta alcanzar el host objetivo.
agd-server # ping -c1 -t1 makeinstall.es
PING makeinstall.es (216.239.32.21) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Time to live exceeded

--- makeinstall.es ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

agd-server # ping -c1 -t2 makeinstall.es
PING makeinstall.es (216.239.32.21) 56(84) bytes of data.
From 1.76.220.87.dynamic.jazztel.es (87.220.76.1) icmp_seq=1 Time to live exceeded

--- makeinstall.es ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

agd-server # ping -c1 -t3 makeinstall.es
PING makeinstall.es (216.239.32.21) 56(84) bytes of data.

--- makeinstall.es ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

agd-server # ...
agd-server # ...
agd-server # ...

agd-server # ping -c1 -t12 makeinstall.es
PING makeinstall.es (216.239.38.21) 56(84) bytes of data.
From 216.239.46.85 icmp_seq=1 Time to live exceeded

--- makeinstall.es ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
El comando traceroute hace exactamente la misma operación que se ha llevado a cabo anteriormente, aunque de forma automatizada mandando pings con valores TTL que van aumentando en una unidad hasta alcanzar el destino. Algunos routers están configurados para no responder a los mensajes ICMP, y por ello aparecen líneas marcadas con * * * en la traza de salida.
agd-server # traceroute makeinstall.es
traceroute to makeinstall.es (216.239.36.21), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.989 ms  1.505 ms  2.335 ms
 2  1.76.220.87.dynamic.jazztel.es (87.220.76.1)  58.827 ms  59.022 ms  60.741 ms
 3  * * *
 4  218.216.106.212.static.jazztel.es (212.106.216.218)  76.022 ms 58.217.106.212.static.jazztel.es (212.106.217.58)  79.900 ms *
 5  * * *
 6  * * *
 7  2.217.106.212.static.jazztel.es (212.106.217.2)  43.372 ms  43.601 ms  46.106 ms
 8  216.239.49.230 (216.239.49.230)  48.112 ms 216.239.49.196 (216.239.49.196)  139.451 ms  49.545 ms
 9  209.85.240.28 (209.85.240.28)  69.545 ms  72.309 ms 209.85.251.200 (209.85.251.200)  81.124 ms
10  216.239.43.233 (216.239.43.233)  81.335 ms  81.624 ms 209.85.253.20 (209.85.253.20)  84.450 ms
11  209.85.249.31 (209.85.249.31)  84.076 ms  191.251 ms *
12  any-in-2415.1e100.net (216.239.36.21)  67.916 ms  64.298 ms  63.823 ms
Analizando la traza, puede determinar donde se pierden los paquetes ICMP lo cual le permitirá saber, al menos, donde se encuentra el problema. Si los paquetes ICMP se pierden en su hosts firewall es probable que su firewall esté bloqueando activamente el flujo de paquetes ICMP o incluso que este bloqueando la salida a Internet por completo. En este caso, deberá desactivar temporalmente el firewall y volver a realizar una traza para ver si es un problema de configuración incorrecta de iptables.


5.- ncat
Esta herramienta le permite comprobar si es posible acceder a un host a través de un determinado puerto. Le será especialmente útil cuando quiera probar la conexión a un puerto determinado a través de un cortafuegos.

Antes de lanzar el comando ncat, deberá asegurarse de cerrar cualquier demonio que este usando el puerto que quiere comprobar. En el siguiente ejemplo, vincularemos ncat al puerto 80 (el utilizado por los servidores web) por ello es imprescindible detener cualquier proceso que esté haciendo uso de dicho puerto.

Si no está seguro si algún proceso está haciendo uso del puerto al que quiere enlazar ncat, puede usar la herramienta netstat. En el siguiente ejemplo, se determinará que demonio esta haciendo uso del puerto 80 (http) mediante netstat, se detendrá el proceso y por último se vinculará ncat al puerto 80 del host agd-server:
agd-server # netstat -lpt | egrep "80|http"
tcp      0      0      *:http      *:*        LISTEN        3247/lighttpd
agd-server # /etc/init.d/lighttpd stop
 * Stopping lighttpd ...                                           [ ok ]
agd-server # netstat -lpt | egrep "80|http"
agd-server # ncat -l 80
A continuación, desde el host agd-desktop se intentará establecer una conexión telnet a través del puerto 80 con el host agd-server. Si se pueda establecer la conexión telnet y lo que se escriba en la conexión telnet desde agd-desktop aparece en la consola agd-server que esta corriendo el comanda ncat, significa que se puede acceder al host agd-server a través del puerto 80, o lo que es lo mismo, la configuración iptables de agd-server permite el tráfico entrante a través del puerto 80.
agd-desktop # telnet 192.168.1.120 80
Trying 192.168.1.120...
Connected to 192.168.1.120.
Escape character is '^]'.
Si lo que escriba aquí, al pulsar intro, aparece en la consola del host
remoto significa que se puede establecer una conexión entre ambos a través
del puerto 80. Es decir, que la configuración iptables actual permite el
tráfico entrante a través del puerto 80.
A continuación veremos si en el host remoto, agd-server, aparece lo que se ha escrito en la conexión telnet abierta desde agd-desktop.
agd-server # ncat -l 80
Si lo que escriba aquí, al pulsar intro, aparece en la consola del host
remoto significa que se puede establecer una conexión entre ambos a través
del puerto 80. Es decir, que la configuración iptables actual permite el
tráfico entrante a través del puerto 80.
Con ncat podrá poner a pruebas las reglas de su cortafuegos, para asegurarse de que los servicios que precisa no están siendo bloqueados por una configuración incorrecta de iptables. También podría usar ncat para determinar si las reglas son demasiadas permisivas, al no bloquear el tráfico a través del puerto analizado.


6.- tcpdump, wireshark y tshark
Las herramientas tcpdump, wireshark y tshark permiten ver el tráfico de red a nivel de paquetes. El número de paquetes que atraviesan cualquier interface de red es muy elevado, por ello es imprescindible el uso de filtros. El comando tcpdump ofrece pocas posibilidades de filtrado, lo que le obligará ha hacer uso de otras herramientas para filtar los resultados, como por ejemplo grep. Wireshark, y su versión por línea de comandos tshark, ofrecen muchas posibilidades para el filtrado y análisis de paquetes.

El uso de tshark es sencillo, y se resume en ejecutar tshark -i <interface>. Si quisiera monitorizar el tráfico de paquetes de su interfaz eth0, tan solo tendría que ejecutar tshark -i eth0. Sin embargo, como podrá comprobar al ejecutar dicho comando la cantidad de información es inmanejable por ello es necesario filtrar el contenido; y en este punto es donde destaca tshark frente a tcpdump.


6.1.- Filtrado de captura
La sintaxis para el filtrado hace uso de una serie de expresiones de filtrado de captura que pueden ser conectadas por las conjugaciones and/or o negadas mediante el operador not. Aunque no es estrictamente necesario, es recomendable usar la opción -f para indicar que el siguiente 'comando' es una expresión de filtrado, así como encerrar la expresión de filtrado entre comillas simples o dobles. A continuación podrá ver algunas expresiones de filtrado y sus ejemplos:

  • src|dst host Permite filtrar la captura de acuerdo a la dirección de origen (src) o destino (dst) indicada (host). A continuación podrá ver un ejemplo de uso, donde se monitoriza el flujo de paquetes a través de eth0 (-i eth0) y se establece un filtrado de captura de acuerdo al origen de los mismos.
    root@VM # tshark -i eth0 -f "src 192.168.1.120"
    Capturing on eth0
      0.000000 192.168.1.120 -> 192.168.1.121 ICMP Echo (ping) request  (id=0x2315, seq(be/le)=1/256, ttl=64)
      0.001587 RealtekU_4f:44:3c -> RealtekU_fa:f8:02 ARP 192.168.1.120 is at 52:54:00:4f:44:3c
      1.013733 192.168.1.120 -> 192.168.1.121 ICMP Echo (ping) request  (id=0x2315, seq(be/le)=2/512, ttl=64)
      6.023835 RealtekU_4f:44:3c -> RealtekU_fa:f8:02 ARP Who has 192.168.1.121?  Tell 192.168.1.120
    
    Si quisiera analizar el tráfico que mantiene su host con otro host, como por ejemplo con el host 192.168.1.120, podría hacerlo usando el operador or: tshark -i eth0 -f "src 192.168.1.120 or dst 192.168.1.120".
  • gateway host Permite filtrar aquellos paquetes que usan su host como pasarela, es decir, paquetes que sin tener origen ni destino al host, pasan a través de él.
  • tcp|udp port <port> Permite filtrar la captura de acuerdo al protocolo y puerto indicado. A continuación podrá ver un ejemplo, donde se monitoriza el tráfico tcp a través del puerto 23 (telnet).
    root@VM # tshark -i eth0 -f "tcp port 23"
    Capturing on eth0
      0.000000 192.168.1.20 -> 192.168.1.121 TCP 35447 > telnet [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSV=187461340 TSER=0 WS=7
      0.016197 192.168.1.121 -> 192.168.1.20 TCP telnet > 35447 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
    
    En la primera línea se observa como 192.168.1.20 intenta establecer un socket con 192.168.1.121 a través del puerto 23 (telnet). En la segunda línea 192.168.1.121 responde a 192.168.1.20 con un paquete RST para abortar la conexión. Este comportamiento se debe a que 192.168.1.121 no dispone de ningún servidor telnet en ejecución.

    Si lo desea puede combinar las opciones de filtrado [src|dst] host y [tcp|udp] port , así por ejemplo podría analizar la comunicación mantenida con un host concreto a través de un determinado puerto: tshark -i eth0 -f "src 192.168.1.120 and dst 192.168.1.121 and tcp port 80".
  • less|greater <length> Le permite filtrar en función del tamaño de paquete indicado; less para un tamaño menor igual al indicado, y greater para un tamaño mayor igual al indicado.

Una opción interesante, y que le será muy útil para la captura y posterior análisis, es -w ruta/archivo-de-registro. Así, por ejemplo, puede dejar tshark en ejecución capturando los paquetes que atraviesan el puerto 978 (el servidor de impresión de cups) en su host y guardar la captura en un archivo para un análisis posterior; tshark -i eth0 -f "port 978" -w /tmp/tshark.


6.2.- Filtrado de lectura
El verdadero potencial de wireshark/tshark se encuentra en su capacidad para emplear filtros complejos, permitiendo incluso combinar expresiones dentro de otras expresiones. Para hacer uso de las expresiones de filtrado de lectura es obligatorio el uso de la opción -R y encerrar la expresión entre comillas simples y dobles.

Note que aunque las expresiones de captura no necesitan ser indicadas expresamente ni encerradas entre comillas, las expresiones de lectura si; por ello es recomendable que tome la costumbre de siempre usar las opciones -f y -R para sus expresiones de captura y lectura, respectivamente, así como el entrecomillado de estas. A continuación veremos algunas expresiones de lectura, aunque podrá consultar una guía mas extensa en Wireshark Display Filter Reference.

  • ip.addr Dirección IP de origen o destino.
  • ip.dst Dirección ip de destino.
  • ip.src Dirección ip de origen. A continuación verá un ejemplo de uso, donde se hará un filtrado de lectura al archivo de registro capturado anteriormente con el comando tshark -i eth0 -f "port 978" -w /tmp/tshark:
    root@VM # tshark -r /tmp/tshark -R "ip.src == 192.168.1.20"
      1   0.000000 192.168.1.20 -> 192.168.1.121 TCP 44403 > 978 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSV=191138949 TSER=0 WS=7
    
  • ip.ttl Valor TTL.
  • ftp.request.command Filtra de acuerdo al comando enviado al servidor de FTP. A continuación podrá ver un ejemplo:
    root@VM # tshark -i eth0 -f "port 21" -R "ftp.request.command == help"
    Capturing on eth0
      0.000000 192.168.1.20 -> 192.168.1.121 FTP Request: help
    
  • http.request.method Filtra de acuerdo al tipo de petición al servidor web. A continuación podrá ver un ejemplo:
    root@VM # tshark -i eth0 -f "tcp port 80" -R "http.request.method == GET"
    Capturing on eth0
      0.000495 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/ HTTP/1.1 
      0.229474 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/components/com_jcomments/tpl/default/style.css?v=12 HTTP/1.1 
      0.230811 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/media/system/js/mootools.js HTTP/1.1 
      0.230847 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/media/system/js/caption.js HTTP/1.1 
      0.230873 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/system/css/system.css HTTP/1.1 
      0.230939 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/system/css/general.css HTTP/1.1 
      0.232470 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/css/style.css HTTP/1.1 
      0.232554 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/script.js HTTP/1.1 
      0.263991 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/images/M_images/pdf_button.png HTTP/1.1 
      0.264005 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/images/M_images/printButton.png HTTP/1.1 
      0.264109 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/images/M_images/emailButton.png HTTP/1.1 
      0.283150 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Page-BgTexture.jpg HTTP/1.1 
      0.335413 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Sheet-s.png HTTP/1.1 
      0.335423 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Sheet-h.png HTTP/1.1 
      0.335487 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Sheet-v.png HTTP/1.1 
      0.335592 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Sheet-c.png HTTP/1.1 
      0.335596 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Header.png HTTP/1.1 
      0.336131 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Header.jpg HTTP/1.1 
      0.336564 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Post-s.png HTTP/1.1 
      0.336580 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Post-h.png HTTP/1.1 
      0.337258 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Post-v.png HTTP/1.1 
      0.337263 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Post-c.png HTTP/1.1 
      0.414583 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/components/com_jcomments/tpl/default/images/jc_blog.gif HTTP/1.1 
      0.450343 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Block-s.png HTTP/1.1 
      0.450363 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Block-h.png HTTP/1.1 
      0.450367 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Block-v.png HTTP/1.1 
      0.450371 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Block-c.png HTTP/1.1 
      0.450379 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/BlockHeader.png HTTP/1.1 
      0.450399 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/BlockContent-s.png HTTP/1.1 
      0.450950 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/BlockContent-h.png HTTP/1.1 
      0.450954 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/BlockContent-v.png HTTP/1.1 
      0.451560 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/BlockContent-c.png HTTP/1.1 
      0.775194 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/livemarks.png HTTP/1.1 
      0.775206 192.168.1.20 -> 192.168.1.121 HTTP GET /blog/joomla/templates/ink_kidsland/images/Footer.png HTTP/1.1 
      0.873157 192.168.1.20 -> 192.168.1.121 HTTP GET /favicon.ico HTTP/1.1
    

Si esta interesado en dominar esta herramienta, deberá de leer al menos la Wireshark User's Guide y por supuesto tener siempre a mano la Wireshark Display Filter Reference.

5 comentarios:

#
Monty dijo...

Ni sé se esto es básico o intermedio... eso me alegra porque puede ser que sea intermedio y ya esté empezando a entender algo... je je
Muy buen apunte. Se agradece.

#
Unknown dijo...

Gracias a ti por leer-me.

#
Anónimo dijo...

Estimado Antonio Guillem

He leido con atención , perdón por hablar de otro tema, tu post en http://www.meneame.net/c/8018179 sobre como era internet hace 13 años. Mi sorpresa es que has nombrado a mi antigua página web, yo era {SiLiCiO}, www.arrakis.es/~silicio. La verdad es que me he alegrado mucho, parace que todo eso paso hace mucho jajaja.
un saludo y muchas gracias

#
Unknown dijo...

@Anónimo/{SiLiCiO}

Es increíble como ha cambiado la cosa en los últimos 15 años. Recuerdo cuando un gif animado era 'lo más' en la web y los juegos de rol se jugaban mediante una consola de telnet. Lo peor de aquella época, sin duda, eran los buscadores con resultados escasamente relevantes, eso sin contar cuando Olé y Ozú comenzaron a 'prostituirse' vendiendo los puestos de los resultados de búsqueda; no se si AltaVista llegó a usar estas tácticas.

A pesar de que hace relativamente poco tiempo, el salto ha sido abismal. Ya veremos donde estamos dentro de otros 15 años.

Saludos

#
Anónimo dijo...

@Anónimo/{SiLiCiO}
Estimado Antonio Guillen. Creo que internet se mueve , como el resto del mundo, de una forma cíclica pero a mucha más velocidad. Son muchos los que piensan que facebook ha revolucionado el mundo, cuando sabemos que las redes sociales ya existian antes que el caralibro. Es decir, internet se reinventa a mucha más velocidad que el resto del mundo, por ser en si mismo una técnología muy dinámica.
Sigo creyendo en el poder de las tecnologías básicas: la web, el correo electrónico, IRC y las news. Todos los nuevos inventos giran alrededor de esos y como decia "aquel", los romanos ya lo inventaron todo.
Por volver al tema de la nostalgia, recordar que, simplemente conseguir subir un archivo por FTP, recibir un correo electrónico o hacer una pequeña página web programando en html puro era una sensación de grandes pasos en la técnología. Ahora, en mi casa, todo está "enchufado" a la red y ya no tenemos que depender de infovía , por dios se me ponen los pelos de punta!!! jajajaj.
un saludo

Publicar un comentario

Recuerde que puede utilizar algunos códigos HTML como <b>para negrita</b>, <i>para cursiva</i> y <a href="URL">para enlaces</a>.