Cloudflare Workers اکنون میتواند اتصالهای TCP ورودی را بپذیرد و gRPC اولین پروتکلی است که روی این قابلیت جدید اجرا شده است.
چطور ممکن شد؟
قابلیت جدید یک handler بهنام connect(socket) معرفی میکند که سوکت خام ورودی را از طریق Spectrum — پراکسی ورود Cloudflare برای ترافیک غیرHTTP — به یک Worker مسیردهی میکند. پس از دریافت سوکت، Worker میتواند آن را بخواند و بنویسد، آن را به Worker دیگری تحویل دهد یا به یک Durable Object منتقل کند.
export default {
async connect(socket): Promise {
const writer = socket.writable.getWriter();
await writer.write(new TextEncoder().encode("Hello, world!\n"));
await writer.close();
},
} satisfies ExportedHandler;
مسیر full-duplex و نقش کانتینرها
از داخل یک Durable Object، سوکت میتواند با getTcpPort() به یک کانتینر منتقل شود؛ جایی که مسیر full‑duplex به پایان میرسد. Cloudflare نمونههایی مانند یک echo server gRPC در Go و یک socketserver در Python ارائه کرده که بدون تغییر اجرا میشوند. این سازوکار اجازه میدهد هر برنامه به هر زبان، برای هر پروتکل مبتنی بر TCP در لبه اجرا شود.
محدودیتها و نحوه پیادهسازی gRPC روی Workers
پیادهسازی فعلی Workers کنترل سطحی جریان در HTTP/2 را برای توسعهدهنده در دسترس نمیگذارد؛ به همین دلیل جریان دو جهته (bidirectional streaming) در gRPC بهصورت بومی پشتیبانی نمیشود. gRPC برای مدیریت streamها به فریمهایی وابسته است که شناسهٔ stream و مکانیزمهای کنترل جریان، لغو و تریلرها را مدیریت میکنند؛ APIهای وب مانند fetch() این کنترلهای سطح پایین را فراهم نمیکنند و مرورگرها نیز با همین محدودیت مواجهند، یکی از دلایل ظهور gRPC‑Web است.
برای غلبه بر این محدودیت، Cloudflare از مکانیسم ترجمه استفاده میکند: درخواستهای gRPC ورودی به gRPC‑Web تبدیل میشوند و پاسخها مجدداً به gRPC بازگردانده میشوند. این رویکرد امکان سرویسدهی به تماسهای unary و server-streaming و همچنین برقراری تماس با سرورهای gRPC خارجی را میدهد، اما جریان دوجهتهٔ کامل هنوز در سطح Worker پشتیبانی نشده است.
ملاحظات عملی و عقبفشار (backpressure)
کنترل دقیق backpressure و گوشههای مربوط به مدیریت استریم تعیینکنندهٔ پایداری پیادهسازی است. Cloudflare بهطور کامل به همه پرسشهای مربوط به رفتار backpressure پاسخ نداده است؛ بنابراین توصیه میشود قبل از بهرهبرداری تولیدی، آزمایشهای بار، استرس و سناریوهای استریم را انجام دهید تا رفتار در شرایط واقعی مشخص شود.
چرایی وضعیت private beta
این قابلیت فعلاً در private beta قرار دارد. دلیل اصلی این است که تیم Cloudflare خود از gRPC در محصولات داخلی استفاده نمیکند و در عوض پروتکلهایی مانند Cap'n Proto و راهکارهای RPC جاوااسکریپتیِ ویژهٔ Workers را بهکار میگیرد. هدف، کار با گروه کوچکی از توسعهدهندگان gRPC برای تثبیت پیادهسازی پیش از عرضهٔ عمومی است.
چشمانداز و موارد قابل توجه
- این قابلیت مرز Workers را از HTTP فراتر میبرد و امکان پذیرش بروکر پیام، پراکسیهای پایگاهداده یا هر پروتکل باینری مبتنی بر TCP را در لبه فراهم میکند.
- عبور سوکت از Worker به Durable Object و سپس به کانتینر، امکان پیادهسازی منطق مسیردهی در JavaScript قبل از تعیین نقطهٔ خاتمهٔ TCP را فراهم میکند.
- برای سناریوهای تولیدی که به استریم دوجهتهٔ کامل نیاز دارند، تا زمان تکمیل پشتیبانی بومی باید از راهحلهای مبتنی بر کانتینر یا سایر مسیرهای جایگزین استفاده شود.
- تستهای عملکردی و بررسی رفتار عقبفشار برای تضمین پایداری در بارهای سنگین ضروری است.
مراجع و منابع
پشتیبانی از اتصال TCP در Workers گامی مهم برای اجرای پروتکلهای مبتنی بر TCP در لبه است، اما تکمیل پشتیبانی از جریانهای gRPC و شفافسازی رفتارهای مرتبط با استریمها همچنان نیاز به کار و آزمون دارد. با افزایش تعداد توسعهدهندگان و بازخوردهای واقعی، انتظار میرود محدودیتهای فعلی کاهش یابند و پشتیبانی وسیعتری فراهم شود.





