计算机网络

一、三次握手和四次挥手

1.TCP报文格式简介

  • 序号: Seq序号,占32位,用来表示从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记
  • 确认号: Ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效 ,Ack=Seq+1
  • 标志位
    • URG:紧急指针
    • ACK:确认序号有效
    • PSH:接收方应该尽快将这个报文交给应用层
    • RST:重置连接
    • SYN:发起一个连接
    • FIN:释放一个连接

需要注意的是: 不要将确认序号Ack和标志位中的ACK搞混了,确认方Ack=发起方Seq+1,两端配对

2.三次握手

1.过程

  1. 首先客户端向服务端发送一段TCP报文
  • 标记为为SYN,表示请求简历连;
  • 序号为Seq=X;    
    
  • 客户端结束CLOSED状态,进入SYN-SENT阶段
    
  1. 服务端接收到来自客户端的TCP报文之后,结束LISTEN阶段,并返回一段TCP报文。
  • 标志位为SYN和ACK,表示客户端的报文Seq序号有效,服务端能正常接收客户端发送的数据,并同意创建新连接;
  • 序号为Seq=y;
  • 确认号为Ack=x+1,表示收到客户端的序号Seq并将其加1作为自己确认号Ack的值,随后服务器端进入SYN-RCVD阶段
  1. 客户端收到来自服务端的确认收到数据的TCP报文之后,明确了从客户端到服务端的数据传输是正常的,结束SYN-SENT状态,并返回最后一段TCP报文。
  • 其中标志位为ACK,表示收到服务端同意连接的信号了;
  • 序号为Seq=x+1,表示确认收到服务器端的确认号Ack,并将其作为自己的序号值
  • 确认号为Ack=y+1,表示收到服务器序号Seq,并将其加1作为自己的确认号Ack的值
  • 客户端进入ESTABLISHED阶段

2.为什么进行三次握手?两次不行吗?四次不行吗?

为了防止服务器开启一些无用的连接增加服务器的开销以及防止已失效的连接请求报文段突然有传送到了服务端,因而产生错误。

  • 由于网络传输是由延时的,在传输的过程中,客户端发起了创建连接的请求,然后服务端收到并创建了这个链接并返回包含SYN、ACK和Seq等内容返回给客户端,这个数据包因为网络传输的原因丢失了,丢失之后客户端一直没有接收到服务端返回的数据包,客户端可能设置了一个超时时间,时间到了就关闭连接创建的请求,而服务端是不知道的,这样就会造成服务端开销的严重浪费。
  • 还有一种情况是已经失效的客户端发出的请求信息,由于某种原因传输到了服务器端,服务器端以为是客户端发出的有效请求,接受后产生错误。
  • 若是四次就会造成浪费,因为经过三次,通信双方就已经确定了各自都可以发送消息,且能收到对方的消息。

3.四次挥手

1.过程

  1. 首先客户端想要释放连接,向服务端发送一段TCP报文
  • 序号为FIN,表示请求释放连接
  • 序号为Seq=U

随后客户端进入FIN-WAIT-1阶段,即半关闭阶段,并且停止在客户端到服务端方向上发送数据,但是客户端仍然能接受从服务端传输过来的数据

  1. 服务端接收到从he护短发出的TCP报文之后,确认了客户端想要释放连接,随后服务端进入CLOSE-WAIT(半关闭状态)并返回一段TCP报文
  • 标记为ACK,表示接收到客户端发送的释放连接的请求
  • 序号Seq=V
  • 确认号为Ack=U+1,表示是在收到客户端报文的基础上,将其序号Seq+1作为本段报文确认号Ack的值
  • 随后服务端开始开始准备释放服务器端到客户端方向上的连接
  1. 服务端自从发出ACK确认报文之后,经过半关闭状态阶段,做好了释放服务端到客户端方向上的连接准备,再次向客户端发出一段TCP报文
  • 标记位为FIN,ACK,表示已经准备好释放连接了
  • 序号为Seq=W
  • 确认号为Ack=U+1,表示是在收到客户端报文的基础上将其序号Seq+1作为本段报文确认号Ack的值

随后服务端结束CLOSE-WAIT阶段,进入LAST-ACK阶段,并且停止在服务端到客户端上发送数据,但是服务器端仍然能够接受从客户端传输过来的数据

  1. 客户端收到从服务端发出的TCP报文,确认了服务端已做好释放连接的准备,结束FIN-WAIT-2阶段,进入TIME-WAIT,并向服务端发送一段报文
  • 标记为ACK,表示接收到服务器准备好释放连接的信号
  • 序号为Seq=U+1,表示是在收到了服务端报文的基础上,将其确认号Ack作为本段报文序号的值
  • 确认号为Ack=W+1,表示是在收到了服务器端报文的基础上,将其序号Seq值作为本段报文确认号的值

随后客户端开始在TIME-WAIT阶段等待2MSL

MSL 是 Maximum Segment Lifetime,报文最大生存时间,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。网络中可能存在来自发送方的数据包,当这些发送方的数据包被接收方处理后又会向对方发送响应,所以一来一回需要等待 2 倍的时间。

3.为什么客户端要等待2MSL

  • 经过2MSL这个时间,足以让两个方向上的数据包都被丢弃,使得原来连接的数据包在网络中都自然消失,再出现的数据包一定都是新建立连接所产生的。
  • 等待足够的时间以确保最后的ACK能让被动关闭方接受,从而帮助其正常关闭。

4.为什么连接的时候是3次,关闭的时候是4次

因为当服务端收到客户端的SYN连接请求报文后,可以直接发送SYN+ACK连接报文。其中ACK报文是直接用来应答的,SYN报文是用来同步的。
但是当服务端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉客户端,“你发送的FIN报文我收到了”。只有等到我Server所有的报文都发送完了,我们才能发送FIN报文,因此不能一起发送。故需要四部握手。

二、TCP/IP四层模型和OSI七层模型

在这里插入图片描述

1.TCP/IP四层模型

应用层: 应用程序间沟通的层,如简单电子邮件(SMTP)文件传输协议(FTP)网络远程访问协议(Telnet)域名解析协议(DNS)等。

传输层: 负责节点之间的数据传输,如传输控制协议(TCP),用户数据报协议(UDP)等,将数据传送到网络互连层。

网络互联层(网络层): 实现数据包的选路和转发。通常使用众多分级的路由器来连接分散的主机,因此,通信的两台主机一般不是直接相连的,而是通过多个节点(路由器)连接的。网络层的任务就是选择这些中间节点,以确定两台主机之间的通信路径。

  • 网络层最核心的协议是IP协议其次是ICMP协议,IP协议根据数据包的目的IP地址来决定如何投递它。如果数据包不能直接发送给目标主机,那么IP协议就会为它寻找一个合适的下一跳路由器,并将数据包交付给该路由器来转发。

网络接口层: 实现了网卡接口的网络驱动程序,以处理数据在物理媒介(比如以太网、令牌环等)上的传输,主要有ARP(地址解析协议)和RARP(逆地址解析协议),它们实现了IP地址和机器物理地址(MAC)之间的相互转换。

2.OSI七层模型

物理层:实现了网卡接口的网络驱动程序,以处理数据在物理媒介(比如以太网、令牌环等)上的传输,主要有ARP(地址解析协议)和RARP(逆地址解析协议),它们实现了IP地址和机器物理地址(MAC)之间的相互转换。

数据链路层:接受来自物理层的位流形式的数据,并封装成帧,传送到上一层,同样,也将来自上层的数据帧,拆装为位流形式的数据转发到物理层。这一层在物理层提供的比特流的基础上,通过差错控制、流量控制方法,使有差错的物理线路变为无差错的数据链路,即提供可靠的通过物理介质传输数据的方法。传输单位为帧,主要包括的协议为MAC VLAN PPP。

网络层:将网络地址翻译成对应的物理地址,并通过路由选择算法为分组通过通信子网选择最适当的路径。传输单位为包,主要包括的协议为IP ARP ICMP。

传输层:在源端与目的端之间提供可靠的透明数据传输,使上层服务用户不必关系通信子网的实现细节。传输单位为报文,主要包括的协议为TCP UDP。

会话层:是用户应用程序和网络之间的接口,负责在网络中的两节点之间建立、维持和终止通信。传输单位为SPDU,主要包括的协议为RPC NFS。

表示层:它对来自应用层的命令和数据进行解释,以确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。主要包括的协议为JPEG ASII。

应用层:允许访问OSI环境的手段,传输单位为APDU,主要包括的协议为FTP HTTP DNS 。

三、从输入URL到页面展示的详细过程

1.过程

  • 输入网址
  • DNS解析
  • 简历TCP连接
  • 客户端发送HTPP请求
  • 服务器处理请求
  • 服务器响应请求
  • 浏览器展示HTML
  • 浏览器发送请求获取其他在HTML中的资源

1. 输入地址

当我们开始在浏览器中输入网址的时候,浏览器其实就已经在智能的匹配可能得 url 了,他会从历史记录,书签等地方,找到已经输入的字符串可能对应的 url,然后给出智能提示,让你可以补全url地址。对于 google的chrome 的浏览器,他甚至会直接从缓存中把网页展示出来,就是说,你还没有按下 enter,页面就出来了。

2.DNS解析IP地址

  • 请求一旦发起,浏览器首先要做的事情就是解析这个域名,一般来说,浏览器会首先查看本地硬盘的hosts文件,看看其中有没有和这个域名对应的规则,如果有的话就直接使用hosts文件里面的ip地址。
  • 如果在本地的hosts文件没有找到对应的ip地址,浏览器会发出一个DNS请求到本地的DNS服务器,主机向本地域名服务器的查询一般采用递归查询

递归查询:如果主机所访问的本地域名服务器不知道被查询的IP地址,那么本地域名服务器就以DNS客户的身份,向其他根域名服务器继续发出查询请求(即代替主机继续查询),而不是让主机自己进行下一步查询。

  • 本地域名服务器向根域名服务器的查询通常是迭代查询(也可以用递归查询,这取决于最初的查询请求报文的设置是要求使用哪一种查询方式)。

迭代查询:当根域名服务器收到本地本地域名服务器发出的迭代查询请求报文时,要么返回所要查询的IP地址,要么告诉本地域名服务器:下一步应当向哪一个域名服务器进行查询,然后让本地域名服务器进行后续的查询(而不是代替本地域名服务服务器进行查询)。根域名服务器通常把自己知道的顶级域名服务器的IP告诉本地域名服务器,让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后,要么直接查询出IP要么继续迭代。

1.什么是DNS

DNS(Domain Name System,域名系统),因特网上作为域名和IP地址相互映射的一个分布式数据库,能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。通过主机名,最终得到该主机名对应的IP地址的过程叫做域名解析(或主机名解析)。

2.DNS域名称空间的组织方式

在这里插入图片描述

3.DNS负载均衡

当一个网站有足够多的用户的时候,假如每次请求的资源都位于同一台机器上面,那么这台机器随时可能会蹦掉。处理办法就是用DNS负载均衡技术,它的原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去,使得不同的客户端访问不同的服务器,从而达到负载均衡的目的。例如可以根据每台机器的负载量,该机器离用户地理位置的距离等等。

3.浏览器向web服务器发送一个HTTP请求

拿到域名对应的IP地址之后,浏览器会以一个随机端口(1024<端口<65535)向服务器的WEB程序(常用的有httpd,nginx等)80端口发起TCP的连接请求。这个连接请求到达服务器端后(这中间通过各种路由设备,局域网内除外),进入到网卡,然后是进入到内核的TCP/IP协议栈(用于识别该连接请求,解封包,一层一层的剥开),还有可能要经过Netfilter防火墙(属于内核的模块)的过滤,最终到达WEB程序,最终建立了TCP/IP的连接。

4.服务器处理请求

后端从在固定的端口接收到TCP报文开始,它会对TCP连接进行处理,对HTTP协议进行解析,并按照报文格式进一步封装成HTTP Request对象,供上层使用。

一些大一点的网站会将你的请求到反向代理服务器中,因为当网站访问量非常大,网站越来越慢,一台服务器已经不够用了。于是将同一个应用部署在多台服务器上,将大量用户的请求分配给多台机器处理。此时,客户端不是直接通过HTTP协议访问某网站应用服务器,而是先请求到Nginx,Nginx再请求应用服务器,然后将结果返回给客户端,这里Nginx的作用是反向代理服务器。同时也带来了一个好处,其中一台服务器万一挂了,只要还有其他服务器正常运行,就不会影响用户使用。

5.服务器返回一个HTTP响应

响应体是由三部分组成:

  • 响应行:协议版本、状态码及其描述组成
  • 响应头:用于描述服务器的基本信息,以及数据的描述,服务器通过这些数据的描述信息,可以通知客户端如何处理等一会儿它回送的数据。
  • 响应体:响应体就是响应的消息体,如果是纯数据就是返回纯数据,如果请求的是HTML页面,那么返回的就是HTML代码,如果是JS就是JS代码,如此之类。

6.浏览器显示HTML

在浏览器没有完整接受全部HTML文档时,它就已经开始显示这个页面了,浏览器是如何把页面呈现在屏幕上的呢?不同浏览器可能解析的过程不太一样,这里我们只介绍webkit的渲染过程
下图对应的就是WebKit渲染的过程,这个过程包括:

解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树
在这里插入图片描述

  • 浏览器在解析html文件时,会”自上而下“加载,并在加载过程中进行解析渲染。在解析过程中,如果遇到请求外部资源时,如图片、外链的CSS、iconfont等,请求过程是异步的,并不会影响html文档进行加载。
  • 解析过程中,浏览器首先会解析HTML文件构建DOM树,然后解析CSS文件构建渲染树,等到渲染树构建完成后,浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂,涉及到两个概念:
    reflow(回流)和repain(重绘)。
  • DOM节点中的各个元素都是以盒模型的形式存在,这些都需要浏览器去计算其位置和大小等,这个过程称为relow;当盒模型的位置,大小以及其他属性,如颜色,字体,等确定下来之后,浏览器便开始绘制内容,这个过程称为repain。
  • 页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的,尤其是在移动设备上,它会破坏用户体验,有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

四、GET和POST的区别

  • GET参数通过URL传递,POST放在Request body中
  • GET请求在URL中传送的参数是有长度限制的,而POST没有
  • GET比POST更不安全,因为参数直接暴露在URL上,所以不能只用来传递敏感信息
  • GET请求只能进行URL编码,而POST支持多种编码方式
  • GET产生一个TCP数据包,POSET产生两个TCP数据包
  • GET方式的请求,浏览器会把http header和data一并发出去,服务端响应200,请求成功
  • POST方式的请求,浏览器会先发送http header给服务端,告诉服务端等一下会有数据过来,服务端响应100 continue,告诉浏览器我已经准备接收数据,浏览器再post发送一个data给服务端,服务端响应200,请求成功。

五、HTTP请求报文格式

一个HTTP请求报文有请求行,请求头部,空行和请求数据4部分组成

1.请求行

请求行有请求方法字段,URL字段和HTTP协议版字段3个字段组成,他们用空格分隔。例如GET/index.html HTTP/1.1。常见的请求方法有GET,POST等

2.请求头部

请求头部有关键字/值对组成,每行一对,关键字和值用英文冒号分隔,请求头部通知服务器有关于客户端请求的信息,典型的请求头有:

  • User-Ageht:产生请求的浏览器类型
  • Accept:客户端可识别的内容类型列表
  • Host:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机

3.空行

最后一个请求头之后是一个空行,发送回车符合换行符,通知服务器一下不在有请求头

4.请求数据

请求数据不再GET方法中使用,而是在POST方法中使用,POST方法适用于需要客户填写表单的场合,与请求数据相关的最常使用的请求头是Content-Type和Content-Length。

HTTP响应也由三个部分组成,分别是:状态行,消息报头,响应正文

5.HTTP中常见的状态码

1xx:信息性状态码,表示服务器已接收了客户端请求,客户端可继续发送请求。

2xx:成功状态码,表示服务器已成功接收到请求并进行处理。

3xx:重定向状态码,表示服务器要求客户端重定向。

4xx:客户端错误状态码,表示客户端的请求有非法内容。

5xx:服务器错误状态码,表示服务器未能正常处理客户端的请求而出现意外错误。

六、TCP保证可靠性传输

1.校验和

发送数据时,为了计算数据包的校验和应按如下步骤:

  1. 把检验和字段置为0
  2. 把需要校验的数据看成以16位为单位的数字组成,以此进行二进制反码求和
  3. 把得到的结果存入校验和字段中。

接受数据时,计算数据报的校验和相对简单,依次进行二进制反码求和包括校验和字段:

  1. 把首部看成以16位为单位的数字组成,依次进行二进制反码求和,包括检验和字段。
  2. 检查计算出的校验和的结果是否等于零(反码应为16个1)。
  3. 如果等于0,说明被整除,检验和正确,否则就是错误的,协议栈就要抛弃这个数据包。

2.序列号

TCP将每个字节的数据都进行了编号,这就是序列号。序列号作用:

  • 保证可靠性(当接收到的数据总少了某个序号的数据时,能马上知道);
  • 保证数据的按序到达;
  • 取出重复数据;
    数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现。

3.确认应答机制(ACK)

TCP通过确认应答机制实现可靠的数据传输,在TCP的首部中有一个标志位——ACK,此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认,当标志位ACK=1时确定首部的确认字段是否有效。

4.超时传输机制

第一种情况:数据包丢失,当数据发出后在一定的时间内未收到接受方的确认,发送方就会进行重传(特定时间间隔内)。

第二种情况:确认包丢失,当接收方收到重复数据(通过序列号进行识别)的时候将其丢弃,重新发送ACK。

5.连接管理机制

三次握手和四次挥手

6.流量控制

1.概念

接收端处理数据的速度是有限的,如果双方发送数据的速度过快,导致接收端的缓冲区满,而发送方继续发送,就会导致丢包,继而引起丢包重传等一系列连锁反应。因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这个机制就叫流量控制。

2.控制方法

在TCP报文段首部中有一个16位窗口长度,当接收端接收到发送方的数据后,在应答报文ACK中就将自身缓冲区的剩余大小,放入16位窗口长度。这个大小随数据传输情况而变,窗口越大,网络吞吐量越高,而一旦接受方发现自身的缓冲区快满了,就将窗口设置为更小的值通知发送方。如果缓冲区满,就将窗口设置为0,发送方收到后将不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。

7.拥塞控制

如果出现拥塞,分组将会出现丢失,此时发送方会继续重传,从而导致网络堵塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同,流量控制是为了让接受方能来得及接受,而拥塞控制是为了降低整个网络的拥塞程度。

1.拥塞控制方法

拥塞控制方法分为:慢开始,拥塞避免,快传输,快恢复

  1. 慢开始:从1开始指数增长到限定大小的过程
  2. 拥塞避免超过:超过限定大小之后线性增长的过程,以及发现丢包(发生了拥塞)后将拥塞窗口改为1,并把限定大小减半的过程。
  3. 快传输:发送方只要一连接收到三个重复确认就应该立即重传对方尚未的接受的报文段,而不必等重传计时器超时后发送。由3个重复应答判断有包丢失,重新发送丢包的信息。
  4. 快恢复:发送方一旦受到3个重复确认,就知道现在只是丢失了个别的报文段,于是不启动慢开始算法,而执行快恢复算法:

七、对称加密和非对称加密以及CA

1.对称加密(概念+优缺点)

对称加密(也叫私钥加密)指加密和解密使用相同秘钥的加密算法

优点:算法公开,计算量小,加密速度快,加密效率高。

缺点:交易双方都使用同样钥匙,安全性得不到保证。

1.常见对称加密算法

DES、3DES、IDEA、RC4、RC5、RC6、和AES

2.非对称加密

与对称加密算法不同,非对称加密算法需要2个密钥:公开密钥和私有密钥

公开密钥和私有密钥是一对,如果公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。

常见的非对称加密算法有:RSA、ECC、Diffie-Hellman、El Gamal、DSA(数字签名用)

3.CA证书

1.概念

如果你自己通过RSA算法生成了一个私钥和公钥,在公钥发送给客户端的过程中有可能被篡改其他的公钥,而客户在没有其他措施的保护下是不知道该公钥是否就是服务器那边的私钥对应的公钥的。公钥有可能才分发的过程中被篡改。因此就需要一个第三方机构来证明客户端收到的公钥是没有被篡改的。这个中间认证机构,就是数字证书认证机构,其颁发的证书也就是我们常说的CA证书。

2. 证书签名、证书分发以及证书验证的过程

  1. 服务端在分发公钥之前需要向CA机构申请将给要分发的公钥进行数字签名。
  2. 对于CA机构来说,其也有两个密钥,我们暂且称之为CA私钥和CA公钥,CA机构先将服务端的公钥用数字摘要算法生成摘要。然后使用CA私钥将这个摘要进行加密处理,生成数字签名。服务端将数字签名和公钥绑定在一起形成数字证书,发送给客户端。
  3. 当客户端收到数字证书之后,会验证其有效性,大部分客户端都会预装CA机构的公钥,也就是CA公钥。客户端使用CA公钥对数字证书上的签名 进行验证,就是使用CA公钥对CA私钥加密的内容进行解密,将解密后的内容与服务端的公钥经过数字摘要算法生成的摘要进行匹配,如果匹配成功,则说明该证书合法,就是相应的服务端发过来的,否则就是非法证书。
  4. 验证完服务端公钥的合法性后,就可以使用该公钥进行加密通信了。

3.CA作用

HTTPS通信的核心就是浏览器用非对称加密算法对密钥进行加密,服务端解密获得密钥后用该密钥进行传输。就是非对称加密算法+对称加密算法。而CA证书只有一个作用,因为非对称加密需要传送公钥,CA就是确保这个公钥中途没有被修改,是相应的服务端发过来的。

八、HTTP和HTTPS的不同

1.概念

HTTP协议传输的数据都是未加密的,也就是明文的,因此使用HTTP协议传输隐私信息非常不安全,为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密,从而诞生了HTTPS。

2.区别

  1. HTTPS协议需要到CA (Certificate Authority,证书颁发机构)申请证书,一般免费证书较少,因而需要一定费用。
  2. HTTP是超文本传输协议,信息是明文传输,HTTPS则是具有安全性的SSL加密传输协议。
  3. HTTP和HTTPS使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
  4. HTTP的连接很简单,是无状态的,HTTPS协议是由SSL+HTTP协议构建的可进行假面传输、身份认证的网络协议,比HTTP协议安全。(无状态的意思是其数据包的发送、传输和接受都是独立的,无连接的意思是指通信双方都不长久的维持对方的任何信息)。

3.HTTPS的工作原理

(1)cilent_hello
客户端发起请求,以明文传输请求信息,包含版本信息、加密套件候选列表、压缩算法候选列表、随机数、扩展字段等信息。

  • 支持的最高TSL协议版本verision。
  • 客户端支持的加密套件列表,每个加密套件对应TLS原理中的四个功能的组合:认证算法、密钥交换算法(密钥协商)、对称加密算法(信息加密)、信息摘要(完成行校验)。
  • 支持的压缩算法列表,用户后续的信息压缩传输。
  • 随机数random_C,用于后续的密钥的生成。
  • 扩展字段,支持协议与算法的相关参数以及其他辅助信息。

(2)server_hello+server_certificate+sever_hello_done

  • server_hello:服务端返回协商的信息结果,包括选择使用的协议版本version、选择的加密套件、选择的压缩算法、随机数random_S等,其中随机数用于后续的密钥协商;
  • server_certificates:服务端配置对应的证书链,用于身份验证与密钥交换;
  • server_hello_done:通知客户端server_hello信息发送结束;

(3)服务端进行数字证书制作

对于CA机构来说,其也有两个密钥,我们暂且称之为CA私钥和CA公钥,CA机构先将服务端的公钥用数字摘要算法生成摘要。然后使用CA私钥将这个摘要进行加密处理,生成数字签名。服务端将数字签名和公钥绑定在一起形成数字证书,发送给客户端。

(4)客户端验证数字证书的合法性

浏览器用内置的CA公钥对数字证书的数字签名进行解密,并用数字摘要算法对数字证书中的公钥进行处理生成本地的数字签名,然后与CA解密后的数字签名进行匹配,确认数字证书的有效性。如有问题,则提示风险。

(5)客户端生成随机数Pre-master,并用公钥加密发送给服务端。

此时客户端已经获取全部的计算协商密钥需要的信息:random_C和random_S与计算产生的Pre_mastrer,计算得到协商密钥。

(6)服务端用自己的私钥进行解密得到随机数,生成通信密钥。

服务器用私钥解密后得到Pre-master 数据,基于之前交换的两个明文随机数random_C和random_S,计算得到通信密钥
change_cipher_spec, 验证通过之后,服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;

(7)双方enc_key密钥进行通信。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值