Новое сообщение в форум Сети, сокеты, протоколы

Форум	Сети, сокеты, протоколы
Тема	Как правильно задавать вопросы

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Sharov, Вы писали:

S>>1)Допустим имеется клиент. Пусть имеется api, когда клиент что-то заращивает у сервера http get(большой json объект с 10000 записей). Правильно ли я понимаю, что   в данном случае у меня http собирает данные (копит в буфере), и когда все данные будут доступны (в памяти), мой клиент получит [b]один[/b] обычный http get ответ?

Pzz>Не обязательно. Может и по частям получать, потоком.

S>>2)Допустим имеется сервер, который получает огромный (8гб) файл от клиента. Вот у меня в api есть stream параметр (networkstream в случае дотнет). Верно, что в данном случае мой сервер получит http post, хотя его тело (т.е. 8гб), еще до конца не получено? Т.е. я получю [b]один[/b] http post и начинаю читать содержимое, которое до конца-то может и не придти, т.е. получается что http post в данном случае может не знать свой размер.

Pzz>Может и не знать. В этом случае используется chunked encoding, он позволяет передавать поток данных, длинна которого заранее не известна.

Pzz>То, как это выглядит с точки зрения программирования, очень зависит от используемых языков и библиотек. Но реализации, рассчитанные на использование взрослыми людьми, разделяют HTTP header и HTTP body. Header ты получаешь в тот момент, когда он пришел и распарсился, а body у тебя есть возможность получать по мере поступления - либо в виде callback'а, которого периодически зовут, передав ему очередную порцию полученных данных, либо в виде какого-то объекта, из которого можно читать данные по мере их поступления.

Pzz>Кстати, на клиентской стороне то же самое. Header уходит одним куском, body можно писать по частям, потом приходит header ответа и body, которые можно читать по мере поступления.

Pzz>Конечно, бывают и реализации, которые сразу все отправляют и получают одним куском. Но это вопрос именно API, а не протокола. С таким API работать проще, но стриминг гигабайта данных с помощью такого API не организуешь.

S>>Т.е. я понимаю разницу между буферизацией  и потоком, но я не понимаю как 2) случае все это будет [b]физически[/b] оформлено в [b]один[/b] http post.

S>>3)Про физику процесса -- я правильно понимаю, что у меня данные копятся в буфере http, а tcp просто прокидывает chunk'и данных? И когда у меня данные закончились - все пришло, либо разрыв - то tcp манифистирует об этом http, и уже http либо оформляет стандартный запрос\ответ, либо у меня вылезает ошибка о разрыве (но в этом случае это не ошибка http, а tcp socket что-то там).

Pzz>Совершенно не обязательно. Вполне возможна реализация HTTP с крошечным буфером. Если мы говорим о HTTP/1.1, разрыв TCP-соединения во время HTTP-транзакции - это всегда ошибка. HTTP/1.0 использовал факт закрытия сокета со стороны сервера как признак окончания возвращаемых данных, и из-за этого не всегда было возможно понять, пришли тебе данные целиком, или в обрезанном виде. Ну и переиспользование уже открытого сокета для следующих запросов было невозможно.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail