OSI的七层协议体系结构的概念清除,理论也比较完整,但它既复杂又不实用。
TCP/IP是一个四层体系结构,TCP/IP体系结构虽然简单,但它现在却得到了非常广泛的使用。
在学习中我们采用折中的办法,学习具有五层协议的原理体系结构
物理层
物理层是原理体系结构的最底层,负责完成计算机网络中最基础的任务,即在传输媒体上传送比特流。
物理层作用:
数据链路层
数据链路层位于物理层之上,网络层之下,将网络层传下的IP数据报封装成 帧,通过差错控制、流量控制等方法,将分组从链路的一端传送到另一端,丢弃有差错的帧保证物理层收到的分组是无差错的信息。
数据链路层的几个基本方法:
网络层(IP层)
网络层负责为分组交换网上的不同 主机间 提供通信服务。
实现网络地址与物理地址的转换,并通过路由选择算法为分组通过通信子网选择最适当的路径。网络层传输的数据单元为 IP数据报(数据报)
运输层(传输层)
运输层负责向两台主机中进程之间的通信提供通用的数据传输服务。
运输层主要的两个运输层协议:
应用层
为用户的应用进程提供网络通信服务,完成和实现用户请求的各种服务。
该模型展示了主机1 向 主机2 发送数据时数据入协议栈和出协议栈的过程
入栈过程:数据发送方每层不断的封装首部和尾部,添加一些传输的信息,确保能传输到目的地。
出栈过程:数据接收方每层不断的拆除首部和尾部,得到最终传输的数据。
数据链路层以帧为单位传输和数据处理,网络层的IP数据报必须向下传递到数据链路层,成为帧的数据部分,同时它的前面和后面同时添加了帧首部和帧尾部,封装成一个完整的帧。帧的长度等于帧的数据部分长度加上帧首部和帧尾部的长度。
每个帧首和帧尾都为特定的字符,当我们要传输的数据中出现了与帧首帧尾相同的字符时,原始数据就会被误判帧首帧尾,这时候就需要将数据部分中与帧首帧尾相同的字符用一个转义字符来填充进行转义,如果原始数据中也出现了转义字符,这时候转义字符也用转义字符转义,从而实现原始数据的透明传输
现实中的通信链路都不会是理想的,比特在传输过程中可能会产生差错:1可能会变成0,而0也可能变成1.这就叫做比特差错,为了防止这种差错,在数据链路层通常使用 **循环冗余校验(CRC)**技术进行差错检测
循环冗余校验计算方法:加法不进位,减法不借位,等价于按位异或(XOR),乘以2和除以2都等价于左/右移位。
上图为循环冗余校验原理的例子
IP地址
整个因特网就是一个单一的逻辑网络。IP地址就是给英特网上的每一个主机(或路由器)的每一个接口分配一个在全世界范围是唯一的32的标识符。IP地址的结构使我们可以在因特网上很方便的进行寻址。
为了提高可读性,我们常常把32位的IP地址中的每8位用其等效的十进制数字表示,并且在这些数字之间加上一个点。这种表示称为点分十进制记法
如下图:
编址方式
下面重点介绍一下无分类编址:
无分类编址的网络前缀是不定长的,用来代替分类编址的’‘网络号’'并指明网络,后面的部分则用来指明主机。
网络前缀计算方式:只需要将子网掩码和IP地址进行逐位的“与”运算,就可以得出其网络地址(主机号全为0的地址)。
相同IP地址和不同的子网掩码得到的网络地址:
这两个例子说明,相同的IP地址和不同的子网掩码可以得出相同的网络地址,但是不同的子网掩码效果是不同的。虽然这两个例子中网络地址空间起始地址是一样的,但是最大地址是不一样的,各自容纳的最大主机数都是不一样的。
我们知道,网络层使用的是IP地址,但在具体物理网络的链路上传送数据帧时,最终还是必须使用该物理网络的物理地址。但IP地址和物理网络地址又不是单一的映射关系,这时候就需要用到 地址解析协议(ARP)
ARP地址解析协议工作原理
ARP是根据IP地址获取MAC地址的一种协议,核心原理就是广播发送ARP请求,单播发送ARP响应。
因特网控制报文协议,用于在IP主机、路由器之间传递控制信息(控制信息是指网络通不通,主机是否可达,路由器是否可用等网络本身的信息),确认IP包是否成功到达目的地址。因为IP协议并不是一个可靠的协议,它不保证数据被送达,当传送IP数据包发生错误,比如主机不可达、路由不可达等等,ICMP协议将会把错误信息封包,然后传回给主机,给主机一个处理错误的机会。
ICMP报文的种类有两种,即ICMP差错报告报文和ICMP询问报文
ICMP差错报告报文
ICMP询问报文
内部网关协议(IGP)
内部网关协议即在一个自治系统内部使用的路由选择协议,而这与在互联网中的其他自治系统选用什么路由选择协议无关。目前这类选择协议很多,如RIP和OSPF协议。
RIP:是一种动态路由选择协议,基于距离矢量算法,使用“跳数”来衡量到达目标地址的路由距离,并且只与自己相邻的路由器交换信息,范围限制在15跳之内。
OSPF:开放最短路径优先协议,使用Dijskra算法计算出到达每一网络的最短路径,并在检测到 链路的情况发生变化时(如链路失效),就执行该算法快速收敛到新的无环路拓扑。
外部网关协议(EGP)
若源主机和目的主机处在不同的自治系统中(这两个自治系统可能使用不同的内部网关协议),就需要在自治系统之间进行路由选择,使用一种协议将路由信息从一个自治系统传递到另一个自治系统中。这样的协议就是外部网关协议EGP。目前因特网使用的外部网关协议就是BGP的版本4。
BGP:边界网关协议,BGP 是力求寻找一条能够到达目的网络 且 较好的路由,而并非要寻找一条最佳路由。BGP采用路径向量路由选择协议。
自治系统之间的路由选择也叫作域间路由选择,而在自治系统内部的路由选择叫作域内路由选择
传输层主要提供不同主机上进程间 逻辑通信+可靠传输 或者 不可靠传输的功能。
TCP是面向字节流的,基本传输单位是TCP报文段;UDP是面向报文的,基本传输单位是用户数据报;
面向字节流:应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序看成一连串的无结构的字节流。TCP有一个缓冲,当应用程序传送的数据块太长,TCP就可以把它划分短一些再传送。
面向报文:面向报文的传输方式是应用层交给UDP多长的报文,UDP就照样发送,因此,应用程序必须选择合适大小的报文。太大会造成IP层对数据进行分片,降低IP层效率;太小会造成首部相对较大,降低IP层效率。
TCP注重安全可靠性,连接双方在通信前要进行三次握手建立连接。UDP是面向无连接的,使用最大努力交付,即不保证可靠交互。
UDP不需要等待,所以数据传输较快,TCP传输效率相对较低。
TCP首部开销是20个字节,UDP首部开销是8个字节,UDP减少了网络传输的部分开销。
TCP有流量控制和拥塞控制,UDP没有流量控制和拥塞控制。
TCP支持点对点通信,提供全双工通信,不提供广播或者多播服务;UDP支持一对一,一对多,多对一,多对多的通信模式。
使用UDP和TCP协议的各种应用和应用层协议:
应用层协议 | 对应运输层协议 | 协议作用 |
---|---|---|
DNS | UDP | 域名解析服务,将域名地址转换为IP地址,使用53号端口 |
TFTP | UDP | 简单文件传输协议,提供不复杂、开销不大的文件传输服务,使用 69 端口 |
RIP | UDP | 路由信息协议 |
DHCP | UDP | 动态主机配置协议 |
SNMP | UDP | 网络管理协议,用来管理网络设备,使用161号端口 |
NFS | UDP | 远程文件服务器 |
IGMP | UDP | 网际组管理协议 |
SMTP | TCP | 邮件传送协议,用于发送邮件,使用25端口 |
TELNET | TCP | 远程终端接入,使用23端口,用户可以以自己的身份远程连接到计算机上,可提供基于DOS模式下的通信服务 |
HTTP | TCP | 万维网超文本传输协议,是从Web服务器传输超文本到本地浏览器的传送协议 |
FTP | TCP | 文件传输协议,使用21端口 |
源端口和目的端口:分别占用16位,指发送方应用程序的端口和目的方应用程序的端口号,通过 IP 地址 + 端口号就可以确定一个进程地址
序号(Sequense Number,SN):在一个TCP连接中传送的字节流中每一个字节都按照顺序编号,该字段表示本报文段所发送数据的第一个字节的序号。(初始序号称为 Init Sequence Number,ISN)
例如,一报文段的序号是 101,共有 100 字节的数据。这就表明:本报文段的数据的第一个字节的序号是 101,最后一个字节的序号是 200。显然,下一个报文段的数据序号应当从 201 开始,即下一个报文段的序号字段值应为 201。
确认号ack:期望收到对方下一个报文段的第一个数据字节的序号。若确认号为 N,则表明:到序号 N-1 为止的所有数据都已正确收到。
数据偏移:指出 TCP报文段的数据起始处 距离 TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。
保留位:占6位,应置为 0,保留为今后使用。
6个控制位:用于说明该报文段的性质:
- 紧急位URG:当 URG = 1 时,表明此报文段中有紧急数据,是高优先级的数据,应尽快发送,不用在缓存中排队。
- 确认ACK:仅当 ACK = 1 时确认号字段才有效,当 ACK = 0 时确认号无效。TCP 规定,在连接建立后所有传送的报文段都必须把 ACK 置为 1。
- 推送PSH:接收方收到 PSH = 1 的报文段时,就直接发送给应用进程,而不用等到整个缓冲区都填满了后再向上传送。
- 复位RST:当 RST = 1 时,表明 TCP 连接中出现了严重错误(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立传输连接。
- 同步SYN:SYN = 1 表示这是一个连接请求或连接接受报文。当 SYN = 1 而 ACK = 0 时,表明这是一个连接请求报文段。对方若同意建立连接,则应在响应的报文段中使 SYN = 1 且 ACK = 1。
- 终止FIN:用来释放一个连接。当 FIN = 1时,表明此报文段的发送发的数据已发送完毕,并要求释放运输连接。
窗口大小:16位,用于控制发送端的滑动窗口大小
校检和:16位,校验数据段是否未被修改
紧急指针:16位。
客户机A主动发送一个SYN报文,该报文指明了第一个字节的初始化序列号(ISN)即seq=x;此时客户端处于SYN-SENT状态
三次握手的一个重要功能是客户端和服务端交换 ISN,以便让对方知道接下来接收数据时如何按序列号组装数据。
ISN 是动态生成的,并非固定,因此每个连接都将具有不同的 ISN。如果 ISN 是固定的,攻击者很容易猜出后续的确认号。
服务器B在收到客户机A发送的SYN报文后,由于SYN=1知道客户端请求建立连接,这时会对这个TCP连接分配缓存和变量(缓冲指的是一个字节流队列),接着返回客户端一个确认报文:设置SYN=1,ACK=1(表示确认号有效) 同时指定自己的初始化序列号ISN,即seq=y,并把客户端的ISN+1作为自己的ack值,表示已经收到客户端发送来的SYN报文,希望收到的下一个数据的第一个字节的序号是x+1,此时服务端进入SYN-RCVD状态。
客户端在收到服务器发送的确认报文后,检查ACK是否为1,ack是否是x+1,如果正确,则给服雾端发送一个ACK报文:设置ACK=1,把服务端的初始化序列号(ISN+1)设置为自己的ack,即ack=y+1,表示已经收到服务端的确认报文,希望收到服务端的下一个数据的字节序号是y+1,并指明此时客户端的初始化序列号为x+1,即seq=x+1,此后客户端和服务端状态都变为ESTABLISHED。完成三次握手,此后服务器和客户端就可以开始传输数据了。
此时SYN控制位已经变成0,表示这不是建立连接的请求了,要正式发送数据了。
两次握手就只能让服务器端对客户端的初始化序列(ISN)进行确认,并不能让客户端对服务器端的初始化序列进行确认,不能达到可靠传输的目的。
三次握手可以防止已失效的连接请求报文段突然又传送到了服务端,导致服务器错误地建立连接,浪费服务端的连接资源。
客户端发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达Server。本来这是一个早已失效的报文段,但Server收到此失效的连接请求报文段后:
① 假设不采用“三次握手”,那么只要Sever发出确认,新的连接就建立了。但由于现在Client并没有发出建立连接的请求,因此不会理睬Server的确认,也不会向Server发送数据。而Server却以为新的连接已经建立,并一直等待Client发来数据,这样,Server的很多资源就白白浪费掉了
② 而采用“三次握手”协议,只要Server收不到来自Client的确认,就知道Client并没有要求建立请求,就不会建立连接了。
第一次挥手:客户端发送FIN报文,设置FIN=1,并指定序列号seq=u(u是之前传过来的最后一个字节的序号+1),主动关闭TCP连接,此时客户端进入FIN-WAIT_1状态。
第二次挥手:服务端收到 FIN 报文后,由FIN=1 知道客户端请求关闭连接,则返回确认报文:设置ACK = 1,ack = u + 1,seq = v(v 的值取决于服务器发送给客户端之前的一个包确认号是多少)
- 服务端进入CLOSE_WAIT状态,此时TCP连接处于半关闭状态,即客户端不能向服务端发送报文,只能接收,但服务端仍然可以向客户端发送数据。
- 客户端收到服务端的确认后,进入 FIN_WAIT_2 状态,等待服务端发出的连接释放报文段。
第三次挥手:当服务端没有要向客户端发送的数据时,就向客户端发送一个 FIN 报文,设置 FIN = 1 并指定序列号 seq = w(w 的值取决于服务器发送给客户端之前的一个包确认号是多少),用于关闭服务端到客户端的数据传送。此时服务器处于 LAST_ACK 状态
第四次挥手:客户端收到 FIN 报文后,发送给服务端一个 ACK 报文作为应答:设置 ACK=1 和 ack = w +1。发送之后,客户端处于 TIME_WAIT状态,如果服务端接收到这个数据包,则进入CLOSED状态,完成四次挥手。
TIME_WAIT 状态持续 2MSL(最大报文存活时间),约4分钟才转换成CLOSE状态。由于TIME_WAIT 的时间会非常长,因此服务端应尽量减少主动关闭连接,TIME_WAIT 的主要作用有:
重发丢失的ACK报文,保证连接可靠关闭
如果客户端连接没有TIME-WAIT状态,收到服务器的FIN报文就直接关闭,由于网络传输的原因,可能客户端发送的ACK报文在服务器端没有被接收,这就导致服务器端无法确认客户端的连接关闭,重而再次发送FIN报文这时,客户端并不能接收到FIN报文,导致连接异常关闭,就只关闭了客户端,没有关闭服务端。
保证本次连接的重复数据段从网络中消失。
如果存在两个连接,第一个连接正常关闭,第二个相同的连接紧接着建立;如果第一个连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达,则会干扰第二连接,等待 2MSL 可以让上次连接的报文数据消逝在网络中。
TCP是全双工模式,并且支持半关闭状态特性,提供了连接的一端在结束发送后还能接收来自另一端数据的能力。在前面四次挥手图解中我们能看到:前面两次挥手是为了关闭客户端到服务端的连接,客户端处于半关闭状态,但是服务端还有发送数据的能力,后两次挥手是为了让服务端也关闭发送数据的能力,从而达到双方都全部释放连接的目的。
两次挥手只能释放一端到另一端的连接,要释放两端的连接就需要四次挥手。
流量控制的基本方法就是接受方根据自己的接收能力控制发送方的发送速率。因此可以说流量控制是一个速度匹配服务,即发送方的发送速率与接收方应用程序的读速率相匹配,利用滑动窗口机制可以很方便的控制发送方的平均发送速率,TCP采用接收方控制发送方发送窗口的大小的方法来实现在TCP连接上的流量控制。在TCP报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值上限。
流量控制实例
设A向B发送数据。在连接建立时,B告诉了A:“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此,发送方的发送窗口不能超过接收方给出的接收窗口的数值。假设每一个报文段为100字节长,而数据报文段序号的初始值设为1。
从图中可以看出,B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ,第二次又减到了 rwnd = 100 ,最后减到 rwnd = 0 ,即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ,只有在 ACK=1 时确认号字段才有意义。
当网络中出现太多分分组时,网络的性能开始下降,这种情况称为拥塞。
如果网络中的负载,即发送到网络中的数据量,超过了网络的容量,即网络中能处理的数据量,那么在网络中就可能发生拥塞。
拥塞控制的任务就是控制源点的发送速率,防止过多的数据注入到网络中,使网络中的路由器或链路不致过载。
发送方维持一个叫做**拥塞窗口 cwnd(congestion window)**的状态变量。发送窗口不能大于拥塞窗口
拥塞窗口的大小随网络拥塞情况而动态变化:
慢启动算法
刚建立连接准备发送数据时不知道网络可用宽带情况,先慢慢发送,再逐步提高发送速率,试探网络可用宽带。
一开始发送方先设置拥塞窗口 cwnd=1(一个最大报文段MSS数值)。然后每经过一个传输轮次RTT,拥塞窗口就加倍。
为了防止拥塞窗口cwnd增长过大引起网络拥塞,还需要设置一个 慢启动门限 ssthresh 状态变量 。
拥塞避免算法
由于慢启动窗口很快,为避免很快又导致网络拥塞,在cwnd>ssthresh时就进入拥塞避免阶段,让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1。这样拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多。
无论在慢开始阶段还是在拥塞避免阶段,只要网络出现拥塞(其根据就是没有收到确认),就要把慢开始门限ssthresh设置为出现拥塞时的拥塞窗口值的一半(但不能小于2)。然后把拥塞窗口cwnd 设置为1,执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的数据量,使得发生拥塞的路由器有足够时间把队列中积压的数据处理完毕。过程图如下:
快重传
快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(使发送方及早知道有报文段没有到达对方)而不必等到自己发送数据时捎带确认。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。
如上图:接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然,接收方不能确认M4,因为M4是收到的失序报文段。根据可靠传输原理,接收方可以什么都不做,也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定,接收方应及时发送对M2的重复确认,这样做可以让 发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后,也还要再次发出对M2的重复确认。这样,发送方共收到了 接收方的四个对M2的确认,其中后三个都是重复确认。
快速恢复
收到连续三个冗余ACK说明网络出现轻度拥塞,将拥塞窗口直接降低为1则反映过于激烈,这会导致发送方要经过很长时间才能恢复到正常的传输速率。因此TCP规定当发送方收到连续三个冗余ACK时,执行快速恢复算法,将拥塞窗口减半,直接进入拥塞避免。
相同点:拥塞控制和流量控制的相同点都是控制丢包现象,实现机制都是让发送方发得慢一点。
不同点:
域名系统(Domain Name System,DNS)并不是直接和用户打交道的网络应用,而是为其他网络应用提供一种核心服务,即名字服务,使各种网络应用能够在应用层使用计算机的名字来进行交互,而不需要直接使用IP地址。
域名服务器大致分为三种类型:根域名服务器、顶级域名服务器、权限域名服务器,其中顶级域名服务器主要负责诸如com、org、net、edu、gov等顶级域名。
根域名服务器存储了所有的顶级域名服务器的IP地址,可以通过根服务器找到顶级域名服务器(例如:www.baidu.com 根服务器会返回所有维护com这个顶级域服务器的IP地址)。
然后你任选其中一个顶级域服务器发送请求,该顶级域服务器拿到域名后能够给出负责当前域的权限服务器地址(以 baidu为例的话,顶级域名服务器将返回所有负责 baidu 这个域的权限域名服务器地址)。
接着任选其中一个权威服务器地址查询 「www.baidu.com」 的具体 IP 地址,最终权威服务器会返回给你具体的 IP 地址。此外,本地 DNS 服务器是具有缓存功能的,通常两天内的记录都会被缓存。
DNS域名系统:用于域名解析服务,将域名地址转换为IP地址,基于UDP服务,使用53端口。
DNS底层既使用TCP又使用UDP协议:
① 域名解析时使用UDP协议:客户端向DNS服务器查询域名,一般返回的内容都不超过512字节,用UDP传输即可,不用经过TCP三次握手,这样DNS服务器负载更低,响应更快。
② 区域传送时使用TCP,主要有一下两点考虑:
- 辅助域名服务器会定时(一般时3小时)向主域名服务器进行查询以便了解数据是否有变动。如有变动,则会执行一次区域传送,进行数据同步。区域传送将使用TCP而不是UDP,因为数据同步传送的数据量比一个请求和应答的数据量要多得多。
- TCP是一种可靠的连接,保证了数据的准确性。
http协议即超文本传输协议,基于TCP协议,用于从Web服务器传输超文本到本地浏览器的传送协议。
http协议是无状态协议,自身不对请求和响应直接的通信状态进行保存,但有些场景下我们需要保存用户的登录信息,因此引入了cookies和session来管理状态。
cookie和session的区别
保存位置与安全性:cookie保存在客户端,session保存在服务端,所以在安全性方面,cookie存在安全隐患,可以通过拦截本地文件找到cookie后进行攻击,而session相对更加安全。因此,可以将登陆信息等重要信息保存在session中;其他信息如果需要保留,可以存在cookie中。
存储容量:单个cookie最大只允许4KB,一个站点最多保存20个Cookie;session没有大小限制,个数只跟服务器的内存大小有关。
有效期于实现机制:cookie可以长期有效存在;session依赖于cookie,过期时间默认为-1,只需关闭窗口该session就会失效。每个客户端对应一个session,客户端之间的session相互独立;
cookie:cookie是一小段的文本信息,当客户端请求服务器时,如果服务器需要记录该用户状态,就在响应头中向客户端浏览器颁发一个Cookie,而客户端浏览器会把cookie保存起来。当再次请求该网站时,浏览器把请求的网站连同该cookie一起提交给服务器,服务器会检查该cookie,以此来辨认用户状态。
session:当客户端请求服务器时,都会带上cookie,cookie里面一般都会有一个JSESSIONID,服务器就按照 JSESSIONID 来找到对应的 session;如果客户端请求不包含 JSESSIONID,则为此客户端创建session并生成相关联的JSESSIONID,并将这个JSESSIONID在本次响应中返回给客户端保存。客户端保存这个 JSESSIONID 的方式可以使用cookie机制。若浏览器禁用Cookie的话,可以通过 URL重写机制 将JSESSIONID传回服务器。
用户在浏览器端输入某一URL点击回车,或者点击某一超链接整个http请求流程:
解析URL,获取URL中包含的域名;
通过DNS系统查询域名对应的IP;
浏览器得到域名对应的IP后,向服务器发起三次握手,建立TCP连接;
TCP连接建立起来后,浏览器向服务器发送http请求,如果HTML文件在缓存中,浏览器则直接返回,如果没有,则去服务器端拿;
① 浏览器首次加载资源成功时,服务器返回200,此时浏览器不仅将资源下载下来,而且把response的header(里面的date属性非常重要,用来计算第二次相同资源时当前时间和date的时间差)一并缓存;
② 下一次加载资源时,首先要经过强缓存的处理,cache-control的优先级最高,比如cache-control:no-cache,就直接进入到协商缓存的步骤了,如果cache-control:max-age=xxx,就会先比较当前时间和上一次返回200时的时间差,如果没有超过max-age,命中强缓存,不发请求直接从本地缓存读取该文件(这里需要注意,如果没有cache-control,会取expires的值,来对比是否过期),过期的话会进入下一个阶段,协商缓存
③ 协商缓存阶段,则向服务器发送header带有If-None-Match和If-Modified-Since的请求,服务器会比较Etag,如果相同,命中协商缓存,返回304;如果不一致则有改动,直接返回新的资源文件带上新的Etag值并返回200;
④ 协商缓存第二个重要的字段是,If-Modified-Since,如果客户端发送的If-Modified-Since的值跟服务器端获取的文件最近改动的时间,一致则命中协商缓存,返回304;不一致则返回新的last-modified和文件并返回200;
服务器接收到请求后,根据路径映射到特定的处理器进行处理,并将处理结果以及相应的视图返回给浏览器。
浏览器解析视图,并根据请求到的资源,数据进行渲染页面,最终向用户呈现一个完整的页面。
构建DOM树(DOM tree):从上到下解析HTML文档生成DOM节点树(DOM tree),也叫内容树(content tree);
构建CSSOM(CSS Object Model)树:加载解析样式生成CSSOM树;
执行JavaScript:加载并执行JavaScript代码(包括内联代码或外联JavaScript文件);
构建渲染树(render tree):根据DOM树和CSSOM树,生成渲染树(render tree);
渲染树:按顺序展示在屏幕上的一系列矩形,这些矩形带有字体,颜色和尺寸等视觉属性。
布局(layout):根据渲染树将节点树的每一个节点布局在屏幕上的正确位置;
绘制(painting):遍历渲染树绘制所有节点,为每一个节点适用对应的样式,这一过程是通过UI后端模块完成;
http的长连接和短连接其本质是TCP的长链接和短连接,从http1.1开始就默认使用长链接。
短连接:客户端向服务端每发送一次请求,就会去建立一次TCP连接,收到服务端响应,请求完毕后就断开TCP连接。
长连接:客户端和服务器端建立起TCP连接后,他们之间的连接会持续存在,不会应为一次HTTP请求后关闭,后续的请求也用这个连接进行通信,使用长连接的HTTP协议,会在响应头加入:Connection:keep-alive。长连接可以省去每次建立连接和断开的握手和挥手操作,节约时间提高效率。但在长连接下,客户端一般不会主动关闭连接,如果客户端和服务端之间的连接一直不关闭的话,随着连接数越来越多,会对服务端造成压力。
各自适用场景:长连接适合频繁请求资源并且连接数并不多的场景,例如数据库的连接使用长连接。而向Web网站这种并发量大,但是每个用户无需频繁操作的场景,一般都使用短连接,因为长连接对服务端来说会消耗一定的资源。
https 是基于tcp协议,在http的基础上加入了SSL/TLS,可看成是添加了加密和认证机制的http,使用对称加密、非对称加密、证书等技术进行进行客户端与服务端的数据加密传输,最终达到保证整个通信的安全性。
对称加密:对称加密指加密和解密都需要同一个密钥,这种方式存在如何安全的将密钥发送对方的问题。
非对称加密:非对称加密使用两个密钥,公钥加密则需要私钥解密,私钥加密则需要公钥解密,不能同一个秘钥既加密又解密。
非对称加密不需要发送用来解密的私钥,所以可以保证安全性,但是和对称加密相比,速度非常慢,所以我们还是用对称加密进行数据传输,但对对称加密的秘钥用非对称加密加密的方式发送出去。
整个过程中一共涉及到2对公私密钥对,一对由服务器产生,用于加密对称秘钥,一对由CA机构产生,用于生成证书验证服务器的公钥S.pub是否合法。
CA机构的作用就是保证服务器端的公钥是准确无误的,合法未修改的;虽然HTTPS是加密的,但是请求还是会被拦截,假设没有CA证书,如果服务器返回的包含公钥的数据包被攻击人截取,然后攻击人也生成一份自己的公私钥,他将自己的公钥发送给客户端,攻击者得到客户端的数据进行解密后,然后再通过服务器的公钥加密发送给服务器,这样数据就被攻击者获取到了。
所以当我们在使用HTTPS协议的时候都必须提前向CA机构申请一份自己的CA证书用来作为持有者的身份证唯一标识;然后浏览器内置的根证书能够验证服务器发来的证书是否合法有效,如果是攻击者的伪造证书很容易发现证书中的网站信息不合法。从而达到了服务器的公钥实现秘密传输给客户端的效果。
证书内容通常包括:
- 服务端的公钥
- 证书发行者(CA)对证书的数字签名
- 证书所用的签名算法
- 证书发布机构、有效期、所有者的信息等其他信息
HTTP报文是面向文本的,因此在报文中的每一个字段都是一些ASCII码串。
报文类型分两种:请求报文,响应报文
请求报文:
响应报文:
报文中各部分的简要描述:
通用头部:既可以出现在请求报文中,也可以出现在响应报文中,它提供了与报文相关的最基本的信息:
请求头部:请求头部是只在请求报文中有意义的头部。用于说明是谁或什么在发送请求、请求源自何处,或者客户端的喜好及能力
响应头部:响应头部为客户端提供了一些额外信息,比如谁在发送响应、响应者的功能,甚至与响应相关的一些特殊指令
实体首部:描述主体的长度和内容,或者资源自身
1xx:请求处理中,请求已被接受,正在处理。
2xx:请求成功,请求被成功处理。
3xx:重定向,要完成请求必须进一步处理。
4xx:客户端错误,请求不合法。
5xx:服务端错误,服务端不能处理合法请求。
参考书目:[1]谢钧 谢希仁.计算机网络教程.第五版|微课版
参考博客:计算机网络常见面试总结