其他专题也也还在整理中,包括Redis,数据库,操作系统,Spring等
物理层
首先解决两台物理机之间的通信需求,具体就是机器A往机器B发送比特流,机器B能收到比特流。
物理层主要定义了物理设备的标准,如网线的类型,光纤的接口类型,各种传输介质的传输速率。主要作用是传输比特流(0101二进制数据),将比特流转化为电流强弱传输,到达目的后再转化为比特流,即常说的数模转化和模数转换。这层数据叫做比特。网卡工作在这层。
物理层是OSI七层模型的物理基础,没有它就谈不上数据传输了
物理层就是由实物所承载的,所以作比喻的话,公路、汽车和飞机等承载货物(数据)的交通工具,就是物理层的象征
数据链路层
在传输比特流的过程中,会产生错传、数据传输不完整的可能。
数据链路层定义了如何格式化数据进行传输,以及如何控制对物理介质的访问。通常提供错误检测和纠正,以确保数据传输的准确性。本层将比特数据组成帧,交换机工作在这层,对帧解码,并根据帧中包含的信息把数据发送到正确的接收方。
该层负责物理层面上互连的节点之间的通信传输。例如与1个以太网相连的两个节点间的通讯。常见的协议有 HDLC、PPP、SLIP 等
数据链路层会将0、1序列划分为具有意义的数据帧传送给对端(数据帧的生成与接收)
举个例子:暂且把需要传输的数据看作为不同来源的水,如果直接倒入池子中时,是无法重新分辨出不同来源的水的。但如果将不同来源的灌入瓶子中并打上记号,那就能区分出不同来源的水。这也就是为什么要划分为具有意义的数据帧传送给对端。同时要注意的是,数据链路层只负责将数据运送给物理相连的两端,并不负责直接发送到最终地址
网络层
随着网络节点的不断增加,点对点通讯需要通过多个节点,如何找到目标节点,如何选择最佳路径成为首要需求。
网络层主要功能是将网络地址转化为对应的物理地址,并决定如何将数据从发送方路由到接收方。网络层通过综合考虑发送优先权、网络拥塞程度、服务质量以及可选路由的花费来决定从一个网络中节点A到另一个网络中节点B的最佳路径。由于网络层处理并智能指导数据传送,路由器连接网络隔断,所以路由器属于网络层。此层的数据称之为数据包。本层需要关注的协议TCP/IP协议中的IP协议。
网络层负责将数据传输到目标地址。目标地址可以使多个网络通过路由器连接而成的某一个地址。因此这一层主要负责寻址和路由选择。主要由 IP、ICMP 两个协议组成
网络层将数据从发送端的主机发送到接收端的主机,两台主机间可能会存在很多数据链路,但网络层就是负责找出一条相对顺畅的通路将数据传递过去。传输的地址使用的是IP地址。IP地址通过不断转发到更近的IP地址,最终可以到达目标地址
传输层
随着网络通信需求的进一步扩大,通信过程中需要发送大量的数据,如海量文件传输,可能需要很长时间,网络在通信的过程中会中断很多次,此时为了保证传输大量文件时的准确性,需要对发送出去的数据进行切分,切割为一个一个的段落(Segement)发送,其中一个段落丢失是否重传,段落是否按顺序到达,是传输层需要考虑的问题。
传输层解决了主机间的数据传输,数据间的传输可以是不同网络,并且传输层解决了传输质量的问题。
传输层需要关注的协议有TCP/IP协议中的TCP协议和UDP协议。
会话层
自动收发包,自动寻址。
会话层作用是负责建立和断开通信连接,何时建立,断开连接以及保持多久的连接。常见的协议有 ADSP、RPC 等
表示层
Linux给WIndows发包,不同系统语法不一致,如exe不能在Linux下执行,shell不能在Windows不能直接运行。于是需要表示层。
解决不同系统之间通信语法问题,在表示层数据将按照网络能理解的方案进行格式化,格式化因所使用网络的不同而不同。
它主要负责数据格式的转换。具体来说,就是讲设备固有的数据格式转换为网络标准格式。常见的协议有 ASCII、SSL/TLS 等
应用层
规定发送方和接收方必须使用一个固定长度的消息头,消息头必须使用某种固定的组成,消息头中必须记录消息体的长度等信息,方便接收方正确解析发送方发送的数据。
应用层旨在更方便应用从网络中接收的数据,重点关注TCP/IP协议中的HTTP协议
OSI七层网络模型 |
TCP/IP四层概念模型 |
对应网络协议 |
应用层(Application) |
应用层 |
HTTP、TFTP, FTP, NFS, WAIS、SMTP |
表示层(Presentation) |
Telnet, Rlogin, SNMP, Gopher |
|
会话层(Session) |
SMTP, DNS |
|
传输层(Transport) |
传输层 |
TCP, UDP |
网络层(Network) |
网络层 |
IP, ICMP, ARP, RARP, AKP, UUCP |
数据链路层(Data Link) |
数据链路层 |
FDDI, Ethernet, Arpanet, PDN, SLIP, PPP |
物理层(Physical) |
IEEE 802.1A, IEEE 802.2到IEEE 802.11 |
IP、TCP、UDP、HTTP等都属于TCP/IP协议,TCP/IP泛指这些协议。
OSI模型注重通信协议必要的功能;TCP/IP更强调在计算机上实现协议应该开发哪种程序
TCP与UDP区别总结:
1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付
3、TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)
4、每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小,只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道
端口:两个进程在计算机内部进行通信,其中两个进程通信最基本的前提是唯一标识一个进程,通过唯一标识找到对应的进程。在本地进程通信中可以通过pid,但pid只在本地唯一。
如果把两个进程放到两台计算机通信,pid实现不了。解决这个问题的方法就是在传输层使用协议端口号,简称端口。IP地址可以唯一标识主机,TCP协议和端口号可以唯一标识主机中的一个进程,利用IP地址+协议+端口号唯一标识去标识网络中的一个进程,这种唯一标识的模式称为Socket。
源端口号和目地端口各占16位两个字节,也就是端口的范围是2^16=65535
另外1024以下是系统保留的,从1024-65535是用户使用的端口范围
seq序号:占4字节,TCP连接中传送的字节流中的每个字节都按顺序编号。例如:一段报文的序号字段值是107,携带的数据是100个字段,下一个报文段序号从107+100=207开始。
ack确认号:4个字节,是期望收到对方下一个报文段的第一个数据字节的序号。例如:B收到A发送的报文,其序号字段是301,数据长度是200字节,表明B正确收到A发送的到序号500为止的数据(301+200-1=500),B期望收到A下一个数据序号是501。B发送给A的确认报文段中把ack确认号置为501。
数据偏移:头部有可选字段,长度不固定,指出TCP报文段的数据起始处距离报文段的起始处有多远。
保留:保留今后使用的,被标为1。
控制位:由8个标志位组成。每个标志位表示一个控制功能。
其中主要的6个:
URG紧急指针标志,为1表示紧急指针有效,为0忽略紧急指针。
ACK确认序号标志,为1表示确认号有效,为0表示报文不含确认信息,忽略确认号字段。上面的确认号是否有效就是通过该标识控制的。
PSH标志,为1表示带有push标志的数据,指示接收方在接收到该报文段以后,应尽快将该报文段交给应用程序,而不是在缓冲区排队。
RST重置连接标志,重置因为主机崩溃或其他原因而出现错误的连接,或用于拒绝非法的报文段或非法的连接。
SYN同步序号,用于建立连接过程,在连接请求中SYN=1和ACK=0表示该数据段没有使用捎带的确认域,连接应答捎带一个确认即SYN=1和ACK=1。
FIN终止标志,用于释放连接,为1时表示发送方没有发送了。
窗口:滑动窗口大小,用来告知发送端接收端缓存大小,以此控制发送端发送数据的速率,从而达到流量控制。
校验和:奇偶校验,此校验和是对整个的TCP报文段(包括TCP头部和TCP数据),以16位进行计算所得,由发送端计算和存储,接收端进行验证。
紧急指针:只有控制位中的URG为1时才有效。指出本报文段中的紧急数据的字节数。
选项:其长度可变,定义其他的可选参数。
UDP报文中每个字段的含义如下:
三次握手是指建立TCP连接协议时,需要在客户端和服务器之间发送三个包,握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据
第一次握手:
客户端将TCP报文标志位SYN置为1,随机产生一个序号值seq=J,保存在TCP首部的***(Sequence Number)字段里,指明客户端打算连接的服务器的端口,并将该数据包发送给服务器端,发送完毕后,客户端进入SYN_SENT状态,等待服务器端确认。
第二次握手:
服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接,服务器端将TCP报文标志位SYN和ACK都置为1,ack=J+1,随机产生一个序号值seq=K,并将该数据包发送给客户端以确认连接请求,服务器端进入SYN_RCVD状态。
第三次握手:
客户端收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给服务器端,服务器端检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,客户端和服务器端进入ESTABLISHED状态,完成三次握手,随后客户端与服务器端之间可以开始传输数据了。
我们上面写的ack和ACK,不是同一个概念:
TCP为什么三次握手而不是两次握手?
《计算机网络》中是这样说的:
为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。
在书中同时举了一个例子,如下:
假如client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。
于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。
采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。
挥手请求可以是Client端,也可以是Server端发起的,我们假设是Client端发起:
为什么连接的时候是三次握手,关闭的时候却是四次握手?
建立连接时因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。所以建立连接只需要三次握手。
由于TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议,TCP是全双工模式。
这就意味着,关闭连接时,当Client端发出FIN报文段时,只是表示Client端告诉Server端数据已经发送完毕了。当Server端收到FIN报文并返回ACK报文段,表示它已经知道Client端没有数据发送了,但是Server端还是可以发送数据到Client端的,所以Server很可能并不会立即关闭SOCKET,直到Server端把数据也发送完毕。
当Server端也发送了FIN报文段时,这个时候就表示Server端也没有数据要发送了,就会告诉Client端,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。
为什么要等待2MSL?
MSL:报文段最大生存时间,它是任何报文段被丢弃前在网络内的最长时间。
有以下两个原因:
RTT和RTO
RTT:发送一个数据包到收到对应的ACK,所花费的时间
RTO:重传时间间隔(TCP在发送一个数据包后会启动一个重传定时器。RTO即定时器的重传时间)
开始预先算一个定时器时间,如果回复ACK,重传定时器就自动失效,即不需要重传;如果没有回复ACK,RTO定时器时间就到了,重传。RTO是本次发送当前数据包所预估的超时时间,RTO不是固定写死的配置,是经过RTT计算出来的。基于RTO便有了重传机制。
滑动窗口
TCP使用滑动窗口做流量控制与乱序重排。
TCP的滑动窗口主要有两个作用:
1.保证TCP的可靠性
2.保证TCP的流控特性
TCP报文头有个字段叫Window,用于接收方通知发送方自己还有多少缓存区可以接收数据,发送方根据接收方的处理能力来发送数据,不会导致接收方处理不过来,这便是流量控制。
发送方都维持了一个连续的允许发送的帧的序号,称为发送窗口;同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样,甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的***代表了那些已经被发送,但是还没有被确认的帧,或者是那些可以被发送的帧
滑动窗口由四部分组成每个字节的数据都有唯一顺序的编码,随着时间发展,未确认部分与可以发送数据包编码部分向右移动,形式滑动窗口
接收窗口的大小就是滑动窗口的最大值,数据传输过程中滑动窗口的可用大小是动态变化的。
但是还有这么一点,滑动窗口的设计仅仅是考虑到了处理方的处理能力,但是没有考虑到道路的通畅问题
就好像服务端可以处理100M数据,但是传输的数据99M都堵在路上了,这不就是导致道路阻塞了么?这就需要另外一个设计拥塞避免
流量控制的目的
如果发送者发送数据过快,接收者来不及接收,那么就会有分组丢失。
为了避免分组丢失,控制发送者的发送速度,使得接收者来得及接收,这就是流量控制。
流量控制根本目的是防止分组丢失,它是构成TCP可靠性的一方面。
如何实现流量控制
由滑动窗口协议(连续ARQ协议)实现。滑动窗口协议既保证了分组无差错、有序接收,也实现了流量控制。
主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小,并且利用大小来控制发送方的数据发送。
流量控制引发的死锁
当发送者收到了一个窗口为0的应答,发送者便停止发送,等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失,发送者一直等待下去,而接收者以为发送者已经收到该应答,等待接收新数据,这样双方就相互等待,从而产生死锁。
为了避免流量控制引发的死锁,TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口,则重置该计时器继续等待;若窗口不为0,则表示应答报文丢失了,此时重置发送窗口后开始发送,这样就避免了死锁的产生。
为什么要进行拥塞控制
假设网络已经出现拥塞,如果不处理拥塞,那么延时增加,出现更多丢包,触发发送方重传数据,加剧拥塞情况,继续恶性循环直至网络瘫痪。可知,拥塞控制与流量控制的适应场景和目的均不同。
拥塞发生前,可避免流量过快增长拖垮网络;拥塞发生时,唯一的选择就是降低流量。
主要使用4种算法完成拥塞控制:
算法1、2适用于拥塞发生前,算法3适用于拥塞发生时,算法4适用于拥塞解决后(相当于拥塞发生前)。
rwnd与cwnd
rwnd(Receiver Window,接收者窗口)与cwnd(Congestion Window,拥塞窗口):
同时考虑流量控制与拥塞处理,则发送方窗口的大小不超过min{rwnd, cwnd}。
慢开始算法的思路就是,不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加拥塞窗口的大小。
这里用报文段的个数作为拥塞窗口的大小举例说明慢开始算法,实际的拥塞窗口大小是以字节为单位的。
一个传输轮次所经历的时间其实就是往返时间RTT,而且每经过一个传输轮次,拥塞窗口cwnd就加倍。
为了防止cwnd增长过大引起网络拥塞,还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下:
注意,这里的“慢”并不是指cwnd的增长速率慢,而是指在TCP开始发送报文段时先设置cwnd=1,然后逐渐增大,这当然比按照大的cwnd一下子把许多报文段突然注入到网络中要“慢得多”。
让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多
无论是在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有按时收到确认,虽然没有收到确认可能是其他原因的分组丢失,但是因为无法判定,所以都当做拥塞来处理),就把慢开始门限ssthresh设置为出现拥塞时的发送窗口大小的一半(但不能小于2)。然后把拥塞窗口cwnd重新设置为1,执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
整个拥塞控制的流程如下图:
1.拥塞窗口cwnd初始化为1个报文段,慢开始门限初始值为16
2.执行慢开始算法,指数规律增长到第4轮,即cwnd=16=ssthresh,改为执行拥塞避免算法,拥塞窗口按线性规律增长
3.假定cwnd=24时,网络出现超时(拥塞),则更新后的ssthresh=12,cwnd重新设置为1,并执行慢开始算法。当cwnd=12=ssthresh时,改为执行拥塞避免算法
注意:“拥塞避免”并非完全能够避免了阻塞,而是使网络比较不容易出现拥塞。
快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方,可提高网络吞吐量约20%)而不要等到自己发送数据时捎带确认。
快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期
快重传配合使用的还有快恢复算法,有以下两个要点:
当发送方连续收到三个重复确认时,就把ssthresh门限减半(为了预防网络发生拥塞)。
但是接下去并不执行慢开始算法
考虑到如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法,而是将cwnd设置为ssthresh减半后的值,然后执行拥塞避免算法,使cwnd缓慢增大。
如下图:是目前使用最广泛的版本。
注意:在采用快恢复算法时,慢开始算法只是在TCP连接建立时和网络出现超时时才使用
在浏览器地址栏键入URL,按下回车之后经历的流程
1.DNS解析:浏览器会依据URL逐层查询DNS服务器缓存,解析URL中的域名对应的IP地址,DNS缓存从近到远依次是浏览器缓存、系统缓存、路由器缓存、IPS服务器缓存、域名服务器缓存、顶级域名服务器缓存。
从哪个缓存找到对应的IP直接返回,不再查询后面的缓存。
2.TCP连接:结合三次握手
3.发送HTTP请求:浏览器发出读取文件的HTTP请求,该请求发送给服务器
4.服务器处理请求并返回HTTP报文:服务器对浏览器请求做出响应,把对应的带有HTML文本的HTTP响应报文发送给浏览器
5.浏览器解析渲染页面
6.连接结束:浏览器释放TCP连接,该步骤即四次挥手。
第5步和第6步可以认为是同时发生的,哪一步在前没有特别的要求
状态码由3位数字组成,第一位定义响应的类别
1XX:指示信息,表示请求以接收,继续处理
2XX:成功,表示请求已经被成功接收、理解、接受
3XX:重定向,要完成请求必须进行进一步操作
4XX:客户端错误,请求由语法错误或请求无法实现
5XX:服务器错误,服务器未能实现合法的请求
GET请求和POST请求的区别
长连接(PersistentConnection)
HTTP 1.1支持长连接(PersistentConnection)
HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。
HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用,在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠,多个请求和响应可以同时进行. 更加多的请求头和响应头
HTTP 1.1的持续连接,也需要增加新的请求头来帮助实现,例如,Connection请求头的值为Keep-Alive时,客户端通知服务器返回本次请求结果后保持连接;Connection请求头的值为close时,客户端通知服务器返回本次请求结果后关闭连接。
流水线(Pipelining)
请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。
例如:一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输,但每个单独的网页文件的请求和应答仍然需要使用各自的连接。 HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容。
host字段
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机,并且它们共享一个IP地址。
HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。此外,服务器应该接受以绝对路径标记的资源请求。
100(Continue) Status
HTTP/1.1加入了一个新的状态码100(Continue)。客户端事先发送一个只带头域的请求,如果服务器因为权限拒绝了请求,就回送响应码401(Unauthorized);如果服务器接收此请求就回送响应码100,客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用,允许客户端在发request消息body之前先用request header试探一下server,看server要不要接收request body,再决定要不要发request body。
Chunked transfer-coding
HTTP/1.1将发送方将消息分割成若干个任意大小的数据块,每个数据块在发送时都会附上块的长度,最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段,避免缓冲整个消息带来的过载。
cache
HTTP/1.1在1.0的基础上加入了一些cache的新特性,当缓存对象的Age超过Expire时变为stale对象,cache不需要直接抛弃stale对象,而是与源服务器进行重新**(revalidation)。
Session的实现方式:
1.使用Cookie来实现。服务器给每个Session分配一个唯一的JSession id,并通过Cookie发送给客户端。客户端发起新的请求的时候,将在Cookie头中携带的JSession id,服务器找到客户端对应的Session。
2.使用URL回写来实现。URL回写是指服务器在发送给浏览器页面的所有链接都携带JSession id的参数,客户端点击任何一个链接,都会把JSession id带回服务器,如果直接在浏览器输入服务端资源的URL来请求该资源,Session是匹配不到的。
Tomcat对Session的实现是一开始同时使用Cookie和URL回写机制,如果发现客户端支持Cookie,就继续使用Cookie,停止使用URL回写;如果发现Cookie被禁用,就一直使用URL回写。
Cookie与Session的区别
HTTP与HTTPS的区别
HTTP 是明文传输协议,HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 HTTP 协议安全
工作原理
HTTPS 协议会对传输的数据进行加密,而加密过程是使用了非对称加密实现。但其实,HTTPS 在内容传输的加密上使用的是对称加密,非对称加密只作用在证书验证阶段
HTTPS的整体过程分为证书验证和数据传输阶段,具体的交互过程如下:
1.Client发起一个HTTPS(比如
https://juejin.im/user/4283353031252967)的请求
2.Server把事先配置好的公钥证书返回给客户端。
3.Client验证公钥证书:比如是否在有效期内,证书的用途是不是匹配Client请求的站点,是不是在CRL吊销列表里面,它的上一级证书是否有效,这是一个递归的过程,直到验证到根证书(操作系统内置的Root证书或者Client内置的Root证书)。如果验证通过则继续,不通过则显示警告信息。
4.Client使用伪随机数生成器生成加密所使用的对称**,然后用证书的公钥加密这个对称**,发给Server。
5.Server使用自己的私钥解密这个消息,得到对称**。至此,Client和Server双方都持有了相同的对称**。
6.Server使用对称**加密“明文内容A”,发送给Client。
7.Client使用对称**解密响应的密文,得到“明文内容A”。
8.Client再次发起HTTPS的请求,使用对称**加密请求的“明文内容B”,然后Server使用对称**解密密文,得到“明文内容B”。