mosn

mosn copied to clipboard

MOSN 作为sidecar时，网格外应用TLS连接网格内应用失败

4

场景为： 先启动了一个以mosn作为边车的 https server ```yaml apiVersion: v1 kind: Service metadata: name: go-ssl spec: ports: - port: 443 targetPort: 443 name: gossl nodePort: 443 appProtocol: HTTPS selector: app: go-ssl --- apiVersion:...

misinibaba

opt: decrease healthcheck goroutine

12

### Issues associated with this PR #2336 初始化协程池的逻辑还没来得及写，等有空了再补充 ### Solutions You should show your solutions about the issues in your PR, including the overall solutions, details and the changes. At...

alpha-baby

disable pre parse multipartform

1

### Issues associated with this PR #2356 Your PR should present related issues you want to solve. ### Solutions You should show your solutions about the issues in your PR,...

fibbery

https://github.com/mosn/mosn/blob/9409ffa46969e2389f0debb9b442feb865c8ec08/pkg/stream/http/stream.go#L512 这里解析Http请求直接使用的fasthttp的ReadLimitBody方式，但是这存在一个问题，它这里默认提前对MultipartForm类型进行了body解析，如图：  这里稍微解析出错，可能会导致body解析的内容缺少，然后导致转发的时候缺少body内容。 这里默认情况，作为网关，是不是不应该对body内容进行解析，只做转发即可，用户需要解析form这类的情况，自己再另行处理。 这里更多考虑的是兼容性问题 举例： 目前MultipartForm格式标准如下： ``` POST /upload HTTP/1.1 Host: example.com Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; name="file"; filename="example.txt" Content-Type: text/plain This is an example file. ------WebKitFormBoundary7MA4YWxkTrZu0gW...

fibbery

您好，请问多路复用的映射关系在哪里记录的呢？

2

### Your question 您好，请问多路复用的映射关系在哪里记录的呢？ ### Environment - MOSN Version ### Logs - Paste the logs you see.

zzqCh

xprotocol协议代理出现了serverCallbacks为空的panic问题

35

### Your question MOSN的config文件如下： ```json { "disable_upgrade": true, "servers":[ { "default_log_path":"stdout", "default_log_level": "TRACE", "routers":[ { "router_config_name":"server_router", "virtual_hosts":[{ "name":"serverHost", "domains": ["*"], "routers": [ { "route":{"cluster_name":"serverCluster"} } ] }] } ], "listeners":...

zzqCh

MOE压测性能上不去

6

我这边想通过压测看下moe的性能提升，现在发现性能上不去，请问可能是什么原因呢？ 压测场景如下：把moe作为入流量sidecar代理，测试链路为：压测平台->iptables入流量劫持->moe->java后端服务，压测使用6个并发，moe和后端服务的容器配置都为4C8G，moe使用的镜像是示例里用到的mosnio/envoy-go-extension:latest。在配置文件几乎都相同的情况下，我用官方的envoy镜像能压到1.1w的qps，平均耗时0.45ms；但用moe只能压到2900的qps，平均耗时1.92ms。性能差异有点大，请问是不是我的压测姿势不太对？ **moe的配置文件如下：** ``` node: id: mosn cluster: mosn bootstrap_extensions: - name: envoy.bootstrap.dso typed_config: "@type": type.googleapis.com/envoy.extensions.dso.v3.dso so_id: mosn so_path: "/usr/local/envoy-go-extension/libmosn.so" static_resources: listeners: - name: virtualInbound use_original_dst: true address: socket_address: address:...

huanglu20124

Mosn的metrics有grafana的展示模板么？

1

### Your question Mosn的metrics有grafana的展示模板么？ ### Environment - MOSN Version 1.5 ### Logs - Paste the logs you see.

zzqCh

关于mosn代理websocket、keepalive机制、重试的问题

7

### Your question 您好，有以下几个问题： 1.mosn支持代理websocket的么？如果支持，是否支持多路复用的呢？ 2.mosn的keepalive机制是否可看出服务端的健康状态？有接口提供的么？目前看到/api/v1/stats中无健康状态 3.mosn在选取上游服务的时候是否支持重试机制？或者说访问出错后，是否支持重试机制？ ### Environment - MOSN Version. 1.5

zzqCh

downstream reset, response code应该是为4xx, 才符合规范点

2

https://github.com/mosn/mosn/blob/07be2d0d6b9cee511262f85132277fcf937be23b/pkg/proxy/downstream.go#L363

fibbery