提供基础用法，基础概念引用 MDN、W3C，基础内容做扩展知识，可应对面试，详细原理及应用需要去官网、GitHub 深入学习。
1、HTTP 、 HTTPS 、 HTTP2.0
HTTP 和 HTTPS 的基本概念
HTTP: 超文本传输协议（HyperText Transfer Protocol：HTTP）是一个用于传输超媒体文档（例如 HTML、图片文件、查询结果等）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端 - 服务端(C-S)模型，客户端打开一个连接以发出请求，然后等待直到收到服务器端响应。HTTP 是无状态协议，这意味着服务器不会在两个请求之间保留任何数据（状态）。尽管通常基于 TCP/IP 层，但它可以在任何可靠的传输层上使用，也就是说，该协议不会像 UDP 那样静默的丢失消息。
HTTPS: 超文本传输安全协议（Hypertext Transfer Protocol Secure：HTTPS）是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 协议的主要作用是：建立一个信息安全通道，来确保数组的传输，确保网站的真实性。
HTTP 和 HTTPS 的区别
HTTP 传输的数据都是未加密的，也就是明文的，网景公司设置了 SSL 协议来对 HTTP 协议传输的数据进行加密处理，简单来说 HTTPS 协议是由 HTTP 和 SSL 协议构建的可进行加密传输和身份认证的网络协议，比 HTTP 协议的安全性更高。
主要的区别如下：
- HTTPS 协议需要 CA 证书，费用较高。HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。使用不同的链接方式，端口也不同，一般而言，HTTP 协议的端口为 80，HTTP 的端口为443。
- HTTP 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。
- HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 SSL 握手需要的 9 个包，所以一共是 12 个包。
HTTPS 协议的优点
使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。谷歌曾在 2014 年 8 月份调整搜索引擎算法，并称“比起同等 HTTP 网站，采用 HTTPS 加密的网站在搜索结果中的排名将会更高”。HTTPS 握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20%的耗电。HTTPS 缓存不如 HTTP 高效，会增加数据开销。SSL 证书也需要钱，功能越强大的证书费用越高。SSL 证书需要绑定 IP，不能再同一个 IP 上绑定多个域名，ipv4 资源支持不了这种消耗。
HTTP2.0
在 HTTP1.1 协议之前，每一个请求都要新建一个链接；在 HTTP 1.1 之后新增了 keep-alive 字段，可以复用原有的 TCP 链接，无需每来一个请求就三次握手创建一个 TCP 链接，也无需一个响应结束四次挥手关闭一个 TCP 链接，在一定程度上提高了整体协议效率。但是，依然存在其他问题，例如：对头阻塞问题(Head-of-line blocking)。在 HTTP 1.1 协议下，同一个网站内所有 HTTP 请求的请求顺序是流水线式的顺序执行的，即虽然可能共用了同一个 TCP 链接通道，但是同一个 TCP 链接通道下的两个请求会存在阻塞等待的情况：如果前一个 HTTP请求没有处理完，第二个 HTTP 请求只能阻塞等待，这样停滞时间会影响整体协议的传输效率。并且，在不同的浏览器中，同一域名下并发连接的数目都是有限的，而且假设其中一个链接通道中某个请求延迟或者等待，将直接阻塞后面队列中的请他请求的请求时间。
HTTP2.0 在不改变当前协议整体格式及语义的前提下，对 HTTP 协议的传输进行了优化，使得 HTTP2.0 的整体传输效率得到了很大的提升，具体包括二进制分帧、头部压缩、数据推送等。具体参见 HTTP2.0。
HTTP2.0 特点如下：
- 内容安全，因为 HTTP2.0 是基于 HTTPS 的，天然具有安全特性，通过 HTTP2.0 的特性可以避免单纯使用 HTTPS 的性能下降。
- 二进制格式，HTTP1.X 的解析是基于文本的，HTTP2.0 将所有的传输信息分割为更小的消息和帧，并对他们采用二进制格式编码，基于二进制可以让协议有更多的扩展性，比如引入了帧来传输数据和指令。
- 多路复用，这个功能相当于是长连接的增强，每个 request 请求可以随机的混杂在一起，接收方可以根据 request 的 id 将 request 再归属到各自不同的服务端请求里面，另外多路复用中也支持了流的优先级，允许客户端告诉服务器那些内容是更优先级的资源，可以优先传输。
2、HTTP状态码/请求头/响应头
HTTP 建立连接与 HTTPS 的工作原理参见 笔记。
HTTP 状态码
| 状态码 | 定义 |
|---|---|
| 100 | Continue 继续。客户端应继续其请求 |
| 101 | Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到 HTTP 的新版本协议 |
200 |
OK 请求成功。一般用于 GET 与 POST 请求 |
201 |
Created 已创建。成功请求并创建了新的资源。[POST/PUT/PATCH]：用户新建或修改数据成功。 |
202 |
Accepted 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information 非授权信息。请求成功。但返回的 meta 信息不在原始的服务器，而是一个副本 |
204 |
No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档。[DELETE]：用户删除数据成功 |
| 205 | Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content 部分内容。服务器成功处理了部分 GET 请求 |
| 300 | Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
301 |
Moved Permanently 永久移动。请求的资源已被永久的移动到新 URI，返回信息会包括新的 URI，浏览器会自动定向到新 URI。今后任何新的请求都应使用新的 URI 代替 |
302 |
Found 临时移动。与 301 类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other 查看其它地址。与 301 类似。使用 GET 和 POST 请求查看 |
304 |
Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused 已经被废弃的 HTTP 状态码 |
| 307 | Temporary Redirect 临时重定向。与 302 类似。使用 GET 请求重定向 |
400 |
Bad Request 客户端请求的语法错误，服务器无法理解。[POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。 |
401 |
Unauthorized 请求要求用户的身份认证 |
| 402 | Payment Required 保留，将来使用 |
403 |
Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求 |
404 |
Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed 客户端请求中的方法被禁止 |
406 |
Not Acceptable 服务器无法根据客户端请求的内容特性完成请求。[GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式） |
| 407 | Proxy Authentication Required 请求要求代理的身份认证，与 401 类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict 服务器完成客户端的 PUT 请求是可能返回此代码，服务器处理请求时发生了冲突 |
410 |
Gone 客户端请求的资源已经不存在。410 不同于 404，如果资源以前有现在被永久删除了可使用 410 代码，网站设计人员可通过 301 代码指定资源的新位置。[GET]：用户请求的资源被永久删除，且不会再得到的。 |
| 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 的请求头信息 |
422 |
Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。 |
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 协议的版本，无法完成处理 |
HTTP 常用请求头
| 协议头 | 说明 |
|---|---|
Accept |
可接受的响应内容类型（Content-Types） |
| Accept-Charset | 可接受的字符集 |
| Accept-Encoding | 可接受的响应内容的编码方式 |
| Accept-Language | 可接受的响应内容语言列表 |
| Accept-Datetime | 可接受的按照时间来表示的响应内容版本 |
Authorization |
用于表示 HTTP 协议中需要认证资源的认证信息 |
Cache-Control |
用来指定当前的请求/回复中的，是否使用缓存机制 |
| Connection | 客户端（浏览器）想要优先使用的连接类型 |
Cookie |
由之前服务器通过Set-Cooki（e 见下文）设置的一个HTTP协议Cookie |
| Content-Length | 以 8 进制表示的请求体的长度 |
| Content-MD5 | 请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果 |
Content-Type |
请求体的 MIME 类型 （用于 POST 和 PUT 请求中） |
| Date | 发送该消息的日期和时间（以 RFC 7231 中定义的"HTTP 日期"格式来发送） |
| Expect | 表示客户端要求服务器做出特定的行为 |
| From | 发起此请求的用户的邮件地址 |
| Host | 表示服务器的域名以及服务器所监听的端口号。如果所请求的端口是对应的服务的标准端口（80），则端口号可以省略 |
| If-Match | 仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新某个资源后，该资源未被修改的情况下，才更新该资源 |
| If-Modified-Since | 允许在对应的资源未被修改的情况下返回 304 未修改 |
| If-None-Match | 允许在对应的内容未被修改的情况下返回 304 未修改（ 304 Not Modified ），参考 超文本传输协议 的实体标记 |
| If-Range | 如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否则，返回整个新的实体 |
| If-Unmodified-Since | 仅当该实体自某个特定时间以来未被修改的情况下，才发送回应 |
| Max-Forwards | 限制该消息可被代理及网关转发的次数 |
| Origin | 发起一个针对跨域资源共享的请求（该请求要求服务器在响应中加入一个 Access-Control-Allow-Origin 的消息头，表示访问控制所允许的来源）。 |
| Pragma | 与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生 |
| Proxy-Authorization | 用于向代理进行认证的认证信息 |
| Range | 表示请求某个实体的一部分，字节偏移以 0 开始 |
| Referer | 表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer 其实是 Referrer 这个单词，但 RFC 制作标准时给拼错了，后来也就将错就错使用 Referer 了 |
| TE | 浏览器预期接受的传输时的编码方式：可使用回应协议头 |
| Transfer-Encoding | 中的值（还可以使用"trailers"表示数据传输时的分块方式）用来表示浏览器希望在最后一个大小为 0 的块之后还接收到一些额外的字段 |
User-Agent |
浏览器的身份标识字符串 |
| Upgrade | 要求服务器升级到一个高版本协议 |
| Via | 告诉服务器，这个请求是由哪些代理发出的 |
| Warning | 一个一般性的警告，表示在实体内容体中可能存在错误 |
常用的 Content-Type 内容（MIME 类型）
浏览器显示的内容有 HTML、XML、GIF、Flash 等，通过 MIME Type 决定用什么内容什么形式来显示。MIME 类型对大小写不敏感，但是传统写法都是小写。常见的 MIME 类型如下：
| 说明 | Type |
|---|---|
| 超文本标记语言文本 .html、.html | text/html |
| 普通文本 .txt | text/plain |
| XML 文件 .xml | text/xml |
| GIF 图形 .gif | image/gif |
| JPEG 图形 .jpeg、.jpg | image/jpeg |
| PNG 图形 .png | image/png |
| au 声音文件 .au | audio/basic |
| MIDI 音乐文件 mid、.midi | audio/midi、audio/x-midi |
| RealAudio 音乐文件 .ra、.ram | audio/x-pn-realaudio |
| MPEG 文件 .mpg、.mpeg | video/mpeg |
| AVI 文件 .avi | video/x-msvideo |
| RTF 文本 .rtf | application/rtf |
| GZIP 文件 .gz | application/x-gzip |
| TAR 文件 .tar | application/x-tar |
| XHTML格式 | application/xhtml+xml |
| XML数据格式 | application/xml |
| Atom XML聚合格式 | application/atom+xml |
| JSON数据格式 | application/json |
| pdf格式 | application/pdf |
| Word文档格式 | application/msword |
| 二进制流数据（如常见的文件下载） | application/octet-stream |
| <form encType=””>中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式） | application/x-www-form-urlencoded |
| 表单中进行文件上传时 | multipart/form-data |
3、WebSocket
WebSocket 协议最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。这是与 HTTP 协议最大的不同点。下面内容来自 阮一峰、MDN-WebSocket。
- 建立在 TCP 协议之上，服务器端的实现比较容易。
- 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。
- 数据格式比较轻量，性能开销小，通信高效。
- 可以发送文本，也可以发送二进制数据。
- 没有同源限制，客户端可以与任意服务器通信。
- 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。
ws://example.com:80/some/path
WebScoket 相关 api 及用法
if('WebSocket' in window) {
// 构造函数，返回一个 WebSocket 对象，连接的 URL 为 WebSocket 服务器将响应的 URL。
var ws = new WebSocket('wss://echo.websocket.org')
// 用于指定连接成功后的回调函数。
ws.onopen = (evt) => {
console.log('Connection open ...')
ws.send('Hello WebSockets!')
}
// 用于指定当从服务器接受到信息时的回调函数。
ws.onmessage = (evt) => {
console.log( 'Received Message: ' + evt.data)
ws.close()
}
// 用于指定连接失败后的回调函数。
ws.onerror = (evt) => {
consoleo.log('Error')
}
// 用于指定连接关闭后的回调函数。
ws.onclose = (evt) => {
console.log('Connection closed.')
}
}
可使用 addEventListener() 或将一个事件监听器赋值给本接口的 oneventname 属性，来监听 ws 事件。
// Connection opened
ws.addEventListener('open', (evt) => {
ws.send('Hello WebSockets!')
})
// 使用 binaryType 属性，显式指定收到的二进制数据类型。
ws.binaryType = 'blob';
// Listen for messages
ws.addEventListener('message', (evt) => {
console.log('Message from server ', evt.data)
})
WebSocket.readyState 返回当前 WebSocket 的链接状态，为只读属性。值为以下其中之一
- 0 (WebSocket.CONNECTING) 正在链接中
- 1 (WebSocket.OPEN) 已经链接并且可以通讯
- 2 (WebSocket.CLOSING) 连接正在关闭
- 3 (WebSocket.CLOSED) 连接已关闭或者没有链接成功
switch (ws.readyState) {
case WebSocket.CONNECTING:
// do something
break;
case WebSocket.OPEN:
// do something
break;
case WebSocket.CLOSING:
// do something
break;
case WebSocket.CLOSED:
// do something
break;
default:
// this never happens
break;
}
WebSocket.bufferedAmount 表示还有多少字节的二进制数据没有发送出去。它可以用来判断发送是否结束。
The WebSocket.bufferedAmount read-only property returns the number of bytes of data that have been queued using calls to send() but not yet transmitted to the network.
This value resets to zero once all queued data has been sent. This value does not reset to zero when the connection is closed; if you keep calling send(), this will continue to climb.
var data = new ArrayBuffer(10000000);
socket.send(data);
if (socket.bufferedAmount === 0) {
// 发送完毕
} else {
// 发送还没结束
}
4、RESTful api
根据 HTTP 标准，HTTP 请求可以使用多种请求方法。HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
- GET 请求指定的页面信息，并返回实体主体。
- HEAD 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
- POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
- PUT 从客户端向服务器传送的数据取代指定的文档的内容。
- DELETE 请求服务器删除指定的页面。
- CONNECT HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
- OPTIONS 允许客户端查看服务器的性能。
- TRACE 回显服务器收到的请求，主要用于测试或诊断。
- PATCH 是对 PUT 方法的补充，用来对已知资源进行局部更新 。
为追求更好的开发效率与协同分工，网络应用程序的开发应遵循前后端分离策略，为此，需要一套成熟的互联网应用程序的 API 设计理论，RESTful api 便是其中最为流行的一种。
API 与用户的通信协议一般使用 HTTP/HTTPS 协议。应该尽量将API部署在专用域名之下，以 api 做前缀开头，如 https://api.example.com。同时应该将 API 的版本号放入 URL，如 https://api.example.com/v1/。另一种做法是将版本号放在HTTP头信息中。
API 的具体网址，也称路径（endpoint），在RESTful架构中，每个网址代表一种资源（resource），并用名词表示，同时所用的名词往往与数据库表相对应。例如：https://api.example.com/v1/courses
发送 HTTP 的请求动词如下：
- GET：从服务器取出资源（一项或多项）。
- POST：在服务器新建一个资源。
- PUT：在服务器更新资源（客户端提供改变后的完整资源）。
- PATCH：在服务器更新资源（客户端提供改变的属性）。
- DELETE：从服务器删除资源。
- HEAD：获取资源的元数据。
- OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。
// 例子来自 http://ruanyifeng.com/blog/2014/05/restful_api.html
GET /zoos：列出所有动物园
POST /zoos：新建一个动物园
GET /zoos/ID：获取某个指定动物园的信息
PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
DELETE /zoos/ID：删除某个动物园
GET /zoos/ID/animals：列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物
// 同时可以添加额外过滤信息
?limit=10：指定返回记录的数量
?page=2&per_page=100：指定第几页，以及每页的记录数。
?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
?_id=1：指定筛选条件
?filter=action：指定过滤条件
Hypermedia api
即返回结果中提供链接，连向其他API方法。这里给出我以前使用过的一款遵从 RESTful 框架: django-rest-framework，有 Python、Django 基础的可以尝试。访问其 api 首页是返回所有可见 api 列表，同时也能自定义 api 文档。
更多 RESTful 相关内容见 https://restfulapi.net/。
5、GraphQL api
6、get 和 post 的区别
- GET - 从指定的资源请求数据
- POST - 向指定的资源提交要被处理的数据
- GET：不同的浏览器和服务器不同，一般限制在 2~8K 之间，更加常见的是 1k 以内
- GET 和 POST 的底层也是 TCP/IP，GET/POST 都是 TCP 链接
- GET 产生一个 TCP 数据包，POST 产生两个 TCP 数据包
- 对于 GET 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）
- 而对于 POST，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）
关于GET/POST长度问题
HTTP 协议 未规定 GET 和 POST 的长度限制，GET 的最大长度显示是因为 浏览器和 web 服务器限制了 URI 的长度，不同的浏览器和 WEB 服务器，限制的最大长度不一样，要支持 IE，则最大长度为 2083byte，若只支持 Chrome，则最大长度 8182byte。