计算机网络
计算机网络的基础知识
参考 | 说明 |
---|---|
自顶向下方法-中科大 | b站课程 |
CS144 | cs144 |
0. Unix/Linux下的网络相关命令
1 ifconfig 查看网络接口信息
1
2
3
4
ifconfig # 查看网络接口信息
ifconfig eth0 # 查看指定网络接口信息
ifconfig eth0 up # 启动指定网络接口
ifconfig eth0 down # 关闭指定网络接口
2 ping 测试网络连通性
1
2
ping www.baidu.com # ping百度
ping -c 4 www.baidu.com # ping百度4次
3 traceroute 查看路由
1
traceroute www.baidu.com # 查看到达百度的路由
4 netstat 查看网络连接
1
2
netstat -an # 查看所有网络连接
netstat -an | grep 80 # 查看所有80端口的网络连接
5 nslookup 查询DNS
1
nslookup www.baidu.com # 查询百度的IP地址
6 route 查看路由表
1
route # 查看路由表
7 iptables 防火墙
1
iptables -L # 查看防火墙规则
8 telnet 测试端口
telnet是一个远程登录协议,可以用来测试网络连接,查看端口是否开放
1
telnet www.baidu.com 80 # telnet百度的80端口
9 ssh
1
ssh user_name@host -p 8008 # 远程登录
10 curl 获取网页
1
curl www.baidu.com # 获取百度的网页
11 设置/取消代理
参考: Linux Proxy Server Settings
关于export:用于设置或显示环境变量
临时设置代理:
1
2
3
4
5
6
7
8
export http_proxy=http://a.b.c.d:port # 设置http代理
export https_proxy=http://a.b.c.d:port # 设置https代理
export ftp_proxy=http://a.b.c.d:port # 设置ftp代理
export all_proxy=http://a.b.c.d:port # 设置所有代理
export http_proxy=http://a.b.c.d:port https_proxy=http://a.b.c.d:port # 设置http和https代理
export no_proxy="localhost,127.0.0.1,someurl.com" # 设置不使用代理的地址
取消临时代理:
1
2
unset http_proxy # 取消http代理
unset https_proxy # 取消https代理
设置永久代理:
1
2
3
4
5
6
7
# 在/etc/profile中添加
http_proxy=http://a.b.c.d:port # 设置http代理
https_proxy=http://a.b.c.d:port # 设置https代理
ftp_proxy=http://a.b.c.d:port # 设置ftp代理
# shell
export http_proxy https_proxy ftp_proxy
查看代理:
1
2
3
echo $http_proxy # 查看http代理
echo $https_proxy # 查看https代理
env | grep -i proxy # 查看所有代理
使用ssh反向代理(远程代理 RemoteForward):
1
2
3
4
5
ssh -fCNR a.b.c.d:port:localhost:port user_name@host # 将a.b.c.d:port的流量转发到localhost:port
# 说明: -f 后台运行 -C 允许压缩 -N 不执行远程命令
# -R 反向代理,将远程主机(服务器)的某个端口转发到本地端指定机器的指定端口
# -L 本地代理,将本地主机(客户端)的某个端口转发到远程主机的指定机器的指定端口
# -D 动态代理,将本地主机的某个端口转发到远程主机的指定机器的指定端口
1. 网络概述
网络层次:
- 应用层
- 传输层
- 网络层
- 数据链路层
- 物理层
1.1 什么是网络
网络的构成
从具体构成角度上看
网络由节点、边、协议组成
- 节点:
- 主机节点(数据的源/目标)
- 数据交换节点(路由器、交换机等网络交换设备)
- 边:通信链路
- 接入网链路:主机连接到互联网的链路
- 主干链路:路由器间的链路
- 协议:规定了节点之间的通信规则
- 包括:语法、语义、时序
从服务的角度看
互联网可以分为应用层和应用层以下提供通信服务的基础设施
- 使用通信设施进行通信的分布式应用
- 通信基础设施为apps提供编程接口(通信服务)
网络的结构
边缘系统、接入系统、网络核心
- 网络的边缘
- 主机
- 应用程序(客户端和服务器)
- 网络核心:
- 互连着的路由器
- 网络的网络
- 接入网、物理媒体:
- 有线或者无线通信链路
1.2 网络的边缘
服务模式/应用交互模式:
- CS(Client/Server)模式
- P2P(Peer-to-Peer)模式
采用网络设施的面向连接服务(TCP)
- 目标:在端系统之间传输数据
- 握手:在数据传输之前做好准备
- 两个通信主机之间为连接建立状态
TCP –传输控制协议(Transmission Control Protocol)
- Internet上面向连接的服务
- 可靠地、按顺序地传送数据(确认和重传)
- 流量控制(发送方不会淹没接收方)
- 壅塞控制(当网络拥塞时,发送方降低发送速率)
使用TCP的应用:
- HTTP(Web)
- FTP(文件传输)
- Telnet(远程登录)
- SMTP(email)
采用基础设施的无连接服务(UDP)
- 目标:在端系统之间传输数据 (无连接服务)
UDP –用户数据报协议(User Datagram Potocol) [RFC 768]:
- 无连接
- 不可靠数据传输
- 无流量控制
- 无拥塞控制
使用UDP的应用:
- 流媒体
- 远程会议
- DNS
- Internet电话
1.3 网络的核心
网络核心:路由器的网状网络
基本问题:数据怎样通过网络进行传输?
- 电路交换:为每个呼叫预留一条专有电路:如电话网
- 分组交换:
- 将要传送的数据分成一个个单位:分组
- 将分组从一个路由器传到相邻路由器(hop),一段段最终从源端传到目标端
- 每段:采用链路的最大传输能力(带宽)
电路交换
端到端的资源被分配给从源端到目标端的呼叫 “call”:
- 独享资源:不同享
- 每个呼叫一旦建立起来就能够保证性能(性能保障)
- 如果呼叫没有数据发送,被分配的资源就会被浪费 (no sharing)
- 通常被传统电话网络采用
为呼叫预留端-端资源
- 链路带宽、交换能力
- 专用资源:不共享, 保证性能但浪费资源
- 保证性能
- 要求建立呼叫连接
网络资源(如带宽)被分成片(piece)
- 为呼叫分配片
- 如果某个呼叫没有数据,则其资源片处于空闲状态(不共享)
- 将带宽分成片:
- 频分(FDM, Frequency-division multiplexing)
- 时分(TDM, Time-division multiplexing)
- 波分(WDM, Wave-division multiplexing)
电路交换不适合计算机之间的通信:
- 连接建立时间长
- 计算机之间的通信有突发性,如果使用线路交换,则浪费的片较多
- 即使这个呼叫没有数据传递,其所占据的片也不够被别的呼叫使用
- 可靠性不高?
分组交换
不将链路带宽分成片,而是将数据分成小的数据包(分组)进行传输(传输时不保留资源)
- 以分组为单位存储-转发方式
- 网络带宽资源不再分分为一个个片,传输时使用全部带宽
- 主机之间传输的数据被分为一个个分组,传到一个节点后,整个分组全部被存储,然后再转发
- 资源共享,按需使用:
- 存储-转发:分组每次移动一跳( hop )
- 被传输到下一个链路之前,整个分组必须到达路由器
- 延迟比线路交换要大
- 排队时间
- 在一个速率为R bps的链路,一个长度为L bits的分组的存储转发延时:L/R s
- 存储-转发:分组每次移动一跳( hop )
- 排队延迟和丢失:
- 如果到达速率>链路的输出速率:
- 分组将会排队,等待传输
- 如果路由器的缓存用完了,分组将会被抛弃
- 如果到达速率>链路的输出速率:
- 网络核心的关键功能:
- 路由: 决定分组采用的源到目标的路径
- 路由算法
- 转发: 将分组从路由器的输入链路转移到输出链路
- 路由: 决定分组采用的源到目标的路径
- 分组交换相较于电路交换的特点
- 适合于对突发式数据传输:
- 资源共享
- 简单,不必建立呼叫
- 过度使用会造成网络拥塞:分组延时和丢失
- 对可靠地数据传输需要协议来约束:拥塞控制
- Q:怎样提供类似电路交换的服务?
- 保证音频/视频应用需要的带宽
- 一个仍未解决的问题(chapter 7)
- 适合于对突发式数据传输:
- 分组交换按照网络层有无连接可以分为:
- 数据报网络(Datagram Network)
- 分组的目标地址决定下一跳
- 在不同的阶段,路由可以改变
- 类似:问路
- 不需要握手,每个分组都有完整的目标地址,路由器不维护状态信息(无连接,只负责转发)
- Internent
- 工作原理:
- 在通信之前,无须建立起一个连接,有数据就传输
- 每一个分组都独立路由(路径不一样,可能会失序)
- 路由器根据分组的目标地址进行路由
- 虚电路网络(Virtual Circuit Network)
- 每个分组都带标签(虚电路标识 VC ID),标签决定下一跳
- 在呼叫建立时决定路径,在整个呼叫中路径保持不变
- 路由器维持每个呼叫的状态信息
- X.25和ATM
- 数据报网络(Datagram Network)
1.4 接入网和物理媒体
- 如何将端系统和边缘路由器连接起来?
- 住宅接入网络:modem(猫), DSL(digital subsccriber line), 线缆网络
- 企业接入网络:以太网(ethernet)
- 无线、有线接入网络
住宅接入网络
- Modem
- 将上网数据调制加载音频信号上,在电话线上传输,在局端将其中的数据解调出来;反之亦然
- 调频
- 调幅
- 调相位
- 综合调制 * 拨号调制解调器
- 56Kbps的速率直接接入路由器(通常更低)
- 不能同时上网和打电话:不能总是在线
- DSL
- 采用现存的到交换局DSLAM的电话线
- DSL线路上的数据被传到互联网
- DSL线路上的语音被传到电话网 * < 2.5 Mbps上行传输速率(typically < 1 Mbps) * < 24 Mbps下行传输速率(typically < 10 Mbps) 上行和下行速率不对称,下行速率更高,适用一般用户的需求
- 线缆网络
- 有线电视信号线缆双向改造
- FDM: 在不同频段传输不同信道的数据,数字电视和上网数据(上下行) * HFC: hybrid fiber coax
- 非对称: 最高30Mbps的下行传输速率, 2 Mbps 上行传输率 * 线缆和光纤网络将个家庭用户接入到 ISP 路由器 * 各用户共享到线缆头端的接入网络
- 与DSL不同, DSL每个用户一个专用线路到CO(central office)
企业接入网络(Ethernet)
经常被企业或者大学等机构采用
10 Mbps, 100Mbps, 1Gbps, 10Gbps传输率
现在,端系统经常直接接到以太网络交换机上
无线接入网络
各无线端系统共享无线接入网络(端系统到无线路由器);通过基站或者叫接入点
- 无线LANs:
- 建筑物内部 (100 ft)
- 802.11b/g (WiFi): 11, 54 Mbps
- 传输速率广域无线接入
- 由电信运营商提供 (cellular), 10’s km
- 1 到 10 Mbps
- 3G, 4G: LTE
物理媒体
物理链路:连接每个发送-接收对之间的物理媒体
- 导引型媒体:
- 信号沿着固体媒介被导引:同轴电缆、光纤和光缆、双绞线(TP)
- 非导引型媒体:
- 开放的空间传输电磁波或者光信号,在电磁或者光信号中承载数字数据
- 地面微波、LAN(e.g. WiFi)、广域无线接入(wide-area wireless access)、数字卫星信道
1.5 Internet结构和ISP
网络的网络(网络互联/Network of Networks)
- ISP: Internet Service Provider
- 互联网的接入点
- 互联网的网络
- 互联网的服务提供者
- ICP: Internet Content Provider
- 互联网的内容提供者
- 互联网的应用
- IXPs: Internet Exchange Points
- 互联网交换点
- 互联网的交换
- regional Network
- 区域网络
- 互联网的网络
1.6 分组延时、丢失、吞吐量
这里讨论的是分组交换下的延时与丢失情况
分组延时
分为 节点处理延时、排队延时、传输延时、传播延时
- 节点处理延时:
- 检查 bit级差错
- 检查分组首部和决定将分组导向何处
- 排队延时
- 在输出链路上等待传输的时间
- 依赖于路由器的拥塞程度
- t = I/(1-I)*L/R, 其中I为流量强度
- 传输延时
- R=链路带宽(bps)
- L=分组长度(bits)
- 将分组发送到链路上的时间= L/R
- 存储转发延时
- 传播延时
- d =物理链路的长度
- s =在媒体上的传播速度(~2x108 m/sec)
- 传播延时 = d/s
节点延时
为一个节点上以上四种延时的加总 \(d_{\mathrm{nodal}}=d_{\mathrm{proc}}+d_{\mathrm{queue}}+d_{\mathrm{trans}}+d_{\mathrm{prop}}\)
- $d_{proc}$ = 处理延时
- 通常是微秒数量级或更少
- $d_{queue}$ = 排队延时
- 取决于拥塞程度
R=链路带宽 (bps)
L=分组长度 (bits)
a=分组到达队列的平均速率
- 流量强度I = La/R
- La/R ~ 0:平均排队延时很小
- La/R -> 1:延时变得很大
- La/R > 1:比特到达队列的速率超过了从该队列输出的速率,平均排队延时将趋向无穷大!
- $d_{trans}$ = 传输延时
- 等于L/R, 对低速率的链路而言很大(如拨号),通常为微秒级到毫秒级
- $d_{prop}$ = 传播延时
- 几微秒到几百毫秒
查看Internet的延时和路由:
1
2
traceroute www.baidu.com # Linux 查看到达百度的路由
tracert www.baidu.com # Windows 查看到达百度的路由
分组丢失
- 链路的队列缓冲区容量有限
- 当分组到达一个满的队列时,该分组将会丢失
- 丢失的分组可能会被前一个节点或源端系统重传,或根本不重传
- 分组到达链路的速率超过了链路输出的能力
吞吐量
吞吐量: 在源端和目标端之间传输的速率(数据量/单位时间)
- 瞬间吞吐量:在一个时间点的速率
- 平均吞吐量:在一个长时间内平均值
瓶颈链路:端到端路径上的最低带宽链路$min(R_s,R_c)$
1.7 协议层次及其服务模型
- 层次化方式实现复杂网络功能:
- 将网络复杂的功能分层功能明确的层次,每一层实现了其中一个或一组功能,功能中有其上层可以使用的功能:服务
- 本层协议实体相互交互执行本层的协议动作,目的是实现本层功能,通过接口为上层提供更好的服务
- 在实现本层协议的时候,直接利用了下层所提供的服务本层的服务:借助下层服务实现的本层协议实体之间交互带来的新功能(上层可以利用的)+更下层所提供的服务
服务和服务访问点
- 服务(Service):低层实体向上层实体提供它们之间的通信的能力
- 服务提供者(service provider)
- 服务用户(service user)
原语(primitive):上层使用下层服务的形式,高层使用低层提供的服务,以及低层向高层提供服务都是通过服务访问原语来进行交互的->形式
- 服务访问点 SAP (Services Access Point):上层使用下层提供的服务通过层间的接口/地点;
- 例子:邮箱
- 地址(address):下层的一个实体支撑着上层的多个实体,SAP有标志不同上层实体的作用
- 可以有不同的实现,队列
- 例子:传输层的SAP–端口(port)
服务的类型: 面向连接服务和无连接服务
- 面向连接的服务(Connection-oriented Service)
- 例如:TCP
- 连接(Connection):两个通信实体为进行通信而建立的一种结合
- 面向连接的服务通信的过程:建立连接,通信,拆除连接
- 面向连接的服务的例子:网络层的连接被称为虚电路
- 适用范围:对于大的数据块要传输;不适合小的零星报文
- 特点:保序
- 服务类型:
- 可靠的信息流 传送页面(可靠的获得,通过接收方的确认)
- 可靠的字节流 远程登录
- 不可靠的连接 数字化声音
- 无连接的服务(Connectionless Service)
- 例如:UDP
- 无连接服务:两个对等层实体在通信前不需要建立一个连接,不预留资源;不需要通信双方都是活跃;(例:寄信)
- 特点:不可靠、可能重复、可能失序
- IP分组,数据包;
- 适用范围:适合传送零星数据;
- 服务类型:
- 不可靠的数据报 电子方式的函件
- 有确认的数据报 挂号信
- 请求回答 信息查询
服务和协议
- 服务与协议的区别
- 服务(Service):低层实体向上层实体提供它们之间的通信的能力,是通过原语(primitive)来操作的,上下层级间(垂直)
- 协议(protocol):对等层实体(peer entity)之间在相互通信的过程中,需要遵循的规则的集合,相同层级间(水平)
- 服务与协议的联系
- 本层协议的实现要靠下层提供的服务来实现
- 本层实体通过协议为上层提供更高级的服务
数据单元(DU)
1.8 Internet协议栈
协议栈层次
自上而下
- 应用层(Application Layer):网络应用
- 为人类用户或者其他应用进程提供网络应用服务
- 例如:FTP, SMTP, HTTP, DNS
- 传输层(Transport Layer):主机之间的数据传输
- 在网络层提供的端到端通信基础上,细分为进程到进程,将不可靠的通信变成可靠地通信
- 两个重要功能:区分进程、转不可靠为可靠
- 例如:TCP, UDP
- 网络层(Network Layer):为数据报从源到目的选择路由
- 在链路层的基础上提供端到端的服务,传输单位为组
- 主机主机之间的通信,端到端通信,不可靠
- 网络层的两个重要功能:转发、路由
- 例如:IP,路由协议
- 链路层(Link Layer):相邻网络节点间的数据传输
- 在相邻网络节点间的传输数据,传输单位:帧(frame)(将bit分组)
- 2个相邻2点的通信,点到点通信,可靠或不可靠
- 例如:点对对协议PPP, 802.11(wifi), Ethernet
- 物理层(Physical Layer):在线路上传送bit
各层次的协议数据单元
- 应用层:报文(Message)
- 传输层:报文段(Segment):TCP段,UDP数据报
- 网络层:分组(Packet),如果无连接方式则为数据报(Datagram)
- 数据链路层:帧(Frame)
- 物理层:位(Bit)
封装与解封装
- 网卡主要工作在链路层和物理层。它负责数据的物理传输和数据帧的封装与解封装。
- 交换机主要工作在链路层。它主要负责在局域网内部进行数据帧的转发。
- 在数据传输时要完成两层的解封装和再封装
- 路由器主要工作在网络层。它的主要功能是决定数据包的转发路径,即路由选择。
- 在数据传输时要完成三层的解封装和再封装
ISO/OSI 参考模型
夹在应用层与传输层之间
- 表示层(Presentation Layer)
- 允许应用解释传输的数据,例如:加密,压缩,机器相关的表示转换
- 会话层(Session Layer)
- 数据交换的同步,检查点,恢复
注意:互联网协议栈没有这两层!这些服务,如果需要的话,必须被应用实现。非强制需要
2. 应用层
2.1 应用层协议原理
网络应用的体系结构
有C/S、P2P、混合体 三种结构
- 客户-服务器模式(C/S:client/server)
- 服务器:
- 一直运行
- 固定的IP地址和周知(约定)的端口号
- 扩展性:服务器场
- 数据中心进行扩展
- 扩展性差,可靠性较差
- 当用户达到一个阈值之后性能会急剧下降
- 客户端:
- 主动与服务器通信
- 与互联网有间歇性的连接
- 可能是动态IP地址
- 不直接与其它客户端通信
- 服务器:
- 对等模式(P2P: Peer To Peer)
- 几乎没有一直运行的服务器
- 任意端系统之间可以进行通信
- 每一个节点既是客户端又是服务器
- 自扩展性:新peer节点带来新的服务能力,当然也带来新的服务请求
- 参与的主机间歇性连接且可以改变IP地址
- 难以管理
- 例子: Gnutella,迅雷
- 混合体:客户-服务器和对等体系结构
- 举例:Napster、即时通信
- Napster
- 文件搜索:集中
- 主机在中心服务器上注册其资源
- 主机向中心服务器查询资源位置
- 文件传输:P2P
- 任意Peer节点之间
- 文件搜索:集中
- 即时通信
- 在线检测:集中
- 当用户上线时,向中心服务器注册其IP地址
- 用户与中心服务器联系,以找到其在线好友的位置
- 两个用户之间聊天:P2P
- 在线检测:集中
进程通信-概述
- 客户端进程:发起通信的进程
- 服务器进程:等待连接的进程
- 注意:P2P架构的应用也有客户端进程和服务器进程之分
- 进程:在主机上运行的应用程序
- 同一个主机内:使用进程间通信机制通信(操作系统定义)
- 不同主机间:通过交换报文(Message)来通信
- 使用操作系统提供的通信服务
- 按照应用协议交换报文
- 借助传输层提供的服务
进程通信-编址
分布式进程通信需要解决的问题:
问题1:进程标识和寻址问题(服务用户)
对进程进行编址(addressing)
- 进程为了接收报文,必须有一个标识,即服务访问点(SAP)(发送也需要标识):
- 主机:唯一的32位IP地址
- 仅仅有IP地址不能够唯一标示一个进程;在一台端系统上有很多应用进程在运行
- 所采用的传输层协议:TCP 或 UDP
- 端口号(Port Numbers)
- 用于确定是哪个应用进程,TCP/UDP分别预留不同的端口号(0-2^16)
一些知名端口(Port)号的例子:HTTP: TCP 80 Mail: TCP 25 FTP: TCP 21
- 主机:唯一的32位IP地址
- 一个进程:用IP+port标示 端节点(end point)
- 本质上,任何一对主机进程之间的通信由2个端节点构成
进程通信-Scoket(套接字)
问题2:传输层-应用层提供服务是如何(服务)
- 位置:层间界面的SAP(TCP/IP:socket)
- 形式:应用程序接口API(TCP/IP:socket API)
传输层提供的服务&需要穿过层间的信息
- 层间接口必须要携带的信息(内容,发送方,接收方):
- 要传输的报文(对于本层来说:SDU)
- 谁传的:对方的应用进程的标识:IP + TCP(UDP)端口号
- 传给谁:对方的应用进程的标识:对方的IP + TCP(UDP)端口号
- Socket API:传输层实体(TCP或者UDP实体)根据上述信息进行TCP报文段(UDP数据报)的封装
- 源端口号,目标端口号,数据等(Socket+数据)
- 将IP地址往下交IP实体,用于封装IP数据报:源IP,目标IP
- 简化:传输层提供的服务-层间信息的代表——Socket
- 如果 Socket API 每次传输报文,都携带如此多的信息,太繁琐易错,不便于管理
- 用一个整数代号标示通信的双方或者单方:socket
- 类比操作系统打开文件返回的句柄:对句柄的操作,就是对文件的操作
- TCP Socket:
- UDP Socket
- UDP服务,两个进程之间的通信需要之前无需建立连接:
- 每个报文都是独立传输的
- 前后报文可能给不同的分布式进程
因此,只能用一个整数表示本应用实体的标示
- 因为这个报文可能传给另外一个分布式进程
- 二元组:目标IP(由源端指定),目标port(由源端指定)
- UDP Socket指定了应用所在的一个端节点(endpoint)
- 传输报文时:必须要提供对方IP,port
- 接收报文时:传输层需要上传对方的IP,port
- 在发送-数据报-时,采用创建好的本地Socket(标识ID),就不必在发送每个报文中指明自己所采用的ip和port
- 但是在发送-报文-时,必须要指定对方的ip和udp port(另外一个端节点)
- 穿过层间接口的信息大小最小
- UDP服务,两个进程之间的通信需要之前无需建立连接:
进程通信-应用层协议
问题3:如何使用传输层提供的服务,实现应用进程之间的报文交换,实现应用(用户使用服务)
- 定义应用层协议:报文格式,解释,时序等
- 编制程序,使用OS提供的API,调用网络基础设施提供通信服务传报文,实现应用时序等
- 应用层协议定义了:运行在不同端系统上的应用进程如何相互交换报文
- 交换的报文类型:请求和应答报文
- 各种报文类型的语法:报文中的各个字段及其描述
- 字段的语义:即字段取值的含义
- 进程何时、如何发送报文及对报文进行响应的规则
- 应用协议仅仅是应用的一个组成部分
- Web应用:HTTP协议,web客户端,web服务器,HTML
- 公开协议:由RFC文档定义,允许互操作
- 如HTTP, SMTP
- 专用(私有)协议:协议不公开
- 如:Skype
- 应用协议衡量指标:
- 数据丢失率
- 有些应用要求100%的可靠数据传输,如文件传输
- 有些应用(如音频)能容忍一定比例以下的数据丢失
- 延迟
- 一些应用出于有效性考虑,对数据传输有严格的时间限制,如Internet电话、交互式游戏
- 需要考虑延迟和延迟差异
- 吞吐量
- 一些应用(如多媒体)必须需要最小限度的吞吐量,从而使得应用能够有效运转
- 一些应用能充分利用可供使用的吞吐量(弹性应用)
- 安全性
- 需要考虑数据的机密性、完整性和可认证性(鉴别)
- 数据丢失率
Internet传输层提供的服务(TCP/UDP)
TCP服务
- 可靠的传输服务
- 流量控制:发送方不会淹没接受方
- 拥塞控制:当网络出现拥塞时,能抑制发送方
- 面向连接:要求在客户端进程和服务器进程之间建立连接
- 不能提供的服务:时间保证、最小吞吐保证和安全
TCP安全性:
- TCP & UDP:都没有加密;明文通过互联网传输,甚至密码
- SSL:在TCP上面实现,提供加密的TCP连接(e.g. http->https)
- 具有私密性、数据完整性、端到端的鉴别
- SSL在应用层,应用采用SSL库,SSL库使用TCP通信
- SSL socket API:应用通过API将明文交给socket,SSL将其加密在互联网上传输
UDP服务
- 不可靠数据传输
不提供的服务:可靠,流量控制、拥塞控制、时间、带宽保证、建立连接
- UDP存在的必要性:
- 能够区分不同的进程,而IP服务不能
- 在IP提供的主机到主机端到端功能的基础上,区分了主机的应用进程
无需建立连接:省去了建立连接时间,适合事务性的应用
- 不做可靠性的工作,例如检错重发,适合那些对实时性要求比较高而对正确性要求不高的应用
- 因为为了实现可靠性(准确性、保序等),必须付出时间代价(检错重发)
- 没有拥塞控制和流量控制,应用能够按照设定的速度发送数据
- 而在TCP上面的应用,应用发送数据的速度和主机向网络发送的实际速度是不一致的,因为有流量控制和拥塞控制
- 能够区分不同的进程,而IP服务不能
2.2 Web和HTTP
- URL格式:
1
<协议>://<用户名>:<密码>@<主机域名或者ip地址>:<端口号>/<路径>;<参数>?<查询>#<片段>
举例:
1
http://joe:password@www.baidu.com:80/main/index.html;type=a;color=b?name=bob&id=123#main
- Web页:Web页含有一个基本的HTML文件,该基本HTML文件又包含若干对象的引用(链接)
HTTP概述
- 超文本传输协议,为Web的应用层协议
- 客户/服务器模式
- 客户:请求、接收和显示Web对象的浏览器
- 服务器:对请求进行响应,发送对象的Web服务器
- HTTP 标准:
- HTTP 1.0: RFC 1945
- HTTP 1.1: RFC 2068
- HTTP是无状态的
- 服务器并不维护关于客户的任何信息
- 使用TCP的流程:
- 客户发起一个与服务器的TCP连接 (建立套接字),端口号为 80
- 服务器接受客户的TCP连接
- 在浏览器(HTTP客户端)与 Web服务器(HTTP服务器 server)交换HTTP报文 (应用层协议报文)
- TCP连接关闭
HTTP连接
- 往返时间RTT(round-trip time)
- 非持久连接
- 每个对象都需要一个新的TCP连接
- 服务器在发送一个对象后关闭连接
- 一个对象的传输需要一个新的连接,下载多个对象需要多个TCP连接
- HTTP/1.0默认是非持久连接
- 问题:每个对象的传输都需要建立连接,连接建立和关闭的开销(即每个对象要2个RTT)
- 持久连接
- 多个对象可以在一个(在客户端和服务器之间的)TCP连接上传输
- 服务器在发送响应后,仍保持TCP连接:
- 非流水方式的持久HTTP:
- 客户端只能在收到前一个响应后能发出新的请求
- 每个引用对象花费一个RTT
- 流水方式的持久HTTP:
- HTTP/1.1的默认模式
- 客户端遇到一个引用对象就立即产生一个请求
- 所有引用(小)对象只花费一个RTT是可能的
- 非流水方式的持久HTTP:
- HTTP/1.1默认使用流水线方式的持久连接
- 优点:在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送,客户端在遇到一个引用对象的时候,就可以尽快发送该对象的请求
HTTP报文
两种类型的HTTP报文:请求、响应
格式:
HTTP请求报文
HTTP响应报文
HTTP提交表单输入的方式
- Post方式:
- 网页通常包括表单输入
- 包含在实体主体(entity body )中的输入被提交到服务器
- URL方式:
- 方法:GET
- 输入通过请求行的URL字段上载
- 举例
1 2 3
http://www.baidu.com/s?wd=xx+yy+zzz&cl=3 参数:wd,cl 参数值:XX+YY+zzz,3
- Post方式:
HTTP请求方法类型
- HTTP/1.HTTP/1.0
- GET:从服务器获取资源。用于请求数据而不对数据进行更改。例如,从服务器获取网页、图片等。
- POST:向服务器发送数据以创建新资源。常用于提交表单数据或上传文件。发送的数据包含在请求体中。
- HEAD:类似于 GET,但服务器只返回响应的头部,不返回实际数据。用于检查资源的元数据(例如,检查资源是否存在,查看响应的头部信息)。
- 要求服务器在响应报文中不包含请求对象,用于故障跟踪
- HTTP/1.1
- GET, POST, HEAD
- PUT
- 将实体主体中的文件上载到URL字段规定的路径
- DELETE
- 删除URL字段规定的文件
HTTP状态码
当浏览者访问一个网页时,浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前,此网页所在的服务器会返回一个包含 HTTP 状态码的信息头(server header)用以响应浏览器的请求。
位于服务器->客户端的响应报文中的首行
举例: 200 OK | 404 Not Found |
使用telnet命令请求网页
1
2
? telnet www.baidu.com 80
? GET /index.html HTTP/1.1
用户-服务器状态:cookies
4个组成部分:
- 在HTTP响应报文中有一个cookie的首部行
- 在HTTP请求报文含有一个cookie的首部行
- 在用户端系统中保留有一个cookie文件,由用 户的浏览器管理
- 在Web站点有一个后端数据库
Cookie的工作过程:
- 用户首次访问一个站点,服务器创建一个cookie,将其发送给用户
- 用户在后续访问站点时,将cookie发送给服务器
- 服务器检查cookie,以识别用户
- 服务器可以将cookie的内容存储在后端数据库中
- 服务器可以使用cookie来跟踪用户的购物车,用户的浏览历史等
Cookie维持状态:
- Cookie实现了HHTP的无状态性下的状态维持
- 还可以通过协议端节点维持状态
Web缓存
- 缓存既是客户端又是服务器
- 通常缓存是由ISP安装 (大学、公司、居民区ISP)
缓存的优点:
- 降低客户端的请求响应时间
- 可以大大减少一个机构内部网络与Internent接入链路上的流量(二八分布,80%的流量指向20%的站点)
- 互联网大量采用了缓存:可以使较弱的ICP也能够有效提供内容
条件GET:缓存服务器向源服务器发送一个条件GET请求,只有在源服务器的对象已经改变的情况下,源服务器才会发送对象
- 目标:如果缓存器中的对象拷贝是最新的,就不 发送对象
- 缓存器:在HTTP请求中指定缓存拷贝的日期:
1 2
If-modified-since: <date>
- 服务器:如果缓存拷贝陈旧,则响应报文没包含对象:
1 2
HTTP/1.0 304 Not Modified
2.3 FTP
FTP:控制连接与数据连接分开
- FTP客户端与FTP服务器通过端口21联系,并使用TCP为传输协议
- 客户端通过控制连接获得身份确认
- 客户端通过控制连接发送命令浏览远程目录
- 收到一个文件传输命令时,服务器打开一个到客户端的数据连接
- 一个文件传输完成后,服务器关闭连接
- 服务器打开第二个TCP数据连接用来传输另一个文件
- 控制连接:带外(“out of band”)传送
- FTP服务器维护用户的状态信息:当前路径、用户帐户与控制连接对应(有状态)
FTP命令、响应
命令样例:
- 在控制连接上以ASCII文本方式传送
USER username
PASS password
LIST
:请服务器返回远程主机当前目录的文件列表RETR filename
:从远程主机的当前目录检索文件 (gets)STOR filename
:向远程主机的当前目录存放文件 (puts)
返回码样例:
- 状态码和状态信息 (同HTTP)
331 Username OK, password required
125 data connection already open; transfer starting
425 Can’t open data connection
452 Error writing file
2.4 EMail
Email3个主要组成部分:
- 用户代理
- 邮件服务器
- 简单邮件传输协议:SMTP
用户代理
- 又名 “邮件阅读器”
- 撰写、编辑和阅读邮件
- 如Outlook、Foxmail
- 输出和输入邮件保存在服务器上
邮件服务器
- 邮箱中管理和维护发送给用户的邮件
- 输出报文队列保持待发送邮件报文
- 邮件服务器之间的SMTP协议用于发送email报文
- 客户:发送方邮件服务器
- 服务器:接收端邮件服务器
邮件访问协议
发送协议:SMTP
拉取协议:POP3、IMAP、HTTP
- SMTP: 传送到接收方的邮件服务器
- 邮件访问协议:从服务器访问邮件
- POP:邮局访问协议(Post Office Protocol)[RFC 1939]
- 用户身份确认 (代理<–>服务器)并下载
- IMAP:Internet邮件访问协议(Internet Mail Access Protocol)[RFC 1730]
- 更多特性 (更复杂)
- 在服务器上处理存储的报文
- HTTP:Hotmail , Yahoo! Mail等
- 方便
- POP:邮局访问协议(Post Office Protocol)[RFC 1939]
SMTP
- 使用TCP在客户端和服务器之间传送报文,端口号为25
- 直接传输:从发送方服务器到接收方服务器
- 传输的3个阶段
- 握手
- 传输报文
- 关闭
- 命令/响应交互
- 命令:ASCII文本
- 响应:状态码和状态信息
- 报文必须为7位ASCII码
特点:
- SMTP使用持久连接
- SMTP要求报文(首部和主体)为7位ASCII编a
- SMTP服务器使用CRLF.CRLF决定报文的尾部
邮件报文格式
RFC 822:文本报文的标准:
- 首部行:如
- To:
- From:
- Subject: (与SMTP命令不同)
- 主体
- 报文,只能是ASCII码字符(故需要扩展)
报文格式:多媒体扩展——MIME:多媒体邮件扩展(multimedia mail extension)
POP3协议
流程:
- 用户确认阶段
- 客户端命令:
- user: 申明用户名
- pass: 口令
- 服务器响应
- +OK
- -ERR
- 客户端命令:
- 事物处理阶段, 客户端:
- list: 报文号列表
- retr: 根据报文号检索报文
- dele: 删除
- quit
- POP3在会话中是无状态的
注:上述处理阶段为“下载并删除”模式(如果改变客户机,就不能阅读邮件),“下载并保留”:不同 客户机上为报文的拷贝
IMAP
- IMAP服务器将每个报文与一个文件夹联系起来
- 允许用户用目录来组织报文
- 允许用户读取报文组件
- IMAP在会话过程中保留用户状态:
- 目录名、报文ID与目录名之间映射
2.5 DNS(Domain Name System)
- DNS的必要性
- IP地址标识主机、路由器,但IP地址不好记忆,不便人类使用(没有意义)
- 存在着“字符串”—IP地址的转换的必要性
- 人类用户提供要访问机器的“字符串”名称
- 由DNS负责转换成为二进制的网络地址
- 问题1:如何命名设备
- 用有意义的字符串:好记,便于人类用使用
- 解决一个平面命名的重名问题:层次化命名
- 问题2:如何完成名字到IP地址的转换
- 分布式的数据库维护和响应名字查询
- 问题3:如何维护:增加或者删除一个域,需要在域名系统中做哪些工作
DNS总体思路和目标
DNS的主要思路
- 分层的、基于域的命名机制
- 若干分布式的数据库完成名字到IP地址的转换
- 运行在UDP之上端口号为53的应用服务
- 核心的Internet功能,但以应用层协议实现
- 在网络边缘处理复杂性
DNS主要目的:
- 实现主机名-IP地址的转换(name/IP translate)
- 其它目的:
- 主机别名到规范名字的转换:Host aliasing
- 邮件服务器别名到邮件服务器的正规名字的转换:Mail server aliasing
- 负载均衡:Load Distribution
DNS名字空间(The DNS Name Space)
- DNS域名结构
- 一个层面命名设备会有很多重名(ARPANET解决方案的缺点)
- NDS采用层次树状结构的命名方法
- Internet根被划为几百个顶级域(top lever domains)
- 通用的(generic)
- .com; .edu ; .gov ; .int ; .mil ; .net ; .org
- .firm ; .hsop ; .web ; .arts ; .rec ;
- 国家的(countries)
- .cn ; .us ; .nl ; .jp
- 通用的(generic)
- 每个(子)域下面可划分为若干子域(subdomains)
- 叶节点是主机
- 域名的管理
- 一个域管理其下的子域
- 例如,
.jp
被划分为ac.jp
,co.jp
- 例如,
.cn
被划分为edu.cn
,com.cn
- 例如,
- 创建一个新的域,必须征得它所属域的同意
- 一个域管理其下的子域
- 域与物理网络无关
- 域遵从组织界限,而不是物理网络
- 一个域的主机可以不在一个网络
- 一个网络的主机不一定在一个域
- 域的划分是逻辑的,而不是物理的
- 域遵从组织界限,而不是物理网络
名字服务器(Name Server)
- 一个名字服务器的问题
- 可靠性问题:单点故障
- 扩展性问题:通信容量
- 维护问题:远距离的集中式数据库
- 区域(zone)
- 区域的划分有区域管理者自己决定
- 将DNS名字空间划分为互不相交的区域,每个区域都是树的一部分
- 名字服务器:
- 每个区域都有一个名字服务器:维护着它所管辖区域的权威信息(authoritative record)
- 名字服务器允许被放置在区域之外,以保障可靠性
权威DNS服务器:组织机构的DNS服务器, 提供组织机构服务器(如Web和mail)可访问的主机和IP之间的映射组织机构可以选择实现自己维护或由某个服务提供商来维护
- 顶级域(TLD)服务器:负责顶级域名(如com, org, net, edu和gov)和所有国家级的顶级域名(如cn, uk, fr, ca, jp)
- Network solutions公司维护com TLD服务器
- Educause公司维护edu TLD服务器
- 本地名字服务器(Local Name Server)
- 并不严格属于层次结构
- 每个ISP(居民区的ISP、公司、大学)都有一个本地DNS服务器
- 也称为“默认名字服务器”
- 当一个主机发起一个DNS查询时,查询被送到其本地DNS服务器
- 起着代理的作用,将查询转发到层次结构中
资源记录(resource records)
区域名字服务器维护资源记录
- 资源记录(Resource Records)
- 作用:维护 域名-IP地址(其它)的映射关系
- 位置:Name Server的分布式数据库中
- RR格式: (domain_name, ttl, type, class, value)
- Domain_name: 域名
- Ttl: time to live :生存时间(权威,缓冲记录),决定了资源记录应当从缓存中删除的时间
- 缓存:提高性能
- 删除:一致性
- Class: 类别,对于Internet,值为IN
- Value: 值,可以是数字,域名或ASCII串
- Type: 类别,资源记录的类型:
Type=A
- Name为主机
- Value为IP地址
Type=NS
- Name: 域名(如foo.com)
- Value: 该域名的权威服务器的域名
Type=CNAME
- Name: 规范名字的别名 (例如,www.ibm.com的规范名字为servereast.backup2.ibm.com)
- Value: 规范名字
Type=MX
- Value: name对应的邮件服务器的名字
DNS工作过程
- DNS大致工作过程
- 名字解析过程
- case1:目标名字在Local Name Server中:
- 情况1:查询的名字在该区域内部
- 情况2:缓存(cashing)
- case2:当与本地名字服务器不能解析名字时
- 联系根名字服务器顺着根-TLD一直找到权威名字服务器
- case1:目标名字在Local Name Server中:
查询方式:递归、迭代
- 缓存:
- 一旦名字服务器学到了一个映射,就将该映射缓存起来
- 根服务器通常都在本地服务器中缓存着
- 使得根服务器不用经常被访问
- 目的:提高效率
- 可能存在的问题:如果情况变化,缓存结果和权威资源记录不一致
- 解决方案:TTL(默认2天)
DNS协议、报文
DNS协议:查询和响应报文的报文格式相同
DNS维护:新增一个域
- 在上级域的名字服务器中增加两条记录,指向这个新增子域的域名和域名服务器的地址
- 在新增子域的名字服务器上运行名字服务器,负责本域的名字解析: 名字->IP地址
- 例子:在com域中建立一个“Network Utopia”
- 到注册登记机构注册域名networkutopia.com
- 需要向该机构提供权威DNS服务器(基本的、和辅助的)的名字和IP地址
- 登记机构在com TLD服务器中插入两条RR记录:
- (networkutopia.com, dns1.networkutopia.com, NS)
- (dns1.networkutopia.com, 212.212.212.1, A)
- 在networkutopia.com的权威服务器中确保有
- 用于Web服务器的www.networkuptopia.com的类型为A的记录
- 用于邮件服务器mail.networkutopia.com的类型为MX的记录
- 到注册登记机构注册域名networkutopia.com
攻击DNS
- DDoS 攻击
- 对根服务器进行流量轰炸
- 攻击:发送大量ping
- 没有成功
- 原因1:根目录服务器配置了流量过滤器,防火墙
- 原因2:Local DNS 服务器缓存了TLD服务器的IP地址, 因此无需查询根服务器
- 向TLD服务器流量轰炸攻击:发送大量查询
- 可能更危险
- 效果一般,大部分DNS缓存了TLD
- 对根服务器进行流量轰炸
- 重定向攻击
- 中间人攻击
- 截获查询,伪造回答,从而攻击某个(DNS回答指定的IP)站点
- DNS中毒
- 发送伪造的应答给DNS服务器,希望它能够缓存这个虚假的结果
- 技术上较困难:分布式截获和伪造
- 中间人攻击
- 利用DNS基础设施进行DDoS
- 伪造某个IP进行查询, 攻击这个目标IP
- 查询放大,响应报文比查询报文大
- 效果有限
2.6 P2P
- P2P:
- 没有(或极少)一直运行的服务器
- 任意端系统都可以直接通信
- 利用peer的服务能力
- Peer节点间歇上网,每次IP地址都有可能变化
- 举例:文件分发 (BitTorrent) 流媒体(KanKan) VoIP (Skype)
- C/S模式与P2P模式下载速度对比
P2P文件共享
- 网络问题
- 如何定位所需资源
- 如何处理对等方的加入与离开
- 可能的解决方案
- 集中式:所有的资源和服务都由一个或几个中心节点提供。
- 分散式:资源和服务分布在所有的节点中,每个节点都有相等的地位。
- 半分散式:结合了集中式和分散式的特点,部分资源和服务由中心节点提供,部分由其他节点提供。
非结构化P2P与DHT(结构化)P2P
具体待补充, 结构化是将peer组织成类似树/图的结构,而非结构化是将各个peer直接相连
非结构化P2P
- 集中式目录
- 完全分布式(泛洪查询)
- 混合体
DHT(结构化)P2P
集中式目录
最初的“Napster”设计:
- 当对等方连接时,它告知中心服务器:
- IP地址
- 内容
- Alice查询 “双截棍.MP3”
- Alice从Bob处请求文件
集中式目录中存在的问题:
- 单点故障
- 性能瓶颈
- 侵犯版权
文件传输是分散的,而定位内容则是高度集中的
查询洪泛:Gnutella
泛洪查询(Flooding Query)是一种在网络中广播查询的方法,主要用于在无中心或分布式网络中查找信息。其工作原理如下:
- 当一个节点需要查找某个信息时,它会将查询请求发送给它所知道的所有其他节点(邻居节点)。
- 这些收到查询请求的节点会检查自己是否有所需的信息。如果有,它们会将信息返回给查询的节点。如果没有,它们会将查询请求再次发送给它们所知道的所有其他节点(邻居节点)。
- 这个过程会一直重复,直到找到所需的信息,或者查询请求已经被发送给了所有的节点。
这种方法的优点是能够在没有中心节点的情况下查找信息,但缺点是会产生大量的网络流量且不易于管理,因为每个查询请求都需要被发送给网络中的每个节点。
如何创建邻居节点:
- 对等方X必须首先发现某些已经在覆盖网络中的其他对等方:使用可用对等方列表自己维持一张对等方列表(经常开机的对等方的IP)联系维持列表的Gnutella站点
- X接着试图与该列表上的对等方建立TCP连接,直到与某个对等方Y建立连接
- X向Y发送一个Ping报文,Y转发该Ping报文
- 4.所有收到Ping报文的对等方以Pong报文响应IP地址、共享文件的数量及总字节数
- X收到许多Pong报文,然后它能建立其他TCP连接
混合体(利用不匀称性:KaZaA)
结构:
- 每个对等方要么是一个组长,要么隶属于一个组长
- 对等方与其组长之间有TCP连接
- 组长对之间有TCP连接
- 组长跟踪其所有的孩子的内容
- 组长与其他组长联系
- 转发查询到其他组长
- 获得其他组长的数据拷贝
如何查询:
- 每个文件有一个散列标识码(HASH值)和一个描述符
- 客户端向其组长发送关键字查询
- 组长用匹配进行响应:
- 对每个匹配:元数据、散列标识码和IP地址
- 如果组长将查询转发给其他组长,其他组长也以匹配进行响应
- 客户端选择要下载的文件
- 向拥有文件的对等方发送一个带散列标识码的HTTP请求
技巧:
- 请求排队
- 限制并行上载的数量
- 确保每个被传输的文件从上载节点接收一定量的带宽
- 激励优先权
- 鼓励用户上载文件
- 加强系统的扩展性
- 并行下载
- 从多个对等方下载同一个文件的不同部分
- HTTP的字节范围首部
- 更快地检索一个文件
举例:BitTorrent
待补充
2.7 CDN和视频流化服务
- 挑战:
- 规模性
- 视频流量:占据着互联网大部分的带宽
- 单个超级服务器无法提供服务,原因如下:
- 服务器到客户端路径上跳数较多,瓶颈链路的带宽小导致停顿
- “二八规律”决定了网络同时充斥着同一个视频的多个拷贝,效率低(付费高、带宽浪费、效果差)
- 单点故障点,性能瓶颈
- 周边网络的拥塞
- 不可扩展
- 异构性
- 不同用户拥有不同的能力(例如:有线接入和移动用户;带宽丰富和受限用户)
- 规模性
- 解决方案: 分布式的,应用层面的基础设施(CDN)
CDN概念
CDN(内容分发网络 Content distribution networks)是一种网络技术,用于通过在各地部署节点服务器,将网站或其他网络服务的内容分发到最接近用户的节点,从而加快用户访问速度和提高用户体验。其主要工作原理如下:
- 当用户请求某个网络服务时,CDN会将请求重定向到离用户最近的节点。 如果该节点已经缓存了所需的内容,它会直接将内容返回给用户。如果没有,它会从源服务器或其他节点获取内容,然后返回给用户,并将内容缓存起来,以便下次能直接提供服务。
- CDN的主要优点是可以显著提高用户访问速度,减轻源服务器的负载,提高服务的可用性和稳定性。常见的CDN服务提供商有Akamai、Cloudflare、Fastly等。
CDN特点
- 全网部署缓存节点,存储服务内容,就近为用户提供服务,提高用户体验
- Enter deep: 将CDN服务器深入到许多接入网
- 更接近用户,数量多,离用户近,管理困难
- Akamai, 1700个位置
- Bring home: 部署在少数(10个左右)关键位置,如将服务器簇安装于POP附近(离若干$1^{st} ISP POP$较近)
- 采用租用线路将服务器簇连接起来
- Limelight
- CDN: 在CDN节点中存储内容的多个拷贝
- 用户从CDN中请求内容
- 重定向到最近的拷贝,请求内容
- 如果网络路径拥塞,可能选择不同的拷贝