The physics of latencyفيزياء زمن الاستجابة (Latency)

Picture a student in Dhahran opening an app whose backend runs in the AWS Frankfurt region. His phone sends a request that must physically cross about 4,400 km of Earth, and the answer must cross it again on the way back. Nothing useful can happen on his screen until both trips are done.

تخيّل طالبا في الظهران يفتح تطبيقا تعمل خلفيته في منطقة AWS في فرانكفورت. يرسل هاتفه طلبا يجب أن يقطع فعليا نحو 4,400 km من سطح الأرض، ويجب أن يقطعها الرد مرة أخرى في طريق العودة. ولا يمكن أن يحدث شيء مفيد على شاشته حتى تكتمل الرحلتان.

Latency is transit time, paid in both directionsزمن الانتقال هو زمن العبور، ويُدفع في الاتجاهين

That travel time is Latency: the time data spends in transit between two points. In the Request-response loop you met earlier, the Client always starts, so every exchange pays latency twice: once from client to Server, once from server back to client. Total network latency is the sum of the two one-way figures. They are often close, but they need not be equal, because Internet routes are not always the same in both directions.

زمن الرحلة هذا هو latency (زمن الانتقال): الوقت الذي تقضيه البيانات في العبور بين نقطتين. في request-response loop (حلقة الطلب والاستجابة) التي رأيتها سابقا، يبدأ client (العميل) دائما، لذلك يدفع كل تبادل زمن الانتقال مرتين: مرة من العميل إلى server (الخادم)، ومرة من الخادم عائدا إلى العميل. زمن الانتقال الكلي في الشبكة هو مجموع القيمتين في الاتجاه الواحد. وكثيرا ما تكونان متقاربتين، لكن لا يلزم أن تتساويا، لأن مسارات الإنترنت ليست دائما واحدة في الاتجاهين.

Putting the server in the Cloud is the default because it is convenient, elastic and cheap to operate. The natural next question is how much time that choice costs at the very least, before any engineering detail enters the picture.

وضع الخادم في cloud (السحابة) هو الخيار الافتراضي لأنه مريح ومرن ورخيص في التشغيل. والسؤال الطبيعي التالي هو: كم من الوقت يكلّف هذا الخيار في أقل تقدير، قبل أن تدخل أي تفاصيل هندسية في الصورة؟

The smallest latency physics allowsأصغر زمن انتقال تسمح به الفيزياء

Start with a number. A server 3,000 km away, reached at the speed of light, needs 3,000 ÷ 300,000 = 0.01 s, which is 10 ms one way. So every 1,000 km costs at least 3.3 ms one way, or 6.7 ms for a round trip.

ابدأ برقم. خادم على بعد 3,000 km، يُوصَل إليه بسرعة الضوء، يحتاج إلى 3,000 ÷ 300,000 = 0.01 s، أي 10 ms في اتجاه واحد. إذن كل 1,000 km تكلّف على الأقل 3.3 ms في اتجاه واحد، أو 6.7 ms لرحلة الذهاب والإياب.

Generalising this gives the Latency lower bound: divide the Geodesic distance by the speed of light $c$. It is a lower bound for three reasons that stack. Nothing carries information faster than light. No cable between two cities can be shorter than the shortest path along the Earth. And the formula ignores every other delay a real packet meets. Because each simplification can only make the true figure larger, the result is a floor that no provider, protocol or hardware upgrade can break.

تعميم ذلك يعطينا latency lower bound (الحد الأدنى لزمن الانتقال): اقسم geodesic distance (المسافة الجيوديسية) على سرعة الضوء $c$. وهو حد أدنى لثلاثة أسباب تتراكم. لا شيء ينقل المعلومات أسرع من الضوء. ولا يمكن لأي كابل بين مدينتين أن يكون أقصر من أقصر مسار على سطح الأرض. والمعادلة تتجاهل كل تأخير آخر تواجهه الحزمة الحقيقية. ولأن كل تبسيط من هذه لا يمكنه إلا أن يجعل القيمة الحقيقية أكبر، فالنتيجة حد أدنى لا يستطيع أي مزوّد أو بروتوكول أو ترقية عتاد أن يكسره.

Real glass is slower than vacuumالزجاج الحقيقي أبطأ من الفراغ

“Speed of light” in the bound means light in a vacuum. Real links carry light through glass fiber with a refractive index of about 1.5, so the signal moves at roughly 200,000 km/s, about two thirds of $c$ (Grigorik, High Performance Browser Networking). Even a perfectly straight fiber therefore needs about 1.5× the bound. ITU-T G.114 plans 5 µs/km for optical fibre systems, which is 5 ms per 1,000 km, against 3.3 ms per 1,000 km at $c$. Keep both numbers in mind: the vacuum bound is the absolute floor, and the fiber floor is the realistic best case for a cabled network.

"سرعة الضوء" في الحد الأدنى تعني الضوء في الفراغ. أما الروابط الحقيقية فتحمل الضوء عبر ألياف زجاجية معامل انكسارها نحو 1.5، فتتحرك الإشارة بنحو 200,000 km/s، أي نحو ثلثي $c$ (Grigorik، High Performance Browser Networking). لذلك حتى الليف المستقيم تماما يحتاج إلى نحو 1.5× الحد الأدنى. وتعتمد التوصية ITU-T G.114 قيمة 5 µs/km لأنظمة الألياف الضوئية، أي 5 ms لكل 1,000 km، مقابل 3.3 ms لكل 1,000 km عند $c$. احفظ الرقمين: الحد في الفراغ هو الأرضية المطلقة، وحد الألياف هو أفضل حالة واقعية لشبكة مكوّنة من كابلات.

Try the simulator. Pick the Frankfurt preset and read the one-way bound, then read the round-trip value to see the number doubled. The presets use the distances implied by the lecture’s own figures (for example 11,100 km for Oregon), a choice examined closely when we compare bounds with measurements below.

جرّب المحاكي. اختر الإعداد المسبق لفرانكفورت واقرأ الحد الأدنى في اتجاه واحد، ثم اقرأ قيمة رحلة الذهاب والإياب لترى الرقم مضاعفا. تستخدم الإعدادات المسبقة المسافات التي تدل عليها أرقام المحاضرة نفسها (مثلا 11,100 km لأوريغون)، وهو اختيار سندرسه عن قرب عندما نقارن الحدود الدنيا بالقياسات أدناه.

The bound is only as good as the distance you feed it, so which distance is the right one? Stretch a string tight between London and Singapore on a real globe. It does not run across Arabia the way a ruler on a flat map suggests. It runs north, over Eastern Europe and Central Asia. Now flatten that globe into a rectangle: the string that was the shortest path turns into a curve.

الحد الأدنى لا يكون جيدا إلا بقدر جودة المسافة التي تُدخلها فيه، فأي مسافة هي الصحيحة؟ شُدّ خيطا مشدودا بين لندن وسنغافورة على كرة أرضية حقيقية. لن يمر عبر الجزيرة العربية كما توحي المسطرة على خريطة مسطحة، بل يتجه شمالا فوق أوروبا الشرقية وآسيا الوسطى. والآن افرد هذه الكرة إلى مستطيل: الخيط الذي كان أقصر مسار يتحول إلى منحنى.

Those are the two candidates. A straight line drawn on the flat map gives the planar distance. The curve that the string traces gives the Geodesic distance between the same two endpoints. Esri’s documentation defines planar distance as straight-line Euclidean distance in a 2D Cartesian coordinate system, and geodesic distance as distance across the curved surface of the world in 3D. Signals travel over the real Earth, not over a map, so latency lives in the second definition.

هذان هما المرشحان. الخط المستقيم المرسوم على الخريطة المسطحة يعطي المسافة المستوية (planar). أما المنحنى الذي يرسمه الخيط فيعطي geodesic distance (المسافة الجيوديسية) بين النقطتين نفسيهما. وتعرّف وثائق Esri المسافة المستوية بأنها المسافة الإقليدية في خط مستقيم ضمن نظام إحداثيات ديكارتي ثنائي الأبعاد، والمسافة الجيوديسية بأنها المسافة عبر سطح العالم المنحني في ثلاثة أبعاد. والإشارات تنتقل فوق الأرض الحقيقية لا فوق خريطة، لذلك ينتمي زمن الانتقال إلى التعريف الثاني.

Map projections stretch the Earth, and the stretch grows with latitude and with the size of the area. Over a city block the two distances agree. Over continents they can disagree a lot, and near the equator they can be surprisingly close: Esri notes that for Singapore to Nairobi, about 7,440 km, the Web Mercator planar result is less than a metre longer. Because you cannot know in advance which case you are in, always use the geodesic when you compute a Latency lower bound. Using a planar distance that happens to be too short would even produce a “bound” that is not a bound at all.

إسقاطات الخرائط تمطّ الأرض، ويزداد هذا المطّ مع خط العرض ومع اتساع المنطقة. على مستوى حيّ في مدينة تتفق المسافتان. وعبر القارات قد تختلفان كثيرا، وقرب خط الاستواء قد تتقاربان على نحو مفاجئ: تذكر Esri أن المسافة من سنغافورة إلى نيروبي، نحو 7,440 km، تكون نتيجتها المستوية في إسقاط Web Mercator أطول بأقل من متر واحد. ولأنك لا تستطيع أن تعرف مسبقا في أي حالة أنت، استخدم دائما المسافة الجيوديسية عندما تحسب latency lower bound. بل إن استخدام مسافة مستوية تصادف أنها أقصر من اللازم سينتج "حدا أدنى" ليس حدا أدنى أصلا.

With the right distance and the right formula in hand, the bound can finally meet reality. Put the client in Dammam and the server in three AWS regions: US West (Oregon, us-west-2), Europe (Frankfurt, eu-central-1) and Asia Pacific (Tokyo, ap-northeast-1). For each, compute the one-way Latency lower bound, then compare it with the Round-trip time (RTT) measured with aws-latency-test.com.

بعد أن صارت لدينا المسافة الصحيحة والمعادلة الصحيحة، يمكن أخيرا أن يلتقي الحد الأدنى بالواقع. ضع العميل في الدمام والخادم في ثلاث مناطق من AWS: غرب الولايات المتحدة (أوريغون، us-west-2)، وأوروبا (فرانكفورت، eu-central-1)، وآسيا والمحيط الهادئ (طوكيو، ap-northeast-1). لكل منطقة احسب latency lower bound في اتجاه واحد، ثم قارنه بـ RTT المقيس باستخدام aws-latency-test.com.

The rule behind the example: compare like with like. An RTT is a round trip, so compare it with twice the one-way bound, never with the one-way figure itself. Doing that for all three regions tells the same story each time: the measurements sit about 2.9× to 3.4× above the vacuum round-trip bound. A ratio that stable across very different distances is a hint that the extra cost is systematic, not bad luck on one path.

القاعدة وراء المثال: قارن الشيء بنظيره. الـ RTT رحلة ذهاب وإياب، فقارنه بضعف الحد الأدنى في اتجاه واحد، ولا تقارنه أبدا بقيمة الاتجاه الواحد نفسها. وعند فعل ذلك للمناطق الثلاث تتكرر القصة نفسها كل مرة: القياسات تقع فوق الحد الأدنى لرحلة الذهاب والإياب في الفراغ بنحو 2.9× إلى 3.4×. ونسبة بهذا الثبات عبر مسافات مختلفة جدا تلمّح إلى أن التكلفة الإضافية منهجية، لا مجرد سوء حظ على مسار واحد.

Where the factor of three comes fromمن أين يأتي معامل الثلاثة

• About 1.5× comes from glass alone, because light in fiber moves at about two thirds of $c$.نحو 1.5× يأتي من الزجاج وحده، لأن الضوء في الألياف يتحرك بنحو ثلثي $c$.
• Cables do not follow the geodesic. They follow coastlines and seabeds, land at a few stations, and backhaul over land to data centers.الكابلات لا تتبع المسار الجيوديسي. إنها تتبع السواحل وقيعان البحار، وترسو في عدد قليل من المحطات، ثم تُنقل برّا (backhaul) إلى مراكز البيانات.
• Each router on the way adds processing and queueing time, two of the four delays in the next concept.كل موجّه (router) في الطريق يضيف زمن معالجة وزمن انتظار في الطابور، وهما اثنان من التأخيرات الأربعة في المفهوم التالي.

Research agrees with this breakdown. Singla and colleagues measured Internet paths worldwide and found router paths about 2.3× the speed-of-light latency at the median. After removing the 1.5× fiber factor, path detours alone still leave about 1.53×.

والأبحاث تتفق مع هذا التقسيم. فقد قاس Singla وزملاؤه مسارات الإنترنت حول العالم ووجدوا أن مسارات الموجّهات تبلغ نحو 2.3× زمن الانتقال بسرعة الضوء عند الوسيط. وبعد إزالة معامل الألياف 1.5×، تظل انحرافات المسار وحدها تترك نحو 1.53×.

The factor of three needs a precise vocabulary. Follow one 1,500-byte packet across one router onto a 4,390 km fiber link running at 1 Gbps. Pushing its 12,000 bits onto the wire takes 12,000 ÷ 10⁹ s = 12 µs. Travelling the fiber takes about 22 ms. The router’s own work takes microseconds. Waiting behind other packets takes anything from nothing to a very long time. Now slow the link to 10 Mbps: pushing the bits out now takes 1.2 ms, and the fiber trip is still 22 ms.

معامل الثلاثة يحتاج إلى مفردات دقيقة. تتبّع حزمة واحدة حجمها 1,500-byte تعبر موجّها واحدا إلى رابط ألياف طوله 4,390 km ويعمل بسرعة 1 Gbps. دفع بتاتها البالغة 12,000 إلى السلك يستغرق 12,000 ÷ 10⁹ s = 12 µs. والسفر عبر الألياف يستغرق نحو 22 ms. وعمل الموجّه نفسه يستغرق ميكروثواني. أما الانتظار خلف الحزم الأخرى فيستغرق أي مدة من لا شيء إلى وقت طويل جدا. والآن أبطئ الرابط إلى 10 Mbps: دفع البتات يستغرق الآن 1.2 ms، ورحلة الألياف ما زالت 22 ms.

Those four pieces are the four packet delays, and Kurose and Ross (section 1.4) add them up at every node a packet crosses. Processing delay happens inside switches and routers. Queueing delay happens in buffers when traffic piles up. Transmission delay happens at the network interface and depends on bandwidth. Propagation delay happens on the physical channel and depends on distance. Only the last one is the physics behind the lower bound; the other three are what real equipment and real traffic add on top.

هذه القطع الأربع هي التأخيرات الأربعة للحزمة، ويجمعها Kurose وRoss (القسم 1.4) عند كل عقدة تعبرها الحزمة. processing delay (تأخير المعالجة) يحدث داخل المبدّلات والموجّهات. queueing delay (تأخير الانتظار في الطابور) يحدث في المخازن المؤقتة عندما تتكدس حركة المرور. transmission delay (تأخير الإرسال) يحدث عند واجهة الشبكة ويعتمد على عرض النطاق. propagation delay (تأخير الانتشار) يحدث على القناة الفيزيائية ويعتمد على المسافة. والأخير وحده هو الفيزياء التي وراء الحد الأدنى، أما الثلاثة الأخرى فهي ما تضيفه المعدات الحقيقية وحركة المرور الحقيقية فوقه.

End to end, you add the nodal delay over every hop on the path, and an RTT adds it again for the return direction. That sum is exactly the measured RTT from Dammam, which is why it sits so far above 2d/c. Hold on to the contrast that exams love: transmission depends on packet size and bandwidth and has nothing to do with distance, while propagation depends on distance and the medium and has nothing to do with bandwidth.

من الطرف إلى الطرف تجمع التأخير العُقدي على كل قفزة في المسار، ويضيفه RTT مرة أخرى لاتجاه العودة. وهذا المجموع هو بالضبط RTT المقيس من الدمام، ولهذا يقع بعيدا جدا فوق 2d/c. وتمسّك بالمقابلة التي تحبها الاختبارات: الإرسال يعتمد على حجم الحزمة وعرض النطاق ولا علاقة له بالمسافة، بينما الانتشار يعتمد على المسافة والوسط ولا علاقة له بعرض النطاق.

Can it really be 100 times the bound?هل يمكن حقا أن يبلغ 100 ضعف الحد الأدنى؟

The lecture claims Internet latency can reach 100× the Latency lower bound. For whole page loads, measurements support this. Singla and colleagues found that fetching just the HTML of popular web pages took 34× the round-trip speed-of-light latency at the median and 169× at the 90th percentile. Those fetches include more than the four per-hop delays: a DNS lookup, the TCP handshake and TCP’s slow start all add round trips. The lecture’s example of a 15 ms theoretical latency turning into 1,500 ms is best read the same way: an illustration of network delays stacked with protocol and application effects, not four delays on a single link.

تقول المحاضرة إن زمن الانتقال في الإنترنت قد يبلغ 100× latency lower bound. وبالنسبة لتحميل صفحات كاملة، تدعم القياسات ذلك. فقد وجد Singla وزملاؤه أن جلب ملف HTML وحده لصفحات ويب شائعة استغرق 34× زمن الانتقال بسرعة الضوء لرحلة الذهاب والإياب عند الوسيط، و169× عند المئين 90th. وهذه العمليات تشمل أكثر من التأخيرات الأربعة لكل قفزة: استعلام DNS، ومصافحة TCP، وبدء TCP البطيء (slow start)، وكلها تضيف رحلات ذهاب وإياب. ومثال المحاضرة عن زمن انتقال نظري 15 ms يتحول إلى 1,500 ms يُفهم أفضل بالطريقة نفسها: توضيح لتأخيرات الشبكة متراكمة مع تأثيرات البروتوكولات والتطبيقات، لا أربعة تأخيرات على رابط واحد.