REST API con Sails – Adaptadores y MongoDB

Información de prueba

curl -is -X POST -d "username=josoroma&email=josoroma@example.com" http://localhost:1337/user

curl -is -X POST -d "username=celine&email=celine@example.com" http://localhost:1337/user

curl -is -X POST -d "username=uifi&email=uifi@example.com" http://localhost:1337/user/create

curl -is -X POST -d "username=coco&email=coco@example.com" http://localhost:1337/user/create
curl -is -X GET http://localhost:1337/user

curl -is http://localhost:1337/user

Generar REST API de ubicación

cd places

sails generate api location

sails lift

Listar

curl -is http://localhost:1337/location

Obtener un Registro desde el Browser

http://localhost:1337/user?where={"username":{"contains":"josoroma"}}

Por favor consulte: Find

Instalar MongoDB

brew install mongodb
lsof -iTCP -sTCP:LISTEN | grep mongo

mongod    337 user   11u  IPv4 0xfbda8d570c57142b      0t0  TCP localhost:27017 (LISTEN)
ps aux | grep '[m]ongo'

user          337   0.0  0.4  2718292  34692   ??  S     2:21PM   0:18.24 /usr/local/opt/mongodb/bin/mongod --config /usr/local/etc/mongod.conf
cat /usr/local/etc/mongod.conf

systemLog:
  destination: file
  path: /usr/local/var/log/mongodb/mongo.log
  logAppend: true
storage:
  dbPath: /usr/local/var/mongodb
net:
  bindIp: 127.0.0.1

Por favor consulte: Install MongoDB on OS-X

Instalar el adaptador MongoDB para nuestra aplicación

cd places

npm install -g sails-mongo --save

sails-mongo asocia/mapea el atributo lógico id con el _id de la capa física del Mongo id. En la versión actual de sails-mongo, no se debe ordenar por id.

Por favor consulte: sails-mongo

config/connections.js

mongo: {
  adapter: 'sails-mongo',
  host: '127.0.0.1',
  port: 27017,
  user: '',
  password: '',
  database: 'places'
},

Por favor consulte: Default MongoDB Port

lsof -iTCP -sTCP:LISTEN | egrep ':2701[7..9]'

mongod    337 user   11u  IPv4 0xfbda8c570c57143b      0t0  TCP localhost:27017 (LISTEN)

config/models.js

// Sails-Mongo Connection.
connection: 'mongo',

// Development Mode.
migrate: 'drop'

Lift

cd places

sails lift

Mongo desde la consola

mongo

Listar las Bases de Datos:

show dbs

admin   (empty)
local   0.078GB
places  0.078GB

Usar la Base de Datos llamada places:

use places

switched to db places

Listar las colecciones de la Base de Datos places:

show collections

location
system.indexes
user

Listar todos los documentos de la colección user:

db.user.find().pretty();

Por favor consulte:

Interacción agil con REST APIs

Postman

En Chrome es la herramienta más eficiente para probar, desarrollar y documentar una API. Agil para crear solicitudes complejas, volver atrás en el tiempo y ver los resultados de una manera amigable.

HTTPie

HTTPie es un cliente HTTP que se puede usar desde la línea de comandos, parece más fácil de usar que Curl.

curl -I http://reqr.es

HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Sun, 23 Nov 2014 04:44:08 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 10944
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
ETag: W/"CenpWUsIvfcCYkB+PleqTA=="

Imprimir la respuesta en formato JSON amigable

curl -s http://reqr.es/api/users | xargs -0 node -e 
"console.log(JSON.stringify(JSON.parse(process.argv[1]), null, 2))"

npm install -g json

curl -s http://reqr.es/api/users | json
{
  "page": 1,
  "per_page": 3,
  "total": 12,
  "total_pages": 4,
  "data": [
    {
      "id": 1,
      "first_name": "george",
      "last_name": "bluth",
      "avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/calebogden/128.jpg"
    },
    {
      "id": 2,
      "first_name": "lucille",
      "last_name": "bluth",
      "avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/josephstein/128.jpg"
    },
    {
      "id": 3,
      "first_name": "oscar",
      "last_name": "bluth",
      "avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/olegpogodaev/128.jpg"
    }
  ]
}

Estilo YAML con color

npm install -g prettyjson
curl -s http://reqr.es/api/users | prettyjson

Mi favorito es underscore-cli

npm install -g underscore-cli
curl -s http://reqr.es/api/users | underscore print --color

GET

curl -is http://reqr.es/api/users
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Sun, 23 Nov 2014 05:10:18 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 446
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
ETag: W/"1be-539742e1"

{"page":1,"per_page":3,"total":12,"total_pages":4,"data":[{"id":1,"first_name":"george","last_name":"bluth","avatar":"https://s3.amazonaws.com/uifaces/faces/twitter/calebogden/128.jpg"},{"id":2,"first_name":"lucille","last_name":"bluth","avatar":"https://s3.amazonaws.com/uifaces/faces/twitter/josephstein/128.jpg"},{"id":3,"first_name":"oscar","last_name":"bluth","avatar":"https://s3.amazonaws.com/uifaces/faces/twitter/olegpogodaev/128.jpg"}]}

POST

curl -is -X POST -d "name=Josoroma&job=Ninja" http://reqr.es/api/users
HTTP/1.1 201 Created
Server: nginx/1.6.2
Date: Sun, 23 Nov 2014 05:13:16 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 82
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *

{"name":"Josoroma","ob":"Ninja","id":"993","createdAt":"2014-11-23T05:13:16.017Z"}

PUT

curl -is -X PUT -d "name=Josoroma&job=Monk" http://reqr.es/api/users/2
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Sun, 23 Nov 2014 05:14:31 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 71
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *

{"name":"Josoroma","job":"Monk","updatedAt":"2014-11-23T05:14:31.618Z"}

DELETE

curl -is -X DELETE -d "name=Josoroma" http://reqr.es/api/users/2
HTTP/1.1 204 No Content
Server: nginx/1.6.2
Date: Sun, 23 Nov 2014 05:19:28 GMT
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *

Listar

curl -is http://jsonplaceholder.typicode.com/posts/1

Crear

curl -is -X POST -d "title=Heading&body=Content&userId=1" http://jsonplaceholder.typicode.com/posts

Actualizar

curl -is -X PUT -d "title=New Updated Heading&body=New Updated Content&userId=1" http://jsonplaceholder.typicode.com/posts/1
curl -is -X PATCH -d "title=New Patched Heading" http://jsonplaceholder.typicode.com/posts/1

Borrar

curl -is -X DELETE http://jsonplaceholder.typicode.com/posts/1

Filtrar

curl -s http://jsonplaceholder.typicode.com/posts?userId=1

Listar Recursos Anidados

curl -s http://jsonplaceholder.typicode.com/posts/1/comments

Watch your Sass!

Los navegadores Web sí entienden bien los archivos CSS, sin embargo no entienden los archivos Sass. Por esta razón, los archivos Saas necesitan ser procesados y transformados en archivos CSS. Con Sass es posible gestionar muchos archivos y combinarlos todos en un sólo archivo CSS.

Automatización de Saas para Ionic

Para dar salida de forma automática a un archivo CSS que el navegador Web sí pueda entender hay que “mirar” los archivos Sass de la aplicación para conocer si hay cambios. Por lo tanto, cada vez que se guardan cambios en un archivo Sass, también se reconstruye de manera automática el archivo CSS.

touch www/lib/ionic/scss/app.scss

sass --watch www/lib/ionic/scss/app.scss:www/css/app.css

Variables Sass

Hay que pensar en las variables como en una forma de almacenar información que se desea reusar a lo largo de la hoja de estilos. Pueden almacenar cosas como: colores, “font stacks”, o cualquier valor CSS que se necesite reutilizar.

Para más información, por favor consulte:

Para instalar Saas hay que tener instalado Ruby

sudo su

\curl -sSL https://get.rvm.io | bash -s stable --rails

La barra invertida antes del comando asegura que estamos usando el comando curl y no un alias o versión alterada.

La opción -s indica que la utilidad debe funcionar en modo silencioso, la opción -S anula esto para permitir el aviso de errores sólo en caso de que algo falle. La opción -L le dice a curl que sí siga las redirecciones.

Entonces el script se canaliza hacia bash para su procesamiento. La opción -s indica que la entrada proviene de “standard in”, además se especifica que queremos que la última versión estable de RVM junto a la última versión estable de Rails, que también se trae el Ruby adecuado.

Para comenzar a utilizar RVM

Se necesita ejecutar en todas las cosolas abiertas:

source /usr/local/rvm/scripts/rvm

which rvm

rvm -v

rvm 1.25.25 (stable)...[https://rvm.io/]

Para comenzar a utilizar Rails

rails new PROJECT_DIR

Para más información, por favor consulte:

Instalar Sass

sudo gem install sass

sudo gem update sass

which sass

sass -v
Sass 3.3.7 (Maptastic Maple)

Para más información, por favor consulte:

Linux networking – Solución simple de problemas

Es muy probable que la mayoría de los problemas relacionados con la red aparecen de las siguientes dos formas:

Lentitud

  • “NIC Duplex” y las incompatibilidades de velocidad.
  • Congestión de la red.
  • Pobre enrutamiento.
  • Error en el cableado.
  • Interferencia eléctrica.
  • Un servidor sobrecargado en el extremo remoto de la conexión.
  • DNS mal configurados.

Todas las fuentes de lentitud pueden llegar a ser tan severas que se termina perdiendo la conectividad.

Falta de conectividad

  • Fallos de alimentación de poder.
  • El servidor remoto está apgando.
  • Un servicio en el servidor remoto se encuentra abajo.

Pruebas de cableado y estado del enlace

Un servidor no puede comunicarse con otro dispositivo de la red a menos que la luz “link” de la tarjeta de red (NIC) se encuentre encendida. Esto indica que la conexión entre el servidor y el switch/router está funcionando de manera correcta.

En la mayoría de los casos, la falta de un enlace es debido al uso equivocado del tipo de cable. Por ejemplo, hay dos tipos de cables Ethernet, uno es “crossover” y el otro es “straight-through”. Otras fuentes de fallo de enlace pueden ser:

  • Los cables no funcionan.
  • El switch o router al que está conectado el servidor está apagado.
  • Los cables no están bien conectados.

Si se cuenta con una red extensa, la inversión en un probador de cable es esencial para realizar pruebas básicas de conectividad. Los modelos más sofisticados en el mercado pueden indicar la ubicación aproximada donde ocurre la rotura del cable, también cuando un cable Ethernet es demasiado largo para ser utilizado.

Probando la NIC

En la solución de problemas, es una buena práctica dar seguimiento al estado de una tarjeta NIC desde la línea de comandos.

Viendo sólo las interfaces activas

ifconfig
netstat -ie
ifconfig | egrep 'Link encap|HWaddr|inet addr|RX|TX|errors|collisions'

Todas las interfaces, aunque no estén activas

ifconfig -a

Consideraciones sobre DHCP

Los clientes DHCP de manera automática proporcionan sus tarjetas de red (NICs) y direcciones IP que comienzan con 169.254.xx hasta que puedan entrar en contacto con el servidor DHCP. Cuando se logra el contacto se reconfiguran las direcciones IP a los valores proporcionados por el servidor DHCP. Por lo tanto, una interfaz con una dirección 169.254.xx significa que hay un fallo en la comunicación con el servidor DHCP.

Estado del enlace (link status)

Conocer información sobre las velocidades de autonegociación compatibles de la tarjeta de red, es útil para resolver problemas de velocidad y dúplex.

mii-tool

mii-tool -v | egrep -i 'eth|link ok'
eth0: negotiated 100baseTx-FD flow-control, link ok
basic status: autonegotiation complete, link ok

eth1: negotiated 100baseTx-FD, link ok
basic status: autonegotiation complete, link ok

apt-get install ethtool

El comando ethtool proporciona mucha más información que el comando mii-tool, además pronto el comando mii-tool será obsoleto en Linux.

ethtool
ethtool eth0 | grep detected
ethtool eth0 | grep Speed

Errores en la tarjeta de red (NIC) 0.5%

Los errores son un síntoma común de una conectividad lenta debido a:

  • Una mala configuración.
  • Un uso excesivo del ancho de banda.

Las tasas de error superiores a 0.5% pueden causar una lentitud bastante notable.

ethtool -S eth0

Con la opción -S de ethtool se puede consultar un dispositivo de red específico con el objetivo de obtener estadísticas sobre:

  • La tarjeta de red NIc
  • El controlador.

netstat

El comando netstat es bastante útil en los sistemas que no cuentan con los comandos mii-tool y ethtool.

Muestra información relacionada con todas las interfaces de red. Datos de las transacciones de paquetes de red, incluyendo tanto la transferencia de paquetes como la recepción de paquetes con un tamaño de MTU.

netstat -i
  • RX-OK: Correct packets received on this interface.
  • RX-ERR: Incorrect packets received on this interface
  • RX-DRP: Packets that were dropped at this interface.
  • RX-OVR: Packets that this interface was unable to receive.

Definiciones similares para las columnas TX que describen los paquetes transmitidos.

Tabla de enrutamiento IP del núcleo (kernel)

netstat -r
route -e
  • A Receive all multicast at this interface.
  • B OK broadcast.
  • D Debugging ON.
  • M Promiscuous Mode.
  • O No ARP at this interface.
  • P P2P connection at this interface.
  • R Interface is running.
  • U Interface is up.
  • G Not a direct entry.

Nombre de servicio con PID

netstat -tp

Monitoreo constante

netstat -ic

Posibles causas de errores de Ethernet

  • Colisiones: Cuando la tarjeta NIC se detecta así misma y otro servidor en la LAN trata de transmitir datos al mismo tiempo. Las colisiones se puede esperar como una parte normal de la operación de Ethernet y están típicamente por debajo de 0,1% de todas las tramas enviadas (frames sent). En general, las altas tasas de error son probablemente causadas ​​por tarjetas de red NIC defectuosas o cables mal terminados.
  • Colisiones individuales: La trama Ethernet atravesada después de sólo una colisión.
  • Colisiones múltiples: La NIC tuvo que intentar varias veces antes de enviar con éxito la trama debido a las colisiones.
  • CRC: Cuando las tramas son eviadas pero se corrompen en el tránsito. La presencia de errores CRC, pero sin muchas colisiones por lo general es una indicación de que existe ruido eléctrico. Hay que verificar el tipo correcto de cable, que el cableado no se encuentre dañado y que los conectores estén bien fijados.
  • Trama (Freme errors): Un CRC incorrecto y un número no entero de bytes se reciben. Esto suele ser el resultado de colisiones o porque un dispositivo Ethernet se encuentra defectuoso.
  • FIFO y saturación: El número de veces que la NIC no fue capaz de entregar datos a sus buffers de memoria debido la tasa de datos de las capacidades del hardware. Esto suele ser un signo de exceso de tráfico.
  • Longitud: La longitud de la trama recibida fue menor o superior al estándar Ethernet. En general, se debe a una configuración dúplex incompatible.
  • Carrier: Debido a que la tarjeta NIC pierde su conexión de enlace (link connection) con el hub o switch. Verifique que el cableado, las interfaces NIC y los equipos de red no encuentren defectuosos.

¿Cómo se ven las direcciones MAC?

Hay momentos en que se puede perder conectividad con otro servidor que está directamente conectado a nuestra red local. Echar un vistazo a la tabla ARP desde el servidor con problemas puede ayudar a determinar si la tarjeta de red NIC del servidor remoto está respondiendo bien a cualquier tipo de tráfico desde mi equipo Linux. La falta de comunicación a este nivel puede significar:

  • Cualquier servidor puede estar desconectado de la red.
  • Es posible que haya cableado de la red dañado.
  • Una tarjeta de red NIC podría estar deshabilitada o el servidor remoto se encuentra abajo.
  • El servidor remoto puede estar corriendo un firewall tal como iptables o como el firewall propio de Windows o Mac. Típicamente, en este caso, se puede ver la dirección MAC y que el servidor está corriendo el software adecuado, pero la comunicación deseada no parece estar ocurriendo para el cliente en la misma red.

A continuación, una descripción de los comandos que se pueden usar para determinar los valores ARP:

El comando ifconfig -a muestra tanto la dirección de MAC de la NIC como las direcciones IP asociadas al servidor en el que nos encontramos. Por lo tanto puede ser posible que una sola interfaz pueda tener dos direcciones atadas al mismo tiempo.

El comando arp -a muestra las direcciones MAC en la tabla ARP del servidor y todos los demás servidores de la red conectada directamente. En general, se puede ver que se tiene algún tipo de conexión con algún router en alguna dirección.

arp -e

Nota: En ambos lados se recomienda verificar que las direcciones IP que aparecen en la tabla ARP coinciden con los de los servidores esperados y aceptables en la red. Si no coinciden, el servidor puede estar conectado en el interruptor del switch o router equivocado.

Si servidor problemático está conectado a la red local o no, es una buena práctica forzar una respuesta de él.

Ping

Uno de los métodos más comunes utilizados para probar la conectividad a través de múltiples redes es el comando ping.

ping envía paquetes “ICMP echo” que solicitan una respuesta “ICMP echo-reply” correspondiente del dispositivo en la dirección de destino. Como la mayoría de los servidores responden a consultas de ping, este comando se convierte en una herramienta muy útil. Una falta de respuesta de ping podría ser debido a:

  • Un servidor con esa dirección IP no existe.
  • El servidor ha sido configurado para no responder a consultas de ping.
  • Un firewall o router a lo largo de la ruta de red está bloqueando el tráfico ICMP.
  • Hay un enrutamiento incorrecto. Compruebe las rutas y las máscaras de subred en ambos lados, los servidores locales y remotos, también en los routers en el medio. Un síntoma clásico de rutas incorrectas en un servidor es la capacidad de sólo hacer ping a los servidores de la red local y no a ninguna otra parte. Podemos usar traceroute para verificar que se está tomando el camino correcto.
  • Cualquiera de los dos, el dispositivo origen o destino tiene una dirección IP o una máscara de subred incorrecta.

Notas:

  • El comando ping Linux envia pings continuos, uno cada segundo, hasta que se detiene con Ctrl-C.
  • Hay una variedad de códigos de respuesta ICMP que pueden ayudar en la solución de problemas.

Si se obtiene un mensaje “Destination Host Unreachable“. Es probable que el mensaje es causado por el router o servidor sabiendo que la dirección IP de destino es parte de una red válida, pero no recibe ninguna respuesta por parte del servidor de destino. Hay un número de razones para esto:

Si se está tratando de hacer ping a un host en una red directamente conectada:

  • El cliente o el servidor puede estar abajo, o desconectado de la red.
  • La NIC no tiene la configuración dúplex adecuada, esto se puede verificar esto con el comando mii-tool.
  • Es posible que se cuente con un tipo incorrecto de cable de conexión desde nuestra máquina Linux hacia la red. Hay dos tipos básicos, “straight through” y “crossover”.
  • En el caso de una red inalámbrica, puede ser que los SSID o las claves de cifrado pueden estar incorrectas.

Si se está tratando de hacer ping a un host de red remoto:

  • El dispositivo de red no tiene una ruta en su tabla de enrutamiento para la red de destino y envía una respuesta ICMP tipo 3 que desencadena el mensaje. El mensaje resultante podría ser “Destination Host Unreachable” o “Destination Network Unreachable”.

Probando la conectividad de red con telnet

Una manera fácil de saber si un servidor remoto está escuchando en un puerto TCP específico es utilizar el comando telnet. De forma predeterminada, telnet intentará conectarse en el puerto TCP 23, pero se pueden especificar otros puertos TCP después de la dirección IP de destino. Por ejemplo, HTTP utiliza el puerto TCP 80 y HTTPS utiliza el puerto 443.

Al usar telnet para la solución de problemas, hay algunas pautas útiles que permiten aislar el origen del problema:

  • Pruebe la conectividad desde el equipo remoto.
  • Verificar la conectividad en el propio servidor. Trate de hacer la conexión a la dirección “loopback”, así como la dirección IP del NIC. Si el servidor se encuentra usando un firewall tal como iptables, se verifica que “loopback” permita toda conectividad, aunque algunas veces la conectividad a ciertos puertos TCP en la interfaz de red NIC algunas vences pueden estar bloqueados.
  • Pruebe la conectividad desde otro equipo de la misma red que el servidor destino. Esto ayuda a eliminar la influencia de “firewalls” que protegen toda la red desde fuera.

Encontrando solución de problemas con telnet

Recuerde iptables. Es probable que muchos servidores de Linux tienen el firewall iptables instalado por defecto. Esto muy a menudo es la causa de muchos problemas de conectividad, por lo que las reglas del “firewall” deben actualizarse de la manera adecuada. En algunos casos en que la red ya está protegida por un “firewall”, iptables pueden ser apagado de forma segura.

En Linux una conexión telnet con éxito siempre presenta un saludo de conexión.

Mensajes de rechazo de conexión

  • Se puede recibir un mensaje de rechazo de conexión por una de las siguientes razones:
  • La aplicación que estamos tratando de probar no se ha iniciado en el servidor remoto.
  • Existe un “firewall” bloqueando y rechazando el intento de conexión.
telnet 192.168.0.20 22
Trying 192.168.0.20...

telnet: Unable to connect to remote host: Connection timed out

Solución de problemas en Windows

A veces hay que solucionar servidores Linux desde un equipo con Windows. Los comandos de telnet son los mismos, pero los resultados son diferentes. Si la pantalla queda en blanco, entonces la conexión es correcta. Si hay conectividad, la pantalla del símbolo del sistema se mostrará en blanco. Con la combinación de teclas Ctrl-C le se puede salir del intento de telnet.

Mensajes “Connect Failed”

Los mensajes “Connect Failed” en Windows son el equivalente de “Connection refused” en Linux.

Tiempo de espera se cuelga usando telnet

Como se menciona arriba, si no hay conectividad, la sesión aparecerá como colgada o agotada. De manera general, esto es causado porque el servidor de destino está apagado o por que un “firewall” se encuentra bloqueando la conexión.

Probando sitios Web con las utilidades curl y wget

Obtener una buena idea de la fuente de rendimiento de un servidor web utilizando sólo un navegador Web es insuficiente. Muchos códigos de error HTTP útiles a menudo no se muestran en los navegadores, lo que hace difícil la solución de problemas.

Una mejor combinación de herramientas es utilizar telnet para probar el tiempo de respuesta del puerto TCP 80 de un sitio en conjunto con los datos obtenidos por utilidades como curl y wget.

Tiempos rápidos de respuesta TCP, con tiempos lentos de curl y wget apunta a que no es un problema de red, pero sí puede ser un problema de lentitud en la configuración del servidor Web, los servidores de aplicación o en la base de datos que se utilizan para generar la página Web.

Usando curl

La utilidad curl actúa como un navegador Web basado en texto en el que se puede elegir si se desea ver sólo el encabezado o sólo cuerpo completo del código HTML de una página Web que se muestra en la pantalla.

Un buen comienzo es usar el comando curl -I para ver sólo el encabezado de la página Web y el código de estado HTTP. Si no utiliza la bandera -I entonces se desplegará todo el código HTML de la página Web que se muestra en la pantalla. Cualquier método puede proporcionar una buena idea del rendimiento de su servidor.

curl -I www.josoroma.com

Usando wget

Se puede usar wget para descargar un directorio local y de forma recursiva todas las páginas de un sitio Web, incluyendo la estructura de directorios del sitio Web.

Sin usar recursividad, y activando la función de “timestamp” (la opción -N), permite no sólo ver el contenido HTML de la página del index del sitio Web en el directorio local, también se puede ver la velocidad de descarga, el tamaño del archivo y el tiempo preciso de inicio y finalizacón de la descarga. Esto puede ser muy útil para obtener “snapshots” de rendimiento del servidor.

El comando netstat

Tal como curl y wget, netstat puede ser muy útil para ayudar a determinar el origen de los problemas. Usar netstat, con la opción -an permite listar todos los puertos TCP en los que el servidor Linux está escuchando, incluyendo todas las conexiones de red activas desde y hacia el servidor. Esto puede ser muy útil para determinar si la lentitud se debe a los altos volúmenes de tráfico:

netstat -an

La mayoría de las conexiones TCP crean conexiones permanentes, HTTP es diferente porque las conexiones se cierran por sí solas después de un tiempo de espera predeterminado de inactividad o de “time_wait” en el servidor Web. Por lo tanto, es una buena idea centrarse en este tipo de conexiones de corta duración también.

Se puede determinar el número de conexiones establecidas y el número de conexiones “time_wait” TCP en el servidor usando el comando netstat, seguidamente filtrado por los comandos grep y egrep y, con el número de coincidencias (matches) que sean contabilizados por el comando wc.

netstat -an | grep tcp | egrep -i 'established|time_wait' | wc -l

El famoso firewall iptables

Una fuente inesperada de problemas de conectividad en servidores nuevos, con frecuencia, puede ser por el firewall iptables. Algunas veces es posible tratar de detener iptables mientras se solucionan problemas.

La gestión de iptables es fácil de hacer, pero el procedimiento es suele ser diferente entre las diversas distribuciones de Linux. Algunas cosas que hay que tener en mente son las siguientes:

  • En primer lugar, las diferentes distribuciones de Linux utilizan diferentes sistemas de gestión de demonios. Cada sistema tiene su propio conjunto de comandos para hacer operaciones similares. Los sistemas de gestión de demonio más comunes son SysV y Systemd.
  • En segundo lugar, el nombre demonio necesita ser conocido. En el caso de iptables el nombre del demonio es iptables.

Con esta información, se puede saber cómo:

  • Comenzar demonios automáticamente en el arranque (booting).
  • Detener, iniciar y reiniciar demonios al momento de resolver problemas.
  • Cuando un cambio en un archivo de configuración necesita y debe aplicarse.

Probando la conectividad con traceroute

Otra herramienta para solucionar problemas de red es el comando traceroute. Ofrece una lista con todos los nodos (hops) de enrutador entre nuestro servidor origien y el servidor de destino. Esto ayuda a verificar que el enrutamiento a través de las redes en el medio es correcto.

El comando traceroute funciona enviando un paquete UDP hacia el destino con un TTL de 0. El primer router en la ruta reconoce que el TTL de hecho ya ha se ha excedido en tiempo, por esta razón descarta el paquete, pero también envía un mensaje ICMP de tiempo excedido de regreso a la fuente. El programa traceroute registra la dirección IP del router que envía el mensaje y sabe que ese es el primer nodo en la ruta hacia el destino final. Seguidamente el programa traceroute intenta de nuevo, esta vez con un TTL de 1. El primer nodo de la ruta no ve nada extraño con el paquete, entonces disminuye el TTL a 0 como se esperaba, y reenvía el paquete al segundo nodo en la ruta. Router 2, ve el TTL de 0, descarta el paquete y responde con un mensaje ICMP de tiempo excedido. Por lo tanto, ahora traceroute conoce bien la dirección IP del segundo router. Esto continúa de nodo en nodo hasta que se alcanza el destino final.

Usando traceroute sólo se reciben respuestas de dispositivos que funcionan. Si un dispositivo responde quiere decir que es menos probable que sea la fuente de los problemas de conectividad.

50 ms es aceptable

Observe que todos los tiempos en los diversos nodos de la ruta sean inferiores a 50 milisegundos (ms), lo cual es bastante aceptable.

traceroute google.com

Respuesta dentro de 5 segundos

Si no hay respuesta dentro de un intervalo de 5 segundos de tiempo de espera, la prueba se marca con asterisco (*).

Algunos dispositivos evitan paquetes traceroute dirigidos a sus interfaces, pero sí permiten paquetes ICMP. Usar traceroute con la opción -I fuerza traceroute a utilizar paquetes ICMP. En ese caso, el esado de mensaje *** desaparece:

traceroute -I google.com

Falsa alarma de lentitud

Muchas veces traceroute da la impresión de que un sitio Web o una Ip puede ser lenta porque hay alguna congestión en el camino en el sector, entre por ejemplo el nodo 6 y 7 de la ruta, donde algun tiempo de respuesta puede ser de más de 200ms.

Esto indica que sólo los dispositivos en los nodos 6 y 7 de la ruta están lentos para responder con mensajes ICMP de TTL excedido, pero no es una indicación de: congestión, latencia o pérdida de paquetes. Si alguna de estas condiciones existiera entonces todos los puntos anteriores en el vínculo problemático mostrarían alta latencia.

Muchos dispositivos de enrutamiento en la Internet dan muy poca prioridad al tráfico relacionado con traceroute para favorecer el tráfico de generación de ingresos (revenue generating traffic).
Muere en el router justo antes del servidor

En este caso, el último dispositivo en responder a traceroute es el router que actúa como puerta de enlace predeterminada del servidor. Entonces el problema no es con el router, pero sí con el servidor. Recuerde, usted sólo recibirá respuestas traceroute desde dispositivos que sí funcionan. Las posibles causas de este problema podrían ser las siguientes:

  • Un servidor tiene una puerta de enlace predeterminada mala.
  • El servidor se encuentra ejecutando algún tipo de “firewall” que bloquea traceroute.
  • El servidor está apagado, desconectado de la red o tiene un NIC mal configurado.

Siempre probar un traceroute bidireccional

Es mejor obtener un traceroute desde la IP origen hasta la IP destino y también desde la IP de destino hasta la IP origen. Esto se debe a que la ruta de retorno de paquetes desde el destino a veces no es la misma ruta tomada para llegar allí.

Un traceroute alto equivale al tiempo de ida y vuelta (round trip time), tanto para la consulta traceroute inicial para cada nodo de la ruta y la respuesta de cada nodo de la ruta.

Resolución de problemas con ping y traceroute

En este ejemplo, un ping a una IP da un mensaje de tiempo de espera TTL (TTL timeout message). Los tiempo de espera ocurren sólo si hay un bucle de enrutamiento en el que el paquete rebota entre dos enrutadores en su camino hacia el destino. Cada rebote hace que el TTL disminuya su conteo en 1 hasta que el TTL alcanza 0, en este momento se obtiene el “TTL timeout message”.

Estos problemas reconfigurando (reseteando) ambos routers. El problema inicial fue provocado por un enlace inestable en la red que causaba cálculos de enrutamiento frecuentes. Dicha actividad constante dañó las tablas de enrutamiento en uno de los routers.

traceroute para Sitios Web

Muchos ISP ofrecen la posibilidad de hacer un traceroute desde servidores llamados “Internet looking glass”. Permiten correr traceroute desde una variedad de lugares que pueden ayudar a identificar si el problema es con el ISP del servidor Web o con el ISP utilizado que usamos acceder a la Internet desde nuestra casa o trabajo. Una forma cómoda de hacerlo es utilizando el sitio www.traceroute.org que proporciona una lista de espejos por país.

Razones por las que puede fallar traceroute

Un traceroute puede fallar en alcanzar su destino por una serie de razones, incluyendo las siguientes:

  • Los paquetes traceroute están siendo bloqueando por un router en el camino. El router inmediatamente después del último visible suele ser el culpable. Por lo tanto es bueno revisar la tabla de enrutamiento y/o cualquier otro estado de este siguiente dispositivo en la ruta.
  • El servidor destino no existe en la red. Podría estar desconectado o apagado. (Se pueden producir los mensajes !H o N!).
  • La red en la que se espera que el host destino puede residir no existe en la tabla de enrutamiento de uno de los routers en el camino. (Se pueden producir los errores !H o !N).
  • Puede haber un error tipográfico en la dirección IP del servidor de destino.
  • Puede haber un bucle de enrutamiento en que los paquetes rebotan entre dos routers y nunca llegan al destino deseado.
  • Los paquetes no tienen una ruta apropiada de retorno a nuestro servidor. El último nodo visible es el último nodo en el que los paquetes vuelven correctamente. El router inmediatamente después del último nodo visible es en el que el enrutamiento cambia. Por lo general es bueno hacer lo siguiente:
    • Iniciar sesión en el último nodo enrutador visible.
    • Mira la tabla de enrutamiento para determinar cuál es el siguiente nodo destino previsto.
    • Iniciar sesión en el siguiente router.
    • Hacer un traceroute desde este router hacia servidor destino previsto.
    • Si esto funciona: El enrutamiento hacia servidor de destino está bien. Hacer un traceroute de nuevo hacia nuestro servidor de origen. Entonces probablemente el traceroute fallará en el router malo que se encuentra en el camino de regreso.
    • Si esto no funciona: Hay que porbar la tabla de enrutamiento y/o cualquier estado de todos los nodos entre este y y el destino previsto.

Nota: Si no hay algo que bloquee el tráfico traceroute, entonces el último enrutador visible de un traceroute es el último router bueno en el camino, o el último router que tiene un retorno válido hacia el servidor emitiendo el traceroute.

Por favor consulte: Simple Network Troubleshooting