CHARPTER Ⅱ应用层

CHARPTER Ⅱ 应用层

协议体系架构

  • C/S结构
  • P2P结构
  • 混合结构

应用层协议主要控制不同主机上的进程通信.

数据是端到端的,操作系统如何确认该数据应该下发给哪个进程?

应用层协议定义了:

  1. 交换的报文类型
  2. 报文的语法
  3. 字段的语义
  • 可靠传输?
  • 带宽控制?
  • 实时反馈?
  • 安全性?

TCP

  • 面向连接 : 在客户端和服务器进程之间需要建立连接
  • 可靠传输 : 在发送和接受进程之间
  • 流量控制 : 发送数据的速度决不超过接收的速度
  • 拥塞控制 : 当网络超负荷时,束紧发送端口,减缓发送速度
  • 不提供 : 实时性, 最小带宽承诺

UDP

  • 在客户端和服务器进程之间实现“不可靠的”数据传输
  • 不提供 :连接建立, 可靠性保证,流量控制,拥塞控制,实时性, 最小带宽承诺

安全性

TCP/UDP不提供安全保证,使用套接字SSL提供加密.

SSL提供加密,数据的完整性校验,以及端点的身份鉴别.

套接字(Socket)

区分数据发送给哪个进程

每个进程有唯一的标识.

格式为:IP.IP.IP.IP:Port(IPV4下…?)

发送进程将报文(数据)交给套接字

套接字将报文传输到接受进程的套接字

Web

WEB的协议:HTTP和HTML

C/S结构:

IIS,Apache…

IE,…

Web由一系列对象组成;每个对象都有一个URL定位.

传输通过HTTP协议.

HTTP

一种基于TCP的传输协议,HTTP报文在浏览器和服务器之间交换.

传输完毕后就关闭连接,因此是无状态的.

1.0

  1. TCP连接请求启动
  2. 服务器80端口接受连接并返回客户端.
  3. 请求报文进入TCP接口
  4. 收到请求报文,生成响应报文发送
  5. 关闭TCP连接
  6. 收到相应报文,分析引用资源,请求-发送.

时间:TTS*2+文件传输时间

1.1

服务器在发送响应后,不再断开TCP连接,而是保持该 连接,用于后续对象的传送,直至该连接非活跃状态保持了一 个较长的时间后,方断开该连接.

减少了对服务器端连接数的需要,从而减少了对服务器 端套接字资源的占用,提高了服务器的负载能力 .

流水线/非流水线方式

请求报文

See: https://www.cnblogs.com/biyeymyhjob/archive/2012/07/28/2612910.html
在这里插入图片描述

请求方法:GET和POST.

GET:请求指定的URL对象.

POST:提交表单数据,请求web页面,

HEAD:要求服务器仅发送响应报文.

<1.1>PUT:上传的文件放在实体主体字段中,目标路径由URL字段 标明

​ DELETE:删除URL指定的文件

GET:最常见的一种请求方式,当客户端要从服务器中读取文档时,当点击网页上的链接或者通过在浏览器的地址栏输入网址来浏览网页的,使用的都是GET方式。GET方法要求服务器将URL定位的资源放在响应报文的数据部分,回送给客户端。使用GET方法时,请求参数和对应的值附加在URL后面,利用一个问号(“?”)代表URL的结尾与请求参数的开始,传递参数长度受限制。例如,/index.jsp?id=100&op=bind,这样通过GET方式传递的数据直接表示在地址中,所以我们可以把请求结果以链接的形式发送给好友。

可以看到,GET方式的请求一般不包含”请求内容”部分,请求数据以地址的形式表现在请求行.

响应报文

HTTP响应也由三个部分组成,分别是:状态行、消息报头、响应正文。

如下所示,HTTP响应的格式与请求的格式十分类似:

<status-line>

<headers>

<blank line>

[<response-body>]

正如所见,在响应中唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行(status line)通过提供一个状态码来说明所请求的资源情况。

状态行格式如下:

HTTP-Version Status-Code Reason-Phrase CRLF

其中,HTTP-Version表示服务器HTTP协议的版本;Status-Code表示服务器发回的响应状态代码;Reason-Phrase表示状态代码的文本描述。状态代码由三位数字组成,第一个数字定义了响应的类别,且有五种可能取值。

  • 1xx:指示信息–表示请求已接收,继续处理。
  • 2xx:成功–表示请求已被成功接收、理解、接受。
  • 3xx:重定向–要完成请求必须进行更进一步的操作。
  • 4xx:客户端错误–请求有语法错误或请求无法实现。
  • 5xx:服务器端错误–服务器未能实现合法的请求。

Cookie

  • 限制访问
  • 身份认证

Cookie技术的组成部分:

  • 在HTTP响应报文中有一个Cookie首部行
  • 在HTTP请求报文中也有一个Cookie首部行
  • 在用户的端系统中保留了一个Cookie文件,由用户 浏览器负责管理
  • 在Web站点有一个后端数据库

WEB缓存

在局域网内置缓存服务器.

条件GET:更新web缓存中的WEB副本.

如果请求对象不在缓存中,接收并更新缓存.

如果在,发送条件GET检查时效性.如果该对象没有被修改过,WEB缓存上的仍然是最新版本,则WEB服务器发送如下响应报文:

HTTP/1.1 304 Not Modified Date: Mon, 14 Jul 2003 15:39:29 Server: Apache/1.3.0(Unix)
NULL

如果该对象在此之后被修改过,WEB服务器上有最新 版本,则WEB服务器发送新版本的对象给WEB缓存

HTTP/1.1 200 OK Date: Mon, 14 Jul 203 15:39:29 Server: Apache/1.3.0(Unix) Last-Modified: Sat, 12 Jul 2003 09:23:24 Content –Type: image/gif
DATA

FTP

也是用TCP.

FTP的控制信息是带外传送的,而HTTP的控制 信息则是带内传送的.

FTP有两个连接,一个是控制连接一个是数据连接.端口分别是21和20.

FTP会全程维护状态,即使传输完毕也会保持连接.

电子邮件使用的SMTP

使用TCP传输报文

直接传输:发送服务器到接受服务器

7bit ASCII表示报文

传输过程示例

S: 220 hamburger.edu
C: HELO crepes.fr 
S: 250  Hello crepes.fr, pleased to meet you 
C: MAIL FROM: <[email protected]> 
S: 250 [email protected]... Sender ok 
C: RCPT TO: <[email protected]> 
S: 250 [email protected] ... Recipient ok 
C: DATA S: 354 Enter mail, end with "." on a line by itself 
C: Do you like ketchup? 
C: How about pickles? 
C: . 
S: 250 Message accepted for delivery 
C: QUIT
S: 221 hamburger.edu closing connection

报文格式:

首部:

  • TO
  • FROM
  • SUBJECT

body:

  • ASCII的报文

MIME扩展

可以传输附件:图片,文件等

From: [email protected] 
To: [email protected]
Subject: Picture of yummy crepe. 
MIME-Version: 1.0 
Content-Transfer-Encoding: base64 Content-Type: image/jpeg 
base64 encoded data 
..... ......................... ......
base64 encoded data 

用户机获取邮件的POP3协议

  1. 认证:username+password->OK/ERR
  2. list列出报文
  3. retr用报文号取信息
  4. dele删除
  5. quit

“下载-删除”: 用户如果 更换客户机无法再次阅读 原来的邮件

“下载-保存”: 在不同的 客户机上保存邮件的副本

POP3会话是没有状态的 .

用户使用POP3协议无法 在邮件服务器上对自己的 邮件进行重组织,只能将 邮件下载到本地计算机进行重组织

DNS服务:域名和IP的转换

  • DNS是一个分布式数据库,由很多台DNS服务 器按照层次结构组织起来
  • DNS运行在端到端系统上,且使用UDP协议 (53号端口)进行报文传输,因此DNS是应用层协议
  • DNS以C/S的模式工作
  • DNS不直接和用户打交道,而是因特网的核心功能

DNS的多级缓存实现:

在这里插入图片描述

本地DNS服务器

每一个网络服务提供商都会提供一个本地DNS 服务器.有时候,我们将其称为“默认DNS服务器” .当一台主机需要做一个域名查询的时候,查询请求首先被发送到本地域名服务器 .本地域名服务器的行为就像一个代理,它会向域名的层次体系中进行进一步的域名查询。

DNS缓存

TLD DNS服务器通常被缓存在本地DNS服务器中.这样可以减少根 DNS 的负载.

DNS的报文

查询和回答报文的格式是一致的.

在这里插入图片描述

P2P Service

一次传输的场景:

  • Alice在她的笔记本电脑上运行了一个P2P客户端应用
  • 她不定期的连接到因特网上,每次都获得一个不同的IP地址 .
  • 她希望获得这样的资源 “Hey Jude”
  • 这个应用显示出拥有这个资源的所有其他的计算机
  • Alice从中选择了Bob
  • 这个资源从Bob的PC拷贝到了Alice的笔记本电脑上
  • 当Alice在下载资源的时候,其他的用户也在向Alice的 机器上传其他的资源
  • Alice的计算机既是一个客户机,也是一个服务器

BitTorrent的基本概念

  • 洪流(torrent):参与一个特定文件分发的所有对 等方的集合
  • 追踪器(tracker):跟踪正参与在洪流中的对等方
  • 文件块(chunk):256KB
  • BitTorrent的基本工作机制
  • 向邻居请求哪些块——最稀罕优先
  • 优先响应哪些请求——对换算法(4+1)

P2P文件定位的方法

  • 集中式目录——Napster :将IP地址和有的资源信息传送到主服务器上
  • 洪泛查询——Gnutella:无中心,全分布, 一个对等方通常所连接的该覆盖网络中的节点要少于10个
  • 利用不均匀性——KaZaA:仍然是全分布的,但所有的对等方并不都是平等的. 存在部分具有特权的对等方,称之为“组长” .组长通常具有高带宽连接和高因特网连通性 .组长之间以洪泛查询的方式连接成覆盖网络 .每一个普通对等方必须指派到一个组长,从而形成以 组长为中心的小“Napster”.

基本工作机制

  • 向邻居请求哪些块——最稀罕优先
  • 优先响应哪些请求——对换算法(4+1)

P2P文件定位的方法

  • 集中式目录——Napster :将IP地址和有的资源信息传送到主服务器上
  • 洪泛查询——Gnutella:无中心,全分布, 一个对等方通常所连接的该覆盖网络中的节点要少于10个
  • 利用不均匀性——KaZaA:仍然是全分布的,但所有的对等方并不都是平等的. 存在部分具有特权的对等方,称之为“组长” .组长通常具有高带宽连接和高因特网连通性 .组长之间以洪泛查询的方式连接成覆盖网络 .每一个普通对等方必须指派到一个组长,从而形成以 组长为中心的小“Napster”.
发布了80 篇原创文章 · 获赞 13 · 访问量 2万+

猜你喜欢

转载自blog.csdn.net/POTASSIUM711/article/details/103376626
今日推荐