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

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

Нет, зависит от того, как работает генератор ответа.
В HTTP/1.1 и последующих есть chunked encoding, позволяющее отдавать ответ по частям — и клиент может его обрабатывать по частям по мере получения. Но можно и цельным телом. Это уже как серверу удобно. Оба варианта должны поддерживаться полноценными клиентами.

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

Точно так же, можно chunked. Но тут уже вопрос дизайна повыше HTTP. Если отправляется 8GB, вероятность разрыва огромна — значит, у клиента должен быть какой-то аплоадер (скрипт в браузере или аналог), который вызывает команду отправки по частям, и закончив отправку — говорит "фиксируй и сохраняй на постоянное".
Как это будет в вашем API — не знаю, не видел. Может, оно и попытается одним куском выслать.

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

Оформить-то можно, но удобно ли.

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

Для HTTP настоятельно рекомендуется или Content-Length заранее, или chunked encoding. Тогда при обрыве TCP принимающая сторона поймёт, что данные неполные.
Можно отправлять и без этого, разрешается, но не рекомендуется — опасно.
Ошибку по самому TCP можете и не увидеть, если программа, например, упала с той стороны — в этом случае просто сокет закрывается (да, увы, такой дизайн — многие на него жалуются).

S>И когда у меня данные закончились — все пришло, либо разрыв — то tcp манифистирует об этом http

В общем случае следует считать, что TCP не скажет, что был разрыв. Он может, но не гарантируется. Проверяйте таки по длине или финальному чанку.