کتاب یکم مفاهیمش قدیمی هس و فریم‌ورک‌های جدیدی رو زیاد توضیح نمیده
ولی مفاهیم پایه رو خوب گفته . در کل بد نبود 🦦

خب آقا دیدم این مبحث هم تویه شبکه مثل بحث های معماری جذابه 🦦😂

ببینین برای ارسال داده ها رویه بستر شبکه دو روش داریم :
یکیش استفاده از packet switching هست و یکی دیگه استفاده از circuit switching

تویه packet switching به این صورت عمل میکنه که داده ها به صورت packet های مختلف وارد route ها میشن و بعد بر اساس پهنای باند بین هر route داده ها انتقال پیدا میکنن .(البته یه شرطی هست که باید هر پکت به صورت کامل بین هر route ارسال بشه و بعد پراکسی بشه به router بعدی ) و البته مسیر ارسال هر داده یکسان نیست و میتونه واسه پکت های مختلف مسیر های متفاوتی داشته باشه .
حالا تویه packet switching یه مشکلی هست و اونم ازدحام پکت هاست . هر route یک مموری ثابتی داره که اگه بیشتر از حد داده روش به صورت صف ذخیره بشه برای ارسال ممکن هست داده drop یا loss بشه
از این روش برای ارسال data بیشتر استفاده میشه مثال هاشم مثل tcp/ip , voIP , ...


تویه circuit switching اول برای برقراری یه call Setup رخ میده و در اصل router ها دنبال یک مسیر و لینک کردن ثابت بین سرور و کلاینت هستن
با این کار یک مسیر دائمی تشکیل میشه و میشه داده ها بدون اینکه ازدحام رخ بده ارسال بشن
دو تا رویکرد داریم واسه تشکیل لینک بین سرور و کلاینت : TDM , FDM
تویه FDM فرض کنین اگه فرکانس بین router ها ۱۰۰ گیگ بر ثانیه باشه این میاد بین یوزر های مختلف ولی در تایمی که ارتباط هنوز فعاله اون مسیر مال خودشه .
تویه TDM بر اساس زمان تقسیم بندی میشن ولی اون مدت زمانی که دست هر یوزر هست کل فرکانس بین ها route دست یک نفره . مثال استفاده هاشم هم تویه ATM ها و تلفن های ثابت و ... هست

اما نکته مهمی که هست اینه که درسته تویه circuit switching یه ارتباط دائمی داریم ولی همین خوبیش میتونه به عنوان بدیش تموم بشه 😂
یعنی حتی وقت هایی که یوزر کاری با سرور نداره باز هم بخشی از فرکانس دست اون هست و در این صورت تعداد یوزر کمتری می‌تونن وصل بشن
ولی تویه packet switching درسته که بعضی از مواقع که تعداد درخواست ها خیلی بالا میره و ازدحام میشه ولی اوب اینکه یوزر ها همیشه در حال ارسال داده نیستن و دوم اینکه میتونیم رویه تایم های خالی که داریم سرشکن کنیم و بهتر بتونیم از زمان استفاده کنیم و تعداد یوزر بیشتری می‌تونن تویه شبکه باشن
اون بخش ازدحام رو هم میشه حل کرد مثلا :

بعضی پروتکل‌ها (مثلاً TCP) Congestion Control دارن که باعث میشه اگه شبکه شلوغ بشه، سرعت ارسال داده رو کم کنن تا بسته‌ها کمتر Drop بشن ولی تویه UDP این کنترل وجود نداره، برای همین توی استریم و VoIP گاهی قطع و وصلی داریم.
یا اگه تویه یه شرایط خاص داشتیم که تاخیر خیلی مهم بود میشه از QoS استفاده کرد که میاد بسته های مهم تر رو زود تر ارسال میکنه .

#network

Over $1.46 billion worth of cryptocurrency was stolen from Bybit's Ethereum cold wallet in the largest crypto heist to date, reportedly orchestrated by the Lazarus Group.

The attack masked the signing interface, tricking the wallet into transferring funds to an unknown address.

Learn more: https://thehackernews.com/2025/02/bybit-confirms-record-breaking-146.html

داشتم درمورد بالابردن سرعت انتقال دیتا بین کلاینت و دیتابیس میخوندم دیدم بحث جالبیه 🦦

حالا علاوه بر اینکه میتونیم Query ها رو بهینه بنویسیم و هم از Parallel Processing تویه CPU ها استفاده کنیم(پزدازش ها به صورت موازی انجام میشن بین cpu ها)، میشه یه سری دیتا ها رو از دیسک تویه رم ذخیره که میشه تویه سطح‌های مختلف تست کرد.

میشه تویه سمت دیتابیس یا از Redis استفاده کنیم که خب یکم مشکله اگه قبلا دیتا ها رویه MySQL باشن اذیت میشیم و اینکه دیتا رویه رم و دیسک باید با هم sync باشن و هم میشه از Memory Table تویه MySQL استفاده کرد که خب مثل این میمونه یه تیکه از دیتابیس که تویه دیسکه اومده تویه رم اما مشکلش اینه اگه دیتایی تغییر کرد چون نمیشه به صورت خودکار sync کرد بین رم و دیسک، به مشکل میخوریم.
برای رفع مشکل هر دو هم میتونیم از write-through caching استفاده کنیم که دیتا دیسک و رم با هم سینک بشن.

به غیر سطح دیتابیس میشه تویه سطح‌های سرور و حتی کلاینت استفاده کنیم.
مثلا تویه سرور از کش کردن با Redis یا تویه کلاینت با استفاده از Local Storage یا sessionStorage که خب حجم زیادی ندارن و برای هر یوزر خاص کاربرد دارن.

اقتصاد مملکت رو کافه ، اسنپ و ایونت میچرخه

من وقتی کسی بلوفمو تویه پوکر میفهمید 🤣

اگه دیتابیسی طراحی کردین و خواستین ایرادی داشت بفهمین این به کار میاد

https://github.com/drawdb-io/drawdb

کش در CDN

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

حالا چطور CDN یه محتوا رو کش می‌کنه؟
وقتی یه سری درخواست به سایت می‌زنیم، اگر محتوای سایت استاتیک باشه، در درخواست اول که هنوز محتوا توسط CDN کش نشده، با یک Miss مواجه می‌شیم. اما در درخواست‌های بعدی، Hit میخوره.
سوالی که پیش میاد اینه که CDN چطور می‌فهمه که ما همون درخواست رو زدیم؟
این کار با تشخیص هدرها انجام میشه. به هدرهایی که برای این تشخیص استفاده می‌شه، "Cache Key" گفته میشه.
مثلا :
HTTP|GET|site.com|/new/test.php?id=1

همچنین، بعضی هدرها وجود دارن که CDN موقع بررسی کش به اون‌ها توجه نمی‌کنه و به این هدرها "unkey input" گفته میشه. اما میشه با هدر vary این هدر ها رو مجبور کرد که کش بشن. مثلا با استفاده از هدر
vary: cookie.

CDN (Content Delivery Network)
CDN یه شبکه از سرورهای مختلف هست که محتوای استاتیک سایت‌ها رو ذخیره و نگهداری می‌کنه.
این کار باعث میشه که سرعت بارگذاری داده‌ها بیشتر بشه یا load balancing و ...

چطور بفهمیم یک سایت پشت CDN هست یا نه؟
1. ping site.com
2. whois ip[site.com]

یا اینکه ip شو تویه این سایت پیدا کنیم.

با این کار می‌تونیم بفهمیم که IP متعلق به CDN هست یا نه. چون وقتی سایتی پشت CDN قرار داشته باشه، دیگه نمی‌تونیم IP اصلی سایت رو ببینیم و فقط IP CDN نمایش داده میشه.

امروز مجبور شدم از Django استفاده کنم
یه تفاوتی در مقابل node js که توجهم رو جلب کرد این بود که Django خودش یه orm داره واسه خودش (یه orm داخلی ) بهش میگن Django ORM ولی در صورتی که تویه node js باید از sequelize استفاده کنیم
که خب تقریبا هیچ برتری نسبت به هم ندیدم و فقط Django یکم اومده بود کارو ساده تر کرده بود ولی تویه sequelize دستتون باز تره 😂🦦

چند تا آسیب‌پذیری موقع Cache توی CDN می‌تونه رخ بده:

اولیش Cache Deception هست که کاربر رو مجبور می‌کنیم اطلاعات حساس خودش رو توی Cache ذخیره کنه و یه مسیری که داینامیک هست رو بیایم به یه مسیر استاتیک تبدیل کنیم که کش بشه.
مثلاً اگه با این URL اطلاعات کاربر نشون داده بشه:
https://example.com/auth/profile
چون یه path داینامیک هست کش نمیشه ولی میشه با
https://example.com/auth/profile/mamad.css
به یه path استاتیک تبدیل کرد و حالا CDN کش می‌کنه و اگه همین لینک رو به یه کاربر عادی بدیم چون هنوز اطلاعات توی کش نیست miss می‌خوره و بعدش می‌تونیم به عنوان attacker با باز کردن همین لینک از توی کش بدون احراز هویت اطلاعات ذخیره شده توی کش رو ببینیم.

چرا این آسیب‌پذیری رخ می‌ده؟ چون برنامه‌نویس فقط /auth/profile رو چک می‌کنه:

app.get('/auth/profile', (req, res) => {
    res.send(`<h1>Welcome, ${req.user.name}</h1>`);
});

در صورتی که باید بگه اگه جز این مسیر بود:

app.get('/auth/profile/*', (req, res) => {
    res.status(404).send('Not Found');
});

یه آسیب‌پذیری دیگه در Cache Poisoning هست که در واقع میاد هدرهایی که توی کش شدن تاثیری ندارن (unkey input) رو شناسایی می‌کنیم. مثلا:

GET / HTTP/1.1  
Host: example.com

یه هدر X-Forwarded-Host توسط CDN کش نمیشه، حالا میشه با فرستادن این درخواست:

GET / HTTP/1.1  
Host: example.com  
X-Forwarded-Host: attacker.com

حالا هر کاربری که example.com رو باز کنه، redirect میشه به attacker.com و حالا دیگه میشه این رو با آسیب پذیری هایی مثل XSS ترکیب کرد.

این نامه ای که ترامپ فرستاده احتمالا Packet Loss شده

@Linuxor