sofa-mosn http 1协议upstream求响应错位问题infinfra.pdfVIP

[sofa-mosn]http1协议upstream请求响应错位问题

问题描述

当client在server响应较慢时，重复发送请求，断开连接的过程，请求被转发到同一个server时，将导致client可能收不到响应或收到前一次请求

的响应。

实际场景中，不要求client为同一个进程或发起相同的请求，可以想象某个server响应较慢，client出现超时断开的情况。

复现详情

(protocol-irrelative)mosn:http1

client=======================[downstreamupstream]=============server

可根据以程复现：

可将server设置为较长时间后响应请求

1.client发起请求，并在server返回响应前断开连接；

2.client再次发起请求；//此请求将在默认超时后收到GatewayTimeout的错误响应；

3.待2中请求超时后再次发起请求；//此请求将收到2中请求的响应。

以上为一种复现流程，请求2等待超时或不等待可复现出不同的效果，但本质相同。

先说结论

mosn使用连接池upstreamconnection，connection上的一次完整的请求响应会话过程抽象为stream。

以上现象主要由两部分因素导致：

1.mosn在client连接断开后将downstream绑定的upstreamclient放回连接池中，该连接可被后续请求直接使用；

2.mosn的http1的upstreamconnection只当前认为活跃的即最近发生stream，并没有未完成请求的stream。

当请求的响应到达时，可能会被误当作当前stream的响应并处理。

当upstream使用其他协议如http2,sofarpc等时不会出现以上现象，这些协议的连接池直接复用的同接，在于这些协议中有关于stream标

识（stream.id）的描述，mosn在这些协议的实现中了stream.id到stream的映射，请求的响应到达后将交由正确的upstream处理，此时若发

现downstream已经关闭，将直接丢弃该响应。

详细分析

以下涉及代码均基于版本874bf8e3。

当downstream连接断开后，若upstreamRequest未完成，mosn会对upstreamRequestreset/destroystream操作，这其中就包括将持有的client连

接放回连接池的操作。

pkg//downstream.go#L186

ifs.upstreamRequest!=nil!s.upstreamProcessDone!s.oneway{

log..Errorf(s.context,[][downstream]upstreamRequest.resetStream,Id:%d,s.ID)

s.upstreamProcessDone=true

s.upstreamRequest.resetStream()

}

pkg/stream/http/connpool.go#L183

if!client.closed{

p.availableClients=append(p.availableClients,client)

}

关于connectionstream的，http2的实现中clientStreamConnection.streams了stream.id到stream的映射，而http1的实现中则只

了一个当前stream。

pkg/stream/http2/stream.go#L489

typeclientStreamConnectionstruct{

streamConnection

mutexsync.RWMutex

streams