Проще перечислить то, чего дочерний процесс НЕ получает.
Википедия в этом плане чуть более развёрнуто объясняет:
Между процессом-потомком и процессом-родителем существуют различия:
— PID процесса-потомка отличен от PID процесса-родителя;
значению PPID процесса-потомка присваивается значение PID процесса-родителя;
— Процесс-потомок получает собственную таблицу файловых дескрипторов, являющуюся копией таблицы процесса-родителя на момент вызова fork(). Это означает, что открытые файлы наследуются, но если процесс-потомок, например, закроет какой-либо файл, то это не повлияет на таблицу дескрипторов процесса-родителя.
— для процесса-потомка очищаются все ожидающие доставки сигналы;
— временная статистика выполнения процесса-потомка в таблицах ОС обнуляется;
— блокировки памяти и записи, установленные в процессе-родителе, не наследуются.
Всё остальное наследуется. Если открыт сокет, то после fork'а он будет открыт и у родителя, и у ребёнка. Так как сокет остаётся один, то и очередь у них будет общая.
Зачем? Чтобы не выходя из редактора получить копипастом код решения.
Это, безусловно удобно, но копипаста, на мой взгляд, едва ли полезна новичку, который хочет научиться. Где-то я видел плагин в браузер, который не даёт копипастить код со stackoverflow.
В первую очередь отмечу, что это не авторская статья, а только перевод.
Но ответить на ваш вопрос я всё же могу. В самом начале статьи, где рассказывается про генерацию трафика так же приведён небольшой пример:
$ tcpdump -ni vlan100 -c 10 -t udp and dst port 1234
IP 198.18.40.55.32059 > 198.18.0.12.1234: UDP, length 16
IP 198.18.51.16.30852 > 198.18.0.12.1234: UDP, length 16
IP 198.18.35.51.61823 > 198.18.0.12.1234: UDP, length 16
IP 198.18.44.42.30344 > 198.18.0.12.1234: UDP, length 16
IP 198.18.106.227.38592 > 198.18.0.12.1234: UDP, length 16
IP 198.18.48.67.19533 > 198.18.0.12.1234: UDP, length 16
IP 198.18.49.38.40566 > 198.18.0.12.1234: UDP, length 16
IP 198.18.50.73.22989 > 198.18.0.12.1234: UDP, length 16
IP 198.18.43.204.37895 > 198.18.0.12.1234: UDP, length 16
IP 198.18.104.128.1543 > 198.18.0.12.1234: UDP, length 16
То есть у пакетов можно найти общий критерий: отправитель из подсети 198.18.0.0/16, протокол UDP и маленький размер пакета (вот тут 16 байт).
Так что нет, отбиваются пакеты с диапазона адресов, и только определённые пакеты.
Если спасение от DDoS-атак — зависит от силы атаки.
Хм. Давайте разберёмся.
Сначала цитата про заблуждение. Я встречал людей, которые ещё недостаточно постигли работу с шеллом и поэтому думают, что перенаправление происходит именно потоков, то есть `1>&2` в их понимании значит «слить во второй поток, второй поток сам разберётся», именно на них нацелена данная задача.
Далее, то, что говорят [вон там](https://www.tldp.org/LDP/abs/html/io-redirection.html).
> gets sent to file pointed to by j.
То есть перенаправление происходит в файл, на который указывает в данный момент j-тый дескриптор. Если j-тый дескриптор станет указывать на другой файл, i-тый останется без изменений.
>В вашем примере stdout перенаправляется и в 1 и в 2 дескрипторы. Затем 2 перенаправляется в /dev/null. Но 1 как содержал в себе stdout, так и содержит.
А вот тут, честно, не понял, откуда stdout? В объяснении есть табличка с дескрипторами.
Исправил
Википедия в этом плане чуть более развёрнуто объясняет:
Всё остальное наследуется. Если открыт сокет, то после fork'а он будет открыт и у родителя, и у ребёнка. Так как сокет остаётся один, то и очередь у них будет общая.
Это, безусловно удобно, но копипаста, на мой взгляд, едва ли полезна новичку, который хочет научиться. Где-то я видел плагин в браузер, который не даёт копипастить код со stackoverflow.
Но ответить на ваш вопрос я всё же могу. В самом начале статьи, где рассказывается про генерацию трафика так же приведён небольшой пример:
То есть у пакетов можно найти общий критерий: отправитель из подсети 198.18.0.0/16, протокол UDP и маленький размер пакета (вот тут 16 байт).
Так что нет, отбиваются пакеты с диапазона адресов, и только определённые пакеты.
Если спасение от DDoS-атак — зависит от силы атаки.
Сервер с игрушкой стоит на vps от digital ocean. Не повезло, твой провайдер блокирует этот ip'шник.
Да, выглядят неплохо.
Согласен. Доберусь до компа — добавлю текста в исходный файл и перепишу задание на "сколько строчек будет в файле 1?" Так будет лучше
Эээ. Смотря какого потока и куда.
И всё заработает, потому что баш откроет файл на дозапись, и содержимое не пострадает.
Сначала цитата про заблуждение. Я встречал людей, которые ещё недостаточно постигли работу с шеллом и поэтому думают, что перенаправление происходит именно потоков, то есть `1>&2` в их понимании значит «слить во второй поток, второй поток сам разберётся», именно на них нацелена данная задача.
Далее, то, что говорят [вон там](https://www.tldp.org/LDP/abs/html/io-redirection.html).
> gets sent to file pointed to by j.
То есть перенаправление происходит в файл, на который указывает в данный момент j-тый дескриптор. Если j-тый дескриптор станет указывать на другой файл, i-тый останется без изменений.
>В вашем примере stdout перенаправляется и в 1 и в 2 дескрипторы. Затем 2 перенаправляется в /dev/null. Но 1 как содержал в себе stdout, так и содержит.
А вот тут, честно, не понял, откуда stdout? В объяснении есть табличка с дескрипторами.
UPD: erwin_shrodinger, пардон, я промахнулся веткой.