Client端的程序是不可改变的，然后针对这个Client端写一个Server端的程序，Client端和Server器采用的是TCP连接，Client端发送好几条报文给Server端，Server端这边调用Recv函数接收报文变成了一条，而不是一条一条接收？怎么让服务器端接收的报文也是和发送时一样变成多条。程序是Windows平台VC编写。
你确定 client 那边是一条一条的发送的吗？
接受处理程序应该是逐字节处理，不能指望一个recv操作就刚好是一个整包。这里有个网络缓冲区机制的嘛。
socket recv后要自己按字节长度拆包的. 按client端每一帧传过来的报文长度拆成相应的数据报
socket 本身会出现，粘包，和分包的情况，这种自己要处理的，处理分包，粘包非常简单，你可以网上搜索一下
socket recv是按照参数规定的长度读取，因此，通常需要分包或者组包才能形成完整的一条报文。而报文的长度是协议来规定的，固定长度的报文，按照固定的长度读取。非固定的，需要计算长度和起始位置，这也需要协议的支撑。需要自己根据协议实现
定义客户端与服务器端的协议，帧头结构体、数据包结构里面定义好比如帧头标识符、包长度，这样按照帧头里面解析的长度接受此帧头下包数据
以上的各位差不多都需要定义好协议，问题是客户端不是我们开发的，不知道协议，所以无法做到拆包合包。
但是WPE之类的封包工具能够分出一帧一帧来。
对tcp协议的理解错误。tcp只是保证发送顺序和接收顺序一致，并不保证你发送的内容，一定会同时到达接收端。这是新手常见的错误。
什么粘包之类的说法都是民科的外行话。tcp根本没有保证你Send一次就是一个包。
tcp的nagle算法是为了流量吞吐最大化。比如，你发送的字节数，达到它预定的字节数，比如是536，它会发包。如果没达到，等一定时间，也会发包。
假如你发了一个很大的包，比如是1000，超过536了，它会拆成2个包发。假如你第一次发2字节，第二次发3字节，一直凑不够一个包，
也不能无限期等待，它会在到达超时时间后，也会发5个字节的包。
但这些，对于应用层都是透明的。
根本就不应该假设，send一次是多少个字节，接收端就收到多少字节。
应该根据协议来决定如何接收。比如协议有表示长度的字段叫length，4字节，那么就先读4字节，然后根据length的值是多少，就再读多少字节。