解决方案 »

  1.   

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

  2.   

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

  3.   

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

  4.   


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

  5.   

    #1楼的想当一部分描述是对的,如果你的客户端想要非常顾及“效率”,那么你应该在监听的足够长度的“body”字节数量时就结束,而不应该一味地等待 count==0 这个结果!这里有着微妙的差别,有时候会让你的客户端变得快10倍。
      

  6.   

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