পরিষেবা কর্মী ক্যাশিং এবং HTTP ক্যাশিং

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

Jonathan Chen

যদিও সার্ভিস ওয়ার্কার এবং পিডব্লিউএ আধুনিক ওয়েব অ্যাপ্লিকেশনগুলোর মানদণ্ড হয়ে উঠছে, রিসোর্স ক্যাশিং আগের চেয়ে অনেক বেশি জটিল হয়ে উঠেছে। এই নিবন্ধে ব্রাউজার ক্যাশিংয়ের একটি সামগ্রিক চিত্র তুলে ধরা হয়েছে, যার মধ্যে অন্তর্ভুক্ত রয়েছে:

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

ক্যাশিং প্রবাহের সংক্ষিপ্ত বিবরণ

সাধারণভাবে, একটি ব্রাউজার যখন কোনো রিসোর্সের জন্য অনুরোধ করে, তখন এটি নিচের ক্যাশিং ক্রমটি অনুসরণ করে:

1. সার্ভিস ওয়ার্কার ক্যাশে : সার্ভিস ওয়ার্কার রিসোর্সটি তার ক্যাশে আছে কিনা তা পরীক্ষা করে এবং তার প্রোগ্রাম করা ক্যাশিং কৌশলের উপর ভিত্তি করে রিসোর্সটি নিজেই ফেরত দেবে কিনা সেই সিদ্ধান্ত নেয়। মনে রাখবেন, এটি স্বয়ংক্রিয়ভাবে ঘটে না। আপনাকে আপনার সার্ভিস ওয়ার্কারে একটি ফেচ ইভেন্ট হ্যান্ডলার তৈরি করতে হবে এবং নেটওয়ার্ক রিকোয়েস্টগুলো ইন্টারসেপ্ট করতে হবে, যাতে রিকোয়েস্টগুলো নেটওয়ার্কের পরিবর্তে সার্ভিস ওয়ার্কারের ক্যাশে থেকে পরিবেশিত হয়।
2. HTTP ক্যাশে (ব্রাউজার ক্যাশে নামেও পরিচিত) : যদি রিসোর্সটি HTTP ক্যাশে পাওয়া যায় এবং এর মেয়াদ এখনও শেষ না হয়ে থাকে, তাহলে ব্রাউজার স্বয়ংক্রিয়ভাবে HTTP ক্যাশে থেকে রিসোর্সটি ব্যবহার করে।
3. সার্ভার-সাইড: যদি সার্ভিস ওয়ার্কার ক্যাশে বা HTTP ক্যাশে কিছু খুঁজে না পাওয়া যায়, তাহলে ব্রাউজার রিসোর্সটির জন্য অনুরোধ করতে নেটওয়ার্কে যায়। যদি রিসোর্সটি কোনো CDN-এ ক্যাশ করা না থাকে, তাহলে অনুরোধটি অবশ্যই একেবারে অরিজিন সার্ভারে ফিরে যেতে হয়।

ক্যাশিং স্তর

পরিষেবা কর্মী ক্যাশিং

একটি সার্ভিস ওয়ার্কার নেটওয়ার্ক-টাইপ HTTP অনুরোধগুলো গ্রহণ করে এবং ব্রাউজারে কোন রিসোর্সগুলো ফেরত পাঠানো হবে তা নির্ধারণ করতে একটি ক্যাশিং কৌশল ব্যবহার করে। সার্ভিস ওয়ার্কার ক্যাশ এবং HTTP ক্যাশ একই সাধারণ উদ্দেশ্য পূরণ করে, কিন্তু সার্ভিস ওয়ার্কার ক্যাশ আরও বেশি ক্যাশিং সুবিধা প্রদান করে, যেমন ঠিক কী ক্যাশ করা হবে এবং কীভাবে ক্যাশিং করা হবে তার উপর সূক্ষ্ম নিয়ন্ত্রণ।

সার্ভিস ওয়ার্কার ক্যাশে নিয়ন্ত্রণ করা

একটি সার্ভিস ওয়ার্কার ইভেন্ট লিসেনারের (সাধারণত fetch ইভেন্ট) মাধ্যমে HTTP রিকোয়েস্ট ইন্টারসেপ্ট করে। এই কোড স্নিপেটটি একটি ক্যাশ-ফার্স্ট ক্যাশিং স্ট্র্যাটেজির লজিক প্রদর্শন করে।

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

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

সার্ভিস ওয়ার্কার ক্যাশিং কৌশল এবং ব্যবহারের ক্ষেত্র

পরবর্তী সারণিতে সাধারণ সার্ভিস ওয়ার্কার ক্যাশিং কৌশলগুলো এবং কখন কোন কৌশলটি উপযোগী, তা তুলে ধরা হয়েছে।

সার্ভিস ওয়ার্কার ক্যাশিংয়ের অতিরিক্ত সুবিধা

ক্যাশিং লজিকের সূক্ষ্ম নিয়ন্ত্রণের পাশাপাশি, সার্ভিস ওয়ার্কার ক্যাশিং আরও যা প্রদান করে:

• আপনার অরিজিনের জন্য আরও বেশি মেমরি এবং স্টোরেজ স্পেস: ব্রাউজার প্রতিটি অরিজিনের জন্য আলাদাভাবে HTTP ক্যাশে রিসোর্স বরাদ্দ করে। অন্য কথায়, যদি আপনার একাধিক সাবডোমেইন থাকে, তবে তারা সবাই একই HTTP ক্যাশে ব্যবহার করে। আপনার অরিজিন/ডোমেইনের কন্টেন্ট যে দীর্ঘ সময়ের জন্য HTTP ক্যাশে থাকবে, তার কোনো নিশ্চয়তা নেই। উদাহরণস্বরূপ, একজন ব্যবহারকারী ব্রাউজারের সেটিংস UI থেকে ম্যানুয়ালি ক্যাশে পরিষ্কার করে বা কোনো পেজ হার্ড-রিলোড করে ক্যাশে মুছে ফেলতে পারেন। সার্ভিস ওয়ার্কার ক্যাশের মাধ্যমে আপনার ক্যাশ করা কন্টেন্ট ক্যাশেই থাকার সম্ভাবনা অনেক বেশি থাকে। আরও জানতে পারসিস্টেন্ট স্টোরেজ দেখুন।
• দুর্বল নেটওয়ার্ক বা অফলাইন অভিজ্ঞতার ক্ষেত্রে অধিকতর নমনীয়তা: HTTP ক্যাশের ক্ষেত্রে আপনার কাছে কেবল দুটি বিকল্প থাকে: হয় রিসোর্সটি ক্যাশ করা হবে, অথবা হবে না। সার্ভিস ওয়ার্কার ক্যাশিংয়ের মাধ্যমে আপনি ছোটখাটো সমস্যা ("stale-while-revalidate" স্ট্র্যাটেজি ব্যবহার করে) অনেক সহজে সমাধান করতে পারেন, একটি সম্পূর্ণ অফলাইন অভিজ্ঞতা দিতে পারেন ("Cache only" স্ট্র্যাটেজি ব্যবহার করে) অথবা এর মাঝামাঝি কিছু করতে পারেন, যেমন কাস্টমাইজড UI তৈরি করা, যেখানে পেজের কিছু অংশ সার্ভিস ওয়ার্কার ক্যাশ থেকে নেওয়া হবে এবং প্রয়োজন অনুযায়ী কিছু অংশ বাদ দেওয়া হবে ("Set catch handler" স্ট্র্যাটেজি ব্যবহার করে)।

HTTP ক্যাশিং

একটি ব্রাউজার যখন প্রথমবার কোনো ওয়েব পেজ এবং সংশ্লিষ্ট রিসোর্স লোড করে, তখন এটি সেই রিসোর্সগুলোকে তার HTTP ক্যাশে সংরক্ষণ করে। HTTP ক্যাশে সাধারণত ব্রাউজার দ্বারা স্বয়ংক্রিয়ভাবে সক্রিয় হয়, যদি না ব্যবহারকারী স্পষ্টভাবে এটি নিষ্ক্রিয় করে থাকেন।

HTTP ক্যাশিং ব্যবহার করার অর্থ হলো, কোনো রিসোর্স কখন এবং কত সময়ের জন্য ক্যাশ করতে হবে, তা নির্ধারণের জন্য সার্ভারের উপর নির্ভর করা।

HTTP রেসপন্স হেডার ব্যবহার করে HTTP ক্যাশের মেয়াদ শেষ হওয়া নিয়ন্ত্রণ করুন

যখন কোনো সার্ভার কোনো রিসোর্সের জন্য ব্রাউজারের অনুরোধে সাড়া দেয়, তখন সার্ভারটি HTTP রেসপন্স হেডার ব্যবহার করে ব্রাউজারকে জানিয়ে দেয় যে রিসোর্সটি কতক্ষণের জন্য ক্যাশ করে রাখা উচিত। আরও জানতে “রেসপন্স হেডার: আপনার ওয়েব সার্ভার কনফিগার করুন” দেখুন।

HTTP ক্যাশিং কৌশল এবং ব্যবহারের ক্ষেত্র

সার্ভিস ওয়ার্কার ক্যাশিংয়ের চেয়ে HTTP ক্যাশিং অনেক সহজ, কারণ HTTP ক্যাশিং শুধুমাত্র সময়-ভিত্তিক (TTL) রিসোর্স এক্সপায়ারেশন লজিক নিয়ে কাজ করে। HTTP ক্যাশিং কৌশল সম্পর্কে আরও জানতে “আপনার কোন রেসপন্স হেডার ভ্যালু ব্যবহার করা উচিত?” এবং “HTTP ক্যাশের মাধ্যমে অপ্রয়োজনীয় নেটওয়ার্ক রিকোয়েস্ট প্রতিরোধ করুন (সারাংশ)” দেখুন।

আপনার ক্যাশে মেয়াদ শেষ হওয়ার যুক্তি ডিজাইন করা

এই অংশে সার্ভিস ওয়ার্কার ক্যাশে এবং এইচটিটিপি ক্যাশে লেয়ার জুড়ে একই এক্সপায়ারি লজিক ব্যবহারের সুবিধা ও অসুবিধা, এবং সেইসাথে এই লেয়ারগুলোতে আলাদা এক্সপায়ারি লজিক ব্যবহারের সুবিধা ও অসুবিধা ব্যাখ্যা করা হয়েছে।

সমস্ত ক্যাশ লেয়ারের জন্য সামঞ্জস্যপূর্ণ মেয়াদোত্তীর্ণ হওয়ার যুক্তি

সুবিধা ও অসুবিধাগুলো দেখানোর জন্য আমরা তিনটি পরিস্থিতি বিবেচনা করব: দীর্ঘমেয়াদী, মধ্যমেয়াদী এবং স্বল্পমেয়াদী।

দৃশ্যকল্প: দীর্ঘমেয়াদী ক্যাশিং (ক্যাশ, নেটওয়ার্কে ফিরে যাওয়া)

• যখন কোনো ক্যাশ করা রিসোর্স বৈধ থাকে (৩০ দিন বা তার কম): সার্ভিস ওয়ার্কার নেটওয়ার্কে না গিয়েই তাৎক্ষণিকভাবে ক্যাশ করা রিসোর্সটি ফেরত দেয়।
• যখন কোনো ক্যাশ করা রিসোর্সের মেয়াদ শেষ হয়ে যায় (৩০ দিনের বেশি): সার্ভিস ওয়ার্কার রিসোর্সটি আনার জন্য নেটওয়ার্কে যায়। ব্রাউজারের HTTP ক্যাশে রিসোর্সটির কোনো কপি থাকে না, তাই এটি রিসোর্সটির জন্য সার্ভার-সাইডে যায়।

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

দৃশ্যকল্প: মধ্য-মেয়াদী ক্যাশিং (পুনরায় বৈধতা দেওয়ার সময় পুরোনো)

• যখন কোনো ক্যাশ করা রিসোর্স বৈধ থাকে (<= ১ দিন): সার্ভিস ওয়ার্কার তাৎক্ষণিকভাবে ক্যাশ করা রিসোর্সটি ফেরত দেয় এবং রিসোর্সটি ফেচ করার জন্য নেটওয়ার্কে যায়। ব্রাউজারের HTTP ক্যাশে রিসোর্সটির একটি কপি থাকে, তাই এটি সেই কপিটি সার্ভিস ওয়ার্কারকে ফেরত দেয়।
• যখন কোনো ক্যাশ করা রিসোর্সের মেয়াদ শেষ হয়ে যায় (> ১ দিন): সার্ভিস ওয়ার্কার তাৎক্ষণিকভাবে ক্যাশ করা রিসোর্সটি ফেরত দেয় এবং রিসোর্সটি আনার জন্য নেটওয়ার্কে যায়। ব্রাউজারের HTTP ক্যাশে রিসোর্সটির কোনো কপি থাকে না, তাই এটি রিসোর্সটি আনার জন্য সার্ভার-সাইডে যায়।

অসুবিধা: "revalidate" ধাপটির সম্পূর্ণ সুবিধা নিতে, সার্ভিস ওয়ার্কারটির HTTP ক্যাশকে ওভাররাইড করার জন্য অতিরিক্ত ক্যাশ-বাস্টিং প্রয়োজন হয়।

দৃশ্যকল্প: স্বল্পমেয়াদী ক্যাশিং (নেটওয়ার্ক ক্যাশে ফিরে যাচ্ছে)

• যখন কোনো ক্যাশ করা রিসোর্স বৈধ থাকে (<= ১০ মিনিট): সার্ভিস ওয়ার্কার রিসোর্সটি আনার জন্য নেটওয়ার্কে যায়। ব্রাউজারের HTTP ক্যাশে রিসোর্সটির একটি কপি থাকে, তাই এটি সার্ভার-সাইডে না গিয়েই সেটি সার্ভিস ওয়ার্কারকে ফেরত দেয়।
• যখন কোনো ক্যাশ করা রিসোর্সের মেয়াদ শেষ হয়ে যায় (> ১০ মিনিট): সার্ভিস ওয়ার্কার তাৎক্ষণিকভাবে ক্যাশ করা রিসোর্সটি ফেরত দেয় এবং রিসোর্সটি আনার জন্য নেটওয়ার্কে যায়। ব্রাউজারের HTTP ক্যাশে রিসোর্সটির কোনো কপি থাকে না, তাই এটি রিসোর্সটি আনার জন্য সার্ভার-সাইডে যায়।

অসুবিধা: মধ্যম-মেয়াদী ক্যাশিং পরিস্থিতির মতোই, সার্ভার-সাইড থেকে সর্বশেষ রিসোর্সটি আনার জন্য সার্ভিস ওয়ার্কারকে HTTP ক্যাশ ওভাররাইড করতে অতিরিক্ত ক্যাশ-বাস্টিং লজিকের প্রয়োজন হয়।

সকল পরিস্থিতিতে পরিষেবা কর্মী

সব পরিস্থিতিতেই, নেটওয়ার্ক অস্থিতিশীল থাকলেও সার্ভিস ওয়ার্কার ক্যাশে ক্যাশ করা রিসোর্স ফেরত দিতে পারে। অন্যদিকে, নেটওয়ার্ক অস্থিতিশীল বা ডাউন থাকলে HTTP ক্যাশে নির্ভরযোগ্য নয়।

সার্ভিস ওয়ার্কার ক্যাশে এবং HTTP লেয়ারে ক্যাশে মেয়াদ শেষ হওয়ার লজিক ভিন্ন।

সুবিধা ও অসুবিধাগুলো তুলে ধরতে আমরা আবারও দীর্ঘমেয়াদী, মধ্যমেয়াদী এবং স্বল্পমেয়াদী পরিস্থিতিগুলো পর্যালোচনা করব।

দৃশ্যকল্প: দীর্ঘমেয়াদী ক্যাশিং (ক্যাশ, নেটওয়ার্কে ফিরে যাওয়া)

• যখন সার্ভিস ওয়ার্কার ক্যাশে কোনো ক্যাশ করা রিসোর্স বৈধ থাকে (৯০ দিন বা তার কম): সার্ভিস ওয়ার্কার তাৎক্ষণিকভাবে ক্যাশ করা রিসোর্সটি ফেরত দেয়।
• যখন সার্ভিস ওয়ার্কার ক্যাশে থাকা কোনো ক্যাশ করা রিসোর্সের মেয়াদ শেষ হয়ে যায় (> ৯০ দিন): সার্ভিস ওয়ার্কার রিসোর্সটি আনার জন্য নেটওয়ার্কে যায়। ব্রাউজারের HTTP ক্যাশে রিসোর্সটির কোনো কপি না থাকায়, এটি সার্ভার-সাইডে যায়।

সুবিধা ও অসুবিধা:

• সুবিধা: ব্যবহারকারীরা তাৎক্ষণিক প্রতিক্রিয়া পান, কারণ সার্ভিস ওয়ার্কার ক্যাশ করা রিসোর্সগুলো সঙ্গে সঙ্গে ফেরত দেয়।
• সুবিধা: সার্ভিস ওয়ার্কারের আরও সূক্ষ্ম নিয়ন্ত্রণ থাকে যে কখন তার ক্যাশে ব্যবহার করতে হবে এবং কখন রিসোর্সের নতুন সংস্করণের জন্য অনুরোধ করতে হবে।
• অসুবিধা: একটি সুনির্দিষ্ট সার্ভিস ওয়ার্কার ক্যাশিং কৌশল প্রয়োজন।

দৃশ্যকল্প: মধ্য-মেয়াদী ক্যাশিং (পুনরায় যাচাই করার সময় পুরোনো)

• যখন সার্ভিস ওয়ার্কার ক্যাশে কোনো ক্যাশ করা রিসোর্স বৈধ থাকে (৩০ দিন বা তার কম): সার্ভিস ওয়ার্কার তাৎক্ষণিকভাবে ক্যাশ করা রিসোর্সটি ফেরত দেয়।
• যখন সার্ভিস ওয়ার্কার ক্যাশে থাকা কোনো ক্যাশ করা রিসোর্সের মেয়াদ শেষ হয়ে যায় (> ৩০ ​​দিন): সার্ভিস ওয়ার্কার রিসোর্সটির জন্য নেটওয়ার্কে যায়। ব্রাউজারের HTTP ক্যাশে রিসোর্সটির কোনো কপি না থাকায়, এটি সার্ভার-সাইডে যায়।

সুবিধা ও অসুবিধা:

• সুবিধা: ব্যবহারকারীরা তাৎক্ষণিক প্রতিক্রিয়া পান, কারণ সার্ভিস ওয়ার্কার ক্যাশ করা রিসোর্সগুলো সঙ্গে সঙ্গে ফেরত দেয়।
• সুবিধা: ব্যাকগ্রাউন্ডে হওয়া রিভ্যালিডেশনের ফলে সার্ভিস ওয়ার্কার এটা নিশ্চিত করতে পারে যে, কোনো নির্দিষ্ট URL-এর জন্য পরবর্তী অনুরোধে নেটওয়ার্ক থেকে একটি নতুন রেসপন্স ব্যবহার করা হবে।
• অসুবিধা: একটি সুনির্দিষ্ট সার্ভিস ওয়ার্কার ক্যাশিং কৌশল প্রয়োজন।

দৃশ্যকল্প: স্বল্পমেয়াদী ক্যাশিং (নেটওয়ার্ক ক্যাশে ফিরে যাচ্ছে)

• যখন সার্ভিস ওয়ার্কার ক্যাশে কোনো ক্যাশ করা রিসোর্স বৈধ থাকে (১ দিন বা তার কম): সার্ভিস ওয়ার্কার রিসোর্সটির জন্য নেটওয়ার্কে অনুসন্ধান করে। রিসোর্সটি HTTP ক্যাশে থাকলে ব্রাউজার সেখান থেকে তা ফেরত দেয়। নেটওয়ার্ক ডাউন থাকলে, সার্ভিস ওয়ার্কার তার নিজস্ব ক্যাশ থেকে রিসোর্সটি ফেরত দেয়।
• যখন সার্ভিস ওয়ার্কার ক্যাশে থাকা কোনো ক্যাশ করা রিসোর্সের মেয়াদ শেষ হয়ে যায় (> ১ দিন): সার্ভিস ওয়ার্কার রিসোর্সটি আনার জন্য নেটওয়ার্কে যায়। যেহেতু ব্রাউজারের HTTP ক্যাশে থাকা সংস্করণটির মেয়াদ শেষ হয়ে গেছে, তাই ব্রাউজার নেটওয়ার্কের মাধ্যমে রিসোর্সটি সংগ্রহ করে।

সুবিধা ও অসুবিধা:

• সুবিধা: নেটওয়ার্ক অস্থিতিশীল বা ডাউন থাকলে, সার্ভিস ওয়ার্কার তাৎক্ষণিকভাবে ক্যাশ করা রিসোর্সগুলো ফেরত দেয়।
• অসুবিধা: HTTP ক্যাশে ওভাররাইড করতে এবং "নেটওয়ার্ক ফার্স্ট" রিকোয়েস্ট পাঠানোর জন্য সার্ভিস ওয়ার্কারটির অতিরিক্ত ক্যাশে-বাস্টিং প্রয়োজন হয়।

উপসংহার

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

• সার্ভিস ওয়ার্কারের ক্যাশিং লজিককে HTTP ক্যাশিং এক্সপায়ারি লজিকের সাথে সামঞ্জস্যপূর্ণ হতে হবে না। সম্ভব হলে, সার্ভিস ওয়ার্কারকে আরও বেশি নিয়ন্ত্রণ দেওয়ার জন্য এতে দীর্ঘতর মেয়াদের লজিক ব্যবহার করুন।
• HTTP ক্যাশিং এখনও একটি গুরুত্বপূর্ণ ভূমিকা পালন করে, কিন্তু নেটওয়ার্ক অস্থিতিশীল বা ডাউন থাকলে এটি নির্ভরযোগ্য নয়।
• প্রতিটি রিসোর্সের জন্য আপনার ক্যাশিং কৌশলগুলো পুনরায় পর্যালোচনা করুন, যাতে নিশ্চিত করা যায় যে আপনার সার্ভিস ওয়ার্কার ক্যাশিং কৌশলটি HTTP ক্যাশের সাথে কোনো বিরোধ না ঘটিয়ে তার কার্যকারিতা প্রদান করছে।

আরও জানুন

• নেটওয়ার্কের নির্ভরযোগ্যতা
• HTTP ক্যাশের মাধ্যমে অপ্রয়োজনীয় নেটওয়ার্ক অনুরোধ প্রতিরোধ করুন।
• HTTP ক্যাশে কোডল্যাব
• পরিষেবা কর্মীদের বাস্তব কর্মদক্ষতার প্রভাব পরিমাপ করা
• ক্যাশ-কন্ট্রোল বনাম এক্সপায়ার
• ক্যাশিংয়ের রহস্য উন্মোচন: ক্যাশ পরিদর্শন, পরিষ্কার এবং নিষ্ক্রিয় করুন