.Net C# TcpClient / Socket HTTP 客户端性能/效率
我正在使用 .Net TcpClient / Sockets 编写 HTTP 客户端。
到目前为止，客户端通过迭代 NetworkStream 响应（在向 TcpClient 写入 GET 请求之后）、解析标头并检索相关消息正文字节/分块字节来处理 Content-Length 和分块响应。为此，它使用 NetworkStream ReadByte 方法。
这一切都工作正常，但性能是应用程序的一个关键考虑因素，因此我希望使其尽可能快速和高效。
最初，这将涉及将消息正文的 ReadByte 交换为 Read（基于内容长度）或将分块消息正文字节检索到适当大小的缓冲区中，在所有其他区域（例如读取标头、块大小等）中使用 ReadByte。
我有兴趣了解更好/不同的方法来实现最佳性能的想法？显然，HTTP 的主要问题是不知道响应流的长度，除非在检索时对其进行解析。
我没有为此使用更多抽象类（例如 HttpWebRequest）有一个具体原因（我需要在套接字级别进行更好的控制）。
非常感谢，
克里斯
I'm writing an HTTP client using the .Net TcpClient / Sockets.
So far, the client handles both Content-Length and chunked responses by iterating through the NetworkStream response (after writing a GET request to the TcpClient), parsing the headers and retrieving the relevant message body bytes / chunked bytes. To do this it uses the NetworkStream ReadByte method.
This all works fine, but performance is a key consideration of the application so I would like to make it as quick and efficient as possible.
Initially this will involve swapping ReadByte for Read for the message body (based on Content-Length) or chunked message body byte retrieval into an appropriately sized buffer, using ReadByte in all other areas (such as reading the Headers, Chunk sizes etc).
I'm interested to know thoughts on better / different ways to do this to achieve optimum performance? Obviously the main problem with HTTP is not knowing the length of the response stream unless it is parsed as it is retrieved.
There a specific reasons why I'm not using more abstract classes (eg HttpWebRequest) for this (I need better control at the socket level).
Many Thanks,
Chris
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议使用具有中等大小缓冲区的进程。重复填充缓冲区，直到响应流结束。当缓冲区已满或流结束时，将该缓冲区内容附加到字符串（或用于存储消息的任何内容）上。
如果您想在流的早期读取重要信息，请读取足够的流以查看该信息。 （换句话说，如果您不想，则无需在第一次传递时填充缓冲区。）
您还应该考虑使用事件系统来指示新数据的存在，这些数据已形成这样的形式：这样，您的流程的主要部分就不需要知道任何有关数据来自何处或如何缓冲数据的信息。
编辑
为了回答您的评论问题，如果您尝试将一个连接重复用于多个请求，您将创建一个线程来反复读取该连接。当它找到数据时，它使用事件将其推出以供程序的主要部分处理。我手边没有示例，但您应该能够通过一些 bing 或 google 搜索找到几个示例。
I suggest using a process with a medium sized buffer. Repeatedly fill the buffer until the response stream ends. When the buffer is full, or the stream ends, attach that buffer content onto the string (or whatever you're using to store the message).
If you want to read an important bit of information early in the stream, read just enough of the stream to see that. (In other words, you don't need to fill the buffer on the first pass if you don't want to.)
You should also consider using an event system to signal the presence of new data, which has been shaped in such a way that the main part of your process doesn't need to know anything about where the data came from or how you are buffering it.
Edit
In response to your comment question, if you have one connection that you are trying to reuse for multiple requests, you would create a thread that reads from it over and over. When it finds data, it uses the event to push it out for the main part of your program to handle. I don't have a sample handy, but you should be able to find several with a few bing or google searches.