تقریبا همه ما روزی ده ها بار این کار رو انجام می دیم.

مرورگر رو باز می کنیم، یه آدرس مثل:

dicode.ir

رو می زنیم و Enter می کنیم.

چند لحظه بعد هم سایت جلومون باز می شه.

خیلی ساده به نظر می رسه، نه؟

اما پشت همین چند لحظه کلی اتفاق مختلف افتاده.

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

مرورگر، DNS و Server توی همین چند لحظه با هم کار می کنن تا سایت به دست ما برسه. MDN هم مسیر کلی رو به همین شکل توضیح می ده: پیدا کردن مقصد با DNS، فرستادن HTTP Request به Server و دریافت Response. ([MDN Web Docs][2])

توی این مقاله می خوایم کل این مسیر رو از صفر باز کنیم.

مسیر کلی ما اینه:

Code → Server → IP → Port → Web Server → Domain → DNS → HTTPS → User

البته این ترتیب، ترتیب یاد گرفتن مفاهیم ماست. آخر مقاله مسیر واقعی اتفاقاتی که بعد از زدن Enter می افته رو کامل کنار هم می چینیم.

فرض کن یه سایت ساختیم و برنامه رو روی سیستم خودمون اجرا کردیم.

مثلا مرورگر رو باز می کنیم و می زنیم:

localhost:3000

و سایت هم بدون مشکل باز می شه.

پس سایت ما روی اینترنت اومده؟

نه.

localhost خیلی ساده یعنی همین دستگاه خودمون.

وقتی برنامه روی localhost اجرا شده، ما داریم از همون کامپیوتری که برنامه روش اجرا شده بهش دسترسی پیدا می کنیم.

برای همین اگه من روی لپ تاپ خودم بزنم:

localhost:3000

ممکنه سایت رو ببینم.

ولی اگه همین آدرس رو برای شما بفرستم، کامپیوتر شما می ره سراغ localhost خودش، نه کامپیوتر من.

پس:

اینکه پروژه روی سیستم ما اجرا می شه با اینکه واقعا روی اینترنت در دسترس باشه دو تا چیز متفاوته.

حالا سوال مهم اینه:

چطوری کاری کنیم برنامه فقط روی لپ تاپ خودمون نباشه و بقیه هم بتونن ببیننش؟

ما به یه کامپیوتر نیاز داریم که برنامه مون روی اون اجرا بشه و از اینترنت قابل دسترسی باشه.

اینجاست که به Server می رسیم.

خیلی ساده بخوام بگم، Server یه کامپیوتره که قراره به دستگاه های دیگه سرویس بده.

این کامپیوتر معمولا توی یه دیتاسنتر قرار داره، همیشه روشنه، اینترنت مناسبی داره و ما پروژه مون رو روی اون اجرا می کنیم.

یکی از چیزهایی که احتمالا زیاد اسمش رو شنیدی VPS هست.

VPS مخفف:

Virtual Private Server

یا سرور خصوصی مجازیه.

یعنی به جای اینکه برای پروژه خودمون یه کامپیوتر فیزیکی کامل بخریم و بذاریم یه گوشه، می تونیم یه سرور مجازی بگیریم و برنامه مون رو روی اون اجرا کنیم.

حالا سایت ما دیگه فقط روی لپ تاپ شخصی مون نیست.

روی یه Server قرار گرفته.

ولی یه مشکل جدید داریم.

هر Server برای اینکه در شبکه پیدا بشه به یه آدرس نیاز داره.

اینجا به IP Address می رسیم.

می تونی IP رو فعلا مثل آدرس یه خونه تصور کنی.

همون طور که برای پیدا کردن یه خونه باید آدرسش رو داشته باشی، برای پیدا کردن Server هم به یه آدرس شبکه نیاز داریم.

مثلا:

203.0.113.x

این فقط یه IP نمونه برای توضیح ماست.

فرض کنیم Server ما یه Public IP داره.

Public IP یعنی آدرسی که از طریق اینترنت عمومی می شه به سمتش ارتباط برقرار کرد.

پس تا اینجا دو چیز داریم:

Server → کامپیوتری که برنامه روی اون اجرا شده

IP → آدرس اون Server

ولی داستان هنوز تموم نشده.

چون روی یه Server ممکنه فقط یک برنامه اجرا نشده باشه.

فرض کن IP مثل آدرس یه ساختمونه.

ما به ساختمون رسیدیم.

ولی داخل اون ساختمون کلی در مختلف وجود داره.

هر کدوم از این درها می تونن ما رو به یه سرویس متفاوت برسونن.

اینجا مفهوم Port به درد ما می خوره.

خیلی خلاصه:

و:

مثلا بعضی Port های معروف این ها هستن:

22 → SSH

80 → HTTP

443 → HTTPS

و برنامه خودمون هم ممکنه مثلا روی:

3000

اجرا شده باشه.

IANA هم Port شماره 22 رو برای SSH، شماره 80 رو برای HTTP و شماره 443 رو برای HTTPS ثبت کرده. ([IANA][3])

حالا یه سوال خیلی خوب پیش میاد.

اگه برنامه ما روی Port شماره 3000 اجرا شده، چرا کاربر نمیاد بنویسه:

dicode.ir:3000

اینجاست که Nginx وارد داستان می شه.

Nginx رو تقریبا "اِن جین اِکس" تلفظ می کنن.

Nginx کاربردهای مختلفی داره، ولی چیزی که توی سناریوی ما مهمه قابلیت Reverse Proxy اونه.

اسم Reverse Proxy شاید یکم عجیب به نظر بیاد، ولی مفهومش خیلی ساده تره.

فرض کن وارد یه ساختمون می شی و جلوی در یه بخش پذیرش وجود داره.

تو لازم نیست بدونی دقیقا کارمند مورد نظرت کدوم اتاق نشسته.

درخواستت رو به پذیرش می گی و پذیرش تو رو به جای درست هدایت می کنه.

Nginx هم می تونه یه همچین نقشی داشته باشه.

مثلا:

Internet → Nginx → localhost:3000 → App

کاربر درخواستش رو می فرسته.

Nginx درخواست رو دریافت می کنه.

بعد درخواست رو به برنامه ما که مثلا روی Port شماره 3000 اجرا شده منتقل می کنه.

در مستندات رسمی Nginx هم proxy_pass دقیقا برای فرستادن Request به Server یا Application دیگه استفاده می شه؛ حتی نمونه رسمی با آدرسی مثل localhost:8000 وجود داره. ([Nginx][4])

در نتیجه کاربر لازم نیست بدونه Application اصلی ما روی چه Port داخلی اجرا شده.

خب، تا اینجا Server و IP داریم.

ولی یه مشکل خیلی ساده وجود داره:

کی دوست داره IP حفظ کنه؟

فرض کن برای ورود به هر سایت مجبور بودی یه عدد طولانی حفظ کنی.

خیلی سریع اینترنت تبدیل می شد به عذاب!

اینجاست که Domain وارد داستان می شه.

به جای اینکه مثلا یه IP رو حفظ کنیم، یه اسم ساده مثل:

dicode.ir

داریم.

Domain در واقع اسم قابل فهم تریه که ما آدم ها باهاش راحت تریم.

اما یه نکته مهم:

اینکه یه Domain بخری به این معنی نیست که سایتت آنلاین شده.

Domain اسم سایته.

Server جاییه که برنامه روی اون اجرا می شه.

حالا باید یه چیزی وجود داشته باشه که بفهمه:

dicode.ir

باید ما رو به کدوم Server برسونه.

اینجاست که DNS وارد می شه.

DNS مخفف:

Domain Name System

هست.

یکی از ساده ترین تشبیه ها برای DNS اینه:

ما اسم رو داریم:

dicode.ir

ولی برای پیدا کردن مقصد شبکه به IP نیاز داریم.

پس باید بفهمیم این اسم به چه IPای مربوطه.

اینجا یه DNS Lookup اتفاق می افته.

Lookup یعنی جستجو یا پیدا کردن اطلاعات.

در یه مدل ساده:

dicode.ir → DNS Lookup → IP Server

یکی از رکوردهایی که اینجا ممکنه ببینی A Record هست.

A Record یه نام دامنه رو به یه IPv4 Address متصل می کنه.

Cloudflare هم در مستندات DNS خودش توضیح می ده که A Record برای نگاشت Domain Name به IPv4 استفاده می شه و AAAA Record همین کار رو برای IPv6 انجام می ده. ([Cloudflare Docs][5])

پس حالا Browser می دونه Server مورد نظرش کجاست.

اما هنوز باید با اون Server حرف بزنه.

حالا مرورگر مقصد رو پیدا کرده.

ولی چی باید به Server بگه؟

اینجا می رسیم به HTTP.

HTTP مخفف:

Hypertext Transfer Protocol

هست.

اسمش رو لازم نیست حفظ کنی.

چیزی که مهمه اینه که HTTP یه Protocol برای ارتباط Client و Server در وبه.

مرورگر یه Request می فرسته.

Request یعنی درخواست.

مثلا:

Server این Request رو دریافت می کنه و بعد یه Response یا پاسخ بر می گردونه.

مثلا:

200 OK

یعنی درخواست با موفقیت انجام شده.

احتمالا این اعداد رو قبلا هم دیدی:

200 → موفق

404 → چیزی که خواستی پیدا نشد

500 → خطایی سمت Server اتفاق افتاده

MDN هم HTTP رو زبان ارتباط Client و Server معرفی می کنه و همین جریان Request و Response و کدهایی مثل 200، 404 و 500 رو توضیح می ده. ([MDN Web Docs][2])

پس تا اینجا:

Browser → HTTP Request → Server

و بعد:

Server → HTTP Response → Browser

اما یه مشکل داریم.

HTTP به تنهایی قرار نیست داده های ما رو رمزنگاری کنه.

یعنی اگه اطلاعات روی یه ارتباط ناامن جابه جا بشن، امکان مشاهده یا دستکاری اون ها در مسیر وجود داره.

ما یه چیزی می خوایم که ارتباط بین Browser و Server رو امن کنه.

اینجاست که می رسیم به:

HTTPS یعنی استفاده از HTTP روی یه ارتباط امن با TLS.

TLS مخفف:

Transport Layer Security

هست.

طبق توضیح MDN، TLS سه ویژگی خیلی مهم برای ارتباط فراهم می کنه: Encryption، Integrity و Authentication. ([MDN Web Docs][6])

یعنی رمزنگاری.

اطلاعات بین Browser و Server طوری منتقل می شن که یه نفر وسط مسیر نتونه راحت محتوای اصلی رو بخونه.

یعنی تایید هویت.

Browser باید مطمئن بشه داره با Server مورد انتظار ارتباط برقرار می کنه.

یعنی مطمئن بشیم اطلاعات وسط راه مخفیانه تغییر نکردن.

برای این ارتباط امن، مفهوم Certificate یا گواهی دیجیتال هم وارد داستان می شه.

یکی از سرویس هایی که احتمالا اسمش رو شنیدی Let's Encrypt هست.

Let's Encrypt یه Certificate Authority رایگان و خودکاره که Certificate های مورد نیاز برای فعال کردن HTTPS رو ارائه می کنه. ([Let's Encrypt][7])

پس اون HTTPS و قفل کنار آدرس سایت فقط یه ظاهر قشنگ نیست.

پشتش یه ارتباط امن وجود داره.

خب.

حالا همه تکه های پازل رو داریم.

برگردیم اول مقاله.

Browser رو باز می کنیم.

می نویسیم:

dicode.ir

و Enter رو می زنیم.

حالا اتفاقات رو مرحله به مرحله ببینیم.

Browser دامنه dicode.ir رو دریافت می کنه.

مرورگر باید بفهمه این Domain مربوط به کدوم مقصد شبکه است.

پس اطلاعات DNS بررسی می شه و IP مورد نیاز پیدا می شه.

حالا مقصد رو داریم و Browser می تونه به Server ارتباط برقرار کنه.

در سناریوی HTTPS، ارتباط امن با TLS برقرار می شه و سرویس HTTPS معمولا از Port شماره 443 استفاده می کنه. ([IANA][8])

در معماری مثال ما، Nginx Request رو می گیره.

مثلا Application اصلی ما روی:

localhost:3000

در حال اجراست.

برنامه Request رو پردازش می کنه و Response می سازه.

جواب دوباره به Browser می رسه.

Render یعنی Browser فایل ها و اطلاعاتی که دریافت کرده رو پردازش کنه و صفحه نهایی رو روی نمایشگر نشون بده.

و تمام.

همون کاری که از دید ما شاید در کمتر از چند ثانیه انجام شد، پشت صحنه چند مرحله مختلف داشت.

حالا اگه یه پروژه روی لپ تاپت داشته باشی و بخوای واقعا آنلاینش کنی، در سناریوی ساده ای که توی این مقاله داشتیم مسیر تقریبا این شکلی می شه:

ساخت پروژه

↓

گرفتن VPS

↓

اتصال با SSH

↓

بردن یا Clone کردن کد روی Server

↓

اجرای Application

↓

تنظیم Nginx

↓

تنظیم DNS دامنه

↓

فعال کردن HTTPS

↓

تست سایت

البته پروژه های واقعی ممکنه جزئیات و سرویس های بیشتری داشته باشن، ولی مدل ذهنی اصلی همینه.

اینجاست که فهمیدن این مسیر واقعا به درد می خوره.

دیگه وقتی سایت باز نمی شه لازم نیست شانسی همه چیز رو دستکاری کنیم.

از اول مسیر بررسی می کنیم.

Domain درسته؟

↓

DNS درست تنظیم شده؟

↓

Server قابل دسترسیه؟

↓

Port درسته؟

↓

Nginx داره کار می کنه؟

↓

Application اجرا شده؟

↓

HTTPS Certificate مشکلی نداره؟

با همین مدل، یه مشکل بزرگ تبدیل می شه به چند مشکل کوچیک که خیلی راحت تر می شه پیداشون کرد.

اگه بخوایم کل مقاله رو توی یه خط خلاصه کنیم:

Browser → DNS → Server → Nginx → App → HTTPS Response

ما کار رو از یه پروژه روی localhost شروع کردیم.

بعد فهمیدیم برای در دسترس بودن از اینترنت به Server نیاز داریم.

برای پیدا کردن Server از IP استفاده می کنیم.

Port مشخص می کنه با کدوم سرویس کار داریم.

Domain یه اسم قابل فهم برای انسانه.

DNS کمک می کنه این اسم رو به مقصد درست وصل کنیم.

HTTP زبان Request و Response بین Browser و Server رو می سازه.

Nginx می تونه Request رو به Application ما هدایت کنه.

و HTTPS کمک می کنه این ارتباط امن باشه.

حالا دفعه بعدی که یه آدرس رو توی Browser می زنی و Enter می کنی، می دونی پشت اون صفحه ای که در چند لحظه برات باز می شه چه مسیری طی شده.

و تازه از اینجا به بعد می تونیم بریم سراغ قسمت جذاب تر:

اینکه واقعا یه VPS بگیریم، پروژه مون رو روی Server اجرا کنیم، Domain رو وصل کنیم، Nginx رو تنظیم کنیم و HTTPS رو فعال کنیم.