Улучшение протокола HTTP
Nitro Gear
и это уже давно реализовано. В любом случае хотелось бы услышать
мнение со стороны.
Итак, суть идеи заключается в том, чтобы веб сервер при наличии в HTTP
запросе определенного заголовка, X-ChkSum примеру, в заголовке своего
ответа выдавал в сmd5 контрольную сумму для запрошенного файла или его
части, если была запрошена на загрузку часть файла.
Где это может быть полезно:
- сразу после загрузки файла мы точно можем сказать что файл был
скачан корректно;
- контроль целостности и защита от атак Man-in-the-Middle;
- имея на руках битый файл, путем последовательных запросов
контрольных сумм, можно вычислить часть файла, отличающуюся от версии
на сервере, и скачать именно эту часть. Т.о. не нужно выкачивать
заново весь образ диска;
- можно реализовать бинарный патч файлов с определенным содержимым,
при условии что размер файла не изменился, а в нем поменялись какая-то
его часть.
Недостатки:
- дополнительная нагрузка на сервер за счет подсчета контрольных
сумм.
Реализовать это уже можно прямо сейчас, к примеру модулем веб-сервера
Apache. А может стоит этим улучшением расширить протокол HTTP.
Жду отзывов и критики.
Mironov Pavel
Денис Клёстер
А вообще это не кнам с такими предложениями.... это w3c заведует http
протоколом...
13 ноября 2009 г. 21:04 пользователь Mironov Pavel
<miron...@gmail.com> написал:
--
С уважением, Клёстер Денис
моб.тел. +79609802959
FidoNet: 2:5004/89.94
ICQ: 290559500
Денис Клёстер
я тоже поржал... давайте еще в ответ http сервера включать еще
бинарную информацию в текстовом виде... Где мой голд едит???? Я давно
из писем файло не собирал ))))))))))
.k1b (00:03:50 14/11/2009):
Фидо епт!
Dini (00:04:26 14/11/2009):
))))
.k1b (00:04:33 14/11/2009):
Ша отправлю 2 метра. Жди 17 писем )))
14 ноября 2009 г. 0:03 пользователь Денис Клёстер <dini...@gmail.com> написал:
Maxim Penzin
> Хочу поделиться своей идей. Возможно это будет изобретение велосипеда,
> и это уже давно реализовано. В любом случае хотелось бы услышать
> мнение со стороны.
Пожалуйста :)
> Итак, суть идеи заключается в том, чтобы веб сервер при наличии в HTTP
> запросе определенного заголовка, X-ChkSum примеру, в заголовке своего
> ответа выдавал в сmd5 контрольную сумму для запрошенного файла или его
> части, если была запрошена на загрузку часть файла.
> Где это может быть полезно:
> - сразу после загрузки файла мы точно можем сказать что файл был
> скачан корректно;
Единственный, но очень сомнительный плюс.
Скажите, Вы сколько раз видели скачанную "битую" страницу или картинку,
при условии, что она скачана вся (Content-Length соответствует
фактической длине) ?
> - контроль целостности и защита от атак Man-in-the-Middle;
От атак подобным способом не защититься - если злоумышленник
способен изменять любые данные, то уж заголовок-то он пересчитает легко.
> - имея на руках битый файл, путем последовательных запросов
> контрольных сумм, можно вычислить часть файла, отличающуюся от версии
> на сервере, и скачать именно эту часть. Т.о. не нужно выкачивать
> заново весь образ диска;
Для выкачивания больших объемов с проверкой поблочно существуют как минимум
rsync и p2p протоколы, в них специально предусмотрены дополнительные
проверки и возможности.
> - можно реализовать бинарный патч файлов с определенным содержимым,
> при условии что размер файла не изменился, а в нем поменялись какая-то его часть.
см. rsync
> Недостатки:
> - дополнительная нагрузка на сервер за счет подсчета контрольных сумм.
- необходимость иметь файл целиком до начала отправки клиенту
- отсутствие целесообразности применения в 99.99% случаев HTTP
--
-- mpe...@gmail.com icq:3861496 www.penzin.ru --
Nitro Gear
> 2009/11/13 Nitro Gear <nitrog...@gmail.com>:
>
> > Хочу поделиться своей идей. Возможно это будет изобретение велосипеда,
> > и это уже давно реализовано. В любом случае хотелось бы услышать
> > мнение со стороны.
>
> Пожалуйста :)
"остроумие" остальных участников ниже моего достоинства.
> > Итак, суть идеи заключается в том, чтобы веб сервер при наличии в HTTP
> > запросе определенного заголовка, X-ChkSum примеру, в заголовке своего
> > ответа выдавал в сmd5 контрольную сумму для запрошенного файла или его
> > части, если была запрошена на загрузку часть файла.
> > Где это может быть полезно:
> > - сразу после загрузки файла мы точно можем сказать что файл был
> > скачан корректно;
>
> Единственный, но очень сомнительный плюс.
Это полезно при нестабильном подключении к интернету - сети GPRS/EDGE,
особенно при перемещении между сотами.
А для обычных пользователей разве после скачки файла не полезно на
100% знать что он скачался корректно?
> Скажите, Вы сколько раз видели скачанную "битую" страницу или картинку,
> при условии, что она скачана вся (Content-Length соответствует
> фактической длине) ?
Контрольную сумму удобно применять при закачке больших файлов (от
100мб и больше), применять к страницам и картинкам особого смысла
нету. Поэтому включать директиву ContentDigest, действующую для всех
файлов, в Apache смысла нет.
> > - контроль целостности и защита от атак Man-in-the-Middle;
>
> От атак подобным способом не защититься - если злоумышленник
> способен изменять любые данные, то уж заголовок-то он пересчитает легко.
Не совсем так - ведь контрольная сумма выдается сначала, а потом уже
файл. Чтобы пересчитать сумму злоумышленнику понадобится сначала
скачать весь файл себе, а потом передать дальше. Что увеличит в
десятки-сотни раз обычное время ответа сервера.
> > - имея на руках битый файл, путем последовательных запросов
> > контрольных сумм, можно вычислить часть файла, отличающуюся от версии
> > на сервере, и скачать именно эту часть. Т.о. не нужно выкачивать
> > заново весь образ диска;
>
> Для выкачивания больших объемов с проверкой поблочно существуют как минимум
> rsync и p2p протоколы, в них специально предусмотрены дополнительные
> проверки и возможности.
Согласен, но они имеют свои недостатки - попробуйте качать p2p через
медленный, нестабильный канал (GRPS/EDGE). А rsync не так распостранен
как обычный HTTP.
> > - можно реализовать бинарный патч файлов с определенным содержимым,
> > при условии что размер файла не изменился, а в нем поменялись какая-то его часть.
>
> см. rsync
Подавляющая часть серверов используют именно HTTP
Maxim Penzin
> Это полезно при нестабильном подключении к интернету - сети GPRS/EDGE,
> особенно при перемещении между сотами.
> А для обычных пользователей разве после скачки файла не полезно на
> 100% знать что он скачался корректно?
>
>> Скажите, Вы сколько раз видели скачанную "битую" страницу или картинку,
>> при условии, что она скачана вся (Content-Length соответствует фактической длине) ?
Вот на этот вопрос почему-то не было ответа, а он достаточно важный.
> Контрольную сумму удобно применять при закачке больших файлов (от
> 100мб и больше), применять к страницам и картинкам особого смысла нету.
Как думаете, сколько человек в мире качают 100-меговые файлы
катаясь при этом между сотами GRPS?
>> > - контроль целостности и защита от атак Man-in-the-Middle;
>>
>> От атак подобным способом не защититься - если злоумышленник
>> способен изменять любые данные, то уж заголовок-то он пересчитает легко.
> Не совсем так - ведь контрольная сумма выдается сначала, а потом уже
> файл. Чтобы пересчитать сумму злоумышленнику понадобится сначала
> скачать весь файл себе, а потом передать дальше. Что увеличит в
> десятки-сотни раз обычное время ответа сервера.
Если атака спланирована, то это всё делается загодя.
Злоумышленник же не на ходу выдумывает, чтобы ему такого подсунуть.
>> Для выкачивания больших объемов с проверкой поблочно существуют как минимум
>> rsync и p2p протоколы, в них специально предусмотрены дополнительные
>> проверки и возможности.
> Согласен, но они имеют свои недостатки - попробуйте качать p2p через
> медленный, нестабильный канал (GRPS/EDGE). А rsync не так распостранен
> как обычный HTTP.
Через медленный и нестабильный канал всё всегда качается плохо,
но тем не менее обычной докачки достаточно.
Поясните механизм, как в вашем примере могут получаться битые в середине файлы?
>> > - можно реализовать бинарный патч файлов с определенным содержимым,
>> > при условии что размер файла не изменился, а в нем поменялись какая-то его часть.
>>
>> см. rsync
> Подавляющая часть серверов используют именно HTTP
Да, и им тривиальной докачки более чем достаточно,
так как она вполне обеспечивает целостность.
А пакетная связь байты сама не выдумывает, даже, если рвется время от времени.
Nitro Gear
> >> при условии, что она скачана вся (Content-Length соответствует фактической длине) ?
>
> Вот на этот вопрос почему-то не было ответа, а он достаточно важный.
> > Контрольную сумму удобно применять при закачке больших файлов (от
> > 100мб и больше), применять к страницам и картинкам особого смысла нету.
>
> Как думаете, сколько человек в мире качают 100-меговые файлы
> катаясь при этом между сотами GRPS?
Да, небольшой перебор. Но развитие беспроводных технологий позволяет
сказать что в будущем можно будет лить такие файлы через 3G/4G,
находясь в дороге
> Если атака спланирована, то это всё делается загодя.
> Злоумышленник же не на ходу выдумывает, чтобы ему такого подсунуть.
Тут может быть много сценариев. Не скажу что контрольная сумма
предотвратит такие атаки, но она сможет усложнить механизм их
реализации
> Через медленный и нестабильный канал всё всегда качается плохо,
> но тем не менее обычной докачки достаточно.
>
> Поясните механизм, как в вашем примере могут получаться битые в середине файлы?
например, при закачке одного файла в несколько потоков
Maxim Penzin
> Такого не было, ведь TCP подразумевает контроль целостности
На самом деле не всё так просто, и на зашумленных линиях сбои не редкость.
Только где сейчас найдешь tcp по таким линиям.
Ну так возвращаясь к нашим баранам -
в наше время контрольной суммы tcp вполне достаточно, чтобы обеспечивать
целостность и нет нужды в каких-то дополнительных ухищрениях.
>> Как думаете, сколько человек в мире качают 100-меговые файлы
>> катаясь при этом между сотами GRPS?
> Да, небольшой перебор. Но развитие беспроводных технологий позволяет
> сказать что в будущем можно будет лить такие файлы через 3G/4G,
> находясь в дороге
Да да, там и подавно нет никаких проблем с докачкой и её верификацией.
>> Поясните механизм, как в вашем примере могут получаться битые в середине файлы?
>
> например, при закачке одного файла в несколько потоков
Эти косяки целиком и полностью на совести авторов этих самых
многопоточных качалок.
И опять же HTTP тут не при чем, так как он позволяет точно сказать
какие куски были прокачаны, а какие нет.