1、计算机网络的各层协议及作用？

简要概括（自下而上）

• 物理层：底层数据传输，如网线；网卡标准。
• 数据链路层：定义数据的基本格式，负责数据的封帧和差错检测；如网卡 MAC 地址。
• 网络层：定义 IP 编址，定义路由功能；如不同设备的数据转发。
• 传输层：负责端到端传输数据的基本功能；如 TCP、UDP。
• 会话层：负责建立、管理和终止表示层实体之间的通信会话，控制应用程序之间会话能力；如不同软件数据分发给不同软件。
• 表示层：数据格式标识，基本压缩加密功能。
• 应用层：负责给应用程序提供统⼀的接口。

说明：

• 在四层，既传输层数据被称作段（Segments）；
• 三层网络层数据被称做包（Packages）；
• 二层数据链路层时数据被称为帧（Frames）；
• 一层物理层时数据被称为比特流（Bits）。

总结

• 网络七层模型是一个标准，而非实现。
• 网络四层模型是一个实现的应用模型。
• 网络四层模型由七层模型简化合并而来。

  2、为什么需要三次握手？两次不行？

  （1）三次握手

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

因此，需要三次握手才能确认双方的接收与发送能力是否正常。
刚开始客户端处于 closed 的状态，服务端处于 listen 状态。然后

1. 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_Send 状态。
2. 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

3、第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 established 状态。
4、服务器收到 ACK 报文之后，也处于 established 状态，此时，双方以建立起了链接

（2）三次握手的作用

1. 确认双方的接受能力、发送能力是否正常；

2. 指定自己的初始化序列号，为后面的可靠传送做准备；

   （3）ISN是固定的吗

   三次握手的一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。
   如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

   （4）什么是半连接队列

   服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下「请求」连接放在一个队列里，我们把这种队列称之为「半连接队列」。
   当然还有一个「全连接队列」，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
   这里在补充一点关于 SYN-ACK 重传次数 的问题： 服务器发送完 SYN－ACK 包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s。

   （5）三次握手过程中可以携带数据吗

   很多人可能会认为三次握手都不能携带数据，其实第三次握手的时候，是可以携带数据的。也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。
   为什么这样呢？大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。
   而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据页没啥毛病。

   （6）什么是 syn - Flood 攻击

   攻击方通过频繁的切换 ip 或者利用大量的 ip 向服务器发起大量的半连接请求，每次连接都只完成第二次握手，从而让服务器频繁的重发连接确认，大量的半连接信息将消耗服务器大量的系统资源和网络带宽。
   解决办法：缩短超时（SYN Timeout）时间、增加最大半连接数、过滤网关防护 。

   （7）如果已经建立了连接，但是客户端突然出现故障了怎么办？

   TCP还设有一个保活计时器。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

   3、为什么需要四次挥手？三次不行？

   刚开始双方都处于 establised 状态，假如是客户端先发起关闭请求，则：

3. 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT_1 状态。

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

这里特别需要主要的就是 TIME_WAIT 这个状态了，这个是面试的高频考点，就是要理解，

（1）为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。

这其中的原因就是，要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文，则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。
这里我给出每个状态所包含的含义，有兴趣的可以看看。

• LISTEN – 侦听来自远方 TCP 端口的连接请求；
• SYN-SENT - 在发送连接请求后等待匹配的连接请求；
• SYN-RECEIVED – 在收到和发送一个连接请求后等待对连接请求的确认；
• ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
• FIN-WAIT-1 – 等待远程 TCP 的连接中断请求，或先前的连接中断请求的确认；
• FIN-WAIT-2 – 从远程 TCP 等待连接中断请求；
• CLOSE-WAIT – 等待从本地用户发来的连接中断请求；
• CLOSING - 等待远程 TCP 对连接中断的确认；
• LAST-ACK – 等待原来发向远程 TCP 的连接中断请求的确认；
• TIME-WAIT - 等待足够的时间以确保远程 TCP 接收到连接中断请求的确认；
• CLOSED – 没有任何连接状态；

  追问1：为什么连接的时候是三次握手，关闭的时候却是四次握手？

  假设只有三次挥手，也就是说服务端在发送完数据就向客户端发送一个带有 FIN 信号的报文，之后服务端彻底关闭连接，但是如果这个 FIN 报文丢失了，客户端没有收到这个报文， 客户端就会以为服务端仍有数据要发送，不会关闭连接。所以我们需要第四次挥手，让客户端收到 FIN 报文后发送一个确认报文，确认自己收到了关闭的信号，这样服务端在收到这个报文后就可以彻底关闭连接了。

  4、TCP 与 UDP 有哪些区别？各自应用场景？

  （1）TCP 协议的主要特点

1. TCP 是面向连接的运输层协议；所谓面向连接就是双方传输数据之前，必须先建立一条通道，例如三次握手就是建立通道的一个过程，而四次挥手则是结束销毁通道的一个其中过程。
2. 每一条 TCP 连接只能有两个端点（即两个套接字），只能是点对点的；
3. TCP 提供可靠的传输服务。传送的数据无差错、不丢失、不重复、按序到达；
4. TCP 提供全双工通信。允许通信双方的应用进程在任何时候都可以发送数据，因为两端都设有发送缓存和接受缓存；

5. 面向字节流。虽然应用程序与 TCP 交互是一次一个大小不等的数据块，但 TCP 把这些数据看成一连串无结构的字节流，它不保证接收方收到的数据块和发送方发送的数据块具有对应大小关系，例如，发送方应用程序交给发送方的 TCP10 个数据块，但就受访的 TCP 可能只用了 4 个数据块久保收到的字节流交付给上层的应用程序，但字节流完全一样。

   （2）TCP 的可靠性原理

   可靠传输有如下两个特点:

6. 传输信道无差错，保证传输数据正确；

7. 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据；

• 首先，采用三次握手来建立 TCP 连接，四次挥手来释放 TCP 连接，从而保证建立的传输信道是可靠的。
• 其次，TCP 采用了连续 ARQ 协议（回退 N，Go-back-N；超时自动重传）来保证数据传输的正确性，使用滑动窗口协议来保证接方能够及时处理所接收到的数据，进行流量控制。
• 最后，TCP 使用慢开始、拥塞避免、快重传和快恢复来进行拥塞控制，避免网络拥塞。

  （3）UDP 协议特点

1. UDP 是无连接的传输层协议；
2. UDP 使用尽最大努力交付，不保证可靠交付；
3. UDP 是面向报文的，对应用层交下来的报文，不合并，不拆分，保留原报文的边界；
4. UDP 没有拥塞控制，因此即使网络出现拥塞也不会降低发送速率；
5. UDP 支持一对一，一对多，多对多的交互通信；

6. UDP 的首部开销小，只有８字节．

   （4）TCP 和 UDP 的区别

7. TCP 是可靠传输，UDP 是不可靠传输；

8. TCP 面向连接，UDP 无连接；
9. TCP 传输数据有序，UDP 不保证数据的有序性；
10. TCP 不保存数据边界，UDP 保留数据边界；
11. TCP 传输速度相对 UDP 较慢；
12. TCP 有流量控制和拥塞控制，UDP 没有；
13. TCP 是重量级协议，UDP 是轻量级协议；

14. TCP 首部较长20字节，UDP 首部较短８字节；

    （5）基于 TCP 和 UDP 的常用协议

    HTTP、HTTPS、FTP、TELNET、SMTP(简单邮件传输协议) 协议基于可靠的 TCP 协议。
    TFTP、DNS、DHCP、TFTP、SNMP(简单网络管理协议)、RIP 基于不可靠的 UDP 协议

    （6）TCP 和 UDP 应用场景

    TCP 应用场景：
    效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有 UDP 高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
    UDP 应用场景：
    效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ 聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）

    5、TCP协议如何保证可靠性？

    TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现了可靠性传输。

15. 检验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。

16. 序列号/确认应答：序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
17. 滑动窗口：滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
18. 超时重传：超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。
19. 拥塞控制：在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。

20. 流量控制：如果主机A 一直向主机B发送数据，不考虑主机B的接受能力，则可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。

    详细讲一下TCP的滑动窗口？

    在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。
    从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组，滑动窗口右边是还没有轮到的分组。滑动窗口里面也分为两块，一块是已经发送但是未被确认的分组，另一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没到的分组进入窗口内。
    可以看到滑动窗口起到了一个限流的作用，也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率，而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。

    详细讲一下拥塞控制？

    面试题——TCP的拥塞控制
    TCP 一共使用了四种算法来实现拥塞控制：

21. 慢开始 (slow-start)；

22. 拥塞避免 (congestion avoidance)；
23. 快速重传 (fast retransmit)；
24. 快速恢复 (fast recovery)。

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。当cwndssthresh时，改用拥塞避免算法。
慢开始：不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小。
拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。
快重传：在 TCP 传输过程中，如果发生了丢包，接收端就会发送之前重复 ACK，比如 第 5 个包丢了，6、7 达到，然后接收端会为 5，6，7 都发送第四个包的 ACK，这个时候发送端受到了 3 个重复的 ACK，意识到丢包了，就会马上进行重传，而不用等到超时重传的时间
快恢复：主要是配合快重传。当发送方连续收到三个重复确认时,会将拥塞阈值降低为拥塞窗口的一半，然后拥塞窗口大小变为拥塞阈值，接着拥塞窗口再进行线性增加，以适应网络状况。

6、HTTP1.0，1.1，2.0，3.0 的版本区别

HTTP/1.0

HTTP/1.0 规定浏览器与服务器只保持「短暂的连接」，浏览器的每次请求都需要与服务器建立一个 TCP 连接，服务器完成请求处理后立即断开 TCP 连接，如果还要请求其他资源，就必须再新建一个连接。
这种方式就好像我们打电话的时候，只能说一件事儿一样，说完之后就要挂断，想要说另外一件事儿的时候就要重新拨打电话。
我们知道 TCP 连接的建立需要三次握手，是很耗费时间的一个过程。所以，HTTP/1.0 版本的性能比较差。HTTP1.0 其实也可以强制开启长链接，例如接受「Connection: keep-alive」这个字段，但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

HTTP/1.1

相比较于 HTTP/1.0 来说，最主要的改进就是引入了「持久连接」。所谓的持久连接即 TCP 连接默认不关闭，可以被多个请求复用。客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。或者客户端在最后一个请求时，主动告诉服务端要关闭连接。
由于之前打一次电话只能说一件事儿，效率很低。后来人们提出一种想法，就是电话打完之后，先不直接挂断，而是持续一小段时间，这一小段时间内，如果还有事情沟通可以再次进行沟通。
HTTP/1.1 版还引入了管道机制（pipelining），即在同一个 TCP 连接里面，客户端可以同时发送多个请求。这样就进一步改进了 HTTP 协议的效率。有了持久连接和管道，大大的提升了 HTTP 的效率。但是服务端还是顺序执行的，效率还有提升的空间。

HTTP/2

HTTP/2 为了解决 HTTP/1.1 中仍然存在的效率问题，HTTP/2 采用了「多路复用」。即在一个连接里，客户端和浏览器都可以同时发送「多个请求或回应」，而且「不用按照顺序一一对应」。
能这样做有一个前提，就是 HTTP/2 进行了「二进制分帧」，即 HTTP/2 会将所有传输的信息「分割为更小的消息和帧」, 并对它们采用二进制格式的编码。
也就是说，老板可以同时下达多个命令，员工也可以收到了 A 请求和 B 请求，于是先回应 A 请求，结果发现处理过程非常耗时，于是就发送 A 请求已经处理好的部分， 接着回应 B 请求，完成后，再发送 A 请求剩下的部分。A 请求的两部分响应在组合到一起发给老板。而这个负责拆分、组装请求和二进制帧的一层就叫做二进制分帧层。
除此之外，还有一些其他的优化，比如做 Header 压缩、服务端推送等。
Header 压缩 就是压缩老板和员工之间的对话。
服务端推送 就是员工事先把一些老板可能询问的事情提现发送到老板的手机（缓存）上。这样老板想要知道的时候就可以直接读取短信（缓存）了。

HTTP1.0 和 HTTP1.1 的区别?

• 长连接：HTTP 1.1支持长连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启 Connection： keep-alive ，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
• 缓存处理：在HTTP1.0中主要使用 header 里的 If-Modified-Since ，Expires 来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略，可供选择的缓存头来控制缓存策略。
• 带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
• 错误通知的管理：在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

• Host头处理：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

  HTTP1.1和 HTTP2.0的区别？

• 新的二进制格式：HTTP1.1的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。

• 多路复用：即连接共享，即每一个request都是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据 request 的 id 将request再归属到各自不同的服务端请求里面。
• 头部压缩，HTTP1.1 的头部（header）带有大量信息，而且每次都要重复发送；HTTP2.0 使用 encoder 来减少需要传输的 header 大小，通讯双方各自 cache 一份 header fields表，既避免了重复 header 的传输，又减小了需要传输的大小。
• 服务端推送：服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求。

  HTTP 3.0

  HTTP 是 HyperText Transfer Protocol（超文本传输协议）的缩写，它是互联网上应用最为广泛的一种网络协议，所有 WWW 文件都必须遵守这个标准。其他的话就不多说了，我们直接进入正题。
  HTTP1.0版本：
  HTTP1.0版本存在一些问题，比如说连接无法复用的问题，这会导致每发送一次请求都需要进行三次握手的过程，重新建立连接，效率太低。还有就是阻塞问题，http1.0是下一个请求的发送必须要等到上一个请求返回后才会进行，如果上一个请求没有返回，那么后面的请求就会全部阻塞。最后就是安全问题，http1.0所传输的内容都是明文的，无法保证数据的安全性。
  HTTP2.0版本：
  HTTP2.0版本比较专注于性能，它采用二进制格式传输数据，http2.0也采用了多路复用的技术，它可以只通过一个 TCP 连接传输所有的请求数据。还有就是采用了头部压缩技术，这也成功解决了http1.0的header 里携带的内容过大的问题，在一定程度上减轻了传输的成本。不过它也存在一定的问题，如果在传输的过程中存在丢包的情况的话，那么整个tcp就得重新传输，后面资源就会被阻塞。
  HTTP3.0版本：
  它最大的不同是放弃了tcp协议而是改用了 QUIC协议，此协议基于传输层UDP协议。UDP协议无需三次握手四次挥手，所以传输速率更高。并且它改善了多路复用产生的问题，如果出现丢包的情况，不需要整个重新发送，只需要重发丢掉的包就可以。

  7、HTTP 与 HTTPS 的区别？

  | | HTTP | HTTPS | | —- | —- | —- | | 端口 | 80 | 443 | | 安全性 | 无加密机制，安全性较差 | 有加密机制，安全性较高 | | 资源消耗 | 资源消耗较少 | 由于加密处理，资源消耗较多 | | 是否需要证书 | 不需要 | 需要 | | 协议 | 运行在TCP协议之上 | 运行在SSL协议之上，SSL运行在TCP协议之上 |

8、HTTPS 的优缺点?

优点

• 安全性：HTTPS协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
• SEO方面：谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

缺点

• 在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
• HTTPS 的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
• 在现有的证书机制下，中间人攻击依然有可能发生。
• HTTPS 需要更多的服务器资源，也会导致成本的升高。

  9、讲一讲HTTPS 的原理？ （工作流程）

  
  加密流程按图中的序号分为：

1. 客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。
2. 采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
3. 服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。
4. 客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。
5. 客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
6. 服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
7. 服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。

8. 双方使用对称加密愉快地传输所有数据。

   10、在浏览器中输入www.baidu.com后执行的全部过程？

9. 域名解析（域名 www.baidu.com 变为 ip 地址）。浏览器搜索自己的DNS缓存（维护一张域名与IP的对应表）；若没有，则搜索操作系统的DNS缓存（维护一张域名与IP的对应表）；若没有，则搜索操作系统的hosts文件（维护一张域名与IP的对应表）。若都没有，则找 tcp/ip 参数中设置的首选 dns 服务器，即本地 dns 服务器（递归查询），本地域名服务器查询自己的dns缓存，如果没有，则进行迭代查询。将本地dns服务器将IP返回给操作系统，同时缓存IP。

10. 发起 tcp 的三次握手，建立 tcp 连接。浏览器会以一个随机端口（1024-65535）向服务端的 web程序 80 端口发起 tcp 的连接。
11. 建立 tcp 连接后发起 http 请求。
12. 服务器响应 http 请求，客户端得到 html 代码。服务器 web 应用程序收到 http 请求后，就开始处理请求，处理之后就返回给浏览器 html 文件。
13. 浏览器解析 html 代码，并请求 html 中的资源。
14. 浏览器对页面进行渲染，并呈现给用户。

    11、POST 和 GET 有哪些区别？各自应用场景？

    GET 用于获取资源，而 POST 用于传输实体主体。

    先说明下安全和幂等的概念：
    在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
    所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

那么很明显 GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全
的，且每次的结果都是相同的。
POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

12、HTTP 哪些常用的状态码及使用场景？

常见状态码

13、HTTP 状态码 301 和 302 的区别，都有哪些用途？

301 重定向的概念

301 重定向（301 Move Permanently），指页面永久性转移，表示为资源或页面永久性地转移到了另一个位置。

哪些情况需要做 301 重定向？

网页开发过程中，时常会遇到网站目录结构的调整，将页面转移到一个新地址；网页扩展名的改变，这些变化都会导致网页地址发生改变，此时用户收藏夹和搜索引擎数据库中的旧地址是一个错误的地址，访问之后会出现 404 页面，直接导致网站流量的损失。或者是我们需要多个域名跳转至同一个域名，例如本站主站点域名为 www.conimi.com ，而还有一个域名 www.nico.cc，由于对该域名设置了 301 重定向，当输入 www.nico.cc 时，自动跳转至 www.conimi.com 。

301 重定向有什么优点？

有利于网站首选域的确定，对于同一资源页面多条路径的 301 重定向有助于 URL 权重的集中。例如 www.conimi.com 和 conimi.com 是两个不同的域名，但是指向的内容完全相同，搜索引擎会对两个域名收录情况不同，这样导致网站权重和排名被分散；对 conimi.com 做 301 重定向跳转至 www.conimi.com 后，权重和排名集中到 www.conimi.com，从而提升自然排名。

302 重定向又是什么鬼？

302 重定向（302 Move Temporarily），指页面暂时性转移，表示资源或页面暂时转移到另一个位置，常被用作网址劫持，容易导致网站降权，严重时网站会被封掉，不推荐使用。

301 与 302 的区别

302 重定向是页面暂时性转移，搜索引擎会抓取新的内容而保存旧的网址并认为新的网址只是暂时的。

14、在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？

在 HTTP 中响应体的 Connection 字段指定为 keep-alive
connetion:keep-alive;

15、HTTP 如何实现长连接？在什么时候会超时？

通过在头部（请求和响应头）设置 Connection: keep-alive，HTTP1.0 协议支持，但是默认关闭，从 HTTP1.1 协议以后，连接默认都是长连接。

• HTTP 一般会有 httpd 守护进程，里面可以设置 keep-alive timeout，当 tcp 链接闲置超过这个时间就会关闭，也可以在 HTTP 的 header 里面设置超时时间
• TCP 的 keep-alive 包含三个参数，支持在系统内核的 net.ipv4 里面设置：当 TCP 链接之后，闲置了 tcp_keepalive_time，则会发生侦测包，如果没有收到对方的 ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了 tcp_keepalive_probes，就会丢弃该链接。
  • tcp_keepalive_intvl = 15
  • tcp_keepalive_probes = 5
  • tcp_keepalive_time = 1800

实际上 HTTP 没有长短链接，只有 TCP 有，TCP 长连接可以复用一个 TCP 链接来发起多次 HTTP 请求，这样可以减少资源消耗，比如一次请求 HTML，可能还需要请求后续的 JS/CSS / 图片等.