‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מסמך עזר בנושא מאפיינים של נקודות קצה

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

במאמר הזה מתוארים מאפייני העברה שאפשר להגדיר בהגדרות של TargetEndpoint ו-ProxyEndpoint כדי לשלוט בהתנהגות של העברת הודעות וחיבורים. מידע מקיף על הגדרות TargetEndpoint ו-ProxyEndpoint זמין במאמר הפניה להגדרת proxy ל-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`. במקרים מסוימים, יכול להיות שיוחזר קוד סטטוס 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`, והגדרות ה-Proxy מצוינות ב-`http.properties` (רק בפריסות מקומיות), אז חיבורי היעד מוגדרים לשימוש ב-Proxy שצוין.
`use.proxy.tunneling`	`true`	אם ההגדרה היא `true`, והגדרות ה-Proxy מצוינות ב-`http.properties` (בפריסות מקומיות בלבד), אז חיבורי היעד מוגדרים לשימוש במנהרה שצוינה. אם היעד משתמש ב-TLS/SSL, המערכת מתעלמת מהמאפיין הזה וההודעה תמיד נשלחת דרך מנהרה.
`enable.method.override`	`false`	מגדיר כותרת `X-HTTP-Method-Override` בבקשה היוצאת לשירות היעד עבור שיטת ה-HTTP שצוינה. לדוגמה, `<Property name="GET.override.method">POST</Property>`.
`*.override.method`	לא רלוונטי	מגדירה כותרת `X-HTTP-Method-Override` בבקשה היוצאת עבור ה-method של ה-HTTP שצוין. לדוגמה, `<Property name="GET.override.method">POST</Property>`.
`request.streaming.enabled`	`false`	כברירת מחדל (`false`), מטען ייעודי (payload) של בקשות HTTP נקרא לתוך מאגר זמני, והמדיניות שיכולה לפעול על המטען הייעודי פועלת כמצופה. אם מטען הייעודי גדול יותר משטח אחסון זמני (10MB), אפשר להגדיר את המאפיין הזה לערך `true`. כשמשתמשים ב-`true`, המערכת לא קוראת את נתוני הבקשה של HTTP לתוך מאגר זמני, אלא מעבירה אותם כמו שהם לנקודת היעד. במקרה כזה, המערכת עוקפת את כל כללי המדיניות שפועלים על מטען הייעודי (payload) בזרימת הבקשות של TargetEndpoint. אפשר לעיין גם במאמר בנושא בקשות ותגובות של סטרימינג.
`response.streaming.enabled`	`false`	כברירת מחדל (`false`), מטען ייעודי (payload) של תגובת HTTP נקרא לתוך מאגר זמני, ומדיניות שיכולה לפעול על המטען הייעודי פועלת כמצופה. אם מטען הייעודי גדול יותר משטח אחסון זמני (10MB), אפשר להגדיר את המאפיין הזה לערך `true`. כשמגדירים את `true`, המטען הייעודי (payload) של תגובת ה-HTTP לא נקרא לתוך מאגר זמני (buffer), אלא מועבר כמו שהוא לזרימת התגובה של ProxyEndpoint. במקרה הזה, כללי מדיניות שפועלים על מטען הייעודי (payload) בתהליך התגובה של 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 none: ההודעה תמיד תישלח ללא דחיסה מידע נוסף: האם Apigee תומך בדחיסה/ביטול דחיסה באמצעות דחיסת GZIP/deflate?
`request.retain.headers. enabled`	`true`	כברירת מחדל, ב-Apigee Edge תמיד נשמרות כל כותרות ה-HTTP בהודעות יוצאות. אם הערך מוגדר כ-`true`, כל כותרות ה-HTTP שקיימות בבקשה הנכנסת מוגדרות בבקשה היוצאת.
`request.retain.headers`	לא רלוונטי	הגדרת כותרות HTTP ספציפיות מהבקשה שצריך להגדיר בבקשה היוצאת לשירות היעד. לדוגמה, כדי לבצע העברה של הכותרת `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`), מטען ייעודי (payload) של בקשות HTTP נקרא לתוך מאגר זמני, והמדיניות שיכולה לפעול על המטען הייעודי פועלת כמצופה. במקרים שבהם מטען הייעודי גדול יותר מגודל שטח אחסון זמני (10MB), אפשר להגדיר את המאפיין הזה לערך `true`. כשמשתמשים ב-`true`, המטענים הייעודיים (payloads) של בקשות HTTP לא נקראים לתוך מאגר זמני (buffer), אלא מועברים כמו שהם לזרימת הבקשות של TargetEndpoint. במקרה כזה, המערכת עוקפת את כל כללי המדיניות שפועלים על מטען הייעודי (payload) בתהליך הבקשה של ProxyEndpoint. אפשר לעיין גם במאמר בנושא בקשות ותגובות של סטרימינג.
`response.streaming. enabled`	`false`	כברירת מחדל (`false`), מטען ייעודי (payload) של תגובת HTTP נקרא לתוך מאגר זמני, ומדיניות שיכולה לפעול על המטען הייעודי פועלת כמצופה. אם מטען הייעודי (payload) גדול יותר מגודל שטח אחסון זמני (10MB), אפשר להגדיר את המאפיין הזה לערך `true`. כשמשתמשים ב-`true`, המטען הייעודי (payload) של תגובת ה-HTTP לא נקרא לתוך מאגר זמני (buffer), אלא מועבר כמו שהוא ללקוח. במקרה כזה, כללי מדיניות שפועלים על מטען הייעודי (payload) בזרימת התגובה של ProxyEndpoint נעקפים. אפשר לעיין גם במאמר בנושא בקשות ותגובות של סטרימינג.
`compression.algorithm`	לא רלוונטי	כברירת מחדל, Apigee Edge מכבד את סוג הדחיסה שמוגדר לכל הודעה שמתקבלת. לדוגמה, אם לקוח שולח בקשה שמשתמשת בדחיסת gzip, ‏ Apigee Edge מעביר את הבקשה ליעד באמצעות דחיסת gzip. אתם יכולים להגדיר אלגוריתמים של דחיסה שיחולו באופן מפורש על ידי הגדרת המאפיין הזה ב-TargetEndpoint או ב-ProxyEndpoint. הערכים הנתמכים הם: ‫gzip: שליחת ההודעה תמיד תתבצע באמצעות דחיסת gzip ‫deflate: שליחת הודעה תמיד באמצעות דחיסת deflate none: ההודעה תמיד תישלח ללא דחיסה מידע נוסף: האם Apigee תומך בדחיסה/ביטול דחיסה באמצעות דחיסת GZIP/deflate?
`api.timeout`	לא רלוונטי	הגדרת זמן קצוב לתפוגה לשרתי proxy נפרדים של API אפשר להגדיר שפרוקסי של API, גם כאלה שמופעלת בהם הזרמה, יפסיקו לפעול אחרי זמן מוגדר עם סטטוס `504 Gateway Timeout`. התרחיש העיקרי לדוגמה הוא לקוחות שיש להם שרתי proxy של API שלוקח להם יותר זמן לפעול. לדוגמה, נניח שאתם צריכים שפרוקסי ספציפיים יפסיקו לפעול אחרי 3 דקות. כך משתמשים ב-`api.timeout`. קודם כול, צריך להגדיר את מאזן העומסים, הנתב ומעבד ההודעות כך שיתרחש פסק זמן אחרי שלוש דקות. לאחר מכן מגדירים את שרתי ה-proxy הרלוונטיים כך שזמן הקצוב לתפוגה שלהם יהיה שלוש דקות. מציינים את הערך באלפיות שנייה. לדוגמה: `<Property name="api.timeout">180000</Property>` עם זאת, חשוב לזכור שהגדלת ערכי הזמן הקצוב לתפוגה של המערכת עלולה לגרום לבעיות בביצועים, כי כל ה-proxy ללא הגדרה של api.timeout משתמשים בערכי הזמן הקצוב לתפוגה החדשים והגבוהים יותר של איזון העומסים, הנתב ומעבד ההודעות. לכן, כדאי להגדיר שרתי proxy אחרים של API שלא דורשים פסק זמן ארוך יותר, כך שישתמשו בפסק זמן קצר יותר. לדוגמה, הקוד הבא מגדיר ש-proxy ל-API יפסיק לפעול אחרי דקה אחת: `<Property name="api.timeout">60000</Property>` אי אפשר להגדיר את המאפיין הזה באמצעות משתנה. לקוחות שלא יכולים לשנות את הזמנים הקצובים לתפוגה ב-Edge יכולים גם להגדיר זמן קצוב לתפוגה של proxy ל-API, בתנאי שהזמן הקצוב לתפוגה קצר יותר מהזמן הקצוב לתפוגה של מעבד בקשות רגיל ב-Edge, שהוא 57 שניות. מידע נוסף מופיע במאמר הגדרת io.timeout.millis ו-api.timeout ל-Edge.

הגדרה של io.timeout.millis ו-api.timeout ב-Edge

ב-Edge, הפעולה של io.timeout.millis ו-api.timeout קשורה. בכל בקשה ל-proxy ל-API:

הנתב שולח את ערך הזמן הקצוב לתפוגה שלו למעבד ההודעות. ערך הזמן הקצוב לתפוגה של הנתב הוא או הערך של proxy_read_timeout שהוגדר על ידי המארח הווירטואלי שמטפל בבקשה, או ערך ברירת המחדל של הזמן הקצוב לתפוגה שהוא 57 שניות.
לאחר מכן, מעבד הבקשות מגדיר את api.timeout:
1. אם api.timeout לא מוגדר ברמת ה-proxy, צריך להגדיר אותו כזמן הקצוב לתפוגה של הנתב.
2. אם api.timeout מוגדר ברמת ה-proxy, צריך להגדיר אותו ב-Message Processor לערך הנמוך מבין הזמן הקצוב לתפוגה של הנתב או הערך של api.timeout.
הערך של api.timeout מציין את משך הזמן המקסימלי שמוקצב ל-proxy ל-API לביצוע הפעולה, מבקשת API ועד לתשובה.

אחרי שכל מדיניות ב-API proxy מופעלת, או לפני שמעבד ההודעות שולח את הבקשה לנקודת היעד, מעבד ההודעות מחשב (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 בשרת ה-proxy. מידע על שימוש ב-Node.js וב-ScriptTarget זמין במאמרים הבאים:

מידע על נקודות קצה של HostedTarget

תג <HostedTarget/> ריק מציין ל-Edge להשתמש באפליקציית Node.js שנפרסה בסביבת Hosted Targets כיעד. פרטים נוספים מופיעים במאמר סקירה כללית על יעדים מתארחים.