从 #169433 :
- 来自 @alexdima: 为了充分利用可用的带宽,我认为 IPC 层需要暴露底层的套接字排空事件、写缓冲区大小等,或者我们可能可以在 IPC 层原生支持返回一个流或 Promise,并在内部正确处理以使写入速度与 TCP/IP 套接字写入速度保持一致,同时允许其他 IPC 消息通过。
- 来自 @bpasero: 实际上一开始我们有一个模型,客户端从服务器拉取数据,但为了优化速度,我将其更改为当前模型以减少大文件通信的开销。这意味着吞吐量更高,但客户端的压力也更大。
- 来自 @connor4312: 最近在实现 Basis 的主机中继(底层使用 SSH)时,处理得非常广泛。您还可以查看类似于 SSH 在通道上执行的流量管理机制。
- SSH 通过单个连接复用多个通道。对于每个通道,每方都有一个接收窗口,其初始大小和更新到的大小都会通知另一方。发送者不得发送比它知道接收者窗口可以处理的字节数更多的字节,并且必须在发送任何更多数据到通道之前等待接收者宣布更大的窗口。
- 正确获取大小和调整可能是棘手的--例如,接收器通常希望在一定比例的使用后调整接收窗口,并需要以适当的优先级方式进行调整--但类似的事情可以实现您的目标。
- 进一步阅读:https://www.rfc-editor.org/rfc/rfc4254#section-5.2
5条答案
按热度按时间wj8zmpe11#
@alexdima, @KartikM123来自Codespaces团队提出了一个与此问题相关的问题:https://github.com/orgs/community/discussions/47531
简而言之,一个Codespaces用户发现通过VS Code浏览器UI上传和下载代码空间中的文件非常慢/操作根本无法完成,尽管他们的网络带宽非常快(包括数字)。这是相同的情况还是我们应该为该用户报告提交一个新的问题?谢谢!
sxpgvts32#
目前还不清楚https://github.com/orgs/community/discussions/47531是否对我们有影响。我们通过websocket工厂为管理连接创建了一个web socket。代码空间的web ui将这个"逻辑web socket"与其他单个真实的web socket进行多路复用,并在发送/接收数据之前对其进行加密。问题并不明显,例如,也许加密正在拖慢速度?我们可以使用在局域网上设置的普通vscode服务器,并从另一台机器连接到它,以测试我们这边是否有缺陷。
e0uiprwp3#
关于:https://github.com/orgs/community/discussions/47531
@bpasero 上传和下载是如何实现的?如果它是通过发送非常大的的数据块来实现的,那么它有可能受益于 https://github.com/microsoft/vscode/pull/174278/files,在那里我们将WebSocket消息限制为最多256KB。
6ie5vjzr4#
我看到自从Codespaces开始以来,上传/下载速度一直很慢。我认为这是因为我们不是直接与服务器进行上传,而是通过远程代理连接和文件服务发送数据块。代码在这里:
vscode/src/vs/workbench/contrib/files/browser/fileImportExport.ts
第243行到第252行
| | // Chrome/Edge/Firefox支持流方法,但仅将其用于较大的文件以减少流式方法的开销 |
| | if(typeoffile.stream==='function'&&file.size>ByteSize.MB){ |
| | awaitthis.doUploadFileBuffered(resource,file,reportProgress,token); |
| | } |
| | |
| | // 对于其他浏览器或小文件,回退到未缓冲的上传 |
| | else{ |
| | awaitthis.doUploadFileUnbuffered(resource,file,reportProgress); |
| | } |
我们从Chrome获取数据块:
vscode/src/vs/workbench/contrib/files/browser/fileImportExport.ts
第324行 in 720985f
| | letres=awaitreader.read(); |
很高兴测试是否现在有所改善。
yiytaume5#