前端校招准备--HTTP相关面试题总结

前言

 上一篇粗糙的总结了一下HTTP中有哪些内容，现在就来看看面试经常会被问到的是哪些问题吧，没道题我都会给出相应的答案，如果只是粗糙的解释的话，我会给出相应的参考资料，下面开始吧~

正文

HTTP中常用的请求方法有哪些？哪些请求方法是安全的？为什么？

答：常用的请求方法有GET,POST,HEAD,PUT,DELETE。其中GET和HEAD是安全的，因为其他的三个方法都会对服务器产生动作，GET和HEAD只是请求数据，POST和POUT都会给服务端发送报文主体。

HTTP中POST和GET方法有什么区别？

答：主要有以下几点区别：

• GET请求在页面后退的时候是无害的（即不会再次发送请求），而POST会再次发送请求
• GET请求的参数是放在请求的URL中，而POST方法是放在请求体中
• GET请求在URL中传递参数时会有长度限制，而POST无限制（不是绝对的，只是相对来说）
• GET请求会被浏览器主动缓存，而POST不会
• GET请求的参数会保存在浏览器中，而POST的参数不会保存在浏览器中

在浏览器中输入URL到页面进行渲染的过程中发生了什么？

答：可以参考下面这张图理解：（图片来自《HTTP权威指南》）

语言描述：经过了以下几步

1. 浏览器解析主机名
2. DNS进行域名解析，即将语义化的主机名转换成IP地址
3. 浏览器获得端口号
4. 浏览器根据得到的ip地址和端口号发起TCP连接
5. 浏览器发起HTTP请求
6. 浏览器读取服务器返回的响应报文
7. 浏览器对返回的HTML进行渲染
8. 浏览器断开TCP连接

请简单描述一下TCP的三次握手和四次挥手的过程，两次握手可以吗？

答：详细解答
 TCP的三次握手：

1. 客户端发送一个SYN报文请求连接，变为SYN_SEND状态
2. 服务端接收到客户端发送SYN包，进行确认过后，发送ACK报文，变为SYN_RECV状态
3. 客户端接收到服务端的SYN和ACK报文后，发送ACK包进行确认，然后客户端和服务端都变成ESTABLISHED状态

 TCP的四次挥手：

1. 客户端没有数据要发送了，请求关闭连接，发送一个FIN报文，并进入FIN_WAIT_1状态
2. 服务端接收到FIN报文后，发送ACK报文，然后进入CLOSE_WAIT状态；客户端接收到ACK报文后，进入FIN_WAIT_2状态
3. 服务端判断是否有数据发送给客户端，如果有的话，就将数据发送给客户端，再发送FIN报文；没有的话就直接发送FIN报文，请求关闭连接，然后进入LAST_ACK状态；
4. 客户端接收到服务端的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，主要分为以下几个步骤（参考文章）：

1. 创建XMLHttpRequst对象
2. 初始化传进来的参数
3. 使用open方法发送请求
4. 接收请求并调用onreadystatechange方法对返回成功以及失败的情况进行定义

什么是HTTP持久化和管线化？

答：

• HTTP持久化是针对HTTP无连接的特点进行改进的，使用的是keep-live首部字段保持长连接
• HTTP管线化是针对HTTP每次只能是请求一次回答一次的模式进行改进，使得可以连续发送多次请求。

HTTP和HTTPS的关系以及HTTPS的实现原理

答：

• HTTPS和HTTP的关系

 HTTPS在HTTP的基础上加上了SSL协议，使得HTTP通信更加安全。针对HTTP无法验证通信方的身份，无法验证报文的完整性以及容易被窃听等安全方面的缺点，HTTPS添加了加密和认证机制，使得HTTP通信更加安全。

• HTTPS通信原理（加密机制，不包括认证机制以及验证报文完整性机制，可参考这里）

1. 客户端发送请求
2. 服务端接收请求返回数字证书
3. 客户端使用内置的CA解密证书，拿到公钥
4. 如果证书没有问题，就将自己的对称秘钥使用公钥加密发送给服务端
5. 服务端使用私钥进行解密
6. 客户端和服务端使用对称秘钥进行通信

webScoket是什么？主要作用是什么？

答：webScoket也是一种协议，用来解决要实现实时更新时，只能通过AJAX轮询等方式的问题。使用这个协议就改变了只能客户端发送请求，服务端接收请求的模式，在该协议中客户端和服务端都可以发送请求和接收请求，从而实现实时推送（服务端有数据更新后就发送数据）的功能，基于该协议可以大大的减少通信量。

SSL有几次握手？具体过程是怎样的？

答：这个问题和HTTPS的实现原理可以看做是一样的，但是比较有针对性，以下是回答：
 SSL有4次握手，握手过程为：

1. 客户端请求SSL连接
2. 服务端发送包含公钥的证书
3. 客户端使用公钥加密对称秘钥并发送给服务端
4. 服务端使用私钥解密对称秘钥

总结

 这篇文章是一个动态更新的文章，看到有相关的问题我就会加上去，希望大家能持续关注哟~