Les deux fonctions P2P cœur de Skype : Découverte pairs & Transport média
L'architecture originale Skype (pré-migration cloud Microsoft) reposait sur overlay pair-à-pair (P2P) décentralisé pour deux tâches critiques :
1. Établir connexions directes pairs (Signalisation & Traversée NAT)
- Table de hachage distribuée (DHT) : Chaque client Skype agissait comme nœud dans DHT style Kademlia, stockant correspondances
(SkypeID → IP:port)pour utilisateurs en ligne. - Supernœuds : Clients haut débit, non pare-feu, promus supernœuds pour indexer segments DHT et assister traversée NAT.
- Logique type ICE/STUN/TURN : Une fois pairs localisés via DHT, tentative UDP hole-punching pour chemins média directs. Si NAT symétriques bloquent UDP direct, média relayé via supernœuds (agissant comme relais TURN).
- Résultat : Voix/vidéo faible latence, haute qualité, sans serveurs média centraux.
2. Transport multimédia temps réel (Audio/Vidéo/Données)
- Codecs propriétaires : SILK (audio, puis Opus), VP7/VP8 (vidéo) optimisés débits variables et pertes paquets.
- Flux P2P chiffrés : Média circulait AES-256 chiffré directement entre endpoints (ou via relais supernœud), réduisant charge/infra coûts centraux.
- Débit adaptatif : Estimation bande passante continue ajustait bitrate/FEC codec temps réel.
- Transfert fichiers & partage écran : Aussi sur mêmes canaux P2P chiffrés.
Basculement architectural (Post-2012)
Microsoft a progressivement déplacé signalisation vers services cloud Azure dédiés (Skype Cloud) et média vers clusters relais (Processeurs Média) pour meilleure autonomie mobile, conformité réglementaire (interception légale), vélocité fonctionnalités. Clients Skype modernes utilisent encore P2P pour certains canaux données pair-à-pair, mais média cœur principalement relayé cloud.
Comprendre le design P2P classique explique scalabilité précoce Skype — millions utilisateurs simultanés avec capex serveur minimal.