برنامه نویسی شبکه - TCP. برنامه کلاینت-سرور در سوکت جریان TCP تنظیم مقادیر پارامتر IP

TCP بطور طبیعی در محیط سرویس گیرنده/سرور ادغام می شود (شکل 10.1 را ببینید). نرم افزار سرور اشکالات(گوش دادن) درخواست های اتصال ورودی. برای مثال، سرویس‌های WWW، انتقال فایل یا دسترسی به ترمینال به درخواست‌های مشتریان گوش می‌دهند. ارتباطات در TCP توسط روتین های مناسب آغاز می شود، که اتصال به سرور را آغاز می کند (به فصل 21 در مورد رابط برنامه نویسی سوکت مراجعه کنید).

برنج. 10.1.مشتری با سرور تماس می گیرد.

در واقع، مشتری ممکن است سرور دیگری باشد. به عنوان مثال، سرورهای پست الکترونیکی می توانند به سرورهای دیگر متصل شوند سرورهای پست الکترونیکیبرای فوروارد کردن پیام ها پست الکترونیکبین کامپیوترها

10.2 مفاهیم TCP

برنامه ها باید به چه شکل داده ها را در TCP ارسال کنند؟ TCP به چه شکل داده ها را به IP منتقل می کند؟ چگونه پروتکل های ارسال و دریافت TCP ارتباط بین برنامه ها و عناصر داده مورد نیاز برای پیاده سازی آن را شناسایی می کنند؟ به تمام این سوالات در بخش های زیر پاسخ داده شده است که مفاهیم اولیه TCP را توضیح می دهد.

10.2.1 جریان داده های ورودی و خروجی

مفهومیمدل اتصال شامل یک برنامه کاربردی است که یک جریان داده را به یک برنامه همتا ارسال می کند. در عین حال، قادر به دریافت جریان داده از شریک اتصال خود است. TCP فراهم می کند دوبلکس کاملحالت کار (فول دوبلکس) که در آن به طور همزمان سرویس می شود دو جریانداده ها (شکل 10.2 را ببینید).

برنج. 10.2.برنامه ها جریان های داده را تبادل می کنند.

10.2.2 بخش ها

TCP می‌تواند جریان داده‌ای را که برنامه را ترک می‌کند، به فرمی مناسب برای ذخیره در دیتاگرام تبدیل کند. چگونه؟

برنامه داده ها را به TCP ارسال می کند و این پروتکل آن را در آن قرار می دهد بافر خروجی(ارسال بافر). سپس، TCP تکه‌هایی از داده‌ها را از بافر بریده و آنها را ارسال می‌کند و یک هدر اضافه می‌کند. بخش ها- بخش). در شکل 10.3 نشان می دهد که چگونه داده ها از بافر خروجی TCP به بخش هایی بسته بندی می شود. TCP بخش را برای تحویل به عنوان یک دیتاگرام جداگانه به IP ارسال می کند. بسته‌بندی داده‌ها به تکه‌هایی با طول صحیح، ارسال کارآمد را تضمین می‌کند، بنابراین TCP قبل از ایجاد یک بخش منتظر می‌ماند تا مقدار مناسب داده در بافر خروجی در دسترس باشد.

برنج. 10.3ایجاد یک بخش TCP

10.2.3 هل دادن

با این حال، استفاده از مقادیر زیاد داده در برنامه های کاربردی دنیای واقعی اغلب غیرممکن است. به عنوان مثال، زمانی که یک برنامه مشتری کاربر نهایی یک جلسه تعاملی را با آن آغاز می کند سرور راه دور، سپس کاربر فقط دستورات را وارد می کند (با فشار دادن کلید دنبال می شود برگشت).

برنامه کلاینت کاربر به TCP نیاز دارد تا بداند داده ها به میزبان راه دور ارسال می شود و این عملیات را فورا انجام دهد. در این مورد استفاده می شود بیرون راندن(فشار دادن).

اگر به عملیات در یک جلسه تعاملی نگاه کنید، بخش‌های زیادی با داده‌های کم را خواهید یافت، و علاوه بر این، تقریباً در هر بخش داده‌ای می‌توان popping را پیدا کرد. با این حال، فشار دادن نباید در حین انتقال فایل استفاده شود (به جز آخرین بخش)، و TCP می‌تواند داده‌ها را در بخش‌هایی به بهترین نحو بسته‌بندی کند.

10.2.4 داده های فوری

مدل ارسال اطلاعات برنامه شامل یک جریان مرتب شده از بایت ها است که به مقصد سفر می کنند. با اشاره مجدد به مثال جلسه تعاملی، فرض کنید کاربر کلیدی را فشار داده است توجه(توجه) یا زنگ تفريح(وقفه). برنامه راه دور باید بتواند بایت های مزاحم را رد کند و در سریع ترین زمان ممکن به ضربه زدن به کلید پاسخ دهد.

سازوکار داده های فوری(داده فوری) اطلاعات ویژه در یک بخش را به عنوان علامت گذاری می کند فوریبا انجام این کار، TCP به همتای خود می گوید که بخش حاوی داده های فوری است و می تواند نشان دهد که در کجا قرار دارد. شریک باید این اطلاعات را در اسرع وقت به برنامه مقصد ارسال کند.

10.2.5 پورت های کاربردی

مشتری باید سرویسی را که می خواهد به آن دسترسی داشته باشد شناسایی کند. این کار از طریق مشخص کردن آدرس IP سرویس میزبان و شماره پورت TCP آن انجام می شود. مانند UDP، شماره پورت های TCP از 0 تا 65535 متغیر است. پورت هایی در محدوده 0 تا 1023 معروف هستند و برای دسترسی به خدمات استاندارد استفاده می شوند.

چندین نمونه از پورت های شناخته شده و کاربردهای مربوط به آنها در جدول 10.1 نشان داده شده است. خدمات دور انداختن(پورت 9) و متهم(پورت 19) نسخه‌های TCP خدماتی هستند که قبلاً از طریق UDP برای ما شناخته شده‌اند. باید به خاطر داشت که ترافیک پورت 9 پروتکل TCP کاملاً از ترافیک به پورت 9 پروتکل UDP جدا شده است.

جدول 10.1 پورت های TCP شناخته شده و کاربردهای مربوط به آنها

بندر	کاربرد	شرح
9	دور انداختن	تمام داده های دریافتی را لغو کنید
19	شارژر	مولد کاراکتر. تبادل جریان کاراکتر
20	داده های FTP	پورت انتقال داده FTP
21	FTP	پورت برای گفتگوی FTP
23	TELNET	پورت برای ثبت نام از راه دور از طریق Telnet
25	SMTP	پورت پروتکل SMTP
110	POP3	خدمات نمونه برداری ایمیل برای رایانه های شخصی
119	NNTP	دسترسی به اخبار آنلاین

در مورد پورت های مورد استفاده مشتریان چطور؟ در موارد نادر، مشتری از طریق یک پورت شناخته شده کار نمی کند. اما در چنین مواقعی که بخواهد یک اتصال را باز کند، اغلب از سیستم عامل می خواهد که یک پورت استفاده نشده و رزرو نشده به آن اختصاص دهد. در پایان اتصال، کلاینت باید این پورت را برگرداند، پس از آن، پورت می تواند توسط کلاینت دیگری مورد استفاده مجدد قرار گیرد. از آنجایی که بیش از 63000 پورت TCP در مجموعه شماره های رزرو نشده وجود دارد، محدودیت های پورت مشتری را می توان نادیده گرفت.

10.2.6 آدرس های سوکت

همانطور که می دانیم ترکیب آدرس IP و پورت برای ارتباط نامیده می شود سوکت آدرسیک اتصال TCP به طور کامل توسط آدرس سوکت در هر انتها مشخص می شود از این ارتباط. در شکل شکل 10.4 ارتباط بین یک کلاینت با آدرس سوکت (128.36.1.24، پورت = 3358) و یک سرور با آدرس سوکت (130.42.88.22، پورت = 21) را نشان می دهد.

برنج. 10.4.آدرس های سوکت

هدر هر دیتاگرام حاوی آدرس IP مبدا و مقصد است. بعداً خواهید دید که شماره پورت مبدا و مقصد در سربرگ بخش TCP مشخص شده است.

به طور معمول، یک سرور قادر است چندین مشتری را به طور همزمان مدیریت کند. آدرس های سوکت سرور منحصر به فرد به طور همزمان به همه مشتریان آن اختصاص داده می شود (شکل 10.5 را ببینید).

برنج. 10.5.چندین مشتری به آدرس های سوکت سرور متصل می شوند

از آنجایی که یک دیتاگرام شامل یک بخش اتصال TCP است که توسط آدرس‌های IP و پورت‌ها مشخص می‌شود، برای سرور بسیار آسان است که چندین اتصال به کلاینت‌ها را پیگیری کند.

10.3 مکانیسم قابلیت اطمینان TCP

در این بخش، مکانیسم TCP مورد استفاده برای تحویل مطمئن داده ها در عین حفظ نظم انتقال و جلوگیری از گم شدن یا تکرار را بررسی خواهیم کرد.

10.3.1 شماره گذاری و تایید

TCP از شماره گذاری و تصدیق (ACK) برای اطمینان از انتقال داده های قابل اعتماد استفاده می کند. طرح شماره گذاری TCP تا حدودی غیر معمول است: هراز طریق اتصال ارسال می شود هشت گانهدارای شماره سریال در نظر گرفته می شود. هدر قطعه TCP حاوی یک شماره دنباله است اولین اکتت داده در این بخش.

گیرنده باید تأیید کند که داده ها دریافت شده است. اگر ACK در بازه زمانی بازنموده نشود، داده ها دوباره ارسال می شود. این روش نامیده می شود تایید مثبت با رله(تصدیق مثبت با ارسال مجدد).

گیرنده داده‌های TCP به‌شدت شماره‌های دنباله ورودی را بررسی می‌کند تا تأیید کند که داده‌ها به ترتیب دریافت شده‌اند و هیچ بخش گمشده‌ای وجود ندارد. از آنجایی که ACK ممکن است به طور تصادفی گم شود یا به تاخیر بیفتد، بخش های تکراری ممکن است به گیرنده برسد. اعداد ترتیبی به شما امکان می‌دهند داده‌های تکراری را شناسایی کنید، که سپس دور ریخته می‌شوند.

در شکل شکل 10.6 یک نمای ساده از مهلت زمانی و ارسال مجدد در TCP را نشان می دهد.

برنج. 10.6.مهلت زمانی و ارسال مجدد در TCP

10.3.2 فیلدهای پورت، ترتیب و ACK در هدر TCP

همانطور که در شکل نشان داده شده است. 10.7، چند فیلد اول هدر TCP فضایی را برای مقادیر پورت مبدأ و مقصد، شماره ترتیب اولین بایت داده های محصور شده و یک ACK برابر با شماره دنباله فراهم می کند. بعدبایت در انتهای دیگر مورد انتظار است. به عبارت دیگر، اگر TCP تمام بایت‌های تا 30 را از همتای خود دریافت کند، این فیلد دارای مقدار 31 خواهد بود که نشان‌دهنده بخش بعدی برای فوروارد است.

برنج. 10.7.مقادیر اولیه در فیلدهای هدر TCP

نمی توان از یک جزئیات کوچک چشم پوشی کرد. فرض کنید TCP بایت های 1 را به 50 ارسال کرده است و دیگر داده ای برای ارسال وجود ندارد. اگر داده‌ها از همتا دریافت می‌شود، TCP باید با ارسال سرصفحه‌ای بدون داده‌های متصل به آن، دریافت آن را تأیید کند. طبیعتاً این هدر حاوی مقدار ACK است. در قسمت sequence - مقدار 51 است، یعنی. تعداد بایت بعدی که قصد داردارسال TCP هنگامی که TCP داده های بعدی را ارسال می کند، هدر TCP جدید نیز دارای یک فیلد توالی 51 خواهد بود.

10.4 ایجاد ارتباط

چگونه دو برنامه به یکدیگر متصل می شوند؟ قبل از برقراری ارتباط، هر یک از آنها یک زیر روال را فراخوانی می کند تا یک بلوک حافظه را تشکیل دهد که برای ذخیره پارامترهای TCP و IP یک اتصال مشخص استفاده می شود، به عنوان مثال، آدرس های سوکت، شماره دنباله فعلی، مقدار طول عمر اولیه و غیره.

برنامه سرور منتظر می ماند تا یک کلاینت ظاهر شود، که در صورت تمایل به دسترسی به سرور، درخواستی برای آن صادر می کند ترکیب(اتصال)، شناسایی آدرس IP سرور و پورت.

یه دونه هست ویژگی فنی. هر طرف شماره گذاری هر بایت را نه با یک، بلکه با شروع می کند شماره سریال تصادفی(بعداً متوجه خواهیم شد که چرا این کار انجام می شود). مشخصات اصلی توصیه می کند که شماره دنباله اولیه بر اساس یک تایمر خارجی 32 بیتی تولید شود که تقریباً هر 4 میکرو ثانیه افزایش می یابد.

10.4.1 سناریوی اتصال

روش اتصال اغلب دست دادن سه طرفه نامیده می شود زیرا سه پیام برای برقراری یک اتصال رد و بدل می شود - SYN، SYN و ACK.

در طول برقراری ارتباط، شرکا سه اطلاعات مهم را مبادله می کنند:

1. فضای بافر برای دریافت داده ها

2. حداکثر مقدار داده حمل شده در یک بخش ورودی

3. شماره دنباله شروع مورد استفاده برای داده های خروجی

توجه داشته باشید که هر یک از طرفین از عملیات 1 و 2 برای نشان دادن استفاده می کنند حدودی که طرف مقابل در آن عمل خواهد کرد.یک کامپیوتر شخصی ممکن است یک بافر دریافت کوچک داشته باشد، اما یک ابر کامپیوتر ممکن است یک بافر بزرگ داشته باشد. ساختار حافظه کامپیوتر شخصیمی تواند تکه های داده های دریافتی را به 1 کیلوبایت محدود کند و ابررایانه بخش های بزرگی را مدیریت می کند.

امکان کنترل نحوه ارسال داده توسط طرف مقابل وجود دارد دارایی مهم، مقیاس پذیری TCP/IP را فراهم می کند.

در شکل شکل 10.8 نمونه ای از اسکریپت اتصال را نشان می دهد. اعداد دنباله اولیه بسیار ساده ارائه شده اند تا نقشه بیش از حد بارگذاری نشود. توجه داشته باشید که در این شکل کلاینت قادر است سگمنت های بزرگتری نسبت به سرور دریافت کند.

برنج. 10.8.برقراری ارتباط

عملیات زیر انجام می شود:

1. سرور مقدار دهی اولیه می شود و برای اتصال به کلاینت ها آماده می شود (به این حالت پسیو باز می گویند).

2. کلاینت از TCP درخواست می کند تا یک اتصال به سرور در آدرس IP و پورت مشخص شده باز کند (به این حالت فعال باز می گویند).

3. TCP مشتری یک شماره دنباله اولیه (in در این مثال- 1000) و ارسال می کند همگام سازی بخش(همگام سازی بخش - SYN). این بخش شامل شماره دنباله، اندازه پنجره دریافت (4K) و اندازه بزرگترین قسمتی است که مشتری می تواند دریافت کند (1460 بایت).

4. هنگامی که یک SYN می رسد، سرور TCP دریافت می کند مال خودمشماره دنباله شروع (3000). یک قطعه SYN حاوی شماره دنباله شروع (3000)، ACK 1001 (به این معنی که اولین بایت ارسال شده توسط مشتری با شماره 1001 شماره گذاری شده است)، اندازه پنجره دریافت (4K) و اندازه بزرگترین بخش که سرور می تواند. دریافت (1024 بایت).

6. مشتری TCP به برنامه خود دستور می دهد تا اتصال را باز کند.

7. سرور TCP با دریافت پیام ACK از مشتری TCP، برنامه خود را در مورد باز کردن اتصال مطلع می کند.

مشتری و سرور قوانین خود را برای داده های دریافتی اعلام می کنند، شماره های دنباله خود را همگام می کنند و آماده تبادل داده می شوند. مشخصات TCP همچنین امکان سناریوی دیگر (نه خیلی موفق) را فراهم می کند، زمانی که برنامه های همتا به طور همزمان به طور فعال یکدیگر را باز می کنند.

10.4.2 تنظیم مقادیر پارامتر IP

یک درخواست برنامه برای ایجاد یک اتصال همچنین ممکن است پارامترهایی را برای دیتاگرام های IP که داده های اتصال را حمل می کنند مشخص کند. اگر مقدار پارامتر خاصی مشخص نشده باشد، از مقدار پیش فرض استفاده می شود.

به عنوان مثال، یک برنامه کاربردی می تواند مقدار دلخواه را برای اولویت IP یا نوع سرویس انتخاب کند. از آنجایی که هر یک از طرف های متصل به طور مستقل اولویت و نوع سرویس خود را تعیین می کند، از نظر تئوری این مقادیر می توانند برای جهت های مختلف جریان داده متفاوت باشند. به عنوان یک قاعده، در عمل از همان مقادیر برای هر جهت مبادله استفاده می شود.

هنگامی که یک برنامه شامل گزینه های امنیتی دولتی یا نظامی می شود، هر نقطه پایانی اتصال باید از همان سطوح امنیتی استفاده کند در غیر این صورت اتصال برقرار نمی شود.

10.5 انتقال داده

انتقال داده ها پس از تکمیل تایید سه مرحله ای ایجاد اتصال آغاز می شود (شکل 10.9 را ببینید). استاندارد TCP اجازه می دهد تا داده های معمولی در بخش های تأیید گنجانده شوند، اما تا زمانی که اتصال کامل نشود به برنامه تحویل داده نمی شود. برای ساده سازی شماره گذاری، از پیام های 1000 بایتی استفاده می شود. هر بخش هدر TCP دارای یک فیلد ACK است که شماره دنباله بایتی را که انتظار می‌رود از شریک اتصال دریافت شود، شناسایی می‌کند..

برنج. 10.9.تبادل داده ساده و جریان ACK

اولین بخش ارسال شده توسط مشتری شامل بایت های 1001 تا 2000 است. فیلد ACK آن باید حاوی مقدار 3001 باشد که نشان دهنده شماره دنباله بایتی است که انتظار می رود از سرور دریافت شود.

سرور با یک بخش حاوی 1000 بایت داده (با شماره 3001 شروع می شود) به مشتری پاسخ می دهد. فیلد ACK هدر TCP آن نشان می‌دهد که بایت‌های 1001 تا 2000 قبلاً با موفقیت دریافت شده‌اند، بنابراین شماره دنباله بخش بعدی مورد انتظار از مشتری باید 2001 باشد.

سپس کلاینت بخش هایی را می فرستد که با بایت های 2001، 3001 و 4001 شروع می شوند در دنباله مشخص شده. توجه داشته باشید که مشتری پس از ارسال هر یک از بخش‌ها منتظر ACK نمی‌ماند. داده ها تا زمانی که فضای بافر آن پر شود برای همتا ارسال می شود (در زیر می بینیم که گیرنده می تواند مقدار داده ارسالی به او را بسیار دقیق مشخص کند).

سرور پهنای باند اتصال را با استفاده از یک ACK برای نشان دادن موفقیت در ارسال همه بخش ها ذخیره می کند.

در شکل شکل 10.10 انتقال داده را زمانی نشان می دهد که اولین بخش از بین می رود. هنگامی که مهلت زمانی منقضی می شود، بخش دوباره ارسال می شود. توجه داشته باشید که با دریافت یک قطعه گم شده، گیرنده یک ACK ارسال می کند که ارسال هر دو بخش را تایید می کند.

برنج. 10.10.از دست دادن داده ها و ارسال مجدد

10.6 بستن یک اتصال

خاتمه عادی یک اتصال با استفاده از همان روش دست دادن سه گانه مانند هنگام باز کردن یک اتصال انجام می شود. هر طرف می تواند با استفاده از سناریوی زیر شروع به بستن اتصال کند:

آ:

ب:"خوب".

که در:"من هم کار را تمام کردم."

آ:"خوب".

بیایید سناریوی زیر را فرض کنیم (اگرچه بسیار به ندرت استفاده می شود):

آ:"کارم تمام شد. اطلاعات دیگری برای ارسال وجود ندارد."

که در:"خوب. با این حال، برخی از داده ها وجود دارد..."

که در:"من هم کار را تمام کردم."

آ:"خوب".

در مثال زیر، اتصال توسط سرور بسته شده است، همانطور که اغلب برای اتصالات سرویس گیرنده/سرور چنین است. در این حالت پس از ورود کاربر به جلسه شبکه راه دوردستور خروج باعث می شود که سرور درخواستی را برای بستن اتصال آغاز کند. در وضعیت نشان داده شده در شکل. 10.11، اقدامات زیر انجام می شود:

1. برنامه روی سرور به TCP می گوید که اتصال را ببندد.

2. سرور TCP یک بخش نهایی (Final Segment - FIN) را ارسال می کند و به همتای خود اطلاع می دهد که داده دیگری برای ارسال وجود ندارد.

3. TCP مشتری یک ACK در بخش FIN ارسال می کند.

4. TCP مشتری به برنامه خود می گوید که سرور می خواهد اتصال را ببندد.

5. برنامه مشتری به TCP خود می گوید که اتصال را ببندد.

6. مشتری TCP یک پیام FIN ارسال می کند.

7. سرور TCP FIN را از کلاینت دریافت می کند و با یک پیام ACK پاسخ می دهد.

8. TCP سرور به برنامه خود می گوید که اتصال را ببندد.

برنج. 10.11.بستن یک اتصال

هر دو طرف می توانند همزمان شروع به بسته شدن کنند. در این حالت، بسته شدن اتصال عادی پس از ارسال پیام ACK توسط هر همتا تکمیل می شود.

10.6.1 خاتمه ناگهانی

هر طرف می تواند درخواست قطع ناگهانی (بسته شدن ناگهانی) اتصال کند. این زمانی قابل قبول است که یک برنامه بخواهد یک اتصال را خاتمه دهد یا زمانی که TCP یک مشکل ارتباطی جدی را تشخیص می دهد که نمی تواند به وسیله خود آن را حل کند. خاتمه ناگهانی با ارسال یک یا چند پیام بازنشانی به همتا درخواست می شود که با یک پرچم خاص در هدر TCP نشان داده شده است.

10.7 کنترل جریان

گیرنده TCP با جریان داده های ورودی بارگیری می شود و تعیین می کند که چه مقدار اطلاعات می تواند بپذیرد. این محدودیت بر فرستنده TCP تأثیر می گذارد. توضیح زیر در مورد این مکانیسم مفهومی است و توسعه دهندگان ممکن است آن را به روش های مختلف در محصولات خود پیاده کنند.

در طول راه اندازی اتصال، هر همتا فضایی را برای بافر ورودی اتصال اختصاص می دهد و طرف مقابل را در مورد آن مطلع می کند. به طور معمول، اندازه بافر به عنوان یک عدد صحیح از حداکثر اندازه های بخش بیان می شود.

جریان داده وارد بافر ورودی می شود و قبل از ارسال به برنامه (تعریف شده توسط پورت TCP) در آنجا ذخیره می شود. در شکل شکل 10.12 یک بافر ورودی را نشان می دهد که می تواند 4 کیلوبایت را بپذیرد.

برنج. 10.12.پنجره دریافت بافر ورودی

فضای بافر با رسیدن داده ها پر می شود. هنگامی که برنامه دریافت کننده داده ها را از بافر بازیابی می کند، فضای آزاد شده برای داده های ورودی جدید در دسترس می شود.

10.7.1 پنجره دریافت

پنجره دریافت(پنجره دریافت) - هر فضایی در بافر ورودی که قبلاً توسط داده ها اشغال نشده باشد. داده ها در بافر ورودی باقی می مانند تا زمانی که توسط برنامه مورد نظر استفاده شود. چرا برنامه بلافاصله داده ها را جمع آوری نمی کند؟

یک سناریوی ساده به پاسخ به این سوال کمک می کند. بیایید فرض کنیم که مشتری فایل را به سرور FTPدر حال اجرا بر روی یک کامپیوتر چند کاربره بسیار شلوغ سپس برنامه FTP باید داده ها را از بافر خوانده و روی دیسک بنویسد. هنگامی که سرور عملیات ورودی/خروجی دیسک را انجام می دهد، برنامه منتظر می ماند تا این عملیات تکمیل شود. در این زمان، ممکن است برنامه دیگری شروع شود (مثلاً طبق برنامه زمانی) و در حالی که برنامه FTPدوباره شروع می شود، داده های بعدی از قبل به بافر می رسند.

پنجره دریافت از آخرین بایت تایید شده تا انتهای بافر امتداد دارد. در شکل 10.12، ابتدا کل بافر در دسترس است و بنابراین، یک پنجره دریافت 4 کیلوبایتی در دسترس است. هنگامی که اولین KB می رسد، پنجره دریافت به 3 کیلوبایت کاهش می یابد (برای سادگی، اندازه هر بخش را 1 کیلوبایت فرض می کنیم، اگرچه در عمل این مقدار بسته به نیاز برنامه متفاوت است). ورود دو بخش 1 کیلوبایتی بعدی، پنجره دریافت را به 1 کیلوبایت کاهش می دهد.

هر ACK ارسال شده توسط گیرنده حاوی اطلاعاتی در مورد وضعیت فعلی پنجره دریافت کننده است، بسته به اینکه جریان داده از منبع تنظیم می شود.

در بیشتر موارد، اندازه بافر ورودی هنگام شروع اتصال تنظیم می شود، اگرچه استاندارد TCP نحوه مدیریت این بافر را مشخص نمی کند. بافر ورودی را می توان برای پیاده سازی افزایش یا کاهش داد بازخوردبا فرستنده

چه اتفاقی می‌افتد اگر بخش ورودی را بتوان در پنجره دریافت‌کننده قرار داد، اما از حالت عادی خارج شد؟ عموماً فرض بر این است که همه پیاده‌سازی‌ها داده‌های دریافتی را در یک پنجره دریافت ذخیره می‌کنند و فقط برای کل بلوک پیوسته از چندین بخش، یک تأیید (ACK) ارسال می‌کنند. این راه درستی است، زیرا در غیر این صورت، دور ریختن داده هایی که از نظم خارج می شوند، عملکرد را به میزان قابل توجهی کاهش می دهد.

10.7.2 پنجره ارسال

سیستم انتقال دهنده داده باید دو ویژگی را دنبال کند: مقدار داده ای که قبلاً ارسال و تأیید شده است و اندازه فعلی پنجره دریافت گیرنده. فعال ارسال فضا(فضای ارسال) از اولین اکتت تایید نشده تا لبه سمت چپ پنجره دریافت فعلی گسترش می یابد. قسمت پنجره، استفاده شده فرستادن، نشان می دهد که چه مقدار داده اضافی می تواند به شریک ارسال شود.

شماره توالی اولیه و اندازه پنجره دریافت اولیه در طول راه اندازی اتصال مشخص می شود. برنج. شکل 10.13 برخی از ویژگی های مکانیسم انتقال داده را نشان می دهد.

1. فرستنده با یک پنجره ارسال 4 کیلوبایتی شروع می کند.

2. فرستنده 1 کیلوبایت ارسال می کند. یک کپی از این داده ها تا زمانی که یک تأییدیه (ACK) دریافت شود حفظ می شود، زیرا ممکن است نیاز به ارسال مجدد داشته باشد.

3. پیام ACK برای اولین KB می رسد و 2 کیلوبایت بعدی داده ارسال می شود. نتیجه در قسمت سوم از بالای شکل نشان داده شده است. 10.13. فضای ذخیره سازی 2 کیلوبایت ادامه دارد.

4. در نهایت، یک ACK برای تمام داده های ارسال شده می رسد (یعنی همه آن ها توسط گیرنده دریافت می شود). ACK اندازه پنجره ارسال را به 4 کیلوبایت باز می گرداند.

برنج. 10.13.ارسال پنجره

چندین ویژگی جالب توجه وجود دارد:

■ فرستنده برای هر بخش داده ای که ارسال می کند منتظر ACK نمی ماند. تنها محدودیت در ارسال، اندازه پنجره دریافت است (به عنوان مثال، فرستنده باید تنها بخش های تک بایتی 4K را ارسال کند).

■ فرض کنید فرستنده داده ها را در چندین بخش بسیار کوتاه (مثلاً 80 بایت) ارسال می کند. در این مورد، داده ها را می توان برای انتقال کارآمدتر (مثلاً به یک بخش واحد) دوباره قالب بندی کرد.

هدر TCP 10.8

در شکل شکل 10.14 فرمت بخش (سرصفحه TCP و داده) را نشان می دهد. هدر با شناسه پورت مبدا و مقصد شروع می شود. فیلد بعدی بعدی شماره سریال(شماره دنباله) موقعیتی را در جریان داده خروجی نشان می دهد که این بخش اشغال می کند. رشته ACK(تصدیق) حاوی اطلاعاتی در مورد بخش بعدی مورد انتظار است که باید در جریان داده ورودی ظاهر شود.

برنج. 10.14.بخش TCP

شش پرچم وجود دارد:

رشته افست داده ها(Data Offset) شامل اندازه هدر TCP در کلمات 32 بیتی است. هدر TCP باید روی یک مرز 32 بیتی ختم شود.

10.8.1 گزینه حداکثر اندازه بخش

پارامتر "حداکثر اندازه بخش"(حداکثر اندازه بخش - MSS) برای اعلام بزرگترین قطعه داده ای که می تواند توسط سیستم پذیرفته و پردازش شود استفاده می شود. با این حال، نام تا حدودی نادرست است. معمولا در TCP بخشبه عنوان هدر به علاوه داده در نظر گرفته می شود. با این حال حداکثر اندازه بخشکه تعریف میشود:

اندازه بزرگترین دیتاگرام قابل دریافت 40 است

به عبارت دیگر، MSS بزرگترین را منعکس می کند ظرفیت ترابریدر گیرنده زمانی که هدر TCP و IP 20 بایت باشد. اگر وجود دارد گزینه های اضافیطول آنها باید از اندازه کل کم شود. بنابراین، مقدار داده ای که می تواند در یک بخش ارسال شود به صورت زیر تعریف می شود:

مقدار بیان شده MSS + 40 - (مجموع طول سرصفحه TCP و IP)

همتایان معمولاً هنگام باز کردن یک اتصال، مقادیر MSS را در پیام‌های SYN اولیه مبادله می‌کنند. اگر سیستم حداکثر مقدار اندازه بخش را تبلیغ نکند، از مقدار پیش فرض 536 بایت استفاده می شود.

حداکثر اندازه بخش به صورت یک ورودی 2 بایتی و سپس یک مقدار 2 بایتی کدگذاری می شود. بزرگترین مقدار 2 16 -1 (65535 بایت) خواهد بود.

MSS محدودیت شدیدی بر روی داده های ارسال شده در TCP اعمال می کند: گیرنده قادر به پردازش مقادیر بزرگ نخواهد بود. با این حال، فرستنده از بخش ها استفاده می کند سایز کوچکتر،از آنجایی که اندازه MTU در طول مسیر نیز برای اتصال تعیین می شود.

10.8.2 استفاده از فیلدهای هدر در درخواست اتصال

اولین بخش ارسال شده برای باز کردن یک اتصال دارای یک پرچم SYN 1 و یک پرچم ACK 0 است. SYN اولیه تنهابخشی که دارای یک فیلد ACK با مقدار 0 است. توجه داشته باشید که ابزارهای امنیتی از این ویژگی برای شناسایی درخواست های ورودی برای یک جلسه TCP استفاده می کنند.

رشته شماره سریالشامل شماره دنباله اولیه(شماره دنباله اولیه)، فیلد پنجره -اندازه اولیه پنجره دریافتتنها پارامتر TCP که در حال حاضر تعریف شده است حداکثر اندازه بخش است (در صورت عدم تعیین، مقدار پیش فرض 536 بایت استفاده می شود) که TCP انتظار دریافت آن را دارد. این مقدار 32 بیت را اشغال می کند و معمولاً در درخواست اتصال در فیلد وجود دارد گزینه ها(گزینه). هدر TCP حاوی مقدار MSS 24 بایت است.

10.8.3 استفاده از فیلدهای سرصفحه در پاسخ درخواست اتصال

در پاسخ اعطایی به درخواست اتصال، هر دو پرچم (SYN و ACK) برابر با 1 هستند. سیستم پاسخ دهنده شماره دنباله شروع را در فیلد مناسب و اندازه پنجره دریافت را در فیلد نشان می دهد. پنجره. حداکثر اندازهبخشی که گیرنده مایل به استفاده از آن است معمولاً در پاسخ به درخواست اتصال یافت می شود (در گزینه ها). این مقدار ممکن است با مقدار طرف درخواست کننده اتصال متفاوت باشد. ممکن است از دو مقدار متفاوت استفاده شود.

درخواست اتصال را می توان با تعیین یک پرچم بازنشانی (RST) با مقدار 1 در پاسخ رد کرد.

10.8.4 انتخاب شماره دنباله شروع

مشخصات TCP فرض می کند که در طول راه اندازی اتصال، هر طرف انتخاب می کند شماره دنباله اولیه(بر اساس مقدار فعلی تایمر داخلی 32 بیتی). چگونه این کار انجام می شود؟

بیایید تصور کنیم در صورت فروپاشی سیستم چه اتفاقی خواهد افتاد. بیایید فرض کنیم که کاربر درست قبل از خرابی یک اتصال را باز کرده و مقدار کمی داده ارسال کرده است. پس از بازیابی، سیستم دیگر هیچ کاری را که قبل از خرابی انجام شده، از جمله اتصالات از قبل شروع شده و شماره پورت های اختصاص داده شده، به خاطر نمی آورد. کاربر دوباره اتصال را برقرار می کند. شماره پورت‌ها با تخصیص‌های اصلی مطابقت ندارند و برخی از آنها ممکن است قبلاً توسط سایر اتصالات ایجاد شده چند ثانیه قبل از خرابی استفاده شوند.

بنابراین، طرف مقابل در انتهای اتصال ممکن است نداند که شریکش از کار افتاده و سپس بازیابی شده است. همه اینها منجر به نقص های جدی می شود، به ویژه زمانی که برای مدت طولانیتا زمانی که داده های قدیمی از طریق شبکه عبور کرده و با داده های اتصال تازه ایجاد شده مخلوط شوند. انتخاب تایمر شروع با به روز رسانی (شروع تازه) چنین مشکلاتی را از بین می برد. داده های قدیمی شماره گذاری متفاوتی نسبت به محدوده شماره دنباله اتصال جدید خواهند داشت. هکرها، هنگام جعل آدرس IP منبع برای یک میزبان مورد اعتماد، سعی می کنند با تعیین یک شماره توالی اولیه قابل پیش بینی در پیام، به رایانه ها دسترسی پیدا کنند. یک تابع هش رمزنگاری مبتنی بر کلیدهای داخلی ارائه می شود بهترین راهبرای انتخاب شماره های شروع محافظت شده

10.8.5 کاربردهای رایج فیلدها

هنگام آماده سازی هدر TCP برای انتقال، شماره دنباله ای از اکتت اول داده های ارسالی در فیلد نشان داده می شود. شماره سریال(شماره ترتیب).

تعداد اکتت بعدی مورد انتظار از شریک اتصال در فیلد وارد می شود تائیدیه(شماره تصدیق) هنگامی که بیت ACK روی 1 تنظیم شده است. فیلد پنجره(پنجره) برای اندازه فعلی پنجره دریافت کننده در نظر گرفته شده است. این فیلد شامل تعداد بایت ها از شماره تصدیق قابل دریافت. توجه داشته باشید که این مقدار امکان کنترل دقیق جریان داده را فراهم می کند. با استفاده از این مقدار، همتا وضعیت واقعی پنجره دریافت را در طول جلسه تبادل نشان می دهد.

اگر یک برنامه یک عملیات فشار را در TCP مشخص کند، پرچم PUSH روی 1 تنظیم می شود. TCP دریافت کننده باید به این پرچم پاسخ دهد. تحویل سریعداده ها به برنامه به محض اینکه فرستنده بخواهد آن را ارسال کند.

پرچم URGENT، زمانی که روی 1 تنظیم شود، به معنای انتقال داده فوری است و نشانگر مربوطه باید به آخرین اکتت داده فوری اشاره کند. یک استفاده معمولی از داده های فوری ارسال سیگنال های سقط یا قطع از ترمینال است.

داده های فوری اغلب نامیده می شود اطلاعات خارج از باند(خارج از گروه). با این حال، این اصطلاح نامشخص است. داده‌های فوری در جریان معمولی TCP ارسال می‌شوند، اگرچه پیاده‌سازی‌های فردی ممکن است مکانیسم‌های خاصی برای نشان دادن ورود داده‌های فوری به برنامه داشته باشند، و برنامه باید محتویات داده‌های فوری را قبل از رسیدن همه بایت‌های پیام بررسی کند.

هنگامی که اتصال باید به طور غیر عادی قطع شود، پرچم RESET روی 1 تنظیم می شود. هنگامی که قطعه ای می رسد که با هیچ یک از اتصالات TCP فعلی مرتبط نیست، همان پرچم در پاسخ تنظیم می شود.

پرچم FIN برای پیام های بسته شدن اتصال روی 1 تنظیم شده است.

10.8.6 Checksum

جمع کنترل IP فقط برای هدر IP است، در حالی که جمع چک TCP برای کل بخش و همچنین شبه سربرگ ایجاد شده از هدر IP محاسبه می شود. در طول محاسبه جمع کنترل TCP، فیلد مربوطه دارای مقدار 0 است. در شکل. شکل 10.15 یک شبه سربرگ را نشان می دهد که شباهت زیادی به آنچه در یک جمع کنترلی UDP استفاده می شود دارد.

برنج. 10.15.فیلد شبه هدر در جمع کنترلی TCP گنجانده شده است

طول TCP با اضافه کردن طول هدر TCP به طول داده ها محاسبه می شود. TCP checksum است اجباری، نه مانند UDP. جمع کنترلی یک بخش وارد شده ابتدا توسط گیرنده محاسبه می شود و سپس با محتویات فیلد جمع کنترل هدر TCP مقایسه می شود. اگر مقادیر مطابقت نداشته باشند، بخش کنار گذاشته می شود.

10.9 نمونه TCP Segment

برنج. 10.16، پروتکل عملیات آنالایزر اسنفراز Network General، دنباله ای از بخش های TCP است. سه بخش اول ارتباط بین مشتری و سرور را برقرار می کند شبکه راه دور. آخرین بخش 12 بایت داده را حمل می کند.

برنج. 10.16.نمایش هدر TCP توسط تحلیلگر Sniffer

تحلیلگر اسنفراکثر مقادیر را به فرم اعشاری تبدیل می کند. با این حال، مقادیر پرچم به صورت هگزادسیمال خروجی می شوند. یک پرچم با مقدار 12 نشان دهنده 010010 است. جمع کنترلی نیز به صورت هگزا دسیمال خروجی می شود.

10.10 پشتیبانی از جلسه

10.10.1 کاوش پنجره

یک فرستنده سریع و یک گیرنده کند می توانند یک پنجره دریافت با اندازه 0 بایت تشکیل دهند. این نتیجه نامیده می شود بستن پنجره(پنجره بسته). هنگامی که فضای خالی برای به روز رسانی اندازه پنجره دریافت در دسترس می شود، ACK استفاده می شود. با این حال، اگر چنین پیامی گم شود، هر دو طرف باید به طور نامحدود منتظر بمانند.

برای جلوگیری از این وضعیت، فرستنده تنظیم می کند تایمر قابل ذخیره(تایمر ماندگار) هنگام بستن پنجره موقت. مقدار تایمر مدت زمان ارسال مجدد است. پس از اتمام تایمر، یک بخش برای شریک ارسال می شود حسگر پنجره(کاوشگر پنجره؛ برخی از پیاده سازی ها شامل داده نیز می شوند). کاوش باعث می شود که همتا یک ACK ارسال کند که وضعیت فعلی پنجره را گزارش می کند.

اگر پنجره همچنان در اندازه صفر باقی بماند، مقدار تایمر ذخیره شده دو برابر می شود. این روند تا زمانی که تایمر به حداکثر 60 ثانیه برسد تکرار می شود. TCP به ارسال پیام های کاوشگر هر 60 ثانیه ادامه می دهد تا زمانی که پنجره باز شود، کاربر فرآیند را خاتمه دهد یا زمان برنامه به پایان برسد.

10.11 پایان دادن به یک جلسه

10.11.1 تایم اوت

شریک اتصال ممکن است به دلیل یک دروازه یا پیوند معیوب از کار بیفتد یا کاملاً قطع شود. برای جلوگیری از ارسال مجدد داده ها در TCP، مکانیسم های مختلفی وجود دارد.

زمانی که TCP به اولین آستانه ارسال مجدد می رسد، به IP می گوید که روتر خراب را بررسی کند و به طور همزمان به برنامه اطلاع می دهد که مشکلی وجود دارد. TCP به ارسال اطلاعات تا رسیدن به آستانه دوم قبل از آزاد کردن اتصال ادامه می‌دهد.

البته قبل از اینکه این اتفاق بیفتد، ممکن است یک پیام ICMP بیاید که نشان دهد مقصد به دلایلی غیرقابل دسترس است. در برخی از پیاده سازی ها، حتی پس از این، TCP به تلاش برای دسترسی به مقصد ادامه می دهد تا زمانی که فاصله زمانی منقضی شود (در این مرحله ممکن است مشکل برطرف شود). در مرحله بعد به برنامه اطلاع داده می شود که نقطه مقصد غیرقابل دسترسی است.

یک برنامه کاربردی می تواند تایم اوت خود را برای تحویل داده ها تنظیم کند و با پایان یافتن این بازه، عملیات خود را انجام دهد. معمولاً اتصال قطع می شود.

10.11.2 حفظ اتصال

هنگامی که یک اتصال ناقص داده هایی برای ارسال برای مدت طولانی داشته باشد، غیرفعال می شود. در طول یک دوره عدم فعالیت، ممکن است شبکه از کار بیفتد یا خطوط ارتباطی فیزیکی قطع شود. به محض اینکه شبکه دوباره عملیاتی شود، شرکا به تبادل داده ها بدون وقفه در جلسه ارتباط ادامه می دهند. این استراتژی مطابق با الزامات وزارت دفاع بود.

با این حال، هر اتصال - فعال یا غیرفعال - مقدار زیادی از حافظه رایانه را اشغال می کند. برخی از مدیران باید منابع استفاده نشده را به سیستم ها برگردانند. بنابراین، بسیاری از پیاده سازی های TCP قادر به ارسال پیامی در مورد آن هستند حفظ ارتباط(keep-live)، که اتصالات غیر فعال را آزمایش می کند. چنین پیام هایی به صورت دوره ای برای شریک ارسال می شود تا وجود آن در شبکه را بررسی کند. پاسخ باید پیام های ACK باشد. استفاده از پیام‌های نگهدارنده اختیاری است. اگر سیستم این قابلیت را داشته باشد، برنامه می تواند با استفاده از ابزار خود آن را لغو کند. دوره تخمینی پیش فرضمدت زمان نگهداری اتصال دو ساعت کامل است!

به یاد داشته باشید که یک برنامه می تواند تایمر خود را تنظیم کند، که بر اساس آن در سطح خود تصمیم می گیرد که آیا اتصال را قطع کند یا خیر.

10.12 کارایی

TCP چقدر کارآمد است؟ عملکرد منبع تحت تأثیر عوامل زیادی قرار می گیرد که اصلی ترین آنها حافظه و پهنای باند است (شکل 10.17 را ببینید).

برنج. 10.17.فاکتورهای عملکرد TCP

پهنای باند و تأخیر شبکه فیزیکی مورد استفاده به طور قابل توجهی توان عملیاتی را محدود می کند. کیفیت پایین ارسال اطلاعات منجر به حجم زیادی از دیتاگرام های دور ریخته شده می شود که باعث ارسال مجدد و در نتیجه کاهش کارایی پهنای باند می شود.

انتهای گیرنده باید فضای بافر کافی را فراهم کند تا به فرستنده اجازه دهد تا داده ها را بدون وقفه ارسال کند. این امر به ویژه برای شبکه های با تأخیر بالا، که در آن فاصله زمانی طولانی بین ارسال داده و دریافت ACK وجود دارد (و هنگام مذاکره در مورد اندازه پنجره) مهم است. برای حفظ یک جریان ثابت داده از منبع، انتهای دریافت کننده باید دارای پنجره ای حداقل به اندازه حاصلضرب پهنای باند و تأخیر باشد.

به عنوان مثال، اگر منبع می تواند داده ها را با سرعت 10000 بایت بر ثانیه ارسال کند و ACK 2 ثانیه طول می کشد تا برگردد، آنگاه طرف مقابل باید یک پنجره دریافتی با اندازه حداقل 20000 بایت ارائه دهد، در غیر این صورت جریان داده نخواهد بود. مستمر باشد یک بافر دریافت 10000 بایتی، توان عملیاتی را به نصف کاهش می دهد.

عامل مهم دیگر برای عملکرد، توانایی میزبان در پاسخگویی به رویدادهای با اولویت بالا و اجرای سریع است تغییر زمینه، یعنی برخی از عملیات ها را کامل کنید و به برخی دیگر تغییر دهید. میزبان می تواند به صورت تعاملی از چندین کاربر محلی پشتیبانی کند فرآیندهای پس زمینهو ده ها اتصال ارتباطی همزمان. سوئیچینگ زمینه به شما این امکان را می دهد که تمامی این عملیات را انجام دهید و در عین حال بار روی سیستم را پنهان کنید. پیاده سازی هایی که TCP/IP را با هسته سیستم عامل ادغام می کنند، می توانند به طور قابل توجهی بار استفاده از سوئیچینگ زمینه را کاهش دهند.

منابع پردازنده مرکزیکامپیوترها برای عملیات پردازش هدر TCP مورد نیاز هستند. اگر پردازنده نتواند به سرعت جمع‌های چک را محاسبه کند، این منجر به کاهش سرعت انتقال داده‌ها از طریق شبکه می‌شود.

علاوه بر این، توسعه دهندگان باید به دنبال ساده سازی پیکربندی تنظیمات TCP باشند تا مدیر شبکه بتواند آنها را مطابق با نیازهای محلی خود پیکربندی کند. به عنوان مثال، توانایی تنظیم اندازه بافر بر روی پهنای باند و تأخیر شبکه به طور قابل توجهی عملکرد را بهبود می بخشد. متاسفانه بسیاری از پیاده سازی ها به این موضوع توجه کافی ندارند و پارامترهای ارتباطی را به شدت برنامه ریزی می کنند.

بیایید فرض کنیم که محیط شبکه عالی است: منابع کافی وجود دارد و تعویض زمینه سریعتر از گاوچران هایی که هفت تیرشان را بیرون می آورند انجام می شود. آیا عملکرد عالی حاصل خواهد شد؟

نه همیشه. کیفیت توسعه نرم افزار TCP نیز مهم است. در طول سال ها، بسیاری از مشکلات عملکرد در پیاده سازی های مختلف TCP تشخیص داده شده و حل شده است. می توان فرض کرد که بهترین خواهد بود نرم افزار، مطابق با RFC 1122 است که الزامات لایه ارتباطی هاست اینترنت را تعریف می کند.

به همان اندازه مهم استثنا است و استفاده از الگوریتم های Jacobson، Kern و Partridge (این الگوریتم های جالب در زیر مورد بحث قرار خواهند گرفت).

توسعه‌دهندگان نرم‌افزار می‌توانند با ایجاد برنامه‌هایی که انتقال‌های غیرضروری مقادیر کم داده را حذف می‌کنند و دارای تایمرهای داخلی به منابع شبکه رایگانی هستند که در حال حاضر استفاده نمی‌شوند، مزایای قابل توجهی کسب کنند.

10.13 الگوریتم های بهبود عملکرد

در ادامه برای آشنایی با بخش نسبتاً پیچیده TCP، مکانیسم‌هایی را برای افزایش عملکرد و حل مشکلات با کاهش توان بررسی خواهیم کرد. این بخش در مورد مسائل زیر بحث می کند:

■ شروع آهسته(آهسته شروع) از استفاده از سهم بزرگ جلوگیری می کند ترافیک شبکهبرای یک جلسه جدید، که ممکن است منجر به سربار شود.

■ درمان از سندرم "پنجره ی بی خبر".(سندرم پنجره احمقانه) از بارگیری بیش از حد شبکه با پیام های برنامه های کاربردی با طراحی ضعیف جلوگیری می کند.

■ ACK با تاخیر(تأخیر ACK) با کاهش تعداد پیام‌های تأیید انتقال داده‌های مستقل، ازدحام را کاهش می‌دهد.

■ مهلت زمانی ارسال مجدد محاسبه شده(مدت زمانی ارسال مجدد محاسباتی) مبتنی بر مذاکره در مورد زمان جلسه واقعی است و میزان ارسال مجدد غیرضروری را کاهش می دهد، اما باعث تاخیر زیاد برای تبادل داده های واقعا ضروری نمی شود.

■ مهار ارسال TCP زمانی که اضافه بارهادر یک شبکه به روترها اجازه می دهد تا به حالت اصلی خود برگردند و منابع شبکه را در تمام جلسات به اشتراک بگذارند.

■ اعزام ACK های تکراری(ACK تکراری) هنگام دریافت یک قطعه خارج از توالی به همتایان اجازه می دهد قبل از وقفه زمانی دوباره ارسال کنند.

10.13.1 شروع آهسته

اگر همه لوازم برقی خانگی را همزمان در خانه روشن کنید، اضافه بار اتفاق می افتد. شبکه برق. در شبکه های کامپیوتری شروع آهستهاز منفجر شدن فیوزهای برق جلوگیری می کند.

یک اتصال جدید که فوراً شروع به ارسال مقدار زیادی داده در یک شبکه از قبل مشغول می کند می تواند منجر به مشکلاتی شود. ایده شروع آهسته این است که اطمینان حاصل شود که یک اتصال جدید با موفقیت راه اندازی می شود در حالی که به آرامی نرخ انتقال داده را مطابق با بار واقعی شبکه افزایش می دهد. فرستنده توسط اندازه پنجره بارگیری محدود می شود، نه با پنجره دریافت بزرگتر.

پنجره بارگذاری(پنجره ازدحام) با اندازه 1 قسمت شروع می شود. برای هر بخش با ACK دریافت شده با موفقیت، اندازه پنجره بارگیری 1 بخش افزایش می یابد تا زمانی که از پنجره دریافت کوچکتر باقی بماند. اگر شبکه شلوغ نباشد، پنجره بارگذاری به تدریج به اندازه پنجره دریافت کننده خواهد رسید. در شرایط عادی حمل و نقل، اندازه این پنجره ها یکسان خواهد بود.

توجه داشته باشید که شروع آهسته آنقدرها هم کند نیست. بعد از اولین ACK، اندازه پنجره بار 2 سگمنت است و پس از دریافت موفقیت آمیز ACK برای دو سگمنت، اندازه می تواند به 8 سگمنت افزایش یابد. به عبارت دیگر، اندازه پنجره به طور تصاعدی افزایش می یابد.

بیایید فرض کنیم که به جای دریافت ACK، یک موقعیت زمانی رخ می دهد. رفتار پنجره بار در این مورد در زیر مورد بحث قرار گرفته است.

10.13.2 سندرم پنجره بدون سرنخ

در اولین پیاده سازی TCP/IP، توسعه دهندگان با این پدیده مواجه شدند سندرم "پنجره ی بی خبر".(سندرم پنجره احمقانه - SWS)، که اغلب ظاهر می شود. برای درک رویدادهای در حال وقوع، سناریوی زیر را در نظر بگیرید که منجر به پیامدهای نامطلوب می شود، اما کاملاً ممکن است:

1. برنامه ارسال کننده داده ها را به سرعت ارسال می کند.

2. برنامه دریافت کننده 1 بایت داده را از بافر ورودی می خواند (یعنی به آرامی).

3. بافر ورودی پس از خواندن به سرعت پر می شود.

4. برنامه دریافت کننده 1 بایت را می خواند و TCP یک ACK به معنای "من فضای خالی برای 1 بایت داده دارم" ارسال می کند.

5. برنامه ارسال یک بسته TCP 1 بایتی را از طریق شبکه ارسال می کند.

6. TCP دریافت کننده یک ACK به معنای "متشکرم. من بسته را دریافت کردم و فضای خالی دیگری ندارم."

7. برنامه دریافت کننده دوباره 1 بایت را می خواند و یک ACK می فرستد و کل فرآیند تکرار می شود.

یک برنامه دریافت کند مدت زمان زیادی را منتظر می ماند تا داده ها برسد و دائماً اطلاعات دریافتی را به لبه سمت چپ پنجره فشار می دهد و یک عملیات کاملاً بی فایده را انجام می دهد که ترافیک اضافی را در شبکه ایجاد می کند.

موقعیت های واقعی، البته، چندان افراطی نیستند. یک فرستنده سریع و یک گیرنده آهسته، قطعات کوچک (نسبت به حداکثر اندازه بخش) داده را مبادله می کنند و روی یک پنجره تقریباً کامل دریافت می شوند. در شکل شکل 10.18 شرایط بروز سندرم "پنجره احمقانه" را نشان می دهد.

برنج. 10.18.پنجره دریافت بافر با فضای خالی بسیار کم

حل این مشکل کار سختی نیست. به محض اینکه پنجره دریافت به طول کمتر از اندازه هدف کاهش یابد، TCP شروع به فریب دادن فرستنده می کند. در این شرایط، TCP نباید به فرستنده نشان دهد اضافیفضای پنجره زمانی که برنامه دریافت کننده داده ها را از بافر در تکه های کوچک می خواند. در عوض، باید منابع آزاد شده را از فرستنده مخفی نگه دارید تا زمانی که تعداد کافی از آنها وجود داشته باشد. اندازه یک بخش توصیه می شود، مگر اینکه کل بافر ورودی یک بخش واحد را ذخیره کند (در مورد دوم، اندازه نیم بافر استفاده می شود). اندازه هدفی که TCP باید گزارش کند را می توان به صورت زیر بیان کرد:

حداقل (1/2 بافر ورودی، حداکثر اندازه بخش)

TCP زمانی شروع به دروغ گفتن می کند که اندازه پنجره از این اندازه کوچکتر شود و وقتی اندازه پنجره کمتر از مقدار بدست آمده از فرمول نباشد حقیقت را می گوید. توجه داشته باشید که هیچ آسیبی برای فرستنده وجود ندارد، زیرا برنامه دریافت کننده نمی تواند بسیاری از داده هایی را که انتظار دارد پردازش کند.

راه حل پیشنهادی را می توان به راحتی در موردی که در بالا بحث شد با خروجی ACK برای هر یک از بایت های دریافتی تأیید کرد. همین روش همچنین برای مواردی مناسب است که بافر ورودی می تواند چندین بخش را ذخیره کند (همانطور که اغلب در عمل انجام می شود). فرستنده سریع بافر ورودی را پر می کند، اما گیرنده نشان می دهد که فضای خالی برای قرار دادن اطلاعات ندارد و این منبع را تا زمانی که اندازه آن به کل بخش نرسد باز نمی کند.

10.13.3 الگوریتم ناگل

فرستنده باید مستقل از گیرنده، از ارسال بخش های بسیار کوتاه با جمع آوری داده ها قبل از ارسال اجتناب کند. الگوریتم Nagle یک ایده بسیار ساده را پیاده سازی می کند که به شما امکان می دهد تعداد دیتاگرام های کوتاه ارسال شده از طریق شبکه را کاهش دهید.

این الگوریتم توصیه می‌کند در حین انتظار برای ACK از داده‌های ارسال شده قبلی، ارسال داده‌ها (و هل دادن) به تأخیر بیفتد. داده های انباشته شده پس از دریافت ACK برای یک قطعه اطلاعات ارسال شده قبلی، یا پس از دریافت داده برای ارسال به مقدار یک بخش کامل، یا پس از اتمام یک بازه زمانی ارسال می شود. این الگوریتم نباید برای برنامه های بلادرنگ که نیاز به ارسال داده ها در سریع ترین زمان ممکن دارند استفاده شود.

10.13.4 ACK تاخیری

مکانیزم دیگر برای بهبود عملکرد، روش تاخیر ACK است. کاهش تعداد ACK ها، پهنای باندی را که می توان برای ارسال ترافیک دیگر استفاده کرد، کاهش می دهد. اگر همتا TCP ارسال ACK را اندکی به تأخیر بیندازد، پس:

■ چند بخش را می توان با یک ACK تایید کرد.

■ برنامه دریافت کننده قادر است مقداری داده را در بازه زمانی بازه زمانی دریافت کند، یعنی. ACK می تواند شامل سرصفحه خروجی باشد و نیازی به تولید پیام جداگانه ندارد.

برای جلوگیری از تأخیر در هنگام ارسال یک جریان از بخش های تمام طول (به عنوان مثال، هنگام تبادل فایل)، حداقل باید برای هر بخش کامل دیگر یک ACK ارسال شود.

بسیاری از پیاده سازی ها از 200 میلی ثانیه تایم اوت استفاده می کنند. اما ACK تاخیری باعث کاهش نرخ ارز نمی شود. وقتی یک بخش کوتاه می رسد، هنوز فضای خالی کافی در بافر ورودی برای دریافت داده های جدید وجود دارد و فرستنده می تواند به ارسال ادامه دهد (علاوه بر این، ارسال مجدد معمولاً بسیار کندتر است). اگر یک بخش کامل رسید، باید در همان ثانیه با یک پیام ACK به آن پاسخ دهید.

10.13.5 مهلت ارسال مجدد

پس از ارسال قطعه، TCP یک تایمر تنظیم می کند و ورود ACK را نظارت می کند. اگر یک ACK در مدت زمان وقفه دریافت نشود، TCP قطعه (رله) را دوباره ارسال می کند. با این حال، مدت زمان استراحت چقدر باید باشد؟

اگر خیلی کوتاه باشد، فرستنده با ارسال بخش‌های غیرضروری که اطلاعات ارسال شده را کپی می‌کنند، شبکه را پر می‌کند. بازه زمانی بسیار زیاد از تعمیر سریع بخش هایی که در حین ارسال از بین می روند جلوگیری می کند و این امر باعث کاهش توان عملیاتی می شود.

چگونه زمان مناسبی را انتخاب کنیم؟ ارزش مناسب برای سرعت بالا شبکه محلی، برای اتصالات از راه دور با بازدیدهای زیاد مناسب نخواهد بود. این بدان معنی است که اصل "یک ارزش برای هر شرایط" به وضوح نامناسب است. علاوه بر این، حتی برای یک اتصال خاص موجود، شرایط شبکه ممکن است تغییر کند و تاخیر ممکن است افزایش یا کاهش یابد.

الگوریتم های Jacobson، Kern و Partridge (توضیح داده شده در مقالات ، ون جاکوبسون و بهبود برآورد زمان رفت و برگشت در پروتکل های حمل و نقل قابل اعتماد، کارن و پارتریج) به TCP اجازه می دهد تا با شرایط متغیر شبکه سازگار شود. این الگوریتم ها برای استفاده در پیاده سازی های جدید توصیه می شوند. در زیر به طور خلاصه به آنها نگاه می کنیم.

عقل سلیم حکم می‌کند که بهترین مبنای برای تخمین زمان مناسب برای یک اتصال خاص، نظارت است. زمان چرخه(زمان رفت و برگشت) به عنوان فاصله بین ارسال داده و دریافت تاییدیه دریافت آن.

راه حل های خوببرای کمیت های زیر را می توان از آمارهای پایه به دست آورد (شکل 10.19 را ببینید) که به محاسبه زمان وقفه کمک می کند. با این حال، نباید به میانگین ها تکیه کنید، زیرا بیش از نیمی از برآوردها بیشتر از میانگین آماری خواهند بود. با در نظر گرفتن چند نقطه پرت، می‌توانیم تخمین‌های بهتری به دست آوریم که توزیع نرمال را در نظر گرفته و زمان انتظار ارسال مجدد بیش از حد طولانی را کاهش می‌دهد.

برنج. 10.19.توزیع زمان چرخه

برای به دست آوردن تخمین های ریاضی رسمی انحرافات، نیازی به محاسبات زیاد نیست. می توانید از تخمین های نسبتاً تقریبی بر اساس قدر مطلق تفاوت بین آخرین مقدار و میانگین تخمین استفاده کنید:

آخرین انحراف = | آخرین چرخه - میانگین |

برای محاسبه مقدار زمان وقفه صحیح، عامل دیگری که باید در نظر گرفته شود، تغییر در زمان چرخه به دلیل شرایط فعلی شبکه است. آنچه در آخرین لحظه آنلاین اتفاق می افتد مهمتر از آن چیزی است که یک ساعت پیش رخ داده است.

بیایید فرض کنیم که میانگین چرخه را برای یک جلسه بسیار طولانی محاسبه می کنیم. اجازه دهید در ابتدا شبکه به آرامی بارگیری شود و ما 1000 مقدار کوچک را شناسایی کردیم، اما پس از آن ترافیک با افزایش قابل توجه تاخیر افزایش یافت.

به عنوان مثال، اگر 1000 مقدار میانگین آماری 170 واحد را به دست آورد، اما سپس 50 مقدار با میانگین 282 اندازه گیری شد، میانگین فعلی خواهد بود:

170×1000/1050 + 282×50/1050 = 175

یک مقدار معقول تر خواهد بود زمان چرخه هموار(Smoothed Round-Trip Time - SRTT)، که اولویت مقادیر بعدی را در نظر می گیرد:

SRTT جدید = (1 – α)×(SRTT قدیمی) + α×مقدار آخرین چرخه

مقدار α بین 0 و 1 است. الف را افزایش دهیدمنجر به تأثیر بیشتر زمان چرخه جاری بر میانگین هموار می شود. زیرا کامپیوترها می توانند به سرعت با جابجایی بر توان های 2 تقسیم شوند اعداد باینریدر سمت راست، α همیشه روی (1/2) n (معمولاً 1/8) تنظیم می شود، بنابراین:

SRTT جدید = 7/8× SRTT قدیمی + 1/8× زمان چرخه آخر

جدول 10.2 نحوه تنظیم فرمول SRTT را نشان می دهد ارزش حاضریک SRTT 230 زمانی که تغییر در شرایط شبکه منجر به افزایش تدریجی زمان چرخه می شود (با فرض اینکه هیچ وقفه ای رخ ندهد). مقادیر در ستون 3 به عنوان مقادیر ستون 1 برای ردیف بعدی جدول (یعنی مانند SRTT قدیمی) استفاده می شود.

جدول 10.2 محاسبه زمان چرخه هموار

SRTT قدیمی	آخرین RTT	(7/8)×(SRTT قدیمی) + (1/8)×(RTT)
230.00	294	238.00
238.00	264	241.25
241.25	340	253.59
253.59	246	252.64
252.64	201	246.19
246.19	340	257.92
257.92	272	259.68
259.68	311	266.10
266.10	282	268.09
268.09	246	265.33
265.33	304	270.16
270.16	308	274.89
274.89	230	269.28
269.28	328	276.62
276.62	266	275.29
275.29	257	273.00
273.00	305	277.00

اکنون مسئله انتخاب یک مقدار برای مهلت ارسال مجدد مطرح می شود. تجزیه و تحلیل مقادیر زمان چرخه انحراف قابل توجهی از این مقادیر را از مقدار متوسط فعلی نشان می دهد. منطقی است که برای بزرگی انحرافات حدی تعیین کنیم. یک مقدار خوب برای مهلت ارسال مجدد (در استانداردهای RFC به این مقدار باز ارسال TimeOut - RTO گفته می شود) با فرمول زیر با محدودیت انحراف هموار (SDEV) داده می شود:

T = مهلت ارسال مجدد = SRTT + 2×SDEV

T = SRTT + 4×SDEV

برای محاسبه SDEV، ابتدا مقدار مطلق انحراف فعلی را تعیین کنید:

DEV = | زمان آخرین چرخه - SRTT قدیمی |

سپس از فرمول هموارسازی برای در نظر گرفتن مقدار دوم استفاده می شود:

SDEV جدید = 3/4× SDEV قدیمی + 1/4×DEV

یک سوال باقی می ماند - چه مقادیر اولیه را باید در نظر گرفت؟ توصیه شده:

تایم اوت اولیه = 3 ثانیه

SRTT اولیه = 0

SDEV اولیه = 1.5 ثانیه

ون جاکوبسون یک الگوریتم سریع تعریف کرد که زمان باز ارسال مجدد داده ها را بسیار کارآمد محاسبه می کند.

10.13.6 مثال آماری

تایم اوت محاسبه شده در بالا چقدر موفق خواهد بود؟ هنگامی که این مقدار اجرا شد، بهبود عملکرد قابل توجهی مشاهده شد. یک مثال می تواند آمار تیم باشد netstat، در سیستم دریافت شد ببر- یک سرور اینترنتی که میزبان های زیادی از سراسر جهان به آن دسترسی دارند.

1510769 بسته (314955304 بایت) به ترتیب دریافت شد

سیستم ببرکمتر از 2.5٪ از بخش های داده TCP دوباره ارسال شد. برای یک و نیم میلیون بخش داده های ورودی (بقیه پیام های ACK خالص هستند)، تنها 0.6٪ تکرار شد. باید در نظر گرفت که سطح تلفات در داده های ورودی تقریباً با سطح بخش های خروجی مطابقت دارد. بنابراین، ترافیک ارسال مجدد بیهوده حدود 0.6٪ از کل ترافیک را تشکیل می دهد.

10.13.7 محاسبات پس از ارسال مجدد

فرمول های ارائه شده در بالا از زمان چرخه به عنوان فاصله بین ارسال یک بخش و دریافت تاییدیه دریافت آن استفاده می کنند. با این حال، فرض کنید که هیچ تاییدیه ای در بازه زمانی دریافت نشده و داده ها باید دوباره ارسال شوند.

الگوریتم کرن فرض می کند که در این حالت زمان چرخه نباید تغییر کند. مقدار زمان سیکل هموار فعلی و انحراف هموارمقادیر خود را تا زمانی که تأییدیه برای ارسال یک بخش خاص بدون ارسال مجدد آن دریافت شود، حفظ می کنند. از این مرحله به بعد، محاسبات بر اساس مقادیر ذخیره شده و اندازه گیری های جدید از سر گرفته می شود.

10.13.8 اقدامات پس از ارسال مجدد

اما قبل از دریافت تاییدیه چه اتفاقی می افتد؟ پس از ارسال مجدد، رفتار TCP به طور اساسی تغییر می کند، عمدتا به دلیل از دست دادن داده ها به دلیل ازدحام شبکه. بنابراین، پاسخ به ارسال مجدد داده ها به صورت زیر خواهد بود:

■ کاهش نرخ ارسال مجدد

■ با کاهش ترافیک کلی با ازدحام شبکه مبارزه کنید

10.13.9 ترمز نمایی

پس از ارسال مجدد، فاصله زمانی دو برابر می شود. با این حال، اگر تایمر دوباره سرریز شود، چه اتفاقی می‌افتد؟ داده ها دوباره ارسال می شود و دوره ارسال مجدد دوباره دو برابر می شود. این فرآیند نامیده می شود ترمز نمایی(بازگشت نمایی).

اگر خطای شبکه همچنان رخ دهد، دوره وقفه دو برابر می شود تا زمانی که به حداکثر مقدار از پیش تعیین شده (معمولاً 1 دقیقه) برسد. پس از یک بازه زمانی، فقط یک بخش می تواند ارسال شود. همچنین زمانی که مقدار از پیش تعیین شده برای تعداد انتقال داده بدون دریافت ACK فراتر رود، مهلت زمانی رخ می دهد.

10.13.10 کاهش ازدحام با کاهش داده های ارسال شده از طریق شبکه

کاهش حجم داده های ارسالی تا حدودی پیچیده تر از مکانیسم های مورد بحث در بالا است. شروع به کار می کند، درست مانند شروع آهسته که قبلاً ذکر شد. اما، از آنجایی که محدودیتی در سطح ترافیک تعیین شده است که در ابتدا می تواند منجر به مشکلات شود، سرعت تبادل در واقع به دلیل افزایش اندازه پنجره بار برای یک بخش کاهش می یابد. شما باید مقادیر مرزی را تنظیم کنید تا در واقع سرعت ارسال را کاهش دهید. ابتدا آستانه خطر محاسبه می شود:

مرز - حداقل 1/2 (پنجره بار فعلی، پنجره دریافت شریک)

اگر مقدار حاصل بیش از دو بخش باشد، به عنوان یک مرز استفاده می شود. در غیر این صورت، اندازه حاشیه به دو بخش تنظیم می شود. الگوریتم بازیابی کامل به موارد زیر نیاز دارد:

■ اندازه پنجره بارگذاری را روی یک بخش تنظیم کنید.

■ برای هر ACK دریافتی، اندازه پنجره بار را یک بخش افزایش دهید تا به مرز برسد (مثل مکانیزم شروع آهسته).

■ پس از آن، با هر ACK دریافت شده، مقدار کوچکتری به پنجره بار اضافه کنید، که بر اساس نرخ افزایش در هر بخش برای زمان چرخه انتخاب می شود (افزایش به صورت MSS/N محاسبه می شود، که در آن N اندازه پنجره بارگذاری است. در بخش ها).

سناریوی ایده آل می تواند نمایش ساده ای از نحوه عملکرد مکانیسم بازیابی ارائه دهد. بیایید فرض کنیم که پنجره دریافت شریک (و پنجره بار فعلی) اندازه 8 قسمت قبل از تشخیص زمان وجود داشت و مرز به عنوان 4 بخش تعریف شده بود. اگر برنامه دریافت کننده فوراً داده ها را از بافر بخواند، اندازه پنجره دریافت 8 بخش باقی می ماند.

■ 1 بخش ارسال می شود (پنجره بار = 1 بخش).

■ ACK دریافت شد - 2 بخش ارسال شد.

■ ACK برای 2 بخش دریافت شد - 4 بخش ارسال شد (به مرز رسید).

■ ACK برای 4 بخش دریافت شد. 5 بخش ارسال می شود.

■ ACK برای 5 بخش دریافت شد. 6 بخش ارسال می شود.

■ ACK برای 6 بخش دریافت شد. 7 بخش ارسال می شود.

■ ACK برای 7 بخش دریافت شد. 8 بخش ارسال می شود (پنجره بارگذاری مجدداً از نظر اندازه با پنجره دریافت کننده برابر است).

از آنجایی که ارسال مجدد زمان پایان نیاز به تایید دریافت تمام داده های ارسالی دارد، این روند تا زمانی ادامه می یابد که پنجره بارگذاری به اندازه پنجره دریافت شود. وقایع رخ داده در شکل نشان داده شده است. 10.20. اندازه پنجره به صورت تصاعدی افزایش می‌یابد، در طول دوره شروع آهسته دو برابر می‌شود و پس از رسیدن به مرز، به صورت خطی افزایش می‌یابد.

برنج. 10.20.محدود کردن سرعت حمل و نقل در هنگام ازدحام

10.13.11 ACK های تکراری

برخی از پیاده سازی ها از یک ویژگی اختیاری به نام استفاده می کنند سریع ارسال مجدد(انتقال مجدد سریع) - به منظور سرعت بخشیدن به ارسال مجدد داده ها در شرایط خاص. ایده اصلی آن شامل ارسال ACK های اضافی توسط گیرنده است که نشان دهنده شکاف در داده های دریافتی است.

هنگام دریافت یک قطعه نامرتب، گیرنده یک ACK را ارسال می کند که به بایت اول اشاره می کند گمشدهداده ها (شکل 10.21 را ببینید).

برنج. 10.21. ACK های تکراری

فرستنده بلافاصله داده ها را دوباره ارسال نمی کند زیرا IP به طور معمول می تواند داده ها را بدون دنباله ارسال به گیرنده برساند. اما هنگامی که چندین ACK داده تکراری اضافی دریافت می شود (به عنوان مثال، سه)، بخش از دست رفته بدون انتظار برای تکمیل مهلت زمانی ارسال می شود.

توجه داشته باشید که هر ACK تکراری دریافت یک بخش داده را نشان می دهد. چندین ACK تکراری نشان می دهد که شبکه قادر به ارائه مقدار کافی داده است و بنابراین بیش از حد بارگذاری نمی شود. به عنوان بخشی از الگوریتم کلی، کاهش کوچکی در اندازه پنجره بار زمانی انجام می شود که افزایش واقعی ترافیک شبکه وجود داشته باشد. در این مورد، فرآیند تغییر اندازه رادیکال هنگام بازیابی کار اعمال نمی شود.

طبق استاندارد نیازهای میزبان(الزامات میزبان) TCP باید همان شروع آهسته ای را که در بالا توضیح داده شد، هنگام خاموش کردن منبع انجام دهد. با این حال، این پیام هدفمند یا موثر نیست زیرا اتصال دریافت کننده پیام ممکن است ترافیک زیادی ایجاد نکند. مشخصات فعلی نیازهای روتر(نیازمندی های روتر) نشان می دهد که روترها نبایدارسال پیام در مورد سرکوب منبع

13/10/13 آمار TCP

در نهایت به پیام های آماری این تیم می پردازیم نت استات،برای دیدن بسیاری از مکانیسم های شرح داده شده در بالا در کار.

به بخش ها بسته گفته می شود.

879137 بسته داده (226966295 بایت)

21815 بسته داده (8100927 بایت) دوباره ارسال شد

ارسال مجدد.

132957 بسته فقط تأیید (104216 با تأخیر)

اجازه دهید به یک عدد بزرگ توجه کنیم

ACK با تاخیر

کاوشگر باز شدن پنجره

اندازه صفر

اینها پیام های SYN و FIN هستند.

762469 آک (برای 226904227 بایت)

سیگنال در مورد رسیدن بسته ها

خارج از ترتیب

1510769 بسته (314955304 بایت)

9006 بسته کاملاً تکراری (867042 بایت)

نتیجه تایم اوت با واقعی

تحویل داده

74 بسته با مقداری dup. داده (12193 بایت فریب خورده)

برای بهره وری بیشتر

برخی از داده‌ها مجدداً بسته‌بندی شدند تا در هنگام ارسال مجدد، بایت‌های اضافی اضافه شود.

13452 بسته بدون سفارش (2515087 بایت)

530 بسته (8551 بایت) داده پس از پنجره

شاید این داده ها بود

در پیام های صوتی گنجانده شده است.

402 بسته پس از بسته شدن دریافت شد

اینها تکرارهای بعدی هستند

در حال ارسال.

108 به دلیل چک‌سوم‌های بد کنار گذاشته شد

جمع چک TCP نامعتبر است.

0 برای فیلدهای آفست سرصفحه بد کنار گذاشته شد

7 به دلیل کوتاه بودن بسته حذف شد

14677 اتصال برقرار شد (از جمله پذیرش)

18929 اتصال بسته شد (شامل 643 قطره)

4100 اتصال جنینی قطع شد

572187 بخش rtt به روز شد (از 587397 تلاش)

تلاش‌های تغییر ناموفق

زمان چرخه، از آنجایی که ACK قبل از انقضای مهلت زمانی نرسیده است،

26 اتصال با مهلت زمانی rexmit قطع شد

متعاقب تلاش های ناموفق

ارسال مجدد، نشان دهنده قطع شدن اتصال است.

کاوش کردن تایم اوت ها

پنجره صفر

مهلت زمانی تأیید

اتصال شکسته

472 اتصال توسط Kealive قطع شد

10.14 مطابقت با الزامات توسعه دهنده

استاندارد کنونی TCP به پیاده‌سازی‌ها نیاز دارد که هنگام راه‌اندازی اولیه اتصال، کاملاً از رویه شروع آهسته پیروی کنند و از الگوریتم‌های Kern و Jacobson برای تخمین بازه زمانی ارسال مجدد داده‌ها و کنترل بار استفاده کنند. آزمایشات نشان داده است که این مکانیسم ها منجر به بهبود عملکرد قابل توجهی می شود.

چه اتفاقی می‌افتد وقتی سیستمی را نصب می‌کنید که کاملاً از این استانداردها پیروی نمی‌کند؟ قادر به ارائه عملکرد مناسب برای کاربران خود نخواهد بود و همسایه بدی برای سایر سیستم های موجود در شبکه خواهد بود و از بازیابی جلوگیری می کند. عملکرد عادیپس از ازدحام موقت و ایجاد ترافیک بیش از حد و در نتیجه حذف دیتاگرام ها.

10.15 موانع بهره وری

TCP انعطاف پذیری خود را با کار بر روی شبکه هایی با سرعت انتقال صدها یا میلیون ها بیت در ثانیه ثابت کرده است. این پروتکل در شبکه‌های محلی مدرن با توپولوژی‌های Ethernet، Token-Ring و Fiber Distributed Data Interface (FDDI) و همچنین برای لینک‌های ارتباطی با سرعت پایین یا اتصالات از راه دور (مشابه لینک‌های ماهواره‌ای) به نتایج خوبی دست یافته است.

TCP برای پاسخگویی به شرایط شدید مانند تراکم شبکه طراحی شده است. با این حال، در نسخه فعلیاین پروتکل دارای ویژگی هایی است که عملکرد را در فناوری های امیدوارکننده ای که پهنای باند صدها یا هزاران مگابایت ارائه می دهند، محدود می کند. برای درک مشکلات موجود، یک مثال ساده (هر چند غیر واقعی) را در نظر بگیرید.

فرض کنید که هنگام جابجایی یک فایل بین دو سیستم، می خواهید یک جریان مبادله پیوسته را تا حد امکان کارآمد انجام دهید. بیایید فرض کنیم که:

■ حداکثر اندازه قطعه گیرنده 1 کیلوبایت است.

■ پنجره دریافت - 4 کیلوبایت.

■ پهنای باند به شما امکان می دهد دو بخش را در 1 ثانیه ارسال کنید.

■ برنامه دریافت کننده داده ها را به محض ورود مصرف می کند.

■ پیام های ACK بعد از 2 ثانیه می رسند.

فرستنده قادر به ارسال مداوم داده ها است. از این گذشته، هنگامی که حجم اختصاص داده شده برای پنجره پر است، یک ACK می آید که امکان ارسال یک بخش دیگر را فراهم می کند:

بعد از 2 ثانیه:

دریافت ACK SEGMENT 1, Can SEGMENT 5.

دریافت ACK OF SEGMENT 2, Can SEGMENT 6.

دریافت ACK of SEGMENT 3, Can SEGMENT 7.

دریافت ACK OF SEGMENT 4, Can SEGMENT 8.

بعد از 2 ثانیه دیگر:

دریافت ACK OF SEGMENT 5, Can SEND SEGMENT 9.

اگر پنجره دریافت فقط 2 کیلوبایت بود، فرستنده مجبور می شد از هر دو ثانیه یک ثانیه قبل از ارسال داده های بعدی صبر کند. در واقع، برای نگهداری یک جریان پیوسته از داده ها، پنجره دریافت باید حداقل:

پنجره = پهنای باند × زمان چرخه

اگرچه مثال تا حدودی اغراق آمیز است (برای ارائه اعداد ساده تر)، یک پنجره کوچک می تواند در اتصالات ماهواره ای با تأخیر بالا مشکل ایجاد کند.

حال بیایید ببینیم که با اتصالات پرسرعت چه اتفاقی می افتد. به عنوان مثال، اگر پهنای باند و نرخ ارسال با 10 میلیون بیت در ثانیه اندازه‌گیری شود، اما زمان چرخه 100 میلی‌ثانیه (1/10 ثانیه) باشد، برای یک جریان پیوسته، پنجره دریافت باید حداقل 1000000 بیت را ذخیره کند. . 125000 بایت اما بیشترین عددی که می توان در فیلد هدر برای پنجره دریافت TCP نوشت 65536 است.

مشکل دیگر زمانی رخ می دهد که سرعت های بالاتبادل، از آنجایی که شماره سریال خیلی سریع تمام می شود. اگر اتصال می تواند داده ها را با سرعت 4 گیگابایت بر ثانیه انتقال دهد، شماره های دنباله باید در هر ثانیه به روز شوند. هیچ راهی برای تمایز بین دیتاگرام های تکراری قدیمی که با انتقال آنها در اینترنت از داده های جدید جدید بیش از یک ثانیه تاخیر داشتند، وجود نخواهد داشت.

تحقیقات جدید به طور فعال برای بهبود TCP/IP و حذف موانع ذکر شده در بالا در حال انجام است.

10.16 توابع TCP

این فصل بسیاری از توابع TCP را پوشش می دهد. موارد اصلی در زیر ذکر شده است:

■ارتباط پورت ها با اتصالات

■ اتصالات را با استفاده از تایید سه مرحله ای راه اندازی کنید

■ اجرای آهسته شروع برای جلوگیری از اضافه بار شبکه

■ تقسیم بندی داده ها در حین انتقال

■ شماره گذاری داده ها

■ پردازش بخش های تکراری ورودی

■ محاسبه چک سام ها

■ کنترل جریان داده از طریق پنجره دریافت و پنجره ارسال

■ پایان دادن به اتصال به شیوه ای تثبیت شده

■ قطع اتصال

■ ارسال داده های فوری

■ تایید مثبت ارسال مجدد

■ مدت زمان ارسال مجدد را محاسبه کنید

■ کاهش ترافیک برگشتی در هنگام ازدحام شبکه

■ سیگنال دادن به این که بخش ها از نظم خارج می شوند

■ احساس بسته شدن پنجره دریافت کننده

10.17 حالت TCP

یک اتصال TCP چندین مرحله را طی می کند: اتصال با تبادل پیام برقرار می شود، سپس داده ها ارسال می شود و سپس اتصال با تبادل پیام های خاص بسته می شود. هر مرحله در عملیات اتصال مربوط به یک مرحله خاص است وضعیتاین ارتباط نرم افزار TCP در هر انتهای اتصال به طور مداوم وضعیت فعلی طرف دیگر اتصال را کنترل می کند.

در زیر به طور خلاصه به انتقال حالت معمولی بین یک سرور و یک کلاینت که در انتهای مخالف یک اتصال قرار دارد نگاه خواهیم کرد. هدف ما ارائه شرحی جامع از همه حالت‌های ممکن هنگام ارسال داده نیست. در RFC 793 و سند آورده شده است نیازهای میزبان.

در طول برقراری اتصال، سرور و سرویس گیرنده از طریق توالی های مشابهی از حالت ها عبور می کنند. حالت های سرور در جدول 10.3 و حالت های سرویس گیرنده در جدول 10.4 نشان داده شده است.

جدول 10.3 توالی وضعیت سرور

وضعیت سرور	رویداد	شرح
بسته شد		حالت ساختگی قبل از شروع برقراری اتصال.
بسته شد	باز کردن غیرفعال توسط یک برنامه سرور.
گوش دادن (ردیابی)		سرور منتظر اتصال مشتری است.
گوش دادن (ردیابی)	سرور TCP SYN را دریافت کرده و یک SYN/ACK ارسال می کند.	سرور SYN را دریافت کرد و SYN/ACK را ارسال کرد. به انتظار ACK می رود.
SYN-RECEIVED	سرور TCP یک ACK دریافت می کند.
تاسیس (نصب شده)		ACK دریافت شد، اتصال باز است.

جدول 10.4 توالی حالت مشتری

اگر شرکا بخواهند به طور همزمان با یکدیگر ارتباط برقرار کنند (که بسیار نادر است)، هر یک از حالت های بسته، SYN-SENT، SYN-RECEIVED و ESTABLISHED عبور می کنند.

طرف های پایانی اتصال تا زمانی که یکی از طرفین شروع به کار کند در حالت ESTABLISHED باقی می مانند بستهاتصالات با ارسال بخش FIN. در طی یک بسته شدن عادی، طرفی که بسته شدن را آغاز می کند، از حالت های نشان داده شده در جدول 10.5 عبور می کند. شریک او از طریق حالات ارائه شده در جدول 10.6 می گذرد.

جدول 10.5 دنباله ای از حالت های طرف بسته شدن اتصال

بسته شدن ایالت های جانبی	رویداد	شرح
ایجاد	یک برنامه محلی درخواست می کند که اتصال بسته شود.
ایجاد	TCP FIN/ACK را ارسال می کند.
FIN-WAIT-1		طرف پایانی منتظر پاسخ شریک است. به شما یادآوری می کنیم که ممکن است داده های جدید همچنان از طرف شریک دریافت شود.
FIN-WAIT-1	TCP یک ACK دریافت می کند.
FIN-WAIT-2		طرف پایانی یک ACK از طرف همتا دریافت کرده است، اما هنوز FIN دریافت نکرده است. طرف بسته کننده هنگام پذیرش داده های ورودی منتظر FIN می شود.
	TCP FIN/ACK را دریافت می کند.
	ACK را ارسال می کند.
زمان انتظار		اتصال در یک حالت نامشخص حفظ می شود تا داده های تکراری یا FIN های تکراری که هنوز در شبکه وجود دارند بتوانند وارد یا دور ریخته شوند. دوره انتظار دو برابر حداکثر تخمین طول عمر بخش است.
بسته شده

جدول 10.6 دنباله ای از ایالات شریک پس از بسته شدن یک اتصال

وضعیت شریک	رویداد	شرح
ایجاد	TCP FIN/ACK را دریافت می کند.
نزدیک منتظر باشید		FIN رسید.
	TCP یک ACK ارسال می کند.
		TCP انتظار دارد که برنامه آن اتصال را ببندد. در این مرحله، برنامه ممکن است حجم نسبتا زیادی داده را ارسال کند.
	برنامه محلی بستن اتصال را آغاز می کند.
	TCP FIN/ACK را ارسال می کند.
آخرین تأیید		TCP منتظر ACK نهایی است.
آخرین تأیید	TCP یک ACK دریافت می کند.
بسته شده		تمام اطلاعات اتصال حذف شده است.

10.17.1 تجزیه و تحلیل وضعیت های اتصال TCP

تیم netstat -anبه شما امکان می دهد وضعیت اتصال فعلی را بررسی کنید. اتصالات در ایالت ها در زیر نشان داده شده است گوش دادن، راه اندازی، تاسیس، بسته شدنو زمان انتظار.

توجه داشته باشید که شماره پورت اتصال در انتهای هر آدرس محلی و خارجی درج شده است. می بینید که ترافیک TCP برای هر دو صف ورودی و خروجی وجود دارد.

Pro Recv-Q Send-Q آدرس محلی آدرس خارجی (ایالت)

Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD

Tcp 0 0 128.121.50.145.25 148.79.160.65.3368 تاسیس شد

Tcp 0 0 127.0.0.1.1339 127.0.0.1.111 TIME_WAIT

Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 تاسیس شد

Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 TIME_WAIT

Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 TIME_WAIT

Tcp 0 848 128.121.50.145.23 192.67.236.10.1050 تاسیس شد

Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 تاسیس شد

Tcp 0 0 128.121.50.145.1022 128.121.50.141.1017 تاسیس شد

Tcp 0 0 128.121.50.145.514 128.121.50.141.1020 CLOSE_WAIT

Tcp 0 1152 128.121.50.145.119 192.67.239.23.3572 تاسیس شد

Tcp 0 0 128.121.50.145.1070 192.41.171.5.119 TIME_WAIT

Tcp 579 4096 128.121.50.145.119 204.143.19.30.1884 تاسیس شد

Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 تاسیس شد

Tcp 0 53 128.121.50.145.119 192.67.236.218.2018 FIN_WAIT_1

Tcp 0 0 128.121.50.145.119 192.67.239.14.1545 تاسیس شد

10.18 یادداشت هایی در مورد پیاده سازی ها

از همان ابتدا، پروتکل TCP برای همکاری با تجهیزات شبکه از سازندگان مختلف طراحی شد. مشخصات TCP دقیقاً نحوه عملکرد ساختارهای پیاده سازی داخلی را مشخص نمی کند. این سوالات به توسعه دهندگان سپرده می شود که وظیفه دارند بهترین مکانیسم ها را برای هر پیاده سازی خاص پیدا کنند.

حتی RFC 1122 (سند نیازهای میزبان -الزامات میزبان) آزادی کافی برای تغییرات ایجاد می کند. هر یک از توابع پیاده سازی شده با سطح مشخصی از سازگاری مشخص شده اند:

■ مه (مجاز)

■ نباید

متأسفانه، گاهی اوقات محصولاتی وجود دارند که الزامات MUST را اجرا نمی کنند. در نتیجه، کاربران ناراحتی ناشی از کاهش عملکرد را تجربه می کنند.

برخی از شیوه های اجرایی خوب در استانداردها پوشش داده نشده است. به عنوان مثال، بهبود امنیت را می توان با محدود کردن استفاده از پورت های شناخته شده توسط فرآیندهای ممتاز در سیستم به دست آورد. سیستم عاملاین روش پشتیبانی می شود. برای بهبود عملکرد، پیاده‌سازی‌ها باید داده‌های ارسالی یا بازیابی شده را تا حد امکان کپی و جابه‌جا کنند.

رابط برنامه نویسی برنامه استاندارد تعریف نشده(و همچنین سیاست امنیتی)، به طوری که فضای آزاد برای آزمایش با مجموعه های مختلف ابزار نرم افزار وجود دارد. با این حال، این ممکن است منجر به استفاده از رابط های برنامه نویسی متفاوت در هر پلت فرم شود و اجازه نمی دهد نرم افزار کاربردی بین پلت فرم ها جابجا شود.

در واقع، توسعه دهندگان ابزارهای خود را بر اساس رابط برنامه نویسی Socket که از برکلی به عاریت گرفته شده است، قرار می دهند. اهمیت رابط نرم افزاری با ظهور WINSock (سوکت ویندوز) افزایش یافت، که منجر به گسترش برنامه های دسکتاپ جدید شد که می توانست بر روی هر رابط WINSock سازگار با پشته TCP/IP اجرا شود.

10.19 ادامه مطلب

استاندارد اصلی TCP در RFC 793 تعریف شده است. ارتقاء، تجدید نظر و الزامات سازگاری در RFC 1122 مورد بررسی قرار گرفته است. Kern و Partridge مقاله را منتشر کردند. بهبود برآوردهای رفت و برگشت در پروتکل های حمل و نقل قابل اعتماددر مجله مجموعه مقالات ACM SIGCOMM 1987.مقاله جیکوبسون پیشگیری و کنترل ازدحامدر ظاهر شد مجموعه مقالات کارگاه ACM SIGCOMM 1988. Jacobson همچنین چندین RFC را برای اصلاح الگوریتم‌های عملکرد منتشر کرد.

سرورهایی که این پروتکل ها را در شبکه شرکتی، یک آدرس IP، دروازه، ماسک شبکه، سرورهای نام و حتی یک چاپگر در اختیار مشتری قرار دهید. کاربران برای استفاده از شبکه نیازی به پیکربندی دستی هاست خود ندارند.

سیستم عامل QNX Neutrino پروتکل پیکربندی خودکار دیگری به نام AutoIP را پیاده سازی می کند که یک پروژه کمیته IETF است. پیکربندی خودکار. این پروتکل در شبکه های کوچک برای تخصیص آدرس های IP لینک محلی به هاست استفاده می شود. پروتکل AutoIP به طور مستقل آدرس IP را به صورت محلی برای پیوند، با استفاده از یک طرح مذاکره با میزبان های دیگر و بدون تماس با سرور مرکزی تعیین می کند.

با استفاده از پروتکل PPPoE

مخفف PPPoE مخفف Point-to-Point Protocol over Ethernet است. این پروتکل داده ها را برای انتقال از طریق یک شبکه اترنت با یک توپولوژی پل شده محصور می کند.

PPPoE مشخصاتی برای اتصال کاربران اترنت به اینترنت از طریق یک اتصال پهن باند، مانند یک خط مشترک دیجیتال اجاره ای، یک دستگاه بی سیم یا یک مودم کابلی است. استفاده از پروتکل PPPoE و یک مودم پهن باند اطلاعات محلی را در اختیار کاربران قرار می دهد شبکه کامپیوتریدسترسی احراز هویت فردی به شبکه های داده پرسرعت.

پروتکل PPPoE فناوری اترنت را با پروتکل PPP ترکیب می کند و به طور موثر برای هر کاربر یک اتصال جداگانه به یک سرور راه دور ایجاد می کند. کنترل دسترسی، حسابداری اتصال، و انتخاب ارائه دهنده خدمات برای کاربران تعیین می شود، نه میزبان. مزیت این روش این است که نه شرکت تلفن و نه ارائه دهنده خدمات اینترنتی مجبور به ارائه پشتیبانی خاصی برای این کار نیستند.

برخلاف اتصالات Dial-up، اتصالات DSL و مودم کابلی همیشه فعال هستند. از آنجا که اتصال فیزیکی به یک ارائه‌دهنده خدمات راه دور بین چندین کاربر به اشتراک گذاشته می‌شود، یک روش حسابداری مورد نیاز است که فرستنده‌ها و مقصد ترافیک را ثبت کرده و از کاربران هزینه دریافت کند. پروتکل PPPoE به کاربر و میزبان راه دوری که در یک جلسه ارتباطی شرکت می کنند اجازه می دهد تا آدرس های شبکه یکدیگر را طی یک تبادل اولیه به نام یاد بگیرند. تشخیص(کشف). هنگامی که یک جلسه بین یک کاربر فردی و یک میزبان راه دور (به عنوان مثال، یک ارائه دهنده خدمات اینترنتی) برقرار شد، می توان جلسه را برای اهداف تعهدی نظارت کرد. بسیاری از خانه‌ها، هتل‌ها و شرکت‌ها با استفاده از فناوری اترنت و پروتکل PPPoE، دسترسی عمومی به اینترنت را از طریق خطوط مشترک دیجیتالی فراهم می‌کنند.

اتصال از طریق پروتکل PPPoE از یک کلاینت و یک سرور تشکیل شده است. کلاینت و سرور با استفاده از هر رابطی که نزدیک به مشخصات اترنت باشد کار می کنند. این رابط برای صدور آدرس‌های IP به کلاینت‌ها و مرتبط کردن آن آدرس‌های IP با کاربران و در صورت تمایل، ایستگاه‌های کاری، به جای احراز هویت مبتنی بر ایستگاه کاری به تنهایی استفاده می‌شود. سرور PPPoE یک اتصال نقطه به نقطه برای هر مشتری ایجاد می کند.

راه اندازی یک جلسه PPPoE

برای ایجاد یک جلسه PPPoE، باید از این سرویس استفاده کنیدpppoed. مدولio-pkt-*nخدمات پروتکل PPPoE را ارائه می دهد. ابتدا باید بدویدio-pkt-*باراننده مناسب. مثال:

سفر از طریق پروتکل های شبکه

TCP و UDP هر دو پروتکل های لایه انتقال هستند. UDP یک پروتکل بدون اتصال با تحویل بسته بدون تضمین است. TCP (پروتکل کنترل انتقال) یک پروتکل اتصال گرا با تحویل بسته تضمینی است. ابتدا یک دست دادن (سلام. | سلام. | بیایید چت کنیم؟ | برویم.) وجود دارد که پس از آن ارتباط برقرار شده در نظر گرفته می شود. سپس بسته ها از طریق این اتصال به عقب و جلو فرستاده می شوند (مکالمه در حال انجام است) و بررسی می شود که آیا بسته به گیرنده رسیده است یا خیر. اگر بسته گم شده باشد، یا وارد شود، اما با چک جمع شکسته، دوباره ارسال شود ("تکرار، من نشنیدم"). بنابراین، TCP قابل اعتمادتر است، اما از نقطه نظر پیاده سازی پیچیده تر است و بر این اساس، به چرخه های ساعت / حافظه بیشتری نیاز دارد، که برای میکروکنترلرها کمترین اهمیت را ندارد. نمونه هایی از پروتکل های کاربردی که از TCP استفاده می کنند عبارتند از FTP، HTTP، SMTP و بسیاری دیگر.

TL; DR

HTTP (پروتکل انتقال ابرمتن) یک پروتکل کاربردی است که با آن سرور صفحاتی را به مرورگر ما ارسال می کند. HTTP در حال حاضر به طور گسترده استفاده می شود شبکه جهانی وببرای به دست آوردن اطلاعات از وب سایت ها تصویر یک لامپ روی یک میکروکنترلر با سیستم عامل را نشان می دهد که در آن رنگ ها از طریق مرورگر تنظیم می شوند.

پروتکل HTTP مبتنی بر متن و بسیار ساده است. در واقع، روش ارسال GET به این صورت است: ابزار netcatبه آدرس سرور محلی IPv6 با چراغ:

~$ nc fe80::200:e2ff:fe58:b66b%mazko 80<

روش HTTP معمولا یک کلمه انگلیسی کوتاه است که با حروف بزرگ نوشته می شود و به حروف بزرگ و کوچک حساس است. هر سرور باید حداقل از متدهای GET و HEAD پشتیبانی کند. علاوه بر روش های GET و HEAD، اغلب از روش های POST، PUT و DELETE استفاده می شود. روش GET برای درخواست محتویات یک منبع مشخص استفاده می شود، در مورد ما در اینجا GET /b HTTP/1.0 که مسیر /b مسئول رنگ (آبی) است. پاسخ سرور:

سرور HTTP/1.0 200 OK: Contiki/2.4 http://www.sics.se/contiki/ اتصال: بستن Cache-Control: no-cache, no-store, must-alidate Pragma: no-cache منقضی می شود: 0 Content- نوع: text/html Contiki RGB

قرمز خاموش است

سبز خاموش است

آبی روشن است

کد وضعیت (ما 200 داریم) بخشی از خط اول پاسخ سرور است. یک عدد صحیح سه رقمی است. رقم اول کلاس شرط را نشان می دهد. کد پاسخ معمولاً با یک عبارت توضیحی به زبان انگلیسی که با فاصله از هم جدا شده است، دنبال می شود که دلیل این پاسخ خاص را برای فرد توضیح می دهد. در مورد ما، سرور بدون خطا کار کرد، همه چیز خوب بود (OK).

درخواست و پاسخ هر دو حاوی سرصفحه هستند (هر خط یک فیلد سرصفحه جداگانه است، جفت نام و مقدار با یک دو نقطه از هم جدا می شود). سرصفحه ها با یک خط خالی پایان می یابند که پس از آن داده ها می توانند دنبال شوند.

مرورگر من از باز کردن آدرس IPv6 محلی امتناع می ورزد، بنابراین یک آدرس اضافی در سیستم عامل میکروکنترلر نوشته می شود و همان پیشوند نیز باید به رابط شبکه مجازی شبیه ساز اختصاص داده شود:

~$ sudo ip addr add abcd::1/64 dev mazko # linux ~$ netsh interface ipv6 set address mazko abcd::1 # windows ~$ curl http://

برنامه کلاینت-سرور در سوکت جریان TCP

مثال زیر از TCP برای ارائه جریان های بایت دو طرفه منظم و قابل اعتماد استفاده می کند. بیایید یک برنامه کامل بسازیم که شامل کلاینت و سرور باشد. ابتدا، نحوه ساخت یک سرور با استفاده از سوکت های جریان TCP و سپس یک برنامه مشتری برای آزمایش سرور خود را نشان می دهیم.

برنامه زیر سروری ایجاد می کند که درخواست های اتصال از کلاینت ها را دریافت می کند. سرور به صورت همزمان ساخته شده است، بنابراین، اجرای رشته مسدود می شود تا زمانی که سرور موافقت کند با مشتری ارتباط برقرار کند. این برنامه یک سرور ساده را نشان می دهد که به یک کلاینت پاسخ می دهد. کلاینت با ارسال پیامی به سرور اتصال را پایان می دهد .

سرور TCP

ایجاد ساختار سرور در نمودار عملکردی زیر نشان داده شده است:

در اینجا کد کامل برنامه SocketServer.cs آمده است:

// SocketServer.cs با استفاده از System; با استفاده از System.Text. با استفاده از System.Net؛ با استفاده از System.Net.Sockets. فضای نام SocketServer ( کلاس برنامه ( static void Main(string args) ( // تنظیم نقطه پایانی محلی برای سوکت IPHostEntry ipHost = Dns.GetHostEntry("localhost")؛ آدرس IPAddr = ipHost.AddressList، newipEndipdPoint(IPEndipdPoint; newipEndipdPoint 11000)؛ // یک سوکت Tcp/IP ایجاد کنید سوکت sListener = سوکت جدید (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp)؛ // سوکت را به نقطه پایانی محلی اختصاص دهید و به سوکت های ورودی گوش دهید (Bind) ipEndPoint)؛ sListener. Listen(10)؛ // شروع به گوش دادن برای اتصالات در حالی که (درست) (Console.WriteLine("در انتظار اتصال در پورت (0)"، ipEndPoint)؛ // برنامه متوقف می شود، در انتظار یک اتصال ورودی Socket handler = sListener.Accept()؛ string data = null؛ // منتظر شدیم تا کلاینت سعی کند به ما متصل شود بایت بایت = بایت جدید؛ int bytesRec = handler.Receive(بایت)؛ داده += رمزگذاری. UTF8.GetString(bytes, 0, bytesRec)؛ // نمایش داده ها در کنسول Console.Write("متن دریافتی: " + داده + "\n\n"); // ارسال پاسخ به کلاینت\ string reply = "با تشکر از درخواست در " + data.Length.ToString() + " کاراکترها"; بایت msg = Encoding.UTF8.GetBytes(پاسخ); handler.Send(msg); if (data.IndexOf(" ") > -1) ( Console.WriteLine ("سرور اتصال به کلاینت را قطع کرده است.")؛ break; ) handler.Shutdown(SocketShutdown.Both); handler.Close(); ) ) catch (Exception ex) ( Console.WriteLine (ex.ToString())؛ ) در نهایت ( Console.ReadLine(); ) ) )

بیایید ساختار این برنامه را بررسی کنیم.

اولین قدم این است که سوکت را روی یک نقطه پایانی محلی تنظیم کنید. قبل از باز کردن یک سوکت برای گوش دادن به اتصالات، باید یک آدرس نقطه پایانی محلی برای آن آماده کنید. یک آدرس سرویس TCP/IP منحصر به فرد با ترکیب آدرس IP میزبان با شماره پورت سرویس، که نقطه پایانی سرویس را ایجاد می کند، تعیین می شود.

کلاس Dns متدهایی را ارائه می دهد که اطلاعات مربوط به آدرس های شبکه پشتیبانی شده توسط یک دستگاه در شبکه محلی را برمی گرداند. اگر یک دستگاه LAN بیش از یک آدرس شبکه داشته باشد، کلاس Dns اطلاعات مربوط به تمام آدرس‌های شبکه را برمی‌گرداند و برنامه باید آدرس مناسب را برای ارائه از آرایه انتخاب کند.

بیایید با ترکیب اولین آدرس IP کامپیوتر میزبان که از متد Dns.Resolve() با شماره پورت به دست آمده، یک IPEndPoint برای سرور ایجاد کنیم:

IPHostEntry ipHost = Dns.GetHostEntry("localhost"); آدرس IP ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = جدید IPEndPoint(ipAddr, 11000);

در اینجا کلاس IPEndPoint نشان دهنده localhost در پورت 11000 است. در مرحله بعد، ما یک سوکت جریان با نمونه جدیدی از کلاس Socket ایجاد می کنیم. با تنظیم یک نقطه پایانی محلی برای گوش دادن به اتصالات، می توانیم یک سوکت ایجاد کنیم:

سوکت sListener = سوکت جدید (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);

انتقال آدرس خانوادهطرح های آدرس دهی را مشخص می کند که یک نمونه از کلاس Socket می تواند برای حل یک آدرس استفاده کند.

در پارامتر SocketTypeسوکت های TCP و UDP متفاوت هستند. در آن می توانید از جمله مقادیر زیر را تعریف کنید:

Dgram

از دیتاگرام پشتیبانی می کند. مقدار Dgram نیاز دارد که Udp برای نوع پروتکل و InterNetwork در پارامتر خانواده آدرس مشخص شود.

خام

از دسترسی به پروتکل حمل و نقل اساسی پشتیبانی می کند.

جریان

از سوکت های جریان پشتیبانی می کند. مقدار Stream نیاز دارد که Tcp برای نوع پروتکل مشخص شود.

سومین و آخرین پارامتر نوع پروتکل مورد نیاز برای سوکت را مشخص می کند. در پارامتر نوع پروتکلمی توانید مهمترین مقادیر زیر را مشخص کنید - Tcp، Udp، Ip، Raw.

مرحله بعدی باید اختصاص دادن سوکت با استفاده از روش باشد بستن(). هنگامی که یک سوکت توسط سازنده باز می شود، نامی به آن اختصاص داده نمی شود، فقط یک دسته رزرو می شود. متد Bind() برای اختصاص یک نام به سوکت سرور فراخوانی می شود. برای اینکه سوکت کلاینت یک سوکت جریان TCP را شناسایی کند، برنامه سرور باید سوکت خود را یک نام بگذارد:

SListener.Bind(ipEndPoint);

متد Bind() یک سوکت را به یک نقطه پایانی محلی متصل می کند. متد Bind() باید قبل از هر تلاشی برای فراخوانی متدهای Listen() و Accept() فراخوانی شود.

اکنون با ایجاد یک سوکت و مرتبط کردن نام با آن، می توانید با استفاده از روش به پیام های دریافتی گوش دهید گوش بده(). در حالت گوش دادن، سوکت به تلاش‌های اتصال ورودی گوش می‌دهد:

SListener.Listen(10);

پارامتر تعریف می کند جمع شدن، نشان دهنده حداکثر تعداد اتصالات منتظر در صف است. در کد بالا، مقدار پارامتر اجازه می دهد تا ده اتصال در صف جمع شود.

در حالت گوش دادن، باید آماده موافقت با ارتباط با مشتری باشید، که برای این روش از این روش استفاده می شود تایید کنید(). این روش یک اتصال کلاینت به دست می آورد و ارتباط نام کلاینت و سرور را تکمیل می کند. متد Accept() رشته برنامه فراخوانی را تا زمانی که یک اتصال برسد مسدود می کند.

متد Accept() اولین درخواست اتصال را از صف درخواست های معلق حذف می کند و یک سوکت جدید برای پردازش آن ایجاد می کند. اگرچه یک سوکت جدید ایجاد می‌شود، سوکت اصلی همچنان به گوش دادن ادامه می‌دهد و می‌تواند با چند رشته برای پذیرش درخواست‌های اتصال متعدد از مشتریان استفاده شود. هیچ برنامه سروری نباید سوکت گوش دادن را ببندد. باید در کنار سوکت های ایجاد شده توسط روش Accept برای پردازش درخواست های مشتری ورودی به کار خود ادامه دهد.

while (true) (Console.WriteLine("Waiting for a Connection on Port (0)"، ipEndPoint)؛ // برنامه در حین انتظار برای اتصال ورودی متوقف می شود. Socket handler = sListener.Accept();

هنگامی که سرویس گیرنده و سرور با یکدیگر ارتباط برقرار کردند، می توان پیام ها را با استفاده از روش ها ارسال و دریافت کرد ارسال()و دريافت كردن()سوکت کلاس

متد Send() داده های خروجی را به سوکت متصل می نویسد. متد Receive() داده های ورودی را در سوکت جریان می خواند. هنگام استفاده از یک سیستم مبتنی بر TCP، قبل از اجرای متدهای Send() و Receive() باید بین سوکت ها ارتباط برقرار شود. پروتکل دقیق بین دو نهاد ارتباطی باید از قبل تعریف شده باشد تا برنامه های کلاینت و سرور با ندانستن اینکه چه کسی باید ابتدا داده های خود را ارسال کند یکدیگر را مسدود نکنند.

هنگامی که تبادل داده بین سرور و کلاینت کامل شد، باید با استفاده از روش ها، اتصال را ببندید خاموش کردن ()و بستن():

Handler.Shutdown(SocketShutdown.Both); handler.Close();

SocketShutdown یک enum حاوی سه مقدار برای توقف است: هر دو- ارسال و دریافت داده ها توسط سوکت را متوقف می کند، دريافت كردن- سوکت را از دریافت اطلاعات متوقف می کند و ارسال- ارسال داده ها توسط سوکت را متوقف می کند.

سوکت با فراخوانی متد ()Close بسته می شود که ویژگی Connected سوکت را نیز روی false قرار می دهد.

کلاینت TCP

توابعی که برای ایجاد یک برنامه مشتری استفاده می شود کم و بیش شبیه به یک برنامه سرور است. همانند سرور، از روش‌های مشابهی برای تعیین نقطه پایانی، نمونه‌سازی سوکت، ارسال و دریافت داده‌ها و بستن سوکت استفاده می‌شود.