1，HTTP协议（HyperText Transfer Protocol，超文本传输协议）
网络传输协议，所有的WWW文件都必须遵守这个标准。
1）特点
- 基于TCP/IP通信协议。
- 默认端口80
可以改为8080或者其他端口。 - 客户端/服务端（C/S）的架构模型：请求响应模型，一次请求对应一次响应
- HTTP是无连接的
即限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 - HTTP是媒体独立的：
只要C/S知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。 - 无状态：
每次请求之间相互独立，不能交互数据。
2）历史版本
- HTTP 1.0：
GET、POST 和 HEAD方法；
每一次请求响应都会建立新的连接。 - HTTP 1.1：
OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法；
复用连接。
3）URL（UniformResourceLocator, 统一资源定位符）
是一种特殊类型的URI，包含了用于查找某个资源的足够的信息URL, 是互联网上用来标识某一处资源的地址。
举例：http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
从上面的URL可以看出，一个完整的URL包括以下几部分：
| URL部分 | 举例 | 说明 | 备注 |
|---|---|---|---|
| 协议 | http: | 代表网页使用的是HTTP协议，// 为分隔符 | 还可以使用：HTTP，FTP，HTTPS |
| 域名 | www.aspxfans.com | 一个URL中，也可以使用IP地址作为域名使用 | |
| 端口 | 8080 | 使用“:”作为分隔符。 | 如果省略端口部分，将采用默认端口 |
| 虚拟目录 | /news/ | 从域名后的第一个“/”开始到最后一个“/”为止，可省略 | |
| 文件名 | index.asp | 可省略。 如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分； 如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。 | |
| 锚 | name | 从“#”开始到最后 | 可省略 |
| 参数 | boardID=5&ID=24618&page=1 | 从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。 参数与参数之间用“&”作为分隔符。 |
2，HTTP方法
1）DELETE（删除）
场景
用于删除资源
方法与规范
其实虽然我们都说 POST（增） DELETE（删）PUT（改）GET（查），但其实真正我们是如何实现方法的是随意的，也就是你完全可以用 GET 删除资源，DELETE 增加资源，但这样是不规范的。
2）GET（获取）
1>场景
获取资源。
2>参数特点
- 参数明文（不安全）
敏感信息不建议使用 GET 方法。
参数可以保存到书签。 - 数据类型只允许 ASCII
传递 二进制 文件就能用 GET 方法。
如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。 - 可以被缓存
GET 方法支持缓存，当本次请求允许被缓存时，会将资源存值本地 cache ，在未过期的情况下直接取本地 cache；缓存过期后视情况而定。 - 请求长度会受限（2k)
根据浏览器不同，长度限制。
4）OPTIONS（预检请求）
场景
OPTIONS 方法的首要目的是 Priflight Request（预检请求）。
为什么要发预检请求？
我们都知道浏览器的同源策略，就是出于安全考虑，浏览器会限制从脚本发起的跨域HTTP请求，像XMLHttpRequest和Fetch都遵循同源策略。
浏览器限制跨域请求一般有两种方式：
浏览器限制发起跨域请求
跨域请求可以正常发起，但是返回的结果被浏览器拦截了
一般浏览器都是第二种方式限制跨域请求，那就是说请求已到达服务器，并有可能对数据库里的数据进行了操作，但是返回的结果被浏览器拦截了，那么我们就获取不到返回结果，这是一次失败的请求，但是可能对数据库里的数据产生了影响。
为了防止这种情况的发生，规范要求，对这种可能对服务器数据产生副作用的HTTP请求方法，浏览器必须先使用OPTIONS方法发起一个预检请求，从而获知服务器是否允许该跨域请求：如果允许，就发送带数据的真实请求；如果不允许，则阻止发送带数据的真实请求。
预检请求的范围：
一般 HTTP1.1 中的方法请求默认都会触发预检请求，但是简单请求满足一下条件也可以触发 Options 请求。
特点：
- 带有自定义头信息
- MIME Type Not in text/plain、multipart/form-data、application/x-www-form-urlencoded
方法特点
假如我现在有如下配置：
Access-Control-Allow-Methods：OPTIONS, PUT
那么当浏览器发起了 Priflight Request 后，只在包含在 被允许的 HTTP 方法中的请求会被通过（Simple Request除外），而没有被包含在内的请求，例如 DELETE 在OPTIONS 之后将不会被请求。
5）POST（新增）
1>场景
- 提交、添加资源。
- 大量检索参数的获取资源。
2>方法特点
- 参数不可见，不可缓存
- 不限制请求长度
- 数据类型不限
可以 提交文件 到服务器的。 - 请求方式
POST 请求与 GET 请求不同，他会首先提交 HEAD 信息，待得到 100 响应后，才会再次将 DATA 提交。
6）PUT（修改）
场景
PUT 与 PATCH 方法都是用于更新资源。
方法特点
PUT 对后台来说 PUT 方法的参数是一个完整的资源对象，它包含了对象的所有字段。
7）PATCH（局部更新）
场景
PUT 与 PATCH 方法都是用于更新资源；PATCH是对 PUT 方法的补充，用来对已知资源进行局部更新 。
方法特点
PATCH 对后台来说 PATCH 方法的参数只包含我们需要修改的资源对象的字段。
8）HEAD
1>场景
获取报头信息，例如检查 cache 是否被修改，是否过期？
2>方法特点
HEAD 方法与 GET 方法类似，但并不会返回响应主体。
9）TRACE
场景
回显服务器收到的请求，主要用于测试或诊断。
10）CONNECT
场景
HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
11）REST API规范
1>服务地址
如： http://10.0.0.1:8080/api/v1/dashborads
{schema}://{host}:{port}/{prefix}/{version}/{resources}/{action}
-schema：协议，http或https
-action：控制类接口动作
2>资源名称
- 小写，用“-”连接；
- 父级用资源的复数形式表示
如 详情：apple/{id}；列表：apples - 用查询变量（条件参数）表达算法的输入
如：/search?page=1&num=20；
3>向下兼容
- 由于一个API服务可以提供多个API接口，如果有不兼容和破坏性的更改，版本号将让你能更容易的发布API；如
GET /api/1.0/……GET /api/2.0/……
4）参数
- GET, DELETE, HEAD 方法，参数：路径参数+request参数，如 ?a=1&b=2；
- POST, PUT, PATCH, OPTIONS 方法：
body参数，json结构；
头信息的 Content-Type 为 application/json，在一些特殊接口中，可以允许 Content-Type 为 application/x-www-form-urlencoded 或者 multipart/form-data ，此时请求实体会被视作标准 POST 风格的参数进行处理；
在特殊场景下，例如查询参数长度超过浏览器限制、不允许使用DELETE方法等，可以使用POST方法代替。 - 参数命名：
动词-名次，不应该包含介词。
驼峰：groupName
3，HTTP消息结构
1）请求消息Request
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
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：
1>请求行（request line）
以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。
用来说明请求类型,要访问的资源以及所使用的HTTP版本。
GET说明请求类型为GET,[/562f25980001b1b106000338.jpg]为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。
2>请求头部（header）
紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息。
3>空行
请求头部后面的空行是必须的；即使第四部分的请求数据为空，也必须有空行。
4>请求数据（请求主体）
可以添加任意的其他数据。
2）响应消息Response
一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。
HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8
<html>
<head></head>
<body>
<!--body goes here-->
</body>
</html>
HTTP响应也由四个部分组成：
1>状态行(响应行)
组成：
- HTTP协议版本号（HTTP/1.1）
- 状态码（200）
- 状态消息（ok）
2>消息报头（Header）
用来说明客户端要使用的一些附加信息。
Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html)，编码类型是UTF-8。
3>空行
消息报头后面的空行是必须的。
4>响应正文
服务器返回给客户端的文本信息。
空行后面的html部分为响应正文。
3）响应头信息
HTTP请求头提供了关于请求，响应或者其他的发送实体的信息。
| 响应头 | 说明 | 备注 |
|---|---|---|
| User-Agent | 客户端浏览器版本 | 主要用于解决浏览器的兼容性问题 |
| HOST | 请求的目的地 | |
| Referer | 当前请求来源 | 1. 防盗链：比如一些电影网址盗用正版电影的播放路径，可以通过查看Referer判断请求从哪来。如果不是页面跳转而来的，是直接输入网址申请访问的，会返回null； 2. 统计工作：广告案例 |
| Allow | 服务器支持哪些请求方法 | 如GET、POST等 |
| Content-Encoding | 文档的编码（Encode）方法 | |
| Content-Length | 内容长度 | body消息大小； 必须和消息内容传输长度完全一致(http1.0除外；如果压缩了就是压缩后的长度). 如果长度不确定，设定 Transfer-Encoding:chunked，分块传输，此时基于长连接持续推送动态内容、Content-Length 字段会被忽略。get方法没用body所以长度为0 |
| Content-Type | MIME类型：本次响应体数据格式以及编码格式 | Servlet默认为text/plain，但通常需要显式地指定为text/html。 |
| Content-disposition | 服务器告诉客户端以什么格式打开响应体数据 | 值包括： 1. in-line:默认值,在当前页面内打开; 2. attachment;filename=xxx：以附件形式打开响应体。文件下载 |
| Date | 当前的GMT时间。 | 可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。 |
| Expires | 应该在什么时候认为文档已经过期，从而不再缓存它？ | |
| Last-Modified | 文档的最后改动时间。 | 客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。 |
| Location | 表示客户应当到哪里去提取文档。 | Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。 |
| Refresh | 表示浏览器应该在多少时间之后刷新文档，以秒计。 | 除了刷新当前文档之外，你还可以通过setHeader(“Refresh”, “5; URL=http://host/path”)让浏览器读取指定的页面。 |
| Server | 服务器名字。 | Servlet一般不设置这个值，而是由Web服务器自己设置。 |
| Set-Cookie | 设置和页面关联的Cookie。 | Servlet不应使用response.setHeader(“Set-Cookie”, …)，而是应使用HttpServletResponse提供的专用方法addCookie。 |
| WWW-Authenticate | 客户应该在Authorization头中提供什么类型的授权信息？ | 在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼””)。注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。 |
4，HTTP状态码
常见状态码：
200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误
1）1** 指示信息，表示请求已接收，继续处理
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
2）2** 成功，操作被成功接收并处理
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
3）3** 重定向，需要进一步的操作以完成请求
重定向(Redirect)
通过各种方法将各种网络请求重新定个方向转到其它位置
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久重定向。只要不是临时重定向全部用301 |
| 302 | Found | 临时重定向 |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
4）4** 客户端错误，请求包含语法错误或无法完成请求
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 请求路径没有对应的资源 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
5）5** 服务器错误，服务器在处理请求的过程中发生了错误
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
5，HTTP与HTTPS
1）区别
http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。http的连接很简单,是无状态的。HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
SSL（安全套接层，secure sockets layer）
TLS（传输层安全，transport layer security），是SSL的继任者。
安全层其实就是在明文的上层和TCP层之间加上一层加密，这样就保证上层信息传输的安全。
注：TLS是SSL的升级替代版，具体发展历史可以参考传输层安全性协议。
HTTP与HTTPS在写法上的区别也是前缀的不同，客户端处理的方式也不同，具体说来：
如果URL的协议是HTTP，则客户端会打开一条到服务端端口80（默认）的连接，并向其发送老的HTTP请求。
如果URL的协议是HTTPS，则客户端会打开一条到服务端端口443（默认）的连接，然后与服务器握手，以二进制格式与服务器交换一些SSL的安全参数，附上加密的 HTTP请求。
所以HTTPS比HTTP多了一层与SSL的连接，这也就是客户端与服务端SSL握手的过程，整个过程主要完成以下工作：
- 交换协议版本号
- 选择一个两端都了解的密码
- 对两端的身份进行认证
- 生成临时的会话密钥，以便加密信道。
SSL握手是一个相对比较复杂的过程，更多关于SSL握手的过程细节可以参考TLS/SSL握手过程
SSL/TSL的常见开源实现是OpenSSL，OpenSSL是一个开放源代码的软件库包，应用程序可以使用这个包来进行安全通信，避免窃听，同时确认另一端连接者的身份。这个包广泛被应用在互联网的网页服务器上。 更多源于OpenSSL的技术细节可以参考OpenSSL。
2）HTTP缓存
HTTP的缓存机制也是依赖于请求和响应header里的参数类实现的，最终响应式从缓存中去，还是从服务端重新拉取，HTTP的缓存机制的流程如下所示：
HTTP的缓存可以分为两种：
①强制缓存
需要服务端参与判断是否继续使用缓存，当客户端第一次请求数据是，服务端返回了缓存的过期时间（Expires与Cache-Control），没有过期就可以继续使用缓存，否则则不适用，无需再向服务端询问。
②对比缓存
需要服务端参与判断是否继续使用缓存，当客户端第一次请求数据时，服务端会将缓存标识（Last-Modified/If-Modified-Since与Etag/If-None-Match）与数据一起返回给客户端，客户端将两者都备份到缓存中 ，再次请求数据时，客户端将上次备份的缓存 标识发送给服务端，服务端根据缓存标识进行判断，如果返回304，则表示通知客户端可以继续使用缓存。
强制缓存优先于对比缓存。
上面提到强制缓存使用的的两个标识：
- Expires
Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。到期时间是服务端生成的，客户端和服务端的时间可能有误差。 - Cache-Control
Expires有个时间校验的问题，所有HTTP1.1采用Cache-Control替代Expires。
Cache-Control的取值有以下几种：
private: 客户端可以缓存。
public: 客户端和代理服务器都可缓存。
max-age=xxx: 缓存的内容将在 xxx 秒后失效
no-cache: 需要使用对比缓存来验证缓存数据。
no-store: 所有内容都不会缓存，强制缓存，对比缓存都不会触发。
我们再来看看对比缓存的两个标识：
- Last-Modified/If-Modified-Since
Last-Modified 表示资源上次修改的时间。
当客户端发送第一次请求时，服务端返回资源上次修改的时间：
Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT
客户端再次发送，会在header里携带If-Modified-Since。将上次服务端返回的资源时间上传给服务端。
If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT
服务端接收到客户端发来的资源修改时间，与自己当前的资源修改时间进行对比，如果自己的资源修改时间大于客户端发来的资源修改时间，则说明资源做过修改， 则返回200表示需要重新请求资源，否则返回304表示资源没有被修改，可以继续使用缓存。
上面是一种时间戳标记资源是否修改的方法，还有一种资源标识码ETag的方式来标记是否修改，如果标识码发生改变，则说明资源已经被修改，ETag优先级高于Last-Modified。
- Etag/If-None-Match
ETag是资源文件的一种标识码，当客户端发送第一次请求时，服务端会返回当前资源的标识码：
ETag: “5694c7ef-24dc”
客户端再次发送，会在header里携带上次服务端返回的资源标识码：
If-None-Match:“5694c7ef-24dc”
服务端接收到客户端发来的资源标识码，则会与自己当前的资源吗进行比较，如果不同，则说明资源已经被修改，则返回200，如果相同则说明资源没有被修改，返回 304，客户端可以继续使用缓存。
3）HTTPS是如何保证安全的，证书如何校验？
4）HTTP如何实现长连接？
6，HTTP工作原理
HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
以下是 HTTP 请求/响应的步骤：
- 客户端连接到Web服务器
一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。 - 发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。 - 服务器接受请求并返回HTTP响应
Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。 - 释放连接TCP连接
若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求; - 客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：
a. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
b. 解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
c. 浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
d. 服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
e. 释放 TCP连接;
f. 浏览器将该 html 文本并显示内容;
7，认证方式
1）Http Basic Auth
- 将用户名和密码用BASE64编码后放在请求头中，每个请求都携带这些信息。
- 不安全，明文传输。至少应该用https对其进行加密。
2）Digest认证
- 认证步骤：
1）客户端访问Http资源服务器。
服务器返回：nonce（随机数）和realm。
2） 客户端构造Authorization请求头，值包含username、realm、nouce、uri和response的字段信息。其中，realm和nouce就是（1）返回的值。nouce只能被服务端使用一次。uri(digest-uri)即Request-URI的值，但考虑到经代理转发后Request-URI的值可能被修改、因此实现会复制一份副本保存在uri内。response也可叫做Request-digest，存放经过MD5运算后的密码字符串，形成响应码。
（3）服务器验证包含Authorization值的请求，若验证通过则可访问资源。 - Digest认证可以防止密码泄露和请求重放，但没办法防假冒。所以安全级别较低。
3）HTTP SSL Client认证
- SSL认证安全级别较高，但需要承担证书费用。SSL可以防泄漏、假冒、重放，所以在Web系统中得到了广泛的应用。
SSL认证过程中涉及到一些重要的概念，数字证书机构的公钥、证书的私钥和公钥、非对称算法（配合证书的私钥和公钥使用）、对称密钥、对称算法（配合对称密钥使用）。 - 认证步骤：
（1）客户端请求服务资源，服务器要求客户端出示数字证书。
（2）客户端发送数字证书
（3）服务器通过数字证书机构的公钥验证数字证书的合法性，验证通过后取出证书的公钥。
（4）服务端随机生成一个随机数即为对称密钥，并使用非对称算法和证书公钥加密。这个加密后的字符串，只有发送的客户端能解。
（5）客服端使用非对称解密算法和证书私钥获取服务端发送的对称密钥。后续客户端和服务端的请求直接基于对称算法和对称密钥。由于只有客户端和服务端有对称密钥，所以后续发送的请求较安全。
4）OAuth2（Open Authrization，开放授权）
-
OAuth是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密资源，而无需将用户名和密码提供给第三方。比如我们熟知的通过qq/微信/微博等登录第三方平台。OAuth 1.0版本发布后有许多安全漏洞，所以在OAuth2.0里面完全废止了OAuth1.0。
-
OAuth2 认证和授权的过程中三个角色：
（1）服务提供方：提供受保护的服务和资源的，用户在这里面存了很多东西。
（2）用户： 存了东西（照片，资料等）在服务提供方的人。
（3）客户端：服务调用方，它要访问服务提供方的资源，需要在服务提供方进行注册，不然服务提供方不鸟它呀。 -
OAuth2 认证和授权的过程：
（1）用户想操作存放在服务提供方的资源；
（2）用户登录客户端，客户端向服务提供方请求一个临时token;
（3）服务提供方验证客户端的身份后，给它一个临时token;
（4）客户端获得临时token之后，将用户引导至服务提供方的授权页面，并请求用户授权。（在这个过程中会将临时token和客户端的回调链接/接口 发送给服务提供方 —很明显服务提供方到时会回来call这个接口在用户认证并授权之后）
（5）用户输入用户名密码登录，登录成功之后，可以授权客户端访问服务提供方的资源；
（6）授权成功后，服务提供方将用户引导至客户端的网页（call第4步里面的回调链接/接口）；
（7）客户端根据临时token从服务提供方那里获取正式的access token；
（8）服务提供方根据临时token以及用户的授权情况授予客户端access token;
（9）客户端使用access token访问用户存放在服务提供方的受保护的资源。
5）Token Auth
-
基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。
-
流程：
（1）用户使用用户名密码来请求服务器
（2）服务器进行验证用户的信息
（3）服务器通过验证发送给用户一个token
（4）客户端存储token，并在每次请求时附送上这个token值
（5）服务端验证token值，并返回数据
这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin。
6）JWT 认证机制（Json Web Token）
- JWT作为一个开放的标准（RFC 7519），定义了一种简洁的，自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在，这些信息是可信的，JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。
（1）简洁性
可以通过URL，POST参数或者在HTTP header发送，因为数据量小，传输速度也很快
（2）自包含性
负载中包含了所有用户所需要的信息，避免了多次查询数据库 - 常用场景：
（1）Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。
（2）Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。
扫一扫
440
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
