TCP передача (транспорт)

Очень схожа с передачей HTTP. Может так же быть осуществлена посредством Порта 80 (Port 80) (чтобы проникнуть через все фаерволы) и даже использовать те же сервера IP адресов. В этой ситуации, сервер понимает, какой протокол нужно использовать - HTTP или TCP - основываясь на первых четырёх входящих байтах (для HTTP это POST).

Когда создано TCP-соединение, оно приписывается сессии (и ключу авторизации), переданной в первом сообщении юзера, и в дальнейшем используется исключительно для этой сессии (составные механизмы не разрешены).

Если payload (пакет) нужно передать от сервера к клиенту или от клиента к серверу, это выражается таким образом: 4 байта длины добавляются впереди (содержащие в себе длину, порядковый номер и CRC32; всегда делятся на 4) и 4 байта с порядковым номером пакета внутри TCP-соединения (первый отправленный пакет нумеруется как 0, следующий - как 1, и т.д.) и 4 CRC32 байта в конце (длина, порядковый номер, и payload вместе).

Есть сокращённая версия этого же протокола: если клиент отправляет 0xef как первый байт (**важно:** только перед самым первым пакетом данных), то тогда длина пакета кодируется одним байтом (0x01..0x7e = длина данных разделённая/ делящаяся на/ кратная 4; или 0x7f после которого следуют 3 байта длины (little endian) кратным 4) после чего следуют собственно данные (порядковый номер и CRC32 не добавляется). В этом случае ответы сервера выглядят точно так же (сервер не отправляет 0xef как первый байт).

В случае, если требуется выравнивание 4-байтовых данных, может быть использована промежуточная версия оригинального протокола: если клиент отправляет 0xeeeeeeee как первый инт (int) (четыре байта), то длина пакета зашифрована всегда четырьмя байтами как в оригинальной версии, но порядковый номер и CRC32 опускаются, таким образом уменьшая итоговый /общий размер пакета на 8 байт.

Полная, промежуточная и сокращённая версии протокола поддерживаются для быстрого подтверждения. В этом случае клиент устанавливает бит длины наивысшего порядка в пакет запроса, и сервер отвечает специальными четырьмя байтами в виде отдельного пакета. Это 32 бита SHA1 высшего порядка зашифрованной части пакета, с самым важным / значимым битом, установленным, чтобы пояснить, что это не длина обыкновенного пакета ответа сервера; если используется упрощённая версия, для этих четырёх байт применяется bswap.

Не существует неявного / скрытого подтверждения для TCP-передачи: все сообщения должны быть подтверждены точно. Чаще всего подтверждения помещают в контейнер с следующим запросом или ответом, если он передаётся в упрощённом порядке. Например, это почти всегда происходит с сообщениями клиента, содержащими RPC-запросы: подтверждение обычно приходит вместе с RPC-ответом.

В случае ошибки, сервер может отправить пакет в котором payload состоит из 4 байт, которые являются кодом ошибки. Например, Код Ошибки 403 соответствует ситуациям, когда сответствующая ошибка HTTP возвращена HTTP-протоколом.


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: