...但是提供套接字 API 以允许与现有协议进行交互有什么问题？

这不是语言本身的限制，而是它在浏览器的沙箱内使用。试想一下，互联网上某处的脚本被加载到浏览器中，并且可以从浏览器内部使用任意协议访问浏览器可访问的每台计算机。您可以很容易地滥用它通过公司内部邮件服务器发送垃圾邮件或攻击/滥用其他内部和外部资源。

这意味着必须有一些限制，并且不同语言运行时的不同沙箱环境提供不同类型的限制：

• 使用闪存，目标主机必须通过提供适当的套接字策略文件来明确允许访问。这类似于HTML5 CORS中的机制。
• 不受信任的 Java 小程序仅限于与提供小程序的主机通信。
• 使用浏览器中的 JavaScript，您几乎可以与所有站点通信，但您会受到可以使用的协议的限制，即 HTTP（受 CORS 限制）和 WebSockets。

我不确定 Flash 对象提供什么套接字 API 访问，但是有很好的理由不允许 JavaScript 中的纯 TCP 或 UDP（更不用说任何其他类型的）套接字。

最大的一个可能是，如果您这样做，您基本上提供了一种绕过防火墙的方法。您机器上侦听环回网络套接字的每个服务（通常外部攻击者无法访问）现在都可以从浏览器中受到攻击。您网络上的每台机器，通常通过网关和防火墙与 Internet 隔离，现在都可以被 Internet 代码访问或攻击。

还有其他原因。当浏览器可以在没有插件的情况下进行端口扫描和 DDOS 攻击时，它们会变得更加容易（是的，浏览器可以尝试在 HTTP(S) 服务器上启动 DDOS，但使用较低级别的套接字可能会更有效）。当在流行网站上查看广告的每个人都开始发送攻击时，网络蠕虫（尤其是只有一小部分机器容易受到攻击的那些）可以更快地传播，而不仅仅是那些实际被感染的人。

Websockets 的存在是为了提供一种与明确希望与运行不受信任代码的浏览器通信的事物进行套接字通信的方法。典型的 Internet 服务器也经过了类似的加固，期待各种类型的恶意客户端。问题来自不期望恶意流量的服务，因为它们只能由受信任的客户端访问。JS 控制的套接字将完全打破这一点。

与典型 TCP 套接字等效的浏览器是 WebSockets API规范。

如果您想要 JavaScript 中的套接字，请查看node.js中的套接字API