برنامه کلاینت-سرور در سوکت جریان TCP. برنامه نویسی شبکه - پشتیبانی از عملیات جلسه TCP

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

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

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

سرور 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)؛ // سوکت را به نقطه پایانی محلی اختصاص دهید و به سوکت های ورودی گوش دهید try.)ipinnds ; sListener. Listen(10)؛ // شروع به گوش دادن برای اتصالات در حالی که (درست) (Console.WriteLine("در انتظار اتصال در پورت (0)"، ipEndPoint)؛ // برنامه متوقف می شود، منتظر یک ورودی است. اتصال Socket handler = sListener.Accept()؛ string data = null; // منتظر مشتری بودیم که سعی می کرد با ما ارتباط برقرار کند بایت بایت = بایت جدید؛ int bytesRec = handler.Receive(bytes)؛ داده += Encoding.UTF8. GetString(bytes, 0, bytesRec)؛ // نمایش داده ها در کنسول Console.Write("دریافت شد text: " + data + "\n\n"); // ارسال پاسخ به کلاینت\ string reply = "با تشکر از درخواست در " + data.Length.ToString() + " کاراکترها"; بایت 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 از شما می خواهد که Udp را برای نوع پروتکل و InterNetwork را در پارامتر خانواده آدرس مشخص کنید.

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

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

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

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

SListener.Bind(ipEndPoint);

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

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

SListener.Listen(10);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. سرور مقدار دهی اولیه می شود و برای ارتباط با کلاینت ها آماده می شود (به این حالت Passive open – passive open می گویند).

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

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

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

5. سرویس گیرنده TCP با دریافت پیام SYN/ACK از سرور، ACK 3001 را پس می فرستد (اولین بایت داده ارسال شده توسط سرور باید با شماره 3001 باشد).

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

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

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

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

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

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

انتقال داده پس از تکمیل تایید ایجاد اتصال سه مرحله ای شروع می شود (شکل 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.از دست دادن داده و ارسال مجدد

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

آ:

ب:"خوب".

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

آ:"خوب".

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

آ:"من کار را تمام کردم. هیچ داده دیگری برای ارسال وجود ندارد."

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

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

آ:"خوب".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

برنج. 10.14.بخش TCP

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

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

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

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

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

مقدار MSS اعلام شده + 40 - (مجموع طول هدر TCP و IP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

170x1000/1050 + 282x50/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 محاسبه زمان چرخه هموار

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

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

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

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

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

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

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

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

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

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

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

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

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

مرز - حداقل 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.محدودیت نرخ پیشروی در هنگام ازدحام

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

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

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

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

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

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

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

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

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

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

ACK های تاخیری

سایز صفر

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

خارج از ترتیب

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

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

تحویل داده ها

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

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

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

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

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

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

در حال ارسال.

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

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

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

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

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

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

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

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

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

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

پنجره صفر

اتصال بیکار

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

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

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

TCP انعطاف پذیری خود را با کار بر روی شبکه هایی با نرخ باود صدها یا میلیون ها بیت در ثانیه ثابت کرده است. این پروتکل این امکان را فراهم کرده است نتایج خوبدر مدرن شبکه های محلیبا توپولوژی های اترنت، 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.

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

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

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

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

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

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

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

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

■ اولیه سازی اتصالات از طریق تایید سه مرحله ای

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

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

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

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

■ محاسبه چک

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

■ قطع اتصال راه تثبیت شده

■ قطع اتصال

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

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

■ محاسبه مهلت ارسال مجدد

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

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

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

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

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

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

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

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

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

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

جدول 10.5 دنباله حالت سمتی که اتصال را می بندد

جدول 10.6 توالی حالت شریک نزدیک اتصال

تیم 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 تاسیس شد

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

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

■ MAY (مجاز)

■ نباید

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

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

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

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

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

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

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

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

سبز خاموش است

آبی روشن است

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

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

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

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