CodeCrafters
رفتن به کانال در Telegram
Software Engineer and IT Group: https://t.me/code_crafters_chat Github: https://github.com/CodeCrafters-ir Site: https://codecrafters.ir
نمایش بیشتر710
مشترکین
اطلاعاتی وجود ندارد24 ساعت
+17 روز
+130 روز
آرشیو پست ها
711
دوست دارم لینوکس
دوست دارم ....
تو حوزه تکنولوژی به این بزرگی و وسعت در لبه ورود به انقلاب بزرگ AI، چه چیزی باعث شده که سمت تولید محتوی و کلیپهای زرد و با تم س..سی رفت؟؟؟
نمیدونم واقعا چرا محتوای دهه نودی به یه همچین شرکتی برسه
دانشجو بودم و اونموقع حوزه هوش مصنوعی میخوندم، از یه کمپانی تبلیغ اموزش هوش مصنوعی دیدم و رفتم دیدمش و وسط آموزش متوجه شدم که یک هوش مصنوعی داره هوش مصنوعی رو آموزش میده
این دو ماجرا رو باهم مقایسه کنید خودتون واقعا
#موقت
711
محاسبات موازی: یک عملیات روی چند هسته انجام میشود
محاسبات همزمان: یک هسته بین چند عملیات جابجا میشود
داریم راجب چی صحبت میکنیم؟؟؟
وقتی برنامه شما اجرا میشه، تبدیل به فرآیندهایی در سطح سیستم عامل میشه و سیستم عامل شروع میکنه به مدیریت اونها (به شکل پیشگیرانه) مطابق استاندارد خودش، اینکه چه منابعی رو و چقدر درگیر کنه یا نگه داره و یا از سر بگیره و به دیگری بده و ...
واسه جماعت برنامه نویس خبر خوب اینکه هیچی دست شما نیست، و خبر بد اینکه هیچی دست شما نیست😅😅😅
در واقع این مشکل شما نیست منتها نمیتونید کار زیادی هم انجام بدید
در پایتون دو کتابخانه داریم:
یکی تردها:
که بوسیله اون چندین نخ روی هسته اجرا میشه - کنترل اون رو سیستم عامل در دست میگیره - هرگاه یک نخ دچار مشکل بشه مابقی نخها توسط سیستم عامل اجرا و کار رو پیش میبرند - مناسب کارهای ورودی خروجی هستش - پیچیدگی استفاده دارند (نمیدونیم چه اتفاقی داره میافته و اصلا نخ فعال داریم یا نه تا زمانیکه رخ دادی ازشون مشاهده کنیم مثه خونه جن زده تا اتفاقی نیافته متوجه حضورشون نمیشیم) - به سطح فرآیند برسند gil فعال شده و در واقع موازی سازی ندارید دلیل اون هم جلوگیری از شرایط مسابقه (race conditions) هستش ـ پر هزینه هم هستند
دومی مولتی پراسس:
هر فرایند روی یک هسته اجرا میشه - کنترل اون توسط سیستم عامل هست - مناسب پردازشهای سنگین - پیچیدگی خاص خودش رو داره و اندکی کار خطرناک هستش - پر هزینه هم هستند
مشکل این دو کتابخانه پیچیدگی زیاد در استفاده هستش و هر کدام در یک کتابخانه جدا تهیه شده بود که استفاده ازش دردسر خاص خودش رو داشت
در نهایت کتابخانه concurrent.future اومد وسط که استخر تردها و پروسس هارو باهم داشت و در api سطح بالا بهمون کمک میکرد مشکلات gil در ترد سرجای خودش باقی موند منتها کار و مدیریت رو راحتتر میکنه برامون
تا اینجا تردها به رویکرد پیشگیرانه توسط سیستم عامل عمل میکردن
میرسیم به نخهای سبز:
این نوع نخها در سطح برنامه شما (مفسر پایتون) کار میکنن - در سطح سیستمعامل تنها بر روی یک نخ اجرا میشوند - دسترسی بیشتری بابت مدیریت و کنترل بهمون میدن و باید خودمون مدیریت کنیم - به روش مشارکتی کار میکنن (منابع رو بر اساس نقاطی که ما مشخص کردیم بهمدیگه پاس میدن) - هزینه کمتری دارن - اما یک اشتباه از سمت ما منجر به کرش برنامه خواهد شد (دیباگ سخت) - هزینه کمتر و سبک تر و اغلب سریعتر از تردهای سیستم عامل هستند - در صورت ترکیب با چند پردازنده موازی سازی رخ میده (در غیر این صورت چون در یک نخ در سیستم عامل اجرا میشود تحت کنترل gil است)
در موضوع بالا احتمال دیباگ و خطا منحر به کرش برنامه میشد بابت همین asyncio اومد وسط که کاملا از لحاظ کارایی شبیه نخهای سبز بود با این تفاوت که در نخ سبز نقاط پایانی و جابجایی توسط ما بود (همون جایی که ممکن بود خطا کنیم)، ناهمزمانی در یک حلقه رویداد رخ میداد و بدین ترتیب مشکل کرش بر طرف شد - اندکی سرعتش از نخهای سبز کمتره و نیاز به یادگیری داره
در نهایت برگردیم سر وب، در وب هر فریمورکی که بر پایه و اساس starlette نوشته بشه (یک ماژول برای http) از ناهمزمانی پشتیبانی میکنه و میتونه رقیب سر سختی برای go و nodejs محسوب بشه که نمونه بارز اون fastapi هستش
اما این مسائل بر علیه django خواهد بود؟
نه حقیقتا، جنگو بشدت برای برنامههای بزرگ و پیچیده مناسب است
سعی کردم خیلی ساده براتون بگم 😂😂😂
#python
#thread
#gil
#process
@code_crafters
711
پروژه وقتی به مرحله پروداکشن میرسه، یه گام خیلی مهم داره که انجام اون الزام آوره
لاگ گرفتن و لاگ انداختن
موضوعی که تو همه پروژهها از کوچیک تا بزرگش و تو هر معماری مورد نیاز هستش
انواع مختلف لاگ رو داریم در سطوح مختلف و همیشه کنترل کردنش بهتره بگیم نوشتن لاگ شخصی و توسعه اون یه دردسر نسبتا بزرگ هستش
مهمترین نوع لاگ در دنیای برنامه نویسی audit log (لاگ میمیزی) هستش که در سطح امنیتی و رهگیری تمامی رفتارهای کاربر در سیستم انجام میشه که با جزئیات کامل صورت میگیره
در جنگو کتابخونه django-auditlog با نصب و کانفیگ (تنظیماتش خیلی راحت هستش) کردنش لاگ ممیزی رو در سیستم شما پیاده سازی میکنه و فیچرهای کنترلی زیادی رو هم بهتون میده
کمتر از نیم ساعت این کتابخونه رو بخونید و خیلی راحت تو پروژهها ازش بهره ببرید هم بخش امنیتی سازمان و هم پشتیبانی و مدیران رده بالا رو به رضایت از بخش لاگ گیری سیستم میرسونه
#monitoring
#django
#log
#audit_log
@code_crafters
711
Content Negotiation
تصور کنید که ما یک سایت بینالمللی داریم که روزانه هزاران درخواست توسط افراد از سرتاسر جهان دریافت میکند. همهمان میدانیم که برای چنین سایت بزرگی نمیتوانیم صرفا محتوا را به زبان انگلیسی به اشتراک بگذاریم بلکه باید از یک مکانیزم استفاده کنیم تا هر کاربر به زبان کشور خودش محتوا را دریافت کند.
به این موضوع Content Negotiation میگوییم.
در این پیام به نحوه تصمیمگیری برای انتخاب یک زبان میپردازیم.
به طور کلی ما دو روش برای انتخاب زبان داریم:
- Client-driven negotiation
- Server-driven negotiation
اکنون به Client-driven negotiation میپردازیم.
در این مکانیزم هنکامی که کاربر به سایت codecrafters.ir درخواست میزنند, سرور کد کرفرترز برای کلاینت لیستی از زبانها را ارسال میکند. اکنون مرورگر میتواند تصمیم بگیرد که کدام یک از url ها را باز کرده و به کاربر نشان دهد.
همانطور که متوجه شدید, این روش اصلا مناسب نیست! چرا که باید ۲ برابر ریکوئست ارسال شود و این موضوع latency را به شدت افزایش میدهد. پس بهتر است به فکر یک روش دیگری باشیم تا دیگر کلاینت اینهمه درگیر انتخاب زبان نباشد.
برای حل این موضوع Server-side negotiation بوجود آمد.
وبسرور به ۲ روش تصمیم میگیرد که کدام یک از زبانها را انتخاب کند.
۱- استفاده از header هایی مانند Accept-language و Accept-charset.
۲- استفاده از User-agent کاربر.
شاید این سوال برایتان پیش بیاید که چرا مورد دوم را بررسی میکنیم.
در جواب این سوال باید بدانیم که گاهی تنها زبان مهم نیست بلکه مهم این است که اطلاعات درست به کاربر نمایش داده شود. تصور کنید که یک وبسایت در صفحاتش از جاوااسکریپت استفاده میکند و مرورگر قدیمی ما از جاوا اسکریپت پشتیبانی نمیکنید.
پس سرور باید محتوای درستی که از JS استفاده نمیکند را با زبان درست برای کاربر ارسال کنید.
گاهی Http اجازه میدهد که کاربران یک لیست از انتظارات خود ارسال کنند.
تصور کنید ما میخواهیم به سایت codecrafters.ir درخواست بزنیم اما نمیدانیم که آیا زبان المانی پشتیبانی میشود یا خیر.
پس ما در هدر Accept-language مقدار زیر را ارسال میکنیم:
Accept-language: en;q=0.5, fr;q=0.0., du;1.0.
هنگامی که سرور این پیام را دریافت میکند, اینگونه برداشت میکند که محتوا باید المانی باشد, اگر چنین چیزی موجود نبود, انگلیسی نیز میپذیرد. اما باید توجه داشته باشد که هیچگاه محتوای فرانسوی ارسال نکند.
گاهی نیز این تصمیمات را بر عهده proxy میسپاریم.
این proxy server است که تصمیم میگیرد به کدام resource درخواست بزند و اطلاعات لازم را به کاربر ارسال کند.
#http_guideline
@code_crafters
711
یکی از مواردی که این روزها خیلی نیازمند هستش در داخل برنامه نویسی تحت وب و وب اپلیکیشن
حضور و وجود تسکهای ناهمگام و زمان بندی و برنامه ریزی شده هستش
اخیرا هم تو مراحل مصاحبه و استخدامی هم از این سوالات زیاد پرسیده میشه
فریمورک fastapi چون پیش فرض و در دل خودش asyncio هستش این مورد هندل میکنه اما برای django ما از ترکیب celery با (rabbitmq ، redis) استفاده میکردیم اما این خودش یکمقدار افزونه و کار بیشتر اضافه میکرد
پکیج django_q اومده و کار رو راحت کرده هم برای تسکها ناهمگام و هم برای تسکهای زمان بندی شده و برنامه ریزی شده پیش فرض و پرفورمنس اون با ردیس هستش اما توان اتصال به سایر ابزارهایی که بتونن بعنوان بروکر استفاده بشند رو هم داره (حتی بروکر کاستوم و شخصی خودتون)
خیلی راحتتر و سبک تر از سلری هستش و هیچگونه پیچیدگی خاص اجرایی و کار کردی نداره
میتونید باهاش در پس زمینه یا برنامه ریزی شده ارسال ایمیل و پیامک داشته باشین، تصاویر و فایلهارو ذخیره کنید (حتی بصورت chunk) و علاوه بر این میتونید لایهکوئری رو هم باهاش به صورت ناهمگام با orm اجرا کنید
بچههای جنگو کار حتما این کتابخونه رو در حد چند ساعت بخونن هم پرفورمنسی و زمانی بکارتون میاد بشدت
#django
@code_crafters
711
رمان گرگ بیابان از هرمان هسه
سالهاست میگذره که یادم نمیاد کی بوده که رمانی خونده باشم و چنان جذاب باشه که خوابش رو ببینم
یه رمان فلسفی بشدت سنگین هستش که درک کردن خط به خط اون واقعا سخته
یه قسمت از رمان شخصیت داستان درگیر کشمکش درونی و برهان وجودی سنگینی میشه و از رفتن به خونه امتناع میکنه و بشدت میترسه
راه رو در پیش میگیره و بقدری پیاده میره که از پا میافته و وارد یه کاواره میشه از شانسش کنار یه دختر میشینه
دختره ازش میپرسه که چی اذیتت کرده که انقدر پریشان وضعی و از خونه فرار کردی، تو خونه چی منتظرت بوده که ازش فرار میکنی
شخصیت داستان بهش میگه تیغ اصلاح صورت منتظرمه تا پیش از موعود گارم رو باهاش انجام بدم (رگ گردنش رو بزنه)
مراقب باشید
بعضی وقتها حتی کسانی که روان قوی و محکمی دارن تو لحظه پرتگاه زندگیشون به سمت خودکشی هستند بدون اینکه حتی کسی متوجه بشه
711
Http Internationalization
روزانه میلیاردها انسان در جهان document هایی را به زبانهای مختلفی در اینترنت به اشتراک میگذارند. همانطور که از اسم world-wide web مشخص است, این شبکه برای تمام افراد جهان با هر زبانی است. پس باید راهی باشد که بتوانیم به نوعی تمامی این اطلاعات را منتقل کنیم
هرگاه یک درخواستی ارسال میشود, یک هدر accept-language نیز با آن ارسال میشود. با این هدر کلاینت به سرور میگوید که من انتظار دارم پیامی که دریافت میکنم, زبانش این باشد.
پس از اینکه سرور با توجه به این هدر ریسپانس را فراهم و ارسال کرد, در آن یک هدر به نام content-language ارسال میکند. اینگونه کلاینت میتواند با استفاده از آن محتوای پیام را باز کرده و از ان استفاده کند.
اما چگونه این اطلاعات باینری تبدیل به متون قابل خواندن میشود؟ برای درک این موضوع ابتدا باید به مفهوم Charset ها بپردازیم.
درواقع این charset ها هستند که میگویند این مقدار باینری را به کدام یک از کاراکتر های کدام زبان وصل کنیم.
هنگامی که ریسپانس را دریافت میکنیم, در هدر content-type یک charset نیز ثبت شده است.
مثال:
Content-Type: text/html; charset=iso-8859-6
این به این معنی است که داده ما به صورت ۸ بیتی map میشود (که احتمالا یا لاتین است یا عربی!)
حالا کار این character set ها چیست؟
کرکتر ست ها درواقع دو کار را انجام میدهند.
۱- تبدیل باینری به کد کاراکتر
۲- تبدیل کد کاراکتر به کلمه
برای مثال ما میخواهیم به کمک کرکتر ست ها مقدار زیر را به کاراکتر تبدیل کنیم.
11100001
ابتدا این را به کاراکتر کد ۲۲۵ تبدیل میکنیم و سپس کد ۲۲۵ را به کلمه اصلی خود مپ میکنیم که درواقع کاراکتر «ف» است.
پس:
11100001 -> 225 -> ف
حالا که متوجه شدیم تمامی این کارها را کرکتر ست ها انجام میدهند, پس چرا هدر content-language ارسال میکنیم؟
کاراکتر ست ها صرفا الگوریتم هایی هستند که صرفا بر اساس زبان, میتوانند کد ها را به کلمات مپ کنند.
برای مثال کرکتر کد ۲۲۵ در زبانهای مختلف شکل های مختلفی دارد.
در زبان لاتین a و در زبان عربی «ف» است و در زبان یونانی «الفا».
به عنوان نکته پایانی باید درنظر داشت که کاراکترها میتوانند فرمهای گوناگونی داشته باشند.
برای مثال کاراکتر «ع» میتواند گاهی «عـ» نیز باشد.
اینجا نیاز است که مفهوم glyph را درک کنیم.
هنگامی که کاراکتر کد به یک کاراکتر مپ میشود, نوع نشان دادن آن مشخص نمیشود. ما صرفا میدانیم که 225 عدد کاراکتر «ف» است. حال نمایش دادن این عبارات بر عهده glyph است.
اگر بخواهیم موشکافانه تر به قضیه نگاه کنیم, فرایند تبدیل بصورت زیر خواهد بود:
11100001 -> 225 -> "ARABIT LETTER FEH" -> glyph shows «ف»
#http_guideline
@code_crafters
711
حادثه تلخ انفجار در بندر رجایی
کشته و مجروح شدن هموطنان عزیزانمون
نام و یاد کشته شدگان این حادثه ماندگار و طلب صبر برای بازماندگان 🖤🖤🖤
آرزوی بهبود مجروحان و بازگشت به کانون گرم عزیزان خود💔💔💔
یک ایران دلواپس و همراه غم و اندوه شماست 🌹🌹🌹🌹
711
خواهشا این پیام رو با دقت بخونید
تو یه شرکتی مشغول بکار شدم
و به همه توصیه میکنم بابت کار کردن اینجا (به هزار و یک دلیل)
خب نیاز به تعدادی نیرو دارن (حضوری، تمام وقت در تهران)
برنامه نویس node js
برنامه نویس فرانت (react, next)
طراح ui/ux
مهندس دواپس (بعدها در آینده)
مدیر پروژه
خواهشا رزومه برام بفرستین و داخل رزومه علاوه بر معرفی کامل خودتون و مهارتهاتون مبلغ پیشنهادی خودتون رو هم ذکر کنید
من رزومههارو جمع میکنم و میدم تحویل مدیران بالادستی دیگه مابقیش برعهده من نیست هیچ چیزی
#موقت
711
با دقت به شبهای اخر هفته آیندتون نگاه کنید
تو گذشته خودم این روزام یجوری دیگه بود کاملا متفاوت از این چیزی که میبینید
#موقت
711
انتیتی (entity) و انکدینگ (encoding)
میدانیم که http روزانه میلیاردها آبجکت از هر نوع اطلاعاتی (مانند عکس، فیلم، متن و...) را جابجا میکند؛
اما ارسال پیام برای ما کافی نیست!
ما باید مطمئن شویم که این پیامها کاملا ارسال شدهاند، identify شدهاند، استخراج و پراسس شده اند.
برای اینکه اطلاعاتمان را به شیوه صحیح ارسال کنیم، میبایستی از header های درستی استفاده کنیم.
قبل از اینکه بدانیم هدر ها کجا ست میشوند، بیایید یک نگاهی مختصر به ساختار http message داشته باشیم:
هر http message میتواند یا برای request باشد و یا برای response.
این پیامها از سه بخش تشکیل شدهاند:
۱- در این بخش ما ریسورس خود را مشخص میکنیم.
برای ریکوئست: url و host را به همراه method در این بخش ست میکنیم.
مثال:
GET google.com/random/path
برای ریسپانس: تنها جواب از سوی سرور را در اینجا ست میکنیم
404 google.com/random/path
۲- در این بخش هدرهای خود را ست میکنیم. هدر ها برای ریکوئست و ریسپانس گاهی متفاوت است.
برای ریکوئست، میگوییم: «من انتظار یک ایمیج را دارم» اما برای ریسپانس میگوییم «در این پیام برایت یک ایمیج را فرستادم».
۳- این بخش، بخش بدنه است. تنها در ریسپانس، در این بخش اطلاعات را میگذاریم.
* درواقع http headers یک plain text از هدر ها هستند که در لایه دوم http message قرار میگیرند.
در این بخش به مرور چند هدر معروف میپردازیم:
1- Content-type:
این هدر، نشان میدهد که شما در بخش body، انتظار چه اطلاعاتی را خواهید داشت.
برای مثال، هنگامی که شما یک متن را باز میکنید، content-type از سمت سرور مقصد به مقدار text/plain ست میشود.
2- content length
پیش از اینکه body را از یک http message استخراج کنیم، میبایستی بدانیم که چه انتظاری از بدنه خواهیم داشت.
برای مثال انتظار یک عکس با حجم ۲ مگابایت را داریم. پس در این هدر، ما حجم content را ست میکنیم.
3- content encoding
گاهی برای امنیت بیشتر و یا کم کردن حجم، ما اطلاعات یک پیام را encode میکنیم. در این هدر، به مقصد میفهمانیم که پیام از قبل با این الگوریتم encode شده، پس برای خواندن آن، آن را decode کنید.
#http_guideline
@code_crafters
711
یک اتصال امن با HTTPS
پیشتر آموختیم که ssl یک لایه رمزگذاری است که با رمزنگاری کردن پیامها، امنیت اطلاعاتمان را در شبکه تضمین میکند.
تا زمانی که شما تبدیل به یک متخصص در زمینه ارز ها نشدید، نیاز نیست بدانید چگونه میتوانید با raw ssl پیامهای خود را جابجا کنید؛ چرا که کتابخانههای مختلفی وجود دارد تا بتوانید ssl program های خود را توسعه دهید!
برای مثال یکی از معروفترین آنها، OpenSsl است.
بیایید و ببینیم چگونه میتوانیم به کمک ssl, پیامهای خود را رمزنگاری و ارسال کنیم.
تصور کنید میخواهید یک پیام از کامپیوتر خود به یک سرور در آمریکا ارسال کنید.
۱- کامپیوتر شما یک local context میسازد و تمام اطلاعات handshake را با فراخوانی SSL_CTX آماده میکند.
۲- دامنهٔ سرور مقصد را به ip تبدیل میکند
۳- یک اتصال به پورت ۴۴۳ مقصد ایجاد میکند که نیازمند ساخت یک local socket است.
۴- هنگامی که اتصال برقرار شد، میتوانیم لایهٔ ssl را به اتصال TCP خود وصل کنیم..
۵- سرور certificate خود را ارسال میکند و با کامپیوتر شما یک کلید رمزنگاری ارسال میکند
۶- تمامی اطلاعات با کلیدی که در مرحله ۵ ارسال شده بود، رمزنگاری و رمزگشایی میشود!
اما آیا این تنها راه است؟ جواب به این سوال، خیر است.
ما میتوانیم به واسطهٔ یک proxy server نیز، به صورت امن اطلاعات خود را جابجا کنیم.
به صورت ساده، این ارتباط به صورت زیر است:
«لوکال -> سرور پروکسی -> مقصد»
اما یک مشکلی داریم!
ما میدانیم که برای رمزنگاری، از public key سرور مقصد استفاده میکنیم.
اینجا اگر اطلاعات را به پروکسی سرور دهیم، باید آن را بازگشایی و مجدد رمزنگاری کند و به سرور ارسال کند. این مسلما چیزی نیست که ما میخواهیم.
اینجا باید به گونهای با سرور پروکسی صحبت کنیم که بداند میخواهیم از آن به عنوان یک middle man استفاده کنیم.
برای اینکار از پروتکل HTTPS SSL TUNNELING استفاده میکنیم!
ابتدا به سرور پروکسی، یک درخواست با پروتکل مخصوص CONNECT میزنیم.
در payload آدرس سرور مقصد را میدهیم.
هنگامی که سرور این پیام را دریافت کرد، تمامی پیامهای کلاینت را به سمت سرور ارسال میکند و جواب را به کلاینت برمیگرداند.
#http_guideline
@code_crafters
711
در این مجموعه پستها، میخواهیم کتاب http guideline را مطالعه کنیم و نکات آن را خلاصه نویسی کرده و به اشتراک بگذاریم.
این کتاب به شما دید خوبی درمورد http میدهد و با خواندن این کتاب میتوانید درک خوبی از مسائل مربوط به این پروتکل و اپلیکیشنهای تحت وب به دست آورید.
این مجموعه پست ها را با هشتگ
#http_guideline
میتوانید در کانال دنبال کنید.
کتاب در ابتدا خیلی ساده و کوتاه شروع شده و در فصلهای بعدی هر بخش از فصل قبل را بازتر کرده و به جزئیات موارد می پردازد
در این پیام میخواهیم درمورد ssl certificate صحبت کنیم.
چگونه سرورها هویت خود را ثابت میکنند؟
در پروتکل HTTP اطلاعات رمزگذاری نمیشوند.
درواقع یک connection به پورت ۸۰ سرور ایجاد میشود و یک request message از سمت کاربر ارسال میشود و یک response message از سوی سرور دریافت میشود و در نهایت این کانکشن بسته میشود.
این flow برای انتقال اطلاعات حساس همچون اطلاعات بانکی اصلأ مناسب نیست، چرا که هرکسی میتواند message ها را باز کند و اطلاعات آن را استخراج کند.
برای جلوگیری از این اتفاق HTTPS ظهور کرد!
درواقع HTTPS همان HTTP است، با این تفاوت که در این پروتوکل یک لایهٔ امنیتی نیز اضافه شده است.
اکنون flow مقداری پیچیده میشود!
کاربر یک connection به پورت ۴۴۳ ایجاد میکند. هنگامی که سرور کانکشن را قبول کرد، ssl initialization انجام میشود.
در این مرحله پارامتر های رمزنگاری توسط client و server جابجا میشود. هنگامی که این handshake انجام شد، اطلاعات ابتدا به لایهٔ ssl ارسال و رمزنگاری میشود و سپس به سمت کلاینت/سرور ارسال میشود.
در مرحله ssl handshake اطلاعات زیر توسط کلاینت و سرور جابجا میشود:
- ورژن پروتوکل http
- یک کلید برای رمزنگاری
- یک session key موقت برای رمزنگاری شبکه
- اطلاعات هویتی سرور (certificate)
بیاید و یکم certificate رو باز کنیم!
درواقع certificate یک فایلی است که سرور برای اثبات هویت خود، به کلاینت ارسال میکند. این سرتیفیکیت برای اینکه اعتبار خود را نشان دهد، از پیش توسط یک Certificate authority امضا شده است.
این فایل شامل اطلاعات زیر میباشد:
- Public key
- Hostname of website
- Name of signing authority
- Signature of signing authority
هنگامی که این فایل توسط کلاینت دریافت میشود، مرورگر به صورت اتوماتیک ولیدیشن هایی را روی این فایل انجام میدهد. برای مثال:
۱- ابتدا تاریخ certificate بررسی میشود که منقضی نشده باشد
۲- امضای signature مورد بررسی قرار میگیرد تا مطمئن شویم authority قابل اعتمادی این certificate را امضا کرده.
۳- در این مرحله با authorities public key سیگنیچر را مقایسه میکنند تا مطمئن شوند CA واقعاً این certificate را امضا کرده.
۴- برای اطمینان از اینکه این certificate تنها برای این سرور است، domain سرور را با دامین سرتیفیکیت مقایسه میکنیم.
کاری از بچههای گروه منتوری
@code_crafters
711
هر اندیشهای که منتهی به عمل نشود، مرض است
این جمله ناب رو گوته گفته
شاید بگید خب من اندیشه قتل دارم الان برم عملیش کنم؟؟؟
باید بهتون بگم متاسفانه گوته رو نمیشناسید که همچین استدلالی میکنید
در بین تمام فیلسوفان گوته دارای شخصیتی بشدت در حد کمال انسانی بود، گوته بشدت زیباشناس بود و چنان شخصیت پختهای داشت که از تمام دنیا برای دیدن و ملاقاتش دست و پا میزدن و بشدت آدمی بود که بزرگترین اشراف زادههای زمان خودش به زندگی گوته حسادت میکردن
همینقدر براتون بگم، شوپنهاوری که به همه فیلسوفان و افکارها حمله کرد در مقابل گوته جز به احترام و بزرگی یادی نکرد ازش، شوپنهاور با همه وجود مادرش مشکل داشت حتی ارتباطاتش با اطرافیانش بجز ارتباطش با گوته
برگردیم به حرفمون
سالها پیش یه جمله از بوکوفسکی خوندم که میگفت هرکاری وقتی تمام شود به لذت تبدیل میشود (پروژهای که گرفتیم، مسیر یادگیری تخصصی، تحصیلات دانشگاهی و ...)
ولی موضوع گوته فراتر از بوکوفسکی هستش، بوکوفسکی از لذت حرف میزنه، گوته از شادی و حس خوب نسبت به خودمون، بحث اصلا تموم کردن یا نکردنش نیست(بقول بوکوفسکی)، بحث سر عملی کردن و انجام دادن هستش (بقول گوته)
خیلی وقتها بابت اینکه نمیتونیم یکاری رو انجام بدیم ناراحتیم، مثلا اینکه چرا شاغل نیستم چرا شغل مورد علاقه خودم رو ندارم
گوته تو این یک جمله ساده میگه چقدر عملیش کردی، اصلا مهم نیست به شغل رسیدی یا نه، چه برسه مورد علاقهت باشه
گوته میگه چقدر بابت داشتن شغل اقدام عملی داشتی، منظورش این هست که خودت رو بجایی نرسون که تبدیل به ای کاش، ای کاش بشی. حداقل خودت رو به جایی برسون بگو من رفتم اقدام کردم ولی نشد دنبال بهونه نگرد اقدام کن فقط این مهمه نه چیز دیگهای
در واقع حس خوب و رضایت از خودمون به همین مسئله بستگی داره، اگه بابتش اقدام جدی نکنی به عملی کردنش، درگیر سرخوردگی و یاس میشی
میخوای مهندس نرم افزار بشی؟؟
عملیش کن
میخوای برنامه نویس بشی؟؟
عملیش کن
میخوای از تخصصت شغل داشته باشی؟؟
عملیش کن
میخوای مستقل بشی؟؟
عملیش کن
حرف آخر بابت حس رضایت درونی، اقدام برای اندیشههامون هستش همین رو شما گوشه ذهنت نگهدار و انجام بده ببین چجوری به حس رضایت از خودت میرسی
#free
@code_crafters
711
استاد کاکایی
میگن هیچ نوازندهای نمیتونه اندازه سازنده ساز، ساز رو به رقص خودش در بیاره
شعرهای استاد رو هم کسی جز خودش نمیتونه انقدر زیبا بیان کنه
711
Repost from KubarCloud | کوبار کلاد
☁️ سرورهای ابری (IaaS) به کوبار کلاد اضافه شد! 🚀
⏰ پرداخت ساعتی(PAYG)
🐧 سیستمعاملهای متنوع
🌐 شبکه خصوصی(Private Network)
💾 دیسک اضافی (Volume)
🔑 پشتیبانی از کلید عمومی(SSH Key)
🖥 دسترسی به کنسول
📊 مانیتورینگ
🎁 اعتبار اولیه رایگان برای شروع سریع و بدون دغدغه
همین حالا سرور ابری خودتون رو با ۳ کلیک بسازید!
🌐 KubarCloud.com
🆔 @KubarCloud
711
دردناکترین قسمت تکنولوژی
زنده کردن صدا و خندیدن عزیزترین دوست زندگیت بطور اتفاقی، بعد از گذشت سه سال خودکشیش
تمام خاطرات برات زنده میشه
تمام روزهایی که سعی کردی یکی از عزیزانت از بحران روحی و روانی نجات بدی اما موفق نشدی
و مدام و مدام این سوال توی ذهنت برای این سالها تکرار بشه، چکار دیگهای میتونستم انجام بدم و ندادم
کجای اون شش ماه لعنتی کوتاهی کردم، در حق آدمی که به من نزدیکتر از خونوادش بود
بار سنگین دوست داشتن، حتی با مرگ هم نه تنها از بین نمیره، بلکه با قدرت بیشتری در زندگیتون باقی میمونه
اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
