Réponse directe
Choisissez TCP lorsque la simplicité du pare-feu et la récupération des pertes sont importantes ; testez UDP sur un réseau local propre pour minimiser le délai de retransmission. La bonne réponse est le mode qui répond à l’objectif de perte, de latence et de stabilité mesuré.
Pourquoi cela arrive
RTSP est le protocole de contrôle, tandis que le support RTP peut utiliser l'entrelacement TCP ou UDP. TCP préserve la livraison commandée mais peut retarder les données ultérieures entraînant une perte ; UDP évite ce comportement mais ne retransmet pas lui-même les paquets perdus.
Traitez le URL, les informations d'identification, la famille d'adresses et le transport RTP comme des variables distinctes qui peuvent échouer indépendamment.
Un test contrôlé
Exécutez le même flux pendant un intervalle fixe dans chaque mode et enregistrez l'heure de démarrage, la perte visible, la latence et les déconnexions.
Modifiez une variable à la fois. Conservez le modèle de caméra, le micrologiciel, le point final et le compte enregistrés ; testez ensuite l'accessibilité du réseau, la réponse du protocole, le transport multimédia et le décodage en tant que couches distinctes.
Utilisez un compte dédié en lecture seule et un outil de diagnostic local fiable. Rédigez les informations d’identification, les adresses privées et les données d’identification avant de partager la sortie.
Séquence diagnostique
| Vérifier | Action | Preuve de progrès |
|---|---|---|
| Référence | Gardez URL, le codec, la résolution et le client fixes. | Seul le transport change entre les tests. |
| TCP | Mesurez la lecture stable via le pare-feu et les chemins VPN. | Aucun décrochage ne dépasse la limite opérationnelle. |
| UDP | Mesurez la perte de paquets et la réorganisation sur le réseau local. | Les artefacts restent en dessous du seuil accepté. |
| Décision | Sélectionnez par chemin réseau plutôt que par slogan. | Le mode choisi a enregistré des preuves. |
Des preuves à conserver
Un court tableau A/B avec la perte mesurée, la latence et le nombre de reconnexions est plus utile que de déclarer un transport universellement plus rapide.
Note de délimitation et de sécurité
N'ouvrez pas de larges plages publiques UDP ou des ports de caméra pour faire fonctionner UDP à distance ; effectuer la route privée à travers un VPN.
Pour la visualisation à distance, utilisez un VPN géré au lieu d'exposer RTSP ou les ports d'administration de la caméra directement à l'Internet public.
SmartRTSP
SmartRTSP est une visionneuse RTSP et ONVIF axée sur la caméra pour les appareils Apple, Windows et Android. Il convient aux contrôles de visualisation directe, de découverte et multi-caméras ; conservez un NVR ou VMS dédié lorsqu’un enregistrement continu, une exportation de preuves ou des contrôles d’entreprise centralisés sont requis.
Questions fréquemment posées
Est-ce que RTSP utilise toujours TCP ?
Le contrôle RTSP utilise généralement TCP, tandis que les médias RTP peuvent être négociés sur UDP ou entrelacés sur TCP.
La latence de UDP est-elle toujours inférieure ?
Pas automatiquement ; la congestion, la perte, la mise en mémoire tampon et le comportement du décodeur affectent tous la latence de bout en bout.
Pourquoi TCP fonctionne-t-il via un VPN alors que UDP échoue ?
Les médias entrelacés partagent la connexion de contrôle établie et nécessitent généralement moins de flux séparés.
Références principales
- IETF RFC 7826 — Protocole de diffusion en temps réel 2.0
- FFmpeg — RTSP options et exemples de protocole
Guide SmartRTSP associé
Ouvrir le guide associéComparez les TCP entrelacés et les UDP unicast avec la même caméra, le même codec et le même réseau avant de choisir une valeur par défaut.