HTTP是哪一层的协议?七层协议模型是哪七层?
OSI七层协议模型:
从下到上:物联网叔会使用
物理层,数据链路层,网络层,运输层,会话层,表示层,应用层
- 应用层的任务是通过应用进程间的交互来完成特定网络应用。包括的协议有HTTP、DNS、SMTP。
- 运输层的任务是负责向两台主机进程之间的通信提供通用的数据传输服务。包括的协议有TCP、UDP。
- 网络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。包括的协议有IP协议。
- 数据链路层的任务是负责两台主机之间的数据传输,将网络层交下来的 IP 数据报组装成帧。
- 物理层的任务是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。
HTTP协议中浏览器和服务器进行交互的四种方法?
基本方法有四种,分别是Get,Post,Put,Delete,这四种方法可以理解为对服务器资源的增删改查。
- Get:从服务器上获取数据,也就是所谓的查,仅仅是获取服务器资源,不进行修改。
- Post:向服务器提交数据,这涉及到了数据的更改,也就是更改服务器的数据。
- Put:向服务器新添加数据
- Delete:删除服务器的数据
Forword和Redirect的区别?
浏览器URL地址:
- Forward是浏览器内部的重定向,服务器内部请求某个Servlet,然后获取响应的内容,浏览器的URL地址是不会变化的。
- Redirect是客户端请求服务器,然后服务器给客户端返回了一个302和一个新的location,客户端重新发起HTTP请求,服务器给客户端响应location对应的URL地址,浏览器的URL地址发生了变化。
数据的共享:
- Forward是服务器内部的重定向,request请求在整个重定向的过程中是不变的,request中的信息在Servlet间是共享的。
- Redirect发起了两次的HTTP请求分别是使用的不同的request。
请求的次数:
- Forward只有一次请求
- Redirect有两次请求。
Get请求和Post请求的区别?
用途:
- get请求用来从服务器获取资源
- post请求用来想服务器提交数据
请求参数:
- Get请求方式是不安全的,因为它会把参数明文放在url中;
- 而Post请求方式是通过请求体来传递参数的。
数据的大小:
- Get请求提交的url中数据最多只能是2048字节,这个限制是浏览器或者服务器添加的;
- Post请求传输的数据理论上没有大小限制。
编码方式:
- GET 编码格式只能用ASCII码
- POST没有限制
缓存:
- get请求可以被浏览器缓存并可以被收藏为标签
- post请求不会被浏览器缓存也不能被收藏为标签
TCP 协议如何保证可靠传输
- 应用数据被分割成 TCP 认为最适合发送的数据块。
- TCP 给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
- 校验和: TCP 将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。
- TCP 的接收端会丢弃重复的数据。
- 流量控制: TCP 连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 (TCP 利用滑动窗口实现流量控制)
- 拥塞控制: 当网络拥塞时,减少数据的发送。
- ARQ协议: 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。
- 超时重传: 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
TCP和UDP的区别,以及各自的优缺点?
- TCP是面向连接的(比如打电话之前需要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接;
- TCP提供可靠的传输,通过TCP传输的数据是无差错、不丢失、不重复且按序到达;UDP是尽最大努力交付,即不保证可靠交付。
- UDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性有较高要求的通信。
- 每一条TCP连接都只能是点对点的;而UDP支持一对一、一对多、多对一、多对多的交互通信
- TCP对系统资源要求较多,UDP对系统资源要求较少。
滑动窗口和流量控制
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
拥塞控制
在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。
为了进行拥塞控制,TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP的拥塞控制采用了四种算法,即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。
- 慢开始: 慢开始算法的思路是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。经验表明,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1,每经过一个传播轮次,cwnd加倍。
- 拥塞避免: 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大,即每经过一个往返时间RTT就把发送放的cwnd加1.
- 快重传与快恢复: 在 TCP/IP 中,快速重传和恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。有了 FRR,就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时,快速重传和恢复(FRR)能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时,它则不能很有效地工作。
说一下 HTTP 和 HTTPS 的区别
- 端口不同:HTTP和 HTTPS 的连接方式不同,的端口也不一样,HTTP是80, HTTPS 用的是443
- 消耗资源:和HTTP相比,HTTPS通信会因为加解密的处理消耗更多的CPU和内存资源。
- 开销: HTTPS 通信需要证书,这类证书通常需要向认证机构申请或者付费购买。
说一下HTTP的长连接与短连接的区别
HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
短连接
在HTTP/1.0中默认使用短链接,也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端访问的某个HTML或其他类型的Web资源,如 JavaScript 文件、图像文件、 CSS 文件等。当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话.
长连接
从HTTP/1.1起,默认使用长连接,用以保持连接特性。在使用长连接的情况下,当一个网页打开完 成后,客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭。如果客户端再次访问这个服务 器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。
Cookie的作用是什么?和Session有什么区别?
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式,但是两者的应用场景不太一样。
Cookie 一般用来保存用户信息 比如①我们在 Cookie 中保存已经登录过得用户信息,下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了;②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了,这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中,下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑,重新登录一般要将 Token 重写);③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
Cookie 数据保存在客户端(浏览器端),Session 数据保存在服务器端。
Cookie 存储在客户端中,而Session存储在服务器上,相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息,不要直接写入 Cookie 中,最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。