套接字操作是否在系统级别并行执行？
如果我有一台四核机器和 4 个打开且活动的套接字，那么使用 4 个线程并行从这些套接字读取数据更快，还是只使用一个线程迭代读取套接字更快？套接字读取操作可以并行执行还是在系统级别的某个位置同步？
类似地，如果我需要向 4 个套接字写入一些数据，那么使用 4 个线程同时写入这些套接字会更快，还是使用一个线程完成所有写入操作会更好？
似乎多个核心应该能够实现更高的吞吐量（当然，如果网络带宽不是瓶颈），但是我想知道是否是这种情况，因为毕竟，最终只有一根以太网线（或其他介质） ，所以在某些时候，所有这些写入都必须同步，并且数据包将按顺序发送...
具体来说，如果我有一台机器运行 n 个线程，这些线程生成需要发送到另一台机器的请求是不是更好打开n个套接字并让每个线程写入它？或者同步所有线程并通过单个套接字发送所有数据是否更好？ 在接收端，使用单个套接字进行读取是否更好？或者让 n 个套接字并行读取更好？如果所有读者都需要在阅读后同步怎么办？
If I have a quad core machine and 4 open and active sockets is it faster to have 4 threads to read from these sockets in parallel or just have one thread that reads the sockets iteratively? Can the socket read operation be performed in parallel or is it synchronized somewhere at the system level?
Analogously, if I have 4 sockets to which I need to write some data, is it faster to have 4 threads that write to these sockets at the same time, or is it better to have one thread that does all the writing?
It seems that multiple cores should enable higher throughput (of course if the network bandwidth is not the bottleneck), however I wonder if this is the case, since after all, in the end there is only a single ethernet cord (or other medium), so at some time, all these writes will have to be synchronized anyway, and the packets will be sent sequentially...
Specifically, if I have a machine running n threads which generate requests that need to be sent to another machine is it better to open n sockets and let each thread write to it? Or is it better to synchronize all the threads and send all the data through a single socket?
And on the receiving side is it better to have a single socket to read from? Or is it better to have n sockets read in parallel? What if all the readers need to be synchronized after reading anyway?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
套接字操作很大程度上与应用程序异步；缓冲；而且，如果幸运的话，可以在内核内部并发：同步的唯一重要状态是每个连接。然而，决定速率的步骤实际上是网络的带宽，即使只有一个线程，您也可以轻松地使其饱和。 Web 浏览器通常为每个网页打开 4 到 8 个线程来获取 HTML 本身和图像等。
Socket operations are largely asynchronous to the application; buffered; and, if you're lucky, concurrent inside the kernel: the only significant state to synchronize on is per-connection. However the rate-determining step is really the bandwidth of the network, which you can easily saturate with even just one thread. Web browsers typically open between 4 and 8 threads per Web page to fetch the HTML itself and the images etc.