《求职》第三部分 - 计算机网络篇 - 计算机网络总结
1.网络总述
计算机经网络体系结构:
各层作用及协议
分层 | 作用 | 协议 |
---|---|---|
物理层 | 通过媒介传输比特,确定机械及电气规范(比特 Bit) | RJ45、CLOCK、IEEE802.3(中继器,集线器) |
数据链路层 | 将比特组装成帧和点到点的传递(帧 Frame) | PPP、FR、HDLC、VLAN、MAC(网桥,交换机) |
网络层 | 负责数据包从源到宿的传递和网际互连(包 Packet) | IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP(路由器) |
运输层 | 提供端到端的可靠报文传递和错误恢复( 段Segment) | TCP、UDP、SPX |
会话层 | 建立、管理和终止会话(会话协议数据单元 SPDU) | NFS、SQL、NETBIOS、RPC |
表示层 | 对数据进行翻译、加密和压缩(表示协议数据单元 PPDU) | JPEG、MPEG、ASII |
应用层 | 允许访问OSI环境的手段(应用协议数据单元 APDU) | FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS |
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
2.应用层
2.1 应用程序体系结构
- 客户机/服务器(C/S)体系结构
- P2P 体系结构
2.2 因特网传输服务
当创建一个新的因特网应用时,首先要做出的决定是选择 UDP 还是 TCP,它们能为应用程序提供下列服务:
• TCP
面向连接的服务
可靠数据传输服务
• UDP
无连接的服务
不可靠数据传输服务(不保证到达,也不保证有序到达)
除此之外, TCP 具有拥塞控制机制,拥塞控制不一定能为应用程序带来直接好处,但能对整个网络带来好处。UDP 没有拥塞控制。
2.3 应用层协议
2.3.1 HTTP
- HTTP(HyperText Transfer Protocol,超文本传输协议)是用于从 WWW(World Wide Web,万维网)服务器传输超文本到本地浏览器的传送协议。HTTP 是万维网的数据通信的基础。
使用 TCP 作为运输层协议
无状态协议:服务器向客户机发送被请求的文件时,并不存储任何关于该客户机的状态信息。假如某个特定
的客户机在短短的几秒钟内两次请求同一个对象,服务器并不会因为刚刚为该用户提供了该对象就不再做出反
应,而是重新发送该对象。
• HTTP 客户机: web 浏览器
• HTTP 服务器: web 服务器,包含 web 对象(HTML 文件、 JPEG 文件、 java 小程序、视频片段等)
连接类型:
• 非持久连接:每个请求/响应对是经一个单独的 TCP 连接发送
• 持久连接:所有请求/响应对使用同一个 TCP 连接发送
如果使用非持久连接,将 TCP 握手第三步与一个 HTTP 请求报文结合起来发送,服务器接收请求后响应一个
对象。因此,传输一个对象消耗 2 个 RTT。(可以同时建立多个连接并行传输)但是,由于 TCP 连接会分配
缓冲区和变量,大量使用非持久连接会给服务器造成压力
如果使用持久连接,则客户机接收到请求对象后服务器不会发送一个 TCP 连接关闭请求。这个连接服务于所
有 web 对象的传输(流水线发送),如果经过一个时间间隔仍未被使用,则 HTTP 服务器关闭连接
• http1.0 使用非持久连接
• http1.1 使用持久连接
1) HTTP 报文格式(请求报文)
- 请求行
- 请求方式
- 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头域:对消息进行端到端的编码。
- range头域与Content-Range头域:请求消息中如果包含比较大的实体内容,但不确定服务器是否能够接收该请求,它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。
- 错误提示:
- HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE,
CONNECT这些Request方法。 - HTTP/1.1引入了一个Warning头域,增加对错误或警告信息的描述。
- 在HTTP/1.1中新增了24个状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
- HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE,
- 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报文:
“Connection:close”:浏览器告诉服务器不希望使用持久连接,而是要求服务器在发送完请求后关闭连接
“Accept-language”:用户想得到该对象的语法版本计算机网络
方法字段:
• GET:绝大部分 HTTP 请求报文使用 GET 方法
• POST:用户提交表单时(如向搜索引擎提供关键字),但提交表单不一定要用 POST 方法
• HEAD:类似于 GET,区别在于服务器返回的响应报文中不包含请求对象(常用于故障跟踪)
• PUT:用于向服务器上传对象
• DELETE:用于删除服务器上的对象
【注】GET 与 POST 的区别与联系
2) HTTP 报文格式(响应报文)
- 响应状态行
- 协议版本
- 状态码
- 200 OK:请求成功,信息包含在返回的响应报文中
- 301 Moved Permanently:请求的对象已经被永久转移了,新的 URL 定义在响应报文的 Location 首部中。客户机软件自动用新的 URL 获取对象
- 302:找到
- 304:Not Modified:条件 GET 的响应报文中的状态码, web 服务器告诉 web 缓存相应对象未被修改(If-Modified-Since,Last-Modified,缓存,条件GET)
- 400 Bad Request:请求不能被服务器理解
- 401:未经授权
- 403 Forbidden:服务器收到请求,但是拒绝提供服务。服务器通常会在响应报文中给出不提供服务的原因
- 404 Not Found:被请求的文档不在服务器上
- 500:服务器错误
- 502:无效网关
- 504:网关超时
- 505 HTTP Version Not Supported:服务器不支持请求报文使用的 HTTP 协议版本
- 描述信息
- 响应头
- Server
- Date:报文生成、发送时的日期
- Expires:控制缓存过期时间
- Location
- Accept-Ranges
- Content-*
- Last-Modified: web 对象最后修改的日期
- ETag:最后缓存时间和文件大小的哈希
- Expires:在某时间前,直接使用,不必请求
- Cache-Control:在某时间内,直接使用,不必请求
- Transfer-Encoding
- Set-Cookie
- Connection
- 实体内容
- MIME类型:大类别/具体类型
“Connection:close”:告诉客户机在报文发送完后关闭了 TCP 连接
Telnet: HTTP 响应报文查看工具
3) cookie>
用于识别用户,可能出于下列意图:
• 服务器想限制用户的访问
• 服务器想把内容与用户身份关联起来
cookie 包含 4 个组成部分:
-
在 HTTP 响应报文中有一个 Set-cookie 首部行
-
在 HTTP 请求报文中有一个 Cookie 首部行
-
在用户端系统中保留有一个 cookie 文件,由用户的浏览器管理
-
在 web 站点有一个后端数据库
4) web 缓存>
web 缓存器也叫代理服务器,用于缓存 web 对象。用户可以配置其浏览器,使得所有 HTTP 请求首先指向web 缓存器。
如果 web 缓存器没有请求的对象,会与初始服务器直接建立一条 TCP 连接, web 缓存器进一步发送 HTTP 请
求,获取对象,当接收到对象后,首先在本地缓存,然后生成一个 HTTP 响应报文,发送给客户机(因此,web 缓存器既是客户机,又是服务器)。
web 缓存器类似于内存与处理器之间的 cache,它能从整体上大大降低因特网上的 web 流量,从而改善所有应用的性能。
条件 GET: web 缓存器使用条件 GET 向 web 服务器确认某个对象是否已经被修改(不是最新的对象)。如果
1)请求报文使用 GET 方法;
2)并且包含一个 If-modified-since:首部行,那么这个 HTTP 请求报文就是一个条件 GET计算机网络。如果相应对象未被修改, web 服务器返回一个实体为空的响应报文(也就是说并没有包含请求对象),状态码为
“304 Not Modified
请求方法
方法 | 意义 |
---|---|
OPTIONS | 请求一些选项信息,允许客户端查看服务器的性能 |
GET | 请求指定的页面信息,并返回实体主体 |
HEAD | 类似于 get 请求,只不过返回的响应中没有具体的内容,用于获取报头 |
POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改 |
PUT | 从客户端向服务器传送的数据取代指定的文档的内容 |
DELETE | 请求服务器删除指定的页面 |
TRACE | 回显服务器收到的请求,主要用于测试或诊断 |
状态码(Status-Code)
- 1xx:表示通知信息,如请求收到了或正在进行处理
- 100 Continue:继续,客户端应继续其请求
- 101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到 HTTP 的新版本协议
- 2xx:表示成功,如接收或知道了
- 200 OK: 请求成功
- 3xx:表示重定向,如要完成请求还必须采取进一步的行动
- 301 Moved Permanently: 永久移动。请求的资源已被永久的移动到新 URL,返回信息会包括新的 URL,浏览器会自动定向到新 URL。今后任何新的请求都应使用新的 URL 代替
- 4xx:表示客户的差错,如请求中有错误的语法或不能完成
- 400 Bad Request: 客户端请求的语法错误,服务器无法理解
- 401 Unauthorized: 请求要求用户的身份认证
- 403 Forbidden: 服务器理解请求客户端的请求,但是拒绝执行此请求(权限不够)
- 404 Not Found: 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置 “您所请求的资源无法找到” 的个性页面
- 408 Request Timeout: 服务器等待客户端发送的请求时间过长,超时
- 5xx:表示服务器的差错,如服务器失效无法完成请求
- 500 Internal Server Error: 服务器内部错误,无法完成请求
- 503 Service Unavailable: 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的 Retry-After 头信息中
- 504 Gateway Timeout: 充当网关或代理的服务器,未及时从远端服务器获取请求
更多状态码:菜鸟教程 . HTTP状态码
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协把处理结果或请求的资源传输到浏览器(响应报文)
- 关闭连接
2.3.2 SMTP
- SMTP(Simple Mail Transfer Protocol,简单邮件传输协议)是一组用于由源地址到目的地址传送邮件的规则,由它来控制信件的中转方式。SMTP 协议属于 TCP/IP 协议簇,它帮助每台计算机在发送或中转信件时找到下一个目的地。是一个相对简单的基于文本的协议。在其之上指定了一条消息的一个或多个接收者(在大多数情况下被确认是存在的),然后消息文本会被传输。可以很简单地通过 Telnet 程序来测试一个 SMTP 服务器。SMTP 使用 TCP 端口 25。
电子邮件系统有 3 个主要组成部分: 用户代理、邮件服务器、简单邮件传输协议(SMTP)
• 每个用户在邮件服务器上有一个邮箱,保存该用户发送和接收的邮件
• 如果邮件未发送成功,会保存在邮件服务器上,通常 30 分钟左右再进行尝试,几天后仍不成功则删除,并以邮件形式通知发送方
• SMTP 传输邮件之前,需要将报文主体编码为 ASCII 码,传输后需要解码(HTTP 传输不需要)
• SMTP 一般不使用中间邮件服务器发送邮件,即使两个邮件服务器位于地球的两端
• SMTP 会把邮件中所有对象封装在一个报文中,而 HTTP 则是每个报文封装一个 web 对象
1)多用途因特网邮件扩展(MIME)
普通的邮件报文主体为 ASCII 编码的数据,报文首部适合于发送普通的 ASCII 文本,但是不能充分满足多媒体
报文或携带非 ASCII 文本格式(非英文字符)的报文需求。需要额外的首部行提供对发送这些文件的支持
MIME 中包含 2 个支持发送上述文件的首部:
• Content-Transfer-Encoding:指出所用编码类型,接收方可以根据这个字段还原
• Content-Type:文件类型,接收方可以根据这个首部采取一些适当动作(如解压)
2)接收方邮件拉取>
SMTP 是一个”推协议“,不能用于接收方代理从邮件服务器上拉取邮件,拉取邮件需要使用 POP3(第三版的邮
局协议)、 IMAP(因特网邮件访问协议)或 HTTP
POP3(第三版的邮局协议):当用户打开一个到邮件服务器端口 110 上的 TCP 连接后, POP3 就开始工作了,
包含 3 个阶段
• 特许:用户发送用户名和口令鉴别身份
• 事务处理:用户代理取回报文(还能标记报文、获取邮件统计信息)
• 更新:客户机发出了 quit 命令后,结束了 POP3 会话,邮件服务器会删除被标记为删除的报文
使用 POP3 拉取时,可以设置为”拉取并删除“或”拉取并保留“
IMAP(因特网邮件访问协议): POP3 不能提供远程文件夹功能, IMAP 可以, IMAP 服务器把每个报文与一个
文件夹联系起来, IMAP 为用户提供了创建文件夹以及在文件夹之间移动邮件的命令。除此之外,还提供在远
程文件夹中查询邮件、按指定条件查询匹配文件的命令。与 POP3 不同, IMAP 服务器维护了 IMAP 会话的用
户状态信息
基于 web 的电子邮件:当使用 web 浏览器发送接收邮件时,推送到邮件服务器和从邮件服务器拉取邮件使用的是 HTTP 协议。
【注】SMTP和HTTP协议的区别
-
SMTP是个推协议,HTTP是个拉协议,所以用户从自己的邮件服务器上收取报文时,需要使用POP3(110)、IMAP()以及HTTP协议
- POP3协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法,不维护用户状态信息
- IMAP解决以上问题
-
SMTP要求每个报文用7比特ASCII码格式
-
SMTP把所有报文对象放在一个报文中
2.3.3 DNS
- DNS(Domain Name System,域名系统)是互联网的一项服务。它作为将域名和 IP 地址相互映射的一个分布式数据库,能够使人更方便地访问互联网。DNS 使用 TCP 和 UDP 端口 53。当前,对于每一级域名长度的限制是 63 个字符,域名总长度则不能超过 253 个字符。
域名:
-
域名 ::= {<三级域名>.<二级域名>.<*域名>}
,如:`blog.huihut.com
DNS运行于UDP之上,使用53号端口,它提供下列服务:
- 主机名到IP地址的转换(主要)。
- 主机别名 :有着复杂主机名的主机可以拥有一个或多个别名,应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址
- 邮件服务器别名:qq.com与foxmail.com,DNS可以解析邮件服务器别名获得规范名和IP地址
- 负载分配:繁忙的站点被冗余分布在多台服务器上,这些服务器有不同IP地址,IP地址集合对应于一个规范主机名,当客户机通过主机名获取IP地址时,DNS服务器用包含全部这些地址的报文进行回答,但在每个回答中选择这些地址排放的顺序,从而将负载分配到不同服务器
1)DNS服务器
集中设计(单一DNS服务器)具有下列问题:
-
单点故障
-
通信容量:单个DNS服务器承受所有查询负载
-
远距离的集中式数据库:单个DNS服务器不可能”邻近“所有查询客户机
所以DNS服务器使用分布式设计方案:
-
根DNS服务器:因特网上有13个根DNS服务器(标号A到M),大部分位于北美洲
-
*域(TLD)DNS服务器
-
权威DNS服务器
除此之外,DNS服务器还有本地DNS服务器。严格来说,本地DNS服务器不属于DNS服务器的层次结构,但对DNS层次结构很重要。一台主机具有一台或多台本地DNS服务器的IP地址,本地DNS服务器起着代理的作用,将请求转发到DNS服务器层次结构中。
2)DNS查询步骤
DNS缓存:在查询链中,当一个DNS服务器接收到一个DNS回答时,DNS服务器能将回答中的信息缓存在本地存储,以便加速后序可能的相同查询。由于主机IP和主机名之间的映射不是永久的,DNS服务器会在一段时间后丢弃缓存(本地DNS服务器可以缓存TLD服务器的IP地址,因而允许直接绕过查询链中的根DNS服务器)。
3)DNS记录和报文
所有DNS服务器共同存储着资源记录,资源记录格式如下:
(Name,Value,Type,TTL)
-
Type=A:此时Name是主机名,Value是对应IP地址
-
Type=NS:Name是域(如foo.com),Value是知道如何获取该域中主机IP地址的权威DNS服务器的主机名
-
Type=CNAME:Value是别名为Name的主机对应的规范主机名
-
Type=MX:Value是别名为Name的邮件服务器的规范主机名
如果一台DNS服务器是某个特定主机名的权威DNS服务器,那么会有一条包含该主机名的类型A记录(不是权威服务器,也可能在缓存中包含A记录)
如果DNS服务器不是某个主机名的权威DNS服务器,那么会包含一条类型NS记录,还将包含一条类型A记录,提供了在NS记录的Value字段中DNS服务器的IP地址
DNS报文(查询和响应报文格式相同)
nslookup:从主机直接向某些DNS服务器发送DNS查询报文
注册域名
因特网名字和地址分配机构(ICANN)向各种注册登记机构授权,可以向这些机构申请注册域名:
- 提供基本权威DNS服务器和辅助权威服务器的域名和IP
- 注册登记机构会将NS和A类型的记录输入TLD服务器
- 确保自身在提供的权威DNS服务器中输入了相应类型的记录
4) DDos带宽洪泛攻击
如,攻击者向每个DNS根服务器连续不断地发送大量的分组,从而使得大多数合法的DNS请求得不到回答
DNS根服务器配置分组过滤器可以拦截这些分组,本地DNS服务器缓存了*域名服务器的IP地址,也能绕过DNS根服务器,防止攻击
【QA】
1.为什么要DNS解析,DNS是什么?
- 人类喜欢便于记忆的主机名标识方式,路由器定长的有层次地IP地址。
- DNS是一个由分层的DNS服务器实现的分布式数据库,一个使得主机能够查询分布式数据库的应用层协议。
2.DNS的解析过程,涉及到的文件以及其记录类型
- 递归查询:本地、根、二级…本地
- 迭代查询:本地、根服务器、本地、二级、本地…本地
- 通常来说请求主机到本地DNS服务器的查询是递归的,其余的查询是迭代的
- 记录类型
- CNAME:主机别名比规范主机名更容易记忆,一个IP给许多主机用,只修改CNAME对应的A记录即可,CDN,主机别名,规范主机名,CNAME
- A:主机名,IP,A(权威服务器有)
- MX:邮件服务器别名,规范主机名,MX
- NS:域,能获取该域的主机IP地址的权威DNS服务器的主机名,NS(非权威服务器)
3.如果DNS解析出现错误,解决的思路是什么?
- 本地缓存被污染
- 本地DNS服务器被污染
- 中间人攻击
- 墙
4.Anycast 的使用场景
- 大型DNS系统中广泛使用的多点部署、分布式方案,对于提高可用性、提高性能、抵抗DDOS有重要作用。
=5.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主要负责节点内部的设备负载均衡
- 运营管理系统:分为运营管理和网络管理子系统,负责处理业务层面的与外界系统交互所必须的收集、整理、交付工作,包含客户管理、产品管理、计费管理、统计分析等功能。
- 分发服务系统:最基本的工作单元就是Cache设备,cache(边缘cache)负责直接响应最终用户的访问请求,把缓存在本地的内容快速地提供给用户。同时cache还负责与源站点进行内容同步,把更新的内容以及本地没有的内容从源站点获取并保存在本地。Cache设备的数量、规模、总服务能力是衡
- 在解析过程中,企业的CDN是怎么起作用的(在解析过程中,如何把请求打到CDN节点上)?
- 使用了CDN缓存后,针对网站的访问过程变为:
- 本地DNS服务器在进行查询的时候,将该DNS请求中继到该域名的权威服务器。权威服务器通过分析二级域名,如video.baidu.com,不直接返回IP地址,而是返回一个对应的CNAME记录,该记录指向公司CDN的DNS权威服务器。
- 用户的本地服务器对获得的CNAME域名进行解析,向CDN的DNS权威服务器发起请求。
- 权威服务器通过在IP库中查询请求IP的地理位置(淘宝使用包裹记录来校准),同时考虑网络成本,流量分布,源站负载等,返回一个最优节点缓存服务器的IP。
- 缓存服务器根据浏览器提供的要访问的域名,通过Cache内部专用DNS解析得到此域名的实际IP地址,再由缓存服务器向此实际IP地址提交访问请求。
- 缓存服务器从实际IP地址得得到内容以后,一方面在本地进行保存,以备以后使用,二方面把获取的数据返回给客户端,完成数据服务过程。
2.3.4 DHCP
DHCP(Dynamic Host Configuration Protocol,动态主机设置协议)是一个局域网的网络协议,使用 UDP 协议工作,主要有两个用途:
- 用于内部网络或网络服务供应商自动分配 IP 地址给用户
- 用于内部网络管理员作为对所有电脑作*管理的手段
获取IP地址,掩码,路由器IP地址,DNS服务器的IP地址
- 实现原理
- 发现:新到主机通过DHCP发现报文,在UDP分组中向端口67发送,使用广播目的地址255.255.255.255,源地址0.0.0.0
- 提供:DHCP服务器通过广播地址能提供的IP信息(地址、掩码、租用期)
- 请求:新到主机从提供报文中选中一个服务器,并响应一个DHCP请求报文,回显配置参数
- ACK:服务器用DHCP ACK报文证实所要求的参数
2.3.5 FTP
- FTP(File Transfer Protocol,文件传输协议)是用于在网络上进行文件传输的一套标准协议,使用客户/服务器模式,使用 TCP 数据报,提供交互式访问,双向传输。
- TFTP(Trivial File Transfer Protocol,简单文件传输协议)一个小且易实现的文件传输协议,也使用客户-服务器方式,使用UDP数据报,只支持文件传输而不支持交互,没有列目录,不能对用户进行身份鉴定。
FTP 使用两个并行的 TCP 连接来传输文件:
- 控制连接(持久):传输控制信息,如用户标识、口令、改变远程目录命令、文件获取上传的命令
- 数据连接(非持久):传输实际文件
FTP 客户机发起向 FTP 服务器的控制连接,然后在该连接上发送用户标识和口令、改变远程目录命令。 FTP服务器收到命令后,发起一个到客户机的数据连接,在该连接上准确地传送一个文件并关闭连接。
有状态的协议: FTP 服务器在整个会话期间保留用户的状态信息。服务器必须把特定的用户账号和控制连接联系起来
- 控制连接:长连接
- 以7比特ASCII格式传输
- 数据连接:短连接
- 用户身份
- 实体用户
- 访客
- 匿名用户
- 主动连接
- 防火墙(NAT)问题:使用iptables的ftp模块
- 客户端先发起,告知自己的端口号,连接到服务器21端口,服务器20端口主动连接客户端
- 被动连接
- 客户端发送被动连接标识,服务器21端口号告诉客户端自己使用的数据端口,客户端随即选用大于1024的端口主动连接服务器,
- 安全性
- vsftpd
- 明文传输不安全
- chroot,限定用户的访问目录
2.3.6 SMB
- 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
2.3.7 P2P应用
不同于C/S架构,P2P架构中,每个主机既是客户机也是服务器,称作对等方,由于文件分布存储在多个对等方中,因此文件分发速度更快
• u:上传速率
• d:下载速率
• F:文件(比特)大小
假设服务器需要将文件发送到N个对等方:
1)如果使用C/S架构
• 服务器总共需要上传NF比特数据,那么至少需要NF/us的时间
• 设dmin为下载速率最小的对等方,那么该对等方不可能在F/dmin内获得文件
那么有:Dcs ≥ max{NF/us,F/dmin},服务器调度传输可使下届作为实际分发时间,即:Dcs = max{NF/us,F/dmin}。当N足够大时,分发时间取决于NF/us,随对等方数量线性增加
2) 如果使用P2P架构:
• 刚开始只有服务器拥有文件,为了将文件的所有比特传至网络,需要F/us
• 设dmin为下载速率最小的对等方,那么该对等方不可能在F/dmin内获得文件
• 设utotal = us + u1 + … + un表示系统总上传速率。由于最终每个对等方会有一个文件,那么总共需要上传NF
比特,那么所有数据的上传时间不可能小于NF/utotal
因此又:Dp2p ≥ max{F/us,F/dmin,NF/utotal},如果每个对等方接收到一个比特就重新分发一个比特,可使下届作为实际分发时间,即:Dp2p = max{F/us,F/dmin,NF/utotal}。实际上,重新分发的是文件块而不是一个个比特
下图展示了在两种架构下分发时间与对等方数量的关系,可以看出使用P2P进行文件分发速度快,具有自我扩展性:
P2P中文件的搜索方式
• 集中式索引:使用一个集中式索引服务器存储索引,是一种P2P和C/S混合的体系结构,文件分发是P2P的,搜索是C/S的
• 查询洪泛:建立在Gnutella协议基础上,索引全面分布在对等方区域中,对等方向相邻对等方发出文件查询请求,相邻对等方进一步转发查询请求
• 层次覆盖:结合以上两种,与因特网高速连接并具有高可用性的对等方被指派为超级对等方,新的对等方与超级对等方之一建立TCP连接,将其可供共享的所有文件告诉超级对等方,超级对等方维护着一个索引,超级对等方之间通过TCP连接,可以转发查询。
2.3.8 TELNET
- TELNET 协议是 TCP/IP 协议族中的一员,是 Internet 远程登陆服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。
2.3.9 WWW
- WWW(World Wide Web,环球信息网,万维网)是一个由许多互相链接的超文本组成的系统,通过互联网访问。
2.3.10 SNMP
- SNMP(Simple Network Management Protocol,简单网络管理协议)构成了互联网工程工作小组(IETF,Internet Engineering Task Force)定义的 Internet 协议族的一部分。该协议能够支持网络管理系统,用以监测连接到网络上的设备是否有任何引起管理上关注的情况。
2.3.11 URL
- URL(Uniform Resource Locator,统一资源定位符)是因特网上标准的资源的地址(Address)
标准格式:
协议类型:[//服务器地址[:端口号]][/资源层级UNIX文件路径]文件名[?查询][#片段ID]
完整格式:
协议类型:[//[访问资源需要的凭证信息@]服务器地址[:端口号]][/资源层级UNIX文件路径]文件名[?查询][#片段ID]
其中【访问凭证信息@;:端口号;?查询;#片段ID】都属于选填项
3.传输层
3.1端口号与套接字
3.3.1 端口号
通常在一台主机上能够运行许多网络应用程序。IP地址可以标识一台主机,端口号则是用来标识这台主机上的特定进程。
端口号是一个16bit的数字,大小在0 ~ 65535之间,0 ~ 1023范围的端口号称为周知端口号,保留给周知的应用层协议。
应用层协议 | 端口号 | 传输层协议 |
---|---|---|
DNS | 53 | UDP |
FTP | 21(控制连接),20(数据连接) | TCP |
TFTP | 69 | UDP |
TELNET | 23 | TCP |
DHCP | 67(服务器),68(客户端) | UDP |
HTTP | 80 | TCP |
HTTPS | 443 | TCP |
SMTP | 25 | TCP |
POP3 | 110 | TCP |
IMAP | 143 | TCP |
3.3.2 套接字
网络应用由成对进程组成,进程通过一个称为套接字的软件接口在网络上发生和接收报文
套接字是同一台主机内应用层与运输层之间的接口,也可称为应用程序和网络之间的应用程序编程接口
TCP套接字:(源IP,源端口,目的IP,目的端口)
UDP套接字:(目的IP,目的端口)
3.2多路复用与多路分解
• 多路分解:将运输层报文段中的数据交付到正确的套接字的过程(通过报文段的端口号字段)
• 多路复用:从源主机不同套接字收集数据,并为数据封装上首部信息从而生成报文段,传递到网络的过程
3.3可靠数据传输原理
-
rdt:可靠数据传输
-
udt:不可靠数据传输
3.3.1完全可靠信道上的可靠数据传输(rdt1.0)
假设底层信道是完全可靠的
3.3.2具有比特差错信道上的可靠数据传输(rdt2.0、rdt2.1、rdt2.2)
更现实的底层信道模型是分组中的比特可能受损
引入了自动重传请求(ARQ)协议,ARQ还需要另外3种协议来处理存在的比特差错:
-
差错检测
-
接收方反馈:肯定确认(ACK)和否定确认(NAK)
-
重传:接收方收到有差错的分组时,发送方重传
对于发送方,在等待ACK或NAK状态时,不能发送更多分组。类似于rdt2.0这种行为的协议被称为停等协议rdt2.0的问题在于没有考虑到ACK和NAK分组可能受损的情况
处理受损ACK或NAK的办法是,如果收到受损的ACK或NAK,则重传一次分组,但是这样又无法确认是一次新的分组还是重传的分组。解决办法是在分组中添加一个序号字段,接收方只需检查序号即可确定收到的分组是否是一次重传。对于rdt2.0,只需1比特序号即可,从而得到rdt2.1
如果收到受损的分组,接收方也可以发送一个对上次正确接收分组的ACK,也能实现与NAK一样的效果,也就是rdt2.2
3.3.3 具有比特差错的丢包信道上的可靠数据传输(rdt3.0)
现在假定除了比特受损外,底层信道还会丢包,因此需要引入时间机制决定何时重传分组
3.3.4 流水线可靠数据传输
rdt3.0功能正确,但由于是一个停等协议,所以性能很差。如果能在收到确认之前发送多个分组,可以大大提升性能
1)回退N步(GBN)
也被称为滑动窗口协议
- 发送方
超时重传所有已发送但未确认的分组
- 接收方
每接收到一个有序分组交付到上层,丢弃无序分组
累积确认收到的有序分组
丢弃无序分组的优点在于接收方缓存简单,需要维护的唯一信息就是下一个按序接收的分组的序号;缺点是对于丢弃的分组,随后重传也许会丢失或出错,因此甚至需要更多的重传
2)选择重传(SR)
一个单个分组的差错就可能引起GBN重传大量分组,许多分组根本没有必要重传。随着信道差错率的增加,流水线可能被这些没有必要重传的分组填满
- 发送方
如果收到的ACK对应一个窗口内的分组,则标记为已接收,序号等于send_base则移动窗口至具有最小序号的未确认分组处
如果窗口移动了,并且有序号落在窗口内的未发送分组,则发送这些分组
如果发生超时,只能发送1个分组
- 接收方
确认(ACK)一个正确接收到的分组(收到滑动窗口前的分组也要再次确认,因为这种情况通常意味着这个分组的前一次确认未被发送方收到);
失序分组会被缓存直到所有丢失分组都被收到,此时将一批分组按序交付给上层.
一个SR运行的例子:
对于SR而言,接收方窗口长度必须小于等于序号空间大小的一半,否则可能无法确认一个分组是重传还是初次传送
3.4 TCP
TCP是面向连接的,提供全双工的服务:数据流可以双向传输。也是点对点的,即在单个发送方与单个接收方之间的连接。
特征:
- 面向连接
- 只能点对点(一对一)通信
- 可靠交互
- 全双工通信
- 面向字节流
TCP 如何保证可靠传输:
- 确认和超时重传
- 数据合理分片和排序
- 流量控制
- 拥塞控制
- 数据校验
3.4.1 TCP报文段结构
TCP 报文结构
TCP头部
字段定义
-
源端口号(16位)
-
目的端口号(16位)
-
序号(32位)TCP的序号是数据流中的字节数,不是分组的序号。表示该报文段数据字段首字节的序号
-
确认号(32位)TCP使用累积确认,确认号是第一个未收到的字节序号,表示希望接收到的下一个字节
-
首部长度(4位)通常选项字段为空,所以一般TCP首部的长度是20字节
-
保留(6位)
-
标志字段(6位)
- ACK:指示确认字段中的值是有效的
- RST,SYN,FIN:连接建立与拆除
- PSH:指示接收方应立即将数据交给上层
- URG:报文段中存在着(被发送方的上层实体置位)“紧急”的数据
-
窗口(16位)
-
校验和(16位)
-
紧急指针(16位)
-
选项
TCP:状态控制码(Code,Control Flag),占 6 比特,含义如下:
- URG:紧急比特(urgent),当
URG=1
时,表明紧急指针字段有效,代表该封包为紧急封包。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据), 且上图中的 Urgent Pointer 字段也会被启用。 - ACK:确认比特(Acknowledge)。只有当
ACK=1
时确认号字段才有效,代表这个封包为确认封包。当ACK=0
时,确认号无效。 - PSH:(Push function)若为 1 时,代表要求对方立即传送缓冲区内的其他对应封包,而无需等缓冲满了才送。
- RST:复位比特(Reset),当
RST=1
时,表明 TCP 连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。 - SYN:同步比特(Synchronous),SYN 置为 1,就表示这是一个连接请求或连接接受报文,通常带有 SYN 标志的封包表示『主动』要连接到对方的意思。
- FIN:终止比特(Final),用来释放一个连接。当
FIN=1
时,表明此报文段的发送端的数据已发送完毕,并要求释放运输连接。
3.4.2 TCP流量控制
概念
流量控制(flow control)就是让发送方的发送速率不要太快,要让接收方来得及接收。
方法
利用可变窗口进行流量控制如果应用程序读取数据相当慢,而发送方发送数据太多、太快,会很容易使接收方的接收缓存溢出,流量控制就是用来进行发送速度和接收速度的匹配。发送方维护一个“接收窗口”变量,这个变量表示接收方当前可用的缓存空间
-
LastByteRead:接收方应用程序从接收缓存中读取的最后一个字节
-
LastByteRcvd:接收方接收到的最后一个字节
要防止缓存溢出,则应该满足如下条件:
LastByteRecv - LastByteRead <= RcvBuffer
接收方可通过下列公式计算RcvWindow:
RcvWindow = RcvBuffer - [LastByteRecv - LastByteRead]
然后将RcvWindow的值记录在TCP报文段中,发送给发送方。发送方轮流跟踪两个变量LastByteSent和LastByteAcked,这两个变量之差就是发送到连接中但未被确认的数据量。通过将其控制在RcvWindow内,就能实现流量控制:
LastByteSent - LastByteAcked <= RcvWindow
这个方案存在一个问题,当接收方缓存已满时,将RcvWindow=0通告给发送方,并且接收方没有任何数据要发送给发送方,随着接收方应用进程清空缓存,TCP并不向发送方发送带有RcvWindow新值的新报文段;TCP仅在它有数据或确认要发送时才会发送报文段。这样,发送方不会知道接收方缓存已经有新的空间,发送方因此被阻塞而不能再发送数据。为解决这个问题,TCP规约中要求:当接收方的接收窗口为0时,发送方继续发送只有1个字节数据的报文段。这些报文段将会被接收方确认。最终缓存将开始清空,并且确认报文里将包含一个非0的RcvWindow值。
3.4.3 TCP连接管理
因为 TCP 三次握手建立连接、四次挥手释放连接很重要。
TCP 三次握手建立连接
【TCP 建立连接全过程解释】
- 客户端发送 SYN 给服务器,说明客户端请求建立连接;
- 服务端收到客户端发的 SYN,并回复 SYN+ACK 给客户端(同意建立连接);
- 客户端收到服务端的 SYN+ACK 后,回复 ACK 给服务端(表示客户端收到了服务端发的同意报文);
- 服务端收到客户端的 ACK,连接已建立,可以数据传输。
TCP 为什么要进行三次握手?
【答案一】因为信道不可靠,而 TCP 想在不可靠信道上建立可靠地传输,那么三次通信是理论上的最小值。(而 UDP 则不需建立可靠传输,因此 UDP 不需要三次握手。)
【答案二】因为双方都需要确认对方收到了自己发送的***,确认过程最少要进行三次通信。
TCP 四次挥手释放连接
【TCP 释放连接全过程解释】
- 客户端发送 FIN 给服务器,说明客户端不必发送数据给服务器了(请求释放从客户端到服务器的连接);
- 服务器接收到客户端发的 FIN,并回复 ACK 给客户端(同意释放从客户端到服务器的连接);
- 客户端收到服务端回复的 ACK,此时从客户端到服务器的连接已释放(但服务端到客户端的连接还未释放,并且客户端还可以接收数据);
- 服务端继续发送之前没发完的数据给客户端;
- 服务端发送 FIN+ACK 给客户端,说明服务端发送完了数据(请求释放从服务端到客户端的连接,就算没收到客户端的回复,过段时间也会自动释放);
- 客户端收到服务端的 FIN+ACK,并回复 ACK 给客户端(同意释放从服务端到客户端的连接);
- 服务端收到客户端的 ACK 后,释放从服务端到客户端的连接。
TCP 为什么要进行四次挥手?
【问题一】TCP 为什么要进行四次挥手? / 为什么 TCP 建立连接需要三次,而释放连接则需要四次?
【答案一】因为 TCP 是全双工模式,客户端请求关闭连接后,客户端向服务端的连接关闭(一二次挥手),服务端继续传输之前没传完的数据给客户端(数据传输),服务端向客户端的连接关闭(三四次挥手)。所以 TCP 释放连接时服务器的 ACK 和 FIN 是分开发送的(中间隔着数据传输),而 TCP 建立连接时服务器的 ACK 和 SYN 是一起发送的(第二次握手),所以 TCP 建立连接需要三次,而释放连接则需要四次。
【问题二】为什么 TCP 连接时可以 ACK 和 SYN 一起发送,而释放时则 ACK 和 FIN 分开发送呢?(ACK 和 FIN 分开是指第二次和第三次挥手)
【答案二】因为客户端请求释放时,服务器可能还有数据需要传输给客户端,因此服务端要先响应客户端 FIN 请求(服务端发送 ACK),然后数据传输,传输完成后,服务端再提出 FIN 请求(服务端发送 FIN);而连接时则没有中间的数据传输,因此连接时可以 ACK 和 SYN 一起发送。
【问题三】为什么客户端释放最后需要 TIME-WAIT 等待 2MSL 呢?
【答案三】
- 为了保证客户端发送的最后一个 ACK 报文能够到达服务端。若未成功到达,则服务端超时重传 FIN+ACK 报文段,客户端再重传 ACK,并重新计时。
- 防止已失效的连接请求报文段出现在本连接中。TIME-WAIT 持续 2MSL 可使本连接持续的时间内所产生的所有报文段都从网络中消失,这样可使下次连接中不会出现旧的连接报文段。
3次握手
1.客户端向服务器发送SYN报文段(不包含应用层数据,首部的一个标志位(即SYN比特)被置位,客户端随机化选择(避免攻击)一个起始序号x)
2.服务器为该TCP连接分配TCP缓存和变量,返回一个SYNACK报文段(也不包含应用层数据,SYN比特被置为1,ACK为x+1,服务器选择自己的初始序列y)
3.客户机为该连接分配缓存和变量,返回一个对SYNACK报文段进行确认的报文段(因为连接已经建立了,所以SYN比特被置为0)
如果客户端不发送ACK来完成第三次握手,最终(通常是一分钟后)服务器将终止该半开连接并回收已分配的资源(在第三次握手前分配缓存和变量,可能会受到SYN洪泛攻击)
如果第二次握手丢包怎么办?第三次呢?——知乎车小胖的回答
-
第二个包,即B发给A的SYN +ACK 中途被丢,没有到达A:B会周期性超时重传,直到收到A的确认
-
第三个包,即A发给B的ACK 中途被丢,没有到达B:A发完ACK,单方面认为TCP为 Established状态,而B显然认为TCP为Active状态
-
假定此时双方都没有数据发送:B会周期性超时重传,直到收到A的确认,收到之后B的TCP 连接也为Established状态,双向可以发包
-
假定此时A有数据发送:B收到A的 Data + ACK,自然会切换为established 状态,并接受A的Data
-
假定B有数据发送:数据发送不了,会一直周期性超时重传SYN + ACK,直到收到A的确认才可以发送数据
SYN洪泛攻击:攻击者发送大量的TCP SYN报文段,而不完成三次握手的第三步。通过从多个源发送SYN能够加大攻击力度,产生DDos(分布式拒绝服务) SYN洪泛攻击 预防:SYN cookies。
- 当服务器接收到一个SYN报文段时,它并不知道该报文段是来自一个合法的用户,还是一个SYN洪泛攻击的一部分。因此服务器不会为该报文段生成一个半开TCP连接。相反,服务器生成一个初始TCP***y,该***是SYN报文段的源和目的IP地址、端口号以及仅被该服务器所知的秘密数的一个散列函数,这种精心制作的初始***被称作“cookie”。服务器发送具有这种特殊***的SYNACK分组,服务器并不记忆该cookie或任何对应于SYN的其他状态信息
SYN cookies预防SYN洪泛攻击:
-
当服务器接收到一个SYN报文段时,它并不知道该报文段是来自一个合法的用户,还是一个SYN洪泛攻击的一部分。因此服务器不会为该报文段生成一个半开TCP连接。相反,服务器生成一个初始TCP***y,该***是SYN报文段的源和目的IP地址、端口号以及仅被该服务器所知的秘密数的一个散列函数,这种精心制作的初始***被称作“cookie”。服务器发送具有这种特殊***的SYNACK分组,服务器并不记忆该cookie或任何对应于SYN的其他状态信息
-
如果客户机是合法的,它将返回一个ACK报文段。服务器一旦收到该ACK,需要验证与前面发送的某些SYN对应的ACK。对于一个合法的ACK,确认字段中的值等于SYNACK序号字段y的值加1。服务器将使用在ACK报文段中的相同字段和秘密数运行相同的函数。如果该函数的结果加1与确认号相同,服务器就认为该ACK对应于前面发送的SYN报文段,生成一个具有套接字的全开的连接
-
如果客户机没有返回一个ACK报文段,则初始化的SYN也没有对该服务器产生危害,因为服务器没有为它分配任何资源
前两次握手不包含有效载荷,第三次“握手”可以承载有效载荷
为什么需要3次握手而不是4次或2次?——知乎车小胖的回答
- 流程
- 客户端发送syn包(syn=x)到服务器,并进入SYN_SEND状态,等待服务器确认;
- 服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;
- 客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vb4ApSJP-1590982812328)(http://img.qiuye.online/18-9-19/67777489.jpg)]
- 为什么需要三次握手,第二次会出现什么问题?
- 防止已经失效的连接请求又被报文段传输到主机,从而产生错误,使得主机持续等待发来的数据,造成资源浪费。
4次挥手
TCP连接的两个进程中任意一个都能终止该连接,连接关闭需要4步。假设客户端发起一个关闭请求:
1.客户端发送一个FIN报文(首部中的FIN比特被置位)
2.服务器返回一个对FIN报文的确认报文
3.服务器发送一个FIN报文(首部中的FIN比特被置位)
4.客户端返回一个对FIN报文的确认报文
MSL(最长分节生命期)是任何IP数据报能够在因特网中存活的最长时间(IP数据报中的TTL首部为8位,具有最大TTL,即255的分组,在网络中存在的时间不能超过MSL)。任何TCP实现都必须为MSL选择一个值。RFC 1122的建议值是2分钟,不过源自Berkeley的实现传统上改用30秒。意味着TIME_WAIT状态的持续时间再1分钟到4分钟之间
四次挥手是因为TCP是全双工的,前2次挥手用于关闭一个方向的数据通道,后两次挥手用于关闭另外一个方向的数据通道
TIME-WAIT状态的详细说明,主要有2个存在的理由:
-
可靠地实现TCP全双工连接的终止
-
等待迷途分组在网络中消逝
nmap:可以“侦察”打开的TCP接口、UDP接口;还能“侦察”防火墙及其配置;甚至能“侦察”应用程序及操作系统版本。
-
流程
- 主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送,也就是主动关闭方告诉被动关闭方:我已经不会再给你发数据了(当然,在fin包之前发送出去的数据,如果没有收到对应的ack确认报文,主动关闭方依然会重发这些数据),但是,此时主动关闭方还可以接受数据。
- 被动关闭方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号)。
- 被动关闭方发送一个FIN,用来关闭被动关闭方到主动关闭方的数据传送,也就是告诉主动关闭方,我的数据也发送完了,不会再给你发数据了。
- 主动关闭方收到FIN后,发送一个ACK给被动关闭方,确认序号为收到序号+1,至此,完成四次挥手。
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1yNwEXJh-1590982812328)(http://img.qiuye.online/18-9-19/89768478.jpg)]
-
为什么需要四次挥手,为什么要等2msl再关闭?
- TCP是全双工通信,主动断开方发送FIN并不意味着立即关闭TCP连接,而是告诉对方自己没有更多的数据要发送了,只有当对方发完自己的数据再发送FIN后,才意味着关闭TCP连接;
-
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)后进入拥塞避免状态。
- 如果出现超时事件,快速恢复在执行如同在慢启动和拥塞避免中相同的动作后,迁移到慢启动状态。
- 慢启动:
-
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攻击是什么,怎么处理?
3.4.4 TCP拥塞控制
概念
拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。
方法
- 慢开始( slow-start )
- 拥塞避免( congestion avoidance )
- 快重传( fast retransmit )
- 快恢复( fast recovery )
拥塞控制分类:
-
端到端拥塞控制:网络层没有为运输层拥塞控制提供显示支持(TCP的拥塞控制)
-
网络辅助的拥塞控制:网络层组件向发送方提供关于网络中拥塞状态的显式反馈信息(ATM ABR)
-
直接反馈:路由器通过阻塞分组直接通知发送方拥塞
-
路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞,接收方收到后通知发送方
由于IP层不向端系统提供显示的网络拥塞反馈,所以TCP必须使用端到端拥塞控制,而不是网络辅助拥塞控制
TCP连接的两方都记录一个额外的变量:拥塞窗口(CongWin),它对一个TCP发送方能向网络中发送流量的速率进行了限制。特别是,在一个发送方中未被确认的数据量不会超过CongWin与RcvWindow中的最小值:
LastByteSent - LastByteAcked <= min{CongWin,RcvWindow}
后面的分析假设TCP接收缓存足够大,因此不受RcvWindow的限制,从而可以只关注拥塞窗口
两个拥塞指示:
-
3次冗余ACK(第一次冗余是第二次收到相同ACK时,所以一共4次)
-
超时
TCP拥塞控制算法包括三个主要部分:
1.加性增、乘性减
-
加性增:缓慢增加CongWin,每个RTT增加1个MSS,线性增长(拥塞避免)
-
乘性减:发生丢包时,设置CongWin = CongWin/2(不低于1个MSS),从而控制发送速度
2.慢启动:TCP连接开始时,CongWin的初始值为1个MSS,指数型增长
3.对拥塞指示作出反应
-
3次冗余ACK:CongWin = CongWin/2,然后线性增加(拥塞避免)
-
超时:CongWin被设置为1个MSS,然后指数增长,直到CongWin达到超时前的一半为止
Threshold(阈值):用于确定慢启动将结束并且拥塞避免将开始的窗口长度,初始化为一个很大的值,每当发送一个丢包时,会被设置为丢包时CongWin的一半
3.4.5 TCP的应用场景
- web:HTTP 80
- 文件传输:FTP 21 20
- 电子邮件:SMTP 25 POP3 110
- 远程终端访问:TELNET 23 RDP 3389 远程桌面协议
如何保证可靠传输?
- 差错检测、确认、重传
- 序号(解决ACK受损的问题,判断是否为重传的):
- 接收端收到冗余分组则丢弃
- 发送端收到冗余ACK则重传
- 定时器
如何检验丢包?
- 校验和、确认分组、超时重传、序号
如何保证TCP的可靠传输?
- 检验和、重传、积累确认、序号、确认号、定时器
TCP协议有几大计时器
-
重传计时器
在一个TCP连接中,TCP每发送一个报文段,就对此报文段设置一个超时重传计时器。若在收到了对此特定报文段的确认之前计时器截止期到,则重传此报文段,并将计时器复位。
-
持续计时器
为了对付零窗口大小通知,TCP需要另一个计时器。假定接收TCP宣布了窗口大小为零。发送TCP就停止传送报文段,直到接收TCP发送确认并宣布一个非零的窗口大小。但这个确认可能会丢失。我们知道在TCP中,对确认是不需要发送确认的。若确认丢失了,接收TCP并不知道,而是会认为它已经完成任务了,并等待着发送TCP接着会发送更多的报文段。但发送TCP由于没有收到确认,就等待对方发送确认来通知窗口的大小。双方的TCP都在永远地等待着对方。要打开这种死锁,TCP为每一个连接使用一个坚持计时器。当发送TCP收到一个窗口大小为零的确认时,就启动坚持计时器。当坚持计时器期限到时,发送TCP就发送一个特殊的报文段, 叫做 探测报文段 。这个报文段只有一个字节的数据。它有一个序号,但它的序号永远不需要确认;甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒对端:确认已丢失,必须重传。
- 保活计时器
保活计时器使用在某些实现中,用来防止在两个TCP之间的连接出现长时期的空闲。假定客户打开了到服务器的连接,传送了一些数据,然后就保持静默了。也许这个客户出故障了。在这种情况下,这个连接将永远地处理打开状态。
- 时间等待计时器
时间等待计时器是在连接终止期间使用的。当TCP关闭一个连接时,它并不认为这个连接马上就真正地关闭了。在时间等待期间中,连接还处于一种中间过渡状态。这就可以使重复的FIN报文段(如果有的话)可以到达目的站因而可将其丢弃。这个计时器的值通常设置为一个报文段的寿命期待值的两倍。
3.4.6 TCP 黏包问题
原因
TCP 是一个基于字节流的传输服务(UDP 基于报文的),“流” 意味着 TCP 所传输的数据是没有边界的。所以可能会出现两个数据包黏在一起的情况。
解决
- 发送定长包。如果每个消息的大小都是一样的,那么在接收对等方只要累计接收数据,直到数据等于一个定长的数值就将它作为一个消息。
- 包头加上包体长度。包头是定长的 4 个字节,说明了包体的长度。接收对等方先接收包头长度,依据包头长度来接收包体。
- 在数据包之间设置边界,如添加特殊符号
\r\n
标记。FTP 协议正是这么做的。但问题在于如果数据正文中也含有\r\n
,则会误判为消息的边界。 - 使用更加复杂的应用层协议。
3.4.7 TCP 有限状态机
TCP 有限状态机图片3.5 UDP
- UDP(User Datagram Protocol,用户数据报协议)是 OSI(Open System Interconnection 开放式系统互联) 参考模型中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务,其传输的单位是用户数据报。
特征:
- 无连接
- 尽最大努力交付
- 面向报文
- 没有拥塞控制
- 支持一对一、一对多、多对一、多对多的交互通信
- 首部开销小
UDP 报文结构
UDP 首部
TCP/UDP 图片来源于:<https://github.com/JerryC8080/understand-tcp-udp
3.5.1 UDP实现的工作
- 复用/分解:通常应用
程序客户端自动分配端口号,服务器端分配一个特定的端口号 - 差错检测:端到端原则,在较低级别设置该功能是冗余的,没有差错恢复
3.5.2 UDP的优点
- 应用层可以更精细的控制何时发送什么数据(TCP拥塞时会遏制发送方发送)
- 无需建立连接,则没有建立连接的时延
- 不必维护连接状态:TCP要维护包括接收和发送缓存、拥塞控制参数、以及序号与确认号的参数
- 分组首部开销小:UDP有8字节首部,TCP有20字节首部
可以在应用程序自身中构建可靠性机制来实现UDP应用的可靠数据传输。
UDP能提供运输层最低限度的两个服务:差错检测、数据交付。
3.5.3 UDP报文段结构
UDP首部只有4个字段,每个字段2个字节,一共8个字节大小的首部
校验和:对报文段中的所有16比特字(包括数据部分,不包括校验和本身)的和相加(如有溢出会卷回)的结果取反就是校验和。在接收方,会将所有16比特字的和相加,如果分组无差错,这个和会是“1111-1111-1111-1111”(为了方便阅读,使用’-’分隔)
许多链路层协议提供了差错检测,UDP还需提供校验和的原因在于,不能确保所有链路都提供了差错检测。此外,即使报文段经链路正确地传输,当其存储在某台路由器的内存中时,也可能引入比特差错。既未确保逐段链路的可靠性,也未确保内存中的差错检测,因此UDP必须在端到端基础上在运输层提供差错检测
校验和方法需要相对小的分组开销。例如,TCP和UDP中的校验和只用了16比特。然而与常用于链路层的CRC(循环冗余检测)相比,他们提供相对弱的差错保护。传输层使用校验和而链路层使用CRC的原因是:运输层通常在主机中作为用户操作系统的一部分并用软件实现,因此采用简单而快速(如校验和)的差错检测方案是重要的。另一方面,链路层的差错检测在适配器中用专业硬件实现,它能快速地执行更复杂的CRC操作。
- 字段含义
- 源端口号(16位)
- 目的端口号(16位)
- UDP长度(16位):冗余的,IP头部已经提供数据报长度和首部长度
- UDP检验和(16位):传送中不会被修改,除非遇到NAT,计算时加入伪头部,包含源IP与目的IP,以验证是否正确的到达目的地
- 数据
3.5.4 UDP的应用场景
- 域名地址转换:DNS
- 路由选择表的更新:RIP
- 远程文件服务器:NFS
- 网络管理数据:SNMP
- TFTP 简单文件传输协议 不支持身份认证
- DHCP
UDP为什么不可靠,怎么解决UPD的可靠性问题?
- 不需要建立连接就可以开始传输,没有确保传递和流量控制机制,没有拥塞控制机制。
- 要在应用层实现类似与TCP的可靠连接的技术,比如确认与重传机制。
2.UDP中一个包的大小最大能多大?
-
以太网(Ethernet)数据帧的长度必须在46-1500字节之间,这是由以太网的物理特性决定的.这个1500字节被称为链路层的MTU(最大传输单元).但这并不是指链路层的长度被限制在1500字节,其实这这个MTU指的是链路层的数据区.
-
并不包括链路层的首部和尾部的18个字节.所以,事实上,这个1500字节就是网络层IP数据报的长度限制.因为IP数据报的首部为20字节,所以IP数据报的数据区长度最大为1480字节.
-
而这个1480字节就是用来放TCP传来的TCP报文段或UDP传来的UDP数据报的.又因为UDP数据报的首部8字节,所以UDP数据报的数据区最大长度为1472字节.这个1472字节就是我们可以使用的字节数。
为什么UDP有时比TCP更有优势?
-
网速的提升给UDP的稳定性提供可靠网络保障,丢包率很低,如果使用应用层重传,能够确保传输的可靠性。
-
TCP为了实现网络通信的可靠性,使用了复杂的拥塞控制算法,建立了繁琐的握手过程,由于TCP内置的系统协议栈中,极难对其进行改进。
-
采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收到后再继续发送,延时会越来越大,基于UDP对实时性要求较为严格的情况下,采用自定义重传机制,能够把丢包产生的延迟降到最低,尽量减少网络问题对游戏性造成影响。
TCP 与 UDP 的区别
- TCP 面向连接,UDP 是无连接的;
- TCP 提供可靠的服务,也就是说,通过 TCP 连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP 尽最大努力交付,即不保证可靠交付
- TCP 的逻辑通信信道是全双工的可靠信道;UDP 则是不可靠信道
- 每一条 TCP 连接只能是点到点的;UDP 支持一对一,一对多,多对一和多对多的交互通信
- TCP 面向字节流(可能出现黏包问题),实际上是 TCP 把数据看成一连串无结构的字节流;UDP 是面向报文的(不会出现黏包问题)
- UDP 没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如 IP 电话,实时视频会议等)
- TCP 首部开销20字节;UDP 的首部开销小,只有 8 个字节
4.网络层
- IP(Internet Protocol,网际协议)是为计算机网络相互连接进行通信而设计的协议。
- ARP(Address Resolution Protocol,地址解析协议)
- ICMP(Internet Control Message Protocol,网际控制报文协议)
- IGMP(Internet Group Management Protocol,网际组管理协议)
4.1网络层功能和服务
网络层的3个重要功能:
1.转发:当一个分组到达某路由器的一条输入链路时,路由器将分组移动到适当输出链路的过程
2.选路:当分组从发送方传至接收方时,网络层决定这些分组所采用的路由或路径的过程
3.连接建立:ATM等非因特网的网络层体系结构要求从源到目的地沿着所选的路径建立连接
虚电路和数据报网络:
-
虚电路(VC)网络:面向连接的,数据按需到达,分组不会丢失,路由器为进行中的连接维持连接状态信息
-
数据报网络:无连接的,但在转发表中维持了转发状态信息。因特网是数据报网络(数据报网络中,通常每1~5分钟左右更新一次转发表,因为转发表会被修改,所以从一个端系统到另一个端系统发送一系列分组可能在通过网络时走不同的路径,从而无序到达)
4.2转发
使用最长前缀匹配来匹配路由表中的表项,决定转发出口
路由器
路由器由4部分组成:
-
输入端口
-
交换结构
-
输出端口
-
选路处理器:维护有选路信息与转发表,并执行路由器中的网络管理功能
1)输入端口
- 查找/转发模块:对于路由器的转发功能是至关重要的。许多路由器中,都是在这确定一个到达的分组经交换结构转发到哪个输出端口。虽然转发表是由选路处理器计算的,但通常一份转发表的影子拷贝会被存放在每个输入端口,而且会被更新。因此,就可以在每个输入端口本地做出转发决策,而无需调用*选路处理器,从而可以避免在路由器中的某个单点产生转发处理的瓶颈
2)交换结构
一个分组可能会在进入交换结构时暂时阻塞,这是由于来自其它输入端口的分组正在使用该交换结构
-
经内存交换:分组到达输入端口时,端口会通过中断向选路处理器发出信号,于是分组被拷贝到处理器内存中。选路处理器则从分组首部中取出目的地址,在转发表中找出适当的输出端口,并将分组拷贝到输出端口的缓存中
-
经一根总线交换:经一根共享总线将分组直接传送到输出端口,不需要选路处理器的干预。因为总线是共享的,故一次只能有一个分组通过总线传送
-
经一个互连网络交换:到达某个输入端口的分组沿着连到输入端口的水平总线穿行,直至该水平总线与连到所希望的输出端口的垂直总线的交叉点
3)输出端口
输出端口处理取出存放在输出端口内存中的分组并将其传输到输出链路上。当交换结构将分组交付给输出端口的速率超过输出链路速率时,就需要排队与缓存管理功能
4)排队
输入端口和输出端口都能形成分组队列,随着队列的增长,路由器的缓存空间将会最终耗尽,出现丢包
输出端口排队:当所有输入端口的分组发往同一个输出端口并且交换结构速率足够大而输出端口的分组传输速率不高时,分组会在该输出端口排队。排队的后果是,输出端口上的一个分组调度程序必须在这些排队的分组中选一个来传送,分组调度程序在提供服务质量保证方面起着关键作用
输入端口排队:如果交换结构速率不高,不同输入端口的队首分组需要发往同一个输出端口,此时交换结构需要选择其中一个输入端口的分组进行发送。因此,其它输入端口中的分组会阻塞产生排队。在队首分组之后的分组,也会因为队首分组阻塞而被阻塞,即使它们需要转发到的输出端口此时处于空闲。这种现象叫做作线路前部阻塞(HOL)
4.3选路
-
第一跳路由器 = 默认路由器 = 源路由器
-
目的路由器:目的主机的默认路由器
源主机到目的主机选路的问题可归结为从源路由器到目的路由器的选路问题
4.3.1 全局选路算法(LS算法)
全局选路算法用完整的、全局性的网络信息来计算从源到目的地之间的最低费用路径。由于具有全局状态信息,所以这种算法又常被称为链路状态算法
- Dijkstra算法
4.3.2 分布式选路算法(距离向量算法)
以迭代的、分布式的方式计算出最低费用路径。和全局选路算法的区别在于,没有节点拥有关于所有网络链路费用的完整信息,每个节点仅有与其直接相连链路的费用信息
- 距离向量算法(DV)
– 分布式:每个节点从一个或多个直接相连的邻居接收某些信息,执行计算,然后将计算结果发回邻居
– 迭代:上述过程持续到邻居之间没有更多的信息要交换为止
– 异步:不要求所有节点相互之间步伐一致
DV使用公式:dx(y) = minv{c(x,v)+dv(y)} 更新x到y的距离(dx(y)是从x到y的最低费用路径的费用,minv是指取遍x的所有邻居)
好消息传的快,坏消息传的慢:
- 好消息传的快
– t0时:y检测到距x的费用由4变为1,更新其距离向量,并通知邻居
– t1时:z收到来自y的更新报文并更新了其距离向量,计算出到x的新最低费用(5减为2)
– t2时:y收到来自z的更新并更新其距离表,y的最低费用未改变,不发送报文,算法终止
- 坏消息传的慢
– t0时:y检测到距x的费用由4变为60,y更新其到x的距离为6(途经z,因为z的距离表中记录到x的距离为5),这是分布式的角度,从全局角度看,这个距离是错的,但分布式中节点的状态信息有效。开始出现选路环路,即为到达x,y通过z选路,z又通过y选路,不停来回反复
– t1时:y将到达x的新费用告知z
– t2时:z收到y的消息,z计算出从x到x是50,从y到x是7,所以更新到x的最低费用为7,并通知y这个改变
– 上述过程会一直反复,直到z最终算出它经由y的路径费用大于50为止(此时到x不途经y),y将经由z到x(如果费用增加到10000甚至更多,开销可想而知)
4.3.3 因特网中的选路
随着路由器数目变大,选路信息的计算、存储及通信的开销逐渐高得惊人,数亿台主机中存储选路信息需要巨大容量的内存。在公共因特网上所有路由器上广播LS更新的开销将导致没有剩余带宽供发送数据分组使用。距离向量算法在如此大的路由器中的迭代将肯定永远不会收敛。可以将路由器组织成自治系统(AS)来解决
自治系统(AS):一组处于相同的管理与技术控制下的路由器集合(ISP和AS之间是什么关系?通常一个ISP中的路由器和互连它们的链路构成了单个AS,但许多ISP将它们的网络划分为多个AS)
因特网中的选路协议:
-
AS之间
-
边界网关协议(BGP/BGP4)
-
BGPv4是一种外部的路由协议。可认为是一种高级的距离向量路由协议。
-
路由器对使用179端口的半永久TCP连接交换选路信息
-
每条TCP连接的两台路由器被称为BGP对等方
-
发送BGP报文的“TCP连接”称为BGP会话(跨越两个AS之间的BGP会话称为eBGP,同一AS中两个路由器间的BGP会话称为内部BGP会话)
-
BGP中,目的地是CIDR化的前缀,表示一个子网或子网集合(假设有多个子网与一个AS相连,AS会聚合这些前缀,来向相邻的AS通告聚合后的单一前缀,如果到达相同前缀有多个路由,BGP会使用一些规则消除直到留下一条路由)
-
在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传播路由占用的带宽。
- 提供了丰富的路由策略。
-
-
-
AS内部
-
选路信息协议(RIP)
-
运行于UDP之上的应用层协议
-
使用DV选路算法,使用跳数作为费用测度,“跳”是从源路由器到目的子网的子网数,一条路径的最大费用被限制为15,从而限制了使用RIP的AS规模。
-
大约每30秒通过RIP响应报文(也称为RIP通告)交换距离向量信息
-
距离矢量协议
- 距离向量:RIP发送的报文包含一个距离向量(跳数)。每个路由器都根据它接收到邻站的这些距离向量来更新自己的路由表。
-
工作过程
-
初始化:在启动一个路由守护程序时,它先判断启动了哪些接口,并在每个接口上发送一个请求报文,要求其他路由器发送完整路由表。在点对点链路中,该请求是发送给其他终点的。如果网络支持广播的话,这种请求是以广播形式发送的。目的UDP端口号是520(这是其他路由器的路由守护程序端口号)
-
接收到请求:如果这个请求是刚才提到的特殊请求,那么路由器就将完整的路由表发送给请求者。否则,就处理请求中的每一个表项:如果有连接到指名地址的路由,则将度量设置成我们的值,否则将度量值设为16(度量为16是一种称为"无穷大"的特殊值,它意味着没有到达目的的路由)。然后发出响应。
-
接收到响应:使响应生效,可能会更新路由表。可能会增加新表项,对已有表项进行修改,或者将已有表项删除。
-
定期选路更新:每过30秒,所有或部分路由器会将其完整路由表发送给相邻路由器。发送路由表可以是广播形式的(如在以太网上),或是发送给点对点链路的其他终点。
-
触发更新:每当一条路由的度量发生变化时,就对它进行更新。不需要发送完整的路由表,而只需要发送那些变化的表项。每条路由都有与之相关的定时器。如果运行RIP的系统发现一条路由在
3分钟内未更新,就将该路由的度量设置成无穷大( 16),并标注为删除。这意味着已经在 6个30秒更新时间里没收到通告该路由的路由器的更新了。再过 60秒,将从本地路由表中删除该路由,以保证该路由的失效已被传播开。
-
-
RIP的优缺点
- 算法简单,配置简单,适合用在小型网络之中
- 无法区分非零部分是子网部分还是主机地址
- 这种方法看起来很简单,但它有一些缺陷。首先,RIP没有子网地址的概念。例如,如果标准的B类地址中16bit的主机号不为0,那么RIP无法区分非零部分是一个子网号,或者是一个主机地址。有一些实现中通过接收到的RiP信息,来使用接口的网络掩码,而这有可能出错。
- 可能会发生路由环路在路由器或链路发生故障后,需要很长的一段时间才能稳定下来。这段时间通常需要几分钟。在这段建立时间里,可能会发生路由环路。在实现RIP时,必须采用很多微妙的措施来防止路由环路的出现,并使其尽快建立。
- 度量最大为15,限制网络大小
- 采用跳数作为路由度量忽略了其他一些应该考虑的因素。同时度量最大值为15,则限制了可以使用RIP的网络的大小。
-
-
开放最短路径优先(OSPF):直接作为IP协议的载荷
-
直接承载在IP分组中,必须自己实现可靠报文传输、链路状态广播等功能
-
使用LS选路算法,链路费用是由网络管理员配置的
-
通常用于较顶层的ISP中,而RIP通常用于较低层的ISP中
-
至少每隔30分钟广播一次链路状态(即使状态未发生改变)
-
核心是一个使用泛洪链路状态信息的链路状态协议和一个Dijkstra最低费用路径算法。每个路由器主动地测试与其邻站相连链路的状态,将这些信息发送给它的其他邻站,而邻站将这些信息在自治系统中传播出去。每个路由器接收这些链路状态信息,并建立起完整的路由表。
-
OSPF与RIP的不同
- 链路状态协议比距离向量协议收敛的更快。收敛的意思是在路由发生变化后,例如在路由关闭或链路出故障后,可以稳定下来。
- OSPF直接使用IP,对于IP首部的protocol字段,OSPF有其自己的值。
-
OSPF较RIP的优点
-
OSPF可以对每个IP服务类型计算各自的路由集。这意味着对于任何目的,可以有多个路由表表项,每个表项对应着一个IP服务类型。
-
给每个接口指派一个无维数的费用。可以通过吞吐率、往返时间、可靠性或其他性能来进行指派。可以给每个IP服务类型指派一个单独的费用。
-
当对同一个目的地址存在着多个相同费用的路由时,OSPF在这些路由上平均分配流量。我们称之为流量平衡。
-
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 是基于跳数的路由协议,以跳数作为选路的依据
- ospf
-
4.4 IP(网际协议)
IP 地址分类:
IP 地址 ::= {<网络号>,<主机号>}
IP 地址类别 | 网络号 | 网络范围 | 主机号 | IP 地址范围 |
---|---|---|---|---|
A 类 | 8bit,第一位固定为 0 | 0 —— 127 | 24bit | 1.0.0.0 —— 127.255.255.255 |
B 类 | 16bit,前两位固定为 10 | 128.0 —— 191.255 | 16bit | 128.0.0.0 —— 191.255.255.255 |
C 类 | 24bit,前三位固定为 110 | 192.0.0 —— 223.255.255 | 8bit | 192.0.0.0 —— 223.255.255.255 |
D 类 | 前四位固定为 1110,后面为多播地址 | |||
E 类 | 前五位固定为 11110,后面保留为今后所用 |
IP 数据报格式:
4.4.1 因特网三大组件
1.IP协议
2.选路组件
3.报告数据报中的差错和对某些网络层信息请求进行响应的设施
4.4.2 数据报格式
下图为一个IPv4数据报的格式:
-
版本号:IP协议的版本,路由器根据版本号确定如何解释剩余部分
-
首部长度:一个IPV4数据报可包含一些可选项,所以需要用4比特确定数据部分实际从哪开始,大多数IP数据报不包含可选项,有20字节的首部
-
服务类型:可以使不同类型(实时与非实时等)的IP数据报区分开来
-
数据报长度:IP数据报的总长(16bit,首部+数据,所以IPv4数据报的最大大小是65535字节)
-
寿命(TTL):8位,用以确保数据报不会永远在网络中循环,每经过一台路由器减1,减为0时丢弃
-
上层协议:指明了数据部分应该交给哪个运输层协议(UDP(6)、TCP(17))
-
首部校验和:首部中每2个字节作为一个数,和的反码存入校验和字段中。路由器一般会丢弃检测出的错误数据报。每台路由器上都必须重新计算并更新校验和,因为TTL及选项字段可能会改变
-
选项:在IPv6中已不再使用
除此之外,首部中的以下3个字段用于IP数据报分片的标识
-
标识:识别分片的序号
-
标志:最后一个分片的标志为0,其余分片的标志为1(设置DF位表示不允许分片,可用于路径MTU发现)
-
比特片偏移:该分片起始数据在原数据报中的偏移量/8
IPv4要求的最小链路MTU是68字节,这允许最大IPv4首部(20字节固定长度+最多40字节选项部分)拼接最小的片段(IPv4首部中片段偏移字段以8个字节为单位)
4.4.3 IP数据报分片
一个链路层帧能承载的最大数据量叫做最大传输单元(MTU)(以太网可承载不超过1500字节的数据),因为每个IP数据报封装在链路层帧中,再从一台路由器运输到下一台路由器,故链路层协议MTU严格地限制着IP数据报的长度。发送方与目的地路径上的每段链路可能使用不同的链路层协议,每种协议可能具有不同的MTU,如果转发表查找决定的出链路的MTU比该IP数据报的长度小,则需要对IP数据报进行分片。片在到达目的地运输层以前需要被组装,如果一个或多个片没有到达目的地,则该不完整的数据报被丢弃
分片可以通过4.2中介绍的IP数据报中的标识、标志、比特片偏移来识别
4.4.4 IPv4编址
主机与物理链路之间的边界叫做接口,一个IP地址在技术上是与一个接口相关联的,而不是与包括该接口的主机或路由器相关联的
IP地址编址格式:点分十进制,一个接口的IP地址的组成部分需要由其连接的子网来决定。互连主机的接口与路由器一个接口的网络形成一个子网:
IP编址为子网分配一个地址:223.1.1.0/24,其中/24记法称为子网掩码。其它要连到223.1.1.0/24网络的主机都要求其地址形式为223.1.1.xxx
除此之外,子网还包括互连路由器接口的网段
1)分类编制
在无类别域间选路之前,IP地址的分配策略采用分类编制,网络分为下面3类
-
A类网络:网络部分被限制长度为8比特
-
B类网络:网络部分被限制长度为16比特
-
C类网络:网络部分被限制长度为24比特
分类编制的问题在于:对于一个组织,分配一个B类网络可能太大,分配一个C类网络可能太小,这样分配B类网络就会造成地址空间的迅速消耗,以及大量的地址浪费。这个问题类似于操作系统内存管理中固定分区的问题
2)无类别域间选路(CIDR)
32比特的IP地址被划分为2部分,a.b.c.d/x,前x比特构成了IP地址的网络部分,被称为该地址的网络前缀
组织外部的路由器仅考虑前缀比特,大大减少了路由器中的转发表的长度。剩余32-x比特用于区分组织内部设备,当组织内部的路由器转发分组时,才会考虑这些比特
IP地址由因特网名字与号码分配机构(ICANN)管理,非盈利的ICANN不仅分配IP地址,还管理DNS根服务器、解决分配域名与域名纠纷,ICANN向地区性因特网***构分配地址,这些机构一起形成了ICANN地址支持组织,处理本地域内的地址分配/管理
4.4.5 DHCP(动态主机配置协议)
一个组织一旦获得一块地址,就可以为该组织内的主机和路由器接口分配独立的IP地址
DHCP可以提供以下服务:
-
为主机分配IP地址
-
获取子网掩码
-
获取第一跳路由器地址(常称为默认网关)
-
提供本地DNS服务器的地址(记录在/etc/resolv.conf文件中)
由于DHCP具有能将主机连接进一个网络的自动化网络相关方面的能力,故它又常被称为即插即用协议
每个子网拥有一台DHCP服务器,如果某个子网没有DHCP服务器,则需要一个知道用于该网络的一台DHCP服务器地址的DHCP中继代理(通常是一台路由器)
DHCP协议的4个步骤:
1.DHCP服务器发现:新到的客户端在68号端口使用UDP广播(255.255.255.255)DHCP发现报文,源地址为0.0.0.0
2.DHCP服务器提供:子网中收到DHCP请求报文的DHCP服务器使用DHCP提供报文作出响应,提供IP地址、网络掩码、IP地址租用期(通常设置为几个小时或几天)
- DHCP请求:客户端从多个服务器的响应中选择一个,并用一个DHCP请求报文对选中的服务器进行响应,回显配置参数(这一步目的地址使用广播地址是因为在DHCP服务器提供时,服务器为客户预分配了IP地址,因此,客户有责任通知不采用的服务器,好让它们释放预分配的地址)
4.DHCP ACK:服务器用DHCP ACK报文对DHCP请求报文进行响应,证实所要求的参数
DHCP有不足之处:每当一个节点连到一个新子网时,都要从DHCP得到一个新的IP地址,这样当一个移动节点在子网直接移动时,就不能维持与远程应用之间的连接。移动IP是一种对IP基础设施的扩展,允许移动节点在子网之间移动时能使用其单一永久的地址
4.4.6 NAT(网络地址转换)
NAT适用这样一种场景:由于每个IP使能的设备都需要一个IP地址,如果一个子网已经获得了一块IP地址,当连入设备增加时,IP地址可能不足
NAT主要通过NAT使能路由器来解决上述问题。同时,地址空间10.0.0.0/8是在RFC 1918中保留的3部分IP地址空间之一,可以用于专用网络或具有专用地址的地域(具有专用地址的地域是指其地址仅对该网络中的设备有意义的网络),关键问题是:专用地址对于外部网络无效,使用专用地址的设备如何与外部网络通信?为了解决这个问题,NAT使能路由器中保存有一个NAT转换表:
NAT使能路由器对外界的行为就像一个具有单一IP地址的单一设备,通过端口号来标识一个使用专用地址的设备
-
当专用设备与外界通信时,NAT使能路由器为其生成一个新的源端口号,并使用连入广域网一侧接口的IP地址作为源地址发送数据报,同时会将这个映射关系记录在NAT转换表中
-
当有数据报到达时,NAT使能路由器通过查找NAT转换表中的映射关系,改写目的IP和端口号,向专用网络转发数据报
私有IP网段:
-
10.0.0.0 ~ 10.255.255.255
-
172.16.0.0 ~ 172.31.255.255
-
192.168.0.0 ~ 192.168.255.255
NAT有很多争议:1)端口号是用于编址进程的方法,不是用于编址主机的;2)路由器应该处理最多达第三层的分组;3)NAT违反了所谓的“端到端原则”;4)解决IP地址短缺的方法应该是IPv6,而不是像NAT这样一种权宜之计;但是不管喜欢与否,NAT已成为因特网一个重要的组件
4.4.7 ICMP(互联网控制报文协议)
ICMP 报文格式:
应用:
- PING(Packet InterNet Groper,分组网间探测)测试两个主机之间的连通性
- TTL(Time To Live,生存时间)该字段指定 IP 包被路由器丢弃之前允许通过的最大网段数量
ICMP用于主机和路由器彼此交互网络层信息。最典型的用途是差错报告,但其用途不仅限于此(如源抑制,用于拥塞控制)
ICMP通常被认为是IP的一部分,但从体系结构上讲,它是位于IP之上,因为ICMP报文承载在IP分组中,作为IP有效载荷
ICMP的类型和编码:
Traceroute:允许用户跟踪从一台主机到世界上任意一台其他主机之间的路由,使用ICMP报文实现。发送一系列不可达UDP端口号的UDP报文段,每个报文段封装后的数据报TTL字段逐1递增,TTL为n的数据报到达第n跳路由器时,由于TTL过期,路由器会生成ICMP报文响应,由此可以获得第n跳路由器的IP和名字,当一个数据报最终到达目的主机时,由于UDP端口不可达,目的主机生成一个ICMP报文,指示此错误信息,从而Traceroute知道不需要再发送探测分组了,因此获得了到达目的主机的所有路由数量、标识以及RTT。
4.4.8 IPv6
1)IPv6数据报格式
IPv6引入了称为任播地址的新地址,这种地址可以使一个数据报能交付给一组主机中的任意一个
定长的40字节首部允许更快的处理IP数据报
-
版本号:IPv6将该字段值设置为6
-
流量类型:与IPv4中的”服务类型“字段含义相同,区分不同类型数据报(实时/非实时)
-
有效载荷:数据部分的字节数(16bit,不包括首部,所以IPv6数据报的最大大小是65535+40=65575字节)
-
下一个首部:应该交付给运输层的哪个协议
-
跳限制:同TTL
IPv6不允许在中间路由器上进行分片与重新组装,这种操作只能在源与目的地上进行。如果一台路由器收到的IPv6数据报因太大而不能转发到出链路上,则只需丢掉该数据报,并返回一个”分组太大“的ICMP差错报文。因此IPv6中没有IPv4用于分片相关的3个字段
IPv6的关注快速处理分组,由于运输层提供了差错检测,IP设计者可能觉得没必要再在网络层进行差错检测,所以去掉了首部校验和字段
IPv4中的选项字段并没有作为IPv6的首部字段出现,但其并未消失,而是可能出现在可能出现在首部中由”下一个首部“指出的位置上
IPv6要求的最小链路MTU为1280字节,IPv6可以运行在MTU小于此最小值的链路上,不过需要特定于链路的分片和重组功能,以使得这些链路看起来具有至少为1280字节的MTU。IPv6只有主机对其产生的数据报分片,IPv6路由器不对其转发的数据报执行分片
2)从IPv4向IPv6迁移
虽然能处理IPv6的系统可做成向后兼容的,即能发送和接收IPv4数据报,但已设置的IPv4使能的系统不能处理IPv6数据报,要解决这个问题可以使用双栈(即IPv6节点也具有完整的IPv4实现,这样的节点在RFC 4213中被称为IPv6/IPv4节点)
一种双栈方法是建隧道:
假定2个IPv6节点要使用IPv6通信(图中的B和E),但经由IPv4路由器而互连,将中间IPv4路由器的集合称为一个隧道
借助于隧道,在该隧道发送端的IPv6节点可将整个IPv6数据报放在一个IPv4数据报的数据字段中。于是该IPv4数据报的目的地址设为隧道接收端的IPv6节点(同时具有IPv6和IPv4地址),然后通过隧道传输,隧道接收端的IPv6节点E最终收到该IPv4数据报,并确定IPv4数据报含有一个IPv6数据报,提取出后再为IPv6数据报选路,转发
为什么TCP/IP在运输层与网络层都执行差错检测?
IP层只对IP首部计算检验和,TCP/UDP检验和是对整个报文段进行的
- TCP/UDP与IP不一定同属于一个协议栈
内部网关协议
- RIP(Routing Information Protocol,路由信息协议)
- OSPF(Open Sortest Path First,开放最短路径优先)
外部网关协议
- BGP(Border Gateway Protocol,边界网关协议)
IP多播
- IGMP(Internet Group Management Protocol,网际组管理协议)
- 多播路由选择协议
VPN 和 NAT
- VPN(Virtual Private Network,虚拟专用网)
- NAT(Network Address Translation,网络地址转换)
路由表包含什么?
- 网络 ID(Network ID, Network number):就是目标地址的网络 ID。
- 子网掩码(subnet mask):用来判断 IP 所属网络
- 下一跳地址/接口(Next hop / interface):就是数据在发送到目标地址的旅途中下一站的地址。其中 interface 指向 next hop(即为下一个 route)。一个自治系统(AS, Autonomous system)中的 route 应该包含区域内所有的子网络,而默认网关(Network id:
0.0.0.0
, Netmask:0.0.0.0
)指向自治系统的出口。
根据应用和执行的不同,路由表可能含有如下附加信息:
- 花费(Cost):就是数据发送过程中通过路径所需要的花费。
- 路由的服务质量
- 路由中需要过滤的出/入连接列表
5.链路层
主要信道:
- 点对点信道
- 广播信道
点对点信道
- 数据单元 ———— 帧
三个基本问题:
- 封装成帧:把网络层的 IP 数据报封装成帧,
SOH - 数据部分 - EOT
- 透明传输:不管数据部分什么字符,都能传输出去;可以通过字节填充方法解决(冲突字符前加转义字符)
- 差错检测:降低误码率(BER,Bit Error Rate),广泛使用循环冗余检测(CRC,Cyclic Redundancy Check)
点对点协议(Point-to-Point Protocol):
- 点对点协议(Point-to-Point Protocol):用户计算机和 ISP 通信时所使用的协议
广播信道
广播通信:
- 硬件地址(物理地址、MAC 地址)
- 单播(unicast)帧(一对一):收到的帧的 MAC 地址与本站的硬件地址相同
- 广播(broadcast)帧(一对全体):发送给本局域网上所有站点的帧
- 多播(multicast)帧(一对多):发送给本局域网上一部分站点的帧
5.1链路层提供的服务
链路层可能提供的服务包括:
- 成帧:将网络数据报封装成帧
- 链路接入:媒体访问控制(MAC)协议规定了帧在链路上传输的规则
- 可靠交付:可靠交付服务通常用于易产生高差错率的链路,对于低比特差错的链路,可靠交付可能被认为是一种不必要的开销,因此不提供此服务
- 流量控制:没有流量控制,可能会造成缓存区溢出
- 差错检测和纠正:奇偶校验,检验和,CRC校验
- 半双工和全双工:全双工时,链路两端的节点可以同时传输分组
5.1.1 差错检测和纠错技术
在发送节点,为了避免比特差错,使用**差错检测和纠错比特(EDC)**来增强数据的可靠性。
差错检测和纠正技术有时使接收方检测到已经出现的比特差错,但并非总是这样。即使采用差错检测比特,也还是可能有未检出比特差错的情况
因此,主要是选择一个差错检测方案,使得这种事件发生的概率很小。可以使用下列3种技术进行差错检测:
1.奇偶校验:只需包含1个附加比特。
– 对于偶校验,选择一个值使得所有比特中1出现偶数次
– 对于奇校验,选择一个值使得所有比特中1出现基数次 接收方通过检测1出现的次数判断是否出现差错。如果出现偶数个比特差错,则检验不出。可以使用二维化的方案(详见教材)进行优化
2.校验和:通常更多的应用于运输层。将数据分为多个k比特的序列,相加(可能回滚)后取反,作为校验和。接收方对所有k比特(包括校验和)的序列相加,结果的任意比特如果出现0,则检测为出现比特差错
3.循环冗余检测**(CRC)**:发送方和接收方协商一个r+1比特的生成多项式(G),要起其最高比特位为1。发送方通过在d比特的数据后附加r比特,使得整个(d+r)比特的值能够被G整除。接收方用G去除(d+r)比特,如果余数非0,则出现差错(附加r比特的计算详见教材)
5.2媒体访问控制(MAC)协议
5.2.1 点对点协议(PPP)
点对点协议(PPP)用于点对点链路,点对点链路由链路一端的单个发送方和链路另一端的单个接收方组成。通常住宅主机拨号链路就是用的PPP,所以它是目前部署最广泛的链路层协议之一。
5.2.2 多路访问协议
多路访问协议用于广播链路,广播链路能够让多个发送和接收节点都连接到相同的、单一的、共享的广播信道上。多路访问协议用于协调多个发送和接收节点对一个共享广播信道的访问
1.信道划分协议:带宽限制:R/N
– TDM(时分多路复用):对于N个节点的信道,传输速率为R bps,TDM将时间划分为时间帧,并进一步划分每个时间帧为N个时隙,每个节点在特定的时隙内传输(消除了碰撞,非常公平;但节点被限制与R/N bps的平均速率,即使只有一个节点有数据要发送)
– FDM(频分多路复用):在R bps的信道中创建了N个较小的R/N bps信道,每个节点使用一个较小的信道传输(消除了碰撞,公平;但节点被限制与R/N bps的平均速率,即使只有一个节点有数据要发送)
– CDMA(码分多址):每个节点分配一种不同的编码,每个节点使用其唯一的编码来对发送的数据进行编码(如果精心选择编码,不同节点能同时传输)
2.随机接入协议:全部速率
– 纯ALOHA:帧到达节点时,立刻传输。如果发生碰撞,节点将立即(在完全传输碰撞帧后)以概率p重传。否则,等待一个帧传输时间,再以概率p重传…(信道有效传输速率实际不是R bps,而是时隙ALOHA的一半,详见教材)
– 时隙ALOHA:时间被划分为时隙,每个节点的时间同步,帧的传输只在时隙的开始时进行。如果发生碰撞,在下一个时隙开始时以概率p重传,否则等待一个时隙再以概率p重传…(信道有效传输速率实际不是R bps,而是0.37R bps,详见教材)
– CSMA(载波侦听多路访问):发送前先侦听信道,如果没有其它节点在使用信道,则传输数据。CSMA没有碰撞检测,即使发生碰撞,也将传输完碰撞帧(由于节点间数据传输存在时延,很可能一个传输正在信道中但是由于还未到达所以检测到信道空闲,此时传输最终会发生碰撞)
– CSMA/CD(具有碰撞检测的载波侦听多路访问):先侦听信道,如果没有其它节点在使用信道,则传输数据。但是有碰撞检测,如果发生碰撞,会停止传输剩下的数据,等待一个随机时间(通常比传输一帧短)后,再进行尝试
3.轮流协议
– 轮询协议:指定节点之一为主节点。主节点以循环的方式轮询每个节点。告诉每个节点能够传输的最大帧数,然后让节点传输帧,主节点通过观察信道上是否缺乏信号来决定一个节点合适完成了帧的发送(消除了困扰随机接入协议的碰撞和空时隙,效率很高;但引入了轮询延时,同时主节点发生故障将使信道不可用)
– 令牌传递协议:节点间通过令牌传递信道使用权,如果没有数据发送,立即传递令牌给下一节点(一个节点的故障可能会使整个信道崩溃。或者如果一个节点忘记释放令牌,必须调用某些恢复步骤使令牌返回到循环中来)
5.3链路层编制
5.3.1 MAC地址
长度为6字节,共48比特,通常用十六进制表示法,地址的每个字节被表示为一对十六进制数
-
每个适配器具有一个唯一的MAC地址,不随位置发生变化(就像人的身份证,而IP则像人的邮政地址)
-
一台路由器的每个接口都有一个ARP模块和一个适配器
MAC地址分配:当一个公司要生产适配器时,它支付象征性的费用购买一块MAC地址空间,IEEE分配这块地址时,固定前24比特,让公司自己为每个适配器生成后24比特的唯一组合
5.3.2 ARP(地址解析协议)
- 提供将IP地址转换为链路层地址的机制(ARP只为同一子网上的节点解析IP地址,DNS为因特网中任何地方的主机解析主机名): 1. 每个节点的ARP模块都在它的RAM中有一个ARP表,包含IP地址到MAC地址的映射关系,每个表项还包含TTL字段,表示表项过期时间(ARP表是自动创建的,如果某节点与子网断开连接,它的表项最终会从留在子网中的节点的表中删除。通常一个表项的过期时间是20分钟) 2. 主机向其ARP模块提供一个IP地址,ARP模块返回IP地址对应的MAC地址。
- 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字节
- 工作原理
如果相应表项尚未存在ARP表中? 1. 查询节点构造ARP查询分组,包含有查询节点和目的节点的IP地址,适配器在链路层帧中封装这个ARP分组,广播帧 2. 子网中的所有其他适配器接收到帧,将帧中的ARP分组向上传递给ARP模块,每个节点检查自身IP是否与ARP查询分组中的目的IP地址相同,相同的返回一个ARP响应分组3. 查询节点接收到ARP分组,获得目的MAC地址,并更新自身的ARP表。
如何发送数据报到子网以外?
假设主机1要向主机2发送数据报,应该使用什么MAC地址?如果使用49-BD-D2-C7-56-2A作为目的MAC地址,由于子网内任何一个适配器的MAC地址都不匹配,所以这个数据报将会死亡。正确的步骤如下:
1.主机1通过ARP获取路由器接口111.111.111.110的MAC地址,将数据报封装成帧,转发
2.路由器的接口111.111.111.110收到帧,由于MAC地址匹配,适配器获取帧中的数据报上传给网络层
3.路由器通过查找转发表将数据报通过交换结构转发到输出接口222.222.222.220
4.输出接口222.222.222.220通过ARP获取子网中主机2的MAC地址
5.获得主机2的MAC地址后,将数据报传递给适配器,封装成帧,最终发送到主机2
5.4以太网
虽然20世纪80年代和90年代早期,以太网面临着其他LAN技术包括令牌环、FDDI、ATM的挑战,但是至今,以太网仍是最流行的有线局域网技术。
所有的以太网技术都向网络层提供无连接服务、不可靠服务。
5.4.1 以太网帧结构
-
前同步码:8字节。以太网帧以一个8字节的前同步码字段开始。前7个字节的值都是10101010,最后一个字节是10101011。前7个字节用于“唤醒”接收适配器,并且将其时钟与发送方的时钟同步,第8个字节的最后两个1告诉接收适配器,“重要的内容”就要来了,因此接收适配器知道接下来的6个字节是目的地址
-
类型:网络层协议类型
-
数据:46~1500字节。承载了IP数据报,以太网的最大传输单元(MTU)是1500字节,IP数据报最小46字节,如果不够会填充(如果填充,在目的端填充也会上传到网络层,通过数据报首部的长度字段去除填充)
-
循环冗余检测**(CRC)**:提供差错检测与纠正,具体见1.1。如果校验成果,并不会发送肯定确认。如果校验失败,也不会发生否定确认,只是丢弃该帧
头信息有14字节,尾部校验和FCS占4字节。因此,一个标准的以太网数据帧大小是1518。
5.4.2 链路层交换机
现代以太网LAN使用了一种星型拓扑,每个节点与中心交换机相连
-
交换机的任务是接收入链路层帧并将它们转发到出链路
-
交换机自身对节点透明:某节点向另一节点寻址一个帧,顺利地将该帧发送进LAN,而不知道这个帧经过了某个交换机的接收与转发
交换机具有如下性质:
-
消除碰撞:交换机缓存帧并且绝不会在网段上同时传输多于一个帧。交换机的最大聚合带宽是所有接口速率之和
-
异质的链路:交换机将链路彼此隔离,LAN中的不同链路能够以不同的速率运行,并且能够在不同的媒体上运行
1)交换机转发与过滤
-
过滤:交换机决定一个帧是应该转发还是应该丢弃
-
转发:决定一个帧应该被导向哪个接口
过滤和转发都借助于交换机表:
假设具有目的地址DD-DD-DD-DD-DD-DD的帧从交换机的x接口到达:
-
如果表中没有针对DD-DD-DD-DD-DD-DD的表项,则向除了x的其它所有接口广播帧
-
如果表中有针对DD-DD-DD-DD-DD-DD的表项
- 1)接口等于x:(说明帧的目的地和帧处于同一子网,意味着该帧已经在包含目的地址的LAN网段广播过了)该帧执行过滤功能
- 2)接口为y,不等于x:将帧转发到接口y的输出缓存区
2)自学习(即插即用)
交换机表是自动、动态、自治地建立的,没有来自网络管理员或配置协议的任何干预。换句话说,交换机是自学习的
1.交换机表初始为空
2.源地址为DD-DD-DD-DD-DD-DD的帧从接口x到达时,1)如果不存在则新建一项;2)存在则更新当前时间
3.如果一段时间后,在x接口没有来自DD-DD-DD-DD-DD-DD的帧,则将该表项删除
3)交换机与路由器对比
-
交换机
-
优点
- 即插即用
- 相对高的分组过滤、转发速率
-
缺点
- 交换网络的活跃拓扑限制为一棵生成树(为了防止广播帧的循环)
- 对广播风暴不提供任何保护措施(如果某主机故障,没完没了传输广播帧流,交换机会转发所有这些帧,使得整个以太网崩溃)
-
-
路由器
-
优点
- 分组不会被限制在一棵生成树上,从而能用各种拓扑结构来构建因特网
- 对广播风暴提供了防火墙保护
-
缺点
- 不是即插即用(需要人为配置IP地址)
- 对分组的处理时间更长(必须处理高达第3层的字段)
-
通常,由几百台主机组成的小网络通常有几个LAN网段,对于这些小网络,交换机就足够了,因为它们不要求IP地址的任何配置就能使流量局部化并增加总吞吐量。但是在由几千台主机组成的更大网络中,通常在网络中还包括路由器。路由器提供了更健壮的流量隔离方式和对广播风暴的控制,并在网络的主机之间使用更“智能的”路由
【QA】
1.为什么运输层使用检验和而链路层使用CRC呢?
- 运输层差错检验用软件实现,采用简单快速的检验和的方式。
- 链路层的差错检测在适配器中采用专用硬件实现。
2.为什么网络层和链路层都需要地址?
- 保持各层的独立,局域网是为任意网络层协议而设计的,不只用于IP和因特网。
- 如果适配器使用IP地址,则适配器不能方便的支持其他网络层协议,且IP地址必须存储在适配器的RAM中。
- 如果适配器中不适用任何地址,则主机将被局域网上发送的每个帧中断。
- 如果网络层使用MAC地址,无法构建高效的路由选择方案,增加一个附加层的地址寻址,可以使得设备更易于移动和维修
6.物理层
- 传输数据的单位 ———— 比特
- 数据传输系统:源系统(源点、发送器) --> 传输系统 --> 目的系统(接收器、终点)
通道:
- 单向通道(单工通道):只有一个方向通信,没有反方向交互,如广播
- 双向交替通行(半双工通信):通信双方都可发消息,但不能同时发送或接收
- 双向同时通信(全双工通信):通信双方可以同时发送和接收信息
通道复用技术:
- 频分复用(FDM,Frequency Division Multiplexing):不同用户在不同频带,所用用户在同样时间占用不同带宽资源
- 时分复用(TDM,Time Division Multiplexing):不同用户在同一时间段的不同时间片,所有用户在不同时间占用同样的频带宽度
- 波分复用(WDM,Wavelength Division Multiplexing):光的频分复用
- 码分复用(CDM,Code Division Multiplexing):不同用户使用不同的码,可以在同样时间使用同样频带通信
7.网络错误排查
- 联系ping等检查网络是否通畅来考察你对问题的追溯程度,比如网络通,但是拿不到服务器上的资源,怎么办,防火墙封闭了端口?如果端口也开了呢,怎么办,dns解析有问题?怎么弄?
- tcpdump抓到的包如何分析?
- 写入到.pcap文件中,使用wireshark或packetyzer查看分析
- 在你们的运维平台上刷新了一条资源如何检测这条资源有没有刷新成功?
- 网易云音乐的评论无法加载,如何排查?说出思路,各业务模块监控指标QPS均无抖降点,但是问题依旧存在,为什么?
- 如何在linux上添加路由?我添加了一条路由之后还是ping不通,可能的原因有哪些?
- 出不去:网关不通,出去的路被防火墙档了
- 回不来:被丢弃,回来的报被挡了
8.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
Socket 中的 read()、write() 函数
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);
read()
- read 函数是负责从 fd 中读取内容。
- 当读成功时,read 返回实际所读的字节数。
- 如果返回的值是 0 表示已经读到文件的结束了,小于 0 表示出现了错误。
- 如果错误为 EINTR 说明读是由中断引起的;如果是 ECONNREST 表示网络连接出了问题。
write()
- write 函数将 buf 中的 nbytes 字节内容写入文件描述符 fd。
- 成功时返回写的字节数。失败时返回 -1,并设置 errno 变量。
- 在网络程序中,当我们向套接字文件描述符写时有俩种可能。
- (1)write 的返回值大于 0,表示写了部分或者是全部的数据。
- (2)返回的值小于 0,此时出现了错误。
- 如果错误为 EINTR 表示在写的时候出现了中断错误;如果为 EPIPE 表示网络连接出现了问题(对方已经关闭了连接)。
Socket 中 TCP 的三次握手建立连接
我们知道 TCP 建立连接要进行 “三次握手”,即交换三个分组。大致流程如下:
- 客户端向服务器发送一个 SYN J
- 服务器向客户端响应一个 SYN K,并对 SYN J 进行确认 ACK J+1
- 客户端再想服务器发一个确认 ACK K+1
只有就完了三次握手,但是这个三次握手发生在 Socket 的那几个函数中呢?请看下图:
从图中可以看出:
- 当客户端调用 connect 时,触发了连接请求,向服务器发送了 SYN J 包,这时 connect 进入阻塞状态;
- 服务器监听到连接请求,即收到 SYN J 包,调用 accept 函数接收请求向客户端发送 SYN K ,ACK J+1,这时 accept 进入阻塞状态;
- 客户端收到服务器的 SYN K ,ACK J+1 之后,这时 connect 返回,并对 SYN K 进行确认;
- 服务器收到 ACK K+1 时,accept 返回,至此三次握手完毕,连接建立。
Socket 中 TCP 的四次握手释放连接
上面介绍了 socket 中 TCP 的三次握手建立过程,及其涉及的 socket 函数。现在我们介绍 socket 中的四次握手释放连接的过程,请看下图:
图示过程如下:
- 某个应用进程首先调用 close 主动关闭连接,这时 TCP 发送一个 FIN M;
- 另一端接收到 FIN M 之后,执行被动关闭,对这个 FIN 进行确认。它的接收也作为文件结束符传递给应用进程,因为 FIN 的接收意味着应用进程在相应的连接上再也接收不到额外数据;
- 一段时间之后,接收到文件结束符的应用进程调用 close 关闭它的 socket。这导致它的 TCP 也发送一个 FIN N;
- 接收到这个 FIN 的源发送端 TCP 对它进行确认。
这样每个方向上都有一个 FIN 和 ACK。
上一篇: 究竟什么是时间复杂度,怎么求时间复杂度,看这一篇就够了
下一篇: 调整数顺序使奇数位于偶数前面