月度归档:2016年08月

Centos67一键安装pptpd VPN

之前有折腾过CentOS 6、7下IPSEC/L2TP VPN一键安装脚本,但是不稳定、不支持IOS,因此换成pptp,并编写一个shell脚本,这个脚本可以单独使用,直接复制或下载执行即可,不用依赖安装包的其它脚本,完成CentOS 6、7下pptpd vpn一键安装脚本,安装如下:

Bare Bones (PPTP) VPN Installer for CentOS6、CentOS7

Installation

To get started with your own secure VPN, simply execute the following commands at your servers command-line:

yum -y install git
cd /root && git clone https://github.com/MonsterWang/VpnForCentos67.git
cd /root/VpnForCentos67/ && bash vpn_centos67.sh 

Statement

This script by other scripts to modify,The original script address is https://github.com/drewsymo/VPN

linux iptables连续端口配置和不连续端口配置

linux iptables可以方便的配置多个端口。其中根据端口的连续性,又可分为连续端口配置和不连续端口配置。

1、连续端口配置

如:

iptables -A INPUT -p tcp dport 21:25 -j DROP

注:这里是英文状态下的冒号。

2、使用multiport参数配置不连续端口

如:

iptables -A INPUT -p tcp -m multiport dport 21:25,135:139 -j DROP

inotify-tools的inotifywait工具用exclude 和 fromfile 排除指定后缀文件

今天打算使用 inotify-tool 来对线上程序文件进行监控, 因为有些目录是缓存目录, 所以要进行排除, 同时还要排除一些指定的后缀的文件, 比如 .swp 等

需要递归监控的目录为: /tmp/inotify-test-dir

需要排除的目录为: /tmp/inotify-test-dir/cache

需要排除特定后缀文件: .log .swp 文件

根据网上看的一些资料, 我先做了如下尝试:

/usr/local/bin/inotifywait -mr -e close_write,modify,create,move,delete –exclude ^.*\.(log|swp)$ –exclude “^/tmp/inotify-test-dir/cache” –timefmt %Y/%m/%d %H:%M –format %T %w%f %e /tmp/inotify-test-dir

发现无论如何改, 第一个排除指定后缀 .log 和 .swp 都不生效, 我以为是我写的正则有问题, 又修改了很多次, 还是不行. 没办法再次google, 最终还是让我发现了问题的所在, 原来 inotifywait 不支持两次 –exclude , 否则,后面的规则将覆盖前面的规则.

明白问题的所在后, 再次修改:

/usr/bin/inotifywait -mr -e modify,create,move,delete –exclude ‘^/tmp/inotify-test-dir/(cache|(.*/*\.log|.*/*\.swp)$)’ –timefmt ‘%Y/%m/%d %H:%M’ –format ‘%T %w%f %e’ /tmp/inotify-test-dir

这次ok 通过

———–

inotifywait 有 –fromfile 选项, 可以直接从文件中读入要监控的目录,和排除的目录. 在这里我使用 –fromfile ‘/tmp/inotify-file-list’ 选项

/tmp/inotify-file-list 文件的内容如下:

/tmp/inotify-test-dir

@/tmp/inotify-test-dir/cache

以@开头的路径代表的是要排除的目录和文件,其他的为要监控的文件

假如:我要递归监控 /tmp/inotify-test-dir 目录下的所有的所有的 .php 文件, 但是排除 /tmp/inotify-test-dir/cache 目录下的所有文件

我就可以这样写

/usr/bin/inotifywait -mr -e modify,create,move,delete –exclude ^.+\.[^php]$ –fromfile ‘/tmp/inotify-file-list’ –timefmt ‘%Y/%m/%d %H:%M’ –format ‘%T %w%f %e’

注意:

1、此种写法可以不用加“/tmp/inotify-test-dir”路径,fromfile中写有即可,经测试,加“/tmp/inotify-test-dir”路径也是可以正常运行

2、fromfile指向的文件,刚开始我是Notepad++创建,不知道是因为文件格式问题还是什么原因,导致在文件中写的规则出现莫名其妙的问题,后来通过touch命令新建一个文件,然后再在里面写入规则,测试后全部正常,害我白研究了一天时间。

附我在生产服务器上的自动同步脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#!/bin/sh
SRC=/data/wwwroot/web/ #代码发布服务器目录
DST=/data/wwwroot/web/ #目标服务器目录
IP="192.168.20.7"    #目标服务器IP,多个以空格隔开
USER=www
INOTIFY_EXCLUDE="--fromfile /data/conf/shell/inotify_exclude.list"
RSYNC_EXCLUDE="--include-from=/data/conf/shell/rsync_include.list --exclude-from=/data/conf/shell/rsync_exclude.list"
 
#su - $USER
inotifywait -mrq --exclude "(.swp|.inc|.svn|.rar|.tar.gz|.gz|.txt|.zip|.bak)" -e modify,delete,create,close_write,attrib $INOTIFY_EXCLUDE | while read D E F 
    do 
        for in $IP
        do
            /usr/bin/rsync -e 'ssh -p 5000' -ahqzt $RSYNC_EXCLUDE --delete $SRC $USER@$i:$DST          
        done       
    done

inotify-tools相关文章:

CentOS使用inotify+rsync实时文件监控的同步备份

inotify文件监控工具inotify-tools使用方法介绍

直播平台大火,最赚钱却是CDN网宿、帝联、快网、蓝汛、ucloud、腾讯云

   在十年前,视频网站刚刚兴起时,也是这般光景,当时视频网站也有数十家,其中两大巨额的开支,一是带宽支出,二是版权内容的购买成本,这两大成本支出让大多数独立视频网站难以为继,直至消失。最终的结局是优酷、土豆这两家最大的视频网站完成合并,而后又被阿里巴巴全资收购,腾讯视频和爱奇艺风靡,网络视频行业最终成为了互联网巨头们的独角戏。

直播平台步视频网站后尘,钱被传统CDN赚走,最终被巨头收割?

如今,直播平台似乎又要重蹈覆辙。根据IT桔子的数据统计,国内的直播创业平台多达288家,有很多直播平台还融到千万甚至过亿的融资。比如2015年11月,斗鱼TV获腾讯、南山资本、红杉1亿美元B轮融资;B站获超2亿人民币D轮融资;2016年3月易直播获A轮6000万人民币融资等等,而更多的直播创业平台都还在处在A轮。

不过,目前为止,这些直播平台基本上都未盈利,一边需要支付高额的带宽成本,另一边只是高价对明星主播资源的签约争夺,这看起来似乎又是一场类似于网络视频行业的“烧钱大战”,而结局似乎早已写好,在弹药补充足的情况下,有很多直播创业很可能将要倒在黎明之前。尤其是,近一年以来,国内的融资形势不容乐观,这更需要直播创业小心谨慎的“花钱”。

而与直播创业平台们面临的危险境遇形成鲜明对比则是,传统CDN厂商却在这一波直播平台创业浪潮当中,利用自身垄断的带宽资源优势大赚特赚。根据网宿科技助理总裁孙孝思在接受界面新闻记者采访时就表示,目前行业里80%的直播平台是网宿科技的客户。而目前直播创业平台最大的开支来自于带宽成本,在30%到50%之间,这是一家直播创业平台的最大头的运营成本支出,而这些支出基本上都流入了传统CDN厂商手里。

实际上,这些带宽成本的开支完全可以省下来一大半。目前国内能够为直播平台提供CDN服务的并不是仅仅只有传统CDN厂商,此外还有以阿里云、腾讯云为首的云服务厂商,以及以星域CDN为代表的创新型CDN服务商,他们提供的服务成本都要远低于传统CDN厂商。以星域CDN为例,其在今年5月份曾发布专为直播平台提供服务的产品,极速版的价格仅为传统CDN厂商的十分之一,仅为0.5元/Mbps/天;而旗舰版产品的价格更低,仅为0.27元/Mbps/天,只相当于传统CDN厂商的5%。这样的价格可以让直播创业平台的运营成本直线下降,可以使得直播平台逃离开烧钱大战的魔咒,从而能够将钱花在其他增加自身竞争力的用处上。

直播创业平台选择传统CDN,缘于三大行业认知误区

不过,既然创新CDN厂商的产品如此便宜,为何这些直播平台还是愿意选择网宿科技这样的传统CDN厂商呢?这可能是由于直播创业平台对于创新型的CDN服务商的认知误区所造成的,主要有以下三个方面:

第一,直播创业平台对于创新CDN厂商的产品和技术能力没有认识。对于直播平台而言,用户的观看体验至关重要,尤其是需要保证视频的清晰流畅的播放不发生卡顿,因此他们在选择CDN厂商时更倾向于选择传统CDN厂商,认为他们网络节点多,可以最大程度的得到保障。实际上,现在整个CDN行业已经进入到技术革新的阶段,而不再是原来那个粗放发展到时代。很多创新型的CDN厂商通过技术手段突破了原来的行业限制,从而能够以更低的成本提供更好的服务。以星域CDN为例,其首创“无限节点”技术,已经拥有了在全国布建百万量级服务节点的能力,其中包括400余个骨干节点和百万量级末梢节点,并且通过推出智能硬件产品赚钱宝以共享经济的方式首次实现了下沉至家庭内拉取内容数据,从而开辟出了一条总量更庞大、分布更均匀,数据传输距离可近至1km的网络加速通道,此外星域还有其独特的调度技术,以及动态防御和弱网加速技术等,这就意味着,在服务质量方面,创新型CDN厂商丝毫不输传统CDN厂商。

第二,很多直播创业平台对于创新CDN厂商的服务质量没有信心,误认为传统CDN厂商的成立时间更久,技术可能更加成熟。实际上,事实可能恰恰相反,尽管传统CDN厂商运营时间很长,但由于在云服务商和创新型CDN厂商出现之前,面临的竞争压力很小,导致传统CDN厂商在产品方面缺乏更多的创新,更多的是通过在全国各地架设节点来提高加大自己的带宽,而在具体的产品服务方面,尤其是针对不同的垂直行业方面,并不会及时的推出专业化的解决方案。相较而言,新兴的CDN服务商以产品创新立足,创新的意愿更为强烈,以星域CDN为例,其在今年5月推出了针对直播行业的新产品,而且还具体到了泛娱乐直播、教育直播、事件直播、移动户外直播、/全景直播等几个方面,这使得不同的直播创业平台可以选择更加专业化的服务。显然,在成本更低的情况下,创新CDN厂商对于直播创业平台的服务可能更加到位。

第三,很多直播创业平台选择传统CDN厂商主要看重其行业知名度,迷信其之前服务过的知名企业案例,而不是选择能够与其共进退的合作伙伴。实际上,在服务的主动性方面,创新CDN厂商可能更好,而传统CDN厂商由于长期以来占据着资源的垄断优势,普遍缺乏服务意识,更多的将直播平台看作是客户关系,而并不是合作伙伴,这就意味着并不会真正从合作伙伴的角度去着手解决问题,而更多的看重其营业收入,因此在这些年以来,带宽价格从来没有主动降价过,直到像星域这样的创新CDN厂商出现之后,带宽价格才有了小幅降低,但是仍然比云服务商和创新CDN厂商的价格高出许多。而早在2015年6月,网心科技CEO陈磊在接受媒体采访时就指出,传统CDN厂商的服务心态有问题。相较而言,创新CDN厂商更愿意与直播创业平台一起发展,也因如此,在星域CDN直播产品的发布会上,获得了包括小米直播、大鹏VR、触手TV等多家直播创业平台的力挺。

总体而言,在直播创业大火的当下,创业公司随时面临倒闭危险,而传统CDN厂商却赚的盆满钵满,这是非常不合理的现象。如此下去,独立的直播创业平台可能最终也只能是投入到巨头的门下,而如果想要改变这种不利的局面,第一步或许可以从降低带宽成本开始,而创新的CDN服务商无疑是一个不错的选择。

全民大直播,流媒体选择Nginx是福还是祸?

CDN,视频云,已经“僧多粥少”

视频直播的持续升温,无意间也让带宽生意的争夺变得异常残酷。一时间,各种云计算、CDN、视频云提供商都在视频尤其是直播上投入重兵,揭竿而起的新生起义军们也正马不停蹄的赶往这方战场,各种号称可以在IaaS、PaaS、SaaS不同层面提供平台级、接口级以及产品级服务的花式作战口号此起彼伏,让人眼花缭乱,“僧多粥少”可能成为了当前支撑视频技术解决方案市场最恰当的提法。如此局面之下,视频云和CDN们,技术上到底是在竞争什么?作为视频平台和即将要进入视频领域的运营者,在技术平台的选型和搭建上又如何才能避免掉入大坑?

一个播放器的背后

谁都知道视频直播最重要的是流畅和高清,但这光鲜亮丽的背后是技术和成本的双高门槛,是诸多技术环节艰难积累和苦逼的人肉运维。主播发起一个简单的直播,主干流程就历经了采集、编码、推流、转码、分发、拉流、解码和播放这么多环节,还要求在数秒内完成,除此之外直播还有如录制、流控、安全、审核等等诸多复杂功能需求。

再如下图,仅一个屌丝观众从播放器看这个主播,就可能出现如此多不可知情形发生。这个屌丝的接入网络怎么样?使用的系统环境又怎么样?一个观众尚且如此,要保障百万千万级别流畅的观看,难度可想而知。

高清流畅到底靠的是什么

也许对于部分视频运营商和新进入者来说,直播推流端和播放器端依然觉得头大,但整体来说,除移动端外,PC端推流和播放技术已经比较成熟。难,主要难在传输和分发!正常情况下,只要推流端网络状况良好,传输和分发决定着直播是否能够流畅。

传输和分发,涉及到了视频最核心技术、巨额服务器和带宽成本以及国内网络环境极度错综复杂也因为如此,视频平台基本上都将传输和分发环节交由专业的第三方视频云服务商或CDN服务商来完成。我们从网络传输的七层中拿出与视频传输分发相关的四层,如下图:

L2资源层:对视频云和CDN来说,资源的确存在差别,但在其可承受范围内,可以视为差别不大;

L4传输层:传输层可针对不同业务场景,比如针对超低延迟可以基于UDP做私有协议等。本文侧重阐述视频流畅的保障,不同应用场景的支持后续文章将专门介绍;

L3网络层:视频云和CDN公司在该层实现各运营商网间打通、多层Cache系统设计以及用户就近调度。该层的设计及优化对访问质量极为重要,随着CDN技术的日益成熟,虽然各家可能存在架构区别,但基本都能保障网络路由正常运转;

L7应用层:抛开细枝末节,视频流的主线还是输入、传输与输出,承担这些工作的就是视频平台最核心组件流媒体服务器,这就是视频直播分发最本质的特点,需要专门的流媒体服务器来分发,所有视频云和CDN,都需要在中心层和边缘层部署流媒体Server。

 

通过以上逐层分析可知,当资源和网络层面相差不大的情况下,流媒体Server的性能决定了视频流分发的效果和质量,故流媒体Server才是视频云和CDN技术竞争的至高点。



市面主要的流媒体服务器对比

目前市面上主流的流媒体服务器,有以Adobe FMS、Real Helix、Wowza为代表的第一代产品,它们的特点是单进程多线程。基于Linux2.7 epoll技术,出现了以多进程单线程为特点的第二代流媒体服务器,NginxRTMP、Crtmpd为其优秀的代表,另外还有基于JAVA的流媒体祖先Red5等。

观止云开源流媒体服务器SRS(Simple RTMP Server),凭借其功能强大、轻量易用、特别适合互动直播等诸多特点备受海内外视频从业者的青睐。蓝汛Chiancache曾用SRS承载其直播边缘分发业务,高升CDN基于SRS搭建其流媒体基础平台,其它还有赛维安讯、VeryCDN、VeryCloud、云博视等也将SRS应用到了自身的业务当中。各家视频云、云计算平台在源站的对接上也非常注重对SRS的支持。SRS作为纯国产的开源Server,在中国流媒体业界实属难能可贵。

观止云源站集群BMS(Bravo Media Server)是SRS的商业版,BMS在SRS基础上增强了11项大功能,新增了9个大功能

增项的11项大功能:



新增的9项大功能:





流媒体Server的话说来也不短,上述列举的目前市面上主流流媒体服务器中,有名副其实的先烈RED5,有生不逢时的CRTMPD,都未大规模商用就不过于讨论了。其中应用最为广泛莫属nginx-rtmp,以下是nginx-rtmp几个盛行于世的重要因素:

  • 2012年CDN业务开始极增长,随之直播需求也多了起来,彼时业界都还没有一套公认的特别满意的流媒体服务器;

  • Nginx是HTTP领域绝对的霸主,大家(尤其是CDN运维)对Nginx熟悉程度很高,便于上手维护;

  • 基于Nginx,直播点播使用一套服务器,这也极具诱惑力,一套管理起来总比多套要简单;

  • CDN是靠运维的行当,运维的信心都是长年运出来的,Nginx在图文上那么优秀,Nginx RTMP也差不了。



nginx-rtmp确实生来就自带光环外,性能也的确是高,比Crtmpd还要高。然而,时过境迁,随着互动直播、移动直播的强势兴起的大直播时代,选择nginx-rtmp到底是福还是祸?

下面小编将从协议支持、体系架构、核心功能支持、配置运维、性能、服务器日志、数据这七大维度将目前市面主流的流媒体Server做一个横向对比,供视频从业者根据自身业务场景特性择优选用。



1
网络协议对比

BMS支持HDS、DASH、RTMPE/S/T等协议的分发,这将支持更多业务应用场景,FLASH P2P的支持能够显著降低网络带宽成本。



2
体系架构对比

架构方面,较之于nginx-rtmp的16万行代码,SRS仅用了6.5万行代码就实现了比nginx-rtmp 多了230%的功能nginx-rtmp注释率为3%,而SRS是23.7%。由此可见SRS在体系架构上的轻,Simple。

观止云BMS在SRS的基础上新增了多进程支持、源站集群、动态配置、可追溯日志等方面能力。源站集群子系统打通了跨网跨地区的源站分布式部署难题;动态配置子系统从业务系统读取配置,依据更新机制动态更新配置,保证直播业务配置变化时依然不中断;端到端的可追溯日志及监控排错子系统将直播故障定位时间缩短到了分钟级别。



3
核心功能对比

核心功能方面,BMS支持了当期互动直播、移动直播急需的大规模直播流实时转码、大规模录制、秒级低延迟、HLS+、并发回源等其它所有流媒体系统不具备的功能。HLS+基于每个播放请求实现了流媒体的“虚拟连接 ”(UUID标识),在减小回源量、排错、防盗链、移动Web端低延迟等方面具有诸多优势。并发回源能够解决回源网络状况差、跨国传输丢包严重等方面能够显著提升回源质量。



4
配置运维对比

以下仅是流媒体众多配置之中几个常用例子,运维日常工作中,需要操作的配置数量更多。

(1)vhost配置

FMS

拷贝默认vhost目录:sudo cp -r conf/_defaultRoot_/_defaultVHost_ conf/_defaultRoot_/bravo.sina.com



nginx-rtmp

不支持



SRS/BMS

动态获取配置文件:vhost bravo.sina.com { }

结论:BMS动态获取配置最简单

(2)app配置

 FMS

拷贝默认app目录:cp applications/live applications/mylive -r



nginx-rtmp

修改配置文件,增加如下内容:application live {  live on; }



SRS/BMS

无需配置

结论:BMS无需配置,最简单 

(3)http配置

在输出为hls、http-flv等基于http协议的直播流时,需要配置http服务

FMS

配置FMS内置的Apache服务器文件:Apache2.2/conf/httpd.conf

再修改如下字段:

<Location /hds-live>

    HttpStreamingEnabled true

    HttpStreamingLiveEventPath “../applications” 

    HttpStreamingContentPath “../applications” 

    HttpStreamingF4MMaxAge 2

    HttpStreamingBootstrapMaxAge 2

    HttpStreamingFragMaxAge -1

    Options -Indexes FollowSymLinks

</Location



nginx-rtmp

nginx本身就是一个http服务器,

修改其配置文件:

conf/nginx.conf

设置端口和根目录:

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    server {

        listen       80;

        server_name  localhost;

        location /dash {

            root /tmp;

            add_header Cache-Control no-cache;

        }

    }

}



SRS/BMS

修改其配置文件:

conf/http.hls.conf

设置端口和根目录:

http_stream {

    enabled         on;

    listen          8080;

    dir             ./objs/nginx/html;

}

结论:nginx-rtmp需指定与app对应的ts文件存放目录,SRS/BMS会自动生成,更简单。

(4)推流、播放URL配置

RTMP直播时,各大服务器推流、播流URL均为:

rtmp://server_ip_or_dns/app/stream



用作HLS直播时,

FMS 

推流域名:

rtmp://fms-ip-or-dns/app/stream?adbe-live-event=liveevent

播流域名:

http://fms-ip-or-dns/hds-live/app/_definst_/liveevent/stream.f4m



nginx-rtmp

推流域名:

rtmp://server_ip_or_dns/app/stream

播流域名:

http://server_ip_or_dns/app/stream.m3u8



SRS/BMS

同nginx-rtmp

结论:nginx-rtmp、SRS/BMS均简单,FMS较复杂。



5
性能

先说结论:

SRS单进程能支持9000并发,nginx-rtmp单进程最多支持3000个,单进程的性能SRS是nginx-rtmp的三倍。单进程性能SRS > nginx-rtmp > crtmpd > wowza > fms > RED5

 

再例举SRS性能如此高的几个原因:

1. st-load,这个是SRS能做到高性能的最重要的原因,一个st-load可以模拟2000+的客户端,如果没有st-load,如何知道系统的性能瓶颈在哪里?总不能打开3000个flash页面播放rtmp流吧?开启3000个ffmpeg来抓流?高性能不是想象和猜测出来的,而是反复测试、调试和改进出来的。

2. gperf/gprof性能,编译SRS时,就可以打开gcp或者gprof的性能分析选项,非常方便的拿到数据。缩短了改进和优化开发周期。

3. 引用计数的msgs避免内存拷贝。

4. 使用writev发送chunked包,避免消息到chunked包的内存拷贝。

5. mw(merged-write)技术,即一次发送多个消息。

6. 减少timeout recv,每个连接都是一个st-thread在服务。

7. fast buffer和cache。

8. vector还是list?vector!vector比list高10%性能。



6
服务器日志

日志是定位故障的唯一途径,定位故障才能快速排错。可以这么说,对于直播,10分钟的排错,谁都会觉得长。然而,当前的视频云或CDN,谁又能做到10分钟呢?

来看看日志吧。

FMS的日志是这样的,恕我愚钝,你能看得出什么信息么?

2015-03-24 12:23:58 3409 (s)2641173 Accepted a connection from IP:192.168.1.141, referrer:http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23,pageurl: http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935-

702111234525315439     3130         3448         normal      livestream         –        –         rtmp://192.168.1.185:1935/live/livestream     rtmp://192.168.1.185:1935/live/livestream        –        flv     –        –        0       –        0       0         –        –    http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935    -1      -1.000000         

crtmpd的日志详细,但我又愚钝,若是上千人在线,你又能看出什么有用的东西么?

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/iohandlermanager.cpp:120Handlers count changed: 15->16 IOHT_TCP_CARRIER

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/tcpacceptor.cpp:185Client connected: 192.168.1.141:54823 -> 192.168.1.173:1935

/home/winlin/tools/crtmpserver.20130514.794/sources/applications/appselector/src/rtmpap

nginx支持中文文件名方法

nginx支持中文文件名方法载过来与大家一起分享!该方法还没有亲自测试,所以不太确定是否真有用!

方法一(已经测试OK):

搞了大半天nginx下无法访问中文文件名的问题,现在看来是secureCRT的问题?
看来还是字符集的问题了。
看来nginx不需要象apache那样要单独加载支持中文模块。

服务器端字符集如下
[root@test]# locale
LANG=en_US.UTF-8
LC_CTYPE=”en_US.UTF-8″
LC_NUMERIC=”en_US.UTF-8″
LC_TIME=”en_US.UTF-8″
LC_COLLATE=”en_US.UTF-8″
LC_MONETARY=”en_US.UTF-8″
LC_MESSAGES=”en_US.UTF-8″
LC_PAPER=”en_US.UTF-8″
LC_NAME=”en_US.UTF-8″
LC_ADDRESS=”en_US.UTF-8″
LC_TELEPHONE=”en_US.UTF-8″
LC_MEASUREMENT=”en_US.UTF-8″
LC_IDENTIFICATION=”en_US.UTF-8″
LC_ALL=

在nginx.conf文件里配置的字符集也是utf-8
server {
listen 80;
server_http://www.dnsdizhi.com/zixun/aggregation/11696.html”>name test.cn;
root /data;
index index.html index.jsp;
charset utf-8;

客户端用的是secureCRT,字符集用的是defalut,用rz上传后在服务器上用ls显示乱码,用ie怎么浏览都不能正常看到。
找朋友测试了一下他那边的nginx,中文显示居然一切正常,后来他告诉我他的secrueCRT用的字符集是utf-8,我改用uft-8后再用rz上传文件,在ie下中文可以正常显示了。

方法二:

一:确定你的系统是UTF编码

[root@Tserver ~]# env|grep LANG
LANG=en_US.UTF-8

二:NGINX配置文件里设置为

server
{
   listen       80;
   server_name  .dnsdizhi.com ;
   index index.html index.htm index.php;
   root  /usr/local/nginx/html/inginx.com;
   charset utf-8;
   }

三:如果使用putty

windows  –> translation –>UTF-8

mkdir NGINX中文技术站
echo NGINX中文技术站 > 中国.html

四,如果是用securecrt 上传文件,请选择 回话–>外观–UTF-8

五,如果出现文件名乱码显示

执行
for f in `ls *.html` ; do mv $f `ls $f|iconv -f GBK -t UTF-8`; done

另一位朋友的解决方案是:

我现在用的方法是
在后端个别目录用APACHE代理了 。。
APACHE支持中文码。。

location /~doc/ {
   proxy_pass http://127.0.0.1:81/;#apache server
}

以上供大家参考!

curl实践HTTP206状态:部分内容和范围请求

HTTP 2xx范围内的状态码表明了:”客户端发送的请求已经被服务器接受并且被成功处理了”.HTTP/1.1 200 OK是HTTP请求成功后的标准响应,当你在浏览器中打开www.cyberciti.biz后,你通常会得到一个200状态码.HTTP/1.1 206状态码表示的是:”客户端通过发送范围请求头Range抓取到了资源的部分数据”.这种请求通常用来:

  1. 学习http头和状态.
  2. 解决网路问题.
  3. 解决大文件下载问题.
  4. 解决CDN和原始HTTP服务器问题.
  5. 使用工具例如lftp,wget,telnet测试断电续传.
  6. 测试将一个大文件分割成多个部分同时下载.

查明远程服务器是否支持HTTP 206

首先你需要知道文件大小以及远程服务器是否支持HTTP 206请求.使用curl命令可以查看任意资源的HTTP头,使用下面的curl命令可以发送一个HEAD请求:

$ curl -I http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png

输出结果为:

HTTP/1.0 200 OK
Content-Type: image/png
Content-Length: 36907
Connection: keep-alive
Server: nginx
Date: Wed, 07 Nov 2012 00:44:47 GMT
X-Whom: l3-com-cyber
Cache-Control: public, max-age=432000000
Expires: Fri, 17 Jul 2026 00:44:46 GMT
Accept-Ranges: bytes
ETag: "278099835"
Last-Modified: Mon, 05 Nov 2012 23:06:34 GMT
Age: 298127

其中有两个我们比较关注的请求头:

Accept-Ranges: bytes – 该响应头表明服务器支持Range请求,以及服务器所支持的单位字节(这也是唯一可用的单位).我们还能知道:服务器支持断点续传,以及支持同时下载文件的多个部分,也就是说下载工具可以利用范围请求加速下载该文件.Accept-Ranges: none 响应头表示服务器不支持范围请求.

Content-Length: 36907 –  Content-Length响应头表明了响应实体的大小,也就是真实的图片文件的大小是36907字节 (37K).

如何发送一个range请求头?

现在,你知道了该图片所在的服务器支持范围请求,你需要发送一个包含Range请求头的GET请求:

Range: bytes=0-1024

完整的请求数据应该是这样的.首先第一行是:

GET /images/misc/static/2012/11/ifdata-welcome-0.png HTTP/1.1 

然后需要发送Host请求头来指定请求资源所在的主机和端口号:

Host: s0.cyberciti.org

最后是要发送的Range请求头,指定了你想要的字节范围:

Range: bytes=0-1024 

使用telnet命令

telnet命令允许你使用Telnet协议来与远程主机(服务器)进行通信.所有的类Unix操作系统以及MS-Windows都包含有Telnet客户端.启动Telnet客户端并进入Telnet提示符,要执行命令:

telnet your-server-name-here www
telnet your-server-name-here 80

想要通过端口号80连接远程服务器s0.cyberciti.org,输入:

telnet s0.cyberciti.org 80 

输出结果为:

Trying 54.240.168.194...
Connected to d2m4hyssawyie7.cloudfront.net.
Escape character is '^]'.

在本例中,使用范围请求(0-1024 字节)来请求s0.cyberciti.org上的/images/misc/static/2012/11/ifdata-welcome-0.png文件,输入:

GET /images/misc/static/2012/11/ifdata-welcome-0.png HTTP/1.1
Host: s0.cyberciti.org
Range: bytes=0-1024

输出结果为:

Fig.01: Telnet command Range-requests bytes header example (HTTP 206)

上图中,

  1. 区域1 – GET请求以及请求头.
  2. 区域2 – 206状态以及响应头.
  3. 区域3 – 二进制数据.

使用curl命令

curl命令是一个和远程服务器交换数据的工具.它支持HTTP/FTPSFTP/FILE协议上的范围请求,在下例中,使用两段范围来请求远程文件ifdata-welcome-0.png,然后使用cat命令将两段数据合并成完整文件:

curl  --header "Range: bytes=0-20000" http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part1
curl  --header "Range: bytes=20001-36907" http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part2 cat part1 part2 >> test1.png
gnome-open test1.png

还可以使用-r选项(可以同时添加-v选项查看请求头和响应头):

curl  -r 0-20000 http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part1
curl  -r 20001-36907 http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part2 cat part1 part2 >> test2.png
gnome-open test2.png

如何开启Accept-Ranges响应头?

大部分web服务器都原生支持字节范围请求. Apache 2.x用户可以在httpd.conf中尝试mod_headers:

Header set Accept-Ranges bytes

Lighttpd用户尝试在lighttpd.conf中进行下面的配置:

## enabled for all file types ##
server.range-requests = "enable" ## But, disable it for pdf files ##
$HTTP["url"] =~ "\.pdf$" { server.range-requests = "disable" }

CentOS6.x下配置sendmail发邮件

安装配置sendmail软件  

yum install -y sendmail sendmail-cf m4

设置Sendmail服务的网络访问权限

vi /etc/mail/sendmail.mc

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

将127.0.0.1改为0.0.0.0,意思是任何主机都可以访问Sendmail服务。如果仅让某一个网段能够访问到Sendmail服务,将127.0.0.1改为形如192.168.1.0/24的一个特定网段地址。

生成Sendmail配置文件

Sendmail的配置文件由m4来生成,m4工具在sendmail-cf包中。如果系统无法识别m4命令,说明sendmail-cf软件包没有安装。

生成Sendmail的配置文件:

m4 /etc/mail/sendmail.mc /etc/mail/sendmail.cf  

需要重启Sendmail才能使配置文件生效。

service sendmail restart

把机器名加入到/etc/hosts中

echo ""  >> /etc/hosts

echo "127.0.0.1      $HOSTNAME"  >> /etc/hosts

iptables配置

iptables -A INPUT -p tcp --dport 25 -j ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

service iptables save

service iptables restart

测试发邮件:

mail -s "hosts" xxxx@qq.com < /etc/hosts

利用ffmpeg将MP4文件切成ts和m3u8(苹果官方推荐ffmpeg脚本)

1、将MP4转成m3u8

ffmpeg -i test.mp4 -codec copy -bsf h264_mp4toannexb test.ts

2、将ts转成m3u8

网上很多垃圾文章推荐segmenter工具,但用的时候,3.5G的ts文件丢了一半的数据,于是想到了ffmpeg转。

在国外网站找到命令,一句话搞定,没报半句错:

ffmpeg -i 12生肖.ts -c copy -map 0 -f segment -segment_list playlist.m3u8 -segment_time 10 output%03d.ts

顺便共享给各位国内的同仁,免得深受其苦。毕竟,大家都说HLS代表future,rtsp已经是过去式了。

苹果官方推荐ffmpeg脚本

#!/bin/sh

BR=800k

ffmpeg -i $1 -f mpegts -acodec libmp3lame -ar 48000 -ab 64k -s 320×240 -vcodec libx264 -b $BR -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -subq 5 -trellis 1 -refs 1 -coder0 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 200k -maxrate $BR -bufsize $BR-rc_eq ‘blurCplx^(1-qComp)’ -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect 320:240 -g 30-async 2 sample_$BR_pre.ts

segmenter sample_$BR_pre.ts 10 sample_$BR stream-$BR.m3u8 http://www.ioncannon.net/

rm -f sample_$BR_pre.ts

可以节约CDN带宽流量的流媒体P2P(Flash/Android/IOS)

很多朋友关心SRS是否有计划支持RTMFP,是否计划支持P2P,这篇文章详细介绍了SRS和P2P的关系。

Summary

我们所指的P2P,并非传统客户端P2P的方式,譬如ed2k那种协议。我们特指三种P2P:

  1. FlashP2P:Adobe开发的P2P,Flash播放器之间可以互相P2P,分享视频。

  2. AndroidP2P:特指Android的App的P2P方式,Android上HTML5不可能做P2P。

  3. IOSP2P:特指IOS的App的P2P方式,IOS上HTML5不可能做P2P。

这三种P2P都有几个共同点:

  1. 只讨论流媒体范畴的P2P,普通文件和数据的P2P不考虑。

  2. 流媒体传输使用通用协议,譬如flv、mp4或hls,配合CDN完成P2P原始资源的传输,而并非所有的数据都是P2P网络用私有协议传输。

  3. 尽量避免安装额外插件。譬如FlashP2P就在flash播放器上跑(别纠结flash本身就是个插件),只需要集成AS的SDK,不需要额外安装ActiveX浏览器插件。而Android和IOS的P2P,需要集成P2P系统的SDK,只需要安装商家的App,而不需要再安装专门用来做P2P的App。

综上所述,我们可以将Flash/Android/IOS
P2P,简称为P2P。下面讲P2P一种可能的结构,以及SRS和P2P的关系。

Structure

一个P2P系统,可以包含下面几个结构:

  1. 客户端SDK:P2P系统必须提供客户端SDK,集成在播放器或者App中。譬如FlashP2P提供的是AS的库,Android提供的是java的库,IOS提供oc的库。

  2. API调度集群:P2P系统必须支持API调度,弥补DNS的不足,以及提供P2P系统需要的额外数据。API调度就是SDK交互的第一个后端,完成认证、其他服务器资源的分配、流信息、实时调度。

  3. RTMFP集群:或者称为基础协议集群,由API调度返回给SDK可用的服务器,客户端使用RTMFP服务器完成NAT打洞,以及必要的数据传输。

  4. Tracker集群:或者称为伙伴发现协议集群,由API调度返回给SDK可用的服务器,客户端向Tracker请求可用的伙伴节点。

  5. Pingback集群:或者称为实时数据集群,由API调度返回给SDK可用的服务器,并提供给API调度集群调度的实时数据依据,SDK向Pingback集群汇报实时数据。

  6. 流媒体源站集群:或者称为流媒体源,主要负责流媒体数据的生成,和CDN对接,由API调度返回给SDK可用的CDN边缘地址。

可以在SRS基础上完成的结构是:流媒体源站集群、RTMFP集群。其他大多是HTTP协议,主要是P2P系统内部的算法和逻辑处理,适合使用Python或者GO实现。

另外,Pingback集群需要提供10秒级别的系统数据,使用GO或者Spark都可以,数据量小时用GO实现也可以,数据量很大时可以用Spark。

下面详细分析SRS在WebP2P中的位置和状态。

SRS for P2P

回过头来说,SRS现在已经支持P2P中的流媒体源站集群和RTMFP集群了吗?SRS支持了流媒体源站集群,但是RTMFP集群不支持。

所谓SRS支持了流媒体源站集群,指的是SRS能输出一种HLS,能符合一种P2P系统的要求。这种P2P系统就是观止创想的P2P系统,具体参考BravoP2P。也就是说,若使用SRS作为您的流媒体服务器,是可以直接对接到观止的P2P系统的,可以给现有的HLS流加上P2P功能。

SRS为何不支持RTMFP集群呢,有几个原因:

  1. RTMFP目前不开源。

  2. RTMFP和SRS的差异太大,就算支持了RTMFP集群,还只是P2P系统的六分之一,没法用起来。

  3. SRS的目标是提供通用方案,SRS3的Dragon技术,SRS4对接Spark,目前还没有支持P2P系统的计划,P2P系统里面很多是私有方案。

因此,在现在的路线图,例如SRS3(预计2016年发布)和SRS4(预计2017年发布)的路线图中,都没有RTMFP的影子。

也就是说,在P2P系统中,SRS只计划支持流媒体源站功能。下面分开看看各种P2P系统。

FlashP2P

FlashP2P是由Adobe研发的P2P协议,包括握手、NAT打洞、数据传输,Adobe收购了一家做P2P的公司,将这个RTMFP协议集成到了Flash中。

FlashP2P在PC上的很成熟了,稳定性也可以达到商用的要求。从2013年开始,支持FlashP2P的公司也开始粗现,现在除了我们观止创想,还有云某动、快播解散后的一个团队等等。

AndroidP2P

Android手机、盒子和Pad上面支持P2P,这个目前还在发展中。

IOSP2P

IOS手机和Pad上面支持P2P,这个难度比AndroidP2P还大,目前没有消息。

Challenge

上面讲了各种P2P的情况,P2P的挑战有以下几点:

  1. 转换思维对接CDN:CDN最惧怕的就是P2P公司,不是要分他流量那么简单,而是对接起来灰常痛苦。据说有的FlashP2P系统,得在CDN每个边缘节点部署服务器,因为流媒体切片不通用,这不是要CDN的命么?因此首先最大的挑战就是转换为互联网思维,尽量使用通用方案,让CDN爽了P2P系统才能爽。

  2. 保证流畅度:传统P2P可以暂停缓冲个几个小时,而WebP2P直播正在进行时,缓冲个几次用户就刷新页面,这个P2P节点就相当于牺牲了。因此保证流畅度才能保证分享率,如何保证流畅度呢,这个就各显神通了。

  3. 实时调度:P2P的变化非常快,有的用户刷新页面啦,有的系统拖动啦,有的还暂停,有的就喜欢乱点。因此整个P2P的节点信息都是变化很快的,这对实时分析系统有非常大的挑战。

  4. 负载均衡和热备:P2P的集群也需要负载均衡,譬如RTMFP协议就支持Redirect方式,可以实现负载均衡和热备。传统P2P系统挂掉后节点就没法看视频,而一个P2P系统挂掉后依然能看,因为有CDN在那里呢,但是带宽就开始飙升了。而P2P系统的恢复需要较长时间,因此必须使用热备,在出现问题时切换到正常的系统。

这些挑战都是我们曾经遇到的,还包括没有遇到的。