美国DNS服务器地址大全，包括公共DNS服务器
2018开放公共DNS服务质量评测（美国访问）
2018开放公共DNS服务质量评测（美国访问），也是电脑或者手机在美国。
DNS在平时上网中扮演重要角色，如果不注意的话，可能会导致网速慢、弹窗广告、网址打不开、打开不是自己想要的网站、劫持、墙中墙等一系列问题。针对DNS的问题，今天我们就来总结一下，看看哪个DNS服务器最好用！
注意：本测试仅通过奇云测对服务器进行综合测试，具体使用情况请以用户本地为主。
DNSPod：★★★★
DNSPod是目前国内第一家支持ECS的公共DNS，可为全网用户提供域名的公共递归解析服务！
DNS 服务器 IP 地址：
首选：119.29.29.29
备选：182.254.116.116
作者点评：查询138毫秒左右，说明在美国没有服务器，应该是回到香港服务器解析的！
# dig @119.29.29.29 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @119.29.29.29 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11439
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 56 IN A 180.149.134.142
www.weibo.com. 56 IN A 180.149.134.141
;; Query time: 138 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Fri May 4 05:04:58 2018
;; MSG SIZE rcvd: 63
114DNS：★★★
国内用户量巨大的DNS，访问速度快，各省都有节点，可同时满足各运营商用户，有效预防劫持。
DNS 服务器 IP 地址：
首选：114.114.114.114
备选：114.114.114.115
作者点评：美国测试130-160毫秒查询反应，说明在美国没有服务器，应该是回到中国大陆服务器解析的！
# dig @114.114.114.114 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @114.114.114.114 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23580
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 38 IN A 123.125.104.197
;; Query time: 160 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Fri May 4 05:06:24 2018
;; MSG SIZE rcvd: 47
阿里 AliDNS：★★★
阿里公共DNS是阿里巴巴集团推出的DNS递归解析系统，面向用户提供快速、稳定、智能的免费DNS递归解析服务。
DNS 服务器 IP 地址：
首选：223.5.5.5
备选：223.6.6.6
作者点评：查询178毫秒查询反应，说明在美国没有服务器，应该是回到中国大陆服务器解析的。
# dig @223.5.5.5 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @223.5.5.5 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13885
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 16 IN A 180.149.134.142
www.weibo.com. 16 IN A 180.149.134.141
;; Query time: 178 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Fri May 4 05:09:14 2018
;; MSG SIZE rcvd: 63
DNS派★★★★
DNS派是聚流旗下的DNS服务，为个人用户、企业提供各种DNS服务，包括域名解析服务、网站授权解析服务、域名解析服务等
DNS 服务器 IP 地址：
首选（电信/移动/铁通）：101.226.4.6
备选（电信/移动/铁通）：218.30.118.6
首选（联通）：123.125.81.6
备选（联通）：140.207.198.6
作者点评：360出品！区分运营商，明显没有做BGP，过断抛弃。
# dig @101.226.4.6 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @101.226.4.6 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20393
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 75 IN A 180.149.134.141
www.weibo.com. 75 IN A 180.149.134.142
;; Query time: 136 msec
;; SERVER: 101.226.4.6#53(101.226.4.6)
;; WHEN: Fri May 4 05:11:18 2018
;; MSG SIZE rcvd: 63
百度旗下云解析服务★★★
百度旗下云解析服务，依托百度一流基础设施和强大技术实力,为用户提供免费的、超越竞品的服务体验。没有套餐区分,安全,稳定,高效
DNS 服务器 IP 地址：
首选：180.76.76.76
作者点评：240毫秒，果断放弃吧。
# dig @180.76.76.76 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @180.76.76.76 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21286
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 49 IN A 180.149.134.142
www.weibo.com. 49 IN A 180.149.134.141
;; Query time: 235 msec
;; SERVER: 180.76.76.76#53(180.76.76.76)
;; WHEN: Fri May 4 05:12:08 2018
;; MSG SIZE rcvd: 63
CNNIC SDNS：★★★
SDNS是由中国互联网络信息中心(CNNIC)推出的免费解析服务(SecureDNS,简称SDNS)。
DNS 服务器 IP 地址：
首选：1.2.4.8
备选：210.2.4.8
作者点评：作为国家出品的DNS，有待测试……（你敢用吗？反正我不敢）查询速度140毫秒,与腾讯dnspod的119.29.29.29相近，返回内容太多了，注定也慢。
]# dig @1.2.4.8 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @1.2.4.8 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64222
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 6
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 60 IN A 180.149.134.142
www.weibo.com. 60 IN A 180.149.134.141
;; AUTHORITY SECTION:
weibo.com. 77857 IN NS ns4.sina.com.cn.
weibo.com. 77857 IN NS ns2.sina.com.cn.
weibo.com. 77857 IN NS ns1.sina.com.cn.
weibo.com. 77857 IN NS ns4.sina.com.
weibo.com. 77857 IN NS ns3.sina.com.
weibo.com. 77857 IN NS ns3.sina.com.cn.
;; ADDITIONAL SECTION:
ns1.sina.com.cn. 82392 IN A 202.106.184.166
ns2.sina.com.cn. 64615 IN A 61.172.201.254
ns3.sina.com. 172452 IN A 61.172.201.254
ns3.sina.com.cn. 67865 IN A 123.125.29.99
ns4.sina.com. 169253 IN A 123.125.29.99
ns4.sina.com.cn. 55546 IN A 121.14.1.22
;; Query time: 140 msec
;; SERVER: 1.2.4.8#53(1.2.4.8)
;; WHEN: Fri May 4 05:13:04 2018
;; MSG SIZE rcvd: 283
OpenDNS：★★★★
OpenDNS创建于2006年，长期以来致力于为广大个人用户以及商务企业用户和公共领域提供免费的域名解析服务。
DNS 服务器 IP 地址：
首选：208.67.222.222
备选：208.67.220.220
作者点评：美国有节点，有时候140毫秒左右，有时候1毫秒，ping延时1毫秒。
[root@10-11-113-118 ~]# dig @208.67.222.222 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @208.67.222.222 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36208
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 60 IN A 123.125.104.197
;; Query time: 148 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri May 4 05:14:42 2018
;; MSG SIZE rcvd: 47
Google DNS：★★★★★
谷歌公共域名解析服务（Google Public DNS）是由谷歌于2009年发布的一项DNS服务
DNS 服务器 IP 地址：
首选：8.8.8.8
备选：8.8.4.4
作者点评：美国有节点，有时候24毫秒左右，ping延时1毫秒。
# dig @8.8.8.8 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @8.8.8.8 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5151
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 52 IN A 123.125.104.197
;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri May 4 05:17:10 2018
;; MSG SIZE rcvd: 47
Cloudflare：★★★★★
Cloudflare宣布今日正式推出1.1.1.1公共DNS服务，号称任何人都可以使用它可以加快互联网访问速度并并保持连接私密性。Cloudflare声称它将是“互联网上速度最快，隐私优先的消费者DNS服务”，此前类似的免费公共服务OpenDNS与GoogleDNS都已经服役了很长时间。
DNS 服务器 IP 地址：
首选：1.1.1.1
作者点评：美国有节点，解析域名失败，ping延时1毫秒。
# dig @1.1.1.1 www.google.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @1.1.1.1 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
[root@10-11-113-118 ~]# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.350 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.165 ms
^C
— 1.1.1.1 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1978ms
rtt min/avg/max/mdev = 0.165/0.257/0.350/0.093 ms
[root@10-11-113-118 ~]# nslookup www.google.com. 1.1.1.1
;; connection timed out; trying next origin
;; connection timed out; no servers could be reached
美国 科州布鲁姆菲尔德市县Level3公共DNS服务器：★★★★★
美国 科州布鲁姆菲尔德市县Level3公共DNS服务器 DNS 服务器 IP 地址：
首选：1.1.1.1
作者点评：美国有节点，超级快，不到1毫秒，ping延时1毫秒。
# dig @4.2.2.1 www.weibo.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @4.2.2.1 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2782
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.weibo.com. IN A
;; ANSWER SECTION:
www.weibo.com. 16 IN A 123.125.104.197
;; Query time: 0 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Fri May 4 05:26:14 2018
;; MSG SIZE rcvd: 47
最后总结
测试结果受用户地区和DNS提供商的服务器等不同因素影响。建议用户在选择DNS时可以依照本排行，ping不同dns服务商的首选DNS地址，一般是哪个延迟最低用哪个，不同地区我也不好发言。大陆美国飞人推荐DNSPodDNS:119.29.29.29/182.254.116.116，长期美国推荐：4.2.2.1、8.8.8.8、208.67.222.222
sftp服务限制用户登录读写家目录
sftp和ftp是两种协议是不同的,sftp是ssh内含的协议，只要sshd服务器启动了，它就可用，它本身不需要ftp服务器启动。
1.查看openssh软件版本,想sftp服务用户只能访问特定的文件目录,版本需要4.8以上
[root@localhost ftp]# rpm -qa | grep openssh
openssh-server-5.3p1-81.el6_3.x86_64
openssh-5.3p1-81.el6_3.x86_64
openssh-clients-5.3p1-81.el6_3.x86_64
2.新增用户,限制用户只能通过sftp访问
[root@localhost ftp]# useradd -m -d /opt/ftp/dave -s /sbin/nologin dave
3.限制用户通过sftp登录进来时只能进入主目录，修改/etc/ssh/sshd_config文件
[root@localhost ftp]# vim /etc/ssh/sshd_config
#Subsystem sftp /usr/libexec/openssh/sftp-server
Subsystem sftp internal-sftp
Match User dave
ChrootDirectory /opt/ftp/dave
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
重启ssh
systemctl restart sshd.service
4.测试访问
root@10.1.1.200:test# sftp -o Port=22 dave@10.1.6.175 Connecting to 10.1.6.175…
dave@10.1.6.175’s password:
Read from remote host 10.1.6.175: Connection reset by peer
Couldn’t read packet: Connection reset by peer
发现连接不上,查看日志
[root@localhost ftp]# tail /var/log/messages
Jan 6 11:41:41 localhost sshd[4907]: fatal: bad ownership or modes for chroot directory “/opt/ftp/dave” Jan 6 11:41:41 localhost sshd[4905]: pam_unix(sshd:session): session closed for user dave
解决方法:
目录权限设置上要遵循2点：
ChrootDirectory设置的目录权限及其所有的上级文件夹权限，属主和属组必须是root；
ChrootDirectory设置的目录权限及其所有的上级文件夹权限，只有属主能拥有写权限，权限最大设置只能是755。
如果不能遵循以上2点，即使是该目录仅属于某个用户，也可能会影响到所有的SFTP用户。
[root@localhost ftp]# ll
total 4 drwxr-xr-x 3 dave dave 4096 Jan 5 13:06 dave
[root@localhost ftp]# chown root:root dave
[root@localhost ftp]# chmod 755 dave
[root@localhost ftp]# ll total 4 drwxr-xr-x 3 root root 4096 Jan 5 13:06 dave
然后在测试通过
root@10.1.1.200:test# sftp -oPort=22 dave@10.1.6.175 Connecting to 10.1.6.175…
dave@10.1.6.175’s password:
sftp> ls
test
sftp> cd ..
sftp> ls
test
sftp> cd test
sftp> ls 1.txt
sftp> get 1.txt
Fetching /test/1.txt to 1.txt
/test/1.txt
可以看到已经限制用户在家目录,同时该用户也不能登录该机器。
hls之m3u8、ts流格式详解
HLS，Http Live Streaming 是由Apple公司定义的用于实时流传输的协议，HLS基于HTTP协议实现，传输内容包括两部分，一是M3U8描述文件，二是TS媒体文件。
1、M3U8文件
用文本方式对媒体文件进行描述，由一系列标签组成。
#EXTM3U
#EXT-X-TARGETDURATION:5
#EXTINF:5,
./0.ts
#EXTINF:5,
./1.ts
#EXTM3U：每个M3U8文件第一行必须是这个tag。
#EXT-X-TARGETDURATION：指定最大的媒体段时间长度（秒），#EXTINF中指定的时间长度必须小于或等于这个最大值。该值只能出现一次。
#EXTINF：描述单个媒体文件的长度。后面为媒体文件，如./0.ts
2、ts文件
ts文件为传输流文件，视频编码主要格式h264/mpeg4，音频为acc/MP3。
ts文件分为三层：ts层Transport Stream、pes层 Packet Elemental Stream、es层 Elementary Stream. es层就是音视频数据，pes层是在音视频数据上加了时间戳等对数据帧的说明信息，ts层就是在pes层加入数据流的识别和传输必须的信息
注： 详解如下
（1）ts层 ts包大小固定为188字节，ts层分为三个部分：ts header、adaptation field、payload。ts header固定4个字节；adaptation field可能存在也可能不存在，主要作用是给不足188字节的数据做填充；payload是pes数据。
ts header
| sync_byte | 8b | 同步字节，固定为0x47 |
| transport_error_indicator | 1b | 传输错误指示符，表明在ts头的adapt域后由一个无用字节，通常都为0，这个字节算在adapt域长度内 |
| payload_unit_start_indicator | 1b | 负载单元起始标示符，一个完整的数据包开始时标记为1 |
| transport_priority | 1b | 传输优先级，0为低优先级，1为高优先级，通常取0 |
| pid | 13b | pid值 |
| transport_scrambling_control | 2b | 传输加扰控制，00表示未加密 |
| adaptation_field_control | 2b | 是否包含自适应区，‘00’保留；‘01’为无自适应域，仅含有效负载；‘10’为仅含自适应域，无有效负载；‘11’为同时带有自适应域和有效负载。 |
| continuity_counter | 4b | 递增计数器，从0-f，起始值不一定取0，但必须是连续的 |
ts层的内容是通过PID值来标识的，主要内容包括：PAT表、PMT表、音频流、视频流。解析ts流要先找到PAT表，只要找到PAT就可以找到PMT，然后就可以找到音视频流了。PAT表的PID值固定为0。PAT表和PMT表需要定期插入ts流，因为用户随时可能加入ts流，这个间隔比较小，通常每隔几个视频帧就要加入PAT和PMT。PAT和PMT表是必须的，还可以加入其它表如SDT（业务描述表）等，不过hls流只要有PAT和PMT就可以播放了。
-
PAT表：他主要的作用就是指明了PMT表的PID值。
-
PMT表：他主要的作用就是指明了音视频流的PID值。
-
音频流/视频流：承载音视频内容。
adaption
| adaptation_field_length | 1B | 自适应域长度，后面的字节数 |
| flag | 1B | 取0x50表示包含PCR或0x40表示不包含PCR |
| PCR | 5B | Program Clock Reference，节目时钟参考，用于恢复出与编码端一致的系统时序时钟STC（System Time Clock）。 |
| stuffing_bytes | xB | 填充字节，取值0xff |
自适应区的长度要包含传输错误指示符标识的一个字节。pcr是节目时钟参考，pcr、dts、pts都是对同一个系统时钟的采样值，pcr是递增的，因此可以将其设置为dts值，音频数据不需要pcr。如果没有字段，ipad是可以播放的，但vlc无法播放。打包ts流时PAT和PMT表是没有adaptation field的，不够的长度直接补0xff即可。视频流和音频流都需要加adaptation field，通常加在一个帧的第一个ts包和最后一个ts包里，中间的ts包不加。
PAT格式
| table_id | 8b | PAT表固定为0x00 |
| section_syntax_indicator | 1b | 固定为1 |
| zero | 1b | 固定为0 |
| reserved | 2b | 固定为11 |
| section_length | 12b | 后面数据的长度 |
| transport_stream_id | 16b | 传输流ID，固定为0x0001 |
| reserved | 2b | 固定为11 |
| version_number | 5b | 版本号，固定为00000，如果PAT有变化则版本号加1 |
| current_next_indicator | 1b | 固定为1，表示这个PAT表可以用，如果为0则要等待下一个PAT表 |
| section_number | 8b | 固定为0x00 |
| last_section_number | 8b | 固定为0x00 |
| 开始循环 | ||
| program_number | 16b | 节目号为0x0000时表示这是NIT，节目号为0x0001时,表示这是PMT |
| reserved | 3b | 固定为111 |
| PID | 13b | 节目号对应内容的PID值 |
| 结束循环 | ||
| CRC32 | 32b | 前面数据的CRC32校验码 |
PMT格式
| table_id | 8b | PMT表取值随意，0x02 |
| section_syntax_indicator | 1b | 固定为1 |
| zero | 1b | 固定为0 |
| reserved | 2b | 固定为11 |
| section_length | 12b | 后面数据的长度 |
| program_number | 16b | 频道号码，表示当前的PMT关联到的频道，取值0x0001 |
| reserved | 2b | 固定为11 |
| version_number | 5b | 版本号，固定为00000，如果PAT有变化则版本号加1 |
| current_next_indicator | 1b | 固定为1 |
| section_number | 8b | 固定为0x00 |
| last_section_number | 8b | 固定为0x00 |
| reserved | 3b | 固定为111 |
| PCR_PID | 13b | PCR(节目参考时钟)所在TS分组的PID，指定为视频PID |
| reserved | 4b | 固定为1111 |
| program_info_length | 12b | 节目描述信息，指定为0x000表示没有 |
| 开始循环 | ||
| stream_type | 8b | 流类型，标志是Video还是Audio还是其他数据，h.264编码对应0x1b，aac编码对应0x0f，mp3编码对应0x03 |
| reserved | 3b | 固定为111 |
| elementary_PID | 13b | 与stream_type对应的PID |
| reserved | 4b | 固定为1111 |
| ES_info_length | 12b | 描述信息，指定为0x000表示没有 |
| 结束循环 | ||
| CRC32 | 32b | 前面数据的CRC32校验码 |
（2）pes层
pes层是在每一个视频/音频帧上加入了时间戳等信息，pes包内容很多，我们只留下最常用的。
| pes start code | 3B | 开始码，固定为0x000001 |
| stream id | 1B |
音频取值（0xc0-0xdf），通常为0xc0 视频取值（0xe0-0xef），通常为0xe0 |
| pes packet length | 2B |
后面pes数据的长度，0表示长度不限制， 只有视频数据长度会超过0xffff |
| flag | 1B | 通常取值0x80，表示数据不加密、无优先级、备份的数据 |
| flag | 1B | 取值0x80表示只含有pts，取值0xc0表示含有pts和dts |
| pes data length | 1B | 后面数据的长度，取值5或10 |
| pts | 5B | 33bit值 |
| dts | 5B | 33bit值 |
pts是显示时间戳、dts是解码时间戳，视频数据两种时间戳都需要，音频数据的pts和dts相同，所以只需要pts。有pts和dts两种时间戳是B帧引起的，I帧和P帧的pts等于dts。如果一个视频没有B帧，则pts永远和dts相同。从文件中顺序读取视频帧，取出的帧顺序和dts顺序相同。dts算法比较简单，初始值 + 增量即可，pts计算比较复杂，需要在dts的基础上加偏移量。
音频的pes中只有pts（同dts），视频的I、P帧两种时间戳都要有，视频B帧只要pts（同dts）。打包pts和dts就需要知道视频帧类型，但是通过容器格式我们是无法判断帧类型的，必须解析h.264内容才可以获取帧类型。
举例说明：
I P B B B P
读取顺序： 1 2 3 4 5 6
dts顺序： 1 2 3 4 5 6
pts顺序： 1 5 3 2 4 6
点播视频dts算法：
dts = 初始值 + 90000 / video_frame_rate，初始值可以随便指定，但是最好不要取0，video_frame_rate就是帧率，比如23、30。
pts和dts是以timescale为单位的，1s = 90000 time scale , 一帧就应该是90000/video_frame_rate 个timescale。
用一帧的timescale除以采样频率就可以转换为一帧的播放时长
点播音频dts算法：
dts = 初始值 + (90000 * audio_samples_per_frame) / audio_sample_rate，audio_samples_per_frame这个值与编解码相关，aac取值1024，mp3取值1158，audio_sample_rate是采样率，比如24000、41000。AAC一帧解码出来是每声道1024个sample，也就是说一帧的时长为1024/sample_rate秒。所以每一帧时间戳依次0，1024/sample_rate，…，1024*n/sample_rate秒。
直播视频的dts和pts应该直接用直播数据流中的时间，不应该按公式计算。
（3）es层
es层指的就是音视频数据，我们只介绍h.264视频和aac音频。
h.264视频：
打包h.264数据我们必须给视频数据加上一个nalu（Network Abstraction Layer unit），nalu包括nalu header和nalu type，nalu header固定为0x00000001（帧开始）或0x000001（帧中）。h.264的数据是由slice组成的，slice的内容包括：视频、sps、pps等。nalu type决定了后面的h.264数据内容。
| F | 1b | forbidden_zero_bit，h.264规定必须取0 |
| NRI | 2b | nal_ref_idc，取值0~3，指示这个nalu的重要性，I帧、sps、pps通常取3，P帧通常取2，B帧通常取0 |
| Type | 5b | 参考下表 |
| nal_unit_type | 说明 |
| 0 | 未使用 |
| 1 | 非IDR图像片，IDR指关键帧 |
| 2 | 片分区A |
| 3 | 片分区B |
| 4 | 片分区C |
| 5 | IDR图像片，即关键帧 |
| 6 | 补充增强信息单元(SEI) |
| 7 | SPS序列参数集 |
| 8 | PPS图像参数集 |
| 9 | 分解符 |
| 10 | 序列结束 |
| 11 | 码流结束 |
| 12 | 填充 |
| 13~23 | 保留 |
| 24~31 | 未使用 |
红色字体显示的内容是最常用的，打包es层数据时pes头和es数据之间要加入一个type=9的nalu，关键帧slice前必须要加入type=7和type=8的nalu，而且是紧邻。
转自：http://my.oschina.NET/u/727148/blog/666824
M3U8的简单介绍和在Android中使用的思路
(在项目中有用到m3u8，现在写篇博文，算是简单的总结
首先是名词介绍，什么是m3u8。m3u8是m3u的一种，不过是utf-8格式的，我记忆中说m3u8是苹果公司搞出来的一种播放的标准吧，其实简单来说就是把整个视频切成一段一段的，然后呢用一个m3u8格式来存这些个小段视频们的地址。可能大家就要问了，这么麻烦干嘛。其实m3u8是为了码率适配而生，而怎样去适配码率呢，这个下面介绍格式的时候会介绍到。
上两个m3u8文件的例子地址，大家能有直观的认识，这是我从Vitamio的官网上扒的。
http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8
http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8
我总结了一下我遇到的m3u8格式，虽然不能说涵盖了全部的情况，但是也差不多了：
1、一级目录（我觉着一级的目录没有适配码率的功能）
1.1、打开第一级m3u8文件，能找到真正的视频地址
1.2、第一级m3u8文件中，没有真正的视频地址，需要拼接才能找到真正的视频地址
2、二级目录
2.1、二级地址在一级文件中直接能看到
2.2、二级地址在一级文件中不能直接看到，需要拼接一级链接的地址才能找到二级文件的地址
2.2、打开二级目录，能找到整整的视频地址
2.3、没有真正的视频地址，需要拼接才能找到真正的视频地址
篇幅关系我不能给大家全部列举出这些全部的可能性。我就拿最麻烦的举个例子，其他的大家自行脑补吧，原理都是一样的，怎么样都跑不出协议的范畴之外。
我们在浏览器中输入http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8，会得到一个名为bipbopall.m3u8的文件，此文件的内容如下：
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000
gear1/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=311111
gear2/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=484444
gear3/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=737777
gear4/prog_index.m3u8
这就符合上面的2.2种情况，这四种码率的m3u8的地址你都不能直接得到，那怎么办呢，我们用得到这个文件的链接地址的前半段http://devimages.apple.com/iphone/samples/bipbop/拼接上二级文件的相对地址gear1/prog_index.m3u8得到一个地址http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8。
把此地址放到浏览器中，我们又会得到一个同样名为prog_index.m3u8的文件，内容如下：
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10, no desc
fileSequence0.ts
#EXTINF:10, no desc
fileSequence1.ts
#EXTINF:10, no desc
fileSequence2.ts
#EXTINF:10, no desc
fileSequence3.ts
#EXTINF:10, no desc
fileSequence4.ts
#EXTINF:10, no desc
fileSequence5.ts
#EXTINF:10, no desc
.
.
.
#EXTINF:10, no desc
fileSequence179.ts
#EXTINF:1, no desc
fileSequence180.ts
#EXT-X-ENDLIST
我们很开心的发现，这设计简直是巧(sang)夺(xin)天(bing)工(kuang)，我们还是没有得到真正的视频地址，老办法拼接后我们得到这么一段链http://devimages.apple.com/iphone/samples/bipbop/gear1/fileSequence179.ts，这就是真正的视频地址。
我举的这个例子是最复杂的情况，一般的情况对于这个来说都是相对简单的。就跟软件设计一样，我们先考虑到最难得情况，简单的来说就迎刃而解了
此篇博文没有具体介绍m3u8的格式，各位看管不了解的话还请自行Google之。
此篇博文完全是作者的经验之谈，可能有不确切的地方还请见谅，转载请贴原文地址。
HLS协议直播延时优化(35s到10S)
1、首先要了解HLS延时的机制，也就是为什么会延时，延时主要发生在什么地方。
HTTP Live Streaming 并不是一个真正实时的流媒体系统，这是因为对应于媒体分段的大小和持续时间有一定潜在的时间延时。在客户端，至少在一个分段媒体文件被完全下载后才能够开始播放，而通常要求下载完两个媒体文件之后才开始播放以保证不同分段音视频之间的无缝连接。此外，在客户端开始下载之前，必须等待服务器端的编码器和流分割器至少生成一个TS文件，这也会带来潜在的时延。服务器软件将接收到的流每缓存一定时间后包装为一个新的TS文件，然后更新m3u8文件。m3u8文件中只保留最新的几个片段的索引，以保证观众任何时候连接进来都会看到较新的内容，实现近似直播的效果。这种方式的理论最小延时为一个ts文件的时长，一般为2-3个ts文件的时长。
所以，hls的延时主要由以下三个部分组成：
（1）服务器端的编码器和流分割器生成TS文件的时间
（2）客户端下载TS文件的时间，而通常要求下载完两个TS媒体文件
（3）客户端解码并播放时间
这三个方面里面，前两个方面我们是可以控制调节的，对于第三个方面只能取决于客户端的性能。
2、具体优化方法
由于服务器端生成TS流段需要时间，那么我们可以调节每段TS文件的大小，让其小些，那么服务器生成它的速度就加快，时间缩短。这样一来，客户端下载第一段或者前两段的时间就会减少，延时就会降低。根据上述的方式可以更改HLS的分段大小，方法是修改nginx配置文件nginx.conf，默认情况下nginx.conf文件的hls配置部分如下：
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on;
}
hls on;
hls_path /tmp/hls;
}
}
文件并没有设置HLS 分段长度，添加设置：
hls_fragment 1s;
将每段的长度限定为1s，HLS官方推荐的是10s，但是在我这里10s延时太大。但是段的时长越短，服务器的负载越大，延时越少。对于这句话我不是十分理解，至少我并没有发现服务器负载增加。当每段的长度固定之后，播放列表的长度也会影响延时时间，而且会对再次播放时的开始时间产生影响，非首次播放时，客户端会在播放列表的开头开始播放，所以总的延时时间等于播放列表长度加上上述的延时时间。所以将播放列表长度不要设置太大：
hls_playlist_length 3s;
这样设置完之后的配置文件RTMP模块配置部分为：
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on;
}
hls on;
hls_path /tmp/hls;
hls_fragment 1s;
hls_playlist_length 3s;
}
}
配置完成后重新启动nginx，重新使用ffmpeg推流，结果延时时间降到7～8s。
优化前测试结果：26S
优化后VLC播放测试结果：11s
贵在坚持,相信自己.
安防摄像头海康、大华IpCamera RTSP地址和格式
海康：
rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream
说明：
- username: 用户名。例如admin。
- password: 密码。例如12345。
- ip: 为设备IP。例如 192.0.0.64。
- port: 端口号默认为554，若为默认可不填写。
- codec：有h264、MPEG-4、mpeg4这几种。
- channel: 通道号，起始为1。例如通道1，则为ch1。
- subtype: 码流类型，主码流为main，辅码流为sub。
例如，请求海康摄像机通道1的主码流，Url如下
主码流：
rtsp://admin:12345@192.0.0.64:554/h264/ch1/main/av_stream rtsp://admin:12345@192.0.0.64:554/MPEG-4/ch1/main/av_stream
子码流：
rtsp://admin:12345@192.0.0.64/mpeg4/ch1/sub/av_stream rtsp://admin:12345@192.0.0.64/h264/ch1/sub/av_stream
大华：
rtsp://username:password@ip:port/cam/realmonitor?channel=1&subtype=0
说明:
- username: 用户名。例如admin。
- password: 密码。例如admin。
- ip: 为设备IP。例如 10.7.8.122。
- port: 端口号默认为554，若为默认可不填写。
- channel: 通道号，起始为1。例如通道2，则为channel=2。
- subtype: 码流类型，主码流为0（即subtype=0），辅码流为1（即subtype=1）。
例如，请求某设备的通道2的辅码流，Url如下
rtsp://admin:admin@10.12.4.84:554/cam/realmonitor?channel=2&subtype=1
直播视频码流、码率、采样率、比特率、帧速率、分辨率、高清视频的概念
高清视频主要编码
480P格式：720×480
720P格式：1280×720 【表现体育节目、快速运动的视频时，720P更明显】
1080P格式：1920×1080 【适合普通电视节目、电影等慢速运动的视频时，1080P更明显】
1、码流（码率）
码流(Data Rate)是指视频文件在单位时间内使用的数据流量，也叫码率或码流率，通俗一点的理解就是取样率,是视频编码中画面质量控制中最重要的部分，一般我们用的单位是kb/s或者Mb/s。一般来说同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。码流越大，说明单位时间内取样率越大，数据流，精度就越高，处理出来的文件就越接近原始文件，图像质量越好，画质越清晰，要求播放设备的解码能力也越高。
当然，码流越大，文件体积也越大，其计算公式是文件体积=时间X码率/8。例如，网络上常见的一部90分钟1Mbps码流的720P RMVB文件，其体积就=5400秒×1Mb/8=675MB。
通常来说，一个视频文件包括了画面及声音，例如一个RMVB的视频文件，里面包含了视频信息和音频信息，音频及视频都有各自不同的采样方式和比特率，也就是说，同一个视频文件音频和视频的比特率并不是一样的。而我们所说的一个视频文件码流率大小，一般是指视频文件中音频及视频信息码流率的总和。
以以国内最流行，大家最熟悉的RMVB视频文件为例，RMVB中的VB，指的是VBR，即Variable Bit Rate的缩写，中文含义是可变比特率，它表示RMVB采用的是动态编码的方式，把较高的采样率用于复杂的动态画面(歌舞、飞车、战争、动作等)，而把较低的采样率用于静态画面，合理利用资源，达到画质与体积可兼得的效果。
码率和取样率最根本的差别就是码率是针对源文件来讲的。
2、采样率
采样率（也称为采样速度或者采样频率）定义了每秒从连续信号中提取并组成离散信号的采样个数，它用赫兹（Hz）来表示。采样率是指将模拟信号转换成数字信号时的采样频率，也就是单位时间内采样多少点。一个采样点数据有多少个比特。比特率是指每秒传送的比特(bit)数。单位为 bps(Bit Per Second)，比特率越高，传送的数据越大，音质越好.比特率 =采样率 x 采用位数 x声道数.
采样率类似于动态影像的帧数，比如电影的采样率是24赫兹，PAL制式的采样率是25赫兹，NTSC制式的采样率是30赫兹。当我们把采样到的一个个静止画面再以采样率同样的速度回放时，看到的就是连续的画面。同样的道理，把以44.1kHZ采样率记录的CD以同样的速率播放时，就能听到连续的声音。显然，这个采样率越高，听到的声音和看到的图像就越连贯。当然，人的听觉和视觉器官能分辨的采样率是有限的，基本上高于44.1kHZ采样的声音，绝大部分人已经觉察不到其中的分别了。
而声音的位数就相当于画面的颜色数，表示每个取样的数据量，当然数据量越大，回放的声音越准确，不至于把开水壶的叫声和火车的鸣笛混淆。同样的道理，对于画面来说就是更清晰和准确，不至于把血和西红柿酱混淆。不过受人的器官的机能限制，16位的声音和24位的画面基本已经是普通人类的极限了，更高位数就只能靠仪器才能分辨出来了。比如电话就是3kHZ取样的7位声音，而CD是44.1kHZ取样的16位声音，所以CD就比电话更清楚。
当你理解了以上这两个概念，比特率就很容易理解了。以电话为例，每秒3000次取样，每个取样是7比特，那么电话的比特率是21000。 而CD是每秒 44100次取样，两个声道，每个取样是13位PCM编码，所以CD的比特率是44100*2*13=1146600，也就是说CD每秒的数据量大约是 144KB，而一张CD的容量是74分等于4440秒，就是639360KB＝640MB。
码率和取样率最根本的差别就是码率是针对源文件来讲的。
3、比特率
比特率是指每秒传送的比特(bit)数。单位为bps(Bit Per Second)，比特率越高，传送的数据越大。在视频领域,比特率常翻译为码率 !!!
比特率表示经过编码（压缩）后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；如果比特率越少则情况刚好相反。
比特率是指将数字声音、视频由模拟格式转化成数字格式的采样率，采样率越高，还原后的音质、画质就越好。
4、常见编码模式：
VBR（Variable Bitrate）动态比特率 也就是没有固定的比特率，压缩软件在压缩时根据音频数据即时确定使用什么比特率，这是以质量为前提兼顾文件大小的方式，推荐编码模式；
ABR（Average Bitrate）平均比特率 是VBR的一种插值参数。LAME针对CBR不佳的文件体积比和VBR生成文件大小不定的特点独创了这种编码模式。ABR在指定的文件大小内，以每50帧（30帧约1秒）为一段，低频和不敏感频率使用相对低的流量，高频和大动态表现时使用高流量，可以做为VBR和CBR的一种折衷选择。
CBR（Constant Bitrate），常数比特率 指文件从头到尾都是一种位速率。相对于VBR和ABR来讲，它压缩出来的文件体积很大，而且音质相对于VBR和ABR不会有明显的提高。
5、帧速率
帧速率也称为FPS(Frames PerSecond)的缩写——帧/秒。
是指每秒钟刷新的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次。越高的帧速率可以得到更流畅、更逼真的动画。每秒钟帧数(FPS)越多，所显示的动作就会越流畅。（PS：英雄联盟中的，Ping值越低越好，FPS值越高越好，O(∩_∩)O哈哈~）
影响FPS值的主要因素就是显卡，一款好的独立显卡会对FPS的提升有着很大的作用。如果FPS值过低可以尝试通过调节一些游戏或者电脑参数来缓解如：降低游戏分辨率、开启垂直同步等等
6、分辨率
就是帧大小每一帧就是一副图像。
640*480分辨率的视频，建议视频的码速率设置在700以上，音频采样率44100就行了
一个音频编码率为128Kbps，视频编码率为800Kbps的文件，其总编码率为928Kbps，意思是经过编码后的数据每秒钟需要用928K比特来表示。
计算输出文件大小公式：（音频编码率（KBit为单位）/8 +视频编码率（KBit为单位）/8）×影片总长度（秒为单位）=文件大小（MB为单位）
7、高清视频
目前的720P以及1080P采用了很多种编码，例如主流的MPEG2，VC-1以及H.264，还有Divx以及Xvid，至于封装格式更多到令人发指，ts、mkv、wmv以及蓝光专用等等。
720和1080代表视频流的分辨率，前者1280*720，后者1920*1080，不同的编码需要不同的系统资源，大概可以认为是H.264>VC-1>MPEG2。
VC-1是最后被认可的高清编码格式，不过因为有微软的后台，所以这种编码格式不能小窥。相对于MPEG2，VC-1的压缩比更高，但相对于H.264而言，编码解码的计算则要稍小一些，目前来看，VC-1可能是一个比较好的平衡，辅以微软的支持，应该是一只不可忽视的力量。一般来说，VC-1多为 “.wmv”后缀，但这都不是绝对的，具体的编码格式还是要通过软件来查询。
总的来说，从压缩比上来看，H.264的压缩比率更高一些，也就是同样的视频，通过H.264编码算法压出来的视频容量要比VC-1的更小，但是VC-1 格式的视频在解码计算方面则更小一些，一般通过高性能的CPU就可以很流畅的观看高清视频。相信这也是目前NVIDIA Geforce 8系列显卡不能完全解码VC-1视频的主要原因。
PS&TS是两种视频或影片封装格式，常用于高清片。扩展名分别为VOB/EVO和TS等；其文件编码一般用MPEG2/VC-1/H.264
高清，英文为“High Definition”，即指“高分辨率”。 高清电视(HDTV)，是由美国电影电视工程师协会确定的高清晰度电视标准格式。现在的大屏幕液晶电视机，一般都支持1080i和720P，而一些俗称的“全高清”(Full HD)，则是指支持1080P输出的电视机。
目前的高清视频编码格式主要有H.264、VC-1、MPEG-2、MPEG-4、DivX、XviD、WMA-HD以及X264。事实上，现在网络上流传的高清视频主要以两类文件的方式存在：一类是经过MPEG-2标准压缩，以tp和ts为后缀的视频流文件;一类是经过WMV-HD(Windows Media Video HighDefinition)标准压缩过的wmv文件，还有少数文件后缀为avi或mpg，其性质与wmv是一样的。真正效果好的高清视频更多地以H.264与VC-1这两种主流的编码格式流传。
一般来说，H.264格式以“.avi”、“.mkv”以及“.ts”封装比较常见。
Linux升级最新OpenSSH,Dropbear临时替换SSH
OpenSSH是一款开源的安全远程控制工具，也是Linux系统中最常用的服务之一，近年来频繁爆出高危漏洞，深受各大企业关注。掌握升级OpenSSH或许是每位运维人员必经的成长阶段，今天给大家分享一下从系统默认OpenSSH
5.3p1升级至最新版本OpenSSH 7.6p1的方法，希望能帮助刚入门的Linux运维朋友们。https://matt.ucc.asn.au/dropbear/dropbear.html
| 实验环境 |
实验平台：VMware虚拟机
操作系统：CentOS 6.5
旧版OpenSSH：5.3p1
旧版OpenSSL：1.0.1e
新版OpenSSH：7.6p1
新版OpenSSL：1.0.2n
Dropbear：2017.75
| 服务端篇 |
第一步 准备工作
禁用SElinux
- [root@Wanghualang ~]# setenforce 0
- [root@Wanghualang ~]# sed -ri ‘s#^(SELINUX=).*#\1disabled#g’ /etc/selinux/config
禁用防火墙
- [root@Wanghualang ~]# service iptables stop
- [root@Wanghualang ~]# service ip6tables stop
- [root@Wanghualang ~]# chkconfig iptables off
- [root@Wanghualang ~]# chkconfig ip6tables off
安装常用软件
- [root@Wanghualang ~]# yum -y install wget vim
第二步 安装远程工具
建议先临时使用其他远程工具，以防升级Openssh失败导致无法远程服务器。一般情况下，可以临时启动Telnet，若企业严禁使用Telnet，则可以Dropbear替代，两种远程工具二选一即可。
安装Telnet
- [root@Wanghualang ~]# yum -y install telnet-server
设置允许root用户登录
- [root@Wanghualang ~]# mv /etc/securetty /etc/securetty.bak
修改配置文件，把默认的disable=yes，修改为disable=no
- [root@Wanghualang ~]# vim /etc/xinetd.d/telnet
启动Telnet
- [root@Wanghualang ~]# service xinetd start
安装Dropbear
- [root@Wanghualang ~]# yum -y install gcc zlib-devel
- [root@Wanghualang ~]# cd /usr/local/src/
- [root@Wanghualang src]# wget –no-check-certificate https://dropbear.nl/mirror/dropbear-2017.75.tar.bz2
- [root@Wanghualang src]# tar xjf dropbear-2017.75.tar.bz2
- [root@Wanghualang src]# cd dropbear-2017.75
- [root@Wanghualang dropbear-2017.75]# ./configure
- [root@Wanghualang dropbear-2017.75]# make
- [root@Wanghualang dropbear-2017.75]# make install
生成证书
- [root@Wanghualang ~]# mkdir /etc/dropbear
- [root@Wanghualang ~]# /usr/local/bin/dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key
- [root@Wanghualang ~]# /usr/local/bin/dropbearkey -t rsa -s 4096 -f /etc/dropbear/dropbear_rsa_host_key
启动Dropbear，监听16888端口，使用Telnet或者Dropbear远程登录到服务器后，接下来正式开始升级Openssh。
- [root@Wanghualang ~]# /usr/local/sbin/dropbear -p 16888
第三步 备份旧程序
备份Openssh、库文件
- [root@Wanghualang ~]# service sshd stop
- [root@Wanghualang ~]# rpm -ql `rpm -qa |egrep openss[hl]` > Wanghualang.txt
- [root@Wanghualang ~]# tar czf OpensshBak.tar.gz -T Wanghualang.txt
- [root@Wanghualang ~]# tar czf LibBak.tar.gz /lib /lib64
第四步 卸载旧程序
在卸载OpenSSL后，Yum、Wget等等命令将无法正常使用，所以卸载之前，建议把相关开发包、源码包提前准备好。
- [root@Wanghualang ~]# yum -y install gcc zlib-devel pam-devel
- [root@Wanghualang ~]# cd /usr/local/src/
- [root@Wanghualang src]# wget –no-check-certificate https://openbsd.hk/pub/OpenBSD/OpenSSH/portable/openssh-7.6p1.tar.gz
- [root@Wanghualang src]# wget –no-check-certificate https://www.openssl.org/source/openssl-1.0.2n.tar.gz
卸载OpenSSL、Openssh
- [root@Wanghualang ~]# rpm -e `rpm -qa | grep openssl` –nodeps –allmatches
- [root@Wanghualang ~]# rpm -e `rpm -qa | grep openssh` –nodeps –allmatches
第五步 安装新程序
安装OpenSSL
- [root@Wanghualang ~]# cd /usr/local/src/
- [root@Wanghualang src]# tar xzf openssl-1.0.2n.tar.gz
- [root@Wanghualang src]# cd openssl-1.0.2n
- [root@Wanghualang openssl-1.0.2n]# ./config -fPIC –prefix=/usr enable-shared
- [root@Wanghualang openssl-1.0.2n]# make
- [root@Wanghualang openssl-1.0.2n]# make install
查看OpenSSL版本
- [root@Wanghualang ~]# openssl version -a
建立软链接，Yum、Wget等命令便可正常使用。
- [root@Wanghualang ~]# ln -s /usr/lib64/libssl.so.1.0.0 /usr/lib64/libssl.so.10
- [root@Wanghualang ~]# ln -s /usr/lib64/libcrypto.so.1.0.0 /usr/lib64/libcrypto.so.10
安装OpenSSH
- [root@Wanghualang ~]# cd /usr/local/src/
- [root@Wanghualang src]# tar xzf openssh-7.6p1.tar.gz
- [root@Wanghualang src]# cd openssh-7.6p1
- [root@Wanghualang openssh-7.6p1]# ./configure –prefix=/usr –sysconfdir=/etc/ssh –with-pam –with-zlib –with-md5-passwords
- [root@Wanghualang openssh-7.6p1]# make
- [root@Wanghualang openssh-7.6p1]# make install
查看OpenSSH版本
- [root@Wanghualang ~]# ssh -V
- OpenSSH_7.6p1, OpenSSL 1.0.2n 7 Dec 2017
设置开机启动
- [root@Wanghualang ~]# cp -rf /usr/local/src/openssh-7.6p1/contrib/redhat/sshd.init /etc/init.d/sshd
- [root@Wanghualang ~]# chmod +x /etc/init.d/sshd
- [root@Wanghualang ~]# chkconfig –add sshd
启动OpenSSH
默认情况下，新版的OpenSSH禁止使用root用户登录，为方便测试，现解除这个限制。
- [root@Wanghualang ~]# sed -i ‘s/#PermitRootLogin prohibit-password/PermitRootLogin yes/’ /etc/ssh/sshd_config
- [root@Wanghualang ~]# service sshd start
第六步 卸载其他远程工具
确认新版OpenSSH正常使用后，可以考虑卸载Telnet、Dropbear。
卸载Telnet
- [root@Wanghualang ~]# yum -y remove telnet-server
卸载Dropbear
查询进程号
- [root@Wanghualang ~]# ps aux | grep dropbear
结束进程
- [root@Wanghualang ~]# kill -9 进程号
删除程序
-
[root@Wanghualang ~]# find / -name dropbear* | xargs rm -rf
1.1.1.1开放DNS好不好用？
1.1.1.1开放DNS好不好用？用服务器测试，电信联通ping延时100以上延时，域名解析300多毫秒，海外测试延时都50毫秒，明显适合海外使用的DNS，不适合国内使用的开发DNS。
1）服务器测试一下，用ucloud服务器测试执行，v.qq.com访问海外服务器了。
# time dig @1.1.1.1 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> @1.1.1.1 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46940
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 600 IN CNAME v.qq.com.edgekey.net.
v.qq.com.edgekey.net. 1361 IN CNAME e5956.f.akamaiedge.net.
e5956.f.akamaiedge.net. 17 IN A 104.65.9.248
;; Query time: 387 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Apr 3 16:44:35 2018
;; MSG SIZE rcvd: 109
real 0m0.392s
user 0m0.001s
sys 0m0.005s
2）汕头电信服务器测试
time dig @1.1.1.1 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @1.1.1.1 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56452
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 600 IN CNAME v.qq.com.edgekey.net.
v.qq.com.edgekey.net. 1403 IN CNAME e5956.f.akamaiedge.net.
e5956.f.akamaiedge.net. 14 IN A 104.65.9.248
;; Query time: 388 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Apr 3 16:43:53 2018
;; MSG SIZE rcvd: 109
real 0m0.397s
user 0m0.005s
sys 0m0.004s