Day5 - 前端高频面试题之计算机网络相关

1、请介绍一下HTTPHTTPS的区别?

HTTPS是在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密(在传输层)

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

  1. HTTPS协议需要到CA申请证书或自制证书

  2. HTTP的信息是明文传输;

    HTTPS则是具有安全性的ssl加密

  3. HTTP是直接与TCP进行数据传输;

    HTTPS运行在SSL/TLS(安全传输层协议)之上,SSL/TLS运行在TCP之上,用的端口也不一样,前者是80(需要国内备案),后者是443

  4. HTTP的连接很简单,是无状态的;

    HTTPS协议是由SSL+HTTP协议构建的,可进行加密传输、身份认证的网络协议,比HTTP协议安全

2、HTTP2HTTP1.x相比的新特性有哪些?

1、HTTP2使用的是新的二进制格式传送,HTTP1.X是文本(字符串)传送。二进制协议解析起来更高效

2、HTTP2支持多路复用,即连接共享。

即 同一域名下,同一TCP连接可以并发处理多个HTTP请求;单个连接上可以并行的请求与响应,互不干扰

HTTP2.0多路复用有多好?

HTTP 性能优化的关键并不在于高带宽,而是低延迟。TCP 连接会随着时间进行自我「调谐」,起初会限制连接的最大速度,如果数据成功传输,会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因,让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
HTTP/2通过让所有数据流共用同一个连接,可以更有效地使用 TCP 连接,让高带宽也能真正的服务于 HTTP 的性能提升。

3、HTTP2头部压缩,通过gzipcompress压缩头部然后再发送,既避免了重复header的传输,又减小了需要传输的大小。

4、HTTP2支持服务器推送。

3、请介绍一下TCP与UDP的区别,TCP的可靠性如何保证?

UDP是面向无连接的,不可靠的数据报服务;

TCP是面向连接的,可靠的字节流服务。

TCP的可靠性是通过顺序编号和确认(ACK)来实现的。

4、为什么TCP连接需要三次握手?为什么要四次挥手?画出TCP三次握手和四次挥手的全过程(并且标注ack确认号 和 seq序列号的值)

三次握手是客户端向服务器发请求,服务器接收请求,服务器接收请求之后发送一个连接标志,客户端接收连接标志之后也向服务器发送一个连接标志,至此连接完成,这是为了保证建立一个可靠的连接;

为什么一定要三次握手呢?考虑一下这种情况:

client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。

假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。

采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”。主要目的防止server端一直等待,浪费资源。

四次挥手的作用就是断开连接,之所以要断开连接是因为TCP/IP协议是要占用端口的,而计算机的端口是有限的,所以一次传输完成之后是要断开连接的;

为什么四次断开?

因为TCP有个半关闭状态,假设A.B要释放连接,那么A发送一个释放连接报文给B,B收到后发送确认,这个时候A不发数据,但是B如果发数据A还是要接受,这叫半关闭。

然后B还要发给A连接释放报文,然后A发确认,所以是4次。

  • 第一次握手:主机A发往主机B,主机A初始序号是X,设置SYN(同步)位,未设置ACK(确认)位
  • 第二次握手:主机B发往主机A,主机B初始序号是Y,ACK(确认号)是X+1,X+1暗示已经收到主机A发来主机B的同步序号。设置ACK位和SYN位
  • 第三次握手:主机A发往主机B,主机A初始序号是X+1,ACK是Y+1,Y+1暗示已经收到主机A发来主机B的同步序号。设置ACK位,未设置SYN位。
5、HTTP中,POST与GET的区别

1、用途不同:Get是从服务器上获取数据,Post是向服务器传送数据

2、数据传输方式不同:GET请求通过URL传输数据,而POST的数据通过请求体传输

3、传输数据量限制不同:Get传送的数据量小,不能大于2KB (因为浏览器对URL的长度有限制);post传送的数据量较大,一般被默认为不受限制

4、GET的数据在URL中,通过历史记录,缓存很容易查到数据信息,相对来说是不安全的;POST的数据在请求主体内,所以有一定的安全性保证

5、GET是安全(这里的安全是指只读特性,就是使用这个方法不会引起服务器状态变化)且幂等(指同一个请求方法执行多次和仅执行一次的效果完全相同),而POST是非安全非幂等

6、HTTP的长连接和短连接分别是什么?你知道keep-alive是干什么的吗?

HTTP的长连接和短连接实际上是TCP的长连接和短连接,HTTP属于应用层协议。

**短连接:**浏览器和服务器每进行一次HTPP操作,就建立一个连接,但任务结束就会中断这个连接

**长连接:**HTTP1.1规定了默认保持长连接,也称为持久连接。

意思就是,数据传输完成了保持TCP连接不断开(不发RST包、不四次握手),等待在同域名下继续用这个通道传输数据。

长连接好处:

  1. 同一个客户端可以使用这个长连接处理其他请求,避免HTTP重新连接和断开所消耗的时间;
  2. 服务器可以利用这个连接 主动推送 消息到客户端(重要的)。

HTTP头部有了Connection: Keep-Alive这个值,代表客户端期望这次请求是长连接的。但是并不代表一定会使用长连接,服务器端都可以无视这个值,也就是不按标准来。实现长连接要客户端和服务端都支持长连接。

keep-alive的优点:

  • 较少的CPU和内存的使用(由于同时打开的连接的减少了)
  • 允许请求和应答的HTTP管线化
  • 降低拥塞控制 (TCP连接减少了)
  • 减少了后续请求的延迟(无需再进行握手)
  • 报告错误无需关闭TCP连接
7、HTTP Request Header和Response Header里面分别都有哪些比较重要的字段?

**通用首部字段:**请求报文和响应报文两方都会使用的首部

  • Cache-Control 告诉所有的缓存机制是否可以缓存及哪种类型 (Cache-Control: no-cache )
  • Connection 表明是否需要持久连接 (Connection: keep-alive)
  • Transfer-Encoding 文件传输编码 ( Transfer-Encoding:chunked)

Request Header:

  • Accept 指定客户端能够接收的内容类型,内容类型中的先后次序表示客户端接收的先后次序 (Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.8,image/png,/;q=0.5)
  • Range 实体的字节范围请求
  • Authorization web的认证信息
  • Host 请求资源所在服务器
  • User-Agent 客户端程序信息

Response Header:

  • Location 令客户端重定向的URI
  • ETag 能够表示资源唯一资源的字符串
  • Server 服务器的信息

实体首部字段:(Entity头域)

  • Last-Modified 请求资源的最后修改时间
  • Expires 响应过期的日期和时间
  • Allow 资源可支持http请求的方法,不允许则返回405
  • Content-Type 返回内容的媒体类型 Content-Type: text/html; charset=utf-8
// 典型的请求消息: 

GET http://download.google.com/somedata.exe 
Host: download.google.com
Accept:*/* 
Pragma: no-cache 
Cache-Control: no-cache 
Referer: http://download.google.com/ 
User-Agent:Mozilla/4.04[en](Win95;I;Nav) 
Range:bytes=554554-

// 典型的响应消息: 

HTTP/1.0200OK 
Date:Mon,31Dec200104:25:57GMT 
Server:Apache/1.3.14(Unix) 
Content-type:text/html 
Last-modified:Tue,17Apr200106:46:28GMT 
Etag:"a030f020ac7c01:1e9f" 
Content-length:39725426 

8、说说你所知道的web安全及防护措施?

对Web应用的攻击模式有以下两种:主动攻击和被动攻击

  • XSS(Cross-Site Scripting, 跨站脚本攻击 )(被动攻击)

    • 是最常见和基本的攻击 WEB 网站方法,攻击者通过注入非法的 html 标签或者 javascript 代码,从而当用户浏览该网页时,控制用户浏览器。

    • 影响:利用虚假输入表单骗取用户个人信息;利用脚本窃取用户的Cookie值

    • 防御:

      1. httpOnly: 在 cookie 中设置 HttpOnly 属性,使js脚本无法读取到 cookie 信息
      2. 前端负责输入检查,后端也要做相同的过滤检查
      3. 某些情况下,不能对用户数据进行严格过滤时,需要对标签进行转换
  • CSRF (Cross-Site Request Forgeries, 跨站请求伪造)(被动攻击)

    • 冒充用户发起请求(在用户不知情的情况下), 完成一些违背用户意愿的事情
    • 本质:重要操作的所有参数都是可以被攻击者猜测到的。攻击者预测出URL的所有参数与参数值,就能成功地构造一个伪造的请求
    • 影响:利用已通过认证的用户权限更新设定信息、购买商品、在留言板上发表言论等
    • 防御:
      1. 验证码;强制用户必须与应用进行交互,才能完成最终请求
      2. 尽量使用 post ,限制 get 使用;get 太容易被拿来做 csrf 攻击
      3. 请求来源限制,此种方法成本最低,但是并不能保证 100% 有效,因为服务器并不是什么时候都能取到 Referer,而且低版本的浏览器存在伪造 Referer 的风险
      4. token 验证 CSRF 防御机制是公认最合适的方案
    • 使用token的原理:
      1. 第一步:后端随机产生一个 token,把这个token 保存到 session 状态中;同时后端把这个token 交给前端页面;
      2. 第二步:前端页面提交请求时,把 token 加入到请求数据或者头信息中,一起传给后端;
      3. 后端验证前端传来的 token 与 session 是否一致,一致则合法,否则是非法请求。
  • SQL注入攻击(主动攻击)

    • 会执行非法SQL的SQL注入攻击
  • HTTP首部注入攻击(被动攻击)

    • 指攻击者通过在响应首部字段内插入换行,添加任意响应首部或主体的一种攻击。
    • 影响:设置任何Cookie信息;重定向至任意URL
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值