最新 | 最热门 | 最高评价
---

+0  用 Mikrotik Simple Queue 救 bufferbloat

Tag: networking
Difan Zhang 发于 2017年03月03日 17:38 | 点击: 1707 | 展开摘要
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 | 点击: 1974 | 展开摘要
虽然不是网络出身，但是对于我们全网架构的「生长」过程还是比较了解的，分几个重要的时间点讲讲里面有意思的事情。

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 | 点击: 1918 | 展开摘要
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 | 点击: 2574 | 展开摘要
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 | 点击: 2286 | 展开摘要
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 | 点击: 3198 | 展开摘要
今天我意外的发现我打不开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 | 点击: 2076 | 展开摘要
网上有很多过时的教程，教你怎么通过命令行的—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 | 点击: 2249 | 展开摘要
今天我在对照着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 | 点击: 1570 | 展开摘要
今天发现一个很令我惊讶的事情，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 | 点击: 1608 | 展开摘要
在京东上买了一个笔记本电源，插上之后外接显示器狂闪。无论是在公司还是在家都是如此，换显示器也没用。想退货时发现，得先绑定手机号，然后设置一个新的交易密码，京东才会考虑给我退货。

今天把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 | 点击: 2831 | 展开摘要
首先，一个令人鼓舞的消息是，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

+1  Tcp Fast Open and Linux 3.7

Tag: Networking
snnn 发于 2012年12月12日 18:41 | 点击: 11370 | 展开摘要
今天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条记录