در سمت سرور ریکوئست‌هایی که به پورت 80 و یا 443 ارسال می‌شوند توسط وب‌سرور دریافت و تحلیل می‌شوند که این وب‌سرورها عموماً برنامه‌هایی نظیر Apache و Nginx می‌باشند که به محض نصب بر روی یک سیستم، پورت‌های HTTP را اِشغال کرده و اصطلاحاً روی این پورت‌ها Listen می‌کنند که برای کسب اطلاعات بیشتر، می‌توانید به آموزش آشنایی با وب سرور و نحوهٔ عملکرد آن مراجعه نمایید.
پس از رسیدن یک ریکوئست به سرور، وب‌سرور ابتدا متد مرتبط با آن ریکوئست را بررسی کرده سپس منبع مرتبط با آن ریکوئست را برای مرورگر پیدا کرده و برایش روی همان پورتی که ریکوئست داده بود، ریسپانس را ارسال می‌کند.
| نکته |
توجه داشته باشید که در این بحث، منظور از سرور دیوایسی سخت‌افزاری است و منظور از وب‌سرور نیز نرم‌افزاری همچون آپاچی است. |
به ریسپانسی که از سمت سرور ارسال می‌گردد اصطلاحاً HTTP Response گفته می‌شود که به غیر از خط اول ریسپانس، باقی موارد آن کاملاً شبیه HTTP Request می‌باشد که در اینجا قسمت Body بسیار مهم بوده و در واقع منبعی هست که کاربر آن را درخواست کرده و در مرورگرش نمایش داده خواهد شد. به طور کلی، ساختار HTTP Response به صورت زیر می‌باشد:
HTTP-version Status-code Reason-phrase
Response-header-name: Response-header-value1, Response-header-value2, ...
Response-message-bodyخط اول همانند ریکوئست، شامل سه بخش می‌باشد که در بخش اول ورژن پروتکل اچ‌تی‌تی‌پی که می‌خواهیم استفاده کنیم را قرار می‌دهیم، در بخش دوم کدی که سرور به ما برمی‌گرداند و در بخش سوم توضیح مختصر این کد قرار دارد که به این کد Status Code و به خط اول Status Line نیز گفته می‌شود.
کدی که سرور در بخش Status Code قرار می‌دهد برای مرورگر قابل‌فهم است و بیان می‌کند که ریکوئست‌اش در سمت سرور با چه وضعیتی روبه‌رو شده است. مثلاً ممکن است منبعی که آن را ریکوئست کرده در سرور موجود نباشد یا دسترسی به آن محدود شده باشد و یا حتی اروری داخل سرور رخ داده باشد که در حال حاضر قادر به ارائۀ سرویس برای ریکوئست شما نباشد و در آخر ممکن است منبع شما را با موفقیت در این ریسپانس فرستاده باشد. در هر صورت، مرورگر در سمت کلاینت باید کاملاً از Status Code مطلع باشد که برای کسب اطلاعات بیشتر، می‌توانید به آموزش آشنایی با پیام‌های HTTP مراجعه نمایید (در صورت موفقیت، سرور کد وضعیت 200 را برمی‌گرداند و از کدهای معروف دیگر می‌توان به 404 و 500 اشاره کرد که احتمالاً با کد 404 بارها و بارها در وب‌گردی مواجه شده باشید.)
در بخش Body، سرور فایل ریکوئستی شما را قرار می‌دهد و در صورتی که شما ریکوئست دیدن یک صفحۀ وب را کرده باشید، سرور کدهای HTML را در اینجا قرار می‌دهد. به عنوان مثال داریم:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>پس از ارسال این ریکوئست، وب‌سرور سوکت مورد نظر را می‌بندد و از همین روی HTTP را یک پروتکل Stateless (بدون حالت) می‌نامند. به عبارت دیگر، اصولاً هیچ‌گونه حافظه‌ای از کاربری که به صورت مداوم به آن ریکوئست می‌دهد ندارد و هر ریکوئست ارسالی از طرف کاربر را به نوعی پردازش می‌کند که گویی کاربر جدیدی است (این مسئله در موارد متعددی می‌تواند برای ما مشکل‌ساز باشد که برای حل آن از مفهوم Session استفاده می‌کنند که خارج از این بحث است.)
در اینجا پیامی که سرور ارسال می‌کند بعد از طی مسیرهای مختلفی که وظیفۀ روتینگ و ... را به عهده دارند به مهم‌ترین بخش خود یعنی Nat Server می‌رسد. Nat Server ریکوئست را گرفته به Nat Table مراجعه می‌کند و آی‌پی و پورتی که سرور برای آن فرستاده است را به آی‌پی و پورت لوکال تبدیل می‌کند و به سمت کلاینت (مرورگر کاربر) می‌فرستد و در نهایت، سیستم‌عامل پس از گرفتن ریسپانس، آن را به برنامه‌ای که پورت را اِشغال کرده بود هدایت می‌کند که در اینجا چنین برنامه‌ای مرورگر است و مرورگر هم بعد از گرفتن آن قسمت، Body را به شکلی ساختاریافته در معرض دید کاربر قرار می‌دهد (مثلاً اگر در Body کدهای HTML وجود داشته باشد، مرورگر وظیفه دارد تا این کدها را تفسیر کند و به صورت اَشکال و متون قابل‌درک توسط کاربر تبدیل کرده و با اِعمال کدهای CSS آن‌ها را شکیل جلوه دهد.)
پس از بررسی سازوکار پروتکل HTTP تا اینجای دوره، در ادامه مسئلۀ تبادل اطلاعاتی که به صورت ناخواسته بین کلاینت و سرور صورت می‌گیرند را زیر ذر‌ه‌بین می‌بریم و خواهیم دید که Privacy به چه شکلی می‌تواند نقض می‌شود!
