13493

Самый уместный анекдот в моей жизни. Анекдот про UDP

Собеседовался в одну IT-компанию. Собеседующих двое: мужчина и женщина.

Мужчина решил "пощупать" мои знания в технической сфере:

- Чем отличается TCP от UDP?

//Спойлер: это протоколы передачи сообщений в компьюетрных сетях. TCP - гарантирует доставку, порядок и целостность сообщений, UDP - нет//

Память подкидывает мне анекдот из студенческого прошлого и я произношу:

- Знаю анекдот про UDP, но не факт, что он до вас дойдет...

Женщина засмеялась, мужчина в недоумении смотрит на меня:

- Хм, ладно, следующий вопрос..., - говорит он.

Секундная пауза. Он начинает смеяться. Дошло :)

Я добиваю:

- А еще знаю анекдот про TCP. Если он до вас не дойдет, я повторю его снова.

Одобрительно засмеялись все. Это был самый уместный анекдот в моей жизни

Вы смотрите срез комментариев. Показать все
Автор поста оценил этот комментарий

Эту "проблему" решает нубский TCP_NODELAY, а вообще кагбэ размер очереди регулируется - это раз. Два - если там где-то по дороге теряются пакеты и TCP это не нравиться, то UDP от проблем с сетью не спсает - просто кто-то отправил датаграмму в пустоту...а потом кто-то телепортировался, например, или вообще начала играть в свою собственную игру, где наконец всех нагнет. В общем при проблемах с сетью UDP точно не спасет. Ну и три - эффективность использования канала у udp и tcp примерно одинаковая. Конечно, если разработчикам норм от того что вся игровая логика недетерменированная, то пожалуйста - суйте везде только UDP, как делает это картоха, даже там, где по идее должно быть надежное соединение.

0
Автор поста оценил этот комментарий
Уважаемый физик, я вам дал ссылку на статью. Вы ее прочитали? Нет? Ну и о чем разговаривать?
раскрыть ветку (3)
0
Автор поста оценил этот комментарий

Вы так и не ответили на вопрос

раскрыть ветку (2)
0
Автор поста оценил этот комментарий
Что за бред? TCP и UDP абсолютно несовместимы, у них даже наборы портов отдельные помимо структуры датаграммы.
раскрыть ветку (2)
0
Автор поста оценил этот комментарий

В чем проблема одновременного использования нескольких протоколов и соответственно портов? Религия не позволяет с несколькими сокетами одновременно работать?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий
«Устанавливаем соединение по TCP, потом шлем игровые данные по UDP»

В том, что TCP и UDP никак не связаны. Так что это предложение непонятно.
0
Автор поста оценил этот комментарий
Блин сразу так интересно стало, астанавись
13
DELETED
Автор поста оценил этот комментарий
Широкую на широкую, ебаные волки!
Иллюстрация к комментарию
54
Автор поста оценил этот комментарий

У нас еще могут брать на работу, где и обезьяна справится, строго с высшим образованием. Не удивляйтесь, мы живем в стране парадоксов.

раскрыть ветку (124)
122
Автор поста оценил этот комментарий

прочитал "в стране пидарасов".

а потом подумал,что логика,в общем-то,не потерялась.

раскрыть ветку (2)
23
Автор поста оценил этот комментарий
Иллюстрация к комментарию
раскрыть ветку (1)
16
Автор поста оценил этот комментарий
Предпросмотр
12
Автор поста оценил этот комментарий

Обезьяна с высшим дипломом не пойдет на такую работу. А идиот который отучился 6 лет на бумажку в виде диплома пойдет

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Не все обезьяны такие умные, как Орешек.
ещё комментарии
5
Автор поста оценил этот комментарий
Есть такая штука, как протекающие абстракции. Можно всю жизнь кодить на высокоуровневых абстракция и в ус не дуть. Но рано или поздно столкнешься с ситуацией, когда без понимания более низкого уровня (как оно устроено внутри) - ничего не заработает. Причем, скорее рано, чем поздно.
раскрыть ветку (3)
4
Автор поста оценил этот комментарий

тогда заводишь тикет, и знающие низкоуровневые люди за тебя разбираются, почему не работает

5
Автор поста оценил этот комментарий

Такими абстракциями можно и по поводу кодирования на физическом уровне пособеседовать, а там и за электромагнетизм спросить.

раскрыть ветку (1)
Автор поста оценил этот комментарий

так и до физики атома можно дойти.

2
Автор поста оценил этот комментарий

понимание базовых протоколов очень нужно, когда провайдер проверяет канал пингами, а у тебя пакеты дропаются непонятно где

раскрыть ветку (9)
0
Автор поста оценил этот комментарий
Тут скорее маршрутизацию знать надо
раскрыть ветку (8)
1
Автор поста оценил этот комментарий

И чем тебе поможет знание маршрутизации, когда у тебя в IPSec l2l на ТРС-сессиях прилетает от МЭ TCP Final, в то время как UPD и ICMP работают исправно?

0
Автор поста оценил этот комментарий

Не факт. Мы например месяц убеждали провайдера что проблема на его стороне, в итоге они всё-таки нашли причину и устранили, правда сломав много чего другого.

На наших серверах был включен tcp selective ack по дефолту, пакеты с таким заголовком не доходили до клиента и терялись где-то у провайдера, оказалось что трафик проходил через старый файрвол провайдера не понимающий пакеты с tcp sack и пакеты дропались на нём.

раскрыть ветку (6)
0
DELETED
Автор поста оценил этот комментарий
На наших серверах был включен tcp selective ack по дефолту
если не секрет, а зачем?
раскрыть ветку (5)
0
Автор поста оценил этот комментарий

в ubuntu server 14.04 оно включено по дефолту, погуглив понял что оно позволяет экономить трафик и увеличить скорость обмена, поскольку с ним отправляются только те пакеты что не дошли до клиента, а не все с самого начала. к тому же на других площадках с другими провайдерами такой проблемы небыло.

раскрыть ветку (4)
0
DELETED
Автор поста оценил этот комментарий

Согласен:

SACK особенно важен для эффективного использования всей доступной пропускной способности в подключениях с большой задержкой. Часто из-за большой задержки в каждый данный момент подтверждения ожидает множество «зависших» пакетов. В Linux эти пакеты стоят в очереди на повторную передачу, пока не будет получено подтверждение их приёма и они больше не будут нужны. Эти пакеты располагаются в порядке следования, но никак не пронумерованы. При получении сообщения SACK, требующего обработки, стек TCP должен найти в очереди на повторную передачу пакеты, которых касается это сообщение. Чем больше эта очередь, тем сложнее найти необходимые данные.

Но каким образом промежуточный сервер (насколько я понял это ваш случай) может рубить эти пакеты? Для него (сервера) эти пакеты прозрачны.


раскрыть ветку (3)
0
Автор поста оценил этот комментарий

Проблема была в инспектирующем файрволе провайдера(Сisco FWSM), на их форуме есть описание этой проблемы
https://supportforums.cisco.com/document/43796/selective-ack-sack-through-fwsm

раскрыть ветку (2)
DELETED
Автор поста оценил этот комментарий

Понял.

Одновременно понял, что это баг самой железячки.

А интересно, что поломали то? ):

...и устранили, правда сломав много чего другого

раскрыть ветку (1)
4
Автор поста оценил этот комментарий

Дай угадаю?! Ты называешь себя фрилансером!

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Ох уж эти диванные эксперты, лишь бы обвинить кого-то в чем-тл :)
1
Автор поста оценил этот комментарий

Не знаю на счёт "средней" компании, но на ум приходят кейсы по диагностике проблем с доступностью сервиса/скоростью работы сервиса, а также ограничение доступа/фильтрация вредоносного трафика.

По поводу "без оглядки на такие простейшие знания" - простейшие знания не нужны ровно до тех пор, когда сервис (приложение) работает ожидаемым образом. Почитайте: http://www.joelonsoftware.com/articles/LeakyAbstractions.html

0
Автор поста оценил этот комментарий

Думаю это просто показывает если ли знание основы, да без этого можно жить, но все же специалист должен обладать базовыми знаниями, а не быть бездумным тыкальщиком кнопок.

0
Автор поста оценил этот комментарий

Телекоммуникации. Без подобных знаний сеть не отладишь, да и без фундаментальщины нет полного понимания.

0
Автор поста оценил этот комментарий
Ну, блять, да! Оно всё сука само работает!
0
Автор поста оценил этот комментарий

Мы вам перезвоним.

(Ибо определять проблемы в сети без wireshark пока мало кто научился).

0
Автор поста оценил этот комментарий
Ты прав. Знание этих протоколов нужно только очень узким специалистам. Но это один из стандартных вопросов на собеседовании. Аналог "почему вы выбрали именно нашу компанию" для ITшников. Такое впечатление, что каждый второй эникей планируется использоваться в качестве разработчика клиент-серверного приложения. Да только у серьезных архитекторов, которые и разрабатывают протокол работы ПО на собеседовании такой вопрос может промелькнуть как шутка, чтобы отвлечся от обсуждения действительно сложных тем. Про сетевиков я вообще молчу ибо там еще хуева туча более сложных протоколов есть, причем знание логики их работы — не самое сложное. Это как спрашивать у кассира как выглядит сторублевая купюра. Да кассир обязан это знать, но вопрос звучит крайне тупо.


Тут всякие @jammarra @marserMD @Fairyvir очень складно льют в уши как важно знать принципы работы этих протоколов. Да знать вообще многое полезно. Я например знаю как работает микропроцессор, а отдельные его элементы я самолично разрабатывал как в двух графических, так и в одной текстовой системе автоматического проектирования. Как ушел работать из почтового ящика, так мне эти знания в реальной практике не пригодились. Так и тут 95% специалистов в IT могут спокойно обойтись и без этих двух дико важных протоколов. Гораздо важнее тому же сисадмину знать ICMP, но ни одна кадровичка ни на одном собеседовании меня про ентот протокол не спросила. А про TCP и UDP на каждом втором.

раскрыть ветку (22)
0
DELETED
Автор поста оценил этот комментарий

Знание этих протоколов нужно только очень узким специалистам.


Лол блин, понимание чем они отличаются это основа IT, на первом курсе универа это рассказывают и в любой книжке про сети на первых страницах пишут. Ни кто же просит рассказать RFC на udp, хотя оно короткое, толи дело на TCP =)

Я подобные вопросы на собеседовании спрашивал кстати когда видел что человек на специализированные ответить не мог от слова совсем. Что бы понять знает ли он вообще хоть что то.

В целом я обычно спрашиваю то что люди в резюме пишут. Обычно пишут хуйню и ответить не могут даже на половину. Если напишут слова apache и nginx я обязательно спрошу чем они отличаются. И 80% ответить не может. Если пишут что работали с сетями спрошу и про UDP и OSI и про виды ddos и про коллизии. Ибо не хуй писать что попало, если этого не знаешь.

раскрыть ветку (6)
0
Автор поста оценил этот комментарий

apache и nginx я обязательно спрошу чем они отличаются

diff'ом листинга.


и про виды ddos и про коллизии

и про Token Ring и про прочую херь которую никто не видел, но все встречали в учебниках.


Ок, различия udp и tcp действительно знать надо и знания эти можно проверить на собеседовании. Но я критиковал моду на этот вопрос. Например меня поставило в тупик просьба кадровика рассказать про TCP\IP доступным для нее языком. Я просто не знал с чего начать, так как не привык такие вещи разъяснять пользователям. Да и досконально я тогда не знал принцип работы этих протоколов, ибо был эникеем и хорошо знал как сеть конфигурировать, но как она работает знал только в общем. Ну не требовалось этих знаний для работы. Только для получения оной.

раскрыть ветку (5)
1
DELETED
Автор поста оценил этот комментарий
Напомнило, как то у человека на собеседовании спросил OSI и он даже вспомнил. Я на столько офигел от этого, что следующий вопрос был "И как пригодилось хоть раз на практике?)"

На самом деле когда проводишь собеседования, нужно в течении 30-60 минут составить впечатление о человеке и понять он вообще хоть что то знает или нет. И примерно оценить уровень знаний. Подобные вопросы из учебника как раз дают эту возможность.
Если у человека будет в резюме чем и где он занимался, что делал и как и он сможет рассказать о этом. Так отлично, тогда они на фиг не нужны.

Но тут наверное все опять же от вакансии зависит.

раскрыть ветку (4)
0
Автор поста оценил этот комментарий

Хуясе Вы садюга, час пытать человека...

раскрыть ветку (3)
0
DELETED
Автор поста оценил этот комментарий

Фигня, я сам когда проходил собеседование в одну компанию. Самое долгое тестовое задание было более чем на 7 часов. Это один этап. Всего было около 3х что ли этапов если верно помню.

раскрыть ветку (2)
0
Автор поста оценил этот комментарий

Я ж говорю, люди не те профессии выбирают, возможно в средневековье они смогли бы найти работу своей мечты...

7 часов...охуеть, мне и на работе столько то сидеть влом
А так да, одно из собеседований как-то у меня у самого растянулось на 2 года...ниче, норм...

раскрыть ветку (1)
1
DELETED
Автор поста оценил этот комментарий

Ну так то я понимаю почему так. Кому попало давать root пароль от всех серверов не надо. Главное что бы и платили соответствующее.

0
Автор поста оценил этот комментарий

Всё-таки, иногда стоит остановиться в стремлении выбросить побольше ненужной инфы из мозга. На хабре вон под 30+% кодерастов считают, что знать алгоритмы — это бессмысленно, потому что умные дяденьки за них всё уже сделали, надо только подключить еще один фреймворк/модуль/заголовочный файл.

раскрыть ветку (4)
0
Автор поста оценил этот комментарий

Алгоритмы развивают мозг, а мозг рабочий инструмент программиста. Знание же нюансов каждого конкретного протокола — ничего не развивает. Это как сравнивать зубрежку параметров таблицы Менделеева и знания квантовой физики по законам которой она и построена.

раскрыть ветку (2)
0
Автор поста оценил этот комментарий

Дебажить сеть или приложение с WireShark не пробовали?
Вот тогда начинаешь проклинать себя, почему не выучил этого раньше.
Зато за те сутки узнал о сетях больше, чем за остальную жизнь.
Ну и параллельно русский матерный подтянул.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Вот конкретно именно WireShar'ом никогда не пользовался. Но он скорее нужен либо сетевикам, либо безопасникам, а я в несколько иной сфере, хоть и близко.Если интересно пользуюсь flow-tools, flowdumper, nfdump, Cflow::find ну и естественно весь этот зоопарк помещается в конвейеры и bash\perl скрипты.


Практика показывает, что если не пользуешься чем-либо долго, то ты это что-либо забываешь. Учить на всякий случай получается не очень. Лучше научиться быстро разбираться на необходимом уровне в том, что нужно.

0
Автор поста оценил этот комментарий

Угу, а потом чесать репу, куда утекает память, а что такое метод градиентного спуска и когда надо и когда не надо применять генетические алгоритмы или что-нибудь из классики - а чем так собственно плохи си-строки.
Знать алгоритмы наизусть - это не надо, а вот какие они есть, куда какой можно приткнуть, как реализовать его в данном случае и где подсмотреть - это знать важно.

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

В общем тут есть тонкая грань между пониманием и использованием. Это для джуна, для хорошего программиста подразумевается, что он еще может сообразить оригинальное решение для комплексной задачи (такое кстати бывает крайне редко на самом деле)

0
Автор поста оценил этот комментарий

Э нет. @Major.Pronin высказал сомнение в том, что этот протокол вообще кому-то бывает нужен в "среднего размера компаниях".

У нас мелкого размера компания, мы делаем игры. И нам это нужно. Более того, я слабо представляю как можно работать с сетевой частью игры не понимая устройства UDP, ограничений и преимуществ. Так что вопрос про UDP вполне может быть релевантен на собеседовании.

раскрыть ветку (4)
0
Автор поста оценил этот комментарий
Мы же понимаем, что требования к IT специалистам в среднюю IT компанию несколько выше, чем требования к IT специалистам в среднюю не IT компанию.


К тому же я уверен, что большинству сотрудникам вашей компании знать как работают сетевые протоколы абсолютно не нужно.

раскрыть ветку (3)
0
Автор поста оценил этот комментарий
К тому же я уверен, что большинству сотрудникам вашей компании знать как работают сетевые протоколы абсолютно не нужно.

Давайте я буду решать что нужно знать сотрудникам в моей команде)

Мне не очень хочется руководить командой программистов, где в случае возникновения *действительно* нетривиальных задач нельзя собраться и обсудить последствия тех или иных решений.

И опять же, @Major.Pronin высказал свой вопрос с довольно очевидным посылом: "Автору задали бессмысленный вопрос, т.к. знание UDP он не применит никак". Я привел контрпример -- бывают компании и должности, где знание протоколов релевантно.

раскрыть ветку (2)
0
Автор поста оценил этот комментарий
Наша контора тоже предпочитает держать избыточных спецов. Как говорится любой каприз за ваши деньги.


Ты понимаешь, что пишешь не логично? Нельзя общую тенденцию опровергать частным случаем. @Major.Pronin нигде не утверждал что "знание UDP никогда и никому пригодиться не может." Очевидно, что автор хотел сказать, что большинство ITшников спокойно могут выполнять свои рабочие обязанности не погружаясь в подобные дебри. Я же достаточно ясно проиллюстрировал справедливость данного утверждения. Более того, мне лично знание данных протоколов необходимо, ибо в данный момент я занимаюсь в том числе анализом трафика. Но для обычных контор, в которых я проработал в десятках в бытность мою разъездным сисадмином — погружение на подобную глубину нафиг не надо. А будет надо — никто не отменял повышение квалификации по мере необходимости. Ведь часто бывает что от излишних теоретических познаний при скудном практическом опыте человек работает менее эффективно.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
@Major.Pronin нигде не утверждал что "знание UDP никогда и никому пригодиться не может."

Тогда видимо мы по разному понимаем его слова.

мне лично знание данных протоколов необходимо, ибо в данный момент я занимаюсь в том числе анализом трафика.

И при этом у нас одинаковый взгляд на ситуацию. Думаю, спор закрыт)

Автор поста оценил этот комментарий

забавы ради можно еще до OSI доебаться :D

читать интересно, знать надо, но практической пользы не особо много в типовых ситуациях работы ITшника.

раскрыть ветку (4)
1
Автор поста оценил этот комментарий

Ну не скажи. При траблшутинг в первую очередь думаешь на каком уровне проблема.

раскрыть ветку (3)
Автор поста оценил этот комментарий
В целом то да, но как часто это возникает? Обрыв линии или отключение сервиса давно вынесены в стандартные диагностические карты с пометкой "интернет для чайников".
раскрыть ветку (2)
0
Автор поста оценил этот комментарий

Если ты отвечаешь за все уровни этой модели, то постоянно. Когда работал аутсорс эникеем мелких контор, то постоянно приходилось искать где проблема. И никаких карт у меня не было. Был звонок "интернет не работает" и поиски решения. Часто творческие. По телефону управляя пользователем. Который немецкий изучал в школе. При Хрущеве.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Техника пилотирования аватаром на уровне мастера :D
Меня по студяге угораздило поработать в тех.поде 1ц. Там буквально каждый звонящий на работу устраивался когда мои родители в школу пошли.
0
DELETED
Автор поста оценил этот комментарий
Слышали про FizzBuzz тесты?
0
Автор поста оценил этот комментарий

Знание этих нюансов поможет в решении задачи, когда непонятна причина нестабильной работы приложения. UDP много где применяется как служебный, для общения разрозненных программ внутри комплекса. Зная его ненадежность можно заранее предусмотреть проверку успешности передачи данных.

0
Автор поста оценил этот комментарий

Когда всё работает, то можно и уборщицу тётю Нюру программистом назначить.

А вот, когда нет...

Это из тех вопросов типа "зачем мы нашему наладчику такие большие деньги платим, если он весь день сидит без дела".

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Программист не сисадмин. Программист код пишет, разрабатывает ПО. Он не может сидеть без дела.

0
Автор поста оценил этот комментарий

К примеру, при пробрасывании портов или при работе с фаерволом. работа сисадмином

0
Автор поста оценил этот комментарий

В разработке сетевых приложений, не?

0
Автор поста оценил этот комментарий
Логично, что прикладные протоколы удобнее применять.
0
Автор поста оценил этот комментарий
На собеседовании можно применить
ещё комментарии
7
Автор поста оценил этот комментарий

Поздравляю!



...Не ожидал такого от Пикабу, да?

4
Автор поста оценил этот комментарий

что значит "офер"? можно в анекдоте)))

раскрыть ветку (3)
24
Автор поста оценил этот комментарий
Иллюстрация к комментарию
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

спасибо)

3
Автор поста оценил этот комментарий

Офер- это что за слово ? Какое то мутантское типа "инжиниринг" ?

раскрыть ветку (4)
5
Автор поста оценил этот комментарий
вероятно offer, предложение тоись.
раскрыть ветку (3)
Автор поста оценил этот комментарий
скорее offiser
раскрыть ветку (2)
0
DELETED
Автор поста оценил этот комментарий

cer

раскрыть ветку (1)
2
Автор поста оценил этот комментарий
Tochnyack
1
Автор поста оценил этот комментарий

нет, в итоге Spoofing

0
Автор поста оценил этот комментарий

и как? Всё еще там работаешь?

Только что задавали мне тот же вопрос - ответил этим же анекдотом))))

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Да, на работе вообще не шучу.

0
Автор поста оценил этот комментарий

Эм...оффер с двумя ф...

0
Автор поста оценил этот комментарий

что такое "в итоге офер"

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

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

2
Автор поста оценил этот комментарий

по UDP

1
Автор поста оценил этот комментарий

но не факт, что звонок до вас дойдет.

0
Автор поста оценил этот комментарий

по UDP протоколу

0
Автор поста оценил этот комментарий

это про Dial-Up анекдот

0
Автор поста оценил этот комментарий

а если не перезвонили то извините, UDP

0
Автор поста оценил этот комментарий

напишем по UDP)

Автор поста оценил этот комментарий
но не факт что звонок дойдет)
Автор поста оценил этот комментарий
Иллюстрация к комментарию
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку