پروتکل TCP چیست؟ بررسی TCP Header با وایرشارک

پروتکل TCP چیست؟

TCP پروتکل پیچیده و با خصوصیات زیادی است؛ برای همین است که میتواند انتقال کامل و سالم داده به مقصد را تضمین کند. این پروتکل برای گارانتی تحویل دیتا به مقصد به این سه ویژگی نیاز دارد:

• TCP Delivery 

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

• TCP Error Correction and Detection

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

• TCP Data Segmentation

در صورتی که اندازه دیتا بیشتر از اندازه TCP MSS (Maximum Segment Size) که بصورت پیشفرض 1460 بایت است باشد، TCP آن را تکه تکه میکند تا سریعتر و بدون خرابی به کامپیوتر مقصد برسد. به هر تکه از دیتا و هدری که TCP به آن میچسباند TCP Data Segment گفته میشود. segmentها توسط این پروتکل در مقصد دوباره به هم میچسبند و به شکل اول بازسازی شده، تحویل برنامه کاربردی موردنظر میشوند. هر TCP Segment شماره ترتیب (Sequence Number) مخصوص به خود را دارد. به کمک Sequence Number است که کامپیوتر گیرنده میتواند بفهمد به چه ترتیبی باید تکه های دیتا را کنار هم بچسباند و آن را دوباره بازسازی و تحویل پروتکل برنامه کاربردی بدهد.

بررسی TCP Handshake

• شماره 1 در تصویر بالا اشاره به اولین TCP Packet از گفتگوی 3 مرحله ای TCP Handshake بین دو کامپیوتر با آدرس 192.168.1.6 به عنوان TCP Client و آدرس 79.127.127.70 به عنوان TCP Server میکند. در ارتباط اپلیکیشنهای TCP Base با یکدیگر ابتدا کلاینت با سرور هماهنگ میکند و مطمئن میشود که آیا سرور آمادگی دریافت دیتا را از کلاینت دارد یا ندارد. کلاینت تا از سرور چراغ سبز دریافت نکند اقدام به ارسال دیتا برای سرور نمیکند. ابتدا کلاینت با ارسال سیگنال TCP SYN سرور را صدا میزند. همانطور که در عکس بالا مشخص است کلاینت مقدار بیتی TCP SYN Flag را برابر با یک قرار میدهد، به این معنی که درخواست ایجاد یک اتصال برای ارسال دیتا دارم.

• شماره 2 در تصویر بالا به دومین TCP Segment از گفتگوی 3 مرحله ای TCP Handshake بین کلاینت و سرور اشاره میکند. سرور در پاسخ به TCP SYN دریافتی از کلاینت، اقدام به ارسال TCP Message با مقدار SYN و ACK با مقدار یک میکند؛ یعنی به کلاینت میگوید درخواستت را دریافت کردم، من هم موافق ایجاد اتصال هستم، پیامم موافقتم را گرفتی خبرم کن.

• شماره 3 در عکس بالا به سومین TCP Packet از TCP Handshake بین کلاینت و سرور اشاره میکند. وقتی کلاینت SYN و ACK را از سمت سرور دریافت میکند باید به سرور خبر بدهد پیام را دریافت کرده تا سرور اتصال TCP را نهایی کند و آماده دریافت دیتا از اپلیکیشن کلاینت و تحویل آن به اپلیکیشن سرور باشد؛ بنابراین در پاسخ به SYN و ACK دریافتی از سرور یک TCP ACK Message با مقدار یک برای آن ارسال میکند.

بررسی TCP Header

TCP Header شامل فیلدهای زیر است:

• TCP Source Port

اولین فیلد از TCP Header بنام Source Port و سایز آن 2 بایت است. برنامه کاربردی پروتکل TCP را صدا میزند و آدرس پورت خود را به پروتکل TCP اعلام میکند.

• TCP Destination Port

دومین فیلد از TCP Header بنام Destination Port و سایز آن 2 بایت است و به آدرس پورت برنامه کاربردی مقابل در کامپیوتر مقصد که گیرنده نهایی دیتا است اشاره میکند. 

• TCP Sequence Number

سومین فیلد از TCP Header بنام Sequence Number و سایز آن 4 بایت است و اشاره به TCP Segment Number میکند. وقتی پروتکل TCP دیتایی بزرگتر از 1460 بایت از اپلیکیشن دریافت میکند، آنها را به قطعه های کوچکتر تقسیم میکند و به هر قطعه از دیتا یک شماره ترتیب میدهد تا کامپیوتر مقصد بر اساس همین شماره ها بتواند دیتا را بازسازی و تحویل اپلیکیشن موردنظر بدهد. کیفیت و پهنای باند مسیرهای شبکه مثل هم نیستند. در شبکه اینترنت مسیرهای زیادی برای عبور ترافیک به سمت کامپیوتر مقصد وجود دارد و ممکن است هر TCP Segment از مسیر متفاوتی عبور کند و در نهایت تکه های دیتای مربوط به یک اپلیکیشن در زمانی متفاوت و بصورت پس و پیش به دست مقصد برسند؛ دراینصورت داده ها بر اساس همین Sequence Number قطعه های دیتا سر هم میشود.

• TCP Acknowledgement

چهارمین فیلد از TCP Header است و اندازه آن 4 بایت یا معادل 32 بیت است. وقتی TCP Destination ترافیک را از TCP Source دریافت میکند، پس از مطمئن شدن از دریافت بسته بصورت سالم و کامل باید به فرستنده خبر و تایید دریافت بسته را بدهد؛ اما کدام بسته؟

TCP Destination یا همان دریافت کننده بسته، TCP Sequence Number بسته دریافتی را در TCP Header میخواند تا در زمان ارسال پیام تایید دریافت سالم و کامل دیتا از TCP Source یا همان ارسال کننده دیتا، شماره TCP Acknowledgement را یک شماره بیشتر از Sequence Number بسته دریافتی قرار دهد. فرستنده دیتا نیز با دریافت پیام تایید و خواندن شماره TCP Ack آنرا منهای یک میکند تا شماره ترتیب دیتای ارسالی را بدست آورد و متوجه شود کدام بسته به سلامت به دست مقصد رسید تا آنرا از بافر حذف کند. 

• TCP Flags 

فیلد 6 بیتی Flag حاوی 6 پرچم 1 بیتی است که صفر یا یک بودن هر کدام از آنها عملکرد خاصی در کنترل جریان داده ایجاد میکند. برای مثال اگر مقدار باینری آخرین بیت (Fin Flag) برابر با 1 تنظیم شده باشد ماشین دریافت کننده متوجه میشود که ماشین فرستنده ارسال داده را به پایان رسانیده است.

این شش پرچم عبارت هستند از:

• • URG
•  
  • ACK
  • کامیپوتر دریافت کننده دیتا از این tcp flag استفاده میکند تا تایید دریافت اطلاعات را به فرستنده بدهد. همینطور در مرحله دوم tcp handshake کامپیوتر سرور در پاسخ به دریافت tcp syn برای کلاینت tcp ack و tcp syn برمیگرداند.
•  
  • PUSH
•  
  • RST
  •  
  • SYN
  • کامپیوتر کلاینت برای شروع ارتباط و ایجاد یک اتصال با کامپیوتر سرور از این tcp flag استفاده میکند. در اولین مرحله از tcp 3way handshake کامپیوتر tcp source اقدام به ارسال tcp syn با مقدار بیت برابر با یک میکند. در مرحله دوم نیز کامپیوتر سرور اقدام به ارسال پاسخ میکند و یک tcp syn و tcp ack برابر با مقدار بیت یک برای کلاینت بر میگرداند.
•  
  • FIN

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

• TCP Checksum

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

• شماره 1 در تصویر بالا به آدرس برنامه کاربردی کلاینت اشاره میکند. اپلیکیشن کلاینت در کامپیوتر مبدا به پروتکل TCP شماره 36470 را بعنوان آدرس درگاه ارتباطی خود با اپلیکیشن سرور اعلام میکند. بنابراین TCP میداند اگر دیتایی با شماره پورت مقصد 36470 دریافت کند باید آن را تحویل همین برنامه کاربردی دهد که آدرس پورتش برای اتصال با سرور موردنظر را به TCP شماره 36470 اعلام کرده است.

• شماره 2 در تصویر بالا به TCP Destination Port که مشخص کننده آدرس اپلیکیشن گیرنده دیتا در ماشین مقصد است اشاره میکند.

• شماره 3: پروتکل TCP دیتای دریافتی از لایه Session مدل OSI را قطعه قطعه (Segmentation) میکند. به هر قطعه یک Sequence Number اضافه میکند تا در ماشین مقصد تمام این قطعات بصورت مرتب و بدون خطا به همدیگر متصل شوند. شماره ترتیب این بسته توسط TCP Source عدد 680 تنظیم شده است. البته این شماره رو اپلیکیشن وایرشارک داره نمایش میده و همانطور که در خط بعدی مشخص است شماره واقعی که داخل پرانتز با کلمه raw مشخص شده، 532192366 است.

• شماره 4: به شماره Ack اشاره میکند که توسط وایرشارک عدد 213 تعیین شده ولی عدد واقعی آن در خط بعدی با کلمه raw داخل پرانتز مشخص شده است: 3526778619

• شماره 5: TCP Payload به مقدار سایز بسته های TCP با واحد بایت اشاره دارد که در تصویر بالا 170 بایت است.

• شماره 6: در اصطلاح و ادبیات پروتکل TCP اشاره به روشن بودن چراغ و یا بالا بودن پرچم PUSH و Ack دارد.

• شماره 7: به TCP Window Size اشاره دارد که در تصویر بالا شماره 501 تنظیم شده است.
• شماره 8: TCP Source یک عملیات پیچیده ریاضی بر روی دیتا انجام میدهد و یک مقدار عددی بدست میاورد که آن را در فیلد Checksum از هدر TCP قرار میدهد. TCP Destination هم همان عملیات ریاضی را بر روی بسته انجام میدهد و عدد Chescksum مبدا و مقصد را مقایسه میکند؛ اگر یکسان بودند یعنی دیتا بدون ایراد یا دستکاری به مقصد رسیده است و اگر نه یعنی بسته دستکاری شده یا در مسیر عبور از شبکه آسیب دیده است و باید دور انداخته شود.

مقایسه پروتکل های UDP  و TCP

TCP Protocol خصوصیات بیشتری نسبت به پروتکل UDP دارد؛ بنابراین اطلاعات بیشتری را نسبت به udp در هدر خود ثبت میکند. 20 بایت اندازه tcp header و 8 بایت اندازه udp header است و همین نشان میدهد که tcp نیاز به ثبت اطلاعات بیشتری در هدر دارد تا بتواند تحویل دیتا به مقصد را گارانتی کند؛ اما udp برعکس tcp علاقه ای به ارائه گارانتی تحویل دیتا به اپلیکیشن در کامپیوتر مقصد را ندارد؛ ولی در عوض قابلیت ارسال سریع دیتا به مقصد را دارد. این پروتکل برای سرعت ارسال بالا ساخته شده است. در هدر این پروتکل چیزی جز اطلاعات ضروری و قطعی برای یک تحویل زمانبندی شده وجود ندارد؛ درحالیکه tcp دارای مقدار زیادی اطلاعات در هدر خود است که برای پشتیبانی از خصوصیات گوناگونی شامل کنترل جریان، ترتیب، تایید و نیز توانایی باز انتقالی دیتا بکار می آیند.