天下无难试之HTTP协议面试刁难大全（上）

小编是一个非典型面试官，对于HTTP协议的第一个问题，通常人会问经常使用的状态码有哪些。小编不这么问，小编的问题是HTTP的全称是什么，把英语给我说出来！

HTTP的全称是什么？

超文本传输协议，HyperText Transfer Protocol，这几个单词可别发走音了。所谓的超文本就是带标记的文本，刚开始的时候是指HTML。如今HTTP协议传输的东西可不仅是HTML了，什么表单啊JSON啊XML啊文件啊均可以传输。

HTTP经常使用的状态码有哪些？

大部分同窗都知道200、40四、500、302状态码。若是连404都不知道，是要被小编鄙视的。500错误为何这么常见呢，由于在开发的时候总是出bug，一个大异常抛出来，浏览器就500了。500表示InternalServerError，也就是内部服务器错误，若是不是bug，通常就是数据库挂了。

再多问几个状态码不少人就不知道了，由于大多数公司的软件服务没有走标准的HTTP状态码，不少状态码历来就不会出现，同窗们天然也不会知道。

400 Bad Request 用于参数验证，少了一个参数或者参数类型错误之类的。

502 Bad Gateway 后端服务挂掉或者压力过大的时候， Nginx接到的请求没法及时传递给后端的服务进行处理，这个时候就会出现502错误。这个也很是常见，知乎豆瓣网站常常开小差的时候发生的错误就是这个。

304 Not Modified 极少人知道这个状态码，由于大部分后端开发者的前端Javascript开发经验都严重不足。当你用Chrome打开一个常常访问的网站，看看Network传输的静态资源就能够看到不少304状态码。它表示该资源被浏览器缓存了不须要从新请求服务器。

401 Unauthorized 权限不足，这个很好理解，就是资源存在可是不让你访问。

403 Forbidden 资源禁止访问，若是你的IP列为黑名单了，就会发生这种错误。

其实还有不少状态码，小编也没去好好研究了，由于实在不会在工做中用到。感兴趣的请继续阅读维基百科

HTTP有哪些Method？

GET 不解释，若是读者不知道，建议别在IT圈混了。

POST 通常用于建立或者修改资源，在RESTFUL规范里面POST只用来建立资源，并返回201 Created状态码表示建立成功。不过大多数网站都不遵循严格的RESTFUL规范，POST拿来作修改资源的事也是很是常见的。

PUT 对应于POST表示建立资源，PUT用于修改资源，PUT的参数必须是对象的所有属性，修改是覆盖式所有修改。

PATCH 对应于PUT的参数是对象的所有属性，PATCH的参数是部分属性，修改是局部字段修改。

DELETE 用于删除资源。

HEAD 不经常使用，跟GET差很少，区别就是不返回Body内容，只返回HTTP头信息。通常用于获取资源的元信息，好比长度，修改时间等

OPTIONS 跨域相关，后面再讲。

TRACE 小编没用过。

CONNECT 小编没用过。

后面三个感兴趣的去阅读一下RPC规范。小编大概看了一下，表示没怎么看懂，你行你上去挑战一下。

HTTP协议格式是怎样的？

HTTP的请求和响应的消息协议是同样的，分为三个部分，起始行、消息头和消息体。这三个部分以CRLF做为分隔符。最后一个消息头有两个CRLF，用来表示消息头部的结束。

HTTP请求的起始行称为请求行，形如GET /index.html HTTP/1.1

HTTP响应的起始行称为状态行，形如200 ok

消息头部有不少键值对组成，多个键值对之间使用CRLF做为分隔符，也能够彻底没有键值对。形如Content-Encoding: gzip

消息体是一个字符串，字符串的长度是由消息头部的Content-Length键指定的。若是没有Content-Length字段说明没有消息体，譬如GET请求就是没有消息体的，POST请求的消息体通常用来放置表单数据。GET请求的响应返回的页面内容也是放在消息体里面的。咱们平时调用API返回的JSON内容都是放在消息体里面的。

什么是分块传送？

当浏览器向服务器请求一个资源时，这个资源是一个动态资源，服务器没法提早预知资源的大小，这个时候就可使用分块传输。

服务器先生成一个thunk，发送这个chunk，再生成一个chunk，再发送一个chunk，直到所有资源传送完成。

分块传送须要在请求头增长一个特殊的键值对transfer-encoding: thunked，那么消息体的内容即是分块传送的。

chunked传输格式如图所示，由一段一段的分块组合而成，每一个块由一个长度行和一个分块体组成，最后一个分块长度为0表示结束。

持久链接的机制是怎样的？

HTTP早期版本中每一个请求都会发起一个链接，一个网页除了页面的HTML以外还会有不少静态资源以及诸多的API调用，若是每一个请求都一个链接，势必网页的一次加载就会和服务器建立屡次链接，这是很是浪费服务器资源的，同时也让客户端的访问速度慢了很多。HTTP1.0以后引入了Keep-Alive持久链接，在HTTP1.1版本中成为默认选项。它使得HTTP的一个链接能够连续服务多个请求，有效节省了资源，增长了客户端页面的加载速度。

持久链接也不宜一直保持，毕竟每一个链接都会占用服务器资源，若是打开网页的人太多，那服务器资源也会紧张，因此通常服务器都会配置一个KeepAlive Timeout参数和KeepAlive Requests参数限制单个链接持续时长和最多服务的请求次数。

若是服务器设置的timeout时长为0，就退化到非持久链接。非持久链接会在响应头部增长一个头信息Connection: Close通知客户端在接受完当前响应后链接须要当即关闭。

一样浏览器也不会由于服务器将KeepAlive Timeout配置了无限长就无论不问一直持续保持链接。每一个浏览器都有它本身的内置限制，具体限制浏览器厂商各有不一样。

什么叫Pipeline管线化？

HTTP1.0不支持管线化，同一个链接处理请求的顺序是逐个应答模式，处理一个请求就须要耗费一个TTL，也就是客户端到服务器的往返时间，处理N个请求就是N个TTL时长。当页面的请求很是多时，页面加载速度就会很是缓慢。

从HTTP1.1开始要求服务器支持管线化，能够同时将多个请求发送到服务器，而后逐个读取响应。这个管线化和Redis的管线化原理是同样的，响应的顺序必须和请求的顺序保持一致。

如何理解HTTP协议的无状态性？

所谓HTTP协议的无状态性是指服务器的协议层无需为不一样的请求之间创建任何相关关系，它特指的是协议层的无状态性。可是这并不表明创建在HTTP协议之上的应用程序就没法维持状态。应用层能够经过会话Session来跟踪用户请求之间的相关性，服务器会为每一个会话对象绑定一个惟一的会话ID，浏览器能够将会话ID记录在本地缓存LocalStorage或者Cookie，在后续的请求都带上这个会话ID，服务器就能够为每一个请求找到相应的会话状态。

阅读相关文章，关注公众号【码洞】