我的校招记录：校招笔记（零）_写在前面，以下是校招笔记总目录。

		备注
算法能力（“刷题”）	这部分就是耗时间多练习，Leetcode-Top100 是很好的选择。	补充练习：codeTop
计算机基础(上)（“八股”）	校招笔记（一）__Java_Java入门	C++后端后续更新
	校招笔记（一）__Java_面对对象
	校招笔记（一）__Java_集合
	校招笔记（一）__Java_多线程
	校招笔记（一）__Java_锁
	校招笔记（一）__Java_JVM
计算机基础(下)（“八股”）	校招笔记（二）__计算机基础_Linux&Git
	校招笔记（三）__计算机基础_计算机网络
	校招笔记（四）__计算机基础_操作系统
	校招笔记（五）__计算机基础_MySQL
	校招笔记（六）__计算机基础_Redis
	校招笔记（七）__计算机基础_数据结构
	校招笔记（八）__计算机基础_场景&智力题
	校招笔记（九）__计算机基础_相关补充
项目&实习	主要是怎么准备项目，后续更新

三、计算机网络

3.1 ISO/OSI模型和 TCP/IP 模型

1.请你简要介绍一下TCP/IP 五层协议和 ISO/OSI七层协议？

应用层：为用户的应用程序（如：电子邮件、文件传输和仿真终端）*提供网络服务；
表示层：可以确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取；
会话层：通过运输层（端口号：传输端口与接收端口）建立数据传输的通路，主要在你的系统之间发起会话或者接受会话请求；
运输层: 任务是为两台主机中进程之间的通信提供通用的*数据传输服务，传输的是报文段（tcp）/用户数据报（udp）；

复用：多个应用层进程可同时使用下面运输层的服务。
分用：运输层把收到的信息分别交付上面应用层中的相应进程。
网络层：为主机间*提供通信服务。在发送数据时，网络层把运输层的报文段或用户数据报封装成分组或包进行传送。在TCP/IP体系中，由于网络层使用IP协议，因此分组也叫做IP数据报，或简称为数据报
数据链路层（忘）：两台主机通信，总是在一段一段的链路上传送的，这就需要需要专门的链路层的协议。在两个相邻结点之间传送数据时，数据链路层将网络层交下来的*IP数据报组装成帧，在两个相邻结点间的链路上传送帧。每一帧包括数据和必要的控制信息。
物理层：主要作用是传入比特流（就是由1、0转化为电流强弱来进行传输，到达目的地后再转化为1、0），定义物理设备标准（例如网线的接口类型、光线的接口类型、各种传输介质的传输速率）。

2.请你简要介绍一下各层的协议？

物理层：暂无
（快手）数据链路层：数据链路层主要是负责传输数据，
- PPP（点到点协议）：在点对点连接上传输多协议数据包提供了一个标准方法，PPP 最初设计是为两个对等节点之间的 IP 流量传输提供一种封装协议。这种链路提供全双工操作，并按照顺序传递数据包。
  
  设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据，使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案。
- 以太网（Ethernet)：
- CSMA/CD 协议：冲突检测的载波监听多路访问技术(载波监听多点接入/碰撞检测)。
  
  许多计算机以多点接入的方式连接在一根总线上，每个主机都必须不停地监听信道。发送前监听，如果忙则等待，如果空闲则发送。
  
  若检测到信道有干扰信号，则表示产生了碰撞，于是就要停止发送数据，计算出退避等待时间，然后使用 CSMA 方法继续尝试发送。
网络层：可参考

IP：网络协议，非常重要的中间层协议，TCP和UDP必须基于IP工作

ICMP：非常重要的中间层协议，用于在 IP主机、路由器之间传递控制消息

IGMP：网络组消息协议，用来在IP主机和与其直接相邻的组播路由器之间建立、维护组播组成员

ARP：地址解析协议，建立IP→MAC地址映射表

RARP：反向地址解析协议，某个网络设备的MAC物理地址转换为IP地址
运输层:TCP(Transmission Control Protocol) 面向连接的，数据传输的单位是报文段，能够提供可靠的交付。

UDP(User Datagram Protocol) ：无连接的，数据传输的单位是用户数据报，不保证提供可靠的交付，只能提供“尽最大努力交付”
应用层：如支持万维网应用的HTTP协议，支持电子邮件的SMTP协议，支持文件传送的FTP协议，DNS，POP3，SNMP，Telnet等等。

2.1 RARP 工作原理？

RARP发出要反向解释的物理地址并希望返回其IP地址，应答包括能够提供所需信息的RARP服务器发出的IP地址。

网络上的每台设备都会有一个独一无二的硬件地址，通常是由设备厂商分配的MAC地址。

主机从网卡上读取MAC地址，然后在网络上发送一个RARP请求的广播数据包；
RARP服务器收到了RARP请求数据包，为其分配IP地址，并将RARP回应发送给主机；
主机收到RARP回应后，就使用得到的IP地址进行通讯。

3. 端口在哪一层？有效端口范围？

端口在传输层。传输层以下的包封装过程：

数据报在传输层：加源端口号和目的端口号；
在网络层加上：源ip和目的ip ；
在数据链路层转化成：数据桢进行校验；
在物理层变成信号（电、光、等信号）发送出去。

UDP和TCP报头使用两个字节存放端口号，端口一共有一共有65535个。

知名端口号从0~1023，比如其中HTTP是80，FTP是20（数据端口）、21（控制端口）；
动态端口的范围是从1024~65535。

3.2 运输层

0. TCP报文头？UDP报文头？

参考：IP、TCP、UDP报文头说明

TCP报文头
- 来源端口：向目标主机指明接入他的主机所使用的端口号用于目标主机回应
- 目标端口：指明要连接的目标主机的端口号
  
  从这也可以看书，端口占16bit，故范围是0~65535。
- 顺序号：数据包编号，表明发送的数据包的顺序。其值通常应该为上次发送包中的顺序号+1 ，若该数据包是整个TCP连接中的第一个包(SYN包) 则该值随意(通常随机)
- 确认号：通常该值是接受到的顺序号+1 ，若该数据包是整个TCP连接中的第一个数据包(SYN包) 则该值随意(通常为0)
- 首部长度：TCP头长度。表明包好多少个32Bit 包括可选头(如果有) 值为TCP头大小除以4 ：
  - 如：没有可选头TCP头为20字节则该值为5
- 标志位：
- - 紧急标志位(URG)：开启时表明此数据包处于紧急状态应该优先处理
  - 确认标志位(ACK)：开启时表明确认号有效否则忽略确认号
  - 推送标志位(PSH)：开启时表明应该尽快交付给应用进程而不必等到缓存区填满才推送
  - 复位标志位(RST)：开启时表明TCP连接出现连接出现错误数据包非法拒绝连接
  - 同步标志位(SYN)：开启时表明一个连接的请求或者接受报文
  - 终止标志位(FIN)：开启时表明释放一个连接
- 窗口大小：表示期望接受到的每个数据包字节数
- 校验和：该值为TCP报文头括数据部分中每16Bit的二进制反码求和
- 紧急指针：若指定该值他应该是一个偏移量该值加上顺序号表示紧急数据最后一个字节的顺序号
- 可选字段：包含最大载荷与窗口比例等信息注：若使用该字段则长度必须为32Bit的倍数不足则填充0
UDP报文
- 来源端口：向目标主机指明接入他的主机所使用的端口号用于目标主机回应
- 目标端口：指明要连接的目标主机的端口号
- 数据包长度：UDP头和数据总长度字节数
- 检验和：该值为UDP报文头括数据部分中每16Bit的二进制反码求和
- - 注：UDP检验和不是必须的

1. 请你说明一下，TCP协议的3次握手（进行连接）？

参考：三次握手与四次挥手面试官想考我们什么？

TCP中，对确认ACK报文是不需要发送确认的。

简略过程

⚠️ SYN 和ACK报文是一起发的！！

1、第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN©。此时客户端处于 SYN_Send 状态。

2、第二次握手：（⚠️ SYN+ACK是在一个包里发的！（字节一面））服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

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

服务器收到 ACK 报文之后，也处于 establised 状态，此时，双方以建立起了链接。

1.1 ISN （Initial Sequence Number）是固定的吗？

ISN作用

三次握手，其中一个重要功能是客户端和服务端交换 ISN，以便让对方知道接下来接收数据的时候如何按序列号组装数据。
ISN为什么不固定（还是不太理解）

ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。
- 防止在网络中被延迟的分组在以后被重复传输，而导致某个连接的一端对它作错误的判断；
- 如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

2.为什么要三次握手？

1.用来确定服务端和客户端的发送能力是否正常；

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

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

如果只有两次握手，那么客户端的起始序列号可以确认，服务端的起始序列号将得不到确认。

如果是 https 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成。

2.1 三次握手可以携带数据吗？

第一次、第二次握手不可以携带数据， 第三次可以携带数据：

对于第一次握手，不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。
- 如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，消耗服务器空间来接收数据；
对于第三次握手，客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，已经知道服务器的接收、发送能力正常，所以能携带数据。

3.请你说明一下，TCP协议的4次挥手（断开连接）？

为什么不像三次握手一样执行三次即可？

因为第二次和第三次对于被动方来说，意义是不一样的。
第二次是为了让主动方闭嘴（不再发挥手请求），自己该干嘛还是干嘛（但是自己可能还有数据美处理完）。
第三次是为了表示“我的活儿干完了，可以结束了”。
通常server接收到挥手的时候，手里还有活儿没做完。

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。

收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。

（1）客户端A发送一个FIN，报文中会指定一个序列号M，用来关闭客户A到服务器B的数据传送，此时客户端处于FIN_WAIT1状态；

（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号M+1。和SYN一样，一个FIN将占用一个序号，此时服务端处于 CLOSE_WAIT状态；

（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A和序列号N，此时服务端处于 LAST_ACK 的状态；

（4）客户端A发回ACK报文确认，并将确认序号设置为收到序N+1，此时客户端处于 TIME_WAIT 状态，需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态；服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

3.1 为什么TCP四次挥手要基于全双工，不基于半双工呢？基于半双工可以改为三次挥手吗？

半双工：同时只能有一端发送消息；全双工：两端都可以随机接受/发送。

在四次挥手过程中，似乎C/S两端都是等待对方发送FIN/ACK，才会发送对应的ACK/FIN版本。同一时刻只有一方在发送消息，满足半双工。

但是，半双工模式效率会更低：比如C端（客户端）发送FIN报文请求关闭，但是S端（服务端）依旧可以同时发生数据 ，这个时候效率更高。

3.2（重点）服务器出现大量close_wait的连接的原因是什么？有什么解决方法？

close_wait状态是在，TCP四次挥手的时候服务器收到FIN，但是没有发送自己的FIN时出现的。服务器出现大量close_wait状态的原因有两种：

服务器内部业务处理占用了过多时间，都没能处理完业务；或者还有数据需要发送；或者服务器的业务逻辑有问题，没有执行close()方法
服务器的父进程派生出子进程，子进程继承了socket，收到FIN的时候子进程处理但父进程没有处理该信号，导致socket的引用不为0无法回收

处理方法：

停止应用程序
修改程序里的bug

4. 为什么要有TIME_WAIT 状态？为什么等待是2MSL？

要确保服务器是否已经收到了客户端最后的ACK 报文，如果没有收到的话，服务器会重新发 FIN + ACK报文给客户端，客户端再次收到 FIN + ACK 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。
确保之前连接的一些数据不在滞留在网络中：确保已经失效连接请求报文段不会再出现在本连接中，客户端发完最后一个ACK报文段后，再经过2MSL可以使得本连接中所有的报文段都从网络中消失。客户端就可以放心地释放TCP占用的资源、端口号，连接任何服务器。

如果客户端直接CLOSED，然后又再次向服务器发起一个新连接，有可能新、老连接的端口号一样的。假设新、老连接端口号一致，若老连接的一些数据仍滞留在网络中，这些滞留数据在新连接建立后才到达服务器，鉴于前后端口号一致，TCP协议就默认这些数据属于新连接，于是数据就这样乱成一锅粥了。

4.1 为什么是2MSL?

MSL是报文在网络中最长生存时间，这是一个工程值(经验值)，不同的系统中可能不同。

考虑最坏情况，客户端A最后一次挥手发送给服务端B的ACK报文丢失了：

ACK从最多经过1MSL会到达服务端，超过1MSL服务端会重发FIN
服务端重发的FIN最多经过1MSL到达A

所以为了确保，客户端能接收到服务端重发的FIN报文。

5. 【重点】请问TCP为什么要更可靠？哪种场景会有所应用？

超时重传：当 TCP 发出⼀个报文段后，它启动⼀个定时器，等待⽬的端确认收到这个报⽂段。如果不能及时收到⼀个确认，将重发这个报⽂段；
数据排序：TCP有专门的序列号ISN字段，可提供数据re-order；
流量控制：滑动窗口和计时器的使用。TCP窗口中会指明双方能够发送接收的最大数据量；

ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完⼀个分组就停⽌发送，等待对方确认。在收到确认后再发下⼀个分组。
拥塞控制：TCP的拥塞控制由4个核心算法组成。“慢启动”（Slow Start）、“拥塞避免”（Congestion avoidance）、“快重传 ”（Fast Retransmit）、“快恢复”（Fast Recovery）；
校验和： TCP 将保持它⾸部和数据的检验和。这是⼀个端到端的检验和，⽬的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报⽂段和不确认收到此报⽂段。

【应用场景】

当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用

比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议

5.1 超时重传机制原理？

基本原理：在发送一个数据之后，就开启一个定时器，若是在这个时间内没有收到发送数据的ACK确认报文，则对该报文进行重传，在达到一定次数还没有成功时放弃并发送一个复位信号。

TCP中有四种计时器（Timer），分别为：

重传计时器：在滑动窗口协议中，接受窗口会在连续收到的包序列（连续ARQ）中的最后一个包向接收端发送一个ACK。当网络拥堵的时候，发送端的数据包和接收端的ACK包都有可能丢失。TCP为了保证数据可靠传输，就规定在重传的“时间片”到了以后，如果还没有收到对方的ACK，就重发此包，以避免陷入无限等待中。
坚持计时器：在滑动窗口协议中，当发送TCP收到窗口大小为0的确认ACK时，就坚持启动计时器。当坚持计时器期限到时，发送TCP就发送一个特殊的报文段，叫做探测报文。这个报文段只有一个字节的数据。他有一个序号，但他的序号永远不需要确认；甚至在计算机对其他部分的数据的确认时该序号也被忽略。探测报文段提醒接受TCP：确认已丢失，必须重传。
保活计时器：保活计时器使用在某些实现中，用来防止在两个TCP之间的连接出现长时间的空闲。假定客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远的处于打开状态。

通常设置为两小时。若服务器过了两小时还没有收到客户的信息，他就发送探测报文段。若发送了10个探测报文段（每一个像个75秒）还没有响应，就假定客户除了故障，因而就终止了该连接。
时间等待计时器：四次挥收后time waiter状态中使用。

5.2 介绍一下ARQ协议？

⾃动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之⼀。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后⼀段时间之内没有收到确认帧，它通常会重新发送。

ARQ包括停⽌等待ARQ协议和连续ARQ协议。

停⽌等待ARQ协议。停⽌等待协议是为了实现可靠传输的，它的基本原理就是每发完⼀个分组就停⽌发送，等待对方确认（回复ACK）。如果过了⼀段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下⼀个分组；在停⽌等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。
- 优点：简单
- 缺点：信道利用低，等待时间长
连续ARQ协议。连续 ARQ 协议可提高信道利用率。发送方维持⼀个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方⼀般采用累计确认，对按序到达的最后⼀个分组发送确认，表明到这个分组为⽌的所有分组都已经正确收到了。
- 优点：信道利用率高，容易实现，即使确认丢失，也不必重传。
- 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。⽐如：发送方发送了 5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传⼀次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的N 个消息。

5.2 介绍一下连续ARQ协议滑动窗口和流量控制？

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报⽂中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

5.3 介绍一下拥塞控制？

为了进行拥塞控制，TCP 发送方要维持⼀个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让⾃⼰的发送窗口 == 取为拥塞窗口和接收方的接受窗口中较小的⼀个。

TCP的拥塞控制采用了四种算法：

慢开始：慢开始算法的思路是当主机开始发送数据时，如果⽴即把大量数据字节注⼊到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测⼀下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过⼀个传播轮次RTT，cwnd加倍；
拥塞避免：拥塞避免算法的思路是让拥塞窗⼝cwnd缓慢增大，即每经过⼀个往返时间RTT，就把发送放的cwnd加1；
快重传/快恢复：

区分快重传，连续ARQ中间丢失是Go back n。

在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是⼀种拥塞控制算法，它能快速恢复丢失的数据包。如果接收机接收到⼀个【不按顺序】的数据段，它会⽴即给发送机发送⼀个重复确认（而不是等到自己发送数据时才捎带确认）。如果发送机接收到三个重复确认，它会假定确认指出的数据段丢失了，并⽴即重传这些丢失的数据段（而不必继续等待为该报文段设置的重传计时器的超时）。

5.4 如何区分流量控制和拥塞控制？

流量控制属于通信双方协商，拥塞控制涉及通信链路全局；
流量控制需要通信双方各维护一个发送窗、一个接收窗，对任意一方，接收窗大小由自身决定，发送窗大小由接收方响应的TCP报文段中窗口值确定；拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。

6.如何提高客户端并发数？

客户端建立的tcp数量受限于最大文件句柄数，一个连接就会建一个文件句柄，在linux 上默认是1024。

使用ulimit 可以修改最大进程数（最大为65535）

7.说说HTTP、TCP、Socket 的关系是什么？

TCP/IP 代表传输控制协议/网际协议，指的是一系列协议族；
HTTP 本身就是一个协议，是从 Web 服务器和本地浏览器的超文本传送协议；
Socket 是 TCP/IP 网络的 API ，其实就是一个门面模式，它把复杂的 TCP/IP 协议族隐藏在Socket 接口后面。对用户来说，一组简单的接口就是全部，让 Socket 去组织数据，以符合指定的协议。

8. 什么是半连接队列？泛洪攻击（DDos攻击的一种），以及解决策略？

半连接队列

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
泛洪攻击

在 TCP 的三次握手机制的第一步中，客户端会向服务器发送 SYN 报文段。
1. 服务器接收到 SYN 报文段后会为该 TCP分配缓存和变量，如果攻击分子伪造大量不存在的IP地址，大量地往服务器发送 SYN 报文段，服务器的连接资源终将被耗尽，导致内存溢出无法继续服务。
2. 当服务端接收到 SYN 后进入 SYN-RECV 状态，此时的连接称为半连接，同时会被服务端写入一个半连接队列。
  想象一下，如果攻击者在短时间内不断的向服务端发送大量的 SYN 包而不响应，那么服务器的半连接队列很快会被写满，从而导致无法工作。
解决策略

设置验证机制：当服务器接受到 SYN 报文段时，不直接为该 TCP 分配资源，而只是打开一个半开的套接字。接着会使用 SYN 报文段的源 Id，目的 Id，端口号以及只有服务器自己知道的一个秘密函数生成一个 cookie，并把 cookie作为序列号响应 给客户端。

如果客户端是正常建立连接，将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源 Id，目的 Id，端口号以及秘密函数计算出一个结果，如果结果的值 + 1 等于确认字段的值，则证明是刚刚请求连接的客户端，这时候才为该 TCP 分配资源。

防火墙过滤：暂不了解具体

9.为什么DNS（域名解析）用UDP，而区域传送用TCP?

DNS用UDP：客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。
区域传送用TCP： TCP协议可靠性好，TCP协议传输的内容大，而UDP最大只能传512字节。

10.说一下 TCP 粘包是怎么产生的？怎么解决粘包？

TCP粘包

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

客户端要发送原信息是A和B两个数据包，服务端接收到之后，可能出现如下情况：

正常情况：读取到了A和B两个数据包；
粘包：A和B两个数据包一起读取了；
拆包：读取了A数据包的一部分，A的另一部分和B数据包一起读取了。

TCP粘包原因

【发送方】TCP默认使用Nagle算法。客户端通过socket给服务端发送数据，为了传输更有效率，会将多次间隔较小的且数据量小的数据，通过nagle算法，合并成一个大的数据块，然后进行封包。这样做提高了效率，缺点就是你发送到服务端的数据，服务端不知道是不是完整的，不知道哪几小块数据拼起来才是原来的数据；
【接收方】来不及接收缓存区的包，导致多个包接收；
TCP连接复用造成的粘包问题；
流量控制，拥塞控制也可能导致粘包。

解决粘包

解决问题的关键在于如何给每个数据包添加边界信息：

Nagle算法问题导致的，需要结合应用场景适当关闭该算法；
发送端给每个数据包添加包首部 ，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了；
数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开；
发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。

11. TCP, UDP的区别？

UDP 在传送数据之前不需要先建立连接。远地主机在收到 UDP 报⽂后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下 UDP 确是⼀种最有效的⼯作方式（⼀般用于即时通信）
- ⽐如： QQ 语⾳、 QQ 视频、直播等等
TCP 提供面向连接的服务。在传送数据之前必须先建⽴连接，数据传送结束后要释放连接。 TCP 不提供⼴播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握⼿来建⽴连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这⼀难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的⾸部增大很多，还要占用许多处理机资源。
- TCP ⼀般用于⽂件传输、发送和接收邮件、远程登录等场景。
数据包： TCP是报文段，UDP是用户数据报。
应用场景 ： TCP用于一些需要可靠传输的场景； UDP则应用一些即时通信场景，不需要可靠传输的场景。
长度：UDP在DNS最长只能是512字节，TCP会更长。

3.3 网络层

1.请简单解释一下，ARP协议和ARP攻击?

ARP协议：地址解析协议，建立IP/MAC地址映射表
ARP攻击：

2.什么是ICMP协议，它的作用是什么？

用于在IP主机、路由器之间传递控制消息。

控制消息是指：网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。

3.请你讲一下路由器和交换机的区别？

动态IP：路由器可以给你的局域网自动分配IP，虚拟拨号，就像一个交通警察，指挥着你的电脑该往哪走，你自己不用操心那么多了。交换机只是用来分配网络数据的。

路由器可以把一个IP分配给很多个主机使用，这些主机对外只表现出一个IP。交换机可以把很多主机连起来，这些主机对外各有各的IP。
寻址方式：路由器在网络层，路由器根据IP地址寻址，路由器可以处理TCP/IP协议，交换机不可以；交换机在中继层，交换机根据MAC地址寻址。
防火墙：路由器提供防火墙的服务，交换机不能提供该功能。集线器、交换机都是做端口扩展的，就是扩大局域网(通常都是以太网)的接入点，也就是能让局域网可以连进来更多的电脑。路由器是用来做网间连接，也就是用来连接不同的网络。

4.请解释`ping`命令过程？

域名在DNS服务器查找IP地址；
通过Ping程序发送ICMP包；
同一网段的情况下，调用IP层的ARP协议请求广播（不同网段的情况下，交给路由器处理），查找目标主机的MAC地址；
目标主机ARP协议收到请求后，将本机MAC地址填充并发送ARP应答回到请求发送方；
请求发送方发送ICMP数据到目标主机；
目标主机响应ICMP包；
请求主机收到目标主机的ICMP响应包。

5. （补充介绍）介绍一下IPV6？一共多少位？

IPv6 协议基础_果子哥丶的博客-CSDN博客

源IP和目的IP地址都是，128（4*32）位（图中标识不清晰）！

6. 介绍一下IP地址分类？C类哪些是保留地址？网络号全 0 全 1 ，主机号全 0 全1 分别什么含义？

IP地址分类

IP地址 == {<网络号>，<主机号>}
- A类：第1位固定为0，网络号只有7位。0（0000 0000）的IP地址是保留地址，意思是“本网络” ； 127（0111 1111）的IP地址也是保留地址，作为本地环回软件测试。
  
  特别的，主机号全1的是广播地址，它代表了网络全部的主机。
- B类：第1、2位固定为10，网络号有14位可以使用。
  
  B类地址网络号为128.0（1000 000 0000 0000）的IP地址是不指派的，所以可指派的网络号需要减一。
- C类：第1、2、3位固定为110，网络号有21位可以使用。
  
  （快手问）C类IP地址包含私有C类地址，范围从192.0.0.0 到223.255.255.255，其中私有C类地址范围从192.168.0.0 到192.168.255.255。
全0或者全1的含义
- 网络号全0：（1）如果主机号也为全0，那么此类ip地址可以当源端但不可以做目的端（2）如果主机号不全为0，那么此类ip地址的使用和（1)相同，只是它代表的是网络上特定的主机
- 网络号全1：全1的网络号和任意的主机号组合当做回环地址来使用。
  
  例如：127（0111 1111）的IP地址
- 主机号全0： 全为0，所得到的地址就是192.168.100.0，它是一个网络地址，代表的是一个网段；
- 主机号全1： 机号全1 代表的是广播地址，广播地址是不可以做源端的，但是可以做目的端。

3.4 应用层

1.请你谈谈DNS的寻址过程？

（1）检查浏览器缓存、检查本地hosts文件：是否有这个网址的映射，如果有，就调用这个IP地址映射，解析完成。

（2）如果没有，则查找本地DNS解析器缓存：是否有这个网址的映射，如果有，返回映射，解析完成。

本地dns服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动等。

（3）如果没有，则查找填写或分配的首选DNS服务器：称为本地DNS服务器。服务器接收到查询时：

如果要查询的域名包含在本地配置区域资源中，返回解析结果，查询结束，此解析具有权威性。
如果要查询的域名不由本地DNS服务器区域解析，但服务器缓存了此网址的映射关系，返回解析结果，查询结束，此解析不具有权威性。

（4）如果本地DNS服务器也失效：

如果未采用转发模式（迭代，从上至下）（1）本地DNS服务器就把请求发至13台根DNS，根DNS服务器收到请求后，会判断这个域名（如.com）是谁来授权管理，并返回一个负责该顶级域名服务器的IP，（2）本地DNS服务器收到顶级域名服务器IP信息后，继续向该顶级域名服务器IP发送请求，（3）该服务器如果无法解析，则会找到负责这个域名的下一级DNS服务器（如http://baidu.com）的IP给本地DNS服务器，循环往复直至查询到映射，（4）将解析结果返回本地DNS服务器，再由本地DNS服务器返回解析结果，查询完成。
如果采用转发模式（递归，从下至上）（1）则此DNS服务器就会把请求转发至上一级DNS服务器，（2）如果上一级DNS服务器不能解析，则继续向上请求，（3）最终将解析结果依次返回本地DNS服务器，本地DNS服务器再返回给客户机，查询完成。

1.1 怎么获取13台根服务器？

ping -R ? 抓包？

1.2 解释一下DNS劫持和DNS污染？

参考：什么是http劫持 ?

一、DNS劫持

DNS劫持某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，返回给用户一个错误的查询结果。

劫持过程
1. 客户端发起域名请求到DNS解析服务器（一般是LocalDNS），但此时DNS解析服务器被攻击篡改；
2. 被攻击篡改后的DNS解析服务器将请求转发给虚假服务器；
  
  DNS查询没有任何认证机制且基于UDP不可靠连接，因此很容易被篡改。
3. 虚假服务器返回响应虚假信息给被攻击篡改后的DNS解析服务器（也可能直接不响应）；
解决办法

DNS劫持的本质是运营商的DNS解析服务器被攻击篡改
- 使用国外免费公用的DNS服务器解决。例如OpenDNS（208.67.222.222）或GoogleDNS（8.8.8.8）
- 直接使用ip进行访问

二、DNS污染

DNS污染是一种让一般用户由于得到虚假目标主机IP而不能与其通信的方法，是一种DNS缓存投毒攻击（DNS cache poisoning）。因为是不是劫持单个DNS服务器，而是监听所有的，所以个人比较难防范。

污染原理
1. 通过对UDP端口53上的DNS查询进行入侵检测；
  
  由于通常的DNS查询没有任何认证机制，而且DNS查询通常基于的UDP是无连接不可靠的协议，因此DNS的查询非常容易被篡改。
2. 一经发现与关键词相匹配的请求则立即伪装成目标域名的解析服务器（NS，Name Server）给查询者返回虚假结果。
解决办法
1. VPN代理或者域名远程解析的方法解决
2. 通过修改Hosts，手动设置域名正确的IP地址

2. Forward和Redirect的区别？

浏览器 URL 地址：Forward 是服务器内部的重定向，服务器内部请求某个 servlet，然后获取响应的内容，浏览器的 URL 地址不会变化；Redirect 是客户端请求服务器，然后服务器给客户端返回了一个302 状态码和新的 location，客户端重新发起 HTTP 请求，服务器给客户端响应 location 对应的 URL 地址，浏览器的 URL 地址发生了变化。
数据的共享：Forward 是服务器内部的重定向，request 在整个重定向过程中是不变的，request 中的信息在 servlet 间是共享的。Redirect 发起了两次 HTTP 请求分别使用不同的request。
请求的次数：Forward 只有一次请求；Redirect 有两次请求。

3.请你简单讲解一下，负载均衡反向代理模式的优点、缺点？

联系实际：正反向代理、科学上网、VPN之间的关系和翻墙基本原理（看他的其他文章补充）

【基本介绍】

反向代理（Reverse Proxy）：方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器；
- 优点：网络络外部用户不能直接访问真实的服务器，具备额外的安全性
- 缺点：反向代理是处于OSI参考模型第七层应用的，所以就必须为每一种应用服务专门开发一个反向代理服务器；限制了应用范围；
  
  针对每一次代理，代理服务器就必须打开两个连接，一个对外，一个对内，因此在并发连接请求数量非常大的时候，代理服务器的负载也就非常大了，在最后代理服务器本身会成为服务的瓶颈。
反向代理负载均衡技术：是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
- 实现：apache mod_proxy、netscape proxy等，也可以在高速缓存器、负载均衡器等硬件设备上实现。
- 优点：可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起，提升静态网页的访问速度，提供有益的性能
- 缺点：

3.1 请解释下负载均衡的相关算法？

不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。

给配置高、负载低的机器配置更高的权重，让其处理更多的请求；
给配置低、负载高的机器分配较低的权重，降低系统负载。

下面是几种比较相关的算法。

加权轮询算法

参考：加权轮询算法
- 基本定义
  1. 假设有 N 台实例 S = {S1, S2, …, Sn}，权重 W = {W1, W2, …, Wn}
  2. currentPos 表示当前选择的实例 ID，初始化为 -1；
  3. currentWeight 表示当前权重，初始值为 max(S)；
  4. max(S) 表示 N 台实例的最大权重值，gcd(S) 表示 N 台实例权重的最大公约数。
- 算法过程
  1. 从上一次调度实例起，遍历后面的每个实例；
  2. 若所有实例已被遍历过一次，则减小 currentWeight 为 currentWeight - gcd(S)，并从头开始遍历；若 currentWeight 小于等于 0，则重置为 max(S)；
  3. 直到遍历的实例的权重 >= currentWeight 时结束，此时实例为需调度的实例；
  4. 每次调度重复步骤 1、2、3；
- 算法实例
  
  例如，上述 4 个服务，最大权重 max(S) 为 4，最大公约数 gcd(S) 为 1。其调度过程如下：
- 算法优缺点
  - 优点：相比简单轮询方式，通过权重进行分配，更加均匀
  - 缺点：如下一个极端情况
    
    服务实例 S = {a, b, c}，权重 W = {5, 1, 1}，使用加权轮询调度生成的实例序列为 {a, a, a, a, a, b, c}，那么就会存在连续 5 个请求都被调度到实例 a。
    
    关于这点，可以采用平滑加权轮询调度算法。
一致性哈希算法

负载均衡算法中的哈希算法，就是根据某个值生成一个哈希值，然后对应到某台服务器上去，即哈希环。

但是可能出现一种，哈希倾斜的情况：A负责的区域太大，B，C负责的小。这个时候采用虚拟节点去解决，这里不表。

3.2 DNS 负载均衡是什么策略？

参考：

原理：还是不太明白，DNS递归查询本身就是个负载均衡策略吧？多台服务器满足同一个查询服务？

4.请说明一下http和https的区别？

https协议要申请证书到ca，需要一定经济成本；
http是明文传输，https是加密的安全传输；
（🚩*1）连接的端口不一样，http是80，https是443；
http连接很简单，没有状态；
https是ssl加密的传输，身份认证的网络协议，相对http明文传输比较安全。

4.1 讲一讲http的请求报文和响应报文？协议？

请求报文和协议

一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。
- 请求行 ：由请求方法字段、URL字段和HTTP协议版本字段3个字段组成。
  
  HTTP协议 : 的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
- 请求头部：请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息。
  
  User-Agent：产生请求的浏览器类型。
  
  Accept：客户端可识别的内容类型列表。
  
  Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。
- 请求数据 : 请求数据不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。
响应报文和协议

HTTP响应也由四个部分组成，分别是：状态行、响应头、空格、响应数据。
- 状态行 ：状态行（status line）通过提供一个状态码来说明所请求的资源情况。如404等

4.2 一个TCP连接中多个HTTP请求发生可以【同时】一起发生吗？

HTTP/1.1单个 TCP 连接在同一时刻只能处理一个请求。意思是说：两个请求的生命周期不能重叠，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 连接里不能重叠；
Pipelining 技术 & Multiplexing。 Pipelining 技术可以完成这个多个请求同时发送，但是由于浏览器默认关闭，所以可以认为这是不可行的。在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行；

那么在 HTTP/1.1 时代，浏览器是如何提高页面加载效率的呢？

维持和服务器已经建立的 TCP 连接，在同一连接上顺序处理多个请求；
和服务器建立多个 TCP 连接。

5.请说明一下http1.0 和https1.1 区别？

长连接
- HTTP1.0默认使用短连接，每次HTTP请求都需要建立新的TCP连接，连接不能复用；
- HTTP1.1支持持久连接和请求的流水线处理（但不是并发！！），在一个TCP连接上可以传送多个HTTP请求和响应，减少建立和关闭TCP连接的消耗和延迟，提高效率
host字段
- 在HTTP1.0中为每台服务器绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）
- HTTP1.1的请求消息和响应消息都应支持Host头域（补充：F12 抓包可以看到），且请求消息中如果没有Host头域，会报400 Bad Request错误
缓存处理
- HTTP1.1则引入了更多的缓存控制策略
带宽优化及网络连接的使用
- HTTP1.0中存在浪费带宽现象，例如：（1）客户端只需要某个对象的一部分，而服务器却将整个对象发送过来；(2) 下载大文件不支持断点续传功能，在发生断连后需要重新下载完整的包；
- HTTP1.1则在请求头中引入range头域，它允许只请求资源的某个部分(因此也支持断点重传)，即返回码是206；
新增一些错误通知状态码
- 如：409（Conflict）表示请求的资源与资源的当前状态发生冲突。

6.请说明一下http1.0 和https2.0 区别？

7.请讲一下浏览器从接收到一个URL，到最后展示出页面，经历了哪些过程？

在浏览器地址栏中输入URL；
DNS域名解析，获得域名相对应的IP地址（详见：应用层DNS寻址过程）；

浏览器首先会从（1）本地浏览器缓存、hosts文件是否存在相应的域名、IP对应关系，如果有则向这个IP地址发送请求，如果没有则向（2）本地DNS解析器缓存中查找，如果都没有，（3）再去DNS服务器中找IP。
浏览器向服务器发起TCP连接，与浏览器建立TCP三次握手；然后 向服务器发送HTTP请求，请求数据包

HTTP请求是由三部分组成：请求行、请求报头和请求正文。

与服务器建立了连接后，就可以向服务器发起请求了。发送HTTP请求的过程就是构建HTTP请求报文，并通过TCP协议发送到服务器指定端口（HTTP协议80/8080，HTTPS协议443）。
服务端（由web服务器）处理收到的请求

服务器端收到请求后，由web服务器（准确来说应该是HTTP服务器）处理请求，诸如Apache、Ngnix、IIS 。
服务器返回相应结果（响应报文）至浏览器
HTTP响应报文也是由三部分组成：状态码、响应报头和响应报文。

状态码是由三位数组成，第一个数字定义了响应的类别：
- 1XX：指示信息，表示请求已接受，继续处理；
- 2XX：成功，表示请求已被成功接收、理解、接受；
- 3XX：重定向，要完成请求必须进行更进一步的操作；
- 4XX：客户端错误，请求有语法错误或无法实现；
- 5XX：服务器端错误，服务器未能实现合法的请求。
四次挥手关闭TCP连接

四次挥手，当双方没有请求或响应传递时，任意一方都可以发起关闭请求。
浏览器解析渲染页面

浏览器在收到HTML、CSS、JS文件后，就需要进行渲染。

（1）浏览器解析HTML文件构建DOM树，（2）然后解析CSS文件构建渲染树，（3）等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上

8.请解释一下SSL工作过程（Https传输过程）？

https是http的扩展，在传输层使用了安全协议：安全套接字层SSL(Secure Socket Layer)。

参考：https://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

公钥通常用于加密会话密钥、验证数字签名，或加密可以用相应的私钥解密的数据。公钥和私钥是通过一种算法得到的一个密钥对(即一个公钥和一个私钥)。

通过这种算法得到的密钥对能保证在世界范围内是唯一的。

使用这个密钥对的时候,如果用其中一个密钥加密一段数据，必须用另一个密钥解密。

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

所以基本过程是：

（1）客户端向服务器端索要并验证公钥。

（2）双方协商生成"对话密钥"。

（3）双方采用"对话密钥"进行加密通信。

协商加密算法。客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求；

（1）支持的协议版本，比如TLS 1.0版。

（2）一个客户端生成的随机数，来生成"对话密钥"。

（3）支持的加密方法，比如RSA公钥加密。

（4）支持的压缩方法。
服务器回应。服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello；

（1）确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2）一个服务器生成的随机数，稍后用于生成"对话密钥"。

（3）确认使用的加密方法，比如RSA公钥加密。

（4）服务器证书。
客户端鉴别。客户端收到服务器回应以后，（1）首先验证服务器证书：如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

（2）如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息：

（1）一个随机数。该随机数用服务器公钥加密，防止被窃听。

（2）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
会话秘钥计算。服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"（使用3个随机数生成更安全）；

（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
安全数据传输。双方用会话秘钥加密和解密之间传送的数据。

8.1 公钥如何保证不被篡改？说一说证书。

将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。
服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。
进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过（证书不可信浏览器会提示），就可以开始通信了。

8.2 公钥加密计算量太大，如何减少耗用的时间？

每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于对话密钥是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。

8.3 为什么有的时候刷新页面不需要重新建立 SSL 连接？

TCP 连接有的时候会被浏览器和服务端维持一段时间，TCP 不需要重新建立，SSL 自然也会用之前的。

9. 介绍一下常见的几种非对称加密算法？优缺点？

非对称加密

非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。

公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。
常用非对称加密算法
- RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的
- DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）
- ECC（Elliptic Curves Cryptography）：椭圆曲线加密
非对称加密优缺点
- 优点：可以更安全地将公开密钥传输给通信发送方；
- 缺点：运算速度慢。

10.公钥加密–私钥解密与公钥解密–私钥加密有什么区别?

主要是应用场景不同。

加解密：公钥加密，私钥解密

不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密
签名：私钥签名，公钥验签

是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证
https可以只有非对称加密吗?

https验证证书阶段是非对称加密，但是在数据传输阶段是对称加密。https不可以只有非对称加密：
- 非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；
- 在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

11. HTTPS 为什么安全？为什么需要CA证书？只有认证机构可以生成证书吗？HTTPS 绝对安全吗？

安全：因为 HTTPS 保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性；
CA证书： HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题，所以需要CA证书
证书生成：如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的 HTTPS 传输。
不绝对安全：不是绝对安全的，可以通过中间人攻击。

CA证书不是可以解决“中间人”吗？

过程原理：
1. 本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器
2. 中间人服务器返回中间人自己的证书（但是这一步服务器不是会对服务器证书进行验证吗？）
3. 客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
4. 中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
5. 中间人以客户端的请求内容再向官方网站发起请求
6. 因为中间人与服务器的通信过程是合法的，官方网站通过建立的安全通道返回加密后的数据
7. 中间人凭借与官方网站建立的对称加密算法对内容进行解密
8. 中间人通过与客户端建立的对称加密算法对官方内容返回的数据进行加密传输
9. 客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

12. http应答码中的301/2/4、500、502、503、504状态码进行解释？

200： 请求成功。
500： 500 (服务器内部错误) 服务器遇到错误，无法完成请求。例如，服务器无法识别请求方法时可能会返回此代码。
501：服务器不支持请求的功能，无法完成请求
502： 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
503： 由于超载或系统维护，服务器暂时的无法处理客户端的请求。
504(及时)：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。

13.介绍一下http请求get、post等？

重点区分一下get和post：

get ：GET方法用于使用给定的URI从给定服务器中检索信息，即从指定资源中请求数据。
- GET请求是可以缓存的，浏览器历史记录中查找到GET请求；长度有限制；不安全，url会暴露请求的参数
post：POST方法用于将数据发送到服务器以创建或更新资源。
- POST请求不会被缓存；长度无限制；更安全
特别的：GET产生一个TCP数据包;POST产生两个TCP数据包。
- get：http header和body一并发送出去；
- post：浏览器先发送header，服务器响应100 continue，浏览器再发送body 。
  ⚠️ post是不一定会发生两个的。
  - HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包，而且实际测试(Chrome)发现，header 和 body 不会分开发送；
  - header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。

13.1 Get方法长度有限制是怎么回事？

HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器 / 服务器的原因。

服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制；
浏览器也会设置url有限。

13.2 POST 方法相比GET方法是绝对安全吗？

POST 比 GET 安全，因为数据在地址栏上不可见；
POST不是绝对安全，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。

想要安全，只有使用HTTPS。

14. HTTP是不保存状态的协议,如何保存用户状态?

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太⼀样。

Cookie ⼀般用来保存用户信息
- 我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以⾃动帮你登录的⼀些基本信息给填了；
- ⼀般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了⼀个 Token 在 Cookie中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录⼀般要将 Token
  重写)；
- 登录⼀次网站后访问网站其他页面不需要重新登录。
Session 的主要作用就是通过服务端记录用户的状态。
- 典型的场景是购物⻋，当你要添加商品到购物⻋的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
- 既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在Cookie 中附加⼀个 Session ID 来方式来跟踪。

Cookie
- 作用：服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。
  
  Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
Session
- 作用： Session 代表着服务器和客户端一次会话的过程，Session 对象存储特定用户会话所需的属性及配置信息。
二者区别
- 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端；
- 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效；
- 安全性： Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些；
- 存储大小不同：单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie；
- 存取类型的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。

15.1 Session的共享方式？（好未来问过）

参考：Session如何共享

问题描述
1. 在集群环境中，假设客户端第一次访问服务A，服务A响应返回了一个sessionId并且存入了本地Cookie中。第二次不访问服务A了，转去访问服务B；
2. 访问服务B的时候，会将sessionId加入到请求头中，而服务B因为通过sessionId没有找到相对应的数据，因此它就会创建一个新的sessionId并且响应返回给客户端
这样就造成了不能共享Session的问题。
解决方案
1. 使用Cookie实现。将系统用户的Session信息加密、序列化后，以Cookie的方式，统一种植在根域名下（如：.host.com），利用浏览器访问该根域名下的所有二级域名站点时，会传递与之域名对应的所有Cookie内容的特性，从而实现用户的Cookie化Session在多服务间的共享访问。
2. 数据库同步session。 每次将session数据存到数据库中。这个方案还是比较可行的。
  - 缺点： Session的并发读写能力取决于MySQL数据库的性能，对数据库的压力大，同时需要自己实现Session淘汰逻辑，以便定时从数据表中更新、删除 Session记录，当并发过高时容易出现表锁。
3. 使用token代替session。 就是Token方式替代了，但是还是没解决。
4. Spring-Sesion实现 。将原本需要由Web服务器创建会话的过程转交给Spring-Session进行创建。Spring-Session会将原本应该保存在Web服务器内存的Session存放到Redis中。然后Web服务器之间通过连接Redis来共享数据，达到Sesson共享的目的。

参考：一文彻底搞懂Cookie、Session、Token到底是什么

为什么需要session？

既然浏览器已经通过Cookie实现了有状态这一需求，那么为什么又来了一个Session呢？

如果将账户的一些重要信息都存入Cookie中的话，一旦被拦截，那么我们所有的账户信息都会丢失掉。所以就出现了Session，在一次会话中将重要信息保存在Session中，浏览器只记录SessionId一个SessionId对应一次会话请求。
session和cookie二者关联

以用户一次登录为例。
1. 用户第一次请求服务器的时候，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
2. 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；并将此 Session 的唯一标识信息 SessionID 返回给浏览器；
3. 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名；
4. 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端；
5. 服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
什么是Token？

Session是将要验证的信息存储在服务端，并以SessionId和数据进行对应，SessionId由客户端存储，在请求时将SessionId也带过去，因此实现了状态的对应。

但是，而Token是在服务端将用户信息经过Base64Url【编码，不是加密】过后传给在客户端，每次用户请求的时候都会带上这一段信息，因此服务端拿到此信息进行解密后就知道此用户是谁了。

这个方法叫做JWT(Json Web Token)。
一个例子理解：基于Token的身份验证流程，在服务端不需要存储用户的登录记录。
1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
  
  Token在服务器端，可以保存在Redis缓存中。
4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
- Token的优点
  1. 无状态，可扩展和解耦：使用 token 而不是 cookie 的最大优点应该就是无状态，后端不需要保持对 token 的记录，每个 token 都是独立的，包含了检查其有效性的所有数据，并通过申明传达了用户信息。
  2. 在 JWT 中存储数据 ：当使用 cookie 进行验证时，你是将 session id 存储到 cookie 里，JWT 允许你存储任何类型的元数据，只要是合法的 JSON。
  3. 自包含：由于串包含了用户所需要的信息，避免了多次查询数据库。
- JWT介绍
  
  JWT有三部分组成：Header，Payload，Signature。
  - Header： 一个Json对象，描述JWT的元数据，通常是下面这样子的。
    1
    2
    3
    4
    {
    "alg": "HS256", # 签名的算法为HS256
    "typ": "JWT" # Token类型为JWT
    }
  - Payload： 也是一个Json对象，用来存放实际需要传输的数据，也可以自己定义一些私有字段，如：
    1
    2
    3
    4
    {
    "name": "xiaoMing",
    "age": 14
    }
  - Signature： 对前面的两部分的数据进行签名，防止数据篡改 。
    
    首先需要定义一个秘钥，这个秘钥只有服务器才知道，不能泄露给用户，然后使用Header中指定的签名算法(默认情况是HMAC SHA256)。算出签名以后将Header、Payload、Signature三部分拼成一个字符串，每个部分用.分割开来，就可以返给用户了。

16.1 session和cookie应该如何去选择（适用场景）？

Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；考虑安全考虑session
对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中，一般是cookie和session配合使用的。

17.说说HTTP、TCP、Socket 的关系是什么？

TCP/IP 代表传输控制协议/网际协议，指的是一系列协议族；
HTTP 本身就是一个协议，是从 Web 服务器传输超文本到本地浏览器的传送协议；
Socket 是 TCP/IP 网络的 API ，其实就是一个门面模式，它把复杂的 TCP/IP 协议族隐藏在Socket 接口后面。对用户来说，一组简单的接口就是全部，让 Socket 去组织数据，以符合指定的协议。

3.5 其它

1. 介绍一下CDN ？ CDN分发节点各个数据都一样吗？

CDN，即内容分发网络
- 解决静态网页加载
  
  不同地区用户访问服务器速度不同，可以把静态网页放在不同地区的服务器，这样用户可以就近去连接，大大提升体验；
- 发展转换成，就近接入解决访问网络资源
  1. 如一个电信用户送请求，进入解析系统，会让用户连接到最近的边缘节点，然后请求数据；
  2. 如果边缘节点没有数据，则去访问源节点；
  3. 源节点也没有，就会去访问主干节点，去联通服务器中查找；
  4. 最后返回数据。
CDN分发节点各个数据不一样

不一样，就相当于DNS服务器缓存了些域名→ip数据，如果没有的话还要向上级查询，最终把源站数据拉下来。

2. 什么是CDN三级溯源？

CDN目的。CDN 系统设计的首要目标是尽量减少用户的访问响应时间
CDN实现思路。为达到这一目标，CDN 系统应该尽量将用户所需要的内容存放在距离用户最近的位置。也就是说，负责为用户提供内容服务的 Cache设备应部署在物理上的网络边缘位置，我们称这一层为 CDN边缘层。
CDN系统架构。CDN 系统中负责全局性管理和控制的设备组成中心层，中心层同时保存着最多的内容副本，当边缘层设备未命中时，会向中心层请求，如果在中心层仍未命中，则需要中心层向源站回源。