最新 | 最热门 | 最高评价

+0  用 Mikrotik Simple Queue 救 bufferbloat

Tag: networking
Difan Zhang 发于 2017年03月03日 17:38 | 点击: 1776 | 展开摘要
Bufferbloat 问题依然是一个比较严重的影响网络性能的问题。在 QoS 是个事情之前,如果你和我一样是 Time Warner Cable 的受害者 (或者比我更差,是 Comcast 的受害者,或是几乎任何 Cable network 的受害者),你很可能被 bufferbloat 所困扰。

Bufferbloat 的表现形式很简单 —— 带宽饱和时,行为不是丢包以整流,而是观察到了更高的延迟。这的本意是好的 —— 基于共享的基础设施,网络设备希望尽可能的减少丢包

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

+0  一张复杂网络的生长过程

Tag: *nix | infrastucture | networking
jaseywang 发于 2017年02月27日 22:30 | 点击: 2062 | 展开摘要
虽然不是网络出身,但是对于我们全网架构的「生长」过程还是比较了解的,分几个重要的时间点讲讲里面有意思的事情。

15 年下旬

公司业务还没起飞,全网架构简单,应付一天 1k+ 的订单了(有效挂号单)绰绰有余,机房跟第三方的卡管机构通过一根 10M 的 SDH 专线打通,所有到院方的请求先经过第三方的卡管机构,由其转发再进行业务层面的处理,实际的带宽峰值不到 500kbps。

16 年初

正式开始批量接入三甲医院,同时跟医院数据打通的方式也由原先的经过第三方卡管机

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

+0  Router Matters

Tag: *nix | networking | tcp
jaseywang 发于 2015年07月05日 21:05 | 点击: 1977 | 展开摘要
We are transfering PBs of our HDFS data from one data center to another via a router, we never thought the performance of a router will becomes the bottleneck until we find the below statistic:

#show interfaces Gi0/1

GigabitEthernet0/1

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

+0  How We Migrate PBs Data from Beijing to Shanghai

Tag: *nix | infrastucture | mongodb | monitoring | mysql | networking | operations | redis
jaseywang 发于 2015年05月13日 00:22 | 点击: 2647 | 展开摘要
We spent more than 6 months migrating our PBs data located in Beijing to Shanghai.

This slide gives you a brief introduction about how we do it.



How We Migrate PBs Data from Beijing to Shanghai from Jasey Wang

Related Posts:
Migrati

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

+0  通过 tcpcopy(pf_ring) 对 BCM 5719 小包做的多组 benchmark

Tag: *nix | benchmark | kernel | networking | nic | tcp
jaseywang 发于 2015年02月28日 17:19 | 点击: 2372 | 展开摘要
tcpcopy 在文档化、用户参与方式方面有很大的提升空间这个问题在之前已经专门说过。最终,在我们自己阅读代码的情况下,结合 pf_ring,坚持跑通了整个流程,用其对目前 BCM 5719 型号的网卡做了多组对比,结论见结尾。

使用 tcpcopy 做 benchmark,务必确定 tcpcopy 语法使用的正确性, 尽管互联网上绝大多数的文档以及官方文档都写的含糊不清。

比如,我们之前把过滤条件 -F "tcp and dst port 80"

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

+0  奇怪的8.8.8.8,难道又是中国特色?

Tag: networking
sunchangming 发于 2013年05月04日 00:38 | 点击: 3250 | 展开摘要
今天我意外的发现我打不开www.soku.com,原因是域名解析失败。

那么,一步步排查吧。我系统当前默认的dns server是8.8.8.8 和211.151.146.5

# nslookup www.soku.com
;; Got SERVFAIL reply from 8.8.8.8, trying next server
Server:         216.218.223.67
Address:        216.218.223.67#53

Non-a

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

+0  不要再使用Chrome浏览器的--enable-npn选项了

Tag: networking | spdy
sunchangming 发于 2013年05月01日 16:09 | 点击: 2142 | 展开摘要
网上有很多过时的教程,教你怎么通过命令行的—enable-npn选项打开chrome的spdy协议功能。但是那些教程真的out of date了。其实什么都不用加,新版本的chrome浏览器已经自动打开spdy了。

目前chrome浏览器(version 26)主要有这么几个spdy相关的开关:

—enable-spdy4a1: 打开SPDY/4 alpha 1的支持,这只是一个临时性的测试开关。

—enable-npn: 通过NPN

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

+0  The Http URI 解析

Tag: networking | HTTP
sunchangming 发于 2013年04月24日 21:30 | 点击: 2305 | 展开摘要
今天我在对照着rfc3986看java.net.URI的实现。URL无处不在,摆在我们面前的一个核心问题就是,如何解析它。

URI的全称是Uniform Resource Identifiers。URL的全称是Uniform Resource Locator,它是URI的子集。意思是说,我们是通过资源的primary access mechanism的一种表示方式来标识这个资源,而不是通过名字、或其它属性的方式标识。

Http request的第一行中,method后面是

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

+0  2013-01-18

Tag: Networking
sunchangming 发于 2013年01月18日 23:49 | 点击: 1629 | 展开摘要
今天发现一个很令我惊讶的事情,C++标准库里面的排序算法std::sort竟然要比C语言的qsort明显快很多。
1亿个int类型的整数在内存中排序.
 
c语言的qsort: 25秒
C++标准库的sort: 14秒
我自己用C++写的quick sort: 19秒
快速排序是一个很典型的分治算法。我总是想着如何不用递归的方式实现它。但是看了一下Freebsd的libc以及gcc的libstdc++,发现大家都是用递归完成的。可见递

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

+0  2013-01-16

Tag: Networking
sunchangming 发于 2013年01月16日 23:34 | 点击: 1662 | 展开摘要
在京东上买了一个笔记本电源,插上之后外接显示器狂闪。无论是在公司还是在家都是如此,换显示器也没用。想退货时发现,得先绑定手机号,然后设置一个新的交易密码,京东才会考虑给我退货。

今天把shrpx的代码check下来改了改。https://github.com/snnn/spdyproxy 这是一个SPDY的proxy server。和我上次发的nodejs的版本相比,这个是纯C/C++的,占用内存只有3-4MB。而nodejs则要40-70MB。我刚改了改给它加上HTTP

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

+0  新年第一文,献给RTMFP协议

Tag: Networking
snnn 发于 2013年01月05日 17:07 | 点击: 2877 | 展开摘要
首先,一个令人鼓舞的消息是,RTMFP的标准在上个月已经由Adobe公司作为RFC草稿提交给了IETF。http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp 。

RTMFP是一个极为复杂的P2P协议。你可以看成是 TCP+SSL+CORBA的合体。单单是用UDP重新实现一遍TCP的握手和流控,就复杂的足以让人想撞墙。

我刚把这份RFC草稿01版的全文看完。令人遗憾的是,很多细节并未公开。比如证书的格式,如何协商密钥

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

+1  Tcp Fast Open and Linux 3.7

Tag: Networking
snnn 发于 2012年12月12日 18:41 | 点击: 11437 | 展开摘要
今天Linux 3.7发布了,一个引人注目的特性是,包含了完整的对TCP Fast Open(TFO)的支持,client端以及server端。

传统的TCP需要经过3次握手才能建立。假设我们要从服务器上用http协议下载一个图片

C->S : SYN

S->C : SYN+ACK

C->S : ACK+ http get request

S->S : http response

所以一个最简单的HTTP请求也需要2个round-trip

查看全文: http://www.udpwork.com/item/8845.html
|<<<12>>>| 一共2页, 24条记录