14道关于计算机网络的面试题，助你查漏补缺

时间 2020-04-14

原文原文链接

最近在整理计算机网络的时候发现遇到了不少面试中常见的面试题，本部分主要原做者在 Github 等各大论坛收录的计算机网络相关知识和一些相关面试题时所作的笔记，分享这份总结给你们，对你们对计算机网络的能够来一次全方位的检漏和排查，感谢原做者 CavsZhouyou 的付出，原文连接放在文章最下方，若是出现错误，但愿你们共同指出！css

应用层

应用层协议定义了应用进程间的交互和通讯规则，不一样主机的应用进程间如何相互传递报文，好比传递的报文的类型、格式、
有哪些字段等等。html

HTTP 协议概况

HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 做为传
输层协议，保证了数据传输的可靠性。前端

HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。webpack

HTTP 有两种链接模式，一种是持续链接，一种非持续链接。非持续链接指的是服务器必须为每个请求的对象创建和维护
一个全新的链接。持续链接下，TCP 链接默认不关闭，能够被多个请求复用。采用持续链接的好处是能够避免每次创建 TCP
链接三次握手时所花费的时间。在 HTTP1.0 之前使用的非持续的链接，可是能够在请求时，加上 Connection: keep-a
live 来要求服务器不要关闭 TCP 链接。HTTP1.1 之后默认采用的是持续的链接。目前对于同一个域，大多数浏览器支持
同时创建 6 个持久链接。git

HTTP 请求报文

HTTP 报文有两种，一种是请求报文，一种是响应报文。github

HTTP 请求报文的格式以下：web

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

HTTP 请求报文的第一行叫作请求行，后面的行叫作首部行，首部行后还能够跟一个实体主体。请求首部以后有一个空行，这
个空行不能省略，它用来划分首部与实体。面试

请求行包含三个字段：方法字段、URL 字段和 HTTP 版本字段。算法

方法字段能够取几种不一样的值，通常有 GET、POST、HEAD、PUT 和 DELETE。通常 GET 方法只被用于向服务器获取数据。
POST 方法用于将实体提交到指定的资源，一般会形成服务器资源的修改。HEAD 方法与 GET 方法相似，可是在返回的响应
中，不包含请求对象。PUT 方法用于上传文件到服务器，DELETE 方法用于删除服务器上的对象。虽然请求的方法不少，但
更多表达的是一种语义上的区别，并非说 POST 能作的事情，GET 就不能作了，主要看咱们如何选择。更多的方法能够参
看文档。数据库

HTTP 响应报文

HTTP 报文有两种，一种是请求报文，一种是响应报文。

HTTP 响应报文的格式以下：

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>

HTTP 响应报文的第一行叫作状态行，后面的行是首部行，最后是实体主体。

状态行包含了三个字段：协议版本字段、状态码和相应的状态信息。

实体部分是报文的主要部分，它包含了所请求的对象。

常见的状态有

200-请求成功、202-服务器端已经收到请求消息，可是还没有进行处理
301-永久移动、302-临时移动、304-所请求的资源未修改、
400-客户端请求的语法错误、404-请求的资源不存在
500-服务器内部错误。

通常 1XX 表明服务器接收到请求、2XX 表明成功、3XX 表明重定向、4XX 表明客户端错误、5XX 表明服务器端错误。

更多关于状态码的能够查看：

《HTTP 状态码》

首部行

首部能够分为四种首部，请求首部、响应首部、通用首部和实体首部。通用首部和实体首部在请求报文和响应报文中均可以设
置，区别在于请求首部和响应首部。

常见的请求首部有 Accept 可接收媒体资源的类型、Accept-Charset 可接收的字符集、Host 请求的主机名。

常见的响应首部有 ETag 资源的匹配信息，Location 客户端重定向的 URI。

常见的通用首部有 Cache-Control 控制缓存策略、Connection 管理持久链接。

常见的实体首部有 Content-Length 实体主体的大小、Expires 实体主体的过时时间、Last-Modified 资源的最后修
改时间。

更多关于首部的资料能够查看：

《HTTP 首部字段详细介绍》

《图解 HTTP》

HTTP/1.1 协议缺点

HTTP/1.1 默认使用了持久链接，多个请求能够复用同一个 TCP 链接，可是在同一个 TCP 链接里面，数据请求的通讯次序
是固定的。服务器只有处理完一个请求的响应后，才会进行下一个请求的处理，若是前面请求的响应特别慢的话，就会形成许
多请求排队等待的状况，这种状况被称为“队头堵塞”。队头阻塞会致使持久链接在达到最大数量时，剩余的资源须要等待其余
资源请求完成后才能发起请求。

为了不这个问题，一个是减小请求数，一个是同时打开多个持久链接。这就是咱们对网站优化时，使用雪碧图、合并脚本的
缘由。

HTTP/2 协议

2009 年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。这个协议在 Chrome 浏览器上证实
可行之后，就被看成 HTTP/2 的基础，主要特性都在 HTTP/2 之中获得继承。2015 年，HTTP/2 发布。

HTTP/2 主要有如下新的特性：

二进制协议

HTTP/2 是一个二进制协议。在 HTTP/1.1 版中，报文的头信息必须是文本（ASCII 编码），数据体能够是文本，也能够是
二进制。HTTP/2 则是一个完全的二进制协议，头信息和数据体都是二进制，而且统称为"帧"，能够分为头信息帧和数据帧。
帧的概念是它实现多路复用的基础。

多路复用

HTTP/2 实现了多路复用，HTTP/2 仍然复用 TCP 链接，可是在一个链接里，客户端和服务器均可以同时发送多个请求或回
应，并且不用按照顺序一一发送，这样就避免了"队头堵塞"的问题。

数据流

HTTP/2 使用了数据流的概念，由于 HTTP/2 的数据包是不按顺序发送的，同一个链接里面连续的数据包，可能属于不一样的
请求。所以，必需要对数据包作标记，指出它属于哪一个请求。HTTP/2 将每一个请求或回应的全部数据包，称为一个数据流。每
个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流 ID ，用来区分它属于哪一个数据流。

头信息压缩

HTTP/2 实现了头信息压缩，因为 HTTP 1.1 协议不带有状态，每次请求都必须附上全部信息。因此，请求的不少字段都是
重复的，好比 Cookie 和 User Agent ，如出一辙的内容，每次请求都必须附带，这会浪费不少带宽，也影响速度。

HTTP/2 对这一点作了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 compress 压缩后再发送；另外一方面，
客户端和服务器同时维护一张头信息表，全部字段都会存入这个表，生成一个索引号，之后就不发送一样字段了，只发送索引
号，这样就能提升速度了。

服务器推送

HTTP/2 容许服务器未经请求，主动向客户端发送资源，这叫作服务器推送。使用服务器推送，提早给客户端推送必要的资源
，这样就能够相对减小一些延迟时间。这里须要注意的是 http2 下服务器主动推送的是静态资源，和 WebSocket 以及使用
SSE 等方式向客户端发送即时数据的推送是不一样的。

详细的资料能够参考：
《HTTP 协议入门》
《HTTP/2 服务器推送（Server Push）教程》

HTTP/2 协议缺点

由于 HTTP/2 使用了多路复用，通常来讲同一域名下只须要使用一个 TCP 链接。因为多个数据流使用同一个 TCP 链接，遵
守同一个流量状态控制和拥塞控制。只要一个数据流遭遇到拥塞，剩下的数据流就无法发出去，这样就致使了后面的全部数据都
会被阻塞。HTTP/2 出现的这个问题是因为其使用 TCP 协议的问题，与它自己的实现其实并无多大关系。

HTTP/3 协议

因为 TCP 自己存在的一些限制，Google 就开发了一个基于 UDP 协议的 QUIC 协议，而且使用在了 HTTP/3 上。 QUIC
协议在 UDP 协议上实现了多路复用、有序交付、重传等等功能

详细资料能够参考：
《如何看待 HTTP/3 ？》

HTTPS 协议

HTTP 存在的问题

HTTP 报文使用明文方式发送，可能被第三方窃听。
HTTP 报文可能被第三方截取后修改通讯内容，接收方没有办法发现报文内容的修改。
HTTP 还存在认证的问题，第三方能够冒充他人参与通讯。

HTTPS 简介

HTTPS 指的是超文本传输安全协议，HTTPS 是基于 HTTP 协议的，不过它会使用 TLS/SSL 来对数据加密。使用 TLS/
SSL 协议，全部的信息都是加密的，第三方没有办法窃听。而且它提供了一种校验机制，信息一旦被篡改，通讯的双方会立
刻发现。它还配备了身份证书，防止身份被冒充的状况出现。

TLS 握手过程

第一步，客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。
第二步，服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。
第三步，客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，而后发给服
务器。而且还会提供一个前面全部内容的 hash 的值，用来供服务器检验。
第四步，服务器使用本身的私钥，来解密客户端发送过来的随机数。并提供前面全部内容的 hash 值来供客户端检验。
第五步，客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，之后的对话过程都使用这个秘钥
来加密信息。

实现原理

TLS 的握手过程主要用到了三个方法来保证传输的安全。

首先是对称加密的方法，对称加密的方法是，双方使用同一个秘钥对数据进行加密和解密。可是对称加密的存在一个问题，就
是如何保证秘钥传输的安全性，由于秘钥仍是会经过网络传输的，一旦秘钥被其余人获取到，那么整个加密过程就毫无做用了。
这就要用到非对称加密的方法。

非对称加密的方法是，咱们拥有两个秘钥，一个是公钥，一个是私钥。公钥是公开的，私钥是保密的。用私钥加密的数据，只
有对应的公钥才能解密，用公钥加密的数据，只有对应的私钥才能解密。咱们能够将公钥公布出去，任何想和咱们通讯的客户，
均可以使用咱们提供的公钥对数据进行加密，这样咱们就可使用私钥进行解密，这样就能保证数据的安全了。可是非对称加
密有一个缺点就是加密的过程很慢，所以若是每次通讯都使用非对称加密的方式的话，反而会形成等待时间过长的问题。

所以咱们可使用对称加密和非对称加密结合的方式，由于对称加密的方式的缺点是没法保证秘钥的安全传输，所以咱们能够
非对称加密的方式来对对称加密的秘钥进行传输，而后之后的通讯使用对称加密的方式来加密，这样就解决了两个方法各自存
在的问题。

可是如今的方法也不必定是安全的，由于咱们没有办法肯定咱们获得的公钥就必定是安全的公钥。可能存在一个中间人，截取
了对方发给咱们的公钥，而后将他本身的公钥发送给咱们，当咱们使用他的公钥加密后发送的信息，就能够被他用本身的私钥
解密。而后他假装成咱们以一样的方法向对方发送信息，这样咱们的信息就被窃取了，然而咱们本身还不知道。

为了解决这样的问题，咱们可使用数字证书的方式，首先咱们使用一种 Hash 算法来对咱们的公钥和其余信息进行加密生成
一个信息摘要，而后让有公信力的认证中心（简称 CA ）用它的私钥对消息摘要加密，造成签名。最后将原始的信息和签名合
在一块儿，称为数字证书。当接收方收到数字证书的时候，先根据原始信息使用一样的 Hash 算法生成一个摘要，而后使用公证
处的公钥来对数字证书中的摘要进行解密，最后将解密的摘要和咱们生成的摘要进行对比，就能发现咱们获得的信息是否被更改
了。这个方法最要的是认证中心的可靠性，通常浏览器里会内置一些顶层的认证中心的证书，至关于咱们自动信任了他们，只有
这样咱们才能保证数据的安全。

详细资料能够参考：
《一个故事讲完 https》
《SSL/TLS 协议运行机制的概述》
《图解 SSL/TLS 协议》
《RSA 算法原理（一）》
《RSA 算法原理（二）》
《分分钟让你理解 HTTPS》

DNS 协议

概况

DNS 协议提供的是一种主机名到 IP 地址的转换服务，就是咱们常说的域名系统。它是一个由分层的 DNS 服务器组成的分
布式数据库，是定义了主机如何查询这个分布式数据库的方式的应用层协议。DNS 协议运行在 UDP 协议之上，使用 53 号
端口。

域名的层级结构

域名的层级结构能够以下

主机名.次级域名.顶级域名.根域名

# 即

host.sld.tld.root

根据域名的层级结构，管理不一样层级域名的服务器，能够分为根域名服务器、顶级域名服务器和权威域名服务器。

查询过程

DNS 的查询过程通常为，咱们首先将 DNS 请求发送到本地 DNS 服务器，由本地 DNS 服务器来代为请求。

从"根域名服务器"查到"顶级域名服务器"的 NS 记录和 A 记录（ IP 地址）。
从"顶级域名服务器"查到"次级域名服务器"的 NS 记录和 A 记录（ IP 地址）。
从"次级域名服务器"查出"主机名"的 IP 地址。

好比咱们若是想要查询 www.baidu.com 的 IP 地址，咱们首先会将请求发送到本地的 DNS 服务器中，本地 DNS 服务
器会判断是否存在该域名的缓存，若是不存在，则向根域名服务器发送一个请求，根域名服务器返回负责 .com 的顶级域名
服务器的 IP 地址的列表。而后本地 DNS 服务器再向其中一个负责 .com 的顶级域名服务器发送一个请求，负责 .com
的顶级域名服务器返回负责 .baidu 的权威域名服务器的 IP 地址列表。而后本地 DNS 服务器再向其中一个权威域名服
务器发送一个请求，最后权威域名服务器返回一个对应的主机名的 IP 地址列表。

DNS 记录和报文

DNS 服务器中以资源记录的形式存储信息，每个 DNS 响应报文通常包含多条资源记录。一条资源记录的具体的格式为

（Name，Value，Type，TTL）

其中 TTL 是资源记录的生存时间，它定义了资源记录可以被其余的 DNS 服务器缓存多长时间。

经常使用的一共有四种 Type 的值，分别是 A、NS、CNAME 和 MX ，不一样 Type 的值，对应资源记录表明的意义不一样。

若是 Type = A，则 Name 是主机名，Value 是主机名对应的 IP 地址。所以一条记录为 A 的资源记录，提供了标
准的主机名到 IP 地址的映射。
若是 Type = NS，则 Name 是个域名，Value 是负责该域名的 DNS 服务器的主机名。这个记录主要用于 DNS 链式
查询时，返回下一级须要查询的 DNS 服务器的信息。
若是 Type = CNAME，则 Name 为别名，Value 为该主机的规范主机名。该条记录用于向查询的主机返回一个主机名
对应的规范主机名，从而告诉查询主机去查询这个主机名的 IP 地址。主机别名主要是为了经过给一些复杂的主机名提供
一个便于记忆的简单的别名。
若是 Type = MX，则 Name 为一个邮件服务器的别名，Value 为邮件服务器的规范主机名。它的做用和 CNAME 是一
样的，都是为了解决规范主机名不利于记忆的缺点。

递归查询和迭代查询

递归查询指的是查询请求发出后，域名服务器代为向下一级域名服务器发出请求，最后向用户返回查询的最终结果。使用递归
查询，用户只须要发出一次查询请求。

迭代查询指的是查询请求后，域名服务器返回单次查询的结果。下一级的查询由用户本身请求。使用迭代查询，用户须要发出
屡次的查询请求。

通常咱们向本地 DNS 服务器发送请求的方式就是递归查询，由于咱们只须要发出一次请求，而后本地 DNS 服务器返回给我
们最终的请求结果。而本地 DNS 服务器向其余域名服务器请求的过程是迭代查询的过程，由于每一次域名服务器只返回单次
查询的结果，下一级的查询由本地 DNS 服务器本身进行。

DNS 缓存

DNS 缓存的原理很是简单，在一个请求链中，当某个 DNS 服务器接收到一个 DNS 回答后，它可以将回答中的信息缓存在本
地存储器中。返回的资源记录中的 TTL 表明了该条记录的缓存的时间。

DNS 实现负载平衡

DNS 能够用于在冗余的服务器上实现负载平衡。由于如今通常的大型网站使用多台服务器提供服务，所以一个域名可能会对应
多个服务器地址。当用户发起网站域名的 DNS 请求的时候，DNS 服务器返回这个域名所对应的服务器 IP 地址的集合，但在
每一个回答中，会循环这些 IP 地址的顺序，用户通常会选择排在前面的地址发送请求。以此将用户的请求均衡的分配到各个不
同的服务器上，这样来实现负载均衡。

详细资料能够参考：
《DNS 原理入门》
《根域名的知识》

传输层

传输层协议主要是为不一样主机上的不一样进程间提供了逻辑通讯的功能。传输层只工做在端系统中。

多路复用与多路分解

将传输层报文段中的数据交付到正确的套接字的工做被称为多路分解。

在源主机上从不一样的套接字中收集数据，封装头信息生成报文段后，将报文段传递到网络层，这个过程被称为多路复用。

无链接的多路复用和多路分解指的是 UDP 套接字的分配过程，一个 UDP 套接字由一个二元组来标识，这个二元组包含了一
个目的地址和一个目的端口号。所以不一样源地址和端口号的 UDP 报文段到达主机后，若是它们拥有相同的目的地址和目的端
口号，那么不一样的报文段将会转交到同一个 UDP 套接字中。

面向链接的多路复用和多路分解指的是 TCP 套接字的分配过程，一个 TCP 套接字由一个四元组来标识，这个四元组包含了
源 IP 地址、源端口号、目的地址和目的端口号。所以，一个 TCP 报文段从网络中到达一台主机上时，该主机使用所有 4 个
值来将报文段定向到相应的套接字。

UDP 协议

UDP 是一种无链接的，不可靠的传输层协议。它只提供了传输层须要实现的最低限度的功能，除了复用/分解功能和少许的差
错检测外，它几乎没有对 IP 增长其余的东西。UDP 协议适用于对实时性要求高的应用场景。

特色：

使用 UDP 时，在发送报文段以前，通讯双方没有握手的过程，所以 UDP 被称为是无链接的传输层协议。由于没有握手
过程，相对于 TCP 来讲，没有创建链接的时延。由于没有链接，因此不须要在端系统中保存链接的状态。
UDP 提供尽力而为的交付服务，也就是说 UDP 协议不保证数据的可靠交付。
UDP 没有拥塞控制和流量控制的机制，因此 UDP 报文段的发送速率没有限制。
由于一个 UDP 套接字只使用目的地址和目的端口来标识，因此 UDP 能够支持一对1、一对多、多对一和多对多的交互
通讯。
UDP 首部小，只有 8 个字节。

UDP 报文段结构

UDP 报文段由首部和应用数据组成。报文段首部包含四个字段，分别是源端口号、目的端口号、长度和检验和，每一个字段的长
度为两个字节。长度字段指的是整个报文段的长度，包含了首部和应用数据的大小。校验和是 UDP 提供的一种差错校验机制。
虽然提供了差错校验的机制，可是 UDP 对于差错的恢复无能为力。

TCP 协议

TCP 协议是面向链接的，提供可靠数据传输服务的传输层协议。

特色：

TCP 协议是面向链接的，在通讯双方进行通讯前，须要经过三次握手创建链接。它须要在端系统中维护双方链接的状态信息。
TCP 协议经过序号、确认号、定时重传、检验和等机制，来提供可靠的数据传输服务。
TCP 协议提供的是点对点的服务，即它是在单个发送方和单个接收方之间的链接。
TCP 协议提供的是全双工的服务，也就是说链接的双方的可以向对方发送和接收数据。
TCP 提供了拥塞控制机制，在网络拥塞的时候会控制发送数据的速率，有助于减小数据包的丢失和减轻网络中的拥塞程度。
TCP 提供了流量控制机制，保证了通讯双方的发送和接收速率相同。若是接收方可接收的缓存很小时，发送方会下降发送
速率，避免由于缓存填满而形成的数据包的丢失。

TCP 报文段结构

TCP 报文段由首部和数据组成，它的首部通常为 20 个字节。

源端口和目的端口号用于报文段的多路复用和分解。

32 比特的序号和 32 比特的确认号，用与实现可靠数据运输服务。

16 比特的接收窗口字段用于实现流量控制，该字段表示接收方愿意接收的字节的数量。

4 比特的首部长度字段，该字段指示了以 32 比特的字为单位的 TCP 首部的长度。

6 比特的标志字段，ACK 字段用于指示确认序号的值是有效的，RST、SYN 和 FIN 比特用于链接创建和拆除。设置 PSH 字
段指示接收方应该当即将数据交给上层，URG 字段用来指示报文段里存在紧急的数据。

校验和提供了对数据的差错检测。

TCP 三次握手的过程

第一次握手，客户端向服务器发送一个 SYN 链接请求报文段，报文段的首部中 SYN 标志位置为 1，序号字段是一个任选的
随机数。它表明的是客户端数据的初始序号。

第二次握手，服务器端接收到客户端发送的 SYN 链接请求报文段后，服务器首先会为该链接分配 TCP 缓存和变量，而后向
客户端发送 SYN ACK 报文段，报文段的首部中 SYN 和 ACK 标志位都被置为 1，表明这是一个对 SYN 链接请求的确认，
同时序号字段是服务器端产生的一个任选的随机数，它表明的是服务器端数据的初始序号。确认号字段为客户端发送的序号加
一。

第三次握手，客户端接收到服务器的确定应答后，它也会为此次 TCP 链接分配缓存和变量，同时向服务器端发送一个对服务
器端的报文段的确认。第三次握手能够在报文段中携带数据。

在我看来，TCP 三次握手的创建链接的过程就是相互确认初始序号的过程，告诉对方，什么样序号的报文段可以被正确接收。
第三次握手的做用是客户端对服务器端的初始序号的确认。若是只使用两次握手，那么服务器就没有办法知道本身的序号是否
已被确认。同时这样也是为了防止失效的请求报文段被服务器接收，而出现错误的状况。

详细资料能够参考：
《TCP 为何是三次握手，而不是两次或四次？》
《TCP 的三次握手与四次挥手》

TCP 四次挥手的过程

由于 TCP 链接是全双工的，也就是说通讯的双方均可以向对方发送和接收消息，因此断开链接须要双方的确认。

第一次挥手，客户端认为没有数据要再发送给服务器端，它就向服务器发送一个 FIN 报文段，申请断开客户端到服务器端的
链接。发送后客户端进入 FIN_WAIT_1 状态。

第二次挥手，服务器端接收到客户端释放链接的请求后，向客户端发送一个确认报文段，表示已经接收到了客户端释放链接的
请求，之后再也不接收客户端发送过来的数据。可是由于链接是全双工的，因此此时，服务器端还能够向客户端发送数据。服务
器端进入 CLOSE_WAIT 状态。客户端收到确认后，进入 FIN_WAIT_2 状态。

第三次挥手，服务器端发送完全部数据后，向客户端发送 FIN 报文段，申请断开服务器端到客户端的链接。发送后进入 LAS
T_ACK 状态。

第四次挥手，客户端接收到 FIN 请求后，向服务器端发送一个确认应答，并进入 TIME_WAIT 阶段。该阶段会持续一段时间，
这个时间为报文段在网络中的最大生存时间，若是该时间内服务端没有重发请求的话，客户端进入 CLOSED 的状态。若是收到
服务器的重发请求就从新发送确认报文段。服务器端收到客户端的确认报文段后就进入 CLOSED 状态，这样全双工的链接就被
释放了。

TCP 使用四次挥手的缘由是由于 TCP 的链接是全双工的，因此须要双方分别释放到对方的链接，单独一方的链接释放，只代
表不能再向对方发送数据，链接处于的是半释放的状态。

最后一次挥手中，客户端会等待一段时间再关闭的缘由，是为了防止发送给服务器的确认报文段丢失或者出错，从而致使服务器
端不能正常关闭。

详细资料能够参考：

《前端面试之道》

状态转化图

ARQ 协议

ARQ 协议指的是自动重传请求，它经过超时和重传来保证数据的可靠交付，它是 TCP 协议实现可靠数据传输的一个很重要的
机制。

它分为中止等待 ARQ 协议和连续 ARQ 协议。

1、中止等待 ARQ 协议

中止等待 ARQ 协议的基本原理是，对于发送方来讲发送方每发送一个分组，就为这个分组设置一个定时器。当发送分组的确认
回答返回了，则清除定时器，发送下一个分组。若是在规定的时间内没有收到已发送分组的确定回答，则从新发送上一个分组。

对于接受方来讲，每次接受到一个分组，就返回对这个分组的确定应答，当收到冗余的分组时，就直接丢弃，并返回一个对冗余
分组的确认。当收到分组损坏的状况的时候，直接丢弃。

使用中止等待 ARQ 协议的缺点是每次发送分组必须等到分组确认后才能发送下一个分组，这样会形成信道的利用率太低。

2、连续 ARQ 协议

连续 ARQ 协议是为了解决中止等待 ARQ 协议对于信道的利用率太低的问题。它经过连续发送一组分组，而后再等待对分组的
确认回答，对于如何处理分组中可能出现的差错恢复状况，通常可使用滑动窗口协议和选择重传协议来实现。

滑动窗口协议

使用滑动窗口协议，在发送方维持了一个发送窗口，发送窗口之前的分组是已经发送并确认了的分组，发送窗口中包含了已经发
送但未确认的分组和容许发送但还未发送的分组，发送窗口之后的分组是缓存中还不容许发送的分组。当发送方向接收方发送分
组时，会依次发送窗口内的全部分组，而且设置一个定时器，这个定时器能够理解为是最先发送但未收到确认的分组。若是在定
时器的时间内收到某一个分组的确认回答，则滑动窗口，将窗口的首部移动到确认分组的后一个位置，此时若是还有已发送但没
有确认的分组，则从新设置定时器，若是没有了则关闭定时器。若是定时器超时，则从新发送全部已经发送但还未收到确认的分
组。

接收方使用的是累计确认的机制，对于全部按序到达的分组，接收方返回一个分组的确定回答。若是收到了一个乱序的分组，那
么接方会直接丢弃，并返回一个最近的按序到达的分组的确定回答。使用累计确认保证了确认号之前的分组都已经按序到达了，
因此发送窗口能够移动到已确认分组的后面。

滑动窗口协议的缺点是由于使用了累计确认的机制，若是出现了只是窗口中的第一个分组丢失，然后面的分组都按序到达的状况
的话，那么滑动窗口协议会从新发送全部的分组，这样就形成了大量没必要要分组的丢弃和重传。

选择重传协议

由于滑动窗口使用累计确认的方式，因此会形成不少没必要要分组的重传。使用选择重传协议能够解决这个问题。

选择重传协议在发送方维护了一个发送窗口。发送窗口的之前是已经发送并确认的分组，窗口内包含了已发送但未被确认的分组，
已确认的乱序分组，和容许发送但还未发送的分组，发送窗口之后的是缓存中还不容许发送的分组。选择重传协议与滑动窗口协
议最大的不一样是，发送方发送分组时，为一个分组都建立了一个定时器。当发送方接受到一个分组的确认应答后，取消该分组的
定时器，并判断接受该分组后，是否存在由窗口首部为首的连续的确认分组，若是有则向后移动窗口的位置，若是没有则将该分
组标识为已接收的乱序分组。当某一个分组定时器到时后，则从新传递这个分组。

在接收方，它会确认每个正确接收的分组，无论这个分组是按序的仍是乱序的，乱序的分组将被缓存下来，直到全部的乱序分
组都到达造成一个有序序列后，再将这一段分组交付给上层。对于不能被正确接收的分组，接收方直接忽略该分组。

详细资料能够参考：
《TCP 连续 ARQ 协议和滑动窗口协议》

TCP 的可靠运输机制

TCP 的可靠运输机制是基于连续 ARQ 协议和滑动窗口协议的。

TCP 协议在发送方维持了一个发送窗口，发送窗口之前的报文段是已经发送并确认了的报文段，发送窗口中包含了已经发送但
未确认的报文段和容许发送但还未发送的报文段，发送窗口之后的报文段是缓存中还不容许发送的报文段。当发送方向接收方发
送报文时，会依次发送窗口内的全部报文段，而且设置一个定时器，这个定时器能够理解为是最先发送但未收到确认的报文段。
若是在定时器的时间内收到某一个报文段的确认回答，则滑动窗口，将窗口的首部向后滑动到确认报文段的后一个位置，此时如
果还有已发送但没有确认的报文段，则从新设置定时器，若是没有了则关闭定时器。若是定时器超时，则从新发送全部已经发送
但还未收到确认的报文段，并将超时的间隔设置为之前的两倍。当发送方收到接收方的三个冗余的确认应答后，这是一种指示，
说明该报文段之后的报文段颇有可能发生丢失了，那么发送方会启用快速重传的机制，就是当前定时器结束前，发送全部的已发
送但确认的报文段。

接收方使用的是累计确认的机制，对于全部按序到达的报文段，接收方返回一个报文段的确定回答。若是收到了一个乱序的报文
段，那么接方会直接丢弃，并返回一个最近的按序到达的报文段的确定回答。使用累计确认保证了返回的确认号以前的报文段都
已经按序到达了，因此发送窗口能够移动到已确认报文段的后面。

发送窗口的大小是变化的，它是由接收窗口剩余大小和网络中拥塞程度来决定的，TCP 就是经过控制发送窗口的长度来控制报文
段的发送速率。

可是 TCP 协议并不彻底和滑动窗口协议相同，由于许多的 TCP 实现会将失序的报文段给缓存起来，而且发生重传时，只会重
传一个报文段，所以 TCP 协议的可靠传输机制更像是窗口滑动协议和选择重传协议的一个混合体。

TCP 的流量控制机制

TCP 提供了流量控制的服务，这个服务的主要目的是控制发送方的发送速率，保证接收方来得及接收。由于一旦发送的速率大
于接收方所能接收的速率，就会形成报文段的丢失。接收方主要是经过接收窗口来告诉发送方本身所能接收的大小，发送方根据
接收方的接收窗口的大小来调整发送窗口的大小，以此来达到控制发送速率的目的。

TCP 的拥塞控制机制

TCP 的拥塞控制主要是根据网络中的拥塞状况来控制发送方数据的发送速率，若是网络处于拥塞的状态，发送方就减少发送的
速率，这样一方面是为了不继续增长网络中的拥塞程度，另外一方面也是为了不网络拥塞可能形成的报文段丢失。

TCP 的拥塞控制主要使用了四个机制，分别是慢启动、拥塞避免、快速重传和快速恢复。

慢启动的基本思想是，由于在发送方刚开始发送数据的时候，并不知道网络中的拥塞程度，因此先以较低的速率发送，进行试探
，每次收到一个确认报文，就将发动窗口的长度加一，这样每一个 RTT 时间后，发送窗口的长度就会加倍。当发送窗口的大小达
到一个阈值的时候就进入拥塞避免算法。

拥塞避免算法是为了不可能发生的拥塞，将发送窗口的大小由每过一个 RTT 增加一倍，变为每过一个 RTT ，长度只加一。
这样将窗口的增加速率由指数增加，变为加法线性增加。

快速重传指的是，当发送方收到三个冗余的确认应答时，由于 TCP 使用的是累计确认的机制，因此颇有多是发生了报文段的
丢失，所以采用当即重传的机制，在定时器结束前发送全部已发送但还未接收到确认应答的报文段。

快速恢复是对快速重传的后续处理，由于网络中可能已经出现了拥塞状况，因此会将慢启动的阀值减少为原来的一半，而后将拥
塞窗口的值置为减半后的阀值，而后开始执行拥塞避免算法，使得拥塞窗口缓慢地加性增大。简单来理解就是，乘性减，加性增。

TCP 认为网络拥塞的主要依据是报文段的重传次数，它会根据网络中的拥塞程度，经过调整慢启动的阀值，而后交替使用上面四
种机制来达到拥塞控制的目的。

详细资料能够参考：
《TCP 的拥塞控制机制》
《网络基本功：TCP 拥塞控制机制》

网络层

网络层协议主要实现了不一样主机间的逻辑通讯功能。网络层协议一共包含两个主要的组件，一个 IP 网际协议，一个是路由选
择协议。

IP 网际协议规定了网络层的编址和转发方式，好比说咱们接入网络的主机都会被分配一个 IP 地址，经常使用的好比 IPV4 使用
32 位来分配地址，还有 IPv6 使用 128 位来分配地址。

路由选择协议决定了数据报从源到目的地所流经的路径，常见的好比距离向量路由选择算法等。

数据链路层

数据链路层提供的服务是如何将数据报经过单一通讯链路从一个结点移动到相邻节点。每一台主机都有一个惟一的 MAC 地址，
这是由网络适配器决定的，在全世界都是独一无二的。

物理层

物理层提供的服务是尽量的屏蔽掉组成网络的物理设备和传输介质间的差别，使数据链路层不须要考虑网络的具体传输介质
是什么。

详细资料能够参考：
《搞定计算机网络面试，看这篇就够了（补充版）》
《互联网协议入门（一）》
《互联网协议入门（二）》

常考面试题

1. Post 和 Get 的区别？

Post 和 Get 是 HTTP 请求的两种方法。

（1）从应用场景上来讲，GET 请求是一个幂等的请求，通常 Get 请求用于对服务器资源不会产生影响的场景，好比说请求一个网
页。而 Post 不是一个幂等的请求，通常用于对服务器资源会产生影响的情景。好比注册用户这一类的操做。

（2）由于不一样的应用场景，因此浏览器通常会对 Get 请求缓存，但不多对 Post 请求缓存。

（3）从发送的报文格式来讲，Get 请求的报文中实体部分为空，Post 请求的报文中实体部分通常为向服务器发送的数据。

（4）可是 Get 请求也能够将请求的参数放入 url 中向服务器发送，这样的作法相对于 Post 请求来讲，一个方面是不太安全，
由于请求的 url 会被保留在历史记录中。而且浏览器因为对 url 有一个长度上的限制，因此会影响 get 请求发送数据时
的长度。这个限制是浏览器规定的，并非 RFC 规定的。还有就是 post 的参数传递支持更多的数据类型。

2. TLS/SSL 中什么必定要用三个随机数，来生成"会话密钥"？

客户端和服务器都须要生成随机数，以此来保证每次生成的秘钥都不相同。使用三个随机数，是由于 SSL 的协议默认不信任每一个主
机都能产生彻底随机的数，若是只使用一个伪随机的数来生成秘钥，就很容易被破解。经过使用三个随机数的方式，增长了自由度，
一个伪随机可能被破解，可是三个伪随机就很接近于随机了，所以可使用这种方法来保持生成秘钥的随机性和安全性。

3. SSL 链接断开后如何恢复？

一共有两种方法来恢复断开的 SSL 链接，一种是使用 session ID，一种是 session ticket。

使用 session ID 的方式，每一次的会话都有一个编号，当对话中断后，下一次从新链接时，只要客户端给出这个编号，服务器
若是有这个编号的记录，那么双方就能够继续使用之前的秘钥，而不用从新生成一把。目前全部的浏览器都支持这一种方法。可是
这种方法有一个缺点是，session ID 只可以存在一台服务器上，若是咱们的请求经过负载平衡被转移到了其余的服务器上，那
么就没法恢复对话。

另外一种方式是 session ticket 的方式，session ticket 是服务器在上一次对话中发送给客户的，这个 ticket 是加密的
，只有服务器可以解密，里面包含了本次会话的信息，好比对话秘钥和加密方法等。这样无论咱们的请求是否转移到其余的服务器
上，当服务器将 ticket 解密之后，就可以获取上次对话的信息，就不用从新生成对话秘钥了。

4. RSA 算法的安全性保障？

对极大整数作因数分解的难度决定了 RSA 算法的可靠性。换言之，对一极大整数作因数分解愈困难，RSA 算法愈可靠。如今102
4位的 RSA 密钥基本安全，2048位的密钥极其安全。

5. DNS 为何使用 UDP 协议做为传输层协议？

DNS 使用 UDP 协议做为传输层协议的主要缘由是为了不使用 TCP 协议时形成的链接时延。由于为了获得一个域名的 IP 地
址，每每会向多个域名服务器查询，若是使用 TCP 协议，那么每次请求都会存在链接时延，这样使 DNS 服务变得很慢，由于大
多数的地址查询请求，都是浏览器请求页面时发出的，这样会形成网页的等待时间过长。

使用 UDP 协议做为 DNS 协议会有一个问题，因为历史缘由，物理链路的最小MTU = 576，因此为了限制报文长度不超过576，
UDP 的报文段的长度被限制在 512 个字节之内，这样一旦 DNS 的查询或者应答报文，超过了 512 字节，那么基于 UDP 的
DNS 协议就会被截断为 512 字节，那么有可能用户获得的 DNS 应答就是不完整的。这里 DNS 报文的长度一旦超过限制，并不
会像 TCP 协议那样被拆分红多个报文段传输，由于 UDP 协议不会维护链接状态，因此咱们没有办法肯定那几个报文段属于同一
个数据，UDP 只会将多余的数据给截取掉。为了解决这个问题，咱们可使用 TCP 协议去请求报文。

DNS 还存在的一个问题是安全问题，就是咱们没有办法肯定咱们获得的应答，必定是一个安全的应答，由于应答能够被他人伪造，
因此如今有了 DNS over HTTPS 来解决这个问题。

详细资料能够参考：
《为何 DNS 使用 UDP 而不是 TCP？》

6. 当你在浏览器中输入 Google.com 而且按下回车以后发生了什么？

（1）首先会对 URL 进行解析，分析所须要使用的传输协议和请求的资源的路径。若是输入的 URL 中的协议或者主机名不合法，
将会把地址栏中输入的内容传递给搜索引擎。若是没有问题，浏览器会检查 URL 中是否出现了非法字符，若是存在非法字
符，则对非法字符进行转义后再进行下一过程。

（2）浏览器会判断所请求的资源是否在缓存里，若是请求的资源在缓存里而且没有失效，那么就直接使用，不然向服务器发起新
的请求。

（3）下一步咱们首先须要获取的是输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，若是
有则使用，若是没有则向本地 DNS 服务器发起请求。本地 DNS 服务器也会先检查是否存在缓存，若是没有就会先向根域
名服务器发起请求，得到负责的顶级域名服务器的地址后，再向顶级域名服务器请求，而后得到负责的权威域名服务器的地
址后，再向权威域名服务器发起请求，最终得到域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用
户。用户向本地 DNS 服务器发起请求属于递归请求，本地 DNS 服务器向各级域名服务器发起请求属于迭代请求。

（4）当浏览器获得 IP 地址后，数据传输还须要知道目的主机 MAC 地址，由于应用层下发数据给传输层，TCP 协议会指定源
端口号和目的端口号，而后下发给网络层。网络层会将本机地址做为源地址，获取的 IP 地址做为目的地址。而后将下发给
数据链路层，数据链路层的发送须要加入通讯双方的 MAC 地址，咱们本机的 MAC 地址做为源 MAC 地址，目的 MAC 地
址须要分状况处理，经过将 IP 地址与咱们本机的子网掩码相与，咱们能够判断咱们是否与请求主机在同一个子网里，若是
在同一个子网里，咱们可使用 APR 协议获取到目的主机的 MAC 地址，若是咱们不在一个子网里，那么咱们的请求应该
转发给咱们的网关，由它代为转发，此时一样能够经过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应
该为网关的地址。

（5）下面是 TCP 创建链接的三次握手的过程，首先客户端向服务器发送一个 SYN 链接请求报文段和一个随机序号，服务端接
收到请求后向服务器端发送一个 SYN ACK报文段，确认链接请求，而且也向客户端发送一个随机序号。客户端接收服务器的
确认应答后，进入链接创建的状态，同时向服务器也发送一个 ACK 确认报文段，服务器端接收到确认后，也进入链接创建
状态，此时双方的链接就创建起来了。

（6）若是使用的是 HTTPS 协议，在通讯前还存在 TLS 的一个四次握手的过程。首先由客户端向服务器端发送使用的协议的版
本号、一个随机数和可使用的加密方法。服务器端收到后，确认加密的方法，也向客户端发送一个随机数和本身的数字证
书。客户端收到后，首先检查数字证书是否有效，若是有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，而后
发送给服务器端，而且还会提供一个前面全部内容的 hash 值供服务器端检验。服务器端接收后，使用本身的私钥对数据解
密，同时向客户端发送一个前面全部内容的 hash 值供客户端检验。这个时候双方都有了三个随机数，按照以前所约定的加
密方法，使用这三个随机数生成一把秘钥，之后双方通讯前，就使用这个秘钥对数据进行加密后再传输。

（7）当页面请求发送到服务器端后，服务器端会返回一个 html 文件做为响应，浏览器接收到响应后，开始对 html 文件进行
解析，开始页面的渲染过程。

（8）浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，若是遇到 script 标签，则判端
是否含有 defer 或者 async 属性，要否则 script 的加载和执行会形成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建
立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页
面进行绘制。这个时候整个页面就显示出来了。

（9）最后一步是 TCP 断开链接的四次挥手过程。

详细资料能够参考：
《当你在浏览器中输入 Google.com 而且按下回车以后发生了什么？》

7. 谈谈 CDN 服务？

CDN 是一个内容分发网络，经过对源网站资源的缓存，利用自己多台位于不一样地域、不一样运营商的服务器，向用户提供资就近访问的
功能。也就是说，用户的请求并非直接发送给源网站，而是发送给 CDN 服务器，由 CND 服务器将请求定位到最近的含有该资源
的服务器上去请求。这样有利于提升网站的访问速度，同时经过这种方式也减轻了源服务器的访问压力。

详细资料能够参考：
《CDN 是什么？使用 CDN 有什么优点？》

8. 什么是正向代理和反向代理？

咱们常说的代理也就是指正向代理，正向代理的过程，它隐藏了真实的请求客户端，服务端不知道真实的客户端是谁，客户端请求的
服务都被代理服务器代替来请求。

反向代理隐藏了真实的服务端，当咱们请求一个网站的时候，背后可能有成千上万台服务器为咱们服务，但具体是哪一台，咱们不知
道，也不须要知道，咱们只须要知道反向代理服务器是谁就行了，反向代理服务器会帮咱们把请求转发到真实的服务器那里去。反向
代理器通常用来实现负载平衡。

详细资料能够参考：
《正向代理与反向代理有什么区别》
《webpack 配置 proxy 反向代理的原理是什么？》

9. 负载平衡的两种实现方式？

一种是使用反向代理的方式，用户的请求都发送到反向代理服务上，而后由反向代理服务器来转发请求到真实的服务器上，以此来实
现集群的负载平衡。

另外一种是 DNS 的方式，DNS 能够用于在冗余的服务器上实现负载平衡。由于如今通常的大型网站使用多台服务器提供服务，所以一
个域名可能会对应多个服务器地址。当用户向网站域名请求的时候，DNS 服务器返回这个域名所对应的服务器 IP 地址的集合，但在
每一个回答中，会循环这些 IP 地址的顺序，用户通常会选择排在前面的地址发送请求。以此将用户的请求均衡的分配到各个不一样的服
务器上，这样来实现负载均衡。这种方式有一个缺点就是，因为 DNS 服务器中存在缓存，因此有可能一个服务器出现故障后，域名解
析仍然返回的是那个 IP 地址，就会形成访问的问题。

详细资料能够参考：
《负载均衡的原理》

10. http 请求方法 options 方法有什么用？

OPTIONS 请求与 HEAD 相似，通常也是用于客户端查看服务器的性能。这个方法会请求服务器返回该资源所支持的全部 HTTP 请
 求方法，该方法会用'*'来代替资源名称，向服务器发送 OPTIONS 请求，能够测试服务器功能是否正常。JS 的 XMLHttpRequest
 对象进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

相关资料能够参考：
《HTTP 请求方法》

11. http1.1 和 http1.0 之间有哪些区别？

http1.1 相对于 http1.0 有这样几个区别：
（1）链接方面的区别，http1.1 默认使用持久链接，而 http1.0 默认使用非持久链接。http1.1 经过使用持久链接来使多个 http 请求复用同一个 TCP 链接，以此来避免使用非持久链接时每次须要创建链接的时延。
（2）资源请求方面的区别，在 http1.0 中，存在一些浪费带宽的现象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了，而且不支持断点续传功能，http1.1 则在请求头引入了 range 头域，它容许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和链接。

（3）缓存方面的区别，在 http1.0 中主要使用 header 里的 If-Modified-Since,Expires 来作为缓存判断的标准，http1.1 则引入了更多的缓存控制策略例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择的缓存头来控制缓存策略。

（4）http1.1 中还新增了 host 字段，用来指定服务器的域名。http1.0 中认为每台服务器都绑定一个惟一的 IP 地址，所以，请求消息中的 URL 并无传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上能够存在多个虚拟主机，而且它们共享一个IP地址。所以有了 host 字段，就能够将请求发往同一台服务器上的不一样网站。

（5）http1.1 相对于 http1.0 还新增了不少方法，如 PUT、HEAD、OPTIONS 等。

详细资料能够参考：
《HTTP1.0、HTTP1.1 和 HTTP2.0 的区别》
《HTTP 协议入门》
《网络---一篇文章详解请求头 Host 的概念》

12. 网站域名加 www 与不加 www 的区别？

详细资料能够参考：
《为何域名前要加 www 前缀 www 是什么意思？》
《为何愈来愈多的网站域名不加「www」前缀？》
《域名有 www 与没有 www 有什么区别？》

13. 即时通信的实现，短轮询、长轮询、SSE 和 WebSocket 间的区别？

短轮询和长轮询的目的都是用于实现客户端和服务器端的一个即时通信。

短轮询的基本思路就是浏览器每隔一段时间向浏览器发送 http 请求，服务器端在收到请求后，不管是否有数据更新，都直接进行
响应。这种方式实现的即时通讯，本质上仍是浏览器发送请求，服务器接受请求的一个过程，经过让客户端不断的进行请求，使得客
户端可以模拟实时地收到服务器端的数据的变化。这种方式的优势是比较简单，易于理解。缺点是这种方式因为须要不断的创建 ht
tp 链接，严重浪费了服务器端和客户端的资源。当用户增长时，服务器端的压力就会变大，这是很不合理的。

长轮询的基本思路是，首先由客户端向服务器发起请求，当服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将
这个请求挂起，而后判断服务器端数据是否有更新。若是有更新，则进行响应，若是一直没有数据，则到达必定的时间限制才返回。
客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，从新创建链接。长轮询和短轮询比起来，它的
优势是明显减小了不少没必要要的 http 请求次数，相比之下节约了资源。长轮询的缺点在于，链接挂起也会致使资源的浪费。

SSE 的基本思想是，服务器使用流信息向服务器推送信息。严格地说，http 协议没法作到服务器主动推送信息。可是，有一种变通
方法，就是服务器向客户端声明，接下来要发送的是流信息。也就是说，发送的不是一次性的数据包，而是一个数据流，会接二连三
地发送过来。这时，客户端不会关闭链接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。SSE 就是利用这种机
制，使用流信息向浏览器推送信息。它基于 http 协议，目前除了 IE/Edge，其余浏览器都支持。它相对于前面两种方式来讲，不
须要创建过多的 http 请求，相比之下节约了资源。

上面三种方式本质上都是基于 http 协议的，咱们还可使用 WebSocket 协议来实现。WebSocket 是 Html5 定义的一个新协
议，与传统的 http 协议不一样，该协议容许由服务器主动的向客户端推送信息。使用 WebSocket 协议的缺点是在服务器端的配置
比较复杂。WebSocket 是一个全双工的协议，也就是通讯双方是平等的，能够相互发送消息，而 SSE 的方式是单向通讯的，只能
由服务器端向客户端推送信息，若是客户端须要发送信息就是属于下一个 http 请求了。

详细资料能够参考：
《轮询、长轮询、长链接、websocket》
《Server-Sent Events 教程》
《WebSocket 教程》

14. 怎么实现多个网站之间共享登陆状态

在多个网站之间共享登陆状态指的就是单点登陆。多个应用系统中，用户只须要登陆一次就能够访问全部相互信任的应用系统。

我认为单点登陆能够这样来实现，首先将用户信息的验证中心独立出来，做为一个单独的认证中心，该认证中心的做用是判断客户端发
送的帐号密码的正确性，而后向客户端返回对应的用户信息，而且返回一个由服务器端秘钥加密的登陆信息的 token 给客户端，该
token 具备必定的有效时限。当一个应用系统跳转到另外一个应用系统时，经过 url 参数的方式来传递 token，而后转移到的应用站
点发送给认证中心，认证中心对 token 进行解密后验证，若是用户信息没有失效，则向客户端返回对应的用户信息，若是失效了则将
页面重定向会单点登陆页面。

详细资料能够参考：
《HTTP 是个无状态协议，怎么保持登陆状态？》