mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-24 20:00:37 +00:00
feat: 初始化
This commit is contained in:
杭城小刘
34
第五部分 开发杂谈/5.1.md
Normal file
34
第五部分 开发杂谈/5.1.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: 开始hexo博客之旅
|
||||
date: 2017-10-10 14:04:27
|
||||
tags: home
|
||||
---
|
||||
|
||||
|
||||
### 首先列一下关键的几个步骤，网站的教程特别多。要看的自己搜一搜
|
||||
|
||||
1、下载安装node环境
|
||||
2、本机配置git环境
|
||||
3、node安装hexo环境
|
||||
4、下载自己细化的主题，我选择的是next主题
|
||||
5、更改next主题文件夹下的 _config.yml 文件，做一些常用设置的更改
|
||||
6、开始写文章，格式采用markdown语法，写完后发布一下 hexo d
|
||||
|
||||
|
||||
### 开启订阅
|
||||
|
||||
1、下载安装hexo插件 npm install hexo-generator-feed --save
|
||||
2、修改根目录_config.yml配置
|
||||
```
|
||||
# RSS
|
||||
plugin: hexo-generator-feed
|
||||
#Feed Atom
|
||||
feed:
|
||||
type: atom
|
||||
path: atom.xml
|
||||
limit: 20
|
||||
```
|
||||
3、修改主题_config.yml配置
|
||||
```
|
||||
rss: /atom.xml
|
||||
```
|
||||
84
第五部分 开发杂谈/5.10.md
Normal file
84
第五部分 开发杂谈/5.10.md
Normal file
@@ -0,0 +1,84 @@
|
||||
# Charles 抓包原理
|
||||
|
||||
> HTTPS(Hyper Text Transfer Protocol Secure)，是一种基于SSL/TLS的HTTP，所有的HTTP数据都是在SSL/TLS协议封装之上进行传输的。HTTPS协议是在HTTP协议的基础上，添加了SSL/TLS握手以及数据加密传输，也属于应用层协议。所以，研究HTTPS协议原理，最终就是研究SSL/TLS协议。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 运行过程
|
||||
|
||||
我们都知道HTTPS在保证数据安全传输上使用了加密算法，但是具体是如何加密的，或许许多人和我一样也是云里雾里。
|
||||
实际上SSL/TLS协议的基本思路是非对称加密和对称加密结合来传输数据，**一言以弊之，HTTPS是通过一次非对称加密算法（如RSA算法）进行了协商密钥的生成与交换，然后在后续通信过程中就使用协商密钥进行对称加密通信**，之所以要使用这两种加密方式的原因在于非对称加密计算量较大，如果一直使用非对称加密来传输数据的话，会影响效率。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### 1. HTTPS请求
|
||||
|
||||
这个步骤是整个通信过程中的第一步，首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，在这一步中，客户端主要向服务器提供以下信息：
|
||||
|
||||
- 支持的协议版本，比如TLS 1.0版
|
||||
- 一个客户端生成的随机数RandomC，稍后用于生成**“协商密钥”**。
|
||||
- 支持的加密方法，比如RSA公钥加密。
|
||||
- 支持的压缩方法。
|
||||
|
||||
#### 2. 服务器响应
|
||||
|
||||
服务器收到客户端请求后，向客户端发出回应，服务器的回应一般包含以下内容：
|
||||
|
||||
- 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
|
||||
- 一个服务器生成的随机数RandomS，稍后用于生成*“协商密钥”**。
|
||||
- 从客户端支持的加密方法中选择一个作为确认要使用的加密方法，比如RSA公钥加密。
|
||||
- 服务器证书。
|
||||
这个服务器证书就是表明服务器身份的东西，其中也包含了非对称加密中需要使用的公钥。
|
||||
|
||||
#### 3. 证书校验、生成密码、公钥加密
|
||||
|
||||
客户端收到服务器回应以后，首先验证服务器返回的证书。如果证书不是可信机构颁发，或者证书中的域名与实际域名不一致，或者证书已经过期，以浏览器为例客户端会向网页访问者显示一个警告，由其选择是否还要继续通信。 如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后生成密码、公钥加密。
|
||||
生成密码的过程会先产生一个随机数Pre-master key，该随机数是整个握手阶段出现的第三个随机数，稍后会经过公钥加密发送到服务端，有了它以后，客户端和服务器就同时有了三个随机数——RandomC，RandomS，Pre-master key，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把“协商密钥”。
|
||||
|
||||
#### 4. 加密信息C-S
|
||||
|
||||
加密信息是指上面一步生成的内容，主要包括
|
||||
|
||||
- 一个随机数Pre-master key。用于给服务端生成“协商密钥”。
|
||||
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
|
||||
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项通常也是前面发送的所有内容的hash值，用来供服务器校验。
|
||||
|
||||
#### 5. 私钥解密、解密握手消息、验证Hash
|
||||
|
||||
服务器收到客户端公钥加密的第三个随机数Pre-master key之后，通过自身私钥解密该数值并由之前的RandomC和RandomS计算生成本次会话所用的“会话密钥”。然后，通过约定的Hash算法验证客户端发送的数据完整性。
|
||||
|
||||
#### 6. 加密信息S-C
|
||||
|
||||
主要是指
|
||||
|
||||
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
|
||||
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发生的所有内容的hash值，用来供客户端校验。
|
||||
|
||||
#### 7. 解密握手消息、验证Hash
|
||||
|
||||
客户端解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束。
|
||||
|
||||
#### 8. 正常加密通信
|
||||
|
||||
握手成功之后，所有的通信数据将由之前协商密钥及约定好的算法进行加密解密。
|
||||
|
||||
# Charles抓HTTPS包原理
|
||||
|
||||
Charles本身是一个协议代理工具，如果只是普通的HTTP请求，因为数据本身没经过再次加密，因此作为代理可以知道所有客户端发送到服务端的请求内容以及服务端返回给客户端的数据内容，这也就是抓包工具能够将数据传输内容直接展现出来的原因。对于HTTPS请求，4，6，8步骤的数据都已经经过了加密，代理如果什么都不做的话是无法获取到其中的内容的。为了实现这个过程的数据获取，Charles需要做的事情是对客户端伪装服务端，对服务端伪装客户端，具体
|
||||
|
||||
- 截获真实客户端的HTTPS请求，伪装客户端向真实服务端发送HTTPS请求
|
||||
- 接受真实服务器响应，用Charles自己的证书伪装服务端向真实客户端发送数据内容
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
145
第五部分 开发杂谈/5.2.md
Normal file
145
第五部分 开发杂谈/5.2.md
Normal file
@@ -0,0 +1,145 @@
|
||||
|
||||
|
||||
> 在日常中，find的使用频率很高，熟练掌握对提供工作效率很有帮助。
|
||||
|
||||
语法:
|
||||
|
||||
```
|
||||
find(选项)(参数)
|
||||
```
|
||||
|
||||
1、列出当前目录以及目录下的所有文件
|
||||
|
||||
```
|
||||
find .
|
||||
```
|
||||
|
||||
2、找到当前目录下名字为 11.png 的文件
|
||||
|
||||
```
|
||||
find . -name "11.png"
|
||||
```
|
||||
|
||||
3、找到当前目录下所有的 jpg 文件
|
||||
|
||||
```
|
||||
find . -name "*.jpg"
|
||||
```
|
||||
|
||||
4、找到当前目录下的 jpg 文件和 png 文件
|
||||
|
||||
```
|
||||
find . -name "*.jpg" -o -name "*.png"
|
||||
```
|
||||
|
||||
5、找到当前目录下不是以 png 结尾的文件
|
||||
|
||||
```
|
||||
find . ! -nam "*.png"
|
||||
```
|
||||
|
||||
6、根据正则表达式查找
|
||||
|
||||
比如：查找当前目录下，文件名都是数字的 png 文件
|
||||
|
||||
```
|
||||
find . -regex "\./*[0-9]+\.png"
|
||||
```
|
||||
|
||||
7、根据路径查找
|
||||
|
||||
找到当前目录下路径中包含 swj 的文件/路径
|
||||
|
||||
```
|
||||
find . -path "*swj*"
|
||||
```
|
||||
|
||||
8、根据文件类型查找
|
||||
|
||||
查找当前目录下，路径包含 swj 的文件
|
||||
|
||||
```
|
||||
find . -type f -path "*swj*"
|
||||
```
|
||||
|
||||
9、限制搜索深度
|
||||
|
||||
查找当前目录下所有的 png，不包括字目录
|
||||
|
||||
```
|
||||
find . -maxdepth 1 -name "*.png"
|
||||
```
|
||||
|
||||
相应的， mindepth 也是选项
|
||||
|
||||
```
|
||||
find . -mindepth 2 -name "*.png"
|
||||
```
|
||||
|
||||
10、根据文件大小
|
||||
|
||||
通过 -size 来过滤文件大小，支持的单位如下
|
||||
|
||||
* b - 块（512字节）
|
||||
* c - 字节
|
||||
* w - 字 （2字节）
|
||||
* k - 千字节
|
||||
* M - 兆字节
|
||||
* G - 吉字节
|
||||
|
||||
找出当前目录下文件大小超过 100M 的文件
|
||||
|
||||
```
|
||||
find . -type f -size +100M
|
||||
```
|
||||
|
||||
11、根据访问/修改/变化时间
|
||||
|
||||
* 访问时间（-atime/天，-amin/分钟）：用户最近一次访问时间
|
||||
* 修改时间 （-mtime/天， -mmin/分钟）： 文件最后一次修改时间
|
||||
* 变化时间 （-ctime/天， -cmin/分钟）：文件数据元（例如权限的过）最后一次修改时间
|
||||
|
||||
找出 1天内被修改过的文件
|
||||
|
||||
```
|
||||
find . -type f -mtime -1
|
||||
```
|
||||
|
||||
找出最近1周内被访问过的文件
|
||||
|
||||
```
|
||||
find . -type f -atime -7
|
||||
```
|
||||
|
||||
12、根据权限
|
||||
|
||||
通过 -perm 来实现
|
||||
|
||||
找出当前目录下权限为777的文件
|
||||
|
||||
```
|
||||
find . -type f -perm 777
|
||||
```
|
||||
|
||||
找出当前目录下权限不是644的php文件
|
||||
|
||||
```
|
||||
find . -type f -name "*.php" ! -perm 644
|
||||
```
|
||||
|
||||
13、根据文件拥有者
|
||||
|
||||
找出文件拥有者为 root 的文件
|
||||
|
||||
```
|
||||
find . -type f -user root
|
||||
```
|
||||
|
||||
找出文件所在群组为 root 的文件
|
||||
|
||||
```
|
||||
find . -type f -group root
|
||||
```
|
||||
|
||||
|
||||
|
||||
282
第五部分 开发杂谈/5.3.md
Normal file
282
第五部分 开发杂谈/5.3.md
Normal file
@@ -0,0 +1,282 @@
|
||||
# Charles 从入门到精通
|
||||
|
||||
## 内容清单
|
||||
|
||||
- Charles 的简介
|
||||
- 安装 Charles
|
||||
- Charles 初始化设置
|
||||
- 过滤网络请求
|
||||
- 截取HTTP/HTTPS数据
|
||||
- 模拟弱网环境
|
||||
- 修改网络请求
|
||||
- 修改服务器返回内容
|
||||
- 服务器压力测试
|
||||
- 反向代理
|
||||
- 解决与翻墙软件的冲突
|
||||
|
||||
|
||||
|
||||
## Charles 的简介
|
||||
|
||||
**Charles** 是目前最主流的网络调试工具（Charles、Fiddler、Wireshark...）之一，对于一个开发者来说与网络打交道是日常需求，因此很多时候我们需要调试参数、返回的数据结构、查看网络请求的各种头信息、协议、响应时间等等。所以了解 Charles 并使用它
|
||||
|
||||
Charles 通过将自己设置为系统的网络访问代理服务器，这样所有的网络请求都会通过它，从而实现了网路请求的截获和分析。
|
||||
|
||||
Chareles 不仅可以分析电脑本机的网络请求（HTTP 和 HTTPS），还可以分析移动端设备的网络请求。
|
||||
|
||||
Charles 是收费软件，作者开发出这样一个方便开发者使用的伟大工具，我们鼓励使用正版软件，但是对于一些囊中羞涩或者学生来说，有破解版的更好，别担心，这些我都准备好了，下一个 section 会讲解如何下载安装。
|
||||
|
||||
|
||||
|
||||
## 安装 Charles
|
||||
|
||||
- 方式1：[ Charles 官网地址](https://www.charlesproxy.com/download/)，根据你的电脑操作系统选择合适的下载方式。此时下载下来的是需要收费的，不差钱的同学当然可以直接购买。[购买链接](https://www.charlesproxy.com/buy/)
|
||||
- 方式2:按照方式1的方式去官网下载，然后下载相应 **[JAR包](https://pan.baidu.com/s/1QqSiEwMGIFrxwyKYg_6Kdw)**。这里以 MAC 为例，打 **Finder**，选择应用程序，选中 Charles，右击并选择“显示包内容”，看到 **Contents** 目录，点击进去选择 **Java** 文件夹，将下载下来的 **JAR包** 拖进去替换。至此，完成了 Charles 的破解。
|
||||
|
||||
|
||||
|
||||
## Charles 初始化设置
|
||||
|
||||
Charles 的工作原理是将自身设置为系统的代理服务器来捕获所有的网络请求。所以使用 Charles ，我们必须设置 Charles 为系统的代理服务器。
|
||||
|
||||
打开 Charles，当第一次启动的时候如果没有购买或者没有破解，会有倒计时，之后会看到软件的主界面，然后会请求你赋予它为系统代理的权限。点击授权会让你输入当前系统用户的密码。当然你也可以忽略或者拒绝该请求，然后等想要抓包的时候将它设置为系统的代理服务器。步骤：**选择菜单中的“Proxy” -> "Mac OS X Proxy"。**如下图：
|
||||
|
||||
|
||||
|
||||
之后你的电脑上的任何网络请求都可以在 Charles 的请求面板中看到
|
||||
|
||||
|
||||
|
||||
看看 Charles 的主界面
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- 图上红色圈1:这里代表所有网络请求的展示方式。分别名为 “Structure” 和 “Sequence”。
|
||||
- Structure 将所有的网络请求按照域名划分并展示
|
||||
- Sequence 将所有的网络请求按照时间排序并展示
|
||||
- 图上红色圈2：一些的网络请求设置比如 HTTPS 以及端口等信息都在这个菜单栏设置
|
||||
- 图上红色圈3：证书设置都在这里进行
|
||||
|
||||
|
||||
|
||||
## 过滤网络请求
|
||||
|
||||
由于 Charles 可以将电脑或者设置过的手机的所有网络请求捕获到，而且我们分析网络传输应该是针对某个特定的网络下的抓包分析，为了清楚明显地看到我们感兴趣的网络请求通常会用到 Charles 的**“过滤网络请求的功能”**。
|
||||
|
||||
- 方法1:在 Charles 主面板的左侧所有网络请求的下方可以看到看到一个 **”Filter“** 输入栏，在这里你可以输入关键词来筛选出自己感兴趣的网络请求。比如我想分析的网络请求来自于”www.baidu.com" 下，你可以在下面输入"baidu"即可。
|
||||
|
||||
|
||||
- 方法2:在 Charles 菜单栏的顶部会看到 “Proxy” 的选项，点击菜单栏选择 “Proxy” -> "Recording Settings" 。选择 “include”。看到面板上面有一个 “Add” 按钮，点击后在弹出的面板里面设置好我们需要分析的网络请求的**协议、主机名、端口、路径、参数**，当然你也可以只设置一些主要的信息，比如协议和主机名的组合。
|
||||
|
||||
|
||||
|
||||
- 方法3:一般打开 Charles 并设置好配置信息后（比如电脑本机或者设置过代理的手机）所有的网络请求都将在 Charles 的面板上显示，同时我们感兴趣的网络请求如果也在面板上显示的话，**“Structure”模式下**可以选中需要分析的网络请求，鼠标右击选择**“Focus”**。**“Sequence”模式下**可以在面板的网络请求显示面板的右下角看到一个**Focus**按钮，点击勾选后 Charles 只会显示你感兴趣的网络请求。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 截取HTTP/HTTPS数据
|
||||
|
||||
### 截取 HTTP 请求
|
||||
|
||||
Charles 的主要目的是抓取捕获网络请求，这里以 iPhone 的抓包为例讲解。
|
||||
|
||||
#### Charles 的设置
|
||||
|
||||
要截获 iPhone 的网络请求就需要为 Charles 开启代理功能。在菜单栏选择**“Proxy” ->"Proxy Settings"**。填写代理的端口号并将**“Enable transparent HTTP proxying”**勾选上。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### iPhone 上的设置
|
||||
|
||||
在电脑“系统偏好设置”中心打开网络查看本机 IP 地址，打开手机“设置”->“无线局域网”，进入当前使用的网络，点击进入当前 WIFI 的详情页（可以看到当前 WIFI 的基本信息，包括子网掩码、端口、IP地址、路由器），在最下角可以看到**“DNS”和“HTTP代理”**2个section。我们点击**“配置代理”**，设置 HTTP 代理选中“手动”。服务器处填写电脑ip地址，端口写8888。设置好后，我们打开 iPhone 上的任意需要网络请求的应用，就可以看到 Charles 弹出请求的确认菜单，单击"Allow"按钮，即可完成设置。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 截取 HTTPS 请求
|
||||
|
||||
如果你需要捕获 HTTPS 协议的网络请求，那么则需要安装 Charles 的 CA 证书。步骤如下；
|
||||
|
||||
- 首先需要在 MAC 上安装证书。点击 Charles 顶部的菜单栏，选择 **“Help” -> "SSL Proxying" -> "Install Charles Root Certificate"**。
|
||||
|
||||
|
||||
|
||||
- 在 keychain 处将新安装的证书设置为永久信任
|
||||
|
||||
|
||||
- 即使安装了 CA 证书，Charles 默认是不捕获 HTTPS 协议的网络请求，所以我们需要对某个主机下的网络请求抓包分析的话，选中该网络请求右击选中 **“SSL Proxying Enabled”**。这样就可以看到我们感兴趣的HTTPS 网络请求了。
|
||||
|
||||
|
||||
|
||||
|
||||
如果你需要捕获移动设备的 HTTPS 网络请求，则需要在移动设备上安装证书并作简单的设置
|
||||
|
||||
- 选择 Charles 顶部菜单栏选择 **“Help” ->"Install Charles Root Certificate on a Mobile Device or Remote Browser"**。然后就可以看到 Charles 弹出的安装说明了。
|
||||
|
||||
|
||||
|
||||
- 在手机设置好 Charles 代理的情况下，在手机浏览器输入 **“chls.pro/ssl”**。安装提示下载好**CA证书**。
|
||||
|
||||
- 验证刚刚安装的 CA证书
|
||||
|
||||
|
||||
- iPhone 打开设置 -> 通用 -> 关于本机 -> 证书信任设置 -> 开启开关
|
||||
|
||||
|
||||
|
||||
- 在 Charles 菜单栏 Proxy -> SSL Proxying Setting -> 点击 Add 按钮 -> 在弹出的对对话框设置需要监听的 HTTPS 域（*:代表通配符）
|
||||
|
||||
|
||||
- 设置完毕，尽情抓取你想要的 HTTPS 网络请求吧。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 模拟弱网环境
|
||||
|
||||
在平时开发的时候我们经常需要模拟弱网环境，并作弱网环境下的适配工作。Charles 为我们提供了这个服务。
|
||||
|
||||
在 Charles 菜单栏选择 **“Proxy” -> "Throttle Settings"**。在弹出的面板上设置网络请求的参数（上行，下行带宽、利用率、可靠性等等信息）。如下图所示。
|
||||
|
||||
|
||||
|
||||
|
||||
如果你想对**指定主机**进行弱网环境下的测试，可以点击上图的“Add”按钮，在弹出的面板上设置协议、主机、端口来对指定的主机进行弱网设置。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 修改网络请求
|
||||
|
||||
|
||||
对于捕获的网络请求，我们经常需要修改网络请求的cookie、Headers、Url等信息。Charles 提供了对网络请求的编辑和重发功能。只需要选中需要修改编辑的网络请求，在对应的右上角看到有一个“钢笔”的按钮，点击后就可以对选中的网络请求进行编辑了，编辑好后可以在右下角看到 **Execute** 按钮。这样我们编辑后的网络请求就可以被执行了。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 修改服务器返回内容
|
||||
|
||||
很多时候为了方便调试代码，我们会有这种需求，修改接口返回的数据节点或者内容、甚至是状态码。比如数据为空、数据异常、请求失败、多页数据的情况。 Charles 为我们提供了超实用的功能，**“Map（Map Local、Map Remote）功能”、Rewrite功能、Breakpoints功能** ，都可以实现修改服务端返回数据的功能。但是有区别和适用场景：
|
||||
|
||||
- Map 功能适合长期地将某一请求重定向到另一个指定的网络地址或者本地 JSON 文件
|
||||
- Rewrite 功能适合对网络请求进行一些正则替换
|
||||
- Breakpoints 功能适合对网络请求进行一些临时性的修改（类似于我们开发的断点作用）
|
||||
|
||||
### Map 功能
|
||||
|
||||
Map 功能分为 Map Local（将某个网络请求重定向到本地 JSON 文件） 和 Map Remote 功能（将网络请求重定向到另一个网络接口）。
|
||||
|
||||
在 Charles 菜单栏选择 **“Tools” -> "Map Remote" 或 “Map Local”** 即可进入相应的功能模块。
|
||||
|
||||
|
||||
|
||||
#### Map Remote 功能
|
||||
|
||||
适合于切换线上到本地、测试服务到正式服务的场景。比如下图从正式服务切换到测试服务
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Map Local 功能
|
||||
|
||||
我们需要填写重定向的原地址信息和本地目标文件。我们可以先将某个接口的响应内容保存下来（选择对应的网络请求，右击点击 **Save Response** ）成为 data.json 文件。然后我们编辑里面的 status 、message、data 等信息为我们想要的目标映射文件。
|
||||
|
||||
|
||||
|
||||
如下所示，我将一个网络请求的内容映射到我本地的一个 JSON 文件。之后这个请求的内容都从网络变为返回我本地的数据了。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Map Local 可能会存在一个小缺陷，其返回的 HTTP Response Header 与正常的网络请求不一样，如果程序设置了校验 Header 信息，此时 Map Local 就会失败，解决办法是同时使用 **Rewrite功能**将相关的HTTP 头部信息 rewrite 成我们需要的信息
|
||||
|
||||
#### Rewrite 功能
|
||||
|
||||
Rewrite 适合对某个网络请求进行正则替换，以达到修改结果的目的。
|
||||
|
||||
假如我的 App 的界面上的显示的功能模块及其点击事件是根据接口来完成的，我想实现替换功能模块的名称的目的。步骤：点击顶部菜单栏的**“Tools” -> "Rewrite"**。在弹出的面板上勾选 **“Enable Rewrite”**。点击左下角的 **Add按钮**，在右上角的 **Name：**处写好本次配置的名称（如果有多个 Rewrite，为了后期容易区分）。
|
||||
|
||||
- 可以针对特定的网络请求进行 Rewrite。可以点击右上角 **Location** 面板下面的 **Add按钮**。在弹出的面板上设置网络请求配置信息。注意此时需要同时设置 Protocol、Port、Host、Path信息（我测试加了 Protocol、Host、Port这3个是无效的）
|
||||
|
||||
|
||||
|
||||
- 然后对指定的 **Type** 和 **Action** 进行 Rewrite。
|
||||
|
||||
Type 主要有 Add Header、Modify Header、Remove Header、Host、Path等等。
|
||||
|
||||
Where 可以选择 Request 和 Response。指的是下面的修改是针对 Request 还是 Response
|
||||
|
||||
|
||||
|
||||
- 完成设置后点击 **Apply** 按钮，即可生效。下次继续请求该网络，返回的内容就是我们刚刚设置的内容。比如当前的“政策法规”要变成“哈哈哈，我是假的政策法规”。这时候就可以使用 Rewrite 功能
|
||||
|
||||
|
||||
|
||||
#### Breakpoints 功能
|
||||
|
||||
Breakpoints 相比于其他几个修改网络请求的特点是只是针对当前的网络请求，Breakpoints 只存在于设置过的当前的网络请求，Charles 关闭后下次打开 Breakpoints 消失了。想要修改网络请求 Breakpoints 步骤最简单，跟我们调试工具里面设置的断点一样方便。
|
||||
|
||||
对于我们设置了 Breakpoints 的网络请求， Charles 会在下次继续访问该请求的时候停止掉，就跟 debug 一样。此时我们可以 **Edit Request**，修改过 Request 之后点击右下角的 **Execute** 按钮。然后等到服务端返回的时候继续是断点状态，此时可以 **Edit Response**。步骤： **选中某个网络请求 -> 右击 -> 点击“Breakpoints”。**
|
||||
|
||||
如下图：对该接口设置了 Breakpoints。请求网络后 Edit Response，点击 execute 后服务端返回的结果就是我们编辑的内容了。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 服务器压力测试
|
||||
|
||||
我们可以使用 Charles 的 **Repeat** 功能地对服务器进行并发访问进行压力测试。步骤：**选中某个网络请求 -> 右击 -> Repeat Advanced -> 在弹出的面板里面设置总共的迭代次数（Iterations）、并发数（Concurrency） -> 点击“OK” 。**开始执行可以看到以设置的并发数的规模，进行总共达设置的总共迭代次数的访问。（专业的压力测试工具：**Load Runner**）
|
||||
|
||||
|
||||
|
||||
|
||||
## 反向代理
|
||||
|
||||
Charles 的反向代理功能允许我们将本地指定端口的请求映射到远程的另一个端口上。设置：**点击顶部菜单栏 Proxy -> 点击 Reverse Proxies**。
|
||||
|
||||
如下所示，我将本地的 8080 端口映射到远程的 80 端口上，点击 OK 生效后，当我继续访问本地的 80 端口，实际返回的就是远程 80 端口的提供的内容了。
|
||||
|
||||
|
||||
|
||||
|
||||
## 解决与翻墙软件的冲突
|
||||
|
||||
Charles 的工作原理是把自己设置为系统的代理服务器，但是我们开发者经常会利用 VPN 翻墙访问谷歌查找资料（这些翻墙软件的工作原理也是把自己设置成为系统的代理服务器），为了2者和平共处。我们可以在 Charles 的 External Proxy Settings 中将翻墙的代理端口等信息填写。同时我们需要关闭翻墙软件的自动设置，更改为**“手动模式”**。（使其不主动修改系统代理）
|
||||
|
||||
|
||||
|
||||
## 总结
|
||||
|
||||
Charles 功能强大、界面简洁，读完这篇文章并做出练习，相信你能很快掌握它，“工欲善其事，必先利其器” ，掌握了它，相信可以为你大大提高开发中调试网络的效率。**Enjoy yourself**
|
||||
|
||||
## 参考链接
|
||||
[唐巧的博客](http://blog.devtang.com/2015/11/14/charles-introduction/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
30
第五部分 开发杂谈/5.4.md
Normal file
30
第五部分 开发杂谈/5.4.md
Normal file
@@ -0,0 +1,30 @@
|
||||
### git常见使用
|
||||
|
||||
```
|
||||
http://blog.csdn.net/wirelessqa/article/details/20153689
|
||||
```
|
||||
|
||||
1. git init
|
||||
2. git add .
|
||||
3. git commit -am "\#\#\#"
|
||||
4. git remote add origin git@xx.xx.xx.xx:repos/xxx/xxx/xxx.git
|
||||
5. git push origin 本地分支:远程分支
|
||||
fatal: refusing to merge unrelated histories
|
||||
决办法：git pull origin master --allow-unrelated-histories
|
||||
|
||||
|
||||
|
||||
### 创建新版本
|
||||
|
||||
* 从现有的分支创建新分支
|
||||
* git checkout -b dev
|
||||
* 将新创建的分支提交到远端
|
||||
* git push origin dev
|
||||
* 提交代码
|
||||
* git add .
|
||||
* git commit -m 'add a new branch named dev'
|
||||
* git pull origin dev
|
||||
* git push origin dev
|
||||
|
||||
|
||||
|
||||
125
第五部分 开发杂谈/5.5.md
Normal file
125
第五部分 开发杂谈/5.5.md
Normal file
@@ -0,0 +1,125 @@
|
||||
# chrome开发者工具各种骚技巧
|
||||
|
||||
对于每个前端从业者来说，除了F5键之外，用的最多的另外一个键就是F12了。
|
||||
|
||||
今天看了一个网站，才知道chrome还有各种骚姿势。
|
||||
|
||||
网站是：[umaar.com/dev-tips/](https://link.juejin.im/?target=https%3A%2F%2Fumaar.com%2Fdev-tips%2F)
|
||||
|
||||
所有的我都看了，这里随便列举几个个人之前不了解，觉得挺有用的。
|
||||
|
||||
### 1.曾经，在线调伪类样式困扰过你？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 2.源代码快速定位到某一行！ctrl + p
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 3.联调接口失败时，后台老哥总管你要response？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 4.你还一层层展开dom？Alt + Click
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 5.是不是报错了，你才去打断点？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 6.你是不是经常想不起来，在哪绑定事件的？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 7.你是不是打断点时还要去改代码？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 8.看dom层级的最直观的方式？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 9.查一些特定的请求，过滤器用过吗？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 10.在Elements面板调整dom结构很不方便？
|
||||
|
||||
|
||||
|
||||
|
||||
###
|
||||
|
||||
|
||||
|
||||
|
||||
### 11.想知道，某图片加载的代码在哪？Initiator！！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 12.不想加载某个文件了？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
多的就不列举了，可以看看开头的网站。看了有几个功能我电脑（win10）是没有的，也可能跟chrome版本有关。
|
||||
|
||||
开发者工具的功能确实挺多，多的有时根本用不上，官网教程建议每个前端人员都看看：
|
||||
|
||||
[developers.google.com/web/tools/c…](https://link.juejin.im/?target=https%3A%2F%2Fdevelopers.google.com%2Fweb%2Ftools%2Fchrome-devtools%2F)
|
||||
|
||||
|
||||
中文版：
|
||||
|
||||
[www.css88.com/doc/chrome-…](https://link.juejin.im/?target=http%3A%2F%2Fwww.css88.com%2Fdoc%2Fchrome-devtools%2F)
|
||||
|
||||
|
||||
本文完。
|
||||
|
||||
32
第五部分 开发杂谈/5.6.md
Normal file
32
第五部分 开发杂谈/5.6.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# Git 实用操作
|
||||
|
||||
1、合并多次提交记录
|
||||
|
||||
有的时候我们对于某个功能为了实时保存自己写的代码，可能会有多次提交，所以等功能稳定下来，我们可能会有这种需求：将前面多余几次的提交记录合并为1个记录。幸运的是 Git 为我们提供了这样的命令。
|
||||
|
||||
有2种做法
|
||||
|
||||
- 合并部分
|
||||
|
||||
- git rebase -I HEAD~n。这里的 n 代表压缩最后n次提交。执行这条命令后会弹出 vim 编辑窗口，这 n 次提交记录会倒序，最上面的是最早的提交，最下面的是最新的提交。
|
||||
|
||||
```
|
||||
pick cc77998 ...
|
||||
pick 1821f6a ...
|
||||
...
|
||||
pick 124422 ...
|
||||
```
|
||||
|
||||
我们需要修改第2到n行的 pick 为 squash，这个的意思为将最后n-1次的提交合并为1次提交。然后我们保存退出，git 会一个个压缩提交历史，如果有冲突则解决冲突就好。
|
||||
|
||||
- 完成之后我们将本地的修改提交到远端。 Git push -f
|
||||
|
||||
- 全部合并
|
||||
|
||||
```
|
||||
git rebase -i --root
|
||||
```
|
||||
|
||||
将全部的提交记录合并为1个
|
||||
|
||||
|
||||
26
第五部分 开发杂谈/5.7.md
Normal file
26
第五部分 开发杂谈/5.7.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# 短网址(short URL)系统的原理及其实现
|
||||
|
||||
> 如果不想重复的造轮子，想开箱即用，可以使用基于 PHP 的开源软件 YOURLS。YOURLS 还可以和 WordPress 整合到一起，功能强大，可扩展性高。
|
||||
|
||||
##什么是短链接 ?
|
||||
就是把普通网址，转换成比较短的网址。比如：http://t.cn/RlB2PdD 这种，在微博这些限制字数的应用里。好处不言而喻。短、字符少、美观、便于发布、传播。
|
||||
百度短网址 http://dwz.cn/
|
||||
谷歌短网址服务 https://goo.gl/ （需科学上网）号称是最快的 ?
|
||||
|
||||
##原理解析
|
||||
当我们在浏览器里输入 http://t.cn/RlB2PdD 时
|
||||
|
||||
* DNS首先解析获得 http://t.cn 的 IP 地址
|
||||
* 当 DNS 获得 IP 地址以后（比如：74.125.225.72），会向这个地址发送 HTTP GET 请求，查询短码 RlB2PdD
|
||||
* http://t.cn 服务器会通过短码 RlB2PdD 获取对应的长 URL
|
||||
* 请求通过 HTTP 301 转到对应的长 URL https://m.helijia.com 。
|
||||
这里有个小的知识点，为什么要用 301 跳转而不是 302 呐？
|
||||
|
||||
> 301 是永久重定向，302 是临时重定向。短地址一经生成就不会变化，所以用 301 是符合 http 语义的。同时对服务器压力也会有一定减少。
|
||||
但是如果使用了 301，我们就无法统计到短地址被点击的次数了。而这个点击次数是一个非常有意思的大数据分析数据源。能够分析出的东西非常非常多。所以选择302虽然会增加服务器压力，但是我想是一个更好的选择。
|
||||
|
||||
来自知乎 iammutex 的答案
|
||||
|
||||
|
||||
|
||||
|
||||
59
第五部分 开发杂谈/5.8.md
Normal file
59
第五部分 开发杂谈/5.8.md
Normal file
@@ -0,0 +1,59 @@
|
||||
## 浅谈iOS和Android后台实时消息推送的原理和区别
|
||||
|
||||
> 前言 iOS和Android上的实时消息推送差异很大，往小了说是技术实现的差异，往大了说是系统实现理念的不同。实时消息推送在移动端互联网时代很平常，也很重要，它的存在让智能终端真正成为全时信息传播的工具。本文将从原理上谈谈两个平台上实时消息推送的区别。
|
||||
|
||||
* 简要对比
|
||||
|
||||
* iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。
|
||||
|
||||
* Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。
|
||||
|
||||
* 技术原理
|
||||
|
||||
* 首先讲解下服务器如何先找到设备、再找到app的问题。
|
||||
|
||||
* 每一个设备都有一个自己的设备号，而设备中的app又都有一个唯一的包名。所以服务器只需要找到设备号与包名就可以定位到某个设备的某个应用，而这设备号与包名会一起构成一个标识符，叫做device\_token，因此问题就简化为把device\_token与消息内容等信息交给服务器，服务器把内容发到唯一的device\_token上。这就好像你在上海要通过顺丰寄送一个快件儿给某某小区的某某房间，那么快件儿首先会邮递到顺丰公司在北京的总站点，之后再根据小区的地址投递/路由到某某房间，这样一个寄件过程就算完成了。
|
||||
|
||||
* iOS 实时消息推送
|
||||
|
||||
iOS的推送是通过苹果自己的APNs服务进行的，用户需要将device\_token以及消息内容等推送信息交给APNs服务器，剩下的均由苹果自己来完成。iOS应用的推送大部分情况下都要依赖苹果生态提供的APNs（Apple Push Notification Service）服务。
|
||||
|
||||
|
||||
|
||||
首先作为设备标识的device-token是由APNs颁发的，App开发者或者第三方推送平台\(图中的Provider\)做的工作是收集这个device-token，APNs的推送是要求基于APNs颁发的device-token来推送的。只有正确的device-token会被APNs接受，如果是一个错误的、或者无效的device-token\(比如App已经卸载了\)，APNs就不会接受。
|
||||
|
||||
|
||||
|
||||
接着开发者使用第三方推送平台（图中的Provider）在将推送内容与范围选定之后进行推送，第三方推送平台将信息提交给APNs，剩下的操作全部都由APNs来进行完成，整个过程第三方推送平台就不能控制了。但是如果提供的device\_token是失效的（app被卸载、系统版本升级导致device\_token变化等情况）那么推送过程就会被中断，频繁的断线重连甚至会被APNs认为是一直DoS攻击。（[详情可以参考为什么苹果的推送，两次推送之间间隔比较久的话，第二次推送会很慢？](http://www.baidu.com)）
|
||||
|
||||
* Android 实时消息推送
|
||||
Android平台在不使用GCM的情况下就需要将自己的服务器或是第三方推送服务提供商的服务器与设备建立一条长连接，通过长连接进行推送。但是不建议自己设置服务器实现推送功能，一是因为成本太高（开发成本、维护成本），自己搭建的服务器无论是稳定性还是速度上都比不了第三方推送服务提供商的效果。另一个是因为自己的数据量较小，使用第三方推送服务提供商可以用他们的维度进行推送，实现精准推送。友盟推送就是做的比较好的，可以根据用户分群、地区、语言等多维度进行推送，最大程度减少对于用户的干扰，仅把消息推送给相关用户。
|
||||
|
||||
* 开发者通过第三方推送服务提供商将信息直接下发给需要的设备，第三方推送服务提供商与设备建立一条长连接通道，并且将消息路由到APP中（图中的设备1与设备2），对于像设备3这种无网络连接或是没有成功建立长连接通道的设备，会在设备3连网且推送消息没有过期的情况下自动收到由第三方推送服务提供商推送过来的消息，保证消息不会丢失。
|
||||
|
||||
* ## 实现上的差异所带来的直观感受
|
||||
|
||||
* ### iOS的实时消息推送
|
||||
|
||||
iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。
|
||||
|
||||
|
||||
|
||||
所以 iOS 的推送可以不严谨的理解为：
|
||||
|
||||
* 苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。
|
||||
* 然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事
|
||||
|
||||
* 然后，系统分别通知这些 Apps 。
|
||||
|
||||
带来的好处是不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。
|
||||
|
||||
* Android的实时消息推送
|
||||
Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。），大家挂后台等待推送就成为技术选择。当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。
|
||||
|
||||
用户的电池？ Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是：没人真正为用户的电池负责。
|
||||
|
||||
但是， Google 的方案也并非全是悲剧：也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。
|
||||
|
||||
|
||||
|
||||
16
第五部分 开发杂谈/5.9.md
Normal file
16
第五部分 开发杂谈/5.9.md
Normal file
@@ -0,0 +1,16 @@
|
||||
## iOS 隔了较久时间推送变得缓慢
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这个图是重点，描述了真实消息推送的过程，App开发者或者第三方推送平台的服务器\(图例中的Provider\)向APNs发起推送指令的请求，**推送指令包含了要下发设备的device-token和要下发的内容payload两部分**，由APNs根据device-token\(device-token是APNs生成颁发的\)将payload下发到设备上，再由设备路由给具体的App。我们这里只关注第一步Provider到APNs的过程，即Provider的服务器和APNs的服务器通信的过程。APNs要求Provider首先与APNs建立一条长连接，Provider通过长连接可以将单个或者一批device-token发送给APNs，这个过程中，只要有一个device-token是不合法的\(错误或者失效\)，那么APNs就会主动断掉Provider到APNs的长连接，Provider探测到连接断掉之后，需要重新建立连接，跳过上次失败的device-token，从下一个device-token接着发送。这个过程循环往复，直至将本次要发送的所有的device-token都推送到APNs，那么这次推送任务就算完成了。剩下的工作就是APNs将消息下发到具体设备了，APNs将消息下发给设备这个过程，不管是App开发者直接和APNs打交道、亦或是第三方推送服务器和APNs打交道，我们都是无法控制的了，所以推送的重点就是图例中的第一步Provider到APNs之间的通信了。
|
||||
|
||||
接下来我们回到问题，就是为什么隔了很久之后再去做推送，发送过程会变得非常慢。其实经过上面的解释，大家就应该能把原因猜的差不多了，就是因为长时间不发送的话，会有很多设备上的device-token已经无效了，比如设备卸载了App，或者系统版本升级过导致device-token变化了，或者是其它导致APNs认为device-token不合法的原因。总之，时间长了，不合法的device-token就会变多，在上面的章节中也提到，Provider和APNs的服务器建立长连接进行消息发送时，如果碰到了不合法的device-token，APNs就会断掉长连接，需要Provider重新建立连接。失效的device-token多了，那么断掉连接-重新连接的次数就会增多，每次重新连接都需要耗费时间，甚至如果频繁的断掉-重连APNs，有时候会被APNs认为是一种DoS攻击\(APNs官网这么解释，但是具体判定的算法没有透露\)，会导致短时间内APNs拒绝Provider的连接，这种情况下，不管是App开发者自己直接和APNs打交道，还是第三方推送平台和APNs打交道，碰到这种情况都是无能为力的。 只能被动的接受“断掉-重连”的工作方式，因此整个发送过程会特别缓慢。 所以总结下来，长时间不发送消息，再次发送的时候，必然会出现推送缓慢的情况，原因就是无效的device-token越来越多，导致不断的“断开-重连”。所以在本文开头的时候，就提到过如果App开发者亲自使用过APNs服务的话，对这种现象必定是非常熟悉了，也会见怪不怪了。 如果是两次发送任务之间隔得时间不是太长，两次发送期间失效device-token不是那么多的时候，速度还是比较快的。
|
||||
|
||||
那么既然失效的device-token是导致发送变慢的主要原因，那么开发者朋友们肯定会想，能不能提前判断出失效的device-token，直接从发送列表中剔除掉这些失效的token。其实APNs是提供这样的feedback接口的，调用这个接口会得到一批失效的device-token列表。那么是不是在一次发送之前去调用一下这个接口，获取到无效的device-token，在发送的过程中剔除掉这些无效的device-token就能加快发送速度呢？ 其实不然，因为feedback接口是一个后验的接口，即只有一次推送任务结束之后，APNs才会把该次失效的device-token更新到feedback接口的返回结果里面。如果你在一次推送任务前调用feedback接口，那么得到的失效device-token是基于上一次推送任务的结果的，两次推送任务之间发生的失效的device-token，是无法提前获取到的，只能等当次推送任务结束之后，才可以去获取新的失效token列表。
|
||||
|
||||
问题到这里就解释清楚了，那么碰到这种情况，我们该如何提升发送速度呢？ 这里我们给大家讲讲友盟推送平台针对这种情况做的一些优化，相比App开发者直接连接APNs做推送，还是有一定的优势:\) 解决方法很简单，就是友盟有很多台连接APNs的服务器，每个服务器我们又会开很多个线程去和APNs做连接，所以在并发度上会有较大的优势。所以针对一次发送任务，使用友盟平台做推送，速度肯定会比自己直接连接APNs有优势，这个也是不少开发者放弃了直接和APNs打交道，而是选择友盟推送来实现iOS推送的原因之一。
|
||||
|
||||
4
第五部分 开发杂谈/chapter5.md
Normal file
4
第五部分 开发杂谈/chapter5.md
Normal file
@@ -0,0 +1,4 @@
|
||||
# 第四部分
|
||||
|
||||
第四部分主要记录在开发中遇到的工具经验或者效率工具总结。
|
||||
|
||||
Reference in New Issue
Block a user