🥇ചൈനയിലെ മഹത്തായ ഫയർവാളിനെ നമ്മൾ എങ്ങനെ തകർത്തു (ഭാഗം 1)

ഹലോ എല്ലാവർക്കും!

നികിത ബന്ധപ്പെട്ടിരിക്കുന്നു - കമ്പനിയിൽ നിന്നുള്ള ഒരു സിസ്റ്റം എഞ്ചിനീയർ SEMrush. ചൈനയിലെ ഞങ്ങളുടെ semrush.com സേവനത്തിന്റെ സ്ഥിരത ഉറപ്പാക്കുന്നതിനുള്ള ചുമതല ഞങ്ങൾ എങ്ങനെ നേരിട്ടുവെന്നും അത് നടപ്പിലാക്കുമ്പോൾ ഞങ്ങൾ നേരിട്ട പ്രശ്‌നങ്ങളെക്കുറിച്ചും ഇന്ന് ഞാൻ നിങ്ങളോട് പറയും (യുണൈറ്റഡ് സ്റ്റേറ്റ്‌സിന്റെ കിഴക്കൻ തീരത്തുള്ള ഞങ്ങളുടെ ഡാറ്റാ സെന്ററിന്റെ സ്ഥാനം കണക്കിലെടുക്കുമ്പോൾ).

ഇത് ഒരു വലിയ കഥയായിരിക്കും, പല ലേഖനങ്ങളായി തിരിച്ചിരിക്കുന്നു. ഞങ്ങൾക്ക് ഇതെല്ലാം എങ്ങനെ സംഭവിച്ചുവെന്ന് ഞാൻ നിങ്ങളോട് പറയും: ചൈനയിൽ നിന്നുള്ള പൂർണ്ണമായും പ്രവർത്തനരഹിതമായ സേവനം മുതൽ അമേരിക്കക്കാർക്കുള്ള അമേരിക്കൻ പതിപ്പിന്റെ തലത്തിലുള്ള സേവനത്തിന്റെ പ്രകടന സൂചകങ്ങൾ വരെ. ഇത് രസകരവും ഉപയോഗപ്രദവുമാകുമെന്ന് ഞാൻ വാഗ്ദാനം ചെയ്യുന്നു. അതിനാൽ, നമുക്ക് പോകാം.

ചൈനീസ് ഇന്റർനെറ്റിന്റെ പ്രശ്നങ്ങൾ

നെറ്റ്‌വർക്ക് അഡ്മിനിസ്ട്രേഷന്റെ പ്രത്യേകതകളിൽ നിന്ന് ഏറ്റവും അകലെയുള്ള വ്യക്തി പോലും കേട്ടിട്ടുണ്ട് ചൈനയിലെ വലിയ ഫയർവാൾ. കൊള്ളാം, നന്നായി തോന്നുന്നു, അല്ലേ? എന്നാൽ അത് എന്താണെന്നും അത് യഥാർത്ഥത്തിൽ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും തികച്ചും സങ്കീർണ്ണമായ ഒരു ചോദ്യമാണ്. ഇന്റർനെറ്റിൽ ഇതിനായി നീക്കിവച്ചിരിക്കുന്ന നിരവധി ലേഖനങ്ങൾ നിങ്ങൾക്ക് കണ്ടെത്താൻ കഴിയും, എന്നാൽ ഒരു സാങ്കേതിക കാഴ്ചപ്പാടിൽ, ഈ ഫയർവാളിന്റെ ഘടന എവിടെയും വിവരിച്ചിട്ടില്ല. ഏതായാലും, അതിശയിക്കാനില്ല. ഒരു വർഷത്തെ ജോലിയുടെ ഫലത്തെ അടിസ്ഥാനമാക്കി, അത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് എനിക്ക് കൃത്യമായി പറയാൻ കഴിയില്ലെന്ന് ഞാൻ ഉടൻ സമ്മതിക്കും, പക്ഷേ എന്റെ അഭിപ്രായങ്ങളെയും പ്രായോഗിക നിഗമനങ്ങളെയും കുറിച്ച് എനിക്ക് നിങ്ങളോട് പറയാൻ കഴിയും. ഈ ഫയർവാളിനെക്കുറിച്ചുള്ള കിംവദന്തികളിൽ നിന്ന് ഞങ്ങൾ ആരംഭിക്കും.

ഈ ഫയർവാളിനെക്കുറിച്ച് നിരവധി കിംവദന്തികൾ ഉണ്ട്. അവയിൽ പ്രധാനവും രസകരവുമായവ നമുക്ക് ഒരു പട്ടികയിലേക്ക് ശേഖരിക്കാം:

ഗൂഗിൾ, ഫേസ്ബുക്ക്, ട്വിറ്റർ എന്നിവയും മറ്റ് സമാന സേവനങ്ങളും തടഞ്ഞു, ചൈനയിൽ പ്രവർത്തിക്കുന്നില്ല.
ചൈനയ്ക്ക് പുറത്ത് ചൈനയിലേക്ക് പോകുന്ന ഏത് ട്രാഫിക്കും മെഷീൻ ലേണിംഗ് (സംശയാസ്‌പദമായ ട്രാഫിക്കിന്റെ കാര്യത്തിൽ) ഉപയോഗിച്ച് പാഴ്‌സ് ചെയ്യുകയും പരിമിതപ്പെടുത്തുകയും ചെയ്യുന്നു, ഇത് അതിർത്തിയിലൂടെ കടന്നുപോകുന്നത് (ട്രാഫിക്) വളരെ മന്ദഗതിയിലാക്കുന്നു.
ചൈനീസ് രഹസ്യാന്വേഷണ ഏജൻസികൾ അവരുടെ ഫയർവാളിലൂടെ കടന്നുപോകുന്ന ഏത് എൻക്രിപ്റ്റഡ് ട്രാഫിക്കും ഹാക്ക് ചെയ്യും.
VPN ടണലുകൾ, IPSEC ടണലുകൾ എന്നിവ അസ്ഥിരമാണ്, തകരുകയും നിരന്തരം തടയുകയും ചെയ്യുന്നു.
ലളിതമായ എൻക്രിപ്ഷൻ, ട്രാഫിക് ആധികാരികമാക്കാൻ/എൻക്രിപ്റ്റ് ചെയ്യാൻ ഉപയോഗിക്കുന്ന പാസ് വാക്യം, ചൈനീസ് ഫയർവാളിലൂടെ വേഗത്തിൽ കടന്നുപോകുന്നു.

ഈ കിംവദന്തികളെക്കുറിച്ച് ഞങ്ങൾ കണ്ടെത്തിയത് ഇതാ:

ഗൂഗിൾ, ഫേസ്ബുക്ക്, ട്വിറ്റർ, മറ്റ് സമാന സേവനങ്ങൾ എന്നിവ തടയപ്പെട്ടിരിക്കുന്നു (നിങ്ങളുടെ കെഒ), എന്നാൽ നിരവധി സാങ്കേതിക ഗൂഗിൾ ഡൊമെയ്‌നുകൾ, ഉദാഹരണത്തിന്, നിരോധിച്ചിട്ടില്ല, പ്രവർത്തിക്കുന്നു (അതേ gstatic.com). ഇതിൽ നിന്നാണ് നിഗമനം: തടഞ്ഞതായി തോന്നുന്ന എല്ലാ Google-ഉം മറ്റ് ഉറവിടങ്ങളും നിങ്ങൾ അശ്രദ്ധമായി വെട്ടിമാറ്റരുത്.
അതിർത്തി കടന്നുപോകുന്ന ഏതൊരു ട്രാഫിക്കും അതിന്റെ സമയത്തിന് ഗുരുതരമായ കാലതാമസമുണ്ടാക്കുന്നു. രണ്ട് ഫലങ്ങൾ നോക്കൂ. ഒരു സൈറ്റ്, ഒരു പേജ്, ലളിതമായ GET ചുരുൾ'ഓം. ആദ്യത്തെ അളവ് ചൈനയിൽ നിന്ന് തന്നെയായിരുന്നു (ഷെൻഷെൻ എന്ന മനോഹരമായ നഗരം). രണ്ടാമത്തേത് ഹോങ്കോങ്ങിൽ നിന്ന് പുറത്ത് നിന്ന് അളന്നു (അതിന് പരമാധികാരമുണ്ട്, അതിനും ലോകത്തിനും ഇടയിൽ ഫയർവാൾ ഇല്ല). നേർരേഖയിൽ നഗരങ്ങൾ തമ്മിലുള്ള ദൂരം ഏകദേശം 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 ടണലുകൾ പലപ്പോഴും പരാജയപ്പെടുന്നു. ഞാൻ ഇതിനെക്കുറിച്ച് കുറച്ച് കഴിഞ്ഞ് കൂടുതൽ വിശദമായി സംസാരിക്കും. ഉപയോക്താക്കൾ ഉപയോഗിക്കുന്ന VPN സെർവറുകൾ കാലക്രമേണ ബ്ലോക്ക് ചെയ്യപ്പെടും (സാധാരണയായി ഉപയോഗം ആരംഭിച്ച് ഒരു ദിവസത്തിനുള്ളിൽ).
ചൈനയിൽ താമസിക്കുന്ന ആളുകളിൽ നിന്ന് ലഭിച്ച ഒരു അഭിപ്രായം ഉണ്ട്, ട്രാഫിക് എൻക്രിപ്ഷൻ ലളിതമാണ്, അത് വേഗത്തിൽ അതിർത്തിയിലൂടെ കടന്നുപോകുന്നു, കാരണം അതിൽ നിയമവിരുദ്ധമായി ഒന്നുമില്ലെന്ന് മനസ്സിലാക്കാൻ എളുപ്പമാണ്. അതുപോലെ, "വൃത്തിയുള്ള" ട്രാഫിക്കിന് കൂടുതൽ ബാൻഡ്‌വിഡ്ത്തും കടന്നുപോകാനുള്ള വേഗതയും ലഭിക്കുന്നു, അതേസമയം ഒന്നും മനസ്സിലാക്കാൻ കഴിയാത്ത "വൃത്തികെട്ട" ട്രാഫിക്ക്, നേരെമറിച്ച്, മന്ദഗതിയിലുള്ള പാത സ്വീകരിക്കുന്നു. ഉദാഹരണത്തിന് ഞാൻ ചുരുളൻ ഉപയോഗിക്കും ifconfig.co HTTPS, HTTP പ്രോട്ടോക്കോൾ വഴി.

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 സെക്കൻഡിന്റെ വ്യത്യാസം. മാത്രമല്ല, അത്തരം ഒരു ടെസ്റ്റ് നിരവധി തവണ ചെയ്യുമ്പോൾ, HTTP-യിൽ GET സാധാരണയായി ഓരോ തവണയും ഒരേ സമയം പൂർത്തിയാകുന്നത് നിങ്ങൾക്ക് കാണാൻ കഴിയും, അതേസമയം HTTPS-ൽ സൈറ്റ് ചിലപ്പോൾ 3, 5, 10, 17 സെക്കൻഡുകൾക്കുള്ളിൽ പ്രതികരിക്കും. ചിലപ്പോൾ SSL പിശകുകൾ സംഭവിക്കുന്നു:

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

അതിനാൽ നമുക്ക് എന്താണ് ഉള്ളത്:

ചൈനീസ് ഫയർവാൾ സൃഷ്ടിച്ച പ്രശ്നങ്ങൾ മുകളിൽ വിവരിച്ചിരിക്കുന്നു.
ബാഹ്യ ഉറവിടങ്ങളിലേക്കും തുരങ്കങ്ങളിലേക്കും ഉള്ള പിംഗുകൾ ഇടയ്ക്കിടെ അപ്രത്യക്ഷമാകുന്നു.
രണ്ട് പോയിന്റുകൾക്കിടയിലുള്ള ലേറ്റൻസി നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്നു, പലപ്പോഴും അത് പ്രവചനാതീതമാണ്. വ്യത്യസ്ത നഗരങ്ങൾ/പ്രദേശങ്ങൾ ബന്ധിപ്പിക്കുമ്പോൾ, പ്രദേശങ്ങളുടെ ഭൂമിശാസ്ത്രപരമായ സ്ഥാനം അനുസരിച്ച്, കാലതാമസം കുറവായിരിക്കുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നു, പക്ഷേ നിങ്ങൾക്ക് കൃത്യമായി വിപരീത സാഹചര്യം ലഭിക്കും.
ഇന്റർനെറ്റും ആശയവിനിമയ ചാനലുകളും ഒന്നുകിൽ വേഗതയേറിയതോ വേഗത കുറഞ്ഞതോ ആണ്. ആഴ്ചയിലെ ദിവസത്തിന്റെയും ദിവസത്തിന്റെയും സമയത്തെ ഒരു ചെറിയ ആശ്രിതത്വമുണ്ട്, പക്ഷേ എല്ലായ്പ്പോഴും അല്ല.
ചൈനയിൽ നിന്നുള്ള പുറം ലോകത്തേക്കുള്ള ഡിഎൻഎസ് അഭ്യർത്ഥനകൾ ചിലപ്പോൾ അനുവദനീയമായ സമയപരിധി കവിയുന്നു.

ഉയർന്നുവരുന്ന ചിത്രം "മികച്ചതാണ്".

ഡാറ്റാ സെന്റർ, ഞാൻ ഇതിനകം പറഞ്ഞതുപോലെ, കിഴക്കൻ യുണൈറ്റഡ് സ്റ്റേറ്റ്സിലാണ്, കൂടാതെ മുഴുവൻ SEMrush-ലും ഡസൻ കണക്കിന് പരസ്പരം ബന്ധിപ്പിച്ച ഉൽപ്പന്നങ്ങൾ, ബാക്കെൻഡുകൾ, ഫ്രണ്ട്‌എൻഡുകൾ, ഡാറ്റാബേസുകൾ എന്നിവയും ഡിസിയിലും ക്ലൗഡുകളിലും ഉള്ളതാണ്. സിസ്റ്റം അഡ്മിനിസ്‌ട്രേറ്റർമാരുടെ ഒരു ടീം എന്ന നിലയിൽ ഞങ്ങൾക്ക് ചൈനയിൽ ചെറിയ പ്രയത്‌നമില്ലാതെ വേഗത്തിൽ പ്രവർത്തിക്കാനുള്ള ചുമതല നൽകി.

ഞങ്ങൾക്ക് ഒരു പ്രധാന ചോദ്യത്തിന് ഉത്തരം നൽകേണ്ടതായി വന്നു: കുറഞ്ഞ ചെലവിൽ അത് പരിഹരിക്കാനും നെറ്റ്‌വർക്ക് / ക്ലൗഡ് / സെർവർ തലത്തിൽ ചൈനീസ് ഇന്റർനെറ്റ്, ഫയർവാളുമായി ബന്ധപ്പെട്ട എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കാനും കഴിയുമോ?

സ്വീകരിച്ചുകൊണ്ട് ഞങ്ങൾ ആരംഭിച്ചു ഐസിപി- ലൈസൻസുകൾ.

ICP ലൈസൻസ്

ചൈനയിൽ (മെയിൻലാൻഡ് ചൈന) നിങ്ങളുടെ സേവനം ഹോസ്റ്റുചെയ്യുന്നതിനും പരിശോധനകൾ നടത്തുന്നതിനും, നിങ്ങൾ ആദ്യം ഡൊമെയ്‌നിനായി ഒരു ICP ലൈസൻസ് നേടണം.

മെയിൻലാൻഡ് ചൈനയിൽ നിങ്ങളുടെ സൈറ്റിന്റെ ഉപയോക്തൃ ട്രാഫിക് അവസാനിപ്പിക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ ഡൊമെയ്‌നിന് ICP ലൈസൻസ് ഇല്ലെങ്കിൽ, നിങ്ങളുടെ ട്രാഫിക് ISP/ഹോസ്റ്റിംഗ് ഭാഗത്ത് തടയപ്പെടും. കൗതുകകരമെന്നു പറയട്ടെ, ICP ലൈസൻസിൽ ഒരു നിർദ്ദിഷ്ട ദാതാവ് ഉൾപ്പെടുന്നു, അത് Cloudflare അല്ലെങ്കിൽ Alibaba ക്ലൗഡ് ആകട്ടെ. അതിനാൽ, ക്ലൗഡ്ഫ്ലെയറിനായി നിങ്ങൾക്ക് ഒരു ഐസിപി ലൈസൻസ് ലഭിക്കുകയും അവരോടൊപ്പം നിങ്ങളുടെ വെബ്‌സൈറ്റ് ഹോസ്റ്റ് ചെയ്യുകയും ചെയ്താൽ, നിങ്ങൾക്ക് അലിബാബ ക്ലൗഡിലേക്ക് "സുഗമമായി" നീങ്ങാൻ കഴിയില്ല. ഈ ലൈസൻസിലേക്ക് നിങ്ങൾ മറ്റൊരു ഹോസ്റ്റിംഗ് ചേർക്കേണ്ടതുണ്ട്.

ഡൊമെയ്‌നിനായി ഒരു ICP ലൈസൻസ് ലഭിച്ചതിനാൽ, നിർദ്ദിഷ്ട സാങ്കേതിക ആശയങ്ങളും പരിഹാരങ്ങളും കൊണ്ടുവരാനും നടപ്പിലാക്കാനും ഞങ്ങൾക്ക് കഴിഞ്ഞു.

പരിഹാരങ്ങൾ പരിശോധിക്കുന്നു

എന്നാൽ നിങ്ങൾ നേരിട്ട് സ്റ്റേജിംഗ് ഓപ്‌ഷനുകൾ സൃഷ്‌ടിക്കുന്നതിന് മുമ്പ്, നോബുകൾ തിരിക്കുക, സൈറ്റിന്റെ പ്രകടനവും അതിന്റെ വേഗതയും ഒപ്റ്റിമൈസ് ചെയ്യുക, ഞങ്ങളുടെ ഏത് പ്രവർത്തനമാണ് മെച്ചപ്പെടുന്നതെന്നോ നേരെമറിച്ച് സൈറ്റിന്റെ പ്രകടനം മോശമാക്കുന്നതിനോ നിങ്ങൾ അത് പരിശോധിക്കുന്നതിനുള്ള ഒരു ഉപകരണം തിരഞ്ഞെടുക്കേണ്ടതുണ്ട്.

ഞങ്ങളുടെ ടെസ്റ്റിംഗ് ടൂൾ രണ്ട് പ്രധാന ആവശ്യകതകൾ പാലിക്കേണ്ടതുണ്ട്:

ഇതിന് ചൈനയിൽ നിന്ന് പരീക്ഷണങ്ങൾ നടത്താൻ കഴിയണം,
അതിന് ബ്രൗസർ ടെസ്റ്റുകൾ ഉണ്ടായിരിക്കണം.

അങ്ങനെ ഞങ്ങൾ കണ്ടെത്തി ചത്ഛ്പൊഇംത്! ലോകമെമ്പാടുമുള്ള ടെസ്റ്റിംഗ് ലൊക്കേഷനുകളുടെ മികച്ച കവറേജ് അവർക്ക് ഉണ്ട്. ചൈനയിൽ, ഈ ടൂൾ വഴി 100500 പ്രവിശ്യകളിൽ നിന്നും ടെസ്റ്റുകൾ നടത്താം. ഓരോരുത്തർക്കും നിരവധി വ്യത്യസ്ത ദാതാക്കളുണ്ട് + ചെയ്യാനുള്ള കഴിവ് ബാക്ക്ബോൺ-ടെസ്റ്റുകൾ (ഒരു ഡാറ്റാ സെന്ററിലെ വെർച്വൽ മെഷീൻ പോലെയുള്ള ഒന്ന്) കൂടാതെ ലാസ്റ്റ്മൈൽ-ടെസ്റ്റുകൾ (ഉപയോക്തൃ വ്യവസ്ഥകൾക്ക് കഴിയുന്നത്ര അടുത്ത്, അല്ലെങ്കിൽ വർക്ക്സ്റ്റേഷൻ). അവസാന തരം ടെസ്റ്റുകൾ കൂടുതൽ ചെലവേറിയതാണ്.

ഒരു വാർഷിക കരാർ അവസാനിപ്പിച്ച ശേഷം (അതിൽ കുറവ് സാധ്യമല്ല), ഞങ്ങൾ ഉപകരണം പഠിക്കാൻ തുടങ്ങി. സത്യം പറഞ്ഞാൽ, അതിന്റെ പ്രവർത്തനക്ഷമതയിൽ ഞങ്ങൾ ആശ്ചര്യപ്പെട്ടു. നിങ്ങൾക്ക് പ്രവർത്തിപ്പിക്കാൻ കഴിയും:

DNS ടെസ്റ്റുകൾ,
വെബ് ടെസ്റ്റുകൾ (ബ്രൗസർ ടെസ്റ്റുകൾ, ലളിതമായ GET/POST, മൊബൈൽ ക്ലയന്റ് എമുലേഷൻ മുതലായവ),
ഇടപാട് പരിശോധനകൾ (ഉദാഹരണത്തിന്, ലോഗിൻ),
API ടെസ്റ്റുകൾ,
പിംഗ്, ട്രേസറൗട്ട്, എൻടിപി മുതലായവ.

നിങ്ങൾക്ക് എല്ലാം പട്ടികപ്പെടുത്താൻ കഴിയില്ല. ഏറ്റവും പ്രധാനമായി, ഒരു കൂട്ടം തലക്കെട്ടുകളും മറ്റ് പാരാമീറ്ററുകളും ചേർത്ത് ഓരോ ടെസ്റ്റും നന്നായി ഇച്ഛാനുസൃതമാക്കാനാകും. നിങ്ങളുടെ പരിശോധനയെ പൂർണ്ണമായി വിവരിക്കുന്ന ഒരു വലിയ അളവിലുള്ള വിവരമാണ് ഔട്ട്പുട്ട്. ഞങ്ങൾക്ക് ഏറ്റവും രസകരമായ കാര്യങ്ങളെക്കുറിച്ച് സംസാരിക്കുകയാണെങ്കിൽ (ബ്രൗസർ ടെസ്റ്റുകൾ), ഫലത്തിൽ ഇവ ഉൾപ്പെടുന്നു:

ബന്ധിപ്പിക്കുക, കാത്തിരിക്കുക, ലോഡ് ചെയ്യുക, SSL, DNS സമയം,
TTFB, TTLB, ഡോക്യുമെന്റ് പൂർത്തിയായി, റെൻഡർ സമയം, DOM ലോഡ്,
പ്രതികരണം (ടൈം ടു ഫസ്റ്റ് ബൈറ്റിന് സമീപമുള്ളത്), വെബ്‌പേജ് പ്രതികരണം (ടൈം ടു ലാസ്റ്റ് ബൈറ്റിന് അടുത്തുള്ള ചിലത്),
ഏതെങ്കിലും ശതമാനം, ശരാശരി, ശരാശരി സമയം
തുടങ്ങിയവ.

അതനുസരിച്ച്, മാറ്റങ്ങൾ കാണുന്നതിനും കാര്യങ്ങൾ മെച്ചപ്പെട്ടിട്ടുണ്ടോ എന്ന് മനസ്സിലാക്കുന്നതിനും ഈ അളവുകളെല്ലാം മികച്ചതാണ്. ഞങ്ങൾ പ്രധാനമായും നോക്കിയത് പ്രതികരണം, വെബ്‌പേജ് പ്രതികരണം, മീഡിയൻ, 75, 95 ശതമാനം.

തുടക്കം മുതൽ അന്തരീക്ഷത്തിൽ ഉണ്ടായിരുന്ന ഒരു പ്രധാന ചോദ്യം: നിങ്ങൾക്ക് ക്യാച്ച്‌പോയിന്റിനെ വിശ്വസിക്കാമോ?? ഈ ടൂൾ വിവിധ നഗരങ്ങളിൽ നിന്ന് ചൈനയിലെ യഥാർത്ഥ സൈറ്റ് ലോഡിംഗ് വേഗതയെ പ്രതിഫലിപ്പിക്കുന്നുണ്ടോ, അതോ യഥാർത്ഥ ഉപയോക്തൃ അനുഭവവുമായി യാതൊരു ബന്ധവുമില്ലാത്ത ഒരു ശൂന്യതയിലെ ഏതെങ്കിലും തരത്തിലുള്ള പരീക്ഷണമാണോ?
ഇത് ഒരു വലിയ പ്രശ്നമാണ്, കാരണം റഷ്യയിലായിരിക്കുമ്പോൾ ചൈനയിൽ നിന്നുള്ള ഒരു സൈറ്റ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് വിശ്വസനീയമായി കണ്ടെത്തുന്നത് മിക്കവാറും അസാധ്യമാണ്. ഒരു വെർച്വൽ മെഷീനിലൂടെ സോക്സ്-പ്രോക്സി ചെയ്യുന്നതിലൂടെ, അന്തിമഫലം രണ്ട് മിനിറ്റുകൾക്കുള്ളിൽ സൈറ്റ് ലോഡുചെയ്യുന്നു, ഇത് ടെസ്റ്റുകൾക്ക് അസ്വീകാര്യമാണ്, അതിനാൽ മാനുവൽ ടെസ്റ്റിംഗിനുള്ള ഏക ഓപ്ഷൻ ചുരുളൻ, ടൈമർ ഉപയോഗിച്ച് കൺസോളിൽ നിന്ന് ലളിതമായി നേടുക എന്നതാണ്. . ഈ ടെസ്റ്റ് നെറ്റ്‌വർക്ക് പരിഹാരത്തിന്റെ വേഗതയെ നന്നായി പ്രതിഫലിപ്പിക്കുന്നതിനാൽ ഇത് സഹായിക്കുന്നു, കൂടാതെ ബ്രൗസർ ടെസ്റ്റുകളും ഉണ്ടെങ്കിൽ, അത് വളരെ നല്ലതാണ്.

പിന്നീട് ഞങ്ങൾ തന്നെ ചൈനയിൽ പോയി അത് ബോധ്യപ്പെട്ടു നിങ്ങൾക്ക് ക്യാച്ച് പോയിന്റിനെ വിശ്വസിക്കാം; ഇത് യഥാർത്ഥ പ്രകടന സൂചകങ്ങളെ കൃത്യമായി പ്രതിഫലിപ്പിക്കുന്നു.

ക്ലൗഡ്ഫ്ലെയർ ചൈന നെറ്റ്‌വർക്ക്

semrush.com എന്ന പ്രധാന ഡൊമെയ്‌നിനായി ഞങ്ങൾ Cloudflare വിജയകരമായി ഉപയോഗിക്കുന്നതിനാൽ, അവരുടെ ഫീച്ചർ എന്ന് വിളിക്കപ്പെടുന്ന ഫീച്ചർ ഉടൻ പരീക്ഷിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ചൈന നെറ്റ്‌വർക്ക്. എന്റർപ്രൈസ് സൈറ്റുകൾക്ക് പ്രത്യേക അഭ്യർത്ഥനയ്ക്കും അധിക ഫീസിനും മാത്രമേ ഈ ഓപ്‌ഷൻ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുള്ളൂ. ക്ലൗഡ്ഫ്ലെയർ ദാതാവായി ലിസ്റ്റ് ചെയ്യുന്ന ഉചിതമായ ICP ലൈസൻസുള്ള സൈറ്റുകൾക്ക് മാത്രമേ ഇത് ലഭ്യമാകൂ. ഇത് പ്രവർത്തനക്ഷമമാക്കിയതിന് ശേഷം, Cloudflare-ൽ നിന്നുള്ള “ചൈനീസ് CDN” സൈറ്റിന് ലഭ്യമാകും - ചൈനീസ് പ്രദേശങ്ങളിൽ നിന്നുള്ള ട്രാഫിക് അടുത്തുള്ള PoP (Points of Presence) CF-ൽ എത്തുന്നു, തുടർന്ന് അതിന്റെ നെറ്റ്‌വർക്കുകൾ വഴിയോ ദാതാക്കളുടെ/പങ്കാളികളുടെ നെറ്റ്‌വർക്കുകൾ വഴിയോ അത് ഉത്ഭവസ്ഥാനത്ത് എത്തിക്കുന്നു. .

ഈ ടെസ്റ്റ് ബെഞ്ചിന്റെ ഡയഗ്രം ചുവടെ അവതരിപ്പിച്ചിരിക്കുന്നു.

ഇത് ഞങ്ങൾക്ക് ഒരു മികച്ച ഓപ്ഷനാണ്. രണ്ടാമത്തെ ഡൊമെയ്‌നും CF-നുള്ളതായിരിക്കുമെന്ന് ഇത് മാറുന്നു, ഇത് കമ്പനിയിൽ ഉപയോഗിക്കുന്ന പരിഹാരങ്ങളുടെ എണ്ണത്തിൽ ചേർക്കുന്നില്ല, മാത്രമല്ല അടിസ്ഥാന സൗകര്യങ്ങളെ പ്രായോഗികമായി സങ്കീർണ്ണമാക്കുന്നില്ല.

ഞങ്ങൾ ബ്രൗസർ ടെസ്റ്റുകൾ നടത്തി, ഇതാണ് സംഭവിച്ചത്:

ചുവന്ന വജ്രങ്ങൾ പരീക്ഷണ പരാജയമാണ്. ചുവടെയുള്ള ഫയലുകൾ DNS പിശകുകളാണ് (കാലഹരണപ്പെടൽ പരിഹരിക്കുക). മുകളിലെ പരാജയങ്ങൾ സമയപരിധിയാണ്.

പ്രവർത്തനസമയം: 86.6
മീഡിയൻ: 18സെ
75 ശതമാനം: 29.3സെ
95 ശതമാനം: 60സെ

മീഡിയൻ, ലോഡ് ചെയ്ത ശേഷം നീക്കം ചെയ്തു reCAPTCHA (ചൈനയിൽ ഗൂഗിൾ സേവനം തടഞ്ഞു) 28ൽ നിന്ന് 18 സെക്കൻഡായി കുറഞ്ഞു. semrush.com (യുഎസിൽ നിന്നുള്ള) അതേ ടെസ്റ്റ് അതേ പേജിലെ (സ്റ്റാറ്റിക് + ഡൈനാമിക്) 10% ഉപയോക്താക്കൾക്ക് (യുഎസിൽ നിന്ന്) 95 സെക്കൻഡിൽ താഴെ സമയം നൽകിയത് പരിഗണിക്കുമ്പോൾ, ഇവ ഇപ്പോഴും ഭയാനകമായ ഫലങ്ങളാണ്.

ഓരോ പരീക്ഷയിലും പോയി നോക്കാം വെള്ളച്ചാട്ടം മറ്റ് കൂടുതൽ വിശദമായ പാരാമീറ്ററുകൾ. പിശകുകളുടെ കാരണങ്ങൾ ഞങ്ങൾ അന്വേഷിക്കാൻ തുടങ്ങി, കാലഹരണപ്പെടുന്നതിന് എല്ലാം കൂടുതലോ കുറവോ വ്യക്തമാണെങ്കിൽ: ചൈനയിലെ ഇന്റർനെറ്റ് “അകത്തേക്കും പുറത്തേക്കും നീങ്ങുന്നു”, ഇക്കാരണത്താൽ, വിദേശത്ത് നിന്നുള്ള ഉറവിടങ്ങളുടെ കണക്ഷന്റെയും ലോഡിംഗിന്റെയും വേഗത അസ്ഥിരവും അസമവുമാണ്, DNS പിശകുകൾ ഞങ്ങളെ വളരെയധികം അത്ഭുതപ്പെടുത്തി. ഞങ്ങൾ അത് കണ്ടെത്തി പോ ക്ലൗഡ്ഫ്ലെയർ യഥാർത്ഥത്തിൽ ചൈനയിലാണ് സ്ഥിതി ചെയ്യുന്നത്, സൈറ്റ് വിലാസം ഒരു ഏതെങ്കിലും ഐപിയിലേക്ക് പരിഹരിക്കുന്നു, എന്നാൽ DNS സെർവറുകൾ അമേരിക്കൻ ആണ്, അതുകൊണ്ടാണ് DNS അഭ്യർത്ഥനകൾ അതിർത്തി കടക്കാൻ നിർബന്ധിതമാകുന്നത്, അതിനാൽ ചിലപ്പോൾ അവ പരാജയപ്പെടും.

സിഎഫുമായി ഈ ചോദ്യം വ്യക്തമാക്കിയ ശേഷം, അത് മാറി അവർക്ക് ചൈനയിൽ സ്വന്തമായി DNS സെർവറുകൾ ഇല്ല, അത് എപ്പോൾ ആയിരിക്കുമെന്ന് ഇപ്പോഴും അജ്ഞാതമാണ്.

അതിനാൽ, ക്ലൗഡ്ഫ്ലെയർ ഡിഎൻഎസ് മാത്രം പരീക്ഷിക്കാൻ ഞങ്ങൾ തീരുമാനിക്കുകയും ഞങ്ങളുടെ സൈറ്റിനായുള്ള ക്ലൗഡ്ഫ്ലെയർ ഓപ്പറേറ്റിംഗ് മെക്കാനിസം "DNS മാത്രം" ക്ലൗഡ്ഫ്ലെയർ ട്രാഫിക്ക് പ്രോക്സി ചെയ്യാത്തപ്പോൾ ഇതൊരു മോഡാണ്, അതായത് ഇത് DDoS പരിരക്ഷയും CDN-ഉം മറ്റ് സവിശേഷതകളും നൽകുന്നില്ല, കൂടാതെ ഒരു സാധാരണ DNS സെർവറിന്റെ മോഡിൽ പ്രവർത്തിക്കുന്നു.

ഈ നിലപാട് ഇനിപ്പറയുന്ന ചിത്രത്തിൽ സ്കീമാറ്റിക് ആയി കാണിച്ചിരിക്കുന്നു. ക്ലൗഡ്ഫ്ലെയറിന്റെ ഡിഎൻഎസ് സെർവറുകൾ ഒരു ഫയർവാളിന് പിന്നിലാണെന്ന ഉയർന്നുവരുന്ന അറിവ് കണക്കിലെടുത്താണ് ചിത്രം.

ക്യാച്ച്‌പോയിന്റിൽ ഞങ്ങൾ ലളിതമായ GET ടെസ്റ്റുകൾ നടത്തി (ബ്രൗസർ ടെസ്റ്റുകളല്ല), അത് ഒരുപാട് പരാജയങ്ങൾ കാണിച്ചു. അതേ DNS പിശകുകൾ മൂലമാണ് അവ സംഭവിച്ചത്.

ഉപയോഗിച്ച് ഞങ്ങൾ ഈ പിശകുകൾ ഡീബഗ്ഗ് ചെയ്യാൻ തുടങ്ങി കുഴിക്കുക ആദ്യത്തെ അഭ്യർത്ഥനയിൽ വിലാസം ശരിയായി നിർണ്ണയിക്കപ്പെടുന്നുവെന്നും ആവർത്തിച്ചുള്ള അഭ്യർത്ഥനയിൽ ഞങ്ങൾക്ക് ഓരോ തവണയും ലഭിക്കുന്നുവെന്നും കണ്ടെത്തി സെർവ്ഫെയിൽ и കാണ്മാനില്ല. എന്തുകൊണ്ടാണ് ഇത് പെട്ടെന്ന് സംഭവിക്കുന്നത്?

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

ഇതിനർത്ഥം പ്രശ്നം "ലോക്കൽ" ഡിഎൻഎസ് സെർവറിന്റെയോ ദാതാവിന്റെ സെർവറിന്റെയോ വശത്താണെന്നാണ്.
തുടർന്നുള്ള അന്വേഷണത്തിലാണ് ഇക്കാര്യം വ്യക്തമായത് സെർവ്ഫെയിൽ ഞങ്ങൾ തീരുമാനത്തിലെത്തുന്നു AAAA-രേഖകള്.

ക്ലൗഡ്ഫ്ലെയറിൽ നിന്ന് അഭ്യർത്ഥിച്ചപ്പോൾ അത് മാറി AAAAഡൊമെയ്‌നിൽ നിലവിലില്ലാത്ത റെക്കോർഡ്, ക്ലൗഡ്ഫ്ലെയർ പ്രതികരിച്ചു А-ഒരു പിശകും RFC-യുമായി പൊരുത്തപ്പെടാത്തതുമായ ഒരു എൻട്രി. എന്തുകൊണ്ടാണ് ലോക്കൽ റിസോൾവർ (xxxx) എനിക്കത് ഇഷ്ടപ്പെട്ടില്ല, അവൻ മറുപടി പറഞ്ഞു സെർവ്ഫെയിൽ. താഴെയുള്ള ലോഗിൽ ഈ സ്വഭാവം വ്യക്തമായി കാണാം:

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

ഞങ്ങൾ ക്ലൗഡ്ഫ്ലെയറിലേക്ക് ഒരു ബഗ് റിപ്പോർട്ട് സമർപ്പിച്ചു, കുറച്ച് സമയത്തിന് ശേഷം അവർ അത് പരിഹരിച്ചു. ഇത് രസകരമായി മാറി: ഇപ്പോൾ ചൈനയിൽ IPv6 പിന്തുണയില്ല, അതിനാൽ ഒരു അഭ്യർത്ഥനയ്ക്ക് മറുപടിയായി Cloudflare-ന് അതിന്റെ IPv6 വിലാസം അവിടെ നൽകാൻ കഴിഞ്ഞില്ല. AAAA-രേഖകള്. അവസാനം, ക്ലൗഡ്ഫ്ലെയർ ചൈനയ്ക്ക് ഉത്തരം നൽകാൻ തുടങ്ങിയ വിധത്തിൽ എല്ലാം പരിഹരിച്ചു ഡാറ്റാ ഇല്ല അത്തരം അഭ്യർത്ഥനകൾക്ക്.

അങ്ങനെ, ക്യാച്ച്‌പോയിന്റ് ടെസ്റ്റുകളിലെ DNS പിശകുകൾ കുത്തനെ കുറഞ്ഞു, പക്ഷേ പൂർണ്ണമായും അല്ല. ടൈംഔട്ടുകൾ ഇപ്പോഴും ഇവിടെയുണ്ട്:

ഞങ്ങൾ മറ്റൊരു പരിഹാരം തേടാൻ തുടങ്ങി.

ഞങ്ങൾ ചൈനീസ് ക്ലൗഡ് എങ്ങനെ പരീക്ഷിച്ചുവെന്ന് അടുത്ത ഭാഗത്ത് ഞാൻ നിങ്ങളോട് പറയും അലിബാബ ക്ലൗഡ്, എങ്ങനെ, Nginx-ന്റെ ഒരു ചെറിയ "മാജിക്കിന്റെ" സഹായത്തോടെ, ഞങ്ങൾക്ക് PoC (പ്രൂഫ് ഓഫ് കോൺസെപ്റ്റ്) സൊല്യൂഷനുകൾ വേഗത്തിൽ സൃഷ്ടിക്കാൻ കഴിഞ്ഞു, ഞങ്ങൾ എങ്ങനെ മൾട്ടി-ക്ലൗഡ് സൊല്യൂഷനുകൾ സൃഷ്ടിച്ചു, അതിലൊന്ന് സേവനത്തിന്റെ പ്രവർത്തനം വേഗത്തിലാക്കാൻ ആത്യന്തികമായി സഹായിച്ചു. ചൈനയിൽ നിന്ന്.

ഇവിടെത്തന്നെ നിൽക്കുക!