前一篇 尝试 FastAPI WebSocket 写简单的聊天应用 刚体验了 WebSocket, HTTP 可以共用下层的 TCP 连接保持网页与服务器的双向连接。先简单作个回顾,也是为了解释后面关于 Nginx 反向代理 WebSocket 作准备,比如说下面的 WebSocket 服务ws://localhost:8000/ws
当在浏览器中用 JavaScriptvar ws = new WebSocket("ws://test.exmple.com:8080/ws");
后,浏览器首先会发送一个 GET /ws 的 HTTP 请求,如下(不相关的 HTTP 头省去) Read More
继续 TLS(或 SSL, HTTPS) 的话题。在我们诊断 HTTP 请求时,为了验证代码中发送了什么样的请求,会用 curl 或 Postman 的辅助,但它们都可能会带上额外的请求头等信息,最为可靠的办法是用网络抓包工具如 Wireshark, 从中看到的 HTTP 文本协议内容才是真正往外发送的内容。可是对于 HTTPS 的协议数据用 Wireshark 抓取到了也没用,因为它是加密了的,作为 TLS 的 Payload, 如果不知道加密算法或密钥是解不开来的。客户端与服务端的密钥交换是采用非对称方式加密的,只通过抓网络包是不可能知道最终确定的密钥是什么,除非像 Zscaler 那样堂而皇之地作为中间人攻击(man in the middle attack)。
但既然是本地浏览器能理解的网页内容,只要浏览器留了口子的话,也是有办法在 WireShark 中显示出抓取到的 HTTPS 的内容,那就是设置环境变量 SSLKEYLOGFILE, 然后启动浏览器(FireFox 或 Chrome), 就会把通信过程中的密钥记录到文件中,WireShark 中引用该 SSLKEY 文件就能显示出确切的 HTTP 请求的内容。 Read More
好久以前阅读《HTTP/2 in Action》一书起了个头,又重新放回了书架。近来再次对 HTTPS/TLS 来了劲,自己的博客用的是 Let's Encrypt 签发的证书,这次实践一下自签发证书的过程与配置,并实现单向和双向的认证方式。
如果是配置单向认证的过程需要有以下三个证书- 根(CA) 证书: root.crt
- 服务端私钥文件: server.key
- 服务端公钥证书: server.crt
证书是含有组织与域名或(CA) 信息以及公钥的文件, root.key 和 root.crt 将被用于签发其他的证书。这里的 crt 证书是 x509 格式的。
浏览器只会信任某些 CA 机构签发的证书,如 DigiCert, GlobalSign, GoDaddy, Amazon Root CA,Let's Encrypt 等。如果是不被信任 CA 签发的证书,我们在浏览器中打开相应的 HTTPS url 就会看到 'Not Secure - Your connection is not private' 的提示,要继续访问需自行承担可能的安全责任。 Read More- 不管是 HTTPS, SSH, SFTP, SCP 等都涉及到 SSL(Secure Sockets Layer) 或 TLS(Transport Layer Security),以及使用非对称加密交互私钥的过程。
很久很久以前傻傻的认为所谓的非对称加密是像 MD5 那样内容加密后,无法从 MD5 码中还原出原始内容,其实那不就加密,是摘要(Digest)。非对称指的是加密与解密使用是不一样的密钥,即用公钥加密,私有解密。
提到 SSL 和 TLS, 顺便了解一下它们的极简史
SSL 由 Netscape 于 90 年代开发,SSL1.0(94 年,未公开), SSL 2.0(95 年发布), SSL 3.0(96 年发布), 后来 IETF 出了个 TLS 1.0 作为 SSL 3.0 的继承者,再就是后面的 TLS 1.1(2006), 1.2(2008), 1.3(2018)。2015 年 TLS 正式的取代了 SSL,从此江湖不再有 SSL 了,而我们习惯说的 SSL 只是在向曾经的 Netscape 致敬,其实指代的就是 TLS。
HTTPS 并非一直使用非对称加密进行数据通信,而只是用 TLS 安全的交换密钥,而后的数据通信使用私钥进行对称加密。如果数据通信都用非对称的方式性能是不允许的,所以只用非对称的方式进行密钥交换。 Read More
本文进行实际测试 FastAPI 的并发能力,即同时能处理多少个请求,另外还能接收多少请求放在等待队列当中; 并找到如何改变默认并发数; 以及它是如何运用线程或进程来处理请求。我们可以此与 Flask 进行对比,参考 Python Flask 框架的并发能力及线,进程模型,是否真如传说中所说的 FastAPI 性能比 Flask 强, FastAPI 是否对得起它那道闪电的 Logo。
本文使用 JMeter 进行测试,测试机器为 MacBook Pro, CPU 6 核超线程,内存 16 Gb。
对于每一种类型 Web 服务基本的测试是每秒发送 2 个请求,连续发送 1000 个,500 秒发送完所有请求,程序中 API 方法接受到请求后 sleep 800 秒,保证在全部 1000 个请求送出之前一直占着连接,并有充足的时间对连接进行分析。在测试极端并发数时,由于在 Mac OS X 尽管设置了 ulimit 最多也只能创建 4000 多一点线程,所以在模拟更多用户数时,JMeter 在远程 Linux(Docker 或虚拟机) 上运行测试用例。
请求的 URL 是 http://localhost:8080/?id=${count}, 带一个自增序列用以识别不同的请求, JMeter 的 Thread Group 配置为 Number of Threads (users): 1000, Ramp-up period (seconds): 500 Read More
JMeter 是一个极好的测试 Web API 及压力测试的工具,另一个的话就是 Python 版的 LOCUST(它也能远程运行测试)。JMeter 的测试可以在本地模拟并发用户,那么为什么要远程执行 JMeter 测试呢?因为一台机器能模拟的并发用户数受限,一个用户就是对应着一个 Java 线程。比如我在 MacBook Pro(内存 16Gb) 上无论如何调整ulimit -n,ulimit -u, 或用 JAVA_TOOL_OPTIONS, HEAP, JVM_ARGS 设置-Xmx, 调大到 10 G, 或用 -Xss 调小栈大小,都无法让 JMeter 模拟的用户数达到 5000。
文后有本人亲自测试 Java/Python 在 Mac OS X 和 Linux 下可创建多少个线程
如果能够远程运行 JMeter 的测试就能突破单机上的线程限制了,比如 Mac OS X 不行,找个 Linux 远程机器(可以是虚拟机)来执行,一台机器不够,找多个。想要模拟 15000 个并发用户,测试可分配到 5 台机器上执行,每个节点跑 3000 个用户并发就行,有点操控肉机的感觉。 Read More
本书买来有一段时日了,一直还未开始阅读,关于网络上 HTTP/2 的真实使用状态查到以下信息- 截止 2021 年 1 月 8 日,有 50% 的网站正在使用 HTTP/2,参见 Usage statistics of HTTP/2 for websites
- 另一篇介绍 HTTP/2 Adoption 说 2020 年就有 64% Web 请求是基于 HTTP/2 的
得看看我们自己的网站对 HTTP/2 的支持以及使用状况
于此同时,HTTP/3(gQUIC) 也上了议程,作为 HTTP/3 的提议标准的 RFC9114 也于 2022 年 6 月 6 日由 IETF 发布。
本书首先介绍的是关于 HTTP 协议从 0.9 到 1.0, 再到 1.1 的变迁史。
关于 IPv4 和 IPv6
IP 报文的前四位表示协议版本,所以 0100 就是 4。版本 0 ~ 3 是留给实验用的,5 设计为 Intenet 流协议的,例如实时音视频,像 VoIP, 实际上也因为地址数量的限制没被使用。所以就跳到了 IPv6,字节为 0110。后续的 IP 协议版本 7, 8, 9 都被预定了(比如中国的 IPv9 - 冷),所以再有新的 IP 协议版本的放丈是 IPv10 Read More
使用了一段时间的 Vue.js 以后,其中有大量的 ES6 的export/import用法,如import axios from 'axios';
因为目前对 ES6 的
import Home from '../views/Home.vue';
export default {
data() { .... }export/import用法是一知半解的,所以基本上都是基于 vue-cli 创建的项目上依葫芦画瓢,更是不太理解 vue 的项目是如何由main.js->App.vue把所有的 router, views, 和 components 串联起来的。为了进一步理清 Vue.js 项目的初步运行机制,现在开始着手试图通过一个例子来尽可能多的理解 ES6 的 export/import 用法。
我不是标题党,所以不可能命名如:理解 export/import 一篇就够了,全网最全诸如此类的。且本人博客主要是记录自己学习过程的,而非为了招人眼球。所以尽力吧,在一个代码例子中尽可能多的展示 export/import 的用法,为不增加代码的复杂性,有些技巧在代码后进行解释。 Read More
紧接上一篇 Flask 和 Vue.js 开发及整合部署实例,来体验一下它们与 Bootstrap/BootstrapVue 的集成。漂亮的网站少不得一个好的 CSS 框架,现在有许许多的 CSS 框架可选,纯 CSS 的, 轻量级的, 含 JS 的 CSS 框架,如 Pure, Bulma, Spectre, 国产的 Element 等。而我总觉得 Bootstrap 更是五臟俱全,像 Element 专为 Vue.js 打造的一样,Bootstrap 也有 BootstrpVue 那样一个结晶品。
本文准确的内容应该是关于 Vue.js 与 Bootstrap/BootstrapVue 的话题,与 Flask 没什么事,不过这里呢,还是强拉上 Flask, 由 Flask 的 API 来产生一些数据。
同样是阅读 Flask和Vue.js构建全栈单页面web应用【通过Flask开发RESTful API】的一个实践品。本篇基于 Flask 和 Vue.js 开发及整合部署实例 中的步骤建立的项目 flask-vue-app,方便起见,用了一个新项目名称 flask-vue-bootstrap。记得我们为 Flask 和 Vue.js 分别建立了 backend 和 frontend 两个子项目。 Read More- 当我们被问及 HTTP 的 GET 与 POST 两种请求方式的区别的时候,很多答案是说 GET 的数据须通过 URL 以 Query Parameter 来传送,而 POST 可以通过请求体来发送数据,所以因 URL 的受限,往往 GET 无法发送太多的字符。这个回答好比在启用了 HTTPS 时,GET 请求 URL 中的参数仍然是明文传输的一样。
GET 果真不能通过 Request Body 来传送数据吗?非也。如此想法多半是因循着网页中 form 的 method 属性只有 get 与 post 两种而来。因为把 form 的 method 设置为 post, 表单数据会放在 body 中,而 method 为 get(默认值) 时, 提交时浏览器会把表单中的字符拼接到 action 的 URL 后作为 query parameter 传送。于是乎就有了这么一种假像:HTTP GET 必须通过 URL 的查询参数来发送数据。
其实 HTTP 规范并未规定说 GET 就不能发送 body 数据,在 RFC GET 中只是说The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
只是说 GET 意味着通过 URI 来识别资源。
我也是本着传统上对 GET 与 POST 区别的误解很多年,今天突然意识到 GET 应该可以使用 body, 况且 HTTP 本身是一个纯文本的协议。没有测试就没有 100% 的发言权,所以做了如下的测试 Read More