网络部分

1. Http和Https的区别？

一、传输信息安全性不同

1、http协议：是超文本传输协议，信息是明文传输。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。

2、https协议：是具有安全性的ssl加密传输协议，为浏览器和服务器之间的通信加密，确保数据传输的安全。

二、连接方式不同

1、http协议：http的连接很简单，是无状态的。

2、https协议：是由SSL＋HTTP协议构建的可进行加密传输、身份认证的网络协议。

三、端口不同

1、http协议：使用的端口是80。

2、https协议：使用的端口是443．

四、证书申请方式不同

1、http协议：免费申请。

2、https协议：需要到申请证书，一般免费证书很少，需要交费。

2. 对称加密与非对称加密？

对称加密：在对称加密当中加密使用的秘钥和解密使用的秘钥是相同的。也就是加密和解密都是同一个秘钥。这样秘钥的安全性就非常重要，秘钥是一定不能公开的。

例子：假如有Client与Server之间要进行通讯，他们商定了一种秘钥，Client用秘钥加密传输信息。Server收到信息用秘钥解密信息。这样的一个通信过程就是对称加密的过程。

缺点：对称加密的缺点就在于如果秘钥要是泄露，这样Client与Server之间的信息传递就不安全了。

非对称加密：有一对秘钥叫做公钥与私钥，公钥是对外公开的，所有人都能拥有，但是私钥有且只有一个。公钥和私钥都能进行加密，但是公钥加密的密文只有私钥能够解密，私钥加密的所有公钥都能解密，这就是非对称加密。

例子：假如有ClientA、ClientB、ClientC与Server进行通讯，Server拥有一对公钥和私钥，它自己保留唯一的私钥，对外公开自己的公钥，这样ClientA、ClientB、ClientC都能拿到公钥。ClientA用公钥加密的密文只有Server的私钥才能解密，这样ClientA传递信息就是安全的了，因为即使有中间黑客获取了公钥加密的密文，因为黑客没有私钥也没有办法解密。

缺点：非对称加密只是保证了Client向Server发送的消息是安全的，因为私钥有且只有一把在Server手中，但是反过来Server向Client发送的消息就不是安全的，因为公钥是公开的大家都能下载，也就都能解密信息。

解决办法：使用Https解决。

3. 三次握手与四次挥手？

   1.”三次握手”的详解

   所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：
   
   握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：

（1）首先客户端向服务器端发送一段TCP报文，其中：

标记位为SYN，表示“请求建立新连接”;序号为Seq=X（X一般为1）；

随后客户端进入SYN-SENT阶段。

（2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：

标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；

序号为Seq=y；

确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；

随后服务器端进入SYN-RCVD阶段。

（3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：

标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；

序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；

随后客户端进入ESTABLISHED阶段。

四次挥手

所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。以下为客户端主动发起释放连接的图解：

挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”：

（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：

标记位为FIN，表示“请求释放连接“；

序号为Seq=U；

随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。

注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。

（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：

标记位为ACK，表示“接收到客户端发送的释放连接的请求”；

序号为Seq=V；

确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；随后服务器端开始准备释放服务器端到客户端方向上的连接。

客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。

于是，可以确认关闭客户端到服务器端方向上的连接了

（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：

标记位为FIN，ACK，表示“已经准备好释放连接了”。

注意：这里的ACK并不是确认收到服务器端报文的确认报文。

序号为Seq=W；

确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。

随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。

并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

标记位为ACK，表示“接收到服务器准备好释放连接的信号”。

序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。

确认号为Ack=W+1；

表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。随后客户端开始在TIME-WAIT阶段等待2MSL

4. 为什么 TCP 链接需要三次握手，两次不可以么？

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

5. 为什么要四次挥手？

参照三次握手机制，挥手最少需要三次，如果只有三次，客户端发送完数据请求断开连接，而服务端不一定也同样发送完数据，若同时回ACK和FIN给客户端，断开连接，可能造成数据的损坏；若先发送ACK，再等B的数据发送完了再发送FIN和ACK，就可以保证传输数据的完整性。

tcp是全双工模式，接收到FIN意味着将没有数据再发来，但是还是可以继续发送数据。

6. TCP 协议如何来保证传输的可靠性？

TCP协议保证数据传输可靠性的方式主要有：

• 校验和
• 序列号
• 确认应答
• 超时重传
• 连接管理
• 流量控制
• 拥塞控制

7. 客户端不断进行请求链接会怎样？DDos(Distributed Denial of Service)攻击？

客户端向服务器发送大量请求连接，服务器因此分配连接资源，并向客户端发送第二次握手数据包，但是此时客户端却不向服务器发送第三次握手数据包，导致服务器有大量资源等待着第三次握手数据包，每个资源须等待30s到2min才会关闭。这会占用大量的服务器资源，使服务器性能降低。

8. GET 与 POST 的区别？

（1）理论上的（Specifification）：GET和POST具有相同语法的，但是有不同的语义。

get是⽤来获取数据的，post是⽤来发送数据的，其他⽅⾯没有区别。

（2）实现上的（Implementation）：各种浏览器，就是这个规范的实现者。

常⻅的那些不同：

• GET的数据在URL是可⻅的。POST请求不显示在URL*中。

• GET对⻓度是有限制的，POST⻓度是⽆限的。

• GET请求的数据可以收藏为书签，post请求到的数据不可收藏为书签。

• GET请求后，按后退按钮、刷新按钮⽆影响，post数据会被重新提交。

• GET编码类型：

  • application/x-www-form-url，

  • *post**的编码类型：有很多种

  • post的编码类型：有很多种

  • encodeapplication/x-www-form-urlencoded**

  • multipart/form-data

• GET历史参数会被保留在浏览器⾥，psot不会保存在浏览器中的。

• GET只允许ASCII.post没有编码限制，允许发⼆进制的。

• GET与POST相⽐，GET安全性较差，因为所发的数据是URL的⼀部分

9. TCP与UDP的区别？

   1、连接方面区别

TCP面向连接（如打电话要先拨号建立连接）。
UDP是无连接的，即发送数据之前不需要建立连接。

2、安全方面的区别

TCP提供可靠的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。

UDP尽最大努力交付，即不保证可靠交付。

3、传输效率的区别

TCP传输效率相对较低。

UDP传输效率高，适用于对高速传输和实时性有较高的通信或广播通信。

4、连接对象数量的区别

TCP连接只能是点到点、一对一的。

UDP支持一对一，一对多，多对一和多对多的交互通信

10. TCP和UDP分别对应的常见应用层协议？

1.TCP对应的应用层协议：
FTP:定义了文件传输协议，使用21端口。下载文件，上传主页都是用到FTP服务。
SMTP：定义了简单邮件传送协议，用于发送邮件，使用的是25端口。
HTTP：从Web服务器传输超文本到本地浏览器的传送协议。
Telnet：一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。
POP3：和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议使用的是110端口，只要你有相应的使用POP3协议的程序（例如Foxmail或Outlook）,就可以不以Web方式登陆进邮箱界面，直接使用邮件程序就可以收到邮件（如163邮箱就是没有必要先进入网易网站，再进入自己的邮箱来收信）。
2.UDP对应的应用层协议：

DNS：用于域名解析服务，将域名地址转换成IP地址。DNS用的是53号端口。
SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出优势。
TFTP（Trival File Transfer Protocal）：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

11. 常见http状态

（1）200：请求成功，一切正常，数据成功返回
（2）301：永久性重定向，是指所请求的文档在别的地方;文档新的URI会在定位响应头信息中给出。浏览器会自动连接到新的URI。
（3）302：临时重定向，该状态码表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的URI访问。
（4）303：该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源
（5）403：Foribidden 服务器端理解本次请求，但是拒绝执行任务，没有权限访问
（6）404：NOT found 请求的资源，网页无法找到，不存在
（7）503：服务器端无法响应，服务器由于在维护或已经超载而无法响应

12. 什么是同源策略?

浏览器最核心，最基本的安全功能是同源策略。限制了一个源中加载文本或者脚本与其他源中资源的交互方式，当浏览器执行一个脚本时会检查是否同源，只有同源的脚本才会执行，如果不同源即为跨域。

1. Jsonp：原理就是利用了script标签不受同源策略的限制，在页面中动态插入了script，script标签的src属性就是后端api接口的地址，并且以get的方式将前端回调处理函数名称告诉后端，后端在响应请求时会将回调返还，并且将数据以参数的形式传递回去。
2. CORS：(跨域资源共享)是一种允许当前域的资源被其他域的脚本请求访问的机制。 当使用XMLHttpRequest发送请求时，浏览器如果发现违反了同源策略就会自动加上一个请求头:origin,后端在接受到请求后确定响应后会在Response
   Headers中加入一个属性:Access-Control-Allow-Origin,值就是发起请求的源地址，浏览器得到响应会进行判断Access-Control-Allow-Origin的值是否和当前的地址相同，只有匹配成功后才进行响应处理。现代浏览器中和移动端都支持CORS，IE下需要8+。
3. 服务器跨域，服务器中转代理。前端向本地服务器发送请求，本地服务器代替前端再向服务器接口发送请求进行服务器间通信，本地服务器是个中转站的角色，再将响应的数据返回给前端。

13. url输入到界面会发生什么？

加载过程：

• • • 浏览器根据 DNS 服务器解析得到域名的 IP 地址
    • 向这个 IP 的机器发送 HTTP 请求
    • 服务器收到、处理并返回 HTTP 请求
    • 浏览器得到返回内容

渲染过程：

• • • 根据 HTML 结构生成 DOM 树
    • 根据 CSS 生成 CSSOM
    • 将 DOM 和 CSSOM 整合形成 RenderTree
    • 根据 RenderTree 开始渲染和展示
    • 遇到js标签时，会执行并阻塞渲染
      浏览器会把HTML解析成DOM，把CSS解析成CSSOM，DOM和CSSOM合并就产生了Render Tree。有了RenderTree，我们就知道了所有节点的样式，然后计算他们在页面上的大小和位置，最后把节点绘制到页面上。

14. 什么是重排和重绘？

• 回流：当Render Tree中部分或全部元素的尺寸、结构、或某些属性发生改变时，浏览器重新渲染部分或全部文档的过程称为回流。

• 重绘：当页面中元素样式的改变并不影响它在文档流中的位置时（例如：color、background-color、visibility等），浏览器会将新样式赋予给元素并重新绘制它，这个过程称为重绘。

• 触发重排和重绘：

• • 页面首次渲染
  • 浏览器窗口大小发生改变
  • 元素尺寸或位置发生改变
  • 元素内容变化（文字数量或图片大小等等）
  • 元素字体大小变化
  • 添加或者删除可见的DOM元素

• 减少重回和重排：避免频繁的样式操作，最好一次性重写style，或者一次性更改class，避免频繁操作dom，对具有复杂动画的元素使用绝对定位，使它脱离文档流，否则会引起父元素及后续元素频繁回流

14. Cookie与Session

1.如果我们⽤JS的变量来存数据，那么在⻚⾯关闭的时候，数据就消失了。

2.保持登录状态是怎么做到的呢？

按照正常的HTTP协议来说，是做不到的。

因为HTTP协议，上下⽂⽆关协议。

3.所以说前端⻚⾯上，有可以持久化存储数据的东⻄。⼀旦登录成功，我就记载在这个⾥⾯。

Cookie是有限制的。

Cookie是存在浏览器⾥的，不是存在某个⻚⾯上的。是可以⻓期存储的。Cookie即使是保

存在浏览器⾥，也是存放在不同的域名下的。

1.初始状态：没有登录

2. 访问百度的登录，输⼊⽤户名，密码。

3. 如果⽤户名和密码是正确的。百度的后端会向这个域名下，设置⼀个Cookie。写⼊⽤户

的基本信息（加密的）。

4. 以后每⼀次向百度发送请求，浏览器都会⾃动带上这些Cookie。

5. 服务端（后端）看到了带有ID的cookie，就可以解析这个加密的ID，来获取到这个⽤户

本身的ID。

6. 如果能获取到本身的ID，那么就证明这个⽤户已经登录过了。所以后端可以继续保留⽤

户的信息。

缺点：如果某个坏⼈，复制了我浏览器⾥的cookie，他就可以在他的电脑上登录我的账号

*了。XSS注⼊攻击。浏览器

数据存在Session上也有缺点

如果⽤户量⾮常⼤，上亿的⽤户。

在⽤户量很⼤的时候，服务器端很耗资源的。

因为后端可能不⽌⼀台服务器，⽤户的登录信息，⼀般只存在⼀台服务器上。

因为⽤户的登录操作，在哪台机器上执⾏的，就⼀般存在哪台机器上。

需要通过反向代理。（轮询，IP哈希。）B/S结构