Еще на тему
Это все потому что он черный?
Да, если не забить то вырастет и станет президентом
Забивать чёрных детей нужно осенью, когда жирок наберут
нет, черный он потому что быстрее
Конечно быстрее, послал его в атаку, и плевать что будет. У нас этих негров ...
А можно для даунов без знания IT расшифровать шутку?
Это шутка про UDP, боюсь она до тебя не дойдет
ты это сам , через пять лет поймёшь ...
или через, два ...
Это уже шутка про диалог копирования в Windows.
нет он просто не узнает, дошла она до него или нет
Это шутка про ТСР. Не дошло, повтори, пожалуйста.
Или дойдёт, но все уже разошлись.
А вообще все просто - грубо говоря данные по протоколу TCP проверяются на корректность (вдруг сбой какой был при доставке), все бережно и аккуратно, а данные по протоколу UDP не проверяются - послал и хер с ними.
хуяссе..
По протоколу UDP работает например потоковое видео, в том числе на ютубе. Как бы не дошло до тебя пара кадров и пофиг, ты все равно их не заметил при просмотре видео на пару часов. TCP же нужен там где нужна достоверность доставки, например почта.
По UDP youtube работает только в хроме с включенным протоколом QUIC (эксперементальный протокол гугла). Вот когда все бравзера завезут HTTP/3 который должен работать по UDP, вот тогда да. А пока HTTP/2 наше все.
И не только потому. Ещё потому что выгоднее и проще со всех позиций дропнуть часть потока и продолжить с текущего момента, чем птаться дождаться недостающего, хранить это всё где-то, а потом ещё и показывать с временным лагом, если говорить о том же видео.
По udp тоже проверяется, но поломанные данные не переотправляются.
Сам UDP не проверяет, там даже контрольные суммы необязательны, может прийти с повреждениями. Обычно проверяет прикладной протокол внутри UDP в зависимости от своих потребностей.
Конечно. Некоторые люди, не слишком разбирающиеся в 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? Изначально-то ты всё это излагал про TCP.
Цитирую: И даже на уровне приложения TCP/IP работает совсем не так
Чувак, посмотри ещё раз на картинку в топике. Контекст у нас - противопоставление протокола TCP и протокола UDP. А ты упорно сливаешься на прикладной уровень (Application Layer) четырехуровневой модели TCP/IP. Это подмена понятий. Не надо так.
"Контекст у нас противопоставление хвойных и лиственных деревьев, а ты упорно сливаешься на обсуждение формы листьев. Это подмена понятий!"
Я, если честно, все еще не понимаю причины твоего недовольства, но как бы то ни было - мне похуй.
Я, если честно, все еще не понимаю причины твоего недовольства, но как бы то ни было - мне похуй.
Как и мне. "В интернете кто-то неправ!" :-)
И на уровне приложения нет сегментов TCP. То, что ты пытаешься описать, это особенности работы API BSD-сокетов, где у каждого сокета есть опция SO_RCVLOWAT с дефолтным значением 1, что означает, что чтение из сокета в блокирующем режиме может вернуть произвольное количество байт, не завязанное на то, как эти байты отправлялись. То есть да, источник на уровне сокета сделал две посылки "ПРЕВЕД ", "ПИДОРЫ!", а приёмник теоретически может получить эти данные в результате произвольного количества операций чтения, если он не меняет значение опции SO_RCVLOWAT читаемого сокета.
Но, во-первых, то же самое API сокетов даёт возможность поменять эту опцию и если прикладной протокол гарантирует, что все сообщения будут длины, кратной 14 байт, то перед чтением сокету можно выставить SO_RCVLOWAT и тогда сообщение будет пролучено в виде ровно одной целой строки "ПРЕВЕД ПИДОРЫ!" или не получено вовсе. Если б ты об этом знал/помнил...
А во-вторых, это всё не про TCP и его сегменты, об особенностях приёма которых я писал выше по треду.
Но, во-первых, то же самое API сокетов даёт возможность поменять эту опцию и если прикладной протокол гарантирует, что все сообщения будут длины, кратной 14 байт, то перед чтением сокету можно выставить SO_RCVLOWAT и тогда сообщение будет пролучено в виде ровно одной целой строки "ПРЕВЕД ПИДОРЫ!" или не получено вовсе. Если б ты об этом знал/помнил...
А во-вторых, это всё не про TCP и его сегменты, об особенностях приёма которых я писал выше по треду.
> Если б ты об этом знал/помнил...
Я даже помню, что до 2.6 этот ебаный RCVLOWAT работал криво. Да и задачу отсечки по 14 байт конечно же надо решать на прикладном уровне, любого ебаного психопата, который попробует это решать описанным тобой способом нужно кастрировать, чтобы не размножался. Мой же пример был о том, что бытующие даже среди айтишников представления о работе протоколов на всех уровнях - крайне далеки от реальности и потому все эти комиксы выглядят вымученной херней. Однако, приятно видеть, что хоть кто-то в теме.
Я даже помню, что до 2.6 этот ебаный RCVLOWAT работал криво. Да и задачу отсечки по 14 байт конечно же надо решать на прикладном уровне, любого ебаного психопата, который попробует это решать описанным тобой способом нужно кастрировать, чтобы не размножался. Мой же пример был о том, что бытующие даже среди айтишников представления о работе протоколов на всех уровнях - крайне далеки от реальности и потому все эти комиксы выглядят вымученной херней. Однако, приятно видеть, что хоть кто-то в теме.
> Да и задачу отсечки по 14 байт конечно же надо решать на прикладном уровне, любого ебаного психопата, который попробует это решать описанным тобой способом нужно кастрировать, чтобы не размножался.
Да прям: протокол вполне может быть бинарным и предварять каждую запись двухбайтовым префиксом длины очередной порции данных, так что приёмник может каждый раз делать setsockopt, сначала выставляя опцию в два байта, читать длину одним вызовом, затем снова дергать setsockopt, выставляя опцию в только что принятое значение и затем читать полезные данные опять одним значением.
Можно даже придумать условия, в которых такой подход будет экономией на количестве системных вызовов, несмотря на пару "лишних" вызовов setsockopt :-)
Да прям: протокол вполне может быть бинарным и предварять каждую запись двухбайтовым префиксом длины очередной порции данных, так что приёмник может каждый раз делать setsockopt, сначала выставляя опцию в два байта, читать длину одним вызовом, затем снова дергать setsockopt, выставляя опцию в только что принятое значение и затем читать полезные данные опять одним значением.
Можно даже придумать условия, в которых такой подход будет экономией на количестве системных вызовов, несмотря на пару "лишних" вызовов setsockopt :-)
> можно выставить SO_RCVLOWAT
*можно выставить SO_RCVLOWAT=14
*можно выставить SO_RCVLOWAT=14
Я не жду от тебя ответа, но серьезно, что ты забыл в айти юморе без знания айти?
О, узнаю юзера!
Я знаю хорошую шутку про UDP.
Но рассказывать ее вам не буду.
Не уверен что она до вас дойдет.
Но рассказывать ее вам не буду.
Не уверен что она до вас дойдет.
Ты добавил в оригинальную шутку лишнюю фразу, которая сделала ее бессмысленной.
Отличный комментарий!