5.1. Pré-connexion optimiste et réutilisation de connexion (Optimistic Pre-connection and Connection Reuse)

Si une réponse d'adresse arrive avant la réponse SVCB correspondante, le client peut initier une connexion comme si la requête SVCB renvoyait NODATA (MAY), mais ne doit pas transmettre d'informations qui pourraient être modifiées par la réponse SVCB avant qu'elle n'arrive (MUST NOT). Par exemple, de futurs SvcParamKeys pourraient être définis pour modifier le ClientHello TLS.

Les clients implémentant cette optimisation devraient attendre 50 millisecondes avant de démarrer la pré-connexion optimiste (SHOULD), conformément aux recommandations de [HappyEyeballsV2].

Un enregistrement SVCB est cohérent avec une connexion si le client tenterait une connexion équivalente lors de l'utilisation de cet enregistrement. Si un enregistrement SVCB est cohérent avec une connexion active ou en cours C, le client peut préférer cet enregistrement et utiliser C comme connexion (MAY). Par exemple, supposons que le client reçoive ce RRset SVCB pour un protocole utilisant TLS sur TCP :

_1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (
    ipv6hint=2001:db8::1 port=1234 )
                               SVCB 2 svc2.example.net. (
    ipv6hint=2001:db8::2 port=1234 )

Si le client a une connexion TCP en cours vers [2001:db8::2]:1234, il peut procéder avec TLS sur cette connexion (MAY), même si l'autre enregistrement du RRset a une priorité plus élevée.

Si aucun des enregistrements SVCB n'est cohérent avec une connexion active ou en cours, les clients procèdent à l'établissement de la connexion comme décrit dans la Section 3.