Pzz>>Окно — это не про размер пакетов, а про то, сколько байт может передать передатчик (байт, а не пакетов, не важно, каким количеством пакетов они уйдут), не дожидаясь подтверждения от приемника, что можно еще слать.
AG>+100500
AG>Ну так это — как раз в тему!
В точку, да не в ту.

AG>Значит, если мы говорим о блоке данных, то увеличение окна — уменьшает фрагментирование этого блока. Вполне логично.
Давай начнем с определения что в твоем понимании 'блок' и что такое 'фрагментирование блока'?

AG>При достаточной ширине окна — на приёме фрагментирования не будет — бесь блок поступит целиком (одним куском)!
recv за раз может принять данные как больше чем текущий размер окна так и меньше. Есть еще куча факторов, которые влияют на то, сколько recv тебе вернет за раз. Самым лучшим будет постулировать что они тебе не подконтрольны (если только не написал свой сетевой стек, от tcp то железа).

Pzz>>Окно — это не про размер пакетов, а про то, сколько байт может передать передатчик (байт, а не пакетов, не важно, каким количеством пакетов они уйдут), не дожидаясь подтверждения от приемника, что можно еще слать.
AG>+100500
AG>Ну так это — как раз в тему!
В точку, да не в ту.

AG>Значит, если мы говорим о блоке данных, то увеличение окна — уменьшает фрагментирование этого блока. Вполне логично.
Давай начнем с определения что в твоем понимании 'блок' и что такое 'фрагментирование блока'?

AG>При достаточной ширине окна — на приёме фрагментирования не будет — бесь блок поступит целиком (одним куском)!
recv за раз может принять данные как больше чем текущий размер окна так и меньше. Есть еще куча факторов, которые влияют на то, сколько recv тебе вернет за раз. Размер tcp окна тут как раз не должен быть релевантен (хотя какая нить конкретная реализация тцп может и учитывать его каким то образом при внутренней буферизации данных) Самым лучшим будет постулировать что они тебе не подконтрольны (если только не написал свой сетевой стек, от tcp то железа).