CONNECT تونلی با بازبودن نامحدود وعده نمی‌دهد. پس از یک تبادل موفق، اتصال جریانی پیوسته از بایت‌ها را به میزبان و پورت درخواستی حمل می‌کند. تا زمانی که طرف‌ها و شبکه آن را باز نگه دارند، می‌تواند چندین تبادل را درون یک نشست TLS مقصد حمل کند.

دو محدودیت پراکسی متفاوت عمل می‌کنند: ترافیک می‌تواند مانع انقضای زمان‌سنج بی‌کاری شود، اما نمی‌تواند محدودیت عمر مطلق را تمدید کند. پروتکل مقصد هم حرفی برای گفتن دارد. یک کلاینت HTTP درونی ممکن است اتصالش را ببندد؛ یک برنامهٔ WebSocket ممکن است نشستش را پایان دهد. پراکسی پس از آن نمی‌تواند آن نشست مقصد را زنده نگه دارد.

تونل به هدفش گره خورده است. وقتی بایت‌های تونل جریان می‌یابد، اتصال دیگر یک کانال معمول درخواست HTTP نیست که بتوان روی آن CONNECT دیگری برای مقصدی نامرتبط صادر کرد. کلاینت به اتصال دیگری یا تونل دیگری نیاز دارد که کتابخانه‌اش مدیریت می‌کند.

برای یک فید پایدار، با استفاده از سازوکارهای زنده‌بودن و اتصالِ پشتیبانی‌شدهٔ کلاینت برای اتصال دوباره برنامه‌ریزی کنید. اگر پس از سکوت بسته می‌شود، سیاست عدم فعالیت سرنخ مفیدی است؛ اگر با وجود ترافیک پس از مدت ثابتی بسته می‌شود، به‌جای آن محدودیت مطلق را بررسی کنید. برای فید WebSocket نیز پس از اتصال دوباره وضعیت برنامه را بازیابی کنید.

مقالات مرتبط