| <html lang="fa" dir="rtl"> | |
| <head> | |
| <meta charset="UTF-8"> | |
| <title>جزوه نهایی و کالبدشکافی شده مهندسی اینترنت</title> | |
| <style> | |
| @page { size: A4; margin: 25mm 20mm; } | |
| body { font-family: 'B Nazanin', Tahoma, sans-serif; font-size: 20px; line-height: 2.2; color: #111; background-color: #fafafa; text-align: justify; padding: 20px; } | |
| h1 { font-size: 40px; color: #2c3e50; text-align: center; border-bottom: 4px solid #3498db; padding-bottom: 20px; margin-bottom: 40px; } | |
| h2 { font-size: 32px; color: #e74c3c; margin-top: 50px; border-right: 5px solid #2980b9; padding-right: 15px; } | |
| h3 { font-size: 26px; color: #8e44ad; margin-top: 30px; } | |
| p { margin-bottom: 20px; } | |
| ul, ol { margin-bottom: 25px; padding-right: 40px; } | |
| li { margin-bottom: 10px; } | |
| .code { font-family: 'Courier New', monospace; direction: ltr; text-align: left; background: #2d2d2d; color: #f8f8f2; padding: 15px; border-radius: 5px; font-size: 16px; overflow-x: auto; margin-bottom: 20px; } | |
| .important { background-color: #f1c40f; padding: 2px 6px; border-radius: 3px; font-weight: bold; } | |
| .q-box { background-color: #ecf0f1; border: 2px dashed #7f8c8d; padding: 20px; border-radius: 8px; margin-top: 30px; } | |
| .q-title { font-weight: bold; color: #d35400; font-size: 22px; } | |
| .q-ans { font-weight: bold; color: #27ae60; margin-top: 15px; } | |
| </style> | |
| </head> | |
| <body> | |
| <h1>جزوه جامع و قطعی مهندسی اینترنت (ویژه امتحان)</h1> | |
| <p>این نسخه شامل تمام جزئیات، کدهای تدریس شده و مفاهیم دقیق تمامی ۱۶ اسلاید است. هیچ نکتهای جا نمانده است.</p> | |
| <!-- فصل ۱ و ۲ و ۳ و ۴ --> | |
| <h2>۱. مقدمهای بر مهندسی اینترنت و برنامههای وب</h2> | |
| <p>تاریخچه معماری کامپیوترها از مدل <strong>Mainframe</strong> (ابررایانه مرکزی با پایانههای گنگ که قدرت پردازش نداشتند) شروع شد. سپس مدل <strong>Client-Server</strong> (کلاینتهای هوشمند مانند PCها که بار پردازشی را تقسیم میکردند) معرفی شد. مشکل بزرگ Client-Server، <span class="important">هزینه نگهداری و استقرار (Deployment Cost)</span> بسیار بالا بود؛ زیرا بروزرسانی نرمافزار باید روی تکتک کلاینتها به صورت دستی انجام میشد.</p> | |
| <p>برای حل این مشکل، <strong>Web Applications</strong> (برنامههای تحت وب) معرفی شدند. در این الگو از <strong>Thin Client (کلاینت لاغر)</strong> استفاده میشود. یعنی کلاینت فقط یک مرورگر وب (Browser) است و تمام منطق برنامه روی سرور اجرا میشود. مزیت بزرگ این روش این است که هزینه استقرار و نگهداری سمت کاربر صفر است.</p> | |
| <h2>۲. برنامهنویسی سازمانی جاوا (Collections, Maven, Git, JUnit)</h2> | |
| <p><strong>Java Collections:</strong> استفاده از <code>ArrayList</code> (سریع برای خواندن تصادفی)، <code>LinkedList</code> (سریع برای درج/حذف)، و <code>HashMap</code> (ذخیره کلید-مقدار). در وبسرورها به دلیل همزمانی (Concurrency) و حضور صدها کاربر به صورت همزمان، استفاده از <code>HashMap</code> خطرناک است و باعث Race Condition میشود. به جای آن از <strong><code>ConcurrentHashMap</code></strong> استفاده میکنیم که به جای قفل کردن کل شیء، فقط بخشهای خاصی را قفل میکند (Segment Locking) و کارایی بالایی دارد.</p> | |
| <p><strong>Maven:</strong> ابزاری برای مدیریت وابستگیها و بیلد خودکار در جاوا. اطلاعات پروژه در فایل <code>pom.xml</code> ذخیره میشود. فازهای اصلی میون عبارتند از: validate (اعتبارسنجی)، compile (کامپایل کدها)، test (اجرای تستهای واحد)، package (بستهبندی در قالب JAR/WAR)، و install (نصب در مخزن محلی).</p> | |
| <p><strong>JUnit:</strong> فریمورکی برای Unit Testing. با انوتیشن <code>@Test</code> متدهای تست مشخص میشوند. <code>@BeforeEach</code> و <code>@AfterEach</code> برای تنظیم شرایط قبل و بعد از هر تست استفاده میشوند. برای بررسی درستی خروجی از <code>assertEquals</code> استفاده میشود.</p> | |
| <h2>۳. سرورهای کاربردی و Socket Programming</h2> | |
| <p>ارتباطات سطح پایین در شبکه توسط <strong>Sockets</strong> انجام میشود. در سرور از <code>ServerSocket</code> استفاده شده و متد <code>accept()</code> منتظر اتصال کلاینت میماند. جاوا برای مدیریت جریانهای داده (I/O) از الگوی طراحی <strong>Decorator (تزئینگر)</strong> استفاده میکند. کلاسهای پایه مثل <code>FileInputStream</code> فقط بایتها را میخوانند، اما میتوان آنها را درون <code>BufferedInputStream</code> قرار داد تا قابلیت کش (Cache) و بافرینگ به آنها اضافه شود، بدون اینکه تغییری در کلاس اصلی داده شود.</p> | |
| <p><strong>مفهوم Reflection:</strong> قابلیتی در جاوا که اجازه میدهد برنامه در زمان اجرا (Run-time) متدها، فیلدها و ساختار کلاسهای خود را بررسی و فراخوانی کند. فریمورکهای مدرن (مثل Spring) برای اجرای کدهای توسعهدهنده به شدت به Reflection وابستهاند، اما این کار مقداری افت سرعت (Performance Overhead) به همراه دارد.</p> | |
| <h2>۴. طراحی پایه صفحات وب (HTML5, CSS3, RWD)</h2> | |
| <p>در HTML5 از <strong>تگهای معنایی (Semantic)</strong> مانند <code><header></code>, <code><footer></code>, <code><nav></code>, و <code><article></code> استفاده میشود. این تگها به جای تگ عمومی <code><div></code> به کار میروند و باعث بهبود شدید <strong>سئو (SEO)</strong> و دسترسیپذیری برای نابینایان (Screen Readers) میشوند.</p> | |
| <p><strong>طراحی واکنشگرا (RWD):</strong> با استفاده از CSS Media Queries (مانند <code>@media (max-width: 768px)</code>) انجام میشود. بهترین رویکرد <strong>Mobile-First Design</strong> است؛ یعنی ابتدا استایلهای سبک برای موبایل نوشته میشود و سپس با بزرگتر شدن صفحه، استایلهای پیچیدهتر اضافه میشوند که باعث میشود مرورگرهای موبایلی نیازی به لود کردن کدهای اضافی دسکتاپ نداشته باشند.</p> | |
| <!-- فصل ۵ کالبدشکافی کامل --> | |
| <h2>۵. معماری MVC، سرولتها (Servlets) و JSP (کالبدشکافی کامل)</h2> | |
| <h3>۵.۱. سرولت چیست؟</h3> | |
| <p>سرولتها (Servlets) کامپوننتهای سمت سرور جاوا هستند که در یک <strong>Web Container (مانند Tomcat)</strong> اجرا میشوند. دو نوع سرولت داریم:</p> | |
| <ul> | |
| <li><strong>Generic Servlets:</strong> از <code>javax.servlet.Servlet</code> ارثبری میکنند و مستقل از پروتکل هستند.</li> | |
| <li><strong>HTTP Servlets:</strong> از <code>javax.servlet.http.HttpServlet</code> ارثبری میکنند و مخصوص مدیریت پروتکل HTTP هستند (شامل متدهای <code>doGet</code> و <code>doPost</code>).</li> | |
| </ul> | |
| <h3>کد نمونه یک Servlet ساده:</h3> | |
| <div class="code"> | |
| import java.io.*; | |
| import javax.servlet.*; | |
| import javax.servlet.http.*; | |
| @WebServlet("/hello") | |
| public class HelloWorld extends HttpServlet { | |
| public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { | |
| response.setContentType("text/html"); | |
| PrintWriter out = response.getWriter(); | |
| out.println("<HTML><BODY><H1>Hello World!</H1></BODY></HTML>"); | |
| } | |
| } | |
| </div> | |
| <h3>۵.۲. وظایف Web Container (تامکت)</h3> | |
| <p>کانتینر تامکت مسئول دریافت درخواست HTTP، پارس کردن آن، پیدا کردن سرولت مربوطه، لود کردن کلاس سرولت (ساختن تنها یک نمونه Singleton از آن)، و در نهایت صدا زدن متد متناظر (doGet/doPost) با استفاده از <strong>Reflection</strong> است.</p> | |
| <h3>۵.۳. تکنولوژی JSP (JavaServer Pages)</h3> | |
| <p>نوشتن تگهای HTML با دستور <code>out.println</code> در سرولتها بسیار سخت بود. JSP اختراع شد تا کدهای جاوا مستقیما درون صفحات HTML تزریق شوند. فایلهای JSP در دو فاز اجرا میشوند:</p> | |
| <ol> | |
| <li><strong>Translation Phase (فاز ترجمه):</strong> فایل JSP به یک فایل کد جاوا (Servlet) ترجمه و سپس کامپایل میشود. بنابراین JSP ذاتا یک Servlet است!</li> | |
| <li><strong>Execution Phase (فاز اجرا):</strong> کلاس کامپایل شده اجرا شده و پاسخ HTML تولید میشود.</li> | |
| </ol> | |
| <h3>۵.۴. عناصر تشکیلدهنده JSP</h3> | |
| <ul> | |
| <li><strong>Scripting Elements (عناصر اسکریپتنویسی):</strong> شامل سه مورد: | |
| <ul> | |
| <li><code><%! %></code> (Declarations): برای تعریف متدها و متغیرهای سراسری (کلاس-لِوِل) استفاده میشود.</li> | |
| <li><code><% %></code> (Scriptlets): برای نوشتن بلوکهای کد جاوا درون بدنه اصلی (متد service).</li> | |
| <li><code><%= %></code> (Expressions): برای چاپ متغیرها به طور مستقیم روی مرورگر (مثلا <code><%= Math.sqrt(100) %></code>).</li> | |
| </ul> | |
| </li> | |
| <li><strong>Implicit Objects (اشیاء ضمنی):</strong> اشیائی که به صورت خودکار در JSP قابل دسترساند، مانند: <code>request</code>, <code>response</code>, <code>session</code>, <code>out</code>, و <code>config</code>.</li> | |
| <li><strong>Directives (دایرکتیوها):</strong> پیامهایی برای کانتینر. مثلا <code><%@ page import="java.util.Date" %></code> برای ایمپورت کردن کلاسها یا تعیین صفحه خطا.</li> | |
| </ul> | |
| <h3>۵.۵. معماری MVC (Model-View-Controller)</h3> | |
| <p>برای حل مشکل کدنویسی اسپاگتی (ترکیب UI و منطق دیتابیس در یک فایل)، الگوی MVC ایجاد شد:</p> | |
| <ul> | |
| <li><strong>Model:</strong> منطق تجاری و دادهها (ارتباط با دیتابیس).</li> | |
| <li><strong>View:</strong> رابط کاربری (صرفا صفحات JSP که دادهها را نمایش میدهند و منطقی ندارند).</li> | |
| <li><strong>Controller:</strong> هماهنگکننده مرکزی (یک Servlet مرکزی). Controller درخواست کاربر را میگیرد، اعتبارسنجی میکند، متدهای Model را فراخوانی میکند، دادههای خروجی را گرفته و کاربر را به View مناسب هدایت (Forward یا Redirect) میکند.</li> | |
| </ul> | |
| <!-- فصل ۶ و ۷ --> | |
| <h2>۶. برنامههای تکصفحهای (SPA) و تکنولوژیهای ناهمگام (AJAX)</h2> | |
| <p>در وب سنتی (نسل اول)، با هر کلیک کاربر، کل صفحه رفرش میشد (Server-Side Rendering). این کار باعث مصرف پهنای باند و چشمک زدن صفحه میشد. در نسل جدید، <strong>SPA (Single Page Application)</strong> معرفی شد. در این مدل، فقط یک بار فایل HTML خالی لود میشود. از آن پس، جاوااسکریپت در پسزمینه با سرور ارتباط برقرار میکند و دادهها را (معمولاً با فرمت بسیار سبک <strong>JSON</strong>) دریافت کرده و فقط بخشهای کوچکی از درخت DOM را بروزرسانی میکند (Client-Side Rendering).</p> | |
| <p><strong>AJAX:</strong> سرنام Asynchronous JavaScript and XML است. از شیء <code>XMLHttpRequest</code> برای این ارتباطات ناهمگام (بدون رفرش شدن صفحه و بدون متوقف کردن کار کاربر) استفاده میشود. استفاده از TypeScript در پروژههای بزرگ SPA بسیار رایج است؛ زیرا TS به JS معمولی قابلیتهای بررسی نوع (Type Checking) را در زمان کامپایل اضافه میکند تا خطاهای برنامه در زمان اجرا کاهش یابند.</p> | |
| <h2>۷. اصول و قواعد طراحی وبسرویسهای RESTful</h2> | |
| <p>معماری <strong>REST (Representational State Transfer)</strong> امروزه استاندارد ساخت APIهاست.</p> | |
| <h3>۷.۱. محدودیتهای کلیدی معماری REST</h3> | |
| <ul> | |
| <li><strong>بدون وضعیت (Statelessness):</strong> مهمترین اصل! سرور نباید هیچ وضعیتی از کلاینت در رم خود (مثل Session) نگه دارد. هر درخواست کلاینت باید کاملاً مستقل بوده و حاوی تمام اطلاعات (مثل توکن امنیتی) باشد. این ویژگی امکان Scale-out (افزودن بینهایت سرور جدید) را فراهم میکند.</li> | |
| <li><strong>رابط یکپارچه (Uniform Interface):</strong> استفاده از اسامی جمع برای Resourceها (مثل <code>/users/123</code>) و خودداری از استفاده از افعال در URL (مثل <code>/getUser</code> غلط است).</li> | |
| <li><strong>سیستم لایهای (Layered System):</strong> کلاینت نباید بداند که آیا به سرور نهایی وصل است یا به یک واسط (مثل Load Balancer).</li> | |
| </ul> | |
| <h3>۷.۲. متدهای استاندارد HTTP</h3> | |
| <ul> | |
| <li><code>GET</code>: فقط برای خواندن دادهها (امن و تکرارپذیر یا Idempotent).</li> | |
| <li><code>POST</code>: برای ایجاد یک رکورد جدید.</li> | |
| <li><code>PUT</code>: برای بروزرسانی و جایگزینی کامل یک موجودیت موجود.</li> | |
| <li><code>DELETE</code>: برای حذف موجودیت.</li> | |
| </ul> | |
| <h3>۷.۳. مفهوم HATEOAS</h3> | |
| <p>این مفهوم (Hypermedia As The Engine Of Application State) بلوغ نهایی یک API را نشان میدهد. در این حالت، API فقط دادههای خام را برنمیگرداند، بلکه <strong>لینکهای ناوبری</strong> مرتبط با آن داده را هم برمیگرداند (مثلاً در کنار اطلاعات کاربر، لینکِ لیستِ سفارشات او را هم میدهد). بدین ترتیب کلاینت نیازی به Hard-code کردن مسیرها ندارد.</p> | |
| <!-- فصل ۸ و ۹ --> | |
| <h2>۸. کالبدشکافی زبان جاوااسکریپت</h2> | |
| <p>جاوااسکریپت زبان داینامیک، مفسری و دارای دو ویژگی عجیب است:</p> | |
| <ul> | |
| <li><strong>Hoisting (بالاکشیدن):</strong> در جاوااسکریپت، اعلان متغیرها (با کلمه `var`) و توابع، قبل از اجرای کد به بالاترین نقطه از Scope انتقال مییابند. یعنی میتوانید یک تابع را قبل از خطِ تعریفِ آن صدا بزنید!</li> | |
| <li><strong>بستارها (Closures):</strong> یکی از مهمترین مفاهیم. وقتی تابعی درون تابع دیگری تعریف میشود، تابع درونی به تمام متغیرهای تابع بیرونی دسترسی دارد، حتی اگر تابع بیرونی execution context خود را به پایان رسانده باشد! از این ویژگی برای ساخت <strong>متغیرهای خصوصی (Private Variables)</strong> در جاوااسکریپت استفاده میشود.</li> | |
| </ul> | |
| <p><strong>DOM در برابر BOM:</strong><br> | |
| DOM (Document Object Model) رابط برنامهنویسی برای دستکاری المانهای HTML صفحه (تغییر استایل، متن، تگها) است. در حالی که BOM (Browser Object Model) برای دسترسی به امکانات مرورگر (مثل <code>window.history</code>, <code>location</code>, <code>setTimeout</code>) استفاده میشود.<br> | |
| <strong>Event Bubbling:</strong> رویدادها از داخلیترین تگ به سمت تگهای والد حباب میسازند. با <code>event.stopPropagation()</code> جلوی این رفتار گرفته میشود.</p> | |
| <h2>۹. فریمورک React (Virtual DOM, Hooks, State)</h2> | |
| <p>ریکت، کتابخانه UI فیسبوک، با معرفی معماری Component-Based دنیای فرانتاند را دگرگون کرد.</p> | |
| <ul> | |
| <li><strong>Virtual DOM (دام مجازی):</strong> دستکاری DOM مرورگر بسیار کُند است. ریکت یک کپی مجازی در حافظه میسازد. با هر تغییر، نسخه جدید مجازی ساخته شده، با نسخه قبلی مقایسه میشود (Diffing) و فقط تفاوتها روی DOM واقعی اعمال میشوند.</li> | |
| <li><strong>Props در برابر State:</strong> <code>Props</code> دادههای ورودی از والد به فرزند هستند (غیرقابل تغییر توسط فرزند). اما <code>State</code> وضعیت داخلی و خصوصی کامپوننت است. با تغییر State، کامپوننت Re-render میشود.</li> | |
| <li><strong>هوکهای React:</strong> | |
| <ul> | |
| <li><code>useState</code>: برای تعریف State محلی.</li> | |
| <li><code>useEffect</code>: برای مدیریت اثرات جانبی (Side effects) مانند تماس با سرور. | |
| <br><span class="important">آرایه وابستگی:</span> اگر پارامتر دوم <code>[]</code> باشد، این هوک فقط یک بار (هنگام لود اولیه صفحه) اجرا میشود. اگر <code>[x]</code> باشد، هر بار که x تغییر کند اجرا میشود. بدون آرایه، هر بار رندر اجرا میشود.</li> | |
| </ul> | |
| </li> | |
| </ul> | |
| <!-- فصل ۱۰ و ۱۱ --> | |
| <h2>۱۰. معماریهای لایهای سازمانی (Enterprise Layered Architecture)</h2> | |
| <p>در پروژههای بزرگ، کدها به لایههای مجزا (Presentation UI، Business Logic Service، Data Access DAO) تقسیم میشوند. این جداسازی دغدغهها باعث قابلیت تستپذیری (Testability) و نگهداری آسان میشود.</p> | |
| <p><strong>الگوی Lasagna Architecture (معماری لازانیا):</strong> یک Anti-pattern است که وقتی تعداد لایهها بیش از حد (مثلاً ۷ یا ۸ لایه) زیاد شود رخ میدهد. این پیچیدگی بیهوده باعث کند شدن روند توسعه و افت شدید پرفورمنس به دلیل پاسکاری مداوم داده بین لایهها میشود.</p> | |
| <p><strong>DTO در برابر DAO:</strong> شیء <code>DAO (Data Access Object)</code> وظیفه کار با دیتابیس (JDBC/JPA) را دارد. اما <code>DTO (Data Transfer Object)</code> یک شیء ساده جاواست که برای انتقال ایمن دادهها بین لایهها (بدون ارسال فیلدهای حساسی مثل رمزعبور به لایه UI) استفاده میشود.</p> | |
| <h2>۱۱. ارتباطات پایگاه داده در جاوا (JDBC)</h2> | |
| <p>JDBC کتابخانه استاندارد جاوا برای ارتباط با RDBMS است.</p> | |
| <ul> | |
| <li><strong>انواع Statement:</strong> | |
| <ul> | |
| <li><code>Statement</code>: کوئری را با مقادیر متنی کاربر میچسباند (Concat). این روش بسیار ناامن است و باعث حمله هکری <strong>SQL Injection</strong> میشود.</li> | |
| <li><code>PreparedStatement</code>: کوئری از پیش توسط دیتابیس کامپایل میشود و دادههای کاربر به عنوان پارامتر جایگزین <code>?</code> میشوند. این کار امنیت را ۱۰۰٪ کرده و جلوی SQL Injection را میگیرد.</li> | |
| <li><code>CallableStatement</code>: برای فراخوانی Stored Procedureهای درون دیتابیس.</li> | |
| </ul> | |
| </li> | |
| <li><strong>Connection Pooling:</strong> فرآیند وصل شدن فیزیکی به دیتابیس بسیار کُند است. استخر اتصالات، تعداد زیادی کانکشن را از پیش ساخته و در حافظه باز نگه میدارد. هر کلاینت یک کانکشن موقت قرض میگیرد و برمیگرداند.</li> | |
| <li><strong>Transactions (تراکنشها):</strong> برای تضمین قواعد ACID (مخصوصا اتمیک بودن). با دستور <code>setAutoCommit(false)</code>، تراکنش شروع میشود و پس از اجرای تمام عملیاتها، متد <code>commit()</code> فراخوانی میشود. در صورت خطا، <code>rollback()</code> همه چیز را به حالت اول برمیگرداند.</li> | |
| </ul> | |
| <!-- فصل ۱۲ و ۱۳ --> | |
| <h2>۱۲. معماری JPA (Java Persistence API) و Hibernate</h2> | |
| <p>در جاوا به دلیل تفاوت ساختار شیءگرا با ساختار جدولی دیتابیس (Impedance Mismatch)، از ابزارهای <strong>ORM (Object-Relational Mapping)</strong> استفاده میشود که Hibernate معروفترین پیادهسازی آن است. در JPA کلاسهای جاوا با انوتیشن <code>@Entity</code> مارک میشوند.</p> | |
| <ul> | |
| <li><strong>استراتژیهای استخراج (Fetching):</strong> | |
| <ul> | |
| <li><code>Eager</code>: وقتی والد خوانده میشود، تمام فرزندان متصل به آن (JOIN سنگین) هم از دیتابیس لود میشوند. (مصرف حافظه بالا).</li> | |
| <li><code>Lazy</code>: فقط والد لود میشود. اطلاعات فرزند تنها زمانی از دیتابیس کشیده میشود که روی والد متد <code>get...()</code> فراخوانی شود. این روش بسیار بهینهتر است.</li> | |
| </ul> | |
| </li> | |
| <li><strong>استراتژیهای ارثبری (Inheritance Strategies):</strong> | |
| <ul> | |
| <li><code>Single Table</code>: تمام ارثبری در یک جدول بزرگ (فوقالعاده سریع، اما پُر از فیلدهای Null).</li> | |
| <li><code>Table per Class</code>: جدولی جداگانه برای هر کلاس (تکرار دادهها).</li> | |
| <li><code>Joined</code>: جداول کاملا نرمال با کلید خارجی (کُندترین روش به دلیل JOIN زیاد، اما بهینهترین مصرف فضا).</li> | |
| </ul> | |
| </li> | |
| </ul> | |
| <h2>۱۳. پایگاههای داده توزیعشده (NoSQL) و تئوری CAP</h2> | |
| <p>وقتی حجم داده از مرز میلیونها گذشت، دیتابیسهای رابطهای دیگر جوابگو نبودند (چون فقط به صورت عمودی با سختافزار گران مقیاسپذیرند). <strong>NoSQL</strong> برای مقیاسپذیری افقی (هزاران سرور ارزان) اختراع شد.</p> | |
| <p><strong>تئوری CAP (Eric Brewer):</strong> در یک سیستم توزیعشده نمیتوان همزمان ۳ ویژگی را با هم داشت:</p> | |
| <ol> | |
| <li><strong>C (Consistency) ثبات:</strong> هر گره کلاستر در یک لحظه دقیقا یک داده را برگرداند.</li> | |
| <li><strong>A (Availability) در دسترس بودن:</strong> سیستم هیچگاه down نشود و همیشه پاسخ بدهد.</li> | |
| <li><strong>P (Partition Tolerance) تحمل قطع شبکه:</strong> اگر شبکه بین گرهها قطع شد، سیستم کلا از کار نیفتد.</li> | |
| </ol> | |
| <p>از آنجا که در اینترنت قطعی شبکه (P) حتمی است، دیتابیسها باید بین A و C یکی را انتخاب کنند. RDBMSها C را انتخاب میکنند. اما اکثر NoSQLها A را انتخاب کرده و ثبات را به شکل <strong>Eventual Consistency (ثبات نهایی)</strong> ارائه میدهند (یعنی سیستم همیشه پاسخ میدهد، اگرچه ممکن است اطلاعات چند ثانیه قدیمی باشد).</p> | |
| <!-- فصل ۱۴ و ۱۵ و ۱۶ --> | |
| <h2>۱۴. مدیریت نشستها و احراز هویت بدون وضعیت (Sessions & JWT)</h2> | |
| <p>مدیریت Session سنتی (در حافظه سرور یا در یک دیتابیس مرکزی) با رشد تعداد سرورها (Load Balancing) تبدیل به کابوس میشود، زیرا همه سرورها باید وضعیت را سینک کنند.</p> | |
| <p><strong>معجزه JWT (JSON Web Token):</strong> در این معماری، سرور اطلاعات مهم کاربر (مثل آیدی و سطح دسترسی) را در یک رشته JSON مینویسد و با یک کلید مخفی (Secret Key) آن را **امضای دیجیتال (Sign)** میکند. کلاینت در هر درخواست این توکن را میفرستد.<br> | |
| سرور بدون نیاز به چک کردن دیتابیس، فقط امضای توکن را بررسی میکند. اگر امضا دستکاری نشده باشد، سرور میفهمد که اطلاعات توکن معتبر است. بدین ترتیب معماری ما ۱۰۰٪ <strong>Stateless</strong> میشود و میتوانیم هزاران سرور را بدون مشکل اضافه کنیم.</p> | |
| <h2>۱۵. امنیت پیشرفته در وب (Cryptography, SSL/TLS, Hashing)</h2> | |
| <ul> | |
| <li><strong>Hashing در برابر Encryption:</strong> رمزنگاری (Encryption) دوطرفه است (قابل بازگشت). اما هشینگ (مثل SHA-256) یکطرفه است و برای ذخیره پسوردها استفاده میشود. برای جلوگیری از حملات Rainbow Table، یک <strong>Salt (رشته تصادفی متنی)</strong> به پسورد هر شخص اضافه میشود تا هش او کاملا منحصربهفرد شود.</li> | |
| <li><strong>SSL/TLS Handshake:</strong> مرورگر و سرور برای تبادل داده ابتدا از <strong>رمزنگاری نامتقارن (Asymmetric)</strong> استفاده میکنند که دارای کلید عمومی و خصوصی است (امن اما به شدت کُند). به کمک این روش امن، آنها در واقع یک "کلید متقارن" را توافق میکنند. از آن لحظه به بعد، به دلیل سرعت بالای رمزنگاری متقارن، تمام ترافیک با آن کلید مشترک تبادل میشود.</li> | |
| </ul> | |
| <h2>۱۶. مجازیسازی نوین و کانتینرها (Docker Ecosystem)</h2> | |
| <p>کابوس معروف برنامهنویسان: "این کد روی کامپیوتر من کار میکند اما روی سرور نه!". برای رفع این مشکل، Docker اختراع شد.</p> | |
| <p><strong>تفاوت Docker با ماشینهای مجازی (VM):</strong> ماشینهای مجازی روی سرور فیزیکی نصب میشوند و هر کدام یک <strong>سیستمعامل (OS) کامل و مجزا</strong> را لود میکنند (که رم و CPU وحشتناکی هدر میدهد). اما کانتینرهای داکر مجازیسازی را در سطح OS انجام میدهند؛ یعنی تمام کانتینرها به جای داشتن OS مجزا، <strong>کرنل (Kernel) سرور میزبان را به اشتراک میگذارند!</strong> این باعث میشود کانتینرها در حد چند مگابایت باشند، در یک میلیثانیه لود شوند و پرفورمنس ۱۰۰٪ مشابه سرور اصلی داشته باشند.</p> | |
| <p>فایل پیکربندی آنها <strong>Dockerfile</strong> نام دارد (شامل دستورات <code>FROM</code> برای ایمیج پایه، <code>COPY</code> برای انتقال فایل پروژه، و <code>CMD</code> برای اجرای برنامه). از این فایل یک Image (نقشه فقط خواندنی) ساخته میشود و در نهایت کانتینرها نمونههای زنده از این ایمیجها هستند.</p> | |
| <br> | |
| <p style="text-align:center; margin-top:50px; font-weight:bold; color:#e74c3c;">پایان جزوه قطعی و فوقِتفصیلی مهندسی اینترنت</p> | |
| </body> | |
| </html> | |
Xet Storage Details
- Size:
- 30.9 kB
- Xet hash:
- af1cbf9686b1438e56c6b2228d134936fd1e3b66c6fdd801c0e6d3b4a0ecbbdb
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.