HTTP 和 HTTPS 的基本概念

http: 是一个客户端和服务器端请求和应答的标准（TCP），用于从 WWW 服务器传输超文本到本地浏览器的超文本传输协议。

https:是以安全为目标的 HTTP 通道，即 HTTP 下 加入 SSL 层进行加密。其作用是：建立一个信息安全通道，来确保数据的传输，确保网站的真实性。

HTTP 和 HTTPS 的区别及优缺点？

• http 是超文本传输协议，信息是明文传输，HTTPS 协议要比 http 协议安全，https 是具有安全性的 ssl 加密传输协议，可防止数据在传输过程中被窃取、改变，确保数据的完整性(当然这种安全性并非绝对的，对于更深入的 Web 安全问题，此处暂且不表)。
• http 协议的默认端口为 80，https 的默认端口为 443。
• http 的连接很简单，是无状态的。https 握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20%的耗电。
• https 缓存不如 http 高效，会增加数据开销。
• Https 协议需要 ca 证书，费用较高，功能越强大的证书费用越高。
• SSL 证书需要绑定 IP，不能再同一个 IP 上绑定多个域名，IPV4 资源支持不了这种消耗。

HTTPS 协议的工作原理

客户端在使用 HTTPS 方式与 Web 服务器通信时有以下几个步骤：

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

HTTP 请求跨域问题

跨域的原理

跨域，是指浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的。 同源策略,是浏览器对 JavaScript 实施的安全限制，只要协议、域名、端口有任何一个不同，都被当作是不同的域。 跨域原理，即是通过各种方式，避开浏览器的安全限制。

解决方案

• JSONP：ajax 请求受同源策略影响，不允许进行跨域请求，而 script 标签 src 属性中的链 接却可以访问跨域的 js 脚本，利用这个特性，服务端不再返回 JSON 格式的数据，而是 返回一段调用某个函数的 js 代码，在 src 中进行了调用，这样实现了跨域。JSONP 的缺点: JSON 只支持 get，因为 script 标签只能使用 get 请求； JSONP 需要后端配合返回指定格式的数据。

• document.domain 基础域名相同 子域名不同

• window.name 利用在一个浏览器窗口内，载入所有的域名都是共享一个window.name

• CORS CORS(Cross-origin resource sharing)跨域资源共享 服务器设置对 CORS 的支持原理：服务器设置Access-Control-Allow-Origin HTTP 响应头之后，浏览器将会允许跨域请求

• proxy 代理 目前常用方式,通过服务器设置代理

• window.postMessage() 利用 h5 新特性 window.postMessage()

HTTP 1.1 和 HTTP 2.0 的区别

二进制协议：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 和 HTTPS 协议的区别

HTTP 和 HTTPS 协议的主要区别如下： HTTPS 协议需要 CA 证书，费用较高；而 HTTP 协议不需要； HTTP 协议是超文本传输协议，信息是明文传输的，HTTPS 则是具有安 全性的 SSL 加密传输协议； 使用不同的连接方式，端口也不同，HTTP 协议端口是 80，HTTPS 协 议端口是 443； HTTP 协议连接很简单，是无状态的；HTTPS 协议是有 SSL 和 HTTP 协 议构建的可进行加密传输、身份认证的网络协议，比 HTTP 更加安全。

GET 和 POST 的请求的区别

Post 和 Get 是 HTTP 请求的两种方法，其区别如下： 应用场景：GET 请求是一个幂等的请求，一般 Get 请求用于对服务 器资源不会产生影响的场景，比如说请求一个网页的资源。而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比 如注册用户这一类的操作。 是否缓存：因为两者应用场景不同，浏览器一般会对 Get 请求缓存， 但很少对 Post 请求缓存。

发送的报文格式：Get 请求的报文中实体部分为空，Post 请求的报 文中实体部分一般为向服务器发送的数据。 安全性：Get 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说是不太安全的，因为请求的 url 会 被保留在历史记录中。 请求长度：浏览器由于对 url 长度的限制，所以会影响 get 请求发 送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。 参数类型：post 的参数传递支持更多的数据类型。

常见的 HTTP 请求头和响应头

HTTP Request Header 常见的请求头：

• Accept:浏览器能够处理的内容类型
• Accept-Charset:浏览器能够显示的字符集
• Accept-Encoding：浏览器能够处理的压缩编码
• Accept-Language：浏览器当前设置的语言
• Connection：浏览器与服务器之间连接的类型
• Cookie：当前页面设置的任何 Cookie
• Host：发出请求的页面所在的域
• Referer：发出请求的页面的 URL
• User-Agent：浏览器的用户代理字符串

HTTP Responses Header 常见的响应头：

• Date：表示消息发送的时间，时间的描述格式由 rfc822 定义 server:服务器名称
• Connection：浏览器与服务器之间连接的类型
• Cache-Control：控制 HTTP 缓存 content-type:表示后面的文档属于什么 MIME 类型

常见的 Content-Type 属性值有以下四种：

1. application/x-www-form-urlencoded：浏览器的原生 form 表单 ， 如果不设置 contentype 属性 ， 那么最终就会以 application/x-www-form-urlencoded 方式提交数据。该种方式提交的数据放在 body 里面，数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。
2. multipart/form-data：该种方式也是一个常见的 POST 提交方 式，通常表单上传文件时使用该种方式。
3. application/json：服务器消息主体是序列化后的 JSON 字符串。
4. text/xml：该种方式主要用来提交 XML 格式的数据。

HTTP 状态码 304 是多好还是少好

状态码 304 不应该认为是一种错误，而是对客户端有缓存情况下服务端的一种响应。

搜索引擎蜘蛛会更加青睐内容源更新频繁的网站。通过特定时间内对网站抓取返回的状态码来调节对该网站的抓取频次。若网站在一定时间内一直处于 304 的状态，那么蜘蛛可能会降低对网站的抓取次数。相反，若网站变化的频率非常之快，每次抓取都能获取新内容，那么日积月累，的回访率也会提高。

产生过 304 的原因是 页面更新周期长或不更新

过多的 304 会造成 网站快照停止；收录减少；权重下降。

OPTIONS 请求方法及使用场景

• 获取服务器支持的所有 HTTP 请求方法；

• 用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

TCP 三次握手

1. 第一次握手：建立连接时，客户端发送 syn 包（syn=j）到服务器，并进入 SYN_SENT 状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
2. 第二次握手：服务器收到 syn 包并确认客户的 SYN（ack=j+1），同时也发送一个自己的 SYN 包（syn=k），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；
3. 第三次握手：客户端收到服务器的 SYN+ACK 包，向服务器发送确认包 ACK(ack=k+1），此包发送完毕，客户端和服务器进入 ESTABLISHED（TCP 连接成功）状态，完成三次握手。

为什么要三次握手

TCP 建立连接之前，需要确认客户端与服务器双方的收包和发包的能力。

1. 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

2. 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

3. 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

所以，只有三次握手才能确认双方的接收与发送能力是否正常。

淘宝二面三次握手、四次挥手

TCP 四次挥手

第一次挥手。客户端发起 FIN 包（FIN = 1）,客户端进入 FIN_WAIT_1 状态。TCP 规定，即使 FIN 包不携带数据，也要消耗一个序号。

第二次挥手。服务器端收到 FIN 包，发出确认包 ACK（ack = u + 1），并带上自己的序号 seq=v，服务器端进入了 CLOSE_WAIT 状态。这个时候客户端已经没有数据要发送了，不过服务器端有数据发送的话，客户端依然需要接收。客户端接收到服务器端发送的 ACK 后，进入了 FIN_WAIT_2 状态。

第三次挥手。服务器端数据发送完毕后，向客户端发送 FIN 包（seq=w ack=u+1），半连接状态下服务器可能又发送了一些数据，假设发送 seq 为 w。服务器此时进入了 LAST_ACK 状态。

第四次挥手。客户端收到服务器的 FIN 包后，发出确认包（ACK=1，ack=w+1），此时客户端就进入了 TIME_WAIT 状态。注意此时 TCP 连接还没有释放，必须经过 2*MSL 后，才进入 CLOSED 状态。而服务器端收到客户端的确认包 ACK 后就进入了 CLOSED 状态，可以看出服务器端结束 TCP 连接的时间要比客户端早一些。

为什么建立连接握手三次，关闭连接时需要是四次呢？

其实在 TCP 握手的时候，接收端发送 SYN+ACK 的包是将一个 ACK 和一个 SYN 合并到一个包中，所以减少了一次包的发送，三次完成握手。

对于四次挥手，因为 TCP 是全双工通信，在主动关闭方发送 FIN 包后，接收端可能还要发送数据，不能立即关闭服务器端到客户端的数据通道，所以也就不能将服务器端的 FIN 包与对客户端的 ACK 包合并发送，只能先确认 ACK，然后服务器待无需发送数据时再发送 FIN 包，所以四次挥手时必须是四次数据包的交互。

淘宝二面三次握手、四次挥手

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

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

（1）为了保证数据包的可靠传递，发送方必须把已发送的数据包保留在缓冲区；

（2）并为每个已发送的数据包启动一个超时定时器；

（3）如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可以是对本包后续包的应答），则释放该数据包占用的缓冲区;

（4）否则，重传该数据包，直到收到应答或重传次数超过规定的最大次数为止。

（5）接收方收到数据包后，先进行 CRC 校验，如果正确则把数据交给上层协议，然后给发送方发送一个累计应答包，表明该数据已收到，如果接收方正好也有数据要发给发送方，应答包也可方在数据包中捎带过去。

TCP 和 UDP 的区别

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

DNS 完整的查询过程

1. 首先会在浏览器的缓存中查找对应的 IP 地址，如果查找到直接返回；
2. 若找不到继续下一步 将请求发送给本地 DNS 服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，
3. 若找不到继续下一步 本地 DNS 服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址本地 DNS 服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，1️⃣ 如果有记录，就返回查询结果，2️⃣ 如果没有就返回相关的下一级的权威域名服务器的地址本地 DNS 服务器向权威域名服务器发送请求，域名服务器返回对应的 结果本地 DNS 服务器将返回结果保存在缓存中，便于下次使用本地 DNS 服务器将返回结果返回给浏览器

比如要查询 www.baidu.com 的 IP 地址

1. 首先会在浏览器的缓存中 查找是否有该域名的缓存，如果不存在就将请求发送到本地的 DNS 服务器中，本地 DNS 服务器会判断是否存在该域名的缓存，
2. 如果不存在，则向根域名服务器发送一个请求，根域名服务器返回负责 .com 的顶级域名服务器的 IP 地址的列表。
3. 然后本地 DNS 服务器再向其 中一个负责 .com 的顶级域名服务器发送一个请求，负责 .com 的顶 级域名服务器返回负责 .baidu 的权威域名服务器的 IP 地址列表。
4. 然后本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，
5. 最后权威域名服务器返回一个对应的主机名的 IP 地址列表。