最新 | 最热门 | 最高评价

+0  港股实时行情系统设计

Tag: 网络编程 | 高性能Web架构
ideawu 发于 2018年07月26日 16:24 | 点击: 964 | 展开摘要
做一下记录。

做了一个可靠传输层,优点是层次分明,缺点是当丢包时价格更新不及时。可以优化成只重传不排序,Aggregator 区分是否是最新包,不是最新包则不更新最新价。

对外提供推和拉接口,两种都有适用场景,不能只提供一种。Query Server 采用 HTTP 协议,Push Server 可以用 WebSocket 协议。

把图改成 stack 形式。

Related posts:
为什么iComet比nginx-push-stream-module更好?

查看全文: http://www.udpwork.com/item/16971.html

+0  那个本可以篇篇十万赞的头部,终于远行了

Tag: 网络随笔录
魏武挥 发于 2018年03月19日 15:23 | 点击: 858 | 展开摘要


李敖去世了。

腾讯大家刊发了一位作者的文章。大家有个很不错的习惯,会在文尾标注作者自己起的原标题。

《那个亦狂亦狷,亦侠亦盗,亦文亦武的大师,终于远行了》

我看到后和腾讯大家的编辑说,还不如改成:那个本可以篇篇十万赞的人,终于远行了。

编辑发了一个笑哭了的表情,表示以后要问我买标题。

不敢当。

其实我一向不会起标题。

 



我并没有开玩笑,李敖的确是一个非常好的自媒体人。

所以今天各类头部号,真的,要感谢这个时代,这个李敖已经基本退隐的时

查看全文: http://www.udpwork.com/item/16733.html

+0  巡航120码无法自行降速刹停那个新闻的最关键处是…还是很细思极恐啊

Tag: 网络随笔录
魏武挥 发于 2018年03月17日 20:05 | 点击: 873 | 展开摘要


周五有个新闻非常劲爆,劲爆得几乎不像是真的。

说一个人三更半夜开着奔驰上高速公路,开了个定速巡航120码,结果想切换回手动切换不回去了。这下麻烦大了去,120码啊,降不下速了。在警车一路护送下,狂飙一个小时,最后是奔驰通过某种手段把这个车给停下了。

这位业余赛车选手开车技术是牛逼,中间还过了个收费口。虽然有警察帮他事先清道,但但凡上过高速的司机就都知道,120码过那么窄的一个收费口,那是什么素质和水平。

但重点是,奔驰是通过什么手段,把这个车给弄停下了?

河南商

查看全文: http://www.udpwork.com/item/16729.html

+0  为什么用本地程序通过本地端口做第三方服务认证是不安全的

Tag: 网络与安全
云风 发于 2018年03月15日 18:02 | 点击: 812 | 展开摘要
今天有同事吐槽钉钉的 windows 客户端做第三方服务权限认证的流程,人机交互方面远没有 qq 好用。

我说,通过一个普通权限的本地程序做统一认证,其实是很容易出安全漏洞的,小心点比较好。一般来说,这个在操作系统层面支持会比较安全,就像 windows 的 UAC 。这种通常是第三方应用向服务器发一个认证请求,然后服务器下转发到本地客户端,然后客户端弹出一个确认窗口,经过用户确认以后,再经由第三方服务器下发给那个第三方客户端。

这里有个安全隐患就是,如果这个弹出窗口不是

查看全文: http://www.udpwork.com/item/16725.html

+0  AWS Load Balance: 获取真实客户端IP

Tag: 网络
Felix021 发于 2018年01月27日 01:04 | 点击: 954 | 展开摘要
AWS的http/https负载均衡挺好用的,但是有一点比较麻烦,因为是应用层协议,所以在后端的nginx(以及下面挂的php-fpm)看到的 REMOTE_ADDR是负载均衡的IP,而直连LB的IP,则是保存在了 HTTP_X_FORWARD_FOR 这个header里面。

当然,在应用里面增加一小段代码去解析这个header也不是什么难事,但是毕竟有些框架已经有一套解析的方案了,而且碰到客户端自己还用代理的时候,这个字段的value是一串IP列表(直连负载均衡的ip是最

查看全文: http://www.udpwork.com/item/16634.html

+0  如何免费的让网站启用HTTPS

Tag: Web开发 | 杂项资源 | 网络安全 | HTTP | HTTPS | SSL | Web | 安全
陈皓 发于 2017年08月26日 14:06 | 点击: 2150 | 展开摘要
今天,我把CoolShell变成https的安全访问了。我承认这件事有点晚了,因为之前的HTTP的问题也有网友告诉我,被国内的电信运营商在访问我的网站时加入了一些弹窗广告。另外,HTTP的网站在搜索引擎中的rank会更低。所以,这事早就应该干了。现在用HTTP访问CoolShell会被得到一个 301 的HTTPS的跳转。下面我分享一下启用HTTPS的过程。

我用的是 Let’s Encrypt这个免费的解决方案。Let’s Encrypt 是一个于

查看全文: http://www.udpwork.com/item/16395.html

+0  防止深度包检测的一个方法

Tag: 网络与安全
云风 发于 2017年07月24日 11:25 | 点击: 1308 | 展开摘要
虽然以现在的加密技术,主要选择的加密算法没问题,在很长一段时间都不太用担心监听通讯的人解密获得明文。但是针对特定的加密通讯协议,还是很可能找到方法找到某种模式。这个模式不能转换为明文,但可以猜测出你是否在使用特定协议。

另外,无论你怎么加密通讯,访问特定服务流量的时间特征也可能泄露你的秘密:用什么节奏通讯,每个 ip 包多大,这些都是可供匹配的特征。

我认为,大多数情况下,通讯的稳定性是大于带宽的需求的。那么,采用本文这种方法应该能去掉上面这些流量特征。

先说说流量的时

查看全文: http://www.udpwork.com/item/16353.html

+0  基于 TCP UDP 协议的实时流媒体的实时性分析

Tag: 网络编程 | RTP | VoIP
ideawu 发于 2017年06月19日 20:31 | 点击: 1182 | 展开摘要
直播,电话通话,视频聊天都是实时流媒体的范畴。无论使用 TCP 还是 UDP,都会有延时。有个过时的观点是 UDP 更实时,但我不认为是这样。

实时流媒体的延时主要有几个因素:发送方缓冲,接收方缓冲,网络延时。缓冲包括网络缓冲,录制缓和冲播放缓冲。假设发送方缓冲是 10ms,接收方缓冲都是 50ms,网络延时是 100ms,那么就有至少 160ms 的播放延时。接收方缓冲比发送方多,是为了解决所谓的 jitter,网络延时不均匀导致的播放断续。

如果使用 UDP,如果丢包

查看全文: http://www.udpwork.com/item/16311.html

+0  SIP INVITE 会话建立过程

Tag: 网络编程 | SIP | VoIP
ideawu 发于 2017年06月19日 19:05 | 点击: 972 | 展开摘要
运行于 UDP 之上的 SIP,因为 UDP 是不可靠传输的,所以 SIP 协议本身要自己实现可靠传输。对于如何可靠传输,SIP 的 RFC 文档没有要求实现独立的传输层,而是将可靠传输隐含于交互过程本身。如果像 TCP/IP 协议那样分层,特点是清晰。而将可靠传输隐含于交互,则可控程度更高,当然也更复杂。

所以,RFC 中创造了一些概念,如 Transaction 等等,对于有经验的程序员来说,这完全没必须,反而造成困扰。对于程序员,用几句简单的过程描述就可以解决。如下。

查看全文: http://www.udpwork.com/item/16309.html

+0  SIP tag 和 Call-ID 的区别

Tag: 网络编程 | SIP | VoIP
ideawu 发于 2017年06月16日 19:29 | 点击: 881 | 展开摘要
SIP 的一次通话,可以通过 From, To, Call-ID 三元组来区分。但是,为什么 From 和 To 不用固定的地址,而要在地址后面加上 tag=随机数 呢?

tag 的目的是为了解决自己给自己打电话的问题(Hairpinning)。如果你自己给自己打电话,那么你应该有两个 Session,但是,如果 From 和 To 是固定的,你就无法区别这两个 Session 哪个是 caller 哪个是 callee。发送 INVITE 时,caller 会在 From

查看全文: http://www.udpwork.com/item/16305.html

+0  SIP报文Via和Contact的区别

Tag: 网络编程 | SIP | VoIP
ideawu 发于 2017年06月16日 18:54 | 点击: 3934 | 展开摘要
Via 是网络层的信息,SIP 报文将通过网络层发往这两个地址。Contact 是业务上的地址。那么问题是,应该发往哪个?

正确的做法是,请求响应模式中的响应发往 Via。如果解析 DNS 之后能直连 Contact,那么之后的报文(无论是否是请求响应模式)发往 Contact。

请求如果经过多个代理,每个代理都增加自己的 Via,变成 Via 列表。最终节点回复响应时,带有全部 Via 列表,根据最后一个 Via 获知要发送的目的网络地址。每个代理转发响应时,把最后一个

查看全文: http://www.udpwork.com/item/16304.html

+0  从 MongoDB “赎金事件” 看安全问题

Tag: 技术新闻 | 网络安全 | Bitcoin | MongoDB | ransom | 安全
陈皓 发于 2017年01月07日 17:11 | 点击: 1435 | 展开摘要
今天上午(2017年1月7日),我的微信群中同时出现了两个MongoDB被黑掉要赎金的情况,于是在调查过程中,发现了这个事件。这个事件应该是2017年开年的第一次比较大的安全事件吧,发现国内居然没有什么报道,国内安全圈也没有什么动静(当然,他们也许知道,只是不想说吧),Anyway,让我这个非安全领域的人来帮补补位。

事件回顾

这个事情应该是从2017年1月3日进入公众视野的,是由安全圈的大拿 Victor Gevers (网名:0xDUDE,GDI.foundation

查看全文: http://www.udpwork.com/item/16052.html
|<<<1234567>>>| 一共30页, 360条记录