- OSI七层模型和TCP/IP四层模型分别是什么?有什么区别?
- OSI模型
- 应用层:HTTP、SMTP、SNMP、FTP、Telnet、SSH、NFS
- 表示层:SMB、AFP
- 会话层:SSH、RPC、NetBIOS、ASP、Winsock、BSD sockets
- 传输层:TCP、UDP、
- 网络层:IP、ICMP、IGMP、BGP、OSPF、RIP、ARP、RARP
- 数据链路层:以太网、PPP
- 实体层:线路、无线电、光纤
- TCP/IP协议栈模型
- 应用层(OSI5到7层):网络应用程序及它们的应用层协议存留的地方
- 传输层(OSI4层):在应用程序端点之间传送应用层报文(端对端)
- 网络层(OSI3层):将数据报从一台主机移动到另一台主机(主机对主机)
- 接口层(OSI1和2层):通过源和目的地之间的一系列路由器路由数据报(设备对设备)
- 两种模型的区别
- OSI 强调提供很可靠的的数据传输服务,每一层都要进行检测和处理错误。
- TCP/IP认为可靠要由端对端来保证,不要把系统搞得太复杂。传输层利用检验和、确认分组、重传、序号和定时器等手段来保证可靠性控制。
- OSI模型
- 请求报文和响应报文
- 请求报文
- 请求行
- 请求方式
- GET POST PUT HEAD DELETE
- 请求资源路径
- HTTP协议版本
- HTTP/1.1与HTTP/1.0的区别:
- 长连接:HTTP/1.1默认使用长连接
- 带宽优化:HTTP/1.1中在请求消息中新引入了用于带宽优化的头域
- range头域与Content-Range头域:请求消息中如果包含比较大的实体内容,但不确定服务器是否能够接收该请求,它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。 响应100则继续发送整体,响应401则停止发送。
- Accept-Encoding头域与Content-Encoding头域:对消息进行端到端的编码。
- 错误提示:
- HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT这些Request方法。
- HTTP/1.1引入了一个Warning头域,增加对错误或警告信息的描述。
- 在HTTP/1.1中新增了24个状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
- HTTP/1.1与HTTP/1.0的区别:
- 请求方式
- 请求头(首部行)
- Host:(1.1引入)
- If-Modified-Since:如果请求报文中包含此字段,则为条件GET请求报文,用于缓存(响应报文304代码表示缓存未修改)
- Referer:检测来源,防盗链
- User-Agent
- Cookie:在无状态的HTTP之上建立一个用户会话层
- Cache-Control:缓存相关
- Connection:
- 短连接:每个TCP连接只传输一个请求报文和一个响应报文
- 给web服务器带来严重的负担(高并发短连接,TIME_WAIT)
- 安全性好
- 长连接:所有的请求响应经相同的的TCP连接发送
- HTTP1.1的默认模式是使用带流水线的持续连接
- 在一个TCP连接内,多个HTTP请求可以并行,下一个HTTP请求在上一个HTTP请求的应答完成之前就发起
- 节约资源
- 短连接:每个TCP连接只传输一个请求报文和一个响应报文
- Range:允许只获取文件部分内容
- 实体内容
- GET报文:
- 通过URL参数传递的方式提交数据
- 通过"?"区分资源路径和提交的数据
- 参数间用&分隔
- 长度受限
- 安全性低
- 通过URL参数传递的方式提交数据
- POST报文:
- 表单提交
- 长度不受限制
- 不被缓存,安全性高
- GET报文:
- 请求行
- 响应报文
- 响应状态行
- 协议版本
- 状态码
- 301:永久移动
- 302:找到
- 304:缓存未修改(If-Modified-Since,Last-Modified,缓存,条件GET)
- 401:未经授权
- 403:禁止
- 500:服务器错误
- 502:无效网关
- 504:网关超时
- 描述信息
- 响应头
- Server
- Date
- Expires:控制缓存过期时间
- Location
- Accept-Ranges
- Content-*
- Last-Modified
- ETag:最后缓存时间和文件大小的哈希
- Expires:在某时间前,直接使用,不必请求
- Cache-Control:在某时间内,直接使用,不必请求
- Transfer-Encoding
- Set-Cookie
- Connection
- 实体内容
- MIME类型:大类别/具体类型
- 响应状态行
- HTTPS与HTTP协议的区别
- https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
- http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。
- http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
- http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
- SSL、TSL的加密方式是什么?为什么https理论上时间更长,现在怎么优化的?
- 服务器端检查会话标识是否在自己的缓存中
- 描述在浏览器的地址栏键入www.baidu.com后发生了哪些事情?
- DHCP
- 获取IP地址,网关地址,DNS服务器地址
- DNS解析
- 从URL中抽取主机名,并将主机名传给DNS应用的客户端
- DNS查询报文被封装到目的地址为DNS服务器的IP数据报中,通过ARP协议获取网关路由器的MAC地址
- DNS客户向DNS服务器发送包含主机名的请求
- 经过一系列的递归查询或迭代查询,DNS客户最终会收到一份回答报文,其中含有主机名对应的IP地址(有CDN和没有CDN的情况不同,要分别说明,后面CDN部分会针对此做详细说明)
- 建立连接
- TCP三次握手
- 用户可以找到和打开socket文件
- 发起请求
- 浏览器运用socket文件向服务器发起各种请求
- 发送HTTP GET报文
- 应答请求
- 运用HTTP协议把请求传输到服务器
- 任务处理
- 运用HTTP协把处理结果或请求的资源传输到浏览器(响应报文)
- 关闭连接
- SMTP是个推协议,HTTP是个拉协议,所以用户从自己的邮件服务器上收取报文时,需要使用POP3(110)、IMAP()以及HTTP协议
- POP3协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法,不维护用户状态信息
- IMAP解决以上问题
- SMTP要求每个报文用7比特ASCII码格式
- SMTP把所有报文对象放在一个报文中
- 为什么要DNS解析,DNS是什么?
- 人类喜欢便于记忆的主机名标识方式,路由器定长的有层次地IP地址。
- DNS是一个由分层的DNS服务器实现的分布式数据库,一个使得主机能够查询分布式数据库的应用层协议。
- DNS的解析过程,涉及到的文件以及其记录类型
- 递归查询:本地、根、二级......本地
- 迭代查询:本地、根服务器、本地、二级、本地......本地
- 通常来说请求主机到本地DNS服务器的查询是递归的,其余的查询是迭代的
- 记录类型
- CNAME:主机别名比规范主机名更容易记忆,一个IP给许多主机用,只修改CNAME对应的A记录即可,CDN,主机别名,规范主机名,CNAME
- A:主机名,IP,A(权威服务器有)
- MX:邮件服务器别名,规范主机名,MX
- NS:域,能获取该域的主机IP地址的权威DNS服务器的主机名,NS(非权威服务器)
- 如果DNS解析出现错误,解决的思路是什么?
- 本地缓存被污染
- 本地DNS服务器被污染
- 中间人攻击
- 墙
- Anycast 的使用场景
- 大型DNS系统中广泛使用的多点部署、分布式方案,对于提高可用性、提高性能、抵抗DDOS有重要作用。
- CDN(内容分发网络) 技术
- CDN中涉及到的关键技术:
- 缓存算法[Squid]:缓存算法决定命中率、源服务器压力、POP节点存储能力
- 分发能力:分发能力取决于IDC能力和IDC策略性分布
- 负载均衡[Nginx]:负载均衡(智能调度)决定最佳路由、响应时间、可用性、服务质量
- 基于DNS[BIND]:基于DNS的负载均衡以CNAME实现[to
cluster],智取最优节点服务
- 为什么要有CNAME而不是直接返回一个CDN边缘节点的ip?
- 由于CDN对域名解析过程进行了调整,所以解析函数库得到的是该域名对应的CNAME记录(CNAME为CDN服务商域名),为了得到实际IP地址,浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址;
- 在此过程中,使用的全局负载均衡DNS解析,如根据地理位置信息解析对应的IP地址,使得用户能就近访问。
- 为什么要有CNAME而不是直接返回一个CDN边缘节点的ip?
- 支持协议:静动态加速(图片加速、https带证书加速)、下载加速、流媒体加速、企业应用加速、手机应用加速
- CDN系统的通用组成架构
- 分发服务系统:最基本的工作单元就是Cache设备,cache(边缘cache)负责直接响应最终用户的访问请求,把缓存在本地的内容快速地提供给用户。同时cache还负责与源站点进行内容同步,把更新的内容以及本地没有的内容从源站点获取并保存在本地。Cache设备的数量、规模、总服务能力是衡 量一个CDN系统服务能力的最基本的指标
- 负载均衡系统:主要功能是负责对所有发起服务请求的用户进行访问调度,确定提供给用户的最终实际访问地址。两级调度体系分为全局负载均衡(GSLB)和本地负载均衡(SLB)。GSLB主要根据用户就近性原则,通过对每个服务节点进行"最优"判断,确定向用户提供服务的cache的物理位置。SLB主要负责节点内部的设备负载均衡
- 运营管理系统:分为运营管理和网络管理子系统,负责处理业务层面的与外界系统交互所必须的收集、整理、交付工作,包含客户管理、产品管理、计费管理、统计分析等功能。
- 在解析过程中,企业的CDN是怎么起作用的(在解析过程中,如何把请求打到CDN节点上)?
- 使用了CDN缓存后,针对网站的访问过程变为:
- 本地DNS服务器在进行查询的时候,将该DNS请求中继到该域名的权威服务器。权威服务器通过分析二级域名,如video.baidu.com,不直接返回IP地址,而是返回一个对应的CNAME记录,该记录指向公司CDN的DNS权威服务器。
- 用户的本地服务器对获得的CNAME域名进行解析,向CDN的DNS权威服务器发起请求。
- 权威服务器通过在IP库中查询请求IP的地理位置(淘宝使用包裹记录来校准),同时考虑网络成本,流量分布,源站负载等,返回一个最优节点缓存服务器的IP。
- 缓存服务器根据浏览器提供的要访问的域名,通过Cache内部专用DNS解析得到此域名的实际IP地址,再由缓存服务器向此实际IP地址提交访问请求。
- 缓存服务器从实际IP地址得得到内容以后,一方面在本地进行保存,以备以后使用,二方面把获取的数据返回给客户端,完成数据服务过程。
- 获取IP地址,掩码,路由器IP地址,DNS服务器的IP地址
- 实现原理
- 发现:新到主机通过DHCP发现报文,在UDP分组中向端口67发送,使用广播目的地址255.255.255.255,源地址0.0.0.0
- 提供:DHCP服务器通过广播地址能提供的IP信息(地址、掩码、租用期)
- 请求:新到主机从提供报文中选中一个服务器,并响应一个DHCP请求报文,回显配置参数
- ACK:服务器用DHCP ACK报文证实所要求的参数
- 控制连接:长连接
- 以7比特ASCII格式传输
- 数据连接:短连接
- 用户身份
- 实体用户
- 访客
- 匿名用户
- 主动连接
- 防火墙(NAT)问题:使用iptables的ftp模块
- 客户端先发起,告知自己的端口号,连接到服务器21端口,服务器20端口主动连接客户端
- 被动连接
- 客户端发送被动连接标识,服务器21端口号告诉客户端自己使用的数据端口,客户端随即选用大于1024的端口主动连接服务器,
- 安全性
- vsftpd
- 明文传输不安全
- chroot,限定用户的访问目录
- rpc
- showmount
- 防火墙设置:/etc/sysconfig/nfs:设置端口
- 权限:网段
- NFS
- ftp无法直接修改主机上的文件数据,需要客户端
- 共享打印机
- 架构在NetBIOS协议上,适合局域网的共享
- 每台主机有NetBIOS Name
- 权限
- nmbd:管理工作组名称的解析,使用UDP实现137 138端口
- smbd:管理主机共享的目录文件与打印机,利用TCP的139 445
- /etc/samba/smb.conf
- 账号密码放在TDB数据库中user
- 在Linux下,必须是Linux的用户,密码可以不同
- 也可以使用外部服务器的密码domain
- NIS或LDAP来进行账号对应
- PDC服务器
- 让PDC成为整个局域网的域管理员,win主机加入域中,win登陆时会从服务器验证账号密码
- selinux、iptables、hosts allow|deny、
- 挂载
- monut -t cifs
- 如何保证可靠传输?
- 差错检测、确认、重传
- 序号(解决ACK受损的问题,判断是否为重传的):
- 接收端收到冗余分组则丢弃
- 发送端收到冗余ACK则重传
- 定时器
- 如何检验丢包?
- 校验和、确认分组、超时重传、序号
- 如何保证TCP的可靠传输?
- 检验和、重传、积累确认、序号、确认号、定时器
- 三次握手
- 四次挥手
- 流程
- 主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送,也就是主动关闭方告诉被动关闭方:我已经不会再给你发数据了(当然,在fin包之前发送出去的数据,如果没有收到对应的ack确认报文,主动关闭方依然会重发这些数据),但是,此时主动关闭方还可以接受数据。
- 被动关闭方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号)。
- 被动关闭方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我的数据也发送完了,不会再给你发数据了。
- 主动关闭方收到FIN后,发送一个ACK给被动关闭方,确认序号为收到序号+1,至此,完成四次挥手。
- 为什么需要四次挥手,为什么要等2msl再关闭?
- TCP是全双工通信,主动断开方发送FIN并不意味着立即关闭TCP连接,而是告诉对方自己没有更多的数据要发送了,只有当对方发完自己的数据再发送FIN后,才意味着关闭TCP连接;
- 流程
- 字段含义
- 源端口号(16位)
- 目的端口号(16位)
- 序号(32位)
- 确认序号(32位)
- 首部长度(4位)
- 保留(6位)
- URG/ACK/PSH/RST/SYN/FIN(6位)
- 窗口大小(16位)
- 校验和(16位)
- 紧急指针(16位)
- 选项
- 数据
- TIME_WAIT 状态
- TIME_WAIT的作用
- 主动关闭的一方在发送完最后一个ACK后就会进入TIME_WAIT状态,并停留2MSL最大报文生存时间。
- 为了实现 TCP 全双工连接的可靠性关闭,用来重发可能丢失的 ACK报文;
- 为什么需要持续2个MSL(最大报文生存时间)?
- 假设应用程序端口在进入TIME_WAIT后,2个MSL时间内并没有收到FIN,说明应用程序最后发出的ACK已经收到了;否则会在2个MSL内再次收到ACK.。
- TIME_WAIT 次数多了会怎么样?为什么 ?如何缓解?
- 在高并发短连接的TCP服务器上,当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高,此时部分客户端就会显示连接不上。
- 调节系统参数reuse,reclcye,负载均衡
- TIME_WAIT的作用
- 回退N帧协议/滑动窗口
- 滑动窗口怎么实现的(原理)
- 使用的技术包括:校验和、积累确认、序号、超时重传
- 窗口里包含已经发送但尚未收到确认的数据,和允许发送但尚未发送的数据
- 积累确认:表明接收方已经接收到序号及之前的所有分组,只关注最近按序接收的分组
- 不缓存失序分组
- 你觉得这样实现会有什么问题->怎么解决
- 性能问题:单个分组的差错就会引起重传大量分组
- 引入选择重传机制
- 选择重传确认一个只能够正确接收的分组而不管其是否按序
- 选择重传会缓存失序分组
- TCP通常会缓存失序报文,但TCP最多会重传一个报文段,GBN会重传n和它后继的所有分组
- 窗口的大小如何确定
- 发送窗口是根据接收窗口和拥塞窗口的最小值确定的
- 接收窗口根据接收方的缓冲区大小决定
- 拥塞窗口根据慢启动拥塞避免快恢复算法决定
- 滑动窗口怎么实现的(原理)
- 拥塞避免/慢启动/快重传/快速恢复
- 慢启动:
- TCP发送速率起始慢,但在慢启动阶段以指数增长,每过一个往返时间,拥塞窗口的报文段数目翻番。
- 检测到阻塞,将慢启动门限设置为拥塞窗口的1/2,将拥塞窗口置1,并重新开始慢启动。
- 当拥塞窗口的值再次达到慢启动门限时,TCP转移到拥塞避免模式。
- 拥塞避免:
- 每个往返时间只将拥塞窗口的值加一个MSS(最大报文段长度1460)
- 当出现超时时,将慢启动门限设置为拥塞窗口的1/2,并将拥塞窗口的值置1,重新开始慢启动。
- 快速恢复:
- 如果发送端接收到到3个冗余ACK,则执行快速重传,并进入快速恢复阶段。
- 将慢启动门限设置为拥塞窗口的一半,并将拥塞窗口设置为此时门限加3(即原窗口/2+3)后进入拥塞避免状态。
- 如果出现超时事件,快速恢复在执行如同在慢启动和拥塞避免中相同的动作后,迁移到慢启动状态。
- 慢启动:
- TCP与UDP的区别是什么?
- TCP向它的应用程序提供了面向连接的服务,这种服务包括了应用层报文向目的地的确保传递和流量控制。TCP将长报文划分为短报文,并提供拥塞控制机制。
- UDP向它的应用程序提供无连接服务,不可靠,没有流量控制,没有拥塞控制。
- 两个UDP报文段源IP地址或源端口号不同但目的IP和目的端口号相同,则报文段通过相同的套接字被定向到相同的目的地址。
- 两个TCP报文段源IP地址或源端口号不同但目的IP和目的端口号相同,则报文段通过被定向到两个不同的目的套接字。
- TCP的应用场景
- web:HTTP 80
- 文件传输:FTP 21 20
- 电子邮件:SMTP 25 POP3 110
- 远程终端访问:TELNET 23 RDP 3389 远程桌面协议
- SYN攻击
- SYN攻击是什么,怎么处理?
- SYN攻击属于DOS攻击的一种,它利用TCP协议缺陷,攻击者通过发送大量的SYN报文端,而不完成第三次握手步骤,耗费CPU和内存资源。
- 配合IP欺骗,SYN攻击能达到很好的效果,通常客户端在短时间内伪造大量不存在的IP地址,向服务器不断地发送syn包,服务器回复确认包,并等待客户的确认,由于源地址是不存在的,服务器需要不断的重发直至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,目标系统运行缓慢,严重者引起网络堵塞甚至系统瘫痪。
- SYN cookie的工作原理,cookie如何计算,在哪里传递
- 服务器收到一个SYN报文段后会先生成一个初始序列号(即cookie)
- 该序号是SYN报文段的源IP、目的IP地址与端口号以及一个秘密数的一个散列函数
- 服务器发送具有这种特殊初始序列号的SYNACK分组
- 如果服务器收到ACK,用同样的秘密数和源、目的IP与端口散列验证
- 如果结果加1等于该ACK中确认号,生成一个具有套接字的全开连接
- SYN攻击是什么,怎么处理?
- UDP实现的工作
- 复用/分解:通常应用 程序客户端自动分配端口号,服务器端分配一个特定的端口号
- 差错检测:端到端原则,在较低级别设置该功能是冗余的,没有差错恢复
- UDP的优点
- 应用层可以更精细的控制何时发送什么数据
- 没有建立连接的时延
- 不必维护连接状态:TCP要维护包括接收和发送缓存、拥塞控制参数、以及序号与确认号的参数
- 分组首部开销小:UDP有8字节首部,TCP有20字节首部
- 字段含义
- 源端口号(16位)
- 目的端口号(16位)
- UDP长度(16位):冗余的,IP头部已经提供数据报长度和首部长度
- UDP检验和(16位):传送中不会被修改,除非遇到NAT,计算时加入伪头部,包含源IP与目的IP,以验证是否正确的到达目的地
- 数据
- UDP为什么不可靠,怎么解决UPD的可靠性问题?
- 不需要建立连接就可以开始传输,没有确保传递和流量控制机制,没有拥塞控制机制
- 要在应用层实现类似与tcp的可靠连接的技术,比如确认与重传机制
- UDP的应用场景
- 域名地址转换:DNS 53
- 路由选择表的更新:RIP 520
- 远程文件服务器:NFS
- 网络管理数据:SNMP
- TFTP 69 简单文件传输协议 不支持身份认证
- DHCP 67
- 网络层能实现的功能
- 确保交付
- 有序分组交付
- 确保最小带宽
- 确保最大时延
- 安全性
- 对一些名词的理解
- 尽最大努力交付
- 最长前缀匹配规则
- 为什么TCP/IP在运输层与网络层都执行差错检测?
- IP层只对IP首部计算检验和,TCP/UDP检验和是对整个报文段进行的
- TCP/UDP与IP不一定同属于一个协议栈
- 字段含义
- 版本(4位)
- 首部长度(4位):32位字数量,没有选项的时候默认为5,最大为15,即60字节
- 服务类型(8位)
- 区分服务(6位)
- 显式拥塞通知ECN(2位)
- 总长度(16位):验证组帧时是否填充
- 标识(16位)
- 标志(3位)
- 片偏移(13位)
- 生存时间(8位):防止在环路中永久循环
- 上层协议(8位)
- 首部校验和(16位):每转发一次都要重新计算,因为TTL变了,没有错误校验和为0
- 源IP地址(32位)
- 目的IP地址(32位)
- 选项
- 数据
- 地址分类
- 0 128 192 224 240
- 私有IP
- 10.*
- 172.16.*--------172.31.*
- 192.168.*
- 路由表
- 目的网络地址 下一跳地址 子网掩码 发送接口
- 路由选择算法
- 链路状态算法:先获得全局状态信息,再计算最短路径
- 距离矢量算法:以迭代、分布式的方式计算最短路径
- AS内部路由选择协议
- RIP:运行在UDP上
- 距离矢量协议
- 距离向量:RIP发送的报文包含一个距离向量(跳数)。每个路由器都根据它接收到邻站的这些距离向量来更新自己的路由表。
- 工作过程
- 初始化:在启动一个路由守护程序时,它先判断启动了哪些接口,并在每个接口上发送一个请求报文,要求其他路由器发送完整路由表。在点对点链路中,该请求是发送给其他终点的。如果网络支持广播的话,这种请求是以广播形式发送的。目的UDP端口号是520(这是其他路由器的路由守护程序端口号)
- 接收到请求:如果这个请求是刚才提到的特殊请求,那么路由器就将完整的路由表发送给请求者。否则,就处理请求中的每一个表项:如果有连接到指名地址的路由,则将度量设置成我们的值,否则将度量值设为16(度量为16是一种称为"无穷大"的特殊值,它意味着没有到达目的的路由)。然后发出响应。
- 接收到响应:使响应生效,可能会更新路由表。可能会增加新表项,对已有表项进行修改,或者将已有表项删除。
- 定期选路更新:每过30秒,所有或部分路由器会将其完整路由表发送给相邻路由器。发送路由表可以是广播形式的(如在以太网上),或是发送给点对点链路的其他终点。
- 触发更新:每当一条路由的度量发生变化时,就对它进行更新。不需要发送完整的路由表,而只需要发送那些变化的表项。每条路由都有与之相关的定时器。如果运行 R I P的系统发现一条路由在 3分钟内未更新,就将该路由的度量设置成无穷大( 1 6),并标注为删除。这意味着已经在 6个3 0秒更新时间里没收到通告该路由的路由器的更新了。再过 6 0秒,将从本地路由表中删除该路由,以保证该路由的失效已被传播开。
- RIP的优缺点
- 算法简单,配置简单,适合用在小型网络之中
- 无法区分非零部分是子网部分还是主机地址
- 这种方法看起来很简单,但它有一些缺陷。首先, RIP没有子网地址的概念。例如,如果标准的B类地址中16 bit的主机号不为0,那么R I P无法区分非零部分是一个子网号,或者是一个主机地址。有一些实现中通过接收到的R I P信息,来使用接口的网络掩码,而这有可能出错。
- 可能会发生路由环路
- 在路由器或链路发生故障后,需要很长的一段时间才能稳定下来。这段时间通常需要几分钟。在这段建立时间里,可能会发生路由环路。在实现 R I P时,必须采用很多微妙的措施来防止路由环路的出现,并使其尽快建立。
- 度量最大为15,限制网络大小
- 采用跳数作为路由度量忽略了其他一些应该考虑的因素。同时度量最大值为15,则限制了可以使用RIP的网络的大小。
- 距离矢量协议
- OSPF:直接作为IP协议的载荷
- 核心是一个使用泛洪链路状态信息的链路状态协议和一个Dijkstra最低费用路径算法。每个路由器主动地测试与其邻站相连链路的状态,将这些信息发送给它的其他邻站,而邻站将这些信息在自治系统中传播出去。每个路由器接收这些链路状态信息,并建立起完整的路由表。
- OSPF与RIP的不同
- 链路状态协议比距离向量协议收敛的更快。收敛的意思是在路由发生变化后,例如在路由关闭或链路出故障后,可以稳定下来。
- OSPF直接使用IP,对于IP首部的protocol字段,OSPF有其自己的值。
- OSPF较RIP的优点
- OSPF可以对每个IP服务类型计算各自的路由集。这意味着对于任何目的,可以有多个路由表表项,每个表项对应着一个IP服务类型。
- 给每个接口指派一个无维数的费用。可以通过吞吐率、往返时间、可靠性或其他性能来进行指派。可以给每个IP服务类型指派一个单独的费用。
- 当对同一个目的地址存在着多个相同费用的路由时,O S P F在这些路由上平均分配流量。我们称之为流量平衡。
- OSPF支持子网:子网掩码与每个通告路由相连。这样就允许将一个任何类型的IP地址分割成多个不同大小的子网。到一个主机的路由是通过全 1子网掩码进行通告的。默认路由是以IP地址为0.0.0.0、网络掩码为全0进行通告的。
- 路由器之间的点对点链路不需要每端都有一个IP地址,我们称之为无编号网络。这样就可以节省IP地址。
- 采用了一种简单鉴别机制。可以采用类似RIP-2的方法指定一个明文口令。
- OSPF采用多播,而不是广播形式,以减少不参与OSPF的系统负载。
- 一些常见的其他问题
- OSPF的实现过程以及五种分组类型
- hello报文的作用,hello报文是基于UDP还是TCP?
- OSPF的负载均衡是怎么做的?
- OSPF的使用场景
- OSPF和rip的本质区别是什么?OSPF一定比RIP收敛快吗?
- ospf 是基于链路状态的路由协议,主要以带宽作为选路的依据
- RIP 是基于跳数的路由协议,以跳数作为选路的依据
- RIP:运行在UDP上
- 自治系统间的路由协议
- BGP:
- BGPv4是一种外部的路由协议。可认为是一种高级的距离向量路由协议。\
- 在BGP网络中,可以将一个网络分成多个自治系统。自治系统间使用eBGP广播路由,自治系统内使用iBGP在自己的网络内广播路由。\
- BGP路由选择方法是基于距离向量路由选择,与传统的距离向量(1个单独的度量,如跳数)协议不同,BGP将AS外部路径的度量复杂化。
- BGP系统的主要功能是和其他BGP系统交换网络可达信息。网络可达信息包括列出的AS信息。这些信息有效地构造了 AS互联的拓朴图并由此清除了路由环路,同时在 AS级别上可实施策略决策。
- BGP特点:
- BGP是一种外部路由协议,与OSPF、RIP不同,其着眼点不在于发现和计算路由,而在于控制路由的传播和选择最好的路由。\
- BGP通过携带AS路径信息,可以彻底的解决路由循环问题。
- 为了控制路由的传播和路由的选择,为路由附带属性信息。\
- 使用TCP作为其传输层协议,提高了协议的可靠性。端口号TCP 179。\
- BGP-4支持CIDR(无类别域间选路),CIDR的引入简化了路由聚合,减化了路由表。
- BGP更新时只发送增量路由,减少了BGP传播路由占用的带宽。\
- 提供了丰富的路由策略。
- BGP:
- 数据链路层实现的功能
- 封装成帧:一个数据字段和若干个首部字段组成
- 链路接入:帧在链路中的传输规则
- 可靠交付:无线信道使用,有线通常没有
- 差错检测和纠正:奇偶校验,检验和,CRC校验
- 差错检验
- 为什么运输层使用检验和而链路层使用CRC呢?
- 运输层差错检验用软件实现,采用简单快速的检验和的方式。
- 链路层的差错检测在适配器中采用专用硬件实现。
- 为什么运输层使用检验和而链路层使用CRC呢?
- 点对点链路
- 广播链路
- 多路访问协议
- 信道划分协议:带宽限制:R/N
- 时分复用
- 频分复用
- 码分多址
- 随机接入协议:全部速率
- 载波侦听多路访问(CSMA)
- 具有碰撞检测的载波侦听多路访问(CSMA/CD)
- 轮询协议
- 轮询协议
- 令牌传递协议
- 信道划分协议:带宽限制:R/N
- 多路访问协议
- 交换局域网
- 为什么网络层和链路层都需要地址?
- 保持各层的独立,局域网是为任意网络层协议而设计的,不只用于IP和因特网。
- 如果适配器使用IP地址,则适配器不能方便的支持其他网络层协议,且IP地址必须存储在适配器的RAM中。
- 如果适配器中不适用任何地址,则主机将被局域网上发送的每个帧中断。
- 如果网络层使用MAC地址,无法构建高效的路由选择方案,增加一个附加层的地址寻址,可以使得设备更易于移动和维修 。
- 为什么网络层和链路层都需要地址?
- 获取目的主机的硬件地址,提供从网络层地址到相关硬件地址的动态映射,自动执行,随时间变化。
- DNS为在因特网任何地方的主机解析主机名,而ARP只为在同一个子网上的主机和路由器接口解析IP地址
- ARP数据报格式
- 工作原理
- 查询ARP表中有没有该目的主机的表项
- 构造一个ARP查询分组,用MAC广播地址(全F)发送给全局域网,匹配的主机发送一个响应ARP分组
- 查询主机更新ARP表,发送IP数据报
- 查询ARP帧是在广播帧中发送的,响应ARP报文在标准帧中发送
- 以太网首部(14字节)加4字节的CRC和1500字节的MTU,最大帧长1518,最小帧长为64,最小有效载荷46字节
- 以太网目的地址(6字节)
- 以太网源地址(6字节)
- 帧类型(2)字节:即协议类型
- CRC(4字节)在有效载荷后面
- ARP请求/应答(28字节)
- 硬件类型(2字节):以太网
- 协议类型(2字节):IP协议
- 硬件地址长度(1字节)
- 协议地址长度(1字节)
- op(1字节):请求/应答
- 发送端以太网地址(6字节)
- 发送端IP地址(4字节)
- 目的以太网地址(6字节)
- 目的IP地址(4字节)
- 填充位(18字节):以太网规定最小数据长度为46字节
- 工作原理
- 网络错误排查
- 联系ping等检查网络是否通畅来考察你对问题的追溯程度,比如网络通,但是拿不到服务器上的资源,怎么办,防火墙封闭了端口?如果端口也开了呢,怎么办,dns解析有问题?怎么弄?
- tcpdump抓到的包如何分析?
- 写入到.pcap文件中,使用wireshark或packetyzer查看分析
- 在你们的运维平台上刷新了一条资源如何检测这条资源有没有刷新成功?
- 网易云音乐的评论无法加载,如何排查?说出思路,各业务模块监控指标QPS均无抖降点,但是问题依旧存在,为什么?
- 如何在linux上添加路由?我添加了一条路由之后还是ping不通,可能的原因有哪些?
- 出不去:网关不通,出去的路被防火墙档了
- 回不来:被丢弃,回来的报被挡了
- Socket网络编程
- 有哪些系统调用?
- Server:socket、bind、listen、accept、read、write、read、...、close
- Client: socket、connect、write、read、write、...、close
- 建立连接的过程
- 服务器调用socket()、bind()、listen()函数完成初始化后,调用accept()阻塞等待。
- 客户端调用socket()初始化后,调用connect()发出SYN段并阻塞等待服务器应答。
- 服务器应答一个SYN-ACK段,客户端收到后从connect()返回,同时应答一个ACK段,服务器收到后从accept()返回,TCP链路建立。
- 数据传输的过程
- 服务器从accept()返回后立即调用read(),读socket就像读管道一样,如果没有数据到达就阻塞等待。
- 这时客户端调用write()发送请求给服务器,
- 服务器收到后从read()返回,对客户端的请求进行处理,在此期间客户端调用read()阻塞等待服务器的应答。
- 服务器调用write()将处理结果发回给客户端,再次调用read()阻塞等待下一条请求,
- 客户端收到后从read()返回,发送下一条请求,如此循环下去。
- 关闭连接的过程
- 如果客户端没有更多请求了,就调用close()关闭连接,就像写端关闭的管道一样,服务器的read()返回0。
- 这样服务器就知道客户端关闭了连接,也调用close()关闭连接。
- 注意,任何一方调用close()后,连接的两个传输方向都关闭,不能再发送数据了。如果一方调用shutdown()则连接处于半关闭状态,仍可接收对方发来的数据。
- close是一次就能直接关闭吗?
- 半关闭状态shut_down
- 有哪些系统调用?

