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 نیاز دارد تا از ارسال داده ها به میزبان راه دور مطلع شود و این کار را فورا انجام دهد. در این مورد استفاده کنید بیرون ریختن(فشار دادن).

اگر به عملیات‌ها در یک جلسه تعاملی نگاه کنید، می‌توانید بخش‌های زیادی را با داده‌های کم پیدا کنید، و علاوه بر این، تقریباً در هر بخش از داده‌ها، برآمدگی‌ها یافت می‌شوند. با این حال، فشار نباید در حین انتقال فایل اعمال شود (به جز آخرین بخش)، و 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-Data	پورت ارسال اطلاعات 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 در قسمت sequence خواهد بود.

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 و پورت مشخص شده باز کند (به این حالت فعال open گفته می شود).

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

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

.

6. Client 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 بستن یک اتصال

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

آ:

ب:"خوب".

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

آ:"خوب".

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

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

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

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

آ:"خوب".

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

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

2. سرور TCP یک بخش نهایی (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 اندازه پنجره ارسال را به 4K بازیابی می کند.

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

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

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

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

10.8 سربرگ TCP

در شکل 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 (65 535 بایت) خواهد بود.

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 بخش

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

برنج. 10.16.نمایش سربرگ TCP توسط Sniffer Analyzer

تحلیلگر اسنفراکثر مقادیر را به اعشار ترجمه می کند. با این حال، مقادیر پرچم به صورت هگزادسیمال خروجی می شوند. پرچم با مقدار 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 قادر به ارسال پیامی در مورد آن هستند حفظ اتصال(زندگی نگه داشتن)، آزمایش اتصالات غیر فعال. چنین پیام هایی به صورت دوره ای برای شریک ارسال می شود تا وجود آن در شبکه تأیید شود. پیام های ACK باید در پاسخ دریافت شود. استفاده از پیام های نگهدارنده اختیاری است. اگر سیستم این قابلیت را داشته باشد، اپلیکیشن می تواند به وسیله خود آن را لغو کند. دوره تخمینی پیش فرضتایم اوت برای حفظ اتصال دو ساعت کامل است!

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

10.12 کارایی

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

برنج. 10.17.عوامل عملکرد TCP

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

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

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

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

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

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

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

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

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

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

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 قطعه (رله) را دوباره ارسال می کند. با این حال، مدت زمان استراحت چقدر باید باشد؟

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

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

الگوریتم های جاکوبسون، کرن و پارتریج (توضیح داده شده در مقالات ، ون جاکوبسون و بهبود برآورد زمان رفت و برگشت در پروتکل های حمل و نقل قابل اعتماد، کارن و پارتریج) به 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

اکنون مسئله انتخاب یک مقدار برای بازنشر مهلت زمانی مطرح می شود. تجزیه و تحلیل زمان های چرخه انحراف قابل توجهی از این مقادیر را از میانگین فعلی نشان می دهد. معقول است که برای بزرگی انحرافات (انحرافات) حد تعیین کنیم. مقادیر خوب برای مهلت ارسال مجدد (به نام Retransmission TimeOut - RTO در استانداردهای RFC) با فرمول زیر با محدودیت انحراف هموار (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 (پنجره بارگیری فعلی، پنجره دریافت شریک)

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

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

S برای هر 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 باید همان شروع آهسته ای را که در بالا توضیح داده شد، هنگام خاموش کردن منبع (منبع خاموش) انجام دهد. با این حال، گزارش این مورد هدفمند یا موثر نیست زیرا اتصالی که این پیام را دریافت می کند ممکن است ترافیک زیادی ایجاد نکند. مشخصات فعلی نیازهای روتر(نیازمندی های روتر) نشان می دهد که روترها نبایدارسال پیام در مورد سرکوب منبع

10.13.13 آمار TCP

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

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

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

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

ارسال مجدد

132957 بسته فقط ack (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 انعطاف پذیری خود را ثابت کرده است و در شبکه هایی با نرخ مبادله صدها یا میلیون ها بیت در ثانیه کار می کند. این پروتکل دستیابی به نتایج خوبی را در شبکه‌های محلی مدرن با توپولوژی‌های اترنت، Token-Ring و Fiber Distributed Data Interface (FDDI) و همچنین برای خطوط ارتباطی با سرعت کم یا اتصالات از راه دور (مانند لینک‌های ماهواره‌ای) ممکن کرده است. .

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

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

■ حداکثر اندازه بخش هدف 1 کیلوبایت است.

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

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

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

پیام های S ACK در 2 ثانیه می رسد.

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

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

دریافت تایید بخش 1، می تواند بخش 5 را ارسال کند.

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

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

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

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

دریافت ACK SEGMENT 5، Can SEGMENT 9.

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

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

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

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

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

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

10.16 توابع TCP

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

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

■ اولیه سازی اتصالات با تایید 3 مرحله ای

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

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

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

■ رسیدگی به بخش های تکراری ورودی

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

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

■ خاتمه اتصال به روش تعیین شده

■ قطع اتصال

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

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

■ محاسبه زمان بازنشر

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

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

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

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		طرف پوشش منتظر پاسخ شریک است. به یاد داشته باشید که ممکن است داده های جدید هنوز از طرف شریک دریافت شود.
	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 را اجرا نمی کنند. در نتیجه، کاربران با مشکلات کاهش عملکرد مواجه می شوند.

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

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

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

10.19 ادامه مطلب

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

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

سیستم عامل QNX Neutrino پروتکل plug-and-play دیگری به نام 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- نوع: متن / html

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

سبز خاموش است

آبی روشن است

کد وضعیت (ما 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 و سپس یک برنامه مشتری برای آزمایش سرور خود را نشان می دهیم.

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

سرور TCP

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

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

// SocketServer.cs با استفاده از System; با استفاده از System.Text. با استفاده از System.Net؛ با استفاده از System.Net.Sockets. فضای نام SocketServer (برنامه کلاس (خلأ ثابت Main (رشته آرگ) (// تنظیم نقطه پایانی محلی برای سوکت IPHostEntry ipHost = Dns.GetHostEntry ("localhost")؛ آدرس IPAddr = ipHost.AddressList =IPEndPoint, IPEndPoint new 11)؛ // ایجاد یک Tcp / Ip Socket sListener = سوکت جدید (ipAddr.AddressFamily، SocketType.Stream، ProtocolType.Tcp)؛ // سوکت را به نقطه پایانی محلی اختصاص دهید و به سوکت های ورودی گوش دهید (sListener.Bind) sListener. Listen (10)؛ // شروع به گوش دادن برای اتصالات در حالی که (درست) (Console.WriteLine ("در انتظار اتصال در پورت (0)"، ipEndPoint)؛ // برنامه متوقف می شود، منتظر اتصال ورودی است. Socket handler = sListener.Accept ()؛ string data = null; // منتظر مشتری بودیم که سعی می کرد با ما ارتباط برقرار کند بایت بایت = بایت جدید؛ int bytesRec = handler.Receive (بایت)؛ داده + = Encoding.UTF8.GetString (بایت، 0، بایت‌Rec)؛ // نمایش داده‌ها در کنسول Console.Write ("دریافت شد" متن: "+ داده +" \ n \ n "); // ارسال پاسخ به مشتری \ string reply = "با تشکر از درخواست در" + data.Length.ToString () + "characters"; بایت msg = Encoding.UTF8.GetBytes (پاسخ); handler.Send (msg); if (data.IndexOf (" ")> -1) (Console.WriteLine ("سرور اتصال به سرویس گیرنده را تمام کرده است."؛ شکست؛) 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 () سوکت را به نقطه پایانی محلی متصل می کند. قبل از هر تلاشی برای فراخوانی متدهای Listen () و Accept () باید متد Bind () را فراخوانی کنید.

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

SListener.Listen (10);

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

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

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

در حالی که (درست) (Console.WriteLine ("در انتظار اتصال در پورت (0)"، ipEndPoint)؛ // برنامه متوقف می شود و منتظر اتصال ورودی است. Socket handler = sListener.Accept ();

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

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

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

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

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

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

مشتری در TCP

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