👩🏿‍⚖️ 👴🏿 👧🏻 C ++ में मजबूत टाइपिंग के लाभ: हाथों पर अनुभव 🎫 👩‍🔬 👩🏼‍⚖️

हमारे कार्यक्रम नेटवर्क पैकेट को संसाधित करते हैं, विशेष रूप से, टीसीपी / आईपी / आदि हेडर। उनमें, संख्यात्मक मान - ऑफ़सेट, काउंटरर्स, एड्रेस - नेटवर्क बाइट ऑर्डर (बिग-एंडियन) में प्रस्तुत किए जाते हैं; हम x86 (थोड़ा-सा एंडियन) पर काम कर रहे हैं। हेडर का वर्णन करने वाले मानक संरचनाओं में, इन क्षेत्रों को सरल पूर्णांक प्रकारों ( uint32_t , uint16_t ) द्वारा दर्शाया जाता है। इस तथ्य के कारण कि हम बाइट क्रम को परिवर्तित करना भूल गए, हमने कई प्रकारों के बाद, फ़ील्ड प्रकारों को उन वर्गों के साथ बदलने का फैसला किया जो अंतर्निहित रूपांतरण और असामान्य संचालन को रोकते हैं। कट के तहत एक उपयोगितावादी कोड और त्रुटियों के विशिष्ट उदाहरण हैं जो सख्त टाइपिंग से पता चला है।

बाइट क्रम

जो लोग बाइट ऑर्डर (एंडियननेस, बाइट ऑर्डर) के बारे में नहीं जानते हैं, उनके लिए लाइकबेज़। पहले से ही अधिक विस्तार में "हैबे" पर था ।

संख्याओं के सामान्य अंकन में, वे सबसे पुराने (बाएं) से सबसे युवा (दाएं) से बाईं ओर जाते हैं: 432 ₁₀ = 4 × 10 ² + 3 × 10 ¹ + 2 × 10 ⁰ । पूर्णांक डेटा प्रकारों का एक निश्चित आकार होता है, उदाहरण के लिए, 16 बिट्स (0 से 65535 तक की संख्या)। उन्हें मेमोरी में दो बाइट्स के रूप में संग्रहीत किया जाता है, उदाहरण के लिए, 432 ₁₀ = 01b0 ₁₆ , यानी बाइट्स 01 और b0।

इस नंबर के बाइट्स प्रिंट करें:

 #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]); } }

साधारण इंटेल या AMD (x86) प्रोसेसर पर, हमें निम्नलिखित मिलते हैं:

 01b0 b0 01

स्मृति में बाइट्स सबसे कम उम्र से सबसे पुराने तक स्थित हैं, और संख्या लिखते समय नहीं। इस आदेश को लिटिल-एंडियन (LE) कहा जाता है । 4-बाइट संख्याओं के लिए भी यही सच है। बाइट ऑर्डर प्रोसेसर आर्किटेक्चर द्वारा निर्धारित किया जाता है। प्रोसेसर के लिए "देशी" ऑर्डर को सीपीयू या होस्ट (सीपीयू / होस्ट बाइट ऑर्डर) का आदेश भी कहा जाता है । हमारे मामले में, मेजबान बाइट ऑर्डर थोड़ा-सा है।

हालाँकि, इंटरनेट x86 पर पैदा नहीं हुआ था, और वहाँ बाइट क्रम अलग था - सबसे पुराने से सबसे कम उम्र (बड़ा-एंडियन, बीई) से। उन्होंने इसका उपयोग नेटवर्क प्रोटोकॉल (आईपी, टीसीपी, यूडीपी) के हेडर में करना शुरू किया, इसलिए बड़े-एंडियन को नेटवर्क बाइट ऑर्डर भी कहा जाता है ।

उदाहरण: पोर्ट 443 (1bb ₁₆ ), जो HTTPS का उपयोग करता है, टीसीपी हेडर बाइट्स 01 में लिखा गया है, जो पढ़ने पर 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++;

किसी संख्या के बाइट क्रम को परिवर्तित किया जा सकता है। उदाहरण के लिए, uint16_t लिए एक मानक फ़ंक्शन htons() ( h ost से n etwork for s hort पूर्णांक - शॉर्ट ऑर्डर के लिए होस्ट ऑर्डर से नेटवर्क ऑर्डर तक) और इसके लिए रिवर्स ntohs() । इसी तरह, uint32_t लिए htonl() और ntohl() (लंबे समय तक एक पूर्णांक है)।

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

दुर्भाग्य से, कंपाइलर को यह नहीं पता है कि uint32_t प्रकार के वैरिएबल का विशिष्ट मान कहां से आया है, और यदि आप अलग-अलग बाइट ऑर्डर के साथ मूल्यों को मिलाते हैं और गलत परिणाम प्राप्त करते हैं तो चेतावनी नहीं देते हैं।

मजबूत टाइपिंग

बाइट ऑर्डर को भ्रमित करने का जोखिम स्पष्ट है, इससे कैसे निपटें?

कोड समीक्षा। यह हमारी परियोजना में एक अनिवार्य प्रक्रिया है। दुर्भाग्य से, सभी परीक्षक कम से कम उस कोड में तल्लीन करना चाहते हैं जो बाइट्स में हेरफेर करता है: "मैं htons() देखता htons() - शायद, लेखक ने सब कुछ के बारे में सोचा था"।
अनुशासन, नियम जैसे: संकुल में केवल BE, LE में सभी चर। यह हमेशा उचित नहीं होता है, उदाहरण के लिए, यदि आपको हैश टेबल के खिलाफ बंदरगाहों की जांच करने की आवश्यकता है, तो उन्हें नेटवर्क बाइट क्रम में संग्रहीत करना और "जैसा है" खोजना अधिक कुशल है।
टेस्ट। जैसा कि आप जानते हैं, वे त्रुटियों की अनुपस्थिति की गारंटी नहीं देते हैं। डेटा खराब रूप से मिलान किया जा सकता है (बाइट ऑर्डर को परिवर्तित करते समय 1.1.1.1 नहीं बदलता है) या परिणाम में समायोजित किया जाता है।

नेटवर्क के साथ काम करते समय, आप बाइट ऑर्डर को अनदेखा नहीं कर सकते हैं, इसलिए मैं कोड लिखते समय इसे अनदेखा करना असंभव बनाना चाहूंगा। इसके अलावा, हमारे पास बीई में एक नंबर नहीं है - यह एक पोर्ट नंबर, आईपी एड्रेस, टीसीपी अनुक्रम संख्या, चेकसम है। एक को दूसरे को नहीं सौंपा जा सकता है, भले ही बिट्स की संख्या मेल खाती हो।

समाधान ज्ञात है - सख्त टाइपिंग, अर्थात्, बंदरगाहों, पते, संख्याओं के लिए अलग-अलग प्रकार। इसके अलावा, इन प्रकारों को BE / LE रूपांतरण का समर्थन करना चाहिए। Boost.Endian हमें शोभा नहीं देता, क्योंकि प्रोजेक्ट में Boost नहीं है।

परियोजना का आकार C ++ 17 में लगभग 40 हजार लाइनें है। यदि आप सुरक्षित आवरण प्रकार बनाते हैं और उन पर हेडर संरचनाओं को अधिलेखित करते हैं, तो बीई के साथ काम करने वाले सभी स्थान स्वचालित रूप से संकलन बंद कर देंगे। आपको उन सभी के माध्यम से एक बार जाना होगा, लेकिन नया कोड केवल सुरक्षित होगा।

बिग-एंडियन वर्ग संख्या

 #include <cstdint> #include <iosfwd> #define PACKED __attribute__((packed)) constexpr auto bswap(uint16_t value) noexcept { return __builtin_bswap16(value); } constexpr auto bswap(uint32_t value) noexcept { return __builtin_bswap32(value); } template<typename T> struct Raw { T value; }; template<typename T> Raw(T) -> Raw<T>; template<typename T> struct BigEndian { using Underlying = T; using Native = T; constexpr BigEndian() noexcept = default; constexpr explicit BigEndian(Native value) noexcept : _value{bswap(value)} {} constexpr BigEndian(Raw<Underlying> raw) noexcept : _value{raw.value} {} constexpr Underlying raw() const { return _value; } constexpr Native native() const { return bswap(_value); } explicit operator bool() const { return static_cast<bool>(_value); } bool operator==(const BigEndian& other) const { return raw() == other.raw(); } bool operator!=(const BigEndian& other) const { return raw() != other.raw(); } friend std::ostream& operator<<(std::ostream& out, const BigEndian& value) { return out << value.native(); } private: Underlying _value{}; } PACKED;

इस प्रकार की एक हेडर फ़ाइल को हर जगह शामिल किया जाएगा, इसलिए एक भारी <iostream> बजाय एक हल्का <iosfwd> ।
htons() , आदि के बजाय - फास्ट कंपाइलर htons() । विशेष रूप से, वे लगातार प्रसार से constexpr होते हैं, इसलिए constexpr निर्माण करते हैं।
कभी-कभी uint16_t में पहले से ही एक uint16_t / uint32_t मान स्थित होता है। कटौती गाइड के साथ Raw<T> संरचना आपको आसानी से एक BigEndian<T> बनाने की अनुमति देती है।

यहां विवादास्पद बिंदु PACKED : पैक किए गए ढांचे को कम अनुकूलन योग्य माना जाता है। केवल उत्तर को मापना है। हमारे कोड बेंचमार्क ने कोई मंदी नहीं दिखाई। इसके अलावा, नेटवर्क पैकेट के मामले में, हेडर में फ़ील्ड्स की स्थिति अभी भी तय है।

ज्यादातर मामलों में, बीई को तुलना के अलावा किसी भी संचालन की आवश्यकता नहीं है। अनुक्रम संख्या को 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;

सुरक्षित टीसीपी हैडर संरचना

 enum TCPFlag : uint8_t { TH_FIN = 0x01, TH_SYN = 0x02, TH_RST = 0x04, TH_PUSH = 0x08, TH_ACK = 0x10, TH_URG = 0x20, TH_ECE = 0x40, TH_CWR = 0x80, }; using TCPFlags = std::underlying_type_t<TCPFlag>; struct TCPHeader { L4Port th_sport; L4Port th_dport; Seqnum th_seq; Seqnum th_ack; uint32_t th_flags2 : 4; uint32_t th_off : 4; TCPFlags th_flags; BE16 th_win; uint16_t th_sum; BE16 th_urp; uint16_t header_length() const { return th_off << 2; } void set_header_length(uint16_t len) { th_off = len >> 2; } uint8_t* payload() { return reinterpret_cast<uint8_t*>(this) + header_length(); } const uint8_t* payload() const { return reinterpret_cast<const uint8_t*>(this) + header_length(); } }; static_assert(sizeof(TCPHeader) == 20);

TCPFlag को TCPFlag enum class बनाया जा सकता है, लेकिन व्यवहार में झंडे पर केवल दो ऑपरेशन किए जाते हैं: प्रविष्टि की जांच करना ( & ) या झंडे को एक संयोजन के साथ बदलना ( | ) - कोई भ्रम नहीं है।
बिट फ़ील्ड को आदिम छोड़ दिया जाता है, लेकिन सुरक्षित पहुंच के तरीके बनाए जाते हैं।
फ़ील्ड नाम क्लासिक छोड़ दिए गए हैं।

परिणाम

अधिकांश संपादन तुच्छ थे। कोड क्लीनर है:

  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); }

भाग में, प्रकार ने कोड को प्रलेखित किया:

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

अचानक, यह पता चला कि आप गलत तरीके से टीसीपी विंडो के आकार को पढ़ सकते हैं, जबकि यूनिट परीक्षण पास हो जाएंगे और यहां तक कि ट्रैफिक को भी रोक दिया जाएगा:

  //  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; }

एक तार्किक त्रुटि का उदाहरण: मूल कोड के डेवलपर ने सोचा कि फ़ंक्शन बीई स्वीकार करता है, हालांकि वास्तव में यह नहीं है। जब 0 बजाय Raw{} का उपयोग करने की कोशिश की जाती है 0 कार्यक्रम बस संकलन नहीं करता था (सौभाग्य से, यह सिर्फ एक इकाई परीक्षण है)। तुरंत हमें डेटा का एक असफल विकल्प दिखाई देता है: यदि 0 का उपयोग नहीं किया गया था, तो त्रुटि जल्द ही मिल जाएगी, जो कि किसी भी बाइट क्रम में समान है।

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

एक समान उदाहरण: सबसे पहले, कंपाइलर ने def_seq और cookie प्रकारों के बीच बेमेल को def_seq , फिर यह स्पष्ट हो गया कि परीक्षण पहले क्यों पारित हुआ - ऐसे स्थिरांक।

 - 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);

परिणाम

नीचे पंक्ति है:

यूनिट परीक्षणों में एक बग और कई तार्किक त्रुटियां मिलीं।
रिफैक्टरिंग ने मुझे संदिग्ध स्थानों को छांटा, पठनीयता बढ़ी।
प्रदर्शन संरक्षित किया गया है, लेकिन कम हो सकता है - बेंचमार्क की आवश्यकता है।

तीनों बिंदु हमारे लिए महत्वपूर्ण हैं, इसलिए हमें लगता है कि रिफैक्टरिंग इसके लायक था।

क्या आप सख्त प्रकार के साथ गलतियों के खिलाफ खुद का बीमा करते हैं?

C ++ में मजबूत टाइपिंग के लाभ: हाथों पर अनुभव

बाइट क्रम

मजबूत टाइपिंग

परिणाम

परिणाम

More articles: