HTTP و Networking

#من كتابة URL لحد ظهور الصفحةFrom typing a URL to rendering a page

لما صفحة بتتأخر، «الشبكة بطيئة» تشخيص واسع. اقسم الرحلة لمراحل علشان تعرف هل المشكلة DNS ولا connection ولا server ولا rendering. دي رحلة HTTPS نموذجية على TCP؛ connection reuse و caches ممكن يختصروا خطوات، و HTTP/3 بيستخدم QUIC بدل TCP.

1. المتصفح يحلل scheme و host و port و path، ويراجع cache وسياسات زي HSTS و service worker لو موجود.
2. DNS: يراجع caches المحلية، ثم recursive resolver. لو مفيش إجابة cached، الـ resolver ممكن يسأل root عن TLD، ثم TLD عن authoritative nameserver، ثم authoritative عن record، ويتابع aliases. مش كل زيارة بتكرر السلسلة.
3. TCP: العميل يبعت SYN، والسيرفر SYN-ACK، والعميل ACK. بورت العميل غالباً ephemeral، والوجهة HTTPS غالباً 443.
4. TLS 1.3: ClientHello يعلن capabilities و key share، والسيرفر يرد باختيار و key share وشهادة ورسائل إثبات الهوية. العميل يتحقق من hostname والثقة، والاتنين يشتقوا مفاتيح التشفير. ALPN بيتفاوض على HTTP protocol.
5. العميل يبعت HTTP request مشفر، والـ server أو proxy يرجع status و headers و body.
6. المتصفح يحلل HTML و CSS، ويبني DOM و CSSOM، ويحمّل resources، وينفذ JavaScript، ويعمل layout و paint. بعض الشغل بيتداخل بدل انتظار كل resource.

#Layers و TCP و UDP و SocketsLayers, TCP, UDP and sockets

الـ layers بتفصل المسؤوليات، وبتساعدك تفهم ليه نجاح ping مش دليل إن HTTPS شغالة. OSI نموذج 7 layers: Physical، و Data link، و Network، و Transport، و Session، و Presentation، و Application. نموذج TCP/IP العملي غالباً بيجمعهم في Link، و Internet، و Transport، و Application؛ TLS مش لازم يتحشر في mapping حرفي واحد.

port رقم endpoint منطقي لخدمة transport، و socket abstraction في الـ OS للاتصال. اتصال TCP بيتحدد بالـ source IP والـ source port والـ destination IP والـ destination port مع protocol. سيرفر واحد يقدر يخدم اتصالات كتير على 443 لأن client endpoints مختلفة.

TCP read واحدة مش لازم تساوي message واحدة؛ لازم framing على مستوى التطبيق. UDP مش «أسرع دائماً»، و QUIC بيضيف reliable streams و congestion control فوقه. DNS ممكن يستخدم TCP كمان؛ ماتحفظش protocol كبورت و transport واحد فقط.

#HTTP request و Methods و Status codesHTTP requests, methods and status codes

HTTP semantics بتقول intent العملية، مش بس شكل URL. GET و HEAD safe و idempotent؛ PUT و DELETE idempotent في الأثر المقصود، مش شرط نفس الرد؛ POST مش idempotent افتراضياً؛ PATCH حسب العملية والتصميم. safe معناها مفيش تغيير business مطلوب من العميل، مش منع logs أو metrics.

المثال raw HTTP/1.1 للعرض؛ الـ wire محتاج CRLF و HTTPS transport لو endpoint محمية. Content-Type بيصف body المرسل، و Accept بيقول إيه أنواع الرد المقبولة.

GET /products/42 HTTP/1.1
Host: store.example.com
Accept: application/json
If-None-Match: "product-v7"

HTTP/1.1 304 Not Modified
ETag: "product-v7"
Cache-Control: public, max-age=60

الـ client عنده representation بنفس ETag، فالـ server رجّع 304 من غير body. header names مش case-sensitive. ماتعيدش POST بعد timeout بشكل أعمى؛ الطلب ممكن يكون اتنفذ والرد ضاع. استخدم idempotency key بعقد واضح لو retry محتاج يضمن عدم تكرار الأثر.

#HTTP/1.1 و HTTP/2 و HTTP/3 في KestrelHTTP/1.1, HTTP/2 and HTTP/3 in Kestrel

تحميل resources كتير على connection واحدة محتاج multiplexing. HTTP/2 بيحل انتظار الطلبات على مستوى HTTP، لكن فقد TCP packet لسه ممكن يوقف streams كلها لحد استرجاعها. HTTP/3 بينقل streams على QUIC؛ فقد داتا stream مش لازم يمنع تسليم داتا stream تانية.

ده Program.cs كامل لـ ASP.NET Core 10 web project. محتاج default HTTPS certificate مضبوطة؛ HTTP/3 محتاج platform و MsQuic مدعومين، و UDP port مفتوح كمان.

using Microsoft.AspNetCore.Server.Kestrel.Core;

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(options =>
{
    options.ListenAnyIP(5001, listen =>
    {
        listen.Protocols = HttpProtocols.Http1AndHttp2AndHttp3; // (1)
        listen.UseHttps(); // (2)
    });
});
var app = builder.Build();
app.MapGet("/", (HttpContext context) => context.Request.Protocol); // (3)
app.Run();

HTTP semantics واحدة عبر الإصدارات؛ HTTP/3 مش أسرع دائماً، و UDP ممكن يتقفل في بعض الشبكات فـ fallback مهم. HTTP/3 specification و متطلبات Kestrel.

#Keep-alive و Connection pooling و Socket exhaustionKeep-alive, connection pooling and socket exhaustion

TCP و TLS handshakes ليهم تكلفة. HTTP/1.1 بيعيد استخدام connections افتراضياً، و HTTP/2 يقدر يشارك connection بين streams. HTTP keep-alive مختلف عن TCP keepalive probes اللي بتكشف اتصال خامل ميت. إنشاء HttpClient بـ handler جديد لكل request بيهدر pools وممكن يستهلك ephemeral ports تحت الحمل.

المثال داخل .NET 10 application مع DI و Microsoft.Extensions.Http. resolve العميل بالـ factory؛ ماتحتفظش بـ factory-created client للأبد لو معتمد على handler rotation لتحديث DNS.

builder.Services.AddHttpClient("catalog", client =>
{
    client.BaseAddress = new Uri("https://catalog.example.com");
    client.Timeout = TimeSpan.FromSeconds(10); // (1)
}).ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler
{
    PooledConnectionLifetime = TimeSpan.FromMinutes(5), // (2)
    MaxConnectionsPerServer = 20 // (3)
});

// Inside a service receiving IHttpClientFactory factory:
using var client = factory.CreateClient("catalog");
using var response = await client.GetAsync("/products/42", cancellationToken);
response.EnsureSuccessStatusCode();

بديل صحيح: long-lived HttpClient مع SocketsHttpHandler و connection lifetime مناسبة. خلص أو dispose responses خصوصاً streaming علشان الموارد ترجع. retries لازم تبقى محدودة وآمنة للأثر، مش علاج تلقائي لكل timeout. إرشادات HttpClient.

#Cookies و Tokens و CORSCookies, tokens and CORS

cookie آلية تخزين وإرسال في المتصفح؛ token دليل هوية أوصلاحية، وممكن يتخزن في cookie. فالمقارنة مش نوعين متضادين. Secure يقيد إرسال cookie على HTTPS، و HttpOnly يمنع قراءتها من JavaScript، و SameSite بيقيد إرسالها في سياقات cross-site. HttpOnly مش مانع إن XSS ينفذ طلبات بصلاحيات المستخدم.

المثال raw response header؛ الـ session value لازم يطلع من نظام authentication، والقيمة هنا placeholder فقط.

Set-Cookie: session=SESSION_VALUE; Path=/; Secure; HttpOnly; SameSite=Lax

SameSite=None محتاج Secure للمتصفحات الحديثة، وسياسات third-party cookies ممكن تمنع الإرسال برضه. cookie auth محتاجة CSRF defense حسب السيناريو؛ bearer token صريح في Authorization مش بيتبعت تلقائياً بنفس الطريقة، لكن تخزينه المتاح لـ JavaScript بيزود أثر XSS.

CORS سياسة متصفح للسماح بقراءة responses بين origins. origin هي scheme و host و port، ومش هي site بالضبط. المثال registration و middleware داخل ASP.NET Core app؛ حطه بعد routing وقبل authorization.

builder.Services.AddCors(options => options.AddPolicy("store", policy =>
    policy.WithOrigins("https://shop.example.com") // (1)
        .WithMethods("GET", "POST")
        .WithHeaders("Content-Type")
        .AllowCredentials())); // (2)

// After builder.Build() and routing:
app.UseCors("store");

preflight عادة OPTIONS قبل طلب غير بسيط. CORS مش authentication ولا firewall؛ curl والـ server clients مش مقيدين بيها، وبعض الطلبات cross-origin بتتوصل حتى لو المتصفح منع قراءة الرد. CORS protocol.

#Caching headers و CompressionCaching headers and compression

cache صح بتقلل latency وحمل السيرفر، و cache غلط ممكن تسرب داتا مستخدم. max-age بيحدد freshness، و public يسمح shared cache، و private يخصصه للـ user cache. no-cache معناها لازم revalidation قبل إعادة الاستخدام، مش منع التخزين؛ no-store بيمنع التخزين. ETag مع If-None-Match ممكن يرجع 304 من غير body.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=60
ETag: "catalog-v8"
Vary: Accept-Encoding
Content-Encoding: br

[Brotli-compressed representation bytes]

المثال schematic لكتالوج عام؛ body المعروضة وصف للبايتات مش JSON قابل للإرسال. Vary يحدد request headers اللي تغير representation ومفتاح cache. compression بتتفاوض بـ Accept-Encoding، و br أو gzip بتوفر bandwidth مقابل CPU؛ الصور المضغوطة غالباً مش هتستفيد.

no-store مايمسحش نسخ قديمة اتخزنت بالفعل. invalidation وسياسات browser و CDN محتاجة تصميم متوافق. HTTP caching specification.

#Proxies و Load balancers و CDNsProxies, load balancers and CDNs

forward proxy بيمثل العميل في الخروج؛ reverse proxy بيمثل السيرفرات قدام العميل. load balancer بيوزع اتصالات أوطلبات؛ CDN بتقرب delivery من المستخدم وبتقدر تعمل cache و edge functions حسب المنتج.

TLS termination معناها إن فيه trust boundary جديدة بين proxy والتطبيق. اضبط trusted forwarded headers، وحدود body، و timeouts، و health checks. CDN cache للـ static assets مفيد، لكن cookies و Authorization و query parameters لازم تتفهم علشان cache key مايسربش داتا. sticky sessions مش بديل عن shared state، و load balancer مش بيضمن إن عملية دفع تتنفذ مرة واحدة.

#DNS records و TTL و IPv4 و IPv6 و NATDNS records, TTL, IPv4, IPv6 and NAT

DNS بيربط أسماء بمعلومات، مش مجرد URL بـ IP. TTL مدة السماح بتخزين record في cache، مش مدة الاتصال ولا ضمان إن كل العملاء هيحولوا في نفس اللحظة.

IPv4 عنوان 32-bit، و IPv6 عنوان 128-bit. private IPv4 ranges هي 10.0.0.0/8، و 172.16.0.0/12، و 192.168.0.0/16. loopback زي 127.0.0.1 مختلف عن private LAN. في IPv6 فيه loopback ::1، و unique-local تحت fc00::/7، و link-local تحت fe80::/10.

NAT بيترجم عناوين، و PAT بيشارك public IP باستخدام ports؛ ده مش encryption ولا بديل عن firewall. IPv6 مش معناه كل endpoint مفتوحة: policies لسه لازمة. في dual-stack اختبر العيلتين؛ AAAA غلط ممكن يعمل تأخير حتى لو A شغالة. تقليل TTL قبل failover مفيد، لكنه مش بيقفل connections قديمة موجودة في pools.

#WebSockets و SSE و أدوات التشخيصWebSockets, SSE and diagnostic tools

polling المتكرر بيهدر طلبات لما مفيش جديد. WebSocket بيوفر channel ثنائي الاتجاه برسائل فوق connection طويلة؛ SSE stream نصي من السيرفر للعميل باستخدام text/event-stream، والمتصفح بيدعم reconnect عبر EventSource. WebSocket مش محصور دائماً في HTTP/1.1 Upgrade؛ فيه آليات للإصدارات الأحدث حسب دعم الـ stack.

ASP.NET Core 10 بيوفر TypedResults.ServerSentEvents. في أي stream اضبط cancellation و backpressure و heartbeats و proxy buffering و idle timeouts؛ reconnect محتاج event IDs و replay policy لو فقد events مش مقبول.

الأوامر Bash مع curl؛ endpoint أمثلة وليست خدمة شغالة هنا. بعض flags زي HTTP/3 محتاجة curl build مناسب؛ افحص curl --version.

curl -I https://store.example.com/products/42       # (1)
curl -v --http2 https://store.example.com/products/42 # (2)
curl --compressed https://store.example.com/products/42
curl -N -H 'Accept: text/event-stream' \
  https://store.example.com/orders/42/events        # (3)
curl --resolve store.example.com:443:192.0.2.10 \
  https://store.example.com/products/42             # (4)

curl مش متصفح: نجاحه مش دليل على CORS أو cookie behavior في المتصفح. افصل اختبار DNS و TLS و HTTP و application behavior.