The Internet and the TCP/IP stackالإنترنت وحزمة TCP/IP

In part 02 a browser controlled a lamp with HTTP requests: PUT /lamp/state to switch it and GET /lamp/energy to read its energy. Each request started on a laptop on KFUPM Wi-Fi and had to reach a server that might sit in a data center on another continent. Neither program knew the path in between, and neither needed to. That is the whole point of the TCP/IP stack.

في الجزء 02 تحكّم متصفح في مصباح عبر طلبات HTTP: الطلب PUT /lamp/state لتشغيله أو إطفائه، والطلب GET /lamp/energy لقراءة استهلاكه من الطاقة. كل طلب بدأ من حاسوب محمول متصل بشبكة Wi-Fi في جامعة KFUPM، وكان عليه أن يصل إلى خادم قد يكون في مركز بيانات في قارة أخرى. لا أحد من البرنامجين يعرف المسار بينهما، ولا يحتاج أن يعرفه. وهذا بالضبط هو جوهر TCP/IP stack.

Every host runs the same set of layers, so a client and a server can exchange bytes as if a private pipe joined them. The stack has a single purpose: connectivity. A program should only have to say who it wants to talk to and what it wants to send. Everything else in this part (layers, PDUs, addresses, sockets) is simply how that one job gets done.

كل مضيف (host) يشغّل مجموعة الطبقات نفسها، لذلك يستطيع client وserver تبادل البايتات وكأن أنبوبًا خاصًا يصل بينهما. للحزمة هدف واحد فقط: الاتصالية (connectivity). يجب أن يكفي البرنامج أن يقول مع من يريد أن يتحدث وماذا يريد أن يرسل. وكل ما تبقى في هذا الجزء (الطبقات، ووحدات PDU، والعناوين، والـ sockets) هو ببساطة طريقة إنجاز هذه المهمة الواحدة.

Why split connectivity into layersلماذا نقسّم الاتصالية إلى طبقات

Hiding the path is a large job, far too large for one piece of software. Think about an air journey. You buy a ticket, check a bag, pass a gate, the plane takes off from a runway and air traffic control routes it. Each step relies on the step below it and offers a service to the step above. Kurose and Ross use exactly this example to motivate network layering.

إخفاء المسار مهمة كبيرة، أكبر بكثير من أن يتولاها برنامج واحد. فكّر في رحلة جوية: تشتري تذكرة، وتسلّم حقيبتك، وتعبر البوابة، ثم تقلع الطائرة من المدرج ويوجّهها مراقبو الحركة الجوية. كل خطوة تعتمد على الخطوة التي تحتها وتقدّم خدمة للخطوة التي فوقها. يستخدم Kurose وRoss هذا المثال بالضبط لتبرير تقسيم الشبكات إلى طبقات.

The Internet divides connectivity the same way. The stack has five layers, and each layer provides one well-defined service using its own protocols. The payoff is explicit structure and modularity: a layer can change how it works internally without the rest of the system noticing. Wi-Fi can be swapped for 5G, and HTTP does not change a single byte.

الإنترنت يقسّم الاتصالية بالطريقة نفسها. للحزمة خمس طبقات، وكل طبقة (layer) تقدّم خدمة واحدة محددة بوضوح باستخدام بروتوكولاتها (protocols) الخاصة. المكسب هو بنية صريحة ونمطية (modularity): تستطيع طبقة أن تغيّر طريقة عملها الداخلية دون أن يلاحظ بقية النظام. يمكن استبدال Wi-Fi بشبكة 5G، ولا يتغير في HTTP بايت واحد.

Read the plus signs as composition, not arithmetic. No single layer delivers a web page. Connectivity emerges only when all five cooperate, the same way no single airport worker delivers you to another city.

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

Five layers versus sevenخمس طبقات مقابل سبع

Part 02 used OSI as its example of a layered system, so it is worth lining the two models up. The OSI reference model (ITU-T X.200) defines seven layers. The Internet stack has no separate session or presentation layer. RFC 1122 says the Internet application layer essentially combines OSI presentation and application, and Kurose and Ross note that any such services must be implemented by the application itself.

استخدم الجزء 02 نموذج OSI مثالًا على نظام ذي طبقات، لذلك من المفيد أن نضع النموذجين جنبًا إلى جنب. النموذج المرجعي OSI (ITU-T X.200) يعرّف سبع طبقات. أما حزمة الإنترنت فليس فيها طبقة جلسة (session) ولا طبقة عرض (presentation) مستقلتان. يقول RFC 1122 إن طبقة التطبيق في الإنترنت تجمع أساسًا بين طبقتي العرض والتطبيق في OSI، ويشير Kurose وRoss إلى أن أي خدمات من هذا النوع يجب أن ينفذها التطبيق بنفسه.

The stack as the band between people and the physical worldالحزمة بوصفها الشريط الواصل بين الناس والعالم الفيزيائي

Now zoom out to a whole system. Picture a distance sensor such as the HC-SR04 wired to a Raspberry Pi Pico. The Pico reads a distance, a Wi-Fi-capable board sends it across the network, and a dashboard in a control room shows it to a person. A command can travel the other way, down to an actuator.

لنبتعد الآن ونرى نظامًا كاملًا. تخيّل حساس مسافة مثل HC-SR04 موصولًا بلوحة Raspberry Pi Pico. تقرأ الـ Pico المسافة، وترسلها لوحة تدعم Wi-Fi عبر الشبكة، ثم تعرضها لوحة متابعة (dashboard) في غرفة تحكم لشخص ما. ويمكن أن ينتقل أمر في الاتجاه المعاكس، نزولًا إلى مُشغِّل (actuator).

The five layers form a band in the middle of that picture. Users sit above it and the physical world of sensing and actuation sits below it. The dashboard does not need to know how bits cross the air, and the device does not need to know how the dashboard draws its charts. This is modularity again, now at the scale of an entire system.

الطبقات الخمس تشكّل شريطًا في منتصف هذه الصورة. المستخدمون فوقه، والعالم الفيزيائي للاستشعار والتشغيل تحته. لوحة المتابعة لا تحتاج أن تعرف كيف تعبر البتات الهواء، والـ device لا يحتاج أن يعرف كيف ترسم لوحة المتابعة رسومها البيانية. هذه هي النمطية (modularity) مرة أخرى، لكن على مستوى نظام كامل.

This is the same shape as the lamp system from part 02, and it is also the shape of your research project. In parts 08 to 10 the same pipeline is stretched across the edge to cloud continuum, and the question becomes where along it each piece of processing should run.

هذا هو الشكل نفسه لـ system المصباح من الجزء 02، وهو أيضًا شكل مشروعك البحثي. في الأجزاء من 08 إلى 10 يمتد خط المعالجة نفسه عبر سلسلة الحافة إلى السحابة (edge to cloud continuum)، ويصبح السؤال: في أي نقطة على هذا الخط يجب أن تُنفَّذ كل مرحلة من مراحل المعالجة؟

Layers cooperate by handing data to each other, and the way they do it is the single most useful mechanism in this part. Take a simple read request, GET /lamp HTTP/1.1. The application layer hands it down as a message. Transport puts a TCP header in front and it becomes a segment. Network adds an IP header and it becomes a packet. Data link adds a MAC header in front and a frame check sequence (a CRC) trailer behind, making a frame. Physical sends that frame as bits.

تتعاون الطبقات بتسليم البيانات بعضها إلى بعض، وطريقة ذلك هي أهم آلية مفيدة في هذا الجزء. خذ طلب قراءة بسيطًا: GET /lamp HTTP/1.1. طبقة application تسلّمه إلى الأسفل على شكل رسالة (message). طبقة Transport تضع ترويسة TCP في مقدمته فيصبح مقطعًا (segment). طبقة Network تضيف ترويسة IP فيصبح حزمة (packet). طبقة Data link تضيف ترويسة MAC في المقدمة وذيلًا (trailer) في النهاية هو تسلسل فحص الإطار (frame check sequence، أي CRC)، فيصبح إطارًا (frame). ثم ترسل طبقة Physical هذا الإطار على شكل بتات.

Each layer's unit of data is its protocol data unit (PDU). The process of wrapping is encapsulation, and it follows one rule: a PDU is this layer's header plus a payload, and the payload is the entire PDU of the layer above. On the receiving host the steps run in reverse. Each layer reads and removes its own header, then passes the payload up. Step through it yourself before reading on.

وحدة البيانات في كل طبقة تسمى وحدة بيانات البروتوكول (protocol data unit, PDU). وعملية التغليف تسمى encapsulation، وهي تتبع قاعدة واحدة: الـ PDU هو ترويسة هذه الطبقة مع حمولة (payload)، والحمولة هي الـ PDU الكامل للطبقة التي فوقها. على المضيف المستقبِل تجري الخطوات بالعكس: كل طبقة تقرأ ترويستها وتزيلها، ثم تمرر الحمولة إلى الأعلى. جرّب الخطوات بنفسك قبل أن تكمل القراءة.

Who reads which headerمن يقرأ أي ترويسة

Encapsulation is also what lets the middle of the network stay simple. Kurose and Ross label the headers Ht (transport), Hn (network) and Hl (link). A switch processes only the link and physical layers. A router processes network, link and physical. Only the two end hosts open the transport header and the application message. The IP header even carries a Protocol field that names the next-level protocol in its data (RFC 791, section 3.1), which is how the receiver knows whether to hand the payload to TCP or UDP.

التغليف هو أيضًا ما يسمح لوسط الشبكة أن يبقى بسيطًا. يرمز Kurose وRoss للترويسات بـ Ht (النقل) وHn (الشبكة) وHl (الربط). المبدّل (switch) يعالج طبقتي الربط والفيزيائية فقط. والموجّه (router) يعالج الشبكة والربط والفيزيائية. المضيفان الطرفيان وحدهما يفتحان ترويسة النقل ورسالة التطبيق. بل إن ترويسة IP تحمل حقلًا اسمه Protocol يسمّي بروتوكول المستوى التالي الموجود في بياناتها (RFC 791، القسم 3.1)، وبه يعرف المستقبِل هل يسلّم الحمولة إلى TCP أم إلى UDP.

These sizes come from RFC 791, RFC 9293 and RFC 768, and together they are the 40 bytes of layering overhead mentioned earlier. They also reveal a division of labor: IP has no acknowledgments, no retransmissions and no flow control (RFC 791, section 1.4). Reliability is added one layer up, by TCP, and only at the end hosts.

هذه الأحجام مأخوذة من RFC 791 وRFC 9293 وRFC 768، ومجموعها هو الـ 40 bytes من تكلفة الطبقات التي ذكرناها سابقًا. وهي تكشف أيضًا تقسيمًا للعمل: بروتوكول IP ليس فيه إشعارات استلام (acknowledgments)، ولا إعادة إرسال (retransmissions)، ولا تحكم في التدفق (flow control) (RFC 791، القسم 1.4). الموثوقية تُضاف في الطبقة التي فوقه بواسطة TCP، وعند المضيفين الطرفيين فقط.

The header table ended with an address column, and that column is not decoration. Each header names something different because each layer connects something different. Your laptop on campus loads a page from a cloud server. The path goes over one Wi-Fi hop to the access point, through several routers, and finally over a data-center link to the server. Along that path there is one conversation between two programs, one route between two machines, and many separate links.

انتهى جدول الترويسات بعمود للعناوين، وهذا العمود ليس للزينة. كل ترويسة تسمّي شيئًا مختلفًا لأن كل طبقة تربط شيئًا مختلفًا. حاسوبك المحمول في الحرم الجامعي يحمّل صفحة من خادم سحابي. يمر المسار عبر قفزة Wi-Fi واحدة إلى نقطة الوصول (access point)، ثم عبر عدة موجّهات، وأخيرًا عبر وصلة داخل مركز البيانات إلى الخادم. على طول هذا المسار توجد محادثة واحدة بين برنامجين، ومسار واحد بين جهازين، ووصلات (links) كثيرة منفصلة.

These are the three connection scopes. The transport layer provides an end-to-end (E2E) connection between two application processes. The network layer provides a host-to-host (H2H) path between two machines, however many routers lie between them. The data link layer handles point-to-point (P2P) transfer across a single hop between two directly attached interfaces.

هذه هي نطاقات الاتصال الثلاثة. transport layer توفّر اتصالًا من طرف إلى طرف (end-to-end, E2E) بين عمليتين من عمليات التطبيقات. network layer توفّر مسارًا من مضيف إلى مضيف (host-to-host, H2H) بين جهازين، مهما كان عدد الموجّهات بينهما. data link layer تتولى النقل من نقطة إلى نقطة (point-to-point, P2P) عبر قفزة واحدة بين واجهتين متصلتين مباشرة.

The rule to take away: the higher the layer, the wider its scope and the more virtual its connection. Only the P2P links are real cables or radio channels. The E2E connection is not a wire at all. It is state held in the two end hosts: RFC 9293 (section 3.3.1) describes the TCP control block that stores the local and remote IP addresses and ports. TCP creates that state with the three-way handshake (section 3.5), while IP itself is connectionless. UDP keeps no connection state at all, yet its datagrams are still delivered process to process.

القاعدة التي يجب أن تخرج بها: كلما ارتفعت الطبقة اتسع نطاقها وصار اتصالها أكثر افتراضية. وصلات P2P وحدها هي كابلات حقيقية أو قنوات راديو. أما اتصال E2E فليس سلكًا على الإطلاق، بل هو حالة (state) محفوظة في المضيفين الطرفيين: يصف RFC 9293 (القسم 3.3.1) كتلة تحكم TCP (TCP control block) التي تخزّن عناوين IP والمنافذ المحلية والبعيدة. يُنشئ TCP هذه الحالة عبر المصافحة الثلاثية (three-way handshake) (القسم 3.5)، بينما IP نفسه عديم الاتصال (connectionless). أما UDP فلا يحتفظ بأي حالة اتصال إطلاقًا، ومع ذلك تُسلَّم رسائله (datagrams) من عملية إلى عملية.

One address per scopeعنوان واحد لكل نطاق

If each scope connects a different kind of thing, each needs its own way to name that thing. Look back at the encapsulation stepper. The server is 3.120.0.10, the service on it is port 443, and the next hop's interface is f4:8c:50:2b:e1:04. Three addresses, one per scope.

إذا كان كل نطاق يربط نوعًا مختلفًا من الأشياء، فكل نطاق يحتاج طريقته الخاصة لتسمية هذا الشيء. ارجع إلى محاكي التغليف: الخادم هو 3.120.0.10، والخدمة عليه هي المنفذ 443، وواجهة القفزة التالية هي f4:8c:50:2b:e1:04. ثلاثة عناوين، عنوان لكل نطاق.

E2E names a process with a port number. H2H names a machine with an IP address. P2P names a network interface on the local link with a MAC address. (The course materials write "Mac"; the standard spelling is MAC, for Media Access Control.)

نطاق E2E يسمّي العملية (process) بـ port number. ونطاق H2H يسمّي الجهاز بـ IP address. ونطاق P2P يسمّي واجهة الشبكة على الوصلة المحلية بـ MAC address. (مواد المقرر تكتب "Mac"، والكتابة القياسية هي MAC، اختصارًا لـ Media Access Control.)

Ports are 16-bit fields in both TCP (RFC 9293) and UDP (RFC 768). IPv4 addresses are a fixed four octets (RFC 791, section 2.3). MAC addresses are 48 bits, burned into the NIC but sometimes settable in software, written like 1A-2F-BB-76-09-AD.

المنافذ حقول بطول 16-bit في كل من TCP (RFC 9293) وUDP (RFC 768). عناوين IPv4 طولها ثابت وهو أربعة أثمان (octets) (RFC 791، القسم 2.3). عناوين MAC طولها 48 بت، وهي محفورة في بطاقة الشبكة (NIC) لكن يمكن أحيانًا ضبطها برمجيًا، وتُكتب بالشكل 1A-2F-BB-76-09-AD.

What changes at each hopما الذي يتغير عند كل قفزة

Putting scopes and addresses together gives the most useful insight of this concept. Along the whole path, ignoring NAT, the source and destination IP addresses and ports stay the same, because their scopes span the whole path. The MAC addresses are replaced at every hop, because their scope is one link: each router strips the old frame and builds a new one for the next link. To build it, the router uses ARP (RFC 826) to map the next hop's IP address to its 48-bit Ethernet address.

جمع النطاقات والعناوين معًا يعطي أهم فكرة في هذا المفهوم. على طول المسار كاملًا، وبتجاهل NAT، تبقى عناوين IP والمنافذ للمصدر والوجهة كما هي، لأن نطاقاتها تمتد على المسار كله. أما عناوين MAC فتُستبدل عند كل قفزة، لأن نطاقها وصلة واحدة: كل موجّه ينزع الإطار القديم ويبني إطارًا جديدًا للوصلة التالية. ولبنائه يستخدم الموجّه بروتوكول ARP (RFC 826) ليحوّل عنوان IP للقفزة التالية إلى عنوان Ethernet الخاص بها بطول 48-bit.

Addresses name endpoints, but a conversation needs more than one name. Open two browser tabs to the same server. Both tabs run on one laptop with one IP address, and both talk to one server port. Yet every reply lands in the right tab. Something must tell the two conversations apart.

العناوين تسمّي نقاط النهاية، لكن المحادثة تحتاج أكثر من اسم واحد. افتح تبويبين في المتصفح على الخادم نفسه. كلا التبويبين يعملان على حاسوب محمول واحد بعنوان IP واحد، وكلاهما يتحدث إلى منفذ واحد على الخادم. ومع ذلك يصل كل رد إلى التبويب الصحيح. لا بد أن شيئًا ما يميّز المحادثتين عن بعضهما.

The general rule builds up in three steps. A socket is one endpoint, an IP address plus a port number. A connection is a pair of sockets, one at each end, which is exactly how RFC 9293 defines it. When networks need to tell flows apart, they add the protocol and use the 5-tuple, which RFC 6437 (section 3) lists as destination address, source address, protocol, destination port and source port. The protocol field is what separates a TCP flow from a UDP flow that happens to share the same addresses and ports.

القاعدة العامة تُبنى في ثلاث خطوات. الـ socket نقطة نهاية واحدة، أي IP address مع port number. والاتصال (connection) زوج من الـ sockets، واحد عند كل طرف، وهذا بالضبط تعريف RFC 9293 له. وعندما تحتاج الشبكات إلى التمييز بين التدفقات (flows)، تضيف البروتوكول وتستخدم الـ 5-tuple، الذي يذكره RFC 6437 (القسم 3) على أنه: عنوان الوجهة، وعنوان المصدر، والبروتوكول، ومنفذ الوجهة، ومنفذ المصدر. حقل البروتوكول هو ما يفصل تدفق TCP عن تدفق UDP يصادف أنه يشترك معه في العناوين والمنافذ نفسها.

Notice how this ties back to the scopes. The 5-tuple uses only the E2E and H2H addresses, the ones that survive the whole path. The MAC address plays no part in identifying a connection, because it covers only one hop and would change before the reply ever came back.

لاحظ كيف يرتبط هذا بالنطاقات. الـ 5-tuple يستخدم فقط عناوين E2E وH2H، أي العناوين التي تبقى على طول المسار كله. أما MAC address فلا دور له في تعريف الاتصال، لأنه يغطي قفزة واحدة فقط وسيتغير قبل أن يعود الرد أصلًا.

So far the layers have been abstractions. The last step is to find them inside a real computer. A Node.js server asks the operating system for a socket and gets back a file descriptor. It writes bytes to that descriptor. Inside the kernel, TCP and IP headers are added. A driver hands the finished frame to the network card, which turns it into electrical or radio signals.

حتى الآن كانت الطبقات مفاهيم مجردة. الخطوة الأخيرة هي أن نجدها داخل حاسوب حقيقي. خادم Node.js يطلب من نظام التشغيل socket فيحصل على واصف ملف (file descriptor). ثم يكتب البايتات في هذا الواصف. داخل النواة (kernel) تُضاف ترويستا TCP وIP. ثم يسلّم برنامج التشغيل (driver) الإطار المكتمل إلى بطاقة الشبكة، التي تحوّله إلى إشارات كهربائية أو راديوية.

That story maps the layers onto three parts of one machine. The application layer lives in application space: the browser or server process, including its HTTP library. The transport layer and network layer live in the operating system kernel. The data link layer and physical layer live in the network interface and its driver.

هذه القصة توزّع الطبقات على ثلاثة أجزاء من جهاز واحد. application layer تعيش في فضاء التطبيق: عملية المتصفح أو الخادم، بما فيها مكتبة HTTP الخاصة بها. transport layer وnetwork layer تعيشان في نواة نظام التشغيل. data link layer وphysical layer تعيشان في واجهة الشبكة وبرنامج تشغيلها.

Two seams separate these spaces. The socket API is the door between application and OS, which is why the socket of the previous concept is also a programming object. The Linux socket(7) manual calls sockets the uniform interface between the user process and the network protocol stacks in the kernel. Drivers are the door between OS and hardware. For the Web, the concrete stack reads: browser or server, HTTP, socket API, TCP, IP, Ethernet, then wired or wireless media.

حدّان فاصلان يفصلان هذه الفضاءات. socket API هو الباب بين التطبيق ونظام التشغيل، ولهذا فإن الـ socket في المفهوم السابق هو أيضًا كائن برمجي. دليل socket(7) في Linux يصف الـ sockets بأنها الواجهة الموحدة بين عملية المستخدم وحزم بروتوكولات الشبكة في النواة. أما برامج التشغيل (drivers) فهي الباب بين نظام التشغيل والعتاد. بالنسبة للويب، تُقرأ الحزمة الفعلية هكذا: المتصفح أو الخادم، ثم HTTP، ثم الـ socket API، ثم TCP، ثم IP، ثم Ethernet، ثم الوسط السلكي أو اللاسلكي.

The seams are also boundaries of privilege. An application cannot forge TCP state directly; it has to go through the socket API. This matters later in the course. Latency is added at every crossing, and virtual machines and containers in lecture 2 virtualize exactly these seams.

هذه الحدود الفاصلة هي أيضًا حدود صلاحيات (privilege). لا يستطيع التطبيق أن يزوّر حالة TCP مباشرة، بل يجب أن يمر عبر الـ socket API. وهذا مهم لاحقًا في المقرر: يُضاف Latency عند كل عبور، والأجهزة الافتراضية (virtual machines) والحاويات (containers) في المحاضرة 2 تعمل على محاكاة هذه الحدود بالذات افتراضيًا.