共计 13266 个字符,预计需要花费 34 分钟才能阅读完成。
在秋招过程中看了大量面经,将常见的计算机网络面试题总结如下,并依照面试中发问的频率做了标注(星数越高,面试中发问频率越高),如有帮到你,能够珍藏点赞反对哦。
举荐浏览:
- 一文搞定所有 Java 基础知识面试题
- 一文搞定所有 Java 汇合面试题
什么是网络协议,为什么要对网络协议分层 *
网络协议是计算机在通信过程中要遵循的一些约定好的规定。
网络分层的起因:
- 易于实现和保护,因为各层之间是独立的,层与层之间不会收到影响。
- 有利于标准化的制订
计算机网络的各层协定及作用 ***
计算机网络体系能够大抵分为一下三种,七层模型、五层模型和 TCP/IP 四层模型,个别面试能流畅答复出五层模型就能够了,表示层和会话层被问到的不多。
- 应用层
应用层的工作是通过利用过程之间的交互来实现特定的网络作用,常见的应用层协定有域名零碎 DNS,HTTP 协定等。
- 表示层
表示层的次要作用是数据的示意、平安、压缩。可确保一个零碎的应用层所发送的信息能够被另一个零碎的应用层读取。
- 会话层
会话层的次要作用是建设通信链接,放弃会话过程通信链接的畅通,同步两个节点之间的对话,决定通信是否被中断以及通信中断时决定从何处从新发送。。
- 传输层
传输层的次要作用是负责向两台主机过程之间的通信提供数据传输服务。传输层的协定次要有传输控制协议 TCP 和用户数据协定 UDP。
- 网络层
网络层的次要作用是抉择适合的网间路由和替换结点,确保数据及时送达。常见的协定有 IP 协定。
- 数据链路层
数据链路层的作用是在物理层提供比特流服务的根底上,建设相邻结点之间的数据链路,通过差错控制提供数据帧(Frame)在信道上无差错的传输,并进行各电路上的动作系列。常见的协定有 SDLC、HDLC、PPP 等。
- 物理层
物理层的次要作用是实现相邻计算机结点之间比特流的通明传输,并尽量屏蔽掉具体传输介质和物理设施的差别。
URI 和 URL 的区别 *
- URI(Uniform Resource Identifier):中文全称为对立资源标志符,次要作用是惟一标识一个资源。
- URL(Uniform Resource Location):中文全称为对立资源定位符,次要作用是提供资源的门路。
有个经典的比喻是 URI 像是身份证,能够惟一标识一个人,而 URL 更像一个住址,能够通过 URL 找到这个人。
DNS 的工作流程 ***
DNS 的定义:DNS 的全称是 domain name system,即域名零碎。DNS 是因特网上作为域名和 IP 地址互相映射的一个分布式数据库,可能使用户更不便的去拜访互联网而不必去记住可能被机器间接读取的 IP 地址。比方大家拜访百度,更多地必定是拜访 www.baidu.com,而不是拜访 112.80.248.74,因为这简直无规则的 IP 地址切实太难记了。DNS 要做的就是将 www.baidu.com 解析成 112.80.248.74。
DNS 是集群式的工作形式还是 单点式的,为什么?
答案是集群式的,很容易想到的一个计划就是只用一个 DNS 服务器,蕴含了所有域名和 IP 地址的映射。只管这种设计形式看起来很简略,然而毛病不言而喻,如果这个惟一的 DNS 服务器出了故障,那么就全完了,因特网就简直崩了。为了防止这种状况呈现,DNS 零碎采纳的是分布式的档次数据数据库模式,还有缓存的机制也能解决这种问题。
DNS 的工作流程
主机向本地域名服务器的查问个别是采纳递归查问,而本地域名服务器向根域名的查问个别是采纳迭代查问。
递归查问主机向本地域名发送查问申请报文,而本地域名服务器不晓得该域名对应的 IP 地址时,本地域名会持续向根域名发送查问申请报文,不是告诉主机本人向根域名发送查问申请报文。迭代查问是,本地域名服务器向根域名收回查问申请报文后,根域名不会持续向顶级域名服务器发送查问申请报文,而是告诉本地域名服务器向顶级域名发送查问申请报文。
简略来说,递归查问就是,小明问了小红一个问题,小红不晓得,但小红是个热心肠,小红就去问小王了,小王把答案通知小红后,小红又去把答案通知了小明。迭代查问就是,小明问了小红一个问题,小红也不晓得,而后小红让小明去问小王,小明又去问小王了,小王把答案通知了小明。
- 在浏览器中输出 www.baidu.com 域名,操作系统会先查看本人本地的 hosts 文件是否有这个域名的映射关系,如果有,就先调用这个 IP 地址映射,实现域名解析。
- 如果 hosts 文件中没有,则查问本地 DNS 解析器缓存,如果有,则实现地址解析。
- 如果本地 DNS 解析器缓存中没有,则去查找本地 DNS 服务器,如果查到,实现解析。
- 如果没有,则本地服务器会向根域名服务器发动查问申请。根域名服务器会通知本地域名服务器去查问哪个顶级域名服务器。
- 本地域名服务器向顶级域名服务器发动查问申请,顶级域名服务器会通知本地域名服务器去查找哪个权限域名服务器。
- 本地域名服务器向权限域名服务器发动查问申请,权限域名服务器通知本地域名服务器 www.baidu.com 所对应的 IP 地址。
- 本地域名服务器通知主机 www.baidu.com 所对应的 IP 地址。
理解 ARP 协定吗? **
ARP 协定属于网络层的协定,次要作用是实现从 IP 地址转换为 MAC 地址。在每个主机或者路由器中都建有一个 ARP 缓存表,表中有 IP 地址及 IP 地址对应的 MAC 地址。先来看一下什么时 IP 地址和 MAC 地址。
- IP 地址:IP 地址是指互联网协议地址,IP 地址是 IP 协定提供的一种对立的地址格局,它为互联网上的每一个网络和每一台主机调配一个逻辑地址,以此来屏蔽物理地址的差别。
- MAC 地址:MAC 地址又称物理地址,由网络设备制造商生产时写在硬件外部,不可更改,并且每个以太网设施的 MAC 地址都是惟一的。
数据在传输过程中,会先从高层传到底层,而后在通信链路上传输。从下图能够看到 TCP 报文在网络层会被封装成 IP 数据报,在数据链路层被封装成 MAC 帧,而后在通信链路中传输。在网络层应用的是 IP 地址,在数据据链路层应用的是 MAC 地址。MAC 帧在传送时的源地址和目标地址应用的都是 MAC 地址,在通信链路上的主机或路由器也都是依据 MAC 帧首部的 MAC 地址接管 MAC 帧。并且在数据链路层是看不到 IP 地址的,只有当数据传到网络层时去掉 MAC 帧的首部和尾部时能力在 IP 数据报的首部中找到源 IP 地址和目标地址。
网络层实现的是主机之间的通信,而链路层实现的是链路之间的通信,所以从下图能够看出,在数据传输过程中,IP 数据报的源地址 (IP1) 和目标地址 (IP2) 是始终不变的,而 MAC 地址 (硬件地址) 却始终随着链路的扭转而扭转。
ARP 的工作流程(面试时问 ARP 协定次要说这个就能够了):
- 在局域网内,主机 A 要向主机 B 发送 IP 数据报时,首先会在主机 A 的 ARP 缓存表中查找是否有 IP 地址及其对应的 MAC 地址,如果有,则将 MAC 地址写入到 MAC 帧的首部,并通过局域网将该 MAC 帧发送到 MAC 地址所在的主机 B。
- 如果主机 A 的 ARP 缓存表中没有主机 B 的 IP 地址及所对应的 MAC 地址,主机 A 会在局域网内播送发送一个 ARP 申请分组。局域网内的所有主机都会收到这个 ARP 申请分组。
- 主机 B 在看到主机 A 发送的 ARP 申请分组中有本人的 IP 地址,会像主机 A 以单播的形式发送一个带有本人 MAC 地址的响应分组。
- 主机 A 收到主机 B 的 ARP 响应分组后,会在 ARP 缓存表中写入主机 B 的 IP 地址及其 IP 地址对应的 MAC 地址。
- 如果主机 A 和主机 B 不在同一个局域网内,即便晓得主机 B 的 MAC 地址也是不能间接通信的,必须通过路由器转发到主机 B 的局域网才能够通过主机 B 的 MAC 地址找到主机 B。并且主机 A 和主机 B 曾经能够通信的状况下,主机 A 的 ARP 缓存表中寸的并不是主机 B 的 IP 地址及主机 B 的 MAC 地址,而是主机 B 的 IP 地址及该通信链路上的下一跳路由器的 MAC 地址。这就是上图中的源 IP 地址和目标 IP 地址始终不变,而 MAC 地址却随着链路的不同而扭转。
- 如果主机 A 和主机 B 不在同一个局域网,参考上图中的主机 H1 和主机 H2,这时主机 H1 须要先播送找到路由器 R1 的 MAC 地址,再由 R1 播送找到路由器 R2 的 MAC 地址,最初 R2 播送找到主机 H2 的 MAC 地址,建设起通信链路。
有了 IP 地址,为什么还要用 MAC 地址?**
简略来说,标识网络中的一台计算机,比拟罕用的就是 IP 地址和 MAC 地址,但计算机的 IP 地址可由用户自行更改,治理起来绝对艰难,而 MAC 地址不可更改,所以个别会把 IP 地址和 MAC 地址组合起来应用。具体是如何组合应用的在下面的 ARP 协定中曾经讲的很分明了。
那只用 MAC 地址不必 IP 地址可不可以呢?其实也是不行的,因为在最早就是 MAC 地址先呈现的,并且过后并不必 IP 地址,只用 MAC 地址,起初随着网络中的设施越来越多,整个路由过程越来越简单,便呈现了子网的概念。对于目标地址在其余子网的数据包,路由只须要将数据包送到那个子网即可,这个过程就是下面说的 ARP 协定。
那为什么要用 IP 地址呢?是因为 IP 地址是和地区相干的,对于同一个子网上的设施,IP 地址的前缀都是一样的,这样路由器通过 IP 地址的前缀就晓得设施在在哪个子网上了,而只用 MAC 地址的话,路由器则须要记住每个 MAC 地址在哪个子网,这须要路由器有极大的存储空间,是无奈实现的。
IP 地址能够比作为地址,MAC 地址为收件人,在一次通信过程中,两者是缺一不可的。
说一下 ping 的过程 **
ping 是 ICMP(网际管制报文协定)中的一个重要利用,ICMP 是网络层的协定。ping 的作用是测试两个主机的连通性。
ping 的工作过程:
- 向目标主机发送多个 ICMP 回送申请报文
- 依据目标主机返回的回送报文的工夫和胜利响应的次数估算出数据包往返工夫及丢包率。
路由器和交换机的区别?*
所属网络模型的层级 | 性能 | |
---|---|---|
路由器 | 网络层 | 辨认 IP 地址并依据 IP 地址转发数据包,保护数据表并基于数据表进行最佳门路抉择 |
交换机 | 数据链库层 | 辨认 MAC 地址并依据 MAC 地址转发数据帧 |
TCP 与 UDP 有什么区别 ***
是否面向连贯 | 可靠性 | 传输模式 | 传输效率 | 耗费资源 | 利用场景 | 首部字节 | |
---|---|---|---|---|---|---|---|
TCP | 面向连贯 | 牢靠 | 字节流 | 慢 | 多 | 文件 / 邮件传输 | 20~60 |
UDP | 无连贯 | 不牢靠 | 数据报文段 | 快 | 少 | 视频 / 语音传输 | 8 |
有时候面试还会问到 TCP 的首部都蕴含什么
- TCP 首部(图片来源于网络):
前 20 个字节是固定的,前面有 4n 个字节是依据需而减少的选项,所以 TCP 首部最小长度为 20 字节。
- UDP 首部(图片来源于网络):
UDP 的首部只有 8 个字节,源端口号、目标端口号、长度和校验和各两个字节。
TCP 协定如何保障牢靠传输 ***
次要有校验和、序列号、超时重传、流量管制及拥塞防止等几种办法。
- 校验和:在发送算和接收端别离计算数据的校验和,如果两者不统一,则阐明数据在传输过程中呈现了过错,TCP 将抛弃和不确认此报文段。
- 序列号:TCP 会对每一个发送的字节进行编号,接管方接到数据后,会对发送方发送确认应答(ACK 报文),并且这个 ACK 报文中带有相应的确认编号,通知发送方,下一次发送的数据从编号多少开始发。如果发送方发送雷同的数据,接收端也能够通过序列号判断出,间接将数据抛弃。如果
- 超时重传:在下面说了序列号的作用,但如果发送方在发送数据后一段时间内(能够设置重传计时器规定这段时间)没有收到确认序号 ACK,那么发送方就会从新发送数据。
这里发送方没有收到 ACK 能够分两种状况,如果是发送方发送的数据包失落了,接管方收到发送方从新发送的数据包后会马上给发送方发送 ACK;如果是接管方之前接管到了发送方发送的数据包,而返回给发送方的 ACK 失落了,这种状况,发送方重传后,接管方会间接抛弃发送方冲重传的数据包,而后再次发送 ACK 响应报文。
如果数据被重发之后还是没有收到接管方的确认应答,则进行再次发送。此时,期待确认应答的工夫将会以 2 倍、4 倍的指数函数缩短,直到最初敞开连贯。
- 流量管制:如果发送端发送的数据太快,接收端来不及接管就会呈现丢包问题。为了解决这个问题,TCP 协定利用了滑动窗口进行了流量管制。在 TCP 首部有一个 16 位字段大小的窗口,窗口的大小就是接收端接收数据缓冲区的残余大小。接收端会在收到数据包后发送 ACK 报文时,将本人的窗口大小填入 ACK 中,发送方会依据 ACK 报文中的窗口大小进而管制发送速度。如果窗口大小为零,发送方会进行发送数据。
- 拥塞管制:如果网络呈现拥塞,则会产生丢包等问题,这时发送方会将失落的数据包持续重传,网络拥塞会更加重大,所以在网络呈现拥塞时应留神管制发送方的发送数据,升高整个网络的拥塞水平。拥塞管制次要有四局部组成:慢开始、拥塞防止、快重传、快复原,如下图(图片来源于网络)。
这里的发送方会保护一个拥塞窗口的状态变量,它和流量管制的滑动窗口是不一样的,滑动窗口是依据接管方数据缓冲区大小确定的,而拥塞窗口是依据网络的拥塞状况动静确定的,一般来说发送方实在的发送窗口为滑动窗口和拥塞窗口中的最小值。
- 慢开始:为了防止一开始发送大量的数据而产生网络阻塞,会先初始化 cwnd 为 1,当收到 ACK 后到下一个传输轮次,cwnd 为 2,以此类推成指数模式增长。
- 拥塞防止:因为 cwnd 的数量在慢开始是指数增长的,为了避免 cwnd 数量过大而导致网络阻塞,会设置一个慢开始的门限值 ssthresh,当 cwnd>=ssthresh 时,进入到拥塞防止阶段,cwnd 每个传输轮次加 1。但网络呈现超时,会将门限值 ssthresh 变为呈现超时 cwnd 数值的一半,cwnd 从新设置为 1,如上图,在第 12 轮呈现超时后,cwnd 变为 1,ssthresh 变为 12。
- 快重传:在网络中如果呈现超时或者阻塞,则按慢开始和拥塞防止算法进行调整。但如果只是失落某一个报文段,如下图(图片来源于网络),则应用快重传算法。
从上图可知,接管方正确地接管到 M1 和 M2,而 M3 失落,因为没有接管到 M3,在接管方收到 M5、M6 和 M7 时,并不会进行确认,也就是不会发送 ACK。这时依据后面说的保障 TCP 可靠性传输中的序列号的作用,接管方这时不会接管 M5,M6,M7,接管方能够什么都不会,因为发送方长时间未收到 M3 的确认报文,会对 M3 进行重传。除了这样,接管方也能够反复发送 M2 的确认报文,这样发送端长时间未收到 M3 的确认报文也会持续发送 M3 报文。
** 然而依据快重传算法,要求在这种状况下,须要疾速向发送端发送 M2 的确认报文,在发送方收到三个 M2 的确认报文后,无需期待重传计时器所设置的工夫,可间接进行 M3 的重传,这就是快重传。**(面试时说这一句就够了,后面是帮忙了解)
- 快复原:从上上图圈 4 能够看到,当发送收到三个反复的 ACK,会进行快重传和快复原。快复原是指将 ssthresh 设置为产生快重传时的 cwnd 数量的一半,而 cwnd 不是设置为 1 而是设置为为门限值 ssthresh,并开始拥塞防止阶段。
TCP 的三次握手及四次挥手 ***
必考题
在介绍三次握手和四次挥手之前,先介绍一下 TCP 头部的一些常用字段。
- 序号:seq,占 32 位,用来标识从发送端到接收端发送的字节流。
- 确认号:ack,占 32 位,只有 ACK 标记位为 1 时,确认序号字段才无效,ack=seq+1。
-
标记位:
- SYN:发动一个新连贯。
- FIN:开释一个连贯。
- ACK:确认序号无效。
三次握手
三次握手的实质就是确定发送端和接收端具备收发信息的能力,在能流畅形容三次握手的流程及其中的字段含意作用的同时还须要记住每次握手时 接收端和发送端的状态。这个比拟容易疏忽。
先看一张很经典的图(图片来源于网络),发送端有 CLOSED、SYN-SENT、ESTABLISHED 三种状态,接收端有 CLOSED、LISTEN、SYN-RCVD、ESTABLISHED 四种状态。
假如发送端为客户端,接收端为服务端。开始时客户端和服务端的状态都是 CLOSE。
- 第一次握手:客户端向服务端发动建设连贯申请,客户端会随机生成一个起始序列号 x,客户端向服务端发送的字段中蕴含标记位 SYN=1,序列号 seq=100。第一次握手前客户端的状态为 CLOSE,第一次握手后客户端的状态为 SYN-SENT。此时服务端的状态为 LISTEN
- 第二次握手:服务端在收到客户端发来的报文后,会随机生成一个服务端的起始序列号 y,而后给客户端回复一段报文,其中包含标记位 SYN=1,ACK=1,序列号 seq=y,确认号 ack=x+1。第二次握手前服务端的状态为 LISTEN,第二次握手后服务端的状态为 SYN-RCVD,此时客户端的状态为 SYN-SENT。(其中 SYN= 1 示意要和客户端建设一个连贯,ACK= 1 示意确认序号无效)
- 第三次握手:客户端收到服务端发来的报文后,会再向服务端发送报文,其中蕴含标记位 ACK=1,序列号 seq=x+1,确认号 ack=y+1。第三次握手前客户端的状态为 SYN-SENT,第三次握手后客户端和服务端的状态都为 ESTABLISHED。
须要留神的一点是,第一次握手,客户端向服务端发动建设连贯报文,会占一个序列号。然而第三次握手,同样是客户端向服务端发送报文,这次却不占序列号,所以建设连贯后,客户端向服务端发送的第一个数据的序列号为 x +1。
四次挥手
和三次握手一样,先看一张十分经典的图(图片来源于网络),客户端在四次挥手过程中有 ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、TIME-WAIT、CLOSED 等五个状态,服务端有 ESTABLISHED、CLOSE-WAIT、LAST-ACK、CLOSED 等四种状态。最好记住每次挥手时服务端和客户端的状态。
假如客户端首先发动的断开连接申请
- 第一次挥手:客户端向服务端发送的数据实现后,向服务端发动开释连贯报文,报文蕴含标记位 FIN=1,序列号 seq=u。此时客户端只能接收数据,不能向服务端发送数据。
- 第二次挥手:服务端收到客户端的开释连贯报文后,向客户端发送确认报文,蕴含标记位 ACK=1,序列号 seq=v,确认号 ack=u+1。此时客户端到服务端的连贯曾经开释掉,客户端不能像服务端发送数据,服务端也不能向客户端发送数据。但服务端到客户端的单向连贯还能失常传输数据。
- 第三次挥手:服务端发送完数据后向客户端收回连贯开释报文,报文蕴含标记位 FIN=1,标记位 ACK=1,序列号 seq=w,确认号 ack=u+1。
- 第四次挥手:客户端收到服务端发送的开释连贯申请,向服务端发送确认报文,蕴含标记位 ACK=1,序列号 seq=u+1,确认号 ack=w+1。
为什么 TCP 连贯的时候是 3 次?两次是否能够?
不能够,次要从以下两方面思考(假如客户端是首先发动连贯申请):
- 假如建设 TCP 连贯仅须要两次握手,那么如果第二次握手时,服务端返回给客户端的确认报文失落了,客户端这边认为服务端没有和他建设连贯,而服务端却认为曾经和客户端建设了连贯,并且可能向服务端曾经开始向客户端发送数据,但客户端并不会接管这些数据,节约了资源。如果是三次握手,不会呈现单方连贯还未齐全建设胜利就开始发送数据的状况。
- 如果服务端接管到了一个早已生效的来自客户端的连贯申请报文,会向客户端发送确认报文批准建设 TCP 连贯。但因为客户端并不需要向服务端发送数据,所以此次 TCP 连贯没有意义并且节约了资源。
为什么 TCP 连贯的时候是 3 次,敞开的时候却是 4 次?
因为须要确保通信单方都能告诉对方开释连贯,假如客服端发送完数据向服务端发送开释连贯申请,当客服端并不知道,服务端是否曾经发送完数据,所以此次断开的是客服端到服务端的单向连贯,服务端返回给客户端确认报文后,服务端还能持续单向给客户端发送数据。当服务端发送完数据后还须要向客户端发送开释连贯申请,客户端返回确认报文,TCP 连贯彻底敞开。所以断开 TCP 连贯须要客户端和服务端别离告诉对方并别离收到确认报文,一共须要四次。
TIME_WAIT 和 CLOSE_WAIT 的区别在哪?
默认客户端首先发动断开连接申请
- 从上图能够看出,CLOSE_WAIT 是被动敞开造成的,当客户端发送 FIN 报文,服务端返回 ACK 报文后进入 CLOSE_WAIT。
- TIME_WAIT 是被动敞开造成的,当第四次挥手实现后,客户端进入 TIME_WAIT 状态。
为什么客户端收回第四次挥手的确认报文后要等 2MSL 的工夫能力开释 TCP 连贯?
MSL 的意思是报文的最长寿命,能够从两方面思考:
- 客户端发送第四次挥手中的报文后,再通过 2MSL,可使本次 TCP 连贯中的所有报文全副隐没,不会呈现在下一个 TCP 连贯中。
- 思考丢包问题,如果第四挥手发送的报文在传输过程中失落了,那么服务端没收到确认 ack 报文就会重发第三次挥手的报文。如果客户端发送完第四次挥手的确认报文后间接敞开,而这次报文又恰好失落,则会造成服务端无奈失常敞开。
如果曾经建设了连贯,然而客户端忽然呈现故障了怎么办?
如果 TCP 连贯曾经建设,在通信过程中,客户端忽然故障,那么服务端不会始终等上来,过一段时间就敞开连贯了。具体原理是 TCP 有一个保活机制,次要用在服务器端,用于检测已建设 TCP 链接的客户端的状态,避免因客户端解体或者客户端网络不可达,而服务器端始终放弃该 TCP 链接,占用服务器端的大量资源(因为 Linux 零碎中能够创立的总 TCP 链接数是有限度的)。
保活机制原理:设置 TCP 保活机制的保活工夫 keepIdle,即在 TCP 链接超过该工夫没有任何数据交互时,发送保活探测报文;设置保活探测报文的发送工夫距离 keepInterval;设置保活探测报文的总发送次数 keepCount。如果在 keepCount 次的保活探测报文均没有收到客户端的回应,则服务器端即敞开与客户端的 TCP 链接。
具体细节请看这篇博客 TCP 通信过程中异常情况整顿。
HTTP 与 HTTPS 的区别 ***
HTTP | HTTPS | |
---|---|---|
端口 | 80 | 443 |
安全性 | 无加密,安全性较差 | 有加密机制,安全性较高 |
资源耗费 | 较少 | 因为加密解决,资源耗费更多 |
是否须要证书 | 不须要 | 须要 |
协定 | 运行在 TCP 协定之上 | 运行在 SSL 协定之上,SSL 运行在 TCP 协定之上 |
什么是对称加密与非对称加密 **
- 对称加密
对称加密指加密和解密应用同一密钥,长处是运算速度快,毛病是如何平安将密钥传输给另一方。常见的对称加密算法有 DES、AES 等等。
- 非对称加密
非对称加密指的是加密和解密应用不同的密钥,一把公开的公钥,一把公有的私钥。公钥加密的信息只有私钥能力解密,私钥加密的信息只有公钥能力解密。长处解决了对称加密中存在的问题。毛病是运算速度较慢。常见的非对称加密算法有 RSA、DSA、ECC 等等。
非对称加密的工作流程:A 生成一对非堆成密钥,将公钥向所有人公开,B 拿到 A 的公钥后应用 A 的公钥对信息加密后发送给 A,通过加密的信息只有 A 手中的私钥能解密。这样 B 能够通过这种形式将本人的公钥加密后发送给 A,两方建设起通信,能够通过对方的公钥加密要发送的信息,接管方用本人的私钥解密信息。
HTTPS 的加密过程 ***
下面曾经介绍了对称加密和非对称加密的优缺点,HTTPS 是将两者联合起来,应用的对称加密和非对称加密的混合加密算法。具体做法就是应用非对称加密来传输对称密钥来保障安全性,应用对称加密来保障通信的效率。
简化的工作流程:服务端生成一对非对称密钥,将公钥发给客户端。客户端生成对称密钥,用服务端发来的公钥进行加密,加密后发给服务端。服务端收到后用私钥进行解密,失去客户端发送的对称密钥。通信单方就能够通过对称密钥进行高效地通信了。
然而认真想想这其中存在一个很大地问题,就是客户端最开始如何判断收到的这个公钥就是来自服务端而不是其他人假冒的?
这就须要证书上场了,服务端会向一个权威机构申请一个证书来证实本人的身份,到时候将证书(证书中蕴含了公钥)发给客户端就能够了,客户端收到证书后既证实了服务端的身份又拿到了公钥就能够进行下一步操作了。
HTTPS 的加密过程:
- 客户端向服务端发动第一次握手申请,通知服务端客户端所反对的 SSL 的指定版本、加密算法及密钥长度等信息。
- 服务端将本人的公钥发给数字证书认证机构,数字证书认证机构利用本人的私钥对服务器的公钥进行数字签名,并给服务器颁发公钥证书。
- 服务端将证书发给客服端。
- 客服端利用数字认证机构的公钥,向数字证书认证机构验证公钥证书上的数字签名,确认服务器公开密钥的真实性。
- 客服端应用服务端的公开密钥加密本人生成的对称密钥,发给服务端。
- 服务端收到后利用私钥解密信息,取得客户端发来的对称密钥。
- 通信单方可用对称密钥来加密解密信息。
上述流程存在的一个问题是客户端哪里来的数字认证机构的公钥,其实,在很多浏览器开发时,会内置罕用数字证书认证机构的公钥。
流程图如下:
罕用 HTTP 状态码 ***
这也是一个面试常常问的题目, 背下来就行了.
状态码 | 类别 |
---|---|
1XX | 信息性状态码 |
2XX | 胜利状态码 |
3XX | 重定向状态码 |
4XX | 客户端谬误状态码 |
5XX | 服务端谬误状态码 |
常见的 HTTP 状态码
1XX
- 100 Continue:示意失常,客户端能够持续发送申请
- 101 Switching Protocols:切换协定,服务器依据客户端的申请切换协定。
2XX
- 200 OK:申请胜利
- 201 Created:已创立,示意胜利申请并创立了新的资源
- 202 Accepted:已承受,已承受申请,但未解决实现。
- 204 No Content:无内容,服务器胜利解决,但未返回内容。
- 205 Reset Content:重置内容,服务器解决胜利,客户端应重置文档视图。
- 206 Partial Content:示意客户端进行了范畴申请,响应报文应蕴含 Content-Range 指定范畴的实体内容
3XX
- 301 Moved Permanently:永久性重定向
- 302 Found:长期重定向
- 303 See Other:和 301 性能相似,但要求客户端采纳 get 办法获取资源
- 304 Not Modified:所申请的资源未修改,服务器返回此状态码时,不会返回任何资源。
- 305 Use Proxy:所申请的资源必须通过代理拜访
- 307 Temporary Redirect:长期重定向,与 302 相似,要求应用 get 申请重定向。
4XX
- 400 Bad Request:客户端申请的语法错误,服务器无奈了解。
- 401 Unauthorized:示意发送的申请须要有认证信息。
- 403 Forbidden:服务器了解用户的申请,然而拒绝执行该申请
- 404 Not Found:服务器无奈依据客户端的申请找到资源。
- 405 Method Not Allowed:客户端申请中的办法被禁止
- 406 Not Acceptable:服务器无奈依据客户端申请的内容个性实现申请
- 408 Request Time-out:服务器期待客户端发送的申请工夫过长,超时
5XX
- 500 Internal Server Error:服务器外部谬误,无奈实现申请
- 501 Not Implemented:服务器不反对申请的性能,无奈实现申请
常见的 HTTP 办法 ***
办法 | 作用 |
---|---|
GET | 获取资源 |
POST | 传输实体主体 |
PUT | 上传文件 |
DELETE | 删除文件 |
HEAD | 和 GET 办法相似,但只返回报文首部,不返回报文实体主体局部 |
PATCH | 对资源进行局部批改 |
OPTIONS | 查问指定的 URL 反对的办法 |
CONNECT | 要求用隧道协定连贯代理 |
TRACE | 服务器会将通信门路返回给客户端 |
为了不便记忆,能够将 PUT、DELETE、POST、GET 了解为客户端对服务端的增删改查。
- PUT:上传文件,向服务器增加数据,能够看作增
- DELETE:删除文件
- POST:传输数据,向服务器提交数据,对服务器数据进行更新。
- GET:获取资源,查问服务器资源
GET 和 POST 区别 ***
- 作用
GET 用于获取资源,POST 用于传输实体主体
- 参数地位
GET 的参数放在 URL 中,POST 的参数存储在实体主体中,并且 GET 办法提交的申请的 URL 中的数据做多是 2048 字节,POST 申请没有大小限度。
- 安全性
GET 办法因为参数放在 URL 中,安全性绝对于 POST 较差一些
- 幂等性
GET 办法是具备幂等性的,而 POST 办法不具备幂等性。这里幂等性指客户端间断收回屡次申请,收到的后果都是一样的.
HTTP 1.0、HTTP 1.1 及 HTTP 2.0 的次要区别是什么 **
HTTP 1.0 和 HTTP 1.1 的区别
- 长连贯
HTTP 1.1 反对长连贯和申请的流水线操作。长连贯是指不在须要每次申请都从新建设一次连贯,HTTP 1.0 默认应用短连贯,每次申请都要从新建设一次 TCP 连贯,资源耗费较大。申请的流水线操作是指客户端在收到 HTTP 的响应报文之前能够先发送新的申请报文,不反对申请的流水线操作须要等到收到 HTTP 的响应报文后能力持续发送新的申请报文。
- 缓存解决
在 HTTP 1.0 中次要应用 header 中的 If-Modified-Since,Expires 作为缓存判断的规范,HTTP 1.1 引入了 Entity tag,If-Unmodified-Since, If-Match 等更多可供选择的缓存头来管制缓存策略。
- 谬误状态码
在 HTTP 1.1 新增了 24 个谬误状态响应码
- HOST 域
在 HTTP 1.0 中认为每台服务器都会绑定惟一的 IP 地址,所以,申请中的 URL 并没有传递主机名。但起初一台服务器上可能存在多个虚拟机,它们共享一个 IP 地址,所以 HTTP 1.1 中申请音讯和响应音讯都应该反对 Host 域。
- 带宽优化及网络连接的应用
在 HTTP 1.0 中会存在节约带宽的景象,次要是因为不反对断点续传性能,客户端只是须要某个对象的一部分,服务端却将整个对象都传了过去。在 HTTP 1.1 中申请头引入了 range 头域,它反对只申请资源的某个局部,返回的状态码为 206。
HTTP 2.0 的新个性
- 新的二进制格局:HTTP 1.x 的解析是基于文本,HTTP 2.0 的解析采纳二进制,实现不便,健壮性更好。
- 多路复用:每一个 request 对应一个 id,一个连贯上能够有多个 request,每个连贯的 request 能够随机混在一起,这样接管方能够依据 request 的 id 将 request 归属到各自不同的服务端申请里。
- header 压缩:在 HTTP 1.x 中,header 携带大量信息,并且每次都须要从新发送,HTTP 2.0 采纳编码的形式减小了 header 的大小,同时通信单方各自缓存一份 header fields 表,防止了 header 的反复传输。
- 服务端推送:客户端在申请一个资源时,会把相干资源一起发给客户端,这样客户端就不须要再次发动申请。
Session、Cookie 和 Token 的次要区别 ***
HTTP 协定是无状态的,即服务器无奈判断用户身份。Session 和 Cookie 能够用来进行身份识别。
- Cookie
Cookie 是保留在客户端一个小数据块,其中蕴含了用户信息。当客户端向服务端发动申请,服务端会像客户端浏览器发送一个 Cookie,客户端会把 Cookie 存起来,当下次客户端再次申请服务端时,会携带上这个 Cookie,服务端会通过这个 Cookie 来确定身份。
- Session
Session 是通过 Cookie 实现的,和 Cookie 不同的是,Session 是存在服务端的。当客户端浏览器第一次拜访服务器时,服务器会为浏览器创立一个 sessionid,将 sessionid 放到 Cookie 中,存在客户端浏览器。比方浏览器拜访的是购物网站,将一本《图解 HTTP》放到了购物车,当浏览器再次拜访服务器时,服务器会取出 Cookie 中的 sessionid,并依据 sessionid 获取会话中的存储的信息,确认浏览器的身份是上次将《图解 HTTP》放入到购物车那个用户。
-
Token
客户端在浏览器第一次拜访服务端时,服务端生成的一串字符串作为 Token 发给客户端浏览器,下次浏览器在拜访服务端时携带 token 即可无需验证用户名和明码,省下来大量的资源开销。看到这里很多人感觉这不是和 sessionid 作用一样吗?其实是不一样的,然而本文章次要针对面试,知识点很多,篇幅无限,几句话也解释不分明,大家能够看看这篇文章,我感觉说的十分分明了。cookie、session 与 token 的真正区别
上面为了不便记忆,做了一个表格进行比照。
寄存地位 占用空间 安全性 利用场景 Cookie 客户端浏览器 小 较低 个别寄存配置信息 Session 服务端 多 较高 寄存较为重要的信息
如果客户端禁止 cookie 能实现 session 还能用吗?*
能够,Session 的作用是在服务端来放弃状态,通过 sessionid 来进行确认身份,但 sessionid 个别是通过 Cookie 来进行传递的。如果 Cooike 被禁用了,能够通过在 URL 中传递 sessionid。
在浏览器中输⼊ url 地址到显示主⻚的过程 ***
面试超高频的一道题,个别能说分明流程就能够。
- 对输出到浏览器的 url 进行 DNS 解析,将域名转换为 IP 地址。
- 和目标服务器建设 TCP 连贯
- 向目标服务器发送 HTTP 申请
- 服务器解决申请并返回 HTTP 报文
- 浏览器解析并渲染页面
Servlet 是线程平安的吗 *
Servlet 不是线程平安的,多线程的读写会导致数据不同步的问题。