최근 Telegram이 얼마나 좋은지, Durov 형제가 네트워크 시스템을 구축하는 데 얼마나 훌륭하고 경험이 있는지 등에 대한 게시물이 Habré에 더 자주 나타나기 시작했습니다. 동시에 기술 장치에 실제로 몰두한 사람은 거의 없었습니다. 기껏해야 상당히 간단한(그리고 MTProto와 매우 다른) JSON 기반 봇 API를 사용하고 일반적으로 그냥 수락합니다. 믿음으로 메신저를 중심으로 돌아가는 모든 칭찬과 PR. 거의 XNUMX년 반 전에 NPO Echelon Vasily의 동료(불행히도 Habré에 대한 그의 계정은 초안과 함께 삭제됨)가 처음부터 Perl로 자신의 Telegram 클라이언트를 작성하기 시작했고 나중에 이 라인의 작성자가 합류했습니다. 왜 Perl입니까? 일부는 즉시 묻습니다. 이미 다른 언어로 그러한 프로젝트가 있기 때문에 사실 이것이 요점이 아니라 다른 언어가 있을 수 있습니다. 완성된 도서관, 따라서 저자는 끝까지 가야합니다 처음부터. 또한 암호화는 신뢰하지만 확인하는 것입니다. 보안에 중점을 둔 제품을 사용하면 공급업체의 기성품 라이브러리에 의존하고 맹목적으로 믿을 수는 없습니다(그러나 이것은 두 번째 부분에서 더 자세히 다룰 주제입니다). 현재 라이브러리는 "중간" 수준에서 매우 잘 작동합니다(모든 API 요청을 할 수 있음).

그러나 이 게시물 시리즈에는 암호화와 수학이 많지 않을 것입니다. 그러나 다른 많은 기술적 세부 사항과 건축학적 목발이 있을 것입니다(처음부터 작성하지는 않지만 어떤 언어로든 라이브러리를 사용하려는 사람들에게도 유용할 것입니다). 따라서 주요 목표는 처음부터 클라이언트를 구현하는 것이었습니다. 공식 문서에 따르면. 즉, 공식 클라이언트의 소스 코드가 닫혀 있다고 가정합니다. 일이 그래서) 그러나 예를 들어 예전과 같이 RFC와 같은 표준이 있습니다. 공식 (Telegram Desktop, 모바일 ), 심지어 비공식 Telethon?

목차 :

• 문서 ... 거기에 있습니까? 사실인가요?..
• 젊은 작가로서 어디에서 시작합니까?
• 이진 직렬화: TL(유형 언어) 및 그 체계, 계층 및 기타 많은 무서운 단어
  • 공식 문서를 읽고 싶지 않은 사람들을 위한 TL 구문의 하위 집합에 대한 간략한 설명
  • 추론할 수 없는 벡터
  • 코드의 기존 TL 구현
  • 유형 언어의 유형 부족
  • 버전 관리. 레이어
• MT프로토
  • 전송 계층
  • 키, 메시지, 세션, Diffie-Hellman
  • 메시지 메시지, msg_id, msg_seqno, 승인, 잘못된 방향의 핑 및 기타 특이성
    • RPC: 요청, 응답, 오류. 확인.
    • 중독: 메시지 게시물 상태
    • 핑과 타이밍. 대기열.
    • 어떻게 설계했어야 할까요?
• API?
• 계속!

문서 ... 거기에 있습니까? 사실인가요?..

이 기사에 대한 메모의 일부는 지난 여름에 수집되기 시작했습니다. 그동안 공식 사이트에서 https://core.telegram.org 문서는 Layer 23, 즉 2014년 어딘가에 멈췄습니다(그 당시에는 아직 채널조차 없었습니까?). 물론 이론상으로는 2014년 당시의 기능으로 클라이언트 구현이 가능했을 것이다. 그러나이 상태에서도 문서는 첫째로 불완전했고 둘째로 모순되는 부분이있었습니다. 한 달여 전인 2019년 XNUMX월, 실수로 이 사이트에는 완전히 새로운 Layer 105에 대한 문서의 대규모 업데이트가 있으며 이제 모든 것을 다시 읽어야 한다는 메모가 있는 것으로 나타났습니다. 실제로 많은 기사가 수정되었지만 많은 기사가 변경되지 않았습니다. 따라서 문서에 대한 아래의 비판을 읽을 때 이러한 항목 중 일부는 더 이상 관련이 없지만 일부는 여전히 상당히 중요하다는 점을 염두에 두어야 합니다. 결국, 현대 사회에서 5년은 단지 많은 것이 아니라 대단히 많은. 그 이후로(특히 그 이후로 폐기 및 부활한 지오챗을 고려하지 않은 경우) 체계의 API 메서드 수가 XNUMX개에서 XNUMX개 이상으로 증가했습니다!

젊은 작가로서 어디에서 시작합니까?

예를 들어 다음과 같은 기성품 라이브러리를 처음부터 작성하거나 사용하는 것은 중요하지 않습니다. 파이썬용 텔레톤 또는 PHP용 매들린, 어쨌든 먼저 필요합니다 애플리케이션 등록 - 매개변수 가져오기 api_id и api_hash (VKontakte API로 작업한 사람들은 즉시 이해합니다) 서버가 애플리케이션을 식별합니다. 이것 ~해야 해. 법적인 이유로 인해 도서관 저자가 출판할 수 없는 이유에 대해서는 두 번째 부분에서 더 자세히 이야기하겠습니다. 매우 제한적이지만 테스트 값에 만족할 수 있습니다. 사실 이제 번호로 등록할 수 있습니다. 오직 하나 응용 프로그램이므로 서두르지 마십시오.

이제 기술적인 관점에서 우리는 등록 후 문서, 프로토콜 등에 대한 업데이트에 대한 Telegram의 알림을 받아야 한다는 사실에 관심을 가져야 했습니다. 즉, 도크가있는 사이트는 단순히 "점수"가 지정되었고 클라이언트를 만들기 시작한 사람들과 특별히 계속 작업했다고 가정 할 수 있습니다. 더 쉽습니다. 그러나 아니요, 그런 것은 관찰되지 않았고 정보도 없었습니다.

그리고 처음부터 작성하는 경우 수신된 매개변수의 사용은 실제로 아직 멀었습니다. 하지만 https://core.telegram.org/ 시작하기에서 먼저 설명합니다. 실제로 먼저 구현해야 합니다. MTProto 프로토콜 - 그러나 당신이 믿는다면 OSI 모델에 따른 레이아웃 프로토콜에 대한 일반적인 설명 페이지 끝에서 완전히 헛된 것입니다.

실제로 MTProto 이전과 이후에 한 번에 여러 수준에서 (OS 커널에서 작업하는 외국 네트워크 사용자가 레이어 위반이라고 말함) 크고 고통스럽고 끔찍한 주제가 방해가 될 것입니다 ...

이진 직렬화: TL(유형 언어) 및 그 체계, 계층 및 기타 많은 무서운 단어

사실 이 주제가 텔레그램 문제의 핵심이다. 그리고 파헤쳐 보면 끔찍한 단어가 많이있을 것입니다.

그래서 계획. 이 단어가 생각난다면 이렇게 말해보세요. JSON 스키마당신은 옳다고 생각했습니다. 목표는 동일합니다. 가능한 전송 데이터 세트를 설명하는 언어입니다. 사실 이것은 유사성이 끝나는 곳입니다. 페이지에서 MTProto 프로토콜, 또는 공식 클라이언트의 소스 트리에서 일부 구성표를 열려고 시도하면 다음과 같은 내용이 표시됩니다.

int ? = Int;
long ? = Long;
double ? = Double;
string ? = String;

vector#1cb5c415 {t:Type} # [ t ] = Vector t;

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

rpc_answer_unknown#5e2ad36e = RpcDropAnswer;
rpc_answer_dropped_running#cd78e586 = RpcDropAnswer;
rpc_answer_dropped#a43ad8b7 msg_id:long seq_no:int bytes:int = RpcDropAnswer;

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

---functions---

set_client_DH_params#f5045f1f nonce:int128 server_nonce:int128 encrypted_data:bytes = Set_client_DH_params_answer;

ping#7abe77ec ping_id:long = Pong;
ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

invokeAfterMsg#cb9f372d msg_id:long query:!X = X;
invokeAfterMsgs#3dc4b4f0 msg_ids:Vector<long> query:!X = X;

account.updateProfile#78515775 flags:# first_name:flags.0?string last_name:flags.1?string about:flags.2?string = User;
account.sendChangePhoneCode#8e57deb flags:# allow_flashcall:flags.0?true phone_number:string current_number:flags.0?Bool = auth.SentCode;

이것을 처음 보는 사람은 쓰여진 내용의 일부만 직관적으로 인식할 것입니다. 유형은 콜론을 통과합니다 ... 아마도. 여기서 꺾쇠괄호 안에는 아마도 C++에서와 같은 템플릿이 있을 것입니다(사실, 별로). 그리고 다른 모든 기호는 무엇을 의미합니까? 물음표, 느낌표, 백분율, 격자(그리고 분명히 그것들은 다른 장소에서 다른 것을 의미합니다), 어딘가에 존재하지만 어딘가에는 존재하지 않는 XNUMX진수 - 그리고 가장 중요한 것은 여기서 얻는 방법입니다. 올바른 (서버에서 거부되지 않음) 바이트 스트림? 설명서를 읽어야 합니다. (예, 근처에 JSON 버전의 스키마에 대한 링크가 있지만 더 명확하지는 않습니다.).

페이지 열기 이진 데이터 직렬화 그리고 4학년의 마탄과 비슷한 버섯과 이산 수학의 마법의 세계로 뛰어드세요. 알파벳, 유형, 값, 결합자, 기능적 결합자, 일반 형식, 복합 유형, 다형성 유형... 그리고 그것은 첫 페이지에 불과합니다! 다음이 당신을 기다립니다 TL 언어, 이미 사소한 요청 및 응답의 예가 포함되어 있지만 더 일반적인 경우에 대한 답변을 전혀 제공하지 않습니다. 즉, 러시아어에서 영어로 번역된 수학을 XNUMX개의 중첩된 페이지!

기능적 언어와 자동 유형 추론에 익숙한 독자는 물론이 언어 설명에서 훨씬 더 친숙한 예를 보았고 일반적으로 이것이 원칙적으로 나쁘지 않다고 말할 수 있습니다. 이에 대한 반대 의견은 다음과 같습니다.

• 예, 골 좋게 들리지만 아아 달성되지 않은
• 러시아 대학의 교육은 IT 전문 분야에 따라 다릅니다. 모든 사람이 해당 과정을 읽는 것은 아닙니다.
• 마지막으로 우리가 보게 될 것처럼 실제로는 필요 없음, 설명된 TL의 제한된 하위 집합만 사용되기 때문에

내가 말했듯이 레오너드 채널에서 #perl FreeNode IRC 네트워크에서 Telegram에서 Matrix로 게이트를 구현하려고 시도합니다(따옴표의 번역이 메모리에서 정확하지 않음).

처음으로 유형 이론을 접한 사람이 신이 나서 그것을 가지고 놀기 시작했지만 실제로 필요한지 여부는 신경 쓰지 않는 것 같습니다.

기본적인 유형(int, long 등)의 필요성이 질문을 제기하지 않는지 직접 확인하십시오. 결국에는 수동으로 구현해야 합니다. 벡터. 즉, 사실 정렬, 결과를 적절한 이름으로 부르는 경우.

하지만 전에

공식 문서를 읽지 않는 사람들을 위한 TL 구문의 하위 집합에 대한 간략한 설명

constructor = Type;
myVec ids:Vector<long> = Type;

fixed#abcdef34 id:int = Type2;

fixedVec set:Vector<Type2> = FixedVec;

constructorOne#crc32 field1:int = PolymorType;
constructorTwo#2crc32 field_a:long field_b:Type3 field_c:int = PolymorType;
constructorThree#deadcrc bit_flags_of_what_really_present:# optional_field4:bit_flags_of_what_really_present.1?Type = PolymorType;

an_id#12abcd34 id:int = Type3;
a_null#6789cdef = Type3;

항상 정의 시작 디자이너, 그 후 선택적으로 (실제로는 항상) 기호를 통해 # 해야 CRC32 주어진 유형의 정규화된 설명 문자열에서. 다음은 필드에 대한 설명입니다. 해당하는 경우 유형이 비어 있을 수 있습니다. 그것은 모두 주어진 생성자, 즉 하위 유형이 속한 유형의 이름 인 등호로 끝납니다. 등호 오른쪽에 있는 유형은 다음과 같습니다. 다형성 - 즉, 여러 특정 유형에 해당할 수 있습니다.

줄 뒤에 정의가 나오는 경우 ---functions---, 그러면 구문은 동일하게 유지되지만 의미는 달라집니다. 생성자는 RPC 함수의 이름이 되고 필드는 매개 변수가 됩니다(즉, 아래 설명된 것과 정확히 동일한 구조로 유지됩니다. 그것은 단지 주어진 의미일 것입니다), "다형성 유형 '은 반환된 결과의 유형입니다. 사실, 그것은 여전히 ​​다형성으로 남아있을 것입니다 - 섹션에서 정의된 것입니다. ---types---, 이 생성자는 고려되지 않습니다. 인수로 호출된 함수의 유형 오버로드, 즉 어떤 이유로 C++에서와 같이 이름은 같지만 서명이 다른 여러 함수가 TL에서 제공되지 않습니다.

OOP가 아닌데 왜 "constructor"와 "polymorphic"인가? 글쎄, 사실 누군가가 OOP의 관점에서 생각하는 것이 더 쉬울 것입니다. 추상 클래스로서의 다형성 유형이며 생성자는 직계 자손 클래스입니다. final 여러 언어의 용어로. 물론 여기서도 사실 유사성 OO 프로그래밍 언어에서 실제 오버로드된 생성자 메서드를 사용합니다. 여기에는 데이터 구조만 있기 때문에 메소드가 없습니다(아래의 함수 및 메소드에 대한 설명은 머리에 혼란을 일으킬 수 있지만 다른 것에 관한 것입니다). 생성자를 다음과 같이 생각할 수 있습니다. 값 건설 중 바이트 스트림을 읽을 때 입력하십시오.

어떻게 이런 일이 발생합니까? 항상 4바이트를 읽는 디시리얼라이저는 값을 확인합니다. 0xcrc32 - 다음에 일어날 일을 이해합니다. field1 유형으로 int, 즉. 유형이 있는 이 위에 있는 필드에서 정확히 4바이트를 읽습니다. PolymorType 읽다. 본다 0x2crc32 두 개의 필드가 더 있다는 것을 이해합니다. long, 그래서 우리는 8 바이트를 읽습니다. 그런 다음 동일한 방식으로 역직렬화되는 복합 형식을 다시 만듭니다. 예를 들어, Type3 두 생성자가 각각 추가로 다음 중 하나를 충족해야 하는 즉시 스키마에서 선언될 수 있습니다. 0x12abcd34, 그 후에 다른 4바이트를 읽어야 합니다. int또는 0x6789cdef, 그 후에는 아무것도 없을 것입니다. 그 외 - 예외를 발생시켜야 합니다. 어쨌든 그 후에 우리는 4 바이트 읽기로 돌아갑니다. int 여백 field_c в constructorTwo 그리고 그것에 우리는 우리의 읽기를 마칩니다 PolymorType.

마지막으로 잡히면 0xdeadcrc 에 constructorThree, 그러면 상황이 더 복잡해집니다. 우리의 첫 번째 분야 bit_flags_of_what_really_present 유형으로 # - 사실 이것은 유형의 별칭일 뿐입니다. nat"자연수"를 의미합니다. 즉, 실제로 unsigned int는 실제 회로에서 unsigned 숫자가 발견되는 유일한 경우입니다. 따라서 다음은 물음표가 있는 구성입니다. 즉, 이것이 필드임을 의미합니다. 해당 비트가 참조된 필드에 설정된 경우에만 와이어에 표시됩니다(대략 삼항 연산자와 같음). 따라서 이 비트가 켜져 있다고 가정하면 다음과 같은 필드를 읽어야 합니다. Type, 이 예에서는 2개의 생성자가 있습니다. 하나는 비어 있고(식별자로만 구성됨) 다른 하나는 필드가 있습니다. ids 유형으로 ids:Vector<long>.

템플릿과 제네릭이 모두 좋거나 Java라고 생각할 수 있습니다. 하지만. 거의. 이것 단 하나의 실제 회로에서 꺾쇠 괄호의 경우이며 벡터에만 사용됩니다. 바이트 스트림에서 이는 벡터 유형 자체에 대해 4 CRC32 바이트가 되며 항상 동일하며 4바이트는 배열 요소의 수, 그 다음에는 이러한 요소 자체입니다.

여기에 직렬화가 항상 4바이트 단어로 발생하고 모든 유형이 그 배수라는 사실을 추가하십시오. 내장 유형도 설명되어 있습니다. bytes и string 길이를 수동으로 직렬화하고 이 정렬을 4로 정렬하면 정상적이고 상대적으로 효율적으로 들리는 것 같습니까? TL은 효율적인 이진 직렬화라고 주장하지만 부울 값과 단일 문자 문자열을 최대 4바이트까지 확장하면 JSON이 여전히 훨씬 두꺼워질까요? 보세요, 불필요한 필드도 비트 플래그로 건너뛸 수 있습니다.

하지만 내 간략한 설명이 아니라 전체 문서를 읽고 구현에 대해 생각한다면 아닙니다. 첫째, 생성자의 CRC32는 정규화된 스키마 텍스트 설명 문자열(여분의 공백 제거 등)에 의해 계산됩니다. 따라서 새 필드가 추가되면 유형 설명 문자열이 변경되므로 CRC32 및 직렬화가 변경됩니다. 그리고 이전 클라이언트는 새 플래그가 설정된 필드를 받았지만 다음에 무엇을 해야할지 모른다면 어떻게 할까요? ..

둘째, 기억하자 CRC32여기서 본질적으로 다음과 같이 사용됩니다. 해시 함수 어떤 유형이 (비)직렬화되고 있는지 고유하게 결정합니다. 여기서 우리는 충돌 문제에 직면해 있습니다. 아니요, 확률은 232분의 32이 아니라 훨씬 더 많습니다. CRC32가 통신 채널의 오류를 감지(및 수정)하고 그에 따라 이러한 속성을 개선하여 다른 사람에게 해를 끼치도록 설계되었다는 것을 누가 기억했습니까? 예를 들어, 그녀는 바이트의 순열에 대해 신경 쓰지 않습니다. 두 줄에서 CRC4를 계산하면 두 번째 줄에서 처음 4바이트를 다음 XNUMX바이트로 교체합니다. 동일합니다. 입력으로 라틴 알파벳의 텍스트 문자열(및 약간의 구두점)이 있고 이러한 이름이 특별히 임의적이지 않은 경우 이러한 순열의 가능성이 크게 증가합니다.

그건 그렇고, 거기에 무엇이 있는지 누가 확인 했습니까? 정말로 CRC32? 초기 소스 중 하나(Waltman 이전)에는 각 문자에 숫자 239를 곱하는 해시 함수가 있었기 때문에 이 사람들이 사랑하는 하하!

마지막으로 필드 유형이 있는 생성자가 Vector<int> и Vector<PolymorType> 다른 CRC32를 갖게 됩니다. 그리고 온라인 프레젠테이션은 어떻습니까? 그리고 이론상으로는 유형의 일부가 됩니까?? XNUMX개의 숫자 배열을 전달한다고 가정해 보겠습니다. Vector<int> 모든 것이 명확하고 길이와 또 다른 40000바이트입니다. 그리고 만약 이것이 Vector<Type2>, 단 하나의 필드로 구성 int 유형에서 유일한 것입니다. 10000xabcdef0를 34번 반복한 다음 4바이트를 반복해야 합니까? int또는 언어가 생성자에서 이를 표시할 수 있습니다. fixedVec 80000바이트 대신 40000바이트만 다시 전송하시겠습니까?

이것은 유휴 이론적 질문이 아닙니다. 각각 ID, 이름, 성을 가진 그룹 사용자 목록을 얻는다고 상상해보십시오. 모바일 연결을 통해 전송되는 데이터 양의 차이는 상당할 수 있습니다. 우리에게 광고되는 것은 Telegram 직렬화의 효율성입니다.

그래서 ...

추론할 수 없는 벡터

콤비네이터의 설명 페이지를 훑어보면 벡터(심지어 행렬도)가 정식으로 튜플을 통해 여러 시트를 추론하려고 시도하는 것을 볼 수 있습니다. 그러나 결국 그들은 두들겨 맞고 마지막 단계는 건너뛰고 벡터의 정의는 단순히 주어집니다. 이 역시 유형에 구속되지 않습니다. 무슨 일이야? 언어로 프로그래밍, 특히 기능적인 경우 구조를 재귀적으로 설명하는 것이 매우 일반적입니다. 게으른 평가를 사용하는 컴파일러는 모든 것을 이해하고 수행합니다. 언어로 데이터 직렬화 그러나 효율성이 필요합니다. 간단히 설명하는 것으로 충분합니다. 명부, 즉. 두 요소의 구조 - 첫 번째는 데이터 요소이고 두 번째는 동일한 구조 자체이거나 꼬리를 위한 빈 공간입니다(팩 (cons) 리스프에서). 그러나 이것은 분명히 요구할 것입니다 각 요소는 해당 유형을 설명하기 위해 추가로 4바이트(TL의 경우 CRC32)를 사용합니다. 배열을 설명하기 쉽습니다. 고정 크기, 그러나 이전에 길이를 알 수 없는 배열의 경우 중단합니다.

따라서 TL은 벡터 출력을 허용하지 않으므로 측면에 추가해야 했습니다. 궁극적으로 문서는 다음과 같이 말합니다.

직렬화는 항상 유형 t 변수의 특정 값에 종속되지 않는 동일한 생성자 "벡터"(const 0x1cb5c415 = crc32("벡터 t:Type # [ t ] = 벡터 t")를 사용합니다.

선택적 매개변수 t의 값은 결과 유형(역직렬화 이전에 항상 알려짐)에서 파생되기 때문에 직렬화에 포함되지 않습니다.

자세히 살펴보세요. vector {t:Type} # [ t ] = Vector t - 하지만 아무데도 정의 자체는 첫 번째 숫자가 벡터의 길이와 같아야 한다고 말하지 않습니다! 그리고 그것은 어디에서나 따르지 않습니다. 이것은 당신이 명심하고 손으로 구현해야 할 주어진 것입니다. 다른 곳에서는 문서에 유형이 가짜라고 솔직하게 언급되어 있습니다.

벡터 t 다형성 의사 유형은 값이 박스형이든 베어형이든 모든 유형 t의 값 시퀀스인 "유형"입니다.

… 그러나 그것에 집중하지 않습니다. 당신이 수학의 늘어남을 헤쳐나가는 데 지쳤을 때(아마도 대학 과정에서 당신에게 알려졌을 것입니다) 점수를 매기고 실제로 그것을 실제로 어떻게 사용하는지 지켜보기로 결정했을 때, 그 인상은 당신의 머리 속에 남아 있습니다. , 분명히 Cool People(수학자 XNUMX명 -ACM 우승자), 그리고 아무나 아닙니다. 과시하는 목표가 달성되었습니다.

그건 그렇고, 숫자에 대해. 상기하다 # 동의어입니다 nat, 자연수:

유형 표현식이 있습니다(typeexpr) 및 숫자 표현식(nat-expr). 그러나 동일한 방식으로 정의됩니다.

type-expr ::= expr
nat-expr ::= expr

그러나 문법에서는 같은 방식으로 설명됩니다. 이 차이점을 다시 기억하고 직접 구현해야 합니다.

예, 템플릿 유형(vector<int>, vector<User>) 공통 식별자(#1cb5c415), 즉. 호출이 다음과 같이 선언된 경우

users.getUsers#d91a548 id:Vector<InputUser> = Vector<User>;

그러면 단순한 벡터가 아니라 사용자의 벡터를 기다리고 있는 것입니다. 더 정확하게, 할까요 대기 - 실제 코드에서 기본 유형이 아닌 경우 각 요소에는 생성자가 있으며 구현에서 좋은 방법으로 확인해야 합니다. 이 벡터의 각 요소에 정확히 전송되었습니다. 그 유형? 그리고 배열이 다른 요소에 다른 유형을 포함할 수 있는 일종의 PHP라면?

이 시점에서 궁금해지기 시작합니다. 그러한 TL이 필요한가요? 카트의 경우 당시 이미 존재했던 것과 동일한 protobuf 인 인간 직렬 변환기를 사용할 수 있습니까? 이론이었으니 실전을 봅시다.

코드의 기존 TL 구현

TL은 Durov의 지분 매각과 함께 잘 알려진 사건 이전에도 VKontakte의 창자에서 태어났습니다.확실히), Telegram이 개발되기 전에도. 그리고 오픈소스에서 첫 번째 구현 소스 재미있는 목발을 많이 찾을 수 있습니다. 그리고 언어 자체는 현재 Telegram보다 더 완벽하게 구현되었습니다. 예를 들어, 해시는 스키마에서 전혀 사용되지 않습니다(일탈적인 동작을 가진 내장 유사 유형(벡터와 같은)을 의미). 또는

Templates are not used now. Instead, the same universal constructors (for example, vector {t:Type} [t] = Vector t) are used w

그러나 완전성을 기하기 위해, 말하자면 사상의 거인의 진화를 추적하기 위해 그림을 살펴봅시다.

#define ZHUKOV_BYTES_HACK

#ifdef ZHUKOV_BYTES_HACK

/* dirty hack for Zhukov request */

또는 이 아름다운 것:

    static const char *reserved_words_polymorhic[] = {

      "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", NULL

      };

이 조각은 다음과 같은 템플릿에 관한 것입니다.

intHash {alpha:Type} vector<coupleInt<alpha>> = IntHash<alpha>;

이것은 int - Type 쌍의 벡터로서 해시맵 템플릿 유형의 정의입니다. C++에서는 다음과 같이 표시됩니다.

    template <T> class IntHash {
      vector<pair<int,T>> _map;
    }

그래서, alpha - 키워드! 하지만 C++에서만 T를 작성할 수 있지만 알파, 베타를 작성해야 합니다... 하지만 매개변수가 8개를 초과하지 않으면 세타에서 환상이 끝났습니다. 그래서 한때 상트 페테르부르크에서 대략 그러한 대화가 있었던 것 같습니다.

-- Надо сделать в TL шаблоны
-- Бл... Ну пусть параметры зовут альфа, бета,... Какие там ещё буквы есть... О, тэта!
-- Грамматика? Ну потом напишем

-- Смотрите, какой я синтаксис придумал для шаблонов и вектора!
-- Ты долбанулся, как мы это парсить будем?
-- Да не ссыте, он там один в схеме, захаркодить -- и ок

그러나 그것은 "일반적으로" TL의 첫 번째 배치 구현에 관한 것입니다. 실제 Telegram 클라이언트에서 구현을 고려하는 단계로 넘어갑시다.

바질의 말:

Vasily, [09.10.18 17:07] 무엇보다도, 그들이 많은 추상화를 망친 다음 볼트를 두드리고 목발로 코드 생성기를 겹쳤다는 사실 때문에 엉덩이가 뜨겁습니다.
결과적으로 부두에서 먼저 pilot.jpg
그런 다음 jekichan.webp 코드에서

물론 알고리즘과 수학에 익숙한 사람들은 Aho, Ullman을 읽었고 수십 년 동안 DSL 컴파일러를 작성하기 위한 사실상의 산업 표준 도구에 익숙하다고 기대할 수 있습니다. ..

저자 전보-cli Vitaliy Valtman은 (cli) 한계를 벗어난 TLO 형식의 발생에서 알 수 있듯이 팀의 구성원입니다. 이제 TL 구문 분석을 위한 라이브러리가 할당됩니다. 따로 따로그녀의 인상은? TL 파서? ..

16.12 04:18 Vasily: 제 생각에는 누군가가 lex + yacc를 마스터하지 않았습니다.
16.12 04:18 바실리: 그렇지 않으면 설명할 수 없습니다
16.12 04:18 바실리: 음, 아니면 VK의 줄 수만큼 돈을 받았습니다.
16.12 04:19 바실리: 기타 3k+ 라인<censored> 파서 대신

예외일까요? 방법을 보자 делает 이것은 공식 클라이언트입니다 — Telegram Desktop:

    nametype = re.match(r'([a-zA-Z.0-9_]+)(#[0-9a-f]+)?([^=]*)=s*([a-zA-Z.<>0-9_]+);', line);
    if (not nametype):
      if (not re.match(r'vector#1cb5c415 {t:Type} # [ t ] = Vector t;', line)):
         print('Bad line found: ' + line);

Python의 1100개 이상의 라인, 두 개의 정규식 + 벡터 유형의 특수한 경우, 물론 TL 구문에 따라야 하기 때문에 스키마에서 선언되지만 이 구문에 배치하고 더 구문 분석합니다. ... 문제는 왜 이 모든 기적을 귀찮게 하느냐입니다.и어쨌든 문서에 따라 아무도 그것을 구문 분석하지 않는다면 더 많은 퍼프?!

그나저나... 우리가 CRC32 검사에 대해 이야기한 것을 기억하십니까? 따라서 Telegram Desktop 코드 생성기에는 계산된 CRC32가 있는 유형에 대한 예외 목록이 있습니다. 일치하지 않는다 다이어그램에 표시된대로!

Vasily, [18.12 22:49] 여기서 그러한 TL이 필요한지 생각해야 합니다.
대체 구현을 엉망으로 만들고 싶다면 줄 바꿈을 삽입하기 시작하면 구문 분석기의 절반이 여러 줄 정의에서 중단됩니다.
그러나 tdesktop도

원 라이너에 대한 요점을 기억하십시오. 나중에 다시 설명하겠습니다.

좋아, telegram-cli는 비공식이고 Telegram Desktop은 공식이지만 다른 것은 어떻습니까? 그리고 누가 압니까? .. Android 클라이언트 코드에는 스키마 파서가 전혀 없었지만 (오픈 소스에 대한 질문이 있지만 이것은 두 번째 부분에 대한 것입니다) 몇 가지 다른 재미있는 코드 조각이 있었지만 그에 대한 내용은 아래 하위 섹션.

직렬화가 실제로 제기하는 다른 질문은 무엇입니까? 예를 들어, 그들은 물론 비트 필드와 조건부 필드를 망쳤습니다.

바실리: flags.0? true
필드가 있음을 의미하고 플래그가 설정되어 있으면 참입니다.

바실리: flags.1? int
필드가 존재하고 deserialize해야 함을 의미합니다.

바실리: 엉덩이, 타지 마, 뭐하는거야!
Vasily: 문서 어딘가에 true는 길이가 XNUMX인 기본 유형이라는 언급이 있지만 문서에서 무언가를 수집하는 것은 비현실적입니다.
Vasily: 개방형 구현에도 그런 것은 없지만 목발과 소품이 많이 있습니다.

텔레톤은 어때? 예를 들어 MTProto 주제를 미리 살펴보면 문서에 그러한 부분이 있지만 기호 % "주어진 기본 유형에 해당"으로만 설명됩니다. 아래 예에서 오류 또는 문서화되지 않은 항목입니다.

바실리, [22.06.18/18/38 XNUMX:XNUMX] 한 곳에서:

msg_container#73f1f8dc messages:vector message = MessageContainer;

다른:

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

그리고 이것들은 두 가지 큰 차이점이 있습니다. 실생활에서 어떤 종류의 알몸 벡터가 옵니다

베어 벡터 정의를 본 적이 없으며 본 적이 없습니다.

손으로 telethon으로 작성된 분석

그의 스키마는 정의를 주석 처리했습니다. msg_container

다시 말하지만, 질문은 %에 대해 남아 있습니다. 설명되어 있지 않습니다.

Vadim Goncharov, [22.06.18/19/22 XNUMX:XNUMX PM] 그리고 tdesktop에서?

Vasily, [22.06.18/19/23 XNUMX:XNUMX] 하지만 규제 기관의 TL 파서는 아마도 그것을 먹지 않을 것입니다

// parsed manually

TL은 아름다운 추상화이며 아무도 완벽하게 구현하지 않습니다.

그리고 그들의 계획 버전에는 %가 없습니다.

그러나 여기서 문서는 그 자체로 모순되므로 xs

그것은 문법에서 발견되었으며 의미 체계를 설명하는 것을 잊을 수 있습니다.

글쎄, 당신은 TL에서 도크를 보았습니다. 반 리터 없이는 알아낼 수 없습니다

다른 독자는 "글쎄요, 당신은 모든 것을 비판하므로 제대로 보여주세요. "라고 말할 것입니다.

Vasily는 다음과 같이 대답합니다. “파서에 관해서는 다음과 같은 것이 필요합니다.

    args: /* empty */ { $$ = NULL; }
        | args arg { $$ = g_list_append( $1, $2 ); }
        ;

    arg: LC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | LC_ID ':' condition '?' type-term { $$ = tl_arg_new_cond( $1, $5, $3 ); free($3); }
            | UC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | type-term { $$ = tl_arg_new( "", $1 ); }
            | '[' LC_ID ']' { $$ = tl_arg_new_mult( "", tl_type_new( $2, TYPE_MOD_NONE ) ); }
            ;

어떻게 든보다

struct tree *parse_args4 (void) {
  PARSE_INIT (type_args4);
  struct parse so = save_parse ();
  PARSE_TRY (parse_optional_arg_def);
  if (S) {
    tree_add_child (T, S);
  } else {
    load_parse (so);
  }
  if (LEX_CHAR ('!')) {
    PARSE_ADD (type_exclam);
    EXPECT ("!");
  }
  PARSE_TRY_PES (parse_type_term);
  PARSE_OK;
}

또는

        # Regex to match the whole line
        match = re.match(r'''
            ^                  # We want to match from the beginning to the end
            ([w.]+)           # The .tl object can contain alpha_name or namespace.alpha_name
            (?:
                #             # After the name, comes the ID of the object
                ([0-9a-f]+)    # The constructor ID is in hexadecimal form
            )?                 # If no constructor ID was given, CRC32 the 'tl' to determine it

            (?:s              # After that, we want to match its arguments (name:type)
                {?             # For handling the start of the '{X:Type}' case
                w+            # The argument name will always be an alpha-only name
                :              # Then comes the separator between name:type
                [wd<>#.?!]+  # The type is slightly more complex, since it's alphanumeric and it can
                               # also have Vector<type>, flags:# and flags.0?default, plus :!X as type
                }?             # For handling the end of the '{X:Type}' case
            )*                 # Match 0 or more arguments
            s                 # Leave a space between the arguments and the equal
            =
            s                 # Leave another space between the equal and the result
            ([wd<>#.?]+)     # The result can again be as complex as any argument type
            ;$                 # Finally, the line should always end with ;
            ''', tl, re.IGNORECASE | re.VERBOSE)

이것은 전체 어휘 분석기입니다.

    ---functions---         return FUNCTIONS;
    ---types---             return TYPES;
    [a-z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return LC_ID;
    [A-Z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return UC_ID;
    [0-9]+                  yylval.number = atoi(yytext); return NUM;
    #[0-9a-fA-F]{1,8}       yylval.number = strtol(yytext+1, NULL, 16); return ID_HASH;

    n                      /* skip new line */
    [ t]+                  /* skip spaces */
    //.*$                 /* skip comments */
    /*.**/              /* skip comments */
    .                       return (int)yytext[0];

저것들. 더 간단한 것은 온화하게 표현하는 것입니다."

일반적으로 결국 TL의 실제로 사용되는 부분 집합에 대한 파서 및 코드 생성기는 약 100줄의 문법과 ~ 300줄의 생성기에 맞습니다(모두 포함). print의 생성 코드), 유형 Goodies, 각 클래스에서 성찰을 위한 유형 정보를 포함합니다. 각 다형성 유형은 빈 추상 기본 클래스로 바뀌고 생성자는 이 클래스에서 상속되며 직렬화 및 역직렬화를 위한 메서드를 갖습니다.

유형 언어의 유형 부족

강력한 타이핑이 좋죠? 아니요, 이것은 holivar(동적 언어를 선호하지만)가 아니라 TL 내의 가정입니다. 이를 기반으로 언어는 우리를 위해 모든 종류의 검사를 제공해야 합니다. 글쎄요, 그가 아니라 구현이지만 적어도 설명해야합니다. 그리고 우리는 어떤 기회를 원합니까?

우선 제약 조건입니다. 파일 업로드에 대한 문서에서 다음을 볼 수 있습니다.

그런 다음 파일의 이진 콘텐츠가 여러 부분으로 나뉩니다. 모든 부품의 크기가 같아야 합니다( 부품 크기 ) 다음 조건을 충족해야 합니다.

• part_size % 1024 = 0 (1KB로 나누어짐)
• 524288 % part_size = 0 (512KB는 part_size로 균등하게 나누어야 함)

마지막 부품은 크기가 part_size보다 작은 경우 이러한 조건을 충족할 필요가 없습니다.

각 부품에는 시퀀스 번호가 있어야 합니다. 파일_부분, 0에서 2,999 사이의 값.

파일이 분할된 후 서버에 저장할 방법을 선택해야 합니다. 사용 업로드.저장BigFilePart 파일의 전체 크기가 10MB 이상인 경우 업로드.저장파일 부분 더 작은 파일의 경우.
[...] 다음 데이터 입력 오류 중 하나가 반환될 수 있습니다.

• FILE_PARTS_INVALID - 부품 수가 잘못되었습니다. 값이 사이에 있지 않음 1..3000

스키마에 이러한 항목이 있습니까? TL을 통해 어떻게든 표현할 수 있습니까? 아니요. 하지만 구식 터보 파스칼도 다음에 의해 주어진 유형을 설명할 수 있었습니다. 범위. 그리고 그는 이제 더 잘 알려진 한 가지 일을 더 할 수 있었습니다. enum - 고정된(작은) 값의 열거형으로 구성된 유형입니다. C - 숫자와 같은 언어에서는 지금까지 유형에 대해서만 이야기했습니다. 숫자. 하지만 배열, 문자열도 있습니다. 예를 들어 이 문자열에는 전화번호만 포함될 수 있다고 설명하면 좋겠죠?

이 중 어느 것도 TL에 없습니다. 그러나 예를 들어 JSON 스키마에 있습니다. 그리고 다른 누군가가 코드에서 여전히 확인해야 하는 512KB의 분할 가능성에 대해 이의를 제기할 수 있는 경우 클라이언트가 못했습니다 범위를 벗어난 번호 보내기 1..3000 (그리고 해당 오류가 발생하지 않았을 수도 있습니다) 가능하겠죠? ..

그건 그렇고, 오류 및 반환 값에 대해. TL과 함께 일한 사람들에게도 눈이 흐릿합니다. 각 TL의 함수는 실제로 설명된 반환 유형뿐만 아니라 오류도 반환할 수 있습니다. 그러나 이것은 TL 자체로는 추론할 수 없습니다. 물론 이해할 수 있고 nafig는 실제로 필요하지 않습니다 (사실 RPC는 다른 방식으로 수행 될 수 있지만 이것으로 돌아갈 것입니다). 그러나 하늘 세계의 추상 유형 수학 개념의 순수성은 어떻습니까? .. 잡아 당김-그래서 일치합니다.

마지막으로 가독성은 어떻습니까? 글쎄요, 일반적으로 설명 스키마에서 올바르게 가지고 있지만(다시 말하지만 JSON 스키마에 있음) 이미 부담이 된다면 실용적인 측면은 어떻습니까? 적어도 업데이트 중에 diff를 보는 것은 진부한 일입니까? 에서 직접 확인하세요. 실제 사례:

-channelFull#76af5481 flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;
+channelFull#1c87a71a flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true can_view_stats:flags.12?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int online_count:flags.13?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;

또는

-message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;
+message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true from_scheduled:flags.18?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;

예를 들어 누군가는 그것을 좋아하지만 GitHub는 그러한 긴 줄 내부의 변경 사항을 강조 표시하지 않습니다. 게임 "10 개의 차이점 찾기", 그리고 뇌가 즉시 보는 것은 두 예에서 시작과 끝이 동일하다는 것입니다. 중간 어딘가를 지루하게 읽어야합니다 ... 제 생각에는 이것은 단지 이론이 아니라, 하지만 순전히 시각적으로 더럽고 깔끔하지 않은.

그건 그렇고, 이론의 순수성에 대해. 비트 필드가 필요한 이유는 무엇입니까? 그들은 보이지 않는 뿡뿡이 유형 이론의 관점에서 나쁜가요? 이전 버전의 스키마에서 설명을 볼 수 있습니다. 처음에는 그렇습니다. 재채기마다 새로운 유형이 만들어졌습니다. 이러한 기초는 여전히 이 형식으로 존재합니다. 예를 들면 다음과 같습니다.

storage.fileUnknown#aa963b05 = storage.FileType;
storage.filePartial#40bc6f52 = storage.FileType;
storage.fileJpeg#7efe0e = storage.FileType;
storage.fileGif#cae1aadf = storage.FileType;
storage.filePng#a4f63c0 = storage.FileType;
storage.filePdf#ae1e508d = storage.FileType;
storage.fileMp3#528a0677 = storage.FileType;
storage.fileMov#4b09ebbc = storage.FileType;
storage.fileMp4#b3cea0e4 = storage.FileType;
storage.fileWebp#1081464c = storage.FileType;

그러나 이제 구조에 5개의 선택적 필드가 있다고 가정하면 가능한 모든 옵션에 대해 32개의 유형이 필요합니다. 조합 폭발. 따라서 TL 이론의 결정적 순도는 연재의 가혹한 현실이라는 주철 엉덩이에 다시 한 번 충돌했습니다.

또한 장소에서이 사람들은 자신의 타이핑을 위반합니다. 예를 들어 MTProto(다음 장)에서 응답은 Gzip으로 압축될 수 있으며 계층 및 스키마 위반을 제외하고 모든 것이 합리적입니다. 한 번, RpcResult 자체가 아니라 그 내용을 거둔 것입니다. 글쎄, 왜 이러지? .. 압축이 어디에서나 작동하도록 목발을 잘라야했습니다.

또는 다른 예를 들어, 한 번 오류를 발견했습니다. InputPeerUser 대신 InputUser. 혹은 그 반대로도. 그러나 그것은 효과가 있었다! 즉, 서버는 유형에 대해 신경 쓰지 않았습니다. 어떻게 이럴 수있어? 대답은 아마도 telegram-cli의 코드 조각에 의해 프롬프트될 것입니다.

  if (tgl_get_peer_type (E->id) != TGL_PEER_CHANNEL || (C && (C->flags & TGLCHF_MEGAGROUP))) {
    out_int (CODE_messages_get_history);
    out_peer_id (TLS, E->id);
  } else {    
    out_int (CODE_channels_get_important_history);

    out_int (CODE_input_channel);
    out_int (tgl_get_peer_id (E->id));
    out_long (E->id.access_hash);
  }
  out_int (E->max_id);
  out_int (E->offset);
  out_int (E->limit);
  out_int (0);
  out_int (0);

즉, 여기에서 직렬화가 완료됩니다. 수동으로, 생성된 코드가 아닙니다! 아마 서버도 비슷한 방식으로 구현된거 아닐까요?.. 원칙적으로 한번만 하면 되는건데 나중에 업데이트로 어떻게 지원할 수 있을까요? 그 계획의 목적이 아니었습니까? 그리고 다음 질문으로 넘어가겠습니다.

버전 관리. 레이어

스키마 버전을 레이어라고 부르는 이유는 게시된 스키마의 기록을 기반으로만 추측할 수 있습니다. 분명히 처음에는 기본 작업이 변경되지 않은 체계에서 수행 될 수 있고 필요한 경우에만 다른 버전에 따라 수행되고 있음을 특정 요청에 표시하는 것처럼 보였습니다. 원칙적으로 좋은 아이디어와 새로운 의지조차도 "혼합"되어 이전에 겹쳐집니다. 그러나 그것이 어떻게 이루어졌는지 봅시다. 사실, 처음부터 볼 수 없었습니다. 재미 있지만 기본 레이어 구성표는 단순히 존재하지 않습니다. 레이어는 2에서 시작되었습니다. 문서는 특별한 TL 기능에 대해 알려줍니다.

클라이언트가 레이어 2를 지원하는 경우 다음 생성자를 사용해야 합니다.

invokeWithLayer2#289dd1f6 {X:Type} query:!X = X;

실제로 이것은 모든 API 호출 전에 값이 있는 int를 의미합니다. 0x289dd1f6 메서드 번호 앞에 추가해야 합니다.

괜찮아요. 그러나 다음에 무슨 일이 일어났습니까? 그리고 왔다

invokeWithLayer3#b7475268 query:!X = X;

다음은 무엇입니까? 추측하기 쉽기 때문에

invokeWithLayer4#dea0d430 query:!X = X;

재미있는? 아니, 웃기엔 너무 이르다. 생각해봐. 각 다른 계층의 요청은 이러한 특수한 유형으로 래핑되어야 합니다. 모두 다른 경우 어떻게 구별해야 합니까? 그리고 앞에 4바이트만 추가하는 것이 매우 효율적인 방법입니다. 그래서

invokeWithLayer5#417a57ae query:!X = X;

그러나 잠시 후 그것은 일종의 bacchanalia가 될 것임이 분명합니다. 그리고 해결책이 나왔습니다.

업데이트: 레이어 9부터 도우미 메서드 invokeWithLayerN 함께 사용할 수 있습니다 initConnection

만세! 9개의 버전 이후, 우리는 마침내 80년대에 인터넷 프로토콜에서 수행되었던 작업에 도달했습니다. 연결 초기에 버전 협상이 한 번 있었습니다!

그래서 다음은?..

invokeWithLayer10#39620c41 query:!X = X;
...
invokeWithLayer18#1c900537 query:!X = X;

이제 웃을 수 있습니다. 또 다른 9개의 레이어 후에야 마침내 버전 번호가 있는 범용 생성자가 추가되었으며 연결 시작 시 한 번만 호출하면 되며 레이어의 의미가 사라진 것 같습니다. 이제는 다음과 같은 조건부 버전일 뿐입니다. 다른 모든 곳. 문제 해결됨.

오른쪽?..

바실리, [16.07.18/14/01 XNUMX:XNUMX PM] 금요일에 나는 생각했다:
텔레서버는 요청 없이 이벤트를 보냅니다. 요청은 InvokeWithLayer로 래핑되어야 합니다. 서버는 업데이트를 래핑하지 않으며 응답 및 업데이트를 래핑하는 구조가 없습니다.

저것들. 클라이언트는 업데이트를 원하는 레이어를 지정할 수 없습니다.

Vadim Goncharov, [16.07.18/14/02 XNUMX:XNUMX PM] InvokeWithLayer는 원칙적으로 버팀목이 아닙니까?

바실리, [16.07.18/14/02 XNUMX:XNUMX PM] 이 방법밖에 없어요

Vadim Goncharov, [16.07.18/14/02 XNUMX:XNUMX PM] 본질적으로 세션 시작 시 레이어링을 의미해야 함

그건 그렇고, 클라이언트 다운 그레이드가 제공되지 않습니다.

업데이트, 즉 유형 Updates 체계에서 이것은 API 요청에 대한 응답이 아니라 이벤트가 발생할 때 자체적으로 서버가 클라이언트에 보내는 것입니다. 이것은 다른 게시물에서 논의할 복잡한 주제이지만 지금은 클라이언트가 오프라인일 때도 서버가 업데이트를 누적한다는 것을 아는 것이 중요합니다.

따라서 포장을 거부할 때 각 버전을 나타내는 패키지이므로 논리적으로 다음과 같은 가능한 문제가 발생합니다.

• 클라이언트가 지원하는 버전을 알려주기 전에 서버가 클라이언트에 업데이트를 보냅니다.
• 클라이언트를 업그레이드한 후 수행해야 하는 작업은 무엇입니까?
• 누구 보증레이어 번호에 대한 서버의 의견은 프로세스에서 변경되지 않습니까?

이것이 순전히 이론적 사고라고 생각하고 서버가 올바르게 작성 되었기 때문에 실제로는 이런 일이 일어날 수 없다고 생각하십니까 (어쨌든 잘 테스트되었습니다)? 하아! 아무리!

이것이 바로 우리가 14월에 만난 것입니다. XNUMX월 XNUMX일, Telegram 서버와 로그에 무언가가 업데이트되고 있다는 메시지가 번쩍였습니다.

2019-08-15 09:28:35.880640 MSK warn  main: ANON:87: unknown object type: 0x80d182d1 at TL/Object.pm line 213.
2019-08-15 09:28:35.751899 MSK warn  main: ANON:87: unknown object type: 0xb5223b0f at TL/Object.pm line 213.

그런 다음 몇 메가바이트의 스택 추적(동시에 로깅이 수정됨). 결국, TL에서 무언가가 인식되지 않은 경우 서명에 의한 바이너리이며 스트림에서 더 멀리 있습니다. 모두 가면 해독이 불가능해집니다. 그런 상황에서 어떻게 해야 할까요?

글쎄, 누구에게나 가장 먼저 떠오르는 것은 연결을 끊고 다시 시도하는 것입니다. 도움이되지 않았습니다. 우리는 CRC32를 검색했습니다. 체계 73에서 작업했지만 체계 82의 개체로 판명되었습니다. 로그를주의 깊게 살펴 봅니다. 두 가지 체계의 식별자가 있습니다!

문제가 순전히 비공식 클라이언트에 있는 것일까요? 아니요, 우리는 Telegram Desktop 1.2.17(여러 Linux 배포판과 함께 제공되는 버전)을 실행하며 예외 로그에 기록합니다. MTP Unexpected type id #b5223b0f read in MTPMessageMedia…

Google은 비공식 클라이언트 중 하나에 유사한 문제가 이미 발생했음을 보여 주었지만 버전 번호와 이에 따라 가정이 달랐습니다 ...

그래서 뭐 할까? Vasily와 나는 헤어졌습니다. 그는 계획을 91로 업데이트하려고 시도했고 며칠을 기다렸다가 73을 시도하기로 결정했습니다. 두 방법 모두 효과가 있었지만 경험적이므로 점프해야 할 버전 수를 이해하지 못합니다. 또는 아래로, 얼마나 오래 기다려야 하는지 .

나중에 상황을 재현할 수 있었습니다. 클라이언트를 시작하고, 끄고, 체계를 다른 계층으로 다시 컴파일하고, 다시 시작하고, 문제를 다시 포착하고, 이전 문제로 돌아갑니다. 분이 도움이 될 것입니다. 서로 다른 계층에서 혼합된 데이터 구조를 받게 됩니다.

설명? 다양한 간접 증상에서 짐작할 수 있듯이 서버는 서로 다른 시스템에 있는 다양한 유형의 프로세스로 구성됩니다. 아마도 "버퍼링"을 담당하는 서버 중 하나는 더 높은 서버가 제공 한 것을 대기열에 넣고 생성 당시의 체계로 제공했습니다. 그리고 이 대기열이 "썩음"이 되기 전까지는 아무 것도 할 수 없었습니다.

그게 아니라면.. 이게 몹쓸 목발?!.. 아니, 미친 아이디어를 생각하기 전에 공식 클라이언트의 코드를 살펴보자. Android 버전에서는 TL 파서를 찾을 수 없지만 (비)직렬화가 있는 무거운 파일(github에서 색상 지정을 거부함)을 찾습니다. 다음은 코드 스니펫입니다.

public static class TL_message_layer68 extends TL_message {
    public static int constructor = 0xc09be45f;
//...
//еще пачка подобных
//...
    public static class TL_message_layer47 extends TL_message {
        public static int constructor = 0xc992e15c;
        public static Message TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
            Message result = null;
            switch (constructor) {
                case 0x1d86f70e:
                    result = new TL_messageService_old2();
                    break;
                case 0xa7ab1991:
                    result = new TL_message_old3();
                    break;
                case 0xc3060325:
                    result = new TL_message_old4();
                    break;
                case 0x555555fa:
                    result = new TL_message_secret();
                    break;
                case 0x555555f9:
                    result = new TL_message_secret_layer72();
                    break;
                case 0x90dddc11:
                    result = new TL_message_layer72();
                    break;
                case 0xc09be45f:
                    result = new TL_message_layer68();
                    break;
                case 0xc992e15c:
                    result = new TL_message_layer47();
                    break;
                case 0x5ba66c13:
                    result = new TL_message_old7();
                    break;
                case 0xc06b9607:
                    result = new TL_messageService_layer48();
                    break;
                case 0x83e5de54:
                    result = new TL_messageEmpty();
                    break;
                case 0x2bebfa86:
                    result = new TL_message_old6();
                    break;
                case 0x44f9b43d:
                    result = new TL_message_layer104();
                    break;
                case 0x1c9b1027:
                    result = new TL_message_layer104_2();
                    break;
                case 0xa367e716:
                    result = new TL_messageForwarded_old2(); //custom
                    break;
                case 0x5f46804:
                    result = new TL_messageForwarded_old(); //custom
                    break;
                case 0x567699b3:
                    result = new TL_message_old2(); //custom
                    break;
                case 0x9f8d60bb:
                    result = new TL_messageService_old(); //custom
                    break;
                case 0x22eb6aba:
                    result = new TL_message_old(); //custom
                    break;
                case 0x555555F8:
                    result = new TL_message_secret_old(); //custom
                    break;
                case 0x9789dac4:
                    result = new TL_message_layer104_3();
                    break;

또는

    boolean fixCaption = !TextUtils.isEmpty(message) &&
    (media instanceof TLRPC.TL_messageMediaPhoto_old ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer68 ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer74 ||
     media instanceof TLRPC.TL_messageMediaDocument_old ||
     media instanceof TLRPC.TL_messageMediaDocument_layer68 ||
     media instanceof TLRPC.TL_messageMediaDocument_layer74)
    && message.startsWith("-1");

흠... 미쳤나보네요. 하지만 아마도 이것은 생성 된 코드라면 괜찮습니까? .. 그러나 확실히 모든 버전을 지원합니다! 사실, 왜 모든 것이 하나의 힙, 비밀 채팅 및 모든 종류의 _old7 왠지 기계 세대와 비슷하지 않습니다 ... 하지만 무엇보다 나는 미쳤습니다

TL_message_layer104
TL_message_layer104_2
TL_message_layer104_3

여러분, 한 겹 내에서 결정도 못 하시나요?! 글쎄요, "XNUMX"가 오류와 함께 출시되었다고 가정 해 봅시다. 하지만 THREE? .. 같은 레이크에서 즉시 다시? 이게 무슨 음란물이야, 미안? ..

그건 그렇고, Telegram Desktop 소스에서도 비슷한 일이 발생합니다. 그렇다면 구성표에 대한 연속 커밋은 레이어 번호를 변경하지 않고 무언가를 수정합니다. 스키마에 대한 공식 데이터 소스가 없는 상황에서 공식 클라이언트 소스를 제외하고 어디에서 얻을 수 있습니까? 그리고 거기에서 가져오면 모든 방법을 테스트할 때까지 계획이 완전히 올바른지 확신할 수 없습니다.

이것이 어떻게 테스트될 수 있습니까? 단위, 기능 및 기타 테스트의 팬이 의견을 공유하기를 바랍니다.

좋습니다. 다른 코드를 살펴보겠습니다.

public static class TL_folders_deleteFolder extends TLObject {
    public static int constructor = 0x1c295881;

    public int folder_id;

    public TLObject deserializeResponse(AbstractSerializedData stream, int constructor, boolean exception) {
        return Updates.TLdeserialize(stream, constructor, exception);
    }

    public void serializeToStream(AbstractSerializedData stream) {
        stream.writeInt32(constructor);
        stream.writeInt32(folder_id);
    }
}

//manually created

//RichText start
public static abstract class RichText extends TLObject {
    public String url;
    public long webpage_id;
    public String email;
    public ArrayList<RichText> texts = new ArrayList<>();
    public RichText parentRichText;

    public static RichText TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
        RichText result = null;
        switch (constructor) {
            case 0x1ccb966a:
                result = new TL_textPhone();
                break;
            case 0xc7fb5e01:
                result = new TL_textSuperscript();
                break;

여기에서 "수동으로 생성된" 주석은 이 파일의 일부만 손으로 ​​작성되었으며(유지 관리 악몽을 상상할 수 있습니까?) 나머지는 기계에서 생성되었음을 나타냅니다. 그러나 또 다른 질문이 생깁니다. 소스를 사용할 수 있다는 것입니다. 완전히 (Linux 커널의 GPL 아래에 있는 blob), 그러나 이것은 이미 두 번째 부분의 주제입니다.

하지만 충분합니다. 이 모든 직렬화가 쫓고 있는 프로토콜로 이동해 봅시다.

MT프로토

그럼 열어봅시다 일반적인 설명 и 프로토콜에 대한 자세한 설명 우리가 가장 먼저 넘어지는 것은 용어입니다. 그리고 모든 것이 풍부합니다. 일반적으로 이것은 Telegram의 상표인 것 같습니다. 다른 위치에 있는 것을 다른 방식으로 부르거나 한 단어로 다른 것을 부르거나 그 반대의 경우도 마찬가지입니다(예: 스티커 팩이 보이면 높은 수준의 API에서 - 이것은 당신이 생각한 것이 아닙니다).

예를 들어 "메시지"(메시지) 및 "세션"(세션) - 여기서는 Telegram 클라이언트의 일반적인 인터페이스와 다른 것을 의미합니다. 글쎄, 메시지로 모든 것이 명확하고 OOP로 해석되거나 단순히 "패키지"라는 단어라고 할 수 있습니다. 이것은 낮은 전송 수준이며 인터페이스와 동일한 메시지가 없으며 많이 있습니다. 서비스의 것. 하지만 세션은 ... 하지만 가장 먼저 해야 할 일이 있습니다.

전송 계층

첫 번째는 운송입니다. 5가지 옵션에 대해 알려드립니다.

• TCP
• 웹 소켓
• HTTPS를 통한 웹소켓
• HTTP
• HTTPS

Vasily, [15.06.18/15/04 XNUMX:XNUMX PM] UDP 전송도 있지만 문서화되지 않았습니다.

세 가지 변형의 TCP

첫 번째는 TCP를 통한 UDP와 유사하며 각 패킷에는 시퀀스 번호와 crc가 포함됩니다.
카트에서 부두를 읽는 것이 왜 그렇게 고통스럽습니까?

그럼 지금 이미 4가지 변종의 TCP:

• 요약 텍스트
• 중간의
• 패딩 중간
• 가득 찬

알겠습니다. MTProxy용 패딩 중간체입니다. 알려진 이벤트로 인해 나중에 추가되었습니다. 그러나 하나는 할 수 있는데 왜 두 가지 버전(총 XNUMX개)을 더 추가해야 할까요? 네 가지 모두 기본적으로 기본 MTProto 자체의 길이와 페이로드를 설정하는 방법만 다릅니다. 이에 대해서는 나중에 자세히 설명합니다.

• 요약본에서는 1 또는 4바이트이지만 0xef 다음 본문은 아닙니다.
• Intermediate에서 이것은 4바이트의 길이와 필드이며 클라이언트가 처음으로 보내야 하는 0xeeeeeeee 중간임을 나타내기 위해
• 네트워커의 관점에서 볼 때 전체적으로 가장 중독성이 강한 것입니다: 길이, 시퀀스 번호, 그리고 기본적으로 MTProto, 본문, CRC32인 것이 아닙니다. 예, 이 모든 것이 TCP를 통해 이루어집니다. 직렬 바이트 스트림의 형태로 안정적인 전송을 제공하므로 시퀀스, 특히 체크섬이 필요하지 않습니다. 자, 이제 TCP에 16비트 체크섬이 있어서 데이터 손상이 발생한다고 반대할 것입니다. 훌륭합니다. 실제로 해시가 16바이트보다 긴 암호화 프로토콜이 있다는 점을 제외하고 이러한 모든 오류는 더 높은 수준의 SHA 불일치에서 포착됩니다. 이것에 대해 CRC32에는 아무런 요점이 없습니다.

4바이트 길이가 가능한 Abridged와 "16바이트 데이터 정렬이 필요한 경우"를 정당화하는 Intermediate를 비교해보자. 뭐, Telegram 프로그래머는 너무 서투른 나머지 소켓에서 정렬된 버퍼로 데이터를 읽을 수 없다고 믿어지나요? 여전히 이 작업을 수행해야 합니다. 읽기는 원하는 수의 바이트를 반환할 수 있기 때문입니다(예를 들어 프록시 서버도 있습니다). 또는 다른 한편으로 상단에 3바이트의 막대한 패딩이 여전히 있는 경우 Abridged를 사용하는 이유는 무엇입니까? XNUMX바이트를 절약하십시오. 때로는 ?

누군가는 Nikolai Durov가 네트워크 프로토콜을 포함하여 실제적인 필요 없이 자전거를 발명하는 것을 매우 좋아한다는 인상을 받습니다.

기타 운송 옵션 포함. Web 및 MTProxy는 요청이 있을 경우 지금은 고려하지 않고 다른 게시물에서 검토하겠습니다. 우리는 2018년에 출시된 직후 공급자가 정확하게 차단하는 방법을 빠르게 배웠던 바로 이 MTProxy에 대해서만 기억할 것입니다. 차단 우회로 패킷 크기! 또한 C로 작성된 MTProxy 서버(Waltman이 다시 말함)가 전혀 필요하지 않았지만(Phil Kulin이 확인할 것임) Linux 사양에 불필요하게 연결되어 있고 유사한 서버가 Go 또는 Node.js에 있다는 사실도 있습니다. XNUMX줄 미만으로 적합합니다.

그러나 다른 문제를 고려한 후 섹션의 끝에서 이 사람들의 기술 문해력에 대한 결론을 도출할 것입니다. 지금은 MTProto 세션을 배치한 세션인 5번째 OSI 레이어로 이동하겠습니다.

키, 메시지, 세션, Diffie-Hellman

그들은 그것을 완전히 정확하게 넣지 않았습니다 ... 세션은 활성 세션 아래의 인터페이스에 표시되는 것과 동일한 세션이 아닙니다. 그러나 순서대로.

여기서 우리는 전송 계층에서 알려진 길이의 바이트 문자열을 받았습니다. 이것은 암호화된 메시지이거나 일반 텍스트입니다. 아직 키 협상 단계에 있고 실제로 수행 중인 경우입니다. "키"라고 하는 개념 중 어떤 것에 대해 이야기하고 있습니까? Telegram 팀 자체에 대해 이 문제를 명확히 합시다.

라는 두 개의 엔터티가 있습니다. 세션 - 각 세션이 전체 장치/OS에 해당하는 "현재 세션" 아래의 공식 클라이언트 UI에 있습니다.
두 번째는 MTProto 세션, 메시지 시퀀스 번호(낮은 수준의 의미)가 있고 서로 다른 TCP 연결 간에 지속될 수 있습니다. 예를 들어 파일 다운로드 속도를 높이기 위해 여러 MTProto 세션을 동시에 설정할 수 있습니다.

이 둘 사이 세션 개념이다 권한 부여. 퇴화의 경우에는 다음과 같이 말할 수 있습니다. UI 세션 와 같다 권한 부여그러나 아아, 그것은 복잡합니다. 우리는 본다:

• 새 기기의 사용자가 먼저 인증_키 예를 들어 SMS를 통해 계정에 연결합니다. 권한 부여
• 그것은 첫 번째 내부에서 발생했습니다 MTProto 세션의 session_id 자신 안에.
• 이 단계에서 조합 권한 부여 и session_id 이름을 붙일 수 있었다 예 - 이 단어는 일부 클라이언트의 문서 및 코드에서 찾을 수 있습니다.
• 그러면 클라이언트가 열 수 있습니다. 여러 MTProto 세션 같은 아래 인증_키 - 같은 DC로.
• 그러던 어느 날 클라이언트는 다음에서 파일을 요청해야 합니다. 다른 DC - 이 DC에 대해 새 DC가 생성됩니다. 인증_키 !
• 이것은 새로운 사용자 등록이 아니라 동일함을 시스템에 알리기 위해 권한 부여 (UI 세션), 클라이언트는 API 호출을 사용합니다. auth.exportAuthorization 집에서 DC auth.importAuthorization 새로운 DC에서.
• 모두 동일하게 여러 개가 열려 있을 수 있습니다. MTProto 세션 (각자 자신의 session_id) 아래에서 이 새 DC로 그의 인증_키.
• 마지막으로 클라이언트는 Perfect Forward Secrecy를 원할 수 있습니다. 모든 인증_키 있었다 영구 키 - DC당 - 클라이언트가 호출할 수 있음 auth.bindTempAuthKey 사용하기위한 일시적인 인증_키 - 그리고 다시 한 번만 임시_인증_키 DC당, 모두에게 공통 MTProto 세션 이 DC에.

유의 사항 소금 (및 미래의 소금) 또한 하나 인증_키 저것들. 모두가 공유 MTProto 세션 동일한 DC에.

"서로 다른 TCP 연결 사이"는 무엇을 의미합니까? 이것은 다음을 의미합니다. 같은 것 웹사이트의 인증 쿠키 - 이 서버에 대한 많은 TCP 연결을 지속(존속)하지만 언젠가는 나빠질 것입니다. HTTP와 달리 MTProto에서는 세션 내에서 메시지가 순차적으로 번호가 매겨지고 확인되며 터널에 들어갔고 연결이 끊어졌습니다. 새 연결을 설정한 후 서버는 이 세션에서 배달하지 않은 모든 것을 친절하게 보냅니다. 이전 TCP 연결.

그러나 위의 정보는 수개월의 소송 끝에 짜낸 것입니다. 그동안 클라이언트를 처음부터 구현하고 있습니까? - 처음으로 돌아가자.

그래서 우리는 생성 auth_key 에 Telegram의 Diffie-Hellman 버전. 문서를 이해하려고 노력합시다 ...

Vasily, [19.06.18/20/05 1:255] data_with_hash := SHAXNUMX(데이터) + 데이터 + (임의의 바이트); 길이가 XNUMX바이트와 같도록;
encryption_data := RSA(data_with_hash, server_public_key); 255바이트 길이의 숫자(빅 엔디안)는 필요한 모듈러스에 대해 필요한 거듭제곱으로 올라가고 결과는 256바이트 숫자로 저장됩니다.

그들은 마약 DH를 얻었습니다.

건강한 사람의 DH처럼 보이지 않는다
dx에는 두 개의 공개 키가 없습니다.

글쎄, 결국 우리는 그것을 알아 냈지만 퇴적물은 남아있었습니다. 고객이 숫자를 인수 분해 할 수 있다는 작업 증명을 수행했습니다. DoS 공격에 대한 보호 유형입니다. 그리고 RSA 키는 본질적으로 암호화를 위해 한 방향으로 한 번만 사용됩니다. new_nonce. 하지만 겉보기에 간단해 보이는 이 작전이 성공하는 동안, 당신은 무엇을 마주해야 할까요?

Vasily, [20.06.18/00/26 XNUMX:XNUMX] 아직 appid 요청에 도달하지 못했습니다.

DH에 요청을 보냈습니다.

그리고 트랜스포트의 도크에는 4바이트의 오류 코드로 응답할 수 있다고 쓰여 있습니다. 그리고 그게 다야

글쎄, 그는 나에게 -404라고 말했다. 그래서 뭐?

여기 내가 그에게 있습니다.

이러한 서버 응답에 대해 어떻게 생각하십니까? 무엇을 해야 합니까? 물어볼 사람이 없습니다(두 번째 부분에서 자세히 설명).

여기서 도크에 대한 모든 관심은

난 할 일이 없어 꿈만 꿨어 숫자를 앞뒤로

두 개의 32비트 숫자. 나는 다른 사람들처럼 그들을 포장

하지만 아니요, BE로 첫 줄에 필요한 것은 이 두 가지입니다.

Vadim Goncharov, [20.06.18/15/49 404:XNUMX PM] 그리고 이 XNUMX 때문에?

바실리, [20.06.18/15/49 XNUMX:XNUMX PM] 예!

Vadim Goncharov, [20.06.18/15/50 XNUMX:XNUMX PM] 그가 "찾지 못한" 것을 이해할 수 없습니다

바실리, [20.06.18 15:50] 약

간단한 약수 %로의 분해를 찾지 못했습니다.)

오류 보고조차 숙달되지 않았습니다.

바실리, [20.06.18/20/18 5:XNUMX PM] 아, MDXNUMX도 있군요. 이미 세 가지 다른 해시

키 지문은 다음과 같이 계산됩니다.

digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)

SHA1 및 샤2

그래서 넣자 auth_key Diffie-Hellman에 따르면 크기는 2048비트입니다. 무엇 향후 계획? 그런 다음 이 키의 하위 1024비트는 전혀 사용되지 않는다는 것을 알게 되지만... 일단은 이에 대해 생각해 봅시다. 이 단계에서 우리는 서버와 비밀을 공유합니다. 매우 비용이 많이 드는 절차인 TLS 세션의 아날로그가 설정되었습니다. 하지만 서버는 우리가 누구인지 아직 아무것도 모릅니다! 아직, 사실 권한 부여. 저것들. ICQ에서 사용했던 "로그인 비밀번호" 또는 SSH에서와 같이 적어도 "로그인 키"(예: 일부 gitlab / github)의 관점에서 생각했다면. 우리는 익명을 얻었습니다. 그리고 서버가 "이 전화번호는 다른 DC에서 제공합니다"라고 응답하면? 아니면 "당신의 전화번호는 금지되어 있습니다"? 우리가 할 수 있는 최선의 일은 키가 여전히 유용하고 그때까지 썩지 않을 것이라는 희망으로 키를 저장하는 것입니다.

그건 그렇고, 예약으로 "받았습니다". 예를 들어 서버를 신뢰합니까? 그는 가짜입니까? 암호화 검사가 필요합니다.

Vasily, [21.06.18/17/53 2:XNUMX PM] 단순성을 위해 XNUMXkbit 숫자를 확인할 수 있는 모바일 클라이언트를 제공합니다%)

하지만 전혀 명확하지 않아, nafeijoa

Vasily, [21.06.18/18/02 XNUMX:XNUMX] 도크는 간단하지 않은 것으로 판명되면 어떻게 해야할지 말하지 않습니다.

말하지 않았다. 이 경우 Android용 공식 클라이언트가 무엇을 하는지 볼까요? ㅏ 그게 뭐야? (예, 전체 파일이 흥미 롭습니다.)-그들이 말했듯이 여기에 그대로 두겠습니다.

278     static const char *goodPrime = "c71caeb9c6b1c9048e6c522f70f13f73980d40238e3e21c14934d037563d930f48198a0aa7c14058229493d22530f4dbfa336f6e0ac925139543aed44cce7c3720fd51f69458705ac68cd4fe6b6b13abdc9746512969328454f18faf8c595f642477fe96bb2a941d5bcd1d4ac8cc49880708fa9b378e3c4f3a9060bee67cf9a4a4a695811051907e162753b56b0f6b410dba74d8a84b2a14b3144e0ef1284754fd17ed950d5965b4b9dd46582db1178d169c6bc465b0d6ff9ca3928fef5b9ae4e418fc15e83ebea0f87fa9ff5eed70050ded2849f47bf959d956850ce929851f0d8115f635b105ee2e4e15d04b2454bf6f4fadf034b10403119cd8e3b92fcc5b";
279   if (!strcasecmp(prime, goodPrime)) {

아니, 물론 거기 일부 숫자의 단순성에 대한 검사가 있지만 개인적으로 더 이상 수학에 대한 충분한 지식이 없습니다.

자, 마스터 키를 얻었습니다. 로그인하려면, 즉 요청을 보내려면 이미 AES를 사용하여 추가 암호화를 수행해야 합니다.

메시지 키는 패딩 바이트를 포함하여 메시지 본문(세션, 메시지 ID 등 포함)의 SHA128의 중간 256비트로 정의되며 인증 키에서 가져온 32바이트가 추가됩니다.

바실리, [22.06.18/14/08 XNUMX:XNUMX PM] 평범한 년들

받은 auth_key. 모두. 더 나아가 ... 부두에서 명확하지 않습니다. 오픈 소스 코드를 자유롭게 공부하십시오.

MTProto 2.0은 12에서 1024바이트의 패딩이 필요하며 결과 메시지 길이를 16바이트로 나눌 수 있다는 조건이 여전히 적용됩니다.

그럼 얼마나 많은 패딩을 넣어야 할까요?

그리고 예, 여기에서도 오류의 경우 404

누군가 다이어그램과 문서의 텍스트를 주의 깊게 연구했다면 거기에 MAC이 없다는 것을 알았습니다. 그리고 그 AES는 다른 곳에서는 사용되지 않는 일부 IGE 모드에서 사용됩니다. 물론 그들은 FAQ에 그것에 대해 씁니다... 여기에서 메시지 키 자체는 동시에 무결성을 확인하는 데 사용되는 해독된 데이터의 SHA 해시이며 불일치의 경우에 대한 문서입니다. 어떤 이유로 조용히 무시할 것을 권장합니다 (하지만 보안은 어떻습니까? 갑자기 우리를 깨뜨릴까요?).

나는 암호 작성자가 아닙니다. 아마도 이 모드에서는 이론적 관점에서 잘못된 것이 없습니다. 그러나 Telegram Desktop의 예를 사용하여 실질적인 문제를 분명히 말할 수 있습니다. MTProto(이 경우에만 버전 877)의 메시지와 동일한 방식으로 로컬 캐시(이 모든 D783F5D3D8EF1.0C)를 암호화합니다. 먼저 메시지 키, 그 다음 데이터 자체(그리고 주요 큰 auth_key 256바이트(없으면 msg_key 쓸모 없는). 따라서 대용량 파일에서 문제가 눈에 띄게 됩니다. 즉, 암호화 및 해독된 두 개의 데이터 사본을 보관해야 합니다. 그리고 예를 들어 메가바이트 또는 스트리밍 비디오가 있는 경우? .. 암호문 뒤에 MAC이 있는 클래식 체계를 사용하면 스트리밍을 읽고 즉시 전송할 수 있습니다. 그리고 MTProto를 사용하면 처음에는 전체 메시지를 암호화하거나 해독한 다음 네트워크나 디스크로 전송하십시오. 따라서 Telegram Desktop의 최신 버전에서 캐시에 있는 user_data CTR 모드에서 AES와 함께 다른 형식이 이미 사용되었습니다.

Vasily, [21.06.18/01/27 20:XNUMX AM] 오, IGE가 무엇인지 알게 되었습니다. IGE는 원래 Kerberos를 위한 "인증 암호화 모드"의 첫 번째 시도였습니다. 실패한 시도(무결성 보호를 제공하지 않음)이므로 제거해야 했습니다. 그것은 작동하는 인증 암호화 모드에 대한 XNUMX년 탐구의 시작이었고, 최근에는 OCB 및 GCM과 같은 모드에서 절정에 달했습니다.

이제 카트 측의 인수:

Nikolai Durov가 이끄는 Telegram 팀은 XNUMX명의 ACM 챔피언으로 구성되어 있으며 그 중 절반은 수학 박사입니다. MTProto의 현재 버전을 출시하는 데 약 XNUMX년이 걸렸습니다.

뭐가 웃겨. 하위 레벨까지 XNUMX년

아니면 그냥 tls를 가져갈 수도 있습니다.

좋아, 우리가 암호화 및 기타 뉘앙스를 수행했다고 가정 해 봅시다. 마침내 TL 직렬화된 요청을 보내고 응답을 역직렬화할 수 있습니까? 그럼 무엇을, 어떻게 보내야 할까요? 방법은 다음과 같습니다. 초기화 연결아마도 이것이 아닐까요?

Vasily, [25.06.18/18/46 XNUMX:XNUMX PM] 연결을 초기화하고 사용자의 장치 및 응용 프로그램에 대한 정보를 저장합니다.

app_id, device_model, system_version, app_version 및 lang_code를 허용합니다.

그리고 일부 쿼리

언제나처럼 문서. 오픈 소스를 자유롭게 공부하십시오.

invokeWithLayer로 모든 것이 대략적으로 명확하다면 그것은 무엇입니까? 클라이언트가 이미 서버에 요청할 무언가를 가지고 있다고 가정하면 다음과 같이 보내려는 요청이 있습니다.

Vasily, [25.06.18/19/13 XNUMX:XNUMX] 코드로 판단하면 첫 번째 호출은 이 가비지로 래핑되고 가비지 자체는 invokewithlayer에 있습니다.

initConnection이 별도의 호출일 수 없고 래퍼여야 하는 이유는 무엇입니까? 예, 결과적으로 기본 키와 같이 한 번이 아니라 각 세션이 시작될 때마다 수행해야 합니다. 하지만! 권한이 없는 사용자가 호출할 수 없습니다! 적용할 수 있는 단계에 이르렀습니다. 이거 설명서 페이지 - 그리고 그것은 우리에게 ...

인증되지 않은 사용자는 API 메서드의 일부만 사용할 수 있습니다.

• 인증.전송코드
• 인증.재전송코드
• account.getPassword
• auth.checkPassword
• au.check전화
• 인증.가입
• 인증.로그인
• auth.import권한 부여
• help.getConfig
• help.getNearestDc
• help.getAppUpdate
• help.getCdnConfig
• langpack.getLangPack
• langpack.getStrings
• langpack.getDifference
• langpack.getLanguages
• langpack.getLanguage

그 중 가장 먼저 auth.sendCode, api_id 및 api_hash를 보내고 그 후에 코드가 포함된 SMS를 받는 소중한 첫 번째 요청이 있습니다. 그리고 잘못된 DC에 도달하면(예를 들어 이 국가의 전화 번호는 다른 국가에서 제공됨) 원하는 DC 번호와 함께 오류가 발생합니다. DC 번호로 연결해야 하는 IP 주소를 찾으려면 help.getConfig. 한때는 5개만 출품됐지만 2018년 유명 행사 이후 크게 늘었다.

이제 익명 서버에서 이 단계에 도달했음을 기억합시다. IP 주소만 받기에는 너무 비싸지 않나요? MTProto의 암호화되지 않은 부분에서 이 작업과 다른 작업을 수행하지 않는 이유는 무엇입니까? “가짜 주소로 응답하는 것이 RKN이 아니라는 것을 어떻게 확신할 수 있습니까?”라는 반대 의견이 들립니다. 이것에 대해 우리는 사실 공식 고객에서 임베디드 RSA 키, 즉. 당신은 그냥 할 수 있습니다 징후 이 정보. 실제로 이것은 클라이언트가 다른 채널을 통해 받는 잠금 우회에 대한 정보에 대해 이미 수행되었습니다(여전히 연결할 위치를 알아야 하기 때문에 MTProto 자체에서 수행할 수 없다는 것이 논리적입니다).

좋아요. 이 클라이언트 인증 단계에서는 아직 인증되지 않았으며 애플리케이션을 등록하지 않았습니다. 지금은 권한이 없는 사용자가 사용할 수 있는 방법에 대해 서버가 응답하는 것을 확인하려고 합니다. 그리고 여기…

바실리, [10.07.18 14:45] https://core.telegram.org/method/help.getConfig

config#7dae33e0 [...] = Config;
help.getConfig#c4f9186b = Config;

https://core.telegram.org/api/datacenter

config#232d5905 [...] = Config;
help.getConfig#c4f9186b = Config;

계획에서 첫 번째, 두 번째가 온다

tdesktop 스키마에서 세 번째 값은

예, 물론 그 이후로 문서가 업데이트되었습니다. 곧 다시 관련이 없게 될 수 있습니다. 그리고 초보 개발자는 어떻게 알아야 합니까? 응용 프로그램을 등록하면 알려줄까요? Vasily는 이것을했지만 아쉽게도 그에게 아무것도 보내지 않았습니다 (다시 말하지만 두 번째 부분에서 이에 대해 이야기하겠습니다).

... 당신은 우리가 이미 어떻게 든 API로 이동했음을 알았습니다. 다음 단계로 이동하여 MTProto 테마에서 뭔가를 놓쳤습니까? 놀라운 것은 없습니다:

Vasily, [28.06.18/02/04 2:XNUMX AM] 음, 그들은 eXNUMXe의 일부 알고리즘을 뒤지고 있습니다.

Mtproto는 두 도메인 모두에 대한 암호화 알고리즘 및 키와 약간의 래퍼 구조를 정의합니다.

그러나 그들은 서로 다른 스택 수준을 지속적으로 혼합하므로 mtproto가 어디에서 끝나고 다음 수준이 시작되었는지 항상 명확하지 않습니다.

그들은 어떻게 혼합되어 있습니까? 글쎄, 예를 들어 PFS에 대한 동일한 임시 키가 있습니다 (그런데 Telegram Desktop은 수행 방법을 모릅니다). API 요청에 의해 실행됩니다. auth.bindTempAuthKey, 즉. 최상위 수준에서. 그러나 동시에 낮은 수준의 암호화를 방해합니다. 예를 들어 이후에 다시 수행해야 합니다. initConnection 등등 이건 아니다 막 정상적인 요청. 이와는 별도로 DC에 하나의 임시 키만 가질 수 있음을 전달합니다. auth_key_id 각 메시지에서 적어도 모든 메시지의 키를 변경할 수 있으며 서버는 언제든지 임시 키를 "잊어버릴" 권리가 있습니다. 미래의 솔트 세트와 같이 여러 개의 키를 가질 수는 없지만 ?..

MTProto 테마에서 주목할 가치가 있는 몇 가지 다른 사항이 있습니다.

메시지 메시지, msg_id, msg_seqno, 승인, 잘못된 방향의 핑 및 기타 특이성

그들에 대해 알아야 하는 이유는 무엇입니까? 한 수준 더 높은 "누설"이기 때문에 API로 작업할 때 이에 대해 알아야 합니다. 우리가 msg_key에 관심이 없다고 가정하면 하위 수준이 우리를 위해 모든 것을 해독합니다. 그러나 해독된 데이터 내부에는 다음과 같은 필드가 있습니다(패딩 위치를 알기 위한 데이터 길이도 있지만 중요하지 않음).

• 소금 int64
• session_id - int64
• message_id - int64
• seq_no-int32

소금은 전체 DC에 대해 하나라는 것을 기억하십시오. 왜 그것에 대해 알고 있습니까? 요청이 있을 뿐만 아니라 get_future_salts, 어떤 간격이 유효한지 알려주지만 소금이 "썩은" 경우 메시지(요청)가 단순히 손실되기 때문입니다. 서버는 물론 새로운 솔트를 발행하여 보고할 것입니다. new_session_created -하지만 이전 버전에서는 예를 들어 어떻게 든 다시 보내야합니다. 그리고 이 질문은 애플리케이션의 아키텍처에 영향을 미칩니다.

서버는 여러 가지 이유로 세션을 완전히 삭제하고 이러한 방식으로 응답할 수 있습니다. 실제로 클라이언트 측에서 MTProto 세션이란 무엇입니까? 이것은 두 개의 숫자입니다. session_id и seq_no 이 세션 내의 메시지. 물론 기본 TCP 연결도 마찬가지입니다. 클라이언트가 연결이 끊겼다가 다시 연결되는 등 많은 작업을 수행하는 방법을 여전히 모른다고 가정해 보겠습니다. 이것이 빠르게 발생하면 이전 세션이 새 TCP 연결에서 계속되면 증가 seq_no 더 나아가. 시간이 오래 걸리면 서버에서 삭제할 수 있습니다. 우리가 알아낸 바와 같이 서버 측에서도 대기열이기 때문입니다.

무엇이 되어야 하는가 seq_no? 오, 까다로운 질문입니다. 무슨 뜻인지 정직하게 이해하려고 노력하십시오.

콘텐츠 관련 메시지

명시적인 확인이 필요한 메시지입니다. 여기에는 모든 사용자 및 많은 서비스 메시지가 포함되며 컨테이너 및 승인을 제외한 거의 모든 메시지가 포함됩니다.

메시지 시퀀스 번호(msg_seqno)

이 메시지 이전에 발신자가 생성한 "콘텐츠 관련" 메시지(확인이 필요한 메시지, 특히 컨테이너가 아닌 메시지) 수의 두 배에 해당하는 32비트 숫자이며 이후에 현재 메시지가 다음과 같은 경우 XNUMX씩 증가합니다. 콘텐츠 관련 메시지. 컨테이너는 항상 전체 내용 다음에 생성됩니다. 따라서 시퀀스 번호는 포함된 메시지의 시퀀스 번호보다 크거나 같습니다.

1증가하고 또 2증가하는 이게 무슨 서커스야?.. 원래 의미는 "ACK는 로우비트, 나머지는 숫자"라고 생각했는데, 결과가 아주 옳지 않다 - 특히, 보낼 수 있다고 합니다 여러 동일하다는 확인 seq_no! 어떻게? 예를 들어, 서버는 우리에게 무언가를 보내고 보내고 우리는 침묵합니다. 우리는 그의 메시지 수신에 대한 서비스 확인 메시지로만 대답합니다. 이 경우 발신 확인은 동일한 발신 번호를 갖습니다. TCP에 익숙하고 이상하게 들린다고 생각한다면 TCP에서는 seq_no 변경되지 않고 확인이 seq_no 다른 쪽-서둘러 화를냅니다. MTProto에 확인이 오고 있습니다. NOT 에 seq_no, TCP에서와 같지만 msg_id !

이게 뭔가요 msg_id, 이 분야의 가장 중요한? 이름에서 알 수 있듯이 메시지의 고유 ID입니다. 이것은 64비트 숫자로 정의되며, 최하위 비트는 다시 서버가 아닌 서버 마법을 가지며 나머지는 소수 부분을 포함하여 왼쪽으로 32비트 이동된 Unix 타임스탬프입니다. 저것들. 타임스탬프 자체(시간이 너무 다른 메시지는 서버에서 거부됨). 이것으로부터 일반적으로 이것은 클라이언트에 대해 전역적인 식별자라는 것이 밝혀졌습니다. 동안 - 기억 session_id - 우리는 다음을 보장합니다: 어떤 경우에도 한 세션을 위한 메시지를 다른 세션으로 보낼 수 없습니다.. 즉, 이미 있음이 밝혀졌습니다. 세 레벨 — 세션, 세션 번호, 메시지 ID. 왜 그렇게 복잡한지, 이 미스터리는 매우 큽니다.

따라서, msg_id 필요한…

RPC: 요청, 응답, 오류. 확인.

알다시피 스키마의 어느 곳에도 "RPC 요청 만들기"라는 특수한 유형이나 함수는 없지만 응답은 있습니다. 결국 콘텐츠 관련 메시지가 있습니다! 그건, 어떤 메시지는 요청이 될 수 있습니다! 그렇지 않으면. 결국, 각 이 msg_id. 답은 다음과 같습니다.

rpc_result#f35c6d01 req_msg_id:long result:Object = RpcResult;

이것이 어떤 메시지에 대한 응답인지 표시되는 곳입니다. 따라서 API의 최상위 수준에서 귀하의 요청이 몇 번인지 기억해야 합니다. 작업이 비동기식이며 동시에 여러 요청이 있을 수 있다는 것을 설명할 필요가 없다고 생각합니다. 어떤 순서로든 반환할 수 있습니까? 원칙적으로 이것과 작업자 없음과 같은 오류 메시지에서 이 아키텍처의 이면에 있는 아키텍처를 추적할 수 있습니다. 사용자와 TCP 연결을 유지하는 서버는 프런트 엔드 밸런서이며 요청을 백엔드로 보내고 다시 수집합니다. message_id. 여기에서는 모든 것이 명확하고 논리적이며 좋은 것 같습니다.

네?.. 그리고 생각해보면? 결국 RPC 응답 자체에도 필드가 있습니다. msg_id! 우리는 서버에서 "당신은 내 대답에 응답하지 않습니다!"라고 소리쳐야 합니까? 그리고 예, 확인에 대해 무엇이 있었습니까? 페이지 정보 메시지에 대한 메시지 무엇인지 알려줍니다

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

그리고 양쪽이 그렇게 해야 합니다. 하지만 항상 그런 것은 아닙니다! RpcResult를 받으면 자체적으로 승인 역할을 합니다. 즉, 서버는 MsgsAck로 요청에 응답할 수 있습니다. 예를 들어 "받았습니다." RpcResult에 즉시 응답할 수 있습니다. 둘 다일 수 있습니다.

그리고 네, 여전히 대답해야 합니다! 확인. 그렇지 않으면 서버에서 배달되지 않은 것으로 간주하고 다시 버립니다. 재접속 후에도. 그러나 여기서 물론 시간 초과 문제가 발생할 것입니다. 잠시 후에 살펴보겠습니다.

그동안 쿼리 실행에서 발생할 수 있는 오류를 고려해 보겠습니다.

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

오, 누군가 외칠 것입니다. 여기에 더 인간적인 형식이 있습니다. 줄이 있습니다! 천천히하세요. 여기 오류 목록그러나 확실히 완전하지는 않습니다. 그것으로부터 우리는 코드가 - 같은 것 HTTP 오류(물론 응답의 의미 체계는 존중되지 않으며 일부 위치에서는 무작위로 코드로 배포됨) 문자열은 다음과 같습니다. CAPITAL_LETTERS_AND_NUMBERS. 예: PHONE_NUMBER_OCCUPIED 또는 FILE_PART_X_MISSING. 음, 즉, 여전히 이 라인을 따라야 합니다. 구문 분석. 예를 들어, FLOOD_WAIT_3600 XNUMX시간을 기다려야 한다는 뜻이고, PHONE_MIGRATE_5이 프리픽스가 있는 전화번호는 5번째 DC에 등록되어야 합니다. 타입 언어가 있죠? 문자열에서 인수가 필요하지 않습니다. 정규식을 사용하면 됩니다.

다시 말하지만 이것은 서비스 메시지 페이지에 없지만 이 프로젝트에서 이미 관례적으로 정보를 찾을 수 있습니다. 다른 문서 페이지에서. 또는 의심을 불러일으키다. 먼저, 타이핑/레이어 위반 - RpcError 에 투자할 수 있다 RpcResult. 밖에선 왜 안돼? 우리는 무엇을 고려하지 않았습니까?.. 따라서 보장은 어디에 있습니까? RpcError 에 투자하지 않을 수 있습니다 RpcResult, 그러나 다른 유형에 직접 또는 중첩되어 있습니까? 부족하다 req_msg_id ? ..

그러나 서비스 메시지에 대해 계속합시다. 클라이언트는 서버가 오랫동안 생각하고 있다고 생각하고 멋진 요청을 할 수 있습니다.

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

세 가지 대답이 가능하며, 다시 확인 메커니즘과 교차하여 무엇이 되어야 하는지(및 일반적으로 확인이 필요하지 않은 유형의 목록은 무엇인지) 이해하려고 시도하면 독자는 숙제로 남습니다(참고: Telegram Desktop 소스의 정보가 완전하지 않음).

중독: 메시지 게시물 상태

일반적으로 TL, MTProto 및 Telegram의 많은 곳은 일반적으로 완고한 느낌을 남기지 만 공손함, 재치 및 기타 소프트 스킬 우리는 그것에 대해 정중하게 침묵을 지켰고 대화의 음란물은 검열되었습니다. 그러나, 이 장소О페이지의 대부분 메시지에 대한 메시지 오랫동안 네트워크 프로토콜로 작업하고 다양한 곡률의 자전거를 본 나에게도 충격을줍니다.

확인과 함께 무해하게 시작됩니다. 다음으로 우리는

bad_msg_notification#a7eff811 bad_msg_id:long bad_msg_seqno:int error_code:int = BadMsgNotification;
bad_server_salt#edab447b bad_msg_id:long bad_msg_seqno:int error_code:int new_server_salt:long = BadMsgNotification;

음, MTProto로 작업을 시작하는 모든 사람은 "수정 - 재컴파일 - 시작" 주기에서 수정 중에 썩은 숫자 오류 또는 솔트를 얻는 것이 일반적입니다. 그러나 여기에는 두 가지 사항이 있습니다.

1. 원본 메시지가 손실됩니다. 일부 대기열을 차단해야 합니다. 나중에 고려할 것입니다.
2. 그 이상한 오류 번호는 무엇입니까? 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 64… 나머지 숫자는 어디에 있습니까, 토미?

설명서에는 다음과 같이 명시되어 있습니다.

의도는 error_code 값이 그룹화되는 것입니다(error_code >> 4). 예를 들어 코드 0x40 - 0x4f는 컨테이너 분해의 오류에 해당합니다.

그러나 첫 번째는 다른 방향으로의 이동이고 두 번째는 나머지 코드가 어디에 있는지는 중요하지 않습니까? 작가의 머리 속에?.. 그러나 이것들은 사소한 일입니다.

중독은 게시물 상태 메시지와 게시물 사본에서 시작됩니다.

• 메시지 상태 정보 요청
  한 당사자가 한동안 발신 메시지 상태에 대한 정보를 받지 못한 경우 상대방에게 명시적으로 요청할 수 있습니다.
  msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;
• 메시지 상태에 관한 정보 메시지
  msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;
  여기 info 들어오는 msg_ids 목록의 각 메시지에 대해 정확히 XNUMX바이트의 메시지 상태를 포함하는 문자열입니다.
  • 1 = 메시지에 대해 알려진 것이 없음(msg_id가 너무 낮음, 상대방이 잊어버렸을 수 있음)
  • 2 = 메시지가 수신되지 않음(msg_id는 저장된 식별자 범위에 속하지만 상대방은 확실히 그러한 메시지를 수신하지 않음)
  • 3 = 메시지가 수신되지 않음(msg_id가 너무 높지만 상대방이 아직 수신하지 않은 것이 확실함)
  • 4 = 메시지 수신됨(이 응답은 동시에 수신 확인이기도 함)
  • +8 = 이미 확인된 메시지
  • +16 = 승인이 필요하지 않은 메시지
  • +32 = 처리 중이거나 처리가 이미 완료된 메시지에 포함된 RPC 쿼리
  • +64 = 이미 생성된 메시지에 대한 콘텐츠 관련 응답
  • +128 = 상대방이 메시지가 이미 수신되었다는 사실을 알고 있음
    이 응답에는 승인이 필요하지 않습니다. 관련 msgs_state_req 자체에 대한 승인입니다.
    갑자기 상대방에게 보낸 것처럼 보이는 메시지가 없는 경우 메시지를 다시 보낼 수 있습니다. 상대방이 동시에 두 개의 메시지 사본을 수신하더라도 중복 메시지는 무시됩니다. (너무 많은 시간이 경과하여 원래 msg_id가 더 이상 유효하지 않은 경우 메시지는 msg_copy로 래핑됩니다.)
• 메시지 현황 자발적 전달
  각 당사자는 상대방이 전송한 메시지의 상태를 자발적으로 상대방에게 알릴 수 있습니다.
  msgs_all_info#8cc0d131 msg_ids:Vector long info:string = MsgsAllInfo
• 하나의 메시지 상태에 대한 확장된 자발적 통신
  ...
  msg_detailed_info#276d3ec6 msg_id:long answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
msg_new_detailed_info#809db6df answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
• 메시지 재전송에 대한 명시적 요청
  msg_resend_req#7d861a08 msg_ids:Vector long = MsgResendReq;
  원격 당사자는 요청된 메시지를 다시 전송하여 즉시 응답 [...]
• 답변 재전송에 대한 명시적 요청
  msg_resend_ans_req#8610baeb msg_ids:Vector long = MsgResendReq;
  원격 당사자는 즉시 재전송하여 응답합니다. 답변 요청된 메시지에 […]
• 메시지 사본
  경우에 따라 더 이상 유효하지 않은 msg_id가 있는 이전 메시지를 다시 보내야 합니다. 그런 다음 복사 컨테이너에 래핑됩니다.
  msg_copy#e06046b2 orig_message:Message = MessageCopy;
  수신되면 메시지는 래퍼가 없는 것처럼 처리됩니다. 그러나 orig_message.msg_id 메시지가 수신된 것이 확실한 경우 새 메시지는 처리되지 않습니다(동시에 해당 메시지와 orig_message.msg_id가 확인됨). orig_message.msg_id의 값은 컨테이너의 msg_id보다 작아야 합니다.

사실에 대해서도 침묵을 지킵시다. msgs_state_info 다시, 미완성 TL의 귀가 튀어나옵니다(우리는 바이트 벡터가 필요했고 enum의 하위 두 비트와 이전 비트 플래그에 필요했습니다). 요점은 다른 것입니다. 이 모든 것이 실제로 실행되는 이유를 이해하는 사람이 있습니까? 실제 클라이언트에서 필요한가요?.. 어려움이 있지만 사람이 디버깅에 참여하고 대화식 모드에서 서버에 무엇을 어떻게 물어보면 어떤 이점이 있는지 상상할 수 있습니다. 그러나 요청은 여기에 설명되어 있습니다. 왕복 여행.

따라서 각 측은 메시지를 암호화하고 보낼 뿐만 아니라 메시지에 대한 데이터, 메시지에 대한 답변 및 알 수 없는 시간 동안 데이터를 저장해야 합니다. 설명서에는 이러한 기능의 타이밍이나 실제 적용 가능성이 설명되어 있지 않습니다. 어떠한 방식으로. 가장 놀라운 것은 실제로 공식 클라이언트의 코드에서 사용된다는 것입니다! 분명히 그들은 공개 문서에 포함되지 않은 내용을 들었습니다. 코드에서 이해 이유, 더 이상 TL의 경우처럼 단순하지 않습니다. 이것은 (비교적으로) 논리적으로 분리된 부분이 아니라 애플리케이션 아키텍처에 연결된 부분입니다. 애플리케이션 코드를 이해하는 데 훨씬 더 많은 시간이 필요합니다.

핑과 타이밍. 대기열.

모든 것에서 서버 아키텍처(백엔드 간 요청 배포)에 대한 추측을 기억하면 다소 둔한 일이 뒤따릅니다. TCP의 모든 전달 보장에도 불구하고(데이터가 전달되거나 중단되지만 문제가 발생하는 순간까지 데이터가 전달됩니다), MTProto 자체에서 확인- 보장 없음. 서버는 쉽게 메시지를 잃거나 버릴 수 있으며 다양한 유형의 목발을 막는 것 외에는 아무것도 할 수 없습니다.

그리고 무엇보다도 - 메시지 큐. 글쎄요, 한 가지는 처음부터 모든 것이 분명했습니다. 확인되지 않은 메시지는 저장하고 다시 보내야 합니다. 그리고 몇시에? 그리고 광대는 그를 알고 있습니다. 아마도 이러한 중독자 서비스 메시지는 목발로이 문제를 어떻게 든 해결할 수 있습니다. 예를 들어 Telegram Desktop에는 이에 해당하는 약 4 개의 대기열이 있습니다 (아마도 이미 언급했듯이 더 많을 수 있으므로 코드와 아키텍처를 더 진지하게 조사해야합니다. 동시에 시간, 우리는 샘플로 사용할 수 없으며 MTProto 체계의 특정 유형이 사용되지 않는다는 것을 알고 있습니다.

왜 이런 일이 발생합니까? 아마도 서버 프로그래머가 클러스터 내에서 안정성을 보장하지 못하거나 적어도 프론트 밸런서에서 버퍼링조차 할 수 없었고 이 문제를 클라이언트로 옮겼을 것입니다. 필사적으로 Vasily는 TCP의 알고리즘을 사용하여 두 개의 대기열만 있는 대체 옵션을 구현하려고 시도했습니다. 즉, 서버에 대한 RTT를 측정하고 승인되지 않은 요청 수에 따라 "창" 크기(메시지에서)를 조정하는 것입니다. 즉, 서버 부하를 추정하기 위한 대략적인 휴리스틱입니다. 동시에 씹을 수 있고 잃지 않을 수 있는 요청 수입니다.

글쎄요, 이해하시겠죠? TCP를 통해 작동하는 프로토콜 위에 TCP를 다시 구현해야 한다면 이는 매우 잘못 설계된 프로토콜을 나타냅니다.

네, 왜 둘 이상의 대기열이 필요하며 일반적으로 이것이 고수준 API로 작업하는 사람에게 무엇을 의미합니까? 보세요, 요청을 하고 직렬화하지만 즉시 보내는 것이 불가능한 경우가 많습니다. 왜? 대답이 될 것이기 때문에 msg_id, 일시적인а나는 약속을 가능한 한 늦게 연기하는 것이 더 좋은 레이블입니다. 우리와 그것 사이의 시간 불일치로 인해 갑자기 서버가 거부합니다 (물론 우리는 시간을 현재에서 이동시키는 버팀목을 만들 수 있습니다. 서버 응답에서 계산된 델타를 추가하여 서버 시간에 - 공식 클라이언트가 이 작업을 수행하지만 이 방법은 버퍼링으로 인해 조잡하고 부정확합니다. 따라서 라이브러리에서 로컬 함수 호출로 요청하면 메시지는 다음 단계를 거칩니다.

1. 동일한 대기열에 있으며 암호화를 기다리고 있습니다.
2. 정해진 msg_id 메시지는 다른 대기열로 이동했습니다. 가능한 전달; 소켓으로 보냅니다.
3. a) 서버가 MsgsAck에 응답했습니다. 메시지가 전달되었으므로 "다른 대기열"에서 삭제합니다.
   b) 또는 그 반대의 경우, 그는 무언가를 좋아하지 않았고 badmsg라고 대답했습니다. 우리는 "다른 대기열"에서 다시 보냅니다.
   c) 알려진 바가 없으므로 다른 큐에서 메시지를 다시 보내야 하지만 정확히 언제인지는 알 수 없습니다.
4. 서버가 마침내 응답함 RpcResult - 실제 응답(또는 오류) - 전달되었을 뿐만 아니라 처리되었습니다.

어쩌면, 컨테이너를 사용하면 부분적으로 문제를 해결할 수 있습니다. 이것은 많은 메시지가 하나로 압축되고 서버가 한 번에 모두에 대한 승인으로 응답하는 경우입니다. msg_id. 그러나 그는 또한 이 팩을 거부할 것입니다. 문제가 발생하면 전체도 거부합니다.

그리고 이 시점에서 비기술적 고려 사항이 작용합니다. 경험을 통해 우리는 많은 목발을 보았고 이제 나쁜 조언과 아키텍처의 더 많은 예를 보게 될 것입니다. 이러한 조건에서 그러한 결정을 신뢰하고 내릴 가치가 있습니까? 질문은 수사적입니다(물론 아닙니다).

우리는 무엇에 대해 이야기하고 있습니까? "메시지에 대한 중독성 메시지"라는 주제에 대해 "당신은 멍청하고 우리의 훌륭한 아이디어를 이해하지 못했습니다! "와 같은 반대 의견으로 여전히 추측 할 수 있습니다. (그러므로 먼저 일반 사람들이 해야 하는 것처럼 이론적 근거와 패킷 교환 예제를 사용하여 문서를 작성하고 나서 이야기하겠습니다) 타이밍/시간 초과는 순전히 실용적이고 구체적인 문제이며 모든 것이 여기에서 오랫동안 알려져 왔습니다. 그러나 설명서는 시간 초과에 대해 무엇을 알려 줍니까?

서버는 일반적으로 RPC 응답을 사용하여 클라이언트로부터 메시지(일반적으로 RPC 쿼리) 수신을 확인합니다. 응답이 오래 걸리는 경우 서버는 먼저 수신 확인을 보내고 다소 나중에 RPC 응답 자체를 보낼 수 있습니다.

클라이언트는 일반적으로 메시지가 너무 늦게 전송되지 않은 경우(예: 수신 후 60-120초 후에 생성된 경우) 다음 RPC 쿼리에 승인을 추가하여 서버로부터 메시지(일반적으로 RPC 응답) 수신을 승인합니다. 서버에서 보낸 메시지). 그러나 오랜 기간 동안 서버에 메시지를 보낼 이유가 없거나 서버에서 승인되지 않은 메시지가 많은 경우(예: 16개 이상) 클라이언트는 독립 실행형 승인을 전송합니다.

... 나는 번역합니다 : 우리는 그것이 얼마나 필요한지, 어떻게 필요한지 모릅니다. 음, 이렇게되도록 추정합시다.

핑 정보:

핑 메시지(PING/PONG)

ping#7abe77ec ping_id:long = Pong;

응답은 일반적으로 동일한 연결로 반환됩니다.

pong#347773c5 msg_id:long ping_id:long = Pong;

이러한 메시지에는 승인이 필요하지 않습니다. Pong은 Ping에 대한 응답으로만 전송되며 Ping은 양쪽에서 시작할 수 있습니다.

지연된 연결 폐쇄 + PING

ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

핑처럼 작동합니다. 또한 이 메시지를 수신한 후 서버는 모든 이전 타이머를 자동으로 재설정하는 동일한 유형의 새 메시지를 수신하지 않는 한 disconnect_delay초 후에 현재 연결을 닫는 타이머를 시작합니다. 예를 들어 클라이언트가 60초마다 한 번씩 이러한 ping을 보내는 경우 disconnect_delay를 75초로 설정할 수 있습니다.

당신 미쳤어?! 60초 안에 기차는 역에 진입하여 승객을 내리고 태우고 터널에서 다시 연결이 끊깁니다. 120초 안에 주변을 찌르는 동안 그는 다른 사람에게 도착하고 연결이 끊어질 가능성이 높습니다. 음, 다리가 어디에서 자라는지는 분명합니다. "울리는 소리가 들리지만 어디 있는지 모르겠습니다." 대화식 작업을위한 Nagle 알고리즘과 TCP_NODELAY 옵션이 있습니다. 하지만 죄송합니다. 기본값인 200을 지연시키세요. 밀리초. 정말로 비슷한 것을 묘사하고 가능한 몇 개의 패킷을 절약하고 싶다면 - 음, 적어도 5초 동안 연기하거나 "사용자가 입력 중입니다..." 메시지의 시간 제한이 무엇이든 간에 지금이 무엇이든 연기하십시오. 하지만 더 이상.

그리고 마지막으로 핑. 즉, TCP 연결의 활성 상태를 확인합니다. 재밌지 만 약 10 년 전에 저는 우리 교수진 호스텔 메신저에 대한 비판적인 텍스트를 썼습니다. 그곳에서 저자도 클라이언트에서 서버를 핑했고 그 반대는 아닙니다. 근데 3학년도 그렇고, 국제사무소는 또 다른거죠? ..

첫째, 소규모 교육 프로그램입니다. 패킷 교환이 없는 TCP 연결은 몇 주 동안 지속될 수 있습니다. 이것은 목적에 따라 좋기도 하고 나쁘기도 합니다. 글쎄, 서버에 대한 SSH 연결이 열려 있으면 컴퓨터에서 일어나 파워 라우터를 재부팅하고 제자리로 돌아 왔습니다. 이 서버를 통한 세션은 중단되지 않았습니다 (아무것도 입력하지 않았고 패킷도 없었습니다). 편리한. 서버에 수천 개의 클라이언트가 있고 각 클라이언트가 리소스를 차지하고(안녕하세요 Postgres!) 클라이언트 호스트가 오래 전에 재부팅되었을 수 있지만 우리는 그것에 대해 알 수 없습니다.

채팅/IM 시스템은 또 다른 추가 이유인 온라인 상태로 인해 두 번째 경우에 속합니다. 사용자가 "떨어졌다"면 대화 상대에게 알려야합니다. 그렇지 않으면 Jabber의 제작자가 만든(그리고 20년 동안 수정된) 실수가 있을 것입니다. 사용자의 연결이 끊어졌지만 사용자는 그가 온라인 상태라고 믿고 계속해서 그에게 메시지를 씁니다(몇 분 전에 완전히 손실됨). 휴식이 발견되었습니다). 아니요, TCP 타이머의 작동 방식을 이해하지 못하는 많은 사람들이 어디에서나 튀어 나오는 TCP_KEEPALIVE 옵션(수십 초와 같은 야생 값 설정)은 여기에서 도움이 되지 않습니다. 사용자의 컴퓨터는 살아 있지만 응답할 수 있고 응용 프로그램 자체도 정상적으로 작동합니다(정지할 수 없다고 생각하십니까? Ubuntu 18.04의 Telegram Desktop이 반복적으로 충돌했습니다).

그렇기 때문에 ping을 해야 합니다. 서버 그 반대가 아닌 클라이언트 - 클라이언트가 이렇게 하면 연결이 끊어지면 핑이 전달되지 않고 목표가 달성되지 않습니다.

Telegram에서 무엇을 볼 수 있습니까? 모든 것이 정반대입니다! 음, 즉 물론 공식적으로 양측은 서로 핑할 수 있습니다. 실제로 클라이언트는 목발을 사용합니다. ping_delay_disconnect, 서버의 타이머를 작동시킵니다. 음, 죄송합니다. 고객이 핑 없이 그곳에서 얼마나 오래 살고 싶은지 결정하는 것은 고객의 일이 아닙니다. 부하에 따라 서버가 더 잘 압니다. 그러나 물론 자원에 대해 미안하다고 느끼지 않으면 그들은 사악한 피노키오 자체이며 목발이 내려올 것입니다 ...

어떻게 설계했어야 할까요?

위의 사실은 전송 (및 하위) 수준의 컴퓨터 네트워크 분야에서 Telegram / VKontakte 팀의 역량이 그다지 높지 않고 관련 문제에 대한 자격이 낮음을 분명히 나타냅니다.

왜 그렇게 복잡해졌으며 Telegram 설계자는 어떻게 이의를 제기할 수 있습니까? TCP 연결이 끊어져도 살아남는 세션을 만들려고 했다는 사실, 즉 지금 전달하지 못한 것은 나중에 전달하겠습니다. 그들은 또한 UDP 전송을 시도했지만 어려움에 부딪혀 포기했지만 (문서가 비어있는 이유입니다. 자랑 할 것이 없었습니다). 그러나 일반적으로 네트워크와 특히 TCP가 어떻게 작동하는지, 어디에 의존할 수 있는지, 어디서 직접 수행해야 하는지(및 방법)에 대한 이해 부족으로 인해 "one shot of two" 암호화와 결합하려는 시도가 있습니다. 하나의 돌을 가진 새”-그런 시체가 나왔습니다.

어땠어야 했나? 사실에 근거 msg_id 재생 공격을 방지하기 위해 암호학적으로 필요한 타임스탬프에 고유 식별자 기능을 붙이는 것은 오류입니다. 따라서 현재 아키텍처를 크게 변경하지 않고(업데이트 스레드가 형성될 때 이것은 이 게시물 시리즈의 다른 부분에 대한 상위 수준 API 주제임) 다음을 수행해야 합니다.

1. 클라이언트에 대한 TCP 연결을 유지하는 서버가 책임을 집니다. 소켓에서 빼거나 ​​확인, 처리 또는 오류를 반환하면 손실이 없습니다. 그런 다음 확인이 되는 것은 id의 벡터가 아니라 단순히 "마지막으로 수신된 seq_no"입니다. TCP에서와 같이 숫자일 뿐입니다(XNUMX개의 숫자 - 자신의 seq와 확인됨). 우리는 항상 회의 중입니다, 그렇죠?
2. 재생 공격을 방지하기 위한 타임스탬프는 별도의 필드인 la nonce가 됩니다. 선택했지만 다른 것은 영향을 받지 않습니다. 충분하고 uint32 - 소금이 적어도 반나절마다 변경되면 현재 시간의 정수 부분의 하위 비트에 16비트를 할당하고 나머지는 초의 소수 부분에 할당할 수 있습니다(지금처럼).
3. 철회됨 msg_id 전혀-백엔드에서 요청을 구별하는 관점에서 볼 때 첫 번째로 클라이언트 ID가 있고 두 번째로 세션 ID가 있으며 연결합니다. 따라서 요청 식별자는 하나만 있으면 충분합니다. seq_no.

또한 최선의 선택은 아니지만 완전한 무작위가 식별자 역할을 할 수 있습니다. 그런데 이것은 메시지를 보낼 때 상위 수준 API에서 이미 수행됩니다. 아키텍처를 상대에서 절대으로 모두 변경하면 더 좋겠지만, 이것은 이 게시물이 아닌 다른 부분에 대한 주제입니다.

API?

따담! 그래서 고통과 목발로 가득 찬 길을 통과한 우리는 마침내 서버에 요청을 보내고 응답을 받을 수 있을 뿐만 아니라 서버에서 업데이트를 받을 수 있었습니다(요청에 대한 응답이 아니라 누군가가 훨씬 더 명확하다면 PUSH와 같은 자체를 우리에게 보냅니다).

주의, 이제 기사에 Perl 예제만 있을 것입니다! (구문에 익숙하지 않은 사람들을 위해 bless의 첫 번째 인수는 객체의 데이터 구조이고 두 번째 인수는 클래스입니다):

2019.10.24 12:00:51 $1 = {
'cb' => 'TeleUpd::__ANON__',
'out' => bless( {
'filter' => bless( {}, 'Telegram::ChannelMessagesFilterEmpty' ),
'channel' => bless( {
'access_hash' => '-6698103710539760874',
'channel_id' => '1380524958'
}, 'Telegram::InputPeerChannel' ),
'pts' => '158503',
'flags' => 0,
'limit' => 0
}, 'Telegram::Updates::GetChannelDifference' ),
'req_id' => '6751291954012037292'
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'req_msg_id' => '6751291954012037292',
'result' => bless( {
'pts' => 158508,
'flags' => 3,
'final' => 1,
'new_messages' => [],
'users' => [],
'chats' => [
bless( {
'title' => 'Хулиномика',
'username' => 'hoolinomics',
'flags' => 8288,
'id' => 1380524958,
'access_hash' => '-6698103710539760874',
'broadcast' => 1,
'version' => 0,
'photo' => bless( {
'photo_small' => bless( {
'volume_id' => 246933270,
'file_reference' => '
'secret' => '1854156056801727328',
'local_id' => 228648,
'dc_id' => 2
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'local_id' => 228650,
'file_reference' => '
'secret' => '1275570353387113110',
'volume_id' => 246933270
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1531221081
}, 'Telegram::Channel' )
],
'timeout' => 300,
'other_updates' => [
bless( {
'pts_count' => 0,
'message' => bless( {
'post' => 1,
'id' => 852,
'flags' => 50368,
'views' => 8013,
'entities' => [
bless( {
'length' => 20,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 18,
'offset' => 480,
'url' => 'https://alexeymarkov.livejournal.com/[url_вырезан].html'
}, 'Telegram::MessageEntityTextUrl' )
],
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'text' => '???? 165',
'data' => 'send_reaction_0'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 9'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'message' => 'А вот и новая книга! 
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
напечатаю.',
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571724559,
'edit_date' => 1571907562
}, 'Telegram::Message' ),
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'message' => bless( {
'edit_date' => 1571907589,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571807301,
'message' => 'Почему Вы считаете Facebook плохой компанией? Можете прокомментировать? По-моему, это шикарная компания. Без долгов, с хорошей прибылью, а если решат дивы платить, то и еще могут нехило подорожать.
Для меня ответ совершенно очевиден: потому что Facebook делает ужасный по качеству продукт. Да, у него монопольное положение и да, им пользуется огромное количество людей. Но мир не стоит на месте. Когда-то владельцам Нокии было смешно от первого Айфона. Они думали, что лучше Нокии ничего быть не может и она навсегда останется самым удобным, красивым и твёрдым телефоном - и доля рынка это красноречиво демонстрировала. Теперь им не смешно.
Конечно, рептилоиды сопротивляются напору молодых гениев: так Цукербергом был пожран Whatsapp, потом Instagram. Но всё им не пожрать, Паша Дуров не продаётся!
Так будет и с Фейсбуком. Нельзя всё время делать говно. Кто-то когда-то сделает хороший продукт, куда всё и уйдут.
#соцсети #facebook #акции #рептилоиды',
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 452'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'text' => '???? 21',
'data' => 'send_reaction_1'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'entities' => [
bless( {
'length' => 199,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 8,
'offset' => 919
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 928,
'length' => 9
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 6,
'offset' => 938
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 11,
'offset' => 945
}, 'Telegram::MessageEntityHashtag' )
],
'views' => 6964,
'flags' => 50368,
'id' => 854,
'post' => 1
}, 'Telegram::Message' ),
'pts_count' => 0
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'message' => bless( {
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 213'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 8'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 2940,
'entities' => [
bless( {
'length' => 609,
'offset' => 348
}, 'Telegram::MessageEntityItalic' )
],
'flags' => 50368,
'post' => 1,
'id' => 857,
'edit_date' => 1571907636,
'date' => 1571902479,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'message' => 'Пост про 1С вызвал бурную полемику. Человек 10 (видимо, 1с-программистов) единодушно написали:
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
Я бы добавил, что блестящая у 1С дистрибуция, а маркетинг... ну, такое.'
}, 'Telegram::Message' ),
'pts_count' => 0,
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'pts_count' => 0,
'message' => bless( {
'message' => 'Здравствуйте, расскажите, пожалуйста, чем вредит экономике 1С?
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
#софт #it #экономика',
'edit_date' => 1571907650,
'date' => 1571893707,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'flags' => 50368,
'post' => 1,
'id' => 856,
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 360'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 32'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 4416,
'entities' => [
bless( {
'offset' => 0,
'length' => 64
}, 'Telegram::MessageEntityBold' ),
bless( {
'offset' => 1551,
'length' => 5
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 3,
'offset' => 1557
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 1561,
'length' => 10
}, 'Telegram::MessageEntityHashtag' )
]
}, 'Telegram::Message' )
}, 'Telegram::UpdateEditChannelMessage' )
]
}, 'Telegram::Updates::ChannelDifference' )
}, 'MTProto::RpcResult' )
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'update' => bless( {
'user_id' => 2507460,
'status' => bless( {
'was_online' => 1571907651
}, 'Telegram::UserStatusOffline' )
}, 'Telegram::UpdateUserStatus' ),
'date' => 1571907650
}, 'Telegram::UpdateShort' )
};
2019.10.24 12:05:46 $1 = {
'in' => bless( {
'chats' => [],
'date' => 1571907946,
'seq' => 0,
'updates' => [
bless( {
'max_id' => 141719,
'channel_id' => 1295963795
}, 'Telegram::UpdateReadChannelInbox' )
],
'users' => []
}, 'Telegram::Updates' )
};
2019.10.24 13:01:23 $1 = {
'in' => bless( {
'server_salt' => '4914425622822907323',
'unique_id' => '5297282355827493819',
'first_msg_id' => '6751307555044380692'
}, 'MTProto::NewSessionCreated' )
};
2019.10.24 13:24:21 $1 = {
'in' => bless( {
'chats' => [
bless( {
'username' => 'freebsd_ru',
'version' => 0,
'flags' => 5440,
'title' => 'freebsd_ru',
'min' => 1,
'photo' => bless( {
'photo_small' => bless( {
'local_id' => 328733,
'volume_id' => 235140688,
'dc_id' => 2,
'file_reference' => '
'secret' => '4426006807282303416'
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'file_reference' => '
'volume_id' => 235140688,
'local_id' => 328735,
'secret' => '71251192991540083'
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1461248502,
'id' => 1038300508,
'democracy' => 1,
'megagroup' => 1
}, 'Telegram::Channel' )
],
'users' => [
bless( {
'last_name' => 'Panov',
'flags' => 1048646,
'min' => 1,
'id' => 82234609,
'status' => bless( {}, 'Telegram::UserStatusRecently' ),
'first_name' => 'Dima'
}, 'Telegram::User' )
],
'seq' => 0,
'date' => 1571912647,
'updates' => [
bless( {
'pts' => 137596,
'message' => bless( {
'flags' => 256,
'message' => 'Создать джейл с именем покороче ??',
'to_id' => bless( {
'channel_id' => 1038300508
}, 'Telegram::PeerChannel' ),
'id' => 119634,
'date' => 1571912647,
'from_id' => 82234609
}, 'Telegram::Message' ),
'pts_count' => 1
}, 'Telegram::UpdateNewChannelMessage' )
]
}, 'Telegram::Updates' )
};

예, 특히 스포일러 아래에 있지 않습니다. 읽지 않았다면 가서 해보세요!

오와이~~... 어때요? 매우 친숙한 것… 아마도 클래스가 개체에 첨부된 것을 제외하고는 JSON의 일반적인 웹 API의 데이터 구조일까요?..

그래서 밝혀졌습니다 ... 그게 뭐야, 동지들? .. 너무 많은 노력-그리고 우리는 웹 프로그래머가 쉬는 곳에서 멈췄습니다. 막 시작?.. HTTPS를 통한 JSON이 더 쉬울까요?! 그리고 우리는 그 대가로 무엇을 얻었습니까? 이러한 노력이 가치가 있었습니까?

TL+MTProto가 우리에게 제공한 것과 가능한 대안이 무엇인지 평가해 봅시다. 글쎄, HTTP 요청-응답은 적합하지 않지만 적어도 TLS 위에 뭔가 있습니까?

컴팩트 직렬화. JSON과 유사한 이 데이터 구조를 보면 바이너리 변형이 있음을 기억합니다. MsgPack을 확장성이 충분하지 않은 것으로 표시하지만 예를 들어 CBOR이 있습니다. RFC 7049. 정의하고 있다는 점에서 주목할 만하다. 태그들, 확장 메커니즘으로, 그리고 이미 표준화 있습니다 :

• 25 + 256 - 저렴한 압축 방법과 같은 중복 행을 행 번호 참조로 교체
• 26 - 클래스 이름과 생성자 인수가 있는 직렬화된 Perl 객체
• 27 - 유형 이름 및 생성자 인수가 있는 직렬화된 언어 독립 객체

글쎄, 나는 문자열과 개체의 패킹이 활성화된 상태에서 TL과 CBOR에서 동일한 데이터를 직렬화하려고 했습니다. 결과는 메가바이트 어딘가에서 CBOR에 유리하게 달라지기 시작했습니다.

cborlen=1039673 tl_len=1095092

따라서, 결론: 동기화 실패 또는 알 수 없는 식별자 문제가 발생하지 않고 효율성이 비슷한 훨씬 간단한 형식이 있습니다.

빠른 연결 설정. 즉, 재연결 후(키가 이미 한 번 생성된 경우) RTT가 XNUMX임을 의미합니다. 첫 번째 MTProto 메시지에서 적용할 수 있지만 일부 예약이 있는 경우 동일한 솔트에 들어갔고 세션이 썩지 않았습니다. TLS는 그 대가로 무엇을 제공합니까? 관련 인용문:

TLS에서 PFS를 사용하는 경우 TLS 세션 티켓(RFC 5077) 키를 재협상하지 않고 서버에 키 정보를 저장하지 않고 암호화된 세션을 재개합니다. 첫 번째 연결을 열고 키를 생성할 때 서버는 연결 상태를 암호화하여 세션 티켓 형식으로 클라이언트에 보냅니다. 따라서 연결이 재개되면 클라이언트는 무엇보다도 세션 키가 포함된 세션 티켓을 서버로 다시 보냅니다. 티켓 자체는 서버에 저장되는 임시 키(세션 티켓 키)로 암호화되며 클러스터 솔루션에서 SSL을 처리하는 모든 프런트엔드 서버에 배포되어야 합니다.[10]. 따라서 임시 서버 키가 손상된 경우(예: OpenSSL, nginx, Apache는 기본적으로 프로그램이 실행되는 전체 시간 동안 키를 저장합니다. 인기 사이트) 키를 몇 시간, 최대 며칠 동안 사용).

여기서 RTT는 XNUMX이 아니므로 적어도 ClientHello와 ServerHello를 교환해야 합니다. 그 후에 Finished와 함께 클라이언트는 이미 데이터를 보낼 수 있습니다. 그러나 여기에서 우리는 새로 열린 연결이 많은 웹이 아니라 연결이 종종 하나 이상의 수명이 길고 상대적으로 짧은 웹 페이지 요청 인 메신저를 가지고 있음을 기억해야합니다. 내부에 다중화. 즉, 매우 나쁜 지하철 구간을 만나지 않았다면 상당히 수용 가능합니다.

다른 것을 잊으셨습니까? 의견을 작성하십시오.

계속!

이 게시물 시리즈의 두 번째 부분에서는 접근 방식, 이데올로기, 인터페이스, 사용자에 대한 태도 등 기술적 문제가 아닌 조직적 문제를 고려할 것입니다. 그러나 여기에 제시된 기술 정보를 기반으로 합니다.

세 번째 부분에서는 기술 구성 요소/개발 경험에 대한 분석을 계속합니다. 특히 다음을 배우게 됩니다.

• 다양한 TL 유형으로 대유행의 지속
• 채널 및 슈퍼그룹에 대한 알려지지 않은 사항
• 대화보다 명단보다 나쁩니다.
• 절대 메시지 주소 지정과 상대 메시지 주소 지정 정보
• 사진과 이미지의 차이점은 무엇입니까
• 그림 이모티콘이 이탤릭체 텍스트를 방해하는 방법

그리고 다른 목발! 계속 지켜봐!

출처 : habr.com