这就是我20年前通过TCP做的方式：每个请求消息都有一个唯一的请求ID，服务器会将其回显，客户端用它来匹配待处理的请求。有一个周期性定时器，检查请求是否等待时间超过超时时间，并将错误传递到应用层。我们甚至在每条消息中都使用了一个递增的序列号，以便在重新连接后恢复消息流。这一切都是用C++实现的，实现起来不需要大量的代码。我当时25岁。作者和类似的网络开发者认为复杂、笨拙或困难的东西让我感到惊讶。最好的情况是，我们已经将编程民主化到不再仅限于那些具有高度算法/状态思维的人。这会是件好事。最坏的情况是，软件工程专业在严谨性方面失去了一些东西。
源讨论你可能不需要WebSockets原帖 266 条评论 · 导入时统计这是文章中的一个次要观点，但向服务器发送一个RequestID以获得请求/响应周期并不少见，也不过分。 在严肃的应用程序中，拥有像`send(message).then(res => ...)`这样的API基本上总是值得的。 但我同意。升级请求有点令人困惑，而且你的WebSocket服务器是你HTTP服务器内部的一个嵌入式东西，无法干净地集成，这很烦人。 比如，而不是直接使用你用来从WebSocket请求中读取headers['authorization']的中间件，你却要访问这个奇怪的`connectionParams`对象，好像它们是请求头一样，呵呵。 但这些特点并不太成问题（好吧，我只是已经习惯了它们）。而且WebSocket浏览器API比比如EventSource更容易使用。
完整原文把你的经验，加入这段讨论。
每种网络浏览器都已经内置了匹配请求和响应的系统，并检查请求是否等待太久。没有必要重新发明轮子。 软件工程专业真正的问题是我们太容易被无意义的架构设计分散注意力，而忽略了实际的业务问题。最坏的情况是，因为大多数业务问题本身很无聊，所以导致人们去追求这些架构设计，或者恶意地增加可计费工时。
完整原文我开始越来越意识到这一点。那些犯着最基本错误的应用程序。一些新的框架试图修复之前三个框架已经修复过的问题。用户体验设计毫无意义，或者出现以前已经解决的错误。从小公司（这可以理解）到数十亿美元的公司（你们应该更清楚），我觉得严谨性确实缺失了。
完整原文保证端点的算法安全性，例如正确实现身份验证，与预见到所有往往与开发人员代码无关的安全问题之间存在巨大差异。前者是可能的，后者则不可能。我理解作者不想处理WebSocket升级过程——如果那里没有零日漏洞，我会感到惊讶。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。