أساسيات الشبكات لأي ديفيلوبر: من الـ IP لحد ما الصفحة تفتح

أساسيات الشبكات هي اللي بتخليك تعرف تبدأ منين لما موقعك ميفتحش، بدل ما تجرب أي حاجة بالعشوائي. تخيل الموقف ده: السيرفر شغال عندك على الجهاز، وأول ما حد تاني يجرب يفتحه تظهرله رسالة زي connection refused أو timed out أو ERR_NAME_NOT_RESOLVED. كل رسالة منهم معناها إن خطوة مختلفة في الطريق فشلت.

المقال ده بيشرح أساسيات الشبكات للمبرمجين: إيه اللي بيحصل بين إنك تكتب عنوان وتدوس Enter لحد ما الصفحة تفتح، وإزاي تعرف الخطوة اللي باظت.

الخلاصة في أربع نقط:

• كل رسالة خطأ في الشبكة بتشاور على خطوة معينة في الرحلة: DNS ثم IP وPort ثم TCP ثم TLS ثم HTTP.
• الـ IP هو عنوان الجهاز، والـ Port هو البرنامج اللي جواه، والـ DNS بيترجم الاسم لعنوان.
• connection refused معناها إن الجهاز بيرد بس مفيش برنامج على الـ Port، وtimed out معناها إن مفيش رد أصلاً.
• أوامر ping وnslookup وcurl -v بتخليك تشوف كل خطوة بنفسك.

المحتويات

• أولاً: أساسيات الشبكات: رحلة الطلب كاملة في نظرة واحدة
• ثانياً: عنوان الـ IP العام والخاص وlocalhost
• ثالثاً: الـ Port: رقم الشقة جوه العمارة
• رابعاً: الـ DNS: دفتر تليفونات الإنترنت
• خامساً: TCP وUDP
• سادساً: HTTP وHTTPS وTLS
• سابعاً: اللي في نص الطريق
• ثامناً: أوامر تجرب بيها كل خطوة بنفسك
• تاسعاً: لما حاجة تتعطل: الرسالة بتقولك الخطوة
• عاشراً: أخطاء شائعة هتقابلك

أولاً: أساسيات الشبكات: رحلة الطلب كاملة في نظرة واحدة

لما تكتب example.com في المتصفح وتدوس Enter، ده اللي بيحصل بالترتيب في أجزاء من الثانية.

1. المتصفح بيسأل الـ DNS: الاسم ده بيشاور على أنهي IP؟
2. بعد ما يعرف العنوان، بيحتاج Port يتكلم عليه (443 لو HTTPS).
3. بيفتح اتصال TCP مع السيرفر.
4. لو الموقع HTTPS، بيتفق مع السيرفر على تشفير (TLS).
5. بيبعت طلب HTTP، والسيرفر بيرد.
6. المتصفح بيعرض الرد. وفي نص الطريق ممكن يكون فيه firewall أو reverse proxy أو load balancer.

الأقسام الجاية بتاخد كل خطوة لوحدها، وفي الآخر هتلاقي إزاي كل رسالة خطأ بتقولك الخطوة اللي فشلت.

ثانياً: عنوان الـ IP العام والخاص وlocalhost

كل جهاز على الشبكة ليه عنوان IP، زي عنوان العمارة: بيقول للرسايل توصل فين. وفيه نوعين لازم تفرق بينهم.

• العنوان العام (Public IP): اللي الإنترنت بيشوفك بيه. السيرفرات على الكلاود بتاخد واحد، وأي حد يقدر يوصله.
• العنوان الخاص (Private IP): اللي جهازك واخده جوه شبكة البيت أو الشركة، زي 192.168.1.5 أو 10.0.0.4. العناوين دي ماشية جوه الشبكة المحلية بس، ومش بتتعرف على الإنترنت العام.

الراوتر عندك غالبًا واخد عنوان عام واحد، وكل الأجهزة اللي وراه بتشاركه عن طريق حاجة اسمها NAT. عشان كده تطبيقك الشغال على جهازك مش هيفتحه حد من برّه شبكتك، حتى لو عرف عنوانه، إلا لو عملت port forwarding أو نشرته على سيرفر.

وفيه عنوان خاص جدًا: 127.0.0.1 واسمه localhost، ومعناه “الجهاز ده نفسه”. لما تفتح localhost:3000 إنت بتكلم جهازك إنت، وأي حد تاني يفتح نفس الرابط هيكلم جهازه هو.

والعناوين اللي شكلها 192.168.1.5 اسمها IPv4 وعددها محدود، وبيحل محلها تدريجيًا IPv6 اللي عناوينه أطول بكتير.

ثالثاً: الـ Port: رقم الشقة جوه العمارة

لو الـ IP عنوان العمارة، فالـ Port هو رقم الشقة. الجهاز الواحد بيشغل برامج كتير في نفس الوقت، والـ Port هو اللي بيحدد الطلب ده رايح لأنهي برنامج. الأرقام من 0 لـ 65535، وفيه أرقام ليها استخدامات معروفة:

• 80 لـ HTTP، و443 لـ HTTPS
• 22 لـ SSH، و53 لـ DNS
• 27017 لـ MongoDB، و5432 لـ PostgreSQL، و3306 لـ MySQL

مشروع الميرن ستاك بتاعنا بيستخدم 3000 للباك إند. ولما كتبنا 3000:3000 في docker-compose في مقال Docker، كنا بنقول: الـ Port 3000 على جهازي يوصل للـ Port 3000 جوه الحاوية.

ولو شغلت برنامجين على نفس الـ Port هتشوف الخطأ EADDRINUSE، لأن الـ Port الواحد مبيخدمش غير برنامج واحد.

رابعاً: الـ DNS: دفتر تليفونات الإنترنت

الإنسان بيفتكر الأسماء، والكمبيوتر بيتعامل بالأرقام. الـ DNS هو اللي بيترجم اسم زي example.com لعنوان IP.

لما تكتب الاسم، المتصفح بيسأل بالترتيب: الكاش بتاعه، وبعدين نظام التشغيل، وبعدين خادم DNS (غالبًا بتاع شركة الإنترنت، أو زي 8.8.8.8 و1.1.1.1). ولو الخادم ده معندوش الإجابة، بيسأل سلسلة سيرفرات لحد ما يوصل للسيرفر المسؤول عن الدومين فعلاً.

السجلات (records) اللي هتقابلها أكتر حاجة:

• A: بيربط الاسم بعنوان IPv4، وAAAA نفس الفكرة لـ IPv6.
• CNAME: اسم مستعار بيشاور على اسم تاني بدل IP.
• MX: بيحدد سيرفر الإيميل الخاص بالدومين.
• TXT: نص حر، وبيتستخدم كتير لإثبات إنك صاحب الدومين.

ولكل سجل TTL، وهو المدة اللي الإجابة بتتخزن فيها في الكاش قبل ما تتسأل من جديد.

ده سبب ما بيتقال إن تغيير الدومين “بياخد وقت لحد ما ينتشر”. هو مش بينتشر فعلاً، لكن كاشات كتير لسه شايلة الإجابة القديمة لحد ما الـ TTL يخلص. ولما تربط دومين بمنصة نشر زي Vercel، اللي بتضيفه عند مزود الدومين هو سجل DNS من النوع ده. وفيه شرح مبسط في صفحة Cloudflare عن الـ DNS.

خامساً: TCP وUDP

فوق الـ IP فيه بروتوكولين رئيسيين لنقل البيانات. الـ TCP بيفتح اتصال الأول، ويتأكد إن كل البيانات وصلت وبنفس الترتيب، ولو حاجة ضاعت بيعيد إرسالها.

فتح الاتصال بيتم بتبادل تلات رسايل اسمه 3-way handshake: العميل بيبعت SYN، والسيرفر بيرد SYN-ACK، والعميل بيأكد بـ ACK. بعد كده يبدأ الكلام الفعلي. الـ HTTP وقواعد البيانات والـ SSH كلهم شغالين فوق TCP.

الـ UDP بيعمل العكس: بيبعت من غير ما يفتح اتصال ومن غير ضمان إن الرسالة توصل، فهو أسرع وأخف. ده مناسب لما ضياع رسالة واحدة مش مشكلة، زي مكالمات الفيديو والألعاب. وغالبًا الاستعلامات العادية في الـ DNS بتتبعت بـ UDP كمان. حتى HTTP/3 الجديد شغال فوق UDP، بس بيضيف فوقه ضمان الوصول بنفسه.

سادساً: HTTP وHTTPS وTLS

بعد ما الاتصال يتفتح، الكلام نفسه بيمشي بـ HTTP: العميل بيبعت طلب والسيرفر بيرد. ده شكل طلب ورد مبسطين من الـ API اللي بنيناه في مقال الـ REST API.

# الطلب
GET /users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...
Accept: application/json

# الرد
HTTP/1.1 200 OK
Content-Type: application/json

[{"name": "Ahmed"}]

الطلب فيه فعل (GET هنا)، ومسار (/users)، وهيدرز زي Authorization اللي بيحمل التوكن اللي شرحناه في مقال الـ JWT. والرد فيه كود حالة، وأول رقم فيه بيقولك نوع النتيجة:

• 2xx: نجح الطلب.
• 3xx: إعادة توجيه لمكان تاني.
• 4xx: الغلط من الطلب نفسه (مسار مش موجود، مفيش صلاحية).
• 5xx: الغلط من السيرفر.

وللتفاصيل الكاملة عن HTTP، شرح MDN مرجع موثوق.

الـ HTTP لوحده بيبعت النص زي ما هو، فأي حد في نص الطريق يقدر يقراه. HTTPS هو نفس HTTP بس جوه قناة مشفرة بـ TLS.

خطوة التشفير دي بتحصل قبل أول طلب: المتصفح والسيرفر بيتفقوا على مفاتيح تشفير، والسيرفر بيبعت شهادة (certificate) بتثبت إن الموقع ده فعلاً صاحب الدومين. وإزاي تجيب شهادة وتظبطها شرحناه في مقال Nginx. من غيرها، التوكن اللي بيتبعت مع كل طلب كان هيبقى مكشوف لأي حد على نفس الشبكة.

سابعاً: اللي في نص الطريق

الطلب مبيروحش للتطبيق مباشرة في الغالب، فيه حاجات كتير بتقف قدامه:

• Firewall: بيسمح أو بيمنع حسب العنوان والـ Port. لو السيرفر شغال وإنت مش قادر توصله، فيه احتمال كبير إن الـ Port مقفول عند الـ firewall أو في إعدادات الأمان عند مزود الكلاود.
• Reverse Proxy: بيستقبل الطلبات بدل التطبيق ويوجهها له، زي Nginx اللي شرحناه.
• Load Balancer: بيوزع الطلبات على أكتر من سيرفر، وده الأساس اللي اتكلمنا عنه في مقال System Design.
• CDN: نسخ من الملفات الثابتة (صور، CSS، JavaScript) متخزنة في أماكن قريبة جغرافيًا من المستخدم.

ومعاهم مصطلحين بيتخلطوا على كتير. الـ latency هو الوقت اللي الرسالة بتاخده عشان تروح وترجع (بالـ ms)، والـ bandwidth هو كمية البيانات اللي تعدي في الثانية.

ممكن يكون عندك إنترنت سريع جدًا وكل طلب لسه بطيء، لأن السيرفر بعيد جغرافيًا. ده سبب إن الـ CDN بيفرق، وسبب إن خمسين طلب صغير غالبًا أبطأ من طلب واحد بنفس الحجم الكلي، لأن كل طلب بيدفع تمن الـ latency.

ثامناً: أوامر تجرب بيها كل خطوة بنفسك

الأوامر دي بتخليك تشوف الخطوات اللي فوق بعينك. جربها على موقعك أو أي موقع تاني، وكل أمر بيغطي جزء من الرحلة.

# الجهاز ده بيرد؟ وقد إيه الـ latency
ping example.com

# الـ DNS: الاسم ده بيترجم لأنهي IP
nslookup example.com

# الطلب بتفاصيله: الاتصال والـ TLS والهيدرز
curl -v https://example.com

# الطريق اللي الرسايل بتمشيه (Windows)
tracert example.com
# نفس الأمر على Linux و Mac
traceroute example.com

# مين مستخدم الـ Port 3000؟ (Windows)
netstat -ano | findstr :3000
# على Linux و Mac
lsof -i :3000

ملحوظة على ping: بعض السيرفرات بتتجاهله عن قصد، فلو مرجعش رد ده مش دليل إن السيرفر واقع. جرب curl بدله لو عايز تتأكد إن الموقع نفسه بيرد.

تاسعاً: لما حاجة تتعطل: الرسالة بتقولك الخطوة

دلوقتي بقى عندك الخريطة، وكل رسالة خطأ بتشاور على نقطة فيها. الجدول ده بيلخص أشهرهم وأول حاجة تجربها مع كل واحدة.

الفايدة العملية: بدل ما تبدأ تغير في الكود لما الموقع مش فاتح، اسأل الأول “الرحلة وقفت عند أنهي خطوة؟”. كتير من المشاكل مش في الكود أصلاً.

عاشراً: أخطاء شائعة هتقابلك

• الظن إن localhost جوه الحاوية هو جهازك. جوه Docker كل حاوية ليها localhost خاص بيها، فعشان حاوية تكلم التانية بتستخدم اسم السيرفس (زي backend في ملف الـ Compose) مش localhost.
• تشغيل التطبيق على 127.0.0.1 بس، فمحدش من برّه الحاوية أو الجهاز يقدر يوصله. بعض الأدوات بتشتغل كده افتراضيًا.
• الاستنتاج إن السيرفر واقع لمجرد إن ping مرجعش رد.
• كتابة عنوان IP ثابت في الكود بدل اسم دومين، فأول ما العنوان يتغير كل حاجة بتقف.
• الاكتفاء بـ HTTP في الإنتاج لأنه “شغال”، وده بيكشف التوكنز وكلمات السر.
• تجربة الموقع من جهازك بس. جربه من شبكة تانية (موبايل من غير WiFi مثلاً) عشان تتأكد إنه متاح من برّه فعلاً.

لو عايز تثبت الفهم، خد مشروع منشور عندك وجرب الأوامر اللي فوق عليه واحد واحد، وشوف كل خطوة بنفسك. ولو قابلتك رسالة خطأ محيرة، ابعتها في التعليقات ونشوف سوا هي بتشاور على أنهي خطوة.