15432

Программой, запущенной с правами администратора, можно:
- убить жёсткий диск/ssd (стерев его прошивку)
- убить процессор (выставив слишком высокое напряжение питания)
- вывести из строя видеокарту (стерев прошивку)
- сломать материнскую плату (стерев биос или выставив высокие напряжения на чипсете)

всё это достаточно сложно сделать, не везде возможно (например, у Intel больше аппаратных защит, у некоторых HDD прошивка подписана и её так просто не испортить и т.д.), и мало кому нужно.

Оперативку сломать можно было во времена DDR2 (перезаписать SPD EEPROM), сейчас они почти все залочены на read-only, по превышению напряжения ОЗУ вряд ли помрёт, они достаточно надёжные, так что можете считать DDR наиболее неубиваемой частью ПК

Либо один из ваших модулей ОЗУ неисправен и не может работать на высокой частоте (попробуйте снизить частоты памяти, прогнать memtest и т.д.), либо BIOS некорректно размечает адресное пространство (тут только техподдержка и обновление BIOS)

1) дампите BIOS
2) открываете в UEFI Tool NE
3) в секции FIT смотрите, для каких ID процов есть микрокод
4) в интеловских PDF-ках "microcode-update-guidance" смотрите, каким процам и сериям эти ID соответствуют

По симптомам - отваливается системный диск. Попробуйте переставить в другой слот. Если не поможет - смените накопитель. Рекомендую забэкапить важные данные.

Вплоть до 29 пакета всё кажется идёт хорошо, но в 29 пакете браузер пытается отправить ACK, как я понял в ответ на FIN ACK, но похоже тут что-то не так.

всё ок, браузер почему-то отправил сразу два ACK, без учета FIN (29) и с учетом FIN (30). Ну лишний пакет получился, и ладно. Последовательность FIN/ACK завершена корректно.

У меня подозрение, что в после того как сервер в 28 пакете отправил FIN ACK он не дожидается ACK от клиента, верно ли это?

не, там всё нормально

но браузер тут-же создаёт новое подключение

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

не присылает никаких запросов в этом подключении

видимо в index.html не было больше ничего, что можно запросить

поскольку я хочу просто отправить ответ и закрыть соединение

так и вышло, но в первом соединении. второе так и висело на всякий случай.

в этом варианте клиенту с сервером чуть-чуть не хватило что-бы полностью обработать последовательность:

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

Правильно ли я понимаю, что сервер посылая FIN ACK не дожидается ACK и в целом неверно производит завершение TCP подключения, завершая соединение раньше времени?

всё корректно дожидается, тут проблем нет

Именно поэтому браузер инициирует повторное подключение, но не присылает никаких данных.

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

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

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

(я пробовал разные браузеры)

видимо все браузеры конкурируют по скорости работы с Web и делают такую оптимизацию

Если это микроконтроллер, то код вполне может находиться в read-only памяти - на флешке ПЗУ, запись в которую нельзя выполнить просто по указателю.
В иных случаях за это отвечает модуль MPU (memory protection unit), который кто-то в системе настраивает.

Нужно в биосе включить режим бифуркации для порта, куда вы его вставили. Сейчас он работает в режиме 1х16, вам нужно включить его в режим 4х4.

Либо вам нужен райзер другого типа, который исполняет роль PCIe свитча (например, Highpoint SSD6202A), он сам разделяет х16 порт на несколько m.2

Нормально. Особенности работы IPS на высокой частоте обновления (точнее с заниженным временем отклика пикселя)

Вы неверно поняли сообщение интерфейса. "drops this packet" относится к ICMP сообщению, в то время как ARP корректно ушёл. Пока ARP не разрезолвится, пакеты на этот IP адрес продолжат дропаться.