OSI,TCP/IP, 五层协议的体系结构
每一层的作用:
物理层: 通过媒介传输比特, 确定机械及电气规范(比特 Bit)
数据链路层: 将比特组装成帧和点到点的传递(帧 Frame)
网络层: 负责数据包从源到宿的传递和网际互连(包 Packet)
传输层: 提供端到端的可靠报文传递和错误恢复(段 Segment)
会话层: 建立, 管理和终止会话(会话协议数据单元 SPDU)
表示层: 对数据进行翻译, 加密和压缩(表示协议数据单元 PPDU)
应用层: 允许访问 OSI 环境的手段(应用协议数据单元 APDU)
每一层的协议:
物理层: RJ45,CLOCK,IEEE802.3 (中继器, 集线器, 网关)
数据链路: PPP,FR,HDLC,VLAN,Mac (网桥, 交换机)
网络层: IP,ICMP,ARP,RARP,OSPF,IPX,RIP,IGRP, (路由器)
传输层: TCP,UDP,SPX
会话层: NFS,SQL,NETBIOS,RPC
表示层: JPEG,MPEG,ASII
应用层: FTP,DNS,Telnet,SMTP,HTTP,WWW,NFS
TCP 对应的应用层协议
FTP: 定义了文件传输协议, 使用 21 端口. 常说某某计算机开了 FTP 服务便是启动了文件传输服务. 下载文件, 上传主页, 都要用到 FTP 服务.
Telnet: 它是一种用于远程登陆的端口, 用户可以以自己的身份远程连接到计算机上, 通过这种端口可以提供一种基于 DOS 模式下的通信服务. 如以前的 BBS 是 - 纯字符界面的, 支持 BBS 的服务器将 23 端口打开, 对外提供服务.
SMTP: 定义了简单邮件传送协议, 现在很多邮件服务器都用的是这个协议, 用于发送邮件. 如常见的免费邮件服务中用的就是这个邮件服务端口, 所以在电子邮件设置 - 中常看到有这么 SMTP 端口设置这个栏, 服务器开放的是 25 号端口.
POP3: 它是和 SMTP 对应, POP3 用于接收邮件. 通常情况下, POP3 协议所用的是 110 端口. 也是说, 只要你有相应的使用 POP3 协议的程序(例如 Fo-xmail 或 Outlook), 就可以不以 web 方式登陆进邮箱界面, 直接用邮件程序就可以收到邮件(如是 163 邮箱就没有必要先进入网易网站, 再进入自己的邮 - 箱来收信).
HTTP: 从 Web 服务器传输超文本到本地浏览器的传送协议.
UDP 对应的应用层协议
DNS: 用于域名解析服务, 将域名地址转换为 IP 地址. DNS 用的是 53 号端口.
SNMP: 简单网络管理协议, 使用 161 号端口, 是用来管理网络设备的. 由于网络设备很多, 无连接的服务就体现出其优势.
TFTP(Trival File Transfer Protocal): 简单文件传输协议, 该协议在熟知端口 69 上使用 UDP 服务.
IP 地址的分类
A 类地址: 以 0 开头, 第一个字节范围: 0~127(1.0.0.0 - 126.255.255.255);
B 类地址: 以 10 开头, 第一个字节范围: 128~191(128.0.0.0 - 191.255.255.255);
C 类地址: 以 110 开头, 第一个字节范围: 192~223(192.0.0.0 - 223.255.255.255);
10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, 192.168.0.0-192.168.255.255.(Internet 上保留地址用于内部)
ARP 协议
ARP 地址解析协议, 简单说就是, 在 IP 以太网中, 当一个上层协议要发包时, 有了该节点的 IP 地址, ARP 就能提供该节点的 Mac 地址. 它的工作原理如下:
首先, 每个主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表, 以表示 IP 地址和 Mac 地址之间的对应关系.
当源主机要发送数据时, 首先检查 ARP 列表中是否有对应 IP 地址的目的主机的 Mac 地址, 如果有, 则直接发送数据, 如果没有, 就向本网段的所有主机发送 ARP 数据包, 该数据包包括的内容有: 源主机 IP 地址, 源主机 Mac 地址, 目的主机的 IP 地址.
当本网络的所有主机收到该 ARP 数据包时, 首先检查数据包中的 IP 地址是否是自己的 IP 地址, 如果不是, 则忽略该数据包, 如果是, 则首先从数据包中取出源主机的 IP 和 Mac 地址写入到 ARP 列表中, 如果已经存在, 则覆盖, 然后将自己的 Mac 地址写入 ARP 响应包中, 告诉源主机自己是它想要找的 Mac 地址.
源主机收到 ARP 响应包后. 将目的主机的 IP 和 Mac 地址写入 ARP 列表, 并利用此信息发送数据. 如果源主机一直没有收到 ARP 响应数据包, 表示 ARP 查询失败.
如果目标 IP 与自己不在同一个网段, 这种情况需要将包发给默认网关, 所以主要获取网关的 Mac 地址. 如果 arp 高速缓存有默认网关的 Mac 地址, 直接发送 IP 数据报道默认网关, 再由网关转发到外网; 如果 arp 高速缓存没有默认网关的 Mac 地址, 还是发送 ARP 广播请求默认网关的 Mac 地址, 缓存该地址, 并且发送数据报到网关.
HTTP 协议
HTTP 是一个属于应用层的面向对象的协议, 由于其简捷, 快速的方式, 适用于分布式超媒体信息系统. HTTP 协议的主要特点可概括如下:
支持客户 / 服务器模式.
简单快速: 客户向服务器请求服务时, 只需传送请求方法和路径. 请求方法常用的有 GET,HEAD,POST. 每种方法规定了客户与服务器联系的类型不同. 由于 HTTP 协议简单, 使得 HTTP 服务器的程序规模小, 因而通信速度很快.
灵活: HTTP 允许传输任意类型的数据对象. 正在传输的类型由 Content-Type 加以标记.
无连接: 无连接的含义是限制每次连接只处理一个请求. 服务器处理完客户的请求, 并收到客户的应答后, 即断开连接. 采用这种方式可以节省传输时间.
无状态: HTTP 协议是无状态协议. 无状态是指协议对于事务处理没有记忆能力. 缺少状态意味着如果后续处理需要前面的信息, 则它必须重传, 这样可能导致每次连接传送的数据量增大. 另一方面, 在服务器不需要先前信息时它的应答就较快.
TCP 三次握手和四次挥手的全过程
三次握手:(我要和你建立链接, 你真的要和我建立链接么, 我真的要和你建立链接, 成功)
第一次握手: 客户端发送 syn 包 (syn=x) 到服务器, 并进入 SYN_SEND 状态, 等待服务器确认;
第二次握手: 服务器收到 syn 包, 必须确认客户的 SYN(ack=x+1), 同时自己也发送一个 SYN 包(syn=y), 即 SYN+ACK 包, 此时服务器进入 SYN_RECV 状态;
第三次握手: 客户端收到服务器的 SYN+ACK 包, 向服务器发送确认包 ACK(ack=y+1), 此包发送完毕, 客户端和服务器进入 ESTABLISHED 状态, 完成三次握手.
握手过程中传送的包里不包含数据, 三次握手完毕后, 客户端与服务器才正式开始传送数据. 理想状态下, TCP 连接一旦建立, 在通信双方中的任何一方主动关闭连接之前, TCP 连接都将被一直保持下去.
四次挥手:(我要和你断开链接; 好的, 断吧. 我也要和你断开链接; 好的, 断吧):
第一次挥手: 客户端主动关闭方发送一个 FIN, 用来关闭客户端到服务端的数据传送, 也就是客户端告诉服务端: 我已经不会再给你发数据了(当然, 在 fin 包之前发送出去的数据, 如果没有收到对应的 ack 确认报文, 客户端依然会重发这些数据), 但是, 此时客户端还可以接受数据.
第二次挥手: 服务端收到 FIN 包后, 发送一个 ACK 给客户端, 确认序号为收到序号 + 1(与 SYN 相同, 一个 FIN 占用一个序号).
第三次挥手: 服务端发送一个 FIN, 用来关闭服务端到客户端的数据传送, 也就是告诉客户端, 我的数据也发送完了, 不会再给你发数据了.
第四次挥手: 客户端收到 FIN 后, 发送一个 ACK 给服务端, 确认序号为收到序号 + 1, 至此, 完成四次挥手.
第 3 次握手失败会怎么办?
第三次失败, 只有客户端处于成功状态(因为第 2 次服务器返回了 ACK), 服务器端没有接收到客户端的 ACK. 这要分几种情况讨论:
In other words, if the ACK is dropped but the next packet is not dropped, then everything is fine. 也就是说客户端发出的 ACK 丢失了, 发出的 下一个数据包 没有丢失, 则服务端接收到下一个数据包(这个数据包里也会带上 ACK 信息), 能够进入正常的 ESTABLISHED 状态
如果服务端和客户端都没有数据发送, 或者服务端想发送数据(但是发不了, 因为没有收到客户端的 ACK), 服务器都会有定时器发送第二步 SYN+ACK 数据包, 如果客户端再次发送 ACK 成功, 建立连接.
如果一直不成功, 服务器肯定会有超时设置, 超时之后会给客户端发 RTS 报文, 进入 CLOSED 状态, 防止 SYN 洪泛攻击.
为什么 TCP 链接需要三次握手, 两次不可以么, 为什么?
为了防止已失效的链接请求报文突然又传送到了服务端, 因而产生错误. 客户端发出的连接请求报文并未丢失, 而是在某个网络节点长时间滞留了, 以致延误到链接释放以后的某个时间才到达 Server. 这是, Server 误以为这是 Client 发出的一个新的链接请求, 于是就向客户端发送确认数据包, 同意建立链接. 若不采用 "三次握手", 那么只要 Server 发出确认数据包, 新的链接就建立了. 由于 client 此时并未发出建立链接的请求, 所以其不会理睬 Server 的确认, 也不与 Server 通信; 而这时 Server 一直在等待 Client 的请求, 这样 Server 就白白浪费了一定的资源. 若采用 "三次握手", 在这种情况下, 由于 Server 端没有收到来自客户端的确认, 则就会知道 Client 并没有要求建立请求, 就不会建立链接.
为什么连接的时候是三次握手, 关闭的时候却是四次握手?
TCP 是全双工模式, 关闭连接时, 当主机 B 收到主机 A 的 FIN 报文时, 仅仅表示主机 A 不再发送数据了但是还能接收数据. 此时, 主机 B 也未必全部数据都发送给 A 了, 所以 B 可以立即 close; 也可以发送一些数据给 A 后, 再发送 FIN 报文给对方来表示同意现在关闭连接, 因此, 主机 BACK 和 FIN 一般都会分开发送.
TCP 的拥塞处理
计算机网络中的带宽, 交换结点中的缓存及处理机等都是网络的资源. 在某段时间, 若对网络中某一资源的需求超过了该资源所能提供的可用部分, 网络的性能就会变坏, 这种情况就叫做拥塞. 拥塞控制就是防止过多的数据注入网络中, 这样可以使网络中的路由器或链路不致过载. 注意, 拥塞控制和流量控制不同, 前者是一个全局性的过程, 而后者指点对点通信量的控制. 拥塞控制的方法主要有以下四种:
慢启动: 不要一开始就发送大量的数据, 先探测一下网络的拥塞程度, 也就是说由小到大逐渐增加拥塞窗口的大小;
拥塞避免: 拥塞避免算法让拥塞窗口缓慢增长, 即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1, 而不是加倍, 这样拥塞窗口按线性规律缓慢增长.
快重传: 快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认 (为的是使发送方及早知道有报文段没有到达对方) 而不要等到自己发送数据时捎带确认. 快重传算法规定, 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段, 而不必继续等待设置的重传计时器时间到期.
快恢复: 快重传配合使用的还有快恢复算法, 当发送方连续收到三个重复确认时, 就执行 "乘法减小" 算法, 把 ssthresh 门限减半, 但是接下去并不执行慢开始算法: 因为如果网络出现拥塞的话就不会收到好几个重复的确认, 所以发送方现在认为网络可能没有出现拥塞. 所以此时不执行慢开始算法, 而是将 cwnd 设置为 ssthresh 的大小, 然后执行拥塞避免算法.
TCP 协议如何来保证传输的可靠性
TCP 提供一种面向连接的, 可靠的字节流服务. 其中, 面向连接意味着两个使用 TCP 的应用 (通常是一个客户和一个服务器) 在彼此交换数据之前必须先建立一个 TCP 连接. 在一个 TCP 连接中, 仅有两方进行彼此通信; 而字节流服务意味着两个应用程序通过 TCP 链接交换 8bit 字节构成的字节流, TCP 不在字节流中插入记录标识符. 对于可靠性, TCP 通过以下方式进行保证:
数据包校验: 目的是检测数据在传输过程中的任何变化, 若校验出包有错, 则丢弃报文段并且不给出响应, 这时 TCP 发送数据端超时后会重发数据;
对失序数据包重排序: 既然 TCP 报文段作为 IP 数据报来传输, 而 IP 数据报的到达可能会失序, 因此 TCP 报文段的到达也可能会失序. TCP 将对失序数据进行重新排序, 然后才交给应用层;
丢弃重复数据: 对于重复数据, 能够丢弃重复数据;
应答机制: 当 TCP 收到发自 TCP 连接另一端的数据, 它将发送一个确认. 这个确认不是立即发送, 通常将推迟几分之一秒;
超时重发: 当 TCP 发出一个段后, 它启动一个定时器, 等待目的端确认收到这个报文段. 如果不能及时收到一个确认, 将重发这个报文段;
流量控制: TCP 连接的每一方都有固定大小的缓冲空间. TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据, 这可以防止较快主机致使较慢主机的缓冲区溢出, 这就是流量控制. TCP 使用的流量控制协议是可变大小的滑动窗口协议.
从输入网址到获得页面的过程
浏览器查询 DNS, 获取域名对应的 IP 地址: 具体过程包括浏览器搜索自身的 DNS 缓存, 搜索操作系统的 DNS 缓存, 读取本地的 Host 文件和向本地 DNS 服务器进行查询等. 对于向本地 DNS 服务器进行查询, 如果要查询的域名包含在本地配置区域资源中, 则返回解析结果给客户机, 完成域名解析(此解析具有权威性); 如果要查询的域名不由本地 DNS 服务器区域解析, 但该服务器已缓存了此网址映射关系, 则调用这个 IP 地址映射, 完成域名解析(此解析不具有权威性). 如果本地域名服务器并未缓存该网址映射关系, 那么将根据其设置发起递归查询或者迭代查询;
浏览器获得域名对应的 IP 地址以后, 浏览器向服务器请求建立链接, 发起三次握手;
TCP/IP 链接建立起来后, 浏览器向服务器发送 HTTP 请求;
服务器接收到这个请求, 并根据路径参数映射到特定的请求处理器进行处理, 并将处理结果及相应的视图返回给浏览器;
浏览器解析并渲染视图, 若遇到对 JS 文件, CSS 文件及图片等静态资源的引用, 则重复上述步骤并向服务器请求这些资源;
浏览器根据其请求到的资源, 数据渲染页面, 最终向用户呈现一个完整的页面.
Session 与 Cookie 的对比
实现机制: Session 的实现常常依赖于 Cookie 机制, 通过 Cookie 机制回传 SessionID; 大小限制: Cookie 有大小限制并且浏览器对每个站点也有 cookie 的个数限制, Session 没有大小限制, 理论上只与服务器的内存大小有关; 安全性: Cookie 存在安全隐患, 通过拦截或本地文件找得到 cookie 后可以进行攻击, 而 Session 由于保存在服务器端, 相对更加安全; 服务器资源消耗: Session 是保存在服务器端上会存在一段时间才会消失, 如果 session 过多会增加服务器的压力. Application(ServletContext): 与一个 Web 应用程序相对应, 为应用程序提供了一个全局的状态, 所有客户都可以使用该状态.
交换机和路由器分别的实现原理是什么? 分别在哪个层次上面实现的?
交换机用于局域网, 利用主机的 Mac 地址进行数据传输, 而不需要关心 IP 数据包中的 IP 地址, 它工作于数据链路层. 路由器识别网络是通过 IP 数据包中 IP 地址的网络号进行的, 所以为了保证数据包路由的正确性, 每个网络都必须有一个唯一的网络号. 路由器通过 IP 数据包的 IP 地址进行路由的(将数据包递交给哪个下一跳路由器). 路由器工作于网络层. 由于设备现在的发展, 现在很多设备既具有交换又具有路由功能, 两者的界限越来越模糊.
TCP 和 UDP 的区别
TCP 的优点: 可靠, 稳定 TCP 的可靠体现在 TCP 在传递数据之前, 会有三次握手来建立连接, 而且在数据传递时, 有确认, 窗口, 重传, 拥塞控制机制, 在数据传完后, 还会断开连接用来节约系统资源. TCP 的缺点: 慢, 效率低, 占用系统资源高, 易被攻击 TCP 在传递数据之前, 要先建连接, 这会消耗时间, 而且在数据传递时, 确认机制, 重传机制, 拥塞控制机制等都会消耗大量的时间, 而且要在每台设备上维护所有的传输连接, 事实上, 每个连接都会占用系统的 CPU, 内存等硬件资源. 而且, 因为 TCP 有确认机制, 三次握手机制, 这些也导致 TCP 容易被人利用, 实现 DOS,DDOS,CC 等攻击.
UDP 的优点: 快, 比 TCP 稍安全 UDP 没有 TCP 的握手, 确认, 窗口, 重传, 拥塞控制等机制, UDP 是一个无状态的传输协议, 所以它在传递数据时非常快. 没有 TCP 的这些机制, UDP 较 TCP 被攻击者利用的漏洞就要少一些. 但 UDP 也是无法避免攻击的, 比如: UDP Flood 攻击...... UDP 的缺点: 不可靠, 不稳定 因为 UDP 没有 TCP 那些可靠的机制, 在数据传递时, 如果网络质量不好, 就会很容易丢包. 基于上面的优缺点, 那么: 什么时候应该使用 TCP: 当对网络通讯质量有要求的时候, 比如: 整个数据要准确无误的传递给对方, 这往往用于一些要求可靠的应用, 比如 HTTP,HTTPS,FTP 等传输文件的协议, POP,SMTP 等邮件传输的协议. 在日常生活中, 常见使用 TCP 协议的应用如下: 浏览器, 用的 HTTP FlashFXP, 用的 FTP Outlook, 用的 POP,SMTP Putty, 用的 Telnet,SSH QQ 文件传输 ............ 什么时候应该使用 UDP: 当对网络通讯质量要求不高的时候, 要求网络通讯速度能尽量的快, 这时就可以使用 UDP. 比如, 日常生活中, 常见使用 UDP 协议的应用如下: QQ 语音 QQ 视频 TFTP ...... 有些应用场景对可靠性要求不高会用到 UPD, 比如长视频, 要求速率
TCP | UDP | |
---|---|---|
连接 | 面向连接 | 面向无连接 |
可靠性 | 可靠,无差错,不丢失,不重复 | 尽最大努力交付,即不保证可靠交付 |
模式 | 流模式(字节流) | 数据报模式(报文) |
连接 | 点到点 | 支持一对一,一对多,多对一和多对多的交互通信 |
首部开销 | 20 字节 | 8 个字节 |
逻辑通信信道 | 全双工的可靠信道 | 不可靠信道 |
速度 | 慢 | 快 |
对系统资源要求 | 较多 | 较少 |
HTTP 和 HTTPS
HTTP: 是互联网上应用最为广泛的一种网络协议, 是一个客户端和服务器端请求和应答的标准(TCP), 用于从 WWW 服务器传输超文本到本地浏览器的传输协议, 它可以使浏览器更加高效, 使网络传输减少.
HTTPS: 是以安全为目标的 HTTP 通道, 简单讲是 HTTP 的安全版, 即 HTTP 下加入 SSL 层, HTTPS 的安全基础是 SSL, 因此加密的详细内容就需要 SSL.
HTTPS 协议的主要作用可以分为两种: 一种是建立一个信息安全通道, 来保证数据传输的安全; 另一种就是确认网站的真实性.
Http 和 Https 的区别
Http 协议运行在 TCP 之上, 明文传输, 客户端与服务器端都无法验证对方的身份; Https 是身披 SSL(Secure Socket Layer)外壳的 Http, 运行于 SSL 上, SSL 运行于 TCP 之上, 是添加了加密和认证机制的 HTTP. 二者之间存在如下不同: 端口不同: Http 与 Http 使用不同的连接方式, 用的端口也不一样, 前者是 80, 后者是 443; 资源消耗: 和 HTTP 通信相比, Https 通信会由于加减密处理消耗更多的 CPU 和内存资源; 开销: Https 通信需要证书, 而证书一般需要向认证机构购买; Https 的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制.
HTTPS 采用混合加密机制
由于公有密钥的机制相对复杂, 导致其处理速度相对较慢. 于是 HTTPS 利用了两者的优势, 采用了混合加密的机制. 我们知道, 共享 (对称) 密钥未能解决的问题是如何能够安全地把密钥发送给对方. 只要解决了这个问题就可以进行安全地通信. 于是, HTTPS 首先是通过公有密钥来对共享密钥进行加密传输. 当共享密钥安全地传输给对方后, 双方则使用共享密钥的方式来加密报文, 以此来提高传输的效率.
步骤 1: 向服务器发起请求. 步骤 2-3: 取出公有密钥及证书并发送给客户端. 步骤 4: 客户端判断公有密钥是否有效, 无效则显示警告. 有效则生成一个随机数串, 并以此生成客户端的共享密钥. 步骤 5: 用步骤 3 得到的公有密钥对该随机数串加密, 发送到服务器. 步骤 6: 服务器得到加密报文, 用私有密钥解密报文, 得到随机数串, 并以此生成服务器端的共享密钥. 此时客户端和服务端拥有相同的共享密钥, 可以用该共享密钥进行安全通信. 步骤 7-8: 服务器对响应进行加密, 客户端对报文进行解密.
HTTPS 的优点
尽管 HTTPS 并非绝对安全, 掌握根证书的机构, 掌握加密算法的组织同样可以进行中间人形式的攻击, 但 HTTPS 仍是现行架构下最安全的解决方案, 主要有以下几个好处: (1)使用 HTTPS 协议可认证用户和服务器, 确保数据发送到正确的客户机和服务器; (2)HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输, 身份认证的网络协议, 要比 http 协议安全, 可防止数据在传输过程中不被窃取, 改变, 确保数据的完整性. (3)HTTPS 是现行架构下最安全的解决方案, 虽然不是绝对安全, 但它大幅增加了中间人攻击的成本. (4)谷歌曾在 2014 年 8 月份调整搜索引擎算法, 并称 "比起同等 HTTP 网站, 采用 HTTPS 加密的网站在搜索结果中的排名将会更高".
HTTPS 的缺点
虽然说 HTTPS 有很大的优势, 但其相对来说, 还是存在不足之处的: (1)HTTPS 协议握手阶段比较费时, 会使页面的加载时间延长近 50%, 增加 10% 到 20% 的耗电; (2)HTTPS 连接缓存不如 HTTP 高效, 会增加数据开销和功耗, 甚至已有的安全措施也会因此而受到影响; (3)SSL 证书需要钱, 功能越强大的证书费用越高, 个人网站, 小网站没有必要一般不会用. (4)SSL 证书通常需要绑定 IP, 不能在同一 IP 上绑定多个域名, IPv4 资源不可能支撑这个消耗. (5)HTTPS 协议的加密范围也比较有限, 在黑客攻击, 拒绝服务攻击, 服务器劫持等方面几乎起不到什么作用. 最关键的, SSL 证书的信用链体系并不安全, 特别是在某些国家可以控制 CA 根证书的情况下, 中间人攻击一样可行.
socket
socket 是通信的基石. 支持 TCP/IP 等协议的基本操作单元. 应用层通过传输层进行数据通信时, TCP 会遇到同时为多个应用程序进程提供并发服务的问题. 多个 TCP 连接或多个应用程序进程可能需要通过同一个 TCP 协议端口传输数据. 为了区别不同的应用程序进程和连接, 许多计算机操作系统为应用程序与 TCP/IP 协议交互提供了套接字 (Socket) 接口. 应用层可以和传输层通过 Socket 接口, 区分来自不同应用程序进程或网络连接的通信, 实现数据传输的并发服务.
来源: https://juejin.im/post/5ba9c3b96fb9a05d2567de00