פסקי זמן של CONNECT בפרוקסי לאחר חיבור TCP מוצלח
אתרו את פסק הזמן שפעיל במהלך CONNECT במקום להניח שחיבור TCP שהושלם גם סיים את הקמת המנהרה.
פסק זמן של חיבור TCP מילא את תפקידו ברגע שהלקוח מתחבר לפרוקסי. ההמתנה הבאה—קבלת תגובת CONNECT מלאה—עשויה להיות כפופה לטיימר אחר.
ייתכן שהפרוקסי עדיין מתחבר במעלה הזרם, מחליף הודעות אימות או ממתין לשירות אחר. התגובה הרגילה של האתר טרם החלה.
| השלב האחרון שהושלם | למה עדיין ממתינים? |
|---|---|
| TCP התחבר לפרוקסי | לחיצת היד של הפרוקסי, כולל קבלת CONNECT |
| CONNECT התקבל | TLS של היעד, כאשר היעד משתמש בו |
| בקשת היעד נשלחה | התגובה של היעד |
מצאו את הטיימר שפעיל בזמן שהמחבר קורא וכותב את לחיצת היד הזו. מאפיין בשם “response timeout” עשוי להיכנס לתוקף רק לאחר הקמת המסלול. ב-HttpClient 5, הבדילו בין ConnectionConfig לפסק הזמן של הסוקט שלו, לתצורת לחיצת היד של TLS, ולפסק הזמן של התגובה ברמת הבקשה. החילו את תצורת החיבור הרלוונטית דרך המנהל שבו משתמש הלקוח בפועל. דורות קודמים של Apache HttpClient משתמשים בממשקי API שונים, ולכן קטע קוד ישן אינו מפה אמינה של האחריות הזו.
התייחסו לדחיית CONNECT סופית כתגובה של הפרוקסי. תגובה מוצלחת שאחריה נתקע TLS היא שלב כשל אחר. „TCP מחובר; אין תגובת CONNECT מלאה לפני מועד ההקמה“ מתאר את הבעיה בדיוק רב יותר מפסק זמן גנרי של פרוקסי.
מועד אחרון כולל יכול להגביל את המתנת הקורא לצד מגבלות השלב הללו. כאשר הוא פוג, בטלו או סגרו את הפעולה דרך מחזור החיים שהלקוח תומך בו, לפני שניסיון נוסף יצרוך קיבולת חיבורים.