文章目录
HTTP的状态
http为何是无状态的？怎样使无状态的http变得有状态？
http是一种无状态协议，即http不会保留服务端和客户端交互的任何信息。即：客户端上次的请求对这次没有任何影响，服务端也不会对客户端上次的请求做任何处理。
要想使http变得有状态，必须提供一种能够保持http状态的技术来支持：
有两种技术可以做到，一种是cookie，一种是session。
cookie
cookie是在客户端维持http状态的一种机制。是在客户端的一个存储空间。当服务端向客户端做出响应之后，会生成一个sessionId并放在响应头中的setcookie中，当客户端收到响应时会将其保存在cookie中，当下次向统一服务器发出请求之后，会连同cookie发送给服务端，服务端收到后会根据信息抽取出用户信息并进行响应。
根据以上的过程分析，可知，cookie最初是在服务端生成的，但是在客户端进行保存。
有的cookie也称为cookies，当客户端要对用户隐私进行保护时，通常会对cookie进行加密，并在服务端解密。
在理解cookie时，可以根据字面意思来加深理解，cookie本身有曲奇饼的意思，曲奇饼通常都是小小甜甜的。当放在网络协议中，它代表了放置在客户端的一小部分用户信息，广泛应用于很多网站，当我们打开某一网站，发现浏览器上有上次登录过的我们的信息，这时你会感觉很开心，就像吃了一块曲奇一样甜。（哈哈哈哈哈哈哈（好生硬的解释……）
session
除了可以通过cookie在浏览器保存用户信息，维持http的状态。同样可以通过session在服务端保存用户信息。
session的字面意思有“会话”的意思，举个栗子，当我们和别人打电话时，从拨通短话到挂断电话的过程，就可以算为一次会话。
当将其放入网路协议中，它又隐藏了“面向连接”，“状态保持”的意思。
session是在客户端第一次向服务端发出请求时生成的，当客户端访问服务器的时候，服务端将客户端信息以某种形式保存在服务端，这就是session。当客户端再次发出请求时，服务端只需要根据这个保存下的session来判断并返回响应即可。
虽然session保存在服务端，对客户端是透明的，但是他正常运行还需要客户端来维持，他需要使用cookie来维持状态。因为http是无状态的，无法保持客户端和服务端交互的信息，所以客户端在发出请求时，会发送一个JESSIONID的cookie，内容即为服务端发给客户端的session的Id，服务端只需根据判断session中的内容和cookie中的是否一致来判断是否请求来自同一用户。
cookie和session的区别/选择
- cookie存在客户端，session存在服务端；
- cookie的安全性低，存放在浏览器信息可能会被窃取；session的安全性相对较好。
- session存放在服务器会占用服务器的性能，对服务器的性能会有所影响，当考虑到为服务器分担压力时可以考虑使用cookie。
- cookie只能存储字符串，session可以存放任何类型的数据。
- cookie有大小限制，单个站点的cookie大小限制为3k。
总结
如果说cookie是检验客户身份的“通行证”，那么session就是存放在服务端的“客户身份明细表”，每次服务端在确认身份时，只需要从明细表中检查通行证中的信息即可。
ps：如果有的浏览器禁用cookie，session怎样判断请求是否来自同一用户？
如果浏览器禁用cookie，可以是用url重写技术来进行跟踪，即每次和HTTP交互，在url中加上"sessionId=。。。"来判断。
HTTP的三个版本
http/1.1和http/1.0
1.短连接和长连接：
在http1.1之前，http默认为短连接，即每次http请求都需要进行一次Tcp连接，都需要进行tcp的三次握手和四次挥手，有时大量的请求会占用浏览器和服务器大量的性能，客户端如果想进行长连接，必须自行设置Connection：keep-alive才可以进行长连接。
（短连接的优点：简化了服务器的设计，使服务器更容易接受并发的请求
缺点：如果每进行一次http通信就进行一次tcp连接，每次的连接都会浪费两个RTT的时间，即一个报文从发送到收到确认所经历的时间。因为在进行http连接之前必须进行tcp的三次握手，前两次握手经历一次RTT的时间，第三次握手再次经历一次，这样会占用很多时间，造成网络延迟严重）
在http1.1之后，http默认为长连接，即只要进行一次Tcp连接就可以进行多次http通信，默认为Connection：keep-alive，若想要断开连接，客户端或者服务端可以自行断开，使用Connection：close。
（长连接的优点：可以减轻服务器的处理请求的压力，提升服务器的性能，避免多余的连接资源的浪费。
缺点：如果keep-alive： timeout中的过期时间设置不当，同样会造成资源无效占用。长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。）
2.流水线处理
在http/1.0中，每次请求都必须得到响应之后才会进行下一次请求处理。由于受到网络延迟和带宽的影响，下一次请求可能需要等待很长时间。
在http/1.1中，支持流水线处理，即一个http请求不必等待收到响应之后进行下一次请求，客户可以同时发出多个请求。简言之，即：在同一个长连接中连续发出请求，而不用等待响应返回，这样可以减少延迟。
3.缓存机制
http1.1中在增加了很多处理缓存的机制如：Etag，If-match，If-none-match，If-unmodified-since；而在http1.0中主要通过if-modified-since和expries来处理缓存。
4.错误信息返回
在http1.1中增加了很多关于错误信息的状态码：如409,410,410表示服务器上的某个资源永久性的被删除；409表示请求的资源与当前状态发生冲突。
5.host头处理
1.0中认为一个服务器只能对应一个ip地址，所以在url中也不包含hostname，但是随着网络虚拟机的发展，一个物理服务器上允许运行多个虚拟机，他们共享同一个ip，在1.1中允许请求和响应投中增加host头域。若请求头中没有host头会返回400错误。
http/2 和http/1.x
简述：相比于http1.x的版本，http2大幅度提升了web服务器的性能。 在与http/1.1的语义完全兼容的基础上，进一步减少了网络延迟。
1.多路复用：
多路复用允许同时通过单一的Http2连接发起多重请求。允许同一连接上使用请求和响应双向数据流。同一tcp连接只需占用同一域名，通过数据流以帧为单位，从根本上上解决了因频繁连接的创建而引起的延迟，减少了内存消耗，提升了使用性能。
（问：比较一下1.1中的流水线处理和多路复用？）
流水线处理虽然可以在同一个长连接中发送多个请求，但是服务器在处理请求的时候仍然是按照顺序来处理的，带浏览器没有收到之前的所有请求对应的响应之前，同样会对之后的请求队列造成阻塞(排队阻塞)，这称为队头阻塞。所以，流水线处理机制并没有从根本上上解决问题。流水线处理可以理解为半双工通信（双向交替运输）的过程。
多路复用和流水线处理不同，虽然也遵循“请求–响应”机制，但是多路复用对同一时间的多个请求的响应的顺序没有限制，避免了队头阻塞，又能更快做出响应。比如，当复用同一个tcp时，如果此时有A请求和B请求，如果服务器正在处理A请求，但是A请求的业务需求量比较大，为了减少延迟，这时先把处理好的A请求的响应返回，然后处理B请求，当B请求处理完之后，再继续处理A请求。这个过程可理解为全双工（双向同时传输）通信的过程。
2. 二进制分层
在不改动http1.1的语义，方法，首部字段的情况西喜爱，怎样做到突破性能限制，改进传输性能？
关键
在应用层和传输层之间增加一个二进制分层。
二进制分层，将所有信息分割为更小的信息和帧，对已采用二进制编码，其中首部信息会封装到headers frame中，请求体会封装到Data frame中。
HTTPS
https是怎样实现的？
证书的获取（申请）
证书申请，最重要的一步就是获取ssl证书，一般由公司或者个人开发者向CA机构提出申请，CA机构对申请进行验证之后使证书得到信任。
- 生成私钥。首先，申请方要通过RSA（一般情况下）加密算法生成私钥，私钥保存在自己的服务器上，不提供给任何人。
- 通过私钥生成证书签名请求（CSR），其中CSR中附带有公钥，需要提供一些申请者相关的信息【域名、拥有者等信息】，将请求发送给CA机构请求验证，只有CA机构认证之后的证书才是可信赖的证书。
- CA机构收到证书签名请求，并对其进行验证，通过验证之后会在证书上添加部 分信息（有CA机构的签名，有效期，指纹算法，签名算法等信息）。
- 对证书完成签名。（其中的详细步骤如下：）
（1）对申请的证书通过指纹/hash算法生成hash值。
（2）用CA机构的私钥对hash值通过签名算法进行加密生成密文，这个密文就是数字证书。
（3）将数字证书签在证书的最后面，完成签名，得到完整的证书，返回给申请者。
（4）申请者得到完整的证书，保证了https服务受信任。
客户端识别证书
当服务器申请到ssl证书之后，客户端怎么能知道证书是受信任的呢？大部分浏览器使用的方法都基本一样，基本都是在系统或者浏览器准备CA机构权威认证的相关信息。具体过程如下：
- 当浏览器访问https服务时，会事先准备好自身浏览器支持的Cipher（c1，c2，c3），其中包括浏览器支持的一些非对称加密，对称加密，hash算法等，将这些信息一并发送给服务器。
- 当服务器收到请求以及这一系列Cipher之后，会将这一系列Cipher和自己支持的加密算法作对比，并从中抽取一个双方共同支持的密文通信加密算法。
- 浏览器确认和服务器之后的密文通信的加密算法。
- 浏览器通过证书中的公钥使用签名算法对数字签名进行解密，获取证书对应的hash值。
- 通过hash/指纹算法获取证书的hash值。
- 对比这两个hash值，如果相等则说明该证书值得信任。（通过数字签名来保证证书内容没有被篡改）
https的密文通信
经过了之前的过程，接下来就是具体的通信过程：
- 客户端确认可服务端的证书受信任，并确认了双方进行密文通信的一系列加密算法（非对称加密算法，信息验证的hash算法，正文通信的对称加密算法）。
- 客户端首先生成一个随机数，然后公钥通过非对称加密算法对随机数进行非对称加密算法生成随机秘钥，对通信体通过hash算法生成通信体的hash值，然后使用随机秘钥对hash值通过对称加密生成加密签名。并将其发送给服务端。
- 服务端收到加密签名之后，使用私钥将随机秘钥进行非对称解密得到随机数，随机数通过对称解密算法对加密签名进行解密生成hash值，在使用hash算法生成通信体对应的hash值，二者进行比较，验证之前是否加密成功。
- 如果验证通过，服务端还是使用hash算法生成通信体的hash值，再使用随机数进行对称加密生成加密签名，发送给客户端。
- 客户端收到之后按照相同的方法进行解密，验证是否加密成功。
- 成功的话整个链接过程完成，之后将使用随机数和约定的对称加密算法进行密文通信，【如果上面的任何步骤出现问题，都将会结束整个握手过程，导致建立安全连接失败。
HTTP存在哪些安全问题？
- http使用明文通信，通信内容可能被窃听；
- http通信时不会验证通信方的身份，通信方身份可能会遭到伪装；
- http通信时报文不能保证完整性，报文内容可能被篡改。
3164
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
