作者回复: 这个问题很好，说明你看的很细致还动手实践了。这里涉及到一些细节了： 首先连接（说白了，就是TCP的三次握手）在服务器端写完下面这句话的时候： ServerSocket serverSocket = new ServerSocket(8091);（注意这里没有accept） 就已经可以连接上去了，而不是必须有accept（）的执行，那accept是做什么的？ 相当于快递的签入。如果你不签入，这个快递还是已经到了（连接已经建立好了），但是你无法对他进行后续处理（最起码，在服务器端你拿不到对应的socket channel来执行调用，更不用谈注册读写事件）。另外一个方面，如果你不accept，那中间的缓存区会满（取决于backlog大小），那很快，就无法建立新的连接了，和快递签入一个道理。你不签入，那快递都堆那个地方，最终还是存不下。 所以总结起来就是，accept准确的说应该说是对连接的后续处理（签入），（但是经常在表述上包括本课程都是直接说处理连接，所以可能会让你误解，以为只有accept调用，连接才能建），至于连接本身（TCP）三次握手并不是accept这个方法做的事情。 你可以写一些简单的例子验证下。很简单，几行代码，抛开netty来看，其实更容易把这些问题搞清楚，如果还有别的疑惑，欢迎继续提问，我应该说清楚这个问题了，哈哈 谢谢！

作者回复: 不管哪种情况下，客户端都是可以发送多个请求，比如请求A，请求B，然后服务器端处理要保证顺序的话，肯定就像你说的使用同一个线程，那这样会导致，请求A不处理完就不能处理B，明显效率不行，所以为提高效率肯定要多线程，那处理就可能结果不是按请求AB的顺序，所以才要需要一个ID来对应下，实现类似分发的效果。不过，不管怎么说，你说的本身没有问题的，因为你也可以发多个，也可以拿到响应，只是速度不会快。

作者回复: 不适合，因为那是encoder，从encoder里获取结果？另外，你怎么来获取响应结果？所以不适合。

作者回复: 是的，不然要考虑的情况远不止这些。

作者回复: 不好意思，将就下吧，兄弟！有不明白的，可以留言。谢谢！

作者回复: future本身就代表是异步的，而get是为了获取结果，相当于异步执行但是结果获取是阻塞同步，这两个不矛盾。 改进的核心点在于：第一个请求和第二个请求可以异步并发了，原来的不行，因为如果并发，无法把结果一一对应起来。

作者回复: 但是如果他的信息传输结构定义成带关键id的，能做到的更好，就像http为什么要搞新版本一样的道理，当然原来的旧版本，现在一直在用，因为能满足需求，不够就加机器。