Sockets and web app architectureالمقابس (Sockets) ومعمارية تطبيقات الويب

Think about what your browser does when you open the KFUPM portal. It cannot put signals on the Wi-Fi radio or build TCP segments by itself. Instead it makes a few requests to the operating system: open a connection to this address and port, send these bytes, give me whatever comes back. The operating system does everything below that. Understanding exactly what that request looks like is the foundation for everything else in this part.

فكّر فيما يفعله متصفحك عندما تفتح بوابة KFUPM. هو لا يستطيع أن يضع إشارات على راديو الـ Wi-Fi أو أن يبني مقاطع TCP (segments) بنفسه. بدلًا من ذلك يقدّم بضعة طلبات إلى نظام التشغيل: افتح اتصالًا إلى هذا العنوان وهذا الـ port، أرسل هذه البايتات، وأعطني ما يعود منها. ونظام التشغيل يتولى كل ما هو تحت ذلك. فهم الشكل الدقيق لهذا الطلب هو الأساس لكل ما يأتي بعده في هذا الجزء.

An API is a menu, and the socket API is the networking menuالـ API قائمة طعام، والـ socket API هي قائمة الشبكات

The set of operations one piece of software offers to another is an Application Programming Interface, or API. Earlier in this lecture you saw that a relationship between components is a protocol plus an Interface. Here the interface sits between the Application layer (your program) and the Transport layer (TCP and UDP inside the operating system). For networking, that interface is the Socket API.

مجموعة العمليات التي يقدّمها برنامج لبرنامج آخر تُسمّى واجهة برمجة التطبيقات (Application Programming Interface)، أو اختصارًا API. رأيت سابقًا في هذه المحاضرة أن العلاقة بين المكوّنات هي protocol زائد interface. هنا تقع الواجهة بين application layer (برنامجك) وtransport layer (TCP وUDP داخل نظام التشغيل). وفي مجال الشبكات، هذه الواجهة هي الـ socket API.

Kurose and Ross describe the socket as the door between the application process and TCP. As a developer you control everything on the application side of that door, and you have very little control over the transport side. The rest of this concept opens the door and looks at what is actually there.

يصف Kurose وRoss الـ socket بأنه الباب بين عملية التطبيق (application process) وTCP. بصفتك مطوّرًا، أنت تتحكم في كل شيء على جهة التطبيق من هذا الباب، ولديك تحكم ضئيل جدًا في جهة النقل (transport). بقية هذا المفهوم تفتح هذا الباب وتنظر إلى ما يوجد خلفه فعلًا.

What a program actually holds: a file descriptorما الذي يمسكه البرنامج فعلًا: file descriptor

Make it concrete. In C, calling socket() returns a small integer, for example 3. From then on the program writes write(3, ...) exactly as it would for an open file. POSIX states that when the descriptor refers to a socket, write() is equivalent to send() with no flags, and the Linux manual says the only difference between recv() and read() is the flags argument.

لنجعل الأمر ملموسًا. في لغة C، استدعاء socket() يُرجع عددًا صحيحًا صغيرًا، مثلًا 3. ومن تلك اللحظة يكتب البرنامج write(3, ...) تمامًا كما يفعل مع ملف مفتوح. ينص POSIX على أنه عندما يشير الـ descriptor إلى socket، فإن write() يكافئ send() بدون أي flags، ويقول دليل Linux إن الفرق الوحيد بين recv() وread() هو وسيط الـ flags.

So to a program, a Socket is an operating system object that it reads and writes like a file. The kernel takes the bytes you write and turns them into TCP segments or UDP datagrams, which is why the application never needs to know how either protocol works. Be careful with the words: the socket API is the interface, and a socket is the endpoint that the API creates and names.

إذن، بالنسبة إلى البرنامج، الـ socket هو كائن من كائنات نظام التشغيل يقرأ منه ويكتب فيه كأنه ملف. الـ kernel يأخذ البايتات التي تكتبها ويحوّلها إلى مقاطع TCP (segments) أو إلى datagrams من نوع UDP، ولهذا لا يحتاج التطبيق أبدًا إلى معرفة كيف يعمل أي من البروتوكولين. انتبه للمصطلحات: الـ socket API هي الواجهة (interface)، أما الـ socket فهو نقطة الطرف (endpoint) التي تنشئها هذه الـ API وتسمّيها.

Naming the endpoint: the socket addressتسمية نقطة الطرف: عنوان الـ socket

A file on disk has a path; a socket has an address: an IP address plus a Port number, for example 10.0.0.5:443. The IP address finds the host and the port finds the process on that host, the same two-level addressing you met with the TCP/IP stack. RFC 9293 identifies a TCP connection by a pair of sockets, one at each end, so a connection is really four numbers: client IP and port, server IP and port.

الملف على القرص له مسار، والـ socket له عنوان: وهو IP address زائد port number، مثلًا 10.0.0.5:443. عنوان الـ IP يحدد الجهاز (host)، والـ port يحدد العملية على ذلك الجهاز، وهي نفس العنونة على مستويين التي قابلتها مع حزمة TCP/IP. تعرّف RFC 9293 اتصال TCP بزوج من الـ sockets، واحد في كل طرف، لذا فالاتصال في الحقيقة أربعة أرقام: IP العميل وport العميل، وIP الخادم وport الخادم.

One more ingredient completes the name. The protocol is fixed when the socket is created, so TCP port 53 and UDP port 53 are different endpoints even on the same host. DNS, as RFC 1035 specifies, listens on both.

هناك عنصر إضافي يكمل الاسم. البروتوكول يُحدَّد لحظة إنشاء الـ socket، ولذلك فإن port 53 في TCP وport 53 في UDP هما نقطتا طرف مختلفتان حتى على الجهاز نفسه. والـ DNS، كما تنص RFC 1035، يستمع على الاثنين.

The lifecycle of a connectionدورة حياة الاتصال

A Server and a Client play different roles, so they use different calls. The server must be findable before anyone arrives: it creates a socket, binds it to a well-known address, marks it as listening, then accepts connections one by one. The client already knows where to go, so it only creates a socket and connects. Once connected, both sides send and receive, then close.

الـ server والـ client يلعبان دورين مختلفين، ولذلك يستخدمان استدعاءات مختلفة. الخادم يجب أن يكون قابلًا للعثور عليه قبل أن يصل أي أحد: ينشئ socket، ويربطه (bind) بعنوان معروف، ويعلّمه على أنه في وضع الاستماع (listening)، ثم يقبل الاتصالات واحدًا تلو الآخر. أما العميل فيعرف مسبقًا إلى أين يذهب، فهو فقط ينشئ socket ويتصل (connect). وبعد الاتصال يرسل الطرفان ويستقبلان، ثم يُغلقان.

Once you know a program holds a socket, the next decision is which kind. Take two jobs. First, downloading a 2 GB dataset for your project: one missing byte corrupts the file, so every byte must arrive, in order. Second, a live video call: a voice frame that arrives 1 s late is useless, so waiting for it to be resent makes the call worse, not better. These two jobs need different sockets, and the difference is fixed the moment socket() is called.

بعد أن عرفت أن البرنامج يمسك socket، فالقرار التالي هو: أي نوع منه؟ خذ مهمتين. الأولى: تنزيل مجموعة بيانات حجمها 2 GB لمشروعك. بايت واحد مفقود يفسد الملف، لذا يجب أن يصل كل بايت، وبالترتيب. الثانية: مكالمة فيديو مباشرة. إطار صوتي يصل متأخرًا 1 s لا فائدة منه، لذا فانتظار إعادة إرساله يجعل المكالمة أسوأ لا أفضل. هاتان المهمتان تحتاجان إلى نوعين مختلفين من الـ sockets، وهذا الفرق يُحدَّد في اللحظة التي يُستدعى فيها socket().

Two services behind the same APIخدمتان خلف الـ API نفسها

A TCP socket is a stream socket. RFC 9293 describes TCP as a reliable, in-order, byte-stream service. It sets up a connection with a three-way handshake, numbers every byte, checks it with a checksum and retransmits what is lost. That reliability costs setup time and state on both hosts, which is exactly the connection that listen(), connect() and accept() manage.

الـ socket من نوع TCP هو stream socket. تصف RFC 9293 بروتوكول TCP بأنه خدمة موثوقة، تحافظ على الترتيب، وتنقل تيارًا من البايتات (byte stream). يُنشئ اتصالًا عبر مصافحة ثلاثية (three-way handshake)، ويرقّم كل بايت، ويتحقق منه بـ checksum، ويعيد إرسال ما يُفقد. هذه الموثوقية تكلّف وقتًا للإعداد وحالة (state) محفوظة على الجهازين، وهذا بالضبط هو الاتصال الذي تديره listen() وconnect() وaccept().

A UDP socket is a datagram socket. RFC 768 says UDP offers a minimum of protocol mechanism: delivery and duplicate protection are not guaranteed, and the header is just four 16-bit fields (source Port number, destination port, length, checksum), 8 bytes in total. There is no listen or accept: each datagram stands alone. POSIX names the two kinds SOCK_STREAM and SOCK_DGRAM.

الـ socket من نوع UDP هو datagram socket. تقول RFC 768 إن UDP يقدّم الحد الأدنى من آليات البروتوكول: التسليم والحماية من التكرار غير مضمونين، والـ header مجرد أربعة حقول كل منها 16 بت (port المصدر، وport الوجهة، والطول، والـ checksum)، أي 8 بايتات إجمالًا. لا يوجد listen ولا accept: كل datagram قائم بذاته. ويسمّي POSIX النوعين SOCK_STREAM وSOCK_DGRAM.

Choosing a socket for a workloadاختيار الـ socket المناسب لحِمل العمل

The right question is not which is faster. Ask what happens to your application when one unit of data is lost or late. If it must be recovered, use TCP. If late data is worthless, or the exchange is tiny and easy to retry, UDP avoids overhead that buys you nothing. For interactive media this is really about Latency: a retransmitted frame arrives after its moment has passed.

السؤال الصحيح ليس: أيهما أسرع؟ اسأل: ماذا يحدث لتطبيقك عندما تُفقد وحدة بيانات واحدة أو تتأخر؟ إذا كان لا بد من استرجاعها، فاستخدم TCP. وإذا كانت البيانات المتأخرة بلا قيمة، أو كان التبادل صغيرًا وسهل الإعادة، فإن UDP يجنّبك كلفة إضافية لا تكسب منها شيئًا. وفي الوسائط التفاعلية، المسألة في حقيقتها مسألة latency: الإطار المعاد إرساله يصل بعد أن فات وقته.

The last row of that table shows that the choice is not always binary. RFC 9114 defines HTTP/3 as the same HTTP semantics over a new transport, QUIC, and RFC 9000 says QUIC packets are carried in UDP datagrams. QUIC rebuilds reliable streams, flow control and encryption in user space on top of UDP. So choosing UDP does not always mean giving up reliability. It means a protocol or library above UDP decides how much reliability to add, and when.

الصف الأخير في ذلك الجدول يبيّن أن الاختيار ليس ثنائيًا دائمًا. تعرّف RFC 9114 بروتوكول HTTP/3 بأنه دلالات (semantics) HTTP نفسها فوق طبقة نقل جديدة هي QUIC، وتقول RFC 9000 إن حزم QUIC تُحمل داخل UDP datagrams. يعيد QUIC بناء التيارات الموثوقة (reliable streams) والتحكم في التدفق (flow control) والتشفير في user space فوق UDP. إذن اختيار UDP لا يعني دائمًا التخلي عن الموثوقية. بل يعني أن بروتوكولًا أو مكتبة فوق UDP هي التي تقرر كم من الموثوقية تضيف، ومتى.

Now bring sockets to the web. You type https://uni.majid.app and press Enter. The browser resolves the name, asks the operating system to open a TCP connection to port 443 (or QUIC over UDP for HTTP/3), sends the HTTP request, reads the response, and may reuse the same connection for the next requests. The page code only calls fetch("/api/...") and never sees a Socket.

الآن لننقل الـ sockets إلى الويب. تكتب https://uni.majid.app وتضغط Enter. يحلّ المتصفح الاسم، ثم يطلب من نظام التشغيل فتح اتصال TCP إلى port 443 (أو QUIC فوق UDP في حالة HTTP/3)، ويرسل طلب HTTP، ويقرأ الاستجابة، وقد يعيد استخدام الاتصال نفسه للطلبات التالية. أما كود الصفحة فلا يفعل إلا استدعاء fetch("/api/...")، ولا يرى أي socket أبدًا.

The browser owns the client socketالمتصفح هو من يملك الـ client socket

A web application is a Network application in which the browser is the Client program and owns the client socket: when to open it, reuse it and close it. MDN puts it simply: browsers communicate with web servers using HTTP, by sending a request to the server. Every socket call from the lifecycle above is still happening, just inside the browser and inside the server runtime.

تطبيق الويب هو network application يكون فيه المتصفح هو برنامج الـ client، ويملك الـ client socket: متى يفتحه، ومتى يعيد استخدامه، ومتى يغلقه. تقولها MDN ببساطة: المتصفحات تتواصل مع خوادم الويب باستخدام HTTP، عن طريق إرسال طلب إلى الخادم. كل استدعاءات الـ socket من دورة الحياة السابقة ما زالت تحدث، لكنها تحدث داخل المتصفح وداخل بيئة تشغيل الخادم (server runtime).

This changes the level at which you work. Frontend code for the World Wide Web is written in terms of HTTP requests, and backend code is written in terms of routes that answer them. The socket becomes infrastructure you rely on rather than an object you manage.

هذا يغيّر المستوى الذي تعمل عليه. كود الـ frontend في World Wide Web يُكتب بلغة طلبات HTTP، وكود الـ backend يُكتب بلغة الـ routes التي تجيب عنها. ويصبح الـ socket بنية تحتية تعتمد عليها، لا كائنًا تديره بنفسك.

Three components: client, server, databaseثلاثة مكوّنات: العميل، والخادم، وقاعدة البيانات

So what is on the other end of that connection? Picture a course portal. You submit a homework answer. The browser sends a request over the Internet. The server checks it and writes a row to the database. When you reopen the page later, the server reads that row and sends it back in a response.

إذن ما الذي يوجد في الطرف الآخر من ذلك الاتصال؟ تخيّل بوابة مقرر دراسي. أنت ترسل إجابة واجب. يرسل المتصفح طلبًا عبر الإنترنت. يتحقق الخادم منه ويكتب صفًا (row) في قاعدة البيانات. وعندما تعيد فتح الصفحة لاحقًا، يقرأ الخادم ذلك الصف ويعيده إليك في استجابة.

The pieces have names. The Frontend is one Component: the client. The Backend is two components: the Server and the database. The client talks only to the server, never directly to the database. MDN describes the same flow: on a request, the server fetches data from the database and builds the response. This is the Request-response loop you met with network applications, and the client always starts it.

لهذه الأجزاء أسماء. الـ frontend هو component واحد: العميل. والـ backend مكوّنان: الـ server وقاعدة البيانات. العميل يتحدث مع الخادم فقط، ولا يتحدث مع قاعدة البيانات مباشرة أبدًا. وتصف MDN التدفق نفسه: عند وصول طلب، يجلب الخادم البيانات من قاعدة البيانات ويبني الاستجابة. هذه هي request-response loop التي قابلتها مع تطبيقات الشبكة، والعميل هو من يبدؤها دائمًا.

Look at the server to database link closely, because it reuses everything from the first concept. It is itself a client-server connection over sockets, with the web server acting as the database client. Writes flow from server to database and reads flow back. A web application is therefore a chain of socket conversations, each with its own client and server role.

انظر بدقة إلى الرابط بين الخادم وقاعدة البيانات، لأنه يعيد استخدام كل شيء من المفهوم الأول. فهو بحد ذاته اتصال client-server عبر sockets، يكون فيه خادم الويب هو عميل قاعدة البيانات. عمليات الكتابة تتدفق من الخادم إلى قاعدة البيانات، وعمليات القراءة تعود في الاتجاه المعاكس. إذن تطبيق الويب سلسلة من المحادثات عبر الـ sockets، لكل منها دور العميل ودور الخادم الخاصان بها.

Why server and database often live apartلماذا يعيش الخادم وقاعدة البيانات غالبًا منفصلين

• They scale separately: many identical server instances can share one carefully managed database.يتوسّعان بشكل مستقل: يمكن لعدد كبير من نسخ الخادم المتطابقة أن تتشارك قاعدة بيانات واحدة تُدار بعناية.
• Their resource needs differ: the server wants CPU, the database wants disk and memory.احتياجاتهما من الموارد مختلفة: الخادم يحتاج إلى CPU، وقاعدة البيانات تحتاج إلى القرص والذاكرة.
• The database can be kept off the public Internet, reachable only from the servers.يمكن إبقاء قاعدة البيانات بعيدًا عن الإنترنت العام، بحيث لا يصل إليها إلا الخوادم.

This is the first placement decision on the edge-to-cloud continuum. Later parts ask where the server and the database should each live, and every placement has a cost: each read or write between separate machines adds its own network Round-trip time (RTT), which later feeds into Response time (RT).

هذا هو أول قرار توزيع (placement) على سلسلة الـ edge-to-cloud continuum. الأجزاء اللاحقة تسأل أين يجب أن يعيش كل من الخادم وقاعدة البيانات، ولكل توزيع ثمن: كل عملية قراءة أو كتابة بين جهازين منفصلين تضيف RTT شبكيًا خاصًا بها، وهذا يدخل لاحقًا في response time.

The architecture becomes real when you read the code on each side. Consider a calculator running in the browser and the backend that serves it. Walk one request through: the user opens the About view, and the frontend sends GET /calculadora/about.

تصبح البنية حقيقية عندما تقرأ الكود في كل جهة. خذ آلة حاسبة تعمل في المتصفح، والـ backend الذي يخدمها. تتبّع طلبًا واحدًا: المستخدم يفتح صفحة About، فيرسل الـ frontend الطلب GET /calculadora/about.

From request to handler to responseمن الطلب إلى الـ handler إلى الاستجابة

On the Backend, the framework compares the request method and path against its routes. It finds the route with method GET and path /calculadora/about and calls its handler, handler(request, h). The handler builds an object with a message field and returns it. In hapi, a returned plain object becomes the response payload, serialized as JSON. The browser receives that JSON in the HTTP response body and the Frontend renders it.

في الـ backend، يقارن الـ framework الـ method والـ path في الطلب بالـ routes المسجلة لديه. فيجد الـ route الذي الـ method فيه GET والـ path فيه /calculadora/about، ويستدعي الـ handler الخاص به، handler(request, h). يبني الـ handler كائنًا (object) فيه حقل message ويُرجعه. في hapi، الكائن العادي الذي يُرجَع يصبح هو محتوى الاستجابة (payload)، مُحوَّلًا إلى JSON. يستقبل المتصفح هذا الـ JSON في جسم استجابة الـ HTTP، ويعرضه الـ frontend.

The general rule: a route is a method plus a path plus a handler. The set of routes a backend exposes is its Web API, the Interface the frontend programs against, while HTTP is the Protocol carried between them. Protocol plus interface again, one level higher than the socket API. Underneath, the Node.js runtime owns a listening socket and one connection socket per Client, exactly the welcoming door picture from the first concept.

القاعدة العامة: الـ route هو method زائد path زائد handler. ومجموعة الـ routes التي يكشفها الـ backend هي الـ Web API الخاصة به، أي الـ interface التي يبرمج الـ frontend بالاعتماد عليها، بينما HTTP هو الـ protocol المنقول بينهما. مرة أخرى protocol زائد interface، لكن في مستوى أعلى بدرجة من الـ socket API. وتحت ذلك كله، تملك بيئة تشغيل Node.js listening socket واحدًا وconnection socket واحدًا لكل client، وهي بالضبط صورة باب الاستقبال من المفهوم الأول.

Same language, different machinesاللغة نفسها، وأجهزة مختلفة

Notice the languages. The frontend uses HTML for structure, CSS for presentation and JavaScript for behaviour, all inside the browser. The backend also runs JavaScript, but in the Node.js runtime on the Server. Same language, different processes on different machines, joined only by HTTP over a socket.

لاحظ اللغات. الـ frontend يستخدم HTML للبنية، وCSS للعرض، وJavaScript للسلوك، وكلها داخل المتصفح. والـ backend يشغّل JavaScript أيضًا، لكن داخل بيئة تشغيل Node.js على الـ server. اللغة نفسها، لكن في عمليات مختلفة على أجهزة مختلفة، لا يربطها إلا HTTP فوق socket.