背景

最近在准备面试，结合之前的工作经验和近期在网上收集的一些面试资料，准备将Android开发岗位的知识点做一个系统的梳理，整理成一个系列：Android应用开发岗面试汇总。本系列将分为以下几个大模块：
Java基础篇、Java进阶篇、常见设计模式
Android基础篇、Android进阶篇、性能优化
网络相关、数据结构与算法
常用开源库、Kotlin、Jetpack

注1：以上文章将陆续更新，直到我找到满意的工作为止，有跳转链接的表示已发表的文章。
注2：该系列属于个人的总结和网上东拼西凑的结果，每个知识点的内容并不一定完整，有不正确的地方欢迎批评指正。
注3：部分摘抄较多的段落或有注明出处。如有侵权，请联系本人进行删除。

1、HTTP

定义：Hypertext Transfer Protocol，超⽂本传输协议，和 HTML (Hypertext Markup Language 超⽂本标记语⾔) ⼀起诞⽣，⽤于在⽹络上请求和传输 HTML 内容。超⽂本，即「扩展型⽂本」，指的是 HTML 中可以有链向别的⽂本的链接

1.1 URL 和 HTTP 报⽂

URL 格式

三部分：

协议类型 ----》http
服务器地址(和端⼝号) ----》hencoder.com
路径(Path) ----》users?gender=male
即：协议类型://服务器地址[:端⼝号]路径
http://hencoder.com/users?gender=male

报⽂格式

请求报⽂

image.png
响应报文

image.png

1.2Request Method 请求⽅法

幂等：多次请求，返回结果一致
非幂等：多次请求，结果不一致
除了POST请求外，其他都是幂等的

GET

⽤于获取资源
对服务器数据不进⾏修改
不发送 Body

GET /users/1 HTTP/1.1
Host: api.github.com

对应 Retrofit 的代码：

@GET("/users/{id}")
Call getUser(@Path("id") String id,
@Query("gender") String gender);

POST

⽤于增加或修改资源
发送给服务器的内容写在 Body ⾥⾯

POST /users HTTP/1.1
Host: api.github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
name=rengwuxian&gender=male

对应 Retrofit 的代码：

@FormUrlEncoded
@POST("/users")
Call addUser(@Field("name") String name,
@Field("gender") String gender);

PUT

⽤于修改资源
发送给服务器的内容写在 Body ⾥⾯

PUT /users/1 HTTP/1.1
Host: api.github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
gender=female

对应 Retrofit 的代码：

@FormUrlEncoded
@PUT("/users/{id}")
Call updateGender(@Path("id") String id,
@Field("gender") String gender);

DELETE

⽤于删除资源
不发送 Body

DELETE /users/1 HTTP/1.1
Host: api.github.com

对应 Retrofit 的代码：

@DELETE("/users/{id}")
Call getUser(@Path("id") String id,
@Query("gender") String gender);

HEAD

和 GET 使⽤⽅法完全相同
和 GET 唯⼀区别在于，返回的响应中没有 Body

1.3 Status Code 状态码

三位数字，⽤于对响应结果做出类型化描述（如「获取成功」「内容未找到」）。

1xx：临时性消息。如：100 （继续发送）、101（正在切换协议）
2xx：成功。最典型的是 200（OK）、201（创建成功）。
3xx：重定向。如 301（永久移动）、302（暂时移动）、304（内容未改变）。
4xx：客户端错误。如 400（客户端请求错误）、401（认证失败）、403（被禁
⽌）、404（找不到内容）。
5xx：服务器错误。如 500（服务器内部错误）。

1.4 Headers

Host：

⽬标主机地址（服务器地址）。注意：不是在⽹络上⽤于寻址的，⽽是在⽬标服务器上⽤于定位⼦服务
器的。
域名：如：bbaidu.com，浏览器输入域名后，通过DNS服务器去查询IP地址，该操作在请求http前完成。

Content-Type：

指定 Body 的类型。主要有四类：

text/html：请求 Web ⻚⾯是返回响应的类型，Body 中返回 html ⽂本。
x-www-form-urlencoded：Web ⻚⾯纯⽂本表单的提交⽅式。
multipart/form-data：Web ⻚⾯含有⼆进制⽂件时的提交⽅式。
application/json , image/jpeg , application/zip ...：单项内容（⽂本或⾮⽂本都可以），⽤于 Web Api 的响应或者 POST / PUT 的请求

Content-Length

指定 Body 的⻓度（字节）。

Location

指定重定向的⽬标 URL

User-Agent

⽤户代理，即是谁实际发送请求、接受响应的，例如⼿机浏览器、某款⼿机 App。

Range / Accept-Range

按范围取数据

Accept-Range: bytes 响应报⽂中出现，表示服务器⽀持按字节来取范围数据
Range: bytes=- 请求报⽂中出现，表示要取哪段数据
Content-Range:-/total 响应报⽂中出现，表示发送的是哪段数据
作⽤：断点续传、多线程下载。

其他 Headers

Accept: 客户端能接受的数据类型。如 text/html
Accept-Charset: 客户端接受的字符集。如 utf-8
Accept-Encoding: 客户端接受的压缩编码类型。如 gzip
Content-Encoding：压缩类型。如 gzip

1.5 Cache

作⽤：在客户端或中间⽹络节点缓存数据，降低从服务器取数据的频率，以提⾼⽹
络性能。
Etag：缓存的tag信息，用来对比本地和服务器的tag是否一直，一致的话就不重新请求数据。

2.加解密

可以加密任何⼆进制数据
⾮对称加密的出现使得密码学有了更⼴泛的⽤途：数字签名

2.1 对称加密

通信双⽅使⽤同⼀个密钥，使⽤加密算法配合上密钥来加密，解密时使⽤加密过程
的完全逆过程配合密钥来进⾏解密。
简化模型：对⽂字进⾏规则化替换来加密，对密⽂进⾏逆向的规则化替换来解密。

image.png

经典算法

DES（56 位密钥，密钥太短⽽逐渐被弃⽤）、AES（128 位、192 位、256 位密钥，
现在最流⾏）

对称加密作⽤

加密通信，防⽌信息在不安全⽹络上被截获后，信息被⼈读取或篡改。

对称加密（如 AES）的破解

破解思路：

拿到⼀组或多组原⽂-密⽂对
设法找到⼀个密钥，这个密钥可以将这些原⽂-密⽂对中的原⽂加密为密⽂，以及将密⽂解密为原⽂的组合，即为成功破解

反破解

⼀种优秀的对称加密算法的标准是，让破解者找不到⽐穷举法（暴⼒破解法）更有效的破解⼿段，并且穷举法的破解时间⾜够⻓（例如数千年）。

对称加密的缺点

密钥泄露：不能在不安全⽹络上传输密钥，⼀旦密钥泄露则加密通信失败。如：中间人攻击。

2.2 ⾮对称加密

2.2.1 原理

使⽤公钥对数据进⾏加密得到密⽂；使⽤私钥对数据进⾏解密得到原数据。⾮对称加密使⽤的是复杂的数学技巧，在古典密码学中没有对应的原型。

image.png

2.2.2 作用

使⽤⾮对称加密通信，可以在不可信⽹络上将双⽅的公钥传给对⽅，然后在发消息前分别对消息使⽤对⽅的公钥来加密和使⽤⾃⼰的私钥来签名，做到不可信⽹络上的可靠密钥传播及加密通信。

image.png

2.2.3 数字签名

由于私钥和公钥互相可解（即公钥和私钥都可以进行加解密数据，但由于公钥需要公开出去，且公钥可以根据私钥计算出来，因此私钥不能公开），因此⾮对称加密还可以应⽤于数字签名技术。
作用：为了证明自己是自己。避免发送的数据被篡改。
简化模型如图：

image.png

通常会对原数据 hash 以后对 hash 签名，然后附加在原数据的后⾯作为签名。这是为了让数据更⼩。
模型如图：

image.png

2.2.4 经典算法

RSA（可⽤于加密和签名）、DSA（仅⽤于签名，但速度更快）

2.2.5 ⾮对称加密的优缺点

优点：可以在不安全⽹络上传输密钥
缺点：计算复杂，因此性能相⽐对称加密差很多

2.2.5 ⾮对称加密（如 RSA、ECDSA）的破解

破解思路

和对称加密不同之处在于，⾮对称加密的公钥很容易获得，因此制造原⽂-密⽂对是没有困难的事
所以，⾮对称加密的关键只在于，如何找到⼀个正确的私钥，可以解密所有经过公钥加密过的密⽂。找到这样的私钥即为成功破解
由于⾮对称加密的⾃身特性，怎样通过公钥来推断出私钥通常是⼀种思路（例如RSA），但往往最佳⼿段依然是穷举法，只是和对称加密破解的区别在于，对称加密破解是不断尝试⾃⼰的新密钥是否可以将⾃⼰拿到的原⽂-密⽂对进⾏加密和解密，⽽⾮对称加密时不断尝试⾃⼰的新私钥是否和公钥互相可解。

2.2.6 反破解

和对称加密⼀样，⾮对称加密算法优秀的标准同样在于，让破解者找不到⽐穷举法更有效的破解⼿段，并且穷举法的破解时间⾜够⻓

2.3 Base64

2.3.1 概念

将⼆进制数据转换成由 64 个字符组成的字符串的编码算法

2.3.2 什么是⼆进制数据？

⼴义：所有计算机数据都是⼆进制数据
狭义：⾮⽂本数据即⼆进制数据

2.3.3 算法

将原数据每 6 位对应成 Base 64 索引表中的⼀个字符编排成⼀个字符串（每个字符8 位）。

2.3.4 值的范围：共64个

AaBbCc……Zz 52个
1234567890 10个
+/ 2个

2.3.5 作用

将⼆进制数据扩充了储存和传输途径（例如可以把数据保存到⽂本⽂件、可以通过聊天对话框或短信形式发送⼆进制数据、可以在 URL 中加⼊简单的⼆进制数据）
普通的字符串在经过 Base64 编码后的结果会变得⾁眼不可读，因此可以适⽤于⼀定条件下的防偷窥（较少⽤）

3.登录和授权

3.1Authorization

两种主流⽅式： Basic 和 Bearer

3.1.1 Basic：

格式：Authorization: Basic

3.1.2 Bearer：

格式：Authorization: Bearer
bearer token 的获取⽅式：通过 OAuth2 的授权流程：

第三⽅⽹站向授权⽅⽹站申请第三⽅授权合作，拿到 client id 和 client secret
⽤户在使⽤第三⽅⽹站时，点击「通过 XX (如 GitHub) 授权」按钮，第三⽅
⽹站将⻚⾯跳转到授权⽅⽹站，并传⼊ client id 作为⾃⼰的身份标识
授权⽅⽹站根据 client id ，将第三⽅⽹站的信息和第三⽅⽹站需要的⽤户权
限展示给⽤户，并询问⽤户是否同意授权
⽤户点击「同意授权」按钮后，授权⽅⽹站将⻚⾯跳转回第三⽅⽹站，并传
⼊ Authorization code 作为⽤户认可的凭证。
第三⽅⽹站将 Authorization code 发送回⾃⼰的服务器
服务器将 Authorization code 和⾃⼰的 client secret ⼀并发送给授权⽅的
服务器，授权⽅服务器在验证通过后，返回 access token。OAuth 流程结
束。
在上⾯的过程结束之后，第三⽅⽹站的服务器（或者有时客户端也会）就可以使⽤ access token 作为⽤户授权的令牌，向授权⽅⽹站发送请求来获取⽤户信息或操作⽤户账户。但这已经在 OAuth 流程之外。

为什么 OAuth 要引⼊ Authorization code，并需要申请授权的第三⽅将Authorization code 发送回⾃⼰的服务器，再从服务器来获取 access token，⽽不是直接返回 access token ？这样复杂的流程意义何在？为了安全。OAuth不强制授权流程必须使⽤ HTTPS，因此需要保证当通信路径中存在窃听者时，依然具有⾜够⾼的安全性。

3.2.1 第三⽅ App 通过微信登录的流程，也是⼀个 OAuth2 流程：

第三⽅ App 向腾讯申请第三⽅授权合作，拿到 client id 和 client secret
⽤户在使⽤第三⽅ App 时，点击「通过微信登录」，第三⽅ App 将使⽤微
信 SDK 跳转到微信，并传⼊⾃⼰的 client id 作为⾃⼰的身份标识
微信通过和服务器交互，拿到第三⽅ App 的信息，并限制在界⾯中，然后
询问⽤户是否同意授权该 App 使⽤微信来登录
⽤户点击「使⽤微信登录」后，微信和服务器交互将授权信息提交，然后跳
转回第三⽅ App，并传⼊ Authorization code 作为⽤户认可的凭证
第三⽅ App 调⽤⾃⼰服务器的「微信登录」Api，并传⼊ Authorization
code，然后等待服务器的响应
服务器在收到登录请求后，拿收到的 Authorization code 去向微信的第三
⽅授权接⼝发送请求，将 Authorization code 和⾃⼰的 client secret ⼀起
作为参数发送，微信在验证通过后，返回 access token
服务器在收到 access token 后，⽴即拿着 access token 去向微信的⽤户信
息接⼝发送请求，微信验证通过后，返回⽤户信息
服务器在收到⽤户信息后，在⾃⼰的数据库中为⽤户创建⼀个账户，并使⽤
从微信服务器拿来的⽤户信息填⼊⾃⼰的数据库，以及将⽤户的 ID 和⽤户
的微信 ID 做关联
⽤户创建完成后，服务器向客户端的请求发送响应，传送回刚创建好的⽤户
信息
客户端收到服务器响应，⽤户登录成功
在⾃家 App 中使⽤ Bearer token
有的 App 会在 Api 的设计中，将登录和授权设计成类似 OAuth2 的过程，但简
化掉 Authorization code 概念。即：登录接⼝请求成功时，会返回 access
token，然后客户端在之后的请求中，就可以使⽤这个 access token 来当做
bearer token 进⾏⽤户操作了。

3.2.2 Refresh token

{
 "token_type": "Bearer",
 "access_token": "xxxxx",
 "refresh_token": "xxxxx",
 "expires_time": "xxxxx"
}

⽤法：access token 有失效时间，在它失效后，调⽤ refresh token 接⼝，传⼊refresh_token 来获取新的 access token。
⽬的：安全。当 access token 失窃，由于它有失效时间，因此坏⼈只有较短的时间来「做坏事」；同时，由于（在标准的 OAuth2 流程中）refresh token 永远只存在与第三⽅服务的服务器中，因此 refresh token ⼏乎没有失窃的⻛险。

4. TCP/IP协议族

4.1 概念

⼀系列协议所组成的⼀个⽹络分层模型
为什么要分层？
因为⽹络的不稳定性
具体分层：

image.png

Application Layer 应⽤层：
HTTP、FTP、DNS，进行具体的网络应用交互，是无状态的。
Transport Layer 传输层：
TCP、UDP，保证网络数据的可靠性传输。TCP用来数据的重传，需要建立连接。UDP不需要重传，不需要建立连接。
Internet Layer ⽹络层：
IP，用来做路由、寻址等工作，解决网络上传输包的问题。
Link Layer 数据链路层：
以太⽹、Wi-Fi，可大概认为是物理层。

4.2 TCP 连接

4.2.1 概念

什么叫做连接（建立连接）？
通信双⽅建⽴确认「可以通信」，不会将对⽅的消息丢弃，即为「建⽴连接」。只TCP的连接，是一种有状态的交互。Java中通过Socket(端口)建立连接。

4.2.2 TCP 连接的建⽴与关闭

TCP连接的建立：（三次握手）

流程：

1.连接方：我要发消息了
2.接收方：我知道了；我也要给你发消息了
3.连接方：我知道了

image.png

TCP连接的关闭：（四次挥手）

流程：

1.连接方：我不再给你发消息了
2.接收方：我知道了
3.接收方：我也不再给你发消息了
3.连接方：我知道了
重点：为什么2、3步不一起发消息呢？
答：必须单独发消息，因为可能第2步发出时，接收方原本正在发送给发送方的消息还未发送完毕，因此必须做两步发送。

image.png

为什么要关闭连接？
为了节省资源。节省连接两方的内存；节省占用的端口资源。

4.2.3 ⻓连接

为什么要⻓连接？

因为移动⽹络并不在 Internet 中，⽽是在运营商的内⽹，并不具有真正的公⽹ IP，因此当某个 TCP 连接在⼀段时间不通信之后，⽹关会出于⽹络性能考虑⽽关闭这条TCP 连接和公⽹的连接通道，导致这个 TCP 端⼝不再能收到外部通信消息，即 TCP连接被动关闭。

⻓连接的实现⽅式（如何保证长连接）

⼼跳。即在⼀定间隔时间内，使⽤ TCP 连接发送超短⽆意义消息来让⽹关不能将⾃⼰定义为「空闲连接」，从⽽防⽌⽹关将⾃⼰的连接关闭。

5.HTTPS

5.1 定义

HTTP over SSL 的简称，即⼯作在 SSL （或 TLS）上的 HTTP。说⽩了就是加密通信的 HTTP。

5.2 ⼯作原理

在客户端和服务器之间用非对称加密协商出⼀套对称密钥，每次发送信息之前将内容加密，收到之后解密，达到内容的加密传输。即对对称秘钥加密采用非对称加密（保证安全，数据小，速度可以得到保证），在传输数据时用对称加密（提升速度，相比非对称加密的方式）。

为什么不直接⽤⾮对称加密？
⾮对称加密由于使⽤了复杂了数学原理，因此计算相当复杂，如果完全使⽤⾮对称加密来加密通信内容，会严重影响⽹络通信的性能。
以上内容来自于HenCoder的视频课程

5.3 HTTPS 连接建⽴的过程

4e2f8ad8804d908cab179c33ae96ff02.png

证书验证阶段

客户端发起 HTTPS 请求
服务端返回 HTTPS 证书（证书中包含公钥）
客户端验证证书是否合法，如果不合法则提示告警

数据传输阶段

当证书验证合法后，在本地生成随机数
通过公钥加密随机数，并把加密后的随机数传输到服务端
服务端通过私钥对随机数进行解密，即随机数就是对称加密的密钥
服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

5.4 相关面试题

5.4.1 为什么数据传输是用对称加密？

①首先，不能使用非对称加密，因为非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；
②另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。
注：网络传输过程中，公钥可以进行传输，不用担心中间人攻击而被泄露出去（公钥也可以根据私钥推算出来）；而私钥需要严格保密，不能进行传输，否则加密就会被破解掉。

5.4.2 为什么需要 CA 认证机构颁发证书？

①HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。
②首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。

“中间人攻击”的具体过程如下：

0a7307bf793e72315a0fc4767bded11f.png

过程原理：

本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器
中间人服务器返回中间人自己的证书
客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
中间人以客户端的请求内容再向正规网站发起请求
因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据
中间人凭借与正规网站建立的对称加密算法对内容进行解密
中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输
客户端通过与中间人建立的对称加密算法对返回结果数据进行解密
由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。

5.4.3 浏览器是如何确保 CA 证书的合法性？

1. 证书包含什么信息？

颁发机构信息
公钥
公司信息
域名
有效期
指纹
......

2. 证书的合法性依据是什么？

首先，权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构。
另外，证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。

3. 浏览器如何验证证书的合法性？

浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：

1、验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；
2、判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；
3、判断证书是否被篡改。需要与 CA 服务器进行校验；
4、判断证书是否已吊销。通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率
以上任意一步都满足的情况下浏览器才认为证书是合法的。

4. 只有认证机构可以生成证书吗？

如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的 HTTPS 传输。

5.4.4 既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？

-这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据(通过公钥加密的随机数)进行解密（拿不到随机数，也就不能构造对称加密的密钥）。

5.4.5 本地随机数被窃取怎么办？

证书验证是采用非对称加密实现，但是传输过程是采用对称加密，而其中对称加密算法中重要的随机数是由本地生成并且存储于本地的，HTTPS 如何保证随机数不会被窃取？

答： HTTPS 并不包含对随机数的安全保证，HTTPS 保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。

5.4.6 用了 HTTPS 会被抓包吗？

HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。
但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。
通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

5.4.7 既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？

HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。

总结

以下用简短的Q&A形式进行全文总结：
Q: HTTPS 为什么安全？
A: 因为 HTTPS 保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。

Q: HTTPS 的传输过程是怎样的？
A: 客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。

Q: 为什么需要证书？
A: 防止”中间人“攻击，同时可以为网站提供身份证明。

Q: 使用 HTTPS 会被抓包吗？
A: 会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

总结如图：

deb36d5c42312b944a5bd84c47741d37.png

参考链接

网络篇

背景

1、HTTP

1.1 URL 和 HTTP 报⽂

URL 格式

报⽂格式

1.2Request Method 请求⽅法

GET

POST

PUT

DELETE

HEAD

1.3 Status Code 状态码

1.4 Headers

Host：

Content-Type：

Content-Length

Location

User-Agent

Range / Accept-Range

其他 Headers

1.5 Cache

2.加解密

2.1 对称加密

经典算法

对称加密作⽤

对称加密（如 AES）的破解

反破解

对称加密的缺点

2.2 ⾮对称加密

2.2.1 原理

2.2.2 作用

2.2.3 数字签名

2.2.4 经典算法

2.2.5 ⾮对称加密的优缺点

2.2.5 ⾮对称加密（如 RSA、ECDSA）的破解

2.2.6 反破解

2.3 Base64

2.3.1 概念

2.3.2 什么是⼆进制数据？

2.3.3 算法

2.3.4 值的范围：共64个

2.3.5 作用

3.登录和授权

3.1Authorization

3.1.1 Basic：

3.1.2 Bearer：

3.2.1 第三⽅ App 通过微信登录的流程，也是⼀个 OAuth2 流程：

3.2.2 Refresh token

4. TCP/IP协议族

4.1 概念

4.2 TCP 连接

4.2.1 概念

4.2.2 TCP 连接的建⽴与关闭

TCP连接的建立：（三次握手）

TCP连接的关闭：（四次挥手）

4.2.3 ⻓连接

为什么要⻓连接？

⻓连接的实现⽅式（如何保证长连接）

5.HTTPS

5.1 定义

5.2 ⼯作原理

5.3 HTTPS 连接建⽴的过程

证书验证阶段

数据传输阶段

5.4 相关面试题

5.4.1 为什么数据传输是用对称加密？

5.4.2 为什么需要 CA 认证机构颁发证书？

5.4.3 浏览器是如何确保 CA 证书的合法性？

1. 证书包含什么信息？

2. 证书的合法性依据是什么？

3. 浏览器如何验证证书的合法性？

4. 只有认证机构可以生成证书吗？

5.4.4 既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？

5.4.5 本地随机数被窃取怎么办？

5.4.6 用了 HTTPS 会被抓包吗？

5.4.7 既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？

总结

你可能感兴趣的:(网络篇)