нет, черный он потому что быстрее
ты это сам , через пять лет поймёшь ...
или через, два ...
Конечно. Некоторые люди, не слишком разбирающиеся в IT вообще и работе протоколов в частности начали шутить про TCP/IP. Шутки получаются вымученные и неудачные.
Реально же, если переносить протокол TCP/IP на картинку с детьми, то он бы швырял бы детей как UDP, причем кусками и иногда повторно. И долетали бы они до цели как попало, совсем не в том порядке, как их кидали. Но на другой стороне стоял бы еще один человек, который бы собирал эти куски в единое целое, основываясь на штампах, которыми швыряющийся помечал бы каждый кусок. Отбраковывая лишнее и подтверждая собранное.
И даже на уровне приложения TCP/IP работает совсем не так, как неофиты себе представляют.
Например, ты отправляешь две строки: "ПРЕВЕД ", "ПИДОРЫ!". И они могут прибыть вот так: "ПРИВЕТ ПИДОРЫ". Или так "ПРИ", "ВЕТ ПИДОРЫ!". Потому что TCP/IP - это поток.
Хуже того, они еще могут внезапно и не прибыть. Потому что есть таймауты.
Реально же, если переносить протокол TCP/IP на картинку с детьми, то он бы швырял бы детей как UDP, причем кусками и иногда повторно. И долетали бы они до цели как попало, совсем не в том порядке, как их кидали. Но на другой стороне стоял бы еще один человек, который бы собирал эти куски в единое целое, основываясь на штампах, которыми швыряющийся помечал бы каждый кусок. Отбраковывая лишнее и подтверждая собранное.
И даже на уровне приложения TCP/IP работает совсем не так, как неофиты себе представляют.
Например, ты отправляешь две строки: "ПРЕВЕД ", "ПИДОРЫ!". И они могут прибыть вот так: "ПРИВЕТ ПИДОРЫ". Или так "ПРИ", "ВЕТ ПИДОРЫ!". Потому что TCP/IP - это поток.
Хуже того, они еще могут внезапно и не прибыть. Потому что есть таймауты.
> Некоторые люди, не слишком разбирающиеся в IT вообще и работе протоколов в частности начали шутить про TCP/IP. Шутки получаются вымученные и неудачные.
А некоторые люди считают, что разбираются в TCP/IP и начинают поучать других, но делают это безграмотно.
TCP/IP это не поток и даже не протокол, а условное название стека протоколов. И даже TCP это не поток; поток это понятие уровня прикладного сокета, а TCP оперирует сегментами. И если TCP отправляет два сегмента с данными "ПРЕВЕД ", "ПИДОРЫ!", то не может прибыть ни замена ПРЕВЕД на ПРИВЕТ, ни потеряться только один восклицательный знак. И не может прибыть ни меньшее количество сегментов (не придёт "ПРИВЕТ ПИДОРЫ"), ни частично пересобранные сегменты (не придёт "ПРИ", "ВЕТ ПИДОРЫ!").
Но может прийти большее количество сегментов, если один будет поделен, например: "ПРИ", "ВЕТ ", "ПИДОРЫ!". На практике, однако, в TCP/IP есть минимально допустимый MTU и резка на такие мелкие части возможна только для гораздо более крупных сегментов.
А некоторые люди считают, что разбираются в TCP/IP и начинают поучать других, но делают это безграмотно.
TCP/IP это не поток и даже не протокол, а условное название стека протоколов. И даже TCP это не поток; поток это понятие уровня прикладного сокета, а TCP оперирует сегментами. И если TCP отправляет два сегмента с данными "ПРЕВЕД ", "ПИДОРЫ!", то не может прибыть ни замена ПРЕВЕД на ПРИВЕТ, ни потеряться только один восклицательный знак. И не может прибыть ни меньшее количество сегментов (не придёт "ПРИВЕТ ПИДОРЫ"), ни частично пересобранные сегменты (не придёт "ПРИ", "ВЕТ ПИДОРЫ!").
Но может прийти большее количество сегментов, если один будет поделен, например: "ПРИ", "ВЕТ ", "ПИДОРЫ!". На практике, однако, в TCP/IP есть минимально допустимый MTU и резка на такие мелкие части возможна только для гораздо более крупных сегментов.
О, битва выебонов. Ну, посмотрим, чье кунг-фу круче. Признаю, что "доебка до орфографии" в целом успешна - я действительно забыл восклицательный знак и это ужасно печально. Но по сути:
> И не может прибыть ни меньшее количество сегментов
На уровне приложения - легко.
> ни частично пересобранные сегменты
На уровне приложения - вообще как нехер, потому что реально будет три сегмента, но два последних для приложения будут доступны в момент чтения.
> И не может прибыть ни меньшее количество сегментов
На уровне приложения - легко.
> ни частично пересобранные сегменты
На уровне приложения - вообще как нехер, потому что реально будет три сегмента, но два последних для приложения будут доступны в момент чтения.
И на уровне приложения нет сегментов TCP. То, что ты пытаешься описать, это особенности работы API BSD-сокетов, где у каждого сокета есть опция SO_RCVLOWAT с дефолтным значением 1, что означает, что чтение из сокета в блокирующем режиме может вернуть произвольное количество байт, не завязанное на то, как эти байты отправлялись. То есть да, источник на уровне сокета сделал две посылки "ПРЕВЕД ", "ПИДОРЫ!", а приёмник теоретически может получить эти данные в результате произвольного количества операций чтения, если он не меняет значение опции SO_RCVLOWAT читаемого сокета.
Но, во-первых, то же самое API сокетов даёт возможность поменять эту опцию и если прикладной протокол гарантирует, что все сообщения будут длины, кратной 14 байт, то перед чтением сокету можно выставить SO_RCVLOWAT и тогда сообщение будет пролучено в виде ровно одной целой строки "ПРЕВЕД ПИДОРЫ!" или не получено вовсе. Если б ты об этом знал/помнил...
А во-вторых, это всё не про TCP и его сегменты, об особенностях приёма которых я писал выше по треду.
Но, во-первых, то же самое API сокетов даёт возможность поменять эту опцию и если прикладной протокол гарантирует, что все сообщения будут длины, кратной 14 байт, то перед чтением сокету можно выставить SO_RCVLOWAT и тогда сообщение будет пролучено в виде ровно одной целой строки "ПРЕВЕД ПИДОРЫ!" или не получено вовсе. Если б ты об этом знал/помнил...
А во-вторых, это всё не про TCP и его сегменты, об особенностях приёма которых я писал выше по треду.
Я не жду от тебя ответа, но серьезно, что ты забыл в айти юморе без знания айти?
Чтобы написать коммент, необходимо залогиниться
Отличный комментарий!