les serveurs (削除) FTP (削除ここまで)HTTPS ne prennent pas en charge la mise en cache et l'accélération ;
Un truc cool avec HTTP c’est qu’un simple proxy (transparent? ) avec quelques règles pour les fichiers provenant d’archives.debian.org est hyper pratique (c’est probablement pourquoi les antivirus distribuent souvent leurs bases en HTTP, c’est très facile à mettre en cache).
Bon au boulot j’ai un miroir Debian complet donc j’ai pas besoin d’un proxy cache pour ça et je pourrai utiliser https pour synchroniser le miroir, mais j’utilise un proxy-cache pour d’autres services similaires (d’où ma supposition que si ces services restent en HTTP, c’est pour me le permettre).
J’imagine que certains gros opérateurs n’hésitent pas à mettre en cache ce genre de chose (mises à jour windows, mises à jour antivirus) pour réduire les coûts de peering.
Un bon exemple sont les miroirs que fournissent certains opérateurs/fournisseurs, comme le miroir mirrors.online.net pour les clients dédibox ou debian.mirrors.ovh.net pour les clients ovh, ainsi que tous les miroirs d’universités. Dans ce cas, utiliser https n’a pas beaucoup de sens (excepté dissimuler à un voisin quels paquets tu télécharges) car le protocole apt vérifie l’intégrité et la légitimité du paquet indépendamment du miroir obscure qui t’as fourni. Pour revenir à cet exemple de mirrors.online.net, en plus de fournir un miroir complet à leur client, je ne serai pas étonné qu’ils placent un gros proxy cache dans chacun de leur datacenters.
Bref, https pourquoi pas (ça dissimulera quel paquet tu télécharges, mais pas vraiment que tu télécharges un paquet), y a un besoin pour ça, mais il y a bien un univers qui va utiliser HTTP encore longtemps, c’est la distribution de paquet (distribution, antivirus...). Le problème du peer-to-peer c’est que tu ne contrôle pas vraiment le peering, alors que monter un miroir de ton côté d’un lien problématique est très facile.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: HTTP remplacent ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 9.
Un truc cool avec HTTP c’est qu’un simple proxy (transparent? ) avec quelques règles pour les fichiers provenant d’
archives.debian.orgest hyper pratique (c’est probablement pourquoi les antivirus distribuent souvent leurs bases en HTTP, c’est très facile à mettre en cache).Bon au boulot j’ai un miroir Debian complet donc j’ai pas besoin d’un proxy cache pour ça et je pourrai utiliser https pour synchroniser le miroir, mais j’utilise un proxy-cache pour d’autres services similaires (d’où ma supposition que si ces services restent en HTTP, c’est pour me le permettre).
J’imagine que certains gros opérateurs n’hésitent pas à mettre en cache ce genre de chose (mises à jour windows, mises à jour antivirus) pour réduire les coûts de peering.
Un bon exemple sont les miroirs que fournissent certains opérateurs/fournisseurs, comme le miroir
mirrors.online.netpour les clients dédibox oudebian.mirrors.ovh.netpour les clients ovh, ainsi que tous les miroirs d’universités. Dans ce cas, utiliser https n’a pas beaucoup de sens (excepté dissimuler à un voisin quels paquets tu télécharges) car le protocole apt vérifie l’intégrité et la légitimité du paquet indépendamment du miroir obscure qui t’as fourni. Pour revenir à cet exemple demirrors.online.net, en plus de fournir un miroir complet à leur client, je ne serai pas étonné qu’ils placent un gros proxy cache dans chacun de leur datacenters.Bref, https pourquoi pas (ça dissimulera quel paquet tu télécharges, mais pas vraiment que tu télécharges un paquet), y a un besoin pour ça, mais il y a bien un univers qui va utiliser HTTP encore longtemps, c’est la distribution de paquet (distribution, antivirus...). Le problème du peer-to-peer c’est que tu ne contrôle pas vraiment le peering, alors que monter un miroir de ton côté d’un lien problématique est très facile.
ce commentaire est sous licence cc by 4 et précédentes