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

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

ببینین برای ارسال داده ها رویه بستر شبکه دو روش داریم :
یکیش استفاده از 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

با Django یه پروژه ساده زدم
کلا بخوام تا الان مقایسه کنم با node js ، جنگو ساختارش خیلی منطقی بود و قشنگ میشد تفاوت بین Single-Threaded تویه node js و حالا استفاده از Event Loop هاش برای مدیریت درخواست ها با Thread-based Processing تویه Django و اینکه اگه تعداد درخواست ها زیاد بشه از multi threads استفاده میکنه رو میشد دید

HTTP Request Smuggling

اول اینکه Smuggling یعنی چی؟
به معنی قاچاق هس، یعنی ما بیایم یه درخواست رو تویه یه درخواست دیگه پنهانش کنیم به خاطر اختلاف در تفسیر HTTP request بین فرانت سرور و بک‌اند سرور.

چرا به وجود میاد؟
به خاطر Inconsistency (ناهماهنگی) بین سرور فرانت و بک‌اند در پردازش هدرهای Content-Length و Transfer-Encoding. یعنی هر دو روی یه هدر توافق ندارن و هر کدوم یه مورد رو قبول دارن.

مثلاً:
- سرور فرانت (Nginx) ممکنه Content-Length رو پردازش کنه.
- سرور بک‌اند (Apache) ممکنه Transfer-Encoding رو پردازش کنه.

سرور فرانت منظورم هر پراکسی که بین کلاینت و سرور بک‌اند (داخلی) باشه میگیم که میتونه CDN، Reverse Proxy، ... باشه.

تویه این فرآیند بین کلاینت تا سرور فرانت و تا بک‌اند یه سری ویژگی‌ها و نکاتی هس که باعث میشه این آسیب‌پذیری به وجود بیاد:
تویه پروتکل HTTP 1.1 چند تا ویژگی جدید میاد نسبت به ورژن 1.0 مثل:

- Pipeline
یعنی چند درخواست بدون انتظار برای پاسخ ارسال بشن و سرور به ترتیب (FIFO) پردازش کنه. یعنی درخواست اول اولین جواب رو داره.

- Keep-Alive
یعنی یک اتصال TCP برای چند درخواست باز بمونه که باعث میشه سرعت بیشتر بشه و دیگه TCP Handshake (قبلاً گفتم دربارش) برای هر درخواست نداشته باشیم.

حالا اینا اصلاً کجای این آسیب‌پذیری نقش دارن؟
بین فرانت سرور تا بک‌اند سرور معمولاً از keep-alive, pipeline استفاده نمیشه،
ولی کلاینت تا سرور فرانت میتونه pipeline باشه.

یه مثال بزنم:

POST / HTTP/1.1
Host: example.com
Content-length: 6
Content-length: 5

12345G

چی میشه اینجا؟
1. این پکت میرسه به سرور فرانت
- سرور فرانت میاد و Content-length: 6 رو پردازش میکنه.
- دیگه کاری به Content-length: 5 نداره و کل body رو به بک‌اند سرور میفرسته.

2. این پکت می‌رسه به بک‌اند سرور
- بک‌اند میاد Content-length: 5 رو پردازش میکنه.
- ولی چون درخواستی که ارسال کردیم body بیشتر از 5 بایت هست، دو تا درخواست حسابش میکنه.
- و چون نمیتونه pipeline ارسال کنه، حرف "G" تویه buffer خودش ذخیره میشه و هر موقع درخواست بعدی اومد به درخواست بعدی prefix میکنه که باعث تغییر درخواست میشه.

GPOST / HTTP/1.1
Host: example.com

و حالاس که کاربر بعدی bad request میگیره.