مقدمه‌ای بر راه‌اندازی ماژول ESP8266 | قسمت دهم مفاهیم شبکه و اینترنت در راه‌اندازی ماژول ESP8266

امیدوارم مطالب نه قسمت قبل خوب بوده باشه. احتمالاً پیش خودتون گفتید “اینا به چه درد من میخوره؟! پس راه‌اندازی ماژول کجاست؟”. نوبتی هم باشه دیگه نوبت خود ماژول ESP8266 هستش. الآن دیگه با مفاهیم شبکه، آی­پی، اینترنت، وب و… آشنا هستید و فقط باید تمام ذهنتون را روی بحث آموزش ESP8266 متمرکز کنید.

تعدادی از این استانداردها به شرح زیر هستند:

استاندارد 802.11 چیست؟

استاندارد تمامی دستگاه­ های وایرلس، با عبارت معروف 802.11 نشان داده می‌شود. اعداد و حروف روبروی این عبارت نشان دهنده دیگر استاندارهای مختلف وایرلس است. محصولاتی که از تکنولوژی Wi-Fi بهره می‌برند، از استانداردهای 802.11a ،802.11b ،802.11g و 802.11n برخوردارند. استاندارد 802.11 که اولین استاندارد شبکه بی سیم محلی یا WLAN است، در سال 1997 توسط IEEE ارائه شد.

اما این استاندارد وایرلس سریعاً از دوره تولید انبوه خارج شد و تمامی ادوات ساخته شده بر اساس این استاندارد دیگر از رده خارج محسوب شده و تولید نمی‌شوند. دلیل غروب زود هنگام استاندارد 802.11، سرعت پایین پهنای باند آن بود. پهنای باندی که این استاندارد پشتیبانی می‌کرد صرفا پهنای باند 2Mbps بود.

معرفی استاندارد 802.11b

حدود دو سال بعد، IEEE استاندارد سابق خود را گسترش داد و این بار آن را با نام 802.11b ارائه کرد. پشتیبانی پهنای باند در این استاندارد ارتقاء داشته و از 2 به 11Mbps ارتقاء یافته است. البته این استاندارد بی­نقص نیست. این استاندارد نیز یکی دیگر از معیاب استاندارد اصلی و سابق را در خود دارد و آن هم استفاده از فرکانس سیگنالی رگوله نشده است.

در هر حال به دلیل نبود رگولاسیون، در صورتی که دستگاه ­های با استاندارد 802.11b در نزدیکی دستگاه ­های فرکانس­دار دیگر قرار بگیرند، ممکن است با آنها تداخل فرکانسی پیدا کنند. این دستگاه ها اغلب دستگاه هایی چون مایکرویو، تلفن بی سیم و… هستند که از بازه فرکانسی 2.4 گیگاهرتز استفاده می‌کنند. بازه فرکانسی مناسبشان، به آنها اجازه نفوذ از سدهای سختی چون دیوار را می‌دهد.

ظهور استاندارد 802.11a

همزمان با توسعۀ 802.11b، مؤسسۀ IEEE استاندارد 802.11 را به شیوۀ دیگری نیز ارتقاء داد و نام آن را 802.11a نهاد. ازآنجایی‌که استاندارد 802.11b خیلی سریع‌تر محبوبیت یافت و رایج شد، برخی تصور می‌کنند که 802.11a بعد از 802.11b به وجود آمده. اما حقیقت این است که 802.11a هم‌زمان با 802.11b ساخته شد. باتوجه‌به هزینۀ بالاتر، 802.11a عموماً مصارف تجاری دارد، درحالی‌که 802.11b بازار مصرف خانگی را بهتر پوشش داده است.

استاندارد 802.11a تا پهنای باند 54Mbps را با فرکانس رگوله شده با طیف 5GHz را پشتیبانی می‌کند. فرکانس بالاتر این استاندارد نسبت به 802.11b، بازۀ شبکه‌های 802.11a را کوچک‌تر می‌کند. فرکانس بالاتر 802.11a به معنای سخت‌تر شدن نفوذ سیگنال‌ها از سد دیوارها و موانع دیگر نیز هست.

معرفی استاندارد 802.11g

استانداردهای 802.11a و 802.11b، در سال 1999 معرفی شدند. حدود 3 تا 4 سال بعد، استاندارد802.11g  معرفی شد. در ساخت این استاندارد سعی شده تا سنگ تمام گذاشته شود و مزایای دو استاندارد قبلی معرفی شده را در کنار هم قرار دهند. در این استاندارد، فرکانس دوباره به حالت رگوله نشده برگشته اما سرعت بالای استاندارد 802.11a در آن حفظ شده.

همین طور سعی شده تا قیمت نهایی با افزایش کمی همراه شود. در اصل این استاندارد از پهنای باند 802.11a یعنی 54Mbps و فرکانس 802.11b یعنی 2.4GHz استفاده می‌کند.

معرفی استاندارد وایرلس 802.11n

جدیدترین استاندارد IEEE در زمینۀ Wi-Fi، استاندارد 802.11n که به استاندارد N هم مشهور است، در سال 2009 معرفی شد. این استاندارد به منظور افزایش پهنای باند 802.11g طراحی شد به این صورت که از چندین سیگنال وایرلس و آنتن استفاده کند.

در استاندارد 802.11n از تکنولوژی MIMO استفاده شده که با استفاده از چندین آنتن باعث افزایش پهنای باند می شود. پهنای باند در این استاندارد تا 300 مگابیت بر ثانیه افزایش یافته است که تقریباً 6 برابر نسل قبلی خود است.

تا اینجا با استاندارد وایرلس 802.11 آشنا شدید. پس اگه این عبارت را توی دیتاشیت ESP8266 دیدید، متوجه موضوع خواهید شد.

پروتکل ­های شبکه در ESP8266

این ماژول برای برقراری ارتباط در شبکه نیاز داره تا حداقل یکی یا چند تا از پروتکل­ های شبکه را اجرا کند. اگر در دیتاشیت دقت کنید، پروتکل­ های شبکه این ماژول را نام‌برده که شاملIPv4 ،TCP  UDP و HTTP است.

باتوجه‌به مطالب قسمت­ های قبل میشه گفت «سیستمی که بتونه پروتکل­ های TCP/IP و UDP/IP را اجرا کنه، می­تونه اکثر پروتکل­ های لایه اپلیکیشن را پشتیبانی کنه.». البته باید دید از نظر نرم افزاری، سیستم موردنظر برای کدوم روش در لایه اپلیکیشن برنامه­ ریزی شده!

این موضوع درباره ESP8266 هم درسته! چه خوب! پس دست طراح یا استفاده‌کننده این ماژول بازه. ولی دقت کنیم که بعضی از این پروتکل­ها (پروتکل ­های لایه اپلیکیشن) پیچیده هستند و کاربرد عمومی ندارند و شاید درمورد شرایطی که ما می­خواهیم استفاده کنیم، خیلی مناسب نباشند (به همین دلیل سازنده این ماژول، سعی کرده تا پروتکل ­ها را محدود کنه!).

چند پروتکل لایه اپلیکیشنی که بیشتر از همه ممکنه ازش استفاده کنیم، شامل پروتکل­ های HTTP ،HTTPS ،FTP ،SMTP و چند مورد دیگه است. البته WebSocket نیز می­تونه تحت HTTP اجرا بشه.

جایگاه اینترنت اشیا کجاست؟ و چه پروتکل­ هایی داره؟

اینترنت اشیا هم روش دیگه ­ای برای تبادل اطلاعات سنسورها از طریق اینترنتِ و یکی از معروف­ ترین پروتکل­ ها در این زمینه MQTT هستش. توی شکل زیر میتونید محل قرارگیری این پروتکل را در لایه ­های شبکه ببینید. پروتکل ­های دیگه اینترنت اشیا رو هم میتونید توی همین شکل ببینید.

پس تا اینجا متوجه شدیم که ماژول ESP8266 با چه پروتکل­ هایی میتونه در اینترنت به تبادل اطلاعات بپردازه. خوب این از این. حالا بریم سراغ روش ایجاد ارتباط کاربر (برنامه‌نویس و طراح پروژه) یا همون راه­اندازی ماژول ESP8266.

درمورد خود ماژول هم روش­ های راه ­اندازی مختلفی وجود داره و حتی اینکه از چه نرم ­افزاری استفاده می‌کنید و… . ساده­ ترین و محدودترین روش راه ­اندازی ماژول، استفاده از AT COMMANDها هستش. این دستورات از طریق پورت سریال (RXD و TXD) ارسال و دریافت میشند. شما میتونید به هر روشی که خواستید این دستورات را با پروتکل UART ارسال و دریافت کنید.

که میتونه از طریق کامپیوتر، میکروکنترلر و… باشه. اگه از میکروکنترلر استفاده می‌کنید، نوع و مدلش اصلاً مهم نیست. فقط باید بتونه پروتکل UART را پشتیبانی کنه! بعضی از دوستان با AVR بعضی دیگه با ARM و بعضیا با ARDUINO این کار رو انجام میدند.

اگر به پایه­ های ماژول دقت کرده باشید می­بینید که به‌غیراز پایه ­های تغذیه و RXD و TXD، پایه ­های دیگه ­ای مثل ADC ،PWM ،I2C و… هم داره! پس این پایه ­ها به چه درد می‌خورند؟! بین لیست AT COMMANDها هم هیچ دستوری برای این پایه ­ها وجود نداره! پس حتماً به‌غیراز روش ارسال AT COMMAND باید روش دیگه­ ای برای کنترل ماژول به‌ویژه پایه ­های ADC ،PWM و… هم وجود داشته باشه.

بله درست حدس زدید. برای یکی مثل من که مبتدی هستش تازه شروع دردسره! البته خیلی نگران نباشد. بهتون میگم چه­ کار کنید تا کمترین درگیری با موارد جدید را داشته باشید. روش دیگه راه اندازی اینه که از ساختار Embedded این ماژول استفاده کنیم.

حالا Embedded چیه؟

در داخل بعضی از آی­سی­ ها علاوه بر بخش­ های اصلی اون آی­سی که کار خودشون رو انجام میدند، یک میکروکنترلر (نسبتاً ضعیف) هم گنجانده (یا Embed) شده. این میکروی داخلی از قبل (در کارخانه سازنده اون آی­سی) برنامه‌ریزی‌شده (برنامه به نام Firmware) تا بتونه واسطه ­ای بین ماژول­ های موجود در اون آی­سی و کسی که از بیرون فرمان میده، باشه.

ترکیب اینها با هم باعث میشه تا اون تراشه کارش رو به‌درستی و کامل انجام بده. بعضی از سازنده ­های این نوع تراشه ­ها اجازه میدند تا کاربر هم به اون میکروی داخلی دسترسی داشته باشه و اگه لازم شد، برنامه‌اش رو تغییر بده.

نکته✅

درضمن یک سری پایه ­های خاص مثل ADC یا پایه ­های خروجی (که بشه از اون به‌عنوان PWM استفاده کرد) هم، برای کاربر قرار میده تا هر وقت لازم شد، از طریق همون میکروی داخلی از این پایه ­ها استفاده بشه. هم خوب شد و هم میتونه بد باشه! خوب ازاین‌جهت که با دسترسی به میکروی نهفته در این ساختار میشه از اون پایه ­ها استفاده کرد و همینطور میشه برنامه دقیق ­تر و کامل­تری داشته باشیم. بد میشه چون پای یه محیط برنامه ­نویسی جدید و احتمالاً یک زبان برنامه‌نویسی جدید به ماجرا باز میشه!

ممکنه اون میکروی داخلی از زبان برنامه‌نویسی خاصی پشتیبانی کنه و حتی IDE خودش را داشته باشه. درمورد ESP8266 هم همین مسئله وجود داره. یعنی داخل تراشه ش یک میکروکنترلر گنجانده شده که شرکت سازنده­ش اجازه دسترسی به اون را داده. برای برنامه‌نویسی برای این میکروکنترلر چند تا IDE و زبان برنامه‌نویسی وجود داره. برای مثال Arduino IDE یکی از اونهاست که با زبان برنامه‌نویسی خود آردوینو میتونید برای میکروکنترلر داخل ماژول، برنامه بنویسید.

یادتون هست که گفتم نگران دردسرای اون پایه­ های دیگه نباشید! منظورم همین بود؛ یعنی شما به­راحتی با آردوینو میتونید به او پایه ­ها دسترسی داشته باشید و براشون برنامه‌نویسی کنید.

یکی دیگه از زبان ­های برنامه‌نویسی برای ماژول ESP8266، زبان برنامه‌نویسی میکرو پایتون هستش. برای این زبان هم چندین کامپایلر وجود داره مثل uPyCraft ،Thonny ،Py Charm و… .

برنامه‌نویسی برای میکروکنترلر داخل تراشه با Arduino IDE خیلی راحت‌تر از دیگر IDE هاست. اگر بخواهید با زبان میکرو پایتون این کار را انجام دهید، کمی کار متفاوت خواهد بود؛ چون میکروی داخلی، زبان پایتون را به‌تنهایی نمی­شناسه و نیاز به یک مفسر داره پس ابتدا باید یک برنامه کوچک برای شناساندن زبان میکرو پایتون به میکروی داخل تراشه را، روی آن فلش کرد و سپس از این زبان برای برنامه‌نویسی میکروی داخل تراشه ESP8266 استفاده کنیم.

خب… الآن در نقطه ­ای قرار داریم که بر اساس اطلاعاتی که تا حالا یاد گرفتیم و اینکه پروژه ما چقدر پیچیده است، باید ادامه راه رو انتخاب کنیم.

ممکنه عده ­ای از دوستان با AT COMMANDها و از پروتکل HTTP استفاده کنند و عده­ای دیگه از FTP و شاید عده­ای هم با میکرو پایتون راحت‌تر باشند و عده­ای هم ترجیح بدن از MQTT استفاده بکنند. از همه راحت‌تر هم آردوینو هستش. این دیگه بستگی به شرایط افراد داره. پس از اینجا به بعد مسیرها جدا میشه. البته برای خداحافظی کمی زوده. تا پایان این قسمت همراه باشید. بعد درمورد مسیرها با هم صحبت خواهیم کرد.

من ترجیح میدم برای شروع کمی با AT COMMANDها آشنا بشم و بعد چون میخوام تحت وب داده ­ها را ارسال و دریافت کنم از پروتکل HTTP یا HTTPS استفاده کنم. پس باید با دستورات پروتکل HTTP و HTTPS هم آشنا بشم.

درمورد AT COMMANDها میتونید خیلی راحت توی اینترنت درموردشون مطلب پیدا کنید. حتی خود شرکت سازنده این تراشه مطالب کاملی را توی سایت ش گذاشته. بهترین مرجع برای توضیح دستورات، خود سایت سازنده تراشه است. یک سری از این دستورات، دستورات Basic یا پایه هستند و دسته دیگه این دستورات مربوط به WIFI و دسته­ ای دیگر مربوط به پروتکل TCP/IP و HTTP و… هستند.

در ادامه مطالب سعی می­کنم درباره پروتکل HTTP(S) بیشتر توضیح بدم و با استفاده از دستورات پایه و دستورات پروتکل TCP/IP یک ارتباط اینترنتی با ماژول برقرار کنم.

ساختار ارتباطی در پروتکل HTTP

در مورد پروتکل HTTP در قسمت­ های گذشته مطالب زیادی را یاد گرفته‌ایم؛ اما در این قسمت با توضیحات کامل‌تری آن را بیان خواهیم کرد. از طریق پروتکل HTTP(S) داده­ ها در اینترنت جابه‌جا می­شوند. دو مفهوم (کلمه) که در مباحث بعدی از آن زیاد نام‌برده خواهد شد، شامل: کلمه اول Client که همان کاربر یا مشتری (دستگاه سرویس‌گیرنده) و کلمه دوم Server که همان سرویس‌دهنده است.

برای مثال مرورگر وب شما یک Client یا همان سرویس‌گیرنده است. اکنون بین این دو قسمت فرایند درخواست (Request) و پاسخ (Response) انجام می­گیرد. چطوری؟

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

وب سرور علاوه بر اینکه می‌تواند فایل‌های صفحه وب را ارائه کند، حاوی HTTP Daemon است. (Daemon فرایندی است که مدت زیادی در پس‌زمینه در حال اجرا است تا به‌محض رسیدن درخواست­های سرویس­ها، پاسخ دهد و در ارتباط مستقیم با کاربر نیست) این HTTP Daemon برنامه‌ای است که منتظر درخواست‌های HTTP می‌ماند تا هنگام رسیدن درخواست­ ها، آنها را مدیریت کند.

زمانی که کاربر یک صفحه وب (با آدرس مشخص) باز می­کند یا بر روی لینکی کلیک می­کند، در اصل درخواست‌های فایل را وارد می‌کند، مرورگر یک درخواست HTTP  ایجاد می‌کند و آن را به آدرس پروتکل اینترنت (آدرس IP) نشان‌داده‌شده توسط URL ارسال می‌کند. اکنون HTTP Daemon در سرور مقصد، درخواست را دریافت کرده و فایل یا فایل‌های درخواستی که مرتبط با درخواست هستند را پس می‌فرستد.

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

به نظر میاد دوباره وارد مباحث تئوری شدیم! جواب خیر است؛ زیرا تمام فرایند گفته شده در بالا و در ادامه را باید توسط ماژول ESP8266 اجرا کنید. پس با دقت مطالب را پیگیری کنید.

درخواست­ ها و پاسخ­ ها در HTTP

هر تعاملی که بین Server و Client برقرار شود، پیام نامیده می‌شود. پیام‌های HTTP همان درخواست‌ها و پاسخ‌ها هستند. این Client ‌ ها هستند که درخواست‌های HTTP را به سرورها ارسال می‌کنند و سرورها با ارسال پاسخ‌های HTTP به Client پاسخ می‌دهند. پروتکل HTTP روش‌‌های مختلفی را برای درخواست اطلاعات در شبکه وب تعریف کرده‌ است.

هر کدام از این روش‌ها با هدف خاصی در وب سرورها استفاده می‌شوند. اولین نسخه این پروتکل (نسخه ۱) فقط از روش‌های (متدهای) درخواست GET ,POST و HEAD پشتیبانی می‌کرد. اما در نسخه ۱٫۱ پنج روش جدید تحت عنوان‌های OPTIONS, PUT, DELETE, TRACE و CONNECT به آن اضافه شد.

متد درخواست GET

پیام‌هایی که در این روش ارسال می‌شوند تنها شامل یک URL هستند. البته در این پیام‌ها می‌توان تعدادی پارامتر دلخواه در انتهای URL اضافه کرد. پارامترهای دلخواه در این پیام‌ها، در URL ارسال شده، به‌راحتی قابل‌مشاهده هستند. این نوع پیام‌ها پس از ارسال توسط سرور پردازش می‌شوند و در نهایت نتیجه آن به درخواست‌کننده یا همان مرورگر بر می‌گردد. متد GET تنها می‌تواند تا ۱۰۲۴ کاراکتر را بفرستد.

همچنین نمی‌تواند اطلاعات باینری مثل تصاویر و فایل word را به سرور ارسال کند. اطلاعات ارسال شده با متد GET با استفاده از متغیر محیطی QUERY-STRING قابل‌دسترسی است.

متد درخواست POST

متد POST اطلاعات را از طریق هدر HTTP انتقال می­دهد. اطلاعات ابتدا همان‌گونه که در مورد متد GET توضیح داده شد، کدگذاری شده و سپس در داخل هدری که QUERY-STRING نام دارد قرار داده می­شود. متد POST هیچ‌گونه محدودیتی در خصوص اندازه اطلاعاتی که قرار است ارسال شود ندارد. متد POST قادر است هم اطلاعات باینری و هم اسکی را ارسال کند.

در این نوع پیام‌ها، پارامترهای دلخواهی که اضافه می‌شود، قابل‌مشاهده نمی‌باشند. زیرا در این روش به‌جای اضافه‌کردن پارامترها در انتهای URL، آن‌ها در درون پیام درخواست شده قرار داده می‌شوند.

تفاوت­ های متد GET و POST

متد درخواست HEAD

این درخواست‌ها مشابه پیام‌های GET هستند. تفاوت این دو درخواست در این است که در پیام‌های Head به‌جای ارسال پاسخ‌های مربوط به محتوای URL، فقط داده‌های مربوط به header سایت (فقط head درخواست return می‌شود که این head شامل یک سری اطلاعات از پارامترهای ارسالی و … است) را ارسال می‌کنند. این داده‌ها همان اطلاعاتی هستند که در قسمت <head> یک سند html وجود دارند.

متد درخواست PUT

در این روش داده‌هایی به همراه پیام درخواست به سرور ارسال می‌شود. سپس از سرور تقاضا می‌شود که این داده‌ها را در آدرس مشخص شده ذخیره کند. اگر در محلِ درخواست شده از قبل داده‌های دیگری ذخیره شده باشند، داده‌های جدید جایگزین خواهند شد.

متد درخواست TRACE

این متد معمولاً برای دیباگ‌کردن و در پروسه Development استفاده می­شود. به این شکل که وقتی درخواستی از نوع TRACE برای سرور از سمت کلاینت ارسال می­شود سرور برای کلاینت درخواستی که کلاینت فرستاده بود را مجدد می­فرستد تا کلاینت بتواند Content درخواستی که ارسال کرده بوده را مشاهده کند. در این روش، سرور داده‌های ارسال شده را دقیقاً به کلاینت یا درخواست‌کننده باز می­­گرداند.

متد درخواست OPTIONS

زمانی از این روش استفاده می‌شود که بخواهند، روش‌های درخواست اطلاعات موجود برای یک آدرس را به دست آورند. این روش از سرور تقاضا می­­کند تا روش‌‌های درخواست موجود برای آدرس فرستاده شده را اعلام کند. به عبارتی این متد عمدتاً زمانی استفاده می‌شود که می‌خواهیم بدانیم چه متدهایی در وب سرور مدنظر ما پشتیبانی می‌شود که می‌توانیم URL خاصی را به آنها بدهیم یا اینکه از کاراکتر  Asterisk (*) جلوی OPTIONS  استفاده کنیم تا ببینیم در کل سرور چه متدهایی را ساپورت می­کند.

متد درخواست DELET

 از این روش برای حذف یک آدرس در سرور استفاده می‌شود.

متد درخواست CONNECT

این روش اطلاعات و داده‌ها را در پروتکل HTTP به یک تونل TCP/IP تبدیل می­کند. این عمل معمولاً برای برقراری ارتباط امن (HTTPS) بر روی یک پراکسی سرور ناامن استفاده می‌شود.

درخواست PATCH

 این روش در سال ۲۰۱۰ به پروتکل HTTP اضافه شد. این روش برای ایجاد تغییرات جزئی بر روی داده‌ها موردنظر در سرور استفاده می­شود. این متد هم مکانیزمی مشابه به متد put دارد؛ ولی مزیتش نسبت به put این است که فیلدهایی که مقادیر جایگزین در درخواست ارسالی برای آنها در نظر گرفته نمی­شود از بین نمی­روند. در اصل فقط مقادیری که باید تغییر کنند تغییر می­کنند. مثلاً اگر نیاز باشد پسورد یک کاربر عوض شود اگر از متد put استفاده می­کردیم همه اطلاعات کاربری اون شخص اعم از ایمیل و نام کاربری از بین می‌رفتند؛ ولی در متد Patch فقط پسورد عوض می‌شود و باقی فیلد­ها مقادیرشان دست‌نخورده باقی می­ماند.

ساختار پیام­ های Request و Response در HTTP

پیام ­های HTTP چه Request و چه Response از نظر ساختاری مشابه هم هستند؛ ولی محتوای آنها متفاوت است. شکل کلی آنها مانند شکل زیر است.

اطلاعات داخل سه قسمت فوق هستند؛ ولی بستگی به Request و Response دارد. تمام قسمت ­ها، پاسخی به‌صورت ASCII دارند؛ ولی گاهی قسمت body دارای پاسخی باینری است.

ساختار پیام HTTP Request

• در قسمت آدرس یا URL، آدرس، منبعی (Resource) است که می­خواهیم جهت ‌نمایش در مرورگر آورده شود.
• در نهایت در بخش شروع، نسخه HTTP که سرویس‌گیرنده به سرویس دهند ارسال می­کند قرار دارد که برای خود پروتکل قابل‌فهم است؛ مانند نسخه یک HTTP.
• قسمت Header اطلاعات و قوانینی است که به سرویس دهند ارسال می­گردد و مورد قبول سرویس‌گیرنده است. از جمله اسم سایت سرویس‌گیرنده، نوع داده و زبان مورد قبول.

ساختار پیام HTTP Response

ساختار کلی پیام HTTP Response مانند شکل زیر است. آدرس در بخش شروع دیگه وجود نداره و در قسمت شروع یک کد وضعیت مهم به همراه ورژن HTTP ارسال میشه که نتیجه درخواست در آن به سرویس‌گیرنده ارسال شده که در ادامه کدهای وضعیت را توضیح خواهیم داد.

این کدهای وضعیت چی هستند؟!

کدهای وضعیت

کدهای وضعیت پیام HTTP وضعیت درخواست را به سرویس‌گیرنده اعلام می‌کنند که شامل موارد زیر است. کدهای مهم و پر کاربرد کدهای ‍‍۱ جهت اطلاع، کدهای ۲ موفقیت، کدهای ۴ خطای سمت سرویس‌گیرنده و کدهای ۵ خطای سمت سرویس‌دهنده را اعلام می­کند.

• کدهای 1XX: این کدها خبری (informational) بوده و برای اطلاع‌رسانی استفاده می‌شوند.
• کدهای 2XX: کدهای این بخش از نوع موفق (successful) بوده و خبر از پایان رسیدن موفقیت‌آمیز درخواست‌ها می‌دهند.
• کدهای 3XX: این کدها برای مشخص‌کردن ریدایرکت‌ها (redirection) استفاده می‌شوند و مشخص می‌کنند که درخواست به آدرس دیگری منتقل شده است.
• کدهای 4XX: کدهایی که با عدد 4 شروع میشوند به معنی خطای کلاینت (client error) بوده و مشخص میکنند که در سمت کاربر مشکلی وجود دارد.
• کدهای 5XX: این کدها به معنای خطای سرور (server error) بوده و مشخص می‌کنند که سرور به مشکل خورده است.

کوئری استرینگ (Query string) در URL وب‌سایت چیست؟

یکی از روش­ های انتقال اطلاعات بین صفحات وب، query string است. گاهی اوقات لازم است که وب‌سایت از وضعیت (State) ما مطلع شود و در همان لحظه، مسیری را طی کند. برای مثال، زمانی که در یک وب‌سایت ثبت‌نام می­کنید و یک فرم چند صفحه ­ای را پر می­کنید، سرور باید مطلع باشد که در صفحه پیش چه کاری انجام داده­ایم. یا مثلاً در خرید اینترنتی که شامل لیست سبد خرید است، آدرس گیرنده، مشخصات خریدار و… است.

پروتکل HTTP امکان نگهداری وضعیت را ندارد. پس باید با مکانیزم دیگری این کار را انجام داد. از جمله می­توان به مکانیزم نگهداری وضعیت سرور “Session” و نگهداری وضعیت کاربر “Cookie” اشاره کرد. مکانیزم دیگری برای نگهداری وضعیت و انتقال اطلاعات بین صفحات وجود دارد. در این مکانیزم، وضعیت قبلی همراه با درخواست­ ها، از طریق URL به سرور ارسال می­شوند. به این روش Query string گفته می­شود. در زیر یک مثال از این مطلب آورده شده است.

https://www.google.com/search?q=query+string

کوئری استرینگ (Query String) هر مقداری است که بعد از علامت سؤال در انتهای URL قرار می­گیرد که می­تواند یک یا تعداد بیشتری پارامتر داشته باشد.

تا اینجا با پروتکل ارتباطی HTTP و جزئیات اون آشنا شدیم. برای درک بهتر نحوه عملکرد این پروتکل می­تونید از نرم‌افزارهای مانیتورینگ HTTP استفاده کنید تا فرایند ارسال و دریافت داده را بهتر درک کنید.

در قسمت بعدی (قسمت یازدهم) و آخرین قسمت از این مجموعه سعی می­کنیم با دانشی که از این قسمت و قسمت ­های قبل داریم، ماژول وای‌فای را راه‌اندازی کنیم، به اینترنت وصل شویم و دیتا را از طریق اینترنت ارسال کنیم.