http响应的数据，永远不会长度为0，除非未收到响应。
http响应的内容分为多行，第一行中含有状态码，你先读取一行数据，如果有字符串中包含“200”字样，则说明是正常响应，如果是“404”则是网页未找到。要分析所有状态码自行百度。
然后读取后面每行数据，后面的数据格式为name: value，当发现有“Content-Length: ”这样的name存在，则后面更的内容就是文档长度。

恩，响应内容的格式是这样的。因为取的时候是按自定义的缓冲区大小存的，所以就想了解最后接收到的数据长度为什么是0，如果服务端发送的是socket.send(buffer,0,SocketFlags.None)的话，很明显不是这样；那么最后到底发送的是什么内容，接收端才能收到长度为0的数据

如果你写服务器端，输出是执行Flush（）方法之后，可以在延迟一段时间（例如50毫秒）之后直接关闭。

引用 2 楼 sunny906 的回复:

恩，响应内容的格式是这样的。因为取的时候是按自定义的缓冲区大小存的，所以就想了解最后接收到的数据长度为什么是0，如果服务端发送的是socket.send(buffer,0,SocketFlags.None)的话，很明显不是这样；那么最后到底发送的是什么内容，接收端才能收到长度为0的数据

receive是一个“阻塞”式的执行语句，因此如果服务器端没有输出，并不会在客户端返回什么。除非检查到关闭了。

#1楼的想当一部分描述是对的，如果你的客户端想要非常顾及“效率”，那么你应该在监听的足够长度的“body”字节数量时就结束，而不应该一味地等待 count==0 这个结果！

这里有着微妙的差别，有时候会让你的客户端变得快10倍。

引用 2 楼 sunny906 的回复:

恩，响应内容的格式是这样的。因为取的时候是按自定义的缓冲区大小存的，所以就想了解最后接收到的数据长度为什么是0，如果服务端发送的是socket.send(buffer,0,SocketFlags.None)的话，很明显不是这样；那么最后到底发送的是什么内容，接收端才能收到长度为0的数据

楼上已经回答了，我再深入下，由于Receive方法是阻塞的，只要发送方不发送内容，它这个方法永远不会返回结果，包括0字节都不可能。如果返回结果了，只有两种情况，一种是对方发送了数据，返回收到的字节数，另一种是对方关闭了Socket，那么就返回0字节，此时就理解为无阻塞了（tcp连接已被关闭，无法阻塞）。
那么对于Http请求，分为两种版本，HTTP 1.0版本是一次“请求—响应”就会结束连接的，你可以通过count != 0来判断数据接收完毕，但是HTTP1.1则不是，那个允许长连接，也就是一次连接发送多次HTTP请求，那么你就不能用count != 0来判断数据接收完毕了，必须判断Content-Length。因此在Socket模拟http的时候，一般都采用HTTP1.0版本，那个处理简单。

引用 6 楼 qldsrx 的回复:

如果返回结果了，只有两种情况，一种是对方发送了数据，返回收到的字节数，另一种是对方关闭了Socket，那么就返回0字节

+1