تلگرام چگونه ساخته شد؟ تاریخچه، زبان برنامه نویسی نسخه های اولیه و معماری MTProto

تلگرام چطور ساخته شد؟ از نسخه اول تا MTProto

تلگرام از اون برنامه هایی است که تا وقتی زیرش را نگاه نکنی، خیلی ساده به نظر می رسد. ولی کافی است چند تا سوال اعصاب خورد کن بپرسی: نسخه اول تلگرام با چه زبانی نوشته شد؟ MTProto دقیقا چه کاری انجام می دهد؟ کلاینت چطور با سرور کلید می سازد؟ Cloud Chat و Secret Chat چه تفاوت معماری دارند؟ و اصلاً چه بخش هایی از زیرساخت تلگرام واقعاً عمومی هستند؟

خلاصه قرار است یک پیچ گوشتی برداریم و ببینیم زیر این پیام رسان معروف چه خبر است. از نسخه های اولیه می رویم سراغ MTProto، handshake، چت های ابری، Secret Chat و دیتا سنترها. هرجا خود تلگرام جواب داده، همان را می آوریم. هرجا جواب نداده، الکی از خودمان جواب در نمی کنیم که مقاله شیک تر به نظر برسد :)

---

<a id="origin"></a>

خب، تلگرام اصلاً از کجا شروع شد؟

طبق تاریخچه رسمی تلگرام، نسخه iOS در ۱۴ اوت ۲۰۱۳ منتشر شد. نسخه رسمی اولیه Android نیز در ۲۰ اکتبر ۲۰۱۳ عرضه شد. پشت پروژه دو برادر، Pavel Durov و Nikolai Durov، قرار داشتند؛ پاول نقش مالی و محصولی/ایدئولوژیک را برعهده داشت و نیکلای بخش فنی را پیش می برد.

تلگرام از همان اول قرار نبود فقط یک رابط چت خوشگل روی یک API معمولی باشد. هسته ارتباطی آن بر پروتکلی اختصاصی به نام MTProto بنا شد؛ پروتکلی که طبق FAQ رسمی تلگرام توسط Nikolai Durov طراحی شد و از ابتدا برای کار با چند دیتا سنتر و شبکه های موبایلی ناپایدار بهینه شده بود.

منبع رسمی: Telegram FAQ و A (Not So) Brief History of Telegram.

یک گزارش هم دوره در TechCrunch در اکتبر ۲۰۱۳ نیز MTProto را به عنوان پروتکل داده های سفارشی توسعه داده شده توسط Nikolai Durov توصیف می کند و تفاوت Secret Chat با چت عادی را همان زمان توضیح می دهد: TechCrunch — Meet Telegram.

---

<a id="first-code"></a>

خب... نسخه اول تلگرام با چه زبانی نوشته شد؟

جواب کوتاهش این است: بستگی دارد کدام قسمت را می پرسی. باید کلاینت را از سرور جدا کنیم.

iOS: نسخه اصلی با Objective-C

تلگرام در سال ۲۰۱۸، هنگام معرفی بازنویسی کامل اپ iOS با Swift، رسماً نوشت که کلاینت قدیمی iOS با Objective-C ساخته شده بود. بنابراین درباره اپ اولیه iPhone پاسخ روشن است: نسل اول تلگرام iOS بر پایه Objective-C بود.

منبع رسمی: Introducing Telegram 5.0 for iOS و Telegram X: Progress through Competition.

Android: Java در هسته اپ اولیه

سورس رسمی Telegram for Android در GitHub نشان می دهد شاخه های قدیمی 1.3.x یک پروژه Android مبتنی بر Java بوده اند. فایل های سورس نسخه 1.3.2 نیز با copyright سال ۲۰۱۳ منتشر شدهاند.

مخزن رسمی: DrKLO/Telegram.

پس اگر فقط جواب سریع را می خواهی و حوصله شیرجه فنی نداری:

• iOS اولیه: Objective-C
• Android اولیه: Java
• پروتکل ارتباطی: MTProto
• بکاند/سرور: کد عمومی نیست و زبان دقیق production backend به صورت رسمی مستند نشده است

و اما آن خط آخر مهم تر از چیزی است که به نظر می رسد. در اینترنت زیاد می بینید که با قطعیت گفته می شود «سرور تلگرام با C++ نوشته شده» یا ترکیبی از چند زبان خاص است. ممکن است بخشی از اجزای واقعی چنین باشد، اما چون Telegram server-side code را منتشر نکرده، نباید یک ادعای بدون سند رسمی را به عنوان واقعیت قطعی تکرار کرد.

---

<a id="mtproto-origin"></a>

اصلاً چه کسی MTProto را ساخت؟

FAQ رسمی تلگرام نقش ها را واضح تفکیک می کند: Pavel Durov پشتیبانی مالی و جهت گیری پروژه را برعهده داشت و Nikolai Durov ورودی فنی اصلی را ارائه کرد و پروتکل داده های سفارشی تلگرام را طراحی کرد.

خیلی ها MTProto را با «رمزنگاری تلگرام» یکی می دانند. نه :) داستان خیلی بزرگ تر از این حرف هاست. این پروتکل چند مسئله را هم زمان حل می کند:

• تبدیل درخواست های و پاسخ های API به پیام های باینری
• مدیریت session
• authorization و ساخت کلید
• رمزنگاری client-server
• شمارهگذاری و acknowledgment پیام ها
• بستهبندی چند پیام در container
• انتقال روی TCP، HTTP، HTTPS و WebSocket
• تحمل بهتر قطع و وصل شدن شبکه
• کار با چند دیتا سنتر

پس بهتر است MTProto را یک protocol stack بین کلاینت و Telegram API ببینیم، نه یک الگوریتم رمزنگاری که فقط آمده باشد پیام هایمان را قفل کند.

مستندات رسمی MTProto

---

<a id="architecture"></a>

زیر این برنامه دقیقاً چه شکلی است؟

اگر خیلی از بالا نگاه کنیم، تقریباً با این شکلی طرفیم. البته نسخه واقعی خیلی شلوغ تر است :)

+---------------------------+
| Telegram Client           |
| iOS / Android / Desktop   |
+-------------+-------------+
              |
              | Telegram API / RPC
              | TL serialization
              | MTProto encryption
              | TCP / HTTP / HTTPS / WS
              v
+-------------+-------------+
| Telegram Data Center (DC) |
+-------------+-------------+
              |
              +--> account/session state
              +--> cloud chat data
              +--> media/file infrastructure
              +--> routing to other DCs/services

در مستندات رسمی، MTProto سه بخش تقریباً مستقل دارد:

1. High-level component برای queryها و responseهای API
2. Cryptographic/authorization layer برای authorization و رمزنگاری
3. Transport component برای انتقال داده روی پروتکل های شبکه موجود

مستند رسمی Telegram اشاره می کند که transport می تواند روی TCP، HTTP، HTTPS، WebSocket و WebSocket Secure قرار بگیرد.

این جداسازی اتفاقاً یکی از بخش های باحال معماری است: منطق API و session به یک اتصال TCP خاص گره نخورده است.

MTProto Mobile Protocol

---

<a id="what-is-mtproto"></a>

خب، MTProto دقیقاً دارد چه کار می کند؟

یک درخواست ساده را اگر خیلی خلاصه کنیم، تقریباً از این مسیر رد می شود:

API call
  -> TL serialization
  -> MTProto message
  -> session metadata
  -> encryption
  -> MTProto transport framing
  -> TCP/HTTP/HTTPS/WebSocket
  -> Telegram DC

پیام فقط «سلام داداش» نیست

برای MTProto، پیام یک ساختار باینری است. در مستندات پروتکل، هر پیام شامل مفاهیمی مانند موارد زیر است:

• msg_id
• msg_seqno
• طول پیام
• بدنه پیام
• session
• server salt
• authorization key identifier
• message key

این metadata برای قشنگی آنجا نیست. واقعاً کار می کند. msg_id و msg_seqno برای ordering، acknowledgment و جلوگیری از برخی replay scenarioها نقش دارند.

MTProto 1.0 در برابر MTProto 2.0

تلگرام ابتدا با MTProto 1.0 کار می کرد. نسخه 2.0 بعداً تغییراتی در derivation کلید و message key ایجاد کرد؛ از جمله استفاده از SHA-256 به جای SHA-1 برای بخش اصلی msg_key و وارد کردن padding در محاسبه.

امروز مستندات Telegram، MTProto 1.0 را deprecated می دانند.

MTProto 2.0 Detailed Description

---

<a id="handshake"></a>

جایی که تلگرام و کلاینت باید به هم اعتماد کنند

قبل از اینکه پیام های عادی شروع کنند به رفت و آمد، کلاینت باید با سرور یک Authorization Key بسازد. یعنی باید سر یک راز مشترک توافق کنند، بدون اینکه آن راز را وسط اینترنت داد بزنند.

Telegram این کلید را یک مقدار 2048-bit مشترک میان کلاینت و سرور توصیف می کند که از طریق فرایند Diffie-Hellman ایجاد می شود و خود کلید به صورت مستقیم روی شبکه ارسال نمی شود.

نسخه خیلی ساده شده handshake این شکلی است. خود پروتکل البته سه تا فلش نیست که تمام شود :)

sequenceDiagram
    participant C as Telegram Client
    participant S as Telegram DC

    C->>S: req_pq_multi + nonce
    S-->>C: resPQ + server_nonce + pq + RSA fingerprints
    C->>C: factor pq -> p, q
    C->>S: req_DH_params (RSA protected)
    S-->>C: server_DH_params_ok
    C->>C: verify DH params and generate b
    C->>S: set_client_DH_params (g_b)
    S-->>C: dh_gen_ok
    C->>C: auth_key established

مرحله اول: req_pq_multi

کلاینت یک nonce تصادفی می سازد و req_pq_multi را می فرستد.

مرحله دوم: resPQ

سرور pq، یک server_nonce و fingerprint کلید های RSA سرور را بر می گرداند.

مرحله سوم: factor کردن pq

کلاینت pq را به دو عدد اول p و q تجزیه می کند. این مرحله بخشی از فرایند شروع ارتباطه.

مرحله چهارم: احراز سرور و پارامتر های DH

کلاینت داده های موردنیاز را با public key سرور محافظت می کند و req_DH_params را می فرستد. سپس سرور پارامتر های Diffie-Hellman را بر می گرداند.

مرحله پنجم: ساخت auth_key

کلاینت مقدار تصادفی خودش را می سازد، g_b را ارسال می کند و در نهایت هر دو سمت به یک auth_key مشترک میرسند.

جزئیات واقعی این مرحله خیلی بیشتر از این خلاصه ای است و شامل nonceها، hashها، بررسی safe prime و کنترل های امنیتی دیگر می شود.

منبع رسمی و مرحله به مرحله: Creating an Authorization Key.

---

<a id="message-flow"></a>

وقتی Send را میزنیم چه اتفاقی می افتد؟

بعد از ساخته شدن authorization key، مسیر تقریبی یک پیام در Cloud Chat را می توان اینطور دید:

1. User taps Send
2. Client builds an API/RPC object
3. Object is serialized using TL
4. MTProto adds session/message metadata
5. msg_key is calculated
6. AES key and IV are derived
7. Payload is encrypted
8. MTProto transport header is added
9. Packet travels to a Telegram data center
10. Server processes the RPC
11. Ack/update/response returns to the client
12. Other logged-in devices receive cloud updates

طبق مستندات رسمی MTProto 2.0، auth_key و msg_key برای تولید کلید AES و IV استفاده می شوند و بخش رمزگذاری شده با AES-256-IGE پردازش می شود.

نکته مهم: این توضیح مربوط به client-server encryption برای Cloud Chat است. Secret Chat یک لایه end-to-end جداگانه دارد.

جزئیات رمزنگاری MTProto 2.0

---

<a id="cloud-vs-secret"></a>

Cloud Chat و Secret Chat؛ یک اپ، دو ایده کاملاً متفاوت

این یکی از مهم ترین بخش های معماری Telegram است و یکی از رایج ترین سوءبرداشتها نیز همینجاست.

Cloud Chat

چتهای معمول Telegram، Cloud Chat هستند. هدف این مدل این است که پیام ها میان دستگاه های شما sync شوند و بتوانید از چند موبایل، لپتاپ یا دسکتاپ به تاریخچه دسترسی داشته باشید.

در این مدل، ارتباط client-server با MTProto رمزگذاری می شود؛ اما مدل آن همان end-to-end encryption اختصاصی Secret Chat نیست.

مزیت معماری Cloud Chat:

• sync چند دستگاهی
• دسترسی به history از دستگاه جدید
• مدیریت مرکزی پیام ها و فایل ها
• تجربه یکپارچه بین موبایل و دسکتاپ

Secret Chat

Secret Chat برای ارتباط one-to-one end-to-end encrypted طراحی شده است. طبق مستند رسمی، کلید Secret Chat فقط نزد شرکت کنندگان چت قرار دارد و schema رمزنگاری آن با Cloud Chat متفاوت است.

پیام های Secret Chat به صورت cloud history معمولی بین همه دستگاهها sync نمی شوند.

Secret Chats — End-to-End Encryption

پس آیا «تمام تلگرام E2EE است»؟

خیر. عبارت دقیق تر این است:

Telegram برای Cloud Chats از رمزنگاری client-server مبتنی بر MTProto استفاده می کند و برای Secret Chats یک لایه end-to-end encryption جداگانه دارد.

این تفاوت برای هر تحلیل فنی یا امنیتی Telegram حیاتی است.

---

<a id="datacenters"></a>

دیتا سنترها و چند دستگاهی بودن

Telegram از یک سرور واحد تشکیل نشده است. مستندات API می گویند سرورها به چند Data Center یا DC در بخش های مختلف جهان تقسیم شدهاند.

کلاینت از طریق config می تواند endpointهای دیتا سنترها را دریافت کند. IP و portها نیز ممکن است بر اساس load و موقعیت کاربر تغییر کنند.

این معماری چند نتیجه مهم دارد:

1. نزدیک شدن مسیر شبکه به کاربر

وجود چند DC می تواند latency را کاهش دهد و routing را انعطافپذیرتر کند.

2. جدا کردن session از یک socket مشخص

در MTProto، session به application instance متصل است، نه لزوماً یک اتصال TCP خاص. بنابراین reconnect شدن شبکه به معنی از بین رفتن کامل session نیست.

3. Cloud synchronization

چون Cloud Chat در سمت سرویس نگهداری می شود، دستگاه های مختلف می توانند updateهای مربوط به همان حساب را دریافت کنند.

4. media routing

Telegram برای فایل و media نیز رفتار و DCهای مرتبط دارد؛ مستندات API حتی حالت های media/CDN را در تنظیمات دیتا سنتر توضیح میدهند.

Working with Different Data Centers

Uploading and Downloading Files

---

<a id="tl"></a>

TL؛ زبان عجیب غریبی که تلگرام برای توصیف داده ها دارد

یکی از بخش هایی که کمتر درباره آن صحبت می شود TL یا Type Language است.

TL زبانی برای توصیف type ها، constructorها و function های API است. به زبان ساده، Telegram باید راه استاندارد و بسیار فشرده ای داشته باشد تا بگوید:

«این بایتها یک User هستند»،

«این بایتها یک Vector از پیام ها هستند»،

یا «این درخواست، فلان RPC method را صدا میزند».

نمونه مفهومی:

user id:int first_name:string last_name:string = User;
getUsers (Vector int) = Vector User;

سپس این ساختارها به binary serialization تبدیل می شوند.

چرا این مهم است؟ چون Telegram به جای وابستگی به JSON متنی برای لایه اصلی پروتکل، ساختاری دارد که برای پیام های باینری، type های مشخص و RPC های قابل تولید مناسب است.

TL Language — Telegram Core

---

<a id="why-custom"></a>

اصلاً چرا تلگرام رفت سراغ پروتکل اختصاصی؟

طبق توضیح Telegram، پروتکل باید برای شرایط موبایل، چند دیتا سنتر و شبکه های متفاوت بهینه می بود. به همین دلیل MTProto فقط یک الگوریتم رمزنگاری نیست؛ transport، session، RPC و authorization را کنار هم قرار می دهد.

از دید مهندسی، مزیت این تصمیم مشخص است: Telegram کنترل کامل روی protocol stack خودش دارد و می تواند رفتار آن را با نیازهای سرویس هماهنگ کند.

اما از دید امنیت نیز این تصمیم همیشه محل بحث بوده است. طراحی cryptographic protocol اختصاصی معمولاً scrutiny زیادی ایجاد می کند، چون جامعه امنیتی ترجیح می دهد primitive ها و protocol های استاندارد و بارها بررسی شده استفاده شوند.

یک تحلیل دانشگاهی از MTProto 2.0 با ابزار ProVerif بسیاری از ویژگی های امنیتی مورد بررسی را formally تأیید کرد، اما هم زمان یک مسئله unknown key-share در پروتکل rekeying گزارش داد. این مثال خوبی است از اینکه «امنیت» یک برچسب صفر و یک نیست و protocol ها باید دائماً تحلیل شوند.

مقاله: Automated Symbolic Verification of Telegram's MTProto 2.0

---

<a id="swift"></a>

بعدش iOS از Objective-C رفت سمت Swift

در ۲۰۱۸ Telegram اعلام کرد که چند سال در حال بازنویسی کامل کلاینت iOS با Swift بوده است. نسخه Telegram 5.0 برای iOS نتیجه این بازنویسی بود.

این تغییر فقط تعویض syntax نبود. بازنویسی یک کلاینت messaging بزرگ یعنی بازسازی یا انتقال بخش های مهمی مانند:

• state management
• rendering و UI
• local cache/database
• network integration
• media pipeline
• background behavior
• synchronization
• performance optimization

مخزن فعلی iOS نیز ترکیبی از Swift، C، Objective-C و C++ دارد، اما نسل جدید اپ به طور عمده حول Swift ساخته شده است.

Telegram iOS Source Code

Introducing Telegram 5.0 for iOS

---

<a id="unknowns"></a>

اینجا باید بگوییم «نمی دانیم»

اینجا باید بین open protocol و open-source backend تفاوت بگذاریم.

Telegram کلاینت های خود را open source کرده و API و MTProto را مستند کرده است؛ اما server-side code را منتشر نکرده است.

FAQ رسمی تلگرام صراحتاً به همین سؤال پاسخ می دهد و می گوید کد سرور عمومی نیست. همچنین معماری Telegram در حال حاضر federation را به شکلی که هرکس cloud مستقل خودش را اجرا کند، پشتیبانی نمی کند.

پس ما می توانیم با اطمینان درباره این موارد صحبت کنیم:

• فرمت و ساختار MTProto
• authorization key generation
• TL serialization
• API behavior
• کلاینت های متن باز
• نحوه کار با DCها از دید client
• تفاوت Cloud و Secret Chat

اما نمی توانیم فقط از روی سورس کلاینت نتیجه بگیریم که production backend دقیقا با چه زبانها، database های یا topology داخلی اجرا می شود.

هر مقالهای که بدون منبع اولیه «stack کامل سرور Telegram» را با قطعیت فهرست می کند، باید با احتیاط خوانده شود.

Telegram FAQ — Server-side code

---

<a id="security"></a>

چند چیزی که درباره امنیت تلگرام زیاد اشتباه گفته می شود

«تلگرام open source است، پس کل زیرساختش open source است»

نه. کلاینت ها open source هستند؛ server-side code عمومی نیست.

«تمام پیام های تلگرام end-to-end encrypted هستند»

نه. Secret Chat، E2EE است. Cloud Chat مدل متفاوتی دارد و با encryption بین client و server کار می کند.

«MTProto فقط یک الگوریتم رمزنگاری است»

نه. MTProto علاوه بر cryptography، session، RPC، serialization، message handling و transport را هم پوشش می دهد.

«چون iOS امروز Swift است، نسخه اول هم Swift بوده»

غلط است. Swift در سال ۲۰۱۴ معرفی شد و Telegram نیز رسماً گفته کلاینت قدیمی iOS با Objective-C ساخته شده بود.

«از GitHub کلاینت می توان backend را بازسازی کرد»

خیر. سورس کلاینت نحوه صحبت کردن با API را نشان می دهد، نه implementation واقعی cloud و backend داخلی Telegram.

---

<a id="conclusion"></a>

پس جواب واقعی چیست؟

اگر بخوام کل ماجرا رو خیلی خلاصه جمع کنم:

Telegram در سال ۲۰۱۳ با کلاینت iOS مبتنی بر Objective-C شروع شد و اندکی بعد کلاینت Android مبتنی بر Java منتشر شد. هسته ارتباطی آن از همان ابتدا MTProto بود؛ پروتکلی طراحیشده توسط Nikolai Durov برای ارتباط سریع، session-based و رمزگذاری شده با زیرساخت چند دیتا سنتری.

در MTProto، داده API با TL به فرمت باینری تبدیل می شود، client با server یک authorization key می سازد، پیام ها session و identifier دارند و transport می تواند روی چند پروتکل شبکه قرار بگیرد.

اما مهم ترین نکته شاید این باشد: Telegram دو مدل چت متفاوت دارد. Cloud Chat برای sync و دسترسی چند دستگاهی طراحی شده و Secret Chat برای end-to-end encryption یک به یک.

و درباره backend؟ چیزی که مستند داریم، protocol و API و چیزهایی است که از سمت client قابل دیدن است. کد واقعی server-side Telegram عمومی نیست؛ بنابراین تحلیل فنی خوب باید دقیقا همانجایی که سند تمام می شود، ادعای قطعی را هم متوقف کند.

---

<a id="faq"></a>

سوال هایی که احتمالاً هنوز داری درباره تاریخچه و معماری تلگرام

تلگرام در چه سالی ساخته شد؟

Telegram برای iOS در ۱۴ اوت ۲۰۱۳ منتشر شد. نسخه اولیه رسمی Android در ۲۰ اکتبر ۲۰۱۳ عرضه شد.

نسخه اولیه Telegram با چه زبانی نوشته شد؟

کلاینت اولیه iOS با Objective-C ساخته شده بود. سورس های اولیه Android نیز Java-based هستند. درباره زبان دقیق production backend تلگرام اطلاعات رسمی کاملی منتشر نشده است.

MTProto چیست؟

MTProto پروتکل ارتباطی Telegram برای API، session، authorization، encryption و transport است. این پروتکل فقط یک الگوریتم رمزنگاری نیست.

آیا Telegram از AES استفاده می کند؟

در MTProto 2.0، Telegram برای رمزنگاری بخش client-server از AES-256-IGE در چارچوب مشخص شده در پروتکل استفاده می کند.

آیا همه چتهای تلگرام end-to-end encrypted هستند؟

خیر. Secret Chats به صورت end-to-end encrypted طراحی شدهاند. Cloud Chats از مدل client-server encryption استفاده می کنند تا cloud synchronization و multi-device access ممکن باشد.

آیا سرور Telegram متن باز است؟

خیر. کلاینت ها متن باز هستند و protocol/API مستند شدهاند، اما server-side code تلگرام عمومی نیست.

Telegram چگونه روی چند دستگاه sync می شود؟

Cloud Chats در زیرساخت cloud Telegram نگهداری می شوند و sessionهای دستگاه های مختلف می توانند updateهای همان حساب را دریافت کنند.

TL در Telegram چیست؟

TL یا Type Language سیستم توصیف type ها، constructorها و RPC function های Telegram است که برای binary serialization در پروتکل استفاده می شود.

---

<a id="sources"></a>

منابع

منابع رسمی Telegram

1. Telegram FAQ
2. A (Not So) Brief History of Telegram
3. MTProto Mobile Protocol
4. MTProto 2.0 — Detailed Description
5. Creating an Authorization Key
6. TL Language
7. Secret Chats — End-to-End Encryption
8. Working with Different Data Centers
9. Uploading and Downloading Files
10. Telegram APIs and TDLib
11. Introducing Telegram 5.0 for iOS
12. Telegram X: Progress through Competition
13. Telegram iOS Source Code
14. Telegram Android Source Code

منابع مستقل و تاریخی

15. TechCrunch — Meet Telegram, A Secure Messaging App From The Founders Of VK
16. Miculan & Vitacolonna — Automated Symbolic Verification of Telegram's MTProto 2.0

---