স্ব-হোস্টিং তৃতীয় পক্ষের সম্পদ: ভাল, খারাপ, কুৎসিত

সাম্প্রতিক বছরগুলিতে, ফ্রন্ট-এন্ড প্রকল্পগুলি অপ্টিমাইজ করার জন্য আরও বেশি প্ল্যাটফর্মগুলি স্ব-হোস্টিং বা তৃতীয়-পক্ষের সংস্থান প্রক্সি করার সুযোগ দেয়। আকমাই আপনাকে সেট করতে দেয় নির্দিষ্ট পরামিতি স্ব-উত্পাদিত URL-এর জন্য। ক্লাউডফ্লেয়ার এজ ওয়ার্কার্স প্রযুক্তি রয়েছে। ফাস্টারজাইন পারেন পুনর্লিখন পৃষ্ঠাগুলিতে URLগুলি যাতে তারা সাইটের প্রধান ডোমেনে অবস্থিত তৃতীয় পক্ষের সংস্থানগুলির দিকে নির্দেশ করে৷

আপনি যদি জানেন যে আপনার প্রকল্পে ব্যবহৃত তৃতীয় পক্ষের পরিষেবাগুলি প্রায়শই পরিবর্তিত হয় না এবং সেগুলিকে ক্লায়েন্টদের কাছে পৌঁছে দেওয়ার প্রক্রিয়া উন্নত করা যেতে পারে, তাহলে আপনি সম্ভবত এই ধরনের পরিষেবাগুলি প্রক্সি করার কথা ভাবছেন৷ এই পদ্ধতির সাহায্যে, আপনি খুব ভালভাবে এই সংস্থানগুলিকে আপনার ব্যবহারকারীদের কাছাকাছি আনতে পারেন এবং ক্লায়েন্টের দিকে তাদের ক্যাশিংয়ের উপর আরও সম্পূর্ণ নিয়ন্ত্রণ অর্জন করতে পারেন। এছাড়াও, এটি আপনাকে তৃতীয় পক্ষের পরিষেবার "ক্র্যাশ" বা এর কার্যকারিতা অবনতির কারণে সৃষ্ট সমস্যা থেকে ব্যবহারকারীদের রক্ষা করতে দেয়।

ভাল: উন্নত কর্মক্ষমতা

অন্য কারো সম্পদ স্ব-হোস্টিং একটি খুব স্পষ্ট উপায়ে কর্মক্ষমতা উন্নত. ব্রাউজারটির আবার DNS অ্যাক্সেস করার দরকার নেই, এটিকে একটি TCP সংযোগ স্থাপন করার এবং তৃতীয় পক্ষের ডোমেনে একটি TLS হ্যান্ডশেক করার প্রয়োজন নেই। নিচের দুটি পরিসংখ্যান তুলনা করে আপনি দেখতে পাচ্ছেন কিভাবে অন্য কারো সম্পদের স্ব-হোস্টিং কর্মক্ষমতাকে প্রভাবিত করে।

তৃতীয় পক্ষের সংস্থানগুলি বাহ্যিক উত্স থেকে ডাউনলোড করা হয় (থেকে নেওয়া এখানে থেকে)

থার্ড-পার্টি রিসোর্স সাইটের বাকি উপকরণের মতো একই জায়গায় সংরক্ষণ করা হয় (থেকে নেওয়া এখানে থেকে)

পরিস্থিতিটিও উন্নত হয়েছে যে ব্রাউজারটি মাল্টিপ্লেক্স করার ক্ষমতা ব্যবহার করবে এবং HTTP/2 সংযোগ থেকে ডেটা অগ্রাধিকার দেবে যা ইতিমধ্যেই প্রধান ডোমেনের সাথে প্রতিষ্ঠিত হয়েছে।

আপনি যদি থার্ড-পার্টি রিসোর্স হোস্ট না করেন, তাহলে যেহেতু সেগুলি প্রধান থেকে আলাদা একটি ডোমেন থেকে লোড করা হবে, সেগুলিকে অগ্রাধিকার দেওয়া যাবে না৷ এটি তাদের ক্লায়েন্টের ব্যান্ডউইথের জন্য একে অপরের সাথে প্রতিদ্বন্দ্বিতা করবে। এর ফলে একটি পৃষ্ঠা তৈরির জন্য গুরুত্বপূর্ণ বিষয়বস্তুর লোডিং সময় হতে পারে যা আদর্শ পরিস্থিতিতে যা অর্জন করা যায় তার চেয়ে অনেক বেশি। এখানে HTTP/2 অগ্রাধিকার নিয়ে কথা বলুন যা এই সমস্ত কিছুকে খুব ভালভাবে ব্যাখ্যা করে।

এটা অনুমান করা যেতে পারে যে বাহ্যিক সংস্থানগুলির লিঙ্কগুলিতে বৈশিষ্ট্যগুলির ব্যবহার preconnect সমস্যা সমাধানে সাহায্য করবে। যাইহোক, যদি বিভিন্ন ডোমেনে এই লিঙ্কগুলির অনেকগুলি থাকে তবে এটি আসলে সবচেয়ে গুরুত্বপূর্ণ মুহুর্তে যোগাযোগ লাইনকে ওভারলোড করতে পারে।

আপনি যদি নিজেই তৃতীয় পক্ষের সংস্থানগুলি হোস্ট করেন, তাহলে আপনি ক্লায়েন্টকে ঠিক কীভাবে এই সংস্থানগুলি দেওয়া হবে তা নিয়ন্ত্রণ করতে পারেন৷ যথা, আমরা নিম্নলিখিত সম্পর্কে কথা বলছি:

• আপনি নিশ্চিত করতে পারেন যে ডেটা কম্প্রেশন অ্যালগরিদম যা প্রতিটি ব্রাউজার সবচেয়ে উপযুক্ত ব্যবহার করা হয়েছে (Brotli/gzip)।
• আপনি এমন সংস্থানগুলির জন্য ক্যাশিং সময় বাড়াতে পারেন যা সাধারণত বিশেষভাবে দীর্ঘ হয় না, এমনকি সবচেয়ে সুপরিচিত প্রদানকারীর সাথেও (উদাহরণস্বরূপ, GA ট্যাগের জন্য সংশ্লিষ্ট মান 30 মিনিটে সেট করা আছে)।

এমনকি আপনি আপনার ক্যাশিং ম্যানেজমেন্ট স্ট্র্যাটেজি (ইউআরএল হ্যাশ, ভার্সনিং, ইত্যাদি) এর সাথে প্রাসঙ্গিক বিষয়বস্তুকে অন্তর্ভুক্ত করে একটি সম্পদের জন্য TTL বাড়িয়ে দিতে পারেন। আমরা নীচে এই সম্পর্কে কথা বলতে হবে.

▍থার্ড-পার্টি পরিষেবার ক্রিয়াকলাপ বা তাদের শাটডাউনে বাধাগুলির বিরুদ্ধে সুরক্ষা

স্ব-হোস্টিং তৃতীয় পক্ষের সংস্থানগুলির আরেকটি আকর্ষণীয় দিক হল এটি আপনাকে তৃতীয় পক্ষের পরিষেবাগুলির বিভ্রাটের সাথে সম্পর্কিত ঝুঁকিগুলি হ্রাস করতে দেয়৷ ধরা যাক যে তৃতীয় পক্ষের A/B পরীক্ষার সমাধান আপনি ব্যবহার করছেন সেটি একটি ব্লকিং স্ক্রিপ্ট হিসাবে প্রয়োগ করা হয়েছে যা পৃষ্ঠার প্রধান বিভাগে লোড হয়। এই স্ক্রিপ্ট ধীরে ধীরে লোড হয়. সংশ্লিষ্ট স্ক্রিপ্ট লোড করতে ব্যর্থ হলে, পৃষ্ঠাটি খালি থাকবে। যদি এটি লোড হতে খুব বেশি সময় নেয়, তাহলে পৃষ্ঠাটি একটি দীর্ঘ বিলম্বের সাথে প্রদর্শিত হবে। অথবা, ধরুন প্রকল্পটি তৃতীয় পক্ষের CDN সম্পদ থেকে ডাউনলোড করা একটি লাইব্রেরি ব্যবহার করে। আসুন কল্পনা করুন যে এই সংস্থানটি ব্যর্থ হয়েছে বা একটি নির্দিষ্ট দেশে অবরুদ্ধ করা হয়েছে। এই ধরনের পরিস্থিতি সাইটের যুক্তি লঙ্ঘনের দিকে পরিচালিত করবে।

কিছু বাহ্যিক পরিষেবা অনুপলব্ধ হলে আপনার সাইট কীভাবে কাজ করে তা খুঁজে বের করতে, আপনি SPOF বিভাগটি ব্যবহার করতে পারেন webpagetest.org.

webpagetest.org এ SPOF বিভাগ

▍ব্রাউজারে উপকরণ ক্যাশে করার সমস্যা সম্পর্কে কী? (ইঙ্গিত: এটি একটি মিথ)

আপনি ভাবতে পারেন যে সর্বজনীন CDN ব্যবহার করলে স্বয়ংক্রিয়ভাবে সম্পদের উন্নতি হবে, যেহেতু এই পরিষেবাগুলির মোটামুটি উচ্চ-মানের নেটওয়ার্ক রয়েছে এবং সারা বিশ্বে বিতরণ করা হয়। কিন্তু সবকিছু আসলে একটু বেশি জটিল।

ধরা যাক আমাদের বিভিন্ন সাইট আছে: website1.com, website2.com, website3.com। এই সমস্ত সাইট jQuery লাইব্রেরি ব্যবহার করে। আমরা একটি CDN ব্যবহার করে তাদের সাথে এটি সংযুক্ত করি, উদাহরণস্বরূপ - googleapis.com৷ আপনি ব্রাউজারটি একবার লাইব্রেরিটি ডাউনলোড এবং ক্যাশে করার আশা করতে পারেন এবং তারপরে এটি তিনটি সাইট জুড়ে ব্যবহার করতে পারেন। এটি নেটওয়ার্কে লোড কমাতে পারে। সম্ভবত এটি আপনাকে কোথাও অর্থ সঞ্চয় করতে এবং সম্পদের কার্যকারিতা উন্নত করতে সহায়তা করবে। ব্যবহারিক দৃষ্টিকোণ থেকে, সবকিছু আলাদা দেখায়। উদাহরণস্বরূপ, Safari নামক একটি বৈশিষ্ট্য আছে বুদ্ধিমান ট্র্যাকিং প্রতিরোধ: নথির উৎস এবং তৃতীয় পক্ষের সম্পদের উৎসের উপর ভিত্তি করে ক্যাশে ডুয়াল কী ব্যবহার করে। এখানে এই বিষয়ে ভাল নিবন্ধ.

পুরানো পড়াশোনা নরপশু и ফেসবুক, সেইসাথে আরো সাম্প্রতিক অধ্যয়ন পল ক্যালভানো, দেখান যে সংস্থানগুলি ব্রাউজার ক্যাশে সংরক্ষণ করা হয় না যতক্ষণ আমরা আশা করতে পারি: “একটি প্রকল্পের নিজস্ব এবং তৃতীয়-পক্ষের সংস্থানগুলির ক্যাশিং সময়ের মধ্যে একটি গুরুতর ব্যবধান রয়েছে৷ আমরা CSS এবং ওয়েব ফন্ট সম্পর্কে কথা বলছি। যথা, 95% নেটিভ ফন্টের ক্যাশে লাইফ এক সপ্তাহের বেশি, যখন তৃতীয় পক্ষের 50% ফন্টের ক্যাশে লাইফ এক সপ্তাহেরও কম! এটি ওয়েব ডেভেলপারদের ফন্ট ফাইলগুলি নিজেরাই হোস্ট করার একটি বাধ্যতামূলক কারণ দেয়!

ফলস্বরূপ, আপনি যদি অন্য লোকেদের সামগ্রী হোস্ট করেন, আপনি ব্রাউজার ক্যাশিং দ্বারা সৃষ্ট কোনো কর্মক্ষমতা সমস্যা লক্ষ্য করবেন না।

এখন যেহেতু আমরা তৃতীয় পক্ষের স্ব-হোস্টিংয়ের শক্তিগুলিকে কভার করেছি, আসুন কীভাবে এই পদ্ধতির একটি খারাপ থেকে একটি ভাল প্রয়োগ করা যায় সে সম্পর্কে কথা বলি।

খারাপ: শয়তান বিস্তারিত আছে

আপনার নিজের ডোমেনে তৃতীয় পক্ষের সংস্থানগুলি সরানো স্বয়ংক্রিয়ভাবে করা যাবে না এই ধরনের সংস্থানগুলি সঠিকভাবে ক্যাশে করা হয়েছে তা নিশ্চিত না করে৷

এখানে প্রধান সমস্যাগুলির মধ্যে একটি হল সময় ক্যাশে করা। উদাহরণস্বরূপ, সংস্করণ তথ্য তৃতীয় পক্ষের স্ক্রিপ্ট নামগুলির মধ্যে অন্তর্ভুক্ত করা হয়েছে যেমন: jquery-3.4.1.js. এই ধরনের একটি ফাইল ভবিষ্যতে পরিবর্তন হবে না, এবং ফলস্বরূপ এটি এর ক্যাশে কোন সমস্যা সৃষ্টি করবে না।

কিন্তু ফাইল, ক্যাশে করা স্ক্রিপ্টগুলির সাথে কাজ করার সময় কিছু সংস্করণ স্কিম ব্যবহার না করা হলে, ফাইলের নাম অপরিবর্তিত থাকাকালীন যেগুলির বিষয়বস্তু পরিবর্তিত হয়, পুরানো হয়ে যেতে পারে। এটি একটি গুরুতর সমস্যা হতে পারে, যেহেতু এটি, উদাহরণস্বরূপ, স্বয়ংক্রিয় নিরাপত্তা প্যাচগুলিকে স্ক্রিপ্টগুলিতে যোগ করার অনুমতি দেয় না যা ক্লায়েন্টদের যত তাড়াতাড়ি সম্ভব গ্রহণ করা প্রয়োজন। বিকাশকারীকে ক্যাশে এই জাতীয় স্ক্রিপ্টগুলি আপডেট করার চেষ্টা করতে হবে। উপরন্তু, এটি অ্যাপ্লিকেশন ব্যর্থতার কারণ হতে পারে কারণ ক্যাশে থেকে ক্লায়েন্টে ব্যবহৃত কোডটি কোডের সর্বশেষ সংস্করণ থেকে পৃথক যার জন্য প্রকল্পের সার্ভার অংশটি ডিজাইন করা হয়েছে।

সত্য, যদি আমরা ঘন ঘন আপডেট করা উপকরণগুলির বিষয়ে কথা বলি (ট্যাগ ম্যানেজার, A/B পরীক্ষার সমাধান), তাহলে CDN টুল ব্যবহার করে সেগুলিকে ক্যাশ করা একটি কাজ যা সমাধান করা যেতে পারে, কিন্তু অনেক বেশি জটিল। কমান্ডার অ্যাক্টের মতো পরিষেবা, একটি ট্যাগ ব্যবস্থাপনা সমাধান, নতুন সংস্করণ প্রকাশ করার সময় ওয়েবহুক ব্যবহার করে। এটি আপনাকে CDN-এ একটি ক্যাশে ফ্লাশ জোরপূর্বক করার ক্ষমতা দেয়, বা, আরও ভাল, একটি হ্যাশ বা URL আপডেট জোর করার ক্ষমতা দেয়৷

▍ ক্লায়েন্টদের উপকরণ অভিযোজিত বিতরণ

উপরন্তু, যখন আমরা ক্যাশিং সম্পর্কে কথা বলি, তখন আমাদের এই বিষয়টি বিবেচনা করতে হবে যে CDN-এ ব্যবহৃত ক্যাশিং সেটিংস কিছু তৃতীয় পক্ষের সম্পদের জন্য উপযুক্ত নাও হতে পারে। উদাহরণস্বরূপ, এই জাতীয় সংস্থানগুলি ব্যবহারকারী এজেন্ট স্নিফিং (অ্যাডাপ্টিভ সার্ভিং) প্রযুক্তি ব্যবহার করে নির্দিষ্ট ব্রাউজারগুলিকে সেই ব্রাউজারগুলির জন্য বিশেষভাবে অপ্টিমাইজ করা সামগ্রীর সংস্করণ সহ পরিবেশন করতে পারে। এই প্রযুক্তিগুলি ব্রাউজারের ক্ষমতাগুলি বের করতে রেগুলার এক্সপ্রেশন বা HTTP হেডার তথ্যের একটি ডাটাবেসের উপর নির্ভর করে। User-Agent. তারা কোন ব্রাউজার নিয়ে কাজ করছে তা জানার পরে, তারা এটির জন্য ডিজাইন করা উপকরণ দেয়।

এখানে আপনি দুটি পরিষেবা মনে রাখতে পারেন। প্রথমটি হল googlefonts.com। দ্বিতীয়টি হল polyfill.io। Google ফন্ট পরিষেবা ব্রাউজারের ক্ষমতার উপর নির্ভর করে একটি নির্দিষ্ট সংস্থানের জন্য বিভিন্ন CSS কোড প্রদান করে (woff2 রিসোর্স ব্যবহার করে লিঙ্ক দেওয়া unicode-range).

এখানে বিভিন্ন ব্রাউজার থেকে তৈরি কয়েকটি গুগল ফন্ট প্রশ্নের ফলাফল রয়েছে।

ক্রোম থেকে Google ফন্ট কোয়েরি ফলাফল

IE10 থেকে এক্সিকিউট করা Google ফন্ট কোয়েরির ফলাফল

Polyfill.io ব্রাউজারটি শুধুমাত্র প্রয়োজনীয় পলিফিল দেয়। এটি কর্মক্ষমতা কারণে করা হয়.

উদাহরণস্বরূপ, আপনি বিভিন্ন ব্রাউজার থেকে নিম্নলিখিত অনুরোধটি চালালে কী হবে তা একবার দেখে নেওয়া যাক: https://polyfill.io/v3/polyfill.js?features=default

IE10 থেকে সম্পাদিত এই ধরনের অনুরোধের জবাবে, 34 KB ডেটা প্রাপ্ত হবে। এবং এটির উত্তর, ক্রোম থেকে কার্যকর করা, খালি হবে।

রাগান্বিত: কিছু গোপনীয়তা বিবেচনা

এই পয়েন্টটি ক্রমানুসারে শেষ, তবে অন্তত গুরুত্বপূর্ণ নয়। মূল বিষয় হল প্রকল্পের প্রধান ডোমেনে বা এর সাবডোমেনে তৃতীয়-পক্ষের সংস্থানগুলির স্ব-হোস্টিং ব্যবহারকারীদের গোপনীয়তাকে বিপন্ন করতে পারে এবং মূল ওয়েব প্রকল্পকে নেতিবাচকভাবে প্রভাবিত করতে পারে।

আপনার CDN সিস্টেম সঠিকভাবে কনফিগার করা না থাকলে, আপনি আপনার ডোমেনের কুকিজ একটি তৃতীয় পক্ষের পরিষেবাতে পাঠাতে পারেন। যদি সঠিক ফিল্টারিং CDN স্তরে সংগঠিত না হয়, তাহলে আপনার সেশন কুকিজ, যা সাধারণত জাভাস্ক্রিপ্টে ব্যবহার করা যায় না (এর সাথে httponly), একটি বিদেশী হোস্ট পাঠানো হতে পারে.

ইউলারিয়ান বা ক্রিটিওর মতো ট্র্যাকারদের সাথে ঠিক এটিই ঘটতে পারে। তৃতীয় পক্ষের ট্র্যাকাররা কুকিতে একটি অনন্য শনাক্তকারী সেট করতে পারে। যদি তারা সাইট সামগ্রীর অংশ হয়, ব্যবহারকারী বিভিন্ন ওয়েব সংস্থানগুলির সাথে কাজ করার সময় তারা তাদের বিবেচনার ভিত্তিতে সনাক্তকারী পড়তে পারে।

আজকাল, বেশিরভাগ ব্রাউজার এই ধরণের ট্র্যাকার আচরণের বিরুদ্ধে সুরক্ষা অন্তর্ভুক্ত করে। ফলে ট্র্যাকাররা এখন প্রযুক্তি ব্যবহার করে CNAME ক্লোকিং, বিভিন্ন প্রকল্পের জন্য তাদের নিজস্ব স্ক্রিপ্ট হিসাবে মাস্করাডিং. যথা, ট্র্যাকাররা একটি নির্দিষ্ট ডোমেনের জন্য তাদের সেটিংসে একটি CNAME যোগ করার জন্য সাইটের মালিকদের অফার করে, যার ঠিকানা সাধারণত অক্ষরগুলির একটি র্যান্ডম সেটের মতো দেখায়৷

যদিও সমস্ত সাবডোমেনে (উদাহরণস্বরূপ - *.website.com) ওয়েবসাইট কুকিজ উপলব্ধ করার পরামর্শ দেওয়া হয় না, তবে অনেক সাইট এটি করে। এই ক্ষেত্রে, এই ধরনের কুকিগুলি স্বয়ংক্রিয়ভাবে একটি ছদ্মবেশী তৃতীয় পক্ষের ট্র্যাকারে পাঠানো হয়। ফলে আমরা আর কোনো গোপনীয়তা নিয়ে কথা বলতে পারি না।

এছাড়াও, HTTP শিরোনামগুলির সাথে একই জিনিস ঘটে ক্লায়েন্ট-ইঙ্গিত, যা শুধুমাত্র প্রধান ডোমেনে পাঠানো হয়, যেহেতু তারা তৈরি করতে ব্যবহার করা যেতে পারে ডিজিটাল ফিঙ্গারপ্রিন্ট ব্যবহারকারী নিশ্চিত করুন যে আপনি যে CDN পরিষেবাটি ব্যবহার করেন তা এই শিরোনামগুলিকে সঠিকভাবে ফিল্টার করে।

ফলাফল

আপনি যদি শীঘ্রই তৃতীয় পক্ষের সংস্থানগুলির স্ব-হোস্টিং বাস্তবায়নের পরিকল্পনা করছেন, তাহলে আমি আপনাকে কিছু টিপস দিই:

• আপনার সবচেয়ে গুরুত্বপূর্ণ JS লাইব্রেরি, ফন্ট এবং CSS ফাইল হোস্ট করুন। এটি তৃতীয় পক্ষের পরিষেবার ত্রুটির কারণে সাইটের জন্য অত্যাবশ্যকীয় সংস্থান অনুপলব্ধ হওয়ার কারণে সাইট ব্যর্থতা বা কার্যক্ষমতা হ্রাসের ঝুঁকি হ্রাস করবে।
• আপনি একটি CDN-এ তৃতীয়-পক্ষের সংস্থানগুলি ক্যাশে করার আগে, নিশ্চিত করুন যে তাদের ফাইলগুলির নামকরণের সময় কোনও ধরণের সংস্করণ সিস্টেম ব্যবহার করা হয়েছে, অথবা আপনি ম্যানুয়ালি বা স্বয়ংক্রিয়ভাবে CDN ক্যাশে রিসেট করে এই সংস্থানগুলির জীবনচক্র পরিচালনা করতে পারেন যখন একটি নতুন সংস্করণ প্রকাশ করেন এই পান্ডুলিপি.
• আপনার CDN, প্রক্সি সার্ভার এবং ক্যাশে সেটিংস সম্পর্কে খুব সতর্ক থাকুন। এটি আপনাকে আপনার প্রকল্প বা শিরোনামগুলিকে কুকি পাঠানো থেকে আটকাতে অনুমতি দেবে৷ Client-Hints তৃতীয় পক্ষের পরিষেবা।

প্রিয় পাঠকগণ! আপনি কি আপনার সার্ভারে অন্য লোকেদের সামগ্রী হোস্ট করেন যা আপনার প্রকল্পগুলির অপারেশনের জন্য অত্যন্ত গুরুত্বপূর্ণ?

উত্স: www.habr.com