Latest

服务器SSH密钥管理规范

密钥使用说明 1. ssh用户名默认为邮箱前缀 2. 使用RSA类型SSH密钥对,长度不小于2048 3. 生成的key必须要配置passphrase 4. 密钥对生成后请自行妥善保管,任何情况下都不得将私钥提供给他人 5. 建议为私钥保留备份(压缩为Zip并添加密码),避免密钥丢失 建议生成方法 推荐使用Linux系统命令ssh-keygen -t rsa -b 2048生成密钥对 ops-coffee@onlinegame:~$ ssh-keygen -t rsa -b 2048 Generating public/private rsa key pair. Enter file in which to save the key (/home/ops-coffee/.ssh/id_rsa): Created directory '

可扩展性

能够获得暴利的职业,都有一个共同特点:可扩展性,一次劳动可以服务成千上万的人。 软件、电影、游戏行业都具有可扩展性,作品的生产成本是固定的,但可以被消费无数次,所以有巨大的获利空间,创造出许许多多的富豪。另一方面,理发师、厨师、出租车司机一次劳动,只能服务少数几个人,就不具有可扩展性,很难获得暴利,生存得很辛苦。 写作是最具可扩展性的活动。你写了一篇文章,每被看到一次,就是扩展了一次。

Elasticsearch Query DSL查询入门

Query DSL又叫查询表达式,是一种非常灵活又富有表现力的查询语言,采用JSON接口的方式实现丰富的查询,并使你的查询语句更灵活、更精确、更易读且易调试 查询与过滤 Elasticsearch(以下简称ES)中的数据检索分为两种情况:查询和过滤。 Query查询会对检索结果进行评分,注重的点是匹配程度,例如检索“运维咖啡吧”与文档的标题有多匹配,计算的是查询与文档的相关程度,计算完成之后会算出一个评分,记录在_score字段中,并最终按照_score字段来对所有检索到的文档进行排序 Filter过滤不会对检索结果进行评分,注重的点是是否匹配,例如检索“运维咖啡吧”是否匹配文档的标题,结果只有匹配或者不匹配,因为只是对结果进行简单的匹配,所以计算起来也非常快,并且过滤的结果会被缓存到内存中,性能要比Query查询高很多 简单查询 一个最简单的DSL查询表达式如下: GET /_search { "query":{ "match_all": {} } } /_search 查找整个ES中所有索引的内容 query 为查询关键字,类似的还有aggs为

Python语言的应用程序人机界面库Tkinter

采用Python开发应用程序时,人机交互界面库可以用tkinter。实现一个小应用只需关注窗口、控件、布局、事件四个部分。 窗口 在tkinter中只需要三行就能生成一个窗口 import tkinter as tk root = tk.Tk() root.mainloop() 控件 在tkinter中不同的功能通过不同的控件实现,tkinter中有几十个控件,常见的有按钮、标签、输入框等。使用控件就像拼积木一样把各种控件放在窗口里。 label = tk.Label(root,text = "请输入你的愿望") entry = tk.Entry(root) button = tk.Button(root,text = "确认") 布局 设置了控件需要“放置”在窗口中才能显示,这个过程需要用“布局”

HTTPS 如何保障数据安全传输

HTTPS在原有的明文HTTP协议上附加了一个TLS加密层来保证传输层的信息不被任何中间方窃听。 在整个TLS的握手阶段,客户端和服务端通过多次交互来确认以下信息: 1. 双方确认使用的TLS版本,如TLS 1.2, 1.3。 2. 双方选择使用的加密模式,包括对应的对称加密和非对称加密算法 3. 客户端通过服务端提供的公钥和服务器数字证书来确认自己连接的是正确的服务器。 4. 客户端选定会话密钥后,通过非对称加密算法传输给服务端 相较于TLS 1.2,TLS 1.3 主要做了以下改进: 1. 更快的握手过程: TLS 1.3通过减少握手过程中的往返次数,加快了连接建立的速度,从而提高了性能。 2. 更强的加密算法: TLS 1.3移除了一些安全性较弱的加密算法,只支持更安全的加密套件,如ChaCha20-Poly1305和AES-GCM。 3. 减少了协议握手过程中的延迟: TLS 1.3减少了协议握手中的往返次数,从而减少了连接建立的延迟。 参考: * Cloudflare - 什么是 TLS(

Python爬虫批量爬取图片——基于urllib与requests

Python到底多强大,绝对超乎菜鸟们(当然也包括我了)的想象。近期我接触到了爬虫,被小小地震撼一下。总体的感觉就两个词——“强大”和“有趣”。今天就跟大家分享一下两个简易的爬虫案例,大牛们请飞过哈。 先来科普一下啊“爬虫技术”吧。网络爬虫(又被称为网页蜘蛛,网络机器人,网页追逐者),是一种按照一定的规则,自动地抓取万维网信息的程序或者脚本。另外一些不常使用的名字还有蚂蚁、自动索引、模拟程序或者蠕虫。 它的名字虽然很多,但是过程很明确,就两个部分:一是从网页源代码中爬取有用信息;二是对这些信息进行处理(如分析、下载等)。 下面用两种方法制作批量爬取网络图片的方法。 第一种方法:基于urllib实现 要点如下: 1.url_request = request.Request(url) 2.url_response = request.urlopen(url) 或者 url_response

TCP 建立连接需要3 次握手?为什么不是 2 或 4

TCP的3次握手本质上是建立一个可靠的全双工通道,此外还同步了双方的滑动窗口大小。 为什么不是2次:客户端SYN,服务端ACK的2次握手只能建立一个客户端到服务端的单工通道。 为什么不是4次:3次握手本质上就是4次,只是将服务端ACK和服务端SYN合并为SYNACK。 参考: * Willam Johnson - Medium Post - Why does TCP connection establishment require three-way handshake?

TCP拆包粘包这种说法对吗

对也不对。本质上对于定义的问题。代码使用方认为在应用层发送数据包时数据包是有边界的,因此在接收方时也应该读到边界。但是实际上TCP是基于字节流的,因此所有通过TCP传输的数据都被视作一个字节流。TCP只保证传输的内容的顺序性,但是应用是否应该将接收到的信息视作是同一个或者不同的包,TCP是管不着的。举个例子,当接收方使用某种带Buffer的机制读取时,就会读到连续的内容,而没有边界,从而可能导致解析发生错误。或者说换种说法,应用层需要自己定义协议内容,确保解析是正确的。 让我们来看看HTTP是怎么处理的。HTTP约定使用\r\n来区分Header和Body,此外在Header中附加的Content-Length确定了客户端应读取的内容长度。以下是一段示例代码。 import socket def send_http_request(host, port, path): # 创建 socket 对象 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 连接服务器 sock.connect((host, port))

TIME_WAIT 的作用

TIME_WAIT是在TCP关闭连接时,在完成四次挥手之后,主动关闭连接的一方应等待TIME_WAIT = 2MSL的时间之后,才重复使用同一个端口进行连接。 1. 保证最后的ACK能到达被动关闭连接方,确保全双工连接正常关闭。否则的话,对方可能会因为收不到ACK包,而请求重传,导致进行一些非法的状态,如RST之类的。 2. 在下一次连接重复使用同一套端口进行连接时,确保不会有丢失在网络里的包重新到达这一套新的连接中。 参考: * 昀溪 - 解读TIME_WAIT--你在网上看到的大多数帖子可能都是错误的