对于send函数：

    send函数只负责将数据提交给协议层。
   当调用该函数时，send先比较待发送数据的长度len和套接字s的发送缓冲区的长度，如果len大于s的发送缓冲区的长度，该函数返回SOCKET_ERROR；
    如果len小于或者等于s的发送缓冲区的长度，那么send先检查协议是否正在发送s的发送缓冲中的数据；
    如果是就等待协议把数据发送完，如果协议还没有开始发送s的发送缓冲中的数据或者s的发送缓冲中没有数据，那么send就比较s的发送缓冲区的剩余空间和len；
    如果len大于剩余空间大小，send就一直等待协议把s的发送缓冲中的数据发送完，如果len小于剩余空间大小，send就仅仅把buf中的数据copy到剩余空间里（注意并不是send把s的发送缓冲中的数据传到连接的另一端的，而是协议传的，send仅仅是把buf中的数据copy到s的发送缓冲区的剩余空间里）。
    如果send函数copy数据成功，就返回实际copy的字节数，如果send在copy数据时出现错误，那么send就返回SOCKET_ERROR；
    如果send在等待协议传送数据时网络断开的话，那么send函数也返回SOCKET_ERROR。要注意send函数把buf中的数据成功copy到s的发送缓冲的剩余空间里后它就返回了，但是此时这些数据并不一定马上被传到连接的另一端。
    如果协议在后续的传送过程中出现网络错误的话，那么下一个Socket函数就会返回SOCKET_ERROR。（每一个除send外的Socket函数在执行的最开始总要先等待套接字的发送缓冲中的数据被协议传送完毕才能继续，如果在等待时出现网络错误，那么该Socket函数就返回SOCKET_ERROR）   

”传输过程中通控制流程简单的判断下带宽和阻塞情况“我的问题就是这点，问怎么判断的

另外，你在其他软件中看到的传输速率变化其实是基于传输控制流程的原因，例如：

控制流程：S发一个包，等待C端返回该包已接收，如果超时则重发，超时三次则报错。

那么网速快的情况下，C端返回消息就快，那么等待时间少，占用的带宽就高，表现就是发的快。

网速慢，C端返回消息慢，那么S端更多的是在等消息，占用的带宽就小，表现就是发的慢。

实际应用中会同时发多个包，并给包标记，然后等待，以此充分利用带宽，也就是所谓的多线程收发。

@hailants:   发送文件时，我采用tcp结合udp，tcp用来发送文件中需要确认的信息（如文件名、大小、丢包索引等），数据包采用udp发送，不知道现在的大神们是采用纯tcp还是纯udp或者也结合？

@metoer: ”传输过程中通控制流程简单的判断下带宽和阻塞情况“我的问题就是这点，问怎么判断的

用 WSAGetQOSByName：

http://msdn.microsoft.com/en-us/library/windows/desktop/ms741587(v=vs.85).aspx

@Launcher: 请问多线程收发，是多个端口同时发送，多个端口同时接收？

@Launcher: 你要的带宽和阻塞情况与QOS还是有区别，QOS是在当前网络中请求达到某种服务质量，但不保证达到。感觉一般在局域网内部要求传输高质量视音频时才多会用到。

如果你是远程网络对端传输普通的文件，那么没必要用QOS。

我说的通过控制流程判断是这样理解：建立链接，发个命令，等待对方回复，送发送到收到回复之间的间隔越长说明网络状况越差，其实阻塞与带宽对于应用来说可以统一理解为网络状况，高带宽高阻塞和低带宽低阻塞是相当的。

多线程收发，TCP模式下，服务端是一个端口，客户端是多端口。例如：客户端请求服务器发送某文件，则首先建立一个链接，获取文件大小，然后再开辟多个链接，分别从服务器请求文件的不同区块的数据，所有链接接收完毕后，再将数据整合为一个文件，基本上就和下载软件一个道理。每个链接里面采用独立的传输控制流程，请求->接收->超时/校验重发