【面试】web前端经典面试题试题及答案-前后端通信（http、https、tcp）

女爷i 2022-12-16 13:08 144阅读 0赞

> http

<table> 
 <tbody> 
  <tr> 
   <td align="left">一次完整的HTTP事务是怎样的一个过程？</td> 
  </tr> 
 </tbody> 
</table>

1、 域名解析  
2、发起TCP的3次握手  
3、 建立TCP连接后发起http请求  
4、服务器端响应http请求，浏览器得到html代码  
5、浏览器解析html代码，并请求html代码中的资源  
6、浏览器对页面进行渲染呈现给用户

# http协议类 #

一、HyperText Transfer Protocol，超文本传输协议。因特网上应用最为广泛的一种网络传输协议,所有的WWW文件都必须遵守这个标准  
二、如果没有写端口，就会启用默认端口  
http默认端口：80  
https默认端口：443

## <table>   <tbody>    <tr>     <td align="left">http协议的主要特点？</td>    </tr>   </tbody>  </table> ##

简单快速、灵活、无连接、无状态  
1、简单快速：每个资源的url是固定的  
2、灵活：每个http协议中有个头部分，有个数据类型，通过一个http协议，可以完成不同类型数据的传输。  
3、无连接：连接一次就会断掉，不会保持连接。  
4、无状态：客户端、服务端是两种身份，http传输完成后，下次连接再过来，服务端无法确认是否是上一次连接者的身份。

## <table>   <tbody>    <tr>     <td align="left">http报文的组成部分？</td>    </tr>   </tbody>  </table> ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FTdW5jYXQ_size_16_color_FFFFFF_t_70]  
1、请求报文= 请求行+请求头+空行+请求体  
（1）请求行：包含http方法，页面地址，http协议，版本。  
（2）请求头：key,value值，告诉服务端我要哪些内容。  
（3）空行：分隔请求头、请求体。  
2、响应报文= 状态行+响应头+空行+响应体

## <table>   <tbody>    <tr>     <td align="left">http方法？</td>    </tr>   </tbody>  </table> ##

get：获取资源  
post：传输资源  
put：更新资源  
delete：删除资源  
head：获得报文首部

## <table>   <tbody>    <tr>     <td align="left">post和get的区别？</td>    </tr>   </tbody>  </table> ##

9个区别，至少记住标记的4个  
1、get在浏览器回退时是无害的，而post会再次提交请求。（记住）  
2、get请求会被浏览器主动缓存，而post不会，除非手动设置。（记住）  
3、get产生的url地址可以被收藏，而post不可以。  
4、get请求只能进行url编码，而post支持多种编码方式。  
5、get请求参数会被完整保留在浏览器历史记录里，而post中的参数不会被保留。（记住）  
6、get参数通过url传递，post放在request body 中。（记住)  
7、get请求在url中传送的参数是有长度限制的，而post没有限制。  
8、对参数的数据类型，get只接受ASCII字符，而post没有限制。  
9、get比post更不安全，因为参数直接暴露在url上，所以不能用来传递敏感信息。

## <table>   <tbody>    <tr>     <td align="left"> get请求传参长度的误区、get和post请求在缓存方面的区别？</td>    </tr>   </tbody>  </table> ##

误区：我们经常说get请求参数的大小存在限制，而post请求的参数大小是无限制的。  
参考答案  
实际上HTTP 协议从未规定 GET/POST 的请求长度限制是多少。对get请求参数的限制是来源与浏览器或web服务器，浏览器或web服务器限制了url的长度。为了明确这个概念，我们必须再次强调下面几点:  
HTTP 协议 未规定 GET 和POST的长度限制  
GET的最大长度显示是因为 浏览器和 web服务器限制了 URI的长度  
不同的浏览器和WEB服务器，限制的最大长度不一样  
要支持IE，则最大长度为2083byte，若只支持Chrome，则最大长度 8182byte  
补充补充一个get和post在缓存方面的区别：  
get请求类似于查找的过程，用户获取数据，可以不用每次都与数据库连接，所以可以使用缓存。  
post不同，post做的一般是修改和删除的工作，所以必须与数据库交互，所以不能使用缓存。因此get请求适合于请求缓存。

# http状态码 #

一、状态码  
1xx：指示信息-表示请求已接收，继续处理。  
2xx：成功-表示请求已被成功接收。  
3xx：重定向-要完成请求必须进行更进一步的操作。  
4xx：客户端错误-请求有语法错误或请求无法实现。  
5xx：服务器错误-服务器未能实现合法的请求。

## <table>   <tbody>    <tr>     <td align="left">有哪些常见状态码？</td>    </tr>   </tbody>  </table> ##

200 OK:客户端请求成功  
206 Partial Content：客户发送了一个带有Range头的GET请求，服务器完成了它。 // video, audio  
301 Moved Permanently：所请求的页面都已经转移至新的url  
302 Found：所请求的页面已经临时转移至新的url  
304 Not Modified：客户端有缓冲的文档并发出了一个条件性的请求，服务器告诉客户，原来缓冲的文档还可以继续使用。  
400 Bad Request：客户端请求有语法错误，不能被服务器所理解  
401 Unauthorized： 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用  
403 Forbidden：对被请求页面的访问被禁止  
404 Not Found：请求资源不存在  
500 Internal Server Error：服务器发生不可预期的错误  
503 Server Unavailable：请求未完成，服务器临时过载或宕机，一段时间后可能恢复正常。

## <table>   <tbody>    <tr>     <td align="left">304原理，相关的header？</td>    </tr>   </tbody>  </table> ##

1、Last-Modified：响应头，表示当前资源的最后修改时间。  
2、If-Modified-Since：请求头，表示缓存的资源最后修改时间。

1、客户端首次访问服务器的静态资源index.html，服务器会把index.html响应给客户端，而且还会添加一个名为Last-Modified的响应头，它说明了当前index.html的最后修改时间  
2、客户端收到响应后，会把index.html缓存在客户端上，而且还会把Last-Modified缓存起来。  
3、客户端第二次请求index.html时，会添加名为If-Modified-Since的请求头，它的值是上次服务器响应头Last-Modified，服务器获取到客户端保存的最后修改时间，以及当前资源的最后修改时间进行比较，如果相同，说明index.html没有改动过，那么服务器不会发送index.html，而是响应状态码304，即通知客户端资源没有改变，你可以使用自己的缓存。

# 持久连接 #

## <table>   <tbody>    <tr>     <td align="left">什么是持久连接？</td>    </tr>   </tbody>  </table> ##

1、http协议采用“请求-应答”模式，当使用普通模式，即非keep-alive模式时，每个请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接（http协议为无连接的协议）  
当使用keep-alive模式（又称持久连接、连接重用）时，keep-alive功能使客户端到服务器端的连接持久有效，当出现对服务器的后继请求时，keep-alive功能避免了建立后者重新建立连接。  
（aSuncat：chrome默认开启持久连接)  
2、http1.1才支持，http1.0是不支持的。

# 管线化 #

## <table>   <tbody>    <tr>     <td align="left">什么是管线化？</td>    </tr>   </tbody>  </table> ##

在使用持久连接的情况下，某个连接上消息的传递类似于  
请求1-> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3  
某个连接上的消息变成了类似这样  
请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3

## <table>   <tbody>    <tr>     <td align="left">管线化注意点？</td>    </tr>   </tbody>  </table> ##

6个注意点，至少记住标记的3个  
1、管线化机制通过持久连接完成，仅http/1.1支持此技术。（记住）  
2、只有get和head请求可以进行管线化，而post则有所限制。（记住）  
3、初次创建连接时不应启动管线机制，因为对方（服务器）不一定支持http/1.1版本的协议。（记住）  
4、管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变。  
5、http/1.1要求服务器支持管线化，但并不要求服务器也对响应进行管线化处理，只是要求管线化的请求不失败即可  
6、由于上面提到的服务器问题，开启管线化很可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因为现代浏览器如chrome和firefox默认并未开启管线化支持

# http2 #

1、多路复用

## <table>   <tbody>    <tr>     <td align="left">关于Http 2.0 你知道多少？</td>    </tr>   </tbody>  </table> ##

1、HTTP/2引入了“服务端推（server push）”的概念，它允许服务端在客户端需要数据之前就主动地将数据发送到客户端缓存中，从而提高性能。  
2、HTTP/2提供更多的加密支持  
3、HTTP/2使用多路技术，允许多个消息在一个连接上同时交差。  
4、它增加了头压缩（header compression），因此即使非常小的请求，其请求和响应的header都只会占用很小比例的带宽。

# https #

HTTP协议通常承载于TCP协议之上，在HTTP和TCP之间添加一个安全协议层（SSL或TSL），这个时候，就成了我们常说的HTTPS。

## <table>   <tbody>    <tr>     <td align="left">https是如何实现加密的？</td>    </tr>   </tbody>  </table> ##

待完善

## <table>   <tbody>    <tr>     <td align="left">为什么HTTPS安全？</td>    </tr>   </tbody>  </table> ##

因为网络请求需要中间有很多的服务器路由器的转发。中间的节点都可能篡改信息，而如果使用HTTPS，密钥在你和终点站才有。https之所以比http安全，是因为他利用ssl/tls协议传输。它包含证书，卸载，流量转发，负载均衡，页面适配，浏览器适配，refer传递等。保障了传输过程的安全性

## <table>   <tbody>    <tr>     <td align="left">HTTPS 握手过程中，客户端如何验证证书的合法性</td>    </tr>   </tbody>  </table> ##

*  首先什么是HTTP协议?  
    http协议是超文本传输协议，位于tcp/ip四层模型中的应用层；通过请求/响应的方式在客户端和服务器之间进行通信；但是缺少安全性，http协议信息传输是通过明文的方式传输，不做任何加密，相当于在网络上裸奔；容易被中间人恶意篡改，这种行为叫做中间人攻击；
 *  加密通信：  
    为了安全性，双方可以使用对称加密的方式key进行信息交流，但是这种方式对称加密秘钥也会被拦截，也不够安全，进而还是存在被中间人攻击风险；  
    于是人们又想出来另外一种方式，使用非对称加密的方式；使用公钥/私钥加解密；通信方A发起通信并携带自己的公钥，接收方B通过公钥来加密对称秘钥；然后发送给发起方A；A通过私钥解密；双发接下来通过对称秘钥来进行加密通信；但是这种方式还是会存在一种安全性；中间人虽然不知道发起方A的私钥，但是可以做到偷天换日，将拦截发起方的公钥key;并将自己生成的一对公/私钥的公钥发送给B；接收方B并不知道公钥已经被偷偷换过；按照之前的流程，B通过公钥加密自己生成的对称加密秘钥key2;发送给A；  
    这次通信再次被中间人拦截，尽管后面的通信，两者还是用key2通信，但是中间人已经掌握了Key2;可以进行轻松的加解密；还是存在被中间人攻击风险；
 *  解决困境：权威的证书颁发机构CA来解决；  
    制作证书：作为服务端的A，首先把自己的公钥key1发给证书颁发机构，向证书颁发机构进行申请证书；证书颁发机构有一套自己的公私钥，CA通过自己的私钥来加密key1,并且通过服务端网址等信息生成一个证书签名，证书签名同样使用机构的私钥进行加密；制作完成后，机构将证书发给A；  
    校验证书真伪：当B向服务端A发起请求通信的时候，A不再直接返回自己的公钥，而是返回一个证书；  
    说明：各大浏览器和操作系统已经维护了所有的权威证书机构的名称和公钥。B只需要知道是哪个权威机构发的证书，使用对应的机构公钥，就可以解密出证书签名；接下来，B使用同样的规则，生成自己的证书签名，如果两个签名是一致的，说明证书是有效的；  
    签名验证成功后，B就可以再次利用机构的公钥，解密出A的公钥key1;接下来的操作，就是和之前一样的流程了；
 *  中间人是否会拦截发送假证书到B呢？  
    因为证书的签名是由服务器端网址等信息生成的，并且通过第三方机构的私钥加密中间人无法篡改；所以最关键的问题是证书签名的真伪；
 *  https主要的思想是在http基础上增加了ssl安全层，即以上认证过程；

## <table>   <tbody>    <tr>     <td align="left">http和https的区别？</td>    </tr>   </tbody>  </table> ##

http传输的数据都是未加密的，也就是明文的，网景公司设置了SSL协议来对http协议传输的数据进行加密处理，简单来说https协议是由http和ssl协议构建的可进行加密传输和身份认证的网络协议，比http协议的安全性更高。主要的区别如下：

*  Https协议需要ca证书，费用较高。
 *  http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
 *  使用不同的链接方式，端口也不同，一般而言，http协议的端口为80，https的端口为443
 *  http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

# tcp #

## <table>   <tbody>    <tr>     <td align="left">tcp3次握手？</td>    </tr>   </tbody>  </table> ##

1、发送端首先发送一个带SYN标志的数据包给对方。  
2、接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。  
3、发送端再回传一个带ACK标志的数据包，代表“握手”结束。

## <table>   <tbody>    <tr>     <td align="left">tcp连接建立只需要3次握手，为什么断开一个TCP连接则需要“四次握手”？</td>    </tr>   </tbody>  </table> ##

1、主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。  
2、被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。  
3、被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。  
4、主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

## <table>   <tbody>    <tr>     <td align="left">TCP和UDP的区别？</td>    </tr>   </tbody>  </table> ##

1、TCP（Transmission Control Protocol，传输控制协议）是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来  
2、UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！  
UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。

## <table>   <tbody>    <tr>     <td align="left">一个 tcp 连接能发几个 http 请求？[高德一面]</td>    </tr>   </tbody>  </table> ##

1、如果是 HTTP 1.0 版本协议，一般情况下，不支持长连接，因此在每次请求发送完毕之后，TCP 连接即会断开，因此一个 TCP 发送一个 HTTP 请求，但是有一种情况可以将一条 TCP 连接保持在活跃状态，那就是通过 Connection 和 Keep-Alive 首部，在请求头带上 Connection: Keep-Alive，并且可以通过 Keep-Alive 通用首部中指定的，用逗号分隔的选项调节 keep-alive 的行为，如果客户端和服务端都支持，那么其实也可以发送多条，不过此方式也有限制，可以关注《HTTP 权威指南》4.5.5 节对于 Keep-Alive 连接的限制和规则。  
2、而如果是 HTTP 1.1 版本协议，支持了长连接，因此只要 TCP 连接不断开，便可以一直发送 HTTP 请求，持续不断，没有上限；  
同样，如果是 HTTP 2.0 版本协议，支持多用复用，一个 TCP 连接是可以并发多个 HTTP 请求的，同样也是支持长连接，因此只要不断开 TCP 的连接，HTTP 请求数也是可以没有上限地持续发送

# http基础 #

## <table>   <tbody>    <tr>     <td align="left">什么是RESTful API，怎么使用？</td>    </tr>   </tbody>  </table> ##

是一个api的标准，无状态请求。请求路由地址是固定的。标准有：.post .put .delete  
需要再整理，待完善

--------------------

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FTdW5jYXQ_size_16_color_FFFFFF_t_70]: /images/20221123/190dde9b1ce04f3eaca72e9dbf5599bd.png