TCP، UDP و پورت شبکه چه تفاوتی دارند؟

IP مشخص می‌کند بسته به کدام آدرس شبکه فرستاده شود؛ پورت در کنار پروتکل و اطلاعات اتصال، به سیستم‌عامل کمک می‌کند آن را به ارتباط برنامه مربوط برساند. TCP و UDP از شماره پورت ۱۶ بیتی، در محدوده صفر تا ۶۵۵۳۵، استفاده می‌کنند. همه این شماره‌ها معنای یکسان یا کاربرد عمومی یکسان ندارند؛ صفر برای سرویس معمول انتخاب نمی‌شود.

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

اگر خود آدرس و نقش دروازه هنوز روشن نیست، راهنمای IP، Subnet و Gateway پیش‌زمینه این بحث است.

فرض کنید مرورگر کامپیوتر 192.168.10.20 به سرویس وب داخلی 192.168.10.50 با TCP روی پورت 443 وصل می‌شود. در این مثال فرضی، سیستم‌عامل برای سمت کاربر پورت موقت 53024 را انتخاب کرده است. پس یک سر ارتباط 192.168.10.20:53024 و سر دیگر 192.168.10.50:443 است.

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

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

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

UDP نیز به معنی داده بی‌ارزش یا حتماً خراب نیست. تفاوت این است که خود این لایه، برای بازیابی پیام گم‌شده و تحویل مرتب همان سازوکار TCP را ارائه نمی‌کند. طراح برنامه تعیین می‌کند چه چیزی باید دوباره ارسال یا کنار گذاشته شود.

UDP سازوکار آغاز و ارسال مجدد TCP را در خود ندارد؛ این ویژگی برای بعضی ارتباط‌های حساس به تأخیر مفید است. مثلاً در صدای زنده، رسیدن خیلی دیر یک بخش صدا ممکن است دیگر ارزش پخش نداشته باشد. اما نتیجه به طراحی برنامه، مسیر شبکه، ازدحام و مدیریت افت بسته بستگی دارد؛ نام UDP تضمین سرعت بیشتر نیست.

یک نمونه مهم HTTP/3 است: روی QUIC کار می‌کند و QUIC از UDP استفاده می‌کند، درحالی‌که تحویل قابل اتکا و مرتب در هر جریان را فراهم می‌سازد. بنابراین گزاره «وب همیشه TCP است» یا «هر برنامه UDP داده گم‌شده را رها می‌کند» دقیق نیست.

DNS معمولی هم می‌تواند از UDP یا TCP استفاده کند و پیاده‌سازی عمومی آن باید هر دو را پشتیبانی کند. انتخاب پروتکل برای یک سرویس را از مستندات و تنظیم همان سرویس بگیرید، نه از یک جدول کوتاه کاربردها.

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

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

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

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

اگر موضوع شما رساندن یک اتصال از بیرون به سرویس داخلی است، NAT و Port Forwarding نقش ترجمه آدرس را توضیح می‌دهد. تنظیم تجهیزات نیز در خدمات پیکربندی شبکه قابل پیگیری است.