TCP_DEFER_ACCEPT এর রিয়েল-ওয়ার্ল্ড ব্যবহার?


15

আমি অনলাইনে অ্যাপাচি httpd ম্যানুয়ালটি অনুধাবন করছিলাম এবং এটি সক্ষম করার জন্য একটি নির্দেশিকা পেলাম। ম্যান পৃষ্ঠায় এর জন্য একটি বিবরণ পেয়েছে tcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

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

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

নিবন্ধটির জন্য, আমার কাছে এটিও মনে হবে যে TCP_DEFER_ACCEPTসকেটের স্থিতি নির্বিশেষে আপনার চারটি প্যাকেট প্রয়োজন (হ্যান্ডশেক তারপর প্রতিটি ক্ষেত্রে ডেটা)। আমি জানি না কীভাবে তারা গণনাটি তিনটিতে নামবে এবং কীভাবে এটি অর্থবহ বর্ধন করে।

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


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

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

যদি কর্মী প্রক্রিয়া ইতিমধ্যে মেমোরিতে থাকে তবে সম্ভবত ডিস্কে যাওয়ার তুলনায় কি খুব কম বিলম্ব হয় না? "ডাউন টু থ্রি" নিবন্ধটির একটি রেফারেন্স যা বলে যে কোনওরকমে এটি এটি তৈরি করবে যাতে ক্লায়েন্টের কাছ থেকে প্রথম প্যাকেটের ডেটা তৃতীয় প্যাকেটে থাকে।
ব্র্যাচলে

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

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

উত্তর:


14

(ওপিতে আমার মন্তব্যগুলি সংক্ষেপে)

তারা যে ত্রিপক্ষীয় হ্যান্ডশেকটি উল্লেখ করছেন তা টিসিপি সংযোগ স্থাপনার অংশ, প্রশ্নে বিকল্পটি এর সাথে বিশেষভাবে সম্পর্কিত নয়। এছাড়াও নোট করুন যে ডেটা এক্সচেঞ্জ হ্যান্ডশেকের তিনটি অংশের অংশ নয়, এটি কেবল উন্মুক্ত / প্রতিষ্ঠিত অবস্থায় টিসিপি সংযোগ তৈরি করে।

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

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

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

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


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

-1

তিন ধরণের হ্যান্ডশেকটি সম্পন্ন করার জন্য অপেক্ষা করার সুবিধা কী হবে তা সম্পর্কে আমি অস্পষ্ট।

ত্রি-মুখী হ্যান্ডশেকগুলি ভয়েস টেলিফোনে একটি সাধারণ প্রোটোকল:

  1. সার্ভার : "শুভ বিকাল, এপিফাইট কর্প।"
  2. কলার : "হ্যালো, এটি র্যান্ডি" "
  3. সার্ভার : "হ্যাঁ, আমি আপনাকে কীভাবে সাহায্য করতে পারি?"
  4. কলার : কল অফ বডি একটি রসিকতার অনুরোধ শুরু করে

চ্যানেলটি প্রতিষ্ঠিত হয়েছে তা নিশ্চিত করার জন্য তারা টিসিপিতে গুরুত্বপূর্ণ। শ্রবণ শুরুর আগে যদি ক্লায়েন্ট বডি কল পাঠাতে শুরু করে (3) সার্ভার শুনছে না বা প্রস্তুত নয় এমন সম্ভাবনা রয়েছে। শ্রবণ (3) গ্যারান্টি দেয় না যে সংক্রমণ হওয়ার পরে সার্ভারটি তাত্ক্ষণিকভাবে স্বতঃস্ফূর্ত জ্বলনে ক্ষতিগ্রস্থ হয় নি তবে এটি আস্থা অর্জন করে যে সার্ভারটি প্রস্তুত হতে প্রস্তুত।

হ্যান্ডশেকিংয়ের উইকিপিডিয়ায় যেমন উল্লেখ করা হয়েছে :

  1. অ্যালিস [সার্ভার] একটি স্বীকৃতি বার্তার সাথে উত্তর + y + 1 দিয়ে উত্তর দিয়েছে, যা বব [ক্লায়েন্ট] পেয়েছে এবং যার কাছে তার জবাব দেওয়ার দরকার নেই

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

  1. সার্ভার : "শুভ বিকাল, এপিফাইট কর্প।"
  2. কলার : "হ্যালো, এটি র্যান্ডি" "
  3. কলার : "আপনি কি আইমেডা মার্কোস সম্পর্কে কোন রসিকতা জানেন?"

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

শ্রবণ (3) গ্যারান্টি দেয় না যে সংক্রমণ হওয়ার পরে সার্ভারটি তাত্ক্ষণিকভাবে স্বতঃস্ফূর্ত জ্বলনে ক্ষতিগ্রস্থ হয় নি তবে এটি আস্থা অর্জন করে যে সার্ভারটি প্রস্তুত হতে প্রস্তুত।
এমএসডব্লিউ

বৃদ্ধি? শূন্য থেকে? আচ্ছা হ্যাঁ, আমি অনুমান করি যে আক্ষরিকভাবে এটি সত্য, তবে বেশিরভাগ লোকেরা বোঝাবেন যে প্যাকেট 3 বাড়ানোর আগে কিছুটা / সুযোগ / সুযোগ ছিল। এবং নেই। এটি কেবল আমার পছন্দ না হওয়া "আত্মবিশ্বাস বাড়িয়ে নিন" এই বাক্যাংশটি, এবং আমি 0.001% 'রিয়েল ওয়ার্ল্ড মেজর ইস্যু'গুলিতে ফ্যাক্টরিংটি মনে করি না তবে বিষয়টি পরিষ্কার রাখতে সহায়তা করে। অবশ্যই, সার্ভারের প্যাকেট পাওয়ার আগে পারমাণবিক যুদ্ধ হতে পারে, প্রচুর পরিমাণে ঘটতে পারে।
আইয়েন

এছাড়াও আমি সবেমাত্র শেষ অনুচ্ছেদে তুলে নিয়েছি, যেখানে আপনি বোঝাচ্ছেন পদক্ষেপ 3 isচ্ছিক। এটা না, একেবারে না। অনুচ্ছেদটি পুনরায় পড়ুন, তৃতীয় পদক্ষেপটি "স্বীকৃতির সাথে এলিসের উত্তর"। এটি alচ্ছিক নয়। বব এর উত্তর দিচ্ছে (একটি তাত্ত্বিক চতুর্থ ধাপ)।
আইয়েন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.