httpbin

1. -O (name) ：指定文件名下载 wget -O test.png http://httpbin.org/image/png 2.--limite-rate :指定速度下载目标文件 wget --limite-rate=1k http://httpbin.org/image/png 3. -c ： 断续传 wget -c --limite-rate=1k http://httpbin.org/image/png 4. -b ： 后台下载 单个“-”之后的参数可以和在一起写such as：-cb ，单数“--”带参数是不能一起写，因为后面还要带参数 5.-U ：user-agent 信息 wget -U ”Windous IE 11.0“ url 6.--mirror ：把网站下载保存到本地 7. -p 下载网站all相关资源ep：img，css ，and so on wget --mirror -U "Mozilla" -p https://docs.scrapy.org/en/latest/ 8. -r ：递归下载 网页中的所有链接 2020-05-21 来源： oschina 链接： https://my.oschina.net/u/4351246/blog/4286758

Splash是一个javascript渲染服务。它是一个带有HTTP API的轻量级Web浏览器，使用Twisted和QT5在Python 3中实现。QT反应器用于使服务完全异步，允许通过QT主循环利用webkit并发。 一些Splash功能： 并行处理多个网页 获取HTML源代码或截取屏幕截图 关闭图像或使用Adblock Plus规则使渲染更快 在页面上下文中执行自定义JavaScript 可通过Lua脚本来控制页面的渲染过程 在Splash-Jupyter 笔记本中开发Splash Lua脚本。 以HAR格式获取详细的渲染信息 1、Scrapy-Splash的安装 Scrapy-Splash的安装分为两部分，一个是Splash服务的安装，具体通过Docker来安装服务，运行服务会启动一个Splash服务，通过它的接口来实现JavaScript页面的加载；另外一个是Scrapy-Splash的Python库的安装，安装后就可在Scrapy中使用Splash服务了，下面我们分三部份来安装： (1)安装Docker # 安装所需要的包： yum install -y yum-utils device-mapper-persistent- data lvm2 # 设置稳定存储库： yum-config-manager --add-repo https://download

by 闲欢 之前我们用了 urllib 库，这个作为入门的工具还是不错的，对了解一些爬虫的基本理念，掌握爬虫爬取的流程有所帮助。入门之后，我们就需要学习一些更加高级的内容和工具来方便我们的爬取。那么这一节来简单介绍一下 requests 库的基本用法。 介绍 首先让我们来看 Requests 官方的介绍： Requests is an elegant and simple HTTP library for Python, built for human beings. 翻译过来就是：Requests 是为人类写的一个优雅而简单的 Python HTTP 库。这个介绍很直白了，让我们先来感受一下 Requests 的威力。 import requests # 发送请求 response = requests.get(url="http://www.baidu.com/s", params={'wd':'python'}) # 处理响应 print(response.status_code) # 输出结果 200 这个请求如果用 urllib 来实现，代码如下： import urllib.parse import urllib.request url = "http://www.baidu.com/s" params = urllib.parse.urlencode({'wd':

最近在写脚本时有一个功能是上传附件，也趁这个机会学习了下对于上传文件类的接口该如何进行传参 本次介绍2种方式来上传附件：一种是通过jmeter；另一种是通过python的requests库 接口参数分析 在讲具体方法之前，先来分析下这次上传附件接口的headers与携带的参数信息 headers种主要看 content-type， 这个请求中的content-type如下 content-type: multipart/form-data; boundary=----WebKitFormBoundaryKtD3qxHwCR9S9Wdy 查了一些资料，大概意思是说：数据以 multipart/form-data 编码， boundary 用于分割不同的字段 继续看下参数是如何的，可能就理解上面说的boundary用于分割字段是什么意思了，chrome控制台下显示的参数信息如下 ------WebKitFormBoundaryKtD3qxHwCR9S9Wdy Content-Disposition: form-data; name="type" 3 ------WebKitFormBoundaryKtD3qxHwCR9S9Wdy Content-Disposition: form-data; name="file"; filename="test.jpg" Content-Type:

原文连接： https://blog.fengjx.com/wrk/ wrk 是一个类似 ab(apache bench)、jmeter 的压力测试工具，底层基于 epoll 和 kqueue 实现，能充分利用 cpu 资源，降低测试工具本身性能开销对测试结果准确性的影响。支持使用 lua 脚本自定义测试逻辑，使用上非常简单，但功能足够强大。 没有了解过 lua 的同学，可以看下 lua 简明教程 https://coolshell.cn/articles/10739.html 安装 linux https://github.com/wg/wrk/wiki/Installing-wrk-on-Linux macOS https://github.com/wg/wrk/wiki/Installing-wrk-on-Mac-OS-X windows( Windows Subsystem for Linux ) https://github.com/wg/wrk/wiki/Installing-wrk-on-Windows-10 用法 $ wrk -h wrk: invalid option -- h Usage: wrk <options> <url> Options: -c, --connections <N> Connections to keep open -d, -

简介 Spring Cloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。 Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。 概念 Route（路由）：Route 是网关的基础元素，由 ID、目标 URI、断言、过滤器组成。当请求到达网关时，由 Gateway Handler Mapping 通过断言进行路由匹配，当断言为真时，匹配到路由。 Predicate（断言）：Predicate 是 Java 8 中提供的一个函数。允许开发人员匹配来自 HTTP 的请求，例如请求头或者请求参数。简单来说它就是匹配条件。 Filter（过滤器）：Filter 是 Gateway 中的过滤器，可以在请求发出前后进行一些业务上的处理。 工作原理 当客户端请求到达 Spring Cloud Gateway 后，Gateway Handler Mapping 会将其拦截，根据 predicates

前言 微服务架构提供了更好的灵活性、可伸缩性以及服务复用的能力，但，微服务也有特殊的安全需求，Istio Security尝试提供全面的安全解决方案。为了提供灵活的服务访问控制，需要双向 TLS 和细粒度的访问策略。Istio 提供两种类型的身份验证：传输身份验证和来源身份验证。通过配置不同级别的认证策略，可以快速控制不同的安全访问粒度。 典型的使用场景： 1.在未启用双向TLS的安装好 Istio 的 Kubernetes 集群中，需要快速启用全网格双向TLS； 2.网格内某些服务之间需要使用双向TLS，可以将这些服务放入同一命名空间并在命名空间启用双向TLS； 3.当单个服务需要启用TLS时，可以在配置策略中通过spec字段指定； 认证策略是对服务收到的请求生效的，要在双向 TLS 中指定客户端认证策略，需要在DetinationRule 中设置 TLSSettings，每个认证策略需要和目的地规则共同生效。下面通过实例来演示在不同存储范围内配置传输身份认证策略的过程，来源身份验证通过spec中的origins字段指定。 环境准备：装好istio的集群，禁用全局双向TLS；Httpbin应用镜像和sleep应用镜像 1.创建命名空间、部署应用 创建3个命名空间：foo、bar、legacy，foo和bar中部署带sidecar的httpbin应用和sleep应用

在之前的最佳实践中，已经带大家通过一系列的实践任务领略了Istio的无穷魅力。今天，将向大家介绍如何用Istio实现流量熔断。 熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意攻击等场景。 在接下来的任务中，idou老师将通过配置一个熔断器来详细介绍如何在Istio中实现熔断，以及背后的原理。 首先，我们需要添加一个应用程序来模拟访问网络中的通信。接着我们按照前面Istio实践中所要求的将Sidecar注入进应用中，然后启动应用。 步骤一 为了演示Istio的熔断功能，我们需要创建熔断器，并在熔断器中设置一个目标规则，如下所示： 在本步骤中，我们可以理解为Istio的熔断功能主要是通过在链接池中加入上述三个参数： MaxConnections定义了到目标主机的 HTTP1/TCP 最大连接数； http1MaxPendingRequests定义了针对一个目标的 HTTP 请求的最大排队数量； maxRequestsPerConnection定义了对某一后端的请求中，一个连接内能够发出的最大请求数量。如果将这一参数设置为 1 则会禁止 keep alive 特性。 在上述yaml文件中，我们为了方便进行实践，所以都设置成了1，当然大家也可以根据自己的需求自己设定阈值。 步骤二

在Istio中，双向TLS是传输身份验证的完整堆栈解决方案，它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信，以及提供密钥管理系统。本文阐述如何在不中断通信的情况下，把现存Istio服务的流量从明文升级为双向TLS。 使用场景 在部署了Istio的集群中，使用人员刚开始可能更关注功能性，服务之间的通信配置的都是明文传输，当功能逐渐完善，开始关注安全性，部署有sidecar的服务需要使用双向TLS进行安全传输，但服务不能中断，这时，一个可取的方式就是进行双向TLS的迁移。 下面通过实例演示如何进行双向TLS的迁移。 环境准备 • 已经部署好Istio的集群，没有启用双向TLS • 创建三个命名空间，分别是 foo、bar 以及 legacy • 在 foo、bar 中分别部署注入 Istio sidecar 的 httpbin 以及 sleep 应用，在legacy中部署未注入sidecar的sleep应用 检查部署情况 可以看到，从任意一个命名空间选一个sleep应用，发送http请求到httpbin.foo，都能请求成功。这个时候，使用的是明文传输。 检查系统中的认证策略和目标规则： 可以看到，系统中在foo、bar 以及 legacy命名空间下没有认证策略和目标规则。 下面开始通过配置服务端和客户端来升级传输过程： 1. 配置服务器

　　掌握了前面几节的的内容，就可以做一些简单的http协议接口的请求发送了，但是这些还不够。HTTP协议是一个无状态的应用层协议，也就是说前后两次请求是没有任何关系的，那如果我们测试的接口之前有相互依赖关系怎么办呢（比如我要在博客园发文章，是需要先登录的），这时我们就要用到cookie和session技术来保持客户端与服务器端连接的状态，这也就是本节要介绍的内容： 一、Cookie: 1、获取cookie: # -*- coding:utf-8 -*- #获取cookie import requests import json url = "https://www.baidu.com/" r = requests.get(url) #将RequestsCookieJar转换成字典 c = requests.utils.dict_from_cookiejar(r.cookies) print r.cookies print c for a in r.cookies: print a.name,a.value 输出： <RequestsCookieJar[<Cookie BDORZ=27315 for .baidu.com/>]> {'BDORZ': '27315'} BDORZ 27315 二、发送cookie: # -*- coding:utf-8 -*-