Les avantages de la frappe forte en C ++: expérience pratique

Notre programme traite les paquets réseau, en particulier les en-têtes TCP / IP / etc. Dans ceux-ci, les valeurs numériques - décalages, compteurs, adresses - sont présentées dans l'ordre des octets du réseau (big-endian); nous travaillons sur x86 (little-endian). Dans les structures standard décrivant les en-têtes, ces champs sont représentés par des types entiers simples ( uint32_t , uint16_t ). Après plusieurs bugs dus au fait que nous avons oublié de convertir l'ordre des octets, nous avons décidé de remplacer les types de champs par des classes qui interdisent les conversions implicites et les opérations atypiques. Sous la coupe se trouve un code utilitaire et des exemples spécifiques d'erreurs que le typage strict a révélé.

Ordre des octets

Likbez pour ceux qui ne connaissent pas l'ordre des octets (endianness, ordre des octets). Plus en détail était déjà sur "Habré" .

Dans la notation habituelle des nombres, ils vont du plus ancien (gauche) au plus jeune (droite) à gauche: 432 ₁₀ = 4 × 10 ² + 3 × 10 ¹ + 2 × 10 ⁰ . Les types de données entiers ont une taille fixe, par exemple 16 bits (nombres de 0 à 65535). Ils sont stockés en mémoire sous la forme de deux octets, par exemple, 432 ₁₀ = 01b0 ₁₆ , c'est-à-dire les octets 01 et b0.

Imprimez les octets de ce numéro:

 #include <cstdio> // printf() #include <cstdint> // uint8_t, uint16_t int main() { uint16_t value = 0x01b0; printf("%04x\n", value); const auto bytes = reinterpret_cast<const uint8_t*>(&value); for (auto i = 0; i < sizeof(value); i++) { printf("%02x ", bytes[i]); } } 

Sur les processeurs Intel ou AMD (x86) ordinaires, nous obtenons ce qui suit:

 01b0 b0 01 

Les octets en mémoire sont situés du plus jeune au plus ancien, et non comme lors de l'écriture de nombres. Cet ordre est appelé little-endian (LE). Il en va de même pour les nombres à 4 octets. L'ordre des octets est déterminé par l'architecture du processeur. L'ordre «natif» du processeur est également appelé ordre du CPU ou de l'hôte (ordre des octets CPU / hôte). Dans notre cas, l'ordre des octets de l'hôte est petit-endien.

Cependant, Internet n'est pas né sur x86, et l'ordre des octets était différent - du plus ancien au plus jeune (big-endian, BE). Ils ont commencé à l'utiliser dans les en-têtes des protocoles réseau (IP, TCP, UDP), donc le big-endian est également appelé l' ordre des octets du réseau.

Exemple: le port 443 (1bb ₁₆ ), qui utilise HTTPS, est écrit dans les en-têtes TCP octets bb 01, qui en lecture donneront bb01 ₁₆ = 47873.

 //  uint16_t  uint32_t     . struct tcp_hdr { uint16_t th_sport; uint16_t th_dport; uint32_t th_seq; uint32_t th_ack; uint32_t th_flags2 : 4; uint32_t th_off : 4; uint8_t th_flags; uint16_t th_win; uint16_t th_sum; uint16_t th_urp; } __attribute__((__packed__)); tcp_hdr* tcp = ...; //      // : dst_port  BE,  443  LE. if (tcp->dst_port == 443) { ... } // : ++  LE,  sent_seq  BE. tcp->sent_seq++; 

L'ordre des octets d'un nombre peut être converti. Par exemple, pour uint16_t il existe une fonction standard htons() ( h ost to n etwork for s hort integer - from host order to network order for short integers) and the reverse ntohs() . De même, pour uint32_t il y a htonl() et ntohl() (long est un entier long).

 // :  BE    BE . if (tcp->dst_port == htons(443)) { ... } //   BE     LE,   1, //   LE    BE. tcp->sent_seq = htonl(ntohl(tcp->sent_seq) + 1); 

Malheureusement, le compilateur ne sait pas d'où provient la valeur spécifique d'une variable de type uint32_t et ne vous avertit pas si vous mélangez des valeurs avec des ordres d'octets différents et obtenez un résultat incorrect.

Typage fort

Le risque de confondre l'ordre des octets est évident, comment y faire face?

• Révision du code. Il s'agit d'une procédure obligatoire dans notre projet. Malheureusement, les testeurs veulent surtout se plonger dans le code qui manipule les octets: "Je vois htons() - probablement, l'auteur a pensé à tout".
• Discipline, règles comme: BE uniquement dans les packages, toutes les variables dans LE. Il n'est pas toujours raisonnable, par exemple, si vous devez vérifier les ports par rapport à une table de hachage, il est plus efficace de les stocker dans l'ordre des octets du réseau et de rechercher «tels quels».
• Tests. Comme vous le savez, ils ne garantissent pas l'absence d'erreurs. Les données peuvent être mal appariées (1.1.1.1 ne change pas lors de la conversion de l'ordre des octets) ou ajustées au résultat.

Lorsque vous travaillez avec un réseau, vous ne pouvez pas ignorer l'ordre des octets, donc je voudrais qu'il soit impossible de l'ignorer lors de l'écriture de code. De plus, nous n'avons pas seulement un numéro en BE - c'est un numéro de port, une adresse IP, un numéro de séquence TCP, une somme de contrôle. Un ne peut pas être affecté à un autre, même si le nombre de bits correspond.

La solution est connue - typage strict, c'est-à-dire types distincts pour les ports, les adresses et les numéros. De plus, ces types doivent prendre en charge la conversion BE / LE. Boost.Endian ne nous convient pas, car il n'y a pas de Boost dans le projet.

La taille du projet est d'environ 40 000 lignes en C ++ 17. Si vous créez des types d'encapsuleurs sûrs et écrasez les structures d'en-tête dessus, tous les endroits où il y a du travail avec BE arrêteront automatiquement la compilation. Vous devrez les parcourir tous une fois, mais le nouveau code ne sera sûr.

• Un fichier d'en-tête avec ce type sera inclus partout, donc au lieu d'un <iostream> lourd, un <iosfwd> léger <iosfwd> .
• Au lieu de htons() , etc. - intrinsèque rapide du compilateur. En particulier, ils sont constexpr une propagation constante, donc des constructeurs constexpr .
• Parfois, il existe déjà une valeur uint16_t / uint32_t située dans BE. La structure Raw<T> avec le guide de déduction vous permet de créer facilement un BigEndian<T> partir de celle-ci.

Le point controversé ici est PACKED : les structures packagées sont considérées comme moins optimisables. La seule réponse est de mesurer. Nos benchmarks de code n'ont révélé aucun ralentissement. De plus, dans le cas des paquets réseau, la position des champs dans l'en-tête est toujours fixe.

Dans la plupart des cas, BE n'a besoin d'aucune opération autre que la comparaison. Les numéros de séquence doivent être pliés correctement avec LE:

 using BE16 = BigEndian<uint16_t>; using BE32 = BigEndian<uint32_t>; struct Seqnum : BE32 { using BE32::BE32; template<typename Integral> Seqnum operator+(Integral increment) const { static_assert(std::is_integral_v<Integral>); return Seqnum{static_cast<uint32_t>(native() + increment)}; } } PACKED; struct IP : BE32 { using BE32::BE32; } PACKED; struct L4Port : BE16 { using BE16::BE16; } PACKED; 

• TCPFlag pourrait être transformé en enum class , mais en pratique, seules deux opérations sont effectuées sur les indicateurs: vérifier l'entrée ( & ) ou remplacer les indicateurs par une combinaison ( | ) - il n'y a pas de confusion.
• Les champs de bits restent primitifs, mais des méthodes d'accès sécurisées sont créées.
• Les noms de champs restent classiques.

Résultats

La plupart des modifications ont été triviales. Le code est plus propre:

  auto tcp = packet->tcp_header(); - return make_response(packet, - cookie_make(packet, rte_be_to_cpu_32(tcp->th_seq)), - rte_cpu_to_be_32(rte_be_to_cpu_32(tcp->th_seq) + 1), - TH_SYN | TH_ACK); + return make_response(packet, cookie_make(packet, tcp->th_seq.native()), + tcp->th_seq + 1, TH_SYN | TH_ACK); } 

En partie, les types ont documenté le code:

 - void check_packet(int64_t, int64_t, uint8_t, bool); + void check_packet(std::optional<Seqnum>, std::optional<Seqnum>, TCPFlags, bool); 

Du coup, il s'est avéré que vous ne pouviez pas lire correctement la taille de la fenêtre TCP, alors que les tests unitaires passeraient et même le trafic serait poursuivi:

  //  window size auto wscale_ratio = options().wscale_dst - options().wscale_src; if (wscale_ratio < 0) { - auto window_size = header.window_size() / (1 << (-wscale_ratio)); + auto window_size = header.window_size().native() / (1 << (-wscale_ratio)); if (header.window_size() && window_size < 1) { window_size = WINDOW_SIZE_MIN; } header_out.window_size(window_size); } else { - auto window_size = header.window_size() * (1 << (wscale_ratio)); + auto window_size = header.window_size().native() * (1 << (wscale_ratio)); if (window_size > WINDOW_SIZE_MAX) { window_size = WINDOW_SIZE_MAX; } 

Exemple d'erreur logique: le développeur du code d'origine pensait que la fonction acceptait BE, bien qu'en fait ce ne soit pas le cas. Lorsque vous essayez d'utiliser Raw{} au lieu de 0 programme n'a tout simplement pas compilé (heureusement, ce n'est qu'un test unitaire). On voit immédiatement un choix de données infructueux: l'erreur aurait été trouvée plus tôt si elle n'avait pas été utilisée 0, ce qui est le même dans n'importe quel ordre d'octets.

 - auto cookie = cookie_make_inner(tuple, rte_be_to_cpu_32(0)); + auto cookie = cookie_make_inner(tuple, 0); 

Un exemple similaire: tout d'abord, le compilateur a souligné l'inadéquation entre les types def_seq et cookie , puis il est devenu clair pourquoi le test a réussi plus tôt - de telles constantes.

 - const uint32_t def_seq = 0xA7A7A7A7; - const uint32_t def_ack = 0xA8A8A8A8; + const Seqnum def_seq{0x12345678}; + const Seqnum def_ack{0x90abcdef}; ... - auto cookie = rte_be_to_cpu_32(_tcph->th_ack); + auto cookie = _tcph->th_ack; ASSERT_NE(def_seq, cookie); 

Résumé

L'essentiel est:

• Trouvé un bogue et plusieurs erreurs logiques dans les tests unitaires.
• Le refactoring m'a fait trier les endroits douteux, la lisibilité a augmenté.
• Les performances ont été préservées, mais auraient pu diminuer - des repères sont nécessaires.

Les trois points sont importants pour nous, nous pensons donc que le refactoring en valait la peine.

Vous assurez-vous contre les erreurs de types stricts?