网络知识 | Leoliu

HTTP

HTTP 请求报文

HTTP 响应报文

HTTP的请求方式

GET
POST
HEAD
PUT
DELETE
OPTIONS

GET和POST方式的区别

GET：用来获取资源

安全：不应该引起server端的任何状态变化（GET、HEAD、OPTIONS）
幂等：同一个请求方法执行多次和执行一次的效果完全相同。（GET、PUT、DELETE）
可缓存的：请求是否可以被缓存（GET、HEAD）

POST：用来处理资源

非安全
非幂等
不可缓存

状态码

1xx:这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应
2xx:这一类型的状态码，代表请求已成功被服务器接收、理解、并接受
3xx:重定向，需要进一步的操作以完成请求
4xx:这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。
5xx:表示服务器无法完成明显有效的请求。[56]这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生

常见状态代码、状态描述的说明如下。

200 OK：客户端请求成功。
400 Bad Request：客户端请求有语法错误，不能被服务器所理解。
401 Unauthorized：请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。
403 Forbidden：服务器收到请求，但是拒绝提供服务。
404 Not Found：请求资源不存在，举个例子：输入了错误的URL。
500 Internal Server Error：服务器发生不可预期的错误。
503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，举个例子：HTTP/1.1 200 OK（CRLF）

连接建立流程

HTTP特点(缺点)

无连接
HTTP的持久连接
无状态
Cookie/Session

持久连接

与持久连接有关的请求头部字段:

Connection:keep-alive 客户端是否期许使用持久连接
time:20 连接在20s没不会断开，多个请求可以复用
max:10 这条连接最对可以发生多少个http请求及响应对

怎么判断一个请求是否结束的？

响应报文
Content-length:1024
所接收到数据的字节数是否与Content-length相同来判断这次请求是否结束

chunked:最后会有一个空的chunked
根据响应报文中chunked是否为空判断请求是否结束

Charles的抓包原理

利用http的中间人攻击来实现的

Cookie保存在客户端，主要用来记录用户状态，区分用户

修改Cookie：
新cookie覆盖旧cookie
删除cookie 通过expires或者maxAge

保证Cookie的安全：

对Cookie进行加密处理
只在https上携带Cookie
设置Cookie为httpOnly,防止跨站脚本攻击

Session技术依赖Cookie,保存在服务端

HTTPS

HTTPS = HTTP + SSL/TLS

HTTPS 连接的建立流程：

①客户端向服务器传送客户端SSL/TLS协议的版本号，加密算法的种类，产生的随机数C，以及其他服务器和客户端之间通讯所需要的各种信息。

②服务器向客户端传送 SSL/TLS协议的版本号，商定好的加密算法，随机数S以及其他相关信息，同时服务器还将向客户端传送自己的数字证书。

③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。

④客户端随机产生一个预主秘钥，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的预主秘钥传给服务器。同时用随机数C、随机数S、预主秘钥共同组装成会话秘钥，会话秘钥就是之后用于对称加密的秘钥。

⑤服务器收到被客户端通过公钥加密的预主秘钥后，用私钥进行解密，得到预主秘钥，然后用随机数C、随机数S、预主秘钥共同组装成会话秘钥。

⑥然后客户端和服务端使用相同的会话秘钥来加密会话消息,用来发送加密的握手消息。

整个过程的流程图如下：

上面第⑤步分两种情况，服务端不验证客户端证书和服务端验证客户端证书，
上面的流程执行是不验证的情况，如果要验证的话，流程是这样的：

如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的预主秘钥一起传给服务器。

如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断。

预主秘钥:客户端产生第一个随机秘钥

会话秘钥 = random S + random C + 预主秘钥

签名就是在信息的后面再加上一段内容，可以证明信息没有被修改过，怎么样可以达到这个效果呢？一般是对信息做一个hash计算得到一个hash值，注意，这个过程是不可逆的，也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时，把这个hash值加密后做为一个签名和信息一起发出去。接收方在收到信息后，会重新计算信息的hash值，并和信息所附带的hash值(解密后)进行对比，如果一致，就说明信息的内容没有被修改过，因为这里hash计算可以保证不同的内容一定会得到不同的hash值，所以只要内容一被修改，根据信息内容计算的hash值就会变化。当然，不怀好意的人也可以修改信息内容的同时也修改hash值，从而让它们可以相匹配，为了防止这种情况，hash值一般都会加密后(也就是签名)再和信息一起发送，以保证这个hash值不被修改。至于如何让别人可以解密这个签名，这个过程涉及到数字证书等概念，我们后面在说到数字证书时再详细说明，这里您先只需先理解签名的这个概念。

客户端证书验证：

证书上面有一个数字签名，可用于验证证书的真伪，这个数字签名同样是利用公开密钥方法加密的，证书办法机构会用自己的私钥对其加密，客户端则用给定的公钥对齐进行解密，解密后得到的内容就拿去验证证书是不是真的；在这个过程中，对证书进行解密的公钥如何传递给客户端是一个问题，因为一旦在网络传输中，公钥被攻击者掉包的话，证书也就有了伪造的可能，所以目前的做法是，在浏览器生产的时候就会内置一些常用的认证机构的公钥。（注意，验证证书真伪用的这组公钥私钥是证书办法机构的，和服务器端用来机密的公钥私钥不是同一对，就是在SSL中，因为证书的使用，会有两对密钥）；

HTTPS 使用了哪些加密手段? 为什么？

连接建立过程中使用的非对称加密，非对称加密很耗时
后续的通信过程使用对称加密

加密算法

常见的加密算法可以分成三类，对称加密算法，非对称加密算法和Hash算法。

对称加密

指加密和解密使用相同密钥的加密算法。对称加密算法的优点在于加解密的高速度和使用长密钥时的难破解性。假设两个用户需要使用对称加密方法加密然后交换数据，则用户最少需要2个密钥并交换使用，如果企业内用户有n个，则整个企业共需要n×(n-1) 个密钥，密钥的生成和分发将成为企业信息部门的恶梦。对称加密算法的安全性取决于加密密钥的保存情况，但要求企业中每一个持有密钥的人都保守秘密是不可能的，他们通常会有意无意的把密钥泄漏出去——如果一个用户使用的密钥被入侵者所获得，入侵者便可以读取该用户密钥加密的所有文档，如果整个企业共用一个加密密钥，那整个企业文档的保密性便无从谈起。
常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES

非对称加密

指加密和解密使用不同密钥的加密算法，也称为公私钥加密。假设两个用户要加密交换数据，双方交换公钥，使用时一方用对方的公钥加密，另一方即可用自己的私钥解密。如果企业中有n个用户，企业需要生成n对密钥，并分发n个公钥。由于公钥是可以公开的，用户只要保管好自己的私钥即可，因此加密密钥的分发将变得十分简单。同时，由于每个用户的私钥是唯一的，其他用户除了可以可以通过信息发送者的公钥来验证信息的来源是否真实，还可以确保发送者无法否认曾发送过该信息。非对称加密的缺点是加解密速度要远远慢于对称加密，在某些极端情况下，甚至能比非对称加密慢上1000倍。
常见的非对称加密算法有：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

Hash算法

Hash算法特别的地方在于它是一种单向算法，用户可以通过Hash算法对目标信息生成一段特定长度的唯一的Hash值，却不能通过这个Hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。
常见的Hash算法有MD4、MD5、HAVAL、SHA
在证书领域，一般都是用SHA（安全哈希算法）
加密算法的效能通常可以按照算法本身的复杂程度、密钥长度（密钥越长越安全）、加解密速度等来衡量。上述的算法中，除了DES密钥长度不够、MD2速度较慢已逐渐被淘汰外，其他算法仍在目前的加密系统产品中使用。

TCP / UDP

网络七层协议

网络四层协议

传输层协议

TCP 传输控制协议
UDP 用户数据报协议

UDP

特点

无连接
尽最大努力交付（不保证可靠传输）
面向报文
- 既不合并，也不拆分

功能：

复用
分用
差错检测

TCP

特点

面向连接：数据传输前，建立连接（三次握手，四次挥手）
可靠传输：无差错、不丢失、不重复、按序到达（通过停止等待协议实现）
面向字节流
流量控制（滑动窗口协议）
拥塞控制（慢开始,拥塞避免快恢复,快重传）

三次握手为什么不是两次

为了解决SYN请求超时的情况，防止重复建立连接。

客户端发送SYN 超时后，客户端会重传，如果只有两次握手，重传后，客户端发送SYN和ACK，建立连接，但这时超时的SYN到达后，服务端又会重新发送SYN和ACK，又一次建立了连接，这不是我们所期望的。
如果是三次握手的情况可以规避这种问题，重传后，客户端发送了ACK确认报文给服务端，然后建立连接，当超时报文到达后，服务端又会重新发送SYN和ACK，客户端不会再发送ACK给服务端，服务端就可知道这个一个超时报文。