টিসিপি এবং ইউডিপি প্যাকেটগুলি কি টুকরো টুকরো করা যেতে পারে?


41

টিসিপি প্যাকেটগুলি কি টুকরো টুকরো করে রিসিভারে আসতে পারে?

উদাহরণস্বরূপ, আমি যদি টিসিপি প্রোটোকল ব্যবহার করে 20 বাইট প্রেরণ করি তবে আমি কি 100% নিশ্চিত হতে পারি যে আমি একবারে ঠিক 20 বাইট পেয়ে যাব, 10 বাইট না পরে আরও 10 বাইট বা তাই?

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


7
স্পষ্টকরণের একটি বিষয়: একে একে টিসিপি বিভাগ এবং একটি ইউডিপি ডেটাগ্রাম বলা হয়। এগুলি প্যাকেট নয়। টিসিপি = সেগমেন্ট, ইউডিপি = ডেটাগ্রাম, আইপি = প্যাকেট, ইথারনেট = ফ্রেম, অন্যান্য সমস্ত স্তরগুলিতে (এএফএআইকি) এগুলিকে কেবল পিডিইউ (প্রোটোকল ডেটা ইউনিট) বলা হয়।
joeqwerty

উত্তর:


33

টিসিপি প্যাকেটগুলি কি টুকরো টুকরো করে রিসিভারে আসতে পারে?

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

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

উদাহরণস্বরূপ: আমি যদি টিসিপি প্রোটোকল ব্যবহার করে 20 বাইট প্রেরণ করি তবে আমি কি 100% নিশ্চিত হতে পারি যে আমি একবারে ঠিক 20 বাইট পেয়ে যাব, 10 বাইট না পরে আরও 10 বাইট বা তাই?

না, তবে প্যাকেটের সাথে এর কোনও যোগসূত্র নেই। টিসিপি হ'ল মূলত, একটি বাইট স্ট্রিম প্রোটোকল যা অ্যাপ্লিকেশন বার্তার সীমানা সংরক্ষণ করে না।

এবং ইউডিপি প্রোটোকলের জন্য একই প্রশ্ন। আমি জানি যে ইউডিপি অবিশ্বাস্য এবং প্যাকেটগুলি একেবারে আগত বা বিভিন্ন ক্রমে আসতে পারে না,

টিসিপি-র ক্ষেত্রেও একই কথা। প্যাকেট প্যাকেট হয়। পার্থক্যটি হ'ল টিসিপি পুনরায় চেষ্টা করে এবং প্রোটোকলটিতে পুনর্নির্মাণ করে যখন ইউডিপি না করে।

কিন্তু 1 প্যাকেট সম্পর্কে কি? যদি এটি পৌঁছে যায় তবে আমি কী নিশ্চিত যে এটি একটি সম্পূর্ণ প্যাকেট, কোনও টুকরো নয়?

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


10
নবীন পাঠকদের জন্য শেষ বিটটি স্পষ্ট করার মতো হতে পারে: আপনি প্রশ্নে ডেটাগ্রামের সম্পূর্ণ ডেটা দেখতে পাবেন । যদি কোনও বিভক্ত প্যাকেট হারিয়ে যায়, ডেটাগ্রামটি হারিয়ে যায় এবং ইউডিপি স্তর এটি কখনই জানতে পারে না। যতক্ষণ না ডাটাগ্রামে সমস্ত প্যাকেট প্রাপ্ত হবে ততক্ষণ এগুলি আইপি স্তরে একত্রিত হবে এবং তারপরে ইউডিপি স্তর পর্যন্ত পাস হবে। এটি ডেটাস্ট্রিমের "অংশগুলি" হারিয়ে যাওয়ার সম্ভাবনাটি হ্রাস করে না। পেডেন্ট হতে হবে না, তবে আমি যখন এই জিনিসগুলি শিখছিলাম তখন আমি পাঠ্যপুস্তকটি ২ য় বা ৩ য় পাস না হওয়া পর্যন্ত আইপি টুকরা এবং ইউডিপি হ্রাসের মধ্যে পার্থক্যটি জাগ্রত করি নি।
জাস্টিন ᚅᚔᚈᚄᚒᚔ

20

আপনি নিশ্চিত হতে পারবেন না যে তারা সত্যই শারীরিকভাবে একবারে এসে পৌঁছেছে। টিসিপি / ইউডিপির নীচে ডেটা লিঙ্ক স্তরগুলি তারা চাইলে আপনার প্যাকেটটি বিভক্ত করতে পারে। বিশেষত আপনি যদি ইন্টারনেট বা আপনার নিয়ন্ত্রণের বাইরে কোনও নেটওয়ার্কের মাধ্যমে ডেটা প্রেরণ করেন তবে এটি অনুমান করা শক্ত hard

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

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


নেটওয়ার্ক কার্ড ড্রাইভার কি প্যাকেটগুলি পুনরায় একত্রিত করার জন্য কার্নেলটি গ্রহণ করে না?
নীলহল্লু

2
@ হালুচিনোজেনিক: যদি না কিছু পরিবর্তন হয়, ইন্টারনেট প্রোটোকলটি তাদের যাত্রার যে কোনও সময়ে 576 বাইটের বেশি প্যাকেটগুলিকে বিভক্ত করার অনুমতি দেওয়ার জন্য ডিজাইন করা হয়েছে, তবে চূড়ান্ত প্রাপককে পুনরায় পুনর্বিবেচনার জন্য আর কিছু আশা করেন না। আমি মনে করি ধারণাটিটি হ'ল বড় প্যাকেটের ব্যবহার বেশিরভাগ ক্ষেত্রে ওভারহেড হ্রাস করার চেষ্টা ছিল; একবার কোনও প্যাকেট যাত্রার কোনও পর্যায়ে বিভক্ত হয়ে গেলে, চূড়ান্ত প্রাপক কোনও কিছুর জন্য সহায়তা করতে প্রস্তুত না হওয়ার আগেই ওভারহেডটি এতক্ষণ পুনরায় সংশ্লেষ করা হয়েছিল এবং এটি পুনরায় বিভক্ত হতে হলে আঘাত করতে পারে।
সুপারক্যাট

আমি বিশ্বাস করি যে 576 বাইটের বেশি প্যাকেটগুলি বিভক্ত হতে পারে, সেই আকারের নীচে থাকা প্যাকেটগুলি বিভক্ত হতে পারে না; এম্বেড থাকা সিস্টেমগুলি যা বিভক্ত প্যাকেটগুলির সাথে কাজ করতে পারে না সেগুলির চেয়ে বড় কিছু জিজ্ঞাসা করা উচিত।
সুপারক্যাট

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

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

14

উদাহরণ। সামঞ্জস্যপূর্ণ অক্ষরের ব্লক প্রেরণের সাথে মিল () কলগুলি:

বিভিন্ন TCP:

Send: AA BBBB CCC DDDDDD E         Recv: A ABB B BCC CDDD DDDE

প্রেরিত সমস্ত ডেটা ক্রমানুসারে প্রাপ্ত হয়, তবে অগত্যা একই অংশে নয়।

এর ফলে UDP:

Send: AA BBBB CCC DDDDDD E         Recv: CCC AA E

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


5

উদাহরণস্বরূপ: আমি যদি টিসিপি প্রোটোকল ব্যবহার করে 20 বাইট প্রেরণ করি তবে আমি কি 100% নিশ্চিত হতে পারি যে আমি একবারে ঠিক 20 বাইট পেয়ে যাব, 10 বাইট না পরে আরও 10 বাইট বা তাই?

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


1

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

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

অন্য প্রান্তে, ডেটা বিভাজন বলতে বোঝায় যে আংশিক পাঠ হতে পারে। একটি রিসিভ অপারেশন সম্ভাব্যভাবে জেগে উঠতে পারে এবং যখন একভাগে কম আসে তখন ডেটা পেতে পারে। বিস্তৃতভাবে প্রয়োগ করা সকেট এপিআই-তে, একটি রিসিভ কল 20 বাইটের জন্য চাইতে পারে, তবে এটি 10 ​​দিয়ে ফিরে আসতে পারে অবশ্যই, এটিতে একটি বাফারিং স্তর তৈরি করা যেতে পারে যা 20 বাইট না পাওয়া পর্যন্ত বা সংযোগ বিরতি না হওয়া অবরুদ্ধ হবে। পসিক্স ওয়ার্ল্ডে, সেই এপিআই হ'ল স্ট্যান্ডার্ড আই / ও স্ট্রিম হতে পারে: আপনি fdopenএকটি FILE *স্ট্রিম পাওয়ার জন্য সকেট বর্ণনাকারী করতে পারেন এবং আপনি freadএটিতে কোনও বাফার পূরণ করতে ব্যবহার করতে পারেন যাতে পূর্ণ অনুরোধ যতটা readকল নেয় তত সন্তুষ্ট থাকে ।

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

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


এটি মিথ্যা: যদি কেউ 10 বা 20 বাইট পেওলড দিয়ে একটি প্যাকেট প্রেরণ করে তবে এটি 1 প্যাকেট তৈরি করবে এবং (যেমন আমি উপরে বলেছি), আইপিভি 4 ব্যবহার করা হলে এটি অন্য প্রোটোকল স্তরগুলির সমস্ত শিরোনাম যুক্ত করার সময়ও উপযুক্ত হতে পারে 68৮ বাইটের মধ্যে thus টিসিপি স্ট্যাক (আপনার প্রথম অনুচ্ছেদে ইঙ্গিত অনুসারে) "এমটিটি ভরা না হওয়া পর্যন্ত অপেক্ষা করুন (অর্থাত, সঠিকভাবে মাপের জন্য কয়েকটি প্যাকেট যুক্ত করুন)" একটি প্যাকেট প্রেরণ করার জন্য! ... এই আচরণটি অনেক কিছু ভেঙে দেবে ( এমনকি যদি এই "টুকরোগুলি" হোস্টের একই জুটির কাছে এবং প্রেরণ করা হয়েছিল)
অলিভিয়ার ডুলাক

@ অলিভারডুলাক: এটি ভুল। টিসিপি সাধারণত প্রয়োজন মতো প্যাকেট তৈরি করে, নেটওয়ার্কের ব্যবহারের অনুকূলকরণের চেষ্টা করে, তাই 20 বাইট দুটি ভিন্ন প্যাকেটে শেষ করতে পারে কাজের ব্যাখ্যা অনুসারে। এটি TCP_NODELAY সকেট বিকল্পটি ব্যবহার করে নিয়ন্ত্রণ করা যেতে পারে , যা নাগলেস অ্যালগরিদমকে অক্ষম করে যা প্যাকেটে বাইট প্রেরণ করে, যদি আপনার অ্যাপ্লিকেশনটিতে দ্রুত TCP নেটওয়ার্কিং প্রয়োজন হয়। এছাড়াও, 68 বাইট কোনওভাবেই প্যাকেটের দৈর্ঘ্যের জন্য ডি-ফ্যাক্টো স্ট্যান্ডার্ড নয়: 1500 বাইট হ'ল একটি স্বাভাবিক ডিফল্ট মান (এটি প্রকৃতপক্ষে নেটওয়ার্কগুলির মধ্যে পরিবর্তিত হয়)।
jjmontes
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.