【计算机网络】应用层

最新推荐文章于 2023-12-25 21:32:41 发布

寂寞烟火~

最新推荐文章于 2023-12-25 21:32:41 发布

阅读量400

点赞数 1

分类专栏：计算机网络文章标签：网络协议网络

本文链接：https://blog.csdn.net/kieson_uabc/article/details/106210762

版权

计算机网络专栏收录该内容

9 篇文章 11 订阅

订阅专栏

单元知识框架
2.1 principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
- SMTP, POP3, IMAP
2.5 DNS
2.1-2.5 重点
2.6 P2P applications
2.7 socket programming with UDP and TCP

principles of network applications

Application architectures(网络应用的体系结构)

CS 结构
- 服务器
  - 一直在线提供服务
  - 永久性的 IP 地址/域名
  - 数据中心实现可扩展性
- 客户机
  - 与服务器进行通信
  - 间歇性的接入网络
  - 可能使用动态的 IP 地址
  - 不会与其他客户机直接通信
P2P 结构
- 没有永远在线的服务器
- 任意的端系统/节点之间直接可以通信
- 每一个节点既使用别的节点的服务，也向别的节点提供服务
- 节点间歇性的接入网络和改变 IP 地址
  - 难于管理

Processes communicating(网络应用的进程通信)

进程：主机上运行的程序
- 同一主机上运行的进程之间通过进程间通信机制进行通信
- 不同主机上的进程则通过消息交换或者报文交换进行通信
1.进程间通信利用 socket(套接字)发送/接收消息实现
- 类似于寄信
  - 发送方将消息送到门外邮箱
  - 发送方依赖门外的传输基础设施将消息传到接收方所在的主机，并送到接收方的门外
  - 接收方从门外获取消息
- 传输基础设施向进程提供 API
  - 传输协议的选择
  - 参数的设置
2.寻址进程过程：IP+端口
- 不同主机上的进程要通信，那么每个进程必须拥有标识符(identifier)
- 每个主机设备都有独一无二的 IP 地址
- 如何寻址主机?------IP 地址
  - Q：运行进程的主机的 IP 地址是否足以识别进程？
  - A：否，同一主机上可能同时有多个进程需要通信
- 端口号/Port number
  - 为主机上每个需要通信的进程分配一个端口号
  - HTTP server:80
  - Mail server:25
- 进程的标识符
  - IP 地址+端口号
3.应用层协议的内容
- 消息的类型
  - 请求消息
  - 响应消息
- 协议三要素
  - ① 消息的语法字段
    - 消息中有哪些字段(field)？
    - 每个字段如何描述
  - ② 字段的语义(semantics)
    - 字段中信息的含义
  - ③ 规则
    - 进程何时发送/响应消息
    - 进程如何发送/响应消息
- 协议的分类
  - 公开协议
    - 协议都定义在 RFC 文档里
    - 允许互用
    - 例如：HTTP，SMTP
  - 私有协议
    - 例如：Skype

网络应用的需求与传输层提供的服务

1.应用层对传输层的需求
- 数据的完整性
  - 某些网络应用要求 100%可靠的数据传输：文件传输，telnet 远程登录
  - 某些网络应用能够容忍一定的数据丢失：网络电话，audio 音频
- 时间
  - 有些应用只有在延迟足够低时才“有效”
  - 例如：网络电话，网络游戏
- 吞吐量
  - 某些应用只有在带宽达到其最低要求时才有效：网络视频
  - 某些应用能够适应任何带宽-----弹性(elastic)应用：email
- 安全性
  - 加密,数据的完整性
2.传输层提供的服务
- 1.TCP 服务
  - 在发送与接收进程中可靠的传输
  - 流量(flow)控制
    - 发送方不会发送速度过快，超过接收方的处理能力(overwhelm 压垮，击败)
    - 拥塞问题：往往通过流量控制的手段来解决
  - 拥塞(congestion)控制
    - 当网络负载过重时能够限制(throttle 勒死;节流阀)发送方的发送速度
  - 面向连接
    - 客户机/服务器进程间需要建立连接(setup)
  - 不提供：时间/延迟保障，最小带宽保障，安全性
- 2.UDP 服务
  - 在发送与接收进程中不可靠的传输
  - 不提供：可靠性保障，流量控制，拥塞控制，时间/延迟保障，最小带宽保障，安全性，无连接建立
- Q：为什么两种协议都有?为什么有一个 UDP？
- A；① 不同应用的需求不一样。②UDP用于定位进程，IP用于定位主机。
- 3.安全的 TCP
  - TCP 和 UDP
    - 没有加密(encryption)
    - 明文传送到套接字的明文密码
  - SSL
    - 提供加密的 TCP 连接
    - 数据完整性
    - 端点身份验证(authentication)

Web and HTTP

HTTP 的回顾
- 超文本传输协议
- web 的应用层协议
使用 TCP 传输服务
- 服务器在 80 端口等待客户的请求
- 浏览器发起到服务器的 TCP 连接(创建套接字 Scoket)
- 服务器在 80 端口接收来自浏览器的 TCP 连接
- 浏览器与(HTTP 客户端)与 Web 服务器(HTTP 服务器)交换 HTTP 消息
- 关闭 TCP 连接
HTTP 是无状态的
- 服务器不维护任何有关客户端过去所发请求的信息

Web 应用：HTTP 协议

一.HTTP 连接
- 非持久性连接
  - 每个请求/响应经过一个单独的 TCP 连接发送
  - 一个 TCP 连接至多只能传输一个对象
  - 下载多个对象需要多个连接
- 持久性连接
  - 可以通过客户端、服务器之间的单个 TCP 连接发送多个对象
1.非持久性连接
- HTTP客户端发起到服务器端的TCP连接请求
- 服务器端在80端口等待TCP连接请求，接受连接，并通知客户端
- HTTP客户端将HTTP请求的消息通过TCP连接的套接字发出
- HTTP服务器收到请求消息，产生响应，通过套接字发给客户端
- HTTP服务器关闭TCP连接
- HTTP客户端收到响应
- 继续为其他对象执行以上步骤
非持久性链接的响应时间
- RTT：从客户端发送一个很小的数据包到服务器并返回所经历的时间
- HTTP响应时间
  - 发起，建立TCP连接：1个RTT
  - 发送HTTP请求消息以及HTTP响应消息的前几个字节到达：1个RTT
  - 响应消息中文件/对象传输时间
  - 非持久性连接总的响应时间=2RTT+文件/对象传输时间
2.持久性连接
- 非持久性连接的问题
  - 每个对象需要2RTT
  - 操作系统(OS)需要为每一个TCP连接开销资源(overhead)
  - 浏览器经常打开多个并行的(parallel)TCP连接以获取(fetch)网页引用的(referenced)对象
- 持久性连接
  - 发送响应后，服务器保持TCP连接的打开
  - 后续的(subsequent)HTTP消息可以通过这个打开的连接发送
  - 客户端只要遇到一个引用对象(响应)就会尽快发送新的请求
  - 理想情况下，收到所有的引用对象只需耗时约1个RTT
二.HTTP消息格式：请求消息和响应消息
- 1.请求消息
  - 请求行(request line)：method URL version
  - 头部(header line)：HOST,UA等等
  - 主体(body)：请求实体(get方法的主体为空)
- 请求方法类型
  - GET：body为空，输入信息通过request行的URL字段上传
  - POST : 表单提交（表单提交也可以get）等、在请求消息的消息体（entity Body ）中上传客户端的输入
  - HEAD: 当服务器收到HEAD方法的请求时，将会用一个HTTP报文响应，但是并不返回请求对象，常用来调式跟踪
  - PUT: 将消息体重的文件上传到URL字段指定的路径中
  - DELETE: 删除URL字段指定的文件
- version
  - HTTP/1.0:GET,POST,HEAD
  - HTTP/1.1:GET,POST,HEAD,PUT,DELETE
- 2.响应消息
  - 状态行：协议的版本字段状态码相应的状态信息
  - 首部行：Date,server等等
  - 数据：html file等等
- 状态码
  - 200：响应成功
  - 301：页面永久转移
  - 302：页面的跳转(页面临时转移)
  - 304：表示使用缓存
  - 400：错误请求
  - 404：未找到
  - 505： HTTP版本不受支持
三.用户与服务器交互：cookie
- HTTP服务器是无状态的，许多Web站点使用cookie
- cookie的four components(组件)
  - 响应消息的头部
  - 请求消息的头部
  - 保存在客户端主机上的cookie文件，由浏览器管理
  - web服务器端(web site)的后台数据库(back- end database)
- cookie可用于
  - 授权
  - 购物车
  - 建议
  - 用户会话状态(web电子邮件)
- 如何保持状态
  - 协议端点：在多个事务上保持发送方/接收方的状态
  - cookies:http消息携带状态
四.Web缓存技术
- Web缓存器也叫代理服务器
  - 对于前端人员来说浏览器就是最常见的Web缓存器
- 功能：在不访问服务器的前提下满足客户端的HTTP请求
- Web缓存器
  - 用户设定浏览器：通过缓存器进行Web访问
  - 浏览器向缓存/代理服务器发送所有的HTTP请求
    - 如果请求对象在缓存器里，缓存器就返回对象
    - 否则，缓存器就向原始服务器发送HTTP请求，获取对象，然后返回给客户端并保存该对象
  - 缓存器既充当客户端，又充当服务器
  - 缓存器一般由ISP架设
- 为什么要用Web缓存
  - 缩短客户请求的响应时间
  - 减少机构组织的流量
  - 从整体上大大降低了因特网上的Web流量，在大范围内(Internet)实现有效的内容分发（CDN）
  - 使用条件GET方法来检查和更新在Web缓存器中的副本是否是最新的以及是否被修改过
五.HTTP协议采用条件性GET方法
- 目标：如果缓存器有最新的版本，则不需要发送请求对象
  - 无对象传输延迟
  - 低链路利用率(utilization)
- 缓存器：在http请求消息中声明所持有版本的日期
  - If-modified-since: <date>
- 服务器：如果缓存的版本是最新的，则响应消息中不包含对象
  - HTTP/1.0 304 Not Modified

FTP文件传输协议

FTP：独立的控制连接和数据连接
- FTP客户端使用TCP协议在端口21与FTP服务器联系
- 客户端授权(authorized)控制连接
- 客户端浏览远程目录，通过控制连接发送命令
- 当服务器收到文件传输命令时，服务器打开到客户端的第二个TCP数据连接，20端口（用于文件）
- 传输一个文件后，服务器关闭数据连接
- 服务器打开另一个TCP数据连接去传送另一个文件
- 注意注意：控制连接贯穿整个会话期间，但是会话的每一次文件传输都需要建立新的数据连接(即数据连接是非连续的)
- FTP：控制连接称为带外连接;HTTP：控制连接称为带内连接
- FTP服务器必须在整个会话期间保留用户的状态; HTTP是无状态的
FTP命令与回答
- 命令和回答都是以7bit的ASCII格式在控制连接上传送的

electronic mail(电子邮件)：SMTP, POP3, IMAP

电子邮件三个主要组成部分
- 用户代理UA
- 邮件服务器MS
- 简单邮件传输协议SMTP
1.UA
- 用户代理：允许阅读，回复，转发，保存，撰写邮件
- 例如：Outlook、Thunderbird、iPhone邮件客户端
2.MS
- 邮箱包含用户的传入邮件
- 待发邮件的消息队列
- 邮件服务器之间的以SMTP协议发送电子邮件
  - 客户端：发送邮件的服务器
  - 服务器：接收邮件的服务器
3.SMTP
- 使用TCP协议将电子邮件消息从客户端可靠地传输到服务器的端口25
- 直接传输：发送服务器到接收服务器
- 传输的三个阶段
  - 握手（问候）
  - 消息传输
  - 关闭
- 命令/响应交互（像HTTP，FTP）
  - 命令：ASCII文本
  - 回复：状态码和短语
- 消息必须以7位ASCII传输
SMTP与HTTP对比
- SMTP
  - SMTP使用持续连接
  - SMTP要求邮件（头和正文）使用7位ASCII
  - SMTP服务器使用CRLF.CRLF(回车换行)确定邮件结尾
- 与HTTP的比较：
  - HTTP:拉取
    - TCP是由想接收文件的机器发起的
  - SMTP:推送
    - TCP是由发送该文件的机器发起的
  - SMTP要求消息必须以7位ASCII传输;HTTP没有该要求
  - HTTP：每个对象(图片，文本单独放)封装在自己的HTTP响应报文中;SMTP：所有的对象放在一个报文中
4.邮件访问协议

DNS

域名解析前的准备
浏览器请求URL的真实情况
DNS服务器的交互
- 从请求主机到本地DNS服务器的查询：是递归查询
- 其他的查询都是迭代查询
DNS缓存
- 如果本地DNS服务器缓存一个主机名/IP地地址对，当相同主机名访问本地DNS缓存时，可直接返回IP
- 本地DNS服务器也能够缓存TLD服务器的IP地址，因而允许本地DNS直接绕过查询链中的根DNS服务器
域名解析时使用UDP协议
- 客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。
DNS区域传输的时候使用TCP协议
- 辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多