计算机网络常见面试题
1. http为啥无连接?
HTTP协议又称超文本传输协议;是OSI模型中的第七层应用程中协议;具有以下特点:
1、支持客户/服务器模式;
2、简单快速;
3、灵活;
4、无连接;
5、无状态;
这里我们主要解释4和5特点: **因为HTTP请求是连接后就马上断开,每次请求都重新建立连接,然后再断开,所以是没有状态的,服务器端是没办法知道客户端的状态的。服务端能做的只是等待客户端连接,无法主动发数据给客户端,这是HTTP连接的主要特点。**
无连接:指的是每次连接只处理一个请求,服务端处理完客户端一次请求,等到客户端作出回应之后便断开连接;这种方式有利于节省传输时间;然后随着互联网的发展,一台服务器同一时间处理的请求越来越多,如果依然采用原来的方式,将会在建立和断开连接上花费大部分时间;为了避免这一劣势。
HTTP/1.0:持久连接被提出来;即当一个TCP连接服务器多次请求:客户端会在请求Header中携带Connection:Keep-Alive;向服务器请求持久连接,如果服务端允许就会在响应报文中加上相同的字段;
HTTP/1.1时代:持久连接称为了默认的连接方式;同时持久连接的弊病也展现出来,即所有的连接都是串行的,HOLB;当某一个请求阻塞时就会导致同一条连接的后续请求被阻塞;
为了解决这一问题:提出了pipellining的概念;客户端发起一次请求时不必等待响应便直接发起第二个请求;服务端按照请求的顺序一次返回结果;
SPDY和HTTP/2:multiplexing:多路复用技术出现;能够让多个请求和响应的传输完全混杂在一起进行;通过streamID来互相区别;
PS:HTTP借助于底层的TCP虚拟连接,HTTP协议本身无需连接;就好比A和B打电话,A和B是借助于底层的简化先连接交换信息;但是A和B本身无需连接;
无状态:是指服务端对于客户端每次发送的请求都认为它是一个新的请求,上一次会话和下一次会话没有联系; HTTP 协议这种特性有优点也有缺点,优点在于解放了服务器,每一次请求“点到为止”不会造成不必要连接占用,缺点在于每次请求会传输大量重复的内容信息。
一个TCP连接可以发送多少个HTTP请求?
原文链接:https://blog.csdn.net/yoyo31/article/details/120189165
TCP与HTTP的渊源
我们知道TCP协议对应于传输层,HTTP协议对应于应用层。WEB项目中,HTTP协议是建立在TCP的基础上的。
最初浏览器从服务器加载一个网页,会发起一个HTTP请求,这时需要先建立一个TCP连接。当本次数据请求完毕之后,会立刻断开TCP连接。
但随着时间的推理,HTML网页内容越来越复杂,不仅有内容,还有JS、CSS和图片资源,每个资源的请求都建立一次TCP连接,效率就会很低。
这时,Keep-Alive就被提出用来了,专门用于解决效率低的问题。
本文关于TCP连接能够发送多少个HTTP请求,本质上就是围绕着解决通信的低效问题的。
下面我们通过几个常见的面试问题,来逐步揭开这其中包含的知识点。
问题一:浏览器建立TCP连接之后,完成一次HTTP请求,是否会断开?
HTTP协议Header中的Connection属性决定了连接是否持久,不同HTTP协议版本有所不同。
HTTP/1.0中Connection默认为close,即每次请求都会重新建立和断开TCP连接。缺点:建立和断开TCP连接,代价过大。
HTTP/1.1中Connection默认为keep-alive,即连接可以复用,不用每次都重新建立和断开TCP连接。超时之后没有连接则主动断开。可以通过声明Connection为close进行关闭。
优点:TCP连接可被重复利用,减少建立连接的损耗,SSL的开销也可以避免。刷新页面时也可以复用,从而不再建立SSL连接等。
结论:默认情况下(HTTP/1.1)建立TCP连接不会断开,只有在请求报头中声明Connection: close才会请求完成之后关闭连接。不断开的最终目的是减少建立连接所导致的性能损耗。
————————————————
问题二:一个TCP连接可以对应几个HTTP请求?
如果Connection为close,则一个TCP连接只对应一个HTTP请求。
如果Connection为Keep-alive,则一个TCP连接可对应一个到多个HTTP请求。
问题三:一个TCP连接中,可以同时发送多个HTTP请求吗?
HTTP/1.1中单个TCP连接在同一时刻只能处理一个请求。HTTP/1.1在RFC 2616中规定了Pipelining来解决这个问题,但浏览器默认是关闭的。
RFC 2616中规定:一个支持持久连接的客户端可以在一个连接中发送多个请求(不需要等待任意请求的响应)。收到请求的服务器必须按照请求收到的顺序发送响应。
Pipelining本身存在一些问题,比如代理服务器不能正确处理HTTP Pipelining、Head-of-line Blocking连接头阻塞(首个请求耗时过长,阻塞其他请求)。所以,浏览器默认关闭该功能。
HTTP/2.0提供了多路复用技术Multiplexing,一个TCP可以并发多个HTTP请求(理论无上限,但是一般浏览器会有TCP并发数的限制)。
HTTP/1.1中为了提升性能,通常会采用连接复用和同时建立多个TCP连接的方式提升性能。
结论:HTTP/1.1中存在Pipelining技术支持一个连接发送多个请求,但存在弊端,浏览器默认关闭。HTTP/2.0中通过多路复用技术支持一个TCP连接中并发请求HTTP。
问题四:浏览器对同一Host建立TCP连接的数量有没限制?
不同浏览器限制不同,比如Chrome最多允许同一个Host可建立6个TCP连接。
如果服务器只支持HTTP/1.1,浏览器会采用在同一个Host下建立多个TCP连接来进行效率提升。如果是基于HTTPS传输,在SSL握手之后,还会尝试协商是否可以采用HTTP/2.0的Multiplexing功能。
问题五:keep-alive使用场景及优缺点
开启keep-alive对内存要求高,关闭keep-alive对CPU要求高;如果内存和CPU都足够,开启和关闭keep-alive对性能影响不大;
如果考虑服务器压力,如果是静态页面,大量的调用js或者图片的话,建议开启keep-alive;如果是***页,建议关闭keep-alive。
注意事项:如果需要使用keep-alive功能,服务器端如果使用nginx中keepalive_timeout值要大于0。
小结
通过上面的整体分析,我们不仅了解了TCP与HTTP之间的关系,还明确了现代浏览器基于不同的HTTP协议所作出的网络层面优化。而HTTP2/0的多路复用机制还是一些高性能框架的基础,比如gRPC的实现。
get和post分别是什么?哪个更高效?区别是什么?
区别
GET产生一个TCP数据包;POST产生两个TCP数据包。
对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);
而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。
这样看起来,因为POST需要两步,时间上消耗的要多一点,所以GET比POST更有效。
精简版区别:Get / post区别:可缓存/不可;保留历史参数/不留;信息可见不安全/较安全;长度限制/不限制
区别详述:
-
get数据明文存放在http请求行的url之后,post则是将提交的数据放在http请求报文的请求体中;(即GET参数通过URL传递,POST放在Request body中)
-
POST比GET更安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
-
GET请求只能进行url编码,而POST支持多种编码方式。
-
受浏览器对url长度的限制,get传送数据量应不超过2KB。post传送数据量则一般无此限制;
-
对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
-
get不能改变服务器的数据,一般用于从服务器获取数据,是幂等的;post可以改变服务器的数据,不是幂等的;
-
get请求可以被浏览器主动缓存,下一次若传输数据相同,则优先返回缓存中的内容,以加快显示速度。post请求不会,除非手动设置一下;
-
get请求参数会被完整地保存在浏览器历史记录中,post请求参数则不会保留。
GET 请求能传图片吗?
图片一般有两种传输方式:base64 和 file 对象。 base64 的本质是字符串,而 GET 请求的参数在 url 里面,所以直接把图的 base64 数据放到 url 里面,就可以实现 GET 请求传图片。
input 输入框拿到的图是 file 对象,图片 file 对象转 base64 ; GET 请求的 url 长度是有限制的,不同的浏览器长度限制不一样,最长的大概是 10k 左右,根据 base64 的编码原理,base64 图片大小比原文件大小大 1/3,所以说 base64 只能传一些非常小的小图,大图的 base64 太长会被截断。 但其实这个长度限制是浏览器给的,而不是 GET 请求本身,也就说,在服务端,GET 请求长度理论上无限长,也就是可以传任意大小的图片。
HTTP与HTTPS的区别?
- 运行层次
- 数据安全
- 端口