admin 管理员组

文章数量: 887021

计算机网络

目录

  • 专栏
  • 网络应用(上)
    • 网络应用(层)内容概述
    • 网络应用的基本原理
      • 网络应用体系结构
        • 客户机/服务器结构
        • 纯P2P结构
        • 混合结构
      • 网络应用进程通信
        • 网络应用的基础:进程间通信
        • 套接字:Socket
        • 如何寻址进程
        • 应用层协议
      • 网络应用需求
        • 网络应用对传输服务的需求
        • Internet提供的传输服务
    • Web应用
      • Web应用概述
        • Web与HTTP
        • HTTP协议概述
      • HTTP连接
        • 非持久性连接
        • 持久性HTTP
      • HTTP消息格式
        • HTTP请求消息
        • 上传输入的方法
        • HTTP响应消息
      • Cookie技术
      • Web缓存技术
        • Web缓存示例
    • Email应用
      • Email应用概述
        • Email应用的构成
        • SMTP协议:RFC 2821
      • Email消息格式与POP协议
        • Email消息格式
        • 邮件访问协议
        • POP协议
        • IMAP协议
    • DNS应用
      • DNS概述
        • 分布式层次式数据库
        • DNS根域名服务器
        • TLD和权威域名解析服务器
        • 本地域名解析服务器
        • DNS查询示例
          • 例题
        • DNS记录缓存和更新
      • DNS记录和消息格式
        • DNS记录
        • DNS协议与消息
        • 如何注册域名?

专栏

计算机网络

网络应用(上)

网络应用(层)内容概述

  • 网络应用体系结构
    • 客户机/服务器
    • P2P
    • 混合结构
  • 网络应用的服务需求
    • 可靠性
    • 带宽
    • 时延
  • Internet传输层服务模型
    • TCP
    • UDP
  • 特定网络应用及协议
    • HTTP
    • SMTP,POP,IMAP
    • DNS
    • P2P应用
  • Socket编程
    • TCP
    • UDP

网络应用的基本原理

网络应用体系结构

你使用过哪些网络应用?

网络应用有哪些特点?

与单机应用有哪些本质性的不同?

网络应用应采取什么样的体系结构?

网络应用的体系结构

  • 客户机/服务器结构(Client-Server,C/S)
  • 点对点结构(Peer-to-peer,P2P)
  • 混合结构(Hybrid)

客户机/服务器结构

  • 服务器
    • 7*24小时提供服务
    • 永久性访问地址/域名
    • 利用大量服务器实现可扩展性
  • 客户机
    • 与服务器通信,使用服务器提供的服务
    • 间歇性接入网络
    • 可能使用动态的IP地址
    • 不会与其他客户机直接通信
  • 例子:Web

纯P2P结构

  • 没有永远在线的服务器
  • 任意端系统/节点之间可以直接通讯
  • 节点间歇性接入网络
  • 节点可能改变IP地址
  • 优点:高度可伸缩
  • 缺点:难于管理

混合结构


能否将两种结构混合在一起使用?

混合能够利用两种的优点同时规避两种的缺点吗?

  • Napster
    • 文件传输使用P2P结构
  • 文件的搜索采用C/S结构——集中式
    • 每个节点向中央服务器登记自己的内容
    • 每个节点向中央服务器提交查询请求,查找感兴趣的内容

网络应用进程通信

网络应用的基础:进程间通信

  • 进程:
    • 主机上运行的程序
  • 同一主机上运行的进程之间如何通信?
    • 进程间通信机制
    • 操作系统提供
  • 不同主机上运行的进程间如何通信?
    • 消息交换

套接字:Socket

  • 进程间通信利用socket发送/接收消息实现
  • 类似于寄信
    • 发送方将信息送到门外邮箱
    • 发送方依赖(门外的)传输基础设施将消息传到接收方所在主机,并送到接收方的门外
    • 接收方从门外获取信息
  • 传输基础设施向进程提供API
    • 传输协议的选择
    • 参数的设置

如何寻址进程

  • 不同主机上的进程间通信,那么每个进程必须拥有标识符
  • 如何寻址主机?——IP地址
    • Q主机有了IP地址后,是否足以定位进程?
    • A否。同一主机上可能同时有多个进程需要通信。
  • 端口号/Port number
    • 为主机上每个需要通信的进程分配一个端口号
    • HTTP Server:80
    • Mail Server:25
  • 进程的标识符
    • IP地址+端口号

应用层协议

  • 网络应用需遵循应用层协议
  • 公开协议
    • 由RFC(Request For Comments)定义
    • 允许互操作
    • HTTP,SMTP,…
  • 私有协议
    • 多数P2P文件共享应用

应用层协议的内容

  • 消息的类型(type)
    • 请求消息
    • 响应消息
  • 消息的语法(syntax)/格式
    • 消息中有哪些字段(field)?
    • 每个字段如何描述
  • 字段的语义(semantics)
    • 字段中信息的含义
  • 规则(rules)
    • 进程何时发送/响应信息

网络应用需求

网络应用对传输服务的需求

  • 数据丢失(data loss)/可靠性(reliability)
    • 某些网络应用能够容忍一定的数据丢失:网络电话
    • 某些应用要求100%可靠的数据传输:文件传输,telnet
  • 时间(timing)/延迟(delay)
    • 有些应用只有在延迟足够低时才“有效”
    • 网络电话/网络游戏
  • 带宽(bandwidth)
    • 某些应用只有在带宽达到最低要求时才“有效”:网络视频
    • 某些应用能够适应任何带宽——弹性应用:email

典型网络应用对传输服务的需求

Internet提供的传输服务

  • TCP服务
    • 面向连接:客户机/服务器进程间需要建立连接
    • 可靠的传输
    • 流量控制:发送方不会发送速度过快,超过接收方的处理能力
    • 拥塞控制:当网络负载过重时能够限制发送方的发送速度
    • 不提供时间/延迟保障
    • 不提供最小带宽保障
  • UDP服务
    • 无连接
    • 不可靠的数据传输
    • 不提供:
      • 可靠性保障
      • 流量控制
      • 拥塞控制
      • 延迟保障
      • 带宽保障

典型网络应用所使用的传输层服务

Web应用

Web应用概述

Web与HTTP

  • World Wide Wed:Tim Berners-Lee
    • 网页
    • 网页互相链接
  • 网页(Web Page)包含多个对象(objects)
    • 对象:HTML文件、JPEG图片、视频文件、动态脚本等
    • 基本HTML文件:包含对其他对象引用的链接
  • 对象的寻址(addressing)
    • URL(Uniform Resoure Locator):统一资源定位器 RFC1738
    • Scheme://host:port/path

HTTP协议概述

  • 万维网应用遵循什么协议?

  • 超文本传输协议

    • HyperText Transfer Protocol
  • C/S结构

    • 客户——Browser:请求、接收、展示Web对象
    • 服务器——Web Server:响应客户的请求,发送对象
  • HTTP版本:

  • 1.0:RFC 1945

  • 1.1:RFC 2068

  • 使用TCP传输服务

    • 服务器在80端口等待客户的请求
    • 浏览器发起到服务器的TCP连接(创建套接字Socket)
    • 浏览器接受来自浏览器的TCP连接
    • 浏览器(HTTP客户端)与Web服务器(HTTP服务器)交换HTTP消息
    • 关闭TCP连接
  • 无状态(stateless)

    • 服务器不维护任何有关客户端过去所发请求的消息
    • 为什么要采用无状态的协议?

HTTP连接

HTTP连接的两种类型

  • 非持久性连接(Nonpersistent HTTP)
    • 每个TCP连接最多允许传输一个对象
    • HTTP 1.0版本使用非持久性连接
  • 持久性连接(Persistent HTTP)
    • 每个TCP连接允许传输多个对象
    • HTTP 1.1版本默认使用持久性连接

非持久性连接



响应时间分析与建模

  • RTT(Round Trip Time)
    • 从客户端发送一个很小的数据包到服务器并返回所经历的时间
  • 响应时间(Response time)
    • 发起、建立TCP连接:1个RTT
    • 发送HTTP请求消息到HTTP响应消息的前几个字节到达:1个RTT
    • 响应消息中所含的文件/对象传输时间
    • Total=2RTT + 文件发送时间

持久性HTTP

  • 非持久性连接的问题
    • 每个对象需要2个RTT
    • 操作系统需要为每个TCP连接开销资源(overhead)
    • 浏览器会怎么做?
      • 打开多个并行的TCP连接以获取网页所需对象
      • 给服务器端造成影响
  • 持久性连接
    • 发送响应后,服务器保持TCP连接的打开
    • 后续的HTTP消息可以通过这个连接发送
    • 无流水(pipelining)的持久性连接
      • 客户端只有收到前一个响应后才发送新的请求
      • 每个被引用的对象耗时1个RTT
    • 带有流水机制的持久性连接
      • HTTP 1.1的默认选项
      • 客户端只要遇到一个引用对象就尽快发出请求
      • 理想情况下,收到所有的引用对象只需耗时约1个RTT

HTTP消息格式

HTTP请求消息

  • HTTP协议有两类消息
    • 请求消息(request)
    • 响应信息(response)
  • 请求消息
    • ASCII:人直接可读

HTTP请求消息的通用格式

上传输入的方法

  • POST方法
    • 网页经常需要填写表格(form)
    • 在请求消息的消息体(entity body)中上传客户端的输入
  • URL方法
    • 使用GET方法
    • 输入信息通过request行的URL字段上传

方法的类型

  • HTTP/1.0
    • GET
    • POST
    • HEAD
      • 请Server不要将所有请求的对象放入响应消息中
  • HTTP/1.1
    • GET,POST,HEAD
    • PUT
      • 将消息体中的文件上传到URL字段所指定的路径
    • DELETE
      • 删除URL字段所指定的文件

HTTP响应消息

HTTP响应状态代码

  • 响应消息的第一行
  • 示例
    • 200 OK
    • 301 Moved Permanently
    • 400 Bad Request
    • 404 Not Found
    • 505 HTTP Version Not Supported

体验HTTP

  • 利用telnet登录到某个Web服务器
    • telnet www.hit.edu.cn 80
  • 输入一个HTTP请求
    • GET /about/profile.htm HTTP/1.1
    • Host:www.hit.edu.cn
  • 查看HTTP服务器所返回的响应信息

Cookie技术

为什么需要Cookie?

HTTP无状态

很多应用需要服务器掌握客户端的状态,如网上购物,如何实现?

Cookie技术

  • 某些网站为例辨别用户身份、进行session跟踪而存储在用户本地终端上的数据(通常经过加密)。
  • RFC6265

Cookie的组件

  • HTTP响应消息的cookie头部行
  • HTTP请求消息的cookie头部行
  • 保存在客户端主机上的cookie文件,由浏览器管理
  • Web服务端的后台数据库

Cookie的原理

Cookie的作用

  • Cookie能够用于:
    • 身份认证
    • 购物车
    • 推荐
    • Web e-mail
  • 隐私问题

Web缓存技术

  • 功能
    • 在不访问服务器的前提下满足客户端的HTTP请求。
  • 为什么要发明这种技术?
    • 缩短客户请求的响应时间
    • 减少机构/组织的流量
    • 在大范围内(Internet)实现有效的内容分发
  • Web缓存/代理服务器
    • 用户设定浏览器通过缓存进行Web访问
    • 浏览器向缓存/代理服务器发送所有的HTTP请求
      • 如果所请求的对象在缓存中,缓存返回对象
      • 否则,缓存服务器向原始服务器发送HTTP请求,获取对象,然后返回给客户端并保存该对象
    • 缓存既充当服务器,也充当服务器
    • 一般由ISP(Internet服务提供商)架设

Web缓存示例

  • 假定:
    • 对象的平均大小=100,100比特
    • 机构网络中的浏览器平均每秒有15个到原始服务器的请求
    • 从机构路由器到原始服务器的往返延迟=2秒
  • 网络性能分析:
    • 局域网(LAN)的利用率 = 15%
    • 接入互联网的链路的利用率 = 100%
    • 总的延迟 = 互联网上的延迟 + 访问延迟 + 局域网延迟 = 2秒 + 几分钟 + 几微秒

  • 解决方案1
    • 提升互联网接入带宽 = 10Mbps
  • 网络性能分析:
    • 局域网(LAN)的利用率 = 15%
    • 接入互联网的链路的利用率 = 15%
    • 总的延迟 = 互联网上的延迟 + 访问延迟 + 局域网延迟 = 2秒 + 几微秒 + 几微秒
  • 问题:
    • 成本太高

  • 解决方案2
    • 安装Web缓存
    • 假定缓存命中率是0.4
  • 网络性能分析:
    • 40%的请求立刻得到满足
    • 60%的请求通过原始服务器满足
    • 接入互联网的链路的利用率下降到60%,从而其延迟可以忽略不计,例如10微妙
    • 总的平均延迟 = 互联网上的延迟 + 访问延迟 + 局域网延迟 = 0.6 * 2.01 + 0.4 * n微秒 < 1.4秒

条件性GET方法

  • 目标:
    • 如何缓存版本有最新的版本,则不需要发送请求对象
  • 缓存:
    • 在HTTP请求消息中声明所持有版本的日期
    • If-modified-since:< date >
    • HTTP/1.0 304 Not Modified

Email应用

Email应用概述

Email应用的构成

  • Email应用的构成组件

    • 邮件客户端(user agent)
    • 邮件服务器
    • SMTP协议(Simple Mail Transfer Protocol)
  • 邮件客户端

    • 读、写Email消息
    • 与服务器交互,收、发Email消息
    • Outlook,Foxmail,Thunderbird
    • Web客户端
  • 邮件服务器(Mail Server)

    • 邮箱:存储发给该用户的Email
    • 消息队列(message queue):存储等待发送的Email
  • SMTP协议

    • 邮件服务器之间传递消息所使用的协议
    • 客户端:发送消息的服务器
    • 服务器:接收消息的服务器

SMTP协议:RFC 2821

  • 使用TCP进行email消息的可靠传输
  • 端口25
  • 传输过程的三个阶段
    • 握手
    • 消息的传输
    • 关闭
  • 命令/响应交互模式
    • 命令(command):ASCII文本
    • 响应(response):状态代码和语句
  • Email消息只能包含7位ASCII码

Email应用示例

SMTP交互示例

动手尝试SMTP交互

  • telnet servername 25
  • 服务器返回代码220
  • 输入以下命令与SMTP服务器交互
    • HELO
    • MALL FROM
    • RCPT TO
    • DATA
    • QUIT

SMTP协议

  • 使用持久性连接
  • 要求消息必须由7位ASCII码构成
  • SMTP服务器利用CRLF.CRLF确定消息的结束

与HTTP对比

  • HTTP:拉式(pull)
  • SMTP:退式(push)
  • 都使用命令/响应交互模式
  • 命令和状态代码都是ASCII码
  • HTTP:每个对象封装在独立的响应消息中
  • SMTP:多个对象在由多个部分构成的消息中发送

Email消息格式与POP协议

Email消息格式

  • SMTP:email消息的传输/交换协议
  • RFC 822:文本消息格式标准
    • 头部行(header)
      • To
      • From 与SMTP不同
      • Subject
    • 消息体(body)
      • 消息本身
      • 只能是ASCII字符

多媒体扩展

  • MIME:多媒体邮件扩展 RFC 2045,2056
    • 通过在邮件头部增加额外的行以声明MIME的内容类型

邮件访问协议

  • 邮件访问协议:从服务器获取邮件
    • POP:Post Office Protocol [RFC 1939]
  • IMAP:Internet Mail Access Protocol [RFC 1730]
    • 更多功能
    • 更加复杂
    • 能够操纵服务器上存储的消息
  • HTTP:163,QQ Mail等。

POP协议

  • 认证过程
    • 客户端命令
      • User:声明用户名
      • Pass:声明密码
    • 服务器响应
      • +OK
      • -ERR
  • 事物阶段
    • List:列出消息数量
    • Retr:用编号获取消息
    • Dele:删除消息
    • Quit
  • “下载并删除”模式
    • 用户如果换了客户端软件,无法重读该邮件
  • “下载并保持”模式:不同客户端都可以保留消息的拷贝
  • POP3是无状态的

IMAP协议

  • 所有消息统一保存在一个地方:服务器
  • 运行用户利用文件夹组织消息
  • IMAP支持跨会话(Session)的用户状态:
    • 文件夹的名字
    • 文件夹与消息ID之间的映射

DNS应用

DNS概述

DNS:Domain Name System

  • Internet上主机/路由器的识别问题
    • IP地址
    • 域名:www.hit.edu.cn
  • 问题:域名和IP地址直接如何映射?
  • 域名解析系统DNS
    • 多层命名服务器构成的分布式数据库
    • 应用层协议:完成名字的解析
      • Internet核心功能,用应用层协议实现
      • 网络边界复杂
  • DNS服务
    • 域名向IP地址的翻译
    • 主机别名
    • 邮件服务器别名
    • 负载均衡:Web服务器
  • 问题:为什么不适应集中式的DNS?
    • 单点失败问题
    • 流量问题
    • 距离问题
    • 维护性问题

分布式层次式数据库

  • 客户端想要查询www.amazon.com的IP
    • 客户端查询根服务器,找到com域名解析服务器
    • 客户端查询com域名解析服务器,找到amazon.com域名解析服务器
    • 客户端查询amazon.com域名解析服务器,获得www.amazon.com的IP地址

DNS根域名服务器

  • 本地域名解析服务器无法解析域名时,访问根域名服务器
  • 根域名服务器
    • 如果不知道映射,访问权威域名服务器
    • 获得映射
    • 向本地域名服务器返回映射
  • 全球有13个根域名服务器

TLD和权威域名解析服务器

  • 顶级域名服务器(TLD,top-level domain):负责com,org,net,edu等顶级域名和国家顶级域名,例如cn,uk,fr等
    • Network Solutions维护com顶级域名服务器
    • Educause维护edu顶级域名服务器
  • 权威(Authoritative)域名服务器:组织的域名解析服务器,提供组织内部服务器的解析服务
    • 组织负责维护
    • 服务提供商负责维护

本地域名解析服务器

  • 不严格属于层级体系
  • 每个ISP有一个本地域名服务器
    • 默认域名解析服务器
  • 当主机进行DNS查询时,查询被发送到本地域名服务器
    • 作为代理(proxy),将查询转发给(层级式)域名解析服务器系统

DNS查询示例

  • Cis.poly.edu的主机想获得gaia.cs.umass.edu的IP地址

  • 迭代查询

    • 被查询服务器返回域名解析服务器的名字
    • “我不认识这个域名,但是你可以问题这服务器”
  • 递归查询

    • 将域名解析的任务交给所联系的服务器
例题

如果本地域名服务器无缓存,当采用递归方法解析另一网络某主机域名时,用户主机、本地域名服务器发送的域名请求消息数分别为

  • A.一条、一条
  • B.一条、多条
  • C.多条、一条
  • D.多条、多条

【解析】域名递归解析过程中,主机向本地域名服务器发送DNS查询,被查询的域名服务器代理后续的查询,然后返回结果。所以,递归查询时,如果本地域名服务器无缓存,则主机和本地域名服务器都仅需要发送一次查询,故正确答案为 A

DNS记录缓存和更新

  • 只要域名解析服务器获得域名——IP映射,即缓存这一映射
    • 一段时间过后,缓存条目失效(删除)
    • 本地域名服务器一般会缓存顶级域名服务器的映射
      • 因此根域名服务器不经常被访问
  • 记录的更新/通知机制
    • RFC 2136
    • Dynamic Updates in the Domain Name System (DNS UPDATE)

DNS记录和消息格式

DNS记录

  • 资源记录(RR,resource records)
  • Type=A
    • Name:主机域名
    • Value:IP地址
  • Type=NS
    • Nama:域(edu.cn)
    • Value:该域权威域名解析服务器的主机域名
  • Type=CHAME
    • Name:某一真实域名的别名
      • www.ibm.com - servereast.backup2.ibm.com
    • Value:真实域名
  • Type=MX
    • value是与name相对应的邮件服务器

DNS协议与消息

  • DNS协议:
    • 查询(query)和回复(reply)消息
    • 消息格式相同
  • 消息头部
    • Identification:16位查询编号,回复使用相同的编号
    • flags
      • 查询或回复
      • 期望递归
      • 递归可用
      • 权威回答

如何注册域名?

  • 例子:你刚刚创建了一个公司“Network Utopia”
  • 在域名管理结构(如Network Solutions)注册域名networkutopia.com
    • 向域名管理机构提供你的权威域名解析服务器的名字和IP地址
    • 域名管理机构向com顶级域名解析服务器中插入两条记录
  • 在权威域名服务器中为www.networkutopia.com加入Type A记录,为networkutopia.com加入Type MX记录

本文标签: 计算机网络