feature: App 逆向防护

Chapter5 - Network/5.1.md

@@ -151,7 +151,7 @@ TCP 会利用另一种机制来解决超时重传带来的时间等待问题，
 
 因为 HTTP 无连接，客户端和服务端交互的时候，打开一个 TCP 连接，然后交互，然后关闭 TCP 连接。下次需要交互的时候，继续打开一个 TCP 连接，继续交互，最后又关闭 TCP 连接。
 
-<img src="./../assets/ HTTPContinuesousLink.png" style="zoom:40%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/ HTTPContinuesousLink.png" style="zoom:40%" />
 
 
 
@@ -180,7 +180,7 @@ Session、Cookie 都是针对 HTTP 协议无状态特点的补偿。
 
 Cookie 主要用来记录用户状态，区分用户；状态保存在客户端。
 
-<img src="./../assets/CookieLifeCycle.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/CookieLifeCycle.png" style="zoom:30%" />
 
 客户端请求服务端的时候，服务端生成 Cookie，通过 HTTP 响应报文，Header 部分中 `Set-Cookie` 首部字段设置 Cookie。
 
@@ -214,7 +214,7 @@ Session 也用来记录用户状态，区分用户。只不过状态保存在服
 
 Session 需要依赖于 Cookie 机制。
 
-<img src="./../assets/SessionWorkflow.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/SessionWorkflow.png" style="zoom:30%" />
 
 
 
@@ -328,7 +328,7 @@ ETag 即 Entity Tag，代表资源的唯一标识。主要用来解决修改时
 
 代理体现在头信息上就是字段 `Via`，是一个通用字段，请求头或响应头里都可以出现。每当报文经过一个代理节点，代理服务器就会把自身的信息追加到字段的末尾，就像是经手人盖了一个章。如果通信链路中有很多中间代理，就会在 Via 里形成一个链表，这样就可以知道报文究竟走过了多少个环节才到达了目的地。
 
-![](./../assets/HTTPProxyVia.png)
+![](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/HTTPProxyVia.png)
 
 `X-Forwarded-For` 的字面意思是“为谁而转发”，形式上和“Via”差不多，也是每经过一个代理节点就会在字段里追加一个信息。但“Via”追加的是代理主机名（或者域名），而“X-Forwarded-For”追加的是请求方的 IP 地址。所以，在字段里最左边的 IP 地址就是客户端的地址
 
@@ -365,7 +365,7 @@ Host: www.xxx.com\r\n
 
 HTTP 传输链路上，不只是客户端有缓存，服务器上的缓存也是非常有价值的，可以让请求不必走完整个后续处理流程，"就近"获得响应结果。特别是对于那些“读多写少”的数据，例如突发热点新闻、爆款商品的详情页，一秒钟内可能有成千上万次的请求。即使仅仅缓存数秒钟，也能够把巨大的访问流量挡在外面，让 RPS（request per second）降低好几个数量级，减轻应用服务器的并发压力，对性能的改善是非常显著的。
 
-![](./../assets/CacheProxyServer.png)
+![](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/CacheProxyServer.png)
 
 代理服务器没有缓存的时候：代理服务器每次直接转发来自客户端的报文给服务端，转发服务端的报文给客户端，中间不会存储任何数据，只有基础的中转功能。
 
@@ -397,7 +397,7 @@ HTTP 传输链路上，不只是客户端有缓存，服务器上的缓存也是
 
 下图是完整的服务器端缓存控制策略，可以同时控制客户端和代理
 
-![](./../assets/CacheControlPipeline.png)
+![](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/CacheControlPipeline.png)
 
 ### 客户端的缓存控制
 
@@ -477,7 +477,7 @@ DNS 解析查询方式：
 
 - 递归查询，核心就是“我去给你问一下”
 
-  <img src="./../assets/DNSRecursiveQuery.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/DNSRecursiveQuery.png" style="zoom:30%" />
 
   客户端根据网址去请求服务器之前，会先获取 IP 地址信息。
 
@@ -486,7 +486,7 @@ DNS 解析查询方式：
 
 - 迭代查询，核心就是“我告诉你谁可能知道”
 
-  <img src="./../assets/DNSIteratorQuery.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/DNSIteratorQuery.png" style="zoom:30%" />
 
   - 客户端发送请求的时候问一下本地 DNS 服务器，该域名对应的 IP 地址是什么，本地 DNS 服务器说“我不知道，你去问问根域名服务器，它可能知道”
 
@@ -506,7 +506,7 @@ DNS 解析查询方式：
 
 ##### 什么是 DNS 劫持
 
-<img src="./../assets/DNSHacker.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/DNSHacker.png" style="zoom:30%" />
 
 
 
@@ -531,13 +531,13 @@ QA：DNS 劫持和 HTTP 的关系是什么？
 
   从“使用 DNS 协议向 DNS 服务器的53端口请求” 变成“使用 HTTP 协议向 HTTP 服务器的80端口请求”
 
-  <img src="./../assets/HTTPDNSServerProcess.png" style="zoom:25%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/HTTPDNSServerProcess.png" style="zoom:25%" />
 
   客户端通过 IP 直连的方式，向 DNS 服务器，通过 HTTP Get 请求的方式，携带域名参数，然后响应一个具体的 IP 地址值给客户端。剩余流程就是拿着请求后的 IP 地址去完成其他逻辑。
 
 - 长连接
 
-  <img src="./../assets/LongConnectionAvoidDNSHacker.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/LongConnectionAvoidDNSHacker.png" style="zoom:30%" />
 
   在客户端和业务服务器之间，建立一个长连接 Server，可以理解成代理服务器。
 
@@ -551,7 +551,7 @@ QA：DNS 劫持和 HTTP 的关系是什么？
 
 #### DNS 解析转发
 
-<img src="./../assets/DNSParseRedirect.png" style="zoom:20%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/DNSParseRedirect.png" style="zoom:20%" />
 
 比如某移动 App 发起网络请求，移动 DNS 服务器为了节省资源，将请求转发到某电信 DNS 服务器，用于帮助移动 DNS 服务器，解析域名，获取对应的 IP 地址。
 

Chapter5 - Network/5.2.md

@@ -60,7 +60,7 @@ UDP 不止支持一对一的传输方式，同样支持一对多，多对多，
 
 发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文
 
-<img src="./../assets/UDPOrientedPackage.png"  style="zoom:40%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/UDPOrientedPackage.png"  style="zoom:40%" />
 
 
 
@@ -96,13 +96,13 @@ UDP 在发送消息时，在传输层直接就将一个消息打包成一个完
 
 复用：UDP 多端口复用指的是在 UDP 通信中，可以通过一个 UDP 端口同时处理多个不同的应用程序或服务的通信。这种技术允许多个应用程序共享同一个 UDP 端口进行通信，而不需要为每个应用程序分配独立的端口。通过在接收数据时区分不同的目标端口，可以实现对多个应用程序的数据传输和处理。这种方式可以提高网络资源的利用率和简化网络配置，但需要确保在接收端能够正确解析和处理来自不同端口的数据。
 
-<img src="./../assets/UDPMultiplePortCommonUse.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/UDPMultiplePortCommonUse.png" style="zoom:30%" />
 
 
 
 分用：UDP 多端口分用是指在 UDP  通信中，可以通过一个应用程序或服务同时监听和处理多个不同的 UDP 端口。这种技术允许一个应用程序在同一时间接收来自多个不同 UDP 端口的数据包，并根据端口信息来区分和处理这些数据。通过 UDP 多端口分用，一个应用程序可以灵活地处理多个 UDP 端口上的数据，实现更高效的网络通信和数据处理
 
-<img src="./../assets/UDPMultiplePortDivideUse.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/UDPMultiplePortDivideUse.png" style="zoom:30%" />
 
 #### 差错检测
 
@@ -137,7 +137,7 @@ HTTP/1.0 为每次 HTTP 请求/相应都建立一条新的 TCP 链接。因此
 
 #### 为什么需要3次握手？
 
-<img src="./../assets/TCPThressTimesBuild.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPThressTimesBuild.png" style="zoom:30%" />
 
 
 
@@ -168,7 +168,7 @@ HTTP/1.0 为每次 HTTP 请求/相应都建立一条新的 TCP 链接。因此
 
 #### 为什么需要4次挥手
 
-<img src="./../assets/TCPFourTimesUnBuild.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPFourTimesUnBuild.png" style="zoom:30%" />
 
 
 
@@ -211,13 +211,13 @@ HTTP/1.0 为每次 HTTP 请求/相应都建立一条新的 TCP 链接。因此
 
 - 无差错情况
 
-  <img src="./../assets/TCPStopAndWaitProtocolNormal.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPStopAndWaitProtocolNormal.png" style="zoom:30%" />
 
   这张图是正常传输的情况。没有发生任何错误
 
 - 超时重传
 
-  <img src="./../assets/TCPStopAndWaitProtocolResendWhenTimeout.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPStopAndWaitProtocolResendWhenTimeout.png" style="zoom:30%" />
 
   这张图是一个超时重传的情况。客户端给服务端发送了 M1 分组报文，由于网络环境比较差，丢失或者滞留，或者被劫持了篡改了，当劫持篡改的情况下服务端接收到 M1 后，会判断篡改后丢弃该报文。在期许的时间内，客户端没有收到分组报文 M1 的确认，认为发生了超时。触发重传机制。然后启动一个分组报文 M1 的重传，此时网络正常，服务端收到 M1，并发送确认给客户端。客户端收到确认报文后，再发送 M2...
 
@@ -227,13 +227,13 @@ HTTP/1.0 为每次 HTTP 请求/相应都建立一条新的 TCP 链接。因此
 
 - 确认丢失
 
-  <img src="./../assets/TCPStopAndWaitProtocolAckMiss.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPStopAndWaitProtocolAckMiss.png" style="zoom:30%" />
 
   客户端发送一个分组报文 M1，服务端收到后发送一个确认报文，但这个确认报文丢失了。此时客户端依旧通过超时定时器，判断在期许的时间内没有收到来自服务端的确认报文，触发超时重传策略。重新发送分组报文 M1，服务端收到 M1 后，由于服务端已经接收过分组报文 M1 了，此时服务端做2件事：丢失重传的 M1 报文；重传确认 M1 报文。客户端收到 M1 确认报文，然后继续发送 M2...
 
 - 确认迟到
 
-  <img src="./../assets/TCPStopAndWaitProtocolAckLater.png" style="zoom:30%" />
+  <img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPStopAndWaitProtocolAckLater.png" style="zoom:30%" />
 
   客户端发送 M1 报文，服务端收到 M1 后发送确认报文，但是由于网络情况不好，传输较慢，客户端在期许时间范围内没有收到确认报文。客户端在超时定时器的作用下，判断超时，触发重传策略。重新发送报文 M1，服务端收到重传的 M1 后，由于服务端之前已经接受过 M1 报文，所以做2件事情：丢弃重传的 M1 报文；重传 M1 确认报文。
 
@@ -246,7 +246,7 @@ HTTP/1.0 为每次 HTTP 请求/相应都建立一条新的 TCP 链接。因此
 #### 面向字节流
 TCP 不像 UDP 那样一个个报文独立传输，而是在不保留报文边界的情况下以字节流方式进行传输。
 
-<img src="./../assets/TCPOrientedByteBuffer.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPOrientedByteBuffer.png" style="zoom:30%" />
 
 发送方在进行数据发送的时候，在 TCP 层面会有一个发送缓存。接收方也有一个接收缓存。
 
@@ -279,14 +279,14 @@ TCP 不像 UDP 那样一个个报文独立传输，而是在不保留报文边
 
 从左到右，字节编号，序号逐渐增大。
 
-<img src="./../assets/TCPWindowElement.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPWindowElement.png" style="zoom:30%" />
 
 - 可用窗口，主要是尽快要发送的部分
 - 重传队列，主要是发送但未被确认的部分
 
 当发送但未被确认的部分，收到确认之后，窗口将进行合拢。假设 7、8、9 被发送后，变成下面的状态
 
-<img src="./../assets/TCPWindowMove.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPWindowMove.png" style="zoom:30%" />
 
 7、8、9变成了发送未被确认的状态，10、11、12变成了需要尽快发送的状态，窗口右移。
 
@@ -302,7 +302,7 @@ TCP 不像 UDP 那样一个个报文独立传输，而是在不保留报文边
 
 在接收方侧：
 
-<img src="./../assets/TCPWindowProcess.png" syle="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPWindowProcess.png" syle="zoom:30%" />
 
 
 
@@ -322,7 +322,7 @@ TCP 不像 UDP 那样一个个报文独立传输，而是在不保留报文边
 
 ##### 慢开始、拥塞避免
 
-<img src="./../assets/TCPCongestionControl.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPCongestionControl.png" style="zoom:30%" />
 
 
 
@@ -342,7 +342,7 @@ TCP 实现可靠传输依赖的是 **超时重传** 机制。TCP 在发送完数
 
 这个是默认的情况，但是传输效率还是有点低，所以 TCP 为了更高的效率，采取了快重传机制。什么是快重传？
 
-<img src="./../assets/TCPQuickResendSample.png" style="zoom:30%" />
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPQuickResendSample.png" style="zoom:30%" />
 
 - 左边是发送方，右边是接收方
 - 发送了序号为1的报文后，接收方收到，回复了一个 ACK2 的报文，ACK2 的意思就是“我收到报文1了，接下来我希望收到序号为2的报文”
@@ -366,7 +366,7 @@ TCP 实现可靠传输依赖的是 **超时重传** 机制。TCP 在发送完数
 
 ##### 快恢复
 
-<img src="./../assets/TCPSlipWindowProcess.png"  style="zoom:40%"/>
+<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/TCPSlipWindowProcess.png"  style="zoom:40%"/>