1、TCP/IP五层协议
TCP/IP五层协议的体系结构,自顶向下依次为:应用层、传输层、网络层、数据链路层、物理层。
- 应用层(报文 message)
应用层的任务是通过应用进程间的交互来完成特定网络应用。应⽤层协议定义的是应⽤进程(进程:主机中正在运⾏的程序)间的通信和交互的规则。对于不同的⽹络应⽤需要不同的应⽤层协议,如DNS、HTTP、SMTP等。
- 传输层(报文段 segment)
传输层的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应⽤进程利⽤该服务传送应⽤层报⽂。“通⽤的”是指并不针对某⼀个特定的网络应⽤,⽽是多种应⽤可以使⽤同⼀个运输层服务。由于⼀台主机可同时运⾏多个线程,因此运输层有复⽤和分⽤的功能。所谓复⽤就是指多个应⽤层进程可同时使⽤下⾯运输层的服务,分⽤和复⽤相反,是运输层把收到的信息分别交付上⾯应⽤层中的相应进程。传输层主要有传输控制协议(Transmission Control Protocol,TCP)和用户数据协议(User Datagram Protocol,UDP)两种协议。
- 网络层(数据报 datagram)
在计算机⽹络中进⾏通信的两个计算机之间可能会经过很多个数据链路,也可能还要经过很多通信⼦⽹。⽹络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。 在发送数据时,⽹络层把运输层产⽣的报文段或用户数据报封装成分组和包进⾏传送。
- 数据链路层(帧 frame)
数据链路层通常简称为链路层。两台主机之间的数据传输,总是在⼀段⼀段的链路上传送的,这就需要使⽤专⻔的链路层的协议。 在两个相邻节点之间传送数据时,数据链路层将⽹络层交下来的 IP 数据报组装成帧,在两个相邻节点间的链路上传送帧。每⼀帧包括数据和必要的控制信息(如同步信息,地址信息,差错控制等)。
- 物理层(比特 bit)
在物理层上所传送的数据单位是比特。物理层的作用是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。 使其上⾯的数据链路层不必考虑网络的具体传输介质是什么。“透明传送⽐特流”表示经实际电路传送后的比特流没有发⽣变化,对传送的比特流来说,这个电路好像是看不见的。
2、三次握手以及为什么需要三次握手
为什么需要三次?
- 防止旧的重复连接初始化造成混乱(主要原因)
如果是两次握手连接,就不能判断当前连接是否是历史连接,三次握手则可以在客户端(发送方)准备发送第三次报文时,客户端因有足够的上下文来判断当前连接是否是历史连接。
- 同步双方的初始序列号
那当服务端发送初始序列号给客户端的时候,依然也要得到客户端的应答回应,这样一来一回,才能确
保双方的初始序列号能被可靠的同步。 - 避免资源浪费
由于没有第三次握手,服务器不清楚客户端是否收到了自己发送的建立连接的
ACK
确认信号,所以每收到一个SYN
就只能先主动建立一个连接。如果客户端的SYN
阻塞了,重复发送多次SYN
报文,那么服务器在收到请求后就会建立多个冗余的无效链接,造成不必要的资源浪费。
不使用两次握手和四次握手的原因
- 两次握手:无法防止历史连接的建立,会造成双方资源的浪费,也无法可靠的同步双方序列号;
- 四次握手:三次握手就已经理论上建立可靠的连接了,所以不需要使用更多的通信次数。
3、四次挥手以及为什么需要四次挥手
为什么需要四次挥手
回顾下四次挥手双方发
FIN
包的过程,就能理解为什么需要四次了
- 关闭连接时,客户端向服务端发送
FIN
时,仅仅表示客户端不再发送数据了但是还能接收数据。 - 服务器端收到客户端的
FIN
报文时,先回一个ACK
应答报文,而服务端可能还有数据需要处理和发送,等服务端不再发送数据时,才会发送FIN
报文给客户端来表示同意现在关闭连接。 - 从上面过程可知,服务端通常需要等待完成数据的发送和处理,所以服务端的
ACK
和FIN
一般都会分开发送,从而比三次握手导致多了一次。
为什么TIME_WAIT等待的时间是2MSL
MSL,Maximum Segment Lifetime英文的缩写,报文最大生存时间,它是任何报文在网络上存在的最长时间,超过这个时间将被丢弃。
- 保证客户端发送的最后一个
ACK
报文能够到达服务器,因为这个ACK
报文可能会丢失。 - 如果被动关闭方没有收到断开连接的最后的
ACK
报文,就会触发超时重发Fin
报文,另一方接收到FIN
后,会重发ACK
给被动关闭方,一来一去正好 2 个 MSL。
4、TCP,UDP协议的区别
概述
- TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议,是专门为了在不可靠的网络中提供一个可靠的端对端字节流而设计的,面向字节流。
- UDP(用户数据报协议)是一种无连接的传输层协议,提供简单不可靠的非连接传输层服务,面向报文。
区别:
- TCP是面向连接的,可靠性高;UDP是基于非连接的,可靠性低。
- 由于TCP是连接的通信,需要有三次握手、重新确认等连接过程,会有延时,实时性差,同时过程复杂;UDP没有建立连接的过程,因而实时性较强,但在某些情况下 UDP 确是⼀种最有效的⼯作⽅式。
- TCP报头比UDP复杂,故实际包含的用户数据较少,传输开销比较大;UDP首部开销小,传输数据报文时是很高效的。
- 每条TCP连接只能是点到点的;UDP支持一对一、一对多、多对一、多对多的交互通信。
区别(表形式)
TCP | UDP | |
---|---|---|
是否连接 | 面向连接 | 无连接 |
是否可靠 | 可靠传输,使用流量控制和拥塞控制 | 不可靠传输,不使用流量控制和拥塞控制 |
连接对象个数 | 只能是一对一通信 | 支持一对一,一对多,多对一和多对多交互通信 |
传输方式 | 面向字节流 | 面向报文 |
首部开销大 | 首部最小20字节,最大60字节 | 首部开销小,仅8字节 |
适用场景 | 适用于要求可靠传输的应用,例如文件传输 | 适用于实时应用(IP电话、视频会议、直播等) |
5、TCP协议如何保证可靠传输
- 应⽤数据被分割成 TCP 认为最适合发送的数据块。
- TCP 给发送的每⼀个包进⾏编号,接收方对数据包进⾏排序,把有序数据传送给应⽤层。
- 校验和: TCP 将保持它⾸部和数据的检验和。这是⼀个端到端的检验和,⽬的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报⽂段和不确认收到此报⽂段。
- TCP 的接收端会丢弃重复的数据。
- 流量控制:TCP 连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收⽅来不及处理发送⽅的数据,能提示发送⽅降低发送的速率,防止包丢失。TCP 使⽤的流量控制协议是可变大小的滑动窗⼝协议。 (TCP 利⽤滑动窗⼝实现流量控制)
- 拥塞控制: 当网络拥塞时,减少数据的发送。
- 重传机制: 网络在实际中是错综复杂的,数据在传输过程中丢失的情况也会存在,所以 TCP 针对数据包丢失的情况,会用重传机制解决。
6、常见的重传机制
- 超时重传
- 快速重传
- SACK
- D-SACK
7、超时重传
概念
超时重传,就是在发送数据时,设定一个定时器,当超过指定的时间后,没有收到对方的
ACK
确认应答报文,就会重发该数据,也就是我们常说的超时重传。
TCP会在以下两种情况发生超时重传:
- 数据包丢失
- 确认应答丢失
超时时间应该设置为多少呢
首先需要先了解RTT(Round-Trip Time 往返时延),RTT就是数据从网络一端传送到另一端所需的时间,也就是包的往返时间。
超时重传时间以RTO(Retransmission Timeout)来表示,RTO过长或过短分别会发生以下情况:
- 当超时时间RTO较大时,网络的空隙时间增大,降低了网络传输效率;
- 当超时时间RTO较小时,会导致不必要的重传,增加网络拥塞,导致更多的超时,更多的超时导致更多的重发。
精确的测量超时时间 RTO 的值是非常重要的,这可让我们的重传机制更高效。
根据上述的两种情况,我们可以得知,超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。实际上报文往返RTT的值是经常变化的,因为我们的网络也是时常变化的。也就因为报文往返
RTT的 是经常波动变化的,所以超时重传时间 RTO 的值应该是一个动态变化的值。如果超时重发的数据,再次超时的时候,又需要重传的时候,TCP 的策略是超时间隔加倍。也就是每当遇到一次超时重传的时候,都会将下一次超时时间间隔设为先前值的两倍。两次超时,就说明网络环境差,不宜频繁反复发送。
超时触发重传存在的问题是,超时周期可能相对较长。那是不是可以有更快的方式呢?于是就可以快速重传机制来解决超时重发的时间等待。
8、快速重传
概念
TCP还有另外一种快速重传(Fast Retransmit)机制,它不以时间为驱动,而是以数据驱动重传。
快速重传的工作方式是当收到三个相同的 ACK 报文时,会在定时器过期之前,重传丢失的报文段。快速重传机制只解决了一个问题,就是超时时间的问题,但是它依然面临着另外一个问题。就是重传的时候,是重传之前的一个,还是重传所有的问题。
比如图中的例子,是重传 Seq2 呢?还是重传 Seq2、Seq3、Seq4、Seq5 呢?因为发送端并不清楚这连续的三个 Ack 2 是谁传回来的。
为了解决不知道该重传哪些TCP报文的问题,于是就有SACK方法。
9、SACK方法
SACK(Selective Acknowledgment 选择性确认),这种方式需要在 TCP 头部选项字段里加一个 叫SACK 的东西,它可以将缓存的地图发送给发送方,这样发送方就可以知道哪些数据收到了,哪些数据没收到,知道了这些信息,就可以只重传丢失的数据。
如上图,发送方收到了三次同样的ACK确认报文,于是就会触发快速重发机制,通过SACK信息发现只有200~299这段数据丢失,则重发时,就只选择了这个 TCP 段进行重传。
如果要支持SACK,必须双方都要支持。在 Linux 下,可以通过
net.ipv4.tcp_sack
参数打开这个功能(Linux 2.4 后默认打开)
10、Duplicate SACK(D-SACK)
D-SACK,其主要使用了 SACK 来告诉发送方有哪些数据被重复接收了。
下面以两个例子,来说明D-SACK的作用。
-
ACK丢包
D-SACK例1 ACK丢包
接收发给发送方的两个 ACK 确认应答都丢失了,所以发送方超时后,重传第一个数据包(3000 ~ 3499)
于是接收方发现数据是重复收到的,于是回了一个 SACK = 3000~3500,告诉发送方3000~3500 的数据早已被接收了,因为 ACK 都到了 4000 了,已经意味着 4000 之前的所有数据都已收到,所以这个 SACK 就代表着 D-SACK 。
这样发送方就知道了,数据没有丢,是接收方的 ACK 确认报文丢了。
-
网络延时
D-SACK例2 网络延时
- 数据包(1000~1499)被网络延迟了,导致发送方没有收到 Ack 1500 的确认报文。
- 而后面报文到达的三个相同的 ACK 确认报文,就触发了快速重传机制,但是在重传后,被延迟的数据包(1000~1499)又到了接收方;
- 所以接收方回了一个 SACK=1000~1500,因为 ACK 已经到了 3000,所以这个 SACK 是 D-SACK,表示收到了重复的包。
- 这样发送方就知道快速重传触发的原因不是发出去的包丢了,也不是因为回应的 ACK 包丢了,而是因为网络延迟了。
D-SACK有这么几个好处:
- 可以让发送方知道,是发出去的包丢了,还是接收方回应的 ACK 包丢了;
- 可以知道是不是发送方的数据包被网络延迟了;
- 可以知道网络中是不是把发送方的数据包给复制了。
11、滑动窗口
引入滑动窗口的原因
TCP 是每发送一个数据,都要进行一次确认应答。当上一个数据包收到应答了,再发送下一个。这种方式的缺点是效率比较低,而且数据包的往返时间越长,通信的效率就越低。
为解决这个问题,TCP 引入了窗口这个概念。即使在往返时间较长的情况下,它也不会降低网络通信的效率。
窗口的实现
窗口的实现实际上是操作系统开辟的一个缓存空间,发送方主机在等到确认应答返回之前,必须在缓冲区中保留已发送的数据。如果按期收到确认应答,此时数据就可以从缓存区清除。
窗口的大小
那么有了窗口,就可以指定窗口大小,窗口大小就是指无需等待确认应答,而可以继续发送数据的最大值。
假设窗口大小为3个TCP 段,那么发送方就可以连续发送3个TCP段,并且中途若有ACK丢失,可以通过下一个确认应答进行确认。
窗口应用示例
图中的 ACK 600 确认应答报文丢失,也没关系,因为可以通过下一个确认应答进行确认,只要发送方收到了 ACK 700 确认应答,就意味着 700 之前的所有数据接收方都收到了。这个模式就叫累计确认或者累计应答。
但是,这种方法不能向发送方反映出接收方已经正确接收到的所有分组的信息。例如,如果发送⽅发送了5条消息,中间第三条丢失(3号),这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,而只好把后三个全部重传⼀次。这也叫 Go-Back-N(回退 N),表示需要退回来重传已经发送过的 N 个消息。
窗口的大小由哪一方决定?
TCP 头里有一个字段叫 Window ,也就是窗口大小。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。所以,通常窗口的大小是由接收方的窗口大小来决定的。发送方发送的数据大小不能超过接收方的窗口大小,否则接收方就无法正常接收到数据。
12、流量控制
TCP 利用滑动窗⼝实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收(让发送方根据接收方的实际接收能力控制发送的数据量)。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
13、拥塞控制
概述
在网络出现拥堵时,如果继续发送大量数据包,可能会导致数据包时延、丢失等,这时 TCP 就会重传数据,但是一重传就会导致网络的负担更重,于是会导致更大的延迟以及更多的丢包,这个情况就会进入恶性循环被不断地放大。当网络发送拥塞时,TCP会自我牺牲,降低发送的数据量。于是,就有了拥塞控制,控制的目的就是避免发送方的数据填满整个网络。与流量控制的区别?
拥塞控制是⼀个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送方发送数据的速率,以便使接收方来得及接收。-
拥塞窗口
为了进行拥塞控制,TCP 发送方要维持⼀个 **拥塞窗口(cwnd) **的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的⼀个。
拥塞窗口cwnd变化的规则:- 只要网络中没有出现拥塞, cwnd 就会增大;
- 但网络中出现了拥塞, cwnd 就减少;
14、拥塞控制的方法:
- 慢启动
是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。经验表明,较好的方法是先探测⼀下,即由小到⼤逐渐增大发送窗⼝,也就是由小到大逐渐增大拥塞窗⼝数值。cwnd初始值为1,每经过⼀个传播轮次,cwnd加倍(可以看作当发送方每收到一个 ACK,拥塞窗口 cwnd 的大小就会加 1)。
- 拥塞避免
慢启动算法,发包的个数是指数性的增长,当拥塞窗口 cwnd 超过慢启动门限 ssthresh 就会进入拥塞避免算法。拥塞避免算法的思路是让拥塞窗⼝cwnd缓慢增⼤,即每经过⼀个往返时间RTT就把发送方的cwnd加1(每当收到一个 ACK 时,cwnd 增加 1/cwnd)。拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长,还是增长阶
段,但是增长速度缓慢了一些。
- 拥塞发生
当网络出现拥塞,也就是会发生数据包重传,重传机制主要有两种:超时重传和快速重传。当发生了超时重传,就会使用拥塞发生算法。这个时候,慢启动门限ssthresh 和 cwnd 的值会发生变化:ssthresh ==cwnd/2,cwnd=1。接着,就重新开始慢启动,慢启动是会突然减少数据流的。这真是一旦超时重传,马上回到解放前。但是这种方式太激进了,反应也很强烈,会造成网络卡顿。
- 快速恢复
快速重传和快速恢复算法一般同时使用,快速恢复算法是认为,你还能收到 3 个重复 ACK 说明网络也不那么糟糕,所以没有必要像超时重传那么强烈。在进入快速恢复之前, cwnd 和 ssthresh 已被更新了:cwnd=cwnd/2,ssthresh=cwnd。然后,进入快速恢复算法如下:
- 拥塞窗口cwnd=ssthresh+3(3 的意思是确认有 3 个数据包被收到了);
- 重传丢失的数据包;
- 如果再收到重复的 ACK,那么 cwnd 增加 1;
- 如果收到新数据的 ACK 后,把 cwnd 设置为第一步中的 ssthresh 的值,原因是该 ACK 确认了新的数据,说明从 duplicated ACK 时的数据都已收到,该恢复过程已经结束,可以回到恢复之前的状态了,也即再次进入拥塞避免状态。
15、在浏览器中输入url,到页面显示的过程
- 浏览器解析url中的信息
- DNS解析
- TCP连接
- 发送HTTP请求
- 服务器处理请求并返回HTTP报⽂
- 浏览器解析渲染⻚⾯
- 连接结束
16、HTTP常见响应码
- 1X:信息,接收的请求正在处理(100:Continue。客户端应继续其请求)
- 2XX:成功,请求正常处理完毕(200:Ok正常)
- 3XX:重定向,需要进行附加操作以完成请求(301:Moved Permanently,永久重定向,302:Found,暂时重定向)
- 4XX:客户端错误,服务器无法处理请求 (400:Bad Request, 404:Not Found,403:Forbidden)
- 5XX:服务器错误,服务器处理请求出错(500:Internal Server Error,502:Bad Gateway:作为网关或者代理服务器尝试执行请求时,从远程服务器接受到了无效的响应)
17、HTTP长连接,短连接
- 在HTTP/1.0中默认使⽤短连接。也就是说,客户端和服务器每进⾏⼀次HTTP操作,就建⽴⼀次连接,任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web⻚中包含有其他的Web资源(如JavaScript⽂件、图像⽂件、CSS⽂件等),每遇到这样⼀个Web资源,浏览器就会重新建⽴⼀个HTTP会话。
- 从HTTP/1.1起,默认使⽤⻓连接,⽤以保持连接特性。使⽤⻓连接的HTTP协议,会在响应头加入这行代码:
Connection:keep-alive
。在使⽤⻓连接的情况下,当⼀个⽹⻚打开完成后,客户端和服务器之间⽤于传输HTTP数据的TCP连接不会关闭,客户端再次访问这个服务器时,会继续使⽤这⼀条已经建⽴的连接。Keep-Alive
不会永久保持连接,它有⼀个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现⻓连接需要客户端和服务端都⽀持长连接。
HTTP协议的⻓连接和短连接,实质上是TCP协议的⻓连接和短连接。
18、HTTP是无状态协议,如何保存用户状态?
HTTP 是⼀种不保存状态的协议,即无状态(stateless)协议。也就是说 HTTP 协议⾃身不对请求和响应之间的通信状态进⾏保存。
无状态的利弊:
- 无状态的好处,因为服务器不会去记忆 HTTP 的状态,所以不需要额外的资源来记录状态信息,这能减轻服务器的负担,能够把更多的 CPU 和内存用来对外提供服务。
- 无状态的坏处,既然服务器没有记忆能力,它在完成有关联性的操作时会非常麻烦。
对于无状态的问题,解法方案有很多种,其中比较简单的方式用 Cookie 技术。Cookie的工作原理如下:
(1)浏览器端第一次发送请求到服务器端
(2)服务器端创建Cookie,该Cookie中包含用户的信息,然后将该Cookie发送到浏览器端
(3)浏览器端再次访问服务器端时会携带服务器端创建的Cookie
(4)服务器端通过Cookie中携带的数据区分不同的用户
此外,还有Session机制来解决这一问题。Session的工作原理如下:
(1)浏览器端第一次发送请求到服务器端,服务器端创建一个Session,同时会创建一个特殊的Cookie(name为JSESSIONID的固定值,value为session对象的ID),然后将该Cookie发送至浏览器端
(2)浏览器端发送第N(N>1)次请求到服务器端,浏览器端访问服务器端时就会携带该name为JSESSIONID的Cookie对象
(3)服务器端根据name为JSESSIONID的Cookie的value(sessionId),去查询Session对象,从而区分不同用户。
19、Cookie的作用是什么?和Session有什么区别
Cookie 和 Session都是⽤来跟踪浏览器⽤户身份的会话⽅式,但是两者的应⽤场景不太⼀样。
Cookie ⼀般⽤来保存⽤户信息。比如①我们在 Cookie 中保存已经登录过得⽤户信息,下次访问⽹站的时候⻚⾯可以⾃动帮你登录的⼀些基本信息给填了;②⼀般的⽹站都会有保持登录也就是说下次你再访问⽹站的时候就不需要重新登录了,这是因为⽤户登录的时候我们可以存放了⼀个Token 在 Cookie 中,下次登录的时候只需要根据 Token 值来查找⽤户即可(为了安全考虑,重新登录⼀般要将 Token 重写);③登录⼀次⽹站后访问⽹站其他⻚⾯不需要重新登录。
Session 的主要作⽤就是通过服务端记录⽤户的状态。 典型的场景是购物⻋,当你要添加商品到购物⻋的时候,系统不知道是哪个⽤户操作的,因为 HTTP 协议是⽆状态的。服务端给特定的⽤户创建特定的 Session 之后就可以标识这个⽤户并且跟踪这个⽤户了。
Cookie数据存储在客户端(浏览器)中,⽽Session数据保存在服务器上,相对来说 Session 安全性更⾼。如果要在Cookie 中存储⼀些敏感信息,不要直接写⼊ Cookie 中,最好能将 Cookie 信息加密然后使⽤到的时候再去服务器端解密。
20、HTTP1.0和HTTP1.1的主要区别是什么
HTTP1.0最早在⽹⻚中使⽤是在1996年,那个时候只是使⽤⼀些较为为简单的⽹⻚上和⽹络请求上,⽽HTTP1.1则在1999年才开始⼴泛应⽤于现在的各⼤浏览器⽹络请求中,同时HTTP1.1也是当前使⽤最为⼴泛的HTTP协议。 主要区别主要体现在:
- ⻓连接 : 在HTTP/1.0中,默认使⽤的是短连接,也就是说每次请求都要重新建⽴⼀次连接。HTTP 是基于TCP/IP协议的,每⼀次建⽴或者断开连接都需要三次握⼿四次挥⼿的开销,如果每次请求都要这样的话,开销会⽐⼤。因此最好能维持⼀个⻓连接,可以⽤个⻓连接来发多个请求。HTTP 1.1起,默认使⽤⻓连接 ,默认开启Connection: keep-alive。 HTTP/1.1的持续连接有⾮流⽔线⽅式和流⽔线⽅式 。流⽔线⽅式是客户在收到HTTP的响应报⽂之前就能接着发送新的请求报⽂。与之相对应的⾮流⽔线⽅式是客户在收到前⼀个响应后才能发送下⼀个请求。
- 错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发⽣冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
- 缓存处理 :在HTTP1.0中主要使⽤header⾥的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引⼊了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match,If-None-Match等更多可供选择的缓存头来控制缓存策略。
- 带宽优化及⽹络连接的使⽤ :HTTP1.0中,存在⼀些浪费带宽的现象,例如客户端只是需要某个对象的⼀部分,⽽服务器却将整个对象送过来了,并且不⽀持断点续传功能,HTTP1.1则在请求头引⼊了range头域,它允许只请求资源的某个部分,即返回码是206(PartialContent),这样就⽅便了开发者⾃由的选择以便于充分利⽤带宽和连接。
21、URI和URL的区别是什么?
- URI(Uniform Resource Identifier) 是统⼀资源标志符,可以唯⼀标识⼀个资源。
- URL(Uniform Resource Location) 是统⼀资源定位符,可以提供该资源的路径。它是⼀种具体的 URI,即 URL 可以⽤来标识⼀个资源,⽽且还指明了如何 locate 这个资源。
URI的作⽤像身份证号⼀样,URL的作⽤更像家庭住址⼀样。URL是⼀种具体的URI,它不仅唯⼀标识资源,⽽且还提供了定位该资源的信息。
22、HTTP和HTTPS的区别
- 端⼝ :HTTP的URL由“http://”起始且默认使⽤端⼝80,⽽HTTPS的URL由“https://”起始且默认使⽤端⼝443。
- 安全性和资源消耗: HTTP协议运⾏在TCP之上,所有传输的内容都是明⽂,客户端和服务器端都⽆法验证对⽅的身份。HTTPS是运⾏在SSL/TLS之上的HTTP协议,SSL/TLS 运⾏在TCP之上。所有传输的内容都经过加密,加密采⽤对称加密,但对称加密的密钥⽤服务器⽅的证书进⾏了⾮对称加密。所以说,HTTP 安全性没有 HTTPS⾼,但是 HTTPS ⽐HTTP耗费更多服务器资源。
- 对称加密:密钥只有⼀个,加密解密为同⼀个密码,且加解密速度快,典型的对称加密算法有DES、AES等;
- ⾮对称加密:密钥成对出现(且根据公钥⽆法推知私钥,根据私钥也⽆法推知公钥),加密解密使⽤不同密钥(公钥加密需要私钥解密,私钥加密需要公钥解密),相对对称加密速度慢,典型的⾮对称加密算法有RSA、DSA等。