前端八股文（一）

1、http与https的基本概念

• **http：**是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的超文本传输协议。
• **https：**是以安全为目标的HTTP通道，即HTTP下加入SSL层进行加密。其作用：建立一个信息安全通道，来确保数据的传输，企鹅包网站的真实性。

2、http与https的区别以及优缺点

1. http是超文本传输协议，信息是明文传输，HTTPS协议比http协议安全，https是具有安全性的ssl加密传输协议，客防止数据在传输过程中被盗窃、改变，确保数据的完整性。
2. http协议的默认端口为 80，https协议的默认端口为 443.
3. http 的连接很简单，是无状态的。https握手阶段很费时，回事页面加载时间延长50%，增加耗电（10~20%）。
4. https缓存不如 http 高效，会增加数据开销。https 协议需要 ca证书，费用较高，功能越强大放入证书费用越高。
5. SSL 证书需要绑定IP ,不能在同一个IP 上绑定多个域名，IPv4资源支持不了这种消耗。

3、https 协议的工作原理

1. 客户端使用 https url 访问服务器，则要求 web 服务器建立 ssl 链接。
2. web 服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥），传输给客户端。
3. 客户端和 web 服务器端开始协商一致的安全等级，建立会话秘钥，然后通过网站的公钥来加密会话秘钥，并传送给网站。
4. web 服务器通过自己的私钥解密出会话秘钥。
5. web 服务器用会话秘钥加密与解密与客户端的通信。

4、TCP 三次握手

讲述三次握手前，先看看TCP报文段结构

三次握手开始：

• 第一步: 客户端TCP向服务器端的TCP发送一个特殊的TCP报文段, 该报文段不包含应用层数据. 报文段首部中的标志位SYN置1, 简称为SYN报文段. 同时客户端随机选取一个初始序列号client_isn, 放置于SYN报文段的序号字段中, 最后把该报文段经下层封装发送给服务器. SYN的意思是: xxx服务器, 我想向你发起TCP连接, 我的初始序号为client_isn.
• 第二步: 服务器收到SYN报文段后, 响应一个SYNACK报文段. SYNACK报文段的SYN标志位置1, 确认号字段设置为client_isn + 1, 序号字段由服务器选择自己的初始序号server_isn. SYNACK报文段的意思是: 我收到了你的SYN报文段, 序号为client_isn, 我同意该连接, 我自己的序号为server_isn.
• 第三步: 客户端接收到SYNACK后要告知服务器自己收到了. 于是发送最后一个报文段, SYN标志位置0, 把确认字段设置为server_isn + 1, 并设置自己的序号. 这个报文意思是: 好的, 我知道你同意了, 我们开始传输数据吧.

看TCP报文段中的序号和确认号.

• 序号:
  **序号是建立在传送的字节流之上, 而不是建立在传送的报文段的序列之上的.。**意思是说如果把传输的数据看作是一个字节文本, 序号则是对文本的首字节进行编号.
  我知道还是很抽象, 看具体例子. 现在要通过TCP发送一个500000字节的大文件, 最大报文长度为1000(一个报文段最多只能装1000个字节). 那么这次TCP传输就要分为500个报文段. 第一个报文段序号为0, 因为在500000字节中首字节的序号为0; 第二个报文段的序号为1000, 因为第一个报文段装了1000个字节, 第二个报文段从第1000个字节开始装起; 同理, 第三个报文段的序号为2000…
• 为什么要使用序号?
  **发送序号是为了告诉接收方, 下一次我将从哪个地方开始传数据给你. 接收方同时也会期待下次从下一个字节序列的位置开始接收发送方的数据。 **接收方会把这个位置写到确认号中, 比如上面的例子, 接收方在接收到0序列分组后, 会在确认字段填入1000, 下一次期待接收1000位置的字节.
• 由上可见: 主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号.

5、TCP 的四次挥手

1. 客户端进程发出连接释放波报文，并且停止发送数据。释放数据报文首部，FIN = 1，其序列号 seq = u（等于前面已经传送过来的数据额租后一个字节的序列号 + 1）,此时客户端进入 FIN-WAIT-1（终止等待1）。TCP规定，FIN报文段即使不懈怠数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK = 1,ack = u + 1，并且带上自己的序列seq = v，此时服务器进入CLOSE-WAIT（关闭连接）状态。TCP服务器通知高岑的应用进程，客户端向服务器的方向就释放了，这时候处于办关闭状态，即客户端已经没有数据要发送了，但是服务器若要发送数据，客户端毅然接受。此状态持续一点时间，整个CLOSE-WAIE 状态持续时间。
3. 客户端收到服务器的确认请求后，此时客户端进入FIN-WAIE-2（终止等待2）状态，等待服务器发送释放报文（在这之前还需接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完后，就向客户端发送链接释放报文，FIN =1,ack= u+1，，由于处于半关闭状态，服务器可能又发送了一些数据，嘉定此时的序列号为 seq = w，此时服务器进入LAST-ACK（最后确认）状态，等到客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认,ACK = 1,ack = w+1，而自己的序列号 seq = u+1,此时客户端进入 TIME-WAIT（时间等待）状态。**注意此时TCP 连接还没有释放，必须经过 2 * MSL（最长 报文寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态
6. 服务器只要接受到客户端发出的确认，立即进入CLOSED 状态。同样撤销TCB后，就结束了这次TCP连接。可以看到服务器结束TCP 连接的时间比客户端要早。

6、TCP/IP 如何保证数据包传输的有序可靠？

对字节流分段并进行编号然后通过ACK回复和超时重发这两个机制来保证。

1. 为了保证数据包的可靠传递，发送发必须将已发的数据包保留到缓冲区；
2. 并为每个已发送的数据包启动一个超时定时器；
3. 如果定时器超时之前收到了对方发来的应答信（可能是对包的应答，也与可能是对本包后续包的应答），则释放包数据包占用的缓冲区；
4. 否则，重传该数据包，直到手打应答或重传次数超过的最大次数为止。
5. 接收方收到数据包后，先进行CRC校验，如果正确则把数据上交到上层协议，然后给发送发发送一个累计应答包，则表明该数据已收到，如果接收方正好也有数据要发送给发送方，应答包也应该在数据包中捎带过去。

7、TCP和UDP 的区别

• TCP是面向连接的，而UDP是无面向连接的。
• TCP仅支持单播传输，而UDP 提供了单播、多播，广播的功能。
• TCP 的三次握手保证了连接的可靠性，而UDP是无连接的、不可靠的一种数据传输协议（可靠体现在无连接上，通信都不需要建立连接，对接受的数据也不发送确认信号，发送端不知道数据是否会正确接受）。
• UDP 的头部开销比TCP更小，数据传输速率更高、实时性更好。

8、Cookie、sessionStrrage、localStrrage的区别

相同点：存储在客户端。

不同点：

• cookie数据大小不超过4k；sessionStrrage、localStrrage的存储比cookie大得多，一般为5M以上；
• cookie在过期时间之前一直有效；localStrrage永久储存，除非收到删除；sessionStorage数据在当前窗口关闭时会自动删除。
• cookie的数据会自动的传递到服务器；而sessionStrrage、localStrrage数据保存在浏览器本地；

9、粘包问题分析与对策

1. 定义：TCP 的粘包是指发送发发送的若干包数据到接收方时粘成一包，从接收缓存区来看，后一包数据的头紧挨着前一包数据尾部。
2. 粘包出现的原因：
   • 在流传输时，UDP不会出现粘包，因为它有消息边界。
   • 粘包出现的两种情况：
     1. 粘在一起的包都是完整的
     2. 粘在一起的包有不完整的
3. 采取的措施
   1. 对于发送发引起的粘包现象，用户客通过编程设置来避免。TCP 提供了强制数据立即传送的操作指push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不比等到发送缓存区满。
   2. 对于接收方引起的粘包，则可通过优化程序设计、精简接受进程工作量、提高接受进程优先级等措施，使其及时接受数据，从而尽量减少粘包现象。
   3. 由接收方控制，将一包数据按照结构字段，人为控制分多次发送，然后合并，通过这种手段来减少粘包。分包多发。

10、浏览器的缓存机制 强制缓存&& 协商缓存

浏览器与服务器通信的方式为应答模式，即是：浏览器发起HTTP请求 – 服务器响应该请求，那么浏览器怎么确定一个资源该不该缓存，如何去缓存呢？浏览器第一次向服务器发起该请求后拿到请求结果后，将请求结果和缓存标识存入浏览器缓存，浏览器对于缓存的处理是根据第一次请求资源时返回的响应头来确定的。具体过程如下图：

由上图我们可以知道：

• 浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识
• 浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中

以上两点结论就是浏览器缓存机制的关键，它确保了每个请求的缓存存入与读取

(1)强制缓存

​ 强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程。当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器，控制强制缓存的字段分别是Expires和Cache-Control，其中Cache-Control优先级比Expires高。
强制缓存的情况主要有三种(暂不分析协商缓存过程):

1. 不存在该缓存结果和缓存标识，强制缓存失效，则直接向服务器发起请求(跟第一次发起请求一致)。
2. 存在该缓存结果和缓存标识，但该结果已失效，强制缓存失效，则使用协商缓存。
3. 存在该缓存结果和缓存标识，且该结果尚未失效，强制缓存生效，直接返回该结果。

(2)协商缓存

​ 协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，同样，协商缓存的标识也是在响应报文的HTTP头中和请求结果一起返回给浏览器的，控制协商缓存的字段分别有:Last-Modified/If-Modified-Since和Etag/If-None-Match，其中Etag/If-None-Match的优先级比Last-Modified/If-Modified-Since高。协商缓存主要有以下两种情况:

1. 协商缓存生效，返回304
2. 协商缓存失效，返画200和请求结果结果