我必须从一台服务器连接到多台电脑（约1000台电脑）。这些电脑通过Wifi网络连接在同一栋楼里。
每台电脑都有一个与服务器的专用连接。从其IP地址来看，服务器知道要向他生成的特定数据。
我必须通过网络向每台电脑发送一个专用的短字符串（一个字符串约30个字符）
专用字符串以每秒30个字符串的频率发送到每个PC。
问题是，这些发送的数据至关重要，应该实时发送。
在我的情况下，哪种解决方案更快、最稳健？
我假设你有两台通过以太网或wifi连接的电脑，或者足够好的现代互联网连接（都在地球上；没有星际…；没有20世纪70年代的鸽子IP RFC1149或1200波特模拟调制解调器）。然后，每秒30个字符的30个字符串大约是每秒千字节，不是这是一件大事，当然不是高频。我目前在家（法国巴黎附近）的光纤互联网连接每秒可以下载十几兆字节，上传至少每秒一兆字节。几年前，它是ADSL，每秒下载大约1兆字节。我从来没有在家里连接过每秒一千字节的互联网。（如果你在星际空间，或者在非洲或南极洲最偏远、最荒凉的地方，那么在2016年，1字节/秒可能是一个问题，但你在互联网连接方面非常不幸）。
您的HTTP设置可能使用websocket（所以有点像您的第二个解决方案）。您可以在服务器端使用libonion（HTTP服务器库），在客户端使用libcurl（HTTP客户端库）。定期轮询（例如每秒发出20次HTTP请求）将需要更多的资源（但这仍然是可管理的）。HTTP连接会比较慢，因为HTTP会增加一些开销（HTTP请求和响应中的头）。
请注意，HTTP协议高于TCP/IP，因此肯定会在提供它们的操作系统（Linux、Windows、MacOSX…）上使用BSD套接字；web解决方案"已经在使用套接字。
如果使用套接字，则需要在其上定义一个协议（或者使用一些现有的协议，如HTTP或JSONRPC）。
我会选择插座的方法。可能是一些与JSON相关的东西，比如JSONRPC。请注意，如果您在套接字API上编码，则TCP/IP是一个没有消息边界的流协议。您需要在两侧进行缓冲，并定义一些消息边界约定。您可以发送以换行符终止的JSON（结束换行符与JSON兼容，便于对消息进行分隔）。
您可能对诸如0mq之类的消息库感兴趣。
补遗（问题版之后）
你的新问题大不相同（成千上万台电脑，而不仅仅是其中的两台；我想它们在同一栋楼里，或者至少在同一块大陆上。）。你需要大约1000*30*30，即每秒不到1兆字节的带宽。我仍然建议使用一些插座。可能0mq更相关。您可以将每条消息制作成JSON。你需要很好地记录你正在使用的协议。可能，您希望服务器有几个线程（例如十几个，而不是几千个线程）来循环发送消息（在TCP上）。也许您可能想要一台具有多个以太网连接的服务器（但每秒一兆字节可以在一个以太网上运行，即使是慢速100Mbits/sec的以太网）。
30字节，每秒30次，即每秒900字节。这一点都不快；任何一种方法都可以。请注意，HTTP连接无论如何都使用套接字。
听起来，您的"套接字"选项意味着始终保持套接字连接打开，而HTTP（通常）为每个请求打开一个单独的连接。我想你真正想问的是：
- 让客户端定期询问服务器是否有新数据，或者
- 让服务器在新数据可用时立即发送
这完全取决于您的程序的要求，我们不知道。
一千个双向TCP通信需要1000个套接字（除非您想为发送的每个字符串打开和关闭连接，但这将是一个主要的性能消耗）。
这与通常的最大打开文件描述符的软限制（1024）非常接近。这是习惯硬限制4096的25%。鉴于此，我发现TCP不太适合这里。
相反，我建议使用UDP。使用UDP，您只需要少量的套接字（即使是一个也可以，但使用多个套接字，您可以更好地扩展）。它会有可靠性问题，但您可以在UDP之上实现某种类型的它。
请熟悉OSI模型。套接字（UDP、TCP）在第4层，HTTP在第5层，因此已经使用了第4层协议