ওয়েবসকেট প্রোটোকল বনাম এইচটিটিপি

Question

ওয়েবসকেট এবং এইচটিটিপি সম্পর্কে অনেকগুলি ব্লগ এবং আলোচনা রয়েছে এবং অনেকগুলি বিকাশকারী এবং সাইটগুলি ওয়েবসকেটগুলির পক্ষে দৃ .়তার সাথে সমর্থন করে তবে আমি কেন এখনও বুঝতে পারি না।

উদাহরণস্বরূপ (ওয়েবসকেট প্রেমীদের যুক্তি):

এইচটিএমএল 5 ওয়েব সকেটগুলি ওয়েব যোগাযোগের পরবর্তী বিবর্তনকে উপস্থাপন করে — একটি সম্পূর্ণ-দ্বৈত, দ্বি নির্দেশমূলক যোগাযোগ চ্যানেল যা ওয়েবে একটি একক সকেটের মাধ্যমে পরিচালিত হয়। ( http://www.websocket.org/quantum.html )

এইচটিটিপি স্ট্রিমিং সমর্থন করে: বডি স্ট্রিমিংয়ের অনুরোধ করুন (আপনি বড় ফাইলগুলি আপলোড করার সময় এটি ব্যবহার করছেন) এবং প্রতিক্রিয়া বডি স্ট্রিমিং।

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

কেন সেই 2 বাইটে টিসিপি এবং টিসিপি প্রোটোকলগুলি ওভারহেডের অন্তর্ভুক্ত নয়?

GET /about.html HTTP/1.1
Host: example.org

এটি ~ 48 বাইটস HTTP শিরোনাম।

এইচডিপি চুনকৃত এনকোডিং - https://en.wikedia.org/wiki/Chunked_transfer_encoding :

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0

• সুতরাং, প্রতিটি খণ্ডে ওভারহেড বড় নয়।

উভয় প্রোটোকল টিসিপি-র উপর কাজ করে, তাই দীর্ঘ-লাইভ সংযোগ সহ সমস্ত টিসিপি সমস্যা এখনও আছে।

প্রশ্নাবলী:

1. ওয়েবসকেট প্রোটোকল কেন ভাল?
2. এটি HTTP প্রোটোকল আপডেট করার পরিবর্তে কেন প্রয়োগ করা হয়েছিল?

Comments

আপনার প্রশ্ন কি?

— জোনাস

@ জোনাস, ১) ওয়েবসকেট প্রোটোকল কেন ভাল? 2) এটি HTTP প্রোটোকল আপডেট করার পরিবর্তে কেন প্রয়োগ করা হয়েছিল? 3) কেন ওয়েবসকেটগুলি এত প্রচারিত হয়?

— 4esn0k

@ জোয়াচিমপাইলবার্গ, আপনি এটি টিসিপি সকেট বা ডেস্কটপ অ্যাপ্লিকেশনগুলির জন্য HTTP দিয়েও করতে পারেন; এবং ওয়েবসাইটের জন্য ব্রাউজার-থেকে-ব্রাউজার যোগাযোগ করতে আপনাকে

— ওয়েবআরটিসি

@ জোয়াচিমপাইলবার্গ, এটি ব্রাউজার-থেকে-ব্রাউজারের জন্য ওয়েবআরটিসি, ওয়েবসকেট নয়

— 4esn0k

@ 4esn0k, ডাব্লুএস আরও ভাল নয়, কিছু নির্দিষ্ট কাজের জন্য এগুলি আলাদা এবং ভাল। 3) এটি একটি নতুন বৈশিষ্ট্য যা লোকেদের ওয়েব সম্পর্কে নতুন সম্ভাবনা সম্পর্কে সচেতন হওয়া এবং খোলার উচিত

— জোনাস

Answer 1

1) ওয়েবসকেটস প্রোটোকল কেন ভাল?

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

আপনার 48 বাইট এইচটিটিপি হ্যান্ডশেক বাস্তব-বিশ্বের এইচটিটিপি ব্রাউজার সংযোগগুলির জন্য বাস্তবসম্মত নয় যেখানে প্রায়শই বেশিরভাগ কিলোবাইট ডেটা অনুরোধের অংশ হিসাবে প্রেরণ করা হয় (উভয় দিকে) অনেকগুলি শিরোনাম এবং কুকি ডেটা সহ। ক্রোম ব্যবহারের জন্য এখানে একটি অনুরোধ / প্রতিক্রিয়ার একটি উদাহরণ:

উদাহরণ অনুরোধ (কুকি ডেটা সহ 2800 বাইট, কুকি ডেটা ছাড়াই 490 বাইট):

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

উদাহরণ প্রতিক্রিয়া (355 বাইট):

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

এইচটিটিপি এবং ওয়েবসকেট উভয়েরই সমান আকারের প্রাথমিক সংযোগ হ্যান্ডশেক রয়েছে তবে একটি ওয়েবস্কট সংযোগের মাধ্যমে প্রাথমিক হ্যান্ডশেক একবার করা হয় এবং তারপরে ছোট বার্তাগুলিতে কেবল ওভারহেডের 6 বাইট থাকে (শিরোনামের জন্য 2 এবং মুখোশের মানের জন্য 4)। লেটেন্সি ওভারহেড শিরোনামের আকার থেকে এতটা নয়, তবে যুক্তি থেকে সেই শিরোনামগুলি পার্স / হ্যান্ডেল / সঞ্চয় করতে হবে। এছাড়াও, প্রতিটি অনুরোধের জন্য আকার বা প্রসেসিং সময়ের চেয়ে টিসিপি সংযোগ সেটআপ বিলম্বিতা সম্ভবত একটি বৃহত ফ্যাক্টর।

২) এইচটিটিপি প্রোটোকল আপডেট করার পরিবর্তে কেন এটি প্রয়োগ করা হয়েছিল?

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

আপডেট :

ওয়েব প্রোটোকল সম্পর্কে চিন্তাভাবনার জন্য এখানে একটি কাঠামো দেওয়া হল:

• টিসিপি : নিম্ন-স্তরের, দ্বি-দিকনির্দেশক, পূর্ণ-দ্বৈত এবং গ্যারান্টিযুক্ত অর্ডার পরিবহন স্তর। কোনও ব্রাউজার সমর্থন নেই (প্লাগইন / ফ্ল্যাশ বাদে)।
• HTTP 1.0 : টিসিপিতে অনুরোধ-প্রতিক্রিয়া পরিবহন প্রোটোকল স্তরযুক্ত। ক্লায়েন্ট একটি সম্পূর্ণ অনুরোধ করে, সার্ভার একটি সম্পূর্ণ প্রতিক্রিয়া দেয় এবং তারপরে সংযোগটি বন্ধ হয়ে যায়। অনুরোধের পদ্ধতিগুলি (জিইটি, পোষ্ট, হেড) এর সার্ভারে সংস্থানগুলির জন্য নির্দিষ্ট লেনদেনের অর্থ রয়েছে।
• HTTP 1.1 : HTTP 1.0 এর অনুরোধ-প্রতিক্রিয়া প্রকৃতি বজায় রাখে, তবে একাধিক সম্পূর্ণ অনুরোধ / পূর্ণ প্রতিক্রিয়া (অনুরোধ অনুযায়ী একটি প্রতিক্রিয়া) এর জন্য সংযোগটি উন্মুক্ত রাখতে দেয়। অনুরোধ এবং প্রতিক্রিয়াতে এখনও পুরো শিরোনাম রয়েছে তবে সংযোগটি পুনরায় ব্যবহৃত হয়েছে এবং বন্ধ নয়। HTTP 1.1 এছাড়াও কিছু অতিরিক্ত অনুরোধ পদ্ধতি যুক্ত করেছে (অপশনস, পুট, মোছা, ট্র্যাক, সংযোগ) যার নির্দিষ্ট ট্রানজেকশনাল অর্থও রয়েছে। তবে, এইচটিটিপি ২.০ খসড়া প্রস্তাবটির প্রবর্তনে উল্লিখিত হিসাবে , এইচটিটিপি ১.১ পাইপলাইনিং ব্যাপকভাবে মোতায়েন করা হয়নি তাই এটি ব্রাউজার এবং সার্ভারের মধ্যে বিলম্ব সমাধানের জন্য এইচটিটিপি ১.১ এর ব্যবহারকে সীমাবদ্ধ করে দেয়।
• লং-পোল : এইচটিটিপিতে ("1.0 বা 1.1) তে" হ্যাক "বাছাই করুন যেখানে ক্লায়েন্টের অনুরোধে সার্ভারটি তাত্ক্ষণিকভাবে প্রতিক্রিয়া জানায় না (বা কেবলমাত্র শিরোনাম দিয়ে আংশিকভাবে প্রতিক্রিয়া জানায়)। সার্ভারের প্রতিক্রিয়ার পরে ক্লায়েন্টটি তাত্ক্ষণিকভাবে একটি নতুন অনুরোধ প্রেরণ করে (HTTP 1.1 এর বেশি হলে একই সংযোগটি ব্যবহার করে)।
• এইচটিটিপি স্ট্রিমিং : বিভিন্ন কৌশল (মাল্টিপার্ট / ছিন্ন প্রতিক্রিয়া) যা সার্ভারকে একক ক্লায়েন্টের অনুরোধে একাধিক প্রতিক্রিয়া প্রেরণে অনুমতি দেয়। ডাব্লু 3 সি একটি এমআইএমএম টাইপ ব্যবহার করে এটি সার্ভার-প্রেরিত ইভেন্ট হিসাবে মানীকৃত করছে text/event-stream। ব্রাউজার এপিআই (যা ওয়েবসকেট এপিআইয়ের সাথে মোটামুটি মিল) বলা হয় ইভেন্টসোর্স এপিআই।
• ধূমকেতু / সার্ভার পুশ : এটি একটি ছাতা শব্দ যা দীর্ঘ-পোল এবং এইচটিটিপি উভয় স্ট্রিমিংয়ের অন্তর্ভুক্ত। ধূমকেতু গ্রন্থাগারগুলি সাধারণত ক্রস ব্রাউজার এবং ক্রস-সার্ভার সমর্থনকে চেষ্টা করার এবং সর্বাধিক করার জন্য একাধিক কৌশল সমর্থন করে।
• ওয়েবসকেটস : একটি ট্রান্সপোর্ট লেয়ারটি বিল্ট-অন টিসিপি যা এইচটিটিপি বান্ধব আপগ্রেড হ্যান্ডশেক ব্যবহার করে। টিসিপি'র বিপরীতে, যা একটি স্ট্রিমিং ট্রান্সপোর্ট, ওয়েবসকেটগুলি একটি বার্তা ভিত্তিক পরিবহণ: বার্তাগুলি তারের উপর বিস্মৃত হয় এবং অ্যাপ্লিকেশনে পৌঁছানোর আগে পুরোপুরি পুনরায় একত্রিত হয়। ওয়েবসকেট সংযোগগুলি দ্বি-দিকনির্দেশক, পূর্ণ দ্বৈত এবং দীর্ঘজীবী। প্রাথমিক হ্যান্ডশেকের অনুরোধ / প্রতিক্রিয়ার পরে, কোনও লেনদেনের শব্দার্থবিজ্ঞান নেই এবং বার্তা ওভারহেডের খুব কম থাকে। ক্লায়েন্ট এবং সার্ভার যে কোনও সময় বার্তাগুলি প্রেরণ করতে পারে এবং ম্যাসেজের রসিদকে সংবিধানে পরিচালনা করতে হবে।
• এসপিডিওয়াই : গুগল আরও দক্ষ তারের প্রোটোকল ব্যবহার করে এইচটিটিপি প্রসারিত করার প্রস্তাব নিয়েছিল কিন্তু সমস্ত এইচটিটিপি শব্দার্থবিজ্ঞান (অনুরোধ / প্রতিক্রিয়া, কুকিজ, এনকোডিং) বজায় রেখেছে। এসপিডিওয়াই একটি নতুন ফ্রেমিং ফর্ম্যাট (দৈর্ঘ্য-প্রিফিক্সড ফ্রেম সহ) প্রবর্তন করে এবং নতুন ফ্রেমিং স্তরটিতে এইচটিটিপি অনুরোধ / প্রতিক্রিয়া জোড়া লেয়ার করার একটি উপায় নির্দিষ্ট করে। সংযোগ স্থাপনের পরে শিরোনামগুলি সংকুচিত করা যায় এবং নতুন শিরোনামগুলি প্রেরণ করা যায়। ব্রাউজার এবং সার্ভারগুলিতে এসপিডিওয়াইয়ের বাস্তব বিশ্ব বাস্তবায়ন রয়েছে।
• এইচটিটিপি ২.০ : এর এসপিডিওয়াইয়ের মতো লক্ষ্য রয়েছে: এইচটিটিপি সিলেটিক্স সংরক্ষণের সময় এইচটিটিপি ল্যাটেন্সি এবং ওভারহেড হ্রাস করুন। বর্তমান খসড়াটি এসপিডিওয়াই থেকে প্রাপ্ত এবং একটি আপগ্রেড হ্যান্ডশেক এবং ডেটা ফ্রেমিংয়ের সংজ্ঞা দেয় যা হ্যান্ডশেক এবং ফ্রেমিংয়ের জন্য ওয়েবস্কট স্ট্যান্ডার্ডের সাথে খুব মিল। একটি বিকল্প এইচটিটিপি ২.০ খসড়া প্রস্তাবনা (httpbis-গতি-গতিশীলতা) আসলে ট্রান্সপোর্ট লেয়ারের জন্য ওয়েবসকেট ব্যবহার করে এবং এসপিডিওয়াই মাল্টিপ্লেক্সিং এবং এইচটিটিপি ম্যাপিংকে ওয়েবস্কট এক্সটেনশান হিসাবে যুক্ত করে (ওয়েবস্কট এক্সটেনশানগুলি হ্যান্ডশেকের সময় আলোচিত হয়)।
• ওয়েবআরটিসি / সিইউ-ওয়েবআরটিসি : ব্রাউজারগুলির মধ্যে পিয়ার-টু-পিয়ার সংযোগের অনুমতি দেওয়ার প্রস্তাবসমূহ। এটি নিম্ন গড় এবং সর্বাধিক বিলম্বিত যোগাযোগটি সক্ষম করতে পারে কারণ অন্তর্নিহিত পরিবহণটি টিসিপির পরিবর্তে এসডিপি / ডেটাগ্রাম। এটি প্যাকেটগুলি / বার্তাগুলির আউট-অফ-অর্ডার সরবরাহের অনুমতি দেয় যা ড্রপ প্যাকেটগুলির ফলে ঘটে যাওয়া বিলম্বিত স্পাইকগুলির টিসিপি ইস্যুকে এড়িয়ে চলে যা পরবর্তী সমস্ত প্যাকেটের বিতরণে বিলম্বিত করে (অর্ডার সরবরাহের গ্যারান্টি দিতে)।
• কুইক : এটি একটি পরীক্ষামূলক প্রোটোকল যা টিসিসিটির চেয়ে ওয়েব ল্যাটেন্সি কমাতে লক্ষ্য করে। সরেজমিনে, ক্যুইকটি ইউডিপিতে প্রয়োগ করা টিসিপি + টিএলএস + এসপিডিওয়াইয়ের সাথে খুব মিল। কুইক এইচটিটিপি / ২ এর সমান মাল্টিপ্লেক্সিং এবং প্রবাহ নিয়ন্ত্রণ সরবরাহ করে, টিএলএসের সমতুল্য সুরক্ষা এবং সংযোগ শব্দার্থ, নির্ভরযোগ্যতা, এবং টিসিপি-তে কনজেশন নিয়ন্ত্রণ সরবরাহ করে। যেহেতু টিসিপি অপারেটিং সিস্টেম কার্নেল এবং মিডলবক্স ফার্মওয়্যারের ক্ষেত্রে প্রয়োগ করা হয়েছে, তাই টিসিপিতে উল্লেখযোগ্য পরিবর্তন করা অসম্ভব হয়ে পড়েছে। তবে, যেহেতু ক্যুইকটি ইউডিপির শীর্ষে নির্মিত, এটি এ জাতীয় কোনও সীমাবদ্ধতায় ভুগছে না। কুইক এইচটিটিপি / 2 শব্দার্থবিজ্ঞানের জন্য ডিজাইন এবং অনুকূলিত হয়েছে।

তথ্যসূত্র :

• এইচটিটিপি :
  • উইকিপিডিয়া এইচটিটিপি পৃষ্ঠা
  • ডাব্লু 3 সি এইচটিটিপি সম্পর্কিত খসড়া / প্রোটোকলগুলির তালিকা
  • আইইটিএফ HTTP / 1.1 এবং HTTP / 2.0 খসড়াগুলির তালিকা
• সার্ভার-প্রেরিত ইভেন্ট :
  • ডাব্লু 3 সি সার্ভার-প্রেরিত ইভেন্ট / ইভেন্টসোর্স প্রার্থী প্রস্তাবনা
  • ডাব্লু 3 সি সার্ভার-প্রেরিত ইভেন্ট / ইভেন্টসোর্স খসড়া
• ওয়েবসকেট :
  • আইইটিএফ আরএফসি 6455 ওয়েবসকেটস প্রোটোকল
  • আইইটিএফ আরএফসি 6455 ওয়েবসকেট ত্রুটি
• এসপিডিওয়াই :
  • আইইটিএফ এসপিডিওয়াই খসড়া
• HTTP 2.0 :
  • আইইটিএফ এইচটিটিপি ২.০ httpbis-http2 খসড়া
  • আইইটিএফ এইচটিটিপি ২.০ httpbis-গতি-গতিশীলতা খসড়া
  • আইইটিএফ httpbis- নেটওয়ার্ক বান্ধব খসড়া - একটি পুরানো HTTP 2.0 সম্পর্কিত প্রস্তাব
• ওয়েবআরটিসি :
  • W3C WebRTC API খসড়া
  • আইইটিএফ ওয়েবআরটিসি খসড়াগুলির তালিকা
  • আইইটিএফ ওয়েবআরটিটিসি ওভারভিউ খসড়া
  • আইইটিএফ ওয়েবআরটিটিসি ডেটাচ্যানেল খসড়া
  • মাইক্রোসফ্ট সিইউ-ওয়েবআরটিসি প্রস্তাব সূচনা পৃষ্ঠা
• কুইক :
  • কুইক ক্রোমিনাম প্রকল্প
  • আইইটিএফ কুইক খসড়া

Comments

>> তবে, এটি ক্লায়েন্টকে সার্ভার ল্যাটেন্সিতে সহায়তা করে না যা প্রতিটি ক্লায়েন্টের জন্য সার্ভার বার্তায় একটি নতুন সংযোগ স্থাপন করা দরকার। - প্রতিক্রিয়া বডি স্ট্রিমিং সম্পর্কে কি? আমি জানি, XMLHttpRequest API এটিকে অনুমতি দেয় না, তবে এটি বিদ্যমান। সার্ভারে স্ট্রিমিংয়ের সাথে আপনি ক্লায়েন্ট দিক থেকে স্ট্রিম করতে পারেন।

— 4esn0k

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

— কনক

প্রোটোকলগুলির এই খুব সুন্দর এবং নির্ভুল ওভারভিউয়ের জন্য আপনাকে অনেক ধন্যবাদ for

— মার্টিন মিজার

@ ওয়ার্ডসি ক্যানিউস.কম ব্রাউজারের সামঞ্জস্যতার তথ্য দেয় (মোবাইল সহ)।

— কানাকা

@ www139, না, ওয়েবস্কট প্রোটোকল স্তরে সংযোগটি একদিকে বা অন্য পক্ষটি সংযোগ বন্ধ না হওয়া পর্যন্ত খোলা থাকবে। আপনাকে টিসিপি টাইমআউটগুলি (যে কোনও টিসিপি ভিত্তিক প্রোটোকল নিয়ে সমস্যা) সম্পর্কেও চিন্তিত হতে পারে, তবে প্রতি মিনিটে বা দু'এই কোনও ধরণের ট্র্যাফিক সংযোগটি উন্মুক্ত রাখবে। প্রকৃতপক্ষে, ওয়েবসকেট প্রোটোকল সংজ্ঞাটি একটি পিং / পং ফ্রেমের ধরণ নির্দিষ্ট করে, যদিও তা ছাড়া আপনি একটি একক বাইট (আরও দুটি বাইট শিরোলেখ) প্রেরণ করতে পারেন এবং এটি সংযোগটি উন্মুক্ত রাখবে। প্রতি মিনিটে 2-3 বাইটগুলি কোনও তাৎপর্যপূর্ণ ব্যান্ডউইথ প্রভাব নয়।

— কনক

Answer 2

আপনি ধরে নিয়েছেন যে ওয়েবস্কটটি এইচটিটিপি-র একটি প্রতিস্থাপন। এইটা না. এটি একটি এক্সটেনশন।

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

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

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

তাহলে কেন স্ট্রিমযুক্ত অনুরোধ এবং প্রতিক্রিয়া সহ সাধারণ HTTP ব্যবহার করবেন না

অন্য উত্তরের একটি মন্তব্যে আপনি কেবল ক্লায়েন্টের অনুরোধ এবং প্রতিক্রিয়া বডিটিকে অবিচ্ছিন্নভাবে স্ট্রিম করার পরামর্শ দিয়েছেন।

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

Comments

>> ক্লায়েন্ট স্পষ্টভাবে এটির জন্য অনুরোধ না করলে তিনি সার্ভার ডেটা প্রেরণ করতে পারবেন না ;; ওয়েব ব্রাউজারটি ওয়েবসকেট সংযোগ শুরু করা উচিত ... এক্সএমএলএইচটিপিআরকুয়েস্টের মতো

— 4esn0k

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

— ফিলিপ

কেন এইচটিটিপি দিয়ে এটি সম্ভব নয়?

— 4esn0k

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

— কনক

ফিলিপ, অন্য নোট: জাভাস্ক্রিপ্টের জন্য এক্সএমএলএইচটিপিআরকিউস্ট এবং ওয়েবসকেট ছাড়াও অন্যান্য পদ্ধতি রয়েছে যা লুকানো আইফ্রেমেস এবং দীর্ঘ-পোলের স্ক্রিপ্ট ট্যাগ সহ সার্ভারের সাথে যোগাযোগ করতে পারে। আরও তথ্যের জন্য ধূমকেতু উইকিপিডিয়া পৃষ্ঠাটি দেখুন: en.wikedia.org/wiki/Comet_( প্রোগ্রামিং)

— কানাকা

Answer 3

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

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

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

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

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

ওয়েবসকেট সম্পর্কে আমি যে উপস্থাপনা করেছি তার থেকে একটি ভিডিও এবং এটি নিয়মিত আরএসটি এপিআই ব্যবহার করার চেয়ে কীভাবে আলাদা হয়: মানককরণ এবং ডেটা স্ট্রিমিংয়ের তাত্পর্যপূর্ণ বৃদ্ধি লাভ

Answer 4

টিএল; ডিআর এর জন্য, এখানে আপনার প্রশ্নের জন্য 2 সেন্ট এবং একটি সহজ সংস্করণ রয়েছে:

1. ওয়েবসকেটগুলি এইচটিটিপি-র মাধ্যমে এই সুবিধা সরবরাহ করে:

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

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

Comments

গুরুত্বপূর্ণ যে আপনি আপনার তুলনা (রাজ্য) এবং রাষ্ট্রবিহীন শব্দটি উল্লেখ করেছেন

— উত্সব টি

Answer 5

ওয়েবসকেট প্রোটোকল কেন ভাল?

আমি মনে করি না যে আমরা কে পাশাপাশি ভাল তাদের পাশাপাশি তুলনা করতে পারি। এটি ন্যায্য তুলনা হবে না কারণ তারা দুটি ভিন্ন সমস্যার সমাধান করছে । তাদের প্রয়োজনীয়তা পৃথক। এটি কমলাগুলির সাথে আপেলের তুলনা করার মতো হবে। তারা ভিন্ন ধরনের.

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

এইচটিটিপি-তে কেবল ক্লায়েন্টের অনুরোধ। সার্ভার কেবল প্রতিক্রিয়া জানায়।

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

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

সার্ভারটি অনুরোধটি বুঝতে পেরে এবং ওয়েবসকেট প্রোটোকলে আপগ্রেড হয়ে গেলে, এইচটিটিপি প্রোটোকলের আর কোনও প্রয়োগ হয়নি।

সুতরাং আমার উত্তর হয় না হয় একে অপরের চেয়ে ভাল। এগুলি সম্পূর্ণ আলাদা।

এটি HTTP প্রোটোকল আপডেট করার পরিবর্তে কেন প্রয়োগ করা হয়েছিল?

ওয়েল, আমরা এইচটিটিপি নামেও সবকিছু তৈরি করতে পারি । কিন্তু আমরা কি করব? যদি সেগুলি দুটি ভিন্ন জিনিস হয় তবে আমি দুটি পৃথক নাম পছন্দ করব। তাই হিকসন এবং মাইকেল কার্টার ।

Answer 6

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

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

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