1. Introduction

Cette section n’est pas normative.

Cette spécification utilise des protocoles enfichables, avec QUIC [QUIC-TRANSPORT] comme un de ces protocoles, pour envoyer et recevoir des données des serveurs. Ça peut être utilisé comme WebSockets mais avec prise en charge de plusieurs flux, unidirectionnel les flux, la livraison dans le désordre et le transport fiable et non fiable.

Remarque: L’API présentée dans cette spécification représente une proposition préliminaire sur la base des travaux en cours au sein du groupe de travail IETF QUIC. Depuis le transport QUIC spécification est un travail en cours, le protocole et l’API sont susceptibles de changer considérablement à l’avenir.

2. Conformité

En plus des sections marquées comme non normatives, toutes directives de rédaction, les diagrammes, exemples et notes de cette spécification ne sont pas normatifs. Tout le reste dans cette spécification est normatif.

Les mots clés DOIT et DEVRAIT doivent être interprétés comme décrit dans [RFC2119] .

Cette spécification définit les critères de conformité qui s’appliquent à un seul produit : l’agent utilisateur qui implémente les interfaces qu’il contient.

Les exigences de conformité formulées sous forme d’algorithmes ou d’étapes spécifiques peuvent être mis en œuvre de quelque manière, tant que le résultat final est équivalent. (Dans en particulier, les algorithmes définis dans cette spécification sont destinés à être facile à suivre et non destiné à être performant.)

Les implémentations qui utilisent ECMAScript pour implémenter les API définies dans ce spécification DOIT les implémenter d’une manière cohérente avec l’ECMAScript Liaisons définies dans la spécification Web IDL [WEBIDL] , comme ceci La spécification utilise cette spécification et cette terminologie.

3. Terminologie

Le Gestionnaire d'événements interface, représentant un rappel utilisé pour l’événement et les ErrorEvent sont définies dans [HTML] .

Les concepts mettre en file d’attente une tâche et source de tâche de mise en réseau sont définis dans [HTML] .

Les termes un événement , gestionnaires d’événements et événement du gestionnaire d’événements types sont défini dans [HTML] .

En se référant aux exceptions, les termes lancer et create sont définis dans [WEBIDL] .

Les termes rempli , rejeté , résolu, en attente et colonisé utilisés dans le cadre des Promesses sont définis dans [ECMASCRIPT-6.0] .

Les termes ReadableStream et WritableStream sont définis dans [WHATWG-STREAMS] . Notez que malgré le partage du nom « stream », ce sont distinct de IncomingStream, OutgoingStream et BidirectionalStream défini ici. IncomingStream, OutgoingStream et BidirectionalStream défini ici correspond à un niveau d’abstraction plus élevé qui contient et dépendent des concepts de «flux» de niveau inférieur définis dans [WHATWG-STREAMS] .

4. UnidirectionalStreamsTransport Mixin

UNE UnidirectionalStreamsTransport peut envoyer et recevoir flux unidirectionnels. Les données d’un flux sont livrées dans l’ordre, mais les données entre les flux peuvent être livrés hors service. Les données sont généralement envoyées de manière fiable, mais les retransmissions peuvent être désactivées ou le flux peut être interrompu pour produire une forme de manque de fiabilité. Toutes les données de flux sont cryptées et contrôlé par la congestion.

 interface  mixin    UnidirectionalStreamsTransport   {   Promettre   SendStream  >   createSendStream   (optionnel   SendStreamParameters     paramètres   ={});     ReadableStream     receiveStreams   (); }; 

4.1. Méthodes

createSendStream ()

Crée un SendStream objet.

Quand createSendStream () est appelée , l’agent utilisateur DOIT exécuter le Etapes suivantes:

1. Laisser transport Soit le UnidirectionalStreamsTransport sur lequel createSendStream est invoqué.

2. Si transport ‘s Etat est "fermé" ou "échoué", retourner immédiatement un nouveau refusée promesse avec un nouvellement créé InvalidStateError et abandonnez ces étapes.

3. Laisser p soit une nouvelle promesse.

4. Revenir p et continuez les étapes suivantes dans Contexte.

5. Résoudre p avec un nouveau SendStream objet et ajouter le SendStream à transport lorsque toutes les conditions suivantes sont remplies rencontré:

   1. Le transport ‘s Etat est en transition à "lié".

   2. Le contrôle du flux de création de flux n’est pas violé en dépassant le limite de flux maximale définie par le point de terminaison distant. Pour QUIC, c’est spécifié dans [QUIC-TRANSPORT].

   3. p n’a pas été colonisé.

6. Rejeter p avec un nouveau InvalidStateError lorsque tous les conditions suivantes sont remplies:

   1. Le transport transitions d’état vers "fermé" ou "échoué".

   2. p n’a pas été colonisé.

receiveStreams ()

Renvoie un ReadableStream de ReceiveStream reçus de l’hôte distant.

Quand receiveStreams est appelé, l’utilisateur l’agent DOIT exécuter ce qui suit pas:

1. Laisser transport Soit le UnidirectionalStreamsTransport sur lequel receiveStreams est invoqué.

2. Renvoyer la valeur de [[ReceivedStreams]] emplacement interne.

3. Pour chaque flux unidirectionnel reçu, créez un correspondant Flux entrant et insérez-le dans [[ReceivedStreams]] . Comme données est reçue sur le flux unidirectionnel, insérez ces données dans le correspondant IncomingStream . Lorsque le côté distant se ferme ou s’interrompt le flux, fermez ou abandonnez le correspondant IncomingStream .

4.2. Procédures

4.2.1. Ajouter SendStream à UnidirectionalStreamsTransport

4.3. SendStreamParameters Dictionary

Le SendStreamParameters le dictionnaire comprend des informations concernant la configuration du flux

 dictionnaire   SendStreamParameters   { }; 

5. BidirectionalStreamsTransport Mixin

UNE BidirectionalStreamsTransport peut envoyer et recevoir flux bidirectionnels. Les données d’un flux sont livrées dans l’ordre, mais les données entre les flux peuvent être livrés hors service. Les données sont généralement envoyées de manière fiable, mais les retransmissions peuvent être désactivées ou le flux peut être interrompu pour produire un formulaire de manque de fiabilité. Toutes les données du flux sont cryptées et contrôlées par la congestion.

 interface  mixin    BidirectionalStreamsTransport   {     Promettre   Flux bidirectionnel  >   createBidirectionalStream   ();       ReadableStream     receiveBidirectionalStreams   (); }; 

5.1. Méthodes

createBidirectionalStream ()

Crée un BidirectionalStream objet.

Quand createBidirectionalStream est appelé, l’utilisateur l’agent DOIT exécuter le Etapes suivantes:

1. Laisser transport Soit le BidirectionalStreamsTransport sur lequel createBidirectionalStream est invoquée.

2. Si transport ‘s Etat est "fermé" ou "échoué", retourner immédiatement un nouveau refusée promesse avec une nouvelle création InvalidStateError et abandonnez ces étapes

3. Si transport ‘s Etat est "lié", immédiatement retourner un nouveau promesse remplie avec une nouvelle création Flux bidirectionnel objet, ajoutez le BidirectionalStream à la transporter et abandonner ces étapes.

4. Laisser p soit une nouvelle promesse.

5. Revenir p et continuez les étapes suivantes dans Contexte.

6. Résoudre p avec un nouveau BidirectionalStream objet et ajoutez le BidirectionalStream à transport lorsque tous les éléments suivants les conditions sont remplies:

   1. Le transport ‘s Etat est passé à " lié".

   2. Le contrôle du flux de création de flux n’est pas violé en dépassant le limite de flux maximale définie par le point de terminaison distant. Pour QUIC, c’est spécifié dans [QUIC-TRANSPORT].

   3. p n’a pas été colonisé.

7. Rejeter p avec un nouveau InvalidStateError lorsque tous les les conditions suivantes sont remplies:

   1. Le transport transitions d’état vers "fermé" ou "échoué".

   2. p n’a pas été colonisé.

receiveBidirectionalStreams ()

Renvoie un ReadableStream de Flux bidirectionnel s qui ont été reçu de l’hôte distant.

Quand receiveBidirectionalStreams est appelée, la méthode l’agent utilisateur DOIT s’exécuter les étapes suivantes:

1. Laisser transport Soit le BidirectionalStreamsTransport sur lequel receiveBidirectionalStreams est invoqué.

2. Renvoyer la valeur de [[ReceivedBidirectionalStreams]] emplacement interne.

3. Pour chaque flux bidirectionnel reçu, créez un correspondant Flux bidirectionnel et insérez-le dans [[ReceivedBidirectionalStreams]] . Lorsque des données sont reçues sur le flux bidirectionnel, insérez ces données dans le correspondant Flux bidirectionnel . Lorsque le côté distant se ferme ou s’interrompt le flux, fermez ou abandonnez le correspondant Flux bidirectionnel .

5.2. Procédures

5.2.1. Ajouter BidirectionalStream à BidirectionalStreamsTransport

6. DatagramTransport Mixin

UNE DatagramTransport peut envoyer et recevoir datagrammes. Les datagrammes sont envoyés dans le désordre, de manière non fiable, et ont une taille maximale limitée. Les datagrammes sont cryptés et la congestion contrôlée.

 interface  mixin    DatagramTransport   {     lecture seulement attribut  non signé court    maxDatagramSize  ;       WritableStream     sendDatagrams   ();       ReadableStream     recevoir des diagrammes   (); }; 

6.1. Les attributs

maxDatagramSize , de type court non signé , lecture seulement

Les données de taille maximale qui peuvent être transmises à sendDatagrams .

6.2. Méthodes

sendDatagrams ()

Envoie des datagrammes qui sont écrits sur le retour WritableStream .

Quand sendDatagrams est appelé, l’utilisateur l’agent DOIT exécuter les étapes suivantes:

1. Laisser transport Soit le DatagramTransport sur lequel sendDatagram est invoqué.

2. Renvoyer la valeur de [[SentDatagrams] ] emplacement interne.

receiveDatagrams ()

Renvoyer la valeur de [[ReceivedDatagrams]] emplacement interne.

Pour chaque datagramme reçu, insérez-le dans [[ReceivedDatagrams]] . Si aussi de nombreux datagrammes sont mis en file d’attente car le flux n’est pas lu rapidement assez, supprimez les datagrammes pour éviter la file d’attente. Les implémentations devraient être plus anciennes datagrammes en faveur de datagrammes plus récents. Le nombre de datagrammes à mettre en file d’attente doit être suffisamment petit pour éviter d’ajouter une latence importante au paquet livraison lorsque le flux est lu lentement (en raison de la lenteur du lecteur) mais suffisamment grand pour éviter de perdre des paquets lorsque le flux n’est pas lu pendant de courtes périodes (en raison d’une pause du lecteur).

7. WebTransport Mixin

Le WebTransport comprend les méthodes communes à tous les transports, tels que l’état, les changements d’état et la possibilité de fermer le transport.

 interface  mixin     WebTransport    {   lecture seulement attribut   WebTransportState    Etat ;   lecture seulement attribut Promettre   WebTransportCloseInfo  >  fermé ;   néant  proche  (optionnel   WebTransportCloseInfo      closeInfo    ={});   attribut  Gestionnaire d'événements    onstatechange  ; }; 

7.1. Les attributs

Etat , de type WebTransportState , lecture seulement

L’état actuel du transport. En obtenant, il DOIT retourner la valeur de les [[WebTransportState]] emplacement interne.

fermé , de type Promise WebTransportCloseInfo >, en lecture seule

Cette promesse DOIT être résolu lorsque le transport est fermé; une la mise en œuvre DEVRAIT inclure des informations d’erreur dans le raison et code d'erreur champs de WebTransportCloseInfo .

onstatechange , de type Gestionnaire d’événements

Ce gestionnaire d’événements, de type événement gestionnaire d’événements statechange , DOIT être renvoyé à tout moment le [[WebTransportState]] change d’emplacement, sauf si l’état change en raison de l’appel proche .

7.2. Méthodes

proche()

Ferme l’objet WebTransport. Pour QUIC, cela déclenche un Immédiat Fermer comme décrit dans [QUIC-TRANSPORT] section 10.3.

Lorsque close est appelé, l’agent utilisateur DOIT exécuter le Etapes suivantes:

1. Laisser transport être le WebTransport sur lequel proche est invoqué.

2. Si transport ‘s [[WebTransportState]] est "fermé" ou "échoué", puis abandonnez ces étapes.

3. Ensemble transport ‘s [[WebTransportState]] à "fermé".

4. Laisser closeInfo être le premier argument.

5. Pour QUIC, démarrez le Fermeture immédiate en envoyant un Cadre CONNECTION_CLOSE avec sa valeur de code d’erreur définie sur la valeur code d'erreur et sa valeur de raison définie sur valeur de raison .

7.3. WebTransportState Enum

WebTransportState indique l’état du transport.

  énumération    WebTransportState   {    "de liaison" ,    "lié" ,    "fermé" ,    "échoué"  }; 

"de liaison"

Le transport est en train de négocier une connexion sécurisée . Une fois par une connexion sécurisée est négociée, les données entrantes peuvent circuler.

"lié"

Le transport a terminé la négociation d’une connexion sécurisée. Sortant les données et les médias peuvent désormais circuler.

"fermé"

Le transport a été fermé intentionnellement via un appel à proche() ou réception d’un message de fermeture de la télécommande côté. Quand le WebTransport interne [[WebTransportState]] fente transitions vers fermé l’agent utilisateur DOIT exécuter les étapes suivantes:

1. Laisser transport Soit le WebTransport .

2. Fermer la ReadableStream dans transport [[ReceivedStreams]] emplacement interne.

3. Fermer la ReadableStream dans transport [[ReceivedBidirectionalStreams]] emplacement interne.

4. Pour chaque OutgoingStream dans transport [[OutgoingStreams]] slot interne exécutez ce qui suit:

   1. Laisser courant Soit le Flux sortant .

   2. Retirer le courant du transport [[OutgoingStreams]] emplacement interne.

"échoué"

Le transport a été fermé suite à une erreur (comme la réception de une alerte d’erreur). Lorsque l’interne du WebTransport [[WebTransportState]] Transitions de slot vers échoué l’agent utilisateur DOIT exécuter les étapes suivantes:

1. Fermer la ReadableStream dans transport ‘s [[ReceivedStreams]] emplacement interne.

2. Fermer la ReadableStream dans transport ‘ s [[ReceivedBidirectionalStreams]] fente interne .

3. Pour chaque Flux sortant dans transport [[OutgoingStreams]] la fente interne exécute ce qui suit:

   1. Retirer le courant du transport [[OutgoingStreams]] emplacement interne.

7.4. WebTransportCloseInfo Dictionnaire

Le WebTransportCloseInfo dictionnaire comprend des informations relative au code d’erreur pour la fermeture d’un WebTransport . Pour QUIC, cela les informations sont utilisées pour définir le code d’erreur et la raison d’un CONNECTION_CLOSE Cadre.

 dictionnaire   WebTransportCloseInfo   {    non signé court   code d'erreur =0;     DOMString    raison =""; }; 

Le dictionnaire DOIT avoir les attributs suivants:

code d'erreur , de type court non signé , par défaut 0

Le code d’erreur communiqué au pair.

raison , de type DOMSt sonnerie , par défaut à ""

La raison de la fermeture du WebTransport .

7.5. QuicTransportStats Dictionnaire

Le QuicTransportStats le dictionnaire comprend des informations sur les statistiques de niveau de connexion QUIC.

 dictionnaire   QuicTransportStats   {     DOMHighResTimeStamp     horodatage  ;    non signé longue longue    octetsEnvoyé  ;    non signé longue longue    paquets Envoyés  ;    non signé longue    numOutgoingStreamsCreated  ;    non signé longue    numIncomingStreamsCreated  ;    non signé longue longue    octets reçus  ;    non signé longue longue    paquets reçus  ;     DOMHighResTimeStamp     minRtt  ;    non signé longue    numReceivedDatagramsDropped  ; }; 

Le dictionnaire DOIT avoir les attributs suivants:

horodatage , de type DOMHighResTimeStamp

Le horodatage pour quand les statistiques sont recueillies, par rapport à la Époque UNIX (1er janvier 1970, UTC).

octetsEnvoyé , de type non signé long long

Le nombre d’octets envoyés sur la connexion QUIC, y compris retransmissions. N’inclut pas UDP ou tout autre cadrage extérieur.

paquets Envoyés , de type non signé long long

Le nombre de paquets envoyés sur la connexion QUIC, y compris retransmissions.

numOutgoingStreamsCreated , de type non signé long

Le nombre de flux QUIC sortants créés sur la connexion QUIC .

numIncomingStreamsCreated , de type non signé long

Le nombre de flux QUIC entrants créés sur la connexion QUIC .

octets reçus , de type non signé long long

Le nombre total d’octets reçus sur la connexion QUIC, comprenant données en double pour les flux. N’inclut pas UDP ou tout autre cadrage extérieur.

paquets reçus , de type non signé long long

Le nombre total de paquets reçus sur la connexion QUIC, comprenant paquets qui n’étaient pas traitables.

minRtt , de type DOMHighResTimeStamp

Le RTT minimum observé sur l’ensemble de la connexion.

numReceivedDatagramsDropped , de type non signé long

Le nombre de datagrammes qui ont été supprimés, en raison de trop de nombreux datagrammes tamponnés entre les appels au receiveDatagrams () .

8. QuicTransport Interface

Le QuicTransport est un UnidirectionalStreamsTransport , une BidirectionalStreamsTransport , et un DatagramTransport . SendStream le sable ReceiveStream s sont implémentés avec des flux QUIC unidirectionnels tels que définis dans [QUIC-TRANSPORT] . Flux bidirectionnel sont implémentés avec des flux QUIC bidirectionnels comme défini dans [QUIC-TRANSPORT] . Les datagrammes sont implémentés avec des datagrammes QUIC comme défini dans [QUIC-DATAGRAM] .

8.1. Configuration

 dictionnaire   QuicTransportOptions   {   séquence   RTCDtlsFingerprint  >   serverCertificateFingerprints  ; }; 

QuicTransportOptions est un dictionnaire de paramètres qui déterminent comment la connexion QuicTransport est établie et utilisée.

serverCertificateFingerprints , de type séquence RTCDtlsFingerprint >

S’il n’est pas vide, l’agent utilisateur DOIT considérer certificat de serveur approuvé si et seulement si cela peut réussir vérifier une empreinte digitale de certificat contre serverCertificateFingerprints et satisfait Exigences de certificat personnalisé . L’agent utilisateur DOIT ignorer tout empreinte digitale qui utilise un inconnu algorithme ou a un mal formé valeur . S’il est vide, l’agent utilisateur DOIT utiliser les procédures de vérification des certificats qu’il utiliserait pour la normale récupérer les opérations .

Le exigences de certificat personnalisé sont les suivants: le certificat DOIT être un certificat X.509v3 tel que défini dans [RFC5280] , l’heure actuelle DOIT être dans la période de validité du certificat tel que défini dans la section 4.1.2.5 de [RFC5280] et la durée totale de la période de validité NE DOIT PAS dépasser deux semaines.

Réexaminez la période ci-dessus. Nous voulons qu’il soit suffisamment grand que les applications qui l’utilisent pour les certificats éphémères peuvent le faire sans avoir à lutter contre le décalage horaire, mais suffisamment petit pour décourager une utilisation à long terme sans rotation des touches.

8.2. Définition de l’interface

 [Exposed=(Window,Worker)] interface   QuicTransport   {     constructeur   (  USVString      URL   , optionnel   QuicTransportOptions      options   ={});   Promettre   QuicTransportStats  >   getStats   (); };    QuicTransport    comprend    UnidirectionalStreamsTransport  ;   QuicTransport    comprend    BidirectionalStreamsTransport  ;   QuicTransport    comprend    DatagramTransport  ;   QuicTransport    comprend    WebTransport  ; 

Quand le QuicTransport () constructeur est invoqué, l’utilisateur l’agent DOIT exécuter les étapes suivantes:

1. Laisser parsedURL Soit le Enregistrement d’URL résultant de analyse de URL .

2. Si parsedURL est un échec, jeter une Erreur de syntaxe exception.

3. Si parsedURL schème n’est pas quic-transport , jeter une Erreur de syntaxe exception.

4. Si parsedURL fragment est non nulle, jeter une Erreur de syntaxe exception.

5. Laisser transport être nouvellement construit QuicTransport objet.

6. Laisser transport avoir un [[OutgoingStreams]] fente interne représentant une séquence de Flux sortant objets, initialisés à vider.

7. Laisser transport avoir un [[ReceivedStreams]] fente interne représentant un ReadableStream de IncomingStream objets, initialisés à vider.

8. Laisser transport avoir un [[ReceivedBidirectionalStreams]] emplacement interne représentant un ReadableStream de Flux entrant objets, initi alizé pour vider.

9. Laisser transport avoir un [[WebTransportState]] interne emplacement, initialisé à "de liaison".

10. Laisser transport avoir un [[SentDatagrams]] fente interne représentant un WritableStream de Uint8Array s, initialisé à vide.

11. Laisser transport avoir un [[ReceivedDatagrams]] interne emplacement représentant un ReadableStream de Uint8Array s, initialisé à vide.

12. Exécutez ces étapes en parallèle:

    1. Laisser clientOrigin être transport ‘ s objet de paramètres pertinents [QUIC-TRANSPORT] origine, sérialisé .

    2. Établissez une connexion QUIC à l’adresse identifiée par parsedURL en suivant les procédures de [WEB-TRANSPORT-QUIC] section 3 et en utilisant clientOrigin comme « origine du client » référencée dans la section 3.2. 1. Lors de l’établissement de la connexion, suivez tous les paramètres spécifié dans le options .

    3. Si la connexion échoue, réglez transport ‘ s [[WebTransportState]] emplacement interne à "échoué" et abandonner ces étapes .

    4. Ensemble transport ‘s [[WebTransportState]] emplacement interne à "lié".

13. Revenir transport.

8.3. Méthodes

getStats ()

Recueille des statistiques pour cela QuicTransport est QUIC connexion et rapporte le résultat de manière asynchrone.

Lorsque close est appelé, l’agent utilisateur DOIT exécuter le Etapes suivantes:

1. Laisser transport être le QuicTransport sur lequel getStats est invoqué.

2. Laisser p soit une nouvelle promesse.

3. Revenir p et continuez les étapes suivantes dans Contexte.

   1. Rassemblez les statistiques de la connexion QUIC sous-jacente.

   2. Une fois les statistiques recueillies, résolvez p avec le QuicTransportStats , représentant les statistiques recueillies.

9. Interface Mixin Flux sortant

Une Flux sortant est un flux qui peut être écrit, comme soit un SendStream ou un BidirectionalStream .

 [ Exposed=(Window,Worker) ] interface  mixin    Flux sortant   {   lecture seulement attribut   WritableStream     inscriptible  ;   lecture seulement attribut Promettre   StreamAbortInfo  >   écrit Avorté  ;   néant   abortWriting   (optionnel   StreamAbortInfo      abortInfo    ={}); }; 

9.1. Aperçu

Le Flux sortant s’initialise avec ce qui suit:

1. Laisser courant Soit le Flux sortant .

2. Laisser courant avoir un [[Writable]] slot interne initialisé sur un nouveau WritableStream .

9.2. Les attributs

inscriptible , de type WritableStream , en lecture seule

Le inscriptible l’attribut représente un WritableStream (d’octets) pouvant être utilisé pour écrire au Flux sortant . Une fois obtenu, il DOIT retourner le valeur de [[Writable]] fente.

écrit Avorté , de type Promise StreamAbortInfo >, en lecture seule

Le écritAvorté attribut représente une promesse que est rempli lorsqu’un message du côté distant interrompant le flux est reçu. Pour QUIC, ce message est une trame STOP_SENDING. Lorsque le flux reçoit ce message, l’agent utilisateur DOIT exécuter ce qui suit:

1. Laisser courant Soit le OutgoingStream objet.

2. Laisser transport Soit le WebTransport , lequel à courant a été créé de.

3. Supprimer le flux du transport ‘s [[OutgoingStreams]] fente interne.

4. Résoudre la promesse avec le résultat StreamAbortInfo avec les code d'erreur réglé sur la valeur de l’avortement message du côté distant.

9.3. Méthodes

abortWriting ()

Un arrêt dur du Flux sortant . Il peut être appelé indépendamment de si le Flux sortant a été créé par l’homologue local ou distant. Quand les abortWriting est appelée, l’agent utilisateur DOIT exécuter ce qui suit pas:

1. Laisser courant Soit le Flux sortant objet qui est sur le point d’avorter l’écriture.

2. Laisser transport Soit le WebTransport , lequel les courant a été créé de.

3. Retirez le flux du transport [[OutgoingStreams]] interne fente.

4. Laisser abortInfo sera le premier argument.

5. Démarrez la procédure de fermeture en envoyant une trame RST_STREAM avec son code d’erreur défini sur la valeur de | abortInfo.errorCode |.

9.4. StreamAbortInfo Dictionnaire

Le StreamAbortInfo dictionnaire comprend des informations relatif au code d’erreur pour abandonner un flux entrant ou sortant. (Pour QUIC, dans une trame RST_STREAM ou une trame STOP_SENDING).

 dictionnaire   StreamAbortInfo   {    non signé court    code d'erreur =0; }; 

Le dictionnaire DOIT avoir les champs suivants:

code d'erreur , de type court non signé , par défaut 0

Le code d’erreur. La valeur par défaut de 0 signifie « FERMETURE ».

dix. Interface Mixin IncomingStream

Une IncomingStream est un flux qui peut être lu depuis , comme soit un ReceiveStream ou un BidirectionalStream .

 [ Exposed=(Window,Worker) ] interface  mixin    Flux entrant   {   lecture seulement attribut   ReadableStream    lisible ;   lecture seulement attribut Promettre   StreamAbortInfo  >   lectureAvorté  ;   néant   avortReading   (optionnel   StreamAbortInfo      abortInfo    ={});   Promettre   ArrayBuffer  >   arrayBuffer   (); }; 

10.1. Aperçu

Le IncomingStream s’initialise avec ce qui suit:

1. Laisser courant Soit le IncomingStream .

2. Laisser courant avoir un [[Readable]] slot interne initialisé sur un nouveau ReadableStream .

10.2. Les attributs

lisible , de type ReadableStream , lecture seulement

Le lisible l’attribut représente un ReadableStream qui peut être utilisé pour lire à partir du Flux entrant . Une fois obtenu, il DOIT retourner le valeur de Flux entrant [HTML] [[Readable]] fente.

lectureAvorté , de type Promise StreamAbortInfo >, en lecture seule

Le lectureAvorté attribut représente une promesse que est rempli lorsque le message du côté distant est abandonné le flux est reçu. Pour QUIC, ce message est une trame RST_STREAM. Lorsque le flux reçoit ce message, l’agent utilisateur DOIT exécuter ce qui suit:

1. Laisser courant Soit le IncomingStream objet pour lequel l’avortement message a été reçu.

2. Laisser transport Soit le WebTransport , lequel à courant a été créé de.

3. Résoudre la promesse avec le résultat StreamAbortInfo avec les code d'erreur mis à la valeur de l’abandon message du côté distant.

10.3. Méthodes

abortReading ()

Un arrêt dur du Flux entrant . Il peut être appelé indépendamment de si le Flux entrant a été créé par le pair local ou distant. Quand les abortWriting est appelée, l’agent utilisateur DOIT exécuter ce qui suit pas:

1. Laisser courant Soit le Flux entrant objet sur le point d’abandonner en train de lire.

2. Laisser transport Soit le WebTransport , lequel à courant a été créé de.

3. Laisser abortInfo sera le premier argument.

4. Démarrez la procédure de fermeture en envoyant un message à la télécommande côté indiquant que le flux a été abandonné (pour QUIC, il s’agit d’un Cadre STOP_SENDING) avec son code d’erreur défini sur la valeur de | abortInfo.errorCode |.

arrayBuffer ()

Une méthode pratique qui lit de manière asynchrone tout le contenu de | IncomingStream.readable | et le renvoie comme un ArrayBuffer. Cela verrouille le diffuser pendant la lecture, comme si | IncomingStream.readable.getReader () | étaient utilisé.

11. Interface BidirectionalStream

 [ Exposed=(Window,Worker) ] interface    BidirectionalStream    { };   Flux bidirectionnel    comprend    Flux sortant  ;   Flux bidirectionnel    comprend    Flux entrant  ; 

12. Interface SendStream

 [ Exposed=(Window,Worker) ] interface    SendStream    { };   SendStream    comprend    Flux sortant  ; 

13. Interface ReceiveStream

 [ Exposed=(Window,Worker) ] interface    ReceiveStream    { };   ReceiveStream    comprend    Flux entrant  ; 

14. Http3Transport Interface

14.1. Aperçu

Une Http3Transport est un UnidirectionalStreamsTransport , une BidirectionalStreamsTransport , et un DatagramTransport . SendStream s, ReceiveStream le sable Flux bidirectionnel s sont implémenté avec des flux HTTP / 3 comme défini dans [WEB-TRANSPORT-HTTP3] . Les datagrammes sont implémentés avec des datagrammes QUIC tels que définis dans [WEB-TRANSPORT-HTTP3] .

14.2. Définition de l’interface

 [Exposed=(Window,Worker)] interface   Http3Transport   {     constructeur   (  DOMString      url    ); };    Http3Transport    comprend    UnidirectionalStreamsTransport  ;   Http3Transport    comprend    BidirectionalStreamsTransport  ;   Http3Transport    comprend    DatagramTransport  ;   Http3Transport    comprend    WebTransport  ; 

14.2. 1. Constructeurs

Quand le Http3Transport () constructeur est invoqué, l’utilisateur l’agent DOIT exécuter les étapes suivantes:

1. Laisser transport être nouvellement construit Http3Transport objet avec état « de liaison ».

2. Laisser transport avoir un [[OutgoingStreams]] slo interne t représentant une séquence de Flux sortant objets, initialisés à vide.

3. Laisser transport avoir un [[ReceivedStreams]] fente interne représentant un ReadableStream de Flux entrant objets, initialisés à vider.

4. Laisser transport avoir un [[ReceivedBidirectionalStreams]] sl interne ot représentant un ReadableStream de Flux entrant objets, initialisés pour être vides.

5. Laisser transport avoir un [[SentDatagrams]] interna fente représentant un WritableStream de Uint8Array s, initialisé à vide.

6. Laisser transport avoir un [[ReceivedDatagrams]] int éternel emplacement représentant un ReadableStream de Uint8Array s, initialisé à vide.

7. Exécutez ces étapes en parallèle:

   1. Établir une connexion HTTP / 3 ou réutiliser une connexion existante HTTP / 3 connexion à l’hôte spécifié par l’url, comme spécifié dans [WEB-TRANSPORT-HTTP3] .

   2. S’il n’y a pas une telle connexion HTTP / 3 à réutiliser et la création de une nouvelle connexion HTTP / 3, définissez transport [[WebTransportState]] emplacement interne pour "échoué" et abandonnez ces étapes.

   3. Une fois la connexion établie, une connexion HTTP / 3 est établie, suis les étapes spécifié dans [WEB-TRANSPORT-HTTP3] section 4 pour l’établissement d’un Session WebTransport dans la connexion HTTP / 3.

   4. Si l’établissement de la session WebTransport échoue, définissez les paramètres de transport [[WebTransportState]] emplacement interne à "échoué" et abandonner celles-ci pas.

   5. Une fois la session établie, réglez transport [[WebTransportState]] emplacement interne à "lié" et abandonner ces pas.

8. Revenir transport.

15. Considérations sur la confidentialité et la sécurité

Cette section n’est pas normative; il ne spécifie aucun nouveau comportement, mais à la place résume les informations déjà présentes dans d’autres parties de la spécification.

15.1. Confidentialité des communications

Le fait que la communication ait lieu ne peut pas être caché à adversaires qui peut observer le réseau, cela doit donc être considéré comme une information publique.

Tous les protocoles de transport décrits dans ce document utilisent soit TLS [RFC8446] ou un protocole sémantiquement équivalent, fournissant ainsi tous les propriétés de sécurité de TLS, y compris la confidentialité et l’intégrité du circulation. QuicTransport et Http3Transport utilisent le même certificat mécanisme de vérification en tant que requêtes HTTP sortantes, reposant ainsi sur le même infrastructure à clé publique pour l’authentification du serveur distant. Dans WebTransport, les erreurs de vérification de certificat sont fatales; pas d’interstitiel permettant de contourner la validation du certificat est disponible.

15.2. Persistance de l’état

WebTransport ne crée pas en soi de nouveaux identifiants uniques ou de nouvelles façons pour stocker l’état de manière persistante, et il n’expose pas automatiquement état persistant existant sur le serveur. Par exemple, aucun des transports défini dans ce document envoie automatiquement des cookies, supporte HTTP mécanismes d’authentification ou de mise en cache d’invalidation. Puisqu’ils utilisent TLS, ils peuvent prendre en charge les tickets de session TLS, qui pourraient être utilisés par le serveur (mais pas par observateurs de réseaux passifs) pour corréler différentes connexions à partir du même client. Ce n’est pas spécifique à WebTransport en soi, mais plutôt inhérent propriété de tous les protocoles basés sur TLS; ainsi, ceci est hors de portée pour cette spécification.

15.3. Sécurité du protocole

WebTransport impose un ensemble d’exigences communes à tous les protocoles, décrit dans [WEB-TRANSPORT-OVERVIEW] . Les plus notables incluent:

1. Tous les transports doivent s’assurer que le serveur distant sait que les la connexion en question provient d’une application Web; Ceci est nécessaire pour empêcher les attaques entre protocoles. Les transports basés sur QUIC utilisent ALPN [RFC7301] Dans ce but.

2. Tous les transports doivent permettre au serveur de filtrer les connexions en fonction de les origine de la ressource à l’origine de la session de transport.

3. Tous les transports nécessitent que les agents utilisateurs vérifient continuellement que le serveur est toujours intéressé à leur parler (concept communément appelé «consentement Fraîcheur »).

Les considérations de sécurité du protocole liées aux transports individuels sont décrit dans les Considérations de sécurité des sections correspondantes documents de protocole, [WEB-TRANSPORT-QUIC] et [WEB-TRANSPORT-HTTP3] .

Les API de mise en réseau peuvent être couramment utilisées pour analyser le réseau local pour disponible hôtes, et donc être utilisé pour les empreintes digitales et d’autres formes d’attaques. WebTransport suit le WebSocket approche à ce problème: l’erreur de connexion spécifique n’est renvoyée que une le point de terminaison est vérifié comme étant un point de terminaison WebTransport; ainsi, l’application Web ne peut pas faire la distinction entre un point de terminaison inexistant et le point de terminaison qui n’est pas prêt à accepter les connexions du Web.

16. Exemples

16.1. Envoi d’un tampon de datagrammes

Cette section n’est pas normative.

L’envoi d’un tampon de datagrammes peut être réalisé en utilisant le sendDatagrams () méthode. Dans l’exemple suivant les datagrammes ne sont envoyés que si DatagramTransport est prêt à envoyer.

   const  transport = getTransport  () ;   const  écrivain = transport.  sendDatagrams  ().  getWriter  ();   const  datagrammes = getDatagramsToSend  ();  datagrammes . pour chaque (( datagramme )  =>   {   attendre l'écrivain . prêt;    écrivain. écrire ( datagramme );  });  

16.2. Envoi de datagrammes à un taux fixe

Cette section n’est pas normative.

Envoi de datagrammes à un taux fixe peu importe si le transport est prêt à envoyer peut être réalisé en utilisant simplement sendDatagrams () et pas en utilisant le prêt attribut. Des scénarios plus complexes peuvent utiliser le prêt attribut.

   // Envoie des datagrammes toutes les 100 ms.   const  transport = getTransport  ();   const  écrivain = transport.  sendDatagrams  ().  getWriter  ();  setInterval  (()  =>   {   écrivain. écrire ( createDatagram  ());  },   100  );  

16,3 . Réception de datagrammes

Cette section n’est pas normative.

La réception des datagrammes peut être obtenue en appelant receiveDatagrams () , rappelant de vérifier la valeur null valeurs indiquant que les paquets ne sont pas traités assez rapidement.

   const  transport = getTransport  ();   const  lecteur = transport.  recevoir des diagrammes  ().  getReader  ();  tandis que  ( vrai )   {    const   {valeur:  datagramme ,  terminé}  = attendent le lecteur . lis () ;    si  (terminé)   {      Pause ;    }     // Traite les données  }  

16.4. Réception de ReceiveStream

Cette section n’est pas normative.

La lecture à partir de ReceiveStreams peut être réalisée en appelant receiveStreams () , puis obtenir le lecteur pour chacun ReceiveStream .

   const  transport = getTransport  ();   const  receiveStreamReader = transport.  receiveStreams  () .  getReader  ();  tandis que  ( vrai )   {    const   {valeur:  receiveStream ,  terminé:  readingReceiveStreamsDone }  =       attendre recevoirStreamReader . lis ();    si  ( readingReceiveStreamsDone )   {     Pause ;    }     // Traite les flux de réception créés par le point de terminaison distant.     const  chunkReader = receiveStream . lisible.  getReader  ();    tandis que  ( vrai )   {      const   {valeur:  tronçon,  terminé:  lecture de morceaux terminés }  = attendent chunkReader . lis ();      si  ( lecture ChunksDone )   {       Pause ;      }      processTheData  (tronçon);    }  }  

17. Remerciements

Les éditeurs souhaitent remercier les présidents des groupes de travail et l’équipe de contact, Harald Alvestrand, Stefan Håkansson, Bernard Aboba et Dominique Hazaël-Massieux, pour leur soutien. Contributions à cette spécification ont été fournis par Robin Raymond.

Le QuicTransport et QuicStream Les objets ont été initialement décrits dans le W3C ORTC CG , et ont été adaptés pour utiliser dans cette spécification.