🥇How we break through the Great Firewall of China (part 1)

ជំរាបសួរមនុស្សគ្រប់គ្នា!

Nikita កំពុងទាក់ទង - វិស្វករប្រព័ន្ធមកពីក្រុមហ៊ុន SEMrush. ថ្ងៃនេះខ្ញុំនឹងប្រាប់អ្នកអំពីរបៀបដែលយើងប្រឈមមុខនឹងភារកិច្ចធានាស្ថេរភាពនៃសេវាកម្ម semrush.com របស់យើងនៅក្នុងប្រទេសចិន និងបញ្ហាអ្វីខ្លះដែលយើងជួបប្រទះក្នុងអំឡុងពេលអនុវត្តរបស់វា (ផ្តល់ទីតាំងនៃមជ្ឈមណ្ឌលទិន្នន័យរបស់យើងនៅឆ្នេរសមុទ្រភាគខាងកើតនៃសហរដ្ឋអាមេរិក)។

នេះនឹងជារឿងធំមួយដែលបែងចែកជាអត្ថបទមួយចំនួន។ ខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដែលវាបានកើតឡើងសម្រាប់ពួកយើង៖ ពីសេវាកម្មដែលមិនមានមុខងារទាំងស្រុងពីប្រទេសចិន រហូតដល់សូចនាករប្រតិបត្តិការនៃសេវាកម្មនៅកម្រិតនៃកំណែអាមេរិកសម្រាប់ជនជាតិអាមេរិក។ ខ្ញុំសន្យាថាវានឹងគួរឱ្យចាប់អារម្មណ៍និងមានប្រយោជន៍។ ដូច្នេះ តោះទៅ។

បញ្ហាអ៊ីនធឺណិតចិន

សូម្បីតែមនុស្សឆ្ងាយបំផុតពីផ្នែកជាក់លាក់នៃការគ្រប់គ្រងបណ្តាញបានឮអំពី ជញ្ជាំងភ្លើងដ៏អស្ចារ្យនៃប្រទេសចិន. Wow ស្តាប់ទៅពិរោះណាស់មែនទេ? ប៉ុន្តែតើវាជាអ្វី និងរបៀបដែលវាដំណើរការពិតប្រាកដ គឺជាសំណួរដ៏ស្មុគស្មាញមួយ។ អ្នកអាចរកឃើញអត្ថបទជាច្រើននៅលើអ៊ីនធឺណិតដែលផ្តោតលើរឿងនេះ ប៉ុន្តែតាមទស្សនៈបច្ចេកទេស រចនាសម្ព័ន្ធនៃជញ្ជាំងភ្លើងនេះមិនត្រូវបានពិពណ៌នានៅគ្រប់ទីកន្លែងទេ។ ដែលទោះជាយ៉ាងណាមិនគួរឱ្យភ្ញាក់ផ្អើលទេ។ ខ្ញុំនឹងទទួលស្គាល់ភ្លាមៗថា ដោយផ្អែកលើលទ្ធផលនៃការងារមួយឆ្នាំ ខ្ញុំនឹងមិនអាចនិយាយបានច្បាស់អំពីរបៀបដែលវាដំណើរការនោះទេ ប៉ុន្តែខ្ញុំអាចប្រាប់អ្នកអំពីមតិយោបល់ និងការសន្និដ្ឋានជាក់ស្តែងរបស់ខ្ញុំ។ ហើយយើងនឹងចាប់ផ្តើមជាមួយនឹងពាក្យចចាមអារ៉ាមអំពីជញ្ជាំងភ្លើងនេះ។

មានពាក្យចចាមអារ៉ាមជាច្រើនអំពីជញ្ជាំងភ្លើងនេះ។ ចូរប្រមូលចំណុចសំខាន់ និងគួរឱ្យចាប់អារម្មណ៍បំផុតក្នុងបញ្ជីមួយ៖

Google, Facebook, Twitter និងសេវាកម្មស្រដៀងគ្នាផ្សេងទៀតត្រូវបានរារាំង ហើយមិនដំណើរការនៅក្នុងប្រទេសចិនទេ។
រាល់ចរាចរណ៍ដែលធ្វើដំណើរទៅក្រៅប្រទេសនៃប្រទេសចិន និងចូលទៅក្នុងប្រទេសចិនត្រូវបានញែក និងកំណត់ដោយប្រើការរៀនម៉ាស៊ីន (ក្នុងករណីមានចរាចរណ៍គួរឱ្យសង្ស័យ) ដែលធ្វើឲ្យវាថយចុះយ៉ាងខ្លាំង (ចរាចរណ៍) ឆ្លងកាត់ព្រំដែន។
ទីភ្នាក់ងារស៊ើបការណ៍សម្ងាត់របស់ចិននឹងលួចចូលអ៊ីនគ្រីបចរាចរណ៍ដែលឆ្លងកាត់ជញ្ជាំងភ្លើងរបស់ពួកគេ។
ផ្លូវរូងក្រោមដី VPN ផ្លូវរូងក្រោមដី IPSEC មិនស្ថិតស្ថេរ គាំង និងត្រូវបានរារាំងឥតឈប់ឈរ។
ការអ៊ិនគ្រីបកាន់តែសាមញ្ញ ឃ្លាសម្ងាត់ដែលប្រើដើម្បីផ្ទៀងផ្ទាត់/អ៊ិនគ្រីបចរាចរណ៍កាន់តែសាមញ្ញ វាកាន់តែលឿនតាមរយៈជញ្ជាំងភ្លើងរបស់ចិន។

នេះជាអ្វីដែលយើងបានរកឃើញអំពីពាក្យចចាមអារ៉ាមទាំងនេះ៖

Google, Facebook, Twitter និងសេវាកម្មស្រដៀងគ្នាផ្សេងទៀតគឺពិតជាត្រូវបានរារាំង (KO របស់អ្នក) ប៉ុន្តែជាឧទាហរណ៍ ដែន Google បច្ចេកទេសជាច្រើនមិនត្រូវបានហាមឃាត់ និងដំណើរការ (ដូចគ្នា gstatic.com) ។ ការសន្និដ្ឋាននេះកើតឡើងពីនេះ៖ អ្នកមិនគួរកាត់បន្ថយ Google និងធនធានផ្សេងទៀតទាំងអស់ដែលហាក់ដូចជាត្រូវបានរារាំងដោយឥតប្រុងប្រយ័ត្ននោះទេ។
រាល់ចរាចរណ៍ឆ្លងកាត់ព្រំដែនពិតជាបន្ថែមការពន្យារពេលយ៉ាងធ្ងន់ធ្ងរដល់ពេលវេលារបស់វា។ មើលលទ្ធផលទាំងពីរ។ គេហទំព័រមួយ ទំព័រមួយ សាមញ្ញ GET curlអូម ការវាស់វែងដំបូងគឺមកពីប្រទេសចិនផ្ទាល់ (ទីក្រុងដ៏ស្រស់ស្អាតនៃ Shenzhen) ។ ទីពីរត្រូវបានវាស់ពីខាងក្រៅពីហុងកុង (វាមានអធិបតេយ្យភាព ហើយមិនមានជញ្ជាំងភ្លើងរវាងវា និងពិភពលោក)។ ចម្ងាយរវាងទីក្រុងនៅក្នុងបន្ទាត់ត្រង់គឺប្រហែល 30-40 គីឡូម៉ែត្រ។

nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832
time_namelookup:  0.004500
time_connect:  0.169342
time_appconnect:  0.723189
time_pretransfer:  0.723499
time_redirect:  0.000000
time_starttransfer:  1.532912
----------
time_total:  5.443407
----------
size_download:  390968 Bytes
speed_download:  71824.000B/s

nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup:  0.029366
time_connect:  0.030742
time_appconnect:  0.047310
time_pretransfer:  0.047388
time_redirect:  0.000000
time_starttransfer:  0.120793
----------
time_total:  0.124871
----------
size_download:  326755 Bytes
speed_download:  2616740.000B/s

យកចិត្តទុកដាក់ ភ្ជាប់ពេលវេលា. ហើយជាទូទៅ អ្នកឃើញលទ្ធផល៖ ជញ្ជាំងភ្លើងបន្ថែម 4 វិនាទីទៀត ដែលវែងខ្លាំង។

VPN និង IPSEC tunnels បរាជ័យជាញឹកញាប់។ ខ្ញុំនឹងនិយាយអំពីរឿងនេះនៅពេលក្រោយ និងលម្អិតបន្ថែមទៀត។ ម៉ាស៊ីនមេ VPN ដែលអ្នកប្រើប្រាស់ត្រូវបានរារាំងតាមពេលវេលា (ជាធម្មតាក្នុងរយៈពេលមួយថ្ងៃបន្ទាប់ពីការចាប់ផ្តើមប្រើប្រាស់)។
មានមតិមួយទទួលបានពីប្រជាជនដែលរស់នៅក្នុងប្រទេសចិនថា ការអ៊ិនគ្រីបចរាចរណ៍កាន់តែងាយស្រួល ឆ្លងកាត់ព្រំដែនកាន់តែលឿន ព្រោះវាងាយស្រួលយល់ថា មិនមានអ្វីខុសច្បាប់នោះទេ។ ហើយតាមរបៀបដូចគ្នា ចរាចរណ៍ "ស្អាត" ទទួលបានកម្រិតបញ្ជូនកាន់តែច្រើន និងល្បឿននៃការឆ្លងកាត់ ខណៈពេលដែលចរាចរណ៍ "កខ្វក់" ដែលគ្មានអ្វីអាចយល់បាន ទទួល ផ្ទុយទៅវិញ ការឆ្លងកាត់យឺតជាង។ ឧទាហរណ៍ខ្ញុំនឹងប្រើ curl ទៅ ifconfig.co តាមរយៈ HTTPS និង HTTP protocol ។

curl -o /dev/null -w@curl_time "https://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3
time_namelookup:  0.004305
time_connect:  0.397465
time_appconnect:  5.149305
time_pretransfer:  5.149393
time_redirect:  0.000000
time_starttransfer:  5.568847
----------
time_total:  5.568893
----------
size_download:  13 Bytes
speed_download:  2.000B/s

curl -o /dev/null -w@curl_time "http://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28
time_namelookup:  0.004282
time_connect:  0.212457
time_appconnect:  0.000000
time_pretransfer:  0.212484
time_redirect:  0.000000
time_starttransfer:  0.450565
----------
time_total:  0.450620
----------
size_download:  13 Bytes
speed_download:  28.000B/s

ភាពខុសគ្នានៃ 5 វិនាទីសម្រាប់ពេលវេលាទាញយកសរុប 13 បៃ។ លើសពីនេះទៅទៀត នៅពេលធ្វើការសាកល្បងបែបនេះច្រើនដង អ្នកអាចសម្គាល់ឃើញថា GET នៅលើ HTTP ត្រូវបានបញ្ចប់ជាធម្មតាក្នុងពេលតែមួយរាល់ពេល ខណៈពេលដែលនៅលើគេហទំព័រ HTTPS ពេលខ្លះឆ្លើយតបក្នុងរយៈពេល 3, 5, 10 និងសូម្បីតែ 17 វិនាទី។ ពេលខ្លះកំហុស SSL កើតឡើង៖

Unknown SSL protocol error in connection to ifconfig.co:443.

ដូច្នេះអ្វីដែលយើងមាន៖

បញ្ហាដែលបង្កើតឡើងដោយជញ្ជាំងភ្លើងចិនត្រូវបានពិពណ៌នាខាងលើ។
Pings ទៅកាន់ធនធានខាងក្រៅ និងខាងក្នុងផ្លូវរូងក្រោមដីបាត់ជាទៀងទាត់។
ភាពយឺតយ៉ាវរវាងចំណុចពីរកំពុងផ្លាស់ប្តូរឥតឈប់ឈរ ហើយជារឿយៗវាមិនអាចទាយទុកជាមុនបាន។ នៅពេលភ្ជាប់ទីក្រុង/តំបន់ផ្សេងៗគ្នា អ្នករំពឹងថា ដោយផ្អែកលើទីតាំងភូមិសាស្ត្រនៃតំបន់ ការពន្យារពេលនឹងតិចជាង ប៉ុន្តែអ្នកទទួលបានស្ថានភាពផ្ទុយពីនេះ។
អ៊ីនធឺណែត និងបណ្តាញទំនាក់ទំនងគឺលឿន ឬយឺត។ មានការពឹងផ្អែកបន្តិចបន្តួចលើពេលវេលានៃថ្ងៃនិងថ្ងៃនៃសប្តាហ៍ប៉ុន្តែមិនតែងតែទេ។
សំណើ DNS ទៅកាន់ពិភពខាងក្រៅពីប្រទេសចិន ជួនកាលលើសពីពេលវេលាដែលអនុញ្ញាត។

រូបភាពដែលលេចចេញមកគឺសាមញ្ញ "អស្ចារ្យ" ។

មជ្ឈមណ្ឌលទិន្នន័យ ដូចដែលខ្ញុំបាននិយាយរួចហើយ គឺនៅភាគខាងកើតសហរដ្ឋអាមេរិក ហើយ SEMrush ទាំងមូលមានផលិតផលដែលទាក់ទងគ្នារាប់សិប ផ្ទាំងខាងក្រោយ ផ្នែកខាងមុខ មូលដ្ឋានទិន្នន័យ និងអ្វីៗទាំងអស់នេះនៅក្នុង DC និងពពក។ យើងជាក្រុមអ្នកគ្រប់គ្រងប្រព័ន្ធត្រូវបានផ្តល់ភារកិច្ចឱ្យចាប់ផ្តើមធ្វើការក្នុងប្រទេសចិនយ៉ាងឆាប់រហ័សដោយមានការខិតខំប្រឹងប្រែងតិចតួច។

យើងត្រូវឆ្លើយសំណួរសំខាន់មួយ៖ តើវាអាចទៅរួចទេក្នុងការចំណាយតិចតួច និងដោះស្រាយបញ្ហាទាំងអស់ដែលទាក់ទងនឹងអ៊ីនធឺណិត និងជញ្ជាំងភ្លើងរបស់ចិននៅកម្រិតបណ្តាញ/ពពក/ម៉ាស៊ីនមេ?

យើងចាប់ផ្តើមដោយការទទួល អាយភីស៊ី។- អាជ្ញាប័ណ្ណ.

អាជ្ញាប័ណ្ណ ICP

ដើម្បីអាចធ្វើជាម្ចាស់ផ្ទះសេវាកម្មរបស់អ្នកនៅក្នុងប្រទេសចិន (ចិនដីគោក) និងធ្វើតេស្ត អ្នកត្រូវតែទទួលបានអាជ្ញាប័ណ្ណ ICP ជាដំបូងសម្រាប់ដែន។

ប្រសិនបើចរាចរណ៍អ្នកប្រើប្រាស់គេហទំព័ររបស់អ្នកត្រូវបានបញ្ចប់នៅក្នុងប្រទេសចិនដីគោក ហើយប្រសិនបើដែនរបស់អ្នកមិនមានអាជ្ញាប័ណ្ណ ICP នោះចរាចរណ៍របស់អ្នកនឹងត្រូវបានរារាំងនៅលើផ្នែក ISP/hosting ។ គួរឱ្យចាប់អារម្មណ៍ អាជ្ញាប័ណ្ណ ICP រួមបញ្ចូលអ្នកផ្តល់សេវាជាក់លាក់មួយ មិនថា Cloudflare ឬ Alibaba Cloud ។ ដូច្នេះហើយ ប្រសិនបើអ្នកបានទទួលអាជ្ញាប័ណ្ណ ICP សម្រាប់ Cloudflare និងបង្ហោះគេហទំព័ររបស់អ្នកជាមួយពួកគេ អ្នកនឹងមិនអាច "ផ្លាស់ទី" ទៅកាន់ Alibaba Cloud ដោយមិនរលូនឡើយ។ អ្នកនឹងត្រូវបន្ថែមការបង្ហោះមួយផ្សេងទៀតទៅអាជ្ញាប័ណ្ណនេះ។

ដោយបានទទួលអាជ្ញាប័ណ្ណ ICP សម្រាប់ដែន យើងអាចបង្កើត និងអនុវត្តគំនិតបច្ចេកទេស និងដំណោះស្រាយជាក់លាក់។

ដំណោះស្រាយសាកល្បង

ប៉ុន្តែមុនពេលអ្នកបង្កើតជម្រើសដំណាក់កាលដោយផ្ទាល់ បង្វែរប៊ូតុង បង្កើនប្រសិទ្ធភាពប្រតិបត្តិការរបស់គេហទំព័រ និងល្បឿនរបស់វា អ្នកត្រូវជ្រើសរើសឧបករណ៍សម្រាប់សាកល្បងវា ដើម្បីមើលថាតើសកម្មភាពណាមួយរបស់យើងប្រសើរឡើង ឬផ្ទុយទៅវិញធ្វើឱ្យដំណើរការគេហទំព័រកាន់តែអាក្រក់។

ឧបករណ៍ធ្វើតេស្តរបស់យើងត្រូវតែបំពេញតាមតម្រូវការសំខាន់ពីរ៖

វាគួរតែអាចដំណើរការការធ្វើតេស្តពីប្រទេសចិន
វាត្រូវតែមានការធ្វើតេស្តកម្មវិធីរុករក។

ដូច្នេះយើងបានរកឃើញ ចំណុចចាប់! ពួកគេមានការគ្របដណ្តប់ដ៏ល្អឥតខ្ចោះនៃទីតាំងធ្វើតេស្តជុំវិញពិភពលោក។ នៅក្នុងប្រទេសចិន ការធ្វើតេស្តក៏អាចដំណើរការពីខេត្តចំនួន 100500 តាមរយៈឧបករណ៍នេះ។ នីមួយៗមានអ្នកផ្តល់សេវាផ្សេងៗគ្នាជាច្រើន + សមត្ថភាពក្នុងការធ្វើ ឆ្អឹងខ្នង-tests (អ្វីមួយដូចជាម៉ាស៊ីននិម្មិតនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ) និង ជាចុងក្រោយ-tests (ជិតបំផុតតាមដែលអាចធ្វើបានទៅនឹងលក្ខខណ្ឌអ្នកប្រើប្រាស់ aka workstation)។ ការធ្វើតេស្តប្រភេទចុងក្រោយមានតម្លៃថ្លៃជាង។

ដោយបានបញ្ចប់កិច្ចសន្យាប្រចាំឆ្នាំ (តិចជាងនោះមិនអាចទៅរួច) យើងបានចាប់ផ្តើមសិក្សាឧបករណ៍។ និយាយឱ្យត្រង់ទៅ យើងមានការភ្ញាក់ផ្អើលយ៉ាងខ្លាំងចំពោះមុខងាររបស់វា។ អ្នកអាចរត់បាន៖

ការធ្វើតេស្ត DNS,
ការធ្វើតេស្តលើបណ្តាញ (ការធ្វើតេស្តកម្មវិធីរុករក, GET/POST សាមញ្ញ, ការត្រាប់តាមម៉ាស៊ីនភ្ញៀវចល័ត។ល។)
ការត្រួតពិនិត្យប្រតិបត្តិការ (ឧទាហរណ៍ ចូល)
ការធ្វើតេស្ត API,
Ping, traceroute, NTP ជាដើម។

អ្នកមិនអាចរាយបញ្ជីអ្វីទាំងអស់។ ហើយសំខាន់បំផុត ការធ្វើតេស្តនីមួយៗអាចត្រូវបានប្ដូរតាមបំណងបានយ៉ាងល្អដោយបន្ថែម bunch នៃបឋមកថានិងប៉ារ៉ាម៉ែត្រផ្សេងទៀត។ លទ្ធផលគឺជាព័ត៌មានដ៏ធំសម្បើម ដែលពិពណ៌នាយ៉ាងពេញលេញអំពីការធ្វើតេស្តរបស់អ្នក។ ប្រសិនបើយើងនិយាយអំពីអ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតសម្រាប់យើង (ការធ្វើតេស្តកម្មវិធីរុករក) លទ្ធផលរួមមាន:

ភ្ជាប់, រង់ចាំ, ផ្ទុក, SSL, DNS time,
TTFB, TTLB, ឯកសារពេញលេញ, ពេលវេលាបង្ហាញ, ការផ្ទុក DOM,
ការឆ្លើយតប (អ្វីមួយនៅជិត Time To First Byte), ការឆ្លើយតបគេហទំព័រ (អ្វីមួយដែលជិតស្និទ្ធនឹង Time To Last Byte),
ភាគរយណាមួយ មធ្យម ពេលវេលាមធ្យម
ល។

ដូច្នោះហើយ រង្វាស់ទាំងអស់នេះគឺល្អណាស់សម្រាប់ការមើលឃើញការផ្លាស់ប្តូរ និងការយល់ដឹងថាតើអ្វីៗបានប្រសើរឡើងឬអត់។ យើងមើលជាចម្បង ការឆ្លើយតប ការឆ្លើយតបគេហទំព័រ មេដ្យាន 75 និង 95 ភាគរយ.

សំណួរសំខាន់មួយដែលមាននៅលើអាកាសតាំងពីដើមដំបូងមក៖ តើអ្នកអាចទុកចិត្ត Catchpoint បានទេ?? តើឧបករណ៍នេះឆ្លុះបញ្ចាំងពីល្បឿននៃការផ្ទុកគេហទំព័រពិតនៅក្នុងប្រទេសចិនពីទីក្រុងផ្សេងៗគ្នា ឬវាគ្រាន់តែជាការសាកល្បងប្រភេទមួយចំនួននៅក្នុងម៉ាស៊ីនបូមធូលីដែលមិនពាក់ព័ន្ធនឹងបទពិសោធន៍អ្នកប្រើប្រាស់ពិតប្រាកដទេ?
នេះគឺជាបញ្ហាធំមួយ ពីព្រោះនៅក្នុងប្រទេសរុស្ស៊ី វាស្ទើរតែមិនអាចជឿជាក់បានថា តើគេហទំព័រមួយមកពីប្រទេសចិនដំណើរការយ៉ាងដូចម្តេច។ តាមរយៈការធ្វើស្រោមជើង-ប្រូកស៊ី តាមរយៈម៉ាស៊ីននិម្មិត លទ្ធផលចុងក្រោយគឺថាគេហទំព័រផ្ទុកក្នុងរយៈពេលពីរបីនាទី ដែលជាការមិនអាចទទួលយកបានសម្រាប់ការធ្វើតេស្ត ដូច្នេះជម្រើសតែមួយគត់សម្រាប់ការធ្វើតេស្តដោយដៃគឺ curl និងសាមញ្ញ ទទួលបានពីកុងសូលដោយប្រើកម្មវិធីកំណត់ម៉ោង។ . នេះជួយព្រោះការធ្វើតេស្តនេះឆ្លុះបញ្ចាំងយ៉ាងល្អអំពីល្បឿននៃដំណោះស្រាយបណ្តាញ ហើយប្រសិនបើមានការធ្វើតេស្តកម្មវិធីរុករកតាមអ៊ីនធឺណិតផងដែរ នោះវាពិតជាល្អណាស់។

ក្រោយមក យើងខ្លួនឯងបានទៅប្រទេសចិន ហើយត្រូវបានគេជឿជាក់ថា អ្នកអាចជឿទុកចិត្តលើ Catchpoint វាឆ្លុះបញ្ចាំងយ៉ាងត្រឹមត្រូវនូវសូចនាករការអនុវត្តជាក់ស្តែង។

បណ្តាញ Cloudflare ប្រទេសចិន

ចាប់តាំងពីយើងប្រើប្រាស់ Cloudflare ដោយជោគជ័យសម្រាប់ដែនមេ semrush.com យើងបានសម្រេចចិត្តសាកល្បងមុខងាររបស់ពួកគេភ្លាមៗដែលហៅថា បណ្តាញចិន. ជម្រើសនេះត្រូវបានបើកសម្រាប់តែគេហទំព័រសហគ្រាសតាមការស្នើសុំដាច់ដោយឡែក និងសម្រាប់ថ្លៃបន្ថែម។ វាក៏មានសម្រាប់តែគេហទំព័រដែលមានអាជ្ញាប័ណ្ណ ICP សមស្របដែលរាយបញ្ជី Cloudflare ជាអ្នកផ្តល់សេវា។ បន្ទាប់ពីបើកដំណើរការវា "CDN ចិន" ពី Cloudflare អាចរកបានសម្រាប់គេហទំព័រ - ចរាចរណ៍ពីតំបន់ចិនចុះចតនៅ PoP (Points of Presence) CF ដែលនៅជិតបំផុត ហើយបន្ទាប់មកតាមរយៈបណ្តាញរបស់វា ឬបណ្តាញអ្នកផ្តល់សេវា/ដៃគូ វាត្រូវបានបញ្ជូនទៅប្រភពដើម .

ដ្យាក្រាមនៃកៅអីសាកល្បងនេះត្រូវបានបង្ហាញខាងក្រោម។

នេះគឺជាជម្រើសដ៏ល្អសម្រាប់យើង។ វាប្រែថាដែនទីពីរក៏នឹងសម្រាប់ CF ផងដែរ ដែលមិនបន្ថែមទៅលើចំនួននៃដំណោះស្រាយដែលបានប្រើនៅក្នុងក្រុមហ៊ុន ហើយការអនុវត្តក៏មិនធ្វើឱ្យស្មុគស្មាញដល់ហេដ្ឋារចនាសម្ព័ន្ធផងដែរ។

យើងបានដំណើរការការធ្វើតេស្តកម្មវិធីរុករក ហើយនេះគឺជាអ្វីដែលបានកើតឡើង៖

ពេជ្រក្រហមគឺជាការបរាជ័យក្នុងការសាកល្បង។ ឯកសារខាងក្រោមគឺជាកំហុស DNS (ដោះស្រាយអស់ពេល)។ ការបរាជ័យនៅកំពូលគឺអស់ពេល។

ពេលវេលាដំណើរការ៖ 86.6
មធ្យម៖ ១៨ វិ
75 ភាគរយ: 29.3s
95 ភាគរយ: 60s

មធ្យមបន្ទាប់ពីផ្ទុកត្រូវបានដកចេញ reCaptcha (សេវាកម្ម Google ត្រូវបានរារាំងនៅក្នុងប្រទេសចិន) ថយចុះពី 28 ទៅ 18 វិនាទី។ ប៉ុន្តែទាំងនេះនៅតែជាលទ្ធផលដ៏គួរឱ្យភ័យខ្លាច ដោយពិចារណាថាការធ្វើតេស្តដូចគ្នាសម្រាប់ semrush.com (ពីសហរដ្ឋអាមេរិក) បានផ្តល់តិចជាង 10 វិនាទីសម្រាប់អ្នកប្រើប្រាស់ 95% (មកពីសហរដ្ឋអាមេរិក) នៅលើទំព័រដូចគ្នា (ឋិតិវន្ត + ថាមវន្ត)។

អ្នកអាចចូលទៅក្នុងការធ្វើតេស្តនីមួយៗហើយមើលទៅ ទឹកជ្រោះ និងប៉ារ៉ាម៉ែត្រលម្អិតផ្សេងទៀត។ យើងចាប់ផ្តើមស៊ើបអង្កេតមូលហេតុនៃកំហុស ហើយប្រសិនបើអស់ពេល អ្វីៗគឺច្បាស់ជាង ឬតិចជាងនេះ៖ អ៊ិនធឺណិតនៅក្នុងប្រទេសចិន "ផ្លាស់ទីចូល និងចេញ" ដោយសារតែនេះល្បឿននៃការតភ្ជាប់ និងការផ្ទុកធនធានពីបរទេសគឺមិនស្ថិតស្ថេរ និងមិនស្មើគ្នា។ បន្ទាប់មក កំហុស DNS បានធ្វើឱ្យយើងភ្ញាក់ផ្អើលយ៉ាងខ្លាំង។ យើងបានរកឃើញនោះ។ ប៉ូ។ Cloudflare ពិតជាមានទីតាំងនៅក្នុងប្រទេសចិន អាស័យដ្ឋានគេហទំព័រដោះស្រាយទៅ IP ណាមួយក៏ដោយ ប៉ុន្តែម៉ាស៊ីនមេ DNS គឺជាជនជាតិអាមេរិក ដែលនេះជាមូលហេតុដែលសំណើ DNS ត្រូវបានបង្ខំឱ្យឆ្លងកាត់ព្រំដែន ដូច្នេះពេលខ្លះពួកគេបរាជ័យ។

ដោយបានបំភ្លឺសំណួរនេះជាមួយ CF វាប្រែថា ពួកគេមិនមានម៉ាស៊ីនមេ DNS ផ្ទាល់ខ្លួនរបស់ពួកគេនៅក្នុងប្រទេសចិនទេ។ហើយតើវានឹងមាននៅពេលណានៅមិនទាន់ដឹងនៅឡើយទេ។

ដូច្នេះហើយ យើងបានសម្រេចចិត្តសាកល្បងតែ Cloudflare DNS ហើយបានផ្លាស់ប្តូរយន្តការប្រតិបត្តិការ Cloudflare សម្រាប់គេហទំព័ររបស់យើងទៅជា "DNS តែប៉ុណ្ណោះ" នេះគឺជារបៀបមួយនៅពេលដែល Cloudflare មិនដំណើរការប្រូកស៊ីឆ្លងកាត់ខ្លួនវា ដែលមានន័យថាវាមិនផ្តល់ការការពារ DDoS, CDN និងលក្ខណៈពិសេសផ្សេងទៀត ហើយដំណើរការនៅក្នុងរបៀបនៃម៉ាស៊ីនមេ DNS ធម្មតា។

ជំហរនេះត្រូវបានបង្ហាញតាមគ្រោងការណ៍ក្នុងរូបខាងក្រោម។ តួលេខនេះពិចារណាលើចំណេះដឹងដែលកំពុងលេចឡើងដែលម៉ាស៊ីនមេ DNS របស់ Cloudflare នៅពីក្រោយជញ្ជាំងភ្លើង។

នៅ Catchpoint យើងបានដំណើរការការធ្វើតេស្ត GET សាមញ្ញ (មិនមែនការធ្វើតេស្តកម្មវិធីរុករកទេ) ដែលបង្ហាញពីការបរាជ័យជាច្រើន។ ពួកគេត្រូវបានបង្កឡើងដោយកំហុស DNS ដូចគ្នា។

យើងចាប់ផ្តើមបំបាត់កំហុសទាំងនេះដោយប្រើ dig ហើយបានរកឃើញថាតាមការស្នើសុំដំបូង អាសយដ្ឋានត្រូវបានកំណត់យ៉ាងត្រឹមត្រូវ ហើយតាមការស្នើសុំម្តងហើយម្តងទៀត យើងទទួលបានរាល់ពេល SERVFAIL и រកមិនឃើញ. ហេតុអ្វីបានជារឿងនេះកើតឡើងភ្លាមៗ?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)

មិនមានកំហុសបែបនេះទេនៅពេលសួរម៉ាស៊ីនមេ Cloudflare NS ដោយផ្ទាល់៖

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192

នេះមានន័យថាបញ្ហាគឺនៅផ្នែកម្ខាងនៃម៉ាស៊ីនមេ DNS "មូលដ្ឋាន" ឬម៉ាស៊ីនមេរបស់អ្នកផ្តល់សេវា។
ការស៊ើបអង្កេតបន្ថែមទៀតបានបង្ហាញថា SERVFAIL យើងដោះស្រាយ AAAA-កំណត់ត្រា។

វាប្រែថានៅពេលស្នើសុំពី Cloudflare អេ។ អេ។ អេ។ អេ-record ដែលមិនមាននៅក្នុងដែន Cloudflare បានឆ្លើយតប А- ធាតុដែលជាកំហុស និងមិនអនុលោមតាម RFC ។ ហេតុអ្វីបានជាអ្នកដោះស្រាយមូលដ្ឋាន (xxxx) ខ្ញុំមិនចូលចិត្តទេ ហើយគាត់បានឆ្លើយ SERVFAIL. ឥរិយាបថនេះអាចមើលឃើញយ៉ាងច្បាស់នៅក្នុងកំណត់ហេតុខាងក្រោម៖

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE  rcvd: 44

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; ANSWER SECTION:
semrushchina.cn.        300     IN      A       220.170.186.192

;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE  rcvd: 60

យើងបានបញ្ជូនរបាយការណ៍កំហុសទៅ Cloudflare ហើយពួកគេបានជួសជុលវាបន្ទាប់ពីពេលខ្លះ។ វាប្រែទៅជាគួរឱ្យចាប់អារម្មណ៍: នៅពេលនេះនៅតែមិនមានការគាំទ្រ IPv6 នៅក្នុងប្រទេសចិនដូច្នេះ Cloudflare មិនអាចចេញអាសយដ្ឋាន IPv6 របស់ខ្លួននៅទីនោះដើម្បីឆ្លើយតបទៅនឹងសំណើ អេ។ អេ។ អេ។ អេ-កំណត់ត្រា។ នៅទីបញ្ចប់ អ្វីគ្រប់យ៉ាងត្រូវបានដោះស្រាយតាមរបៀបដែល Cloudflare ចាប់ផ្តើមឆ្លើយតបសម្រាប់ប្រទេសចិន គ្មានទិន្នន័យ ទៅនឹងសំណើបែបនេះ។

ដូច្នេះ កំហុស DNS ក្នុងការធ្វើតេស្ត Catchpoint បានថយចុះយ៉ាងខ្លាំង ប៉ុន្តែមិនទាំងស្រុងទេ។ ការអស់ពេលនៅតែមាននៅទីនេះ៖

ហើយយើងបានចាប់ផ្តើមស្វែងរកដំណោះស្រាយមួយផ្សេងទៀត។

នៅផ្នែកបន្ទាប់ខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដែលយើងបានសាកល្បងពពកចិន អាលីបាបាពពកដោយមានជំនួយពី "វេទមន្ត" តិចតួចរបស់ Nginx យើងអាចបង្កើតដំណោះស្រាយ PoC (Proof of Concept) យ៉ាងឆាប់រហ័ស របៀបដែលយើងបង្កើតដំណោះស្រាយ Multi-Cloud ដែលជាដំណោះស្រាយមួយដែលទីបំផុតបានជួយបង្កើនល្បឿនការងាររបស់សេវាកម្ម។ ពីប្រទេសចិន។

ចាំមើល!