محتوای آموزشی وبلاگ نت‌آرام
برنامه Node.js شما به یک API بیرونی وصل می‌شود. درخواست‌های پی‌درپی درست‌اند، اما بعد از چند دقیقه بیکاری، اولین درخواست گاهی با
ECONNRESET شکست می‌خورد و تلاش بعدی موفق می‌شود. یکی از احتمال‌ها این است که برنامه خواسته از اتصال نگه‌داشته‌شده قبلی استفاده کند، در حالی که سرور مقصد یا واسطه شبکه آن اتصال بیکار را بسته است.این فقط یکی از علت‌های
ECONNRESET است؛ قطع شبکه، بسته‌شدن ناگهانی مقصد، محدودیت سرویس یا مشکل پراکسی هم می‌توانند پیام مشابه بدهند. در این آموزش شواهد را جمع می‌کنیم، اتصال جدید و اتصال استفاده‌شده را مقایسه می‌کنیم و فقط برای درخواست امن، تکرار محدود را توضیح می‌دهیم. تکرار خودکار پرداخت یا ثبت سفارش بدون سازوکار جلوگیری از ثبت دوباره می‌تواند عملیات را دو بار انجام دهد.۱. الگوی خطا و نوع درخواست را ثبت کنید
زمان آخرین درخواست موفق، مدت بیکاری، روش درخواست مانند GET یا POST و کد خطا را در گزارش خصوصی ثبت کنید. اگر خطا فقط در اولین درخواست پس از فاصله بیکاری رخ می‌دهد و تلاش بعدی موفق است، اتصال قدیمی یک فرضیه مناسب است. اگر همه درخواست‌ها شکست می‌خورند، ابتدا دسترسی شبکه، DNS، TLS و وضعیت سرویس مقصد را هم بررسی کنید.
نشانی کامل دارای توکن، سرآیند Authorization، کوکی، اطلاعات پرداخت یا محتوای خصوصی را ثبت نکنید. برای آزمایش، از یک مسیر سلامت عمومی و بی‌ضرر متعلق به خودتان استفاده کنید. در هاست اشتراکی نام و محل گزارش برنامه را از بخش مدیریت همان برنامه پیدا کنید.
۲. نسخه و روش ارسال درخواست را بشناسید
در Terminal یا SSH حساب، پس از ورود به محیط اختصاصی برنامه Node.js، نسخه را ببینید:
کد / دستورnode --version
npm --version
اگر برنامه از
http یا https داخلی Node.js استفاده می‌کند، کلاس Agent می‌تواند اتصال‌ها را برای استفاده دوباره مدیریت کند. گزینه‌ها و پیش‌فرض‌ها به نسخه Node.js و کتابخانه وابسته‌اند. اگر از fetch، Axios یا کتابخانه دیگری استفاده می‌کنید، ابتدا مشخص کنید آن کتابخانه در نسخه پروژه چگونه اتصال را مدیریت می‌کند؛ تنظیم Agent برای یک روش الزاماً بر روش دیگر اثر نمی‌گذارد.برای آزمودن دسترسی عمومی مقصد از همان محیط می‌توانید بنویسید:
کد / دستورcurl -I https://api.example.com/health
نشانی باید با مسیر سلامت واقعی و عمومی خودتان جایگزین شود. موفقیت این درخواست فقط نشان می‌دهد یک اتصال جدید در همان لحظه پاسخ داده؛ اثبات نمی‌کند استفاده دوباره از اتصال قدیمی نیز سالم است. خطای گواهی را با خاموش‌کردن تأیید TLS دور نزنید.
۳. استفاده دوباره از اتصال را در یک آزمایش امن ببینید
در یک نسخه آزمایشی، برای درخواست‌های
کد / دستورhttps می‌توانید وضعیت reusedSocket و کد خطا را بدون ثبت اطلاعات خصوصی گزارش کنید:const https = require("node:https");
const agent = new https.Agent({ keepAlive: true, maxSockets: 4 });
function checkHealth() {
const req = https.get("https://api.example.com/health", { agent }, (res) => {
console.log("status:", res.statusCode);
res.resume();
});
req.on("error", (err) => {
console.log("error:", err.code, "reused:", req.reusedSocket);
});
}
checkHealth();
آدرس را با مسیر سلامت خودتان عوض کنید.
res.resume() بدنه پاسخ نمونه را مصرف می‌کند تا مدیریت اتصال به‌درستی ادامه یابد. برای مقایسه واقعی باید پس از پایان درخواست اول، با همان Agent و فاصله بیکاری موردنظر درخواست دیگری اجرا شود؛ یک بار اجرای نمونه ثابت نمی‌کند اتصال دوباره استفاده شده است. مقدار reusedSocket و امکان‌های Agent را با نسخه Node.js پروژه تطبیق دهید.اگر خطا همراه
reused: true و عمدتاً پس از بیکاری دیده می‌شود، فرضیه بستن اتصال بیکار تقویت می‌شود، ولی هنوز باید تنظیم‌های مقصد و واسطه‌ها را مقایسه کنید. اگر reused: false است یا خطا در شروع اتصال جدید هم رخ می‌دهد، فقط تنظیم Keep-Alive را مقصر ندانید.۴. اتصال تازه و تنظیمات مسیر را مقایسه کنید
در نسخه آزمایشی، برای یک درخواست بی‌خطر می‌توان از گزینه
کد / دستورagent: false در https.get استفاده کرد تا از Agent مشترک نمونه استفاده نشود:https.get("https://api.example.com/health", { agent: false }, (res) => {
console.log("status:", res.statusCode);
res.resume();
}).on("error", (err) => console.log("error:", err.code));
اگر خطا با اتصال تازه از بین رفت و با اتصال استفاده‌شده تکرار شد، زمان بستن اتصال بیکار در کلاینت، پراکسی و سرور مقصد را با مستندات و مدیر سرویس بررسی کنید. خاموش‌کردن دائمی استفاده دوباره ممکن است هزینه اتصال و فشار را بیشتر کند؛ مقدار مناسب برای همه سرویس‌ها یکسان نیست. روی هاست اشتراکی ممکن است تنظیم پراکسی در اختیار حساب شما نباشد.
در Node.js،
fetch و بعضی کتابخانه‌ها از سازوکار اتصال متفاوت استفاده می‌کنند. نمونه Agent بالا را بی‌تغییر به هر کتابخانه نسبت ندهید؛ راهنمای همان نسخه را بخوانید. اگر تماس از سمت برنامه به یک مقصد خارجی با محدودیت شبکه انجام می‌شود، نتیجه اتصال تازه و زمان خطا را برای پشتیبانی ارسال کنید، بدون ارسال کلید یا بدنه محرمانه.۵. فقط درخواست امن را محدود و آگاهانه تکرار کنید
برای یک GET سلامت که تکرار آن اثری روی داده ندارد، می‌توان در صورت
کد / دستورECONNRESET روی اتصال استفاده‌شده، حداکثر یک بار تلاش دیگر انجام داد. نمونه ساده:function getHealth(attempt = 0) {
const req = https.get("https://api.example.com/health", { agent }, (res) => {
console.log("status:", res.statusCode);
res.resume();
});
req.on("error", (err) => {
if (attempt === 0 && req.reusedSocket && err.code === "ECONNRESET") {
return getHealth(1);
}
console.log("request failed:", err.code);
});
}
این قطعه از
https و agent تعریف‌شده در نمونه قبلی استفاده می‌کند و نمونه کامل مدیریت زمان انتظار یا خاموشی برنامه نیست. در برنامه واقعی علاوه بر مهلت مناسب، خطا و تعداد تلاش را ثبت و بار روی سرویس را کنترل کنید. برای POST پرداخت، ثبت سفارش یا هر عملیات دارای اثر، صرف دیدن خطای اتصال نشان نمی‌دهد سرور مقصد عملیات را انجام نداده است. تکرار چنین درخواستی فقط با طراحی مشخص idempotency و پیگیری وضعیت مقصد مجاز است.۶. نتیجه را با همان الگوی واقعی بسنجید
پس از اصلاح، در محیط آزمایشی چند بار درخواست موفق، یک دوره بیکاری و سپس درخواست بعدی را تکرار کنید. تعداد خطا، استفاده دوباره از سوکت و نتیجه واقعی API را مقایسه کنید. یک آزمایش موفق ثابت نمی‌کند خطای پراکنده همیشه حل شده است؛ در بازه معقول و با گزارش کافی بررسی کنید.
برای بررسی امکانات اجرای پروژه به صفحه هاست Node.js نت‌آرام و برای تنظیمات محیط برنامه به راهنمای متغیرهای محیطی Node.js مراجعه کنید. توضیح
Agent و request.reusedSocket در مستندات رسمی Node.js آمده است.برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام