Si las Mac tienen algo sorprendente, además de su diseño y su visualmente atractivo sistema operativo es la casi inmediata capacidad de volver a estar online luego de regresar de la suspensión. Esto es sumamente visible en equipos con discos SSD, como las Macbook Air (las locas se despiertan al toque e inmediatamente están conectadas).
Afortunadamente David Simmons quién sabe mucho de redes notó lo mismo y lo comparó con los 15 segundos promedio que su eeePC tardaba para “tomar red” y decidió utilizar un scanner de paquetes para ver las diferencias entre las implementaciones de DHCP entre OSX y los demás sistemas operativos.
(Instantánea, así es la conexión de red en OSX)
Si tenés un rato libre y te gusta leer este tipo de geekeadas te recomiendo el resumen que traduje del excelente artículo. En caso de que te haya gustado el resumen, no dudes en leer el original, vale la pena.
La clave para entender la magia son las tres primeras peticiones ARP unicast. Parece que Mac OS recuerde cierta información no sólo sobre la última red conectada, también las redes conectadas en mucho tiempos. En particular, se debe persistir por lo menos la tupla siguiente para cada una de estas redes:
- La dirección Ethernet del servidor de DHCP
- La dirección IP del servidor DHCP
- Su propia dirección IP, que le han sido asignadas por el servidor DHCP
Durante la inicialización de la red, una Mac transmite cuidadosamente peticiones unicast ARP con esta información almacenada.Para cada red en su memoria, se trata de enviar una solicitud a la específica dirección Ethernet del servidor DHCP para esa red, en la que se pregunta sobre la dirección IP del servidor, y pide que la respuesta del servidor a la dirección IP que la Mac utilizaba previamente. A menos que máquinas de la red han cambiado radicalmente una de estas peticiones ARP se traducirá en una respuesta de la solicitud correspondiente a la red actual, si la red actual pasa a ser una de las redes recordado.
Esta técnica de reconocimiento de red permite que una Mac pueda descubrir rápidamente si está conectado a una red conocida. Si la red se reconoce (y, presumiblemente, si la Mac sabe que el contrato de arrendamiento DHCP está todavía activo), de inmediato y con presunción configura su interfaz con la dirección IP que conoce de antemano. (Bueno, lleva a cabo un auto-ARP pero no parece que esperar más de 13ms de respuesta.) El proceso de establecimiento de comunicación DHCP se inicia en el fondo, enviando una solicitud DHCP para asumir su dirección IP pero la de interfaz de red está disponible para su uso durante el proceso de establecimiento de comunicación. Si la red no fue reconocida, supongo que la Mac comienza la fase de descubrimiento de DHCP, en lugar de enviar las peticiones a ciegas para una dirección IP antigua como lo hace la Galaxy tab, por ejemplo.
La inicialización de red rápida que tan bien funciona en las Mac puede ser asociada a más cosas que solo el sistema de reconocimiento de la red. A juzgar por el uso de ARP (que puede ser problemática para tratar en el espacio de usuario) y los intervalos de transmisión inusualmente regular (un retardo de 1.0ms fiable entre cada paquete enviado), supongo que el cliente DHCP de las Mac está implantado totalmente en el kernel del sistema. La Mac inicia el proceso de inicialización de la interfaz IP solamente 10 ms después del establecimiento del enlace, algo mucho más rápido que cualquier otro dispositivo que probé.
Dispositivos Android, tales como la Galaxy tab confian en el sistema dhclient en modo de usuario (parte del paquete dhcpcd) y el programa dhcpcd, que sin duda aporta una gran cantidad de gastos adicionales, tales como la carga del programa, el cambio de contexto, y tal vez incluso scripts en ejecución.
Ahora solo falta que alguien desarrolle un modulo y parchee un kernel con esto asi a aquellos que nos interesa mas la velocidad cuando levantamos la maquina que la seguridad de la conexion.
Che, muy rápido si, pero si metés dos MAC (o mas) en la misma red y justo da la puta casualidad que ambas tuvieron alguna vez la misma dirección de IP durante un par de segundos ambas van a tener el mismo número de IP o entendí mal?
Crearía un conflico de números de IP en la red supongo… ¿No? habría que tener varias MAC para hacer algunos experimentos…
¡Saludos!
Que raro las Mac, ¡presuntuosas hasta para asumir una IP que no les dieron! xD
Muy interesante y bastante lógico y práctico. Son esos pequeños detalles que hacen que la gente ame ese SO.
Saludos.
Logico que DCHP sea rapido, Mac es de la familia UNIX BSD que es la mas usada en servidores, en concreto en FreeBSD. Aunque Linux no se queda nada corto. En cambio windows… para que explicar. Perdidas del host, fallos de conexion, lentitud en la conexion.
Para que hablar.
En eso te equivocas Javier. En este caso puntual, no por que sea Unix Like tiene que ser mas rápido.
El kernel tiene poco y nada que ver con el cliente dhcp que se utilice, FreeBSD usa dhclient, al igual que muchas de las distros de Linux. El resto de las distribuciones Linux usa dhcpcd que es otra implementación mas de lo mismo, (bastante mas efectiva de hecho) pero en ambos casos estamos hablando de aplicaciones en espacio de usuario, nada que ver con el kernel.
Evidentemente Mac usa su propia implementación de cliente dhcp por que de otra forma no podría malformar las peticiones ARP y ser tan rápido para reconectar. (Ni dhcpcd ni dhclient disponen de esta característica).
¡Saludos!
Lo que pasa Juan es que es mas fácil hacerse el poronga Pro Unix en lugar de leer el artículo original, donde la comparación la hacen con un Samsung Galaxy tab cuyo OS está basado en… tarán tarán… ¡Linux!
Interesante el artículo. Si bien notaba que mi mac se conectaba muy rápido después de salir del reposo nunca me había imaginado todo este mecanismo para lograrlo. De las cosas que uno se entera jeje.
[…] ¿Por qué el DHCP en OSX es tán rápido? (Alt-tab). […]
También hay que pensar en la cantidad de plata que ha corrido para hacer este OS.