V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  also24  ›  全部回复第 218 页 / 共 286 页
回复总数  5701
1 ... 214  215  216  217  218  219  220  221  222  223 ... 286  
2018-12-25 14:58:19 +08:00
回复了 mseasons 创建的主题 macOS Mac 下如何优雅的控制 Windows
借楼问个问题,自己在家里内网使用 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
2018-12-24 18:29:07 +08:00
回复了 jiezhi 创建的主题 奇思妙想 [idea] 共享接口平台
@jiezhi #5
百度以前有个 APIStore,支持个人发布,现在好像被优化掉了。
2018-12-24 18:21:21 +08:00
回复了 WDD 创建的主题 问与答 60 多 G 的文件上传到 onedrive 怎么最稳?
本地丢文件夹等客户端慢慢传就完了……

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

https://ws2.sinaimg.cn/large/760b39b3gy1fyi09jtrw3j206s0bzglx.jpg
2018-12-24 18:19:54 +08:00
回复了 jiezhi 创建的主题 奇思妙想 [idea] 共享接口平台
@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 是可以被解码查看的。当然那就是另一个话题了,不多说。
2018-12-23 17:24:57 +08:00
回复了 orangeface 创建的主题 前端开发 有没有大神来科普一下前后端职责
一开始以为是 “模板” 带来的后遗症,在后端模板嵌前端代码的情况下,确实有可能混淆这部分职责。
结果仔细看下来发是个前后端分离的项目……


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

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


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

改一下好像也没什么问题嘛:
如果前端自己写后端,前端牛逼的话最快可能一两天就搞定,1 服务器是不用跨域的,2 自己写的代码自己可以去调配
2018-12-23 16:05:12 +08:00
回复了 zxcvsh 创建的主题 生活 爷爷奶奶是否算直系亲属
@zxcvsh #18
哈哈哈,主要是因为我帐号之前处于降权状态,回复不会触发提醒。

其实我上面扯了那么一大堆,就三个核心意思:
1、“婚丧假” 和 “因婚丧而请的‘事假’” 不一样,很多人当成后者了
2、“婚丧假” 的适用范围,其实是有规可循的,但具体实施可能还要看情况
3、“直系亲属” 到底包括谁,其实没有明确定义
2018-12-23 16:03:06 +08:00
回复了 hao2345 创建的主题 程序员 想实现直接在网站源代码文件夹里搜索某个内容
2018-12-21 16:01:41 +08:00
回复了 caviar 创建的主题 Apple Macbook Air 有什么可用的免驱 usb 网卡吗?
https://ws3.sinaimg.cn/bmiddle/62e721e4gw1et02ek7u61j200k00k3y9.jpg 突然发现楼主需求的好像是无线网卡…………

我刚才回复的全部都是 USB 转 RJ45 的,都是有线网卡 =。=
2018-12-21 15:37:37 +08:00
回复了 caviar 创建的主题 Apple Macbook Air 有什么可用的免驱 usb 网卡吗?
认芯片买就好了,手头正好有一份之前供应商发过来的表,可以参考里面的芯片描述进行购买。
比较常见的应该还有个 AX88760,实际上是 88772A + HUB

https://ws2.sinaimg.cn/large/760b39b3gy1fyeelmzc0gj212o0sq7cx.jpg
1 ... 214  215  216  217  218  219  220  221  222  223 ... 286  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2855 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 102ms · UTC 03:48 · PVG 11:48 · LAX 19:48 · JFK 22:48
Developed with CodeLauncher
♥ Do have faith in what you're doing.