Почему telnet считается протоколом? Разве это не простая программа TCP send/echo?

A sub-system called "Telnet" is proposed which is a shell program around the network system primitives, allowing a teletype or similar terminal at a remote host to function as a teletype at the serving host.

Это из RFC 15, который упоминается в википедии "telnet". Эта статья также начинается с того, что telnet называется «протокол приложения ».

RFC 15 от сентября 1969 года -всего несколько дней назад я услышал интересное интервью с парнем, который ровно 50 лет назад установил первое "интернет-соединение". Его история была такой:

«В отличие от Н. Армстронга, мы не подумали ни о каком специальном сообщении. Но после ввода «lo» (вместо «login» )система дала сбой. Итак, «lo» (как в « о чудо» )были первыми двумя символами, переданными через Интернет. Оглядываясь назад, мы не могли бы придумать ничего лучше».

(Вот часть этого интервью:wiki arpanet Kleinrock)

Telnet появился раньше, чем TCP/IP. RFC 15 говорит о «сетевых примитивах». Из-за TCP/IP telnet должен был позаботиться только об «остальном», прикладном уровне («согласованных параметрах» в RFC854 ).

Да, telnet довольно прост, даже без TCP. RFC 15 заканчивается на:

TELNET subsystem constitutes a "level 0" network program which will quickly be surpassed. It is, however, simple enough to be working fairly soon.

«Протокол» используется с telnet, потому что две (разные )системы должны общаться на одном «языке».

RFC 854 также объясняет концепцию:

The TELNET Protocol is built upon three main ideas: first, the concept of a "Network Virtual Terminal"...

Существующие ответы уже объясняют, что telnetможет делать больше, чем просто передавать входные данные по TCP без изменений; Вместо этого я хотел бы сосредоточиться на «Моя тупая клиентская программа чата не создает протокол [приложения]». -часть вопроса. (Кроме того, для фактических «необработанных данных по TCP» вы можете использовать netcatвместоtelnet)

Тот факт, что протокол прост или плох -или даже плохо -указан где-либо -, не означает, что это не протокол. Две системы не могут взаимодействовать без согласованного -протокола, даже если этот протокол представляет собой просто «необработанные данные по TCP». Если вы попытаетесь использовать FTP на одном конце и HTTP на другом, у вас возникнут проблемы, так или иначе -, если вам повезет, это не сработает; если нет, вы получите неправильное поведение. (По крайней мере раньше было так, что если вы запускали FTP-демон на нестандартном порту -на том же хосте, что и HTTP-сервер, в некоторых браузерах вы могли использовать это для выполнения XSS и обхода защиты CSRF с помощью указав браузеру жертвы POST на FTP-сервер, который будет отображать отправленный контент в сообщениях об ошибках, а браузер интерпретирует его как ответ HTTP/0.9 -и с радостью запускает любой javascript.)

Это совершенно правильный вопрос: «Какой протокол использует эта штука, которую вы называете my dumb chat client program? Я хочу поговорить с ней из моей программы». и одним из возможных ответов будет «необработанные данные по TCP». Однако это не исчерпывающий ответ.

• Если у вас есть какой-то порт по умолчанию, это, вероятно, должно быть частью ответа.
• Если вы хотите внести ясность, вы можете указать, что имеете в виду «обычные данные TCP, а не срочные/исходящие данные TCP -из -данных диапазона» (, что несколько натянуто, поскольку не имеет никакого смысла, и, судя по количеству людей, которых я видел, которые думают, что третий fd набор select()предназначен для ошибок, большинство людей, похоже, даже не знают -из -. ] данные диапазона существуют -, но даже если это немного плохой пример, я надеюсь, вы понимаете, к чему я клоню)
• Даже вещи, о которых вы, возможно, даже не думали, могут неявно быть частью протокола. :Как закрыть соединение? Вы просто звоните close()или используете shutdown(), чтобы убедиться, что все ожидающие данные сначала доставлены?

Вы сказали «открыть сокет потока TCP для необработанного ввода/вывода? Это не правило», но так ли это на самом деле? «Вы должны использовать TCP», «вы должны отправлять данные как -» и «вы должны использовать порт XXX» звучат для меня как правила.

(П.С. Я немного увлекся, когда писал это; Остальная часть этого ответа немного тангенциальна и пытается ответить на естественный последующий -вопрос: «Хорошо, значит, все является протоколом -, имеет ли это какие-то последствия?»)

Итак, имейте в виду, что каждый раз, когда вы заставляете две системы взаимодействовать друг с другом, вы либо используете существующий протокол, либо создаете новый протокол. :Документируйте свои протоколы, пока не стало слишком поздно! (Т.е. самое позднее, когда протокол перестанет быть простым или станет иметь больше пользователей, чем просто разработчиков )Напр. многие ранние протоколы P2P -говорили, что «источником официального клиента является документация», что чрезвычайно раздражает в сложном проекте и просто приводит к тому, что клиенты используют немного разные протоколы и несовместимы здесь и там.

Есть старая поговорка «будь строг в том, что ты производишь, и либерально в том, что ты принимаешь» -основная идея хороша, но, честно говоря, по крайней мере, то, как она применяется,Я думаю, что это ерунда, и приводит только к большим проблемам в ремонтопригодности и совместимости. Я говорю :Уточняйте подробно (постарайтесь продумать каждый крайний случай )и будьте предельно строги в том, что вы производите и принимаете, и вы, вероятно, предотвратите/решите настоящие ошибки.

Пример, о строгих решениях ошибок :Несколько лет назад у одного битторрент-трекера возникла проблема :Некоторые их торренты не работали на некоторых клиентах; клиенты не жаловались, просто у них был другой инфохэш, и поэтому они не могли найти торрент. Они не могли понять, что происходит, и заявили, что затронутые клиенты должны содержать ошибки -, прекратите их использовать. Bittorrent использует бенкодирование, которое очень строго и хорошо определено -и по уважительной причине :Один и тот же ввод всегда приводит к одной и той же закодированной выходной строке, так что хэш [info] всегда одинаков для одних и тех же входных данных. Когда я впервые наткнулся на один из этих торрентов, я попытался загрузить его в свой собственный -очень строгий -синтаксический анализатор, и он сразу сказал:Error: Bencoded dictionary keys not sorted (last='sha1', key='private').

Итак, что случилось? Трекер начал автоматически добавлять ключ "private" к каждому загружаемому торренту, но просто добавлял его в конец, вместо того, чтобы сортировать словарные ключи, как указывает бенкодирование -, он не был строгим в том, что он выдавал. Некоторые клиенты декодировали торрент только частично и вычисляли хэш для некодированной, неизмененной строки. Некоторые клиенты декодировали весь торрент и перекодировали -часть, которую им нужно было хешировать, правильно сортируя ключи в процессе (, создавая правильное кодирование ), и получали другой хэш. Насколько мне известно/на моей памяти, ни один клиент не жаловался на то, что данные недействительны -, клиенты не были строги в том, что они принимали. Итак, какие хэши были правильными? Ни один! Оба способа подсчета хеша верны, но торренты были испорчены! Если бы хотя бы один из клиентов пожаловался на это,ошибка, скорее всего, была бы исправлена ​​в тот же день, а не месяцами. (IIRC I также сообщил об идентичной ошибке в другом совершенно не связанном трекере несколько лет спустя; программное обеспечение первого из них было сделано в -доме, так что кодовая база тоже была другой)

Еще один пример, на этот раз о крайних случаях :Протокол eDonkey2000 P2P -использовал пользовательский хэш под названием ed2k; В спецификации не было указано поведение в угловом -случае, когда длина входных данных точно делится на размер блока, поэтому родились два несовместимых варианта, которые дают разные хэши для некоторых файлов и несовместимы. (Я сказал «спецификация», но, поскольку это был ранний протокол P2P -, я почти уверен, что спецификации не было; особый -случай, вероятно, был упущен при обратном -инжиниринге протокола)

О необходимости подробных спецификаций :Много раз, пытаясь написать клиент для протокола или парсер для формата файла, я сталкивался с ситуацией, когда даже исходные программисты понятия не имеют, как устроены некоторые данные. на самом деле закодирован, потому что они использовали какую-то библиотеку и никогда не проверяли подробно, что она на самом деле делает. Два примера:

Определенный API использовал собственный протокол UDP с зашифрованными пакетами [переменной -длины] -, в документации указан AES128, но не упоминается используемое заполнение. Когда разработчиков спросили об этом, ответ был примерно таким::

Uh, we actually have no idea, we just used this function in this Java library, and the documentation doesn't seem to mention which padding it uses

На веб-сайте определенного устройства есть информация о взаимодействии с их файлами сохранения:

It is not possible to create or modify a saved *.logicdata files. That is because the files are generated with boost binary serialization and contain a very complex object structure. In truth, we don't even understand how it works. Boost serialization is extremely complex.

(Примечание :В действительности, однако, не требуется так много времени, чтобы реконструировать -достаточно формат файла, чтобы можно было экспортировать данные)

Некоторые из примеров касались кодировок, форматов файлов или пользовательских алгоритмов (, хотя они все еще использовались внутри протоколов, за исключением последнего ),но я бы сказал, что все это относится ко всем тем. Независимо от того, говорите ли вы о протоколе, формате файла, кодировке или пользовательском алгоритме:

• Напишите хорошую спецификацию/хорошо задокументируйте ее
  • Попробуй подумать обо всех угловых -делах
  • Постарайтесь указать всю необходимую информацию
• Буквально следуйте спецификации / будьте строги