计算机网络
笔记:
网络的出现与RFC规范
接入方式
应用层
SMTP 邮件发送
服务协议
:将邮件通过指定我方邮件服务器投送到对方邮件服务器中
1 | telnet servername 25 |
POP3 邮件接收服务
用于从邮件服务器上拉取
邮件;第三版的邮局协议(Post
Office Protocol—Version 3)
1 | telnet mailServer 110 |
POP3 服务器不会再会话中包含状态信息
POP3 协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的
方法
IMAP
:(Internet Mail Access Protocol ),因特网邮件访问协议;拉取
邮件内容
1 | IMAP 协议比POP3复杂 |
HTTP
:超文本传输协议,拉取
邮件内容;基于Web的邮件服务(QQ,GMAIL,163),使用HTTP获取邮件(用户代理-浏览器 : 邮件服务器),后段依然适用 SMTP 协议发送邮件
DNS
: DNS协议是应用层协议,其原因在于:
① 使用客户-服务器模式运行在通信的端系统之间;
② 在通信的端系统之间通过下面的端到端运输协议来传送DNS报文
特殊之处在于:DNS协议通常是由其他应用层协议所使用的;DNS额外的功能
- 主机别名
- 邮件服务器别名
- 负载分配
DNS 服务单点核心问题:
- 单点故障
- 通信容量(带宽限制)
- 远距离(跨网时延)
- 数据维护(数据量大)
为解决这些问题,造就了 分布式互联网服务的 范例 DNS 服务
分布式,层次数据库
根域名服务 : 12(13)个机构-1000多个节点遍布世界。中国有26个根域名服务器节点。I/L/J/K/F
顶级域名服务:顶级域名(com,org,edu… 通用顶级域名&国家顶级域名 .cn,.fr.de)
权威服务:域名的最终解释服务,具体的IP映射关系
另一类重要的DNS服务器:本地DNS服务器 (local DNS server)
一般由ISP(运营商)分配,指的是 用户设备上配置的DNS服务器IP地址
实践中:递归查询(用户到本地DNS ) / 迭代查询 (本地DNS 到各个级别的域名服务器都是迭代查询)
DNS缓存
- DNS 查询响应包被缓存,权威服务IP也可以被缓存
- 事实上:因为DNS缓存,除了少数DNS查询外,根服务器一般都被绕过了
DNS记录与报文 -[RFC 1034; RFC 1035]
记录:(Name,Value,Type,TTL)
查询报文 / 响应报文
1
2
3
4
5
6
7
81. 首部区域
12字节 : 标识符, 标识
查询数, 应答记录数
权威应答数, 附加应答数
2. 查询信息区域
3. 查询结果区域
4. 权威区域
5. 附加区域
DNS的脆弱性
DDoS
攻击 :- 攻击
根域名服务
:2002 年 ICMP ping报文负载;更为有效DDoS
攻击将是向顶级域名服务
发 大量的DNS 求。顶级域名服务器不像根服务器 样容易绕过
。但是这种攻击 严 性通过本 地DNS服务器中的缓存技术可将 分地被缓解 - 中间人攻击:
缓存投毒
:在中 人攻击中 攻击 截 来 主机的请求 并 回伪造的回答。在DNS毒害攻击中 攻击 向一台DNS服务器发 伪造的回答, 使服务器在它的缓存中接收伪造的记录。
P2P 文件分发
文件分块传输
最稀缺优先规则
分布式散列表 DHT
视频流:
HTTP流 和 DASH ( Dynamic Adaptive
Streaming over HTTP: 为经HTTP的动态适应性流 ) - manifest file 告示文件:包含各个版本的视频url,允许客户端选择不同码率 不同URL来播放(速率选择算法)内容分发网:
CDN 服务
主动利用 DNS 截获或重定向请求:加速
Google 的专用网络与CDN基础设施:具有三个等级的服务器集群。
1. 14个“ 万数据中心” 其中8个位于北 4个位于欧洲 2个位于亚洲[Google
Locations 2016],每个数据中心具有10万台量级的服务器。 些“ 万数据中心”
负责服务于动态 并且 常是个性化 内容 包括搜索结果和Gmail报文。2. IXP中大约50个集群分布于全 其中每个集群由100-500台服务器组成。这些集群负责服务于 静态内容 包括YouTube视频 3. 数以百计的“深入 enter-deep M集群位于一个接入ISP中。这里一个集群通
〜 常 位于一个机架上 数十台服务器 成。 些“深入服务器”执 TCP分岔 参 3. 7 并服务于 态内容[Chen 2011],包括体 搜索结果 Web
页的静态 分。Google云服务:当某用户进行搜… …
总的来说:除了本地ISP,Google云服务很大程度上是由独立于公共网络 的 网络基础设施提供的
套接字编程 Socket: golang 代码
- TCP (粘包问题,自编码/解码)
- UDP
传输层
TCP 和 UDP 运输层协议
运输层协议将要发送的数据转换为运输层的报文段
(segment)。
实现的方法可能是将数据划分为较小的块,并为每块加上一个运输层首部以生成运输层报文段
。
传递给网络层
后被封装为网络层
数据包,并发送到端系统中。
网络路由器仅作用于该数据报的网络层
字段;即它们不检查封装在该数据报的运输层报文段
的字段。在接收端,网络层
从数据报中提取运输层报文段
,并将该报文段
向上交给运输层。运输层则处理接收到的报文段
,使该报文段
中的数据为接收应用进程使用。
数据的完整传输:
- 应用层:数据文件
- 传输层:报文段
- 网络层:数据包
- 数据链路层:MAC帧
- 物理层:Bit 流
运输层的多路复用与多路分解
在接收端,运输层检查套接字字段标识(端口号),将报文段定向到该套接字。将运输层报文段中的数据交付到正确的套接字的工作称为 多路分解 (demultiplexing)
在源主机从不同套接字中收集数据块,并为每个数据块封装上首部信息(这将在以后用于分解)从而生成报文段,然后将报文段传递到网络层,这些工作称为 多路复用 (multiplexing)
无连接多路复用与分解(上)
- UDP 套接字由 二元组 标识:目的地IP,目的地端口;分解到相应的套接字
面向连接的多路复用与分解
- TCP 四元组:源IP,源端口,目的地IP,目的地端口;确定分解到相应的套接字
- TCP 报文段携带了初始创建链接的请求,会分解到新的套接字
安全性: 寻找突破口
端口扫描: nmap, 对于TCP/UDP,nmap顺序扫描端口,创建TCP链接 或发送 UDP报文段。
无连接传输: UDP
DNS 是使用UDP的应用层协议的例子。
特点:
发送什么数据/何时发送的应用层控制更为精细:
1
21. UDP传输直接对打包进UDP报文段,并立即传递给网络层。
2. 另一方面 TCP 有一个拥塞控制机制:用来遏制极端拥塞情况下的发送方。重发数据报文段知道确认接受,而忽略交付需要时间。无需连接建立:
相比TCP少了三次握手耗时
无连接状态:
无需维护连接状态,拥塞控制等,一般能支持更多的活跃用户连接
分组首部开销小
1
每个TCP报文段都有20字节的首部开销,而UDP仅有8字节的开销。
应用中的问题:
现在通常在 UDP传输协议书运行多媒体应用,但是有争议的;在用户都适用UDP传输用高比特率视频的情况下,不做拥塞控制会导致路由器中有大量的数据分组溢出,以至于很少的UDP分组数据能成功的通过源到目的地的路径传输。
另外,无控制的UDO发送方引起的搞丢包率将引起TCP发送方大大地减少他们的速率。因此,UDO中取少拥塞控制能够导致UDP发送方和接受方之间的高丢包率,并挤垮TCP会话.
现在有很多研究人员提出了新的机制:促使所有的数据源(包括UDP源)执行自适应的拥塞控制。
UDP 与 可靠性传输
使用 UDP传输协议的应用 是可能实现可靠数据传输的。通过在应用程序自身中建立可靠性机制来完成:如,增加确认与重传机制来实现.UDP 协议本身是不可靠的传输协议,只有确认报文段的完整性 检验和 。
运输层UDP报文段结构:
1
2
3
4
5
6
71. 套接字有唯一标识符
2. 每个报文段有特殊字段来指示该报文段所要交付到的套接字
结构:(UDP报文段)
4 字节 = 32 比特 : 源端口号(16) | 目的端口(16)其大小在0 ~65535
: 其他首部字段 (长度|检验和)
: 应用数据(报文)检验和
用于确认UDP报文段在传输过程中是否发生了改变:例如,由于链路中的噪声干扰或者存储在路由器中时引入问题。检验和的生成
:发送发对UDP报文段中的所有16比特字的和进行反码运算。求和时遇到的任何溢出都被回卷(回卷=反码运算:0->1,1->0)。得到的结果就是检验和。接收方检验:全部4个16比特字(包括检验和)加在一起,如果该分组中没有引入差错,则显然在接收方处该和将是(1111 1111 1111 1111),如果这些比特之一是0,那就表示分组中已经出现了差错。
可靠数据传输原理
经完全可靠信道的可靠数据传输:rdt1.0
经具有比特差错信道的可靠数据传输: rdt2.0
自动重传请求 ARQ协议;ARQ协议宁外还需要三种协议功能来处理存在比特差错的情况
- 差错检测
- 接收方反馈: 肯定确认/否定确认
- 重传。接收方收到差错分组是,发送方将重传
- 停等协议 stop-and-wait
- 发送分组序号
- 冗余分组
- 冗余ACK
经具有比特差错的丢包信道的可靠数据传输:rdt3.0
- 检验和,序号,ACK分组和重传
- 冗余数据分组(提供数据的同时,被序号处理产生的问题)
- 基于时间的重传机制: 倒计数定时器,在一个鹅给定的时间量过期后,可中断发送方
- 每次发送一个分组时(包括第一次分组和重传分组),启动一个定时器
- 响应定时器中断
- 终止定时器
现象:
- 无丢包操作:
- 分组丢失
- 丢失ACK
- 过早超时
总结: 在检验和,序号,定时器,肯定/否定确认这些技术中,我们完成了一个可靠数据传输协议。
没有搞太明白!!!
流水线可靠数据传输协议
rdt3.0 是一个功能正确的协议,但性能不够优秀,核心原因在于它是一个停等协议(stop-and-wait)
解决方法:
不以停等的方式运行,允许发送方发送多个分组而无需等待确认。如在等待去人之前发送三个报文,利用率也就提高了三倍。因为许多从发送方 向 接收方输送的分组可以被看成是填充到一条流水线中,故这种技术被称为流水线(pipelining)
停等操作:
1: t=0 ; 2: t=L/R
首个分组的最后一个比特到达,发送ACK
ACK到达,发送下一个分组 t=RTT+L/R
停等+流水线发送:
1: t=0 ; 2: t=L/R
在RTT 时间内 ,以n组的方式发送
接收方顺序确认,当n组确认后,开始发送下一个n*分组
产生:
- 回退N步协议 GNB (go-back-n) = 滑动窗口协议(sliding-window protocol)
- 选择重传协议 SR (Selective Repeat)
优秀的可靠传输机制:窗口,流水线(允许未确认情况发送N组数据);窗口长度根据接收方接受和缓存报文的能力,网络中的拥塞程度或者两者情况来进行设置
面向连接的传输 :TCP
TCP 是运输层的面向连接的可靠的运输协议。
报文结构:
- 32 比特的序号字段
- 32 比特的确认号字段:用于实现可靠传输
- 16 比特的接收窗口字段:该字段用于流量控制,表示接收方愿意接受的字节数量
- 4 比特的首部长度字段:该字段指示了以32 比特的字为单位的TCP首部长度。长度可变(通常选项字段未空,TCP首部的典型长度为20字节)
- 可选与变长的选项字段:用于发送发与接收方协商最大的报文段长度 MSS 时,或在高速网络环境下用作窗口调节因子时使用。
- 6 比特的标志字段: ACK 比特用于确认字段中的值时有效的,即该报文段包括一个对已被成功接受报文段的确认。RST,SYN 和 FIN用于连接的建立与拆除。在明确拥塞通告中使用了CWR 和 ECE。
序号与确认号:
TCP连接状态详解
服务端 LISTEN: 侦听来自远方的TCP端口的连接请求
客户端 SYN-SENT: 发送连接请求后等待匹配的连接请求
服务端 SYN-RECEIVED:收到和发送一个连接请求后等待对方对连接请求的确认
客户端/服务端 ESTABLISHED: 代表一个打开的连接
客户端 FIN-WAIT-1: 等待远程TCP连接中断请求,或先前的连接中断请求的确认
客户端 FIN-WAIT-2: 从远程TCP等待连接中断请求
服务端 CLOSE-WAIT: 等待从本地用户发来的连接中断请求
客户端 CLOSING: 等待远程TCP对连接中断的确认
服务端 LAST-ACK: 等待原来的发向远程TCP的连接中断请求的确认
客户端 TIME-WAIT: 等待足够的时间以确保远程TCP接收到连接中断请求的确认
客户端。服务端 CLOSED: 没有任何连接状态
三次握手和编程的关系
- 服务器通过 socket(),bind(),listen() 来完成 CLOSE 到 LISTEN 状态的转化。称为被动打开,打开后使用 accept()
阻塞,等待客户端请求。 - 客户端通过connect()进行主动打开,1.发送 SYN 包
- 服务端收到 并 回复 2. SYN+ACK 进行确认
- 客户端收到 服务端确认 SYN+ACK ,并 发送 3. ACK 客户端确认。connect()返回成功
- 服务端收到客户端确认 accept()
三次握手异常:
第一次丢包:connect()是阻塞的,如果无法发送到服务端,那么会进行重试等待,通过设置 SO_SNDTIMEO 来设置超市等待时间
第二次握手丢包:对于用户来说发包了没有回包还是 connect() 超时;
对于服务端来说,由于收不到第三次请求,所以会进入等待重传,知道多次重传失败后,关闭半连接;
a) 半连接的等待状态。
b) 常见的DDoS就是 发送第一次握手数据后,关闭连接,将服务器的额半连接队列占满。第三次握手丢包: 发送第三次数据包后,客户端已经直接进入 ESTABLISHED 状态。
这时服务端与客户端的状态不同步了,这时候服务端会进行多次重发,一旦客户端再次收到 SYN+ACK(第二次握手请求),会再次确认。
不过如果第三次握手一直失败,则会出现,客户端已建立连接,服务端关闭连接的情况。
随后一旦客户端想服务器发送数据,则会收到一条RST回应,告诉客户端连接已经重置,需要重新进行三次握手
a) RST 与 SIGPIPE 信号
四次挥手
CLOSE_WAIT: 客户端表示不接受数据了,但是服务端不一定没数据要发了,
这段时间主要用于给杜芳发送必要数据,对自己的数据进行收尾,所有工作结束之后掉用 close() ,发送 FIN,等待LAST_ACKTIME_WAIT:
a) 实现TCP全双工连接的可靠性:LAST_ACK丢失,对方重发可接受到。
b) 允许老的网络分组在网络中消逝;
TCP的同时打开 / 同时关闭
tcp 粘包现象:
主要原因就是tcp数据传递模式是流模式,在保持长连接的时候可以进行多次的收和发。
“粘包”可发生在发送端也可发生在接收端:
由Nagle算法造成的发送端的粘包
接收端接收不及时造成的接收端粘包
粘包解决:
出现”粘包”的关键在于接收方不确定将要传输的数据包的大小,因此我们可以对数据包进行封包和拆包的操作。
封包:封包就是给一段数据加上包头,这样一来数据包就分为包头和包体两部分内容了(过滤非法包时封包会加入”包尾”内容)。包头部分的长度是固定的,并且它存储了包体的长度,根据包头长度固定以及包头中含有包体长度的变量就能正确的拆分出一个完整的数据包。
我们可以自己定义一个协议,比如数据包的前4个字节为包头,里面存储的是发送的数据的长度。
拥塞控制:
- 慢启动:1=》2=》4=》8 个包
- 拥塞避免
- 快速恢复
当前拥塞控制观察丢失分组情况来推断拥塞。
新一代:明确拥塞通告
(ECN) :网络辅助拥塞控制
在网络层中使用 IP 数据首部的服务类型字段中的 两个比特(四个可能的值)被用于 ECN
新的传输层协议:
- DCCP 数据报拥塞控制协议(Datagram Congestion Control Protocol, DCCP) [ RFC 4340 ]
- QUIC ( Quick UDP Internet Connections)协议
[Iyengar 2016] - DCTCP (数据中心TCP) [Alizadeh 2010]
- SCTP 流控制传输协议(Stream Control Transmission Protocol, SCTP) [ RFC 4960, RFC 3286 ]
唯有未来才能告诉我们DCCP、SCTP、QUIC或TFRC是否能得到广泛实施。虽然这些 协议明确地提供了超过TCP和UDP的强化能力,但是多年来已经证明了 TCP和UDP自身
是“足够好”的。是否“更好”将胜岀“足够好”,这将取决于技术、社会和商业考虑的复杂组合
网络层
数据平面
网络层中每台路由器的功能,该数据平面功能决定到达路由器输入链 路之一的数据报(即网络层的分组)如何转发到该路由器的输出链路之一
IP转发
通用转发
IPv4 IPv6协议及其寻址
DHCP 动态主机配置协议,第一跳路由器(默认网关)配置,本地DNS服务器地址
- DHCP 发现报文 客户端(新机器)
- DHCP 提供报文 服务端
- DHCP 请求报文 客户端发送
- DHCP ACK报文 服务端发送
基于移动节点与子网之间的单一永久地址:移动IP
网络地址转换 NAT
控制平面
即网络范围的逻辑,该控制平面功能 控制数据报沿着从源主机到目的主机的端到端路径中路由器之间的路由方式
路由选择算法:
- OSPF 协议
- AS 自治域 内的最短开放路径算法
- BGP 协议
- 跨AS 自治域时
SDN 控制器
- 跨AS 自治域时
软件定义网络(Software- Defined Networking, SDN)通过将这些控制平面功能作为
一种单独服务,明确地分离数据平面和控制平面,控制平面功能通常置于一台远程“控制 器”中