barmic a écrit 927 commentaires

Ton message présente un logiciel de chat pas en quoi il différe de celui présenté dans le journal ou en quoi il est mieux ou moins bien. Bref il n'y a pas vraiment de lien entre ton commentaire et ce journal. Énumérer les solutions de chat n'est pas plus intéressant que ça.

le frontal en reverse-proxy t'oblige à le faire

Haproxy ne gère aucun état partagé, à aucun moment. Même entre ces processus il ne fusionne pas ses statistiques. Je ne vois pas du tout de quoi tu parle.

Maîtrisable dans quel sens ?

C'est toi qui choisi quels ports sont utilisés (c'est un mapping que tu fais). Tu n'es pas obligé d'autoriser des plages de port parce que peut être que quelqu'un va les utiliser un jour

Si tu as de l'authentification fait par ton frontal, il faut que l'état soit répliqué sur tous tes fronts de la bonne manière. C'est complexe. Si il y a un peu de gestion de session sur les fronts, pareil.

Si tu es distribué c'est complexe quelque soit ta version d'IP, c'est le fait d'avoir 2 logiciels qui tournent et qui doivent être synchronisés qui pose problème pas le routage, pas le reverse proxy.

Hmm, je ne vois pas d'où tu sors ça

D'un linuxmag d'il y a 2 ans je pense.

Bah tu dis ça, mais une fois que tu as monté ton ensemble de Docker dans tous les sens avec tes quarante applis containerisées qui font plein de trucs dynamique, cet ensemble va bien « lancer des connexions dans tous les sens ». Une application complexe aura ce comportement au bout d'un moment. Vouloir modéliser ça et le mettre dans le marbre d'une firewall (applicatif ou non) c'est scléroser ton modèle applicatif, qui va par la suite devoir truander tes flux pour se faufiler là où ça passe. C'est ça qui est vendu d'avance.

Docker va cacher ça dans un réseau spécifique. Ce qui entre et sors de ce réseau est tout à fais maîtrisable.

Et puis cette hypocrisie du « monitoring » quand aujourd'hui la moindre page web envoie des infos à droite à gauche dans tous les sens de manière dynamique… (OK, je change de contexte)

C'est pas mon taf, je ne connais pas du tout.

Ça dépend de ce que tu cherche à faire. traefik sait réagir à des erreurs 5xx (par exemple) retournées par ton serveur. Couche réseau je vois pas trop ce que tu va regarder comme erreur, couche transport tu peut regarder les connexions reset par le serveur. Ça n'est pas que de l'anti-DDOS, ton serveur destinataire peut juste se faire slashdoter par exemple (donc il ne s'agit pas de remplacer les solutions du genre limitation du trafic coté firewall qui vont vérifier qu'un client ne va pas générer trop de trafic par exemple.

Je n'ai pas dit qu'il était dépassé, juste que cet un argument d'autorité. Ni plus ni moins.

Par contre je n'ai pas compris ton exemple de ne pas router « s'il y a trop d'erreurs avant ».

Des reverse proxy qui font circuit breaker. C'est le cas de traefik notamment

tu es « on-premise », ou dans le « Cloud », par exemple, mais jamais tu ne mélanges tout ça ; hérésie !

Avant de regarder le routage, le coût réseau d'entrée/sortie des clouds tend ce genre de déploiements complètement infaisable. Tes latences explosent (tu n'est plus sur un réseau 10G), tu peux avoir une bande passante limité ou facturée, etc Tout ça fait que c'est de base une mauvaise idée sans même s'intéresser au routage.

Oui, j'ai peut-être du mal à « faire rêver » avec mes trucs.

Le problème n'est pas de faire rêver, mais que ce n'est pas parce que l'IETF a imaginé un truc il y a 30 ans que c'est toujours d'actualité ou qu'il ne faut pas le remettre en question aujourd'hui.

le SPOF que ça constitue

On peut très bien déclarer plusieurs reverse proxy dans ton enregistrement dns. Par contre si je ne me trompe pas c'est bien plus compliqué avec IPv6. Là où les ip sont présenté en round robin avec IPv4, avec IPv6 l'ordre est défini et fixé. Donc les clients doivent consciemment implémenter le balancing.

ou si tu utilises des front redondés la complexité du partage d'état fait (problématique non présente en IP)

Hum ? Je ne vois pas de quoi tu parle ?

C'est les protocoles qui font n'importe quoi pour le coup. Lancer des connexions dans tous les sens sans pouvoir les tracker autrement c'est daubé de base. Rien que pour monitorer ce qu'il se passe sur ton réseau c'est affreux.

genre FTP passif ; oui, c'est considéré comme « has-been », mais il existerait tellement d'avantages à autoriser ce genre de chose pour des modèles d'interactions nouveaux

C'est surtout que ceux qui ont lu le code d'ip_conntrack_* qui font encore cauchemars…

Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes…

On peut avoir une discussion sans partir dans ce genre d'idées reçues niaises, biaisées, malhonnêtes et totalement manichéenne ?

Les informations au niveau de ton service et au niveau de ton répartiteur de charge sont différentes et servent des besoins différents.

WAF,

Quelle différence avec un firewall standard, quand tu utilise mon architecture ?

Euh ? Un WAF analyse le contenu du trafic HTTP, hein ? Donc tu fais une analyse couche applicative par conception. Si tu veux la faire via ton firewall c'est possible, mais c'est bizarre (ça veut dire que ton firewall (ou ce qui se plug à ton fw) va décoder la requête http, puis que tu va dans la suite continuer de vouloir être agnostique à la couche 7. Ça n'est pas particulièrement beau.

TLS offloading,

Je ne suis pas sûr de ce que tu proposes

Terminaison TLS si tu préfère.

mais la manière historique de faire c'est IPsec

Non, la première RFC d'IPsec date de 1998 alors que SSL1.0 date de 1994, mais bon comment tu adresse un serveur IPsec+SMTP ?

sinon, dans mon exemple tu pourrais rajouter du TLS avec un wrapper adapté (OK, c'est hypothétique).

Oui tu utilise un reverse proxy donc.

logging,

Mmmhhh, je le fais aussi. Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes…

Je n'ai pas était très précis. Mais tu peux vouloir avoir des log qui inclus l'information métier et donc doit décoder la 7ème couche. Tu peux imaginer vouloir réagir à ces informations comme ne pas router le trafic s'il y a trop d'erreurs avant.

Note que dans ton cas, tu as externalisé toutes ces difficultés en prenant comme hypothèse que tu avais déjà une machine qui a un enregistrement DNS et un routage qui fonctionne. Ces choses ne sont pas arrivées magiquement, et un administrateur a bien dû les configurer.

Prendre comme hypothèse que ça a était fais une fois est un peu plus simple que de considérer que ce sera fais pour chaque nouveaux services.

Le principe du « bout-en-bout », c'est de ne pas rajouter une couche au-dessus de tout ça (HTTP et reverse-proxy) pour faire quelque-chose qui était à la base prévu dans l'architecture d'Internet : le réseau a été conçu pour être un « réseau de processus », pas forcément de « machines » sur lesquelles on va rajouter une couche. Donc on pousse le nommage et le routage jusqu'aux extrémités.

Je sais et je le comprends bien. Ça n'empêche pas de pouvoir le critiquer. Mais l'argument disant que les gens l'ont pensé comme ça il y a 30 ans donc on doit continuer à le faire n'est pas très convainquant.

mais contrairement à ce qui est dit dans le journal choisir de faire un peu plus tardivement le routage ne me paraît pas forcément choquant.

Je n'ai pas dit choquant, je crois, jusque que c'est plus complexe et fragile. Si tu y trouves des avantages, tant mieux, mais j'ai souvent vu ses promoteurs sous-estimer ses désavantages.

Et des idéalistes voir des désavantages au microscopes. En fait quand je vois la facilité de mise en place et comme de très grosses infrastructures s'en servent, je me dis que pour mes besoins ça doit le faire sans trop se poser de question.

Je vois 3 points qui peuvent pose des problèmes sous fortes charges avec les reverses proxy :

1. le loadbalancing est fait plutôt tardivement ce qui réduit théoriquement les performance, mais il faut relativiser ce coût face au reste du boulot de loadbalancing
2. le nombre de connexion une connexion TCP est identifiée par le quadruplé src_host:src_port → dest_host:dest_port si tu fixe la partie destination un client ne peux ouvrir que 30k connexions vers ton serveur (les distributions que j'ai regardé son configuré pour n'utiliser que les ports de 32768 à 60999 (voir /proc/sys/net/ipv4/ip_local_port_range). C'est utile pour certain bench
3. lors de l'ajout/suppression de service, il faut pouvoir reconfigurer à chaud ton reverse proxy. Nous avec haproxy, on utilise nl-qdisc-add et ça se passe bien. Sozu a était conçu pour ça. L'utilisation de pile réseau différente permet de faire des bidouille d'un coté sans impacter le reste ce qui est cool. Par contre pour la mise à jour atomique d'un service ça me semble plus compliquée

Ça me parait juste infaisable

C'est pourtant ce que fais sslh ok c'est pas magnifique comme façon de faire, mais ça fonctionne très bien en 2 coups de cuillère à pot.

J'utilise un reverse proxy tcp par exemple ? (c'est précisément ce que je suis entrain de faire avec haproxy, mais nginx le fait aussi)
Pour udp je ne me suis jamais posé la question c'est un protocole que je n'ai pas eu l'occasion de manipuler.

Il s'agit évidement d'un troll de ma part, mais néanmoins entre tout ce qui est décrit et ajouter un sous domaine à ton reverse proxy, il y a un monde. Le second est bien plus simple… et régulièrement plus souhaitable. Ton reverse proxy peut faire un tas de choses réellement intéressantes (WAF, TLS offloading, logging, load balancing,…). Tout ça pour un coup de latence généralement négligeable. Beaucoup de gros services internet utilisent ce genre de solutions, c'est que ça doit pas trop être coûteux.

Grosso modo il s'agit de gérer le routage au niveau Application (c'est l'url - soit le chemin soit le sous domaine - qui discrimine), au niveau Transport (c'est le port qui discrimine) ou au niveau Réseau (c'est l'IP qui discrimine). Plus tu fais ça tôt plus tu gagne en performance (après est-ce que c'est sensible je ne suis pas sûr), mais tu dois faire des manipulations « système » (avoir ton DNS, ajouter une interface à ta machine, t'assurer que ton routage fonctionne bien,…). Tester et reproduire tout ça n'est pas trivial.

Est-ce que le jeu en vaut la chandelle ? C'est à chacun de se faire une idée, mais contrairement à ce qui est dit dans le journal choisir de faire un peu plus tardivement le routage ne me paraît pas forcément choquant.

Merci pour ton explication claire et très didactique ! J'ai enfin compris pourquoi on reste en IPv4.

une justification au délire, qui dit en gros que si on compromet le compilo, on compromet tout ce qu'il produit (c'est la Ken Thompson Attack)

Ça demande à ce que la propriété soit maintenu dans les compilateurs générés. Hors de cas totalement triviaux qui sont pas forcément très compliqué à déceler, ça me paraît assez complexe.

giphy utilise de plus en plus de vidéos

Je parlais plus par rapport à gif qu'a apng.

C'est le seul blocage qui pourrait empêcher certains de ne plus utiliser le format GIF au profit de WebP.

L'outillage peut être ? Si je me souviens bien gimp peut produire des animations gif, est-ce qu'il peut en faire avec WebP ?

Écran en veille, hibernation, s2ram, s2disk, power off, whatever tout ça c'est un ordinateur éteint. C'est du détail d'implémentation de l'extinction. C'est juste des manière que l'administrateur a choisi pour démarrer plus ou moins vite et tenter de ne pas perdre de travail.

Donc quand tu es devant un ordinateur éteint tu appuie sur le bouton. Devoir se demander dans quel état il se trouve et inutile pour l'utilisateur potentiel risque d'erreur. Avoir un bouton polymorphe n'est pas compliqué.

C'est en effet lié à l'algorithme de compression. PNG est efficace avec des surfaces d'une même teinte.

Après je ne sais pas comment ça se passe en pratique pour WebP. Passer de jpg à webp, n'est peut être pas génial (avoir les artefacts de l'un que l'on tente de compresser puis rendre avec l'autre).