前言
上一篇粗糙的总结了一下HTTP中有哪些内容,如今就来看看面试常常会被问到的是哪些问题吧,没道题我都会给出相应的答案,若是只是粗糙的解释的话,我会给出相应的参考资料,下面开始吧~
正文
HTTP中经常使用的请求方法有哪些?哪些请求方法是安全的?为何?
答:经常使用的请求方法有GET,POST,HEAD,PUT,DELETE。其中GET和HEAD是安全的,由于其余的三个方法都会对服务器产生动做,GET和HEAD只是请求数据,POST和POUT都会给服务端发送报文主体。web
HTTP中POST和GET方法有什么区别?
答:主要有如下几点区别:面试
- GET请求在页面后退的时候是无害的(即不会再次发送请求),而POST会再次发送请求
- GET请求的参数是放在请求的URL中,而POST方法是放在请求体中
- GET请求在URL中传递参数时会有长度限制,而POST无限制(不是绝对的,只是相对来讲)
- GET请求会被浏览器主动缓存,而POST不会
- GET请求的参数会保存在浏览器中,而POST的参数不会保存在浏览器中
在浏览器中输入URL到页面进行渲染的过程当中发生了什么?
答:能够参考下面这张图理解:(图片来自《HTTP权威指南》)
segmentfault
语言描述:通过了如下几步浏览器
- 浏览器解析主机名
- DNS进行域名解析,即将语义化的主机名转换成IP地址
- 浏览器得到端口号
- 浏览器根据获得的ip地址和端口号发起TCP链接
- 浏览器发起HTTP请求
- 浏览器读取服务器返回的响应报文
- 浏览器对返回的HTML进行渲染
- 浏览器断开TCP链接
请简单描述一下TCP的三次握手和四次挥手的过程,两次握手能够吗?
答:详细解答
TCP的三次握手:缓存
- 客户端发送一个SYN报文请求链接,变为SYN_SEND状态
- 服务端接收到客户端发送SYN包,进行确认事后,发送ACK报文,变为SYN_RECV状态
- 客户端接收到服务端的SYN和ACK报文后,发送ACK包进行确认,而后客户端和服务端都变成ESTABLISHED状态
TCP的四次挥手:安全
- 客户端没有数据要发送了,请求关闭链接,发送一个FIN报文,并进入FIN_WAIT_1状态
- 服务端接收到FIN报文后,发送ACK报文,而后进入CLOSE_WAIT状态;客户端接收到ACK报文后,进入FIN_WAIT_2状态
- 服务端判断是否有数据发送给客户端,若是有的话,就将数据发送给客户端,再发送FIN报文;没有的话就直接发送FIN报文,请求关闭链接,而后进入LAST_ACK状态;
- 客户端接收到服务端的FIN报文后,发送ACK报文,而后客户端进入TIME_WAIT状态;服务端接收到ACK报文后,关闭链接,变为CLOSED状态,客户端在2MSL后依然没有收到回复,也能够关闭链接了。
两次握手能够吗?服务器
不能够,三次握手主要是防止已通过期的请求再次链接到服务端而占用资源形成浪费。若是是两次握手的话,假设主机A在发送第一次请求时,因为网络滞留的问题卡住了,好久后没有收到主机B的确认信息,因而又发送了第二次请求。过了一段时间后,第一个请求到达了主机B,主机B觉得是一次新的请求,就返回确认信息,可是因为没有第三次握手,只要主机B发出确认信息,就会链接,这个时候主机B一直等待着主机A发送信息,就会形成资源浪费。(参考资料)网络
TCP和UDP的区别是什么?
答:主要有如下几个方面的区别:并发
- 链接方面:TCP是面向链接的,而UDP是无链接的,即UDP在传输数据以前不须要像TCP那样3次握手创建链接
- 可靠性:TCP比UDP更可靠,TCP能够保证不丢包,会按照顺序传输数据,这也是致使
- 资源消耗:TCP对系统资源要求比较高,而且消耗资源比较大;UDP要求不高,可是在网络质量很差的状况下比较容易丢包,消耗资源相对比较小
- 适用场景:TCP适用于HTTP,FTP以及邮件传输等等;而UDP比较适合于语音,视频等
- 速度问题:TCP传输速度比较慢,效率低,在握手和挥手的过程当中会占用不少时间;UDP传输速度比较快,因为是无链接的,只有传输数据的过程
- 安全性:安全性和可靠性是不一样的概念,因为TCP的机制比较多,更容易受到攻击;UDP相对来讲就比较安全,可是也不能避免受到攻击
- 链接形式:TCP是只能一对一的发送,而UDP能够是一对一,一对多,多对多
HTTP中常见的状态码有哪些?分别表示什么意思?
答:常见的状态码有:加密
- 200:接收并响应成功
- 301:请求的资源已经换了URL,须要从新请求(永久重定向)
- 302:请求的资源临时换了URL,须要从新请求(临时重定向)
- 304:在缓存中有该资源,能够直接获取
- 403:该资源禁止访问
- 404:该资源不存在
HTTP有什么特色?
答:
HTTP有什么缺点?
答:有如下缺点:
- 一条链接上只能发送一个请求
- 请求只能从客户端开始,客户端不能够接收除响应以外的指令
- 请求/响应首部未经压缩就发送,首部信息越多形成的延迟越大
- 发送冗长的首部,每次互发相同的首部形成很大的浪费
- 通讯使用明文,内容可能会被窃听
- 不验证通讯方的身份,有可能会遭遇假装
- 没法验证报文的完整性,有可能遭遇篡改
请描述AJAX实现原理
答:AJAX的实现核心在于XMLHttpRequest这个API,主要分为如下几个步骤(参考文章):
- 建立XMLHttpRequst对象
- 初始化传进来的参数
- 使用open方法发送请求
- 接收请求并调用onreadystatechange方法对返回成功以及失败的状况进行定义
什么是HTTP持久化和管线化?
答:
- HTTP持久化是针对HTTP无链接的特色进行改进的,使用的是keep-live首部字段保持长链接
- HTTP管线化是针对HTTP每次只能是请求一次回答一次的模式进行改进,使得能够连续发送屡次请求。
HTTP和HTTPS的关系以及HTTPS的实现原理
答:
HTTPS在HTTP的基础上加上了SSL协议,使得HTTP通讯更加安全。针对HTTP没法验证通讯方的身份,没法验证报文的完整性以及容易被窃听等安全方面的缺点,HTTPS添加了加密和认证机制,使得HTTP通讯更加安全。
- HTTPS通讯原理(加密机制,不包括认证机制以及验证报文完整性机制,可参考这里)
- 客户端发送请求
- 服务端接收请求返回数字证书
- 客户端使用内置的CA解密证书,拿到公钥
- 若是证书没有问题,就将本身的对称秘钥使用公钥加密发送给服务端
- 服务端使用私钥进行解密
- 客户端和服务端使用对称秘钥进行通讯
webScoket是什么?主要做用是什么?
答:webScoket也是一种协议,用来解决要实现实时更新时,只能经过AJAX轮询等方式的问题。使用这个协议就改变了只能客户端发送请求,服务端接收请求的模式,在该协议中客户端和服务端均可以发送请求和接收请求,从而实现实时推送(服务端有数据更新后就发送数据)的功能,基于该协议能够大大的减小通讯量。
SSL有几回握手?具体过程是怎样的?
答:这个问题和HTTPS的实现原理能够看作是同样的,可是比较有针对性,如下是回答:
SSL有4次握手,握手过程为:
- 客户端请求SSL链接
- 服务端发送包含公钥的证书
- 客户端使用公钥加密对称秘钥并发送给服务端
- 服务端使用私钥解密对称秘钥
总结
这篇文章是一个动态更新的文章,看到有相关的问题我就会加上去,但愿你们能持续关注哟~