记录一次面试中的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中上传文件是怎么上传的

http://www.javashuo.com/article/p-senpdgtg-bu.html

 

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的信息。

原答案网址：http://www.javashuo.com/article/p-swvqtzls-b.html

 

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节点（广告），实际是修改了数据流。

    在用户角度，这些劫持的表现分为：

    一、网址被无辜跳转，多了推广尾巴；在访问地址后面多了？xxxx之类的推广尾巴

    二、页面出现额外的广告（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和发送全部内嵌资源的请求。服务器推送服务经过“推送”那些它认为客户端将会须要的内容到客户端的缓存中，以此来避免往返的延迟。

 

答案网址：http://www.javashuo.com/article/p-msohsfnk-cc.html

 

全文完，以为有帮助，不妨点个赞哦~