小林计算机网络|面试必背总结篇
HTTP返回状态301 302分别是什么?
3xx 类状态码表示客户端请求的资源发生了变动,需要客户端用新的URL重新发送请求获取资源,也就是重定向。
• 「301 Moved Permanently」表示永久重定向,说明请求的资源已经不存在了,需改用新的 URL 再次访问。
• 「302Found」表示临时重定向,说明请求的资源还在,但暂时需要用另一个 URL 来访问。
http 502和 504 的区别?
- 502 Bad Gateway:作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
- 504 Gateway Time-out:作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器收到响应。
502 Bad Gateway(浏览器看到的)
- 你在浏览器输入网址,发送请求
- 请求先到Nginx /网关
- 网关把请求转给后端服务器
- 后端服务器返回了一个错误 / 无效 / 崩溃的响应
- 网关看不懂这个响应
- 网关给浏览器返回:502
👉 关键:后端有响应,但响应无效
504 Gateway Timeout(浏览器看到的)
- 你在浏览器输入网址,发送请求
- 请求先到Nginx /网关
- 网关把请求转给后端服务器
- 后端服务器一直不回数据
- 网关等超时了
- 网关给浏览器返回:504
👉 关键:后端完全没响应,超时了
HTTP层请求的类型有哪些?
HTTPS握手过程说一下
TLS第一次握手
首先,由客户端向服务器发起加密通信请求,也就是 ClientHello 请求。
发送以下信息:
- 客户端支持的 TLS 协议版本
- 客户端生产的随机数(Client Random),后面用于生成「会话秘钥」条件之一。
- 客户端支持的密码套件列表,如 RSA 加密算法。
TLS第二次握手
服务器收到客户端请求后,向客户端发出响应,也就是 SeverHello。
发送以下信息:
- 确认 TLS 协议版本,如果浏览器不支持,则关闭加密通信。
- 服务器生产的随机数(Server Random),也是后面用于生产「会话秘钥」条件之一。
- 确认的密码套件列表,如 RSA 加密算法。
- 服务器的数字证书。
TLS第三次握手
客户端收到服务器的回应之后,首先通过浏览器或者操作系统中的CA公钥,确认服务器的数字证书的真实性。
如果证书没有问题,客户端会从数字证书中取出服务器的公钥,然后使用它加密报文,
发送以下信息:
- 一个随机数(pre-master key)。该随机数会被服务器公钥加密。
- 加密通信算法改变通知,表示随后的信息都将用「会话秘钥」加密通信。
- 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供服务端校验。
TLS第四次握手
服务器收到客户端的第三个随机数(pre-master key)之后,通过协商的加密算法,计算出本次通信的「会话秘钥」。
发送以下信息:
- 加密通信算法改变通知,表示随后的信息都将用「会话秘钥」加密通信。
- 服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供客户端校验。
至此,整个 TLS 的握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的 HTTP 协议,只不过用「会话秘钥」加密内容。
HTTPS是如何防范中间人的攻击?
主要通过加密和身份校验机制来防范中间人攻击的:
- 加密:https 握手期间会通过非对称加密(服务器公钥(RSA))的方式来协商出对称加密密钥(会话密钥)。
- 身份校验:服务器会向证书颁发机构申请数字证书,证书中包含了服务器的公钥和其他相关信息。当客户端与服务器建立连接时,服务器会将证书发送给客户端。客户端会验证证书的合法性,包括检查证书的有效期、颁发机构的信任等。如果验证通过,客户端会使用证书中的公钥来加密通信数据,并将加密后的数据发送给服务器,然后由服务端用私钥解密。
Http1.1和2.0的区别是什么?
HTTP/2 相比 HTTP/1.1 性能上的改进:
- 头部压缩:HTTP/2会压缩头(Header)如果你同时发出多个请求,他们的头是一样的或是相似的,那么,协议会帮你消除重复的部分。这就是所谓的 HPACK 算法:在客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
- 二进制格式:HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文,而是全面采用了二进制格式,头信息和数据体都是二进制,并且统称为帧(frame):头信息帧(Headers Frame)和数据帧(Data Frame)。这样虽然对人不友好,但是对计算机非常友好,因为计算机只懂二进制,那么收到报文后,无需再将明文的报文转成二进制,而是直接解析二进制报文,这增加了数据传输的效率。
- 并发传输:引出了Stream 概念,多个 Stream 复用在一条TCP连接。解决了HTTP/1.1队头阻塞的问题
- 服务器主动推送资源:HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式,服务端不再是被动地响应,可以主动向客户端发送消息。
HTTP进行TCP连接之后,在什么情况下会中断?
- 当服务端或者客户端执行 close 系统调用的时候,会发送FIN报文,就会进行四次挥手的过程
- 当发送方发送了数据之后,接收方超过一段时间没有响应ACK报文,发送方重传数据达到最大次数的时候,就会断开TCP连接
- 当HTTP长时间没有进行请求和响应的时候,超过一定的时间,就会释放连接
1。客户端和服务端执行close系统调用的时候,就是进行四次挥手的过程
- 发送方发送了数据,接收方超过一段时间没有响应ACK报文,发送方重试达到最大次数,就会断开连接
- http长时间没有进行连接和响应,会自动断开
HTTP、SOCKET和TCP的区别
- HTTP是应用层协议,定义了客户端和服务器之间交换的数据格式和规则;
- Socket是通信的一端,提供了网络通信的接口;
- TCP是传输层协议,负责在网络中建立可靠的数据传输连接。它们在网络通信中扮演不同的角色和层次。
- HTTP是一种用于传输超文本数据的应用层协议,用于在客户端和服务器之间传输和显示Web页面。
- Socket是计算机网络中的一种抽象,用于描述通信链路的一端,提供了底层的通信接口,可实现不同计算机之间的数据交换。
- TCP是一种面向连接的、可靠的传输层协议,负责在通信的两端之间建立可靠的数据传输连接。
DNS的全称了解么?
DNS的全称是Domain Name System(域名系统),它是互联网中用于将域名转换为对应IP地址的分布式数据库系统
DNS 中的域名都是用句点来分隔的,比如 www.server.com,这里的句点代表了不同层次之间的界限。
越靠右的位置表示其层级越高。
域名的层级关系类似一个树状结构:
- 根 DNS 服务器(.)
- 顶级域 DNS 服务器(.com)
- 权威 DNS 服务器(server.com)
根域的 DNS 服务器信息保存在互联网中所有的 DNS 服务器中。
这样一来,任何 DNS 服务器就都可以找到并访问根域 DNS 服务器了。
DNS 域名解析的工作流程?
- 客户端首先会发出一个 DNS 请求,问 www.server.com 的 IP 是啥,并发给本地 DNS 服务器(也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址)。
- 本地域名服务器收到客户端的请求后,如果缓存里的表格能找到 www.server.com,则它直接返回 IP 地址。如果没有,本地 DNS会找到它的根域名服务器:
- 根 DNS 收到来自本地 DNS 的请求后,发现后置是 .com,找到 .com 顶级域名服务器
- 顶级域名服务器中找到权威 DNS 服务器
- 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
- 本地 DNS 再将 IP 地址返回客户端,客户端和目标建立连接。
DNS的端口是多少?
默认端口号是53
DNS的底层使用TCP还是UDP?
DNS 基于UDP协议实现,DNS使用UDP协议进行域名解析和数据传输。因为基于UDP实现DNS能够提供低延迟、简单快速、轻量级的特性,更适合DNS这种需要快速响应的域名解析服务。
• 低延迟:UDP是一种无连接的协议,不需要在数据传输前建立连接,因此可以减少传输时延,适合DNS这种需要快速响应的应用场景。
• 简单快速:UDP相比于TCP更简单,没有TCP的连接管理和流量控制机制,传输效率更高,适合DNS这种需要快速传输数据的场景。
• 轻量级:UDP头部较小,占用较少的网络资源,对于小型请求和响应来说更加轻量级,适合DNS这种频繁且短小的数据交换。
HTTP到底是不是无状态的?
HTTP是无状态的,这意味着每个请求都是独立的,服务器不会在多个请求之间保留关于客户端状态的信息。在每个HTTP请求中,服务器不会记住之前的请求或会话状态,因此每个请求都是相互独立的。
可以通过一些机制来实现状态保持,其中最常见的方式是使用Cookie和Session来跟踪用户状态。
携带Cookie的HTTP请求是有状态还是无状态的?Cookie是HTTP协议簇的一部分,那为什么还说HTTP是无状态的?
携带Cookie的HTTP请求实际上是可以在一定程度上实现状态保持的,因为Cookie是用来在客户端存储会话信息和状态信息的一种机制。当浏览器发送包含Cookie的HTTP请求时,服务器可以通过读取这些Cookie来识别用户、管理会话状态以及保持特定的用户状态。因此,可以说即使HTTP本身是无状态的协议,但通过Cookie的使用可以实现一定程度的状态保持功能。
虽然Cookie是HTTP协议簇的一部分,但是HTTP协议在设计初衷上仍然保持无状态特性,即每个请求都是相互独立的(服务器并不保存关于客户端的状态信息)。使用Cookie只是在无状态协议下的一种补充机制,用于在客户端存储状态信息以实现状态保持。
cookie和session有什么区别?
- **存储位置**:
- Cookie的数据存储在客户端(通常是浏览器)。当浏览器向服务器发送请求时,会自动附带Cookie中的数据。
- Session的数据存储在服务器端。服务器为每个用户分配一个唯一的Session ID,这个ID通常通过Cookie或URL重写的方式发送给客户端,客户端后续的请求会带上这个Session ID,服务器根据ID查找对应的Session数据。
- **数据容量:**
- 单个Cookie的大小限制通常在4KB左右,而且大多数浏览器对每个域名的总Cookie数量也有限制.
- Session存储在服务器上,理论上不受数据大小的限制,主要受限于服务器的内存大小。
- **安全性:**
- Cookie相对不安全,因为数据存储在客户端,容易受到XSS(跨站脚本攻击)的威胁。不过,可以通过设置HttpOnly属性来防止JavaScript访问,减少XSS攻击的风险,但仍然可能受到CSRF(跨站请求伪造)的攻击。
- Session通常认为比Cookie更安全,因为敏感数据存储在服务器端。但仍然需要防范Session劫持(通过获取他人的Session ID)和会话固定攻击。
- **生命周期:**
- Cookie可以设置过期时间,过期后自动删除。也可以设置为会话Cookie,即浏览器关闭时自动删除。
- Session在默认情况下,当用户关闭浏览器时,Session结束。但服务器也可以设置Session的超时时间,超过这个时间未活动,Session也会失效。
- **性能:**
- 使用Cookie时,每个请求都会带Cookie发送到服务器,Cookie数据较大时可能会影响网络传输效率
- 使用Session时,因为数据存储在服务器端,高并发的查询服务器上的Session数据,这可能会增加服务器的负载,特别是在高并发场景下。
token,session,cookie的区别?
- cookie类似一个令牌,存储在客户端,装有sessionId,浏览器通常会自动添加。
- session存储于服务器,可以理解为一个状态列表,拥有一个唯一识别符号sessionId,通常存放于cookie中。服务器收到cookie后解析出sessionId,再去session列表中查找,才能找到相应session,依赖cookie。
- token也类似一个令牌,无状态,用户信息都被加密到token中,服务器收到token后解密就可知道是哪个用户,需要开发者手动添加。
如果客户端禁用了cookie,session还能用吗?
默认情况下禁用Cookie后,Session 是无法正常使用的,
为什么?
客户端浏览器禁用 Cookie 时,服务器将无法把会话 ID 发送给客户端,客户端也无法在后续请求中携带会话 ID 返回给服务器,从而导致服务器无法识别用户会话。
解决方法:
- **URL重写:每次请求时,将Session ID附加到URL中作为参数。例如,原本的链接http://example.com/page变为http://example.com/page;jsessionid=XXXXXX,服务器端需要相应地解析 URL 来获取 Session ID,并维护用户的会话状态。
- 这种方式的缺点是URL变得不那么整洁,且如果用户通过电子邮件或其他方式分享了这样的链接,可能导致Session ID的意外泄露。
- 隐藏表单字段:在HTML表单中包含一个隐藏字段,用来存储Session ID。当表单提交时,Session ID随表单数据一起发送回服务器,服务器通过解析表单数据中的 Session ID 来获取用户的会话状态。
- 这种方法仅适用于通过表单提交的交互模式,不适合链接点击或Ajax请求。
如果我把数据存储到 localStorage,和Cookie有什么区别?
- 存储容量:
- Cookie的存储容量通常较小,每个 Cookie 的大小限制在几 KB 左右。
- LocalStorage 的存储容量通常较大,一般限制在几 MB 左右。因此,如果需要存储大量数据,LocalStorage 通常更适合;
- 数据发送:
- Cookie在每次 HTTP 请求中都会自动发送到服务器,这使得 Cookie 适合用于在客户端和服务器之间传递数据。
- localStorage 的数据不会自动发送到服务器,它仅在浏览器端存储数据,因此 LocalStorage适合用于在同一域名下的不同页面之间共享数据;
- 生命周期:
- Cookie可以设置一个过期时间,使得数据在指定时间后自动过期。
- LocalStorage 的数据将永久存储在浏览器中,除非通过 JavaScript 代码手动删除;
- 安全性:
- Cookie的安全性较低,因为 Cookie 在每次 HTTP 请求中都会自动发送到服务器,存在被窃取或篡改的风险
- LocalStorage 的数据仅在浏览器端存储,不会自动发送到服务器,相对而言更安全一些;
什么数据应该存在到cookie,什么数据存放到 Localstorage
Cookie 适合用于在客户端和服务器之间传递数据、跨域访问和设置过期时间,
LocalStorage 适合用于在同一域名下的不同页面之间共享数据、存储大量数据和永久存储数据。
JWT 令牌和传统方式有什么区别?
- 无状态性:JWT是无状态的令牌,不需要在服务器端存储会话信息。相反,JWT令牌中包含了所有必要的信息,如用户身份、权限等。这使得JWT在分布式系统中更加适用,可以方便地进行扩展和跨域访问。
- 安全性:JWT使用密钥对令牌进行签名,确保令牌的完整性和真实性。只有持有正确密钥的服务器才能对令牌进行验证和解析。这种方式比传统的基于会话和Cookie的验证更加安全,有效防止了CSRF(跨站请求伪造)等攻击。
- 跨域支持:JWT令牌可以在不同域之间传递,适用于跨域访问的场景。通过在请求的头部或参数中携带JWT令牌,可以实现无需Cookie的跨域身份验证。
1.jwt是无状态的令牌,不需要服务器存储会话信息。jwt 包含了所有必要的信息
2.jwt使用密钥进行签名的,只有持有密钥的服务器才能正确解密
3.jwt支持跨域
JWT 令牌都有哪些字段?( 没答上来,忘了有哪些,没想到会问)
JWT令牌由三个部分组成:头部(Header)、载荷(Payload)和签名(Signature)。其中,头部和载荷均为JSON格式,使用Base64编码进行序列化,而签名部分是对头部、载荷和密钥进行签名后的结果。
JWT 令牌为什么能解决集群部署,什么是集群部署?( 答上来了)
在传统的基于会话和Cookie的身份验证方式中,会话信息通常存储在服务器的内存或数据库中。但在集群部署中,不同服务器之间没有共享的会话信息,这会导致用户在不同服务器之间切换时需要重新登录,或者需要引入额外的共享机制(如Redis),增加了复杂性和性能开销。
而JWT令牌通过在令牌中包含所有必要的身份验证和会话信息,使得服务器无需存储会话信息,从而解决了集群部署中的身份验证和会话管理问题。当用户进行登录认证后,服务器将生成一个JWT令牌并返回给客户端。客户端在后续的请求中携带该令牌,服务器可以通过对令牌进行验证和解析来获取用户身份和权限信息,而无需访问共享的会话存储。
就是传统的基于会话和Cookie的身份验证方式中,会话都是存储在服务器上的,在集群模式下,不同的服务器没有共享会话信息,导致用户在不同服务器之间切换时需要重新登录
而jwt令牌包含了所有的身份信息和会话信息,服务器不需要存储会话信息,解决了集群部署中的身份验证和会话管理问题。用户进行登录认证后,服务器将生成一个JWT令牌并返回给客户端。客户端在后续的请求中携带该令牌,服务器可以通过对令牌进行验证和解析来获取用户身份和权限信息,而无需访问共享的会话存储。
jwt的缺点是什么?
JWT 一旦派发出去,在失效之前都是有效的,没办法即使撤销JWT。
解决方法:
使用内存数据库比如 Redis 维护一个黑名单,如果想让某个 JWT 失效的话就直接将这个 JWT 加入到 黑名单 即可。然后,每次使用 JWT 进行请求的话都会先判断这个 JWT 是否存在于黑名单中。
JWT 令牌如果泄露了,怎么解决,JWT是怎么做的?
- 及时失效令牌:当检测到JWT令牌泄露或存在风险时,可以立即将令牌标记为失效状态。服务器在接收到带有失效标记的令牌时,会拒绝对其进行任何操作,从而保护用户的身份和数据安全。
- 刷新令牌:JWT令牌通常具有一定的有效期,过期后需要重新获取新的令牌。当检测到令牌泄露时,可以主动刷新令牌,即重新生成一个新的令牌,并将旧令牌标记为失效状态。这样,即使泄露的令牌被恶意使用,也会很快失效,减少了被攻击者滥用的风险。
- 使用黑名单:服务器可以维护一个令牌的黑名单,将泄露的令牌添加到黑名单中。在接收到令牌时,先检查令牌是否在黑名单中,如果在则拒绝操作。这种方法需要服务器维护黑名单的状态,对性能有一定的影响,但可以有效地保护泄露的令牌不被滥用。
简记:
- 及时失效令牌:立即将令牌标记为失效状态,
- 刷新令牌,获取新的令牌,将旧令牌标记为失效状态
- 将泄露的令牌添加到黑名单中
前端是如何存储JWT的?
客户端收到服务器返回的 JWT,可以储存在Local Storage里面,也可以储存在Cookie里面,还可以存储在Session Storage里面。下面将说明存在上述各个地方的优劣势:
Local Storage(本地存储):
- 优点:Local Storage提供了较大的存储空间(一般为5MB),且不会随着HTTP请求一起发送到服务器,因此不会出现在HTTP缓存或日志中。
- 缺点:存在XSS(跨站脚本攻击)的风险,恶意脚本可以通过JavaScript访问到存储在Local Storage中的JWT,从而盗取用户凭证。
Session Storage(会话存储):
- 优点:与Local Storage类似,但仅限于当前浏览器窗口或标签页,当窗口关闭后数据会被清除,这在一定程度上减少了数据泄露的风险。
- 缺点:用户体验可能受影响,因为刷新页面或在新标签页打开相同应用时需要重新认证。
Cookie:
- 优点:可以设置HttpOnly标志来防止通过JavaScript访问,减少XSS攻击的风险;可以利用Secure标志确保仅通过HTTPS发送,增加安全性。
- 缺点:大小限制较小(通常4KB),并且每次HTTP请求都会携带Cookie,可能影响性能;设置不当可能会受到CSRF(跨站请求伪造)攻击。
为什么有HTTP协议了?还要用RPC?
- RPC 本质上不算是协议,而是一种调用方式。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式,不一定非得基于 TCP 协议。
- 对外一般用 HTTP 协议,而内部集群的微服务之间则采用 RPC 协议进行通讯。
- RPC其实比 HTTP 出现的要早,且比目前主流的 HTTP/1.1 性能要更好,所以大部分公司内部都还在使用 RPC。
HTTP长连接与WebSocket有什么区别?
- 全双工和半双工: http是半双工协议的,WebSocket 是全双工协议,
- TCP 协议本身是全双工的,但我们最常用的 HTTP/1.1,虽然是基于 TCP 的协议,但它是半双工的,对于大部分需要服务器主动推送数据到客户端的场景,都不太友好,因此我们需要使用支持全双工的 WebSocket 协议。
- 应用场景区别:在HTTP/1.1里,只要客户端不问,服务端就不答。基于这样的特点,对于登录页面这样的简单场景,可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。对于客户端和服务端之间需要频繁交互的复杂场景,比如网页游戏,都可以考虑使用WebSocket 协议。
Nginx有哪些负载均衡算法?
- 轮询:按照顺序依次将请求分配给后端服务器。这种算法最简单,但是也无法处理某个节点变慢或者客户端操作有连续性的情况。
- IP哈希:根据客户端IP地址的哈希值来确定分配请求的后端服务器。适用于需要保持同一客户端的请求始终发送到同一台后端服务器的场景,如会话保持。
- URL哈希:按访问的URL的哈希结果来分配请求,使每个URL定向到一台后端服务器,可以进一步提高后端缓存服务器的效率。
- 最短响应时间:按照后端服务器的响应时间来分配请求,响应时间短的优先分配。适用于后端服务器性能不均的场景,能够将请求发送到响应时间快的服务器,实现负载均衡
- 加权轮询:按照权重分配请求给后端服务器,权重越高的服务器获得更多的请求。适用于后端服务器性能不同的场景,可以根据服务器权重分配请求,提高高性能服务器的利用率
Nginx位于七层网络结构中的哪一层?
应用层,nginx 是七层负载均衡。
