首页 文章 精选 留言 我的

精选列表

搜索[密码管理],共10021篇文章
优秀的个人博客,低调大师

openstack创建实例无密码登录详解

[root@openstack ~]# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 86:ce:45:80:43:27:97:8c:4d:2d:1b:7b:4c:54:0c:a2 root@openstack The key's randomart image is: +--[ RSA 2048]----+ | .o**+o+. | | +=*oo . | | E. B. | | ooo | | ..S | | o o | | o | | | | | +-----------------+ [root@openstack ~]# nova keypair-list +------+-------------+ | Name | Fingerprint | +------+-------------+ +------+-------------+ [root@openstack ~]# cd .ssh/ [root@openstack .ssh]# ll total 12 -rw------- 1 root root 1675 Feb 28 11:06 id_rsa -rw-r--r-- 1 root root 396 Feb 28 11:06 id_rsa.pub -rw-r--r-- 1 root root 393 Feb 27 09:34 known_hosts [root@openstack .ssh]# nova keypair-add --pub_key id_rsa.pub mykey [root@openstack .ssh]# nova keypair-list +-------+-------------------------------------------------+ | Name | Fingerprint | +-------+-------------------------------------------------+ | mykey | 86:ce:45:80:43:27:97:8c:4d:2d:1b:7b:4c:54:0c:a2 | +-------+-------------------------------------------------+ [root@openstack .ssh]# nova boot --flavor 2 --key_name mykey ^Cimage centos6.4-x86_64 centos4 创建完成后即可登录 [root@openstack .ssh]# ssh root@10.1.1.8 The authenticity of host '10.1.1.8 (10.1.1.8)' can't be established. RSA key fingerprint is 42:e2:8e:55:2a:b7:8f:8f:39:60:db:31:b3:c7:80:cc. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.1.1.8' (RSA) to the list of known hosts. Please login as the user "cloud-user" rather than the user "root". [root@openstack .ssh]# ssh cloud-user@10.1.1.8 [cloud-user@centos4 ~]$

优秀的个人博客,低调大师

解锁tRPC高性能密码:网络方案简介!

导语 | 本文介绍了部分高性能网络方案,包括RDMA、HARP、io_uring等。从技术原理、落地可行性等方面,简要地做出分析,希望能对此方面感兴趣的开发者提供一些经验和帮助。 一、背景 业务中经常会有这样的场景: 随着网卡速率的提升(10G/25G/100G),以及部分业务对低延迟的极致追求(1ms/50us),目前的内核协议栈由于协议复杂、流程复杂、设计陈旧等因素,已经逐渐成为业务瓶颈。 业界已经有部分RDMA、DPDK的实践,但是对于大多数开发者而言,依然比较陌生。 那么这些方案各自的场景究竟怎样?是否能够为更多的业务赋能?以下是阶段性简要总结。 二、RDMA (一)原理简介 相对于传统的网络协议栈,RDMA提供的关键特性即为:Kernel Bypass,也即利用专用的NIC(网卡)进行硬件层面的协议传输、编解码(Offload),通过内存映射技术直接与用户态程序交互,从而避免了复杂低效的内核中介。 基于这种设计,随之提供几个额外的重要特性: Zero-Copy:基于DMA操作,通信全程没有额外的CPU介入拷贝,从而降低CPU消耗。 稳定低延迟:由于硬件通路的可靠性,从而保证了稳定的通信延迟。 多种传输模式:RC、RD、UC、UD等。基于不同业务的不同可靠性和性能需求,提供类似TCP/UDP的多种传输模式。 由于RDMA定位为高性能网络传输,同时也为了简化硬件的设计,一般来说,RDMA会避免如软件TCP那样复杂的可靠性设计,而是极其依赖底层传输网络的可靠性。 根据不同的传输网络,RDMA的具体实现分为几类: 另外补充说明: 虽然RoCE v1/2依赖融合融合以太网,也即无损传输,不过也有部分厂商的优化实现,可以减轻对无损传输的依赖。 Linux kernel 4.9+中,实现了Soft-RoCE,也即软件版本的RoCE v2,主要用于测试、学习。 (二)RoCE v2 v.s. iWARP 在以太网环境,主要可选项为RoCE v2和iWARP,相关对比如下: 目前来看,目前的机房网络建设中,对RoCE v2的支持更好,而iWARP却仍然处于相对空白的状态。 为此,当前的调研主要针对RoCE v2,而iWARP仍然有待探索。 (三)业务落地 后台业务主流协议仍然是TCP,具有运行稳定、调试工具丰富等优势。不过对于少数期望高性能的业务,RDMA也是值得考虑的。 业务使用RDMA主要面临两方面的困难: RoCE v2无损网络的要求导致难以跨机房传输,当前腾讯机房的支持为module内传输(如5跳之内)。 全新的开发接口如libverbs、UCX等,业务软件需要进行适配。 而有些存储业务依赖多副本,网络传输需要能够跨越MAN,甚至跨城市传输。这直接导致RoCE v2难以落地。 三、io_uring/socket (一)原理简介 io_uring是Linux 5.1+中支持的异步IO框架,其核心优势有: 真正的异步化设计(Proactor),而非如epoll等本质上的同步行为(Reactor)。而其关键在于,程序和kernel通过SQ/CQ两个队列进行解耦。 统一的异步IO框架,不仅支持存储、网络。由于良好的扩展性,甚至可以支持任何的系统调用,如openat、stat等。 如前述,一个io_uring的实例,会建立一对内核和用户程序共享的队列,也即提交队列SQ和完成队列CQ,两者皆为SPSC范型: SQ:用户态线程生产,然后系统调用(io_uring_enter)通知内核(io_wq kernel thread)消费。其中元素称为SQE。 CQ:内核生产,然后通知(若用户程序睡眠等待则唤醒)用户态消费。其中元素称为CQE。 这其实是最常规也是最经典的异步模型,在众多异步设计中可见。 一般情况下,CQE和SQE一一对应,不过io_uring支持multi-shot模式后则不一定如此。 另外,io_uring支持批量生产和消费,也即连续生产多个SQ后,一次性通知内核,或者持续消费CQ直到其空。 为了进一步优化部分场景的性能,io_uring支持众多的高级特性: File Registration:在反复操作同一个fd时,加速其查找映射。 Buffer Registration:在read/write等反复需要在内核和用户程序交换数据的场景,可以重复利用预注册的一批内存。 Automatic Buffer Selection:为Proactor read预注册一批内存,在就绪后内核自动选择其中一块存放数据,从而减少内存分配释放,也节约内存资源。 SQ Polling:使内核(io_wq)轮询SQ指定时间才睡眠,从而减少通知的系统调用。 IO Polling:开启子系统(存储、网络等)的轮询模式(需要设备驱动支持),从而加速部分高速设备。另外可以配合io_uring_enter(flag:IORING_ENTER_GETEVENTS)进行忙等。 Multi-Shot:一次提交,多次完成,如只要一次提交socket accept,后续连接到来后多次返回。 io_uring在存储IO场景,相对之前的阻塞IO、glibc aio、linux aio等,都有不错的性能提升。 那么在网络IO场景呢?是否优于epoll等方案呢? (二)测试数据 经过调研,在知名开源软件中,暂未发现直接采用io_uring进行网络IO的方案,如seastar/nginx等都没有官方支持,既然可借鉴较少,那么就自行测试。 由于io_uring还处于完善阶段,而且对于网络IO的支持也有多种方式。目前我们梳理出其中3种: Proactor:io_uring直接recv/send。 Reactor:io_uring接管socket_fd(POLL_ADD)后再recv/send。 io_uring接管epoll_fd后再epoll_wait再RECV/SEND:路径繁琐,推测性能不佳,直接略过。 为此,我们针对前两种io_uring模型,以及常用的epoll模型,进行测试对比。 为了利用更多的io_uring特性,测试采用当前最新kernel(5.15)。测试模型如下: 通信协议:tcp echo 服务模型:单线程,异步并发 压测客户端:多线程,每个线程一个连接同步测试 数据:包大小为512B 测试环境:本机通信loopback接口 epoll io_uring(Proactor) io_uring(Reactor) 目前网上的很多程序采用此方式。不过从理论上分析,应该epoll性能接近,故暂未测试。 (三)数据分析 通过对比、分析以上的测试数据,可以得到以下结论: io_uring在网络IO方面,并不比epoll性能强大。网络IO的主要瓶颈还是在于内核协议栈的开销。 io_uring即使开启内核轮询,在负载低时可降低延时,而满载性能提升不明显,反而浪费了CPU资源。 (四)业务落地 在Linux网络IO场景中,io_uring并不比epoll带来额外的性能提升。这与存储IO不同。 不过值得思考的是,如果一个系统中同时存在网络IO和存储IO,对比以下两种方式: 网络IO采用epoll,存储IO采用io_uring(可结合eventfd与epoll配合) 网络IO、存储IO都采用io_uring。 从理论上分析,方式2可以依赖io_uring批量提交等优化,从而进一步减少系统调用,是否可以带来性能提升呢? 这部分需要进一步测试分析。 四、总结 以上简单介绍了RDMA、io_uring/socket等方案,各有优缺点以及场景限制。后续将介绍DPDK的方案,敬请期待。 作者简介 quintonwang,腾讯后台开发工程师。

优秀的个人博客,低调大师

密码学系列之:内容嗅探

简介 内容嗅探,也被称为媒体类型嗅探或MIME嗅探,是检查一个字节流的内容,试图推断其中数据的文件格式的做法。内容嗅探通常用在媒体类型没有被准确指定的情况,用于补偿元数据信息。 本文将会讲解内容嗅探的常用场景和可能出现的问题。 MIME types MIME的全称是Multipurpose Internet Mail Extensions,多用途互联网邮件扩展。它是一种标准,它表明了文档、文件或各种字节的性质和格式。它是在IETF的RFC 6838中定义的。互联网编号分配机构(IANA)负责定义所有官方的MIME类型。 MIME的结构包含两部分,分别是type和subtype,他们以 / 来进行分割: type/subtype 类型代表数据类型所属的一般类别,如视频或文本。子类型确定MIME类型所代表的指定类型的确切数据种类。例如,对于 MIME 类型的文本,子类型可能是 plain(纯文本)、html(HTML 源代码)或日历(对于 iCalendar/.ics)文件。 每种类型都有它自己的一套可能的子类型, 一个MIME类型必须包含一个类型和一个子类型。 还可以在后面加上额外的参数: type/subtype;parameter=value 例如,对于主类型是text的任何MIME类型,可选的charset参数可以用来指定数据中字符的字符集。如果没有指定字符集,默认为ASCII (US-ASCII),除非被用户代理的设置覆盖。要指定UTF-8文本文件,则使用MIME类型text/plain;charset=UTF-8。 MIME类型不区分大小写,但传统上用小写,但参数值除外,因为参数值的大小写可能有或没有特定的意义。 MIME有两中类型,分别是discrete和multipart。 离散类型是代表单一文件或媒介的类型,如单一文本或音乐文件,或单一视频。 多部分类型是指由多个组件组成的文件,每个组件都有自己独立的MIME类型;或者,指封装在一个事务中一起发送的多个文件。例如,电子邮件中多个附件就是一种多部分MIME类型。 我们看下常见的discrete类型: application, 比如:application/octet-stream,application/pdf,application/pkcs8和application/zip等。 audioList, 比如:audio/mpeg,audio/vorbis。 font, 比如:font/woff,font/ttf和font/otf。 image,比如:image/jpeg,image/png和image/svg+xml。 model, 比如:model/3mf和model/vml。 text,比如:text/plain,text/csv和text/html. video,比如:video/mp4。 常见的Multipart类型如下: message,比如:message/rfc822和message/partial。 multipartList, 比如:multipart/form-data 和multipart/byteranges。 浏览器嗅探 因为浏览器使用MIME类型,而不是文件扩展名来决定如何处理一个URL,所以Web服务器在响应的Content-Type头中发送正确的MIME类型非常重要。如果没有正确配置,浏览器很可能会误解文件的内容,网站将无法正常运行,下载的文件也可能会被错误处理。 为了解决这个问题,或者说是更好的用户体验,很多浏览器会进行MIME内容嗅探,也就是通过解析文件的内容,来猜测MIME类型的格式。 不同的浏览器处理MIME嗅探的方式是不一样的。但是他们都可能会产生严重的安全漏洞,因为有些MIME类型是可执行类型的,恶意攻击者可以通过混淆MIME嗅探算法,从而使攻击者可以进行网站运营者或用户都没有预料到的操作,如跨站脚本攻击。 如果不想浏览器端进行嗅探,可以在服务端的响应中设置X-Content-Type-Options头,比如: X-Content-Type-Options: nosniff 这个头最早是在IE 8中支持的,不过现在所有的浏览器基本都支持这个head类型了。 客户端嗅探 我们通常需要在JS中判断浏览器是否是IE浏览器,然后做响应的处理: var isIEBrowser = false; if (window.ActiveXObject) { isIEBrowser = true; } // Or, shorter: var isIE = (window.ActiveXObject !== undefined); 上面的例子就是非常简单的客户端嗅探,通过判断window是否有ActiveXObject 这个属性来确定这个浏览器是否是IE浏览器。 本文已收录于http://www.flydean.com/content-sniffing/ 最通俗的解读,最深刻的干货,最简洁的教程,众多你不知道的小技巧等你来发现! 欢迎关注我的公众号:「程序那些事」,懂技术,更懂你!

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册