Net.Sockets.TcpClient发送大尺寸数据包出现数据丢失的问题排查

Tcp协议本身根本没有单包传输的硬尺寸限制，你碰到的随机丢包问题，本质是对同步Socket.Send方法的行为有误解，和SendBufferSize的阈值效应直接相关，不存在固定的故障截断点。

• SendBufferSize的真实定位：你当前看到的65536是操作系统给这个Socket预留的内核态发送缓冲区大小，根本不是应用层调用发送接口时的允许传输上限。调用同步Send方法时，接口的返回值是实际从用户态拷贝到内核发送缓冲区的字节数，不是你传进去的整个字节数组的总长度。
• 故障到底怎么发生的：你测试用的单包在600KB以上，远大于64KB的内核缓冲区容量。正常情况下，内核会快速把缓冲区里已经缓存的数据通过回环路径发出去，腾出空间让应用层把剩下的字节继续拷进内核；但如果碰到系统线程调度抖动、回环网卡中断处理延迟，内核缓冲区没及时腾出足够空间，Send方法就会拷贝满当前能装的部分直接返回，根本不会自动把剩下的字节补拷进内核缓冲区。你没检查Send的返回值，默认1MB整包已经全发出去了，实际上剩下的字节还卡在客户端的用户态内存里，根本没进到Socket管道，服务端当然收不全。
• 为什么故障点刚好在600KB附近波动：这个阈值根本不是Tcp或者TcpClient内置的限制，是本地回环环境下内核缓冲区的常规排空速度决定的。系统调度顺畅的时候，哪怕单包1MB也能一次性把全量数据拷完，测试就顺利通过；碰到调度抖动，Send提前返回，故障就随机出现。单包降到512KB以下时，就算碰到轻微的调度抖动，也足够Send把全量数据拷完，测试就能保持稳定。

你现在写的发送代码是最容易踩坑的写法：

myClient.Client.Send(SendBytes)

这个方法根本不会保证你传进去的字节数组被完整发送，必须手动跟踪已发送的字节偏移，循环把全量数据拷进内核发送层，才算真的把一个完整数据包推出去：

Dim totalSent As Integer = 0
' 循环直到整个数据包全部拷入内核发送缓冲区
While totalSent < SendBytes.Length
    Dim currentSent As Integer = myClient.Client.Send(
        SendBytes, 
        totalSent, 
        SendBytes.Length - totalSent, 
        SocketFlags.None
    )
    ' 连接断开时直接抛错，避免静默丢包
    If currentSent = 0 Then Throw New InvalidOperationException("Socket连接已中断")
    totalSent += currentSent
End While

Tcp本身的自动拆包逻辑，只能作用于已经进到内核发送缓冲区的数据，根本管不到还滞留在应用层用户态内存里的字节。

• 盲目把SendBufferSize调大只能缓解症状，治不了根。比如把发送缓冲区调到2MB，够一次性装下你的1MB测试包，确实能大幅降低故障概率，但只要碰到高系统负载、真实网络带宽更低的环境，缓冲区再次被占满的时候，同样的丢包问题还会复现。
• 你之前测试流程里觉得“管道内的待处理数据不会超过单包大小”的判断是错的：因为有一部分数据根本没从客户端进程发出去，卡在用户态内存里，服务端等不到全量数据超时、客户端等不到服务端ACK超时，本质是双端状态错位，根本不是网络传输中途的随机丢包。

内容的提问来源于stack exchange，提问作者Martin