TCP и UDP

@yura91 · Регистрация: 23.10.2013

Студворк — интернет-сервис помощи студентам

Вот при отправке данных по TCP - данные передаются как поток байт. И не известен размер порции которую отправляет функция send() за один раз. По UDP наборот передача идет ввиде датаграм и размер порции которую отправляет функция send() за один раз известен, но нет никаких гарантий что порция прийдет и все порции данных прийдут в правильном порядке. Так почему по TCP не могли сделать чтобы был известен размер порции которую отправляет функция send() за один раз и в тоже время сохранить всю надежность присущую этому протоколу?

Убежденный · 28.05.2016, 22:41

А если тебе кто-нибудь отправит 200 ГБ за один вызов send?
Сможешь их принять одним вызовом recv? Памяти хватит?

@elch10 · 30.05.2016, 11:45

Убежденный, тогда получается только recv знает сколько мы получили данные? а если мы отправим например 10 мб через send, а скорость интернета не позволяет за 1 порцию получить все 10 мб, то пакеты будут отправляться несколько раз?

@yura91 · 30.05.2016, 11:53 **[ТС]**

Ну для размера TCP пакета все равно есть ограничение - размер MTU. Чему он равен? Не подскажете?

Убежденный · 30.05.2016, 12:15

Сообщение от elch10

а если мы отправим например 10 мб через send, а скорость интернета не позволяет за 1 порцию получить все 10 мб, то пакеты будут отправляться несколько раз?

В TCP есть механизм, чтобы регулировать такие вещи, называется "sliding window".

Сообщение от yura91

Ну для размера TCP пакета все равно есть ограничение - размер MTU. Чему он равен? Не подскажете?

Как админы настроят, тому и будет равен. TCP-приложениям незачем беспокоиться о
таких вещах, ибо они работают поверх.

@elch10 · 30.05.2016, 12:26

Сообщение от Убежденный

В TCP есть механизм, чтобы регулировать такие вещи, называется "sliding window".

Убежденный, дело в том что мне пришла в голову идея проверить скорость интернета, и я не знал как, и если данные будут отправляться кусками постоянно, то я смогу проверить скорость интернета. Или это реализовывается как-то по-другому?

Новые блоги и статьи Все статьи Все блоги /
Символьное дифференцирование igorrr37 13.02.2026 / * Логарифм записывается как: (x-2)log(x^2+2) - означает логарифм (x^2+2) по основанию (x-2). Унарный минус обозначается как ! */ #include <iostream> #include <stack> #include <cctype>. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»
SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL3_image 8Observer8 10.02.2026 Содержание блога Библиотека SDL3_image содержит инструменты для расширенной работы с изображениями. Пошагово создадим проект для загрузки изображения формата PNG с альфа-каналом (с прозрачным. . .	Установка Qt-версии Lazarus IDE в Debian Trixie Xfce volvo 10.02.2026 В общем, достали меня глюки IDE Лазаруса, собранной с использованием набора виджетов Gtk2 (конкретно: если набирать текст в редакторе и вызвать подсказку через Ctrl+Space, то после закрытия окошка. . .

@yura91 3 / 27 / 2 Регистрация: 23.10.2013 Сообщений: 2,331

	TCP и UDP 28.05.2016, 19:23. Показов 1468. Ответов 5 Метки нет (Все метки) Вот при отправке данных по TCP - данные передаются как поток байт. И не известен размер порции которую отправляет функция send() за один раз. По UDP наборот передача идет ввиде датаграм и размер порции которую отправляет функция send() за один раз известен, но нет никаких гарантий что порция прийдет и все порции данных прийдут в правильном порядке. Так почему по TCP не могли сделать чтобы был известен размер порции которую отправляет функция send() за один раз и в тоже время сохранить всю надежность присущую этому протоколу? 0

Убежденный Ушел с форума 16481 / 7444 / 1187 Регистрация: 02.05.2013 Сообщений: 11,616 Записей в блоге: 1
	28.05.2016, 22:41
	А если тебе кто-нибудь отправит 200 ГБ за один вызов send? Сможешь их принять одним вызовом recv? Памяти хватит? 0

@elch10 40 / 21 / 3 Регистрация: 27.04.2015 Сообщений: 176
	30.05.2016, 11:45
	Убежденный, тогда получается только recv знает сколько мы получили данные? а если мы отправим например 10 мб через send, а скорость интернета не позволяет за 1 порцию получить все 10 мб, то пакеты будут отправляться несколько раз? 0

@yura91 3 / 27 / 2 Регистрация: 23.10.2013 Сообщений: 2,331
	30.05.2016, 11:53 [ТС]
	Ну для размера TCP пакета все равно есть ограничение - размер MTU. Чему он равен? Не подскажете? 0