راهنمای انتخاب VPS در نیویورک و نیوجرسی

آنچه یک VPS در نیویورک واقعاً برای شما فراهم می‌کند

یک VPS در نیویورک در یکی از دو بازار بزرگ اتصال (interconnection) در ساحل شرقی ایالات متحده قرار دارد. بازار دیگر در اشبرن، ویرجینیا واقع شده است. آنچه شما خریداری می‌کنید، یک زمان رفت و برگشت (round trip) کوتاه برای کاربران بین بوستون و واشینگتن، به‌علاوه کوتاه‌ترین مسیر فیبر نوری از آمریکای شمالی به اروپا است. اگر کاربران شما به‌طور یکنواخت در سراسر قاره پراکنده هستند، یک موقعیت مرکزی معمولاً خدمات بهتری به آن‌ها ارائه می‌دهد و تشخیص تفاوت بین این دو مورد، نیازمند اندازه‌گیری است، نه حدس و گمان.

چرا میزبانی VPS در نیویورک عمدتاً در نیوجرسی انجام می‌شود

منهتن محل قرارگیری هتل‌های مخابراتی (carrier hotels) است. ساختمان 60 Hudson Street مشهورترین آن‌هاست: یک بنای سبک Art Deco در منطقه Tribeca که در سال 1930 تکمیل شد و بیش از 300 اپراتور و ارائه‌دهنده خدمات ابری به همراه مراکز تبادل داده‌ای که به منطقه سرویس می‌دهند، از جمله DE-CIX New York و NYIIX، در آن مستقر هستند. ساختمان 32 Avenue of the Americas نیز در چند بلوک آن‌طرف‌تر همین وظیفه را بر عهده دارد و 165 Halsey Street در نیوآرک، معادل همین مراکز در سمت نیوجرسی است.

این ساختمان‌ها محل تلاقی شبکه‌ها با یکدیگر هستند. این مکان‌ها محل استقرار حجم عظیمی از توان پردازشی نیستند، زیرا هزینه برق و فضای کف در منهتن بسیار بالاست و توسعه آن دشوار است. سالن‌های بزرگ سرور در آن سوی رودخانه هادسون، در مناطقی مانند Secaucus، Weehawken، Carteret، Piscataway و Newark قرار دارند. ارائه‌دهنده‌ای که یک VPS با عنوان «نیویورک» می‌فروشد، تقریباً همیشه به معنای داشتن یک رک در جایی در این محدوده، در فاصله حدود 40 کیلومتری از مرکز شهر (Midtown) است. هزینه فیبر نوری اضافی برای این فاصله بسیار کمتر از 1 میلی‌ثانیه است، بنابراین یک workload وب هرگز متوجه این تأخیر نخواهد شد. تنها در صورتی که به یک cross-connect به شبکه خاصی نیاز دارید، بپرسید که سرور در کدام ساختمان قرار دارد.

چه عواملی ظرفیت را به این کلان‌شهر جذب کرد

چهار عامل که هر کدام دیگری را تقویت می‌کند.

• کابل‌های ترنس‌اتلانتیک در همسایگی قرار دارند. Wall Township و Manasquan در ساحل New Jersey شلوغ‌ترین خوشه در کشور هستند. کابل Havfrue که با نام AEC-2 فروخته می‌شود، از Wall به Blaabjerg در دانمارک کشیده شده و شاخه‌هایی به ایرلند و نروژ دارد. کابل Seabras-1 از همان ایستگاه به برزیل می‌رود و TGN Atlantic به اروپا متصل می‌شود. کابل Apollo از Bude در انگلستان و Lannion در فرانسه به Manasquan می‌رسد. کابل Grace Hopper متعلق به Google در Bellport در Long Island قرار دارد و از سپتامبر 2022 ترافیک را به Bude منتقل می‌کند.
• صرافی‌ها از Wall Street خارج شدند. موتور تطبیق NYSE در Mahwah، موتور Nasdaq در Carteret و موتور Cboe در Secaucus اجرا می‌شوند. معامله‌گران به این سایت‌ها مثلث سهام می‌گویند. شرکت‌هایی که به داده‌های بازار در مقیاس میکروثانیه نیاز دارند، باید در کنار یکی از این سایت‌ها فضا اجاره کنند و آن تقاضا، هزینه فیبر نوری را تأمین کرد که بقیه ما اکنون از آن استفاده می‌کنیم.
• رسانه و تبلیغات در اینجا مستقر هستند. یک حراج مناقصه بلادرنگ (real-time bidding) باید پیش از تکمیل بارگذاری صفحه، پاسخ را برگرداند؛ بنابراین صرافی‌های تبلیغاتی در کنار شبکه‌های آژانسی که به آن‌ها خدمات می‌فروشند، ساخته شدند.
• شبکه‌ها به جایی می‌روند که شبکه‌ها از قبل حضور دارند. وقتی چند صد اپراتور در یک ساختمان حضور دارند، برای ساختمان بعدی، پیوستن به آن‌ها نسبت به ساخت‌وساز در هر جای دیگر، ترانزیت ارزان‌تر و peering بهتری به همراه دارد.

برای خریدار VPS، هیچ‌کدام از این‌ها جنبه اعتبار ندارد. این یعنی ترانزیت رقابتی است، peering متراکم است و مسیر به اروپا کوتاه است، زیرا از همان‌جایی شروع می‌شود که کابل‌ها آغاز می‌شوند.

هزینه واقعی یک رفت و برگشت (Round Trip)

سرعت نور در شیشه حدود 200,000 کیلومتر بر ثانیه است که تقریباً دو سوم سرعت آن در خلأ محسوب می‌شود. این یعنی به ازای هر 100 کیلومتر فیبر نوری، پیش از آنکه حتی یک روتر به بسته (packet) دست بزند، 1 میلی‌ثانیه زمان برای رفت و برگشت (RTT) صرف می‌شود. مسیرهای واقعی طولانی‌تر از مسافت روی نقشه هستند، زیرا فیبرهای نوری به جای خطوط مستقیم، از مسیرهای دارای حق عبور و بسترهای دریایی پیروی می‌کنند.

هزینه نهایی فقط یک رفت و برگشت نیست؛ بلکه تعداد رفت و برگشت‌هایی است که پروتکل شما به آن نیاز دارد. یک اتصال HTTPS جدید، یک رفت و برگشت را صرف دست‌دادن (handshake) پروتکل TCP (پروتکل کنترل انتقال)، یک رفت و برگشت دیگر را صرف دست‌دادن TLS (امنیت لایه انتقال) نسخه 1.3 و یک رفت و برگشت دیگر را برای ارسال درخواست و دریافت اولین بایت‌ها صرف می‌کند. این یعنی پیش از آنکه مرورگر حتی یک خط HTML ببیند، سه رفت و برگشت انجام شده است. پروتکل TLS 1.2 یک رفت و برگشت چهارم نیز اضافه می‌کند.

[
  {
    "label": "Same metro",
    "rtt_ms": 5,
    "https_first_byte_ms": 15,
    "six_call_chain_ms": 30
  },
  {
    "label": "New York to Dallas",
    "rtt_ms": 38,
    "https_first_byte_ms": 114,
    "six_call_chain_ms": 228
  },
  {
    "label": "New York to London",
    "rtt_ms": 78,
    "https_first_byte_ms": 234,
    "six_call_chain_ms": 468
  },
  {
    "label": "New York to Singapore",
    "rtt_ms": 230,
    "https_first_byte_ms": 690,
    "six_call_chain_ms": 1380
  }
]

آن ستون‌ها محاسبات ریاضی هستند، نه اندازه‌گیری‌های تجربی: اولین بایت نیازمند سه رفت و برگشت است و ستون زنجیره (chain) مربوط به صفحه‌ای است که شش فراخوانی API وابسته را یکی پس از دیگری اجرا می‌کند. در محدوده شهری با تأخیر 5 میلی‌ثانیه، برپایی اتصال نامحسوس است. در آن سوی اقیانوس اطلس با تأخیر 78 میلی‌ثانیه، همان صفحه 234 میلی‌ثانیه منتظر اولین بایت HTML می‌ماند و زنجیره شش‌تایی فراخوانی‌ها، 468 میلی‌ثانیه را صرفاً در انتظار سپری می‌کند. از نیویورک تا سنگاپور با تأخیر 230 میلی‌ثانیه، هزینه آن زنجیره 1380 میلی‌ثانیه خواهد بود.

پیش از جابه‌جایی سرور، ستون زنجیره را بررسی کنید. استفاده مجدد از اتصال (Connection reuse) و ازسرگیری نشست TLS (TLS session resumption)، رفت و برگشت‌هایی را که مکرراً بابت آن‌ها هزینه می‌پرداختید، حذف می‌کنند. تبدیل شش فراخوانی وابسته به دو فراخوانی موازی، زمان بیشتری نسبت به نزدیک‌تر کردن سرور به یک قاره دیگر صرفه‌جویی می‌کند. زمانی سرور را جابه‌جا کنید که رفت و برگشت‌ها غیرقابل‌کاهش باشند: مانند یک ورود به سیستم (login) یا نوشتن در پایگاه داده که کلاینت شما قادر به دسته‌بندی (batch) آن نیست.

زمان‌های رفت و برگشت معمول از یک VPS در منطقه نیویورک

[
  {
    "label": "Within the NY and NJ metro",
    "rtt_ms": 2
  },
  {
    "label": "Ashburn, Virginia",
    "rtt_ms": 8
  },
  {
    "label": "Toronto",
    "rtt_ms": 14
  },
  {
    "label": "Chicago",
    "rtt_ms": 22
  },
  {
    "label": "Dallas",
    "rtt_ms": 38
  },
  {
    "label": "Miami",
    "rtt_ms": 40
  },
  {
    "label": "Los Angeles",
    "rtt_ms": 70
  },
  {
    "label": "London",
    "rtt_ms": 78
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 88
  },
  {
    "label": "Sao Paulo",
    "rtt_ms": 120
  }
]

این ارقام را به عنوان مقادیر معمول منتشرشده در نظر بگیرید، نه اندازه‌گیری‌های انجام‌شده از یک ماشین خاص. این‌ها محدوده‌هایی هستند که معمولاً برای میزبان‌های دارای اتصال مناسب در مسیرهای انتقال عادی ذکر می‌شوند و مسیر شبکه شما ممکن است مقادیری کمتر یا بیشتر از این‌ها داشته باشد. فاصله Ashburn حدود 8 میلی‌ثانیه است؛ این فاصله به اندازه‌ای کم است که یک VPS در نیویورک می‌تواند بدون افت کارایی محسوس، سرویس‌های موجود در کلاستر ویرجینیا را فراخوانی کند. فاصله تا Toronto حدود 14 میلی‌ثانیه است. London در نزدیکی 78 میلی‌ثانیه و Frankfurt در نزدیکی 88 میلی‌ثانیه قرار دارند؛ به همین دلیل است که یک سرور در ساحل شرقی می‌تواند به کاربران اروپایی خدمات قابل‌قبولی ارائه دهد، اما سروری در ساحل غربی قادر به این کار نیست.

چه زمانی انتخاب موقعیت مکانی در ساحل شرقی تصمیم درستی است

• بخش عمده‌ای از کاربران شما در کریدور بوستون تا واشینگتن قرار دارند. این نوار جغرافیایی سهم بزرگی از تقاضای اینترنت در ایالات متحده را به خود اختصاص داده است و تمام این نقاط تنها چند میلی‌ثانیه با این کلان‌شهر فاصله دارند.
• شما از یک ماشین واحد به کاربران شرق ایالات متحده و اروپا سرویس می‌دهید. نیویورک ارزان‌ترین راهکار میانه است، زیرا مسیر ترنس‌اتلانتیک از اینجا آغاز می‌شود.
• شما به چیزی وابسته هستید که از قبل در این کلان‌شهر مستقر است: یک فید داده‌های بازار، یک ad exchange، یا یک API شریک در Secaucus یا Ashburn.
• شما می‌خواهید بدون میزبانی در کانادا، مسیر کوتاهی به آنجا داشته باشید. تورنتو حدود 14 میلی‌ثانیه فاصله دارد. اگر اقامت داده در کانادا یک الزام قطعی باشد، موضوع متفاوت است و آنچه در انتخاب میزبانی VPS کانادا واقعاً اهمیت دارد به بررسی آن می‌پردازد.

زمانی که یک موقعیت مرکزی در ایالات متحده از ساحل شرقی پیشی می‌گیرد

به جای میانگین، برای بدترین حالت طراحی کنید. کاربری که در دورترین ساحل قرار دارد، تأخیر را حس می‌کند، اما کاربری که در ایالت مجاور است، متوجه آن نمی‌شود.

[
  {
    "label": "New York metro",
    "to_new_york_ms": 2,
    "to_los_angeles_ms": 70
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 38,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Chicago",
    "to_new_york_ms": 22,
    "to_los_angeles_ms": 50
  },
  {
    "label": "Los Angeles",
    "to_new_york_ms": 70,
    "to_los_angeles_ms": 2
  }
]

یک سرور در نیویورک با Los Angeles فاصله 70 میلی‌ثانیه دارد. یک سرور در دالاس با نیویورک 38 میلی‌ثانیه و با Los Angeles 35 میلی‌ثانیه فاصله دارد؛ بنابراین بدترین حالت تأخیر آن در سراسر کشور، تقریباً نصف نیویورک است. زمانی که نقشه ترافیک شما واقعاً ملی است، این موقعیت برتری محسوب می‌شود و دلایل انتخاب VPS در دالاس این بازار را به تفصیل بررسی می‌کند. شیکاگو گزینه منطقی دیگر در مرکز است که البته به سمت شرق متمایل است.

دو موقعیت دیگر نیز انتخاب نیویورک را زیر سؤال می‌برند. اگر کاربران شما در انتاریو یا کبک متمرکز هستند، یک VPS در تورنتو به جای اضافه کردن 14 میلی‌ثانیه تأخیر از نیویورک، مستقیماً به آن‌ها سرویس می‌دهد. و اگر تقریباً تمام ترافیک شما بین سرورهای خودتان جابه‌جا می‌شود، آن‌ها را در یک منطقه نگه دارید و به جغرافیا فکر نکنید؛ چرا که یک پرش بین‌منطقه‌ای (cross-region hop)، هرگونه مزیتی که از نزدیکی به کاربران به دست آورده‌اید را خنثی می‌کند.

آن را اندازه بگیرید، به نقشه بازاریابی اعتماد نکنید

نقشه پوشش‌دهی به شما می‌گوید که یک ساختمان کجا قرار دارد. این نقشه به شما نمی‌گوید که بسته‌ها چگونه به آن ساختمان می‌رسند، و آن مسیر توسط قراردادهای ترانزیت و توافق‌های peering تعیین می‌شود، نه توسط فاصله. بنابراین از جایی که کاربران شما هستند، اندازه‌گیری کنید. یک لپ‌تاپ روی اینترنت پهن‌باند خانگی، کاوشگر (probe) بهتری نسبت به خود VPS است که در سمتِ باکیفیت شبکه قرار دارد.

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

با یک round trip ساده شروع کنید و به جای 4 کاوشگر، 20 کاوشگر بفرستید. نام میزبان (hostname) را با سرور خود جایگزین کنید.

ping -c 20 your-server.example.com

خط آخر rtt min/avg/max/mdev را گزارش می‌دهد. میانگین، کم‌کاربردترین عدد در آنجاست. mdev همان jitter است و jitter بالا، حتی زمانی که میانگین سالم به نظر می‌رسد، جلسات صوتی و تعاملی را مختل می‌کند. در یک مسیر کابلی، هرگونه packet loss بالاتر از صفر، یک خطا محسوب می‌شود، نه نویز.

سپس پیدا کنید که زمان کجا صرف می‌شود.

mtr -rwzbc 100 your-server.example.com

mtr تعداد 100 کاوشگر به هر hop می‌فرستد و میزان loss و latency را برای هر hop چاپ می‌کند، و -z شماره AS (سیستم خودمختار) را اضافه می‌کند تا بتوانید ببینید کدام شبکه مالک هر hop است. loss گزارش‌شده در یک hop میانی که در hopهای بعدی ناپدید می‌شود، واقعی نیست: آن روتر در حال محدود کردن نرخ (rate-limiting) پاسخ‌های ICMP است که خودش باید تولید کند، که این موضوع هیچ هزینه‌ای برای ترافیک شما ندارد. lossای که از یک hop شروع می‌شود و در تمام hopهای بعدی ادامه می‌یابد، واقعی است.

پروتکل ICMP همچنین برای قضاوت در مورد یک سرویس وب پروتکل اشتباهی است، زیرا بسیاری از شبکه‌ها به آن اولویت پایینی می‌دهند. چیزی را که واقعاً ارائه می‌دهید، زمان‌سنجی کنید.

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

هر مقدار، ثانیه‌های تجمعی از شروع است، بنابراین برای خواندن آن باید تفریق انجام دهید. time_connect منهای time_namelookup یک round trip است. time_appconnect منهای time_connect همان TLS handshake است. time_starttransfer منهای time_appconnect یک round trip دیگر به اضافه زمانی است که برنامه شما برای پاسخ‌دهی صرف کرده است. آن تفریق آخر، تشخیص نهایی است. اگر به یک round trip نزدیک باشد، شبکه محدودیت است و یک سرور نزدیک‌تر کمک خواهد کرد. اگر چندین برابر round trip باشد، برنامه شما کند است و جابه‌جایی آن هیچ تغییری ایجاد نمی‌کند.

for i in $(seq 1 20); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'

پیش از انتخاب نهایی، همان تست را روی یک نمونه آزمایشی در هر مکان کاندید اجرا کنید. روش کامل برای بنچمارک کردن یک VPS علاوه بر شبکه، دیسک و CPU را نیز پوشش می‌دهد تا انتخاب شما فقط بر اساس latency نباشد.

چه تغییرات دیگری با داشتن آدرس نیویورک رخ می‌دهد

قیمت اولین مورد است. هزینه برق و فضای کف در کلان‌شهر نیویورک نسبت به تگزاس یا غرب میانه بیشتر است و برخی از ارائه‌دهندگان این هزینه را به عنوان اضافه‌بهای مکان (per-location surcharge) دریافت می‌کنند، در حالی که برخی دیگر آن را در کل ناوگان خود سرشکن می‌کنند. تا اوت 2026 هیچ قانون واحدی وجود ندارد، بنابراین پیش از آنکه فرض کنید جریمه‌ای وجود دارد، مشخصات یکسانی را در دو مکان مختلف در صفحه سفارش همان ارائه‌دهنده قیمت‌گذاری کنید. هزینه واقعی یک VPS در ماه چقدر است بقیه صورت‌حساب را پوشش می‌دهد.

قانون از سرور پیروی نمی‌کند. قانون SHIELD نیویورک وظایف اطلاع‌رسانی در صورت نقض امنیتی و اقدامات حفاظتی معقول را برای هر کسی که اطلاعات خصوصی یک ساکن نیویورک را در اختیار دارد، تعیین می‌کند؛ فارغ از اینکه آن داده کجا قرار دارد. انتقال سرور به دالاس این وظیفه را از بین نمی‌برد و انتقال آن به منهتن نیز آن را ایجاد نمی‌کند. همین موضوع در مورد GDPR (مقررات عمومی حفاظت از داده‌ها) و کاربران اروپایی شما نیز صدق می‌کند. مکان زمانی اهمیت پیدا می‌کند که یک قرارداد یا مقررات بخشی، نام یک کشور را ذکر کرده باشد، که این امر در حوزه مراقبت‌های بهداشتی و برخی خدمات مالی رایج است.

ریسک برق و سیل شایسته یک پاراگراف جداگانه است. هنگامی که طوفان Sandy در اکتبر 2012 رخ داد، چندین ساختمان مخابراتی در پایین منهتن به دلیل آب‌گرفتگی پمپ‌های سوخت در زیرزمین و تمام شدن سوخت ژنراتورهای طبقات بالا، سرویس خود را از دست دادند. یک سایت واحد در هر کلان‌شهری، یک نقطه شکست واحد (single point of failure) محسوب می‌شود. نسخه‌های پشتیبان را روی شبکه برق متفاوتی نگه دارید و حداقل یک بار عملیات بازیابی را در جای دیگری انجام دهید تا مطمئن شوید که فرآیند بازیابی کار می‌کند.

FAQ

آیا یک VPS در نیویورک برای کاربران اروپایی سریع‌تر از یک سرور در مرکز ایالات متحده است؟

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

چرا VPS «نیویورک» من در واقع در نیوجرسی قرار دارد؟

زیرا فضای دیتاسنتر و تأمین برق در آنجا قرار دارد. ساختمان‌های منهتن مانند 60 Hudson Street بیشتر هاب‌های اتصال هستند تا سالن‌های بزرگ پردازش؛ بنابراین رک‌ها در Secaucus، Weehawken، Carteret، Piscataway یا Newark قرار می‌گیرند. فیبر نوری اضافی کمتر از یک میلی‌ثانیه تأخیر ایجاد می‌کند که هیچ بار کاری وب متوجه آن نخواهد شد. تنها زمانی که به یک cross-connect به شبکه خاصی در یک ساختمان مشخص نیاز دارید، درخواست مکان دقیق مرکز داده را مطرح کنید.

از کجا بفهمم که آیا تأخیر واقعاً مشکل من است؟

آنالیز زمان‌بندی curl را اجرا کرده و مقادیر را تفریق کنید. فاصله بین time_appconnect و time_starttransfer برابر است با یک رفت‌وبرگشت شبکه (round trip) به اضافه زمان پردازش سرور شما. اگر این فاصله بسیار بزرگ‌تر از رفت‌وبرگشتی است که با ping اندازه‌گیری کرده‌اید، تأخیر در داخل اپلیکیشن شماست و انتخاب دیتاسنتر نزدیک‌تر آن را حل نخواهد کرد. اگر فاصله نزدیک به یک رفت‌وبرگشت است و صفحه همچنان کند به نظر می‌رسد، تعداد درخواست‌های متوالی صفحه را بشمارید، زیرا هر درخواست دوباره هزینه یک رفت‌وبرگشت را تحمیل می‌کند.

آیا میزبانی در نیویورک قوانین حریم خصوصی حاکم بر من را تغییر می‌دهد؟

در اکثر موارد خیر. قوانینی مانند SHIELD Act نیویورک و GDPR به این بستگی دارند که داده‌های چه کسی را نگهداری می‌کنید، نه اینکه دیسک در کجا می‌چرخد. مکان سرور زمانی به عامل تعیین‌کننده تبدیل می‌شود که یک قرارداد یا مقررات بخشی، کشور خاصی را نام ببرد؛ این موضوع در حوزه سلامت و بخش‌هایی از خدمات مالی رایج است. پیش از انتخاب مکان برای رعایت الزامات، متن دقیق آن الزامات را مطالعه کنید.

آیا یک CDN می‌تواند جایگزین یک VPS با موقعیت مکانی مناسب شود؟

برای فایل‌های استاتیک، بله. یک CDN (شبکه توزیع محتوا) تصاویر و اسکریپت‌ها را در نزدیکی کاربران شما کش می‌کند و بخش بزرگی از فاصله را برای آن درخواست‌ها حذف می‌کند. CDN نمی‌تواند یک داشبورد که کاربر در آن لاگین کرده یا عملیات نوشتن در دیتابیس را کش کند، بنابراین این موارد همچنان باید به سرور اصلی (origin) شما ارسال شوند و هزینه کامل رفت‌وبرگشت را پرداخت کنند. سرور اصلی را در نزدیکی کاربرانی که داده‌ها را می‌نویسند قرار دهید و اجازه دهید CDN بقیه کارها را انجام دهد.