hirthwork
30.12.2012 21:04 mcabber
подумалось тут. а ведь хороший, годный асинхронный http-сервер при вычитывании запроса до появления CRLF CRLF всё равно будет все CRLF'ы находить. так что мог бы сразу складывать в какой-нибудь отдельный массив разметку заголовков.
8 comments
recommend
bookmark
subscribe
разметку заголовков? а?..
границы заголовков. после каждого прочитанного CRLF всегда будет идти либо HT | SP, который означает многострочный заголовок, либо CRLF, который означает конец заголовков, либо же начало нового заголовка
я так и не понял, какие профиты эта идея приносит — да и в чём, собственно, заключается её новизна.
профит в трм, что при разборе заголовков не требуется ещё раз искать CRLF'ы, ибо их уже искали один раз. още экономит проц. в случае с по настоящему асинхронным сервером с апстримами и фильтрами — это может даже заметно будет
не забывай, что благодаря кешам последовательные сканы памяти — полнейшая халява, особенно повторные. Вполне вероятно, что ты ударишься в безблагодатную микрооптимизацию и проебешь много времени впустую.
не проебу, потому что я не собираюсь это реализовывать
вот это правильное решение, как по мне.
но вот посмотреть как это сделано в HttpCore NIO, наверное, следует. там и бенчмарк готовый есть