Если говорить про один файл на 50 ГБ, универсального самого быстрого протокола нет: итоговая скорость зависит от пропускной способности канала, RTT, потерь, congestion control и конкретной реализации клиента и сервера. Для интернета HTTP(S) удобен благодаря Range-запросам: файл можно запрашивать частями и возобновлять загрузку с нужного диапазона после обрыва. При этом сам HTTP не делает передачу многопоточной автоматически — параллельная загрузка нескольких диапазонов означает несколько отдельных запросов и, в зависимости от реализации клиента, несколько соединений. FTP тоже работает поверх TCP, поэтому фундаментального преимущества по скорости перед HTTP у него нет. В локальной сети NFS и SMB вполне способны обеспечить высокую скорость последовательной передачи: NFS использует pipelining/windowing для RPC-запросов, а SMB3 поддерживает Multichannel. Поэтому для передачи большого файла через интернет я бы рассматривал HTTP(S) с Range, а для LAN — сравнивал NFS и SMB уже на конкретном железе и конфигурации, а не выбирал протокол только по названию.
Скорее не совсем так. У SMB на больших последовательных файлах действительно есть протокольные накладные расходы, но «дикие» — сильное преувеличение: современные версии SMB умеют хорошо работать с большими последовательными передачами. FTP тоже не обязательно даст выигрыш в несколько процентов — всё зависит от реализации и сети. А Jumbo Frames сами по себе NFS быстрее не делают: нужен поддерживаемый MTU на всём пути. Для одного большого файла в LAN я бы сравнивал конкретные реализации NFS/SMB/HTTP на одинаковых настройках, а не объявлял HTTP или NFS победителем заранее.
Согласен, поэтому я и вынес это в самое начало раздела со стендом. "quic-go" хотя бы честно пишет об этом в лог при запуске. Правда, судя по всему, логи при включении HTTP/3 все читают уже в последнюю очередь :)
Спасибо, улыбнуло :) Только не спешите откатывать: зависания я ловил на старой связке curl 8.2.1-DEV + quiche 0.18.0 и на эмулированных потерях через netem. Браузеры используют свои реализации QUIC и при проблемах сами откатываются на HTTP/2. Если хочется проверить у себя, проще всего посмотреть в DevTools, по какому протоколу реально идут запросы и сколько из них не завершаются.
Планируется интеграция с Claude API — модель будет анализировать контекст находки и убирать false positives умнее чем простые regex правила. Пока в разработке!
Если говорить про один файл на 50 ГБ, универсального самого быстрого протокола нет: итоговая скорость зависит от пропускной способности канала, RTT, потерь, congestion control и конкретной реализации клиента и сервера. Для интернета HTTP(S) удобен благодаря Range-запросам: файл можно запрашивать частями и возобновлять загрузку с нужного диапазона после обрыва. При этом сам HTTP не делает передачу многопоточной автоматически — параллельная загрузка нескольких диапазонов означает несколько отдельных запросов и, в зависимости от реализации клиента, несколько соединений. FTP тоже работает поверх TCP, поэтому фундаментального преимущества по скорости перед HTTP у него нет. В локальной сети NFS и SMB вполне способны обеспечить высокую скорость последовательной передачи: NFS использует pipelining/windowing для RPC-запросов, а SMB3 поддерживает Multichannel. Поэтому для передачи большого файла через интернет я бы рассматривал HTTP(S) с Range, а для LAN — сравнивал NFS и SMB уже на конкретном железе и конфигурации, а не выбирал протокол только по названию.
Скорее не совсем так. У SMB на больших последовательных файлах действительно есть протокольные накладные расходы, но «дикие» — сильное преувеличение: современные версии SMB умеют хорошо работать с большими последовательными передачами. FTP тоже не обязательно даст выигрыш в несколько процентов — всё зависит от реализации и сети. А Jumbo Frames сами по себе NFS быстрее не делают: нужен поддерживаемый MTU на всём пути. Для одного большого файла в LAN я бы сравнивал конкретные реализации NFS/SMB/HTTP на одинаковых настройках, а не объявлял HTTP или NFS победителем заранее.
Согласен, поэтому я и вынес это в самое начало раздела со стендом. "quic-go" хотя бы честно пишет об этом в лог при запуске. Правда, судя по всему, логи при включении HTTP/3 все читают уже в последнюю очередь :)
Спасибо, улыбнуло :) Только не спешите откатывать: зависания я ловил на старой связке curl 8.2.1-DEV + quiche 0.18.0 и на эмулированных потерях через netem. Браузеры используют свои реализации QUIC и при проблемах сами откатываются на HTTP/2. Если хочется проверить у себя, проще всего посмотреть в DevTools, по какому протоколу реально идут запросы и сколько из них не завершаются.
Это только крупными мазками. Если расписать каждый DNS-запрос, пакет и этап рендеринга, получится уже не семь шагов, а отдельная статья.
Планируется интеграция с Claude API — модель будет анализировать контекст находки и убирать false positives умнее чем простые regex правила. Пока в разработке!