记录一次面试中的HTTP请求相关问题

1.HTTP中的状态码分别代表什么
比较基础，自行百度。
 
2.HTTP请求，响应头部content-length用来做什么的
答：Content-Length首部告诉浏览器报文中实体主体的大小。这个大小是包含了内容编码的，比如对文件进行了gzip压缩，Content-Length就是压缩后的大小，而不是原始大小。除非使用了分块编码（chunked），否则Content-Length首部就是带有实体主体的报文必须使用的。使用Content-Length首部是为了能够检测出服务器崩溃而导致的报文截尾，并对共享持久连接的多个报文进行正确分段.
 
另外Content-Length首部对于长连接是必不可少的，长连接代表在连接期间会有多个http请求响应在排队，而服务器不能够关闭连接，客户端只能通过Content-Length知道一条报文在哪里结束，下一条报文在哪里开始。
 
除非使用了分块编码Transfer-Encoding: chunked，否则响应头首部必须使用Content-Length首部。（HTTP1.1必须支持chunk模式。因为当不确定消息长度的时候，可以通过chunk机制来处理这种情况。也就是有chunk就不能有content-length 。） [摘自http权威指南]
 
那么扩展一下就是，如果使用chunked编码的时候，就不用Content-length，以及，如果使用非长连接keep-alive的时候也可以不要，因为可以直接通过服务器关闭连接来确定消息的传输长度
 
3.HTTP中上传文件是怎么上传的
 
4.TCP为什么是三次握手，为什么不是两次或者四次
答：这是一个很有意思的问题~  
　　首先，我们要知道TCP是全双工的，即客户端在给服务器端发送信息的同时，服务器端也可以给客户端发送信息。而半双工的意思是A可以给B发，B也可以给A发，但是A在给B发的时候，B不能给A发，即不同时，为半双工。 单工为只能A给B发，B不能给A发； 或者是只能B给A发，不能A给B发。
　　我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。
  • 第一次握手： A给B打电话说，你可以听到我说话吗？
  • 第二次握手： B收到了A的信息，然后对A说： 我可以听得到你说话啊，你能听得到我说话吗？  
  • 第三次握手： A收到了B的信息，然后说可以的，我要给你发信息啦！
　　在三次握手之后，A和B都能确定这么一件事： 我说的话，你能听到； 你说的话，我也能听到。 这样，就可以开始正常通信了。
 
　　注意： HTTP是基于TCP协议的，所以每次都是客户端发送请求，服务器应答，但是TCP还可以给其他应用层提供服务，即可能A、B在建立链接之后，谁都可能先开始通信。
　　　　
　　如果两次，那么B无法确定B的信息A是否能收到，所以如果B先说话，可能后面的A都收不到，会出现问题 。
　　如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。
 
5.HTTP头部里有哪些Content-Type？
 MediaType，即是Internet Media Type，互联网媒体类型；也叫做MIME类型，在Http协议消息头中，使用Content-Type来表示具体请求中的媒体类型信息。
常见的媒体格式类型如下：
  •     text/html ： HTML格式
  •     text/plain ：纯文本格式      
  •     text/xml ：  XML格式
  •     image/gif ：gif图片格式    
  •     image/jpeg ：jpg图片格式 
  •     image/png：png图片格式
   以application开头的媒体格式类型：
  •    application/xhtml+xml ：XHTML格式
  •    application/xml     ： XML数据格式
  •    application/atom+xml  ：Atom XML聚合格式    
  •    application/json    ： JSON数据格式（Java后台可以通过@RequestBody进行接收，适配主流RestApi风格）
  •    application/pdf       ：pdf格式  
  •    application/msword  ： Word文档格式
  •    application/octet-stream ： 二进制流数据（如常见的文件下载）
  •    application/x-www-form-urlencoded ： <form encType=””>中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式，常见的以key1=value1&keys=value2，拼接在url后面，java后台可以使用getParameter（‘key’）的方式接收）
   另外一种常见的媒体格式是上传文件之时使用的：
  •     multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式(java后台可以使用request.getInputStream()获得数据，然后再通过一些开源组件的api获得指定项数据)
     以上就是我们在日常的开发中，经常会用到的若干content-type的内容格式。
 
 
6.DNS用来做什么
DNS就是把域名和IP地址联系在一起的服务，有了DNS服务器，你就不用输入IP地址来访问一个网站，可以通过输入网址访问。
更符合人类的记忆习惯。
 
7.HTTP劫持有哪些类型
答：说道HTTP劫持，我们可以联想到DNS劫持，这两种劫持都是，运营商通过某些方式篡改了用户正常访问的网页，插入广告或者其他一些杂七杂八的东西。
DNS劫持：
一般而言，用户上网的DNS服务器都是运营商分配的，所以，在这个节点上，运营商可以为所欲为。
例如，访问http://jiankang.qq.com/index.html，正常DNS应该返回腾讯的ip，而DNS劫持后，会返回一个运营商的中间服务器ip。访问该服务器会一致性的返回302，让用户浏览器跳转到预处理好的带广告的网页，在该网页中再通过iframe打开用户原来访问的地址。
 
HTTP劫持：
在运营商的路由器节点上，设置协议检测，一旦发现是HTTP请求，而且是html类型请求，则拦截处理。后续做法往往分为2种，1种是类似DNS劫持返回302让用户浏览器跳转到另外的地址，还有1种是在服务器返回的HTML数据中插入js或dom节点（广告），实际是修改了数据流。
    在用户角度，这些劫持的表现分为：
    1、网址被无辜跳转，多了推广尾巴；在访问地址后面多了？xxxx之类的推广尾巴
    2、页面出现额外的广告（iframe模式或者直接同页面插入了dom节点）
 
HTTP劫持的应对办法是：
1.在页面中做检测，一但发现有dom植入或者检测当前窗口层级，如果嵌套在iframe里面，则需检查url白名单，如果不是嵌套在白名单内的iframe里，则调用location重定向
2.使用https，一劳永逸
 
 
8.301，302重定向的使用场景
301是永久重定向，使得搜索引擎在抓取新内容的同时将旧的网址替换为重定向后的网址，可缓存。
而302是临时重定向，使得搜索引擎会抓去新的内容却保留旧的网址
 
适用场景
301：域名切换、HTTP迁移到HTTPS
302：未登录用户访问个人中心时重定向到登录页面、404页面提示后跳转到首页
 
场景：如果我有一短连接，用户访问的时候需要重定向到短连接对应的网址。这种情况下，你会考虑用301还是302？
当时没有什么思路，面试官的想法是，301虽然可以缓存，但是我服务器又不值钱。。。 302的话，可以获取到一些用户统计数据，
显然数据更有价值。具体的，还是看公司业务场景吧。
 
9.HTTP请求数量有限制吗？HTTP请求数量限制是针对域名还是什么？
同一时间针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。主流的浏览器好像是6-8个。这也是为什么有的网站，有些资源请求的会是另外一个域名。
 
10.HTTP2.0跟HTTP1.1有什么区别
1. HTTP/2采用二进制格式而非文本格式
2. HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
3. 使用报头压缩，HTTP/2降低了开销
4. HTTP/2让服务器可以将响应主动“推送”到客户端缓存中
 
HTTP/2为什么是二进制？
比起像HTTP/1.x这样的文本协议，二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少。
 
为什么 HTTP/2 需要多路传输?
HTTP/1.x 有个问题叫线端阻塞(head-of-line blocking), 它是指一个连接(connection)一次只提交一个请求的效率比较高, 多了就会变慢。 HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重。而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。所以客户端只需要一个连接就能加载一个页面。
 
消息头为什么需要压缩?
假定一个页面有80个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1400字节的消息头（着同样也并不少见，因为Cookie和引用等东西的存在）, 至少要7到8个来回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已。这全都由于TCP的慢启动机制，它会基于对已知有多少个包，来确定还要来回去获取哪些包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量。相比之下，即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个包就可以了。这种开销是可以被节省下来的，特别是当你考虑移动客户端应用的时候，即使是良好条件下，一般也会看到几百毫秒的来回延迟。
 
服务器推送的好处是什么？
当浏览器请求一个网页时，服务器将会发回HTML，在服务器开始发送JavaScript、图片和CSS前，服务器需要等待浏览器解析HTML和发送所有内嵌资源的请求。服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端的缓存中，以此来避免往返的延迟。
 
 
全文完，觉得有帮助，不妨点个赞哦~
posted @ 2019-04-20 17:00  daisy,gogogo  阅读(617)  评论(0)  编辑  收藏  举报