‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

مرجع ویژگی‌های نقطه پایان

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

این موضوع دارایی‌های انتقال را که می‌توان در پیکربندی‌های TargetEndpoint و ProxyEndpoint تنظیم کرد تا رفتار پیام‌رسانی و اتصال را کنترل کند توصیف می‌کند. برای پوشش کامل پیکربندی TargetEndpoint و ProxyEndpoint، به مرجع پیکربندی پراکسی API مراجعه کنید.

خصوصیت‌های انتقال 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>

مشخصات دارایی انتقال TargetEndpoint

نام دارایی	مقدار پیش‌فرض	شرح
`keepalive.timeout.millis`	`60000`	مهلت زمانی اتصال غیرفعال برای اتصال هدف در استخر اتصال. اگر اتصال در استخر فراتر از حد مشخص‌شده در حالت آماده‌به‌کار باشد، اتصال بسته می‌شود.
`connect.timeout.millis`	`3000`	مهلت اتصال هدف تمام شد. اگر اتصال مهلت زمانی داشته باشد، Edge کد وضعیت HTTP `503` را برمی‌گرداند. در برخی موارد، وقتی از `LoadBalancer` در تعریف TargetServer استفاده شود و زمان اتمام فرا برسد، ممکن است کد وضعیت HTTP 504 برگردانده شود. توجه: در برخی موارد، 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` باشد و کارخواه درخواست ۱.۰ ارسال کند، درخواست ۱.۰ نیز به هدف ارسال می‌شود. درغیراین‌صورت، درخواست ۱.۱ به هدف ارسال می‌شود.
`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 در میان‌گیر خوانده می‌شوند و خط‌مشی‌هایی که می‌توانند روی بار داده عمل کنند، طبق انتظار کار می‌کنند. در مواردی که حجم داده‌های بیشتر از اندازه میان‌گیری (۱۰ مگابایت) باشد، می‌توانید این مشخصه را روی `true` تنظیم کنید. وقتی `true`، بار داده‌های درخواست HTTP در میان‌گیر خوانده نمی‌شود؛ آن‌ها همان‌طور که هستند به نقطه پایان مقصد جاری‌سازی می‌شوند. در این مورد، هر خط‌مشی‌ای که روی بار در جریان درخواست TargetEndpoint عمل می‌کند دور زده می‌شود. همچنین درخواست‌ها و پاسخ‌های جاری‌سازی را ببینید.
`response.streaming.enabled`	`false`	به‌طور پیش‌فرض (`false`)، بار پاسخ HTTP در میان‌گیر خوانده می‌شود و خط‌مشی‌هایی که می‌توانند روی بار عمل کنند، طبق انتظار عمل می‌کنند. در مواردی که حجم داده‌های بیشتر از اندازه میان‌گیری (۱۰ مگابایت) باشد، می‌توانید این مشخصه را روی `true` تنظیم کنید. وقتی `true`، بار پاسخ HTTP در بافر خوانده نمی‌شود؛ این بارها همان‌طور که هستند به جریان پاسخ ProxyEndpoint جاری می‌شوند. در این مورد، هر خط‌مشی‌ای که در جریان پاسخ TargetEndpoint روی بار عمل می‌کند دور زده می‌شود. همچنین درخواست‌های جاری‌سازی و پاسخ‌ها را ببینید.
`success.codes`	موجود نیست	به‌طور پیش‌فرض، Apigee Edge کد HTTP `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`	موجود نیست	سرصفحه‌های اچ‌تی‌تی‌پی‌اس خاصی را از درخواست تعریف می‌کند که باید در درخواست خروجی برای سرویس هدف تنظیم شود. برای مثال، برای گذردهی سرصفحه `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

نام دارایی	مقدار پیش‌فرض	شرح
`X-Forwarded-For`	`false`	وقتی روی `true` تنظیم شود، نشانی IP میزبان مجازی به‌عنوان مقدار سرایند HTTP `X-Forwarded-For` به درخواست خروجی اضافه می‌شود.
`request.streaming. enabled`	`false`	به‌طور پیش‌فرض (`false`)، بار درخواست HTTP در میان‌گیر خوانده می‌شود و خط‌مشی‌هایی که می‌توانند روی بار عمل کنند، طبق انتظار کار می‌کنند. در مواردی که حجم داده‌های مبادله بزرگ‌تر از اندازه میان‌گیری (۱۰ مگابایت) باشد، می‌توانید این مشخصه را روی `true` تنظیم کنید. وقتی `true`، بار داده‌های درخواست HTTP در میان‌گیر خوانده نمی‌شود؛ آن‌ها همان‌طور که هستند به جریان درخواست TargetEndpoint جاری می‌شوند. در این مورد، هر خط‌مشی‌ای که روی بار در جریان درخواست ProxyEndpoint عمل می‌کند دور زده می‌شود. همچنین درخواست‌ها و پاسخ‌های جاری‌سازی را ببینید.
`response.streaming. enabled`	`false`	به‌طور پیش‌فرض (`false`)، بار پاسخ HTTP در میان‌گیر خوانده می‌شود و خط‌مشی‌هایی که می‌توانند روی بار عمل کنند، طبق انتظار عمل می‌کنند. در مواردی که حجم داده‌های بزرگ‌تر از اندازه میان‌گیری (۱۰ مگابایت) باشد، می‌توانید این مشخصه را روی `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` زمان‌بندی شوند. مورد استفاده اصلی برای مشتریانی است که کارگزاران میانای برنامه‌سازی کاربردی دارند که اجرای آن‌ها بیشتر طول می‌کشد. برای مثال، فرض کنید به پراکسی‌های خاصی نیاز دارید که پس‌از ۳ دقیقه منقضی شوند. در زیر نحوه استفاده از `api.timeout` آمده است. ابتدا، مطمئن شوید که ترازکننده بار، رهیاب، و پردازشگر پیام را به‌گونه‌ای پیکربندی کنید که پس‌از سه دقیقه زمان‌بندی شود. سپس پراکسی‌های مربوطه را پیکربندی کنید تا پس‌از سه دقیقه زمان آن‌ها به‌پایان برسد. مقدار را به میلی‌ثانیه مشخص کنید. برای مثال: `<Property name="api.timeout">180000</Property>` بااین‌حال، توجه داشته باشید که افزایش زمان‌های انتظار سیستم می‌تواند منجر به مشکلات عملکردی شود، زیرا همه پراکسی‌های بدون تنظیم api.timeout از زمان‌های انتظار جدید و بالاتر ترازکننده بار، مسیریاب، و پردازشگر پیام استفاده می‌کنند. بنابراین، پراکسی‌های میانای برنامه‌سازی کاربردی دیگری را که به زمان‌های انتظار طولانی‌تر نیاز ندارند پیکربندی کنید تا از زمان‌های انتظار کوتاه‌تر استفاده کنند. برای مثال، مجموعه زیر یک کارگزار میانای برنامه‌سازی کاربردی را تنظیم می‌کند تا پس‌از ۱ دقیقه زمان آن به‌پایان برسد: `<Property name="api.timeout">60000</Property>` نمی‌توانید این دارایی را با متغیر تنظیم کنید. مشتریانی که نمی‌توانند زمان‌های اتمام Edge را تغییر دهند، می‌توانند زمان اتمام کارگزار API را نیز پیکربندی کنند، به‌شرطی که زمان اتمام کوتاه‌تر از زمان اتمام استاندارد پردازشگر پیام Edge (۵۷ ثانیه) باشد. برای اطلاعات بیشتر، به تنظیم io.timeout.millis و api.timeout برای Edge مراجعه کنید.

تنظیم io.timeout.millis و api.timeout برای Edge

در Edge، عملکرد io.timeout.millis و api.timeout مرتبط است. در هر درخواست به یک پراکسی API:

«مسیریاب» مقدار مهلت زمانی خود را به «پردازشگر پیام» ارسال می‌کند. مقدار «مهلت زمانی روتر» یا مقدار proxy_read_timeout تنظیم‌شده توسط میزبان مجازی که درخواست را مدیریت می‌کند، یا مقدار مهلت زمانی پیش‌فرض ۵۷ ثانیه است.
سپس «پردازشگر پیام» api.timeout را تنظیم می‌کند:
1. اگر api.timeout در سطح پراکسی تنظیم نشده است، آن را روی «مهلت زمانی روتر» تنظیم کنید.
2. اگر api.timeout در سطح پراکسی تنظیم شده است، آن را در «پردازشگر پیام» روی مقدار کمتر از «مهلت زمانی رهیاب» یا مقدار api.timeout تنظیم کنید.
مقدار api.timeout حداکثر زمان اجرای کارگزار API از درخواست API تا پاسخ را مشخص می‌کند.

پس‌از اجرای هر خط‌مشی در پراکسی API، یا قبل‌از اینکه «پردازشگر پیام» درخواست را به نقطه پایانی هدف ارسال کند، «پردازشگر پیام» (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 که در محیط «هدف‌های میزبانی‌شده» مستقر شده است به‌عنوان هدف خود استفاده کند. برای جزئیات بیشتر، نمای کلی «هدف‌های میزبانی‌شده» را ببینید.