នេះ អ្នកអភិវឌ្ឍន៍ Cloudflare បានចេញផ្សាយហើយ ព័ត៌មានអំពីការងារដែលពួកគេកំពុងធ្វើដើម្បីធ្វើឱ្យដំណើរការអ៊ីនគ្រីបឌីសបានប្រសើរបំផុតនៅក្នុងខឺណែលលីនុចដែលពួកគេបានលើកឡើងថាពួកគេបានរៀបចំ បំណះសំរាប់ប្រព័ន្ធរង dm-crypt និង Crypto API ។
ជាមួយនោះ តេស្តសំយោគត្រូវបានអនុញ្ញាតិអោយបន្ថែមកំរិតបញ្ជូនទ្វេដងសំរាប់ការអាននិងសរសេរ ក៏ដូចជា ភាពយឺតយ៉ាវពាក់កណ្តាល។ នៅពេលធ្វើតេស្តលើម៉ាស៊ីនពិតប្រាកដការដាក់លេខកូដខាងលើត្រូវបានកាត់បន្ថយស្ទើរតែដល់កម្រិតដែលបានឃើញនៅពេលធ្វើការជាមួយឌីសដោយមិនប្រើការអ៊ិនគ្រីបទិន្នន័យ។
ចំណាប់អារម្មណ៍ក្នុងការកែលម្អការអ៊ិនគ្រីប ទិន្នន័យនៅលើថាស វាដោយសារតែ Cloudflare ប្រើ dm-crypt ដើម្បីអ៊ិនគ្រីបទិន្នន័យនៅលើដ្រាយដែលបានប្រើដើម្បីលាក់មាតិកានៅលើស៊ីឌីអិន។ Dm-គ្រីបធ្វើការនៅកម្រិតឧបករណ៍ប្លុកហើយអ៊ីនគ្រីបសំណើរអ៊ី / អូដើម្បីសរសេរនិងឌិគ្រីបសំណើអានដែលដើរតួជាស្រទាប់រវាងឧបករណ៍ប្លុកនិងកម្មវិធីបញ្ជាប្រព័ន្ធឯកសារ។
ដើម្បីវាយតម្លៃការអនុវត្ត dm-crypt ដោយប្រើកញ្ចប់តេស្ត I / O ដែលអាចបត់បែនបាន, se វាស់ល្បឿននៃការធ្វើការជាមួយភាគថាសដែលបានអ៊ិនគ្រីប និងមិនបានអ៊ិនគ្រីបនៅលើថាស RAM ដែលមានទីតាំងនៅក្នុង RAM ដើម្បីលុបបំបាត់ភាពប្រែប្រួលនៃដំណើរការឌីស។
ចំពោះភាគថាសដែលមិនបានអ៊ិនគ្រីបការអាននិងការសរសេរនៅតែមានដល់ ១១២៦ មេកាបៃ / វិនាទីប៉ុន្តែនៅពេលការអ៊ិនគ្រីបត្រូវបានបើកល្បឿនបានធ្លាក់ចុះ ៧ ដងមកត្រឹម ១៤៧ មេកាបៃ / វិនាទី។
នៅដើមដំបូង, ការប្រើក្បួនដោះស្រាយគ្មានប្រសិទ្ធភាពត្រូវបានគេសង្ស័យ នៅក្នុងប្រព័ន្ធគ្រីបខឺណែល។ ប៉ុន្តែការធ្វើតេស្តបានប្រើក្បួនដោះស្រាយ aes-xts លឿនជាងមុនដោយប្រើកូនសោអ៊ិនគ្រីប ២៥៦ ដែលការសម្តែងរបស់វានៅពេលដំណើរការតារាង "គ្រីសថឺតេសស្ទឺរ" គឺខ្ពស់ជាងលទ្ធផលដែលទទួលបាននៅពេលសាកល្បងឌីសរ៉េម។
ការពិសោធន៍ ជាមួយទង់ dm-គ្រីប ដើម្បីកែសំរួលការអនុវត្តមិនបានដំណើរការទេ៖ នៅពេលទង់ –perf-same_cpu_crypt ត្រូវបានប្រើការសម្តែងរឹតតែថយចុះដល់ ១៣៦ មេកាបៃ / វិនាទីហើយនៅពេលទង់ –perf-submit_from_crypt_cpus ត្រូវបានប្រើវាកើនឡើងត្រឹមតែ ១៦៦ មេកាបៃ / វិនាទី។
ការវិភាគកាន់តែស៊ីជម្រៅ នៃតក្កនៃការងារ បានបង្ហាញថាឌីអេគ្រីគ្រីមិនសាមញ្ញទេ ដូចដែលវាហាក់ដូចជា។
នៅពេលដែលការស្នើសុំសរសេរត្រូវបានទទួលពីឧបករណ៍បញ្ជាអេហ្វអេសអេសអេសគ្រីមិនដំណើរការភ្លាមៗទេប៉ុន្តែដាក់វានៅលើជួរ "kcryptd" ដែលមិនត្រូវបានយល់ភ្លាមៗប៉ុន្តែនៅពេលពេលវេលាល្អកើតឡើង។ ពីជួរការស្នើសុំត្រូវបានផ្ញើទៅលីនុចគ្រីថូ API សម្រាប់ការអ៊ិនគ្រីប។
នៅពេលអានដំបូងជួរ dm-គ្រីប "kcryptd_io" សំណើរដើម្បីទទួលបានទិន្នន័យពីអង្គភាព។ បន្ទាប់ពី សម្រាប់ខណៈពេលមួយ, ទិន្នន័យគឺអាចរកបាននិង ពួកវាត្រូវបានដាក់ជាជួរ "kcryptd" សម្រាប់ការដាក់លេខកូដ។
Kcryptd ផ្ញើរសំណើរទៅលីនុចអ៊ិនគ្រីបលីនុច API ដែលជាលេខកូដនៃព័ត៌មានមិនត្រឹមត្រូវ។ សំណើមិនតែងតែឆ្លងកាត់ជួរទាំងអស់ទេប៉ុន្តែក្នុងករណីដ៏អាក្រក់បំផុត ការស្នើសុំសរសេរត្រូវបានកំណត់ជាជួររហូតដល់ ៤ ដង និងសំណើអានរហូតដល់ទៅ ៣ ដង។ រាល់ការវាយក្នុងកន្ទុយនាំឱ្យមានការពន្យារពេល ដែលជាហេតុផលដ៏សំខាន់សម្រាប់ការថយចុះគួរឱ្យកត់សម្គាល់នៃការអនុវត្តឌីអេសគ្រីគ្រី។
ដោយពិចារណាថាដ្រាយវ៍ទំនើបបានលឿននិងឆ្លាតជាងមុនប្រព័ន្ធបែងចែកធនធាននៅក្នុងខឺណែលលីនុចត្រូវបានកែលម្អហើយ ប្រព័ន្ធរងមួយចំនួនត្រូវបានរៀបចំឡើងវិញវិស្វករ Cloudflare បានបន្ថែមរបៀបប្រតិបត្ដិការថ្មីមួយទៅឌី - គ្រីដោយលុបបំបាត់ការប្រើប្រាស់ជួរបន្ថែមនិងការហៅអសមកាល។
របៀបត្រូវបានបើកដំណើរការដោយទង់ "បង្ខំ_inline" ដាច់ដោយឡែកហើយនាំ dm-គ្រីបទៅជាទម្រង់ប្រូកស៊ីសាមញ្ញមួយដែលអ៊ីនគ្រីបនិងឌិគ្រីបសំណើចូល។ អន្តរកម្មជាមួយ Crypto API ត្រូវបានធ្វើឱ្យប្រសើរតាមរយៈជម្រើសជាក់ស្តែងនៃក្បួនដោះស្រាយការអ៊ិនគ្រីប ពួកវាដំណើរការក្នុងរបៀបធ្វើសមកាលកម្មហើយមិនប្រើជួរស្នើសុំទេ។
នៅពេលធ្វើតេស្តបន្ទុកនៅលើម៉ាស៊ីនមេពិតប្រាកដការអនុវត្តថ្មីបានបង្ហាញពីការអនុវត្តជិតនឹងការកំណត់រចនាសម្ព័ន្ធដែលដំណើរការដោយគ្មានការអ៊ិនគ្រីបហើយការដាក់បញ្ចូលលេខកូដនៅលើម៉ាស៊ីនមេជាមួយឃ្លាំងសម្ងាត់ពពកមិនប៉ះពាល់ដល់ល្បឿនឆ្លើយតបទេ។
នៅពេលអនាគត, Cloudflare គ្រោងនឹងផ្ទេរបំណះដែលបានរៀបចំទៅខឺណែលលីនុចសំខាន់ប៉ុន្តែមុននោះពួកគេនឹងត្រូវបានផ្លាស់ប្តូរចាប់តាំងពីពួកគេត្រូវបានធ្វើឱ្យប្រសើរឡើងសម្រាប់បន្ទុកជាក់លាក់មួយហើយមិនគ្របដណ្តប់លើគ្រប់ផ្នែកនៃកម្មវិធីឡើយ។
ប្រភព: https://blog.cloudflare.com
ធ្វើជាយោបល់ដំបូង