目录
最大传输单元MTU
最大传输单元 (MTU)
IP 分段(IP Fragmentation)
Path MTU Discovery
关于网络编程中MTU、TCP、UDP优化配置的一些总结
TCP，UDP数据包的大小以及MTU
简略
什么是MTU
MTU：Maximum Transmission Unit,最大传输单元MTU。
以太网为例：
TCP/IP协议：链路层，网络层，传输层，应用层。 其中以太网(Ethernet)的数据帧在链路层
IP包在网络层 TCP或UDP包在传输层 TCP或UDP中的数据(Data)在应用层 它们的关系是 数据帧｛IP包｛TCP或UDP包｛Data｝｝｝
以太网MTU 就是IP包｛TCP或UDP包｛Data｝｝的size的上限，所以我们的data 一旦达到一定的值使得IP包size超过MTU ，发送端就需要分包。接收端就需要组包。
发送方IP层就需要将数据包分成若干片，而接收方IP层就需要进行数据报的重组。更严重的是，如果使用UDP协议，当IP层组包发生错误，那么包就会被丢弃。接收方无法重组数据报，将导致丢弃整个IP数据报。
可以通过增加MTU值来增加数据的传输效率。
1、MTU(Maximum Transmission Unit) 大小指的是一个以太帧(Ethernet Frame)能携带的最大数据部分(payload)的大小, 当MTU值设置为9000 Bytes的时候也叫做巨型帧(Jumbo Frame)
2、一般情况下网卡的MTU大小是1500(最大可配置到9000)，可以通过增加MTU值来增加数据的传输效率，MTU的增加即每帧(Frame)传输的数据量就会更大。
3、网络中的所有节点必须同时增大MTU，网络中小MTU的节点遇到上家发来的大于MTU的Frame(且没有切分标记)，则直接丢弃。
最大传输单元MTU
原文：最大傳輸單元 (Maximum Transmission Unit, MTU) - NotFalse 技術客
比较好的简介结构：https://www.cloudflare.com/zh-cn/learning/network-layer/what-is-mtu/
(Maximum Transmission Unit, MTU)
封装 与 拆装 一文，提及了 区段 (Segment)、资料包 (Datagram)、帧 (Frame)、封包 (Packet) 的概念。应用层的资料，经由逐层的 封装 (Encapsulation)，最后成为 数据链路层 (Data-Link Layer) 的 帧 (Frame) 并传送。
但是，帧 (Frame) 太大会发生什麽事?
传输需耗损大量的 缓衝区 (buffer) 大小 传输媒介可能被某一传送端独佔，造成堵塞 … 因此，数据链路 (Data-Link) 规范了 帧 (Frame) 的大小上限， 也就是 — — 最大传输单元 (Maximum Transmission Unit, MTU)， 如果没有这些缺点， MTU 当然越大越好啦!
最大传输单元 (MTU)
不同的 数据链路层，有不同的 MTU。 如: 以太网路 (Ethernet) 的 1500 个位元组， IEEE 802.3/802.2 的 1492 个位元组， 光纤分散式数据介面 (FDDI) 的 4352 个位元组…。 以 以太网路 (Etherner) 为例: 一个 以太网路 帧(Frame)，最大的长度为 1518 位元组 (octet)， 去掉表头与尾端数据后，载荷的最大资料长度则为 1500 octet， 且资料最小长度需为 46 octet，不足的话就用 填充位元 (padding) 填满至 46 为止。
使用指令:
netstat -i
可显示系统网路介面信息(含 MTU)
IP 分段 (IP Fragmentation)
网络层的 IPv4 与 IPv6， 其封包大小上限，分别为 65535 与 65575 位元组 (octet)， 并提供较大的封包选项 — — 巨型封包 (jumbograms)。 远远超出了许多数据链路层的 帧大小(MTU)! IP 分段 (IP Fragmentation) 即是其中一种解法:
IP 会将封包切割成多个较小的 (小于 MTU) 片段 (fragment)，使其能透过数据链路层传输 ， 目的端接收完所有片段后，再将片段 (fragment) 进行重组。
分段 (fragmentation)，可能由传输路径中的任何一台路由器来做 (含来源主机)， 且被分段的封包 — — 片段 (fragment) 可能经由不同路由方式， 只要最终达到相同的目的地即可。 (IPv6 只有来源端可以做分段) 将 IP 数据包 (IP Datagram) 分段的主机或路由器， 会复制必要栏位到各个片段中， 并更改 标志、片段偏移量、(封包)总长度，与重新计算各个分段的检验和。 (IP 检验和，不含虚拟表头) 最后，目的端接收完所有片段后，再将片段 (fragment) 进行重组：
IP Datagram 格式
将在未来讨论 IP 协定进一步说明。
Path MTU Discovery
如果 IP Fragmentation 任一片段遗失、毁损呢?
答案是: 目的端将无法重组这个封包。 更重要的是:
网路层的 IP 并不会处理重送
这对有重送机制的传输层 (Ex: TCP)，降低了传输效率 (无法只重送一个 片段)； 对没有重送机制的传输层 (Ex: UDP)，增加了资料的遗失率。 Path MTU Discovery 技术，有效的避免 IP Fragmentation:
找出 来源 与 目的端路径中， 所有数据连接层的 最小 MTU。 (通常，为以太网路的 1500 octet)
许多可靠的传输层 (如: TCP)，会以此值做为参考， 调整 最大区段长度 (Maximum Segment Size, MSS)。 最简单的算法:
MSS = MTU - 20 octet (TCP 固定表头) - 20 octet (IP 固定表头)
或 其他动态调整演算法，
常见的 MSS 有 1460、1400、1380…。
而没有此机制的传输层 (如: UDP)，则是选择适当的 数据报 (Datagram) 大小，
确保传输的 IP 封包，会小于 IPv4 的最小可重组缓衝区大小 (576 octet)，避免 IP Fragmentation。
关于网络编程中MTU、TCP、UDP优化配置的一些总结
原文：https://www.cnblogs.com/maowang1991/archive/2013/04/15/3022955.html
首先要看TCP/IP协议，涉及到四层：链路层，网络层，传输层，应用层。 其中以太网(Ethernet)的数据帧在链路层 IP包在网络层 TCP或UDP包在传输层 TCP或UDP中的数据(Data)在应用层 它们的关系是 数据帧｛IP包｛TCP或UDP包｛Data｝｝｝ --------------------------------------------------------------------------------- 在应用程序中我们用到的Data的长度最大是多少，直接取决于底层的限制。 我们从下到上分析一下： 1.在链路层，由以太网的物理特性决定了数据帧的长度为(46＋18)－(1500＋18)，其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500(不包括帧头和帧尾)---(怀疑，现在还是1500？“历史网络媒体速度较慢，更容易出错，因此MTU Size设置得较小。对于大多数以太网，此设置为1500字节……”见：【MTU】关于MTU size| MTU size, PMTUD 和分段_bandaoyu的博客-CSDN博客_mtu大小)，即MTU(Maximum Transmission Unit)为1500；
2.在网络层，因为IP包的首部要占用20字节，所以这的MTU为1500－20＝1480； 3.在传输层，对于UDP包的首部要占用8字节，所以这的MTU为1480－8＝1472； 所以，在应用层，你的Data最大长度为1472。 (当我们的UDP包中的数据多于MTU(1472)时，发送方的IP层需要分片fragmentation进行传输，而在接收方IP层则需要进行数据报重组，由于UDP是不可靠的传输协议，如果分片丢失导致重组失败，将导致UDP数据包被丢弃)。 从上面的分析来看，在普通的局域网环境下，UDP的数据最大为1472字节最好(避免分片重组)。 但在网络编程中，Internet中的路由器可能有设置成不同的值(小于默认值)，Internet上的标准MTU值为576，所以Internet的UDP编程时数据长度最好在576－20－8＝548字节以内。 --------------------------------------------------------------------------------- MTU对我们的UDP编程很重要，那如何查看路由的MTU值呢？ 对于windows OS: ping -f -l 如：ping -f -l 1472 192.168.0.1 如果提示：Packets needs to be fragmented but DF set. 则表明MTU小于1500，不断改小data_length值，可以最终测算出gateway的MTU值； 对于linux OS: ping -c -M do -s 如： ping -c 1 -M do -s 1472 192.168.0.1 如果提示 Frag needed and DF set…… 则表明MTU小于1500，可以再测以推算gateway的MTU。
原理：ping程序使用ICMP报文，ICMP报文首部占8字节，IP数据报首部占20字节，因此在数据大小基础上加上28字节为MTU值。
---------------------------------------------------------------------------------
IP数据包的最大长度是64K字节(65535)，因为在IP包头中用2个字节描述报文长度，2个字节所能表达的最大数字就是65535。 由于IP协议提供为上层协议分割和重组报文的功能，因此传输层协议的数据包长度原则上来说没有限制。实际上限制还是有的，因为IP包的标识字段终究不可能无限长，按照IPv4，好像上限应该是4G(64K*64K)。依靠这种机制，TCP包头中就没有“包长度”字段，而完全依靠IP层去处理分帧。这就是为什么TCP常常被称作一种“流协议”的原因，开发者在使用TCP服务的时候，不必去关心数据包的大小，只需讲SOCKET看作一条数据流的入口，往里面放数据就是了，TCP协议本身会进行拥塞/流量控制。 UDP则与TCP不同，UDP包头内有总长度字段，同样为两个字节，因此UDP数据包的总长度被限制为65535，这样恰好可以放进一个IP包内，使得UDP/IP协议栈的实现非常简单和高效。65535再减去UDP头本身所占据的8个字节，UDP服务中的最大有效载荷长度仅为65527。这个值也就是你在调用getsockopt()时指定SO_MAX_MSG_SIZE所得到返回值，任何使用SOCK_DGRAM属性的socket，一次send的数据都不能超过这个值，否则必然得到一个错误。 那么，IP包提交给下层协议时将会得到怎样的处理呢？这就取决于数据链路层协议了，一般的数据链路层协议都会负责将IP包分割成更小的帧，然后在目的端重组它。在EtherNet上，数据链路帧的大小如以上几位大侠所言。而如果是IP over ATM，则IP包将被切分成一个一个的ATM Cell，大小为53字节。
一些典型的MTU值：
网络： MTU字节 超通道 65535 16Mb/s信息令牌环(IBM) 17914 4Mb/s令牌环(IEEE802.5) 4464 FDDI 4352 以太网 1500 IEEE802.3/802.2 1492 X.25 576 点对点(低时延) 296
路径MTU：如果两台主机之间的通信要通过多个网络，那么每个网络的链路层就可能有不同的MTU。重要的不是两台主机所在网络的MTU的值，重要的是两台通信主机路径中的最小MTU。它被称作路径MTU。
Tcp传输中的nagle算法
TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。(一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据)。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。
Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。
1. Nagle算法的规则：
(1)如果包长度达到MSS，则允许发送；
(2)如果该包含有FIN，则允许发送；
(3)设置了TCP_NODELAY选项，则允许发送；
(4)未设置TCP_CORK选项时，若所有发出去的小数据包(包长度小于MSS)均被确认，则允许发送；
(5)上述条件都未满足，但发生了超时(一般为200ms)，则立即发送。
Nagle算法只允许一个未被ACK的包存在于网络，它并不管包的大小，因此它事实上就是一个扩展的停-等协议，只不过它是基于包停-等的，而不是基于字节停-等的。Nagle算法完全由TCP协议的ACK机制决定，这会带来一些问题，比如如果对端ACK回复很快的话，Nagle事实上不会拼接太多的数据包，虽然避免了网络拥塞，网络总体的利用率依然很低。
Nagle算法是silly window syndrome(SWS)预防算法的一个半集。SWS算法预防发送少量的数据，Nagle算法是其在发送方的实现，而接收方要做的时不要通告缓冲空间的很小增长，不通知小窗口，除非缓冲区空间有显著的增长。这里显著的增长定义为完全大小的段(MSS)或增长到大于最大窗口的一半。
注意：BSD的实现是允许在空闲链接上发送大的写操作剩下的最后的小段，也就是说，当超过1个MSS数据发送时，内核先依次发送完n个MSS的数据包，然后再发送尾部的小数据包，其间不再延时等待。(假设网络不阻塞且接收窗口足够大)。
举个例子，一开始client端调用socket的write操作将一个int型数据(称为A块)写入到网络中，由于此时连接是空闲的(也就是说还没有未被确认的小段)，因此这个int型数据会被马上发送到server端，接着，client端又调用write操作写入‘\r\n’(简称B块)，这个时候，A块的ACK没有返回，所以可以认为已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到(大概40ms之后)，B块才被发送。整个过程如图所示：
这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是因为TCP/IP中不仅仅有nagle算法，还有一个TCP确认延迟机制 。当Server端收到数据之后，它并不会马上向client端发送ACK，而是会将ACK的发送延迟一段时间(假设为t)，它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么'\r\n'(B块)总是在A块之后40ms才发出。
当然，TCP确认延迟40ms并不是一直不变的，TCP连接的延迟确认时间一般初始化为最小值40ms，随后根据连接的重传超时时间(RTO)、上次收到数据包与本次接收数据包的时间间隔等参数进行不断调整。另外可以通过设置TCP_QUICKACK选项来取消确认延迟。
关于TCP确认延迟的详细介绍可参考：http://blog.csdn.net/turkeyzhou/article/details/6764389
2. TCP_NODELAY 选项
默认情况下，发送数据采用Negale 算法。这样虽然提高了网络吞吐量，但是实时性却降低了，在一些交互性很强的应用程序来说是不允许的，使用TCP_NODELAY选项可以禁止Negale 算法。
此时，应用程序向内核递交的每个数据包都会立即发送出去。需要注意的是，虽然禁止了Negale 算法，但网络的传输仍然受到TCP确认延迟机制的影响。
3. TCP_CORK 选项
所谓的CORK就是塞子的意思，形象地理解就是用CORK将连接塞住，使得数据先不发出去，等到拔去塞子后再发出去。设置该选项后，内核会尽力把小数据包拼接成一个大的数据包(一个MTU)再发送出去，当然若一定时间后(一般为200ms，该值尚待确认)，内核仍然没有组合成一个MTU时也必须发送现有的数据(不可能让数据一直等待吧)。
然而，TCP_CORK的实现可能并不像你想象的那么完美，CORK并不会将连接完全塞住。内核其实并不知道应用层到底什么时候会发送第二批数据用于和第一批数据拼接以达到MTU的大小，因此内核会给出一个时间限制，在该时间内没有拼接成一个大包(努力接近MTU)的话，内核就会无条件发送。也就是说若应用层程序发送小包数据的间隔不够短时，TCP_CORK就没有一点作用，反而失去了数据的实时性(每个小包数据都会延时一定时间再发送)。
4. Nagle算法与CORK算法区别
Nagle算法和CORK算法非常类似，但是它们的着眼点不一样，Nagle算法主要避免网络因为太多的小包(协议头的比例非常之大)而拥塞，而CORK算法则是为了提高网络的利用率，使得总体上协议头占用的比例尽可能的小。如此看来这二者在避免发送小包上是一致的，在用户控制的层面上，Nagle算法完全不受用户socket的控制，你只能简单的设置TCP_NODELAY而禁用它，CORK算法同样也是通过设置或者清除TCP_CORK使能或者禁用之，然而Nagle算法关心的是网络拥塞问题，只要所有的ACK回来则发包，而CORK算法却可以关心内容，在前后数据包发送间隔很短的前提下(很重要，否则内核会帮你将分散的包发出)，即使你是分散发送多个小数据包，你也可以通过使能CORK算法将这些内容拼接在一个包内，如果此时用Nagle算法的话，则可能做不到这一点。
实际上Nagle算法并不是很复杂，他的主要职责是数据的累积，实际上有两个门槛：一个就是缓 冲区中的字节数达到了一定量，另一个就是等待了一定的时间(一般的Nagle算法都是等待200ms)；这两个门槛的任何一个达到都必须发送数据了。一般 情况下，如果数据流量很大，第二个条件是永远不会起作用的，但当发送小的数据包时，第二个门槛就发挥作用了，防止数据被无限的缓存在缓冲区不是好事情哦。 了解了TCP的Nagle算法的原理之后我们可以自己动手来实现一个类似的算法了，在动手之前我们还要记住一个重要的事情，也是我们动手实现Nagle算 法的主要动机就是我想要紧急发送数据的时候就要发送了，所以对于上面的两个门槛之外还的增加一个门槛就是紧急数据发送。
对于我现在每秒钟10次数据发送，每次数据发送量固定在85~100字节的应用而言，如果采用默认的开启Nagle算法，我在发送端，固定每帧数据85个，间隔100ms发送一次，我在接受端(阻塞方式使用)接受的数据是43 138交替出现，可能就是这个算法的时间阈值问题，如果关闭Nagle算法，在接收端就可以保证数据每次接收到的都是85帧。
Nagle算法适用于小包、高延迟的场合，而对于要求交互速度的b/s或c/s就不合适了。socket在创建的时候，默认都是使用Nagle算法的，这会导致交互速度严重下降，所以需要setsockopt函数来设置TCP_NODELAY为1.不过取消了Nagle算法，就会导致TCP碎片增多，效率可能会降低。
关闭nagle算法,以免影响性能，因为控制时控制端要发送很多数据量很小的数据包,需要马上发送。
const char chOpt = 1; int nErr = setsockopt(pContext->m_Socket, IPPROTO_TCP, TCP_NODELAY, &chOpt, sizeof(char));
if (nErr == -1) {
TRACE(_T("setsockopt()?error\n"), WSAGetLastError()); return;
} setsockopt(sockfd, SOL_TCP, TCP_CORK, &on, sizeof(on)); //set TCP_CORK
TCP传输小数据包效率问题
摘要：当使用TCP传输小型数据包时，程序的设计是相当重要的。如果在设计方案中不对TCP数据包的延迟应答，Nagle算法，Winsock缓冲作用引起重视，将会严重影响程序的性能。这篇文章讨论了这些问题，列举了两个案例，给出了一些传输小数据包的优化设计方案。
背景：当Microsoft TCP栈接收到一个数据包时，会启动一个200毫秒的计时器。当ACK确认数据包 发出之后，计时器会复位，接收到下一个数据包时，会再次启动200毫秒的计时器。为了提升应用程序在内部网和Internet上的传输性能，Microsoft TCP栈使用了下面的策略来决定在接收到数据包后 什么时候发送ACK确认数据包： 1、如果在200毫秒的计时器超时之前，接收到下一个数据包，则立即发送ACK确认数据包。 2、如果当前恰好有数据包需要发给ACK确认信息的接收端，则把ACK确认信息附带在数据包上立即发送。 3、当计时器超时，ACK确认信息立即发送。 为了避免小数据包拥塞网络，Microsoft TCP栈默认启用了Nagle算法，这个算法能够将应用程序多次 调用Send发送的数据拼接起来，当收到前一个数据包的ACK确认信息时，一起发送出去。下面是Nagle 算法的例外情况： 1、如果Microsoft TCP栈拼接起来的数据包超过了MTU值，这个数据会立即发送，而不等待前一个数据 包的ACK确认信息。在以太网中，TCP的MTU(Maximum Transmission Unit)值是1460字节。 2、如果设置了TCP_NODELAY选项，就会禁用Nagle算法，应用程序调用Send发送的数据包会立即被投递到网络，而没有延迟。为了在应用层优化性能，Winsock把应用程序调用Send发送的数据从应用程序的缓冲区复制到Winsock内核缓冲区。Microsoft TCP栈利用类似Nagle算法的方法，决定什么时候才实际地把数据投递到网络。内核缓冲区的默认大小是8K，使用SO_SNDBUF选项，可以改变Winsock内核缓冲区的大小。如果有必要的话，Winsock能缓冲大于SO_SNDBUF缓冲区大小的数据。在绝大多数情况下，应用程序完成Send调用仅仅表明数据被复制到了Winsock内核缓冲区，并不能说明数据就实际地被投递到了网络上。唯一一种例外的情况是：
通过设置SO_SNDBUT为0禁用了Winsock内核缓冲区。
Winsock使用下面的规则来向应用程序表明一个Send调用的完成： 1、如果socket仍然在SO_SNDBUF限额内，Winsock复制应用程序要发送的数据到内核缓冲区，完成Send调用。 2、如果Socket超过了SO_SNDBUF限额并且先前只有一个被缓冲的发送数据在内核缓冲区，Winsock复制要发送 的数据到内核缓冲区，完成Send调用。 3、如果Socket超过了SO_SNDBUF限额并且内核缓冲区有不只一个被缓冲的发送数据，Winsock复制要发送的数据 到内核缓冲区，然后投递数据到网络，直到Socket降到SO_SNDBUF限额内或者只剩余一个要发送的数据，才 完成Send调用。
案例1 一个Winsock TCP客户端需要发送10000个记录到Winsock TCP服务端，保存到数据库。记录大小从20字节到100 字节不等。对于简单的应用程序逻辑，可能的设计方案如下： 1、客户端以阻塞方式发送，服务端以阻塞方式接收。 2、客户端设置SO_SNDBUF为0，禁用Nagle算法，让每个数据包单独的发送。 3、服务端在一个循环中调用Recv接收数据包。给Recv传递200字节的缓冲区以便让每个记录在一次Recv调用中 被获取到。
性能： 在测试中发现，客户端每秒只能发送5条数据到服务段，总共10000条记录，976K字节左右，用了半个多小时 才全部传到服务器。
分析： 因为客户端没有设置TCP_NODELAY选项，Nagle算法强制TCP栈在发送数据包之前等待前一个数据包的ACK确认 信息。然而，客户端设置SO_SNDBUF为0，禁用了内核缓冲区。因此，10000个Send调用只能一个数据包一个数据 包的发送和确认，由于下列原因，每个ACK确认信息被延迟200毫秒： 1、当服务器获取到一个数据包，启动一个200毫秒的计时器。 2、服务端不需要向客户端发送任何数据，所以，ACK确认信息不能被发回的数据包顺路携带。 3、客户端在没有收到前一个数据包的确认信息前，不能发送数据包。 4、服务端的计时器超时后，ACK确认信息被发送到客户端。
如何提高性能： 在这个设计中存在两个问题。第一，存在延时问题。客户端需要能够在200毫秒内发送两个数据包到服务端。 因为客户端默认情况下使用Nagle算法，应该使用默认的内核缓冲区，不应该设置SO_SNDBUF为0。一旦TCP 栈拼接起来的数据包超过MTU值，这个数据包会立即被发送，不用等待前一个ACK确认信息。第二，这个设计 方案对每一个如此小的的数据包都调用一次Send。发送这么小的数据包是不很有效率的。在这种情况下，应该 把每个记录补充到100字节并且每次调用Send发送80个记录。为了让服务端知道一次总共发送了多少个记录， 客户端可以在记录前面带一个头信息。
案例二： 一个Winsock TCP客户端程序打开两个连接和一个提供股票报价服务的Winsock TCP服务端通信。第一个连接 作为命令通道用来传输股票编号到服务端。第二个连接作为数据通道用来接收股票报价。两个连接被建立后， 客户端通过命令通道发送股票编号到服务端，然后在数据通道上等待返回的股票报价信息。客户端在接收到第一 个股票报价信息后发送下一个股票编号请求到服务端。客户端和服务端都没有设置SO_SNDBUF和TCP_NODELAY 选项。
性能： 测试中发现，客户端每秒只能获取到5条报价信息。
分析：
这个设计方案一次只允许获取一条股票信息。第一个股票编号信息通过命令通道发送到服务端，立即接收到 服务端通过数据通道返回的股票报价信息。然后，客户端立即发送第二条请求信息，send调用立即返回， 发送的数据被复制到内核缓冲区。然而，TCP栈不能立即投递这个数据包到网络，因为没有收到前一个数据包的 ACK确认信息。200毫秒后，服务端的计时器超时，第一个请求数据包的ACK确认信息被发送回客户端，客户端 的第二个请求包才被投递到网络。第二个请求的报价信息立即从数据通道返回到客户端，因为此时，客户端的 计时器已经超时，第一个报价信息的ACK确认信息已经被发送到服务端。这个过程循环发生。
如何提高性能： 在这里，两个连接的设计是没有必要的。如果使用一个连接来请求和接收报价信息，股票请求的ACK确认信息会 被返回的报价信息立即顺路携带回来。要进一步的提高性能，客户端应该一次调用Send发送多个股票请求，服务端 一次返回多个报价信息。如果由于某些特殊原因必须要使用两个单向的连接，客户端和服务端都应该设置TCP_NODELAY 选项，让小数据包立即发送而不用等待前一个数据包的ACK确认信息。
提高性能的建议： 上面两个案例说明了一些最坏的情况。当设计一个方案解决大量的小数据包发送和接收时，应该遵循以下的建议： 1、如果数据片段不需要紧急传输的话，应用程序应该将他们拼接成更大的数据块，再调用Send。因为发送缓冲区 很可能被复制到内核缓冲区，所以缓冲区不应该太大，通常比8K小一点点是很有效率的。只要Winsock内核缓冲区 得到一个大于MTU值的数据块，就会发送若干个数据包，剩下最后一个数据包。发送方除了最后一个数据包，都不会 被200毫秒的计时器触发。 2、如果可能的话，避免单向的Socket数据流接连。 3、不要设置SO_SNDBUF为0，除非想确保数据包在调用Send完成之后立即被投递到网络。事实上，8K的缓冲区适合大多数 情况，不需要重新改变，除非新设置的缓冲区经过测试的确比默认大小更高效。 4、如果数据传输不用保证可靠性，使用UDP。
TCP，UDP数据包的大小以及MTU
转自：TCP，UDP数据包的大小以及MTU_Answer-3的博客-CSDN博客_一个tcp包mtu的大小
TCP、UDP数据包大小的确定
UDP和TCP协议利用端口号实现多项应用同时发送和接收数据。数据通过源端口发送出去，通过目标端口接收。有的网络应用只能使用预留或注册的静态端口；而另外一些网络应用则可以使用未被注册的动态端口。因为UDP和TCP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。动态端口的范围是从1024到65535。
MTU最大传输单元，这个最大传输单元实际上和链路层协议有着密切的关系，EthernetII帧的结构DMAC+SMAC+Type+Data+CRC由于以太网传输电气方面的限制，每个以太网帧都有最小的大小64bytes最大不能超过1518bytes，对于小于或者大于这个限制的以太网帧我们都可以视之为错误的数据帧，一般的以太网转发设备会丢弃这些数据帧。
由于以太网EthernetII最大的数据帧是1518Bytes这样，刨去以太网帧的帧头(DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes)14Bytes和帧尾CRC校验部分4Bytes那么剩下承载上层协议的地方也就是Data域最大就只能有1500Bytes这个值我们就把它称之为MTU。
UDP 包的大小就应该是 1500 - IP头(20) - UDP头(8) = 1472(BYTES) TCP 包的大小就应该是 1500 - IP头(20) - TCP头(20) = 1460 (BYTES)
注*PPPoE所谓PPPoE就是在以太网上面跑“PPP”。随着宽带接入(这种宽带接入一般为Cable Modem或者xDSL或者以太网的接入)，因为以太网缺乏认证计费机制而传统运营商是通过PPP协议来对拨号等接入服务进行认证计费的，所以引入PPPoE。PPPoE导致MTU变小了以太网的MTU是1500，再减去PPP的包头包尾的开销(8Bytes)，就变成1492。不过目前大多数的路由设备的MTU都为1500。
如果我们定义的TCP和UDP包没有超过范围，那么我们的包在IP层就不用分包了，这样传输过程中就避免了在IP层组包发生的错误；如果超过范围，既IP数据报大于1500字节，发送方IP层就需要将数据包分成若干片，而接收方IP层就需要进行数据报的重组。更严重的是，如果使用UDP协议，当IP层组包发生错误，那么包就会被丢弃。接收方无法重组数据报，将导致丢弃整个IP数据报。UDP不保证可靠传输；但是TCP发生组包错误时，该包会被重传，保证可靠传输。
UDP数据报的长度是指包括报头和数据部分在内的总字节数，其中报头长度固定，数据部分可变。数据报的最大长度根据操作环境的不同而各异。从理论上说，包含报头在内的数据报的最大长度为65535字节(64K)。
我们在用Socket编程时， UDP协议要求包小于64K，TCP没有限定。
不过鉴于Internet上的标准MTU值为576字节，所以建议在进行Internet的UDP编程时，最好将UDP的数据长度控制在548字节 (576-8-20)以内。
就具体函数而言：
用UDP协议发送时，用sendto函数最大能发送数据的长度为：65535- IP头(20) - UDP头(8)＝65507字节。用sendto函数发送数据时，如果发送数据长度大于该值，则函数会返回错误。
用TCP协议发送时，由于TCP是数据流协议，因此不存在包大小的限制(暂不考虑缓冲区的大小)，这是指在用send函数时，数据长度参数不受限制。而实际上，所指定的这段数据并不一定会一次性发送出去，如果这段数据比较长，会被分段发送，如果比较短，可能会等待和下一次数据一起发送。
文章来源
发表评论