h56wcom什么网站,网站关键词搜不到了,达州市住房与城乡建设厅网站,固原地网站seo1、QUIC 是一个精巧的协议#xff0c;它有哪些特性#xff1f;
答#xff1a;QUIC 还有其他特性#xff0c;一个是快速建立连接。另一个是拥塞控制#xff0c;QUIC 协议当前默认使用了 TCP 协议的 CUBIC#xff08;拥塞控制算法#xff09;。
CUBIC 进行了不同的设计它有哪些特性
答QUIC 还有其他特性一个是快速建立连接。另一个是拥塞控制QUIC 协议当前默认使用了 TCP 协议的 CUBIC拥塞控制算法。
CUBIC 进行了不同的设计它的窗口增长函数仅仅取决于连续两次拥塞事件的时间间隔值窗口增长完全独立于网络的时延 RTT。
CUBIC 的窗口大小以及变化过程如图所示。 当出现丢包事件时CUBIC 会记录这时的拥塞窗口大小把它作为 Wmax。接着CUBIC 会通过某个因子执行拥塞窗口的乘法减小然后沿着立方函数进行窗口的恢复。
从图中可以看出一开始恢复的速度是比较快的后来便从快速恢复阶段进入拥塞避免阶段也即当窗口接近 Wmax 的时候增加速度变慢立方函数在 Wmax 处达到稳定点增长速度为零之后在平稳期慢慢增长沿着立方函数的开始探索新的最大窗口。
2、HTTP 的 keepalive 模式是什么样
答在没有 keepalive 模式下每个 HTTP 请求都要建立一个 TCP 连接并且使用一次之后就断开这个 TCP 连接。
使用 keepalive 之后在一次 TCP 连接中可以持续发送多份数据而不会断开连接可以减少 TCP 连接建立次数减少 TIME_WAIT 状态连接。
然而长时间的 TCP 连接容易导致系统资源无效占用因而需要设置正确的 keepalive timeout 时间。当一个 HTTP 产生的 TCP 连接在传送完最后一个响应后还需要等待 keepalive timeout 秒后才能关闭这个连接。如果这个期间又有新的请求过来可以复用 TCP 连接。
3、HTTPS 协议比较复杂沟通过程太繁复这样会导致效率问题那有哪些手段可以解决这些问题吗
答通过 HTTPS 访问的确复杂至少经历四个阶段DNS 查询、TCP 连接建立、TLS 连接建立最后才是 HTTP 发送数据。
首先如果使用基于 UDP 的 QUIC可以省略掉 TCP 的三次握手。至于 TLS 的建立如果按基于 TLS 1.2 的双方要交换 key经过两个来回也即两个 RTT才能完成握手。
在 TLS 1.3 中握手过程中移除了 ServerKeyExchange 和 ClientKeyExchangeDH 参数可以通过 key_share 进行传输。这样只要一个来回就可以搞定 RTT 了。
对于 QUIC 来讲也可以这样做。当客户端首次发起 QUIC 连接时会发送一个 client hello 消息服务器会回复一个消息里面包括 server config类似于 TLS1.3 中的 key_share 交换。当客户端获取到 server config 以后就可以直接计算出密钥发送应用数据了。
4、.HTTPS 的双向认证流程是什么样的
答
5、随机数和 premaster 的含义是什么
答
6、RTMP 建立连接的序列是什么样的
答 客户端发送 C0、C1、 C2服务器发送 S0、 S1、 S2。
首先客户端发送 C0 表明自己的版本号不必等对方的回复然后发送 C1 表明自己的时间戳。
服务器只有在收到 C0 的时候才能返回 S0表明自己的版本号。如果版本不匹配可以断开连接。
服务器发送完 S0 后也不用等什么就直接发送自己的时间戳 S1。客户端收到 S1 的时候发一个知道了对方时间戳的 ACK C2。同理服务器收到 C1 的时候发一个知道了对方时间戳的 ACK S2。
于是握手完成。
7、全局负载均衡使用过程中常常遇到失灵的情况你知道具体有哪些情况吗对应应该怎么来解决呢
答全局负载均衡失灵的时间可以分情况来应对而导致的。
1全局负载均器因为流量过大失灵此情况是因为流量已经超过了当前机器的极限所导致的针对此只能通过扩容来解决。 2全局负载均衡器因为机器故障了导致的失灵。此情况的发生说明机器存在负载均衡器有单点问题须通过增加备机或者更为可靠的集群来解决。 3全局负载均衡器因为网络故障导致的失录此情况案例莫过于支付宝的光纤被挖掘机挖断此问题可通过接入更多的线路来解。
8、如果权威 DNS 连不上怎么办
答一般情况下DNS 是基于 UDP 协议的。在应用层设置一个超时器如果 UDP 发出没有回应则会进行重试。
DNS 服务器一般也是高可用的很少情况下会挂。即便挂了也会很快切换重试一般就会成功。
对于客户端来讲为了 DNS 解析能够成功也会配置多个 DNS 服务器当一个不成功的时候可以选择另一个来尝试。
9、对于数据中心来讲高可用是非常重要的每个设备都要考虑高可用那跨机房的高可用你知道应该怎么做吗
答其实跨机房的高可用分两个级别分别是同城双活和异地灾备。 同城双活就是在同一个城市距离大概 30km 到 100km 的两个数据中心之间通过高速专线互联的方式让两个数据中心形成一个大二层网络。
同城双活最重要的是数据如何从一个数据中心同步到另一个数据中心并且在一个数据中心故障的时候实现存储设备的切换保证状态能够快速切换到另一个数据中心。在高速光纤互联情况下主流的存储厂商都可以做到在一定距离之内的两台存储设备的近实时同步。数据双活是一切双活的基础。
基于双数据中心的数据同步可以形成一个统一的存储池从而数据库层在共享存储池的情况下可以近实时地切换例如 Oracle RAC。
虚拟机在统一的存储池的情况下也可以实现跨机房的 HA在一个机房切换到另一个机房。
SLB 负载均衡实现同一机房的各个虚拟机之间的负载均衡。GSLB 可以实现跨机房的负载均衡实现外部访问的切换。
如果在两个数据中心距离很近并且大二层可通的情况下也可以使用 VRRP 协议通过 VIP 方式进行外部访问的切换。
异地灾备。 异地灾备的第一大问题还是数据的问题也即生产数据中心的数据如何备份到容灾数据中心。由于异地距离比较远不可能像双活一样采取近同步的方式只能通过异步的方式进行同步。可以预见的问题是容灾切换的时候数据会丢失一部分。
由于容灾数据中心平时是不用的不是所有的业务都会进行容灾否则成本太高。
对于数据的问题我比较建议从业务层面进行容灾。由于数据同步会比较慢可以根据业务需求高优先级同步重要的数据因而容灾的层次越高越好。
例如有的用户完全不想操心直接使用存储层面的异步复制。对于存储设备来讲它是无法区分放在存储上的虚拟机哪台是重要的哪台是不重要的只会完全根据块进行复制很可能就会先复制了不重要的虚拟机。
如果用户想对虚拟机做区分则可以使用虚拟机层面的异步复制。用户知道哪些虚拟机更重要一些哪些虚拟机不重要则可以先同步重要的虚拟机。
对业务来讲如果用户可以根据业务层情况在更细的粒度上区分数据是否重要。重要的数据例如交易数据需要优先同步不重要的数据例如日志数据就不需要优先同步。
在有异地容灾的情况下可以平时进行容灾演练看容灾数据中心是否能够真正起作用别容灾了半天最后用的时候掉链子。 此文章为10月Day13学习笔记内容来源于极客时间《趣谈网络协议》推荐该课程。
