المقدمة
تخيل إنك عايز تبعت رسالة مهمة لصاحبك. عندك طريقتين:
الطريقة الأولى (TCP):
- تتصل بيه تليفونياً
- تتأكد إنه سامعك
- تقوله الرسالة جملة جملة
- تتأكد إنه فهم كل جملة
- لو مفهمش حاجة، تعيدها
- في الآخر تقوله “خلصت”
الطريقة التانية (UDP):
- تبعتله رسالة واتساب
- من غير ما تستنى رد
- ممكن يشوفها، ممكن لأ
- ممكن توصل في الترتيب الصح، ممكن لأ
- إنت مش مهتم، بعتها وخلاص
الطريقة الأولى = TCP (موثوق، بس أبطأ) الطريقة التانية = UDP (سريع، بس مش مضمون)
TCP (Transmission Control Protocol)
التعريف
بروتوكول موثوق لنقل البيانات. بيضمن وصول كل البيانات بالترتيب الصحيح بدون أخطاء.
الخصائص الأساسية
✓ Connection-Oriented (محتاج اتصال قبل النقل)
✓ Reliable (موثوق - بيضمن الوصول)
✓ Ordered (البيانات بتوصل بالترتيب)
✓ Error Checking (كشف وتصليح الأخطاء)
✓ Flow Control (تنظيم السرعة)
✓ Congestion Control (تجنب الازدحام)
TCP Three-Way Handshake
قبل ما أي بيانات تنتقل، لازم يحصل “مصافحة” من 3 خطوات.
الخطوات

الشرح بالتفصيل
Step 1: SYN (Synchronize)
Client → Server:
"عايز أتصل بيك. رقمي التسلسلي هو 1000"
TCP Header:
SYN = 1
Sequence Number = 1000
Step 2: SYN-ACK
Server → Client:
"تمام، أنا موافق. رقمك 1000 وصلني، ورقمي هو 5000"
TCP Header:
SYN = 1
ACK = 1
Sequence Number = 5000
Acknowledgment Number = 1001 (يعني استلمت لحد 1000)
Step 3: ACK (Acknowledgment)
Client → Server:
"تمام، رقمك 5000 وصلني. يلا نبدأ"
TCP Header:
ACK = 1
Acknowledgment Number = 5001
مثال عملي - شوف الـ Handshake
# استخدم tcpdump
sudo tcpdump -i any port 80 -nn
# في Terminal تاني، اعمل Request
curl http://example.com
# النتيجة في tcpdump:
# Packet 1: Client → Server [SYN]
# Packet 2: Server → Client [SYN, ACK]
# Packet 3: Client → Server [ACK]
أو استخدم Wireshark وشوف بعينك:
1. 192.168.1.5 → 93.184.216.34 TCP 74 54321 → 80 [SYN] Seq=0
2. 93.184.216.34 → 192.168.1.5 TCP 74 80 → 54321 [SYN, ACK] Seq=0 Ack=1
3. 192.168.1.5 → 93.184.216.34 TCP 66 54321 → 80 [ACK] Seq=1 Ack=1
بنية TCP Segment

الحقول المهمة
1. Source & Destination Port
من أنهي برنامج لأنهي برنامج (مثلاً 54321 → 80).
2. Sequence Number
رقم تسلسلي لكل byte. يستخدم لترتيب البيانات.
Segment 1: Seq = 1000 (Bytes 1000-1499)
Segment 2: Seq = 1500 (Bytes 1500-1999)
Segment 3: Seq = 2000 (Bytes 2000-2499)
3. Acknowledgment Number
“استلمت لحد byte رقم X، ابعت اللي بعده”.
Client → Server: Seq=1000, Data: 500 bytes
Server → Client: Ack=1500 (يعني استلمت 1000-1499، عايز 1500)
4. TCP Flags
| Flag | الاسم | الوظيفة |
|---|---|---|
| SYN | Synchronize | بداية الاتصال |
| ACK | Acknowledgment | تأكيد الاستلام |
| FIN | Finish | إنهاء الاتصال |
| RST | Reset | إعادة تعيين (خطأ) |
| PSH | Push | أرسل البيانات فوراً |
| URG | Urgent | بيانات طارئة |
5. Window Size
كم byte يقدر المستقبل يستقبل (Flow Control).
Server → Client: Window=1000
يعني: "ابعتلي 1000 byte بس، مش أكتر دلوقتي"
6. Checksum
للتأكد إن البيانات مفيهاش أخطاء.
TCP في العمل
مثال: تحميل ملف
1. Client → Server: "عايز file.zip" [SYN]
2. Server → Client: "تمام" [SYN-ACK]
3. Client → Server: "يلا ابدأ" [ACK]
═══ Connection Established ═══
4. Server → Client: [Bytes 0-1499] Seq=0
5. Client → Server: "وصل" Ack=1500
6. Server → Client: [Bytes 1500-2999] Seq=1500
7. Client → Server: "وصل" Ack=3000
8. Server → Client: [Bytes 3000-4499] Seq=3000
... (يكمل لحد الملف يخلص)
9. Client → Server: "شكراً، خلصت" [FIN]
10. Server → Client: "تمام" [ACK]
11. Server → Client: "أنا كمان خلصت" [FIN]
12. Client → Server: "باي" [ACK]
═══ Connection Closed ═══
لو في أي Segment ضاع:
Server → Client: [Bytes 1500-2999] Seq=1500
(الـ Segment يضيع في الطريق)
Client: (ينتظر... timeout)
Client → Server: "فين Seq=1500؟" (Duplicate ACK)
Server: "آه، سوري" → يعيد بعت Seq=1500
UDP (User Datagram Protocol)
التعريف
بروتوكول بسيط وسريع لنقل البيانات. مش بيضمن الوصول ولا الترتيب.
الخصائص الأساسية
✓ Connectionless (مفيش اتصال مسبق)
✗ Unreliable (مش موثوق)
✗ Unordered (ممكن يوصل مش مرتب)
✓ Fast (سريع جداً)
✓ Simple (بسيط)
✓ Low Overhead (حجم Header صغير)
بنية UDP Datagram

ملاحظة: UDP Header بس 8 bytes! (TCP Header على الأقل 20 bytes)
الحقول
- Source Port: المنفذ المرسل
- Destination Port: المنفذ المستقبل
- Length: طول الـ Datagram كله
- Checksum: (اختياري) للتحقق من الأخطاء
- Data: البيانات
UDP في العمل
مثال: DNS Query
Client → DNS Server:
"فين google.com؟" (UDP packet واحد)
DNS Server → Client:
"ده 142.250.185.46" (UDP packet واحد)
خلاص! مفيش Handshake، مفيش ACKs، مفيش تعقيدات.
مثال عملي
# شوف DNS Query باستخدام UDP
sudo tcpdump -i any port 53 -nn
# في Terminal تاني
dig google.com
# النتيجة:
# Packet 1: Client → DNS [UDP] Query: google.com
# Packet 2: DNS → Client [UDP] Answer: 142.250.185.46
المقارنة الشاملة
| Feature | TCP | UDP |
|---|---|---|
| Connection | Needed | Not needed |
| Reliability | Guaranteed | Best effort |
| Ordering | Yes | No |
| Speed | Slower | Faster |
| Header Size | 20–60 bytes | 8 bytes |
| Error Recovery | Yes (Retrans) | No |
| Flow Control | Yes | No |
| Congestion Control | Yes | No |
| Use Case | Reliability | Speed |
متى تستخدم TCP؟
✓ نقل الملفات (FTP, HTTP)
✓ البريد الإلكتروني (SMTP, POP3, IMAP)
✓ تصفح المواقع (HTTP, HTTPS)
✓ SSH, Telnet
✓ Database Connections
✓ أي حاجة محتاجة تأكد إن البيانات وصلت كاملة
القاعدة: لو البيانات مهمة ولازم توصل كاملة → استخدم TCP.
متى تستخدم UDP؟
✓ DNS Queries
✓ DHCP
✓ Video Streaming (YouTube, Netflix)
✓ Voice Calls (VoIP, Zoom)
✓ Online Gaming
✓ Live Broadcasting
✓ IoT Sensors
✓ TFTP (Trivial FTP)
✓ أي حاجة محتاجة سرعة والبيانات الضايعة مش مشكلة كبيرة
القاعدة: لو السرعة أهم ولو في بيانات ضاعت مش مشكلة → استخدم UDP.
أمثلة تفصيلية
1. Video Streaming (UDP)
Frame 1: ████████████ ✓ Arrived
Frame 2: ████████████ ✗ Lost
Frame 3: ████████████ ✓ Arrived
Frame 4: ████████████ ✓ Arrived
Frame 5: ████████████ ✓ Arrived
Result: فريم واحد ضاع، هتشوف glitch صغير
لكن الفيديو مش هيوقف
لو كان TCP:
Frame 1: وصل ✓
Frame 2: ضاع ✗
(الفيديو يوقف وينتظر Frame 2)
Frame 2: يعاد إرساله ✓
Frame 3: وصل ✓
...
Result: الفيديو هيقف كتير (Buffering)
2. File Download (TCP)
Byte 0-999: ████████████ ✓
Byte 1000-1999: ████████████ ✗ Lost
Byte 2000-2999: ████████████ ✓ (Wait...)
Byte 1000-1999: ████████████ ✓ Retransmitted
Byte 3000-3999: ████████████ ✓
Result: الملف يوصل كامل 100% صحيح
لو كان UDP:
Byte 0-999: ✓
Byte 1000-1999: ✗ Lost
Byte 2000-2999: ✓
Byte 3000-3999: ✓
Result: الملف فاسد (corrupted)
3. DNS Query (UDP)
Client: "فين google.com؟"
DNS: "ده 142.250.185.46"
Time: 20ms
لو ضاع:
Client: (Timeout) يعيد السؤال
DNS: "ده 142.250.185.46"
Time: 40ms (extra 20ms)
Still fast!
لو كان TCP:
Client → DNS: [SYN]
DNS → Client: [SYN-ACK]
Client → DNS: [ACK]
Client → DNS: "فين google.com؟"
DNS → Client: "ده 142.250.185.46"
Client → DNS: [ACK]
Client → DNS: [FIN]
DNS → Client: [ACK]
DNS → Client: [FIN]
Client → DNS: [ACK]
Time: 60-80ms
Slow for a simple query!
خلاصة
TCP
✓ Reliable (موثوق)
✓ Ordered (مرتب)
✓ Error Recovery (يصلح الأخطاء)
✗ Slower (أبطأ)
✗ More Overhead (حجم أكبر)
Use When: البيانات لازم توصل كاملة وصحيحة
Examples: HTTP, FTP, Email, SSH
UDP
✓ Fast (سريع)
✓ Simple (بسيط)
✓ Low Overhead (حجم صغير)
✗ Unreliable (مش مضمون)
✗ No Ordering (مش مرتب)
Use When: السرعة أهم من الدقة
Examples: DNS, DHCP, Streaming, Gaming
القرار
هل البيانات لازم توصل 100% صحيحة؟
├─ Yes → TCP
└─ No → هل السرعة مهمة؟
├─ Yes → UDP
└─ No → TCP برضه (أأمن)
من ناحية السيكيورتي
TCP:
- SYN Flood
- Session Hijacking
- TCP Reset
UDP:
- UDP Flood
- Amplification Attacks
- Spoofing (أسهل)
الدفاع: Firewall + Rate Limiting + Encryption
في المقالات الجاية هنتعمق في البروتوكولات المبنية على TCP/UDP وإزاي نستغلها ونحميها.