计算机网络系列笔记(二) - 网络应用层

概述

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

网络应用的基本原理

网络应用的体系结构有三种
客户机/服务器结构(Client-Server, C/S)
服务器特点: 7 × 24小时提供服务, 永久性访问地址, 利用大量服务器实现可扩展性
客户机特点: 与服务器通信使用服务器提供的服务, 间歇性接入网络, 可能使用动态IP地址, 不会与其他客户机直接通信
点对点结构(Peer-to-Peer, P2P): 没有永远在线的服务器, 任意节点之间可直接通讯, 节点间歇性接入网络, 节点可能改变IP地址, 优点是高度可伸缩, 缺点是难于管理
混合结构(Hybrid): 例如Napster, 文件传输使用P2P结构, 文件搜索采用C/S结构

进程间通信

不同主机上的进程间通信需要消息交换, 发起通信的进程叫客户机进程, 等待通信请求的进程叫服务器进程
套接字(Socket): 进程间通信利用socket发送/接收消息实现, 传输基础设施向进程提供API
进程的标识符: IP地址+端口号
应用层协议: 网络应用需遵守应用层协议, 分为公开协议, 由RFC(Request For Comments)定义和私有协议
应用层协议内容

  • 消息的类型 (请求消息, 相应消息)
  • 消息的语法格式 (包含哪些字段)
  • 字段的语义 (字段中信息的含义)
  • 规则 (进程何时发送/相应消息, 进程如何发送/相应消息)

网络应用的需求

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

  • 可靠性 (网络电话能容忍一定数据丢失, 文件传输不行)
  • 延迟 (网络游戏要求低延迟)
  • 带宽 (网络视频对带宽有最低要求, email则没有)

Internet提供的传输服务对比
TCP服务

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

UDP服务

  • 无连接
  • 不可靠数据传输
  • 不提供可靠性保障, 流量控制, 拥塞控制, 延迟保障, 带宽保障

WEB应用

网页对象的寻址: URL(Uniform Resoure Locator)统一资源定位器

http协议概述
万维网遵循的协议, 超文本传输协议(HyperTexi Transfer Protocol), 使用TCP传输服务, 无状态, 服务器不维护任何有关客户端过去所发请求的信息
http有两种连接方式, 非持久性连接, 每个TCP连接最多允许传输一个对象; 持久性连接, 每个TCP连接允许传输多个对象
响应时间
RTT(Round Trip Time), 从客户端发送一个很小的数据包到服务器并返回所经历的时间
发起, 建立TCP连接, 需要1个RTT, 发送http请求消息到http响应消息的前几个字节到达, 需要1个RTT, 再加响应中所含文件的传输时间
响应时间总共 = 2RTT + 文件发送时间
cookie技术
http协议无状态, 为了辨别用户身份, 进行session跟踪而储存在用户本地终端上的数据, 通常经过加密
cookie的组件

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

可用于, 身份认证, 购物车, 推荐等
web缓存/代理服务器技术
在不访问服务器的前提下满足客户端的http请求
目的是: 缩短客户请求的相应时间, 减少机构/组织的流量, 在大范围内实现有效的内容分发
缓存既充当客户端也充当服务器

Email应用

构成组件: 邮件客户端, 邮件服务器, SMTP协议
使用TCP进行email消息的可靠传输, 命令/响应交互模式, 使用持久性连接
邮件访问协议, POP(Post Office Protocol), IMAP(Internet Mail Access Protocol), HTTP
POP3是无状态的, IMAP支持跨会话的用户状态

DNS(Domain Name System)

域名解析系统DNS: 多层命名服务器构成的分布式数据库, 应用层协议, 完成名字的解析
DNS服务作用: 域名向IP地址的翻译, 主机别名, 邮件服务器别名, 负载均衡
解析流程: 本地域名解析服务器 -> 根域名服务器 ->权威域名服务器 -> 本地域名服务器

  • 顶级域名服务器(TLD, top-level domain): 负责com,org,net,edu等顶级域名和国家顶级域名,如cn
  • 权威域名服务器: 组织的域名解析服务器, 提供组织内部服务器的解析服务
  • 本地域名解析服务器: 不严格属于层级体系, 每个ISP有一个本地域名服务器, 默认的, 当主机进行DNS查询时, 查询被发送到本地域名服务器, 作为代理将查询层级式转发给域名解析服务器系统

全球有13个根域名服务器

两种查询方式, 迭代查询, 递归查询
DNS记录和消息格式
DNS记录是一个四元组, 资源记录(RR, resource records), RR format: (name, value, type, ttl)

type=A name是主机域名, value是ip地址
type=NS name是域, value是该域权威域名解析服务器的主机域名
type=CNAME name是某一真实域名的别名, value是真实域名
type=MX value是name对应的邮件服务器

依赖DNS协议

P2P

P2P架构: 没有服务器, 任意端系统之间直接通信, 节点阶段性接入互联网, 节点可能更换ip地址
文件分发比C/S模式效率高
文件分发
采用BitTorrent协议, torrent负责交换同一个文件的文件块的节点组, tracker跟踪参与torrent的节点
文件被划分为256KB的chunk, 节点加入torrent, 向tracker注册以获得节点清单, 与某些节点建立连接, 下载的同时, 节点需要向其他节点上传chunk
获取chunk流程, 给定任一时刻, 不同节点持有文件的不同chunk集合, 当前节点定期查询每个邻居所拥有的chunk列表, 节点发送请求, 请求获取缺失的chunk, 稀缺优先
发送chunk流程, tit-for-tat, 谁给我我给谁, 向正在给自己发送chunk且速率最快的四个邻居发送chunk, 每10s重新评估top4, 每30s随机选择一个其他节点
P2P索引方式

  • 集中式索引, 存在单点失效问题, 性能瓶颈, 版权问题
  • 洪泛式查询, 完全分布式架构, 每个节点只对它共享的文件进行索引, 查询消息通过已有TCP连接发送, 节点继续转发查询, 查询像洪水泛滥
  • 层次式覆盖网络, 集中式和洪泛式的结合, 节点和超级节点维持TCP连接, 超级节点之间维持TCP连接, 超级节点负责跟踪子节点内容, 查询到后节点直接直接通信, 不经过超级节点

很常用的设计思路

打赏
  • 版权声明: 本博客所有文章除特别声明外,均采用 Apache License 2.0 许可协议。转载请注明出处!
  • © 2017-2023 王丹鹏
  • Powered by Hexo Theme Ayer
  • 冀ICP备15029707号

请我喝杯咖啡吧~

支付宝
微信