这是一个创建于 1550 天前的主题，其中的信息可能已经有所发展或是发生改变。
希望类似于 http 协议的 rpc 一样，在长链接通讯里，针对 S1 端的每个 request 、S2 端都会有一个是否接受到合法请求的回复，不知道在长链接里 S1 要怎么分辨 S2 的回复是针对哪个 request 的呢？
如果每次 request 都带一个随机 token，那 S1 发完 request 后，岂不是还要保存 token 和这条 request 的对应？ 可以做到 http 那样的 request-response 一一对应吗？
不知道在 netty 里是如何方便实现的。。。 这算是全双工的概念吗
如果每次 request 都带一个随机 token，那 S1 发完 request 后，岂不是还要保存 token 和这条 request 的对应？ 可以做到 http 那样的 request-response 一一对应吗？
不知道在 netty 里是如何方便实现的。。。 这算是全双工的概念吗
 |
1
treblex 2020-08-31 00:31:35 +08:00
长链接是保持的，不是直接 write 和 read 就行吗
|
 |
2
abelking OP @suke971219 就是说我发送了一条消息 A，然后别人也会返回一个消息 B，我怎么知道 B 是针对 A 的返回呢？
|
 |
3
opengps 2020-08-31 01:47:28 +08:00
我说下 tcp 长连接，可以参考打电话的场景：
A 拨通 B，然后 A 可以随便说，B 也可以随便回。 但是如果需要问答对应，那么则需要设计一个通信标识，用来作为 B 的 0001 回答 A 的 0001 问题（来回传递，用完作废） 并不是所有对话都是问答（ http 短链接几乎都是一问一答的设计），比如 A 让 B 更新下数据，B 让 A 更新下数据（各自收到命令尽管去做，无需应答） |
 |
4
jiangzm 2020-08-31 02:41:06 +08:00
http 1.1 就可以复用 tcp 链接做到 http 持久链接，但是消息对(request-response) 是串行的，完成了一次 http 响应才发起下一次请求。服务端要独立处理每一次 request，凭证要包含在每一次请求当中。
而真正的 tcp 长链接是可以通过鉴权信任链接对象(socket)，经过三次握手链接成功后，客户端就可以发送凭证信息服务端验证后就可以把当前 socket 标记为受信任的，后面两端再通信的内容就无需鉴权。 另外你说的 消息对 是可以自己设计在 tcp 报文格式里面。比如在报文头放一个消息 ID 和回复消息 ID 字节区域，这样就很容易找到消息对了。 |
 |
5
nuk 2020-08-31 02:55:52 +08:00
HTTP pipelining 很久以前就有啊
给他们一个序列号，按顺序来就行了 |
 |
6
xuanbg 2020-08-31 08:17:32 +08:00  1
长 /短连接指的是 TCP 的链接，http 是在 TCP 链接之上的一个传输协议，这两个链接不是一回事。
你可以把 TCP 链接看做机场的行李传送带，http 链接就是传送带上的行李箱。所谓长连接就是用同一条传送带传送不同的行李箱，短连接就是每传送一个行李箱都换一条传送带。 |
 |
7
micean 2020-08-31 08:38:19 +08:00
#3 +1
按原来的套接字开发，每个 request 收到回复前是不发送新的 request，这样重发、回复处理的业务逻辑会好做一些 |
 |
8
MrTreasure 2020-08-31 11:07:09 +08:00 1
差点以为自己学错了
长连接是指 TCP 连接的复用，http 1.1 提出来的，通过请求头 Connection: keep-alive 控制 接收方是记住了发送方的 域名+端口，所以一次三次握手以后后面都可以继续通信了 |
 |
9
ZSeptember 2020-08-31 11:59:16 +08:00
TCP 是有序的流，写入的时候加锁，需要并发的话，需要在应用层协议实现，用 requestid 之类的关联。
|
 |
10
newmlp 2020-09-02 10:56:19 +08:00
http 现在并不“短”，主要还是有协议负载
|
Select Language