ماذا يحدث عند كتابة google.com في المتصفح؟ من DNS و TCP حتى رسم البكسلات
رحلة الطلب من الضغط على Enter: كاش المتصفح، استعلامات DNS الشجرية، مصافحة TCP الثلاثية، تشفير TLS، حتى معالجة DOM ورسم الصفحة.
🌐 What Really Happens When You Type google.com?
<img src="https://cdn.simpleicons.org/google/4285F4" alt="Google" width="100"/>
أنت مش "بتكلم Google" وخلاص.
أنت بتبدأ رحلة من DNS → TCP/TLS → HTTP → Routing → Encapsulation → Servers → Rendering.
</div>📚 Table of Contents
- الفكرة في دقيقة
- 1. Browser يبدأ منين؟
- 2. DNS Resolution
- 3. DNS مش Server واحد
- 4. من IP إلى Connection
- 5. TCP Three-Way Handshake
- 6. TLS Handshake
- 7. HTTP Request
- 8. Encapsulation
- 9. Application Layer
- 10. Transport Layer
- 11. Internet / Network Layer
- 12. Link Layer
- 13. رحلة الـPacket
- 14. Routers بتعمل إيه؟
- 15. Decapsulation
- 16. Google Infrastructure
- 17. HTTP Response
- 18. Browser Rendering
- 19. HTTP/2 وHTTP/3
- 20. الرحلة كاملة
- 21. Common Misconceptions
- 22. Production / Networking Checklist
- الخلاصة
- Further Reading
⚡ الفكرة في دقيقة
ناس كتير فاكرة إنك لما تكتب:
google.com
وتضغط Enter:
Browser
↓
Google
↓
Page
وخلاص.
لكن اللي بيحصل أقرب إلى:
URL
↓
DNS
↓
IP
↓
TCP / QUIC
↓
TLS
↓
HTTP
↓
Encapsulation
↓
Routers
↓
Edge / CDN / Load Balancer
↓
Application Servers
↓
HTTP Response
↓
Decapsulation
↓
Browser
↓
Rendering
↓
Page
وكل ده ممكن يحصل في وقت قصير جدًا.
1. Browser يبدأ منين؟
أنت كتبت:
google.com
وضغطت:
Enter
الـBrowser محتاج يعرف:
إيه الـIP address اللي هبعت له الـrequest؟
الإنترنت لا يستخدم google.com كعنوان توجيه في طبقة IP.
يحتاج عنوانًا مثل:
142.250.x.x
لكن قبل ما يعمل DNS lookup كامل، الـBrowser والـOS ممكن يكون عندهم caching للمعلومة.
2. DNS Resolution
DNS اختصار لـ:
Domain Name System
وظيفته الأساسية:
Domain Name
↓
IP Address
مثلاً بشكل مبسط:
google.com
↓
142.250.x.x
لكن العملية مش بالضرورة تبدأ مباشرة من Root DNS.
الـclient غالبًا يستخدم DNS resolver configured في النظام، والـresolver قد يكون عند ISP أو public DNS provider.
وفي الطريق قد توجد caches متعددة.
Browser / OS
↓
Local DNS Cache
↓
DNS Resolver
↓
DNS Infrastructure
↓
IP Address
🧠 DNS Caching
لو الـIP موجود في cache:
google.com
↓
Cached answer
↓
IP
ممكن نتجنب lookup كامل.
الـDNS records لها:
TTL
والـTTL يحدد مدة صلاحية الإجابة في caches وفق سياسات DNS.
وده واحد من الأسباب إن تغيير DNS record لا يظهر بالضرورة لكل الناس في نفس اللحظة.
3. DNS مش Server واحد
دي من أهم النقاط.
الـDNS عبارة عن نظام موزع وهرمي.
بشكل مبسط، ممكن resolver يحتاج للوصول إلى:
Root
↓
.com TLD
↓
Authoritative DNS
↓
Answer
مثلاً:
Root
│
▼
.com
│
▼
Authoritative DNS
for domain
│
▼
Record
│
▼
IP
Root Servers
تعرف resolver بمكان الـTLD servers.
TLD Servers
مثل:
.com
.org
.net
توجه resolver إلى authoritative servers الخاصة بالنطاق.
Authoritative DNS
هو المصدر authoritative للـDNS zone الخاصة بالدومين.
🌍 هل Google عندها IP واحد؟
مش بالضرورة.
في المواقع والخدمات العالمية، الـDNS answer قد يتأثر بالـnetworking architecture مثل:
- Anycast
- Geographic / latency-aware routing
- Load balancing
- CDN / edge infrastructure
- Service topology
لذلك عميل في مصر قد لا يحصل على نفس endpoint أو نفس path الذي يحصل عليه عميل في ألمانيا.
الفكرة:
User in Egypt
↓
Nearby / suitable edge
↓
Google infrastructure
و:
User in Germany
↓
Different suitable edge
↓
Google infrastructure
الـDNS ليس وحده المسؤول عن كل قرار routing؛ الشبكة والـCDN والـload-balancing architecture كلها ممكن تشارك.
4. من IP إلى Connection
دلوقتي عرفنا:
IP Address
لكن لسه الـapplication محتاجة transport connection مناسب.
في HTTP/1.1 وHTTP/2 التقليديين فوق TCP، بيبدأ:
TCP Connection
أما HTTP/3 فيستخدم:
QUIC over UDP
ودي نقطة مهمة جدًا لأن العالم الحديث مش كله TCP.
5. TCP Three-Way Handshake
في TCP، البداية تكون غالبًا:
Client Server
│ │
│ ─────── SYN ──────────► │
│ │
│ ◄──── SYN-ACK ───────── │
│ │
│ ─────── ACK ──────────► │
│ │
│ Connection │
SYN
الـClient يقول:
"عايز أبدأ TCP connection."
SYN-ACK
السيرفر يرد:
"تمام، وأنا مستعد."
ACK
الـClient يؤكد:
"وصلت، نبدأ."
دلوقتي:
TCP Connection Established
TCP يوفر إيه؟
من أهم خصائصه:
- Reliable byte stream
- Ordered delivery
- Retransmission
- Flow control
- Congestion control
6. TLS Handshake
لو الموقع:
https://google.com
فأنت مش هتبعت HTTP data عادي فوق connection غير مشفر.
في HTTP over TLS، يحصل TLS handshake.
الهدف يشمل:
Authentication
+
Key Agreement
+
Secure Encryption
بشكل مبسط:
Browser
│
│ TLS negotiation
▼
Server
│
├── Certificate
├── Certificate validation
├── Key agreement
└── Session keys
الـBrowser يتحقق من أشياء مثل:
- Certificate validity
- Domain identity
- Trusted certificate chain
- Cryptographic parameters
ثم يتم إنشاء مفاتيح جلسة لاستخدامها في حماية الاتصال.
تفاصيل TLS الحديثة أكثر تعقيدًا من هذا الرسم، والـhandshake يختلف حسب TLS version وcipher suites والـresumption.
🔐 HTTPS يعني إيه؟
ببساطة:
HTTP
+
TLS
=
HTTPS
والـTLS يحمي البيانات أثناء النقل من القراءة أو التعديل من أطراف على الطريق، مع authentication للسيرفر وفق نظام الشهادات.
لكن:
HTTPS لا يعني أن التطبيق نفسه آمن.
ممكن يكون عندك:
HTTPS
+
SQL Injection
+
Broken Authorization
والـsite يظل vulnerable.
7. HTTP Request
دلوقتي الـBrowser جاهز يبعث request.
مثلاً:
GET / HTTP/2
Host: www.google.com
User-Agent: ...
Accept: text/html,...
في HTTP/1.1 ستظهر صيغة text-like request واضحة.
أما HTTP/2 وHTTP/3 فالنقل على wire مختلف وأكثر binary، رغم أن الـHTTP semantics مثل:
Method
Path
Headers
Status
ما زالت موجودة.
8. Encapsulation
هنا واحدة من أهم أفكار Networking:
كل layer تضيف metadata تخصها حول البيانات.
بشكل مبسط:
Application Data
↓
Transport Segment
↓
IP Packet
↓
Link-Layer Frame
مثال:
┌──────────────────────────────┐
│ Link / Frame Header │
├──────────────────────────────┤
│ IP Header │
├──────────────────────────────┤
│ TCP Header │
├──────────────────────────────┤
│ HTTP Data │
├──────────────────────────────┤
│ Link / Frame Trailer │
└──────────────────────────────┘
وده:
Encapsulation
🧩 9. Application Layer
الـBrowser والـHTTP يشتغلوا في أعلى طبقة من الـmodel المستخدم للتفكير في الشبكات.
الـapplication تنتج:
HTTP Request
مثلاً:
GET /
ومعاه:
Headers
Cookies
Request metadata
لو فيه body، ممكن يكون:
{
"name": "Amr"
}
🚚 10. Transport Layer
لو HTTP فوق TCP:
HTTP Data
↓
TCP
TCP يضيف معلومات مثل:
- Source port
- Destination port
- Sequence information
- Acknowledgment information
- Flags
فتصبح بشكل مبسط:
[TCP Header][HTTP Data]
لكن في HTTP/3:
HTTP/3
↓
QUIC
↓
UDP
فمش كل Web traffic الحديث يمر عبر TCP.
🌐 11. Internet / Network Layer
بعدها IP.
مثلاً:
[TCP Header][HTTP Data]
يتم وضعه داخل IP packet:
[IP Header][TCP Header][HTTP Data]
الـIP header يحتوي معلومات مثل:
Source IP
Destination IP
TTL / Hop Limit
Protocol / Next Header
وده اللي يساعد routers في توجيه الـpacket.
📡 12. Link Layer
قبل ما الـpacket تمشي على local network، يتم وضعها داخل link-layer frame.
حسب الشبكة قد يكون:
Ethernet
أو:
Wi-Fi
بشكل مبسط:
[Frame Header]
[IP Header]
[TCP Header]
[HTTP Data]
[Frame Trailer]
في Ethernet مثلًا توجد معلومات مرتبطة بالـMAC addressing وFrame Check Sequence.
📦 الصورة الكاملة للـEncapsulation
Application
┌─────────────────────┐
│ HTTP Data │
└─────────────────────┘
↓
Transport
┌─────────────────────┐
│ TCP │ HTTP Data │
└─────────────────────┘
↓
Internet
┌─────────────────────────────┐
│ IP │ TCP │ HTTP Data │
└─────────────────────────────┘
↓
Link
┌──────────────────────────────────────┐
│ Frame │ IP │ TCP │ HTTP │ Trailer │
└──────────────────────────────────────┘
كل طبقة تضيف المعلومات التي تحتاجها.
🚦 13. رحلة الـPacket
دلوقتي تبدأ الرحلة:
Your PC
↓
Wi-Fi Router
↓
ISP
↓
Internet Routers
↓
Google / Edge Network
لكن مش شرط يكون الطريق ثابت.
Routing decisions تعتمد على:
- Routing tables
- BGP
- ISP topology
- Peering
- Anycast
- Congestion
- Network failures
- Traffic engineering
🧭 14. Routers بتعمل إيه؟
واحدة من أهم الـmisconceptions:
Router مش بيفهم الـHTML بتاعك.
الـrouter يهتم أساسًا بمعلومات الشبكة الموجودة في الـpacket headers.
بشكل مبسط:
Incoming Packet
↓
Read destination
↓
Routing table
↓
Choose next hop
↓
Forward
ثم:
Router
↓
Router
↓
Router
↓
Router
كل hop يعيد إرسال الـpacket إلى الـnext hop.
🧠 MAC Address vs IP Address
دي نقطة مهمة جدًا.
IP
يستخدم في:
Network-level addressing
ويساعد في routing بين الشبكات.
MAC
يستخدم في:
Link-local delivery
على الشبكة المحلية.
فمش معنى إن الـdestination IP هو Google إن جهازك يعرف MAC بتاع Google.
الـMAC غالبًا يكون للـnext hop على الـlocal link.
مثلاً:
Your PC
│
│ Destination IP:
│ Google
▼
Home Router
الـEthernet/Wi-Fi frame على أول hop يستخدم MAC addresses الخاصة بالـlocal link.
🔓 15. Decapsulation
لما البيانات توصل للجهة المقصودة، يحصل العكس:
Frame
↓
Remove Link Header
↓
IP Packet
↓
Remove IP Header
↓
Transport Data
↓
Remove Transport Header
↓
Application Data
يعني:
[Frame][IP][TCP][HTTP]
↓
[IP][TCP][HTTP]
↓
[TCP][HTTP]
↓
[HTTP]
وده:
Decapsulation
🏢 16. Google Infrastructure
وهنا المفاجأة:
ممكن أصلًا الـIP اللي وصلت له مش هو "السيرفر اللي عليه Google HTML" بالشكل البسيط اللي متخيله.
بينك وبين application logic ممكن تلاقي طبقات كثيرة.
مثلاً:
Internet
↓
Edge Network
↓
DDoS / WAF-like Protection
↓
Load Balancing
↓
Reverse Proxy
↓
Caching
↓
Application Services
↓
Databases / Internal Services
مش لازم كل request يمر حرفيًا بكل طبقة بنفس الترتيب.
🌍 CDN / Edge
لو المحتوى موجود في edge قريب منك:
User in Egypt
↓
Nearby Edge
↓
Cached Content
بدل:
User
↓
Long-distance route
↓
Origin
↓
Response
الهدف:
Lower latency
+
Higher scalability
+
Less origin traffic
⚖️ Load Balancer
لو عندك آلاف السيرفرات:
Load Balancer
/ | \
▼ ▼ ▼
Server Server Server
\ | /
\ | /
Application
الـload balancer يوزع traffic على backend instances حسب architecture والhealth/load policies.
🔁 Reverse Proxy
ممكن يكون فيه layer قدام التطبيق:
Client
↓
Reverse Proxy
↓
Application
أمثلة شائعة:
- NGINX
- Envoy
- Cloudflare
- HAProxy
ممكن يتولى وظائف مثل:
- TLS termination
- Routing
- Compression
- Caching
- Security controls
- Load balancing
🧊 Caching Layers
ممكن request أصلًا ما توصلش للـapplication.
Request
↓
Cache
├── HIT → Response
│
└── MISS
↓
Backend
وده سبب إن نفس الـURL ممكن يكون سريع جدًا أحيانًا.
🛡️ WAF
WAF اختصار:
Web Application Firewall
ممكن يقف قبل الـapplication ويبحث عن patterns مرتبطة بهجمات Web شائعة.
مثلاً:
Request
↓
WAF
├── Block
│
└── Allow
↓
App
لكن WAF مش بديل عن secure coding.
🚦 Rate Limiting
لو attacker يعمل:
100,000 requests / second
ممكن infrastructure تطبق rate limits:
Client
↓
Rate Limiter
├── Allowed
└── Throttled / Rejected
وده يساعد في:
- Abuse control
- Resource protection
- API fairness
- Cost control
📊 Monitoring & Telemetry
الأنظمة الكبيرة مش بس تستقبل requests.
هي كمان تجمع:
Metrics
Logs
Traces
Latency
Errors
Traffic
Saturation
مثلاً:
Request
↓
Trace ID
↓
Service A
↓
Service B
↓
Database
فتقدر تعرف:
"الـrequest اتأخر فين؟"
📤 17. HTTP Response
بعد ما السيرفر يعالج request:
HTTP/2 200
Content-Type: text/html
Cache-Control: ...
Set-Cookie: ...
والbody ممكن يحتوي:
HTML
لكن تحميل الصفحة الحديثة غالبًا لا ينتهي هنا.
الـHTML ممكن يطلب:
CSS
JavaScript
Images
Fonts
APIs
وكل resource من دول قد يبدأ رحلة networking جديدة.
🔁 الرحلة لا تحدث مرة واحدة
مثلاً:
GET /
↓
HTML
↓
Browser parses HTML
↓
Find CSS
↓
GET /style.css
↓
Find JS
↓
GET /app.js
↓
Find images
↓
GET /hero.webp
↓
JS calls API
↓
GET /api/products
فـ"فتح Google" مش request واحدة بالضرورة.
الصفحة قد تبدأ chain من requests وsubresources، وبعضها قد يستخدم connections موجودة بالفعل.
🖼️ 18. Browser Rendering
بعد وصول الموارد، الـBrowser يبدأ rendering pipeline.
بشكل مبسط:
HTML
↓
DOM
↓
CSS
↓
CSSOM
↓
Render Tree
↓
Layout
↓
Paint
↓
Compositing
↓
Screen
DOM
الـHTML يتحول إلى:
Document Object Model
CSSOM
الـCSS يتحول إلى model يفهم منه browser styles.
Layout
يحسب:
Where is every element?
What size is it?
Paint
يرسم pixels.
Compositing
يجمع layers ويعرض النتيجة النهائية.
⚡ 19. HTTP/2 وHTTP/3
الـWeb الحديث مش مبني فقط على:
HTTP/1.1 + TCP
HTTP/2
يعمل فوق TCP ويضيف تحسينات مثل:
- Binary framing
- Multiplexing
- Header compression
- Multiple concurrent streams over one connection
فبدل:
Request 1 → Connection
Request 2 → Connection
Request 3 → Connection
ممكن:
One TCP Connection
├── Stream 1
├── Stream 2
├── Stream 3
└── Stream 4
HTTP/3
HTTP/3 يستخدم:
HTTP/3
↓
QUIC
↓
UDP
QUIC يوفر transport features مثل:
- Encryption integration
- Multiplexed streams
- Faster connection establishment in many cases
- Connection migration support
وده ممكن يحسن الأداء خصوصًا في الشبكات المتغيرة.
🧬 TCP vs QUIC
| Header | TCP + HTTP/2 | QUIC + HTTP/3 |
|---|---|---|
| Transport | TCP | QUIC over UDP |
| Streams | HTTP/2 streams | QUIC streams |
| Encryption | TLS layered with TCP | TLS integrated into QUIC handshake |
| Multiplexing | نعم | نعم |
| Connection migration | محدود | مدعوم في QUIC |
| Web usage | واسع | واسع ومتزايد |
UDP هنا لا يعني "connectionless = unreliable HTTP". QUIC يبني reliability, congestion control, streams وغيرها فوق UDP.
🗺️ 20. الرحلة كاملة
flowchart TD
A["Type google.com"] --> B["Browser / OS Cache"]
B --> C["DNS Resolver"]
C --> D["Root / TLD / Authoritative DNS"]
D --> E["IP Address"]
E --> F{"Transport"}
F -->|HTTP/1.1 or HTTP/2| G["TCP Handshake"]
F -->|HTTP/3| H["QUIC"]
G --> I["TLS"]
H --> I["TLS / QUIC Handshake"]
I --> J["HTTP Request"]
J --> K["Encapsulation"]
K --> L["Router / ISP / Internet"]
L --> M["Edge / CDN / Load Balancer"]
M --> N["Reverse Proxy / Cache"]
N --> O["Application Services"]
O --> P["Database / Internal APIs"]
P --> Q["HTTP Response"]
Q --> R["Network Back"]
R --> S["Decapsulation"]
S --> T["Browser"]
T --> U["DOM / CSS / JS / Rendering"]
U --> V["Pixels on Screen"]
📦 Encapsulation vs Decapsulation
الصورة الأهم:
SENDER
────────────────────────────
HTTP DATA
↓
[TCP][HTTP]
↓
[IP][TCP][HTTP]
↓
[FRAME][IP][TCP][HTTP][FCS]
↓
NETWORK
↓
RECEIVER
────────────────────────────
[FRAME][IP][TCP][HTTP][FCS]
↓
[IP][TCP][HTTP]
↓
[TCP][HTTP]
↓
HTTP DATA
🔥 Common Misconceptions
❌ "Browser يكلم Google مباشرة"
مش بالبساطة دي.
بينك وبين application قد توجد:
DNS
ISP
Routers
Peering
Edge
Load Balancing
Proxy
Cache
Application Services
❌ "DNS يرجع IP واحد ثابت دائمًا"
لا.
DNS answers قد تتغير حسب:
- TTL
- Load balancing
- Geo / latency policies
- Anycast / infrastructure
- Service changes
❌ "كل HTTP يستخدم TCP"
لا.
HTTP/1.1 → TCP
HTTP/2 → TCP
HTTP/3 → QUIC/UDP
❌ "Router يفك HTTP"
غالبًا لا.
Router في path لا يحتاج يفهم HTML.
هو يوجه packets بناءً على network information.
❌ "MAC Address هو عنوان السيرفر النهائي"
لا.
MAC addresses تعمل على link-local segment.
الـIP هو اللي يستخدم في network-level routing.
❌ "TLS يخفي كل حاجة"
TLS يحمي محتوى الاتصال، لكن metadata مثل destination IP ليست سرية بنفس الطريقة.
وفي بعض الحالات DNS نفسه يمكن حمايته باستخدام تقنيات مثل DoH/DoT، لكن ده موضوع منفصل.
❌ "فتح الصفحة Request واحدة"
غالبًا لا.
HTML ممكن يسبب عشرات أو مئات requests حسب الصفحة والresources.
❌ "DNS دائمًا يأخذ وقت كبير"
لا.
DNS caching قد يجعل lookup سريع جدًا أو لا يحتاج network lookup كامل أصلًا.
🧪 21. Production / Networking Checklist
لو عايز تفهم أداء أي Web App:
- افهم DNS path
- افهم DNS caching وTTL
- اعرف الـorigin والendpoint
- اعرف هل تستخدم HTTP/1.1 أو HTTP/2 أو HTTP/3
- افهم TLS
- راقب connection reuse
- افهم CDN / Edge behavior
- راقب cache HIT/MISS
- افهم load balancing
- راقب TTFB
- راقب DNS lookup time
- راقب connection time
- راقب TLS time
- راقب download time
- استخدم browser DevTools Network
- استخدم tracing للـbackend
- راقب errors وlatency
- افهم rate limiting
- افهم WAF / reverse proxy layer
⏱️ أين يضيع الوقت؟
الـpage load ممكن يتأثر بعوامل كثيرة:
DNS
↓
Connection
↓
TLS
↓
Request
↓
Server Processing
↓
Response
↓
Browser Parsing
↓
Rendering
لذلك لما موقع يكون "بطيء"، السؤال مش:
"السيرفر بطيء؟"
لكن:
DNS?
TCP?
TLS?
Network?
CDN?
TTFB?
Backend?
Database?
Payload size?
JavaScript?
Rendering?
🔬 DevTools Perspective
افتح:
Chrome DevTools
→ Network
ممكن تشوف timings مثل:
Queueing
↓
DNS Lookup
↓
Initial Connection
↓
SSL
↓
Request Sent
↓
Waiting for Server Response
↓
Content Download
والـWaterfall يساعدك تفهم الرحلة بدل ما تخمن.
🧠 Layer Model
للتفكير:
Application
↓
HTTP
Transport
↓
TCP / QUIC
Internet
↓
IP
Link
↓
Ethernet / Wi-Fi
Physical
↓
Electrical / Radio / Optical signals
لكن خليك فاكر:
OSI وTCP/IP models أدوات لفهم الشبكات، مش وصف حرفي لكل implementation حديث.
🎯 الخلاصة
لما تكتب:
google.com
أنت في الحقيقة بدأت رحلة كبيرة:
Domain
↓
DNS
↓
IP
↓
TCP / QUIC
↓
TLS
↓
HTTP
↓
Encapsulation
↓
Routers
↓
Internet
↓
Edge / CDN
↓
Load Balancer
↓
Application
↓
Response
↓
Decapsulation
↓
Browser
↓
Rendering
والموضوع لا ينتهي عند أول HTML.
الـBrowser بعدها ممكن يبدأ:
CSS
JS
Images
Fonts
APIs
وكل واحد منهم ممكن يطلق network requests إضافية.
والأجمل:
كل ده بيحصل وأنت شايف شاشة بسيطة جدًا قدامك.
يعني لما تكتب:
google.com
أنت مش "فتحت موقع".
أنت بدأت:
رحلة كاملة عبر طبقات الـWeb والـNetwork والـDistributed Systems. 🌐
📚 Further Reading
DNS
HTTP
TLS
QUIC
Browser Networking
<div align="center">
