feature: dyld && LD 链接器

Chapter5 - Network/5.1.md

@@ -143,6 +143,87 @@ TCP 会利用另一种机制来解决超时重传带来的时间等待问题，
 
 - 当 RW < CW 时，速度由 RW 决定
 
+
+
+## HTTP 特点及解决方案
+
+### 无连接
+
+因为 HTTP 无连接，客户端和服务端交互的时候，打开一个 TCP 连接，然后交互，然后关闭 TCP 连接。下次需要交互的时候，继续打开一个 TCP 连接，继续交互，最后又关闭 TCP 连接。
+
+<img src="./../assets/ HTTPContinuesousLink.png" style="zoom:40%" />
+
+
+
+为了解决该问题，HTTP 推出持久连接方案。
+
+涉及哪些头部字段？
+
+- `Connection: keep-alive`：客户端期许使用持久连接
+- `time: 20`：20s 内不会进行四次挥手关闭。20s 内发送请求会复用之前的 TCP 连接
+- `max： 10`：最多可以发送多少个请求和响应对。
+
+怎么样判断一个请求是否结束了？2个方案
+
+- 服务端响应的时候会在 header 中携带  `Content-length: 1024`  如果接受到的数据字节数大小，等于 `Content-length` 则说明已经全部接受完毕。  
+- `chunked` ：使用 post 请求的时候，服务端返回给客户端是通过多个块返回的。每个报文都带有 chunked 这个字段，最后一个报文会带一个空的 chunked。
+
+
+
+### 无状态 - Cookie/Session
+
+Session、Cookie 都是针对 HTTP 协议无状态特点的补偿。
+
+
+
+#### Cookie
+
+Cookie 主要用来记录用户状态，区分用户；状态保存在客户端。
+
+<img src="./../assets/CookieLifeCycle.png" style="zoom:30%" />
+
+客户端请求服务端的时候，服务端生成 Cookie，通过 HTTP 响应报文，Header 部分中 `Set-Cookie` 首部字段设置 Cookie。
+
+- 客户端发送的 Cookie 在 HTTP 请求报文的 `Cookie` 首部字段中
+- 服务端设置 HTTP 的响应报文 `Set-Cookie` 首部字段
+
+
+
+怎么修改 Cookie？
+
+新 Cookie 覆盖旧 Cookie。
+
+覆盖规则：name、path、domain 等需要与原 Cookie 一致。
+
+怎么删除 Cookie？
+
+- 新 Cookie 覆盖旧 Cookie。覆盖规则：name、path、domain 等需要与原 Cookie 一致。
+- 设置 Cookie 的过期时间在过去。比如 `expires = 过去的一个时间点`，或者 `maxAge = 0`
+
+怎么保证 Cookie 的安全？
+
+- 对 Cookie 进行加密处理
+- 只在 HTTPS 上携带 Cookie
+- 设置 Cookie 为 httponly，防止跨站脚本攻击
+
+
+
+#### Session
+
+Session 也用来记录用户状态，区分用户。只不过状态保存在服务端。
+
+Session 需要依赖于 Cookie 机制。
+
+<img src="./../assets/SessionWorkflow.png" style="zoom:30%" />
+
+
+
+
+
+
+
+
+
 ## HTTP 缓存控制
 
 缓存（Cache）是计算机领域里的一个重要概念，是优化系统性能的利器。
@@ -247,7 +328,7 @@ ETag 即 Entity Tag，代表资源的唯一标识。主要用来解决修改时
 
 代理体现在头信息上就是字段 `Via`，是一个通用字段，请求头或响应头里都可以出现。每当报文经过一个代理节点，代理服务器就会把自身的信息追加到字段的末尾，就像是经手人盖了一个章。如果通信链路中有很多中间代理，就会在 Via 里形成一个链表，这样就可以知道报文究竟走过了多少个环节才到达了目的地。
 
-![](/Users/lbp/Desktop/GitHub/knowledge-kit/assets/HTTPProxyVia.png)
+![](./../assets/HTTPProxyVia.png)
 
 `X-Forwarded-For` 的字面意思是“为谁而转发”，形式上和“Via”差不多，也是每经过一个代理节点就会在字段里追加一个信息。但“Via”追加的是代理主机名（或者域名），而“X-Forwarded-For”追加的是请求方的 IP 地址。所以，在字段里最左边的 IP 地址就是客户端的地址
 
@@ -284,7 +365,7 @@ Host: www.xxx.com\r\n
 
 HTTP 传输链路上，不只是客户端有缓存，服务器上的缓存也是非常有价值的，可以让请求不必走完整个后续处理流程，"就近"获得响应结果。特别是对于那些“读多写少”的数据，例如突发热点新闻、爆款商品的详情页，一秒钟内可能有成千上万次的请求。即使仅仅缓存数秒钟，也能够把巨大的访问流量挡在外面，让 RPS（request per second）降低好几个数量级，减轻应用服务器的并发压力，对性能的改善是非常显著的。
 
-![](/Users/lbp/Desktop/GitHub/knowledge-kit/assets/CacheProxyServer.png)
+![](./../assets/CacheProxyServer.png)
 
 代理服务器没有缓存的时候：代理服务器每次直接转发来自客户端的报文给服务端，转发服务端的报文给客户端，中间不会存储任何数据，只有基础的中转功能。
 
@@ -316,7 +397,7 @@ HTTP 传输链路上，不只是客户端有缓存，服务器上的缓存也是
 
 下图是完整的服务器端缓存控制策略，可以同时控制客户端和代理
 
-![](/Users/lbp/Desktop/GitHub/knowledge-kit/assets/CacheControlPipeline.png)
+![](./../assets/CacheControlPipeline.png)
 
 ### 客户端的缓存控制
 
@@ -374,6 +455,124 @@ Range：bytes=20-39 //：从第20个字节到第39个字节之间的数据
 - 先发送一个 HEAD 方法的请求，知道总文件大小（Content-Length 就是总字节大小）
 - 多线程下载（线程1:Range:bytes=0-100，线程2:Range:bytes=100-200,...）
 
+
+
+## Charles 抓包原理
+
+抓包原理其实就是：HTTP 中间人攻击。
+
+
+
+
+
+## DNS 解析
+
+域名到 IP 地址的映射，DNS 解析请求采用 UDP 数据报，且明文传输。
+
+
+
+### DNS 解析方式
+
+DNS 解析查询方式：
+
+- 递归查询，核心就是“我去给你问一下”
+
+  <img src="./../assets/DNSRecursiveQuery.png" style="zoom:30%" />
+
+  客户端根据网址去请求服务器之前，会先获取 IP 地址信息。
+
+  - 先去本地 DNS 服务器，本地 DNS 服务器可以处理结果（根据域名对应到 IP 数据）则直接返回给客户端
+  - 如果不能解析，则会去请求根域 DNS 服务器，根域 DNS 告诉本地 DNS“你先等一下，我去问问顶级 DNS”
+
+- 迭代查询，核心就是“我告诉你谁可能知道”
+
+  <img src="./../assets/DNSIteratorQuery.png" style="zoom:30%" />
+
+  - 客户端发送请求的时候问一下本地 DNS 服务器，该域名对应的 IP 地址是什么，本地 DNS 服务器说“我不知道，你去问问根域名服务器，它可能知道”
+
+  - 然后客户端去问根域 DNS 服务器，根域 DNS 服务器说“我也不知道，你去问问顶级 DNS 服务器，它可能知道”
+
+  - 然后客户端去问顶级 DNS 服务器，顶级 DNS 服务器说“我也不知道，你去问问权限 DNS 服务器，它可能知道”
+
+  - 然后权限 DNS 服务器把域名对应的 IP 告诉客户端，客户端拿到 IP 后去请求
+
+
+
+#### DNS 解析存在哪些常见问题
+
+最容易遇到：DNS 劫持问题、DNS 解析转发问题
+
+#### DNS 劫持问题
+
+##### 什么是 DNS 劫持
+
+<img src="./../assets/DNSHacker.png" style="zoom:30%" />
+
+
+
+由于 DNS 解析是采用 UDP 数据包、明文传输，所以很容易遇到中间人攻击，也就是 DNS 劫持。
+
+
+
+QA：DNS 劫持和 HTTP 的关系是什么？
+
+**DNS 劫持和 HTTP 是没有关系的**。
+
+- DNS 解析是发生在 HTTP 连接建立前
+- DNS 解析请求采用 UDP 数据报，端口为53
+
+
+
+
+
+##### 如何解决 DNS 劫持问题
+
+- httpDNS
+
+  从“使用 DNS 协议向 DNS 服务器的53端口请求” 变成“使用 HTTP 协议向 HTTP 服务器的80端口请求”
+
+  <img src="./../assets/HTTPDNSServerProcess.png" style="zoom:25%" />
+
+  客户端通过 IP 直连的方式，向 DNS 服务器，通过 HTTP Get 请求的方式，携带域名参数，然后响应一个具体的 IP 地址值给客户端。剩余流程就是拿着请求后的 IP 地址去完成其他逻辑。
+
+- 长连接
+
+  <img src="./../assets/LongConnectionAvoidDNSHacker.png" style="zoom:30%" />
+
+  在客户端和业务服务器之间，建立一个长连接 Server，可以理解成代理服务器。
+
+  客户端和长连接 Server 建立一个长连接通道。客户端可以发送一个 HTTP 请求，通过长连通道将 HTTP 请求发送给长连 Server。
+
+  长连 Server 可以通过内网专线的方式，进行 HTTP 的请求和响应。也就是说 DNS 解析这步还存在，只不过是发生在内网专线阶段，避免了在外部公网阶段，DNS 劫持的问题。
+
+  
+
+
+
+#### DNS 解析转发
+
+<img src="./../assets/DNSParseRedirect.png" style="zoom:20%" />
+
+比如某移动 App 发起网络请求，移动 DNS 服务器为了节省资源，将请求转发到某电信 DNS 服务器，用于帮助移动 DNS 服务器，解析域名，获取对应的 IP 地址。
+
+这个电信 DNS 服务器，会向权威 DNS 服务器去请求解析域名对应的 IP 地址。
+
+权限 DNS 会根据不同运营商请求情况（网络请求）的流量调度分发：
+
+移动返回是2.2.2.2，电信返回是3，3，3，3，这种情况下，客户端在通过电信网络请求移动 DNS 服务器，进而转发到电信 DNS 服务器之后，权威 DNS 会返回3.3.3.3，也就是客户端在移动环境，由于 DNS 解析转发，而返回的 DNS 是3.3.3.3的电信环境，造成了跨网访问的效率问题
+
+
+
+
+
+
+
+
+
+
+
+
+
 ## HTTPS 安全
 
 HTTP 的缺点之一就是：明文 + 不安全。为此诞生了 HTTPS 协议。
@@ -1115,4 +1314,4 @@ HTTP/3 没有指定默认的端口号，也就是说不一定非要在 UDP 的 8
 
 ## 参考资料
 
-- [HTTP/2 协议-HPACK（HTTP2 头部压缩算法）原理介绍_爱因诗贤的博客-CSDN博客_hpack算法](https://blog.csdn.net/qq_38937634/article/details/111410191)
+- [HTTP/2 协议-HPACK（HTTP2 头部压缩算法）原理介绍_爱因诗贤的博客-CSDN博客_hpack算法](https://blog.csdn.net/qq_38937634/article/details/111410191)