diff options
Diffstat (limited to 'files/ar/web/http/overview/index.html')
| -rw-r--r-- | files/ar/web/http/overview/index.html | 167 |
1 files changed, 167 insertions, 0 deletions
diff --git a/files/ar/web/http/overview/index.html b/files/ar/web/http/overview/index.html new file mode 100644 index 0000000000..d727b8cc7f --- /dev/null +++ b/files/ar/web/http/overview/index.html @@ -0,0 +1,167 @@ +--- +title: نظرة عامة عن HTTP +slug: Web/HTTP/Overview +translation_of: Web/HTTP/Overview +--- +<div>بروتكول ال HTTP هو {{Glossary("protocol")}} يسمح بجلب الموارد, مثل مستندات HTML. انه الأساس لتبادل أي بيانات على الويب بالأضافة من أنه يعمل كبروتوكول خادم-عميل, والذي يعني من أن الطلبات تبدأ من قبل العميل نفسه باستخدام المتصفح. يتم إعادة بناء المستند الكامل من مختلف الملفات الفرعية المجلوبة. على سبيل المثال, النص و و صف التنسيق و الصور و مقاطع الفيديو و الملفات النصية و الكثير... </div> + +<p><img alt="A Web document is the composition of different resources" src="https://mdn.mozillademos.org/files/13677/Fetching_a_page.png" style="height: 319px; width: 545px;"></p> + +<p>العملاء و الخادم يتواصلون من خلال تبادل الرسائل الفردية (على عكس تدفق البيانات). يتم إرسال الرسائل من العميل نفسه, باستخدام متصفح الإنترنت على سبيل المثال, و يتم استدعاء البيانات التي تم ارسالها الى الخادم كجواب عن تلك الرسائل التي ارسلت من العميل.</p> + +<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png" style="float: left; height: 299px; padding-bottom: 15px; padding-right: 20px; width: 418px;">تم تصميم HTTP في أوائل التسعينيات ، وهو بروتوكول قابل للتوسيع تطور بمرور الوقت. إنه بروتوكول يعمل من خلال طبقة التطبيقات يتم إرساله عبر {{Glossary("TCP")}}, ، أو عبر اتصال TCP مشفر بواسطة {{Glossary("TLS")}}- ، على الرغم من أنه يمكن نظريًا استخدام أي بروتوكول نقل موثوق. نظرًا لقابليته للتوسعة ، فإنه لا يستخدم فقط لجلب مستندات النص التشعبي ، ولكن أيضًا الصور ومقاطع الفيديو أو لنشر المحتوى على الخوادم ، كما هو الحال مع نتائج نماذج HTML. يمكن أيضًا استخدام HTTP لجلب أجزاء من المستندات لتحديث صفحات الويب عند الطلب.</p> + +<h2 id="مكونات_الأنظمة_المستندة_إلى_الأنظمةHTTP"> مكونات الأنظمة المستندة إلى الأنظمةHTTP</h2> + +<p>HTTP هو بروتوكول خادم عميل: يتم إرسال الطلبات بواسطة كيان واحد أو وكيل المستخدم (أو وكيل نيابة عنه). في معظم الأحيان يكون وكيل المستخدم مستعرض ويب ، ولكن يمكن أن يكون أي شيء ، على سبيل المثال روبوت يزحف إلى الويب لملء فهرس محرك البحث والحفاظ عليه.</p> + +<p>يتم إرسال كل طلب فردي إلى الخادم الذي يتعامل معه ويقدم إجابة تسمى الاستجابة. بين العميل والخادم ، هناك العديد من الكيانات ، التي تسمى مجتمعة {{Glossary("Proxy_server", "proxies")}} ، والتي تؤدي عمليات مختلفة وتعمل كبوابات أو {{Glossary("Cache", "caches")}} ، على سبيل المثال.</p> + +<p><img alt="Client server chain" src="https://mdn.mozillademos.org/files/13679/Client-server-chain.png"></p> + +<p>في الحقيقة, هناك العديد من أجهزة الكمبيوتر بين المتصفح وبين الخادم الذي يعمل على معالجة الطلبات: هناك الراوترز, المودمز, و الكثير. شكرا لمصمم طبقات شبكات الويب, هذه مخفية في طبقات الشبكة والنقل. HTTP في القمة, عند طبقة التطبيقات. على الرغم من أهمية تشخيص مشاكل الشبكة ، إلا أن الطبقات الأساسية لا علاقة لها في الغالب بوصف HTTP.</p> + +<h3 id="العميل_وكيل_المستخدم">العميل: وكيل المستخدم</h3> + +<p>وكيل المستخدم هو أي أداة تعمل نيابة عن المستخدم. يتم تنفيذ هذا الدور بشكل أساسي بواسطة مستعرض الويب; الاحتمالات الأخرى هي البرامج التي يستخدمها المهندسون ومطورو الويب لتصحيح أخطاء تطبيقاتهم.</p> + +<p>المستعرض هو دائمًا الكيان الذي يبدأ الطلب. إنه ليس الخادم أبدًا (على الرغم من إضافة بعض الآليات على مر السنين لمحاكاة الرسائل التي يبدأها الخادم).</p> + +<p>لتقديم صفحة ويب ، يرسل المستعرض طلبًا أصليًا لجلب مستند HTML الذي يمثل الصفحة. يقوم بعد ذلك بتحليل هذا الملف ، وتقديم طلبات إضافية تتوافق مع البرامج النصية للتنفيذ ، ومعلومات التخطيط (CSS) لعرضها ، والموارد الفرعية الموجودة في الصفحة (عادةً الصور ومقاطع الفيديو). يقوم مستعرض الويب بعد ذلك بمزج هذه الموارد ليقدم للمستخدم مستندًا كاملاً ، صفحة الويب. يمكن للنصوص التي ينفذها المتصفح جلب المزيد من الموارد في مراحل لاحقة ويقوم المتصفح بتحديث صفحة الويب وفقًا لذلك.</p> + +<p>صفحة الويب هي مستند نص تشعبي. هذا يعني أن بعض أجزاء النص المعروض عبارة عن روابط يمكن تنشيطها (عادةً بنقرة الماوس) لجلب صفحة ويب جديدة ، مما يسمح للمستخدم بتوجيه وكيل المستخدم الخاص به والتنقل عبر الويب. يترجم المستعرض هذه الاتجاهات في طلبات HTTP ، ويفسر استجابات HTTP بشكل أكبر لتقديم استجابة واضحة للمستخدم</p> + +<h3 id="The_Web_server">The Web server</h3> + +<p>على الجانب الآخر من قناة الاتصال ، يوجد الخادم ، الذي يخدم المستند حسب طلب العميل. يظهر الخادم كجهاز واحد فقط افتراضيًا: هذا لأنه قد يكون في الواقع مجموعة من الخوادم ، أو مشاركة الحمل (موازنة التحميل) أو قطعة معقدة من البرامج تستجوب أجهزة الكمبيوتر الأخرى (مثل ذاكرة التخزين المؤقت ، أو خادم قاعدة البيانات ، أو التجارة الإلكترونية الخوادم) ، لإنشاء المستند كليًا أو جزئيًا عند الطلب.</p> + +<p>ليس بالضرورة أن يكون الخادم جهازًا واحدًا ، ولكن يمكن استضافة العديد من مثيلات برنامج الخادم على نفس الجهاز. باستخدام HTTP / 1.1 ورأس {{HTTPHeader ("Host")}} ، يمكنهم أيضًا مشاركة عنوان IP نفسه.</p> + +<h3 id="Proxies">Proxies</h3> + +<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://blogs.bmc.com/wp-content/uploads/2018/06/osi-model-7-layers-1024x734.jpg" style="float: left; height: 400px; width: 400px;">بين متصفح الويب والخادم ، تقوم العديد من أجهزة الكمبيوتر والآلات بنقل رسائل HTTP.. نظرًا للهيكل متعدد الطبقات لمكدس الويب ، يعمل معظمها على مستوى النقل أو الشبكة أو المستوى المادي ، وتصبح شفافة في طبقة HTTP ويحتمل أن يكون لها تأثير كبير على الأداء<span>. </span>تسمى تلك التي تعمل في طبقات التطبيق عمومًا الوكلاء(<strong>proxies)</strong><span>. </span>يمكن أن تكون هذه شفافة ، حيث يتم إعادة توجيه الطلبات التي يتلقونها دون تغييرها بأي شكل من الأشكال ، أو غير شفافة ، وفي هذه الحالة سوف يقومون بتغيير الطلب بطريقة ما قبل تمريره إلى الخادم. قد تؤدي الوكلاء وظائف عديدة<span>:</span></p> + +<ul> + <li>التخزين المؤقت (يمكن أن تكون ذاكرة التخزين المؤقت عامة أو خاصة ، مثل ذاكرة التخزين المؤقت للمتصفح)</li> + <li>التصفية (مثل فحص مكافحة الفيروسات أو المراقبة الأبوية)</li> + <li>موازنة الحمل (للسماح لخوادم متعددة بخدمة الطلبات المختلفة)</li> + <li>المصادقة (للتحكم في الوصول إلى الموارد المختلفة)</li> + <li>التسجيل (السماح بتخزين المعلومات التاريخية)</li> +</ul> + +<h2 id="الجوانب_الأساسية_لـ_HTTP">الجوانب الأساسية لـ HTTP</h2> + +<h3 id="HTTP_بسيط">HTTP بسيط</h3> + +<p>تم تصميم HTTP بشكل عام ليكون بسيطًا وقابل للقراءة البشرية ، حتى مع التعقيد الإضافي المقدم في HTTP / 2 عن طريق تغليف رسائل HTTP في إطارات. يمكن قراءة رسائل HTTP وفهمها من قبل البشر ، مما يوفر اختبارًا أسهل للمطورين ، ويقلل من التعقيد للقادمين الجدد.</p> + +<h3 id="HTTP_قابل_للتوسيع">HTTP قابل للتوسيع</h3> + +<p>المقدمة في, <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a> HTTP هذا البروتوكول سهل التوسيع والتجربة. يمكن أيضًا تقديم وظائف جديدة من خلال اتفاقية بسيطة بين العميل والخادم حول دلالات الرأس الجديدة.</p> + +<h3 id="HTTP_عديم_الحالة_،_ولكن_ليس_بدون_جلسات">HTTP عديم الحالة ، ولكن ليس بدون جلسات</h3> + +<p>HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.</p> + +<h3 id="HTTP_والاتصالات">HTTP والاتصالات</h3> + +<p>على الرغم من أن HTTP لا يتطلب أن يكون بروتوكول النقل الأساسي قائمًا على الاتصال ؛ فقط تتطلب أن تكون موثوقة ، أو لا تفقد الرسائل (لذلك على الأقل تقديم خطأ). من بين بروتوكولي النقل الأكثر شيوعًا على الإنترنت ، يعتبر TCP موثوقًا و UDP ليس كذلك. لذلك يعتمد HTTP على معيار TCP ، الذي يعتمد على التوصيل.</p> + +<p>قبل أن يتمكن العميل والخادم من تبادل زوج طلب / استجابة HTTP ، يجب عليهم إنشاء اتصال TCP ، وهي عملية تتطلب عدة رحلات ذهابًا وإيابًا. السلوك الافتراضي لـ HTTP / 1.0 هو فتح اتصال TCP منفصل لكل زوج من طلبات / استجابة HTTP. هذا أقل كفاءة من مشاركة اتصال TCP واحد عندما يتم إرسال طلبات متعددة في تتابع قريب.</p> + +<p>من أجل التخفيف من هذا الخلل ، قدم HTTP / 1.1 خطوط الأنابيب (التي ثبت صعوبة تنفيذها) والتوصيلات المستمرة: يمكن التحكم في اتصال TCP الأساسي جزئيًا باستخدام الرأس {{HTTPHeader ("Connection")}}. تقدمت HTTP / 2 خطوة إلى الأمام من خلال تعدد إرسال الرسائل عبر اتصال واحد ، مما يساعد في الحفاظ على الاتصال دافئًا وأكثر كفاءة.</p> + +<p>التجارب جارية لتصميم بروتوكول نقل أفضل أكثر ملاءمة لـ HTTP. على سبيل المثال ، تقوم Google بالتجربة مع <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a> الذي يعتمد على UDP لتوفير بروتوكول نقل أكثر موثوقية وفعالية.</p> + +<h2 id="ما_يمكن_التحكم_فيه_عن_طريق_HTTP">ما يمكن التحكم فيه عن طريق HTTP</h2> + +<p>هذه الطبيعة القابلة للتوسيع لـ HTTP ، بمرور الوقت ، سمحت بمزيد من التحكم والوظائف على الويب. تم التعامل مع طرق التخزين المؤقت أو المصادقة في وقت مبكر في سجل HTTP. على النقيض من ذلك ، تمت إضافة القدرة على تخفيف قيود الأصل فقط في 2010.</p> + +<p>فيما يلي قائمة بالميزات الشائعة التي يمكن التحكم فيها باستخدام HTTP.</p> + +<ul> + <li><em><a href="/en-US/docs/Web/HTTP/Caching">Caching</a> </em>يمكن التحكم في كيفية تخزين المستندات مؤقتًا بواسطة HTTP. يمكن للخادم توجيه الوكلاء والعملاء ، حول ما يجب تخزينه مؤقتًا ومدة ذلك. يمكن للعميل توجيه وكلاء ذاكرة التخزين المؤقت الوسيطة لتجاهل المستند المخزن.</li> + <li>To <em>Relaxing the origin constraint</em> لمنع التطفل وانتهاكات الخصوصية الأخرى ، تفرض متصفحات الويب الفصل الصارم بين مواقع الويب. يمكن فقط للصفحات من نفس الأصل الوصول إلى كافة المعلومات الخاصة بصفحة الويب. على الرغم من أن هذا القيد يمثل عبئًا على الخادم ، إلا أن رؤوس HTTP يمكن أن تخفف هذا الفصل الصارم على جانب الخادم ، مما يسمح للمستند بأن يصبح خليطًا من المعلومات التي يتم الحصول عليها من مجالات مختلفة ؛ يمكن أن تكون هناك أسباب أمنية للقيام بذلك.</li> + <li><em>Authentication</em><br> + Some pages may be protected so that only specific users can access them. Basic authentication may be provided by HTTP, either using the {{HTTPHeader("WWW-Authenticate")}} and similar headers, or by setting a specific session using <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>.</li> + <li><em><a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling">Proxy and tunneling</a></em>غالبًا ما توجد الخوادم أو العملاء على شبكات إنترانت وتخفي عنوان IP الحقيقي الخاص بهم عن أجهزة الكمبيوتر الأخرى. تنتقل طلبات HTTP بعد ذلك عبر الوكلاء لعبور حاجز الشبكة هذا. ليست كل الوكلاء عبارة عن وكلاء HTTP. بروتوكول SOCKS ، على سبيل المثال ، يعمل بمستوى أدنى. البروتوكولات الأخرى ، مثل بروتوكول نقل الملفات ، يمكن التعامل معها بواسطة هذه البروتوكولات.</li> + <li><em>Sessions</em>يتيح لك استخدام ملفات تعريف الارتباط HTTP ربط الطلبات بحالة الخادم. يؤدي هذا إلى إنشاء جلسات ، على الرغم من أن HTTP الأساسي هو بروتوكول بدون حالة. هذا مفيد ليس فقط لسلة التسوق في التجارة الإلكترونية ، ولكن أيضًا لأي موقع يسمح للمستخدم بتكوين المخرجات.</li> +</ul> + +<h2 id="HTTP_flow">HTTP flow</h2> + +<p>When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:</p> + +<ol> + <li>Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.</li> + <li>Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these simple messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. For example: + <pre class="line-numbers language-html notranslate"><code class="language-html">GET / HTTP/1.1 +Host: developer.mozilla.org +Accept-Language: fr</code></pre> + </li> + <li>Read the response sent by the server, such as: + <pre class="line-numbers language-html notranslate"><code class="language-html">HTTP/1.1 200 OK +Date: Sat, 09 Oct 2010 14:28:02 GMT +Server: Apache +Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT +ETag: "51142bc1-7449-479b075b2891b" +Accept-Ranges: bytes +Content-Length: 29769 +Content-Type: text/html + +<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)</code></pre> + </li> + <li>Close or reuse the connection for further requests.</li> +</ol> + +<p>If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.</p> + +<h2 id="HTTP_Messages">HTTP Messages</h2> + +<p>HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a <em>frame</em>, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.</p> + +<p>There are two types of HTTP messages, requests and responses, each with its own format.</p> + +<h3 id="Requests">Requests</h3> + +<p>An example HTTP request:</p> + +<p><img alt="A basic HTTP request" src="https://mdn.mozillademos.org/files/13687/HTTP_Request.png" style="height: 336px; width: 693px;"></p> + +<p>Requests consists of the following elements:</p> + +<ul> + <li>An HTTP <a href="/en-US/docs/Web/HTTP/Methods">method</a>, usually a verb like {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} or a noun like {{HTTPMethod("OPTIONS")}} or {{HTTPMethod("HEAD")}} that defines the operation the client wants to perform. Typically, a client wants to fetch a resource (using <code>GET</code>) or post the value of an <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML form</a> (using <code>POST</code>), though more operations may be needed in other cases.</li> + <li>The path of the resource to fetch; the URL of the resource stripped from elements that are obvious from the context, for example without the {{Glossary("protocol")}} (<code>http://</code>), the {{Glossary("domain")}} (here, <code>developer.mozilla.org</code>), or the TCP {{Glossary("port")}} (here, <code>80</code>).</li> + <li>The version of the HTTP protocol.</li> + <li>Optional <a href="/en-US/docs/Web/HTTP/Headers">headers</a> that convey additional information for the servers.</li> + <li>Or a body, for some methods like <code>POST</code>, similar to those in responses, which contain the resource sent.</li> +</ul> + +<h3 id="Responses">Responses</h3> + +<p>An example response:</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13691/HTTP_Response.png" style="height: 494px; width: 758px;"></p> + +<p>Responses consist of the following elements:</p> + +<ul> + <li>The version of the HTTP protocol they follow.</li> + <li>A <a href="/en-US/docs/Web/HTTP/Status">status code</a>, indicating if the request was successful, or not, and why.</li> + <li>A status message, a non-authoritative short description of the status code.</li> + <li>HTTP <a href="/en-US/docs/Web/HTTP/Headers">headers</a>, like those for requests.</li> + <li>Optionally, a body containing the fetched resource.</li> +</ul> + +<h2 id="APIs_based_on_HTTP">APIs based on HTTP</h2> + +<p>The most commonly used API based on HTTP is the {{domxref("XMLHttpRequest")}} API, which can be used to exchange data between a {{Glossary("user agent")}} and a server. The modern {{domxref("Fetch API")}} provides the same features with a more powerful and flexible feature set.</p> + +<p>Another API, <a href="/en-US/docs/Web/API/Server-sent_events">server-sent events</a>, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the {{domxref("EventSource")}} interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate {{domxref("Event")}} objects, delivering them to the event handlers that have been registered for the events' {{domxref("Event.type", "type")}} if known, or to the {{domxref("EventSource.onmessage", "onmessage")}} event handler if no type-specific event handler was established.</p> + +<h2 id="Conclusion">Conclusion</h2> + +<p>HTTP is an extensible protocol that is easy to use. The client-server structure, combined with the ability to simply add headers, allows HTTP to advance along with the extended capabilities of the Web.</p> + +<p>Though HTTP/2 adds some complexity, by embedding HTTP messages in frames to improve performance, the basic structure of messages has stayed the same since HTTP/1.0. Session flow remains simple, allowing it to be investigated, and debugged with a simple <a href="/en-US/docs/Tools/Network_Monitor">HTTP message monitor</a>.</p> |