物理层：
集线器：
MAC地址：
MAC地址表：
数据链路层：
交换机：
以太网：
网络层：
路由器：
IP地址：
路由器：
子网：
子网掩码：
如何知道谁是路由器：
通过设置网关来确定
所以默认网关，就是a在自己电脑里配置一个ip地址，以便发给不同子网的机器时，发给这个ip地址。
路由表：
arp协议：一个子网下的主机会同时有一个arp表。路由器也有。
A->F
首先A知道自己的IP地址，知道自己的MAC地址，以及知道F的IP地址。它先将数据包发给交换机（数据包内容源IP是A源MAC是A，目的IP是F，目的MAC是路由器的端口）。它先将用IP和子网掩码做与运算，发现不在同一个子网，就会将数据包发给默认网关（这里如何将数据包发给默认网关的呢？是因为通过ARP表查找到了默认网关的MAC地址，而交换机收到报文后因为MAC表发现MAC地址是从端口X出去的。所以MAC地址是默认网关的MAC地址，交换机是没有MAC地址的。这里对于交换机来说，收到A的数据包后，看了MAC地址是路由器的，就将数据包转发给路由器。所以它只有根据MAC地址转发功能，有MAC地址表。在路由器收到数据包后查看自己路由表，发现目的IP地址不存在，也不属于某一个子网，则会将数据包发送给自己的默认路由！！错的！！！路由器1在收到了数据包后，发现对应的下一跳是192.168.100.5，然后根据子网掩码做与运算。结果和192.168.100.0/24对应，匹配到2端口，于是将数据封装到数据链路层，最后把包从2号口发出去。 路由器2。在路由器2收到数据包后，查看路由表，发现是自己端口下某个子网，就查看ARP缓存，找到其MAC地址，将其封装在数据链路层头部，就将数据包从端口发出去。交换机收到数据包后，查看自己的ARP表！！！错的！！！（交换机没有arp表，只能是简单的根据MAC表转发），发现存在IP与MAC地址的对应关系是，FIP对应到MAC地址FFFF。就将数据包从6转发出去。这样F就收到了来自A发送的数据包。这样有个也知道了A的IP和目的MAC地址，就能通信了。
总结：
交换机的功能：
存有MAC表，能根据MAC地址与端口的对应关系，将数据包转发。倘若没有对应关系就会将数据包从所有端口全部转发出去。与交换机相连的设备都有ARP表（包括路由器，包括主机）
路由器的功能：
能够连接不同的子网，实现不同子网间的通信，每个端口都有一个MAC地址。有一张路由表，里面包含了ip地址/子网掩码。下一跳地址，以及端口。
带宽是指：网速，单位是Kbps。
CDN：
使用CDN会极大简化网站的系统维护工作量，网站维护人员只需将网站内容注入CDN的系统，通过CDN部署在各个物理位置的服务器进行全网分发，就可以实现跨运营商、跨地域的用户覆盖
CDN技术概述：
CDN（content-disrtibution-network）内容分发网络，具体的功能是将内容靠近用户，降低用户的访问延迟，减少源站的压力。
具体的实现原理：
关键技术
- 缓存算法
- 分发能力
- 负载均衡
- 基于DNS
- 支持协议
缓存算法决定命中率、源服务器压力、POP节点存储能力
分发能力取决于IDC能力和IDC策略性分布
负载均衡（智能调度）决定最佳路由、响应时间、可用性、服务质量
基于DNS的负载均衡以CNAME实现[to cluster]，智取最优节点服务，
缓存点有客户端浏览器缓存、本地DNS服务器缓存
缓存内容有DNS地址缓存、客户请求内容缓存、动态内容缓存
支持协议如静动态加速（图片加速、https带证书加速）、下载加速、流媒体加速、企业应用加速、手机应用加速
正向代理：客户使用代理访问多个外部服务器，而这种代理方式是代理多个客户访问内部服务器，因此也被称为反向代理模式。
DNS递归查询。DNS迭代查询
递归解析，是默认的解析方式，当主机向本地服务器发起请求后，如果本地服务器没有记录，就会代替主机进行全球查询。
迭代解析，是指当主机向本地服务器发起请求后，如果本地服务器没有记录，就会自己向根服务、顶级服务器、权威服务器一级级发起查询。
DNS系统本身是具备简单负载分配能力的，这是基于DNS的轮询机制。如果有多台Web服务器（多源）同时为站点 abc.com提供服务，abc.com的权威服务器可能会解析出一个或多个IP地址。权威域名服务器还可以调整响应中IP地址的排列方式，即在每次响应 中将不同的IP地址置于首位（取决于可服务能力和服务质量），通过这种方式实现对这些Web服务器的负载均衡
通过CNAME方式实现负载均衡：域名服务器获得CNAME记录后，就会用记录中的别名来替换查找的域名或主机名（实现多个域名->服务器映射）。后面会查询这个别名的A记录来获取相应的IP地址。
具体操作为：先将GSLB的主机名定义为所查询域名的权威DNS服务器的别名，然后将GSLB主机名添加多条A记录，分别对应多个服务器的IP地址。这样，本地DNS服务器会向客户端返回多个IP地址作为域名的查询结果，并且这些IP地址的排列顺序是轮换的。客户端一般会选择首个IP地址进行访问
负载均衡作为代理DNS服务器：负载均衡器被注册为一个域名空间的权威DNS服务器，而真正的权威域名服务器则部署在负 载均衡器后面。所有的DNS请求都会先到达负载均衡器，由负载均衡器转发到真正的权威DNS服务器，然后修改权威DNS服务器返回的响应信息。真正的权威 DNS服务器正常响应浏览器的DNS请求，返回域名解析结果列表，这个响应会先发送到负载均衡器，而负载均衡器会根据自己的策略选择一个性能最好的服务器 IP并修改需要实现GSLB的域名的DNS查询响应，对其他请求透明转发，这样就不会影响整个域名空间的解析性能。
在基于DNS方式下无论采用何 种工作方式，都会有一些请求不会到达GSLB，这是DNS系统本身的缓存机制在起作用。当用户请求的域名在本地DNS或本机（客户端浏览器）得到了解析结 果，这些请求就不会达到GSLB。Cache更新时间越短，用户请求达到GSLB的几率越大。由于DNS的缓存机制屏蔽掉相当一部分用户请求，从而大大减 轻了GSLB处理压力，使得系统抗流量冲击能力显著提升，这也是很多商业CDN选择DNS机制做全局负载均衡的原因之一。但弊端在于，如果在DNS缓存刷 新间隔之内系统发生影响用户服务的变化，比如某个节点故障，某个链路拥塞等，用户依然会被调度到故障部位去
智能DNS功能，它在向本地DNS返回应答之前会先根据一些静态或动态策略进行智能计算。
– 服务器的“健康状况”
– 地理区域距离
– 会话保持
– 响应时间
– IP地址权重
– 会话能力阈值
– 往返时间（TTL）
– 其他信息，包括服务器当前可用会话数、最少选择次数、轮询等
在有些CDN中（用于视频网站加速的情况较多），网站需要加速的内容全部先缓存在OCS（内容中心），然后再将一部分 （通常是热门的内容）分发到个POP节点（Cache边缘集群），所以POP节点在某些时候会出现本地不命中而需要回OCS取内容或者从其他POP节点取 内容的情况
纯粹基于DNS方式的GSLB只能完成就近性判断。为实现智能调度，大多数解决方案需要在GSLB设备附近以旁路的方式 部署一台辅助设备（为方便描述，我们可称之为GRM——全局资源管理设备），用以实现和各POP节点的本地资源管理设备进行通信，完成CDN对各POP节 点的状态检查，并根据POP节点的状态和流量情况，重新制订用户调度策略，将策略实时发送到GSLB中去执行
流媒体CDN系统的组成：
而互联网视频网站（点播/直播）则多倾向于使用HTTP streaming的流化技术。
HTTP streaming前身是progressive download（渐进式下载：边下载边播放，直到下载完）。HTTP streaming首先会将视频数据（包括直播的视频流和点播的视频文件）在服务器上进行编码，然后将编码后的数据进行更细粒度的分片，再把每个分片通过 HTTP协议传输到客户端。HTTP streaming的客户端需要对视频文件的每个分片都发出一个HTTP请求，这样，在视频播放速度低于下载速度的情况下，客户端可以灵活控制HTTP请 求的发出速度，从而保证用户在中途退出时不会出现下载浪费。另外，因为采用分片的特点，HTTP streaming还可以实现媒体播放过程中的码率切换（码率自适应），结合网络带宽资源，为用户提供更好的体验。
流媒体加速的回源要求：因为流媒体文件传送带宽需求高，而且往往需要维持TCP长连接，所以一旦CDN回源比例过高，源 站服务器I/O将不堪负荷。CDN对内容采取分发方式分为pull和push两种。Pull是被动下拉的方式，push是主动推送的方式。对于流媒体内 容，系统一般会选择对热点内容采取push方式的预分发，而普通的网页内容几乎100%是pull方式的。
在流媒体CDN系统中，用户访问的调度会更多考虑内容命中，主要是因为流媒体内容文件体积大，业务质量要求高，如果从其 他节点拉内容再向用户提供服务会带来额外的延迟，影响用户体验。为进一步提高命中率，流媒体CDN系统普遍采用了对热点内容实施预先push的内容分发策 略
在流媒体服务系统中，主要关注的技术是对不同流媒体协议、不同编码格式、不同播放器、不同业务质量要求等的适应。
对使用CDN服务的SP来说，CDN的作用在于尽量就近为用户提供服务，帮助SP解决长距离IP传输和跨域传输带来的种 种业务质量问题（通过空间换取时间）。因此，为用户提供服务的Cache设备一定部署在离用户比较近的地方。另一方面，CDN的建设者从成本角度考虑，又 不能把所有内容都存放在这些离用户最近的节点中，这会消耗大量存储成本，所以这些提供服务的Cache设备会根据需要从源站服务器或者其他Cache获取 内容。这样就形成了CDN网络分层部署的概念。
从网络分层上看，Web CDN通常是两级架构（也有三级架构以减少回源），即中心-边缘。而流媒体CDN通常有三级以上架构，即中心-区域-边缘。产生这种区别的原因在于流媒体 回源成本比较高，源站服务器响应一次流媒体内容回源请求，要比Web内容回源消耗更多资源。尤其对于流媒体直播业务来说，只要直播节目没结束，服务器就需 要长时间持续吐流，如果没有第二层节点作为中继，那么中心节点的压力将是不可想象的。
动态内容加速服务的实现：
随着Web2.0的兴起，产生了动态网页、个性化内容、电子交易数据等内容的加速，这些就涉及了动态内容加速技术。
Web系统由表现层、业务逻辑层、数据访问层+用户数据层
表现层是Web系统与外部系统的交互界面，这一层通常由HTTP服务器组成，负责接收用户端的HTTP内容访问请求，从文件系统中读取静态文件
业务逻辑层负责处理所有业务逻辑和动态内容的生成
数据访问层位于系统的后端，负责管理Web系统的主要信息和数据存储，通常由数据库服务器和存储设备组成
用户数据层负责存储用户信息数据和关联关系，内容来自用户提供和用户行为分析结果
Web网站借助CDN技术能够获得更好的扩展性和高性能，核心在于CDN采用的缓存（caching）和复制（replication）机制，其中缓存是将最近经常被访问的源服务器拥有的内容复制到边缘服务器上，可被视为具有特定策略的复制。
CDN的复制机制是指将源Web系统逻辑架构的各个层次的相应功用复制到边缘服务器上实现，以缓解源系统的处理压力。
– Web系统表现层的复制，就是静态内容的复制。边缘服务器又被称为代理服务器，通过反向代理加速静态文件的交付
– Web系统业务逻辑层的复制。CDN被用于改进动态生成内容的交付性能。即将应用程序和业务组件直接在CDN的边缘服务器中计算，从而直接在靠近用户的地方生成动态Web内容
– – Akamai边缘计算部署模型
– Web系统数据访问层复制。CDN边缘服务器能够具备生成动态内容和掌管内容生成数据的能力
– Web系统用户文件的复制。
（应用加速技术实际上是传统的网络负载均衡的升级和扩展，综合使用了负载均衡（智能调度）、TCP优化管理（TCP keep-alive connection，更激进的TCP窗口策略，基于HTTP1.1），链接管理（routing）、SSL VPN、压缩优化（代码压缩，图片压缩）、智能网络地址（NAT-公私网IP转换）、高级路由、智能端口镜像等技术。）
TCP的问题
– TCP窗口大小的限制（TCP窗口大小随传输成功而变大，而一旦发生传输失败，其窗口大小会立即缩小）
– TCP协议慢启动（三握手）和拥塞控制
CDN实现原理：
在描述CDN的实现原理，让我们先看传统的未加缓存服务的访问过程，以便了解CDN缓存访问方式与未加缓存访问方式的差别：
用户提交域名→浏览器对域名进行解释→得到目的主机的IP地址→根据IP地址访问发出请求→得到请求数据并回复
由上可见，用户访问未使用CDN缓存网站的过程为:
1)、用户向浏览器提供要访问的域名；
2)、浏览器调用域名解析函数库对域名进行解析，以得到此域名对应的IP地址；
3)、浏览器使用所得到的IP地址，向域名的服务主机发出数据访问请求；
4)、浏览器根据域名主机返回的数据显示网页的内容。
通过以上四个步骤，浏览器完成从用户处接收用户要访问的域名到从域名服务主机处获取数据的整个过程。CDN网络是在 用户和服务器之间增加Cache层，如何将用户的请求引导到Cache上获得源服务器的数据，主要是通过接管DNS实现，下面让我们看看访问使用CDN缓 存后的网站的过程：
通过上图，我们可以了解到，使用了CDN缓存后的网站的访问过程变为：
1)、用户向浏览器提供要访问的域名；
2)、浏览器调用域名解析库对域名进行解析，由于CDN对域名解析过程进行了调整，所以解析函数库一般得到的是该域 名对应的CNAME记录，为了得到实际IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址；在此过程中，使用的全局负载均衡 DNS解析，如根据地理位置信息解析对应的IP地址，使得用户能就近访问。
3)、此次解析得到CDN缓存服务器的IP地址，浏览器在得到实际的IP地址以后，向缓存服务器发出访问请求；
4)、缓存服务器根据浏览器提供的要访问的域名，通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交访问请求；
5)、缓存服务器从实际IP地址得得到内容以后，一方面在本地进行保存，以备以后使用，另一方面把获取的数据返回给客户端，完成数据服务过程；
6)、客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程。
通过以上的分析我们可以得到，为了实现既要对普通用户透明(即加入缓存以后用户客户端无需进行任何设置，直接使用被 加速网站原有的域名即可访问，又要在为指定的网站提供加速服务的同时降低对ICP的影响，只要修改整个访问过程中的域名解析部分，以实现透明的加速服务， 下面是CDN网络实现的具体操作过程。
1)、作为ICP，只需要把域名解释权交给CDN运营商，其他方面不需要进行任何的修改；操作时，ICP修改自己域名的解析记录，一般用cname方式指向CDN网络Cache服务器的地址。
2)、作为CDN运营商，首先需要为ICP的域名提供公开的解析，为了实现sortlist，一般是把ICP的域名解释结果指向一个CNAME记录；
3)、当需要进行sortlist时，CDN运营商可以利用DNS对CNAME指向的域名解析过程进行特殊处理，使DNS服务器在接收到客户端请求时可以根据客户端的IP地址，返回相同域名的不同IP地址；
4)、由于从cname获得的IP地址，并且带有hostname信息，请求到达Cache之后，Cache必须知道源服务器的IP地址，所以在CDN运营商内部维护一个内部DNS服务器，用于解释用户所访问的域名的真实IP地址；
5)、在维护内部DNS服务器时，还需要维护一台授权服务器，控制哪些域名可以进行缓存，而哪些又不进行缓存，以免发生开放代理的情况。
若有收获，就点个赞吧
0 人点赞
