配置predicates和filters有两种方式：简写和全参数展开。
公式：name=name，regexp，例如
如果yaml文件标准一样进行配置，通常会有name和args两个键，args是一个map的键值对组配置predicate或者filter。如下：
每种路由的判断依据都是根据Http请求的不同属性。
**
value为正则表达式
value为正则表达式
每个Host为Ant-style格式，以.号分割。
参数包括一个Spring PathMatcherpatterns和一个可选的matchOptionalTrailingSeparator分隔符
上面的规则可以匹配诸如/red/1/red/blue/blue/green等路径。
抽取URI中的模板变量（如segment），作为键值对存储在ServerWebExchange.getAttributes()，key为ServerWebExchangeUtils.URI_TEMPLATE_VARIABLES_ATTRIBUTE。这些值可以被GatewayFilter factories获取到。有个工具方法可以更简单地获取到这些值。如下
value为正则表达式
格式为CIDR-notation，例如192.168.0.1/16，192.168.0.1是ip，16是子网掩码。
配置两个参数：group和weight（数值）。
上面的配置会让 80%的请求发送到weighthigh.org， 20%的请求发送到weightlow.org。
增加请求头参数，可以使用URI变量
增加查询参数，可以使用URI变量
增加响应头中参数，可以使用URI变量
去掉重复的响应头参数
上面会去掉重复的Access-Control-Allow-Credentials，Access-Control-Allow-Origin参数值。
可以设置strategy值修改默认删除策略，默认为RETAIN_FIRST，即保留第一个。其他有RETAIN_LAST，RETAIN_UNIQUE。
轻量的断路由
可以替换头部的参数的名称，如将Blue：abc替换为X-Request-Red：abc
增加前缀，例如/hello将被发送到/mypath/hello
The RequestRateLimiter GatewayFilter Factory
通过实现RateLimiter接口配置限流规则，可通过keyResolver参数设置具体的限流的key。现在默认的是PrincipalNameKeyResolver，调用的是 ServerWebExchange 中的 Principal.getName()。
如果key解析后为空，请求会被拒绝，可以通过配置下面参数进行自定义策略
spring.cloud.gateway.filter.request-rate-limiter.deny-empty-key ( true or false ) spring.cloud.gateway.filter.request-rate-limiter.empty-key-status-code
redis限流，使用的是令牌桶算法。
redis-rate-limiter.replenishRate 每秒多少个请求，也是令牌入桶的频率。
redis-rate-limiter.burstCapacity 峰值请求。
redis-rate-limiter.requestedTokens 每个请求消耗的令牌数，默认1.
如果想保持稳定的请求频率，可以设置 replenishRate 和 burstCapacity 为相同值，如果有突发的大量请求，则需要设置 burstCapacity 比 replenishRate 大。
如果想设置每分钟1个请求，可以通过以下配置实现
replenishRate=1
requestedTokens=60
burstCapacity=60
也可以实现自己的 RateLimiter 和 KeyResolver
配置参数 status and url
删除指定的请求头参数
删除指定响应头参数
删除请求参数
重写路径
上面配置会把/red/blue变为/blue
/red/blue会变为/blue
替换请求头参数值
替换响应头参数值
设置状态码
上面两种配置都会设置为401
删除前缀
上面的配置将使/name/blue/red变为nameservice/red。
参考
https://cloud.spring.io/spring-cloud-gateway/reference/html/#the-path-route-predicate-factory
1.1 第一行的字段为请求的：方法，资源地址，协议版本
http协议常用的请求方法[method]为
资源地址[uri]：一般为URL中去掉域名后剩下的那部分，即浏览器地址栏网址中域名之后的内容。
http协议版本[version]: 目前主流版本有HTTP/1.0和HTTP/1.1。
http请求头中的的换行用的是\r\n, 而非Linux中的换行符\n。以下为一个真实请求头的示例
1.2 Host字段为请求的主机域名
早期没有虚拟主机的概念，一台服务器有一个主机名。因此规定在请求头的第一行，资源地址只需给出相对地址，不必给出主机名（域名）。但现在一台服务器可能提供多个主机服务，比如一条服务器同时运行了example.com和example.cn两个web站点。只给出相对地址，服务器在收到连接请求后，无法得知该请求是希望与自己哪个web服务建立连接。因此增加了Host字段 [1] 。
1.3 Connection字段为连接选项
用于对连接进行说明：说明是保持连接还是关闭连接等。
早期的http协议不支持此字段，因此为http提供代理的http代理服务器自然也不支持此字段。如今互联网上比较古老的代理服务器依然存在。为了兼容早期的http代理服务器，在客户端和代理之间又增加了Proxy-Connection字段。关于此字段此处简要介绍。
http代理的实现原理是，代理服务器作为通信中介；客户端把代理当作他想访问的服务器，向代理发送连接轻求。之后代理收到连接请求，向客户端真正想访问的服务器转发此连接请求。
使用http代理的客户端，会主动修改其http请求头，比如浏览器在设置http代理后，会将请求头做出如下修改：
修改内容主要是请求头第一行的URI, 由相对地址变为绝对地址。原因同Host字段的产生类似，为了让代理能够区分此连接是希望与哪个主机建立连接。但是这里存在一个疑问：既然有了host字段，为什么还要完整地址？我个人给出两个 可能 的理由：
修改的第二部分是Connection字段，该字段修改为Proxy-Connection。
Proxy-Connection: 用于兼容不支持Connection字段的旧版代理服务器，因为代理服务器默认会将所有未知字段原样转发，而老旧的代理工具不支持Connection选项。当客户端发送 Connection: Keep-Alive 希望保持连接请求，但是代理无法识别此字段，转发一次数据依然会立即断开连接。虽然服务端收到请求且接受保持连接，但代理却关闭了连接，会导致连接中断。因此代理协议要求将Connection修改为Proxy-Connection，只有识别Proxy-Connection的代理服务器才能将Proxy-Connection转为Connection发给服务端，让服务端保持连接。
2.1 CONNECT方法
隧道代理不同于http代理：http代理是代理服务器作为中介，获取到客户端的数据转发给服务器端，获取到服务端的数据转发给客户端。其通信过程是客户端与代理建立http连接，代理和服务端建立http连接。显然无法用于https通信：因为https是加密协议，代理即使使用https协议代替客户端与服务端通信获取到连接应答数据，也无法使用https加密发送给客户端，因为代理没有服务器的证书。此时退而求其次的方式是，代理到客户端这段转为http通信，可能会降低安全性。当然可以在应用层进行加密，依然能保证安全性。但这样并不是完美的https代理。为了解决此问题，http或者说https增加了CONNECT方法，该方法是请求代理向服务器建立一条隧道通信。该隧道是在TCP层建立，客户端与代理建立一条TCP连接，代理再与服务器建立一条TCP连接。之后客户端和服务端在这条TCP连接之上建立一条https连接。
建立连接的请求头方法为CONNECT， 地址只需要主机地址，不能再添加具体的资源路径，因为该请求只是用来建立一条连接，连接建立完成才真正请求数据用来通信。
这里说明一下隧道和http直观上的区别：隧道所使用的TCP属于ISO七层网络模型的第4层，而http和https协议处于第7层，所以TCP作为https的底层协议，https并不会察觉代理的存在。举个例子：隧道相当于A向C输送石油，建立了一条A到B的公路，然后建立了一条B到C的公路，之后在这段公路上建立一条A经由B到C的油管。而http代理是建立了一条A到B的公路，然后建立了一条A到B的油管；之后建立了一条B到C的公路，再建立了一条B到C的油管。隧道方式AC是油管直连，http方式在B处要有个储油罐。
3. 1 简述
移动通信提供了wap和net两种网络接入方式，net即直连，和电脑通过网线连接网络没有什么区别。而wap则是通过代理连接，类比电脑通过路由器联网，多台电脑可以共用一个路由器，多部手机也可共用一个代理，这样只需要一个ip地址即可让多个用户实现通信。对运营商而言wap是节省资源的一种方式。所以早期的手机默认都是wap方式，但是这样当一个代理提供接入的用户过多时，可能导致网速下降。这即是网上盛传修改接入点能提高网速的原因。 但我个人感觉其实影响不大，因为运营商的代理吞吐能力肯定够高，不会和直连有太大差距 。
3.2 移动接入点cmwap分析 [2]
cmwap代理, 在http协议之上增加了扩展字段X-Online-Host；
移动的网关代理和http协议相似，而又同于http代理或隧道代理。
http协议在不使用代理时才使用相对url，与Host字段拼接为绝对地址。
标准的http代理协议是在GET 后添加绝对URL，而非相对URL(http协议在不使用代理时才使用相对url，与Host字段拼接为绝对地址)；
而移动的wap代理GET字段仍是相对URL，但是增加了X-Online-Host字段，通过与X-Online-Host字段拼接为绝对地址。
但是如果GET字段获取到绝对地址，则不再和X-Online-Host字段拼接。
这就产生了下面这个问题：
假设我连接的URL为： http://wap.baidu.com/logo.gif?img=http://wap.uc.cn/uc.png
使用移动网关代理X-Online-Host字段联网：
早期的移动网络，这样的请求到达移动网关之后，可能会被误发至 http://wap.baidu.com/uc.png 。但是实际上我们想要请求的是 http://wap.baidu.com/logo.gif （?之后表示提交内容）。
因为，移动网关实际上就是一个HTTP的代理服务器，它对于X-Online-Host协议处理如下：
截取请求头中的URL字段：
现在处理方法应该已经完善，不会再出现此问题。
这里可以看到存在3个位置可以出现域名：
请求头第一行方法字段；
Host字段；
X-Online-Host字段；
符和移动网关代理协议的标准请求，应该是方法字段使用无域名的相对地址，Host和X-Online-Host字段使用相同的域名。但是事情往往没有想象的那么美好：如果我修改请求方法用绝对地址，同时Host和X-Online-Host字段使用两个不同的域名，将三个域名设为都不相同。网关收到此数据包会发生什么，直接丢掉异或是三个地址具有某种优先级，选择优先级高的作为目的地址转发？这个就看各自地区的运营商如果制定规则了。
但更有趣的事情不在这里而是下面这个问题，流量费用是由网关统计的，当网关转发目的地址都难以确定时，费用又是如何计算呢？之所以发出这个疑问，是因为有些访问特定主机的流量运营商是不收费的，比如访问运营商官网，又或者现在互联网套餐兴起，各种定向免流数据。也就是说计费也需要知道用户请求的Host地址。那么计费又是根据哪个字段，所用的规则和转发规则是相同的么？我想此处是可以给个否定回答的。转发规则和计费规则是不同的!!!
由此我们就可以顺理成章的提出一个坊间流传多年词汇：免流。相传2012年就有人运用此漏洞修改UC浏览器达到免流的目的。时隔多年，三大运营商或注意到或没注意到，此问题也在一点点修复。但是以此作为基础，免流的手段可以说层出不穷，虽然也在一个个失效。但似乎如同道高一尺魔高一丈般，免流的技术却从未中断。尤其各大互联网套餐的出现，让这淡出视野的东西又浮现出来。当然在这个家家有宽带处处有wifi的今天，还玩免流的是真不多了。玩也不是图省那点流量，就是想装装13。
附：联通大王卡动态免流脚本，需要手机获取root权限，使用RE文件管理器，复制到系统/system/xbin目录执行即可
https://lanzous.com/iat0glg
range的值当然可以在前端设置好了，然后调用后台的setHeader进行设置range的值。uriRequest. setHeader ("Range", "bytes=" + current + "-")
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）