Взять на работу в качестве безопасника человека только-только из института, который при вопросе о стаже работы «не знаю что бормочет в ответ» (по его же рассказу)? Решающим вопросы безопасности — человека, который входит в состояние стресса от пары вопросов? Ой.
Столяров, например, в предисловии к своей книге довольно подробно расписывает, почему (по его мнению) обучение программированию должно идти в порядке Паскаль-ассемблер-Си, а уже дальше что угодно.
То есть одно дело взять людей, которые программировать умеют, и обучать их веб-разработке. Вообще другое дело начинать обучать программированию прямо с веб-разработки.
Там, где я знаю лучше (интернет в его WWW-проявлении), основные задержки возникают от уровня TCP и выше: 3-way handshake требует определённого времени; SSL handshake требует определённого времени; собственно обработка сервером запроса требует определённого времени, грубо говоря, на осмысление запроса, позиционирование головок винчестера, чтение нужных данных, формирование из них приемлемого по форме ответа.
Кроме того, физический уровень вносит свои задержки. Скорость света в волокне равна примерно 0.6 «це», поэтому на расстояниях в десятки тысяч километров задержка распространения сигнала становится очевидной. Плюс время на срабатывание активного сетевого оборудования (роутеров, свитчей), правда, с ростом расстояний оно становится всё меньше относительно растущей задержки физического уровня.
Как бороться — мне очевиден путь только в двух направлениях: заменять HDD на SSD и использовать более производительные процессоры на серверах и сетевом оборудовании :)
P.S. Вышеописанное справедливо для непереполненных каналов связи. Если начинают теряться пакеты — там другие задержки и другие методы.
Как правило, задержки канального уровня несравнимы с задержками вышележащих, особенно прикладного. Поэтому, будь они тут равны, например, стандартному циклу TDM в 125 мкс или превышать его в десять раз, на времени ответа S3 это скажется крайне мало.
gag_fenix, спасибо за прекрасный квест и за потраченное на его разработку время!
К сожалению, RGB сильно придержал за отсутствием paint'а, зато на последнем уровне вспомнил и «Пляшущих человечков», и частотный анализ в целом. Здо́рово размял мозги и узнал кое-что новое.
То есть одно дело взять людей, которые программировать умеют, и обучать их веб-разработке. Вообще другое дело начинать обучать программированию прямо с веб-разработки.
Там, где я знаю лучше (интернет в его WWW-проявлении), основные задержки возникают от уровня TCP и выше: 3-way handshake требует определённого времени; SSL handshake требует определённого времени; собственно обработка сервером запроса требует определённого времени, грубо говоря, на осмысление запроса, позиционирование головок винчестера, чтение нужных данных, формирование из них приемлемого по форме ответа.
Кроме того, физический уровень вносит свои задержки. Скорость света в волокне равна примерно 0.6 «це», поэтому на расстояниях в десятки тысяч километров задержка распространения сигнала становится очевидной. Плюс время на срабатывание активного сетевого оборудования (роутеров, свитчей), правда, с ростом расстояний оно становится всё меньше относительно растущей задержки физического уровня.
Как бороться — мне очевиден путь только в двух направлениях: заменять HDD на SSD и использовать более производительные процессоры на серверах и сетевом оборудовании :)
P.S. Вышеописанное справедливо для непереполненных каналов связи. Если начинают теряться пакеты — там другие задержки и другие методы.
К сожалению, RGB сильно придержал за отсутствием paint'а, зато на последнем уровне вспомнил и «Пляшущих человечков», и частотный анализ в целом. Здо́рово размял мозги и узнал кое-что новое.