L'utilisation directe de l'adresse IP de n'importe quelle interface sur l'hôte local - soit l'interface de bouclage (127.0.0.1) ou toute autre - est l'option offrant les meilleures performances. Les paquets seront en fait acheminés via l'interface de bouclage (quelle que soit l'adresse IP réellement utilisée) à - pratiquement - la vitesse du processeur.
Il y a cependant trois raisons de préférer 127.0.0.1 aux IP des autres interfaces :
-
L'interface de bouclage est cruciale pour le fonctionnement du système et, en tant que telle, elle est initialisée très tôt dans le processus de démarrage et presque toujours disponible.
-
Il n'est pas affecté par des facteurs externes :bien que le retrait du câble eth0 n'interrompe pas en soi l'accès de localhost à lui-même via l'IP d'eth0, il le fera gâcher les choses si vous avez l'un des nombreux systèmes de "configuration automatique" qui fermeront volontiers l'interface en cas de perte de lien.
-
Si vous avez configuré un pare-feu, il est tout à fait possible que la chaîne de règles soit plus longue (et donc légèrement moins performante) lorsque les adresses IP des interfaces publiques sont impliquées.
Si vous utilisez des noms d'hôte, le nom d'hôte localhost sera normalement résolu par une recherche /etc/hosts qui est très rapide, bien que l'utilisation directe de l'adresse IP supprime complètement cette recherche. Selon votre configuration, il peut également être mis en cache dans la mémoire afin qu'il soit presque aveuglément rapide plus tard.
Si vous utilisez un nom d'hôte public, cela peut impliquer une requête DNS qui implique une utilisation supplémentaire du processeur et une latence du réseau. L'utilisation d'un serveur de noms de cache sur l'hôte local résoudra principalement ce problème. Gardez à l'esprit, cependant, qu'il peut toujours y avoir un problème si votre service DNS devient instable.
Le seul avantage d'utiliser un nom d'hôte public serait s'il s'agissait de quelque chose comme db.example.com. qui vous permet de déplacer votre base de données vers un serveur séparé sans avoir à modifier la configuration des clients.
Puisque vous utilisez JDBC, je suppose que vous réutilisez une seule connexion pour toutes vos requêtes, auquel cas la surcharge de résolution du nom d'hôte elle-même devrait être négligeable dans tous les cas, sauf si vous devez gérer un serveur DNS en panne. Cependant, il peut être encore utile de choisir l'adresse 127.0.0.1 pour sa configuration de pare-feu potentiellement plus efficace.
