计算机网络之应用层
程序员文章站
2024-02-22 21:56:42
...
读计算机网络之自顶向下做的读书笔记，排版有些混乱。。。
如果有同学发现错误希望指正
应用层
应用层协议原理
1.1网络应用的体系结构
客户-服务器体系结构
一个总是打开主机叫做服务器，服务于许多称作客户相应的主机
服务器具有固定的地址（IP地址）
P2P体系结构
实现端到端的直接通信
自拓展性
1.2进程通信
一个进程可以看作一个程序
两个不同端系统上的进程通过计算机网络交换报文
1.2.1客户与服务器进程
一个进程识别为客户（client），一个识别为服务器(server）
在p2p体系中，下载的识别为客户，上载的识别为服务器（或者说发起通信的识别为客户，等待联系的识别为服务器）
1.2.2进程与计算机网络之间的接口
进程之间通过套接字（后续详解）进行通信
！套接字：应用程序编程接口（API）
1.2.3进程寻址
接受进程需要定义两种信息：
1.主机的地址（IP地址）
2.目的主机接受进程的标识符（端口号）
流行的应用会分配固定的端口号（可在<http://www.iana.org>找到）
可供应用程序选择的运输服务
- 分类
- 可靠数据传输
- 吞吐量：发送进程相接受进程交付比特的速率
- 时延
- 安全性
- 因特网（一般TCP/IP）提供的运输服务
- 1.TCP服务
* 面向连接服务
* 可靠数据传输服务
* 拥塞控制
* 流量控制
* 。。。
- 2.UDP服务
* 无连接
* 无可靠数据
* 无拥塞控制
* 。。。
1.3应用层协议
- 内容
- 类型
- 语法/格式
- 语意
- 规则
Web与HTTP
2.1 HTTP概况
HTTP:超文本传输协议
无状态协议：不维护客户端过去发送的任何信息
web网页由一个或多个对象组成
对象可以是HTML文件，图片，Java小程序。。。
2.2 HTTP连接
1.非持续连接
例：访问www.baidu.com
- 过程
1.客户进程向百度的HTTP服务器进程(端口号80)发起TCP连接请求
2.HTTP服务器在端口号80等待请求，接受连接后响应客户端
3.客户端将请求消息(包含url)通过套接字(端口号80)向服务器发送请求
4.服务器接受消息并解析出结果通过套接字返回给客户端并关闭TCP连接
RTT(Round Trip Time):从客户端发送一个很小的数据包返回的时间
响应时间=RTT(发起，建立TCP连接)+RTT(发送请求消息到接受到请求消息)+服务器响应的时间
2.持久性连接
在维持连接的情况下后续的请求和相应通过该TCP连接发送
3.非持久性连接的问题
1.对每一个对象都要重新建立TCP连接
2.操作系统要对每个TCP连接开销资源
游览器器会并行的多个TCP连接
## 2.3 HTTP的报文格式
---------------------
GET /admin_ui/rdx/core/images/close.png HTTP/1.1
Host: xxx.xxx.xxx.xxx
Connection: close
User-agent:xxx
Accept-language: fr
HTTP/1.1 200 OK
Connection: close
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
Last-Modified: date
Content-type: text/html
data data data data data data data data
---------------------
第一行叫做请求行, 包含了请求方式GET(类似的还有POST, PUT, DELETE),请求的URL,以及版本号
接下来的是首部行
HOST: 发起请求的主机
Connetion:告诉服务器不要使用持续连接
User-agent:游览器类型
Accept-language:语言种类
共有三个部分：一行状态行，六行首部行， 其余的都为实体体
状态行：版本， 状态码， 状态
- 常见的状态码
* 200 OK :请求成功
* 301 Moved Permanently:请求的对象被永久转移了，新的URL在响应报文的Location: 首部行中。客户端将自动获取新的URL
* 400 Bad Request: 一个通用的差错代码, 该请求不能被服务器理解
* 404 Not Found: 请求的文档不在服务器上
* 505 HTTP Version Not Supported: 服务器不支持该版本的HTTP协议
- 首部行：
* Connection:close 完成响应后关闭连接
* Server:Apache Tomcat/5..12 告知服务器类型
* Date 发送该响应报文的时间
* Last-Modified 对象创建或最后一次修改的时间
* Content-Length 发送对象的字节数
* Content-type 发送对象的类型
2.4 cookie
cookie:由于HTTP是无状态的,用于后续对用户的身份进行特定的响应
* Cookie的组成
1. HTTP响应报文的一个cookie首部行
2. HTTP请求报文的一个cookie首部行
3. 在客户端的主机上保存的cookie, 游览器进行管理
4. 在服务器上数据库储存的cookie
cookie的使用:
1. 服务器在响应报文加上首部行 (eg: Set-cookie:6666)的同时在数据库中储存一个ID 6666
2. 客户端在响应报文中加上首部行(eg: cookie:6666)
3. 在后续的操作中服务器可以根据cookie的ID对用户进行特定的响应
cookie的不足:
1.客户端浏览器可以禁用cookie,导致服务器通过cookie跟踪客户端不可靠
2.cookie中储存的信息有限, 4k左右
3.cookie不安全
2.5 Web缓存/代理服务器技术
作用：
1. 减少客户请求的响应时间
2. 减少机构或者组织的流量
3. 实现在大范围内(Internet)的内容分发
eg：
1. 客户端浏览器先与代理服务器建立TCP连接
2. 代理服务器检测是否存储了客户端所需对象的副本
3. 如果有就返回该副本, 没有就由代理服务器向该对象的初始服务器建立TCP连接
4. 代理服务器接受到该对象后, 先存储到本地后再将该副本通过一开始建立的TCP连接返回给客户端
缓存又当客户端,又当服务器
代理服务器一般由ISP(Internet服务商)架设
为什么大大减少响应时间:
由于代理服务器(位于局域网中)响应的时间少于初始服务器的响应时间
问题:代理服务器上的副本并不是最新的
解决:条件性GET请求:
代理服务器在HTTP请求报文中加入首部行: If-Modified-since:date
告诉服务器请求的对象只有在date时间后被修改才发送更新的对象
如果没有就发送状态码304 Not Modified
Email应用
电子邮件是一种异步的通信媒介
电子邮件系统的主要组成:
1. 用户代理
2. 邮件服务器
3. 简单邮件传输协议(SMTP)
发送邮件过程:
当张三想要发送一份邮件给李四,张三在编写完邮件后,张三的用户代理向他的邮箱服务器发送邮件,此时邮件在张三的邮件服务器外出报文队列中。再由张三的邮箱服务器发送给李四的用户服务器,李四想要查看张三发的邮件,则李四的邮箱服务器就会鉴别李四的身份(用户名和密码),此时李四就可以查看张三给他发的邮件
当张三的邮件不能发送给李四时,张三的邮箱服务器会在报文列表中保持该邮件并以30分钟的频次尝试发送,若几天不能成功,则以电子邮件的方式通知张三
2.6.1 SMTP
SMTP是因特网电子邮件的主要的应用层协议,使用TCP可靠数据传输
邮件报文的体部分(不仅仅只有首部)只能采用7比特ASCII表示。
SMTP不使用中间服务器进行邮件的转发
端口号：25
与HTTP的对比:
1. HTTP是一个拉取协议(pull), SMTP是一个推送协议。
2. HTTP将每个对象封装的每一个报文里面,邮箱将所有对象封装到一个报文里面
3. HTTP没有7比特的限制
2.6.2 邮箱报文格式
头部行:
1.To:
2.From:
3.Subject:
消息体:
消息本身(ASCII)
多媒体邮件拓展(MIME):
在头部增加额外的行声明MIME的内容类型
2.6.3 邮件访问协议
由于SMTP协议是push协议,当用户想要向邮件服务器申请查看邮件时,需要使用pull式协议。
1. POP3协议
主要分为三个阶段
第一阶段:特许。用户代理通过向服务器发送用户名(明文)以及口令让服务器鉴别用户
第二阶段:事务处理。用户代理可以取回报文并且做出删除标记或取消删除标记.
第三阶段:更新。用户代理发送quit后，断开POP3对话,此时服务器根据删除标记删除对应的邮件
在事务处理阶段,服务器会根据用户代理发出的命令做出应答,例如+OK代表之前的命令是正确的,-ERR代表前面的命令出现了差错。
2.IMAP协议
由于POP3协议不能够让用户创建远程邮箱文件夹,IMAP协议可以解决该问题
IMAP服务器会将每一个邮件与文件夹联系起来，与POP3不同的是，IMAP服务器会维护IMAP会话用户状态信息。
IMAP还支持用户代理只获取邮件中的某些部分的命令
DNS(域名系统)
主机使用IP地址,或者域名(eg:www.facebook.com)进行标识
IP地址由四个字节所组成
2.7.1 DNS所提供的服务
1.解决域名到IP地址的映射：
域名解析系统(DNS)
* 多层DNS服务器组成分布式数据库
* 应用层协议
2. 主机别名(使得别名规范主机名更好记忆)
3. 邮件服务器别名(同上)
3. 负载分配
2.7.2 DNS工作机制
不采用集中式设计的原因:
1. 单点故障
2. 流量问题
3. 距离问题
4. 维护问题
采用分布式，层次数据库
大致来说有三种域名服务器:
根域名服务器，*域名服务器， 权威域名服务器。
还有一种本地域名服务器：
当主机进行DNS查询时，先将查询发到本地域名服务器上，再由本地域名服务器作为代理发送给域名解析服务器系统
eg:当主机cse.nyu.deu想要知道主机gaia.cs.umass.edu的域名
查询方式:迭代查询
*被查询的服务器返回之后将要查询服务器的地址("我不知道该服务器的地址，你可以问它")
查询方式:递归查询
*将域名解析的任务交给查询的服务器
DNS缓存:
当域名解析服务器获得 域名--IP 的这一映射时，将会缓存这一映射
* 一般的域名服务器会缓存*域名服务器(所以根域名服务器一般不会被访问)
* 缓存条目一段时间过后将会被清除
2.7.3 DNS记录和报文
共同实现分布式数据库的DNS服务器均储存了资源记录(RR)
每个报文中都包含了一条或多条资源记录
RR:提供了主机到IP地址的映射
资源记录里包含四个元组(Name, Value, Type, TTL)
TTL:记录的生存时间
Name和Value取决于Type:
* 当Type=A, Name代表主机, Value代表IP地址
* 当Type=NS,Name代表一个域(eg:foo.com),Value代表获得该域主机IP地址的权威DNS服务器的主机名
* 当Type=CNAME,Value是起了别名为Name的主机对应的规范主机名
* 当Type=MX, Value是起来别名为Name的邮箱服务器对应的规范主机名
ps:同一个公司的邮箱服务器的别名可以与其它服务器的别名相同.
2.7.3.1 DNS报文
DNS包含两种报文且该两种报文格式相同:查询和回答报文
报文结构:
* 首部区域(12字节):标识查询还是回答报文.....
* 问题区域:正在进行的查询信息
* 回答区域:最初请求名字的资源记录
* 权威区域
* 附加区域
2.7.3.2 在DNS数据库里插入记录
在注册登记机构注册域名
P2P文件分发
学习内容:研究一个单一主机想多个主机(对等方)发大文件的应用，使用BitTorrent协议
1. P2P体系结构的拓展性
在对于单一主机对多个对等方发送文件具有时间上的优越性
2.BitTorrent
文件分发协议:
名词介绍:
洪流(torrent):被接受方的所有集合。
追踪器:每个洪流都具有的一个基础设施节点。
内容:
假设有一个新的对等方A加入洪流，追踪器会向A发送一个洪流中的主机IP地址的子集(作为A的邻居)，子集中的每一个用户都会拥有来自该文件块的子集。A周期性的向邻居询问他们所拥有的块列表.
此时出现了两个问题:
1. A应该向邻居选择哪些块呢?
2. A应该响应哪些向他发起请求的邻居发送块。
解决一:
最稀缺优先:针对A所需的文件块，优先发送最稀缺的块
解决二:
A优先向能够给他发送速率最高的四个邻居发送块。并且每过10秒重新计算速率。这四个对等方被称作**疏通**。并且A还要随机的选择另外的一个对等方B向其发送块，也许由于A向B发送数据，A或许能够成为B的疏通。相应的B也许也可以成为A的疏通。
视频流和内容分发网
在用户向服务器请求视频文件时，可根据自身网络速率选择不同画质的视频。
内容分发网
建立单规模数据中心造成的问题:
1.如果客户远离数据中心，将会通过多个ISP。
2. 浪费网络带宽
3. 单点故障
采用CDN(内容分发网):
管理多个地理位置上的服务器，根据客户位置为其选择最优的服务器。
CDN服务器安置原则:
1.“深入”，利用高度分布式设计，将每个CDN服务器尽量在地理位置靠近端用户。维护和管理服务器较为困难。
2.“邀请做客”，建立多个大型数据中心。较高时延和较低吞吐量作为代价
1.CDN操作
当用户主机检索特定视频时，需要1.选择合适的CDN服务器集群2.将用户请求重定向到该集群的某台服务器上。
2.集群选择策略
1.地理位置最近。
2.根据实时测量。
套接字编程
网络应用程序由客户程序和服务器程序组成
开发网络应用程序有两种:
1.使用公开的协议标准
2.自己定义私有的协议标准
分组地址包括目的主机的IP地址与端口号
每创建一个套接字都会创建一个端口号
....
应用层小结
应用层中学习了客户-服务器模型，主要内容是各种应用层协议。
下一篇： Java学习的捷径