网络

Content-Type请求示例 1.application/json 请求 python代码示例 import requests import json data = { 'a': 123, 'b': 456 } ## headers中添加上content-type这个参数，指定为json格式 headers = {'Content-Type': 'application/json'} ## post的时候，将data字典形式的参数用json包转换成json格式。 response = requests.post(url='http://127.0.0.1:9000/api/ttt', headers=headers, data=json.dumps(data)) 实际发出的请求体 POST /api/ttt HTTP/1.1 Host: 127.0.0.1:9000 User-Agent: python-requests/2.31.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Type: application/json Content-Length: 20 {"a": 123, "b": 456} 2. application/x-www-form-urlencoded 请求 python代码示例 import requests data = { 'a': 123, 'b': 456 } ## headers中添加上content-type这个参数，指定为x-www-form-urlencoded格式 headers = {'Content-Type': 'application/x-www-form-urlencoded'} ## post的时候，默认按x-www-form-urlencoded格式处理 response = requests.post(url='http://127.0.0.1:9000/api/ttt', headers=headers, data=data) 实际发出的请求体 POST /api/ttt HTTP/1.1 Host: 127.0.0.1:9000 User-Agent: python-requests/2.31.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 11 a=123&b=456

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.序言 有些读者在访问云服务器或者跳板机的时候，可能会发现如果一段时间不使用客户端，连接就自动断开了。 为什么要这么做呢？以跳板机举例，跳板机有时候被称作堡垒机，它类似于一个封闭的房子所开的窗户。跳板机负有身份验证，授权控制，安全审计等义务。 对机房内部任何主机的访问，都必须要访问跳板机。因此每个client都要与跳板机建立连接，跳板机的资源有限，所以通常会定期对闲置的client进行清理。 2.怎样清理空闲连接？ TCP协议header中有一个RST标识。 RST一般出现于异常情况，归类为 对端的端口不可用 和 socket提前关闭。 只需要向连接中任意一方发送带有RST标识的TCP包就可以迫使连接断开 但是需要注意的是，接收方收到RST包，首先会看下TCP包的seq是否合法，即seq是否在合法接收窗口范围内。如果不在范围内，这个RST包就会被丢弃。 2.1 获取合法的Seq 经过上面的分析，我们已经现在的问题是如何获取一个合法的Seq。仔细观察TCP header， Acknowledgment Number 表示sender期待的下一个序列号(Seq). Window 表示sender还能够接收的数据大小 [Ack, Ack + Window] 一定是合法的Seq范围 通过抓包，并计算就可以得到一个Sender所能接受的Seq，从而成功的发起一次RST攻击。 2.2 Challenge Ack 但是如果这个连接非常空闲，一直无法抓到数据包怎么办？根据参考资料1的介绍，我们还可以使用Challenge Ack。使用任意的Seq，伪造一个带有SYN标识的TCP包，receiver会发送带有正确Ack的Ack包给sender, 这样我们也能快速获得合法的Seq。萌叔在项目vearne/grpcreplay 中也使用了这个技术。 3.网络工具Tcpkill 社区已经有开源工具tcpkill可以使用 3.1安装 Centos sudo yum -y install dsniff Ubuntu sudo apt install dsniff 3.2 用法 tcpkill [-i interface] [-1..9] expression 第1个参数 -i 指定网卡设备 第2个参数指定强度 第3个参数expression 是libcap抓包使用的过滤器 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 参考资料 1.1 In Search of an Understandable Consensus Algorithm 1.2 寻找一种易于理解的一致性算法 1.3 Raft协议精解 1.4 Raft协议动画演示 1.5 goraft/raftd The original project authors have created new raft implementations now used in etcd and InfluxDB. goraft/raftd的作者参与了etcd项目的实现，所以goraft/raftd是有参考价值的 。另外goraft/raftd的实现不完整，没有实现Log擦除等功能，因此不能用于生产环境。 2. Node的简单介绍 2.1 node的三种状态(state) 图1 有限状态自动机 Leader Candidate Follower 2.2 各种存储 2.2.1 Write-Ahead Log（WAL） 存储:文件 4f raft:join">{"name":"2832bfa","connectionString":"http://localhost:4001"} e raft:nop 4f raft:join">{"name":"3320b68","connectionString":"http://localhost:4002"} 4f raft:join">{"name":"7bd5bdc","connectionString":"http://localhost:4003"} e raft:nop 29 write"{"key":"foo","value":"bar"} 29 write"{"key":"aaa","value":"bbb"} 29 write"{"key":"bbb","value":"ccc"} 29 write"{"key":"ddd","value":"eee"} e raft:nop e raft:nop 29 write"{"key":"foo","value":"bar"} 29 write"{"key":"foo","value":"bar"} 2.2.2 状态信息(状态信息) commitIndex、peer等 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 前言 本文将从功能特性上对比与TCP协议的差别。KCP有大量的思想借鉴了TCP的思想，最终得到的设计方案也与QUIC协议有很多的类同之处，很值得学习和研究。 特性对比 黄色表示新加的功能或者有较大的优化 绿色表示较小的优化 打赏萌叔

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 xtaci/kcp-go的作者，在KCP标准协议的基础上做了扩展，增加了加密和FEC（Forward error correction，前向纠错）那么前向纠错到底是干什么用的 2. reed-solomon算法概述 在xtaci/kcp-go中，FEC的实现使用的是reed-solomon编码(实现库为klauspost/reedsolomon)，这是一种诞生于上个世纪60年代的一种纠错码。详细的解释见参考资料1 原始数据如下图所示 它由4个piece组成, “ABCD” “EFGH” “IJKL” “MNOP”, 每行当做一个piece。 reed-solomon算法构造了一个编码矩阵(别问萌叔怎么构造，反正是挺深奥的数学问题)，使得这个矩阵与原始矩阵相乘以后，得到的新矩阵。可以观察出来，新矩阵的前4个piece与旧矩阵完全相同，剩余的2个piece，被叫做parity, 权且翻译为校验块吧。 即使新矩阵丢失了2个piece 在等式2边乘以编码矩阵的逆矩阵，就可以消去编码矩阵，重新恢复出原始数据 3. reed-solomon算法结论总结 包含有n个symbol的消息可以通过reed-solomon算法，得到包含 n + k 个 symbol的新消息。任意丢失至多k个symbol，原始消息仍然能够被恢复出来。这里symbol和piece的概念类同。 因为reed-solomon算法的这个特性，它被广泛的用于 1）DVD、CD、二维码 碟片即使有部分被刮花，仍然能够播放 二维码即使部分被遮挡，仍然能够识别 2）远距离空间传输 空间探测器在向地球发送数据包时，每个包的传输可能需要耗费几个小时，传输过程中，极有可能由于其他陨石遮挡等原因，造成丢包。有了reed-solomon算法，丢失的包可以被直接恢复出来，不需要再重传。 3）存储系统，比如 minio 甚至萌叔发现它在 minio/minio 一个支持Amazon S3协议的对象存储系统中也有使用 缺点 增加了额外的存储和传输量，另外在做数据恢复时，有额外的计算开销。 4. FEC KCP协议中前向纠错相关的字段是这样设定的，它和块加密一样，都是可选的 FEC TYPE: typeData = 0xF1 原始数据块 typeParity = 0xF2 校验数据块 FEC SEQID: 递增的计数器 +-----------------+ | SESSION | +-----------------+ | KCP(ARQ) | +-----------------+ | FEC(OPTIONAL) | +-----------------+ | CRYPTO(OPTIONAL)| +-----------------+ | UDP(PACKET) | +-----------------+ | IP | +-----------------+ | LINK | +-----------------+ | PHY | +-----------------+ (LAYER MODEL OF KCP-GO) 注意 和网络分层模型一样，FEC只对自己这层负责，FEC对自己的数据包中到底存的是什么并不感兴趣。因此校验数据块中的数据应该被理解为2进制数据，它们是不能按照ARQ被解析的。 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 KCP协议包含了2中模式，消息模式和流模式。今天笔者来讲讲这2种模式的区别。 2. 流模式和消息模式 回顾一下KCP协议 0 4 5 6 8 (BYTE) +---------------+---+---+-------+ | conv |cmd|frg| wnd | +---------------+---+---+-------+ 8 | ts | sn | +---------------+---------------+ 16 | una | len | +---------------+---------------+ 24 | | | DATA (optional) | | | +-------------------------------+ frg:分片，用户数据可能会被分成多个KCP包，发送出去 在xtaci/kcp-go的消息模式实现不完整，这个字段始终为0 详见issues/121 sn: 序列号 len:数据长度(DATA的长度) data:用户数据 2.1 消息模式 假定一个场景，在IM中，A向B发送了一个消息，这个消息可能是文本消息，也可能是图片消息。那么应用程序发送的数据是有逻辑的消息的概念的。 kCP协议提供了一种能力把不同的消息(应用程序)划分在不同的KCP包中。 KCP定义 MSS的默认大小为1400 bytes，MSS(maximum segment size)表示最大段大小，它本身是TCP中的概念，表示包含TCP header，整个数据包的最大大小。在KCP协议中，概念类似，表示包含KCP header在内，整个KCP包的最大大小。 超过MSS的数据将会被拆分到成多个KCP包。根据是否拆包将会分成2种情况。 1）不拆包 3条消息Msg1,Msg2,Msg3分别包含在sn为 90、91、92的KCP包中 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 KCP协议的很多东西都是脱胎于TCP协议，所以他们在思想和实现上是完全相通的。xtaci/kcp-go 包含FEC也不过4000多行代码，skywind3000/kcp 主要是C/C++的代码，也就2000多行，萌叔建议大家都去阅读下源码。 慢启动、拥塞避免、拥塞发生、快速重传，这些概念都非常唬人，但看完代码你会发现不过尔尔。 在开始正式的文章之前，萌叔打算问几个问题？ 流控是为了保护谁？ 在实现中如何体现？ 2. 流控是为了保护谁？ TCP是全双工，这里简化一下，我们只看半双工的情况 Sender发送数据给Receiver 1) Sender中的应用程序把数据写入到本机的发送缓冲区 2) 数据从发送缓冲区写入到链路中，链路可能是由实际的光缆、电缆、多个路由器节点组成。 3）数据从链路转交到Receiver的接收缓冲区 4）数据从接收缓冲区交给Receiver的应用程序 发送缓冲区大小是有限的，它必须被保护起来 Sender和Receiver之间的链路的收发能力也是有限的，且是与网络中的其它节点共享的，因此Link也必须受到保护 接收缓冲区大小也是受限的，它也应该受到保护 3. 在实现中如何体现？ 在实际实现中每一个需要保护的点，都有与之对应的参数，先上结论 3.1 使用发送端的发送窗口(snd_wnd)保护本机的发送缓冲区 3.2 使用拥塞窗口(cwnd)来保护发送端与接收端之间的链路 cwnd是动态变化的值, 算法与TCP协议基本相同 3.3 使用接收端的接收窗口(rmt_wnd, 表示接收窗口的空闲大小）保护接收端的接收缓冲区 rmt_wnd对应KCP协议的wnd, 由接收端汇报 回顾一下KCP协议 0 4 5 6 8 (BYTE) +---------------+---+---+-------+ | conv |cmd|frg| wnd | +---------------+---+---+-------+ 8 | ts | sn | +---------------+---------------+ 16 | una | len | +---------------+---------------+ 24 | | | DATA (optional) | | | +-------------------------------+ 4. 分析一次完整的写入动作 4.1 发送窗口和接收窗口对写入的影响 在KCP中，数据被拆分成Segment后 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 KCP协议是一种快速可靠传输ARQ(Automatic Repeat-reQuest)协议，能以比TCP浪费10%-20%的带宽的代价，换取平均延迟降低 30%-40%，且最大延迟降低三倍的传输效果。它跟QUIC协议一样也是基于UDP协议的实现。KCP从TCP协议中借鉴了大量的思路，是理解TCP/IP协议栈的非常好的资料。 补充说明下，无论是QUIC还是KCP只有在弱网络条件下，相比TCP才有优势。 KCP协议在网络分层模型的位置 +-----------------+ | SESSION | +-----------------+ | KCP(ARQ) | +-----------------+ | FEC(OPTIONAL) | +-----------------+ | CRYPTO(OPTIONAL)| +-----------------+ | UDP(PACKET) | +-----------------+ | IP | +-----------------+ | LINK | +-----------------+ | PHY | +-----------------+ KCP的设计者有意识的把KCP依赖的网络通讯给解耦了 纯算法实现，并不负责底层协议（如UDP）的收发，需要使用者自己定义下层数据包的发送方式，以 callback的方式提供给 KCP。 如果读者阅读 skywind3000/kcp 源码，可能会发现如下代码 test.cpp // 创建模拟网络：丢包率10%，Rtt 60ms~125ms vnet = new LatencySimulator(10, 60, 125); 测试和验证是不需要再真实网络上进行。 skywind3000/kcp 只是设计了最初的协议, 包括 非延迟ACK 快速重传（TCP协议也有） 非退让流控(拥塞控制，和TCP实现类同) xtaci/kcp-go 在此基础上，又增加了 加密机制 FEC(Forward Error Correction)前向纠错 PS: skywind3000和xtaci其实是大学同学 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 萌叔试图通过Gateway把服务暴露在服务网格外部，下面是笔者的一些总结。 2. 体系结构 很重要 gateway-controller <-> ingress-controller (实际的pod) istio-ingressgateway <-> nginx-ingress-controller (一种实现) gateway <-> ingress (配置) gateway-controller的一个实现是 istio-ingressgateway ingress-controller的一个实现是 nginx-ingress-controller nginx-ingress-controller相当于openresty, 配置ingress以后会生成对应nginx的配置文件。同样配置gateway之后, 会生成envoy对应的配置文件。 3. 配置 3.1 istio-ingressgateway 当安装了istio以后，服务中会有一个istio-ingressgateway 默认情况下, istio-ingressgateway对应的容器并没有暴露在服务网格之外。需要修改配置。 修改istio-ingressgateway的 Deployment 也可以直接修改helm的 deployment.yaml "dnsPolicy": "ClusterFirstWithHostNet" # 修改（确保能够正确访问pilot） "hostNetwork": true # 添加 （将pod以host网络模式暴露在服务网格外部） “ClusterFirstWithHostNet“: For Pods running with hostNetwork, you should explicitly set its DNS policy “ClusterFirstWithHostNet”. 3.2 gateway 以对kiali的配置为例 1) 创建namespace kubectl create namespace myistio 2）配置gateway 文件 kiali-gateway.yaml ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 前言 HTTP状态码 除了最常见的200，201，其实302应该是我们用的最多的，尤其是在Oauth实现中 简单说明 301 Moved Permanently 描述 状态码301表示永久重定向 场景 网址永久变更 302 Moved Temporarily 描述 状态码302表示临时重定向 场景 网址（资源）临时变更，特别是在Oauth、单点登录等过程中，被大量使用 过程说明 下面是我用python实现的http server的简单例子 redirect.py import time import tornado.ioloop import tornado.web class PermanentlyHandler(tornado.web.RequestHandler): def get(self): print '--301 Permanently--' self.redirect('http://vearne.cc/archives/365', permanent=True) class TemporarilyHandler(tornado.web.RequestHandler): def get(self): print '--302 Temporarily--' self.redirect('http://vearne.cc/archives/365', permanent=False) def make_app(): return tornado.web.Application([ (r"/abc", PermanentlyHandler), (r"/def", TemporarilyHandler), ]) if __name__ == "__main__": app = make_app() app.listen(8888) tornado.ioloop.IOLoop.current().start() 可以直接使用浏览器模拟请求 让我们来观察一下301和302请求的实际返回 ...