498 右上角似乎有个星号，那个星号对应了什么备注信息？

@zhjits #17
哇，非常感谢，关掉 RemoteFX 之后确实流畅了非常多，本条回帖来自 RDP 中的 Win10

@zhjits #17 这样的嘛？我本来是想开着玩儿玩儿的，我关掉试一下

借楼问个问题，自己在家里内网使用 Microsoft Remote Desktop，从黑苹果台式机上连接两台 Windows 主机。

使用中遇到了奇怪的问题，同样是 4K 分辨率的 RDP 连接，
NAS 自身打底的 Server 2016 操作非常顺滑，
NAS 上 hyper-v 内的 Win10 就延迟贼高，这是什么鬼。

视频链接：
http://img.by24.cn/temp/rdp_problem.mp4
（视频会在 1 月 1 日 后删除）

NAS 是双网卡的，hyper-v 里的 Win10 走的是独立的一张网卡。
内网是千兆有线连接，检查过两台机器的 ping 值，都在 1ms 以内。

hyper-v 上有开启 remoteFX，不知道是否有关联。

https://ws2.sinaimg.cn/large/760b39b3gy1fyizv92mfgj210a0u0wpl.jpg

@jiezhi #5
百度以前有个 APIStore，支持个人发布，现在好像被优化掉了。

本地丢文件夹等客户端慢慢传就完了……

我百来 G 的照片备份，一晚上就传完了

https://ws2.sinaimg.cn/large/760b39b3gy1fyi09jtrw3j206s0bzglx.jpg

like this ？
https://www.juhe.cn/docs

@lhx2008 #18
哈哈哈哈，所以我还是推荐直接在负载均衡端解决，业务性能损耗小，实现简单。
追求完美实现的话，实在是太折腾了~


@also24 #8
勘误一下：“另外就是 flask 只对 session 做了签名，没做校验”
应修改为：“另外就是 flask 只对 session 做了签名校验，没做加密”

@lhx2008 #16
但是如果用共享 session 的方式，session 方面的压力其实也还是压在了一个单点。

另外在 AWS 的 ELB 文档中有关于单点失效情况下的策略的描述：
如果实例失败或者实例运行状况不佳，负载均衡器会停止将请求路由到该实例，并根据现有负载均衡算法来选择新的运行状况良好的实例。此时会将请求路由到新实例，就像没有 Cookie 一样，会话不再具有粘性。

@s609926202 #10
看了下 ELB 关于粘性会话的描述，是没问题的，而且是基于 cookies 实现的，比基于 ip 识别的 ip_hash 方案效果会更好。

https://docs.aws.amazon.com/zh_cn/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

OK，背景普及完毕，楼主的问题是怎么出现的呢？
很简单，session-id 是 A 服务器生成的，你去 B 服务器查，当然查不到相应的 session-data 啦。

那么问题怎么解决呢？简单提两个方法：
（推荐） 1、让从 A 服务器拿 session-id 的用户，永远只访问 A 服务器，可以通过负载均衡服务器的配置实现（例如 nginx 的 ip_hash ）

（治本） 2、让 B 服务器能从 A 服务器拿到 session-data，这就是其它 V 友说到的 session 同步。

这就体现出了很多人混淆 session / session-data / session-id / cookies 的情况了。


不少人因为 cookies 里存储了一个叫做 session 的变量，就粗暴的认为这是 session 的本体了。

我倾向于把东西划分为 session 和 session-data 来解释：
session 是个虚拟概念，代表了一个虚拟的会话过程
session-data 是个实体概念，代表这个会话中的独享数据（例如登录状态、用户信息等）

在大部分实现中（ flask 除外），cookies 里存储的只是 session-id，只是一个索引 id 而已，就一串字符 id 而已。
真正的 session-data，其实是存储在服务端程序中的，服务端程序，根据 session-id，取出了 session-data 参与运算渲染。
于是在外界看来，就好像这个 session 是通过 cookies 里的 session-id 来维持的一样。

https://ws2.sinaimg.cn/large/760b39b3gy1fyhtr5gmuqj209105u74e.jpg


这就造成了许多人 “ session 是存储在 cookies 中” 的误解。
同时也造成了，在讨论 session 的时候，很多人混淆 session 会话 / session-data / session-id 的情况。


当然，刚才被我排除掉的 flask，人家是真的把 session-data 存储在 cookies 中的（即 “客户端 session ”），所以在使用 flask 的时候，要处理好 secret_key 的安全性，否则容易出现 伪造 session 的问题，另外就是 flask 只对 session 做了签名，没做校验，所以本地 session 是可以被解码查看的。当然那就是另一个话题了，不多说。

一开始以为是 “模板” 带来的后遗症，在后端模板嵌前端代码的情况下，确实有可能混淆这部分职责。
结果仔细看下来发是个前后端分离的项目……


真的从分工精细化角度来说，前端确实有可能细分为：
* 专门实现页面，写样式的前端
* 专门对接接口，写 JS 写页面逻辑的前端

但无论如何，写 JS 怎么都不应该是后端的 “职责” 的~
后端对前端页面的触及，最多也就到 “模板” 这个层级了。


至于对方所使用的理由：
如果后端自己对接，后端牛逼的话最快可能一两天就搞定，1 服务器是不用跨域的，2 自己写的代码自己可以去调配

改一下好像也没什么问题嘛：
如果前端自己写后端，前端牛逼的话最快可能一两天就搞定，1 服务器是不用跨域的，2 自己写的代码自己可以去调配