# 1. 参考模型

# 1. OSI 参考模型七层

Open System Interconnection

物理层 利用物理传输介质为数据链路层提供物理连接。传递的数据是比特流，0101010100。
数据链路层 定义通过通信媒介互连的设备之间传输的规范；首先，把比特流封装成数据帧的格式，对 0、1 进行分组。电脑连接起来之后，数据都经过网卡来传输，而网卡上定义了全世界唯一的 MAC 地址。然后再通过广播的形式向局域网内所有电脑发送数据，再根据数据中 MAC 地址和自身对比判断是否是发给自己的。
网络层 寻址和路由； IP ; 广播的形式太低效，为了区分哪些 MAC 地址属于同一个子网，网络层定义了 IP 和子网掩码，通过对 IP 和子网掩码进行与运算就知道是否是同一个子网，再通过路由器和交换机进行传输。
传输层 为上层协议提供端到端的可靠传输；TCP、UDP 有了网络层的 MAC+IP 地址之后，为了确定数据包是从哪个进程发送过来的，就需要端口号，通过端口来建立通信
会话层 建立、断开和维护通信链接
表示层 数据格式转换、数据压缩和数据加密 HTML、MIME
应用层 （各种应用程序协议 HTTP、FTP、SMTP、POP3）为应用程序提供网络服务；最高层，面对用户，提供计算机网络与最终呈现给用户的界面

详细的见科来网络通讯协议图 http://www.colasoft.com.cn/download/protocols_map.php

# 2. TCP/IP 参考模型四层

ISO 制定的 OSI 参考模型的过于庞大、复杂招致了许多批评。与此对照，由技术人员自己开发的 TCP/IP 协议栈获得了更为广泛的应用。

有四层五层两种说法

（知乎上的图，链接见文末）

数据链路层，也有称作网络访问层、网络接口层。他包含了 OSI 模型的物理层和数据链路层，把电脑连接起来。
网络层，也叫做 IP 层，处理 IP 数据包的传输、路由，建立主机间的通信。
传输层，就是为两台主机设备提供端到端的通信。TCP UDP
应用层，包含 OSI 的会话层、表示层和应用层，提供了一些常用的协议规范，比如 FTP、SMPT、HTTP、DNS 等。

（《图解 TCP/IP》中的图）

总结一下就是
物理层通过物理手段把电脑连接起来
数据链路层则对比特流的数据进行分组
网络层来建立主机到主机的通信
传输层建立端口到端口的通信
应用层最终负责建立连接，数据格式转换，最终呈现给用户

# 2. 在浏览器中输入网址之后执行会发生什么？

（1）从浏览器输入网址后，首先要经过域名解析，因为浏览器并不能直接通过域名找到服务器，而是通过 IP 地址找到对应的服务器，DNS 将域名解析为 IP 地址；
（2）浏览器通过 IP 地址找到服务器，建立 TCP 连接，通过三次握手以同步客户端和服务端的序列号和确认号，并交换 TCP 窗口大小的信息；
（3）TCP 三次握手结束后，开始发送 HTTP 请求；
（4）服务器处理请求，并返回 HTTP 响应报文；
（5）浏览器拿到响应文本 HTML 后，解析渲染页面；
（6）当数据传送完毕后，断开 TCP 连接。

# 3.URL 和 URI 的区别？

URI(Uniform Resource Identifier) 统一资源标识符
URL(Uniform Resource Locator) 统一资源定位符

URI 用字符串标识某一互联网资源，而 URL 表示资源的位置，URL 是 URI 的子集。

URI 的目的就是唯一标识互联网中的一份资源，具体可以用资源名称、资源地址等，但是资源地址是目前使用最广泛的，因此 URL 就容易和 URI 混淆。URI 相当于抽象类，URL 就是这个抽象类的具体实现类。

# 4. 关于 HTTP 协议

用于客户端与服务端通信的协议

# 4.1 为什么说 HTTP 协议是无状态协议？

HTTP 协议是一种无状态协议，协议自身不对请求和响应之间的通信状态进行保存，即对发送过来的请求和响应都不做持久化处理，把 HTTP 协议设计的如此简单是为了更快地处理大量事务。

# 4.2 怎么解决 HTTP 协议无状态协议？Cookie

为了解决 HTTP 协议不能保存通信状态的问题，引入了 Cookie 状态管理。
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
Cookie 会根据从服务端发送的响应报文的一个叫 Set-Cookie 的首部字段，通知客户端保存 Cookie。
当下次客户端再往该服务端发送请求时，客户端会自动在请求报文中加入 Cookie 值发送出去，服务端发现客户端发来的 Cookie 后，会检查是哪一个客户端发来的连接请求，对比服务器上的记录，最后得到之前的状态信息。

# 4.3 HTTP 协议包括哪些请求方法？

GET ：对服务器资源的简单请求
POST ：用于发送包含用户提交数据的请求
PUT ：传输文件
DELETE ：发出一个删除指定文档的请求
HEAD ：类似于 GET 请求，不过返回的响应中没有具体内容，用于获取报文首部
OPTIONS ：返回所有可用的方法，检查服务器支持哪些方法
TRACE ：发送一个请求副本，以跟踪其处理进程
CONNECT ：用于 ssl 隧道的基于代理的请求

# 4.4 简述 HTTP 中 GET 和 POST 的区别

从原理性看：
根据 HTTP 规范，GET 用于信息获取，而且应该是安全和幂等的
根据 HTTP 规范，POST 请求表示可能修改服务器上资源的请求

从表面上看：
GET 请求的数据会附在 URL 后面，POST 的数据放在 HTTP 包体
POST 安全性比 GET 安全性高

1、GET 参数通过 URL 传递，POST 放在 Request body 中。

2、GET 请求会被浏览器主动 cache，而 POST 不会，除非手动设置。

3、GET 请求参数会被完整保留在浏览器历史记录里，而 POST 中的参数不会被保留。

4、Get 请求中有非 ASCII 字符，会在请求之前进行转码，POST 不用，因为 POST 在 Request body 中，通过 MIME，也就可以传输非 ASCII 字符。

5、一般我们在浏览器输入一个网址访问网站都是 GET 请求

6、HTTP 的底层是 TCP/IP。HTTP 只是个行为准则，而 TCP 才是 GET 和 POST 怎么实现的基本。GET/POST 都是 TCP 链接。GET 和 POST 能做的事情是一样一样的。但是请求的数据量太大对浏览器和服务器都是很大负担。所以业界有了不成文规定，（大多数）浏览器通常都会限制 url 长度在 2K 个字节，而（大多数）服务器最多处理 64K 大小的 url。

7、GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。对于 GET 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）；而对于 POST，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

8、在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的 TCP 在验证数据包完整性上，有非常大的优点。但并不是所有浏览器都会在 POST 中发送两次包，Firefox 就只发送一次。

传递数据的最大长度

GET 是通过 URL 提交数据，因此 GET 可提交的数据量就跟 URL 所能达到的最大长度有直接关系。

POST 理论上讲是没有大小限制的，HTTP 协议规范也没有进行大小限制，但实际上 POST 所能传递的数据量大小取决于服务器的设置和内存大小。

# 4.5 PUT 和 POST 区别

PUT 是幂等的，POST 不是。

幂等是数学的一个用语，对于单个输入或者无输入的运算方法，如果每次都是同样的结果，则称其是幂等的。也就是说，如果一个网络重复执行多次，产生的效果是一样的，那就是幂等（idempotent）。

PUT 请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉。（所以 PUT 用来改资源）
POST 请求：后一个请求不会把第一个请求覆盖掉。（所以 POST 用来增资源）

# 4.6 常见的状态码有哪些？

状态码由 3 位数字和原因短语组成。

【HTTP】HTTP 状态码 - 返回结果 - 2XX-3XX-4XX-5XX

2×× 成功
200 OK 请求被正常处理
204 No Content 请求已成功处理，但无资源返回。
206 Partial Content 客户端只是请求资源的一部分，服务器只对请求的部分资源执行 GET 方法，相应报文中通过 Content-Range 指定范围的资源。

3×× 重定向
301 Moved Parmanently 永久性重定向请求的资源已被分配了新的 URL。
302 Found 临时重定向请求的资源被临时定位到新的 URL。
303 See Other 与 302 状态码有相似功能，只是它希望客户端在请求一个 URI 的时候，能通过 GET 方法重定向到另一个 URI 上
304 Not Modified 发送附带条件的请求时，条件不满足时返回，与重定向无关

4×× 客户端错误
400 Bad Request 请求报文语法有误，服务器无法识别
401 Unauthorized 用户认证失败
403 Forbidden 服务器拒绝
404 Not Found 服务器上没有找到请求的资源。

5×× 服务器错误
500 Internal Server Error 服务器内部错误
503 Service Unavailable 服务器正忙

# 4.7 HTTP 如何禁用缓存？如何确认缓存？

HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。

禁止进行缓存
no-store 指令规定不能对请求或响应的任何一部分进行缓存。

Cache-Control: no-store

强制确认缓存
no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性，只有当缓存资源有效时才能使用该缓存对客户端的请求进行响应。

Cache-Control: no-cache

# 4.8 HTTP 缓存

强制缓存
当缓存数据库中已有所请求的数据时。客户端直接从缓存数据库中获取数据。当缓存数据库中没有所请求的数据时，客户端的才会从服务端获取数据。

协商缓存
又称对比缓存，客户端会先从缓存数据库中获取到一个缓存数据的标识，得到标识后请求服务端验证是否失效（新鲜），如果没有失效服务端会返回 304，此时客户端直接从缓存中获取所请求的数据，如果标识失效，服务端会返回更新后的数据。

哪些资源可以被缓存 —— 静态资源（js、css、img）

# 强制缓存

Cache-Control （Response Headers）

max-age 设置缓存有效时间
no-cache 不用本地强制缓存，让服务端处理缓存
no-store 不强制缓存，不让服务端处理缓存，直接返回资源
private 只能允许最终用户做缓存
public 允许中间路由、代理做缓存

Expires （Response Headers）
控制缓存过期，已被 Cache-Control 代替

# 协商缓存（对比缓存）

服务端缓存策略
服务端判读客户端资源，是否和服务端资源一样
一致返回 304 ，否则返回 200 和最新的资源

Last-Modified [资源标识] 资源最后修改时间

Etag [资源标识] 资源唯一标识（一个字符串，类似人类的指纹）

# Last-Modified 与 Etag 的区别

优先使用 Etag
Last-Modified 只能精确到秒级
如果资源被重复生成，而内容不变，则 Etag 更精确

# 刷新页面对缓存的影响

正常操作：地址栏输入 URL，跳转链接，前进后退等【强制缓存有效，协商缓存有效】
手动刷新：F5，点击刷新按钮，点击菜单刷新【强制缓存失效，协商缓存有效】
强制刷新：CRTL+F5【强制缓存失效，协商缓存失效】

# 总结

# 4.9 常见 HTTP Headers

# 常见 Request Headers

Accept 浏览器可接收的数据格式
Accept-Encoding 浏览器可接收的压缩算法，如 gzip
Accept-Languange 浏览器可接收的语言，如 zh-CN
Connection: keep-alive 一次 TCP 连接重复使用
cookie
Host 请求域名
User-Agent 简称 UA 浏览器信息
Content-type 发送数据的格式，如 application/json

# 常见 Response Headers

Content-type 发送数据的格式，如 application/json
Content-length 返回数据的大小，多少字节
Content-Encoding 返回数据的压缩算法，如 gzip
Set-Cookie 设置 Cookie
Cache-Control 缓存控制
Expires 控制缓存过期
Last-Modified 资源最后修改时间
Etag 资源唯一标识

HTTP----HTTP 缓存机制

面试精选之 http 缓存

# 5. 关于 HTTPS

# 5.1 HTTP 的缺点有哪些？

使用明文进行通信，内容可能会被窃听；
不验证通信方的身份，通信方的身份有可能遭遇伪装；
无法证明报文的完整性，报文有可能遭篡改。

# 5.2 HTTPS 的工作原理

用户通过浏览器请求 HTTPS 网站，服务器收到请求，选择浏览器支持的加密和 hash 算法，同时返回数字证书给浏览器，包含颁发机构、网址、公钥、证书有效期等信息。
浏览器对证书的内容进行校验，如果有问题，则会有一个提示警告。
否则，就生成一个随机数 X，同时使用证书中的公钥进行加密，并且发送给服务器。
服务器收到之后，使用私钥解密，得到随机数 X，然后使用 X 对网页内容进行加密，返回给浏览器浏览器则使用 X 和之前约定的加密算法进行解密，得到最终的网页内容

# 5.3 HTTPS 采用的加密方式有哪些？是对称还是非对称？

HTTPS 采用混合的加密机制，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。

确保传输安全过程（其实就是 rsa 原理）：
Client 给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
Server 确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
Client 确认数字证书有效，然后生成呀一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给 Server。
Server 使用自己的私钥，获取 Client 发来的随机数（Premaster secret）。
Client 和 Server 根据约定的加密方法，使用前面的三个随机数，生成” 对话密钥”（session key），用来加密接下来的整个对话过程。

# 5.4 HTTP 和 HTTPS 的区别

HTTP 是超文本传输协议，设计目的是保证客户机与服务器之间的通信

HTTPS=HTTP + 加密 + 认证 + 完整性保护

HTTPS 通过 SSL 证书验证通信方的身份，并为浏览器和服务器之间的通信进行加密。通常，HTTP 直接和 TCP 通信，当使用 SSL 时，则 HTTP 先和 SSL 通信，再由 SSL 和 TCP 通信。

# 5.5 HTTPS 的缺点

（1）除了和 TCP 连接，发送 HTTP 请求外，还必须和 SSL 通信，因此通信慢；
（2）SSL 必须进行加密处理，在服务器和客户端都需要进行加密和解密的运算处理，因此更多地消耗硬件资源，导致负载增强；
（3）申请 SSL 证书需要费用。

# 5.6 SSL 中的认证中的证书是什么？

通过使用证书来对通信方进行认证。
数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。
服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。
进行 HTTPS 通信时，服务器会把证书发送给客户端。
客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。

# 5.7 为什么有的时候刷新页面不需要重新建立 SSL 连接？

TCP 连接有的时候会被浏览器和服务端维持一段时间，TCP 不需要重新建立，SSL 自然也会用之前的。

# 6. DNS 的解析过程？域名解析

DNS：将域名和 IP 地址的映射关系保存在一个分布式的数据库中。
（1）当浏览器拿到输入的网址后，首先会去浏览器的 DNS 缓存中去查询是否有对应的记录，如果查询到就直接返回 IP 地址，完成解析；
（2）如果浏览器中没有缓存，就会查看操作系统的缓存；
（3）如果操作系统中没有缓存，去查看本地 host 文件（windows 下的 host 文件一般位于 “C:\Windows\System32\drivers\etc”）；
（4）如果本地 host 文件也没有响应的记录，那就需要求助本地的 dns 服务器（本地 dns 服务器的 ip 地址是 114.114.114.114）；
（5）找到本地的 DNS 服务器后，它会先查询一遍自己的缓存，若没有记录，再去根域名 (.com) 服务器查询；
（6）当根域名接收到本地 DNS 的解析后，发现后缀是.com，于是就把负责.com 顶级域名的服务器 IP 地址返回给本地 DNS;
（7）本地 DNS 拿着返回的 ip 地址再去找对应的顶级域名服务器，该服务器将负责该域名的权威服务器 ip 返回回去；
（8）本地 DNS 又拿着 ip 去找对应的权威服务器，权威服务器最终将对应的主机 ip 返回给本地 DNS，至此完成了域名的解析。

# 7. ARP 协议的工作过程解析地址

解析地址，根据通信方的 IP 地址反查出对应的 MAC 地址

# 8. 关于 TCP 协议

# 8.1 TCP 的三次握手

tree-way handshaking
SYN synchronize 同步
ACK acknowledgement 确认

刚开始客户端处于 closed 的状态，服务端处于 listen 状态。
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN©。此时客户端处于 SYN_Send 状态。
第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN (s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised 状态。
服务器收到 ACK 报文之后，也处于 establised 状态，此时，双方以建立起了链接。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。因此，需要三次握手才能确认双方的接收与发送能力是否正常

# 8.2 TCP 的四次挥手

刚开始双方都处于 establised 状态，假如是客户端先发起关闭请求：
第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 CLOSED_WAIT1 状态。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT2 状态。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。
需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

client 端向 server 发送 FIN 包，进入 FIN_WAIT_1 状态，这代表 client 端已经没有数据要发送了 server 端收到之后，返回一个 ACK，进入 CLOSE_WAIT 等待关闭的状态，因为 server 端可能还有没有发送完成的数据等到 server 端数据都发送完毕之后，server 端就向 client 发送 FIN，进入 LAST_ACK 状态 client 收到 ACK 之后，进入 TIME_WAIT 的状态，同时回复 ACK，server 收到之后直接进入 CLOSED 状态，连接关闭。但是 client 要等待 2MSL (报文最大生存时间) 的时间，才会进入 CLOSED 状态。

# 为什么握手要 3 次？挥手要 4 次？

为什么握手要 3 次？
因为 TCP 是双工传输模式，不区分客户端和服务端，连接的建立是双向的过程。如果只有两次，无法做到双向连接的建立，从建立连接 server 回复的 SYN 和 ACK 合并成一次可以看出来，他也不需要 4 次。
挥手为什么要四次？
因为挥手的 ACK 和 FIN 不能同时发送，因为数据发送的截止时间不同。

# 8.3 为什么要等待 2MSL 的时间才关闭？

为了保证连接的可靠关闭。如果 server 没有收到最后一个 ACK，那么就会重发 FIN。为了避免端口重用带来的数据混淆。如果 client 直接进入 CLOSED 状态，又用相同端口号向 server 建立一个连接，上一次连接的部分数据在网络中延迟到达 server，数据就可能发生混淆了。

# 8.4 简述 TCP 与 UDP 的区别

TCP 和 UDP 是 OSI 模型中的运输层中的协议。
TCP 提供可靠的通信传输，而 UDP 则常被用于让广播和细节控制交给应用的通信传输。

TCP
TCP 是一种面向连接的传输层协议，在传输数据之间必须先建立连接，数据传输结束后要释放链接。TCP 提供可靠传输，它的可靠性体现在传输数据之前会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传输完断开连接。
UDP
UDP 是无连接的，在传输数据之前不需要先建立连接，远程主机在收到 UDP 报文之后，不需要给出任何确认，虽然不可靠，但是高效，可用于即时通信。
区别
1. TCP 是面向有连接型，UDP 是面向无连接型即发送数据前不需要建立链接；
2. TCP 支持传输可靠性的多种措施，包括保证包的传输顺序、重发机制、流量控制和拥塞控制；UDP 仅提供最基本的数据传输能力。无法保证可靠
3. TCP 是一对一传输，UDP 支持一对一、一对多、多对一和多对多的交互通信；
4. TCP 是面向字节流的，即把应用层传来的报文看成字节流，将字节流拆分成大小不等的数据块，并添加 TCP 首部；UDP 是面向报文的，对应用层传下来的报文不拆分也不合并，仅添加 UDP 首部；
5. TCP 数据传输慢，UDP 数据传输快

# 8.5 TCP 怎么保证传输过程的可靠性？

校验和：发送方在发送数据之前计算校验和，接收方收到数据后同样计算，如果不一致，那么传输有误。
确认应答，序列号：TCP 进行传输时数据都进行了编号，每次接收方返回 ACK 都有确认序列号。
超时重传：如果发送方发送数据一段时间后没有收到 ACK，那么就重发数据。连接管理：三次握手和四次挥手的过程。
流量控制：TCP 协议报头包含 16 位的窗口大小，接收方会在返回 ACK 时同时把自己的即时窗口填入，发送方就根据报文中窗口的大小控制发送速度。
拥塞控制：刚开始发送数据的时候，拥塞窗口是 1，以后每次收到 ACK，则拥塞窗口 + 1，然后将拥塞窗口和收到的窗口取较小值作为实际发送的窗口，如果发生超时重传，拥塞窗口重置为 1。这样做的目的就是为了保证传输过程的高效性和可靠性。

# 8.6 TCP 对应的典型的应用层协议

FTP：文件传输协议；
SSH：远程登录协议；
HTTP：web 服务器传输超文本到本地浏览器的超文本传输协议。
UDP 对应的典型的应用层协议：

DNS：域名解析协议；
TFTP：简单文件传输协议；
SNMP：简单网络管理协议。

# 9. 关于地址与端口

# 9.1 IP 地址分为哪几类？简单说一下各个分类

IPv6 – 采用 128bit，首部固定部分为 40 字节。

# 9.2 IP 地址、MAC 地址、端口号的区别

以太网用 MAC 地址
MAC 地址用于识别数据链路中互连的节点。
MAC 地址指网卡所属的固定地址（具有唯一性）

IP 协议用 IP 地址
IP 地址指明了节点被分配到的地址

TCP/UDP 用端口号

# 9.3 端口及对应的服务

# 9.4 有哪些私有（保留）地址？

A 类：10.0.0.0 - 10.255.255.255
B 类：172.16.0.0 - 172.31.255.255
C 类：192.168.0.0 - 192.168.255.255

# 10. 负载均衡有哪些实现方式？

DNS：这是最简单的负载均衡的方式，一般用于实现地理级别的负载均衡，不同地域的用户通过 DNS 的解析可以返回不同的 IP 地址，这种方式的负载均衡简单，但是扩展性太差，控制权在域名服务商。
Http 重定向：通过修改 Http 响应头的 Location 达到负载均衡的目的，Http 的 302 重定向。这种方式对性能有影响，而且增加请求耗时。
反向代理：作用于应用层的模式，也被称作为七层负载均衡，比如常见的 Nginx，性能一般可以达到万级。这种方式部署简单，成本低，而且容易扩展。
IP：作用于网络层的和传输层的模式，也被称作四层负载均衡，通过对数据包的 IP 地址和端口进行修改来达到负载均衡的效果。常见的有 LVS（Linux Virtual Server），通常性能可以支持 10 万级并发。

按照类型来划分的话，还可以分成 DNS 负载均衡、硬件负载均衡、软件负载均衡。其中硬件负载均衡价格昂贵，性能最好，能达到百万级，软件负载均衡包括 Nginx、LVS 这种

# 11. WebSocket 协议

WebSocket 协议：5 分钟从入门到精通

HTML5 开始提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于 TCP 传输协议，并复用 HTTP 的握手通道。

优点
支持双向通信，实时性更强。
更好的二进制支持

# 12. 什么是 JWT

JSON Web Token（简称 JWT）是目前最流行的跨域认证解决方案。
是一种认证授权机制。

JSON Web Token 入门教程 http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html

# 13. Web 存储与身份认证

安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
存储大小不同：单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

# 13.3 Token 和 Session 的区别

Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。Token 使服务端无状态化，不会存储会话信息。
Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。
所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SessionID 的不可预测性，暂且认为是安全的。而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是认证和授权，认证是针对用户，授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App 上，也不可以转到其它用户上。Session 只提供一种简单的认证，即只要有此 SessionID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方 App。所以简单来说：如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

# 14. 什么是 Restful API

传统 methods

GET 获取服务器数据
POST 向服务器提交数据

现代 methods

GET 获取数据
POST 新建数据
PATCH / PUT 更新数据
DELETE 删除数据

传统 API：把每个 URL 当作一个功能
Restful API：把每个 URL 当作一个唯一的资源

用 URL 定位资源，用 HTTP 动词（GET，POST，DELETE，PUT）描述操作
尽量不用 URL 参数，用 method 表示操作类型

① url 参数

传统 API ： /api/list?pageIndex=2
Restful API ： /api/list/2

② method 表示操作类型

传统 API
POST 请求 /api/create-blog
POST 请求 /api/update-blog?id=100
GET 请求 /api/get-blog?id=100
Restful API
POST 请求 /api/blog
PATCH 请求 /api/blog/100
GET 请求 /api/blog/100

# 15. 协议英文全称

# HTTP

HyperText Transfer Protocol 超文本传输协议

# HTTPS

HTTP Secure 超文本传输安全协议
HTTP over SSL

# URL

Uniform Resource Locator 统一资源定位符

# URI

Uniform Resource Identifier 统一资源标识符

# FTP

File Transfer Protocol 文件传输协议

# DNS

Domain Name System 域名系统

# TCP

Transmission Control Protocol 传输控制协议

# UDP

User Data Protocol 用户数据报协议

# NIC

Network Interface Card 网络适配器，网卡

# IP

Internet Protocol 网际协议

# MAC

Media Access Control Address 媒体存取控制位址

# ARP

Address Resolution Protocol 地址解析协议

# SSL

Secure Socket Layer 安全套接层

# TLS

Transport Layer Security，安全传输层协议