HTTP之请求消息Request

HTTP之回应消息Response

http无状态之cookie 、session和token

Session机制

http详解

工作流程

HTTP是基于传输层的TCP协议，而TCP是一个端到端的面向连接的协议。所谓的端到端可以理解为进程到进程之间的通信。所以HTTP在开始传输之前，首先需要建立TCP连接（“三次握手”）。在TCP三次握手之后，建立了TCP连接，此时HTTP就可以进行传输了。一个重要的概念是面向连接，既HTTP在传输完成之间并不断开TCP连接。在HTTP1.1中(通过Connection头设置)这是默认行为。

一次HTTP操作称为一个事务，其工作过程可分为四步：
1）首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。
2）建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
3）服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
4）客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。

HTTP之URL

HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息。

URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

从上面的URL可以看出，一个完整的URL包括以下几部分：

1.协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符。

2.域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用。

3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口。

4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”

5.文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名。

6.锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分

7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

URI和URL的区别

URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。

Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
URI一般由三部组成：
①访问资源的命名机制
②存放资源的主机名
③资源自身的名称，由路径表示，着重强调于资源。

URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。
采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
①协议(或称为服务方式)
②存有该资源的主机IP地址(有时也包括端口号)
③主机资源的具体地址。如目录和文件名等

URN，uniform resource name，统一资源命名，是通过名字来标识资源，比如mailto:[email protected]。

URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。
在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。
相反的是，URL类可以打开一个到达资源的流。

HTTP之请求消息Request

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：

请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。
- Get请求例子，使用Charles抓取的request：

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent  Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept  image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8

请求行：请求方法+url+支持的http版本号
- 请求方法（所有方法全为大写）有多种，各个方法的解释如下：
  - GET ：向特定的资源发出请求。
  - POST ：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
  - HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。
  - PUT：向指定资源位置上传其最新内容。
  - DELETE：请求服务器删除Request-URI所标识的资源
  - TRACE：请求服务器回送收到的请求信息，主要用于测试或诊断
  - CONNECT：保留将来使用
  - OPTIONS ：回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
- GET和POST的区别：
  - GET提交的数据会放在URL之后，以?分割URL和传输数据，参数之间以&相连，如EditPosts.aspx?name=test1&id=123456。 POST方法是把提交的数据放在HTTP包的Body中。
  - GET提交的数据大小有限制，最多只能有1024字节（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制。
  - GET方式需要使用Request.QueryString来取得变量的值，而POST方式通过Request.Form来获取变量的值
  - GET方式提交数据，会带来安全问题，比如一个登录页面，通过GET方式提交数据时，用户名和密码将出现在URL上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码。
请求头：说明服务器要使用的附加信息
- Accept方面的请求头：能接受（返回）哪些类型
  - 格式：type/sub-type
    - */* 表示任何类型
  - 举例：
    - Accept: application/json
    - Accept: text/plain
    - Accept: text/html
    - Accept: image/jpeg
    - Accept: image/png
    - Accept: application/pdf
  - Accept-Charset：能接受的字符集
  - Accept-Encoding：能接受的（编码）压缩类型，比如：gzip，deflate。
  - Accept-Language：能接受的语言类型
- User-Agent:告诉你我是哪种浏览器（所处的操作系统是什么类型）等信息
  - 举例：
    - User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN;rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
    - User-Agent：Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
- Referer：告诉服务器是从（参考）哪个链接去访问的。举例：Referer： https://www.google.co.uk/
- Keep-Alive：希望服务器保持此次连接（多长时间）
- Cache-Control：表示是否使用缓存
- Connection：完成本次请求的响应后，是否断开连接，是否要等待本次连接的后续请求了
  - Connection: close
  - Connection: keepalive

HTTP之回应消息Response

状态行、消息报头、空行、响应正文。

状态行：最常用的状态码及含义
- Server Error - 5xx：服务器错误类，服务器不能实现一种明显无效的请求
  - 500 INTERNAL SERVER ERROR
    - 服务器内部错误。最常见的原因是：服务器内部挂了，比如你传递参数中有些参数是空，而导致后台代码无法解析，出现异常而崩溃。
  - 502 BAD GATEWAY：网管错误
  - 503 SERVICE UNAVAILABLE：无服务。举例：比如服务器内部正在维护，暂时不提供服务
- Client Error - 4xx：客户端错误类，请求包含语法错误或者请求无法实现
  - 404 NOT FOUND
    - 找不到资源
    - 有些做法是：把属于401或403的原因，但是返回假装找不到而返回404
  - 400 BAD REQUEST
    - 错误的请求
    - 往往为了简化处理，把属于401的没有权限和属于403的有权限但是权限不够，往往都返回404
  - 401 UNAUTHORIZED
    - 没有权限访问该资源。典型情况：用户没有登录，没有获得对应的access token而直接访问某资源
- Redirection - 3xx：重定向类，为了完成请求，必须进一步执行的动作
  - 301 Moved
    - 该资源的URI接口已经变了，变成别的接口了。response header中应该告诉新接口地址，比如：URI: url地址
- Successful - 2xx：成功类，行为被成功地接受、理解和采纳
  - 200 OK
    - 服务器成功返回用户请求的数据
    - 往往为了简化处理，POST创建成功后应该返回201的但也返回200
  - 201 CREATED
    - 通过POST或PUT创建资源成功
    - 通过response header中会返回新创建的资源的url连接
    - response body可能有信息，也可能为空
  - 202 Accepted
    - 服务器接受了此请求，但是待会才会执行
  - 204 NO CONTENT
    - 资源创建成功，但是没有返回内容
    - 常用于DELETE或PUT操作的返回
- Informational - 1xx：信息类，请求收到，继续处理
消息报头：Response中有很多Content方面的字段，表示服务器返回的内容的各种类型说明
- Content-Encoding：此响应中使用了什么压缩方法（gzip，deflate）压缩响应中的对象
- Content-Language：用了什么语言
- Content-Length：数据内容的长度，单位：字节
- Content-Type：自己返回的数据是什么格式的
- Connection：和Request对应。Connection: close；Connection: keepalive。
- 以及其他一些表示当前信息的情况的：
  - Location：一个url地址，表示你想要的资源被转移到别处了，典型的是发生了302表示自动跳转，告诉你要的东西，换了地址了。

http无状态之cookie 、session和token

Cookie是服务器存储在本地计算机上的小块文本，并随每个请求发送到同一服务器。IETF RFC 2965 HTTP状态管理机制是一种通用的cookie规范。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端，浏览器解析cookie并将其保存为本地文件，该文件自动将来自同一服务器的任何请求绑定到这些cookie。
具体来说，cookie机制使用一种在客户端维护状态的方案。它是客户端会话状态的存储机制，他需要用户打开客户端的cookie支持。 Cookie的作用是解决HTTP协议中缺少无状态缺陷的问题。
通过扩展HTTP协议来实现cookie分发。服务器通过向HTTP响应头添加特殊指示来提示浏览器生成相应的cookie。但是，纯JavaScript等客户端脚本也可以生成cookie。根据某些原则，浏览器在后台自动将cookie的使用发送到服务器。浏览器检查所有存储的cookie。如果cookie声明范围大于或等于要请求的资源的位置，则cookie将附加到请求资源的HTTP请求标头并发送到服务器。
cookie的内容主要包括：名称，值，到期时间，路径和域。路径与域一起构成了cookie的范围。
- 如果未设置到期时间，则表示此cookie的生命周期是在浏览器会话期间，浏览器窗口关闭，并且cookie消失。生命周期为浏览器会话的cookie称为会话cookie。会话cookie通常不存储在硬盘上，而是存储在内存中。当然，这种行为不受监管。
- 如果设置了到期时间，浏览器会将cookie保存到硬盘，关闭它并再次打开浏览器。在超过设定的到期时间之前，这些cookie仍然有效。存储在硬盘上的Cookie可以在不同的浏览器进程之间共享，例如两个IE窗口。不同的浏览器对存储在内存中的cookie有不同的处理方法。

Session机制

session会话机制是一种服务器端机制，它使用类似于哈希表（可能还有哈希表）的结构来保存信息。
当程序需要为客户端的请求创建会话时，服务器首先检查客户端的请求是否包含会话标识符（称为会话ID）。如果包含它，它先前已为此客户端创建了一个会话。服务器根据会话ID检索会话（无法检索，将创建新会话），如果客户端请求不包含会话ID，则为客户端创建会话并生成与会话关联的会话ID。 session id应该是一个既不重复也不容易被复制的字符串。会话ID将返回给客户端以保存此响应。
该会话适用于每个用户。变量的值存储在服务器上。 sessionID用于区分使用哪个用户会话变量。当用户访问浏览器时，该值将返回给服务器。当客户端禁用cookie时，此值也可以设置为通过get返回给服务器。
保存此会话ID的方法可以是cookie，以便浏览器可以根据交互期间的规则自动将此标志用于服务器。通常，此cookie的名称与SEEESIONID类似。但是，cookie可以被人为禁止，因此必须有其他机制在禁用cookie时将会话ID传递回服务器。经常使用的一种技术称为URL重写，它只是将会话ID直接附加到URL路径。还有一种称为形式隐藏字段的技术。也就是说，服务器将自动修改表单并添加隐藏字段，以便在提交表单时将会话ID传递回服务器。
在安全性方面：当您访问使用会话并在您自己的计算机上创建cookie的站点时，建议服务器端的会话机制更安全，因为它不会任意读取客户端存储的信息。

Cookie和Sessions都能够进行会话跟踪，但原则并不相同。一般情况下，两者都可以满足需求，但有时候他们不能使用cookies，有时候不能使用Session。以下是两者和适用场所的特征比较。

不同的访问方法
- 只有ASCII字符串可以存储在cookie中。如果需要访问Unicode字符或二进制数据，则需要先对其进行编码。无法在cookie中直接访问Java对象。要存储稍微复杂的信息，使用cookie会更难。
- 会话可以访问任何类型的数据，包括但不限于字符串、Integer、List、Map等。 Session也可以直接存储Java Beans甚至任何Java类，对象等，使用起来非常方便。将Session视为Java容器类
不同的隐私政策
- Cookie存储在客户端阅读器中，对客户端可见。客户端上的某些程序可能会窥探、副本以更正cookie的内容。会话存储在服务器上，对客户端是透明的。不存在敏感信息泄露的风险。
- 如果您选择cookie，最好不要写敏感信息，如帐户密码。最好加密像Google、Baidu这样的cookie信息，并将其提交给服务器进行解密，以确保我自己可以读取cookie中的信息。如果选择Session，则可以省去很多麻烦。无论如何，它被放置在服务器上，并且会话中的任何隐私都可以得到有效保护。
有效期的差异
- 使用Google的任何人都知道，如果您已登录Google，Google的登录信息将长期有效。用户每次访问时都不必再次登录，Google会永久记录用户的登录信息。要达到这个效果，使用cookies将是一个不错的选择。只需将cookie的到期时间属性设置为一个非常大的数字。
- 由于Session依赖于名为JSESSIONID的cookie，并且Cookie JSESSIONID的到期时间默认为-1，因此只需关闭阅读器就会使Session无效，Session将无法永久完成信息。无法使用URL地址重写。此外，如果设置Session的超时时间太长，服务器将累积的Sessions越多，导致内存溢出的可能性就越大。
不同的服务器压力
- 会话保留在服务器端，每个用户都将生成一个会话。如果有很多并发用户，它会产生大量的Session并消耗大量内存。因此，具有高并发流量的站点（如Google、Baidu、Sina）不太可能使用Session来跟踪客户会话。
- Cookie保留在客户端上，不消耗服务器资源。如果有很多用户同时阅读，那么cookie是一个不错的选择。关于Google、Baidu、Sina，cookies可能是唯一的选择。
不同的浏览器支持
- 客户端浏览器需要支持Cookie。如果客户端禁用cookie或不支持cookie，则会话跟踪将无效。关于WAP上的应用程序，常规cookie无用。
- 如果客户端浏览器不支持cookie，则需要使用会话和URL地址重写。应该注意的是，Session程序中使用的所有URL都必须重写URL地址，否则会话会话跟踪将无效。对于WAP应用程序，会话+ URL地址重写可能是唯一的选择。
- 如果客户端支持cookie，则可以在浏览器窗口和子窗口中将cookie设置为有效（将到期时间设置为-1），或者可以将cookie设置为在所有阅读器窗口中有效（设置到期时间）大于1）0的整数。但是，Session只能在此阅读器窗口及其子窗口中使用。如果两个浏览器窗口彼此不相关，则它们将使用两个不同的会话。（与IE8下不同窗口相关的会话）
跨域支持的差异
- Cookie支持跨域访问。例如，如果domain属性设置为“.biaodianfu.com”，则所有以“.biaodianfu.com”为后缀的域名都可以访问cookie。跨域cookie现在通常在网络上使用，例如Google、Baidu、Sina。会话不支持跨域访问。会话仅在其所在的域名内有效
- 仅使用cookie或仅使用Sessions可能无法达到预期的效果。此时，您应该尝试使用Cookie和会话。 Cookie和Sessions的组合将在练习项目中实现许多意想不到的结果。

我的理解：

Session是保存在服务器上的数据结构，用于跟踪用户的状态。此数据可以保存在群集、数据库、文件中。
Cookie是客户端存储用户信息的机制。它用于记录有关用户的一些信息，是实现会话的一种方式。
http协议是无状态的：
- 每个请求都是一个新请求，并且不会记住先前通信的状态。
- 客户端和服务器之间的一次通信是会话
- 实现状态保留的方法：在客户端或服务器端存储与会话相关的数据
- 存储方法包括cookie、session，会话通常是指会话对象。
- 使用cookie，所有数据都存储在客户端上，注意不要存储敏感信息。
- 建议使用sesison模式，所有数据都存储在服务器端，session_id存储在客户端cookie中。
- 状态保持的目的是在一段时间内跟踪请求者的状态，并实现对当前请求者的数据的跨页访问。
- 注意：不同请求者之间不会共享此数据，与请求者一一对应

token

token的意思是“令牌”，是用户身份的验证方式

组成：uid+time+sign[+固定参数]
- uid: 用户唯一身份标识
- time: 当前时间的时间戳
- sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
- 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库
token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是服务端并不会保存身份认证相关的数据。
存放：token在客户端一般存放于localStorage，cookie，或sessionStorage中。在服务器一般存于数据库中。
token认证流程
- 用户登录，成功后服务器返回Token给客户端。
  - 服务器对令牌数据做一个签名，比如用HMAC-SHA256 算法，加上一个只有服务器才知道的密钥，对数据做一个签名，把这个签名和数据一起作为token ，由于密钥别人不知道，就无法伪造token了。
- 客户端收到数据后保存在客户端
- 客户端再次访问服务器，将token放入headers中
- 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
  - 服务器不保存token ，当客户端把这个token 给服务器发过来的时候，服务器再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名，和token 中的签名做个比较，如果相同，就知道客户端已经登录过了，并且可以直接取到客户端的user id , 如果不相同，数据部分肯定被人篡改过，则返回客户端：对不起，没有认证。
token可以抵抗csrf，cookie+session不行
- 假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。

HTTP应用

断点续传的实现原理
- HTTP协议的GET方法，支持只请求某个资源的某一部分；
- 206 Partial Content 部分内容响应；
- Range 请求的资源范围；
- Content-Range 响应的资源范围；
- 在连接断开重连时，客户端只请求该资源未下载的部分，而不是重新请求整个资源，来实现断点续传。
- 分块请求资源实例：
  - Eg1：Range: bytes=306302- ：请求这个资源从306302个字节到末尾的部分；
  - Eg2：Content-Range: bytes 306302-604047/604048：响应中指示携带的是该资源的第306302-604047的字节，该资源共604048个字节；
  - 客户端通过并发的请求相同资源的不同片段，来实现对某个资源的并发分块下载。从而达到快速下载的目的。目前流行的FlashGet和迅雷基本都是这个原理。
多线程下载的原理
- 下载工具开启多个发出HTTP请求的线程；
- 每个http请求只请求资源文件的一部分：Content-Range: bytes 20000-40000/47000；
- 合并每个线程下载的文件。
http代理

原文链接：http://caibaojian.com/http-protocol.html

代理服务器英文全称是Proxy Server，其功能就是代理网络用户去取得网络信息。形象的说：它是网络信息的中转站。
代理服务器是介于浏览器和Web服务器之间的一台服务器，有了它之后，浏览器不是直接到Web服务器去取回网页而是向代理服务器发出请求，Request信号会先送到代理服务器，由代理服务器来取回浏览器所需要的信息并传送给你的浏览器。
而且，大部分代理服务器都具有缓冲的功能，就好象一个大的Cache，它有很大的存储空间，它不断将新取得数据储存到它本机的存储器上，如果浏览器所请求的数据在它本机的存储器上已经存在而且是最新的，那么它就不重新从Web服务器取数据，而直接将存储器上的数据传送给用户的浏览器，这样就能显著提高浏览速度和效率。更重要的是：Proxy Server(代理服务器)是Internet链路级网关所提供的一种重要的安全功能，它的工作主要在开放系统互联(OSI)模型的对话层。·
http代理服务器的主要功能：
- 1）突破自身IP访问限制，访问国外站点。如：教育网、169网等网络用户可以通过代理访问国外网站；
- 2）访问一些单位或团体内部资源，如某大学FTP(前提是该代理地址在该资源的允许访问范围之内)，使用教育网内地址段免费代理服务器，就可以用于对教育网开放的各类FTP下载上传，以及各类资料查询共享等服务；
- 3）突破中国电信的IP封锁：中国电信用户有很多网站是被限制访问的，这种限制是人为的，不同Serve对地址的封锁是不同的。所以不能访问时可以换一个国外的代理服务器试试；
- 4）提高访问速度：通常代理服务器都设置一个较大的硬盘缓冲区，当有外界的信息通过时，同时也将其保存到缓冲区中，当其他用户再访问相同的信息时，则直接由缓冲区中取出信息，传给用户，以提高访问速度；
- 5）隐藏真实IP：上网者也可以通过这种方法隐藏自己的IP，免受攻击。

对于客户端浏览器而言，http代理服务器相当于服务器。而对于Web服务器而言，http代理服务器又担当了客户端的角色。

HTTPS传输协议原理

原理

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。

SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

浏览器将自己支持的一套加密规则发送给网站。 
网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。
- 证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
浏览器获得网站证书之后浏览器要做以下工作：
- 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
- 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
- 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
网站接收浏览器发来的数据之后要做以下的操作：
- 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
- 使用密码加密一段握手消息，发送给浏览器。
浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

如何防止中间人攻击

验证证书：Ocsp 全称在线证书状态检查协议 (rfc6960)，用来向 CA 站点查询证书状态，比如是否撤销。
通常情况下，浏览器使用 OCSP 协议发起查询请求，CA 返回证书状态内容，然后浏览器接受证书是否可信的状态。
将证书保存下来，浏览器请求时候直接通过自己的服务器发送回去，防止验证服务器出问题，还能加快访问速度。

中间人攻https：客户端say hello 后，被代理服务器拦截，代理服务器也有CA颁发的证书，他把自己的合法证书发给客户端，客户端用证书里面的公钥解密签名之后，得到了各种信息，一看信息都对上了，没毛病信任。然后代理服务器宰相真正的服务器say hello，服务器下发真正的证书，代理服务器假装自己是客户端，信任了证书，然后校验通过，发用真正公钥加密后的随机数给服务器，服务器当然能解开，也就是代理服务器作为客户端和真正的服务器建立了合法的通信。再看客户端在校验了代理服务器自己的证书后也建立了合法的通信，这个时候，代理服务器作为中间人，因为他有自己的私钥和真正的公钥，可以欺上瞒下，俩边的信息都从它这里过了一次，信息被他偷窥到。攻击成功。

怎么防御：客户端内置真正的公钥，当代理服务器把它自己的证书传过来的时候，客户端用内置的公钥去解密证书中的签名（签名是私钥加密的，可以用公钥解开），因为不是真正的私钥加密的所以解密失败，校验也就失败，连接中断。这也就是客户端信任所有的证书的风险—被中间人攻击。

计算机网络之http和https（知识点总结）

http详解

工作流程