发表于 | 分类于 | 阅读次数

Introduction

Openssl 是一个很牛逼的工具，基本能搞定 PKI & HTTPS 证书相关的事情。这篇博文归类了一堆常用的命令，全部都是关于 key & csr & crt。

本文分成两部分，第一部分对 SSL/TLS 证书最核心的几个名词概念，第二部分则是一系列 openssl 常用命令。

阅读全文 »

发表于 | 分类于 | 阅读次数

本篇主要介绍除RFC2544四项指标外的其它指标的测试方法。其中的性能测试项主要来源于RFC3511中的定义，并根据实际需求，更新或舍弃了部分指标项。

目录

本系列分为以下四部分：

  1. 简介及性能指标介绍
  2. RFC2544四项指标测试方法
  3. 其它指标测试方法 - 本篇
  4. 测试工具、注意事项及经验总结

术语介绍

文章中会涉及到一些术语，现总结如下，供参考。

  • 性能测试，对产品负载压力承受能力的测试。
  • RFC，互联网及软件等的一些标准，基本的互联网通信协议都有在RFC文件内详细说明。
  • 网关类产品，部署作为网关的设备及软件。
  • IDS，入侵检测系统
  • IPS，入侵防御系统
  • UTM，对防火墙、IDS、IPS三个的综合，可以比较全面的进行管理。但是UTM通过一台物理设备集成大量功能，导致了应对大量数据的时候效率会下降，同时存在设备损坏导致全面崩溃的可能。
  • NGFW，下一代防火墙，安全设备类产品未来的发展方向。
  • 被测设备，devices under test，测试设备。

其它性能指标测试方法

以下主要包括CPS、TPS、HTTP吞吐、TCP最大连接数及其它性能指标的测试方法。

阅读全文 »

发表于 | 分类于 | 阅读次数

目前在移植 BBR 拥塞控制的算法，这部分文章就不直接转载。把开发过程中，看过的几篇好文章链接直接贴在下面。

BBR Congestion Control

Congestion Avoidance Mechanism

Fast Retransmit

ACK

RTO Timer

Pacing Rate

Bomb250 这个人写的 TCP 相关的东西，是写的真好。剖析的很深入，但居然很易懂 [赞]。

发表于 | 分类于 | 阅读次数

slice 切片是对底层数组 Array 的封装，slice 就可以看作一个长度可变的数组使用。slice 可以通过两种方式定义，一种是从原数组中衍生，一种是通过make函数定义，本质上来说都是一样的，doit是在内存中通过数组的初始化的方式开辟一块内存，然后将其划分为若干个小块用来存储数组元素，然后slice就去引用整个或者局部数组元素。

  • 从数组中切片构建slice

    1
    2
    3
    a := [10]int {1,2,3,4,5,6,7,8,9,0}
    s := a[2 : 8]
    fmt.Println(s)

  • 通过 make 函数定义 slice

    1
    2
    ss := make([]int, 5, 20)
    fmt.Println(ss)

    ​

slice 的容量，如果通过 make 函数创建 slice 的时候指定了容量参数，那内存管理器会根据指定的容量的值先划分一块儿内存空间，然后才在其中按长度，存放数组元素，多余的部分处于空闲状态。

在 slice 上追加元素的时候，首先会到这块儿空闲的内存中，如果添加的元素的个数超过了容量的值，内存管理器会重新划分一块容量值为原容量2倍大小的内存空间。append 函数返回的是一个新构造的 slice，虽然其指向的 Underlay Buffer 可能保持不变（未发生 Reallocate 情况时），因此如果要完整实现 slice 的 append，则需要将 append 的返回值拷贝给原有的 slice。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
a := [5]int{1, 2, 3, 4, 5}

s := a[:2]
fmt.Printf("&s=%p, &s[0]=%p, s=%x\n", &s, &s[0], s)

s1 := append(s, 13, 14, 15)
fmt.Printf("&s1=%p, &s1[0]=%p, s1=%x\n", &s1, &s1[0], s1)

s = s1
fmt.Printf("&s=%p, &s[0]=%p, s=%x\n", &s, &s[0], s)

----

&s =0xc420014580,  &s[0]=0xc420016390,  s=[1 2]
&s1=0xc4200145c0, &s1[0]=0xc420016390, s1=[1 2 d e f]
&s =0xc420014580,  &s[0]=0xc420016390,  s=[1 2 d e f]
阅读全文 »

发表于 | 分类于 | 阅读次数

大家好，我是黄惠波，今天分享的主题是kubernetes在微服务化游戏中的探索实践

微服务化游戏容器化探索

随着Docker技术在近几年的快速发展，国内外掀起了一股容器之风。而我们也在这时，开启了游戏容器化的探索之路。最开始在Docker容器的应用上，还是以VM的模式去部署，毕竟游戏是非常复杂的应用，没有统一的模式。除此之外，对于一项全新技术的应用，大家都很谨慎，一步一步地去实践。

而在近一两年，部分游戏的架构也逐渐往微服务化方向转变，以下是一款游戏的架构：游戏的逻辑层按不同的服务划分为不同的模块，每个模块都是高内聚低耦合，之间的通信通过消息队列（或者API）来实现。模块的版本通过CI/CD，实现镜像标准交付，快速部署。在这些模块中，大部分是无状态服务，很容易实现弹性伸缩。

图片1.png

我们再来看另一款微服务化游戏的架构：也是按功能模块划分不同的服务，前端通过HAProxy来代理用户请求，后端服务可以根据负载来实现扩缩容。在服务发现模块中，通过Registrator来监视容器的启动和停止，根据容器暴露的端口和环境变量自动注册服务，后端存储使用了Consul，结合consul-template来发现服务的变化时，可以更新业务配置，并重载。

图片2.png

阅读全文 »

发表于 | 分类于 | 阅读次数

在之前的文章中，我们从容器OS、容器引擎，基础架构的容器网络、存储、安全，容器运行必不可少的镜像仓库、编排，及运维关注的监控、日志，多维度关注并解读了容器生态圈中的各个玩家。总体而言，较为活跃的有Google主导的kubernetes生态，和Docker公司主导的docker生态。选择哪个技术流派从某种意义上，也决定了选择哪种生态，这也是当前使用容器的公司面临的一大难题。

本文将从容器引擎为切入点，说明这两大流派的历史、初衷和技术对比。

容器引擎玩家知多少

看到这个标题，你的表情可能是这样滴[惊愕]：纳尼？容器引擎不就是docker么？这时，CoreOS可能在后面默默地流泪，因为CoreOS的rkt也是玩家中的一员。虽然目前Docker的容器使用者相对更多，但rkt的发展也不可忽视。

docker-and-rtk

Rocket 与 Docker 引发的站队

前世

这里让我们先来八一个卦，故事要从2013年开始说起。是的，Docker公司在2013年发布了后来红遍大江南北的docker产品，一场新的技术带来一次新的革命，也带来新的市场机遇，CoreOS也是其中的一员，在容器生态圈中贴有标签：专为容器设计的操作系统CoreOS。作为互补，CoreOS+Docker曾经也是容器部署的明星套餐。值得一提的是，CoreOS为Docker的推广和源码社区都做出了巨大的贡献。

然而好景不长，CoreOS认为Docker野心变大，与之前对Docker的期望是“一个简单的基础单元”不同，Docker也在通过开发或收购逐步完善容器云平台的各种组件，准备打造自己的生态圈，而这与CoreOS的布局有直接竞争关系。

阅读全文 »

发表于 | 分类于 | 阅读次数

Bandwith Limit to 12Mbps

1
2
3
# tc qdisc add dev ens4 handle 1: root htb default 11
# tc class add dev ens4 parent 1: classid 1:1 htb rate 1000Mbps
# tc class add dev ens4 parent 1:1 classid 1:11 htb rate 12Mbit

Latency with 300ms and 3% Loss (Be careful about the limit argument)

1
# tc qdisc add dev ens4 root handle 1:0 netem limit 102343600 delay 300ms 0ms loss 3%

Bandwith Limit + Latency + Loss

1
2
3
4
# tc qdisc add dev ens4 handle 1: root htb default 11
# tc class add dev ens4 parent 1: classid 1:1 htb rate 1000Mbps
# tc class add dev ens4 parent 1:1 classid 1:11 htb rate 12Mbit
# tc qdisc add dev ens4 parent 1:11 handle 10: netem limit 102343600 delay 300ms loss 3%

Metrics

1
# tc -s qdisc ls dev ens4

更多 TC 内部机制细节，请参考 http://perthcharles.github.io/2015/06/12/tc-tutorial/

发表于 | 分类于 | 阅读次数

An SD‐WAN has several advantages over a traditional WAN.

✓ Simplified WAN:

  • Rapid deployment and automation
  • Quality‐of‐Service (QoS) that adjusts with automated link and capacity monitoring
  • Scalable secure communications over any transport
  • Management and orchestration that can be cloud delivered or on‐premise

✓ 精简的 WAN :

  • 自动化的快速部署
  • 感知网络状态，实现 QoS 动态调整
  • 可伸缩的安全传输层设计
  • 部署及管理过程可实现云端交付

✓ Efficient WAN utilization:

  • Unification of all available WAN links to provide aggregate capacity
  • Distributed, cloud‐based services with simple policy‐based insertion

✓ 高效的网络利用率

  • 可以复用所有 WAN 链路，实现带宽倍增
  • 新增网络服务方便，支持分布式架构

✓ Assured application performance:

  • Forwarding based on real‐time evaluation of WAN characteristics, including quality and capacity of the link
  • Dynamic reactions to meet business policy based on performance or security criteria
  • Active‐Active support to provide subsecond reaction to WAN blackouts or brownouts so that application flow can be continued

✓ 高性能服务

  • 实时监测 WAN 链路质量，动态优化包转发路径
  • 闭环状态反馈，满足业务级别的性能和安全要求
  • 提供亚秒级别的 WAN 链路容灾切换，完全不影响用户应用

✓ Highly available WAN:

  • A physical transport‐independent overlay for managing user connectivity and experience to different applications
  • Greater flexibility in choosing and changing service providers
  • Faster provisioning times and automated configurations
  • Delivery of performance and security for on‐premise and cloud applications. No backhaul performance penalty

✓ 高可靠服务

  • 为用户应用提供，独立于底层传输层的网络性能保证
  • 用户可以随意切换网络供应商
  • 平台配置简单快速
  • 消除了 backhaul 性能损耗，不论是云端应用或者本地应用性能都得以保证

✓ MSP ready:

  • Central management and troubleshooting of complex customer environments
  • MSPs move from connectivity play to service delivery offerings
  • Elimination of expensive truck rolls and lengthy deployment cycles

✓ Manage Service Provider 托管服务友好

  • 为复杂的用户环境，提供集中化管理和故障排查
  • 实现持续交付的服务
  • 缩短部署周期

发表于 | 分类于 | 阅读次数

In a nutshell, SD-WAN

  • Virtualizes the network
  • Enables a secure overlay
  • Simplifies services delivery
  • Provides interoperability
  • Leverages cost effective hardware
  • Supports automation with business policy framework
  • Monitors usage and performance
  • Supports interoperable and open networking
  • Enables managed services

Virtualizes the network

SD‐WAN as a network overlay enables application traffic to be carried independently of the underlying physical or transport layer, offering a transport‐independent overlay. Multiple links, even from different service providers, constitute a unified pool of resources, often referred to as a virtual WAN.
This capability enables SD‐WAN to provide high availability and performance for applications. It also increases the utilization of resources and simplifies the network.

SD-WAN 能够对底层物理传输层进行抽象，对各种各样的物理链路进行整合统一，为应用程序提供高可用和高性能的虚拟 WAN 服务。

Network operators can add new links and applications easily because no static tie exists between the application and the link it must use – a key benefit of the abstraction principle. The virtualization also provides self‐healing as links experience degraded performance.

SD-WAN 将应用程序和物理链路之间进行了解耦，这样使得网络运行商可以随意引进新的传输链路或者部署新的应用程序。

阅读全文 »

发表于 | 分类于 | 阅读次数

软件定义网络 (SDN) 和网络功能虚拟化 (NFV) 在近两年已经成为全球网络行业的热点话题。它们之前显然是有关系的, 但是它们有哪些地方类似呢?不同之处又在哪里?二者如何做到相互辅助，相辅相成的呢？

SDN的本质

SDN 的本质是把网络软件化，提高网络可编程能力和易修改性。SDN没有改变网络的功能，而是重构了网络的架构。

SDN的价值

  • 快：网络业务自动化和网络自治，更快部署网络业务实例。更快在网络中增加新业务，大量需求仅需要升级控制器软件就可以实现。
  • 简：简化了网络协议，大量网络业务协议逐渐消失，用户的策略处理集中在控制器实现。
  • 省：通过集中控制，对网络资源进行统筹调度和深度挖掘，提高网络资源利用率，接入更多业务，从垂直整合走向水平整合，使得芯片、设备、控制器各层可以独立分层充分竞争。

NFV的本质

NFV没有改变设备的功能，而是改变了设备的形态。NFV的本质是把专用硬件设备变成一个通用软件设备，共享硬件基础设施

NFV的价值

  • 快：软件设备的发行安装速度远比硬件设备快，容量伸缩更快，避免硬件采购安装的长周期，可按需实时扩容。实现新需求新业务更快，避免了硬件的冗长开发周期。
  • 简：简化了设备形态，统一了底层硬件资源，都是服务器和交换机。
  • 省：采用通用服务器作为和交换机作为基础设施，大大降低设备成本。水平整合改变了原来的竞争格局，各个层次可以分层竞争。

SDN和NFV的关系

NFV 的软件设备（统称VNF）快速部署以及 VNF 之间网络快速建立，需要支持网络自动化和虚拟化能力，这需要 SDN 网络提供支持。

在 SDN 网络情况下的一些网络诉求，比如能够快速提供虚拟网络，快速部署增值业务处理设备和网络设备等这些快速业务上线需求，需要NFV的软件网络设备（FW、vRouter）才能达成目的。

小结：

  • SDN是面向网络的，SDN没有改变网络的功能，而是重构了网络的架构。
  • NFV是面向设备的，NFV没有改变设备的功能，而是改变设备的形态。

本文转载至：http://developer.huawei.com/ict/forum/thread-10097-1-1.html