Перейти к содержимому

Windows 11 25H2 میں TCP connection lifecycle

На этой странице

یہ پیرامیٹرز TCP کنکشن کے لائف سائیکل کو کنٹرول کرتے ہیں: پروٹوکول ایکسٹینشنز، TIME_WAIT، keep-alive اور Path MTU کے مسائل کی نشاندہی۔ یہ ping متعین نہیں کرتے اور نہ ہی پہلے سے قائم کنکشن کو تیز کرتے ہیں۔

یہ جانچا گیا کہ tcpipreg.sys اور NSI TCP لائف سائیکل کے پیرامیٹرز کیسے پڑھتے ہیں، کون سی ڈیفالٹ ویلیوز اور رینجز لاگو ہوتی ہیں، اور کیا کنفیگریشن دوبارہ بوٹ کیے بغیر اپ ڈیٹ ہوتی ہے۔

Windows 11 25H2 build 26200.9168, tcpipreg.sys اور NSI۔ مختلف نیٹ ورکس اور ایپلیکیشنز میں نیٹ ورک ٹریسز کی کنٹرولڈ ریکارڈنگ نہیں کی گئی۔

سسٹم کمپوننٹس کا جامد تجزیہ، bootlog کا تجزیہ اور کنفیگریشن کی live اپ ڈیٹ کا مشاہدہ۔

Registry path Value Type Default/عام حالت کردار
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Tcp1323Opts REG_DWORD 3، اگر موجود نہ ہو legacy extensions policy
وہی path TcpTimedWaitDelay REG_DWORD 120 سیکنڈ، 30..300 TIME_WAIT duration
وہی path KeepAliveTime REG_DWORD 7200000 ms idle keep-alive interval
وہی path EnablePMTUBHDetect REG_DWORD 0 PMTU black-hole detection

پرانی TCP پیرامیٹرز کو tcpipreg.sys پڑھتا ہے اور NSI کے ذریعے tcpip.sys کمپوننٹ تک پہنچاتا ہے۔ کچھ ویلیوز کے لیے ZwNotifyChangeKey استعمال ہوتا ہے، جو نیٹ ورک اسٹیک کو مکمل دوبارہ بوٹ کیے بغیر کنفیگریشن دوبارہ پڑھنے کی اجازت دیتا ہے۔

Tcp1323Opts مطابقت کے لیے محفوظ رکھا گیا ہے۔ اس کی ویلیوز 0..3 تاریخی طور پر TCP ونڈو اسکیلنگ اور ٹائم اسٹیمپس کو بیان کرتی تھیں۔ Windows 11 25H2 میں یہ پیرامیٹر tcpipreg.sys پڑھتا ہے، اور ویلیو 1 NSI کو پاس کرنے سے پہلے تبدیل ہوتی ہے۔ جدید خودکار receive window tuning ایک الگ پالیسی کے ذریعے کنٹرول ہوتی ہے۔ لہٰذا پرانا بٹ ٹیبل ہر کنکشن کی حقیقی حالت کا تعین نہیں کرتا۔

TcpTimedWaitDelay کنکشن بند ہونے کے بعد TCP کنٹرول بلاک کو TIME_WAIT میں رکھنے کا دورانیہ متعین کرتا ہے۔ دستاویزی رینج 30..300 سیکنڈ ہے، ڈیفالٹ ویلیو 120 ہے۔ انتظار کم کرنے سے عارضی پورٹس پہلے آزاد ہو جاتے ہیں، لیکن پرانے کنکشن کے تاخیر سے پہنچنے والے سیگمنٹس سے تحفظ کے لیے کم وقت بچتا ہے۔

KeepAliveTime بیکار کنکشن کے لیے keep-alive پروب پیکٹ تک کا وقفہ متعین کرتا ہے۔ ڈیفالٹ کے طور پر یہ 7 200 000 ms ہے۔ ایپلیکیشن کو ساکٹ کے لیے keep-alive الگ سے فعال کرنا ہوگا، لہٰذا گلوبل وقفہ کم کرنے سے تمام کنکشنز کے پس منظر کے پروبز شروع نہیں ہوتے۔

EnablePMTUBHDetect=1 Path MTU کے “بلیک ہولز” کی نشاندہی فعال کرتا ہے، جب ICMP کے fragmentation کی ضرورت کے نوٹیفکیشنز بھیجنے والے تک نہیں پہنچتے۔ یہ میکانزم ایسے مسئلے والے روٹ پر کام کرنے میں مدد کرتا ہے اور دوبارہ ترسیل کی تعداد بڑھا سکتا ہے۔ یہ صحت مند نیٹ ورک کو تیز نہیں کرتا۔

یہ پیرامیٹرز ان سرورز اور کلائنٹس کے لیے مفید ہیں جن میں بہت زیادہ مختصر TCP کنکشنز ہوں یا MTU غیر مستحکم ہو۔ ایک ویلیو تبدیل کرنے سے عام ایپلیکیشنز کی عالمگیر تیزی کی توقع نہیں کرنی چاہیے۔ نتیجہ کنکشن کے دوسرے سرے، NAT، روٹر، نیٹ ورک کارڈ ڈرائیور، VPN اور congestion control پر منحصر ہے۔

یہ تحقیق Windows 11 25H2 build 26200.9168 سے متعلق ہے۔ مختلف نیٹ ورکس اور ایپلیکیشنز میں نیٹ ورک ٹریسز کی کنٹرولڈ ریکارڈنگ نہیں کی گئی۔

tcpipreg.sys کلید میں تبدیلیوں کی نگرانی کرتا ہے اور کچھ پرانی سیٹنگز کو دوبارہ بوٹ کیے بغیر اپ ڈیٹ کر سکتا ہے۔ تاہم پہلے سے کھلے TCP کنکشنز ضروری نہیں کہ اپنے پیرامیٹرز دوبارہ طے کریں۔ اصل اور تبدیل شدہ حالت کے درست موازنے کے لیے نئے کنکشنز بنائیں۔

  • جانچے گئے build میں پیرامیٹرز کے paths، types، ڈیفالٹ ویلیوز اور رینجز۔
  • tcpipreg.sys اور NSI کے ذریعے پڑھنا؛ کچھ ویلیوز اسٹیک کو مکمل دوبارہ بوٹ کیے بغیر اپ ڈیٹ ہوتی ہیں۔
  • Tcp1323Opts کے لیے ویلیو 1 NSI کو پاس کرنے سے پہلے تبدیل ہوتی ہے۔
  • Keep-alive کے لیے ساکٹ کے لیے الگ سے فعال کرنا ضروری ہے۔
  • انفرادی ویلیوز تبدیل کرنے سے ایپلیکیشنز کی تیزی۔
  • مخصوص نیٹ ورکس، NAT، VPN کے پیچھے اور پیکٹ لاس کے دوران رویہ۔
  • پہلے سے کھلے کنکشنز کی جانب سے پیرامیٹرز کا دوبارہ طے ہونا۔

ڈیفالٹ ویلیوز رہنے دیں۔ پیرامیٹرز صرف ان سرورز اور کلائنٹس کے لیے تبدیل کریں جن میں بہت زیادہ مختصر کنکشنز ہوں یا MTU غیر مستحکم ہو، اور نتیجے کا موازنہ نئے کنکشنز پر کریں۔

اصل ویلیوز واپس لائیں یا اختیاری اندراجات حذف کریں۔ نتیجہ نئے کنکشنز پر جانچیں: پہلے سے کھلے کنکشنز پرانے پیرامیٹرز برقرار رکھ سکتے ہیں۔

مشاہدات کے متحرک حصے کو کیسے دہرایا جائے — دیکھیں خود کیسے جانچیں۔

تحقیق اور استعمال شدہ ٹولز BoosterX کے ڈویلپر کی ملکیت ہیں، لہٰذا ڈویلپر کا نتائج میں براہ راست مفاد ہے۔ طریقہ کار اور اطلاق کی حدود اوپر بیان کی گئی ہیں، اور نتائج کو کھلے ڈیٹا اور درج ذیل عوامی ذرائع سے جانچا جا سکتا ہے۔

عوامی ذرائع کی جانچ: 2026-09-02۔

  • 2026-09-20: مفادات کے تصادم کے بارے میں ڈس کلیمر اور طریقہ کار میں متحرک مشاہدات کی خود جانچ کے لنک کا اضافہ۔
  • 2026-09-02: پہلی اشاعت؛ readers، defaults اور live reload کی تصدیق، عملی اثرات کی حدود کا اضافہ۔