2021-09-26

最新推荐文章于 2023-03-17 11:08:31 发布

大师兄啊

最新推荐文章于 2023-03-17 11:08:31 发布

阅读量1.5w

点赞数

CC 4.0 BY-SA版权

分类专栏：大厂面经文章标签： kafka zookeeper

本文链接：https://blog.csdn.net/qq_25843323/article/details/120480368

面试二问了整个项目的整体的流程，为什么选择某些技术或者基础组件

1.自我介绍

2.挑一个项目，画项目的架构图

Kafka发送数据之后立即返回还是等待ACK之后才返回？

Kafka工作流程：

1. producter先从Zookeeper获取分区的leader
1. producter将消息发送给leader
1. Leader将消息写入本地文件
1. followers从leader pull消息
1. followers将消息写入本地后向leader发送ACK
1. leader收到所有副本的ACK后向producer发送ACK（或者leader自己收到消息后就发送ACK）。ACK有三个参数配置：参数是0，1，-1.
- 0： producter不等待broker的ACK，这种操作提供了最低的延迟，broker还没有写入磁盘就已经返回了，当broker故障的时候丢失数据（相当于异步发送）
- 1： producter等待broker的ACK，partition的leader落盘成功后返回ACK，如果follower同步数据之前leader故障，此时会丢失数据。此时follower需要同步leader中的数据，但是leader宕机了，挂了之后Kafka集群会重新选举leader，选举出leader之后，并没有同步到原有的数据，就会造成数据的丢失
- -1或all： prodecter等待broker的ACK和partition的leader和follower全部落盘成功后，才会返回ACK，但是如果follower同步完成之后，在broker发送ACK之前，leader发生故障，那么会出现数据的重复，但不会造成数据丢失。

有了解过网络攻击吗？黑客频繁发起二次握手导致连接占满，如何解决恶意二次握手？如果黑客二次握手后也不下线，通过 tcp_syncookies 发送请求时，也回应，怎么办？

SYN攻击：TCP连接建立是需要三次握手，假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入 SYN_RCVD 状态，但服务端发送出去的 ACK+SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常用户服务。

避免 SYN 攻击方式：

方式一、增大半连接队列。通过修改Linux内核参数，控制队列大小和当队列满时应做什么处理。

当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数：net.core.netdev_max_backlog
SYN_RCVD 状态连接的最大个数：net.ipv4.tcp_max_syn_backlog
超出处理能力时，对新的SYN直接回RST，丢弃连接：net.ipv4.tcp_abort_on_overflow

增⼤ tcp_max_syn_backlog 和 somaxconn 的⽅法是修改 Linux 内核参数：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xYzNEmOl-1632587894643)(D:\Desktop\知识整理\图片\image-20210724152822889.png)]

增⼤ backlog 的⽅式，每个 Web 服务都不同，⽐如 Nginx 增⼤ backlog 的⽅法如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AuCUjO2P-1632587894647)(D:\Desktop\知识整理\图片\image-20210724152859337.png)]

方式二：开启tcp_syncookies功能。Linux内核 SYN（未完成连接建立）队列与 Accept （已完成连接建立）队列是如何工作的：

当服务端接收到客户端的SYN报文时，会将其加⼊到内核的「 SYN 队列」；
接着发送 SYN + ACK 给客户端，等待客户端回应 ACK 报⽂；
服务端接收到 ACK 报⽂后，从「 SYN 队列」移除放⼊到「 Accept 队列」；
应⽤通过调⽤ accpet() socket 接⼝，从「 Accept 队列」取出连接。

产生问题的环节：

如果应用程序过慢时，就会导致「 Accept 队列」被占满。
如果不断受到SYN攻击，就会导致「 SYN 队列」被占满。tcp_syncookies的方式可以应对SYN攻击的方法：
```
net.ipv4.tcp_syncookies = 1 
#（0值表示关闭该功能；1值表示仅当SYN半连接队列放不下时，再启用它；2值表示无条件开启功能）
```
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1AK2jT6O-1632587894649)(D:\Desktop\知识整理\图片\image-20210724152705338.png)]
- 当「 SYN 队列」满之后，后续服务器收到 SYN 包，不进⼊「 SYN 队列」；
- 计算出一个 cookie 值，再以SYN + ACK中的「序列号」返回客户端，
- 服务端接收到服务端的应答报文时，服务器会检查这个ACK包的合法性。如果合法，直接放入到「 Accept队列」。
- 最后应用通过调用accept() socket接口，从「 Accept 队列」取出的连接。

方式三：减少SYN+ACK重传次数。当服务端受到SYN攻击时，就会有大量处于SYN_REVC状态的TCP连接，处于这个状态的TCP会重传SYN+ACK，当重传超过次数达到上限后，就会断开连接。那么针对SYN攻击的场景，我们可以减少SYN+ACK的重传次数，以加快处于SYN_REVC状态的TCP连接断开。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qc3PRBlP-1632587894651)(D:\Desktop\知识整理\图片\image-20210724152635912.png)]

重放攻击

重放攻击：Session ID和Session Ticket都不具备向前安全性，一旦加密的会话密钥的密钥被破解或者服务器泄露会话密钥，前面劫持的通信密文都会被破解。

解决办法：避免重发攻击的方式就是需要对话密钥设定一个合理的过期时间。

重放攻击的危险之处在于，如果中间人截获了某个客户端的Session ID或Session Ticket以及POST报文，而一般POST请求会改变数据库的数据，中间人就可以利用此截获的报文，不断向服务器发送该报文，这样就会导致数据库的数据被中间人改变了，而客户是不知情的。

Https的核心是什么以及客户端与服务端如何交互的？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zYTshBBH-1632587894653)(D:\Desktop\知识整理\图片\image-20210825165554969.png)]

信息加密：交互信息无法被窃取，采用混合加密（对称加密和非对称加密结合）
- 在通信建⽴前采⽤⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。
- 在通信过程中全部使⽤对称加密的「会话秘钥」的⽅式加密明⽂数据。
校验机制：无法篡改通信内容，采用摘要算法
身份证书：证明网站的真实性，将服务器公钥放入到数字证书中（CA-数字证书认证机构）

Cookie，Session的区别？

Cookie和Session都是用来跟踪浏览器用户身份的会话技术，但两者有所区别：

Cookie数据保存在客户端，Session数据保存在服务端；
Cookie是客户端保持HTTP会话状态的技术；Session是服务端保持HTTP会话状态的技术；
Cookie不是很安全，别人可以分析存放在本地的Cookie并进行欺骗，考虑到安全应当使用Session；
Cookie有大小限制以及浏览器存Cookie的数量也有限制，Session没有大小限制和服务器的内存大小有关，Session保存在服务器端存在一段时间才会消失，如果Session过多会增加服务器的压力；
Cookie一般用来保存用户信息，Session的主要作用就是通过服务端记录用户的状态。
session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）；
session 默认被存储在服务器的一个文件里（不是内存）；
session 可以放在文件、数据库、或内存中都可以；
用户验证这种场合一般会用 session；

Session的SessonID存储到浏览器之后，关闭浏览器再启动还能拿到SessionID吗？

由于Session是基于Cookie的。浏览器发起请求会携带SessonID到服务器，服务器根据这个id来判断当前访问的是哪个Session。

然而浏览器被关闭后由于浏览器的Cookie文件还未设置MaxAge值，所以在此时浏览器的Cookie是会话级别的，是存在浏览器的内存中，当浏览器被关闭时，浏览器的内存被释放，临时文件被清除，这时的Cookie也随之销毁，则当前这个请求中并没有之前的那个SessionID值，服务器就当是第一次访问，给浏览器创建一个新的Session值并返回一个null。

但是之前的那个Session并没有被干掉，只是浏览器找不到这个SessionID了。这样一来，此时服务器就存在了两个Session了。服务器会一直保留这个会话对象直到它一直处于非活动状态并超过设定的间隔为止。所以我们没必要重新添加Session。解决方法如下：结合Cookie来实现

我们可以手动为Cookie中添加JSESSIONID信息，此时不管你的浏览器是否关闭，我的Cookie中都会携带JSESSION信息，这样的话，只要Session没有消亡，服务器就一定能够找到对应的Session，而不会重新建立一个新的Session。

//登录成功后 ? 手动添加cookie，保存JSESSIONID信息
Cookie cookie = new Cookie("JSESSIONID", session.getId());
cookie.setMaxAge(1800); //设置cookie 和 session生命周期同步.
response.addCookie(cookie);

大文件为什么越下载越快

滑动窗口，慢启动算法，越传越快。

ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”。一般来说ssthresh的值是65535，单位是字节，当cwnd达到这个值+后，算法如下：

收到一个ACK时，cwnd = cwnd + 1/cwnd
当每过一个RTT时，cwnd = cwnd + 1

这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。很明显，是一个线性上升的算法。

HTTP 无状态无连接

无连接：是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。当请求时建立连接、请求完释放连接，以尽快将资源释放出来服务其他客户端，可以加KeepAlive弥补无连接的问题

无状态：是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。可以通过Cookie和Session来弥补这个问题。

volatile 内存屏障

CPU有可能会把相应代码的CPU指令进行一次重排序，这虽然能提高运行的效率，但是也可能会影响一些数据的可见性，而volatile通过内存屏障这个指令，来保证了相应代码块的执行顺序。内存屏障还会强制更新一次CPU缓存。加载最新的内容。

TCP和UDP的不同？

连接
- TCP是面向连接的传输层协议，传输数据前先要建立连接。
- UDP是不需要连接的，即刻传输数据。
服务对象
- TCP是一对一的两点服务，即一条连接只有两个端点。
- UDP支持一对一、一对多、多对多的交互通信。
可靠性
- TCP是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
- UDP是尽最大努力交付，不保证可靠交付数据。
拥塞控制、流量控制
- TCP有拥塞控制和流量控制机制，保证数据传输的安全性
- UDP则没有，即使网络非常拥堵了，也不会影响UDP的发送速率。
首部开销
- TCP首部长度较长，会有一定的开销，首部在没有使用选项字段时是 20 个字节，如果使用了选项字段则会更长的。
- UDP ⾸部只有 8 个字节，并且是固定不变的，开销较⼩。
传输方式
- TCP 是流式传输，没有边界，但保证顺序和可靠。
- UDP 是⼀个包⼀个包的发送，是有边界的，但可能会丢包和乱序。
分片不同
- TCP的数据大小如果大于MSS大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装TCP数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
- UDP的数据大小如果大于MTU*(Maximum Transmission Unit)*大小，则会在IP层进行分片，目标主机收到后，在IP层组装完数据，接着再传输给传输层，但是如果中途丢了一个分片，在实现可靠传输的UDP时则就需要重传所有的数据包，这样传输效率非常差，所以通常UDP的报文应该小于MTU。

TCP 和 UDP 应⽤场景

由于TCP是面向连接，能保证数据的可靠性交付，因此经常用于：FTP文件传输，HTTP/HTTPS、SMTP
由于UDP面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：
- 包总量较少的通信，如DNS、SNMP、RIP等
- 视频、音频等多媒体通信
- 广播通信

TCP粘包原因和解决方法

TCP粘包是指：发送方发送的若干包数据到接收方接收时粘成一包

发送方原因：

TCP默认使用Nagle*[ˈneɪgəl]*算法（主要作用：减少网络中报文段的数量）。

收集多个小分组，在一个确认到来时一起发送、导致发送方可能会出现粘包问题

接收方原因：

TCP将接收到的数据包保存在接收缓存里，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

解决粘包问题：

最本质原因在于接收方无法分辨消息与消息之间的边界在哪，通过使用某种方案给出边界，例如：

发送定长包。每个消息的大小都是一样的，接收方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收方先接收包体长度，依据包体长度来接收包体。

TCP三次握手

⼀开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端⼝，处于 LISTEN 状态；

客户端随机初始化序列号 client_isn ，将序列号置于TCP首部的序列号字段中，同时把 SYN 标制位置为 1，表示 SYN 报文。接着把第一个SYN报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 **SYN_SENT**状态；
服务端收到客户端的 SYN报文后，首先服务端也随机初始化自己的序列号 server_isn，并填入 TCP 首部的序列号字段中，其次把TCP首部的确认应答号字段填入 client_isn + 1，接着把 SYN 和 ACK 标制置为 1，最后把该报文发送给客户端，该报文也不包含应用层数据，之后服务端处于 SYN_RCVD 状态；
客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文TCP首部 ACK 标志位置为 1，其次确认应答号字段填入 server_isn + 1，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。

服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态。

可通过 netstat -napt 命令查看TCP的连接状态

什么是TCP连接：用于保证可靠性和流量控制维护的某些状态信息，这信息的组合，包括 Socket、序列号和窗口大小称为连接。

TCP握手为什么三次

三次握手才可以避免历史连接（主要原因）；

我们来看看 RFC 793 指出的 TCP 连接使⽤三次握⼿的⾸要原因：

The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.

简单来说，三次握⼿的⾸要原因是为了防⽌旧的重复连接初始化造成混乱。

客户端连续发送多次 SYN 建⽴连接的报⽂，在⽹络拥堵情况下：
- ⼀个「旧 SYN 报⽂」⽐「最新的 SYN 」报⽂早到达了服务端；
- 那么此时服务端就会回⼀个 SYN + ACK 报⽂给客户端；
- 客户端收到后可以根据⾃身的上下⽂，判断这是⼀个历史连接（序列号过期或超时），那么客户端就会发送 RST 报⽂给服务端，表示中⽌这⼀次连接。
三次握手才可以同步双方的初始序列号；

TCP 协议的通信双⽅，都必须维护⼀个「序列号」，序列号是可靠传输的⼀个关键因素，它的作⽤：
- 接收⽅可以去除重复的数据；
- 接收⽅可以根据数据包的序列号按序接收；
- 可以标识发送出去的数据包中，哪些是已经被对⽅收到的；
三次握手才可以避免资源浪费；

如果只有「两次握⼿」，当客户端的 SYN 请求连接在⽹络中阻塞，客户端没有接收到 ACK 报⽂，就会重新发送 SYN ，由于没有第三次握⼿，服务器不清楚客户端是否收到了⾃⼰发送的建⽴连接的 ACK 确认信号，所以每收到⼀个 SYN 就只能先主动建⽴⼀个连接，这会造成什么情况呢？

如果客户端的 SYN 阻塞了，重复发送多次 SYN 报⽂，那么服务器在收到请求后就会建⽴多个冗余的⽆效链接，造成不必要的资源浪费。

为什么两次不行？

无法防止历史连接的建立；会造成双方资源的浪费；也无法可靠的同步双方序列号。

TCP四次挥手

客户端打算关闭连接，此时会发送一个TCP首部 FIN 标制位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态；
服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 **CLOSED_WAIT**状态；客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态；
等到客户端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态；
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态；服务器收到了 ACK 应答报文后，就进入 CLOSED 状态，至此服务器已经完成连接的关闭；

客户端在经过 2MSL*(Maximum Segment Lifetime)* 时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

这⾥⼀点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

TCP回收为什么四次

再来回顾下四次挥⼿双⽅发 FIN 包的过程，就能理解为什么需要四次了。

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
服务器收到客户端的 FIN 报⽂时，先回⼀个 ACK 应答报⽂，⽽服务端可能还有数据需要处理和发送，等服务端不再处理数据时，才发送 FIN 报⽂给客户端来表示同意现在关闭连接。

从上⾯过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN ⼀般都会分开发送，从⽽⽐三次握⼿导致多了⼀次。

为什么需要 TIME_WAIT 状态？

首先，主动发起关闭连接的一方，才会有 TIME_WAIT 状态。

需要**TIME_WAIT**状态，主要有两个原因：

防止具有相同四元组的旧数据包被收到；

TCP 就设计出了这么⼀个机制，经过 2MSL 这个时间，⾜以让两个⽅向上的数据包都被丢弃，使得原来连接的数据包在⽹络中都⾃然消失，再出现的数据包⼀定都是新建⽴连接所产⽣的。
保证被动关闭连接的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭；

TCP 怎么处理丢包的问题的

ack，超时重传，接收缓冲，快速重传

知道一个域名，怎么和他通信

dns（首先查询本地HOST文件，没有则查询网络），ip，路由

TCP是如何实现数据的可靠传输的

通过 校验和、序列号、确认应答、重发控制（又分为超时重传、快速重传、SACK、D-SACK）、连接管理、流量控制、拥塞控制等。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XCLcjG8K-1632587894655)(D:\Desktop\知识整理\图片\image-20210826145130394.png)]

校验和：在数据传输过程中，将发送的数据段都当做一个16位的整数，将这些整数加起来，并且前面的进位不能丢弃，补在最后，然后取反，得到校验和。

发送方：在发送数据之前计算校验和，并进行校验和的填充。

接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方进行比较。
序列号：TCP 传输时将每个字节的数据都进行了编号，这就是序列号。序列号的作用不仅仅是应答作用，有了序列号能够将接收到的数据根据序列号进行排序，并且去掉重复的数据。
确认应答：TCP 传输过程中，每次接收方接收到数据后，都会对传输方进行确认应答，也就是发送 ACK 报文，这个 ACK 报文中带有对应的确认序列号，告诉发送方，接收了哪些数据，下一次数据从哪里传。
重发控制：
- 超时重传：在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据。TCP会在以下两种情况发生超时重传：数据包丢失和确认应答号丢失。超时时间应略大于RTT（Round-Trip Time 往返时延）。
- 快速重传：当收到三个相同的ACK报文时，会在定时器过期之前，重传丢失的报文段。
- SACK（Selective Acknowledgment 选择性确认）：快速重传机制解决了超时时间的问题，但是没有解决当重传的时候，是重传之前的一个，还是重传所有的问题。该方式需要在TCP头部选项字段里加一个SACK的东西，它可以将缓存的地图发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没有收到，知道了这些数据，就可以只重传丢失的数据。
- D-SACK（Duplicate SACK）：使用SACK主要来告诉发送方有哪些数据被重复接收了。
连接管理：就是指三次握手、四次挥手的过程。
流量控制：如果发送方的发送速度太快，会导致接收方的接收缓冲区填充满了，这时候继续传输数据，就会造成大量丢包，进而引起丢包重传等等一系列问题。TCP 支持根据接收端的处理能力来决定发送端的发送速度，这就是流量控制机制。

具体实现方式：接收端将自己的接收缓冲区大小放入 TCP 首部的『窗口大小』字段中，通过 ACK 通知发送端。
拥塞控制：TCP 传输过程中一开始就发送大量数据，如果当时网络非常拥堵，可能会造成拥堵加剧。所以 TCP 引入了慢启动机制，在开始发送数据的时候，先发少量的数据探探路。
- 慢启动：当发送⽅每收到⼀个ACK，拥塞窗⼝cwnd 的⼤⼩就会加 1。
  有⼀个叫慢启动⻔限 ssthresh （slow start threshold）状态变量。
  - 当cwnd < ssthresh 时，使⽤慢启动算法。
  - 当 cwnd >= ssthresh 时，就会使⽤「拥塞避免算法」。
- 拥塞避免算法：每当收到一个ACK时，cwcd增加1/cwnd。
- 拥塞发生：当⽹络出现拥塞，也就是会发⽣数据包重传，重传机制主要有两种：超时重传和快速重传。
  
  当发生了超时重传，就会使用拥塞发生算法，这个时候，ssthresh 和 cwnd 的值会发⽣变化：ssthresh 设为 cwnd/2 ；cwnd 重置为 1
  
  当发生快速重传时，TCP 认为这种情况不严重，因为⼤部分没丢，只丢了⼀⼩部分，则 ssthresh 和 cwnd 变化如下：cwnd = cwnd/2 ，也就是设置为原来的⼀半;ssthresh = cwnd ;进⼊快速恢复算法。
- 快速恢复算法：快速重传和快速恢复算法⼀般同时使⽤，快速恢复算法是认为，你还能收到 3 个重复 ACK 说明⽹络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。然后，进⼊快速恢复算法如下：
  - 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
  - 重传丢失的数据包；
  - 如果再收到重复的 ACK，那么 cwnd 增加 1；
  - 如果收到新数据的 ACK 后，把 cwnd 设置为第⼀步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进⼊拥塞避免状态；

IP地址是怎样分类的？

先说一下 IP 的基本特点：

IP地址由四段组成，每个字段是一个字节，8位，最大值是255。
IP地址由两部分组成，即网络地址和主机地址。网络地址表示其属于互联网的哪一个网络，主机地址表示其属于该网络中的哪一台主机。

IP 地址主要分为A、B、C三类及特殊地址D、E这五类，甩一张图：

A类：(1.0.0.0-126.0.0.0)一般用于大型网络。

B类：(128.0.0.0-191.255.0.0)一般用于中等规模网络。

C类：(192.0.0.0-223.255.255.0)一般用于小型网络。

D类：是多播地址，地址的网络号取值于224~239之间，一般用于多路广播用户。

E类：是保留地址。地址的网络号取值于240~255之间。

http1.0、http1.1、https、http2、http3演变

HTTP1.0

性能问题：每发送一个请求，都需要新建立一次TCP连接（三次握手），而且是串行请求，增加了通信开销。

HTTP1.1

性能提升：

提出了长连接的通信方式，也叫持久连接，减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。长连接特点：只要任意一端没有明确提出断开连接，则保持TCP连接状态。
管道网络传输：在同一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发送出去了，不必等其回来，就可以发送第二个请求出去，可以减少整体的响应时间。

因此出现的新问题：队头阻塞，即服务器还是按照顺序对请求进行回应，如果前面的回应特别慢，后面就会有许多请求排队等着。

性能瓶颈：

Header（请求/响应头部）未经压缩就发送，首部信息越多延迟越大。只能压缩Body部分；
发送冗长的首部，每次互相发送相同的首部造成的浪费较多；
队头阻塞；
没有请求优先级控制；
请求只能从客户端开始，服务器只能被动响应；

HTTP 2：HTTP 2 协议基于HTTPS

性能提升：

头部压缩：HPACK算法，在客户端和服务器同时维护一张头部信息表；
二进制格式：全面采用二进制格式，头信息和数据体都是二进制，统称为帧（frame），分为头信息帧和数据帧；
数据流：每个请求或回应的所有数据包，称为数据流（Stream），每个数据流都标记着一个独一无二的编号，其中规定客户端发送的数据流为奇数，服务端发出的数据流编号为偶数，客户端还可以指定数据流的优先级；
多路复用：一个链接中并发多个请求或响应，而不是顺序一一对应；
服务器推送：服务器可以主动向客户端发送信息；

性能瓶颈：

多路复用，一旦发生了丢包现象，就会触发TCP的重传机制，这样在一个TCP连接中的所有HTTP请求都必须等待这个丢了的包被重传回来；
握手时延迟：需要经过TCP三次握手和TLS四次握手（1.2版本）的过程，需要3个RTT时延才能发送数据；

HTTP 3：HTTP 3 把HTTP下层的TCP协议改成了UDP

性能提升：

UDP是不可靠传输，但基于QUIC协议可以实现类似TCP的可靠传输，当某个流丢包时，只会阻塞这个流，其他流不受影响；
TLS/1.3 的头部压缩算法升级成了QPACK；
QUIC把以往的TCP和TLS/1.3 的6次交互合并成了3次，减少了交互次数。QUIC是一个在UDP之上的伪TCP+TLS+HTTP/2的多路复用协议。

HTTPS

特点

在TCP和HTTP层间加入了SSL/TLS安全协议，使得报文能够加密传输；
HTTPS在TCP三次握手之后，还需要进行SSL/TLS的握手过程，才可进入加密报文传输；
HTTPS协议需要向CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的；
端口号是443；

解决安全方案

信息加密：混合加密的方式实现信息的机密性，解决了窃听的风险；
校验机制：摘要算法的方式来实现完整性，它能为数据生成独一无二的指纹，指纹用于校验数据的完整性，解决了篡改的风险；
身份证书：将服务器公钥放入到数字证书中，解决了冒充的风险；

SSL/TLS协议基本流程

第一步，客户端向服务器索要并验证服务器的公钥；
第二步，双方协商生产会话密钥；
第三步，双方采用会话密钥进行加密通信；

上述前两步就是SSL/TLS的建立过程，也就是握手阶段：①ClientHello；②ServerHello；③客户端回应；④服务器的最后回应。注：SSL/TLS 1.3经过优化只需要3次握手。

HTTPS优化

HTTPS性能损耗的两个环节

第一个环节是TLS协议握手过程，不仅增加了2RTT的网络延迟，而且握手过程中的一些步骤也会产生性能损耗（ECDHE算法需要临时生成椭圆曲线公钥、访问CA、双方计算对称加密密钥等）；
第二个环节就是握手后的对称加密报文传输；

优化方案

针对第一个环节：

HTTPS协议是计算密集型，而不是IO密集型，优化重点在CPU，首选支持AES-NI特性的CPU；
软件优化：软件升级；
协议优化：尽可能选择ECDHE密钥交换算法替换RSA算法，TLS升级到1.3，简化握手的步骤，完成TLS握手只需要1个RTT延时；
证书优化：

证书传输：减小证书的大小，选择ECDSA证书，而不是RSA这个念书；

证书验证：使用OCSP Stapling（在线证书状态协议）来查询证书的有效性；
会话复用：TLS会话的目的就是为了协商出会话密钥，就是对称加密密钥，如果将首次的TLS握手协商的对称加密密钥缓存启来，下次连接时就可以直接复用，分为Session ID 和 Session Ticket；

针对第二个环节：现在主流的对称加密算法 AES、ChaCha20 性能都是不错的，⽽且⼀些 CPU ⼚商还针对它们做了硬件级别的优化，因此这个环节的性能消耗可以说⾮常地⼩。

HTTP 与 HTTPS 有哪些区别？

HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全⻛险的问题；

HTTPS 则解决 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。
HTTP 连接建⽴相对简单，是无状态的，TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输；

⽽ HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。
HTTP 的端⼝号是 80；HTTPS 的端⼝号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

对称加密和非对称加密的区别和原理

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方;

而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它比较慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

常见的状态码有哪些?

1×× : 请求处理中，请求已被接受，正在处理；
2×× : 请求成功，请求被成功处理 200 OK、204：与 200 OK 基本相同，但响应头没有 body 数据、206：是应⽤于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，⽽是其中的⼀部分，也是服务器处理成功的状态；
3×× : 重定向，要完成请求必须进行进一步处理。301 : 永久性转移，需改⽤新的 URL 再次访问、302 ：暂时性转移、 304 ：已缓存；
4×× : 客户端错误，请求不合法。 400：Bad Request,请求有语法问、 403：拒绝请求，并不是客户端的请求出错、404：客户端所访问的页面不存在，所以⽆法提供给客户端；
5×× : 服务器端错误，服务器不能处理合法请求 500 ：服务器内部错误、501：客户端请求的功能还不⽀持、502：通常是服务器作为⽹关或代理时返回的错误码，表示服务器⾃身⼯作正常，访问后端服务器发⽣了错误、503 ：服务不可用，稍等；

http中常见的header字段有哪些

cookie，请求时传递给服务端的cookie信息

set-cookie，响应报文首部设置要传递给客户端的cookie信息

allow，支持什么HTTP方法

last-modified，资源的最后修改时间

expires,设置资源缓存的失败日期

content-language，实体的资源语言

content-encoding，实体的编码格式

content-length，实体主体部分的大小单位是字节

content-range，返回的实体的哪些范围

content-type，哪些类型

accept-ranges，处理的范围请求

age，告诉客户端服务器在多久前创建了响应

vary，代理服务器的缓存信息

location，用于指定重定向后的

URI If-Match，值是资源的唯一标识

User-Agent，将创建请求的浏览器和用户代理名称等信息传递给服务器

Transfer-Encoding，传输报文的主体编码方式

connection，管理持久连接，keep-alive ,

close Cache-Control，控制浏览器的强缓存

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tIV6vQYb-1632587894656)(D:\Desktop\知识整理\图片\image-20210826164833271.png)]

Get与POST的区别？

GET 一般用来从服务器上获取资源；POST 一般用来创建资源；
GET 是幂等的，即读取同一个资源，总是得到相同的数据；而 POST 不是幂等的。GET 不会改变服务器上的资源；而 POST 会对服务器资源进行改变；
从请求参数形式上看，GET 请求的数据会附在URL之后；而 POST 请求会把提交的数据则放置在是HTTP请求报文的请求体中。
POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上；而 POST 请求参数则被包装到请求体中，相对更安全。
GET 请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小；而POST请求则是没有大小限制的。

http除了常用的get和post还有什么方法

方法	描述
GET	向特定资源发送请求，查询数据，并返回实体
POST	向指定资源提交数据进行处理请求，可能会导致新的资源建立、已有资源修改
PUT	向服务器上传新的内容
HEAD	类似GET请求，返回的响应中没有具体的内容，用于获取报头
DELETE	请求服务器删除指定标识的资源
OPTIONS	可以用来向服务器发送请求来测试服务器的功能性
TRACE	回显服务器收到的请求，用于测试或诊断
CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

DNS 的寻址过程

（1）在浏览器中输入www.baidu.com域名，操作系统会先检查自己本地的 hosts 文件是否有这个网址映射关系，如果有就先调用这个IP地址映射，完成域名解析。

（2）如果 hosts 里没有这个域名的映射，则查找本地 DNS 解析器缓存，是否有这个网址映射关系，如果有直接返回，完成域名解析。

（3）如果 hosts 与本地 DNS 解析器缓存都没有相应的网址映射关系，首先会找 TCP/IP 参数中设置的首选 DNS 服务器，在此我们叫它本地 DNS 服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。

（4）如果要查询的域名，不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析，此解析不具有权威性。

（5）如果本地 DNS 服务器本地区域文件与缓存解析都失效，则根据本地 DNS 服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地 DNS 就把请求发至13台根 DNS ，根 DNS 服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地 DNS 服务器收到IP信息后，将会联系负责 .com 域的这台服务器。这台负责 .com 域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(baidu.com)给本地 DNS 服务器。当本地 DNS 服务器收到这个地址后，就会找 baidu.com 域服务器，重复上面的动作，进行查询，直至找到 www.baidu.com 主机。

（6）如果用的是转发模式，此 DNS 服务器就会把请求转发至上一级 DNS 服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根 DNS 或把转请求转至上上级，以此循环。不管是本地 DNS 服务器转发，还是根提示，最后都是把结果返回给本地 DNS 服务器，由此 DNS 服务器再返回给客户机。

在浏览器中输入一个www.baidu.com后执行的全部过程

域名解析 -> 建立TCP连接（三次握手）-> 发起http请求 -> 服务器响应http请求，浏览器得到html代码 -> 浏览器解析html代码，并请求html代码中的资源（如 js、css、图片等）-> 浏览器对页面进行渲染呈献给用户。

有哪些 web 性能优化技术

DNS查询优化
客户端缓存
优化TCP连接
避免重定向
网络边缘的缓存
条件缓存
压缩和代码极简化
图片优化

什么是 XSS 攻击

XSS 即（Cross Site Scripting）中文名称为：跨站脚本攻击。XSS的重点不在于跨站点，而在于脚本的执行。

XSS的原理是：

恶意攻击者在web页面中会插入一些恶意的 script代码。当用户浏览该页面的时候，那么嵌入到web页面中script代码会执行，因此会达到恶意攻击用户的目的。

XSS攻击最主要有如下分类：反射型、存储型、及 DOM-based型。反射型和 DOM-baseed型可以归类为非持久性XSS攻击。存储型可以归类为持久性XSS攻击。

什么是跨站攻击CSRF

CSRF（Cross Site Request Forgery，跨站域请求伪造）是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一，也被称为『One Click Attack』或者『Session Riding』，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。

听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。

XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。