Le seul vrai avantage de l'IP dynamique est la compatibilité. Peu importe ta configureation, il suffit d'utiliser TCP/IP ainsi qu'un client DHCP pour obtenir une adresse IP valide, une (voire trois) IP de serveurs de noms de ton FAI (par rapport aux serveurs publics, car permet de partager les charges sur les requettes de noms et d'aller plus vite), et de pouvoir surfer "plug and play", et non plus "plug and pray".
Le problème de la méthode avancée par kalamit est que les logs des FAI ne sont visibles que sur réquisition d'un procureur de la république, ce qu'on ne peut pas obtenir parcequ'un adolescent s'amuse à flooder un forum voire un serveur via des requettes HTTP. Par contre, s'il commence à poster des propos xénophobes sur un forum de manière récurrente et abusive, y'a peut être moyen, mais il faut au minimum porter plainte ...
Néanmoins, même avec une IP dynamique, un traceroute ainsi que quelques bonnes requêtes au serveur whois te permettent d'obtenir la localisation géographique de l'utilisateur, avec un précision de l'odre de la ville (voire du quartier sur certaines grandes villes). Les hébergeurs intransigeants avec la tranquillité n'hésitent plus à bannir des plages IP provenant de certains FAI (completement !!), alors les autres n'hésiteront pas à bannir ce qui est relayé par tel routeur de tel FAI.
L'IP fixe est restée car elle est nécessaire à la mise en place de serveurs. Il existe des services de DNS dynamiques, néanmoins ceux-ci ont un énorme désavantage : Si on peut résoudre DNS -> IP, la résolution inverse (RDNS) est impossible, car l'Ip change tout le temps, et il faut 24h pour mettre à jour les serveurs de RDNS :(
Pourquoi le RDNS ? Pour monter un serveur mail. Lorsqu'un serveur reçoit un mail provenant de x@domaine.com, il résoud domaine.com et obtient une ip x.x.x.x et un masque, le tout définissant une plage d'IPs. Certains vérifient que le mail a bien été envoyé par cette plage d'IP, et la plupart vérifie qu'en resolvant x.x.x.x on obtienne bien domaine.com (ce qu'on appelle un "full qualified domain").
***
Le coup du refresh, ce n'est même pas une protection, c'est juste que lorsque tu te connectes à un site, le serveur te dédie un processus et en crée un nouveau, jusqu'à une certaine limite. Si tu fais trop de refresh, tu obtiens beaucoup de process (1 par refresh) et le serveur sature. Au dela de la limite, le serveur refuse de te répondre car il n'a plus de processus à te dédier et ne peut en créer d'autres.
Lorsque tu as peu de bande passante, il faut configurer la limite du nombre de processus assez bas, pour que même si tu as beaucoup de visiteurs, ils aient tous une bonne qualité de surf. Si tu as 150 process simultanés sur un 486, ton serveur va avoir VRAIMENT du mal. Si tu configures à 10 process max, les visiteurs se partageront en 10 tes ressources. Tu limites le nombre simultané de visiteurs (gênant si tu as beaucoup de trafic ... mais si tu as plus de 10 visiteurs simultanés pendant plus d'une heure par jour, il va falloir investir !!), néanmoins ces 10 visiteurs obtiennet une charge CPU et une bande passante correctes (1.6ko/s théoriques de BP pour une connection en 128kbps). Ainsi, même avec un serveur connecté via ADSL avec 128kbps en envoi, tu peux garantir 1ko/s à tes visiteurs :]
Ca permet aussi de diminuer les temps de réponse, car si tu as 149 requêtes à traiter avant de pouvoir répondre au visiteur, ca peut prendre jusqu'à 2 secondes sur un serveur qui se contente d'aficher des pages. Après, tu ajoutes la latence, le temps de transfert des paquest et la charge CPU etc ...
Bref, c'est plus compliqué que la guerre juvénile des ados en crise, contre laquelle on prendrait beaucoup plus de mesures si les connections superconducteurs étaient des standard ... ;]
Adresse ip fixe