CDN નો ઉપયોગ કરો

સાઇટની ઝડપને ઑપ્ટિમાઇઝ કરવા માટે લગભગ દરેક લેખ અથવા સાધનમાં "CDN નો ઉપયોગ કરો" નો સાધારણ કલમ છે. સામાન્ય રીતે, CDN એ સામગ્રી વિતરણ નેટવર્ક અથવા સામગ્રી વિતરણ નેટવર્ક છે. અમે મેથડ લેબમાં વારંવાર આ વિષય પર ક્લાયંટ તરફથી પ્રશ્નોનો સામનો કરીએ છીએ; તેમાંથી કેટલાક તેમના પોતાના CDN ને સક્ષમ કરે છે. આ લેખનો હેતુ એ સમજવાનો છે કે CDN સાઇટ લોડ કરવાની ગતિના સંદર્ભમાં શું પ્રદાન કરી શકે છે, કઈ સમસ્યાઓ ઊભી થઈ શકે છે અને કયા કિસ્સાઓમાં CDN નો ઉપયોગ વાજબી છે.

ચિત્રમાં વિલંબ CDN ના ઉપયોગને કારણે થાય છે.

ઇતિહાસ એક બીટ

ઘણી ટેક્નોલોજીની જેમ, CDN એ આવશ્યકતામાંથી બહાર આવ્યું છે. ઇન્ટરનેટ વપરાશકર્તાઓમાં ઇન્ટરનેટ ચેનલોના વિકાસ સાથે, ઑનલાઇન વિડિઓ સેવાઓ દેખાઈ. સ્વાભાવિક રીતે, વિડિયો સામગ્રીને નિયમિત વેબસાઇટ સામગ્રી (ચિત્રો, ટેક્સ્ટ અને CSS અથવા JS કોડ) ની તુલનામાં વધુ બેન્ડવિડ્થની તીવ્રતાના ઓર્ડરની જરૂર છે.

જ્યારે એક સર્વરમાંથી ઘણા ક્લાયન્ટ્સની સમાંતર વિડિઓ સ્ટ્રીમ પ્રસારિત કરવાનો પ્રયાસ કરવામાં આવે છે, ત્યારે સર્વરની ઈન્ટરનેટ ચેનલ સંભવતઃ અડચણ બની જશે. નિયમ પ્રમાણે, સામાન્ય સર્વર ચેનલને ક્લોગ કરવા માટે થોડા હજાર થ્રેડો પૂરતા છે. અલબત્ત, અન્ય સંસાધન મર્યાદાઓ હોઈ શકે છે, પરંતુ તે અત્યારે મહત્વપૂર્ણ નથી. તે પણ મહત્વનું છે કે સર્વર ચેનલનું વિસ્તરણ ખૂબ ખર્ચાળ છે (અને ક્યારેક અશક્ય), અને અવ્યવહારુ પણ છે. પ્રસારણ દરમિયાન ચેનલ પરનો ભાર ચક્રીય હશે.

વ્યક્તિગત સર્વરની ચેનલને મર્યાદિત કરવાની સમસ્યા સીડીએન દ્વારા સંપૂર્ણ રીતે હલ થાય છે. ક્લાયન્ટ સીધા સર્વર સાથે કનેક્ટ થતા નથી, પરંતુ CDN નેટવર્કમાં નોડ્સ સાથે. આદર્શ પરિસ્થિતિમાં, સર્વર CDN નોડ પર એક સ્ટ્રીમ મોકલે છે, અને પછી નેટવર્ક ઘણા વપરાશકર્તાઓ સુધી આ સ્ટ્રીમ પહોંચાડવા માટે તેના પોતાના સંસાધનોનો ઉપયોગ કરે છે. આર્થિક દૃષ્ટિકોણથી, અમે ખરેખર વપરાશમાં લેવાયેલા સંસાધનો માટે જ ચૂકવણી કરીએ છીએ (આ બેન્ડવિડ્થ અથવા ટ્રાફિક હોઈ શકે છે) અને અમારી સેવાની ઉત્તમ માપનીયતા મેળવીએ છીએ. ભારે સામગ્રી પહોંચાડવા માટે CDN નો ઉપયોગ કરવો સંપૂર્ણપણે ન્યાયી અને તાર્કિક છે. જો કે તે નોંધવું યોગ્ય છે કે આ જગ્યાના સૌથી મોટા ખેલાડીઓ (દા.ત. નેટફ્લિક્સ) મોટા કોમર્શિયલ સીડીએન (અકામાઈ, ક્લાઉડફ્લેર, ફાસ્ટલી, વગેરે) નો ઉપયોગ કરવાને બદલે તેમના પોતાના સીડીએન બનાવી રહ્યા છે.

જેમ જેમ વેબનો વિકાસ થયો છે તેમ તેમ વેબ એપ્લિકેશનો પોતે વધુ જટિલ અને જટિલ બની છે. લોડિંગ સ્પીડની સમસ્યા સામે આવી. વેબસાઈટ સ્પીડના ઉત્સાહીઓએ ઘણી મોટી સમસ્યાઓને ઝડપથી ઓળખી કાઢી જેના કારણે વેબસાઈટ ધીમે ધીમે લોડ થાય છે. તેમાંથી એક નેટવર્ક વિલંબ (RTT - રાઉન્ડ ટ્રીપ સમય અથવા પિંગ સમય) હતો. વિલંબ વેબસાઇટ લોડિંગમાં ઘણી પ્રક્રિયાઓને અસર કરે છે: TCP કનેક્શન સ્થાપિત કરવું, TLS સત્ર શરૂ કરવું, દરેક વ્યક્તિગત સંસાધન લોડ કરવું (છબી, JS ફાઇલ, HTML દસ્તાવેજ, વગેરે.)

સમસ્યા એ હકીકતને કારણે વધી ગઈ હતી કે HTTP/1.1 પ્રોટોકોલનો ઉપયોગ કરતી વખતે (SPDY, QUIC અને HTTP/2ના આગમન પહેલાં આ એકમાત્ર વિકલ્પ હતો), બ્રાઉઝર્સ એક હોસ્ટ માટે 6 કરતાં વધુ TCP કનેક્શન ખોલતા નથી. આ બધું કનેક્શન ડાઉનટાઇમ અને ચેનલ બેન્ડવિડ્થના બિનકાર્યક્ષમ ઉપયોગ તરફ દોરી ગયું. સમસ્યાને આંશિક રીતે ડોમેન શાર્ડિંગ દ્વારા હલ કરવામાં આવી હતી - કનેક્શન્સની સંખ્યા પરની મર્યાદાને દૂર કરવા માટે વધારાના હોસ્ટની રચના.

આ તે છે જ્યાં CDN ની બીજી ક્ષમતા દેખાય છે - મોટી સંખ્યામાં પોઈન્ટ અને નોડ્સની વપરાશકર્તાની નિકટતાને કારણે લેટન્સી (RTT) ઘટાડવા. અંતર અહીં નિર્ણાયક ભૂમિકા ભજવે છે: પ્રકાશની ગતિ મર્યાદિત છે (ઓપ્ટિકલ ફાઈબરમાં લગભગ 200 કિમી/સેકંડ). આનો અર્થ એ છે કે દરેક 000 કિમીની મુસાફરી RTTમાં 1000 ms વિલંબ અથવા 5 ms ઉમેરે છે. આ ટ્રાન્સમિશન માટે જરૂરી ન્યૂનતમ સમય છે, કારણ કે મધ્યવર્તી સાધનો પર પણ વિલંબ થાય છે. CDN સામાન્ય રીતે તેના સર્વર પર ઑબ્જેક્ટને કેવી રીતે કૅશ કરવું તે જાણે છે, તેથી અમે CDN દ્વારા આવા ઑબ્જેક્ટ્સને લોડ કરવાથી ફાયદો મેળવી શકીએ છીએ. આ માટે જરૂરી શરતો: કેશમાં ઑબ્જેક્ટની હાજરી, વેબ એપ્લિકેશન સર્વર (ઓરિજિન સર્વર) ની તુલનામાં વપરાશકર્તા માટે CDN પોઇન્ટની નિકટતા. તે સમજવું અગત્યનું છે કે CDN નોડની ભૌગોલિક નિકટતા ઓછી વિલંબની ખાતરી આપતી નથી. ક્લાયંટ અને સીડીએન વચ્ચે રૂટીંગ એવી રીતે બનાવી શકાય છે કે ક્લાયંટ બીજા દેશમાં અને સંભવતઃ બીજા ખંડમાં હોસ્ટ સાથે જોડાય. આ તે છે જ્યાં ટેલિકોમ ઓપરેટર્સ અને CDN સેવા (પીઅરિંગ, કનેક્શન, IX માં ભાગીદારી વગેરે) અને CDN ની ટ્રાફિક રૂટીંગ નીતિ વચ્ચેનો સંબંધ અમલમાં આવે છે. ઉદાહરણ તરીકે, Cloudflare, જ્યારે બે પ્રારંભિક યોજનાઓ (મફત અને સસ્તી) નો ઉપયોગ કરે છે, ત્યારે નજીકના હોસ્ટ તરફથી સામગ્રીની ડિલિવરીની બાંયધરી આપતું નથી - ન્યૂનતમ ખર્ચ હાંસલ કરવા માટે હોસ્ટની પસંદગી કરવામાં આવશે.

ઘણી અગ્રણી ઈન્ટરનેટ કંપનીઓ લોડિંગ સ્પીડ અને વેબસાઈટની કામગીરીના વિષય પર જાહેર હિત (વેબ ડેવલપર્સ અને સેવા માલિકોને) આકર્ષે છે. આ કંપનીઓમાં Yahoo (Yslow tool), AOL (WebPageTest) અને Google (Page Speed ​​Insights service), જે સાઇટ્સને ઝડપી બનાવવા માટે તેમની પોતાની ભલામણો વિકસાવી રહી છે (મુખ્યત્વે તેઓ ક્લાયંટ ઑપ્ટિમાઇઝેશન સાથે સંબંધિત છે). બાદમાં, નવા વેબસાઈટ સ્પીડ ટેસ્ટીંગ ટૂલ્સ દેખાય છે, જે વેબસાઈટની સ્પીડ વધારવા માટેની ટીપ્સ પણ આપે છે. આમાંની દરેક સેવાઓ અથવા પ્લગિન્સની એક સુસંગત ભલામણ છે: "સીડીએનનો ઉપયોગ કરો." નેટવર્ક લેટન્સીમાં ઘટાડો સામાન્ય રીતે CDN ની અસર માટે સમજૂતી તરીકે ટાંકવામાં આવે છે. કમનસીબે, દરેક જણ CDN ની પ્રવેગક અસર કેવી રીતે પ્રાપ્ત થાય છે અને તેને કેવી રીતે માપી શકાય છે તે બરાબર સમજવા માટે તૈયાર નથી, તેથી ભલામણ વિશ્વાસ પર લેવામાં આવે છે અને તેનો ઉપયોગ પોસ્ટ્યુલેટ તરીકે કરવામાં આવે છે. વાસ્તવમાં, બધા CDN સમાન બનાવવામાં આવતા નથી.

આજે CDN નો ઉપયોગ કરવો

CDN નો ઉપયોગ કરવાની ઉપયોગિતાનું મૂલ્યાંકન કરવા માટે, તેમને વર્ગીકૃત કરવાની જરૂર છે. વ્યવહારમાં હવે શું મળી શકે છે (કૌંસમાંના ઉદાહરણો, અલબત્ત, સંપૂર્ણ નથી):

1. JS પુસ્તકાલયોના વિતરણ માટે મફત CDN (MaxCDN, Google. Yandex).
2. ક્લાયંટ ઑપ્ટિમાઇઝેશન માટે સેવાઓનું CDN (ઉદાહરણ તરીકે, ફોન્ટ્સ માટે Google ફોન્ટ્સ, ક્લાઉડિનરી, છબીઓ માટે ક્લાઉડ ઇમેજ).
3. સીએમએસમાં સ્ટેટિક અને રિસોર્સ ઓપ્ટિમાઇઝેશન માટે સીડીએન (બિટ્રિક્સ, વર્ડપ્રેસ અને અન્યમાં ઉપલબ્ધ છે).
4. સામાન્ય હેતુ CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. વેબસાઇટ પ્રવેગક માટે CDN (Cloudflare, Imperva, Airi).

આ પ્રકારો વચ્ચેનો મુખ્ય તફાવત એ છે કે કેટલો ટ્રાફિક CDN મારફતે જાય છે. પ્રકાર 1-3 એ સામગ્રીના માત્ર એક ભાગની ડિલિવરી છે: એક વિનંતીથી ઘણા ડઝન સુધી (સામાન્ય રીતે ચિત્રો). પ્રકાર 4 અને 5 એ CDN દ્વારા ટ્રાફિકનું સંપૂર્ણ પ્રોક્સીંગ છે.

વ્યવહારમાં, આનો અર્થ એ છે કે સાઇટ લોડ કરવા માટે ઉપયોગમાં લેવાતા જોડાણોની સંખ્યા. HTTP/2 સાથે, અમે કોઈપણ સંખ્યાની વિનંતીઓ પર પ્રક્રિયા કરવા માટે હોસ્ટ સાથે એક TCP કનેક્શનનો ઉપયોગ કરીએ છીએ. જો આપણે મુખ્ય હોસ્ટ (મૂળ) અને CDN માં સંસાધનોને વિભાજિત કરીએ, તો તે પછી વિવિધ ડોમેન્સમાં વિનંતીઓનું વિતરણ કરવું અને ઘણા TCP જોડાણો બનાવવા જરૂરી છે. સૌથી ખરાબ સ્થિતિ છે: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. આ સૂત્ર ઉપકરણની રેડિયો ચેનલના સક્રિયકરણ માટે મોબાઇલ નેટવર્ક્સમાં વિલંબ (જો તે સક્રિય ન હોય તો) અને સેલ ટાવર પરના વિલંબને ધ્યાનમાં લેતું નથી.

સાઇટના લોડિંગ વોટરફોલ પર તે કેવું દેખાય છે તે અહીં છે (CDN સાથે કનેક્ટ થવા માટેની વિલંબ RTT 150 ms પર પ્રકાશિત થાય છે):

જો CDN તમામ સાઇટ ટ્રાફિકને આવરી લે છે (તૃતીય-પક્ષ સેવાઓ સિવાય), તો અમે એક TCP કનેક્શનનો ઉપયોગ કરી શકીએ છીએ, વધારાના યજમાનો સાથે કનેક્ટ થવામાં વિલંબને બચાવી શકીએ છીએ. અલબત્ત, આ HTTP/2 જોડાણોને લાગુ પડે છે.

વધુ તફાવતો ચોક્કસ CDN ની કાર્યક્ષમતા દ્વારા નક્કી કરવામાં આવે છે - પ્રથમ પ્રકાર માટે તે માત્ર એક સ્થિર ફાઇલને હોસ્ટ કરી રહ્યું છે, પાંચમા માટે તે ઑપ્ટિમાઇઝેશનના હેતુ માટે વિવિધ પ્રકારની સાઇટ સામગ્રીને બદલી રહ્યું છે.

વેબસાઇટ પ્રવેગક માટે CDN ક્ષમતાઓ

ચાલો સીડીએનના વ્યક્તિગત પ્રકારોની કાર્યક્ષમતાને ધ્યાનમાં લીધા વિના, ગતિશીલ સાઇટ્સ માટે સીડીએન ક્ષમતાઓની સંપૂર્ણ શ્રેણીનું વર્ણન કરીએ, અને પછી તેમાંથી દરેકમાં શું લાગુ કરવામાં આવે છે તે જુઓ.

1. ટેક્સ્ટ સંસાધનોનું સંકોચન

સૌથી મૂળભૂત અને સમજી શકાય તેવી સુવિધા, છતાં ઘણી વખત નબળી રીતે અમલમાં મુકાય છે. બધા CDN તેમના પ્રવેગક લક્ષણ તરીકે કમ્પ્રેશનની હાજરી જાહેર કરે છે. પરંતુ જો તમે વધુ વિગતવાર જુઓ, તો ખામીઓ સ્પષ્ટ થઈ જશે:

• ડાયનેમિક કમ્પ્રેશન માટે ઓછી ડિગ્રીનો ઉપયોગ કરી શકાય છે - 5-6 (ઉદાહરણ તરીકે, gzip માટે મહત્તમ 9 છે);
• સ્ટેટિક કમ્પ્રેશન (કેશમાંની ફાઇલો) વધારાની સુવિધાઓનો ઉપયોગ કરતું નથી (ઉદાહરણ તરીકે, ડિગ્રી 11 સાથે ઝોપ્ફી અથવા બ્રોટલી)
• કાર્યક્ષમ બ્રોટલી કમ્પ્રેશન માટે કોઈ સપોર્ટ નથી (gzip ની તુલનામાં લગભગ 20% બચત).

જો તમે CDN નો ઉપયોગ કરો છો, તો આ થોડા મુદ્દાઓ તપાસવા યોગ્ય છે: CDN માંથી આવતી ફાઇલ લો, તેનું સંકુચિત કદ રેકોર્ડ કરો અને સરખામણી માટે તેને મેન્યુઅલી સંકુચિત કરો (તમે બ્રોટલી સપોર્ટ સાથે કેટલીક ઑનલાઇન સેવાનો ઉપયોગ કરી શકો છો, ઉદાહરણ તરીકે vsszhat.rf).

2. ક્લાયંટ કેશીંગ હેડરો સુયોજિત કરી રહ્યા છે

એક સરળ સ્પીડઅપ સુવિધા પણ: ક્લાયંટ (બ્રાઉઝર) દ્વારા સામગ્રી કેશીંગ માટે હેડરો ઉમેરો. સૌથી વર્તમાન હેડર કેશ-કંટ્રોલ છે, જૂનું છે તે સમાપ્ત થઈ ગયું છે. વધુમાં, Etag નો ઉપયોગ કરી શકાય છે. મુખ્ય વસ્તુ એ છે કે કેશ-કંટ્રોલની મહત્તમ-વય પૂરતી મોટી છે (એક મહિના અથવા વધુથી). જો તમે સંસાધનને શક્ય તેટલું સખત કેશ કરવા માટે તૈયાર છો, તો તમે અપરિવર્તનશીલ વિકલ્પ ઉમેરી શકો છો.

સીડીએન મહત્તમ-વય મૂલ્યને ઘટાડી શકે છે, વપરાશકર્તાને સ્થિર સામગ્રીને વધુ વખત ફરીથી લોડ કરવાની ફરજ પાડે છે. તે સ્પષ્ટ નથી કે આ શું સાથે જોડાયેલ છે: નેટવર્ક પર ટ્રાફિક વધારવાની અથવા કેશ રીસેટ કેવી રીતે કરવી તે જાણતી ન હોય તેવી સાઇટ્સ સાથે સુસંગતતા વધારવાની ઇચ્છા. ઉદાહરણ તરીકે, ડિફૉલ્ટ Cloudflare હેડર કેશ સમય 1 કલાક છે, જે અપરિવર્તનશીલ સ્ટેટિક ડેટા માટે ખૂબ ઓછો છે.

3. છબી ઓપ્ટિમાઇઝેશન

સીડીએન ઈમેજીસ કેશીંગ અને સર્વિંગના કાર્યોને લેતું હોવાથી, તેને સીડીએન બાજુ પર ઓપ્ટિમાઇઝ કરવું અને આ ફોર્મમાં વપરાશકર્તાઓને સેવા આપવી તે તાર્કિક રહેશે. ચાલો તરત જ એક આરક્ષણ કરીએ કે આ સુવિધા ફક્ત CDN પ્રકારો 2, 3 અને 5 માટે જ ઉપલબ્ધ છે.

તમે વિવિધ રીતે છબીઓને ઑપ્ટિમાઇઝ કરી શકો છો: અદ્યતન કમ્પ્રેશન ફોર્મેટ્સ (જેમ કે WebP), વધુ કાર્યક્ષમ એન્કોડર્સ (MozJPEG), અથવા ફક્ત બિનજરૂરી મેટાડેટાને સાફ કરીને.

સામાન્ય રીતે, આવા ઑપ્ટિમાઇઝેશનના બે પ્રકાર છે: ગુણવત્તાની ખોટ સાથે અને ગુણવત્તાની ખોટ વિના. CDN સામાન્ય રીતે ઇમેજની ગુણવત્તામાં ફેરફાર વિશે ગ્રાહકની સંભવિત ફરિયાદોને ટાળવા માટે લોસલેસ ઑપ્ટિમાઇઝેશનનો ઉપયોગ કરવાનો પ્રયત્ન કરે છે. આવી પરિસ્થિતિઓમાં, લાભ ન્યૂનતમ હશે. વાસ્તવમાં, ઘણીવાર JPEG ગુણવત્તા સ્તર જરૂરી કરતાં ઘણું ઊંચું હોય છે અને તમે વપરાશકર્તાના અનુભવ સાથે સમાધાન કર્યા વિના નીચા ગુણવત્તા સ્તર સાથે સુરક્ષિત રીતે ફરીથી સંકુચિત કરી શકો છો. બીજી બાજુ, તમામ સંભવિત વેબ એપ્લિકેશન માટે ગુણવત્તા અને સેટિંગ્સનું સ્તર સાર્વત્રિક રીતે નક્કી કરવું મુશ્કેલ છે, તેથી CDN એ સંદર્ભને ધ્યાનમાં રાખીને લાગુ કરી શકાય તેવી સરખામણીમાં વધુ રૂઢિચુસ્ત સેટિંગ્સનો ઉપયોગ કરે છે (છબીઓનો હેતુ, વેબ એપ્લિકેશનનો પ્રકાર , વગેરે)

4. TLS કનેક્શનને ઑપ્ટિમાઇઝ કરવું

મોટા ભાગનો ટ્રાફિક આજે TLS કનેક્શન પર મુસાફરી કરે છે, જેનો અર્થ છે કે અમે TLS વાટાઘાટો પર વધારાનો સમય પસાર કરીએ છીએ. તાજેતરમાં, આ પ્રક્રિયાને ઝડપી બનાવવા માટે નવી તકનીકો વિકસાવવામાં આવી છે. ઉદાહરણ તરીકે, આ EC ક્રિપ્ટોગ્રાફી, TLS 1.3, સત્ર કેશ અને ટિકિટ, હાર્ડવેર એન્ક્રિપ્શન પ્રવેગક (AES-NI), વગેરે છે. TLS યોગ્ય રીતે સેટ કરવાથી કનેક્શન સમય 0-1 RTT સુધી ઘટાડી શકે છે (DNS અને TCPની ગણતરી કરતા નથી).

આધુનિક સૉફ્ટવેર સાથે, તમારા પોતાના પર આવી પદ્ધતિઓનો અમલ કરવો મુશ્કેલ નથી.

બધા CDNs TLS શ્રેષ્ઠ પ્રેક્ટિસનો અમલ કરતા નથી; તમે TLS કનેક્શન સમય (ઉદાહરણ તરીકે, વેબપેજટેસ્ટમાં) માપીને આને ચકાસી શકો છો. નવા કનેક્શન માટે આદર્શ - 1RTT, 2RTT - સરેરાશ સ્તર, 3RTT અને વધુ - ખરાબ.

એ પણ નોંધવું જોઈએ કે CDN સ્તરે TLS નો ઉપયોગ કરતી વખતે, અમારી વેબ એપ્લિકેશન સાથેના સર્વરે પણ TLS પર પ્રક્રિયા કરવી જોઈએ, પરંતુ CDN બાજુથી, કારણ કે સર્વર અને CDN વચ્ચેનો ટ્રાફિક જાહેર નેટવર્ક પર પસાર થાય છે. સૌથી ખરાબ કિસ્સામાં, અમને ડબલ TLS કનેક્શન વિલંબ મળશે (સીડીએન હોસ્ટ માટે પ્રથમ, તે અને અમારા સર્વર વચ્ચેનો બીજો).

કેટલીક એપ્લિકેશનો માટે, સુરક્ષા મુદ્દાઓ પર ધ્યાન આપવું યોગ્ય છે: ટ્રાફિક સામાન્ય રીતે CDN નોડ્સ પર ડિક્રિપ્ટ થાય છે, અને આ ટ્રાફિક અવરોધ માટે સંભવિત તક છે. ટ્રાફિક ડિસ્ક્લોઝર વિના કામ કરવાનો વિકલ્પ સામાન્ય રીતે ટોચના ટેરિફ પ્લાનમાં વધારાની ફી માટે આપવામાં આવે છે.

5. કનેક્શન વિલંબમાં ઘટાડો

CDN નો મુખ્ય ફાયદો જેના વિશે દરેક જણ વાત કરે છે: CDN હોસ્ટ અને વપરાશકર્તા વચ્ચે ઓછી વિલંબતા (ઓછું અંતર). ભૌગોલિક રીતે વિતરિત નેટવર્ક આર્કિટેક્ચર બનાવીને હાંસલ કર્યું, જેમાં યજમાનો વપરાશકર્તાઓની સાંદ્રતાના બિંદુઓ (શહેરો, ટ્રાફિક વિનિમય બિંદુઓ, વગેરે) માં સ્થિત છે.

વ્યવહારમાં, વિવિધ નેટવર્ક્સ માટેની પ્રાથમિકતાઓ ચોક્કસ પ્રદેશોમાં હોઈ શકે છે. ઉદાહરણ તરીકે, રશિયન સીડીએનની રશિયામાં હાજરીના વધુ બિંદુઓ હશે. અમેરિકનો સૌ પ્રથમ યુએસએમાં નેટવર્ક વિકસાવશે. ઉદાહરણ તરીકે, સૌથી મોટા સીડીએન ક્લાઉડફ્લેયરમાં રશિયામાં માત્ર 2 પોઈન્ટ છે - મોસ્કો અને સેન્ટ પીટર્સબર્ગ. એટલે કે, અમે મોસ્કોમાં ડાયરેક્ટ પ્લેસમેન્ટની સરખામણીમાં લગભગ 10 ms જેટલી લેટન્સી બચાવી શકીએ છીએ.

મોટાભાગના પશ્ચિમી સીડીએન પાસે રશિયામાં બિલકુલ પોઈન્ટ નથી. તેમની સાથે કનેક્ટ કરીને, તમે ફક્ત તમારા રશિયન પ્રેક્ષકો માટે વિલંબ વધારી શકો છો.

6. સામગ્રી ઑપ્ટિમાઇઝેશન (મિનિફિકેશન, માળખાકીય ફેરફારો)

સૌથી જટિલ અને તકનીકી રીતે અદ્યતન બિંદુ. ડિલિવરી દરમિયાન સામગ્રી બદલવી ખૂબ જોખમી હોઈ શકે છે. જો આપણે મિનિફિકેશન લઈએ તો પણ: સોર્સ કોડ ઘટાડવાથી (વધારાની જગ્યાઓ, બિનમહત્વપૂર્ણ સ્ટ્રક્ચર વગેરેને કારણે) તેની કામગીરીને અસર કરી શકે છે. જો આપણે વધુ ગંભીર ફેરફારો વિશે વાત કરીએ - જેએસ કોડને HTML ના અંતમાં ખસેડવું, ફાઇલોને મર્જ કરવી વગેરે - સાઇટની કાર્યક્ષમતામાં ખલેલ પહોંચાડવાનું જોખમ પણ વધારે છે.

તેથી, માત્ર અમુક પ્રકાર 5 CDN આ કરે છે. અલબત્ત, વસ્તુઓને ઝડપી બનાવવા માટે જરૂરી તમામ ફેરફારોને સ્વચાલિત કરવું શક્ય બનશે નહીં - મેન્યુઅલ વિશ્લેષણ અને ઑપ્ટિમાઇઝેશન જરૂરી છે. ઉદાહરણ તરીકે, ન વપરાયેલ અથવા ડુપ્લિકેટ કોડને દૂર કરવું એ મેન્યુઅલ કાર્ય છે.

એક નિયમ તરીકે, આવા તમામ ઑપ્ટિમાઇઝેશન સેટિંગ્સ દ્વારા નિયંત્રિત થાય છે અને સૌથી ખતરનાક ડિફૉલ્ટ રૂપે અક્ષમ કરવામાં આવે છે.

CDN પ્રકાર દ્વારા પ્રવેગક ક્ષમતાઓ માટે સપોર્ટ

તો ચાલો જોઈએ કે CDN ના વિવિધ પ્રકારો કઈ સંભવિત પ્રવેગક તકો પ્રદાન કરે છે.

સગવડ માટે, અમે વર્ગીકરણનું પુનરાવર્તન કરીએ છીએ.

1. JS પુસ્તકાલયોના વિતરણ માટે મફત CDN (MaxCDN, Google. Yandex).
2. ક્લાયંટ ઑપ્ટિમાઇઝેશન માટે સેવાઓનું CDN (ઉદાહરણ તરીકે, ફોન્ટ્સ માટે Google ફોન્ટ્સ, ક્લાઉડિનરી, છબીઓ માટે ક્લાઉડ ઇમેજ).
3. સીએમએસમાં સ્ટેટિક અને રિસોર્સ ઓપ્ટિમાઇઝેશન માટે સીડીએન (બિટ્રિક્સ, વર્ડપ્રેસ અને અન્યમાં ઉપલબ્ધ છે).
4. સામાન્ય હેતુ CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. વેબસાઇટ પ્રવેગક માટે CDN (Cloudflare, Imperva, Airi).

હવે ચાલો CDN ના લક્ષણો અને પ્રકારોની તુલના કરીએ.

તક
પ્રકાર 1
પ્રકાર 2
પ્રકાર 3
પ્રકાર 4
પ્રકાર 5

ટેક્સ્ટ કમ્પ્રેશન
+–
-
+–
+–
+

કેશ હેડરો
+
+
+
+
+

ચિત્રો
-
+–
+–
-
+

TLS
-
-
-
+–
+

વિલંબ
-
-
-
+
+

અનુક્રમણિકા
-
-
-
-
+

આ કોષ્ટકમાં, "+" નો ઉપયોગ સંપૂર્ણ સમર્થન દર્શાવવા માટે થાય છે, "–" કોઈ સમર્થન નથી અને "+–" આંશિક સમર્થન છે. અલબત્ત, વાસ્તવિકતામાં આ કોષ્ટકમાંથી વિચલનો હોઈ શકે છે (ઉદાહરણ તરીકે, કેટલાક સામાન્ય હેતુ CDN છબીઓને ઑપ્ટિમાઇઝ કરવા માટેની સુવિધાઓ લાગુ કરશે), પરંતુ સામાન્ય વિચાર માટે તે ઉપયોગી છે.

પરિણામો

આશા છે કે, આ લેખ વાંચ્યા પછી તમારી સાઇટ્સને ઝડપી બનાવવા માટે "CDN નો ઉપયોગ કરો" ભલામણ સંબંધિત સ્પષ્ટ ચિત્ર તમારી પાસે હશે.

કોઈપણ વ્યવસાયની જેમ, તમે કોઈપણ સેવાના માર્કેટિંગ વચનો પર વિશ્વાસ કરી શકતા નથી. અસરને વાસ્તવિક પરિસ્થિતિઓમાં માપવા અને પરીક્ષણ કરવાની જરૂર છે. જો તમે પહેલેથી જ CDN નો ઉપયોગ કરી રહ્યાં છો, તો લેખમાં વર્ણવેલ માપદંડોનો ઉપયોગ કરીને અસરકારકતા માટે તેને તપાસો.

સંભવ છે કે અત્યારે CDN નો ઉપયોગ કરવાથી તમારી સાઇટનો લોડ થવાનો સમય ધીમો પડી રહ્યો છે.

સામાન્ય ભલામણ તરીકે, અમે નીચેના પર ધ્યાન કેન્દ્રિત કરી શકીએ છીએ: તમારા પ્રેક્ષકોનો અભ્યાસ કરો, તેનો ભૌગોલિક અવકાશ નક્કી કરો. જો તમારા મુખ્ય પ્રેક્ષકો 1-2 હજાર કિલોમીટરની ત્રિજ્યામાં કેન્દ્રિત છે, તો તમારે તેના મુખ્ય હેતુ માટે CDN ની જરૂર નથી - વિલંબ ઘટાડવો. તેના બદલે, તમે તમારા સર્વરને તમારા વપરાશકર્તાઓની નજીક મૂકી શકો છો અને લેખમાં વર્ણવેલ મોટાભાગના ઑપ્ટિમાઇઝેશન (મફત અને કાયમી) મેળવીને તેને યોગ્ય રીતે ગોઠવી શકો છો.

જો તમારા પ્રેક્ષકો ખરેખર ભૌગોલિક રીતે વિતરિત થયા હોય (3000 કિલોમીટરથી વધુની ત્રિજ્યા), ગુણવત્તાયુક્ત CDN નો ઉપયોગ કરવો ખરેખર ઉપયોગી થશે. જો કે, તમારે અગાઉથી સમજવાની જરૂર છે કે તમારું CDN બરાબર શું ઝડપી કરી શકે છે (ક્ષમતાઓનું કોષ્ટક અને તેમનું વર્ણન જુઓ). જો કે, વેબસાઈટ પ્રવેગક હજુ પણ એક જટિલ કાર્ય છે જે CDN ને કનેક્ટ કરીને હલ કરી શકાતું નથી. ઉપરોક્ત ઑપ્ટિમાઇઝેશન ઉપરાંત, પ્રવેગકના સૌથી અસરકારક માધ્યમો CDN પાછળ રહે છે: સર્વર ભાગનું ઑપ્ટિમાઇઝેશન, ક્લાયંટના ભાગમાં અદ્યતન ફેરફારો (ન વપરાયેલ કોડને દૂર કરવા, રેન્ડરિંગ પ્રક્રિયાને ઑપ્ટિમાઇઝ કરવા, સામગ્રી સાથે કામ કરવું, ફોન્ટ્સ, અનુકૂલનક્ષમતા વગેરે. )

સોર્સ: www.habr.com