什么是最小大小的UDP数据包？ [英] What is the minimum-size UDP packet?

问题描述

我正在编写一个应用程序，其中客户端（C＃/ WinForms）和服务器

（C＃/ service）与之交互另一个。客户端与服务器建立会话

但是出于可伸缩性的原因，会话和物理TCP连接之间没有一对一的映射。如果客户端空闲超过60秒，客户端可能会断开连接...但是这是一个概念性的

会话。可能会持续数天。


服务器必须跟踪所有打开的会话。我计划处理这个问题的方法是让客户端每2次向服务器发送它的会话ID

[长度为4个字节]通过UDP分钟。服务器

将通过UDP响应一位（datatype =''bit''）回复yes或

no。如果服务器在10分钟内没有从客户端通过UDP收到有效的会话ID

，服务器将认为客户端已经消失并将关闭
关闭退出会话。


以此为背景，以下是我的问题：


1）我知道UDP是一个尽力而为的协议和

数据包的传送不能保证。我的系统可以容忍这一点。什么*不能*

容忍只是部分客户端的UDP通知使其成为电汇的b $ b。回想一下，客户端的UDP通知长度为4个字节。我不能让b $ b容忍只有2个字节通过的情况[没有服务器

意识到通过Winsock发生了某种错误

例外]。它应该是4个字节或根本不存在。 UDP是否适合我的

需要？


2）是否有最小数据包大小？对于UDP？换句话说，当我的
客户端向服务器发送4字节的有效负载时，由于最小数据包大小，实际上是否有更多的b / b $ b字节通过线路？我对TCP / IP的速度不是很高，但是我知道有一些叫做最小的传输单元（MTU）的传输单元（MTU）可以是设置高达1,500字节左右。

我的4字节通知是否填充有1,496个额外字节？非常重要的是，我得到了这个问题的答案，因为我的应用程序需要

节省带宽[我可能有1000'的同时会话 ;在给定时间的任何

]。


提前感谢您提供的任何帮助！


-

真诚的，


David Sworder
http://www.CodeFanatic.com

推荐答案

David，

David,

1）据我所知，UDP是一种尽力而为的协议，无法保证传送数据包。我的系统可以容忍这一点。它不能容忍的只是部分的。客户端的UDP通知使其成为电线。


保持在MTU之下，你会看到整个数据包或者没有看到它。

2）是否有最小数据包大小。对于UDP？换句话说，当我的客户端向服务器发送4字节的有效负载时，由于最小数据包大小，实际上是否有更多的字节通过线路？

1) I understand that UDP is a best-effort protocol and delivery of the
packets is not guaranteed. My system can tolerate that. What it *can''t*
tolerate is only "part" of the client''s UDP notification making it across
the wire.
Stay under the MTU and you will either see the entire packet or none of it.
2) Is there a "minimum packet size" for UDP? In other words, when my
client sends a payload of 4 bytes to the server, are there actually more
bytes going across the wire due to a minimum packet size?

否 - 有一些与数据包相关的开销，但没有_minimum_

大小（呃，实际上我还没有尝试发送零字节< g>）。

-

Abderaware

.NET的精细组件

打开，收听，下载。 />
zane a @ t abderaware.com

No - there is some overhead associated with the packet but there is no _minimum_
size (uh, actually I haven''t tried sending zero bytes <g>).
--
Abderaware
Fine Components For .NET
Turn on, tune in, download.
zane a@t abderaware.com

" David Sworder" < GI ******** @ CSILasVegas.com>在留言中写道

news：uz ************** @ TK2MSFTNGP12.phx.gbl ...

"David Sworder" <Gi********@CSILasVegas.com> wrote in message
news:uz**************@TK2MSFTNGP12.phx.gbl...

我正在编写一个应用程序，其中客户端（C＃/ WinForms）和服务器（C＃/ service）彼此交互。客户端与服务器建立会话，但出于可伸缩性的原因，在会话和物理TCP连接之间没有一对一的映射。如果TCP连接空闲超过60秒，客户端可以断开
的连接...但是概念性的会话是可能会持续数天。

服务器必须跟踪所有打开的会话。我计划处理的
方式是让客户端通过UDP每2分钟向服务器发送一次会话ID
[长度为4个字节]。服务器
将通过UDP响应一位（datatype =''bit''）回复是
或否。如果服务器在超过10分钟内没有从
客户端通过UDP收到有效的会话ID，则服务器将假定客户端已经消失并且
将关闭会话。

以此为背景，以下是我的问题：

1）我理解UDP是一种尽力而为的协议，并且
数据包的传送不是保证。我的系统可以容忍这一点。它不能容忍的只是部分的。客户端的UDP通知使其成为电线。回想一下，客户端的UDP通知长度为4个字节。 I
不能容忍只有2个字节通过的情况[没有服务器知道通过Winsock
异常发生了某种错误]。它应该是4个字节或根本不存在。 UDP是否适合我的需求？

2）是否存在最小数据包大小？对于UDP？换句话说，当我的客户端向服务器发送4字节的有效负载时，由于最小的数据包大小，实际上是否有更多的字节通过线路？我对TCP / IP的速度不太高，但我知道有一种称为最小传输单元（MTU）的东西，可以设置为高达1,500字节左右。
我的4字节通知是否会被填充有1,496个额外字节？我得到这个问题的答案是非常重要的，因为我的应用程序需要节省带宽[我可能有1000'的同时会话。在任何给定的时间]。

提前感谢您提供的任何帮助！

-
真诚的，

David Sworder
http://www.CodeFanatic.com

David，


1）您将获得全部或全部数据报。 UDP适合你吗？我将

列出每个TCP&的一些优缺点。 UDP让你决定。


UDP：

无连接 - 没有连接。 "会话"经常用于模仿连接的
。由于没有连接，你不知道它何时被破坏（另一端断开连接）。主机通常会在
时没有收到某种脉冲（在您的情况下，会话ID）数据报中移除客户端。

这可能发生在其他设备实际上关闭了，这对你来说可能是好事还是坏事。


比TCP更少的开销 - 数据报发送一次，无论是他们还是

他们没有成功。


基于数据包 - 你正在处理数据报（数据包）。


TCP：

基于连接 - 两端都知道对等体何时断开连接


比UDP更多的开销 - 帧（TCP的数据包）将是如果

另一方不承认他们，则表示不满。这比UDP效率低，但是当您在UDP中构建ACK /重试/订单时，它们的效率大约相同

效率水平。


基于流 - 您正在处理连续的数据流。你可以

像流一样处理流，但实际上并不是这个想法。


这些都是优点。如果您正在寻找更多信息，有很多论据支持互联网上的每个

协议。


2）最小数据报大小为1个字节。 MTU意味着MAXIMUM发送单元，

不是最小值。对于UDP数据包，Winsock堆栈将通过网络发送另一个20 b字节（12个用于IP报头，8个用于UDP报头）。这20个字节

是所需的UDP / IP头，它们不是填充字节。 1500是

标准 UDP数据报的MTU。当我设置我的MTU

到512时，我得到最好的结果.YMMV。


当然，这只是我的0.02。

David,

1) You will get either all or none of the datagram. Is UDP for you? I will
list some pro/cons of each TCP & UDP and let you decide.

UDP:
Connectionless - there is no connection. "sessions" are frequently used to
simulate a connection. Since there is no connection, you don''t know when it
is broken (other end disconnects). The host typically removes a client when
it hasn''t received some sort of pulse (in your case, session ID) datagram.
This can happen some time after the other device actually shuts off, which
may be good or bad for you.

Less overhead than TCP - datagrams are sent once, either they make it or
they don''t make it.

Packet based - you are dealing with datagrams (packets).

TCP:
Connection based - both ends know when the peer has broken the connection

More overhead than UDP - frames (packets for TCP) will be resent if the
other side does not acknowledge them. This is less efficient than UDP, but
when you build ACK/retries/order into UDP they end up at about the same
efficiency level.

Stream based - you are dealing with a continious stream of data. You can
treat the stream like packets but it is not really the idea.

Those are the strong points. There are tons of arguments favoring each
protocol on the internet if you are looking for more information.

2) The minimum datagram size is 1 byte. MTU means MAXIMUM transmit unit,
not minimum. For a UDP packet, the Winsock stack will send across another
20 bytes (12 for IP header, 8 for UDP header) over the wire. These 20 bytes
are the UDP/IP headers which are required, they are not pad bytes. 1500 is
the "standard" MTU for UDP datagrams. I get best results when I set my MTU
to 512. YMMV.

Of course, this is all just my 0.02.

谢谢Zane和Trevor ......


这是很好的信息。鉴于UDP的开销很大（相对来说，给出了我的小有效载荷大小），我想知道是否可能更好地支持
只需保持TCP连接永远放置。我想这会消除对Keepalive的需求。缺点是服务器可以在任何给定时间保持1000'的空闲连接。这是另一个

有点相关的问题：


让我们说客户端和服务器有一个TCP连接。

客户端然后拔掉他的网络线[或采取一些其他行动

异常断开他的计算机而服务器没有接收TCP / IP

连接已关闭的通知]。

需要多长时间我的服务器才意识到连接已经死了？ TCP / IP是否有自己的

测试连接失败的机制？


-

此致


David Sworder
http：//www.CodeFanatic .com

Thanks Zane and Trevor...

That''s great information. Given the large overhead (relatively speaking,
given my small payload size) of UDP, I''m wondering if it might be better to
just keep the TCP connection in place at all times. I imagine this would
eliminate the need for keepalives. The downside is that the server could be
maintaining 1000''s of idle connections at any given time. Here''s another
somewhat related question:

Let''s say that the client and server have a TCP connection in place. The
client then unplugs his network cord [or takes some other action to
abnormally disconnect his computer without the server receiving a TCP/IP
notification that the connection has closed]. How long will it take before
my server realizes that the connection is dead? Does TCP/IP have it''s own
mechanism of testing for downed connections?

--
Sincerely,

David Sworder
http://www.CodeFanatic.com

这篇关于什么是最小大小的UDP数据包？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！