La réponse à cette question pourrait éventuellement être "ça dépend", et alors ma question devient "de quoi dépend-elle?" et "que faut-il faire pour qu'ils soient reçus dans l'ordre?".Les appels à SSL_read sont-ils garantis pour consommer les messages dans l'ordre où ils ont été envoyés?
Oui. TLS fonctionne sur TCP qui garantit l'ordre des octets du flux, et, comme le note @ dave_thompson_085 ci-dessous, TLS fournit la numérotation des séquences d'enregistrement et échouera le transfert s'il détecte une erreur de séquence. Avec tout ce qui est en dessous des niveaux d'enregistrement octet et TLS, vous n'avez rien à faire concernant le séquençage des messages au niveau du protocole d'application.
TCP fournit un flux malgré les erreurs «naturelles» mais peut être vaincu par un adversaire intelligent; SSL/TLS ajoute un MAC qui inclut une séquence d'enregistrement (en pseudo-en-tête) pour éviter cela (avec une probabilité écrasante). Mais notez qu'un flux (TCP ou SSL/TLS) ne fournit que des octets _not_ délimités 'messages'; les protocoles/formats supérieurs qui nécessitent des limites de message doivent les ajouter. –
Notez que la réponse est différente si vous utilisez DTLS au lieu de TLS. Dans DTLS, les messages peuvent être réorganisés (mais vous utilisez toujours SSL_read()). –