throughtheether

Спасибо, что "призвали" в тред, и извините за задержку с ответом.

Отвечаю на вопрос, вынесенный в заголовок,

В чем заключается работа человека в web и с сетями?

Web и сети (интернет) - две большие разницы, как говорят в Одессе.
В любом случае стоит знать, как между двумя хостами в сети передаются данные. Как инкапсулируются пакеты, мультиплексируются каналы, разделяются ресурсы и так далее. То есть знать азы Ethernet, IP, TCP, UDP и вспомогательных протоколов вроде ARP, ICMP, DNS. Как пользоваться сокетами, какие есть подходы к реализации сетевых приложений. Как и зачем использовать криптографию (криптографические примитивы, для чего нужны, как их сочетать). Как и для чего использовать модели TCP/IP и OSI. Начальная диагностика сети.

Далее, в случае изучения сетей стоит обратить внимание на маршрутизацию (какая бывает и зачем нужна, откуда столько протоколов маршрутизации и чем различаются, протокол маршрутизации как распределенная система), коммутацию (Ethernet - каким и для чего был создан, каким стал, отличие коммутации Ethernet и маршрутизации IP, есть ли компромиссный вариант), фаерволлы (почему так называются, какую задачу решают, какие бывают), побочные вещи вроде NAT и тоннелей. Какие и где есть потенциальные слабые места.

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

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

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

Как он это узнает?

Импульсная рефлектометрия (ссылка1,ссылка2).

Свитч после первого включения составляет таблицу соответствия портов и mac-адресов устройств

Да.

с помощью broadcast

Нет. Таблица соответствия MAC-адресов и интерфейсов заполняется при помощи наблюдения за трафиком. Для каждого входящего на интерфейс кадра/фрейма соответствующий MAC-адрес (если он "обычный", т.е. не мультикастовый/широковещательный) источника ассоциируется с интерфейсом.

(отсутствует пара порт=mac-адрес --> рассылает пакет на все порты кроме отправителя). После составления таблицы он направляет пакет только на нужный порт.

Да, в случае одноадресного (юникастового) трафика (подробнее см. ответ, который предоставил Руслан Федосеев ).

2. Свитч рассылает входящий пакет по всем портам (broadcast domain), увеличивая нагрузку на сеть и хосты, поэтому он подходит для создания лишь небольших сегментов сети.

Это верно для широковещательного (броадкастового, пример - ARP-запрос) и иногда для многоадресного (мультикастового) трафика. Или для одноадресного (юникастового) трафика, адреса назначения которого нет в таблице MAC-адресов (иногда ее называют CAM-таблица, по типу используемой памяти, content-addressable-memory или FDB, filtering/forwarding database), такое бывает при исчерпании CAM-ресурсов коммутатора.

Чем, на мой взгляд, плохи растянутые L2-домены:
1) широковещательный и, при неграмотной настройке, многоадресный трафик доставляется всем хостам. Это может привести к труднопрогнозируемой утилизации буферов и отбрасыванию пользовательского трафика. Кроме того, широковещательный трафик на сетевом оборудовании часто обрабатывается процессором, что может привести к его повышенной утилизации и отказу важных сервисов (маршрутизация и т.д).
2) в случае L2-петли последствия затрагивают все хосты; один широковещательный фрейм может привести к самоусиливающемуся шторму, далее см. п. 1)
3) фильтровать трафик в такой сети довольно затруднительно

Хочу приспособить данную шляпу для защиты от осадков для мопеда Huawei - имеет ли право на жизнь такая идея?..

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

Хороший вопрос.

Насколько помню, манчестерский код в мире Ethernet (речь, как я понял, именно об этой технологии) используется только в 10BASE-T реализации. В 100BASE-TX, если не путаю, используется расширительное кодирование 4B/5B, затем скремблирование (т.е. замена символов на другие), затем MLT-3. Предположу, что от манчестерского кодирования отказались по соображениям компактности спектра и других ВЧ-параметров (при использовании NRZI или MLT-3 наблюдается меньше фронтов). Кроме того, расширительное кодирование (4B/5B) позволяет использовать до 16 символов в качестве служебных (JK, TR в случае Ethernet 100BASE-TX). 100BASE-TX интерфейс, например, при отсутствии пользовательских данных постоянно шлет служебные символы, что позволяет быстро обнаружить потерю линка.

Скремблирование (100BASE-TX и выше), т.е. замена символов на другие, насколько мне известно, производится в случае использования витой пары для нормализации таких характеристик, как cross-talk.

Кстати, нашел интересную картинку. И статью.

Первый коммутатор:

create vlan 10 tag 10
create vlan 20 tag 20
!ввод 10 влана:
config vlan 10 add untagged 1:1
!ввод 20 влана:
config vlan 20 add untagged 1:2
!транк до другого коммутатора
config vlan 10 add tagged 1:48
config vlan 20 add tagged 1:48

Второй коммутатор (то же самое):

create vlan 10 tag 10
create vlan 20 tag 20
!ввод 10 влана:
config vlan 10 add untagged 1:1
!ввод 20 влана:
config vlan 20 add untagged 1:2
!транк до другого коммутатора
config vlan 10 add tagged 1:48
config vlan 20 add tagged 1:48

Коммутаторы соединить 48 портами. Порты 1 - ввод и вывод влана 10, порты 2 - влана 20.

Вы говорите, что в теории вам все понятно, я вам не верю. Изучите, когда и как на фрейм ставится или снимается тег, вам многое станет ясно.

В данном случае, трафик входит через access-порт (untagged в мире d-link), в случае направления (форвардинга) через транк (tagged), к нему добавляется тег. На втором коммутаторе приходит тегированный фрейм, перенаправляется в соответствующий влану порт. Так как данный влан в данном порту не тегируется, тег снимается.

Все IPv4 и IPv6 префиксы, кроме некоторых зарезервированных (список здесь), а именно тех, у которых параметр global задан как false, являются глобально маршрутизируемыми. Вероятно, именно их вы называете публичными.