Tutoriel Go

tester résilience réseau Go avec toxiproxy: guide expert

Lorsque l’on parle de tester résilience réseau Go, il ne suffit plus de vérifier que le code fonctionne dans un environnement parfait. Les architectures modernes basées sur des microservices et le cloud sont intrinsèquement fragiles. Notre objectif est de passer d’une simple fonctionnalité testée à une véritable robustesse, capable de survivre aux pannes, aux latences imprévues et aux déconnexions partielles. Cet article est conçu pour les ingénieurs Go et les architectes DevOps qui cherchent à industrialiser la qualité de leurs systèmes en les soumettant au chaos de manière contrôlée.

Le concept de « Chaos Engineering » est au cœur de notre sujet. Historiquement, les développeurs se fiaient aux tests unitaires, puis aux intégrations. Cependant, ces tests ne simulent jamais la complexité réelle du réseau (jitter, perte de paquets, etc.). C’est là que des outils comme Toxiproxy deviennent indispensables. Tester résilience réseau Go avec un outil spécialisé permet de reproduire des scénarios de panne déterministes, garantissant que les mécanismes de récupération de votre application Go sont parfaitement calibrés, comme l’implémentation des circuit breakers.

Dans cette présentation approfondie, nous allons d’abord détailler les prérequis techniques nécessaires pour mettre en place un banc d’essai réaliste. Ensuite, nous plongerons dans les concepts théoriques de la manipulation réseau et nous explorerons un code source complet pour simuler des coupures de service. Nous aborderons également des cas d’usage avancés, comme la simulation de taux de perte aléatoires ou de latences asymétriques, et enfin, nous partagerons nos pièges à éviter et nos meilleures pratiques. Préparez-vous à transformer vos tests de charge en véritables simulations de catastrophes réseau pour bâtir des applications Go qui ne craignent rien.

tester résilience réseau Go — illustration

🛠️ Prérequis

Pour réaliser des tests de résilience réseau Go avec Toxiproxy, vous aurez besoin d’un environnement de développement moderne et de quelques outils spécifiques. Le respect des prérequis garantit que votre banc de test soit stable et reproductible.

Prérequis techniques

Langage : Go (Version 1.20 ou supérieure recommandée).
Outil principal : Toxiproxy (doit être installé et accessible en tant que service ou binaire).
Système d’exploitation : Linux est fortement recommandé pour la gestion réseau fine.

Installation détaillée :

Go : Si ce n’est pas fait, installez Go via le gestionnaire de paquets de votre OS (e.g., sudo apt install golang). Vérifiez la version avec go version.
Toxiproxy : Téléchargez le binaire Toxiproxy pour votre système ou utilisez son installation via Docker, ce qui est le moyen le plus simple de garantir la version correcte. Exemple Docker : docker pull ghcr.io/shopify/toxiproxy.
Librairies Go : Aucun module externe n’est strictement requis pour le code de démonstration, mais une gestion des erreurs et du contexte (context.Context) est fondamentale.

Ces outils permettent de créer une couche d’abstraction réseau parfaite, essentielle pour tester résilience réseau Go sans dépendre de la topologie physique du réseau réel.

📚 Comprendre tester résilience réseau Go

Le cœur du problème dans les systèmes distribués est que le réseau est le point de défaillance le plus faible. Les protocoles de transport (comme TCP) sont géniaux pour les flux stables, mais ils masquent les problèmes de performance et de fiabilité qui ne se manifestent qu’en cas de dégradation. Pour tester résilience réseau Go, nous devons injecter délibérément du chaos.

Toxiproxy agit comme un proxy de réseau bidirectionnel programmable. Au lieu de simplement relayer le trafic entre deux services (Service A vers Service B), Toxiproxy permet d’intercepter ce flux de données et de le modifier ou de le bloquer. C’est une approche bien plus fine que le simple pare-feu (iptables), qui ne permet que des règles de port ou d’IP.

Imaginez un tuyau d’eau parfait (le réseau normal). Toxiproxy est un robinet programmable que vous insérez juste avant le tuyau. Vous pouvez contrôler si l’eau s’écoule au bon débit (latence), si le tuyau est temporairement obstrué (coupure), ou si la pression fluctue aléatoirement (perte de paquets). Ce contrôle granulaire est ce qui rend Toxiproxy si puissant pour les tests de chaos.

Comment fonctionne la manipulation réseau Toxiproxy?

Les fonctionnalités clés comprennent :

Latency : Ajouter un délai fixe ou variable, simulant une mauvaise bande passante.
Downstream/Upstream : Injecter des paquets de perte (packet loss) ou des erreurs TCP spécifiques.
Blackhole : Bloquer complètement le trafic pour simuler une panne de route ou de serveur.

Comparer avec d’autres outils : Tandis que des frameworks de service mesh comme Istio gèrent la résilience *en production* (et utilisent des sidecar proxies), Toxiproxy est un outil de *test* pur. Il vous offre un point de contrôle réseau parfait et isolé, idéal pour intégrer la défaillance dans votre cycle CI/CD, permettant de tester résilience réseau Go avant le déploiement. En Go, cette capacité de contrôle est exploitée en plaçant la logique de gestion des timeouts et des retries directement autour des appels réseau qui passent par le proxy Toxiproxy.

🐹 Le code — tester résilience réseau Go

package main

import (
	"context"
	"fmt"
	"log"
	"net"
	"time"
)

// simulateServiceCall simule un appel HTTP/gRPC entre le service client et le service serveur.
func simulateServiceCall(context context.Context, targetAddress string) error {
	fmt.Printf("[Client] Tentative de connexion vers %s...\n", targetAddress)

	// Utilisation de net.DialTimeout pour simuler une connexion qui doit supporter des timeouts.
	conn, err := net.DialTimeout("tcp", targetAddress, 5*time.Second)
	if err != nil {
		return fmt.Errorf("échec de la connexion réseau : %w", err)
	}
	defer conn.Close()

	fmt.Println("[Client] Connexion établie avec succès. Données envoyées.")
	// Simuler l'envoi d'une requête
	if _, err := conn.Write([]byte("Requête de test\n")); err != nil {
		return fmt.Errorf("échec de l'écriture sur le socket : %w", err)
	}

	// Lire la réponse en attendant un timeout
	buffer := make([]byte, 1024)

	// Attente de la réponse avec un contexte limité (important pour la résilience)
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()

	go func() {
		// Lecture en arrière-plan
		_, readErr := conn.Read(buffer)
		if readErr != nil && readErr != net.ErrClosed { 
			log.Println("Alerte lecture :", readErr)
		}
	}()

	select {
	case <-ctx.Done():
		// Ce cas est activé si le délai de 2 secondes est dépassé.
		return fmt.Errorf("timeout simulé : la réponse est trop lente et le contexte est annulé")
	case <-time.After(1 * time.Second): // Simulation d'une attente normale
		return nil
	}
}

func main() {
	// ATTENTION : Ceci est un appel simulé. Pour un test réel, targetAddress doit pointer vers Toxiproxy.
	// Ex: toxiproxy:8080
	const target = "localhost:8080"

	fmt.Println("====================================================================
")
	fmt.Printf("Début du test de résilience réseau contre %s (simule l'appel Toxiproxy)...
", target)

	// Premier appel: Simulation réussie (ou dans un état contrôlé)
	if err := simulateServiceCall(context.Background(), target); err != nil {
		log.Printf("[Résultat 1] Échec (Attendu ou réel) : %v\n", err)
	}

	fmt.Println("--------------------------------------------------------------------")

	// Deuxième appel: Simulation de timeout (En réalité, Toxiproxy est configuré pour la latence)
	// Nous appelons la fonction à nouveau, mais en théorie, Toxiproxy est réglé sur 10s de latence.
	fmt.Println("--- Simulation de Timeout (latence excessive) ---")
	if err := simulateServiceCall(context.Background(), target); err != nil {
		log.Printf("[Résultat 2] Échec (Timeout) : %v\n", err)
	} else {
		log.Println("[Résultat 2] Succès inattendu.")
	}

	fmt.Println("====================================================================")
}

📖 Explication détaillée

Ce premier snippet Go est conçu pour démontrer la manière dont une application Go doit se comporter lorsqu’elle est confrontée à un réseau défaillant ou latent, un scénario parfaitement créé par Toxiproxy. Nous ne testons pas seulement la connexion, mais la *gestion* de la déconnexion.

L’utilisation de net.DialTimeout est le point de départ crucial. Au lieu de laisser le système tenter de se connecter indéfiniment, nous imposons un délai strict (5 secondes). C’est la première ligne de défense de votre code en cas de tester résilience réseau Go. Si Toxiproxy est mis en place pour bloquer le trafic ou injecter une latence excessive, cette fonction sera le premier à signaler un *net.OpError, que nous capturons et traitons.

Décomposition des mécanismes de résilience

context.Context et Timeouts : C’est le pilier de la résilience Go. En passant un context avec un timeout limité (context.WithTimeout), nous garantissons qu’aucune opération réseau ne va bloquer le goroutine indéfiniment. Si l’API distante met trop de temps à répondre (simulé par Toxiproxy), le contexte s’annule (<-ctx.Done()) et le circuit breaker est déclenché, empêchant l'épuisement des ressources.
Gestion de l'échec réseau (net.DialTimeout) : Le code capture explicitement les erreurs réseau. Si ce bloc reçoit un err, il signifie que Toxiproxy a réussi à empêcher la connexion ou l'a considérablement retardée, forçant le développeur à implémenter une logique de fallback.
Sélection (select) : L'utilisation de select est la manière idiomatique en Go de gérer plusieurs événements concurrents (réussite, timeout, annulation). Elle est fondamentale car elle permet de répondre à une condition (ex: timeout) sans attendre la fin de l'opération réseau en arrière-plan.

En choisissant net.DialTimeout plutôt que de simplement utiliser net.Dial, nous faisons le choix technique explicite de gérer les pannes de réseau, plutôt que de laisser Go gérer le défaut système, ce qui est essentiel pour des systèmes Go robustes. Le piège potentiel est de ne pas gérer les cas de context.Done() correctement, car cela ne signifie pas toujours qu'une panne est survenue, mais simplement que le temps écoulé, ce qui nécessite des logs et des traitements différenciés pour tester résilience réseau Go efficacement.

📖 Ressource officielle : Documentation Go — tester résilience réseau Go

🔄 Second exemple — tester résilience réseau Go

package main

import (
	"fmt"
	"log"
	"time"
)

// checkRetryMechanism simule la tentative de reconnexion avec mécanisme de backoff.
func checkRetryMechanism(attempt int, serviceName string) error {
	// Dans un scénario réel, cette fonction utiliserait une librairie comme Hystrix ou Resilience4j (via Go binding).
	// Ici, nous simulons l'échec initial puis la récupération.
	if attempt < 3 {
		// Échec simulé : Le service est hors ligne ou le proxy Toxiproxy bloque le trafic.
		log.Printf("[Tentative %d] Échec : Connexion refusée. Réseau indisponible.", attempt+1)
		return fmt.Errorf("connexion refusée")
	}
	
	// Après 3 tentatives (c'est-à-dire la 4ème tentative), on suppose que le service est revenu.
	log.Printf("[Tentative %d] Succès : Le service %s est de nouveau disponible !", attempt+1, serviceName)
	return nil
}

func main() {
	log.Println("Démarrage du test de reconnexion (Backoff et Retry)")

	// Test de résilience : Tenter la connexion 5 fois avec une logique de backoff exponentiel.
	maxAttempts := 5
	var lastError error

	for attempt := 0; attempt < maxAttempts; attempt++ {
		err := checkRetryMechanism(attempt, "AuthService")
		if err == nil {
			break // Sortie réussie
		}
		lastError = err
		
		// Logique de Backoff Exponentiel : Attendre 2s, 4s, 8s... avant la prochaine tentative.
		waitTime := time.Duration(1<<attempt) * 2 * time.Second
		log.Printf("Attente de %v avant la prochaine tentative...", waitTime)
		time.Sleep(waitTime)
	}

	if lastError != nil {
		log.Printf("Test terminé après %d tentatives. Échec final : %v", maxAttempts, lastError)
	}
}

▶️ Exemple d'utilisation

Imaginons un microservice de catalogage produit (ProductService) qui dépend d'un autre service de tarification (PriceService). Normalement, la requête est rapide. Pour un test avancé, nous voulons vérifier que si le PriceService devient très lent (simulée par Toxiproxy), notre ProductService affiche quand même le produit avec un message de warning, au lieu de planter.

Scénario :

L'architecte de test configure Toxiproxy pour intercepter le port de PriceService et y appliquer une latence constante de 7 secondes.
Le développeur exécute le client Go avec un timeout de 3 secondes sur l'appel à PriceService.

Code d'appel (conceptuel) :

// Dans le ProductService :
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()

// Appelle le service, qui est bloqué par Toxiproxy
price, err := priceClient.GetPrice(ctx, productID)

if err != nil {
    // Gestion de l'échec grâce au timeout de 3 secondes
    log.Printf("Attention : Impossible d'obtenir le prix. Problème réseau détecté. Utilisation du prix par défaut.")
    return PriceDefault
}
return price, nil

Sortie console attendue :

[ProductService] Appel à PriceService démarré...
// ... 3 secondes de latence simulées par Toxiproxy
[ProductService] Timeout détecté ! Le prix n'a pas pu être récupéré à temps.
Prix affiché : 99.99 USD (Prix Fallback)

Ce résultat prouve que notre logique de fallback, déclenchée par le timeout (grâce au mécanisme de context.Context en Go), fonctionne correctement. Nous avons ainsi réussi à tester résilience réseau Go avec succès en simulant une panne de performance.

🚀 Cas d'usage avancés

Le véritable pouvoir de Toxiproxy, intégré avec Go, réside dans sa capacité à simuler des scénarios de défaillance complexes, bien au-delà du simple "hors ligne". Ces cas d'usage permettent de passer de l'état "ça marche bien" à "ça tient la route".

1. Test de Circuit Breaker (Open/Closed State)

Le motif Circuit Breaker est vital. Il empêche une application d'appeler un service défaillant en boucle, ce qui pourrait surcharger ce service. Toxiproxy permet de simuler la dégradation pour forcer le passage de l'état "Closed" à "Open".

Scénario : Le service de paiement est lent pendant 5 secondes. Le circuit doit se fermer et revenir en mode fallback immédiatement.

// Code pour forcer l'ouverture du circuit : // 1. Configurer Toxiproxy pour Latency=5s // 2. Exécuter la requête Go 3 fois en séquence : for i := 0; i < 3; i++ { /* callService(ctx) */ } // 3. Si les 3 appels échouent dans la fenêtre de temps, le circuit doit immédiatement déclencher la logique de fallback.

2. Simulation de Taux de Perte de Paquets (Jitter et Packet Loss)

Les réseaux réels ne tombent pas brutalement, ils dégénèrent. Simuler une perte aléatoire de paquets (5% de perte) oblige votre protocole à gérer la retransmission et le désordre des données. C'est une forme de stress plus réaliste qu'un simple timeout.

Implémentation : On configure Toxiproxy pour un PacketLossRate = 0.05. Votre code Go doit donc être écrit pour tolérer l'ordre des messages et ne pas paniquer si des paquets sont reçus en retard ou manquent.

3. Gestion des Limites de Taux (Rate Limiting)

Au lieu de laisser une erreur 429 Too Many Requests remonter directement, on peut simuler des goulots d'étranglement. Cela permet de vérifier que votre client Go implémente correctement un mécanisme de Retry-After.

// Explication : // Toxiproxy est configuré pour bloquer les requêtes après 10 appels. // Le client Go doit analyser le header HTTP 'Retry-After' et ne pas réessayer avant la seconde spécifiée.

// Pseudo-code de gestion des limites : if resp.StatusCode == 429 { retryAfter := resp.Header.Get("Retry-After") if retryAfter != "" { time.Sleep(parseDuration(retryAfter)) } }

4. Latence Asymétrique (Downstream vs Upstream)

Un scénario très réaliste est que l'envoi de la requête (Upstream) soit rapide, mais que la réponse (Downstream) soit très lente, ou vice-versa. Toxiproxy permet de séparer ces deux injections de latence. Ceci est crucial pour tester résilience réseau Go et s'assurer que le traitement côté client ne s'accélère pas en attendant des métadonnées lentement envoyées.

⚠️ Erreurs courantes à éviter

Même avec des outils puissants comme Toxiproxy, il est facile de faire des erreurs de conception dans les tests de résilience. Voici les pièges les plus fréquents pour les développeurs Go.

Erreurs classiques à éviter

Ne tester que l'état de déconnexion total : Le piège le plus courant. Un réseau réel ne coupe pas brutalement. Il ralentit. Oublier d'introduire des tests de latence et de perte de paquets signifie que votre code échouera en production, même si les tests passent.
Ignorer le contexte de timeout : Ne jamais utiliser de context.Context avec des timeouts est une faille majeure. Une requête bloquée sur un appel réseau peut faire s'écraser tout le goroutine et potentiellement le service entier.
Dépendance unique au mécanisme de retry : Se contenter de faire des boucles de retry sans mécanisme de backoff exponentiel. Tenter de se reconnecter immédiatement après un échec peut aggraver la congestion réseau et saturer les ressources.
Manque de test des limites de débit (Rate Limits) : Considérer que les appels API sont toujours acceptés. Toxiproxy permet de simuler des refus 429, forçant le développeur à intégrer une gestion des headers Retry-After.

Pour tester résilience réseau Go, chaque type d'erreur doit être traité, pas seulement l'erreur "Connexion refusée".

✔️ Bonnes pratiques

Pour monter en compétence sur la résilience et les tests de chaos, suivez ces conseils de niveau expert.

1. Adopter le Pattern Circuit Breaker (Circuit-Breaker Pattern)

Ce pattern est non négociable dans les microservices. Il doit envelopper tous les appels externes pour détecter rapidement les pannes et fournir une réponse immédiate (fallback) au lieu de patienter pour un timeout.

Conseil Go : Utilisez des librairies éprouvées ou implémentez votre propre gestion d'état (Open, Half-Open, Closed) autour de vos appels réseau.

2. Déployer la "Random Failure Injection"

Ne testez pas toujours les mêmes pannes. Le meilleur moyen de robustesse est de rendre les échecs imprévisibles. Utilisez des mécanismes pour injecter aléatoirement de la latence ou de la perte, forçant le code à se stabiliser sur une base de tolérance au chaos plutôt que sur la dépendance à un chemin réseau parfait.

3. Isoler les tests avec Toxiproxy

Ne laissez jamais les tests de résilience dépendre du réseau physique. Dockerisez l'ensemble de votre test (Client, Service A, Service B, Toxiproxy) et utilisez Toxiproxy comme couche réseau unique et contrôlable.

4. Implémenter le Backoff Exponentiel avec Jitter

Lors de la logique de retry, n'attendez pas un temps fixe. Utilisez un backoff exponentiel (attente = base ^ attempt) et ajoutez un facteur de jitter (aléatoire) pour éviter que tous les clients ne tentent de se reconnecter en même temps au service redevenu en ligne (le fameux "thundering herd problem").

5. Mesurer les métriques de résilience

Un test réussi n'est pas seulement un test qui ne plante pas. Il doit générer des métriques : taux de timeout, temps moyen pour passer en état fallback, et temps de récupération. Ces données sont essentielles pour améliorer votre SLO/SLA.

📌 Points clés à retenir

Toxiproxy est essentiel pour simuler des pannes réseau déterministes, un prérequis critique pour le Chaos Engineering en Go.
L'utilisation de context.Context avec des timeouts stricts est la meilleure pratique Go pour prévenir les blocages réseau indéfinis.
La résilience ne se limite pas au timeout ; elle implique la gestion des pannes partielles, des latences et de la perte de paquets.
Le Circuit Breaker Pattern doit être implémenté au niveau du client Go pour isoler l'impact d'un service défaillant.
Pour les tests de résilience réseau Go, le 'backoff exponentiel' doit être combiné à du 'jitter' pour éviter la congestion post-panne.
Travailler avec Toxiproxy dans un conteneur Docker garantit l'isolation et la reproductibilité des scénarios de tests.
Un code résilient doit toujours avoir une stratégie de fallback clairement définie lorsque le réseau ne répond pas, plutôt que de simplement planter.
Le passage des tests unitaires aux tests de résilience nécessite une méthodologie de test orientée 'failure'.

📚 Articles liés

✅ Conclusion

En conclusion, maîtriser le processus pour tester résilience réseau Go avec Toxiproxy, ce n'est pas seulement apprendre un outil; c'est adopter une mentalité d'ingénieur qui anticipe la défaillance. Nous avons vu que le passage des tests unitaires simples à des simulations de chaos réseau complexes est une étape mature dans le cycle de vie du développement. En utilisant des outils comme Toxiproxy, et en intégrant des patterns comme le Circuit Breaker et le Backoff dans notre code Go, nous transformons nos applications potentiellement fragiles en systèmes distribués véritablement robustes. La capacité à gérer un timeout ou une coupure réseau avec élégance est la marque d'un code Go de classe mondiale.

Pour aller plus loin, nous vous recommandons d'explorer le domaine du Chaos Engineering avec des outils comme Chaos Mesh, ou de pratiquer en simulant des scénarios de latence asymétrique. La documentation officielle des outils de networking de Go, ainsi que des projets de service mesh open source, sont d'excellentes ressources. Rappelez-vous que le meilleur test est celui qui simule l'environnement le plus hostile, mais de la manière la plus contrôlée possible.

La communauté Go est reconnue pour son minimalisme et sa performance, mais la robustesse de cette performance dépend directement de la façon dont elle gère l'incertain. N'attendez pas la première panne en production pour vous outiller. Adoptez ces pratiques dès aujourd'hui ! N'hésitez pas à partager vos propres cas de stress réseau ou de fallbacks réussis dans les commentaires, et considérez cet article comme le début de votre parcours vers l'excellence en ingénierie de la résilience Go. Pour toutes les références de gestion réseau en Go, consultez la documentation Go officielle. Bonne chance dans vos tests de chaos !

tester résilience réseau Go avec toxiproxy: guide expert

tester résilience réseau Go avec toxiproxy: guide expert

🛠️ Prérequis

Prérequis techniques

📚 Comprendre tester résilience réseau Go

Comment fonctionne la manipulation réseau Toxiproxy?

🐹 Le code — tester résilience réseau Go

📖 Explication détaillée

Décomposition des mécanismes de résilience

🔄 Second exemple — tester résilience réseau Go

▶️ Exemple d'utilisation

🚀 Cas d'usage avancés

1. Test de Circuit Breaker (Open/Closed State)

2. Simulation de Taux de Perte de Paquets (Jitter et Packet Loss)

3. Gestion des Limites de Taux (Rate Limiting)

4. Latence Asymétrique (Downstream vs Upstream)

⚠️ Erreurs courantes à éviter

Erreurs classiques à éviter

✔️ Bonnes pratiques

1. Adopter le Pattern Circuit Breaker (Circuit-Breaker Pattern)

2. Déployer la "Random Failure Injection"

3. Isoler les tests avec Toxiproxy

4. Implémenter le Backoff Exponentiel avec Jitter

5. Mesurer les métriques de résilience

✅ Conclusion

Graceful Shutdown Go : Maîtriser le graceful shutdown go des serveurs

Injection SQL via arguments

CLI Go professionnel : Maîtriser Cobra pour vos outils en ligne de commande

DI framework Go lifecycle : Maîtriser l’injection de dépendances en Go

KV store LSM Go : Maîtriser BadgerDB en Go

Serveur fichiers statiques Go : Guide de création rapide et robuste

Laisser un commentaire Annuler la réponse

tester résilience réseau Go avec toxiproxy: guide expert

🛠️ Prérequis

Prérequis techniques

📚 Comprendre tester résilience réseau Go

Comment fonctionne la manipulation réseau Toxiproxy?

🐹 Le code — tester résilience réseau Go

📖 Explication détaillée

Décomposition des mécanismes de résilience

🔄 Second exemple — tester résilience réseau Go

▶️ Exemple d'utilisation

🚀 Cas d'usage avancés

1. Test de Circuit Breaker (Open/Closed State)

2. Simulation de Taux de Perte de Paquets (Jitter et Packet Loss)

3. Gestion des Limites de Taux (Rate Limiting)

4. Latence Asymétrique (Downstream vs Upstream)

⚠️ Erreurs courantes à éviter

Erreurs classiques à éviter

✔️ Bonnes pratiques

1. Adopter le Pattern Circuit Breaker (Circuit-Breaker Pattern)

2. Déployer la "Random Failure Injection"

3. Isoler les tests avec Toxiproxy

4. Implémenter le Backoff Exponentiel avec Jitter

5. Mesurer les métriques de résilience

✅ Conclusion

Publications similaires

Laisser un commentaire Annuler la réponse