협약
기술적으로 소질이 있는 분들을 위한 FAQ를 자유롭게 확인해 보세요. 클라이언트 개발자는 보안 지침을 준수해야 합니다.
관련 링크
이 페이지는 클라우드 채팅(서버-클라이언트 암호화)에 사용되는 MTProto 암호화의 기본 레이어에 대해 다룹니다. 또한 참조:
간략한 구성 요소 요약
고수준 컴포넌트의 관점에서 클라이언트와 서버는 세션 내에서 메시지를 교환합니다. 세션은 특정 WebSocket/http/https/tcp 연결이 아닌 클라이언트 장치(보다 정확하게는 애플리케이션)에 연결됩니다. 또한 각 세션은 사용자 키 ID에 연결되며, 이 ID를 통해 실제 인증이 수행됩니다.
여러 개의 서버 연결이 열려 있을 수 있으며, 메시지는 연결 중 어느 하나를 통해 양방향으로 전송될 수 있습니다(질의에 대한 응답이 반드시 동일한 연결을 통해 반환되는 것은 아니지만, 대부분의 경우 그러합니다; 그러나 다른 세션에 속한 연결을 통해 메시지를 반환하는 경우는 없습니다). UDP 프로토콜을 사용할 경우, 응답은 질의가 전송된 IP 주소와 다른 주소에서 반환될 수 있습니다.
메시지에는 여러 유형이 있습니다:
RPC 호출 (클라이언트에서 서버로): API 메서드 호출
RPC 응답 (서버에서 클라이언트로): RPC 호출 결과
메시지 수신 확인 (혹은 오히려, 메시지 세트의 상태 통지)
메시지 상태 조회
멀티파트 메시지 또는 컨테이너(여러 메시지를 포함하는 컨테이너; 예를 들어 HTTP 연결을 통해 여러 RPC 호출을 한 번에 보낼 때 필요; 또한 컨테이너는 gzip을 지원할 수 있음).
하위 프로토콜의 관점에서 메시지는 4바이트 또는 16바이트 경계에 정렬된 이진 데이터 스트림입니다. 메시지의 첫 몇 필드는 고정되어 있으며 암호화/인증 시스템에 사용됩니다.
각 메시지는 개별적으로 또는 컨테이너 내에 포함되어 있으며, 메시지 식별자(64비트, 아래 참조), 세션 내 메시지 시퀀스 번호(32비트), 메시지 바디 길이(바이트 단위; 32비트), 그리고 바디(4바이트의 배수 크기 가능)로 구성됩니다. 또한, 컨테이너 또는 개별 메시지를 전송할 때, 상단에 내부 헤더가 추가된 후(아래 참조) 전체 메시지가 암호화되고, 메시지 상단에 외부 헤더(64비트 키 식별자 및 128비트 메시지 키)가 배치됩니다.
메시지 바디는 일반적으로 32비트 메시지 유형과 유형에 따라 결정되는 매개변수로 구성됩니다. 특히 각 RPC 함수에는 해당하는 메시지 유형이 있습니다. 자세한 내용은 이진 데이터 직렬화, 모바일 프로토콜: 서비스 메시지를 참조하십시오.
모든 숫자는 리틀 엔디안 방식으로 작성됩니다. 그러나 RSA 및 DH에서 사용되는 매우 큰 숫자(2048비트 또는 pq, p, q 매개변수)는 OpenSSL 라이브러리가 이를 사용하는 방식이 비그 엔디안 형식이기 때문에 비그 엔디안 형식으로 작성됩니다.
일반적인 설명
프로토콜은 모바일 기기에서 실행되는 애플리케이션으로부터 서버 API에 접근하기 위해 설계되었습니다. 웹 브라우저가 그러한 애플리케이션이 아니라는 점을 강조해야 합니다.
프로토콜은 세 개의 거의 독립적인 구성 요소로 세분화됩니다:
고수준 컴포넌트(API 쿼리 언어): API 쿼리와 응답이 이진 메시지로 변환되는 방법을 정의합니다.
암호화 (권한 부여) 계층: 전송 프로토콜을 통해 전송되기 전에 메시지가 암호화되는 방법을 정의합니다.
Transport 컴포넌트: 클라이언트와 서버가 HTTP, HTTPS, WS(일반 WebSockets), WSS(HTTPS를 통한 WebSockets), TCP, UDP와 같은 기존 네트워크 프로토콜을 통해 메시지를 전송하는 방법을 정의합니다.
4.6 버전부터 주요 텔레그램 클라이언트는 이 글에서 설명한 MTProto 2.0을 사용하고 있습니다.
MTProto v1.0(여기서 참고로 설명함)은 더 이상 사용되지 않으며 현재 단계적으로 폐기 중입니다.