网络基础知识

前言

下文全部来自其他文章的摘抄
基础不牢, 地动山摇

一、HTTP1.0、HTTP1.1、HTTP2.0区别

1.1 HTTP1.0与HTTP1.1的区别

• 1、长连接
• 2、节约带宽
• 3、HOST域(暂时没涉及到, 无法理解)
• 4、缓存处理
• 5、错误通知的管理

1.1.1 长连接

  HTTP1.1支持长连接和请求的 流水线处理, 在一个TCP连接上可以传送多个HTTP请求和响应, 减少了建立和关闭连接的消耗和延迟, 在HTTP1.1中默认开启长连接keep-alive, 一定程度上弥补了HTTP1.0每次请求都创建连接的缺点. HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接.

1.1.2 节约带宽

  HTTP1.0中存在一些浪费带宽的现象, 例如客户端只是需要某个对象的一部分, 而服务器却将整个对象送过来了, 并且不支持断点续传功能. HTTP1.1支持只发送header消息(不带任何body信息), 如果服务器认为客户端有权限请求服务器, 则返回100, 客户端接收到100才开始把请求body发送到服务器, 如果返回401, 客户端就可以不用发送请求body了.

1.1.3 HOST域

1.1.4 缓存处理

  在HTTP1.0中主要使用了header里的If-Modified-Since, Expires来作为缓存判断的标准. HTTP1.1则引入了更多的缓存控制策略例如Entity tag, If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略

1.1.5 错误通知的管理

  在HTTP1.1中新增了24个错误状态响应码, 如409表示请求的资源与资源的当前状态发生冲突, 410表示服务器上的某个资源被永久性的删除

1.2 HTTP1.1和HTTP2.0的区别

1.2.1 多路复用

  HTTP2.0使用了多路复用的技术, 做到同一个连接并发处理多个请求, 而且并发请求的数量比HTTP1.1大了好几个数量级. HTTP1.1也可以多建立几个TCP连接, 来支持处理更多并发的请求, 但是创建TCP连接本身也是有开销的.
  HTTP2.0中涉及到一个 二进制帧层, 可以看做是基于传输层和应用层之间的一个分层.
  HTTP1.1直接将字符形式的请求报文交付给TCP层进行传输, 在应用层必须解析出请求head和body才能完成通信
  HTTP2.0将应用层的数据经过二进制帧层处理, 将不同请求拆成不同的stream, 由stream的id进行标记, 请求的stream被分割成多种类型的帧, 其中包括head帧和data数据帧. 正是因为有了stream的id标记、以及各种不同类型的帧, 确保了请求和响应的有序重组.
  例如请求a.js和b.css, a.js对应的stream的id为1, b.css对应的stream的id为2, a.js的head帧为head1, 数据帧为data1, b.js的head帧为head2, 数据帧为data2, 浏览器可以将head1、data1、head2、data2同时放入TCP信道进行报文传输, 在TCP层, 可能会进一步对这些数据进行拆分, 拆成不同的报文序号进行传输, 但是可以无需关注这层是如何拆分、组装的. 因为可以在HTTP2.0的二进制帧层进行有序处理, 将接收到的stream的id为1的放一起处理, 接收到的stream的id为2的放一起处理.

1.2.2 头部数据压缩

  在HTTP1.1中, HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成. 一般而言, 消息主体 都会经过 gzip压缩, 或者本身传输的就是压缩过后的二进制文件, 但状态行和头部却没有经过任何压缩, 直接以纯文本传输. 随着Web功能越来越复杂, 每个页面产生的请求数也越来越多, 导致消耗在头部的流量越来越多, 尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容, 完全是一种浪费.
  HTTP1.1不支持header数据的压缩, HTTP2.0使用HPACK算法对header的数据进行压缩, 这样数据体积小了, 在网络上传输就会更快.

1.2.3 服务器推送

  服务端推送是一种在客户端请求之前发送数据的机制, 网页使用了许多资源: HTML、样式表、脚本、图片等. 在HTTP1.1中这些资源每一个都必须明确地请求. 这是一个很慢的过程. 浏览器从获取HTML开始, 然后在它解析和评估页面的时候, 增量地获取更多的资源. 因为服务器必须等待浏览器做每一个请求, 网络经常是空闲的和未充分使用的.
  为了改善延迟, HTTP2.0引入了server push, 它允许服务端推送资源给浏览器, 在浏览器明确地请求之前, 免得客户端再次创建连接发送请求到服务器端获取. 这样客户端可以直接从本地加载这些资源, 不用再通过网络.

二、HTTP的keep-alive与TCP的KeepAlive

2.1 TCP的KeepAlive

2.1.1 KeepAlive起源

  TCP协议中有长连接和短连接之分. 短连接环境下, 数据交互完毕后, 主动释放连接;
  长连接的环境下, 进行一次数据交互后, 很长一段时间内无数据交互时, 客户端可能意外断电、死机、崩溃、重启, 还是中间路由网络无故断开, 这些TCP连接并未来得及正常释放, 那么, 连接的另一方并不知道对端的情况, 它会一直维护这个连接, 长时间的积累会导致非常多的半打开连接, 造成端系统资源的消耗和浪费, 且有可能导致在一个无效的数据链路层面发送业务数据, 结果就是发送失败. 所以服务器端要做到快速感知失败, 减少无效连接操作, 这就有了TCP的KeepAlive(保活探测)机制.

2.1.2 KeepAlive工作原理

  当一个TCP连接建立之后, 启用TCP KeepAlive的一端便会启动一个计时器, 当这个计时器数值到达0之后(也就是经过tcp_keep_alive_time时间后), 一个TCP探测包便会被发出. 这个TCP探测包是一个纯ACK包, 其Seq号与上一个包是重复的, 所以 探测保活报文不在窗口控制范围内

2.1.3 KeepAlive工作流程

如果一个给定的连接在两小时内(默认时长)没有任何的动作, 则服务器就向客户端发送一个探测报文段, 客户主机必须处于以下4个状态之一

• 1、客户主机依然正常运行, 并从服务器可达. 客户端的TCP响应正常, 而服务器也知道对方是正常的, 服务器在两小时后将保活定时器复位
• 2、客户主机已经崩溃, 并且关闭或者正在重新启动. 在任何一种情况下, 客户端的TCP都没有响应, 服务端将不能收到对探测的响应, 并在75秒后超时. 服务器总共发送10个这样的探测, 每个间隔75秒, 如果服务器没有收到一个响应, 它就认为客户主机已经关闭并终止连接
• 3、客户主机崩溃并已经重新启动. 服务器收到一个对其保活探测的响应, 这个响应是一个复位, 使得服务器终止这个连接.
• 4、客户机正常运行, 但是服务器不可达, 这种情况与2类似, TCP能发现的就是没有收到探测的响应.

2.1.4 KeepAlive的作用

• 1、探测连接的对端是否存活, 在应用交互的过程中, 可能存在以下几种情况:

1. 客户端或服务器意外断电, 死机、崩溃、重启
2. 中间网络已经中断, 而客户端与服务器并不知道

利用保活探测功能, 可以探知这种对端的意外情况, 从而保证在意外发生时, 可以释放半打开的TCP连接

• 2、防止中间设备因超时删除连接相关的连接表
    中间设备如防火墙等, 会为经过它的数据报文建立相关的连接信息表, 并为其设置一个超时时间的定时器, 如果超出预定时间, 某连接无任何报文交互的话, 中间设备会将该连接信息从表中删除, 在删除后, 再有应用报文过来时, 中间设备将丢弃该报文, 从而导致应用出现异常.

2.1.5 KeepAlive可能导致的问题

KeepAlive配置默认是关闭的, 不当的配置可能导致下列问题:

• 1、在短暂的故障期间, KeepAlive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接
• 2、需要消耗额外的宽带和流程
• 3、在以流量计费的互联网环境中增加了费用开销

2.2 HTTP的keep-alive

在HTTP1.0中, 默认使用的是短连接. 也就是说浏览器和服务器每进行一次HTTP操作, 就建立一次连接, 但任务结束就中断连接. 如果客户端浏览器访问的某个HTML或其他类型的Web页中包含其他的Web资源, 当浏览器每遇到这样一个Web资源, 就会建立一个HTTP会话.

但从HTTP1.1开始, 默认使用长连接, 用以保持连接特性. 使用长连接的HTTP协议, 会在响应头上加Connection:keep-alive字段

HTTP1.0和1.1在TCP连接使用方面的差异如下图所示:

2.3 KeepAlive与keep-alive总结

HTTP协议的keep-alive意图在于TCP连接复用, 同一个连接上串/并行方式传递请求-响应数据; TCP的KeepAlive机制意图在于探测连接的对端是否存活.

二、HTTPS

2.1 HTTPS加密过程

2.1.1 客户端发起HTTPS请求

  客户端发起连接的请求

2.1.2 服务端的配置

  采用HTTPS协议的服务器必须要有一套数字证书, 可以自己制作, 也可以向组织申请, 区别就是自己颁发的证书需要客户端验证通过, 才可以继续访问, 而使用受信任的公司申请的证书则不会弹出页面. 这套证书其实就是一对公钥和私钥. 如果对公钥和私钥不太理解, 可以想象成一把钥匙和一个锁头, 只是全世界只有你一个人有这把钥匙, 你可以把锁头给别人, 别人可以用这个锁把重要的东西锁起来, 然后发给你, 因为只有你一个人有这把钥匙, 所以只有你才能看到被这把锁锁起来的东西.

2.1.3 传送证书

  这个证书其实就是公钥, 只是包含了很多信息, 如证书的颁发机构, 过期时间等

2.1.4 客户端解析证书

  这部分工作是客户端的TLS来完成的, 首先会验证公钥是否有效, 比如颁发机构、过期时间等, 如果发现异常, 则会提示证书存在问题, 如果证书没有问题, 生成一个随机值. 然后用证书对该随机值进行加密.

2.1.5 传送加密信息

  这部分传送的是用证书加密后的随机值, 目的就是让服务端得到这个随机值, 以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了.

2.1.6 服务端解密信息

  服务端用私钥解密后, 得到了客户端传过来的随机值(私钥), 然后把内容通过该值进行对称加密.

2.1.7 传输加密后的信息

  这部分信息是服务端用私钥加密后的信息, 可以在客户端被还原

2.1.8 客户端解密信息

  客户端用之前生成的私钥解密服务端传过来的信息, 于是获取了解密后的内容.

2.2 证书机制/证书验证

在TLS中, 我们需要证书来保证你所访问的服务器是真实的, 可信的.

• 1、客户端获取到了站点证书, 拿到了站点的公钥
• 2、要验证站点可信后, 才能使用其公钥, 因此客户端找到其站点证书颁发者的信息
• 3、站点证书的颁发者验证了服务端站点是可信的, 但客户端依然不清楚该颁发者是否可信
• 4、再往上回溯, 找到认证中间证书商的源头证书颁发者. 由于源头的证书颁发者非常少, 浏览器或者设备内置的之前就认识了, 因此可以认为根证书颁发者是可信的
• 5、一路倒推, 证书颁发者可信, 那么它所颁发的所有站点也是可信的, 最终确定了所访问的服务端是可信的

2.3 证书验证策略

2.3.1 CRL

  Certificate Revocation List(证书撤销名单). 证书颁发者会提供一份已经失效证书的名单, 供客户端验证证书使用. 这份名单非常的大, 客户端不可能每次TLS都去下载, 所以常用的做法是客户端会缓存这份名单, 定期做后台更新, 这样虽然后台更新存在时间间隔, 证书失效不实时

2.3.2 OCSP

  Online Certificate StatusProtocol(在线证书状态协议). 除了离线文件, 证书颁发者也会提供实时的查询接口, 查询某个特定证书目前是否有效. 实时查询的问题在于浏览器需要等待这个查询结束才能继续TLS握手, 延迟会更大.

2.4 中间人劫持

2.4.1 中间人劫持流程

  中间人截取客户端发送给服务器的请求, 然后伪装成客户端与服务器进行通信, 将服务器返回给客户端的内容发送给客户端, 伪装成服务器与客户端进行通信, 通过这样的手段, 便可以获取客户端和服务器之间通信的所有内容
  使用中间人攻击手段, 必须要让客户端信任中间人的证书, 如果客户端不信任, 则这种攻击手段也无法发挥作用.

2.4.2 中间人攻击的预防

2.5 加密算法

加密方式	加密算法
对称加密	AES、DES
非对称加密	RSA、DSA、ECC

三、TCP与UDP

3.1 TCP与UDP的区别

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输, 不使用流量控制和拥塞控制
连接对象个数	支持一对一、一对多、多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小, 仅8字节	首部最小20字节, 最大60字节
适用场景	适用于实时应用(IP电话、视频会议、直播等)	适用于要求可靠传输的应用, 例如文件传输

3.2 UDP

UDP协议全称是用户数据报协议, 特点如下:

3.2.1 面向无连接

  UDP不需要和TCP一样在发送数据前进行三次握手建立连接, 想发数据就可以开始发送了, 并且也只是数据报文的搬运工, 不会对数据报文进行任何拆分和拼接操作.
  具体来说就是:

• 1、在发送端, 应用层将数据传递给传输层的UDP协议, UDP只会给数据增加一个UDP头标识下是UDP协议, 然后就传递给网络层了
• 2、在接口端, 网络层将数据传递给传输层, UDP只去除IP报文头就传递给应用层, 不会进行任何拼接操作

3.2.2 有单播、多播、广播的功能

3.2.3 UDP是面向报文的

  发送方的UDP对应用程序交下来的报文, 在添加首部后就向下交付IP层. UDP对应用层交下来的报文, 既不合并, 也不拆分, 而是保留这些报文的边界. 因此, 应用程序必须选择合适大小的报文.

3.2.4 不可靠性

• 首先不可靠性体现在无连接上, 通信都不需要建立连接, 想发就发, 这样的情况肯定不可靠
• 收到什么数据就传递什么数据, 也不会对数据进行备份, 发送数据也不会关心对方是否已经正确收到数据了
• 网络环境时好时坏, 但是UDP因为没有拥塞控制, 一直会以恒定的速度发送数据, 即使网络条件不好, 也不会对发送速率进行调整. 这样实现的弊端就是在网络条件不好的情况下可能会导致丢包. 但是 优点也很明显, 在某些实时性要求高的场景(比如电话会议)就需要使用UDP而不是TCP

3.2.5 头部开销小

3.3 TCP

TCP协议全称是传输控制协议. 特点如下:

3.3.1 面向连接

  面向连接, 是指发送数据之前必须在两端建立连接, 建立连接的方法是"三次握手", 这样能建立可靠的连接, 建立连接是为数据的可靠传输打下基础

3.3.2 面向字节流

  TCP不想UDP一样一个个报文独立地传输, 而是在不保留报文边界的情况下以字节流方式进行传输

3.3.3 可靠传输

  对于可靠传输, 判断丢包, 误码靠的是TCP的段编号以及确认号, TCP为了保证报文传输的可靠, 就给每个包一个序号, 同时序号也保证了传递到接收端实体的包的按序接收, 然后接收端实体对已成功收到的字节发回一个相应的确认, 如果发送端实体在合理的往返时延(RTT)内未收到确认, 那么对于的数据(假设丢失了)将会被重传

3.4 三次握手

• 第一次握手: 建立连接时, 客户端发送syn = a包 (SYN = Synchronize Sequence Numbers同步序列编号) , 并进入syn_sent状态,等待服务器确认;
• 第二次握手: 服务器收到syn包以后, 向客户端返回ack = a + 1, 并生成自己的seq = b, 进入SYN_RECV状态
• 第三次握手: 客户端收到服务器的ack后, 向服务器发送确认包ack = b + 1, 此包发送完毕以后, 客户端和服务端进入成功连接状态

3.5 四次挥手

• 第一次挥手: 客户端发出连接释放报文, 并且停止发送数据, 释放数据报文首部. FIN = 1, seq = a, 然后客户端进入FIN-WAIT-1(终止等待1)状态
• 第二次挥手: 服务端收到报文以后, 返回 ack = a + 1, 并返回自己的seq = b, 此时服务端进入CLOSE-WAIT(关闭等待)状态
• 客户端: 客户端收到服务器的确认请求后, 进入FIN-WAIT-2(终止等待2)状态, 等待服务器发送连接释放报文(在这之前还需要接收服务器发送的最后的数据)
• 第三次挥手: 服务器将最后的数据发送完毕后, 就向客户端发送连接释放的报文. FIN = 1, ack = a + 1, seq = c, 此时客户端进入TIME-WAIT(时间等待)状态, 注意: 此时TCP连接还没有释放, 必须经过2MSL (Maximum Segment Lifetime最长报文寿命) 时间后, 当车客户端撤销TCB后, 才进入CLOSED状态
• 第四次挥手: 服务端只要收到客户端发出的确认后, 立即进入CLOSED状态.(服务器结束TCP连接的时间要比客户端早一些)

问题一:
  为什么连接的时候是三次握手, 关闭的时候是四次挥手?
答一:
  因为当Server端收到Client端的SYN连接请求报文后, 可以直接发送SYN + ACK报文, 其中ACK报文是用来应答的, SYN报文是用来同步的, 但是关闭连接时, 当Server端收到FIN报文时, 很可能并不会立即关闭SOCKET, 所以只能先回复一个ACK报文. 告诉Client端, “你发送的FIN报文我收到了”, 只有等到我的Server端所有的报文都发送完了, 我才能发送FIN报文, 因此不能一起发送, 所以需要四次握手

问题二:
  为什么TIME_WAIT状态需要经过2MSL才能到CLOSE状态?
答二:
  实际上需要假想网络是不可靠的, 有可能最后一个ACK丢失, 所以TIME_WAIT状态就是用来重发可能丢失的ACK报文, 在Client发送出最后的ACK回复之后, 但该ACK丢失了, Server如果没有收到ACK, 将不断重复发送FIN, 所以Client不能立即关闭, 它必须确认Server接收到了该ACK. Client会在发送出ACK之后进入到TIME_WAIT状态. Client会设置一个计时器, 等待2MSL的时间, 如果在该时间内再次收到FIN, 那么Client会重发ACK并再次等待2MSL (MSL指一个片段在网络中最大的存活时间, 2MSL就是一个发送和一个回复所需的最大时间), 如果直到2MSL, Client都没有再次收到FIN, 那么Client推断ACK已经被成功接收, 则结束TCP连接

问题三:
  为什么不能两次握手进行连接?
答三:
  如果把三次握手改为仅需要两次握手, 可能会发生死锁, 举例: Client给Server发送一个连接请求, S收到这个请求, 并发送了确认应答. 按照两次握手协定, Server认为连接已经成功地建立了, 开始发送数据, 假设Server发送给Client的应答数据在传输的过程中丢失了, 将不知道Server是否已准备好, 在这种情况下, Client认为连接还未建立成功, 将忽略Server发送来的任何数据, 只等待连接确认, 而Server在发出的数据超时后, 重复发送同样的数据, 这样就形成了死锁.

四、DNS

4.1 DNS域名解析流程

• 1、客户端先检查本地是否存在缓存
• 2、如果本地没有缓存, 会进行诊治的请求本地域名服务器(LDNS)来解析这个域名, 这台服务器一般在你的城市的某个角落, 举例你不会很远, 并且这台服务器的性能都很好, 一般都会缓存域名解析结果, 大约80%的域名解析到这里就完成了
• 3、如果LDNS也没有命中, 就直接跳到Root Server域名服务器请求解析
• 4、根域名服务器返回给LDNS一个所查询域的主域名服务器 (gTLD Server) 地址
• 5、此时LDNS再发送请求给上一步返回的gTLD
• 6、接受请求的gTLD返回给LDNS这个域名对应的Name Server, 这个Name Server就是网站注册的域名服务器
• 7、Name Server根据映射关系表找到目标IP, 返回给LDNS
• 8、LDNS缓存这个域名和对应的IP
• 9、LDNS把解析的结果返回给用户, 用户根据TTL值缓存到本地系统中, 域名解析过程至此结束

4.2 DNS负载均衡

4.2.1 HTTP重定向协议实现负载均衡

4.2.1.1 原理

  HTTP重定向服务器是一台普通的应用服务器, 其唯一功能是根据用户的HTTP请求计算出一台真实的服务器地址, 并将该服务器地址写入HTTP重定向响应中 (重定向响应状态码为302) 返回给用户浏览器. 用户浏览器在获取到响应之后, 根据返回的信息, 重新发送一个请求到真实的服务器上. 如上图所示, 浏览器访问www.apusapp.com, DNS服务器解析到的IP地址为114.100.20.200, 即HTTP重定向服务器的IP地址. 重定向服务器根据某种负载均衡算法算出真实的服务器地址为114.100.20.203并返回给用户浏览器, 用户浏览器得到返回的结果后重新对114.100.20.203发起请求, 最后完成访问

4.2.1.2 优点

  实现简单

4.2.1.3 缺点

• 1、客户端需要两次请求服务器才能完成一次访问, 性能较差
• 2、同时重定向服务器本身的处理能力有可能成为瓶颈, 整个集群的伸缩性规模有限
• 3、使用HTTP返回码302重定向, 有可能使搜索引擎判断为SEO作弊, 降低搜索排名
• 4、因此实践中很少使用这种负载均衡方案来部署

4.2.2 集群的方式实现负载均衡

4.2.2.1 原理

  在DNS系统中有一个比较重要的资源类型叫做主机记录也称为A记录, A记录是用于名称解析的重要记录, 它将特定的主机名映射到对应主机的IP地址上. 如果你有一个自己的域名, 那么要想别人能访问到你的网站, 你需要到特定的DNS解析服务商的服务器上填写A记录, 过一段时间后, 别人就能通过你的域名访问你的网站了.
  每次域名解析请求都会根据对应的负载均衡算法计算出一个不同的IP地址并返回, 这样A记录中配置多个服务器就可以构成一个集群, 并可以实现负载均衡.

4.2.2.2 DNS域名解析负载均衡优点

• 1、将负载均衡的工作交给DNS, 省去了网站管理维护负载均衡服务器的麻烦
• 2、技术实现比较灵活、方便、简单易行、成本低, 适用于大多数TCP/IP应用
• 3、对于部署在服务器上的应用来说不需要进行任何的代码修改即可实现不同机器上的应用访问
• 4、服务器可以位于互联网的任意位置
• 5、许多DNS还支持基于地理位置的域名解析, 即会将域名解析成距离用户地理最近的一个服务器地址上, 这样就可以加速用户访问, 改善性能

4.2.2.3 DNS域名解析缺点

• 1、目前DNS是多级解析的, 每一级DNS都可能缓存A记录, 当某台服务器下线之后, 即使修改了A记录, 要使其生效也需要较长的时间, 这段时间DNS仍然会将域名解析到已下线的服务器上, 最终导致用户访问失败
• 2、不能够按服务器的处理能力来分配负载. DNS负载均衡采用的是简单的轮询算法, 不能区分服务器之间的差异, 不能反映服务器当前运行状态, 所以其负载均衡算法效果并不是太好
• 3、可能会造成额外的网络问题. 为了使本地DNS服务器和其他DNS服务器及时交互, 保证DNS数据及时更新, 使地址能随机分配, 一般都要将DNS的刷新时间设置的较小, 但太小将会使DNS流量大增造成额外的网络问题

4.2.3 总结

  事实上, 大型网站总是部分使用DNS域名解析, 利用域名解析作为第一级负载均衡手段, 即域名解析得到的一组服务器并不是实际提供服务的物理服务器, 而是同样提供负载均衡服务器的内部服务器, 这组内部负载均衡服务器再进行负载均衡, 将请求发到真实的服务器上, 最终完成请求.

4.3 HTTPDNS

4.3.1 DNS存在的问题

4.3.1.1 域名缓存问题

  本地做一个缓存, 直接返回缓存数据. 可能会导致全局负载均衡失败, 因为上次进行的缓存, 不一定是这次离客户最近的地方, 可能会绕远路.

4.3.1.2 域名转发问题

  如果是A运营商将解析的请求转发给B运营商, B去权威DNS服务器查询的话, 权威服务器会认为你是B运营商的, 就返回了B运营商的网站地址, 结果每次都会跨运营商

4.3.1.3 出口NAT问题

  做了 网络地址转化后, 权威的DNS服务器没法通过地址来判断客户到底是哪个运营商, 极有可能误判运营商, 导致跨运营商访问

4.3.1.4 域名更新问题

  本地DNS服务器是由不同地区, 不同运营商独立部署的, 对域名解析缓存的处理上, 有区别, 有的会偷懒忽略解析结果TTL的时间限制, 导致服务器没有更新新的ip而是指向旧的ip

4.3.1.5 解析延迟

  DNS的查询过程需要遍历多个DNS服务器, 才能获得最终结果. 可能会带来一定的延时

4.3.2 HTTPDNS工作模式

4.3.2.1 原理

  不走传统的DNS解析, 而是自己搭建基于HTTP协议的DNS服务器集群, 分布在多个地点和多个运营商, 当客户端需要DNS解析的时候, 直接通过HTTP协议进行请求这个服务器集群, 获得就近的地址

4.3.2.2 流程

• 1、在客户端的SDK里动态请求服务端, 获取HTTPDNS服务器的ip列表, 缓存到本地. SDK也会在本地缓存DNS域名解析的结果. 这个缓存和本地DNS的缓存不一样, 不是整个运营商统一做的, 而是手机应用来做的, 如何更新, 何时更新
• 2、如果本地无, 就需要请求HTTPDNS的服务器, 在本地的ip列表中, 选择一个发出HTTP请求, 返回一个要访问的网站的ip列表. 手机客户端知道手机所在的运营商, 可以精确做到全局负载均衡

4.3.2.3 HTTPDNS的缓存设计

  解析的过程不需要本地DNS服务递归调用一大圈, 一个HTTP请求直接搞定, 本地也有缓存, 过期时间, 更新时间都可以自己控制.
  例如DNS缓存在内存中, 也可以持久化到存储上, app重启后就可以尽快的从存储中加载上次积累的解析结果.
  SDK中的缓存会严格按照缓存过期时间, 如果没有命中, 或已经过期, 则不允许使用过期记录, 会发起一次解析, 保证记录是新的.
  解析支持 同步、异步

4.3.2.4 HTTPDNS调度设计

  客户端嵌入了SDK, 在客户端HTTPDNS服务端可以根据手机的国家、省市地点、运营商、选择最佳的服务节点

4.4 DNS劫持和DNS污染

总感觉好像DNS劫持和DNS污染是差不多的

4.4.1 DNS劫持

  DNS劫持是指用户访问一个被标记的地址时, DNS服务器故意将此地址指向一个错误的IP地址的行为

4.4.2 DNS污染

  用户访问一个地址, 国内的服务器监控到用户访问的已经被标记地址时, 服务器伪装成DNS服务器向用户发回错误的地址的行为. 范例: 访问YouTube、Facebook等网站出现的状况

五、状态码

状态码	描述
2xx	成功
3xx	重定向
4xx	客户端错误
5xx	服务器错误

5.1 状态码301与302

5.1.1 重定向概念

  Redirect重定向的定义通常指的是 域名跳转, 是指当使用者浏览某个网址时, 将他导向另外一个网址的技术.
  举例 重定向网址指的是当你进入A.com网址时, 它会自动跳转到B.com网址.

5.1.2 重定向出现的原因

• 1、原始URL已不存在
• 2、原始网站/网页已经删除
• 3、网站从www转成non-www
• 4、在特定期间想要自动跳转到活动页面
• 5、网站正在进行维护
• 6、网站进行A/B交叉测试
• 7、从旧网站迁移至新网站

5.1.3 301demo

• 1、重定向(301/302 Redirect)单个页面

Redirect 301/302 /new.PHP https://example.com/new.html
表示将https://example.com/new.php使用301/302跳转方式转至https://example.com/new.html

• 2、重定向(301/302 Redirect)整个网站/域名到另一个新的网站/域名

Redirect 301/302 / https://newsite.com/
将目前域名/网站通过301/302跳转方式转移至/subfolder/这个子目录当中

5.1.4 301与302的区别

• 1、301是指 永久重定向 意味着将A域名的所有权重全部转移给B域名, 因此当你使用301Redirect重定向时, 不仅是网址的跳转, 还包括: 网址排名、PageRank页面权重、流量
• 2、302是指 临时重定向, 不会将A域名的所有权重全数转移给B域名, 因此当你使用302Redirect重定向时, 仅仅是网址的暂时跳转, 并不会转移所有的权重与排名, 仅仅只会转移 流量

5.1.5 301适用场景

如果想要永久将旧网址转移至新网址, 此时就适合使用301 Redirect重定向

5.1.6 302适用场景

例如如果想要在圣诞节建立一个活动页面, 让进入你首页的使用者能够先跳转至活动页面时, 就可以使用302Redirect重定向

六、