最新 | 最热门 | 最高评价

+0  SYN和RTO

Tag: Technical | TCP
老王 发于 2017年08月13日 15:21 | 点击: 785 | 展开摘要
前两天,我在微博上推荐了一篇朝花夕拾的文章:The story of one latency spike,文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题,细细读来受益良多,不过我并不打算详细介绍那篇文章的细枝末节, 本文只摘录一个点:

When debugging network problems the delays of 1s, 30s are very characteristic. They may indicate packet

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

+0  全网统一账户实践

Tag: *nix | freeIPA | infrastucture | LDAP | tcp | vpn
jaseywang 发于 2017年03月04日 14:44 | 点击: 902 | 展开摘要
分享下目前我们全网的账号管理体系。

整体的账户管理思路是分而治之。主要分为下面三类账户:

1. 办公网账户,也就是大家熟悉的域账户。对于办公网账户,全网用户一人一账户,在 OpenLDAP 的基础上做了一些开发,这是进入公司内部的大门,所有新入职的员工都会分配一个该账号,不管是在办公室连接 Wi-Fi 还是在家连接 anyconnect VPN,访问 confluence/jira 等基础办公设置,都需要通过此账户进行登录认证。

2. 生产网账户,主要用来访问线上

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

+0  关于FIN_WAIT2

Tag: Technical | Linux | TCP
老王 发于 2016年09月05日 22:30 | 点击: 770 | 展开摘要
前些天,有朋友问我关于 FIN_WAIT2 的问题:如果主动关闭的一方在进入 FIN_WAIT2 状态后没有收到被动关闭的一方发送的 FIN 包,那么会怎样?

让我们热热身,通过一张旧图来回忆一下 TCP 关闭连接时的情况:

TCP Close

按照正常的状态迁移路径,当 FIN_WAIT2 收到 FIN 包后会迁移到 TIME_WAIT 状态。如果没有收到 FIN 包,那么连接状态会如何迁移,我们不妨测试一下:

#!/usr/bin/env python

impo

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

+0  OpenVPN Connectivity Issue in Public Network

Tag: *nix | monitoring | networking | tcp | vpn
jaseywang 发于 2016年02月12日 21:12 | 点击: 644 | 展开摘要
We established a ovpn tunnel between 2 IDCs in September 2014, and we have monitored the availability and performance of two ends for a long time. The geographical distance between 2 IDCs are quite short, but with different telecom carries.

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

+0  一例 Timeout 故障

Tag: Qiniu | TCP
alswl 发于 2016年02月02日 23:34 | 点击: 839 | 展开摘要
早晨刚到公司, HAProxy 报警,Trtornis(第三方云存储网关,用来统一管理阿里云和七牛云的对象存储) 全飘红。

检查日志,并没有 ERROR 信息,但是大量 WARN 报错。

WARN [2015-12-09 11:01:02,730] org.eclipse.jetty.util.thread.QueuedThreadPool: dw{STARTED,8<=50<=50,i=0,q=1024} rejected org.eclipse.jett

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

+0  浅谈CLOSE_WAIT

Tag: Technical | Linux | TCP
老王 发于 2016年01月19日 20:19 | 点击: 223 | 展开摘要
TCP 有很多连接状态,每一个都够聊十块钱儿的,比如我们以前讨论过 TIME_WAIT 和 FIN_WAIT1,最近时不时听人提起 CLOSE_WAIT,感觉有必要梳理一下。

所谓 CLOSE_WAIT,借用某位大牛的话来说应该倒过来叫做 WAIT_CLOSE,也就是说「等待关闭」,如果你还不理解其含义,可以看看 TCP 关闭连接时的图例:

TCP Close

不要被图中的 client 和 server 所迷惑,你只要记住:主动关闭的一方发出 FIN 包,被动关闭的一

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

+0  Router Matters

Tag: *nix | networking | tcp
jaseywang 发于 2015年07月05日 21:05 | 点击: 797 | 展开摘要
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 Many Non-Persistent Connections Can Nginx/Tengine Support Concurrently

Tag: *nix | benchmark | nginx | optimization | tcp
jaseywang 发于 2015年06月04日 14:00 | 点击: 950 | 展开摘要
Recently, I took over a product line which has horrible performance issues and our customers complain a lot. The architecture is qute simple, clients, which are SDKs installed in our customers' handsets send POST requests to a cluster o

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

+0  tcp_keepalive_time and rst Flag in NAT Environment

Tag: *nix | ipvs | kernel | mongodb | tcp
jaseywang 发于 2015年04月27日 14:39 | 点击: 1087 | 展开摘要
Here, I'm not going to explain the details of what is TCP keepalive, what are the 3 related parameters tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes mean.

You need to know, the default value of these 3 parameters with

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

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

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

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

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

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

+0  PF_RING 对网络抓包性能的提升不仅仅是 30% – 40%

Tag: *nix | kernel | tcp
jaseywang 发于 2015年01月22日 21:42 | 点击: 6928 | 展开摘要
pf_ring 由于涉及的东西比较多,最初看的时候可能会云里雾里,不过多看几遍官方文档应该就能大致理解含义了。

安装的步骤可以看这里。 我建议还是自己跑一遍,这样能熟悉每个零部件的作用。要是实在没空,也可以直接用官方提供的 rpm, deb 安装。

这里提示下,除了编译出来的 pf_ring.ko 之外,如果你的 NIC 不支持 PF_RING™-aware driver,那么只能使用 mode 0,如果支持的话,可以使用 mode 1 以及 mode 2

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

+0  resolv.conf 的超时(timeout)与重试(attempts)机制

Tag: *nix | dns | infrastucture | operations | programming | tcp
jaseywang 发于 2015年01月02日 23:06 | 点击: 1932 | 展开摘要
/etc/resolv.conf 有两个默认的值至关重要,一个是超时的 timeout,一个是重试的 attempts,默认情况下,前者是 5s 后者是 2 次。

这个估计很多工程师都不是很在意,一般情况下,使用默认的值倒没什么大问题,特殊情况我会在最后说明。

要测试,不要使用 dig, host, nslook 这类工具,因为他们并没有调用 resolver 的库,可以使用 getent 来测试。上面提到的只是一些诊断的工具,对于日常的应用来说,包括 web ser

查看全文: http://www.udpwork.com/item/13720.html
|<<<123456>>>| 一共6页, 65条记录