যখন ওয়েবসাররা কোনও পৃষ্ঠা প্রেরণ করে, তখন তারা কেন সমস্ত প্রয়োজনীয় সিএসএস, জেএস, এবং চিত্রগুলি জিজ্ঞাসা না করে প্রেরণ করবে না?

45

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

ব্রাউজারটি ওয়েবপৃষ্ঠার জন্য প্রাথমিক জিইটি অনুরোধ প্রেরণ করে এবং সার্ভারের প্রতিক্রিয়ার জন্য অপেক্ষা করে।
ব্রাউজার সিএসএস ফাইলের জন্য অন্য জিইটি অনুরোধ প্রেরণ করে এবং সার্ভারের প্রতিক্রিয়ার জন্য অপেক্ষা করে।
ব্রাউজারটি চিত্র ফাইলের জন্য অন্য একটি জিইটি অনুরোধ প্রেরণ করে এবং সার্ভারের প্রতিক্রিয়ার জন্য অপেক্ষা করে।

পরিবর্তে তারা এই সংক্ষিপ্ত, প্রত্যক্ষ, সময় সাশ্রয়কারী রুটটি ব্যবহার করতে পারে?

ব্রাউজার একটি ওয়েব পৃষ্ঠার জন্য একটি জিইটি অনুরোধ প্রেরণ করে।
ওয়েব সার্ভার এর সাথে প্রতিক্রিয়া জানায় ( index.html এর পরে style.css এবং image.jpg )

— আহমেদ
সূত্র

2

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

— ক্লোজটোনক

20

আমি অবাক হয়েছি কেউই ক্যাশিংয়ের কথা উল্লেখ করেনি। যদি আমার কাছে ইতিমধ্যে সেই ফাইলটি থাকে তবে আমার কাছে এটি প্রেরণের দরকার নেই।

— কোরি ওগবার্ন 21

2

এই তালিকাটি কয়েক শত জিনিস দীর্ঘ হতে পারে। প্রকৃতপক্ষে ফাইলগুলি প্রেরণের চেয়ে ছোট হলেও এটি এখনও একটি অনুকূল সমাধান থেকে বেশ দূরে।

— কোরি ওগবার্ন

1

প্রকৃতপক্ষে, আমি এমন কোনও ওয়েব পৃষ্ঠাতে

— আহমেদ

2

@ আহমেদএলসুবকি: ব্রাউজারটি প্রথমে পৃষ্ঠাটি পুনরুদ্ধার না করে ক্যাশেড-রিসোর্স হেডার হিসাবে কী সংস্থান পাঠানো যেতে পারে তা ব্রাউজারটি জানে না doesn't এটি কোনও গোপনীয়তা এবং সুরক্ষা দুঃস্বপ্ন হতে পারে যদি কোনও পৃষ্ঠা পুনরুদ্ধার করা সার্ভারকে বলে যে আমার কাছে অন্য একটি পৃষ্ঠা ক্যাশে আছে, যা সম্ভবত মূল পৃষ্ঠার (একটি বহু-ভাড়াটে ওয়েবসাইট) এর চেয়ে পৃথক সংস্থা দ্বারা নিয়ন্ত্রিত।

— মিথ্যা রায়ান

63

সংক্ষিপ্ত উত্তরটি "কারণ HTTP এর জন্য ডিজাইন করা হয়নি"।

টিম বার্নার্স-লি কোনও দক্ষ এবং এক্সটেনসিবল নেটওয়ার্ক প্রোটোকল ডিজাইন করেননি। তাঁর এক ডিজাইনের লক্ষ্য ছিল সরলতা। (কলেজে আমার নেটওয়ার্কিং ক্লাসের অধ্যাপক বলেছিলেন যে তাঁর পেশাগত পেশাজীবীদের উপর ছেড়ে দেওয়া উচিত ছিল।) আপনি যে সমস্যাটির রূপরেখাটি উল্লেখ করেন তা হ'ল এইচটিটিপি প্রোটোকল নিয়ে থাকা অনেক সমস্যার মধ্যে একটি। এর মূল আকারে:

কোনও প্রোটোকল সংস্করণ ছিল না, কেবলমাত্র একটি উত্সের অনুরোধ
কোন শিরোনাম ছিল
প্রতিটি অনুরোধের জন্য একটি নতুন টিসিপি সংযোগ প্রয়োজন
কোন সংকোচনের ছিল না

প্রোটোকল পরে এই সমস্যার অনেকগুলি সমাধান করার জন্য সংশোধিত হয়েছিল:

অনুরোধগুলি ভার্সন করা হয়েছিল, এখন অনুরোধগুলি দেখতে ভাল লাগবে GET /foo.html HTTP/1.1
অনুরোধ এবং প্রতিক্রিয়া উভয়ই শিরোনামগুলি মেটা তথ্যের জন্য যুক্ত করা হয়েছিল
সংযোগগুলি পুনরায় ব্যবহার করার অনুমতি দেওয়া হয়েছিল Connection: keep-alive
দস্তাবেজের আকার সময়ের আগে জানা না গেলেও সংযোগগুলি পুনরায় ব্যবহার করার অনুমতি দেওয়ার জন্য খণ্ডিত প্রতিক্রিয়াগুলি প্রবর্তিত হয়েছিল।
জিজিপ সংক্ষেপণ যুক্ত করা হয়েছিল

এই মুহুর্তে এইচটিটিপি পিছনের দিকের সামঞ্জস্যতা না ভেঙে যতদূর সম্ভব নেওয়া হয়েছে।

আপনি প্রথম ব্যক্তি নন যে কোনও পৃষ্ঠা এবং তার সমস্ত সংস্থান ক্লায়েন্টের দিকে ঠেলে দেওয়া উচিত। আসলে, গুগল এমন একটি প্রোটোকল তৈরি করেছে যা এসপিডিওয়াই নামে পরিচিত ।

বর্তমানে ক্রোম এবং ফায়ারফক্স উভয়ই এটি সমর্থন করে এমন সার্ভারগুলিতে HTTP এর পরিবর্তে SPDY ব্যবহার করতে পারে। এসপিডিওয়াই ওয়েবসাইট থেকে, HTTP এর তুলনায় এর প্রধান বৈশিষ্ট্যগুলি হ'ল:

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

এসপিডিওয়াই একক সংযোগের জন্য একাধিক, একাধিকবার অনুরোধগুলি ক্লায়েন্ট এবং সার্ভারের মধ্যে রাউন্ড ট্রিপগুলিতে সঞ্চয় করে এবং নিম্ন-অগ্রাধিকার সংস্থানগুলিকে উচ্চ-অগ্রাধিকারের অনুরোধগুলি ব্লক করা থেকে রোধ করে allows

এসপিডিওয়াই সার্ভারকে ক্লায়েন্টের সক্রিয়ভাবে সংস্থানগুলি সঞ্চার করতে দেয় যে এটি জানে যে ক্লায়েন্টের প্রয়োজন হবে (যেমন জাভাস্ক্রিপ্ট এবং সিএসএস ফাইল) তাদের ক্লায়েন্টের জন্য অনুরোধ না করে অপেক্ষা করে, সার্ভারটিকে ব্যবহার না করা ব্যান্ডউইথের দক্ষ ব্যবহার করতে দেয়।

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

এসপিডিওয়াই সার্ভার পুশ প্রযুক্তির সাথে এইচটিটিপি সংস্করণ 2 এর ভিত্তি হয়ে উঠেছে ।

— স্টিফেন অসটারমিলার
সূত্র

2

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

— ক্লোজটোনক

6

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

— জাস্ট

3

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

— মিসৌথ

11

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

— শান্তনু তিওয়ারি

2

স্পষ্ট করে বলতে গেলে কোনও যোগ্য পেশাদার আর নেই। বিশ্বব্যাপী ওয়েব কীভাবে বানাতে হয় তা কেউ জানে না, কারণ কারওর কোনওটিই কখনও এটি তৈরি করেনি। হাইপারমিডিয়া ধারণাটি টিম আবিষ্কার করেননি, তিনি সিইআরএন-তে "তথ্য হারাতে" সমস্যা সমাধানের জন্য "ইনফরমেশন ম্যানেজমেন্ট" এর প্রস্তাব লেখার দশ বছর আগে বিভিন্ন স্থানীয় অঞ্চল হাইপারমিডিয়া সিস্টেমের সাথে অভিজ্ঞতা অর্জন করেছিলেন।

— মিথ্যা রায়ান

14

আপনার ওয়েব ব্রাউজারটি অতিরিক্ত সংস্থানগুলি সম্পর্কে জানে না যতক্ষণ না এটি সার্ভার থেকে ওয়েব পৃষ্ঠা (এইচটিএমএল) ডাউনলোড করে, যাতে সেই সংস্থানগুলির লিঙ্ক রয়েছে।

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

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

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

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

জিবন্ত রাখ

পাইপলাইনিং

কিছুটা ওয়েব ইতিহাস ...

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

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

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

উত্স: আমি নোড.জেএস এর মতো ইভেন্ট-ভিত্তিক ওয়েব সার্ভার তৈরি করেছি একে র‌্যাপিড সার্ভার বলে ।

তথ্যসূত্র:

আরও পড়া:

— পেরি
সূত্র

ওয়েল, আসলে, আমরা ঐ সমস্ত পার্শ্ব-সমস্যার যত্ন নিতে পারি (যেমন জিনিস: ক্যাশে, সামগ্রী-প্রকার header..etc), আছে সমাধান নীচে উপস্থিত এই সমস্যার সমাধানের। এবং আমি উপরের পোস্টে মন্তব্যে যেমন পরামর্শ দিয়েছি, আমরা এই শিরোনামের মতো কিছু ব্যবহার করতে পারি> ক্যাশেড-রিসোর্সস: image.jpg; style.css; ক্যাশে সমস্যা সমাধানের জন্য .. (যদি আপনার কাছে সময় থাকে তবে আপনি উপরের মন্তব্যগুলি একবার দেখে নিতে পারেন ..)

— আহমেদ

হ্যাঁ এই ধারণাটি আগে আমার মনকে অতিক্রম করেছিল, তবে এটি HTTP- র পক্ষে কেবলমাত্র অত্যধিক ওভারহেড এবং এটি একাধিক সার্ভারগুলিতে সংস্থানগুলি ছড়িয়ে দেওয়া হতে পারে তা এই সমস্যার সমাধান করে না। তদুপরি, আমি মনে করি না যে আপনার প্রস্তাবিত সময় সাশ্রয় করার পদ্ধতিটি আসলে সময় সাশ্রয় করবে কারণ আপনি যেভাবেই দেখেন না কেন তথ্য প্রবাহ হিসাবে প্রেরণ করা হবে এবং বাঁচিয়ে রাখার সাথে সাথে একসাথে ১০০ টি এইচটিটিপি অনুরোধ মূলত ১ টি অনুরোধ হয়ে যায়। আপনার প্রস্তাবিত প্রযুক্তি এবং দক্ষতা ইতিমধ্যে একটি উপায়ে উপস্থিত রয়েছে বলে মনে হচ্ছে। En.wikedia.org/wiki/HTTP_persistent_connection

— পেরি

@ পেয়ারি: https://বড় আকারে প্রকাশিত বিতরণকৃত ফাইল প্রেরণের বিকল্পের ধারণা সম্পর্কে আপনি কী ভাবেন যা প্রমাণীকরণের প্রয়োজন হয় তবে গোপনীয় রাখা যায় না: ইউআরএলটিতে বৈধ জবাবের শিরোনামের কিছু অংশের একটি হ্যাশ অন্তর্ভুক্ত থাকে যা পরিবর্তিত হতে পারে ডেটা পেওলডের একটি স্বাক্ষর বা হ্যাশ অন্তর্ভুক্ত করুন এবং ব্রাউজারগুলি শিরোনামের বিপরীতে প্রাপ্ত ডেটাটিকে বৈধতা দিয়েছে? এই জাতীয় নকশা কেবল কয়েকটি এসএসএল হ্যান্ডশেকের পদক্ষেপগুলি সংরক্ষণ করবে না, তবে আরও গুরুত্বপূর্ণভাবে প্রক্সিগুলির ক্যাশে দেওয়ার অনুমতি দেবে। কোনও এসএসএল লিঙ্কের মাধ্যমে URL পান এবং কোথাও থেকে ডেটা দেওয়া যেতে পারে।

— সুপারক্যাট

11

কারণ তারা জানে না যে এই সংস্থানগুলি কী। ওয়েব পৃষ্ঠার যে সম্পদগুলি প্রয়োজন তা HTML এ কোড করা হয়। কোনও পার্সার নির্ধারণ করার পরে those সম্পদগুলি কী তা ব্যবহারকারী-এজেন্টের মাধ্যমে y এর জন্য অনুরোধ করা যেতে পারে।

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

— জন কনডে
সূত্র

2

বিশেষত যদি আপনি need.js এর মতো কিছু ব্যবহার করেন। ব্রাউজারটি কেবল এটির জন্য যা প্রয়োজন তা জিজ্ঞাসা করে। একবারে সব কিছু লোড করার কথা ভাবুন ...

— অরণ মুলহোল্যান্ড

2

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

1

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

— ডেভিড মিস্টার

@ ডেভিডমিস্টার যেহেতু সার্ভার সর্বদা ক্লায়েন্ট কী চায় তা জানে না - কোনও অনুসন্ধান ইঞ্জিনের জন্য একটি ওয়েবক্রোলার হয়ত সিএসএস / জেএস সম্পর্কে চিন্তা করে না এবং এর বাইরেও কোনও নথিতে লিঙ্কযুক্ত আরও অনেক সংস্থান রয়েছে - পুরো পাঠানোর দরকার নেই আরএসএস প্যাকেজে কোনও ওয়েব ব্রাউজারে ফিড দেয় (বেশিরভাগ সামগ্রী সম্ভবত ইতিমধ্যে এইচটিএমএলে রয়েছে), যখন কোনও ফিড রিডার কেবল <head>আরএসএস বিকল্প লিঙ্কগুলির সন্ধানকারী উপাদানটিকে কেবল এটি আবিষ্কার করতে পারে - ক্লায়েন্ট একটি তালিকা পাঠাতে পারে এটি কী সম্পর্কে আগ্রহী, তবে তারপরে এটি কী পাওয়া যায় তা জানতে হবে এবং আমরা শুরুতে ফিরে এসেছি

— ঝাফ - বেন ডুগুইড

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

— ডেভিড মিস্টার

8

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

এখন, আপনি " ঠিক আছে " বলে ব্যান্ডউইদথের অপচয়কে ঘিরে কাজ করার চেষ্টা করতে পারেন তবে ক্লায়েন্টটি ইঙ্গিত দিতে পারে যে এর মধ্যে ইতিমধ্যে কিছু সংস্থান রয়েছে, তাই সার্ভার আবার এটি প্রেরণ করবে না "। কিছুটা এইরকম:

GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "686897696a7c876b7e"
Connection: Keep-Alive

GET /style.css HTTP/1.1
Host: www.example.com
If-None-Match: "70b26618ce2c246c71"

GET /image.png HTTP/1.1
Host: www.example.com
If-None-Match: "16d5b7c2e50e571a46"

এবং তারপরে পরিবর্তিত হয়নি কেবল এমন ফাইলগুলি পান যা একটি টিসিপি সংযোগের মাধ্যমে প্রেরিত হয়ে যায় (অবিচ্ছিন্ন সংযোগের উপরে এইচটিটিপি পাইপলাইন ব্যবহার করে)। এবং কি অনুমান? এটি ইতিমধ্যে কীভাবে কাজ করে (আপনি যদি ইফ- নন -ম্যাচের পরিবর্তে ইফ-মডিফায়েড-যেহেতু ব্যবহার করতে পারেন )।

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

এটি করার জন্য, আপনার পৃথক ফাইলে সিএসএস বা জাভাস্ক্রিপ্ট থাকতে হবে না, আপনি এগুলি ব্যবহার করে <style>এবং <script>ট্যাগ ব্যবহার করে মূল HTML ফাইলটিতে অন্তর্ভুক্ত করতে পারেন (আপনার সম্ভবত এটি নিজে নিজে করার দরকারও নেই, আপনার টেম্পলেট ইঞ্জিনটি সম্ভবত এটি স্বয়ংক্রিয়ভাবে করতে পারে) । আপনি এমনকি ইউআরআই ডেটা ব্যবহার করে এইচটিএমএল ফাইলে চিত্রগুলি অন্তর্ভুক্ত করতে পারেন :

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

অবশ্যই, বেস 64 এনকোডিং ব্যান্ডউইথের ব্যবহার সামান্য বাড়িয়ে তোলে তবে আপনি যদি নষ্ট ব্যান্ডউইথের বিষয়ে চিন্তা না করেন তবে এটি কোনও সমস্যা হবে না।

এখন, যদি আপনি সত্যিই যত্নবান হন তবে আপনি ওয়েব স্ক্রিপ্টগুলি উভয় বিশ্বের সেরা পাওয়ার জন্য যথেষ্ট স্মার্ট করে তুলতে পারেন: প্রথম অনুরোধে (ব্যবহারকারীর একটি কুকি নেই), কেবলমাত্র একটি একক এইচটিএমএলে এমবেড থাকা সমস্ত কিছু (সিএসএস, জাভাস্ক্রিপ্ট, চিত্র) প্রেরণ করুন উপরে বর্ণিত ফাইল হিসাবে ফাইলের বাহ্যিক অনুলিপিগুলির জন্য একটি লিঙ্ক rel = "প্রিফেট" ট্যাগ যুক্ত করুন এবং একটি কুকি যুক্ত করুন। ব্যবহারকারী ইতিমধ্যে (যেমন। তিনি আগে পরিদর্শন করেছেন) একটি কুকি থাকে, তাহলে তার সঙ্গে শুধু একটি স্বাভাবিক এইচটিএমএল পাঠাতে <img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">ইত্যাদি

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

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

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

— মাতিজা নালিস
সূত্র

3

আমি মনে করি এটি সঠিক উত্তর।

— el.pescado

7

এইচটিটিপি 2 এসপিডিওয়াইয়ের উপর ভিত্তি করে এবং আপনার পরামর্শ অনুসারে ঠিক তাই করে:

উচ্চ স্তরে, HTTP / 2:

পাঠ্য পরিবর্তে বাইনারি হয়

অর্ডার করা এবং ব্লক করার পরিবর্তে সম্পূর্ণ মাল্টিপ্লেক্সড

সুতরাং সমান্তরালতার জন্য একটি সংযোগ ব্যবহার করতে পারেন

ওভারহেড কমাতে হেডার সংকোচনের ব্যবহার করে

সার্ভারগুলিকে ক্লায়েন্ট ক্যাশে সক্রিয়ভাবে প্রতিক্রিয়াগুলি "ধাক্কা" দিতে দেয়

আরও এইচটিটিপি 2 ফ্যাক্সে পাওয়া যায়

— MaBu
সূত্র

3

কারণ এটি ধরে নেই যে এই জিনিসগুলি আসলে প্রয়োজনীয় ।

প্রোটোকল কোনও বিশেষ ধরণের ফাইল বা ব্যবহারকারী-এজেন্টের জন্য কোনও বিশেষ হ্যান্ডলিং সংজ্ঞায়িত করে না। এটি একটি HTML ফাইল এবং একটি পিএনজি চিত্রের মধ্যে পার্থক্যটি জানে না know আপনি যা যা বলছেন তা করার জন্য, ওয়েব সার্ভারকে ফাইলের ধরণটি সনাক্ত করতে হবে, এটি উল্লেখ করছে যে এটি অন্যান্য ফাইলগুলি কী উল্লেখ করছে এবং তা নির্ধারণ করতে হবে এবং তারপরে আপনি যা করতে চান তার ভিত্তিতে কোন ফাইলগুলি আসলে প্রয়োজন তা নির্ধারণ করতে হবে ফাইল । এটি নিয়ে তিনটি বড় সমস্যা রয়েছে।

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

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

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

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

— স্পুনিস্ট
সূত্র

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

— আহমেদ

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

— দ্য স্পুনিস্টে