HTTP পোলিং, লং পোলিং, এইচটিটিপি স্ট্রিমিং এবং ওয়েবসকেট সম্পর্কে আমার বোঝাপড়া


123

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

এইচটিপি পোলিং: এক্সএমএলএইচটিপিআরকোয়েস্ট ব্যবহার করে মূলত এজেএক্স।

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

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

জাভা অ্যাপলেট, ফ্ল্যাশ, সিলভারলাইট: তারা সকেট সার্ভারের সাথে tcp / ip এর সাথে সংযোগ স্থাপনের ক্ষমতা সরবরাহ করে তবে তারা যেহেতু প্লাগইন, তাই বিকাশকারীরা তাদের উপর নির্ভর করতে চান না।

ওয়েবসকেটস: এগুলি হ'ল নতুন এপিআই যা নীচের পদ্ধতিতে উপরোক্ত পদ্ধতির সংক্ষিপ্তসারগুলি সমাধান করার চেষ্টা করে:

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

আমি অনুপস্থিত অন্য কোন উল্লেখযোগ্য পার্থক্য আছে? আমি দুঃখিত যদি আমি ইতিমধ্যে এসও-তে থাকা অনেকগুলি প্রশ্নকে একক প্রশ্নের মধ্যে পুনরায় জিজ্ঞাসা করি বা একত্রিত করি তবে এসও এবং ওয়েবে এই ধারণাগুলি সম্পর্কে যে সমস্ত তথ্য রয়েছে সেগুলি থেকে আমি কেবল সঠিক ধারণাটি তৈরি করতে চাই।

ধন্যবাদ!


4
যখন আপনার দ্বি-দিকনির্দেশক যোগাযোগের প্রয়োজন নেই তখন সার্ভার-প্রেরিত ইভেন্টগুলিও দেখার মতো হতে পারে।
লেগেটেটার

1
এটি সত্যিই দরকারী প্রশ্ন। আমি মনে করি একাধিক লেখক এতে অবদান রাখতে পারে এমন একটি উত্তর থাকলে এটি সম্ভবত আরও কার্যকর হবে be
লেগেটেটার

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

1
এইচটিটিপি স্ট্রিমিং এবং দীর্ঘ-পোলিংয়ের মাধ্যমে দ্বি-দিকনির্দেশক যোগাযোগের জন্য আপনার একটি দ্বিতীয় সংযোগ প্রয়োজন। সার্ভার -> ক্লায়েন্ট 'ধাক্কা' যোগাযোগের জন্য আর দীর্ঘকালীন সংযোগ এবং ক্লায়েন্টের জন্য দ্বিতীয় স্বল্প জীবিত সংযোগ -> সার্ভার কমস। এই দ্বিতীয় সংযোগটি ডেটাতে সাবস্ক্রিপশন সেট আপ এবং পরিবর্তন করা হিসাবে কাজ করতে ব্যবহৃত হয়। সুতরাং, ইভেন্টসোর্স দ্বি-দিকের সমাধানে ব্যবহার করা যেতে পারে এবং বাস্তবে এইচটিটিপি স্ট্রিমিং এবং লং-পোলিং থেকে জন্ম নেওয়া একটি মানক সমাধান।
লেগেটেটার

1
: আপনি কৌশল এই শ্রেণীবিভাগ আমি লিখেছি চেক আউট করতে চাইতে পারেন stackoverflow.com/questions/12078550/...
আলেসান্দ্রো Alinone

উত্তর:


92

আপনি চিহ্নিত করেছেন তার চেয়ে আরও বেশি পার্থক্য রয়েছে।

দ্বৈত / নির্দেশমূলক:

  • ইউনি-দিকনির্দেশক: এইচটিটিপি পোল, দীর্ঘ পোল, স্ট্রিমিং।
  • দ্বি-নির্দেশনা: ওয়েবসকেটস, প্লাগইন নেটওয়ার্কিং

ক্রমবর্ধমান বিলম্বের ক্রম (আনুমানিক):

  • ওয়েবসকেট
  • প্লাগইন নেটওয়ার্কিং
  • এইচটিটিপি স্ট্রিমিং
  • এইচটিটিপি লং-পোল
  • এইচটিটিপি ভোটদান

কর্স (ক্রস-অরিজিন সমর্থন):

  • ওয়েবসকেটস: হ্যাঁ
  • প্লাগইন নেটওয়ার্কিং: নীতি অনুরোধের মাধ্যমে ফ্ল্যাশ করুন (অন্যদের সম্পর্কে নিশ্চিত নয়)
  • এইচটিটিপি * (সাম্প্রতিক কিছু সমর্থন)

নেটিভ বাইনারি ডেটা (টাইপ করা অ্যারে, ব্লবস):

  • ওয়েবসকেটস: হ্যাঁ
  • প্লাগইন নেটওয়ার্কিং: ফ্ল্যাশের সাথে নয় (এক্সটার্নাল ইনটারফেসে ইউআরএল এনকোডিং প্রয়োজন)
  • এইচটিটিপি *: বাইনারি ধরণের সমর্থন সক্ষম করার সাম্প্রতিক প্রস্তাব

হ্রাস দক্ষতা ব্যান্ডউইথ:

  • প্লাগইন নেটওয়ার্কিং: প্রাথমিক নীতি অনুরোধ ব্যতীত ফ্ল্যাশ সকেটগুলি কাঁচা
  • ওয়েবসকেটস: সংযোগ সেটআপ হ্যান্ডশেক এবং ফ্রেম প্রতি কয়েকটি বাইট
  • এইচটিটিপি স্ট্রিমিং (সার্ভার সংযোগের পুনরায় ব্যবহার)
  • এইচটিটিপি লং-পোল: প্রতিটি বার্তার জন্য সংযোগ
  • এইচটিটিপি পোল: প্রতিটি বার্তার জন্য সংযোগ + কোনও ডেটা বার্তা নেই

মোবাইল ডিভাইস সমর্থন:

জাভাস্ক্রিপ্ট ব্যবহার জটিলতা (সর্বাধিক জটিল থেকে জটিল)। স্বীকার করা জটিলতা ব্যবস্থা কিছুটা বিষয়গত।

  • ওয়েবসকেট
  • এইচটিটিপি পোল
  • প্লাগইন নেটওয়ার্কিং
  • এইচটিটিপি দীর্ঘ পোল, স্ট্রিমিং

এছাড়াও মনে রাখবেন যে সার্ভার-প্রেরিত ইভেন্টগুলি নামে এইচটিটিপি স্ট্রিমিং মানক করার জন্য একটি ডাব্লু 3 সি প্রস্তাব রয়েছে । এটি বর্তমানে এটির বিবর্তনের মোটামুটি প্রথম দিকে এবং ওয়েবসকেটে তুলনীয় সরলতার সাথে একটি মানক জাভাস্ক্রিপ্ট এপিআই সরবরাহ করার জন্য ডিজাইন করা হয়েছে।


1
ধন্যবাদ সুন্দর উত্তর দেওয়ার জন্য আপনাকে অনেক ধন্যবাদ। আপনি কি দয়া করে আমাকে বলতে পারেন যে কেন / কীভাবে ওয়েবকোকেটের তুলনায় http স্ট্রিমিংয়ের উচ্চতর বিলম্ব রয়েছে? একটি সাধারণ উদাহরণ সঙ্গে? অনেক ধন্যবাদ.
সফটওয়্যার গাই

2
@SoftwareGuy। অনেক কারণ. সাম্প্রতিক ব্রাউজারগুলিতে, আপনি XMLHTTPRequest অনপ্রেস ইভেন্ট হ্যান্ডলারটি ডেটা সম্পর্কে অবহিত করতে ব্যবহার করতে পারেন। তবে অনুমানটি বলছে যে 50ms হ'ল ক্ষুদ্রতম বিজ্ঞপ্তি ব্যবধান। অন্যথায় আপনাকে অবশ্যই প্রতিক্রিয়া ডেটার জন্য পোল করতে হবে। এছাড়াও, ক্লায়েন্ট একটি নতুন এইচটিটিপি সংযোগ স্থাপন করে প্রেরণ করে এবং তাই উল্লেখযোগ্যভাবে বৃত্তাকার-ট্রিপ বিলম্বিত করে increase এছাড়াও, অনেক ওয়েব সার্ভার 30 সেকেন্ড বা তার পরে এইচটিটিপি সংযোগগুলি বিচ্ছিন্ন করে দেয় যার অর্থ আপনাকে প্রায়শই সার্ভার পুশ সংযোগটি পুনরায় প্রতিষ্ঠিত করতে হয়। আমি একটি স্থানীয় নেটওয়ার্কে 5-10 মিমি ওয়েবস্কট রাউন্ডট্রিপ বিলম্ব দেখতে পেয়েছি। এইচটিটিপি স্ট্রিমিং লেটেন্সি সম্ভবত 50ms + হবে।
কনক

বিস্তারিত উত্তরের জন্য অনেক ধন্যবাদ :)
সফটওয়্যার গাই

1
@ গ্রেগটার ধন্যবাদ ফিল, আপনার অর্থ ক্লায়েন্ট থেকে সার্ভারে HTTP স্ট্রিমিংয়ের মাধ্যমে ডেটা পাঠানো ওভারহেডের কারণ হবে? কোনও নতুন সংযোগ না খুলে HTTP স্ট্রিমিংয়ের মাধ্যমে সার্ভারে ডেটা পাঠানো সম্ভব? ধন্যবাদ।
সফটওয়্যার গাই

1
@ নাথান একটি ভাল মাস্টার্স ডিগ্রি থিসিস প্রকল্পের মত মনে হচ্ছে! অবশ্যই, পোলিংটি ইভেন্টটি চালিত মডেলের চেয়ে সিস্টেমকে আরও ব্যস্ত রাখবে, তবে শক্তি সঞ্চয় ঠিক কী হতে পারে তা বিভিন্ন স্কেলের মোটামুটি বিস্তৃত অভিজ্ঞতা অভিজ্ঞতা প্রয়োজন।
কানাকা

13

অন্যদের কাছ থেকে কিছু দুর্দান্ত উত্তর যা প্রচুর জমিটি জুড়ে। এখানে কিছুটা অতিরিক্ত।

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

যদি এর দ্বারা আপনি বোঝাচ্ছেন যে সকেট সংযোগ স্থাপনের জন্য আপনি জাভা অ্যাপলেটস, ফ্ল্যাশ বা সিলভারলাইট ব্যবহার করতে পারেন তবে হ্যাঁ, এটি সম্ভব is তবে আপনি দেখতে পান না যে বাস্তব জগতে প্রায়শই সীমাবদ্ধতার কারণে মোতায়েন রয়েছে।

উদাহরণস্বরূপ, মধ্যস্থতাকারীরা সেই ট্র্যাফিকটি শাটডাউন করতে এবং করতে পারে। ওয়েবস্কট স্ট্যান্ডার্ডটি বিদ্যমান এইচটিটিপি পরিকাঠামোর সাথে সামঞ্জস্যপূর্ণ হওয়ার জন্য ডিজাইন করা হয়েছিল এবং তাই ফায়ারওয়ালস এবং প্রক্সিগুলির মতো মধ্যস্থতাকারীদের দ্বারা হস্তক্ষেপ করার ঝুঁকি কম less

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

এই সকেটের বিকল্পগুলি (জাভা, ফ্ল্যাশ এবং সিলভারলাইট) ক্রস-অরিজিন আর্কিটেকচারে নিরাপদে ব্যবহার করা কঠিন। সুতরাং লোকেদের প্রায়শই ক্রস-উত্সটি ব্যবহার করার চেষ্টা করা সুরক্ষিতভাবে করার চেষ্টা করার পরিবর্তে নিরাপত্তাহীনতা সহ্য করবে will

তাদের অতিরিক্ত "অ-মানক" পোর্টগুলি খোলার প্রয়োজন হতে পারে (কিছু প্রশাসককে করণীয় নয়) বা নীতি ফাইল যা পরিচালনা করতে হবে।

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

ওয়েবসকেট স্ট্যান্ডার্ড এই বিধিনিষেধগুলি মাথায় রেখে একটি নতুন পদ্ধতির সাথে শুরু করতে সক্ষম হয়েছিল এবং আশা করা যায় যে সেগুলি থেকে কিছু পাঠ শিখেছে।

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

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

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

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

এইচটিপি স্ট্রিমিংয়ের মাধ্যমে ওয়েবসকেটগুলির একমাত্র সুবিধা হ'ল আপনাকে প্রাপ্ত তথ্য "বোঝার" এবং পার্স করার চেষ্টা করতে হবে না।

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

সুতরাং আপনি যদি ক্লায়েন্টের কাছে একাধিক বার্তা প্রেরণ করেন তবে এটি সম্ভব যে ক্লায়েন্ট অ্যাপ্লিকেশন কোনও মূল্যবান 50 বার্তা না পাওয়া পর্যন্ত ক্লায়েন্ট অ্যাপ্লিকেশন ডেটা গ্রহণ করবে না। এটি খুব রিয়েল-টাইম নয়।

যখন ওয়েবস্কটটি উপলভ্য নয় তখন এইচটিটিপি স্ট্রিমিং একটি কার্যকর বিকল্প হতে পারে, এটি কোনও নিরাময়ে নয়। বাস্তব-বিশ্বের পরিস্থিতিতে ওয়েবের খারাপ অঞ্চলে শক্তিশালী উপায়ে কাজ করার জন্য এটি একটি ভাল বোঝাপড়া দরকার।

আমি অনুপস্থিত অন্য কোন উল্লেখযোগ্য পার্থক্য আছে?

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

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

উদাহরণস্বরূপ, আপনি ওয়েবসকেটের মাধ্যমে এএমকিপি বা এক্সএমপিপি করতে পারতেন, যেমন লোকেরা ইতিমধ্যে করেছে। সুতরাং কোনও ক্লায়েন্ট কোনও এএমকিউপি ব্রোকারের কাছ থেকে বার্তা পেতে পারে যেন এটি সরাসরি ব্রোকারের সাথে সংযুক্ত ছিল (এবং কিছু ক্ষেত্রে এটি রয়েছে) cases

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

(স্বাভাবিকভাবেই, আপনি নিরাপদে সেগুলি করতে সক্ষম হবেন তাই বিক্রেতার সাথে বা ওয়েবস্কট সরবরাহকারীর সাথে চেক করুন))

কিছু লোক ওয়েবসকেটকে ওয়েবের জন্য টিসিপি হিসাবে উল্লেখ করেছেন। কারণ টিসিপি যেমন উচ্চ স্তরের প্রোটোকল পরিবহন করে তেমনি ওয়েবসকেটও করে, তবে এমন একটি উপায়ে যা ওয়েব পরিকাঠামোর সাথে সামঞ্জস্যপূর্ণ।

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

আমি দুঃখিত যদি আমি ইতিমধ্যে এসও-তে থাকা অনেকগুলি প্রশ্নকে একক প্রশ্নের মধ্যে পুনরায় জিজ্ঞাসা করি বা একত্রিত করি তবে এসও এবং ওয়েবে এই ধারণাগুলি সম্পর্কে যে সমস্ত তথ্য রয়েছে সেগুলি থেকে আমি কেবল সঠিক ধারণাটি তৈরি করতে চাই।

এটি একটি দুর্দান্ত প্রশ্ন ছিল, এবং উত্তরগুলি সমস্ত খুব তথ্যপূর্ণ ছিল!


দুর্দান্ত সাহায্য এবং তথ্যের জন্য রবিনকে অনেক ধন্যবাদ। যদি আমি একটি অতিরিক্ত জিনিস জিজ্ঞাসা করতে পারি: আমি কোথাও একটি নিবন্ধে এসেছি যাতে বলা হয়েছে যে ওয়েবসকেটগুলি না থাকায় এইচটিএমএল স্ট্রিমিংও প্রক্সি দ্বারা ক্যাশে করা যেতে পারে। ওটার মানে কি?
সফটওয়্যার গাই

: যেহেতু Stackoverflow প্রতিক্রিয়া মন্তব্য আকার সীমিত করে আমি নিচে আমার উত্তর দিয়েছি stackoverflow.com/questions/12555043/...
রবিন Zimmermann

@ রোবিনজিমারম্যান, আপনার উত্তরটি আমার প্রিয়। সত্যিই ভাল উত্তরের জন্য +1।
সুরক্ষিত 25

10

যদি আমি একটি অতিরিক্ত জিনিস জিজ্ঞাসা করতে পারি: আমি কোথাও একটি নিবন্ধে এসেছি যাতে বলা হয়েছে যে ওয়েবসকেটগুলি না থাকায় এইচটিএমএল স্ট্রিমিংও প্রক্সি দ্বারা ক্যাশে করা যেতে পারে। ওটার মানে কি?

(স্ট্যাকওভারফ্লো মন্তব্য প্রতিক্রিয়ার আকারকে সীমাবদ্ধ করে, তাই আমাকে ইনলাইন না দিয়ে এখানে উত্তর দিতে হবে))

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

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

সুতরাং ক্লায়েন্ট # 1 অনুরোধ http://example.com/images/logo.gif , বলুন। এই অনুরোধটি প্রক্সির মধ্য দিয়ে কেন্দ্রীয় ওয়েব সার্ভারে যায়, যা logo.gif সরবরাহ করে। লোগো.gif প্রক্সিটির মধ্য দিয়ে যাওয়ার সাথে সাথে প্রক্সিটি সেই চিত্রটি সংরক্ষণ করবে এবং এটি http://example.com/images/logo.gif ঠিকানার সাথে যুক্ত করবে ।

যখন ক্লায়েন্ট # 2 আসেন এবং http://example.com/images/logo.gif অনুরোধ করেন , প্রক্সিটি চিত্রটি ফিরিয়ে দিতে পারে এবং কেন্দ্রের ওয়েব সার্ভারে কোনও যোগাযোগের প্রয়োজন হয় না। এটি শেষ ব্যবহারকারীকে দ্রুত প্রতিক্রিয়া দেয় যা সর্বদা দুর্দান্ত তবে এর অর্থ এটিও হয় যে কেন্দ্রে কম লোড রয়েছে। এটি হ্রাস করা হার্ডওয়ারের ব্যয়, নেটওয়ার্কিং ব্যয় হ্রাস ইত্যাদিতে অনুবাদ করতে পারে তাই এটি খুব ভাল বিষয় thing

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

এই আপনার প্রশ্নের মধ্যে টাই কিভাবে?

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

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

সুতরাং যদি আপনার ক্লায়েন্ট স্টক মূল্যের জন্য একটি অনুরোধ করে, বলে, এবং একটি প্রতিক্রিয়া পেয়েছে, তবে পরবর্তী ক্লায়েন্ট একই অনুরোধ করতে পারে এবং ক্যাশেড ডেটা পেতে পারে। সম্ভবত আপনি যা চান না! আপনি যদি স্টকের দামের জন্য অনুরোধ করেন তবে আপনি সর্বশেষতম ডেটা চান, তাই না?

সুতরাং এটি একটি সমস্যা।

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


1
চমৎকার বিস্তারিত রবিন, আপনাকে অনেক ধন্যবাদ! আমি সত্যিই আপনার পুরো সাড়া প্রশংসা করি। আমি ইতিমধ্যে এখানে সমস্ত মহান ব্যক্তিদের কাছ থেকে অনেক কিছু শিখেছি! :)
সফটওয়্যার গাই

4

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

ওয়েবসকেটগুলি একটি টিসিপি-ভিত্তিক প্রোটোকল এবং যেমন এই এইচটিটিপি-স্তর সংযোগ সীমাতে ভোগেনা (তবে অবশ্যই ব্রাউজার সমর্থনটি অভিন্ন নয়)।


ধন্যবাদ থেজুয়েস, সুতরাং আপনার দ্বারা হাইলাইট করা একাধিক যুগপত সংযোগ ইস্যু ছাড়াও, ওয়েবসকেট সম্পর্কিত আমার অনুমানগুলি কী সঠিক?
সফটওয়্যার গাই
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.