运维知识结构

worker_processes 2; # 2核CPU的配置
worker_cpu_affinity 01 10;
worker_processes 4; # 4核CPU的配置
worker_cpu_affinity 0001 0010 0100 1000;
worker_processes 8; # 8核CPU的配置
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 1000000;

四层

七层

如果您的业务对负载敏感性高，高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况，通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式，来降低对业务的影响。但为了保障业务的持续可用，不建议关闭健康检查。

client_max_body_size 5m;

 - none：请求标头中缺少“Referer”字段，也就是说Referer为空，浏览器直接访问的时候Referer一般为空。

- blocked： Referer”字段出现在请求标头中，但其值已被防火墙或代理服务器删除; 这些值是不以“http://” 或 “https://” 开头的字符串;

- server_names： 服务器名称，也就是域名列表。

# gzip
# 开启gzip
gzip on;
# 启用gzip压缩的最小文件，小于设置值的文件将不会压缩
gzip_min_length 1k;
#设置压缩缓冲区大小，此处设置为16个8K内存作为压缩结果流缓存
gzip_buffers 16 8k;
# 无条件启用压缩
gzip_proxied any;
# gzip 压缩级别，1-10，数字越大压缩的越好，也越占用CPU时间
gzip_comp_level 6;
# 进行压缩的文件类型。javascript有多种形式。其中的值可以在 mime.types 文件中找到。
gzip_types text/plain text/css application/javascript application/x-javascript application/xhtml+xml text/xml application/xml application/xml+rss image/jpg image/jpeg image/png image/gif image/x-icon;
# 是否在http header中添加Vary: Accept-Encoding，建议开启
gzip_vary on;
# 禁用IE 6 gzip
gzip_disable "MSIE [1-6].(?!.*SV1)";

（1）last：相当于apache里的（L）标记，表示完成rewrite匹配。（浏览器地址栏URL地址不变）

（2）break：本条规则匹配完成后，终止匹配，不再匹配后面的规则。（浏览器地址栏URL地址不变）

（3）redirect：返回302临时重定向，浏览器地址栏会显示跳转后的URL地址。

（4）permanent：返回301永久重定向，浏览器地址栏会显示跳转后的URL地址。

代码里面加（开发做）

nginx里配

#support websocket comunication
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://wee_admin;

(location `=` ) > (location `完整路径` ) > (location `^~` 路径) > (location `~`,`~*` 从上向下正则顺序，匹配在最后一条终止) > (location 部分起始路径) > (`/`)

NAT

DR

TUN: IP隧道

1. 压测负载均衡转发能力建议使用短连接 。

2. 压测负载均衡吞吐量建议使用长连接，用于测试带宽上限或特殊业务。

3. 后端服务器提供一个静态网页用于压测，以避免应用逻辑带来的损耗。

4. 压测时，监听配置建议如下：

1. 客户端端口不足

2. 后端服务器accept队列满 。

3. 后端服务器连接过多。

4. 后端服务器依赖的应用成为瓶颈。

5. 后端服务器的健康检查状态异常。

Apache ab在大量并发场景下存在3s、6s、9s阶梯式停顿的现象。Apache ab会通过判断content length来确定请求是否成功，而负载均衡挂载多台后端服务器时，返回的content length会不一致，导致测试结果有误。

namespace：用来修改进程视图的主要方法，“障眼法”

cgroup：用来制造约束的主要手段（Linux Control Group）

rootfs(根文件系统)

1.启用 Linux Namespace 配置

2.设定指定的 Cgroups 参数

3.切换进程的根目录（Change Root）

网桥：起到虚拟交换机作用的网络设备，通过使用一种名叫Veth Pair的虚拟设备连接到网桥，VethPair 成对出现，一张在容器中，一张连接网桥

缓存

p2p 网络下载

后端存储使用 s3，私有使用 hdfs

前端使用负载均衡

采取了预热模式，线下构建好镜像后就直接异步分发到线上各地域的mirror中，分批发布中第一批机器在执行时，第二批机器就提前去pull镜像。

阿里云开源了蜻蜓项目：Dragonfly 说明：https://yq.aliyun.com/articles/670136

基础镜像预分发，如果扩容时，基础镜像已经在本地了，就只需要拉取业务镜像的部分，可以明显提升速度，所以预先把基础镜像分发到所有的服务器上去

镜像加速架构

dfget

压测对比

网络插件

service

ingress

service与 ingress 对比

kubeadm

kubespray

kops

二进制

k8s-ansible

子主题

PV(PV 没有名称空间)

PVC

StorageClass

1. Master当 Worker 用

2. 证书到期怎么办

3. init containers 的用法:  启动时检查依赖，如果不满足，轮询等待，而不是直接退出

4. 配置restart policy

5. 配置Liveness Probe和Readiness Probe

6. 确保不存在SPOF（Single Point of Failure）

7. 每个进程一个容器

8. pause容器

9. QoS（服务质量等级）

10. kubernetes滚动升级的过程

Kaniko：无需高权限即可在Kubernetes与Google Container Builder中构建容器镜像，也可以构建镜像推送私有仓库        kaniko -f `pwd`/Dockerfile -c `pwd` --destination=${ORIGIN_REPO}/${REPO}:${IMAGE_TAG}

证书保证不泄露

使用命名空间建立安全边界

阻止 Pod 中的容器以 root 用户运行

容器是否可以写入 root 文件系统

基于角色的访问控制（RBAC）

限制对Kubernetes节点的管理访问

NetworkPolicy

针对 pod的资源限制 cpu  mem

1.单独创建用户及用户组 elastic

2.修改最大文件打开数

3.修改虚拟内存大小

4.禁用所有文件交换

5.配置 `swappiness`

6.修改 elastic 用户可以创建的线程数至少为 4096

7.配置内存锁

8.JVM配置建议

9.配置 TLS 、密码

shard数量(包括副本)，尽可能匹配节点数，等于或者是节点数的整数倍

通常建议单节点上同一索引的 shard 数不要超过 5 个

小规格节点下单 shard 大小不要超过 30G,更高规则单 shard 不要超过 50G

对于日志分析场景或超大索引，建议单 shard 大小不要超过 100G

input {
redis {
data_type => "list"
key => "filebeat"
host => "r-2ze3fa9fbcd4d544.redis.rds.aliyuncs.com"
port => 6379
password => "Tiangwang20190220+*-@$"
db => 13
threads => 5
}
}


filter {

}

output {

elasticsearch {
hosts => ["172.17.80.172:9221","172.17.80.172:9222","172.17.80.172:9223"]
user => "elastic"
password => "HjE43uOR8mGot4Szd7oc"
index => "logstash-%{+YYYY.MM.dd}"
ilm_enabled => false
}

# stdout {
# codec => "rubydebug"
# }
}

读文件输出 console

读文件输出 redis

【分布式】Zookeeper的Leader选举

子主题

子主题

子主题

registrator: 独立于服务注册表的自动服务注册/注销组件

consul-template

confd

正常环境内存要求 8GB,为避免交换内存或内存不足

SSD

etcd默认情况下强制将可配置的存储大小配额设置为2GB

建议 5 个节点，允许坏两个，不建议超过 7

硬件建议

v2

v3

Member flags

Clustering flags

Proxy flags

Security flags

Logging flags

Unsafe flags

Miscellaneous flags

Profiling flags

Auth flags

Experimental flags

阶段1 - 通知新配置群集

阶段 2 - 启动新成员

https://www.maideliang.com/index.php/archives/25/

flannel当前版本 (v0.10.0) 操作etcd使用的是v2的API

kubernetes操作etcd使用的v3的API

推荐在 Kubernetes 集群中使用 Etcd v3，v2 版本已在 Kubernetes v1.11 中弃用

少数跟随者失败

Leader 失败

多数失败

网络分区

启动期间失败

etcd 是一个强一致性的分布式 KV 存储，所谓强一致性，简单来说就是一个写操作成功后，从任何一个节点读出来的数据都是最新值，而不会出现写数据成功后读不出来或者读到旧数据的情况。etcd 通过 raft 协议来实现 leader 选举、配置变更以及保证数据读写的一致性。下面简单介绍下 etcd 的读写流程：

写数据流程（以 leader 节点为例，见上图）：

读数据流程：

当服务节点数越来越多时，服务注册中心的性能会成为瓶颈，这时候就需要通过水平扩容来提升服务注册中心集群的性能。

* 对于那些采用了类 Paxos 协议的强一致性的组件，如ZooKeeper，由于每次写操作需要过半的节点确认。水平扩容不能提升整个集群的写性能，只能提升整个集群的读性能。
* 而对于采用最终一致性的组件来说，水平扩容可以同时提升整个集群的写性能和读性能。

etcd和Consul解决了不同的问题。如果寻找分布式一致键值存储，etcd是比Consul更好的选择。如果寻找端到端集群服务发现，etcd将没有足够的功能; 选择Kubernetes，Consul或SmartStack。

 binlog 格式

复制的基本过程如下：

从节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”；
Slave 的 SQL线程检测到relay-log 中新增加了内容后，会将relay-log的内容解析成在主节点上实际执行过的操作，并在本数据库中执行。

四个特性（ACID）

mysqldump

xtrabackup

RDB

AOF(Append-only file)

两种存储方式对比

着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。

着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

密码认证

限制一些上锁 或者造成阻塞的操作 keys

线上禁止使用 monitor 命令

禁用命令

Redis 4.0的Lazyfree机制可以避免del、flushdb、flushall、rename等命令引起的redis-server阻塞，提高服务稳定性

过程原理：
     1.当从库和主库建立MS关系后,会向主数据库发送SYNC命令
     2.主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程),并将期间接收到的写命令缓存起来
     3.当快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis
     4.从Redis接收到后,会载入快照文件并且执行收到的缓存的命令
     5.之后,主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致
缺点：所有的slave节点数据的复制和同步都由master节点来处理,会照成master节点压力太大,使用主从从结构来解决

1. volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-enviction（驱逐）：禁止驱逐数据

1. 使用AOF文件进行迁移

2.使用redis-shake进行迁移

3.使用阿里云DTS进行迁移

4.校验迁移后的数据

【解决】MongoDB 线上业务处理，数据去重脚本实现

基于日志的异步复制

BASE：相对于事物的 ACID 特性，NoSQL 数据库保证的是 BASE 特性。BASE 是最终一致性和软事物。

提取字符串

按最后一列求和

列求最大值

求平均值

设置该选项后，当脚本中任何以一个命令执行返回的状态码不为0时就退出整个脚本（默认脚本运行中某行报错会继续往下执行）

设置该选项后，当脚本在执行过程中尝试使用未定义过的变量时，报错并退出运行整个脚本（默认会把该变量的值当作空来处理），这个感觉也非常有用，有些时候可能在脚本中变量很多很长，疏忽了把某个变量的名字写错了，这时候运行脚本不会报任何错误，但结果却不是你想要的，排查起来很是头疼，使用这个选项就完美的解决了这个问题。

默认情况下，脚本执行后，屏幕只显示运行结果，没有其他内容。加上之后执行过程会显示

设置了这个选项以后，包含管道命令的语句的返回值，会变成最后一个返回非零的管道命令的返回值。

表示关闭

ansible web -m command -a 'echo lyj|passwd --stdin lyj2'

ansible all -m ping 返回 pong

command（默认模块）: 绝大多数系统命令，可能会不支持管道

ping 模块：检测主机存活

shell 模块： 调用bash执行命令

copy 模块： 复制本地文件至远程服务器，并且能够改属性等

cron模块：crontab 定时执行任务的模块

file 模块：设置文件属性

hostname模块：

pip 模块：python的包管理工具

yum 模块：安装软件

service 模块：

user模块：

script模块: 将本地脚本复制到被管理主机上进行运行

setup模块: 用于模块收集、查看被管理主机的facts。可基于特定值做条件判断，比如系统版本

ansible

ansible-playbook:剧本

ansible-galaxy: 查找安装 roles

ansible-doc

ansible-vault 加解密相关

ansible-console: 交互式工具

物理内存（主存）

虚拟内存

将虚拟内存地址映射到物理内存地址。为了完成内存映射，内核为每个进程都维护了一张页表，记录虚拟地址与物理地址的映射关系,为了完成内存映射，内核为每个进程都维护了一张页表，记录虚拟地址与物理地址的映射关系,页表实际上存储在 CPU 的内存管理单元 MMU 中，这样，正常情况下，处理器就可以直接通过硬件，找出要访问的内存。
而当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入内核空间分配物理内存、更新进程页表，最后再返回用户空间，恢复进程的运行。

分配

回收

free

top

buffer：缓冲（用于平滑流速、衔接不同流速的设备）减小短期内突发I/O的影响，起到流量整形的作用

cache：快取、缓存（用于减少低速设备的访问、提高高速设备的效率）是系统两端处理速度不匹配时的一种折衷策略。因为CPU和memory之间的速度差异越来越大，所以人们充分利用数据的局部性（locality）特征，通过使用存储系统分级（memory hierarchy）的策略来减小这种差异带来的影响。

/proc/meminfo

读写请求中的 buffer/cache

使用 buffer/cache 的好处

缓存命中率

手动释放缓存

内存泄露到底是怎么发生的

发生内存泄漏之后该如何排查和定位

总结： 应用程序可以访问的用户内存空间，由只读段、数据段、堆、栈以及文件映射段等组成。其中，堆内存和内存映射，需要应用程序来动态管理内存段，所以我们必须小心处理。不仅要会用标准库函数 malloc()来动态分配内存，还要记得在用完内存后，调用库函数 _free() 来 _ 释放它们。

java 性能调优 https://my.oschina.net/feichexia/blog/196575

脏页：大部分文件页，都可以直接回收，以后有需要时，再从磁盘重新读取就可以了。而那些被应用程序修改过，并且暂时还没写入磁盘的数据（也就是脏页），就得先写入磁盘，然后才能进行内存释放。

Swap 把不常访问的内存（脏页、匿名页）先写到磁盘中，然后释放这些内存，给其他更需要的进程使用。再次访问这些内存时，重新从磁盘读入内存就可以了。

原理：把一块磁盘空间或者一个本地文件，当成内存来使用。它包括换出和换入两个过程。

总结： 内存回收机制。这些回收的内存既包括了文件页，又包括了匿名页。
- 对文件页的回收，当然就是直接回收缓存，或者把脏页写回磁盘后再回收。
- 而对匿名页的回收，其实就是通过 Swap 机制，把它们写入磁盘后再释放内存。

在内存资源紧张时，Linux 通过直接内存回收和定期扫描的方式，来释放文件页和匿名页，以便把内存分配给更需要的进程使用。

文件页的回收比较容易理解，直接清空缓存，或者把脏数据写回磁盘后，再释放缓存就可以了。
而对不常访问的匿名页，则需要通过 Swap 换出到磁盘中，这样在下次访问的时候，再次从磁盘换入到内存中就可以了。
开启 Swap 后，你可以设置 /proc/sys/vm/min_free_kbytes ，来调整系统定期回收内存的阈值，也可以设置 /proc/sys/vm/swappiness ，来调整文件页和匿名页的回收倾向。

为什么一般应用要关闭 swap?

当 Swap 变高时，你可以用 sar、/proc/zoneinfo、/proc/pid/status 等方法，查看系统和进程的内存使用情况，进而找出 Swap 升高的根源和受影响的进程。

降低 swap 的使用提高性能

根据指标找工具

根据工具找指标

1. 先用 free 和 top，查看系统整体的内存使用情况。
2. 再用 vmstat 和 pidstat，查看一段时间的趋势，从而判断出内存问题的类型。
3. 最后进行详细分析，比如内存分配分析、缓存 / 缓冲区分析、具体进程的内存使用分析等。

保证应用程序的热点数据放到内存中，并尽量减少换页和交换

优化思路

# 使用 grep 查找 Pss 指标后，再用 awk 计算累加值
[root@jikeshijian ~]# grep Pss /proc/[1-9]*/smaps | awk '{total+=$2}; END {printf "%d kB\n", total }'
75628 kB

平均负载与CPU使用率的关系

CPU 上下文切换

 CPU 使用率总结

不可中断状态和僵尸状态

1、自愿上下文切换变多了，说明进程都在等待资源，有可能发生I/O问题
2、非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢cpu，说明cpu的确成为瓶颈
3、中断次数变多，说明cpu被中断程序占用，还需要通过查看/proc/interrupts文件来分析具体的中断类型

索引节点（index node）

目录项（directory entry）

索引节点是每个文件的唯一标志，而目录项维护的正是文件系统的树状结构。目录项和索引节点的关系是多对一，你可以简单理解为，一个文件可以有多个别名。

根据是否利用标准库缓存

根据是否利用操作系统的页缓存

根据应用程序是否阻塞自身运行

根据是否等待响应结果

容量

文件系统缓存

使用率

饱和度

IOPS（Input/Output Per Second）

吞吐量

响应时间

场景

图示

fio

观测方法

1.“狂打日志”的场景时，你可以用 iostat、strace、lsof 等工具来定位狂打日志的进程，找出相应的日志文件，再通过应用程序的接口，调整日志级别来解决问题。

2. 子线程况刷日志, 写文件是由子线程执行的，所以直接strace跟踪进程没有看到write系统调用，可以通过pstree查看进程的线程信息，再用strace跟踪。或者，通过strace -fp pid 跟踪所有线程。

1. 先用 iostat 发现磁盘 I/O 性能瓶颈；
2. 再借助 pidstat ，定位出导致瓶颈的进程；
3. 随后分析进程的 I/O 行为；
4. 最后，结合应用程序的原理，分析这些 I/O 的来源。

1.fio 性能测试

应用程序优化

文件系统优化

磁盘优化

带宽

吞吐量

延时

PPS（Packet Per Second）

网络的可用性（网络能否正常通信)

并发连接数（TCP 连接数量）

丢包率（丢包百分比）

重传率（重新传输的网络包比例）

网络配置

套接字信息

协议栈统计信息

网络吞吐和 PPS

连通性和延时

# 统计总的连接跟踪数
$ conntrack -L -o extended | wc -l
14289

# 统计 TCP 协议各个状态的连接跟踪数
$ conntrack -L -o extended | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}'
SYN_RECV 4
CLOSE_WAIT 9
ESTABLISHED 2877
FIN_WAIT 3
SYN_SENT 2113
TIME_WAIT 9283

# 统计各个源 IP 的连接跟踪数
$ conntrack -L -o extended | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10
14116 192.168.0.2
172 192.168.0.96

查看ip_conntrack实时连接状态信息，安装iptstate工具

C10K 和 C1000K 的首字母 C 是 Client 的缩写。C10K 就是单机同时处理 1 万个请求（并发连接 1 万）的问题，而 C1000K 也就是单机支持处理 100 万个请求（并发连接 100 万）的问题。

C10K

C1000K

C10M

TCP/UDP 性能

HTTP 性能

应用负载性能

tcpdump -nn udp port 53 or host 35.190.27.188

tcpdump选项类

tcpdump过滤表达式

tcpdump 的输出格式

wireshark

三次握手四次挥手

先要获得网络基准测试报告，然后通过相关性能工具，定位出网络性能瓶颈。再接下来的优化工作，就是水到渠成的事情了

Linux 系统的网络协议栈和网络收发流程

优化角度

状态

TCP状态迁移路线

1、最大连接数是不是受限于 65535 个端口

2、DNS慢

3、DDOS：分布式拒绝服务攻击

4、为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

5、为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

6、tcp包超过最大 MTU:

7、优酷+淘宝活动性能优化实战：  http://jm.taobao.org/2017/05/04/20170504/#more

8、A 服务内网调用 B 服务，中间经过防火墙，每天约 1000 万连接，每天约 100 个连接超时，如何排查问题？

1.pow

2.pos

3.dpos

4.poa

通信双方协定，用同一把钥匙🔑来进行通信双方的加解密

AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高；AES是一个使用128为分组块的分组加密算法，分组块和128、192或256位的密钥一起作为输入，对4×4的字节数组上进行操作。众所周之AES是种十分高效的算法，尤其在8位架构中，这源于它面向字节的设计。AES 适用于8位的小型单片机或者普通的32位微处理器,并且适合用专门的硬件实现，硬件实现能够使其吞吐量（每秒可以到达的加密/解密bit数）达到十亿量级。同样，其也适用于RFID系统。

DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。

3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。

通信的双方各自分别生成两个秘钥，一个公钥一个私钥，公钥完全公开，谁都可以看到，私钥自己保存，通信的过程中，双方分别用对方的公钥进行加密，然后用自己的私钥进行解密

公钥加密，私钥解密，私钥签名，公钥验签

RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的。RSA在国外早已进入实用阶段，已研制出多种高速的RSA的专用芯片。

DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准），严格来说不算加密算法。

ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学。ECC和RSA相比，具有多方面的绝对优势，主要有：抗攻击性强。相同的密钥长度，其抗攻击性要强很多倍。计算量小，处理速度快。ECC总的速度比RSA、DSA要快得多。存储空间占用小。ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多，意味着它所占的存贮空间要小得多。这对于加密算法在IC卡上的应用具有特别重要的意义。带宽要求低。当对长消息进行加解密时，三类密码系统有相同的带宽要求，但应用于短消息时ECC带宽要求却低得多。带宽要求低使ECC在无线网络领域具有广泛的应用前景。

其实不是安全领域下的加密解密算法，只能算是一个编码算法，通常用于把二进制数据编码为可写的字符形式的数据，对数据内容进行编码来适合传输(可以对img图像编码用于传输)。这是一种可逆的编码方式。编码后的数据是一个字符串，其中包含的字符为：A-Z、a-z、0-9、+、/，共64个字符(26 + 26 + 10 + 1 + 1 = 64，其实是65个字符，“=”是填充字符。Base64要求把每三个8Bit的字节转换为四个6Bit的字节(3*8 = 4*6 = 24)，然后把6Bit再添两位高位0，组成四个8Bit的字节，也就是说，转换后的字符串理论上将要比原来的长1/3。原文的字节最后不够3个的地方用0来补足，转换时Base64编码用=号来代替。这就是为什么有些Base64编码会以一个或两个等号结束的原因，中间是不可能出现等号的，但等号最多只有两个。其实不用"="也不耽误解码，之所以用"="，可能是考虑到多段编码后的Base64字符串拼起来也不会引起混淆。)
Base64编码是从二进制到字符的过程，像一些中文字符用不同的编码转为二进制时，产生的二进制是不一样的，所以最终产生的Base64字符也不一样。例如"上网"对应utf-8格式的Base64编码是"5LiK572R"， 对应GB2312格式的Base64编码是"yc/N+A=="。
标准的Base64并不适合直接放在URL里传输，因为URL编码器会把标准Base64中的“/”和“+”字符变为形如“%XX”的形式，而这些“%”号在存入数据库时还需要再进行转换，因为ANSI SQL中已将“%”号用作通配符。
为解决此问题，可采用一种用于URL的改进Base64编码，它不在末尾填充'='号，并将标准Base64中的“+”和“/”分别改成了“-”和“_”，这样就免去了在URL编解码和数据库存储时所要作的转换，避免了编码信息长度在此过程中的增加，并统一了数据库、表单等处对象标识符的格式。
另有一种用于正则表达式的改进Base64变种，它将“+”和“/”改成了“!”和“-”，因为“+”，“*”以及前面在IRCu中用到的“[”和“]”在正则表达式中都可能具有特殊含义。
此外还有一些变种，它们将“+/”改为“_-”或“._”（用作编程语言中的标识符名称）或“.-”（用于XML中的Nmtoken）甚至“_:”（用于XML中的Name）。

URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间），提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。它的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

认真负责，喜欢和善于学习新东西，保持好奇心和热情

我喜欢独立工作，而不喜欢主管领导在我的工作中安排一切。

对准时要求严格

运维开发，有开发技能之后，能更容易找到程序运行过程中容易出现瓶颈的地方