英文网站建设费用,微信小程序怎么关闭防沉迷,软件开发需要的软件,个人网站源代码下载2.5 HTTPS 数字签名#xff1a;发送端将消息使⽤ hash 函数⽣成摘要#xff0c;并使⽤私钥加密后得到“数字签名”#xff0c;并将其附在消息之后。接收端使⽤公钥对“数字签名”解密#xff0c;确认发送端身份#xff0c;之后对消息使⽤ hash 函数处理并与接收到的摘要对…2.5 HTTPS 数字签名发送端将消息使⽤ hash 函数⽣成摘要并使⽤私钥加密后得到“数字签名”并将其附在消息之后。接收端使⽤公钥对“数字签名”解密确认发送端身份之后对消息使⽤ hash 函数处理并与接收到的摘要对⽐确认消息是否被修改。 数字证书 数字中⼼ CA 使⽤私钥对⽤户的公钥和相关信息⼀起加密⽣成“数字证书”。发送端在发送时除了需要数字签名还需要附上数字证书。接收端使⽤ CA 公钥解开数字证书拿到⽤户的公钥则可证明该数字签名是真实发送端发送的。 证书吊销列表 (CRL) ⼀个结构化数据⽂件该⽂件包含证书颁发机构 (CA) 已经吊销的证书的序列号及其吊销⽇期等。 证书吊销列表分发点 (CDP) 是含在数字证书中的⼀个可以供各种应⽤软件⾃动下载的最新的 CRL 的位置信息。CDP ⼀般是⼀个可以访问 http ⽹址。 证书状态在线查询协议OCSP是⽤于实时查询数字证书在某⼀时间是否有效的标准。 HTTP 与 HTTPS 有哪些区别 ● 安全性HTTP 是超⽂本传输协议信息是明⽂传输存在安全⻛险的问题。HTTPS 在 TCP 和 HTTP 之间加⼊了 SSL/TLS 安全协议使得报⽂能够加密传输。 ● 连接步骤TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。⽽ HTTPS 在 TCP 三次握⼿之后还需进⾏ SSL/TLS 的握⼿过程才可进⼊加密报⽂传输。 ● 速度、资源根据上述分析HTTP速度快使⽤资源少HTTPS速度慢使⽤资源多。 ● 端⼝号HTTP 的端⼝号是 80HTTPS 的端⼝号是 443。 ● HTTPS 协议需要向 CA证书权威机构申请数字证书来保证服务器的身份是可信的。 SSL/TLS SSL/TLS协议的基本思路是采⽤公钥加密法也就是说客户端先向服务器端索要公钥然后⽤公钥加密信息服务器收到密⽂后⽤⾃⼰的私钥解密。 作⽤ 1. 所有信息都是加密传播第三⽅⽆法窃听。 2. 具有校验机制⼀旦被篡改通信双⽅会⽴刻发现。 3. 配备身份证书防⽌身份被冒充。 如何保证公钥不被篡改 解决⽅法将公钥放在数字证书中。只要证书是可信的公钥就是可信的。 公钥加密计算量太⼤如何减少耗⽤的时间 每⼀次对话session客户端和服务器端都⽣成⼀个对话密钥session key⽤它来加密信息。由于对话密钥是对称加密所以运算速度⾮常快⽽服务器公钥只⽤于加密对话密钥本身这样就减少了加密运算的消耗时间。 TCP 与 HTTPS 握⼿顺序 「HTTPS 是先进⾏ TCP 三次握⼿再进⾏ TLSv1.2 四次握⼿」⽽「HTTPS 中的 TLS 握⼿过程可以同时进⾏三次握⼿」这个场景是可能存在的但是需要同时满⾜下⾯这两个条件才可以 1. 客户端和服务端已经完成过⼀次通信 2. TLS 版本是 1.3 TLSv1.3 会话恢复机制在重连 TLvS1.3 只需要 0-RTT 3. 客户端和服务端都开启了 TCP Fast Open 功能第⼀次通信服务端设置cookie选项之后客户端保存并在后续再次连接时使⽤可传递cookie建⽴连接并传输数据。 RSA 密钥交换算法 第⼀次握⼿客户端发出请求ClientHello ⾸先客户端通常是浏览器先向服务器发出加密通信的请求这被叫做ClientHello请求。在这⼀步客户端主要向服务器提供以下信息。 1. ⽀持的协议版本⽐如TLS 1.0版。 2. ⼀个客户端⽣成的随机数稍后⽤于⽣成对话密钥。 3. ⽀持的加密⽅法⽐如RSA公钥加密。 4. ⽀持的压缩⽅法。 第⼆次握⼿服务器回应SeverHello 服务器收到客户端请求后向客户端发出回应这叫做SeverHello。服务器的回应包含以下内容。 1. 确认使⽤的加密通信协议版本。如果浏览器与服务器⽀持的版本不⼀致服务器关闭加密通信。 2. 服务器⽣成的随机数稍后⽤于⽣成对话密钥。 3. 确认使⽤的加密⽅法。 4. 服务器证书。除了上⾯这些信息如果服务器需要确认客户端的身份就会再包含⼀项请求要求客户端提供客户端证书。 第三次握⼿客户端回应 客户端收到服务器回应以后⾸先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不⼀致、或者证书已经过期就会向访问者显示⼀个警告由其选择是否还要继续通信。如果证书没有问题客户端就会从证书中取出服务器的公钥。然后向服务器发送下⾯三项信息。 1. ⼀个随机数。该随机数⽤服务器公钥加密防⽌被窃听。 2. 编码改变通知表示随后的信息都将⽤双⽅商定的加密⽅法和密钥发送。 3. 客户端握⼿结束通知表示客户端的握⼿阶段已经结束。这⼀项同时也是前⾯发送的所有内容的 hash值⽤来供服务器校验。此时客户端和服务器就同时有了三个随机数接着双⽅就⽤事先商定的加密⽅法各⾃⽣成本次会话所⽤的同⼀把会话密钥。此外如果前⼀步服务器要求客户端证书客户端会在这⼀步发送证书及相关信息。 第四次握⼿服务器的最后回应服务器收到客户端的第三个随机数pre-master key之后计算⽣成本次会话所⽤的会话密钥。然后向客户端最后发送下⾯信息。 1. 编码改变通知表示随后的信息都将⽤双⽅商定的加密⽅法和密钥发送。 2. 服务器握⼿结束通知表示服务器的握⼿阶段已经结束。这⼀项同时也是前⾯发送的所有内容的 hash值⽤来供客户端校验。⾄此整个握⼿阶段全部结束。接下来客户端与服务器进⼊加密通信就完全是使⽤普通的HTTP协议只不过⽤会话密钥加密内容。如何⾃动切换到 HTTPS 的 1. 最原始的使⽤ 302 跳转。但这样做有⼀个明显的安全漏洞 很可能都没到 302 跳转的时候就被劫持了。 2. 使⽤ HSTS 。⽀持 HSTS 的服务端可以强制访问它的浏览器使⽤ HTTPS 协议。 使⽤ RSA 密钥协商算法的最⼤问题是不⽀持前向保密。因为客户端传递随机数⽤于⽣成对称加密密钥的条件之⼀给服务端时使⽤的是公钥加密的服务端收到到后会⽤私钥解密得到随机数。所以⼀旦服务端的私钥泄漏了过去被第三⽅截获的所有 TLS通讯密⽂都会被破解。为了解决这个问题后⾯就出现了 ECDHE 密钥协商算法我们现在⼤多数⽹站使⽤的正是 ECDHE 密钥协商算法。 ECDHE 密钥交换算法 ECDHE 密钥协商算法是 DH 算法演进过来的DH 算法是⾮对称加密算法 因此它可以⽤于密钥交换该算法的核⼼数学思想是离散对数。 RSA 和 ECDHE 握⼿过程的区别 ● RSA 密钥协商算法「不⽀持」前向保密ECDHE 密钥协商算法「⽀持」前向保密 ● 使⽤了 RSA 密钥协商算法TLS 完成四次握⼿后才能进⾏应⽤数据传输⽽对于 ECDHE 算 法客户端可以不⽤等服务端的最后⼀次 TLS 握⼿就可以提前发出加密的 HTTP 数据节省了 ⼀个消息的往返时间 2.6 DNS 整体流程浏览器搜索⾃身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host ⽂件和向本地 DNS 服务器进⾏查询等。 DNS 服务器查询共有两类 1. 递归查询当 A 向 B 查询某个域名的 IP 地址时如果 B 不知道被查询的域名的 IP 地址那么 B 会替 A 向更上层的服务器发起查询将查询结果返回 A。 2. 迭代查询当 A 向 B 查询某个域名的 IP 地址时如果 B 不知道被查询的域名的 IP 地址B 会告诉 A 下⼀步应该向哪个服务器查询由 A ⾃⼰去查。 ⼀般来说主机向本地域名服务器的查询是递归查询⽽本地域名服务器向根域名服务器的查询是迭代查询。 2.7 IP IP协议头部20字节使⽤逐跳的⽅式确定通信路径为上层协议提供⽆状态、⽆连接、不可靠的服务。 ● ⽆状态 是指 IP 通信双⽅不同步传输数据的状态信息因此所有IP数据报的发送、传输和接收都是相互独⽴、没有上下⽂关系的这种服务最⼤的缺点是⽆法处理乱序和重复的IP数据报。 ● ⽆连接 是指 IP 通信双⽅都不⻓久地维持对⽅的任何信息上层协议每次发送数据的时候都必须明确指定对⽅的IP地址。 ● 不可靠 是指 IP 协议不能保证 IP 数据报准确地到达接收端即使检测到 IP 数据报发送失败则通知上层协议发送失败⽽不会试图重传。IP 转发处理步骤 1. 检查数据报头部的TTL值如果等于0则丢弃该数据报 2. 查看数据报头部的严格源路由选择选项。如果该项被设置则检测数据报的⽬标IP地址是否是本机的某个IP地址。如果不是则发送⼀个ICMP源站选路失败报⽂给发送端。如果有必要则给源端发送⼀个ICMP重定向报⽂以告诉它⼀个更合理的下⼀跳路由器 3. 将TTL值减⼀ 4. 处理IP头部选项。如果有必要则执⾏IP分⽚操作。 2.8 WebSocket 握⼿过程 1. 浏览器、服务器建⽴ TCP 连接三次握⼿ 2. TCP 连接成功后浏览器通过 HTTP 协议向服务器传送 WebSocket ⽀持的版本号等信息 3. 服务器收到客户端的握⼿请求后同样采⽤ HTTP 协议回馈数据 4. 当收到了连接成功的消息后通过 TCP 通道进⾏传输通信 WebSocket 与 HTTP 的关系 相同点 1. 都是基于 TCP 的、可靠的传输协议 2. 都是应⽤层协议 不同点 1. WebSocket 是双向通信协议模拟 Socket 协议可以双向发送或接受信息。HTTP 是单向的 2. WebSocket 是需要握⼿进⾏建⽴连接的联系 WebSocket 在建⽴握⼿时数据是通过 HTTP 传输的。但是建⽴之后在真正传输的时候是不需要HTTP 协议的WebSocket 与 Socket 关系。 1. Socket 其实并不是⼀个协议⽽是为了⽅便使⽤ TCP 或 UDP ⽽抽象出来的⼀层是位于应⽤层和传输层之间的⼀组接⼝。当两台主机通信时必须通过 Socket 连接Socket 则利⽤ TCP/IP 协议建⽴ TCP 连接。TCP 连接则更依靠于底层的 IP 协议IP 协议的连接则依赖于链路层等更低 层次。 2. WebSocket 则是⼀个典型的应⽤层协议。 WebSocket 与 HTML5 的关系 WebSocket API 是 HTML5 标准的⼀部分但这并不代表 WebSocket ⼀定要⽤在 HTML 中或者只能在基于浏览器的应⽤程序中使⽤。实际上许多语⾔、框架和服务器都提供了 WebSocket ⽀持。 2.9 DHCP DHCP 动态主机配置协议 是⼀个局域⽹的⽹络协议。指的是由服务器控制⼀段IP地址范围客户机登录服务器时就可以⾃动获得服务器分配的IP地址和⼦⽹掩码。DHCP 客户端进程监听的是 68 端⼝号DHCP 服务端进程监听的是 67 端⼝号。 4 个步骤 ● 客户端⾸先发起 DHCP 发现报⽂DHCP DISCOVER 的 IP 数据报由于客户端没有 IP 地址也不知道 DHCP 服务器的地址所以使⽤的是 UDP ⼴播通信其使⽤的⼴播⽬的地址是 68 255.255.255.255端⼝ 67 并且使⽤ 0.0.0.0端⼝ 68 作为源 IP 地址。DHCP 客户端将该 IP 数据报传递给链路层链路层然后将帧⼴播到所有的⽹络中设备。 ● DHCP 服务器收到 DHCP 发现报⽂时⽤ DHCP 提供报⽂DHCP OFFER 向客户端做出响 应。该报⽂仍然使⽤ IP ⼴播地址 255.255.255.255该报⽂信息携带服务器提供可租约的 IP 地 址、⼦⽹掩码、默认⽹关、DNS 服务器以及 IP 地址租⽤期。 ● 客户端收到⼀个或多个服务器的 DHCP 提供报⽂后从中选择⼀个服务器并向选中的服务器发送 DHCP 请求报⽂进⾏响应回显配置的参数。 ● 最后服务端⽤ DHCP ACK 报⽂对 DHCP 请求报⽂进⾏响应应答所要求的参数。 ⼀旦客户端收到 DHCP ACK 后交互便完成了并且客户端能够在租⽤期内使⽤ DHCP 服务器分配的 IP 地址 如果租约的 DHCP IP 地址快到期后客户端会向服务器发送 DHCP 请求报⽂ ● 服务器如果同意继续租⽤则⽤ DHCP ACK 报⽂进⾏应答客户端就会延⻓租期。 ● 服务器如果不同意继续租⽤则⽤ DHCP NACK 报⽂客户端就要停⽌使⽤租约的 IP 地址。 可以发现DHCP 交互中全程都是使⽤ UDP ⼴播通信。如果 DHCP 服务器和客户端不是在同⼀个局域⽹内路由器⼜不会转发⼴播包为了解决这⼀问题就出现了 DHCP 中继代理。有了 DHCP 中继代理以后对不同⽹段的 IP 地址分配也可以由⼀个 DHCP服务器统⼀进⾏管理。 ● DHCP 客户端会向 DHCP 中继代理发送 DHCP 请求包⽽ DHCP 中继代理在收到这个⼴播包以 后再以单播的形式发给 DHCP 服务器。 ● 服务器端收到该包以后再向 DHCP 中继代理返回应答并由 DHCP 中继代理将此包⼴播给 DHCP客户端 。因此DHCP 服务器即使不在同⼀个链路上也可以实现统⼀分配和管理IP地址. 2.10 NET 由于绝⼤多数的⽹络应⽤都是使⽤传输层协议 TCP 或 UDP 来传输数据的。因此可以把 IP 地址 端⼝号⼀起进⾏转换。这样就⽤⼀个全球 IP 地址就可以了这种转换技术就叫⽹络地址与端⼝转换NAPT。这种转换表在 NAT 路由器上⾃动⽣成。例如在 TCP 的情况下建⽴ TCP 连接⾸次握⼿时的 SYN 包⼀经发出就会⽣成这个表。⽽后⼜随着收到关闭连接时发出 FIN 包的确认应答从表中被删除。由于 NAT/NAPT 都依赖于⾃⼰的转换表因此会有以下的问题 ● 外部⽆法主动与 NAT 内部服务器建⽴连接因为 NAPT 转换表没有转换记录。 ● 转换表的⽣成与转换操作都会产⽣性能开销。 ● 通信过程中如果 NAT 路由器重启了所有的 TCP 连接都将被重置。 解决的⽅法 ● 第⼀种改⽤ IPv6IPv6 可⽤范围⾮常⼤以⾄于每台设备都可以配置⼀个公有 IP 地址就不搞那么多花⾥胡哨的地址转换了但是 IPv6 普及速度还需要⼀些时间。 ● 第⼆种 NAT 穿透技术客户端主动从 NAT 设备获取公有 IP 地址然后⾃⼰建⽴端⼝映射条⽬并⽤这个条⽬对外通信就不需要 NAT 设备来进⾏转换了。 2.11 IGMP IGMP 是因特⽹组管理协议⼯作在主机组播成员和最后⼀跳路由之间。IGMP 报⽂向路由器申请 加⼊和退出组播组默认情况下路由器是不会转发组播包到连接中的主机除⾮主机通过 IGMP 加⼊到 组播组主机申请加⼊到组播组时路由器就会记录 IGMP 路由器表路由器后续就会转发组播包到对 应的主机了。IGMP 报⽂采⽤ IP 封装IP 头部的协议号为 2⽽且 TTL 字段值通常为 1因为 IGMP 是⼯作在主机与连接的路由器之间。 常规查询与响应⼯作机制 ● 路由器会周期性发送⽬的地址为 224.0.0.1表示同⼀⽹段内所有主机和路由器 IGMP 常规查询报⽂。 ● 主机收到这个查询随后会启动「报告延迟计时器」计时器的时间是随机的通常是 0~10 秒计时器超时后主机就会发送 IGMP 成员关系报告报⽂源 IP 地址为⾃⼰主机的 IP 地址⽬的 IP 地址为组播地址。如果在定时器超时之前收到同⼀个组内的其他主机发送的成员关系报告报⽂则⾃⼰不再发送这样可以减少⽹络中多余的 IGMP 报⽂数量。 ● 路由器收到主机的成员关系报⽂后就会在 IGMP 路由表中加⼊该组播组后续⽹络中⼀旦该组播地址的数据到达路由器它会把数据包转发出去。离开组播组⼯作机制 ● 主机 1 要离开组 224.1.1.1发送 IGMPv2 离组报⽂报⽂的⽬的地址是 224.0.0.2表示发向⽹段内的所有路由器 ● 路由器 收到该报⽂后以 1 秒为间隔连续发送 IGMP 特定组查询报⽂共计发送 2 个以便确认该⽹络是否还有 224.1.1.1 组的其他成员。 ● 主机 3 仍然是组 224.1.1.1 的成员因此它⽴即响应这个特定组查询。路由器知道该⽹络中仍然存在该组播组的成员于是继续向该⽹络转发 224.1.1.1 的组播数据包。否则不会再向这个⽹段转发该组播地址的数据包。
