تستخدم Google تكنولوجيا الذكاء الاصطناعي لترجمة المحتوى إلى لغتك المفضّلة، وقد تتضمّن بعض الأخطاء.

مرجع خصائص نقاط النهاية

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

يتناول هذا الموضوع خصائص النقل التي يمكن ضبطها في إعدادات TargetEndpoint وProxyEndpoint للتحكّم في سلوك المراسلة والاتصال. للحصول على تغطية كاملة لإعدادات TargetEndpoint وProxyEndpoint، راجِع مرجع إعدادات خادم وكيل لواجهة برمجة التطبيقات.

خصائص النقل TargetEndpoint

يحدّد العنصر HTTPTargetConnection في إعدادات TargetEndpoint مجموعة من خصائص نقل البيانات عبر HTTP. يمكنك استخدام هذه الخصائص لضبط إعدادات على مستوى النقل.

يتم ضبط الخصائص على عناصر TargetEndpoint HTTPTargetConnection كما هو موضّح أدناه:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="supports.http10">true</Property>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
    <CommonName>COMMON_NAME_HERE</CommonName>
  </HTTPTargetConnection>
</TargetEndpoint>

مواصفات السمة transport الخاصة بـ TargetEndpoint

اسم السمة	القيمة التلقائية	الوصف
`keepalive.timeout.millis`	`60000`	مهلة عدم النشاط للاتصال المستهدف في مجموعة الاتصالات إذا كان الاتصال في مجموعة الاتصالات غير نشط لمدة تتجاوز الحدّ المحدّد، سيتم إغلاقه.
`connect.timeout.millis`	`3000`	انتهت مهلة الاتصال بالوجهة. يعرض Edge رمز حالة HTTP `503` في حال حدوث مهلة انتهاء الاتصال. في بعض الحالات، قد يتم عرض رمز الحالة HTTP 504 عند استخدام `LoadBalancer` في تعريف TargetServer وحدوث مهلة. ملاحظة: في بعض الحالات، ستعيد Apigee تلقائيًا محاولة الاتصال ثلاث مرات كحد أقصى. نتيجةً لذلك، قد يتجاوز إجمالي وقت إعادة المحاولة الوقت الذي تم ضبطه لـ `connect.timeout.millis`.
`io.timeout.millis`	`55000`	إذا لم تتوفّر بيانات للقراءة خلال عدد الملّي ثانية المحدّد، أو إذا لم يكن المقبس جاهزًا لكتابة البيانات خلال عدد الملّي ثانية المحدّد، سيتم التعامل مع المعاملة على أنّها مهلة. في حال حدوث مهلة أثناء كتابة طلب HTTP، يتم عرض `408, Request Timeout`. في حال حدوث مهلة أثناء قراءة استجابة HTTP، يتم عرض `504, Gateway Timeout`. يجب أن تكون هذه القيمة دائمًا أصغر من قيمة السمة proxy_read_timeout الخاصة بالمضيف الظاهري. يجب أن تكون هذه القيمة أقل من المهلة التي يستخدمها جهاز التوجيه للتواصل مع معالج الرسائل. لمزيد من المعلومات، راجِع ضبط مهلة جهاز التوجيه. راجِع ضبط io.timeout.millis وapi.timeout في Edge للحصول على مزيد من المعلومات.
`supports.http10`	`true`	إذا كان هذا هو `true` وأرسل العميل طلبًا بالإصدار 1.0، سيتم أيضًا إرسال طلب بالإصدار 1.0 إلى الهدف. بخلاف ذلك، يتم إرسال طلب الإصدار 1.1 إلى الهدف.
`supports.http11`	`true`	إذا كان هذا هو `true` وأرسل العميل طلبًا بالإصدار 1.1، سيتم أيضًا إرسال طلب بالإصدار 1.1 إلى الهدف، وإلا سيتم إرسال طلب بالإصدار 1.0 إلى الهدف.
`use.proxy`	`true`	إذا تم ضبطها على `true` وتم تحديد إعدادات الخادم الوكيل في `http.properties` (عمليات النشر المحلية فقط)، سيتم ضبط الاتصالات المستهدَفة لاستخدام الخادم الوكيل المحدّد.
`use.proxy.tunneling`	`true`	إذا تم ضبط هذا الخيار على `true`، وتم تحديد إعدادات الخادم الوكيل في `http.properties` (عمليات النشر المحلية فقط)، يتم ضبط اتصالات الاستهداف لاستخدام النفق المحدّد. إذا كان الهدف يستخدم بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL)، يتم تجاهل هذه السمة، ويتم دائمًا إرسال الرسالة عبر نفق.
`enable.method.override`	`false`	بالنسبة إلى طريقة HTTP المحدّدة، يتم ضبط عنوان `X-HTTP-Method-Override` على الطلب الصادر إلى الخدمة المستهدَفة. على سبيل المثال، `<Property name="GET.override.method">POST</Property>`
`*.override.method`	لا ينطبق	بالنسبة إلى طريقة HTTP المحدّدة، يتم ضبط عنوان `X-HTTP-Method-Override` على الطلب الصادر. على سبيل المثال، `<Property name="GET.override.method">POST</Property>`
`request.streaming.enabled`	`false`	تلقائيًا (`false`)، تتم قراءة حمولات طلبات HTTP في مخزن مؤقت، وتعمل السياسات التي يمكنها العمل على الحمولة على النحو المتوقّع. في الحالات التي تكون فيها حمولات البيانات أكبر من حجم ذاكرة التخزين المؤقت (10 ميغابايت)، يمكنك ضبط هذه السمة على `true`. عندما تكون القيمة `true`، لا تتم قراءة حمولات طلبات HTTP في مخزن مؤقت، بل يتم بثها كما هي إلى نقطة النهاية المستهدَفة. في هذه الحالة، يتم تجاوز أي سياسات تعمل على الحمولة في مسار طلب TargetEndpoint. راجِع أيضًا طلبات وبلاغات البث.
`response.streaming.enabled`	`false`	بشكل تلقائي (`false`)، تتم قراءة حمولات استجابة HTTP في مخزن مؤقت، وتعمل السياسات التي يمكنها العمل على الحمولة على النحو المتوقّع. في الحالات التي تكون فيها حمولات البيانات أكبر من حجم ذاكرة التخزين المؤقت (10 ميغابايت)، يمكنك ضبط هذه السمة على `true`. عند استخدام `true`، لا تتم قراءة حمولات استجابة HTTP في مخزن مؤقت، بل يتم بثها كما هي إلى مسار استجابة ProxyEndpoint. في هذه الحالة، يتم تجاوز أي سياسات تعمل على الحمولة في مسار استجابة TargetEndpoint. راجِع أيضًا طلبات البث والاستجابات.
`success.codes`	لا ينطبق	تتعامل Apigee Edge تلقائيًا مع الرمز `4XX` أو `5XX` في بروتوكول HTTP على أنّهما خطأ، وتتعامل مع الرموز `1XX` و`2XX` و`3XX` على أنّها رموز نجاح. تتيح هذه السمة تحديد رموز النجاح بشكل صريح، فعلى سبيل المثال، تعتبر `2XX, 1XX, 505` أي رموز استجابة HTTP `100` و`200` و`505` ناجحة. يؤدي ضبط هذه السمة إلى استبدال القيم التلقائية. لذلك، إذا أردت إضافة رمز HTTP `400` إلى قائمة رموز النجاح التلقائية، اضبط هذه السمة على النحو التالي: <Property name="success.codes">1XX,2XX,3XX,400</Property> إذا كنت تريد أن يتم التعامل مع رمز HTTP `400` فقط كرمز ناجح، اضبط السمة على النحو التالي: <Property name="success.codes">400</Property> من خلال ضبط رمز HTTP `400` كرمز النجاح الوحيد، يتم التعامل مع الرموز `1XX` و`2XX` و`3XX` على أنّها رموز تعذّر.
`compression.algorithm`	لا ينطبق	بشكلٍ تلقائي، تعيد Apigee Edge توجيه الطلبات إلى الهدف باستخدام نوع الضغط نفسه الذي يستخدمه طلب العميل. إذا تم تلقّي الطلب من العميل باستخدام، على سبيل المثال، ضغط gzip، يعيد Apigee Edge توجيه الطلب إلى الهدف باستخدام ضغط gzip. إذا كان الردّ الذي تم تلقّيه من الهدف يستخدم deflate، ستعيد Apigee Edge توجيه الردّ إلى العميل باستخدام deflate. القيمتان المسموح بهما هما: gzip: إرسال الرسالة دائمًا باستخدام ضغط gzip deflate: إرسال الرسالة دائمًا باستخدام ضغط deflate بدون ضغط: إرسال الرسالة دائمًا بدون أي ضغط راجِع أيضًا: هل تتيح Apigee إمكانية الضغط/فك الضغط باستخدام GZIP/deflate؟
`request.retain.headers. enabled`	`true`	تحتفظ Apigee Edge تلقائيًا بجميع عناوين HTTP في الرسائل الصادرة. عند ضبطها على `true`، يتم ضبط جميع عناوين HTTP المتوفّرة في الطلب الوارد على الطلب الصادر.
`request.retain.headers`	لا ينطبق	تحدّد هذه السياسة عناوين HTTP معيّنة من الطلب يجب ضبطها على الطلب الصادر إلى الخدمة المستهدَفة. على سبيل المثال، لتمرير عنوان passthrough `User-Agent`، اضبط قيمة `request.retain.headers` على `User-Agent`. يتم تحديد عناوين HTTP المتعددة كقائمة مفصولة بفواصل، على سبيل المثال، `User-Agent,Referer,Accept-Language`. تؤدي هذه السمة إلى إلغاء `request.retain.headers.enabled`. إذا تم ضبط `request.retain.headers.enabled` على `false`، سيتم ضبط أي عناوين محددة في السمة `request.retain.headers` على الرسالة الصادرة.
`response.retain.headers. enabled`	`true`	تحتفظ Apigee Edge تلقائيًا بجميع عناوين HTTP في الرسائل الصادرة. عند ضبطها على `true`، يتم ضبط جميع عناوين HTTP المتوفّرة في الاستجابة الواردة من الخدمة المستهدَفة على الاستجابة الصادرة قبل تمريرها إلى ProxyEndpoint.
`response.retain.headers`	لا ينطبق	تحدّد هذه السمة عناوين HTTP معيّنة من الاستجابة يجب ضبطها على الاستجابة الصادرة قبل تمريرها إلى ProxyEndpoint. على سبيل المثال، لتمرير عنوان `Expires`، اضبط قيمة `response.retain.headers` على `Expires`. يتم تحديد عناوين HTTP المتعددة كقائمة مفصولة بفواصل، مثل `Expires,Set-Cookie`. تؤدي هذه السمة إلى إلغاء `response.retain.headers.enabled`. إذا تم ضبط `response.retain.headers.enabled` على `false`، سيتم ضبط أي عناوين محددة في السمة `response.retain.headers` على الرسالة الصادرة.
`retain.queryparams. enabled`	`true`	بشكلٍ تلقائي، يحتفظ Apigee Edge دائمًا بجميع مَعلمات طلب البحث في الطلبات الصادرة. عند ضبطها على `true`، يتم ضبط جميع مَعلمات طلب البحث المتوفّرة في الطلب الوارد على الطلب الصادر إلى الخدمة المستهدَفة.
`retain.queryparams`	لا ينطبق	تحدّد هذه السمة مَعلمات طلب بحث معيّنة يتم ضبطها على الطلب الصادر. على سبيل المثال، لتضمين مَعلمة طلب البحث `apikey` في رسالة الطلب، اضبط `retain.queryparams` على `apikey`. يتم تحديد مَعلمات طلب البحث المتعدّدة على شكل قائمة قيم مفصولة بفاصلة، مثل `apikey,environment`. تؤدي هذه السمة إلى إلغاء `retain.queryparams.enabled`.

سمات النقل الخاصة بـ ProxyEndpoint

تحدّد عناصر ProxyEndpoint HTTPTargetConnection مجموعة من خصائص نقل بيانات HTTP. يمكن استخدام هذه الخصائص لضبط إعدادات على مستوى النقل.

يتم ضبط السمات على عناصر ProxyEndpoint HTTPProxyConnection على النحو التالي:

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <Properties>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
    <VirtualHost>default</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

لمزيد من المعلومات عن المضيفين الافتراضيين، يمكنك الاطّلاع على لمحة عن المضيفين الافتراضيين.

مواصفات السمة ProxyEndpoint transport

اسم السمة	القيمة التلقائية	الوصف
`X-Forwarded-For`	`false`	عند ضبط القيمة على `true`، تتم إضافة عنوان IP الخاص بالمضيف الافتراضي إلى الطلب الصادر كقيمة لعنوان HTTP `X-Forwarded-For`.
`request.streaming. enabled`	`false`	تلقائيًا (`false`)، تتم قراءة حمولات طلبات HTTP في مخزن مؤقت، وتعمل السياسات التي يمكنها العمل على الحمولة على النحو المتوقّع. في الحالات التي تكون فيها حمولات البيانات أكبر من حجم ذاكرة التخزين المؤقت (10 ميغابايت)، يمكنك ضبط هذه السمة على `true`. عندما تكون قيمة `true` هي "صحيح"، لا تتم قراءة حمولات طلبات HTTP في مخزن مؤقت، بل يتم بثها كما هي إلى مسار طلب TargetEndpoint. في هذه الحالة، يتم تجاوز أي سياسات تعمل على الحمولة في مسار طلب ProxyEndpoint. راجِع أيضًا طلبات وبلاغات البث.
`response.streaming. enabled`	`false`	بشكل تلقائي (`false`)، تتم قراءة حمولات استجابة HTTP في مخزن مؤقت، وتعمل السياسات التي يمكنها العمل على الحمولة على النحو المتوقّع. في الحالات التي تكون فيها حمولات البيانات أكبر من حجم ذاكرة التخزين المؤقت (10 ميغابايت)، يمكنك ضبط هذه السمة على `true`. عندما تكون قيمة `true` هي "صحيح"، لا تتم قراءة حمولات استجابة HTTP في مخزن مؤقت، بل يتم نقلها مباشرةً إلى العميل. في هذه الحالة، يتم تجاوز أي سياسات تعمل على الحمولة في مسار استجابة ProxyEndpoint. راجِع أيضًا طلبات وبلاغات البث.
`compression.algorithm`	لا ينطبق	تلتزم Apigee Edge تلقائيًا بنوع الضغط الذي تم ضبطه لأي رسالة يتم تلقّيها. على سبيل المثال، عندما يرسل العميل طلبًا يستخدم ضغط gzip، يعيد توجيه Apigee Edge الطلب إلى الهدف باستخدام ضغط gzip. يمكنك ضبط خوارزميات الضغط ليتم تطبيقها بشكلٍ صريح من خلال ضبط هذه السمة على TargetEndpoint أو ProxyEndpoint. القيمتان المسموح بإدراجهما هما: gzip: إرسال الرسالة دائمًا باستخدام ضغط gzip deflate: إرسال الرسالة دائمًا باستخدام ضغط deflate بدون ضغط: إرسال الرسالة دائمًا بدون أي ضغط راجِع أيضًا: هل تتيح Apigee إمكانية الضغط/فك الضغط باستخدام GZIP/deflate؟
`api.timeout`	لا ينطبق	ضبط المهلة الزمنية لخوادم وكيل واجهة برمجة التطبيقات الفردية يمكنك ضبط خوادم وكيلة لواجهة برمجة التطبيقات، حتى تلك التي تم تفعيل البث فيها، بحيث تنتهي مهلتها بعد فترة زمنية محدّدة مع عرض الحالة `504 Gateway Timeout`. حالة الاستخدام الأساسية هي للعملاء الذين لديهم خوادم وكيلة لواجهة برمجة التطبيقات تستغرق وقتًا أطول للتنفيذ. على سبيل المثال، لنفترض أنّك بحاجة إلى وكلاء محدّدين لتنتهي مهلتهم بعد 3 دقائق. في ما يلي كيفية استخدام `api.timeout`. أولاً، احرص على ضبط موازن التحميل وجهاز التوجيه ومعالج الرسائل على أن تنتهي المهلة بعد ثلاث دقائق. بعد ذلك، اضبط إعدادات الخوادم الوكيلة ذات الصلة على أن تنتهي مهلتها بعد ثلاث دقائق. حدِّد القيمة بالملّي ثانية. مثلاً: `<Property name="api.timeout">180000</Property>` يُرجى العِلم أنّ زيادة مهلات النظام قد تؤدي إلى حدوث مشاكل في الأداء، لأنّ جميع الخوادم الوكيلة التي لا تتضمّن إعداد api.timeout تستخدم المهلات الجديدة الأطول لموازنة التحميل والموجّه ومعالج الرسائل. لذا، عليك ضبط إعدادات الخوادم الوكيلة الأخرى لواجهة برمجة التطبيقات التي لا تتطلّب مهلات أطول لاستخدام مهلات أقصر. على سبيل المثال، يضبط ما يلي خادمًا وكيلاً لواجهة برمجة التطبيقات على أن تنتهي مهلته بعد دقيقة واحدة: `<Property name="api.timeout">60000</Property>` لا يمكنك ضبط هذه السمة باستخدام متغيّر. يمكن للعملاء الذين لا يمكنهم تعديل مهلات Edge أيضًا ضبط مهلة لخادم وكيل لواجهة برمجة التطبيقات، شرط أن تكون المهلة أقصر من المهلة العادية لمعالج رسائل Edge البالغة 57 ثانية. راجِع ضبط io.timeout.millis وapi.timeout في Edge للحصول على مزيد من المعلومات.

ضبط io.timeout.millis وapi.timeout في Edge

في Edge، يرتبط تشغيل io.timeout.millis وapi.timeout. في كل طلب يتم إرساله إلى خادم وكيل لواجهة برمجة التطبيقات:

يرسل الموجه قيمة المهلة إلى "معالج الرسائل". تكون قيمة المهلة في جهاز التوجيه إما قيمة proxy_read_timeout التي يضبطها المضيف الظاهري الذي يعالج الطلب، أو قيمة المهلة التلقائية البالغة 57 ثانية.
يضبط "معالج الرسائل" بعد ذلك api.timeout:
1. إذا لم يتم ضبط api.timeout على مستوى الخادم الوكيل، اضبطه على مهلة جهاز التوجيه.
2. إذا تم ضبط api.timeout على مستوى الخادم الوكيل، اضبطه على "معالج الرسائل" على قيمة أقل من مهلة جهاز التوجيه أو قيمة api.timeout.
تحدّد قيمة api.timeout الحدّ الأقصى للمدة التي يستغرقها تنفيذ خادم وكيل لواجهة برمجة التطبيقات، بدءًا من طلب البيانات من واجهة برمجة التطبيقات وحتى الاستجابة.

بعد تنفيذ كل سياسة في خادم وكيل واجهة برمجة التطبيقات، أو قبل أن يرسل "معالج الرسائل" الطلب إلى نقطة النهاية المستهدَفة، يحسب "معالج الرسائل" (api.timeout - الوقت المنقضي منذ بداية الطلب). إذا كانت القيمة أقل من صفر، يعني ذلك أنّ الحد الأقصى للوقت المسموح به لمعالجة الطلب قد انتهى، ويعرض معالج الرسائل القيمة 504.
تحدّد قيمة io.timeout.millis الحدّ الأقصى للمدة الزمنية التي يجب أن يستجيب خلالها نقطة النهاية المستهدَفة.

قبل الاتصال بنقطة نهاية مستهدَفة، يحدّد "معالج الرسائل" الحد الأدنى من (api.timeout - الوقت المنقضي منذ بداية الطلب) وio.timeout.millis. ثم يتم ضبط io.timeout.millis على هذه القيمة.
- إذا حدث انتهاء مهلة أثناء كتابة طلب HTTP، سيتم عرض 408, Request Timeout.
- في حال حدوث مهلة أثناء قراءة استجابة HTTP، يتم عرض 504, Gateway Timeout.

لمحة عن ScriptTarget لتطبيقات Node.js

يتم استخدام عنصر ScriptTarget لدمج تطبيق Node.js في الخادم الوكيل. للحصول على معلومات حول استخدام Node.js وScriptTarget، يُرجى الاطّلاع على:

لمحة عن نقاط نهاية HostedTarget

تطلب علامة <HostedTarget/> فارغة من Edge استخدام تطبيق Node.js كنقطة استهداف، ويتم نشر هذا التطبيق في بيئة "نقاط الاستهداف المستضافة". لمزيد من التفاصيل، يُرجى الاطّلاع على نظرة عامة على "الاستهداف المستضاف".