noham/knowledge-kit
1
0
Fork 0
mirror of https://github.com/NohamR/knowledge-kit.git synced 2026-05-25 04:17:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

feature: App 逆向防护

Browse Source
This commit is contained in:
杭城小刘
2024-07-15 20:03:01 +08:00
parent 13f7457be9
commit 83fefff66b
109 changed files with 2549 additions and 672 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
Chapter5 - Network/5.2.md
View File

@@ -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%"/>