根据CoAP RFC，NSTART是对未完成交互数量的限制。但它将一个出色的交互描述为：
尚未接收到ACK的CON仍然期望(消息层(或请求尚未接收到响应或确认消息，但仍然预期(可能两者同时发生，算作一次出色的交互作用(
这似乎意味着，如果已经接收到针对CON请求的空ACK，但尚未接收到匹配的响应，则可以在不违反NSTART=1的情况下发送新的CON请求(当然带有不同的令牌(。这种解释正确吗？
在我的记忆中，几年前我们就曾就此进行过这样的讨论。首先，如果你真的想要一个合格的答案，请尝试核心邮件列表或在更正和澄清中创建问题
对我来说，NSTART-1主要在拥堵控制中发挥作用。因此，第一个问题是，如果您的设备、服务器或网络受到了相当大的限制？如果您在约束用例中违反了NSTART-1，您将得到更多的丢弃，因此也会得到更多的重试，这将导致更低的效率。
如果NSTART-1现在坚持到"0"；"受限传输层"；或一个"；"受限应用层"；，可能会给你答案。如果是传输层，你不想让它过载。也就是说，你在航班上只有一次兑换。您不仅要等待ACK，还要等待响应，否则新的请求可能会越过响应并导致过载。但这些都只是假设。在许多情况下，网络层和应用程序层都没有受到限制，因此，您也可以从一个开放的"；请求-响应交换"；到一个打开的"；con/ack"；。最后，如果您实现和服务器，不要强制使用NSTART-1，根据我的经验，这会带来更多的麻烦。
我收到了来自IETF核心邮件列表的响应，确认NSTART不是并发ACK’d CON请求数量的限制：
如果NSTART=1，这句话是否意味着并发的CON请求(已确认，但仍需要CON响应(是可以接受的？
是。
如果收到CON请求的空ACK，是否可以在收到第一个CON响应之前发送新的CON请求请求，而不违反NSTART=1约束？
是。
其想法是，CON确实收到了ACK(以及为此所花费的延迟(表示路径不是很重建议，或已实现必要的减速(通过原始RTT以及通过重传之前的等待时间(。
服务器将独立控制其各自的拥塞响应。