socket.Receive(buf, 4096, SocketFlags.None);
这里的4096，最大值为多少？？？
------解决思路----------------------
Socket.Receive Method (Byte[], Int32, SocketFlags)，看到了么，整数的最大值
------解决思路----------------------
取决于通讯协议。为什么通讯协议要限制包的大小？因为过大的包丢失的概率会更大。
这是起码的常识问题。
------解决思路----------------------
过大的包丢失概率会更大,而且过大的包占内存也多,如果是传数据,完全可以分成许多较小的包,收到就直接写入文件,而不是整个文件作为一个包一次性发送
------解决思路----------------------
如果是传数据->如果是传文件
如果仅仅是传数据,一般包都不会很大.
------解决思路----------------------
Byte[] 数组的长度决定，建议你用ping命令+L 测试你本机数据包大小的稳定性下。。要不怕丢数据包
------解决思路----------------------
越大越快的说法是不靠谱的
凭什么说越大就越快?
------解决思路----------------------
首先这个socket.Receive的大小与网络层没有任何关系，不需要考虑分包的事情，与丢包更没有关系。
其次确实是越大越快，不过这个快成指数级下降的，达到一定程度基本就没什么意义了，而且这个阀值一般网络环境都不大。
为什么数据包要小，因为怕爆内存。
------解决思路----------------------
这里说的丢包没有关系，是说接收缓冲区足够大的情况。
反过来，如果你socket.Receive(buf, 1, SocketFlags.None);，就很可能出现程序Receive跟不上网卡的情况，也就容易出现接收端造成的丢包故障。
------解决思路----------------------
1.如果仅仅是tcp/ip丢包的问题,tcp有重发机制,是不用应用层处理的
但是如果涉及到连接异常断开,错误重连,断点续传的问题,包过大的话,需要重传的内容也过多了
2.最终数据会通过网卡传输,而网卡中的缓存是有限的,内部会有机制从内存中传入网卡中再发送,包大到一定程度,CPU处理时间比起网络传输时间就可以忽略不计了
------解决思路----------------------
tcp丢包对应用层的逻辑处理可能没有影响，但是频繁重发将是灾难的祸端。
我也说快是成指数级下将的，看不懂啊。而且不仅仅是CPU处理时间，Tcp网络层对于数据包大小的处理，也一般是动态调整的。
------解决思路----------------------
网络是有固有延迟的，比如中国和美国相距1万5千千米的两个主机通讯，因为光速的存在，那么一来一回至少要0.1秒。那么如果采用应答/同步的方式传送数据，那么如果一个数据包是1KB，那么传输速度就不可能快于10KB/s。相反，一个数据包是1MB，那么速度就是10MB/s，这就是越大越快。
当然。现实情况是，数据传输往往不是应答模式，很多传输协议都有类似窗口/异步的概念，也就是这边发送完一个数据包，不等对方反馈是否收到，接着传下一个，所谓窗口，就是传一批（当然这是形象的比喻，具体google tcp滑动窗口机制）。即便这样，过小的数据包同样用在同步的时间上会更多。另外一点是，任何协议对数据打包，都需要额外的数据占位来保存诸如包编号、校验、时间戳等等附加的信息，如果包非常小，那么这些额外需要传输的数据和真正有效数据的占比就会大，那么也会使得传输效率低下。
总之，过犹不及，无论太大，太小都不好。
------解决思路----------------------
楼主所说的"包"的概念,并不是tcp/ip协议中的数据包,而是发送缓冲区和接收缓冲区大小
tcp/ip数据包是定长的,无论缓冲区大还是小,都会被拆包成固定大小并追加报文信息,再发送
所以不存在10MB的数据一次性发送到网络的情况,不管缓冲区大还是小,它都是依次发送出去的
当然,经过路由的时候,可能会经多路由转发
这个跟应用层没有任何关系啊