【计算机网络-自顶向下】2—Application layer应用层(Web、邮件、DNS、P2P、视频流、套接字)

2 Application layer应用层

⭐⭐⭐⭐⭐⭐
Github主页👉https://github.com/A-BigTree
项目链接👉https://github.com/A-BigTree/college_assignment
⭐⭐⭐⭐⭐⭐

2.1 应用层协议原理

Principles of network applications

2.1.1 网络应用程序体系结构

Network application structure

**应用程序体系结构(application architecture)**由应用程序研发者设计,规定了如何在各种端系统上组织该应用程序。现代网络应用程序中所使用的两种主流体系结构:

客户-服务器体系结构

Client-server architecture

  1. Server

    • 总是在线(always on host);
    • 永久的IP地址(permanent IP address);
    • 配置在数据中心(often in data centers);
  2. Client

    • 与服务器沟通联系;
    • 被间歇性(intermittently)的连接;
    • 拥有动态地址;
    • 客户之间不直接联系;

在这里插入图片描述

P2P体系结构

Peer-peer architecture

  • 没有一直在线的服务器;
  • 端与端之间直接进行连接;
  • 自拓展性(self-scalability),每个对等方通过向其他对等方分发文件为系统提供服务能力;
  • 对等方可间歇性的被连接并且可以改变IP地址;

在这里插入图片描述

2.1.2 进程通信

Process communicating

用操作系统的术语来说,进行通信的实际上是**进程(process)而不是程序;在两个不同端系统上的进程,通过跨越计算机网络交换报文(message)**而相互通信。

客户和服务器进程
  • 客户进程:发起通信的进程;
  • 服务进程:在会话开始时等待联系的进程;
进程与计算机网络之间的接口

Socket

进程通过一个称为套接字(Sockets)的软件接口向网络发送报文和从网络接受报文。由于该套接字是建立网络应用的可编程接口,因此套接字被称为应用程序和网络之间的应用程序编程接口(Application Programming Interface,API)

在这里插入图片描述

进程寻址

Addressing processes

  • 主机地址👉 IP地址(IP address) 标识;
  • 目的主机指定接受进程的标识符👉目的地端口号(port number)

在这里插入图片描述

2.1.3 可供应用程序使用的运输服务

Transport service used in application

  1. 可靠数据传输(reliable data transfer)
    • 一些应用需要100%可靠数据传输;
    • 一些应用允许丢包(loss);
  2. 吞吐量(Throughout)
    • 具有吞吐量要求是应用程序被称为带宽敏感的应用(bandwidth-sensitive application)
    • 弹性应用(elastic application) 能够根据当时可用的带宽或多或少地利用可供使用的吞吐量;
  3. 定时(Timing)
    • 低延时(low delay) 要求;
  4. 安全(Security)
    • 加密技术(encryption)、数据完整性(data integrity);

2.1.4 因特网提供的运输服务

Transport protocols services

TCP服务
  • 面向连接的服务(connection-oriented):报文开始流动之前,TCP让客户和服务器互相交换运输层控制信息(握手阶段),握手阶段后,一条TCP连接(TCP connection)就在两条进程的套接字之间建立;
  • 可靠的数据传送服务(reliable transport):无差别、按适当顺序交付所有发送的数据;
  • 拥塞控制机制(congestion control);

TCP安全

安全套接字层(Secure Sockets Layer,SSL) 提供了关键的进程到进程的安全性服务。

在这里插入图片描述

我们平时上网冲浪时,网址前面的httphttps的关系其实就是http + SSL = https🫡

UDP服务
  • 提供一种不可靠数据传送服务(unreliable data transfer);
  • 当进程将报文发送至UDP套接字时,UDP并不能保证该报文将到达接收进程;

2.1.5 应用层协议

Application-layer protocol

应用层协议(Application-layer protocol) 定义了运行在不同端系统上的应用程序进程如何相互传递报文。

2.1.6 网络应用

  • Web
  • 电子邮件
  • 目录服务
  • 流式视频
  • P2P
  • 。。。

2.2 Web和HTTP

Web and http

2.2.1 HTTP概况

HTTP overview

Web的应用层协议超文本传输协议(HyperText Transfer Protocol,HTTP),它是Web的核心。。

  • Web页面(Web page)(也叫文档)是由对象组成。一个对象(object)只是一个文件,诸如一个HTML文件、一个JPEG图片、一个Java小程序等等;
  • 多数Web页面包含HTML基本文件(base HTML) 以及几个引用对象;
  • Web浏览器(Web browser) 实现了HTTP的客户端;Web服务器(Web server) 实现了HTTP的服务器端;
  • HTTP使用TCP作为它的支撑运输协议;
  • 因为HTTP服务器并不保存关于客户的任何信息,所以我们会说HTTP是一个无状态协议(stateless protocol);

2.2.2 非持续连接和持续连接

Non-persistent HTTP and Persistent HTTP

非持续连接
  1. TCP连接开启;
  2. 最多一个对象通过该TCP连接发送;
  3. 该TCP连接关闭;
持续连接
  1. TCP连接开启;
  2. 多个对象通过该TCP连接发送;
  3. 该TCP连接关闭;

在这里插入图片描述

  • 往返时间(Round-Trip Time,RTT) 定义:该时间是指一个短分组从客户到服务器然后在返回客户所需要的时间;

在这里插入图片描述

2.2.3 HTTP报文格式

HTTP message format

HTTP请求报文
GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n
  • 请求报文的第一行叫做请求行(request line),其后继的行叫作首部行(header line)
  • 请求行有3个字段:方法字段、URL字段和HTTP版本字段;
    • 方法可取GET,POST,HEAD,PUT,DELETE
  • 首部行HOST:指明了对象所在的主机;首部行User-Agent:指明了用户代理,即浏览器类型;。。。

HTTP请求报文通用格式:

在这里插入图片描述

HTTP响应报文
HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\r\n
\r\n
(data data data data data ... )
  • 上例响应报文包括一个初始状态行(status line),9个首部行(header line),然后是实体体(entity boby)
  • 状态行有3个字段:协议版本字段、状态码和状态信息;
    • 200 OK:请求成功;
    • 301 Moved Permanently:请求对象以及被永久转移;
    • 400 Bad Request:一个通用差错代码,该请求不能被服务器理解;
    • 404 Not Found:被请求的文档不在服务器上;
    • 505 HTTP Version Not Support:服务器不支持请求报文使用的HTTP协议版本;

2.2.4 用户与服务器的交互:cookie🍪

Maintaining user/server state: cookies🍪

前面提到HTTP服务器为无状态的,而一个Web站点通常希望能够识别用户,可能是因为服务器希望限制用户的访问,或者因为它希望把内容与用户身份联系起来。为此,HTTP使用了cookie🍪。

cookie技术有4个组件:

  • HTTP响应报文的cookie首部行;
  • HTTP请求报文的cookie首部行;
  • 用户端系统中保留一个cookie文行;
  • 位于Web站点的一个后端数据库;

在这里插入图片描述

2.2.5 Web缓存

Web cache(proxy server)

Web缓存器(Web cache)也叫代理服务器(proxy server),它是能够代表初始Web服务器(origin server) 来满足HTTP网络请求的实体。
在这里插入图片描述

请求过程:

  1. 浏览器创建一个到Web缓存器的TCP连接,并向Web缓存器中的对象发送一个HTTP请求;
  2. Web缓存器进行检查,看看本地是否存储该对象副本。如果有,Web缓存器向客户返回该对象;
  3. 如果缓存器中没有该对象,它就打开一个与该对象的初始服务器的TCP连接。Web缓存器向初始服务器发送请求,并得到初始服务器的响应;
  4. 当Web缓存器接受对象后,在本地创建给对象的副本,并向客户发送响应报文返回该对象;

通过使用内容分发网络(Content Distribution Network,CDN),Web缓存器正在因特网中发挥着越来越重要的作用。

2.2.6 条件GET方法

Conditional GET

尽管高速缓存器能减少用户感受到的响应时间,但引入了一个新的问题,即存放在缓存器中的副本可能陈旧的。

条件GET方法:

  1. 请求报文使用GET方法;
  2. 请求报文中包含一个If-Modified-Since:首部行;

响应报文中状态行为304 Not Modified表示缓存器可以使用该对象的副本。

2.3 因特网种的电子邮件

E-mail

电子邮件三个主要组成部分:

  • 用户代理(User agent);
  • 邮件服务器(mail server);
  • 简单邮件传输协议(Simple Mail Transfer Protocol,SMTP);

在这里插入图片描述

用户代理

  • 撰写、编辑、阅读邮件;
  • 服务器上存储的传入和传出的消息;

邮件服务器

  • 邮箱(mailbox)包括用户传入的消息;
  • 报文队列(message queue)中为待发送的邮件报文;

SMTP协议

  • 在邮箱服务器之间传输邮件报文;

2.3.1 SMTP

假设Alice想给Bob发送一封简单的ASCII报文:

  1. Alice调用她的邮件代理程序并提供Bob的邮件地址,撰写报文,然后指示用户代理发送该报文;
  2. Alice的用户代理把报文发给她的邮件服务器,在那里该报文被放在报文队列中;
  3. 运行在Alice的邮件服务器上的SMTP客户端发现了该报文队列中的这个报文,它就创建一个到运行在Bob的邮件服务器上的SMTP服务器的TCP连接
  4. 经过一些初始SMTP握手后,SMTP客户通过该TCP连接发送Alice的报文;
  5. 在Bob的邮件服务器上,SMTP的服务器端接受该报文。Bob的邮件服务器然后将该报文放入Bob的邮箱中;
  6. 在Bob方便的时候,他调用用户代理阅读该报文;

在这里插入图片描述

  • 如果Bob的邮件服务器没有开机,该报文会保留在Alice的邮件服务器上并等待进行新的尝试,这意味着邮件并不在中间的某个邮件服务器存留

2.3.2 与HTTP对比

  1. HTTP主要是一个拉协议(pull protocol),TCP连接是由想接受文件的机器发起的;SMTP是一个推协议(push protocol),TCP连接是由发送文件的机器发起;
  2. SMTP要求报文采用7比特ASCII码格式,如果含有非7比特ASCII字符,则这些数据必须按照7比特ASCII码进行编码;HTTP不受这种限制;
  3. HTTP把每个对象分别封装在不同的HTTP响应报文中;SMTP则把所有报文对象放在一个报文中;

2.3.3 邮件报文格式

To:发件人地址
From:收件人地址
Subject:邮件主题

...邮件正文

2.3.4 邮件访问协议

Mail accss protocol

收件人的用户代理不能使用SMTP得到报文,因为取得报文是一个拉操作,而SMTP协议是一个推协议。通过引用一个特殊的邮件访问协议来解决这个问题,该协议将收件人邮件服务器上的报文传送给他的本地PC。目前有一些流行的邮件访问协议,包括第三版的邮局协议(Post Office Protocol-Version 3,POP3)(不常用)、因特网邮件访问协议(Internet Mail Access Protocol,IMAP)以及HTTP。

在这里插入图片描述

在这里插入图片描述

2.4 DNS:因特网的目录服务

Domain Name System

2.4.1 DNS提供的服务

DNS:services

识别主机的两种方式:通过主机名(hostname)或者IP地址(IP address)。人们喜欢记忆主机名标识方式,而路由器喜欢定长的、有着层次结构的IP地址。域名系统的主要任务:主机名到IP地址转换的目录服务

DNS是:

  1. 一个由分层的DNS服务器(DNS service) 实现的分布式数据库;
  2. 一个使得主机能够查询分布式数据库的应用层协议;

DNS协议运行在UDP之下,使用53号端口;

在这里插入图片描述

DNS重要的服务:

  • 主机名到IP地址的转换(hostname to IP address translation);
  • 主机别名(host aliasing):应用程序调用DNS获取主机别名对应的规范主机名(canonical hostname) 以及主机的IP地址;
  • 邮件服务器别名(mail server aliasing);
  • 负载分配(load distribution):繁忙的站点被冗余分布在多台服务器上,每台服务器运行在不同的端系统上,每个都有着不同的IP地址。由于这些冗余的Web服务器,一个IP地址集合一个规范主机名相联系。当客户对映射到某处到某地址集合的名字发出一个DNS请求时,该服务器用IP地址的整个集合进行响应,但在每个回答中循环这些地址次序。因为客户通常 总是向IP地址排在最前面的服务器发送HTTP请求报文 ,所以DNS就在所有这些冗余的Web服务器之间循环分配了负载;

2.4.2 DNS工作机理概述

Overview of How DNS Works

集中式设计的问题包括:

  • 单点故障(a single point of failure);
  • 通信容量(traffic volume);
  • 远距离的集中式数据库(distant centralized database);
  • 维护(maintenance);
分布式,层次数据库

分布式DNS服务器的层次结构:

  • 根DNS服务器(root DNS servers);
  • 顶级域服务器(Top-Level Domain DNS servers);
  • 权威DNS服务器(authoritative DNS servers);
  • 本地服务器(local DNS servers):不属于该服务器的层次结构,但它对DNS层次结构是至关重要的;

在这里插入图片描述

查询方式
  1. 递归查询(Recursive query)

在这里插入图片描述

  1. 迭代查询(Iterative query)

在这里插入图片描述

从请求主机到本地的DNS服务器的查询是递归的,其余的查询是迭代的。

DNS缓存

在某一个请求链中,当某DNS服务器接收一个DNS回答,它能映射在本地存储器中。由于主机和主机名与IP地址的映射并不是永久的,DNS服务器在一段时间后将丢弃缓存的信息。

2.4.3 DNS记录和报文

DNS Record and Protocol Message

DNS记录

所有DNS服务器存储了资源记录(Resourse Record,RR),资源记录是一个包含了下列字段的4元组:

  • (Name, Value, Type, TTL)

下面为不同类型TypeNameValue

在这里插入图片描述

DNS报文

DNS报文中各字段的语义如下:

在这里插入图片描述

2.5 P2P文件分发

Peer-to-Peer File Distribution

CS系统极大依赖于总是打开的基础设施服务器,P2P对总是打开的服务器有最小的(或者没有)依赖。

P2P体系结构的扩展性

Scalability of P2P Architectures

文件分发问题的示例图如下:

在这里插入图片描述

对于客户-服务器体系结构的分发时间如下:
D c s = max ⁡ { N F u s , F d m i n } D_{cs}=\max\{\frac{NF}{u_s},\frac{F}{d_{min}}\} Dcs=max{usNF,dminF}
对于P2P体系结构分发时间如下:
D P 2 P = max ⁡ { F u s , F d m i n , N F u s + ∑ i = 1 N u i } D_{P2P}=\max\{\frac{F}{u_s},\frac{F}{d_{min}},\frac{NF}{u_s+\sum^N_{i=1}u_i}\} DP2P=max{usF,dminF,us+i=1NuiNF}
P2P和客户-服务器体系结构的分发时间随用户数量变化如下:

在这里插入图片描述

BitTorrent

参与一个特定文件分发的所有对等方的集合被称为一个洪流(torrent)。在一个洪流中的对等方彼此下载等长度的文件块(chunk) ,典型块长度为256KB。当一个对等方下载块时,也为其他对等方上载了多个块。每个洪流具有一个基础设施节点,称为追踪器(tracker)。当一个对等方加入某洪流时,它向追踪器注册自己,并周期性地通知追踪器它仍在该洪流中。

在这里插入图片描述

  • 决定请求哪些块的过程:最稀缺优先(rarest first) 技术;
  • 决定响应哪个请求:根据当前能够以最高速率的疏通(unchoked) 的对等方提供数据的邻居,给出优先权;

2.6 视频流和内容分发网

Video Streaming and Content Distribution Networks

2.6.1 HTTP流和DASH

HTTP流所有客户接受到相同编码的视频,但对不同用户或者不同时间,客户可用的带宽大小有很大不同。HTTP的动态适应性流(Dynamic Adaptive Streaming over HTTP,DASH):视频编码成几个不同的版本,其中每个版本具有不同的比特率,对应于不同的质量水平。客户动态地请求来自不同版本且长度为几秒的视频段数据块。

每个视频版本存储在HTTP服务器中,每个版本都有一个不同的URL。HTTP服务器也有一个告示文件(manifest file),为每个版本提供了一个URL及其比特率。

2.6.2 内容分发网

为了应对向分布于全世界的用户分发巨量视频数据的挑战,几乎所有主要的视频流公司都利用内容分发网(Content Distribution Network,CDN)。CDN管理分布在多个地理位置上的服务器,在它的服务器中存储视频的副本,并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置。CDN可以是专用CDN(private CDN),即它由内容提供商自己所拥有;另一种CDN可以是第三方CDN(third-party CDN),它代表多个内容提供商分发内容。

CDN操作

当客户请求一个特定视频时,CDN必须截获该请求,以便能够:

  1. 确定此时适合用于该客户的CDN服务器集群;
  2. 将客户的请求重定向到该集群的某台服务器;

CDN操作步骤如下:

在这里插入图片描述

2.7 套接字编程:生成网络应用

Socket Programming: Creating Network Applications

2.7.1 UDP套接字编程

在这里插入图片描述

2.7.2 TCP套接字编程

在这里插入图片描述

⭐⭐⭐⭐⭐⭐
Github主页👉https://github.com/A-BigTree
项目链接👉https://github.com/A-BigTree/college_assignment
⭐⭐⭐⭐⭐⭐

  • 4
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
经典计算机网络教材 Computer Networks, Fourth Edition By Andrew S. Tanenbaum Table of Contents Chapter 1. Introduction Section 1.1. Uses of Computer Networks Section 1.2. Network Hardware Section 1.3. Network Software Section 1.4. Reference Models Section 1.5. Example Networks Section 1.6. Network Standardization Section 1.7. Metric Units Section 1.8. Outline of the Rest of the Book Section 1.9. Summary Chapter 2. The Physical Layer Section 2.1. The Theoretical Basis for Data Communication Section 2.2. Guided Transmission Media Section 2.3. Wireless Transmission Section 2.4. Communication Satellites Section 2.5. The Public Switched Telephone Network Section 2.6. The Mobile Telephone System Section 2.7. Cable Television Section 2.8. Summary Chapter 3. The Data Link Layer Section 3.1. Data Link Layer Design Issues Section 3.2. Error Detection and Correction Section 3.3. Elementary Data Link Protocols Section 3.4. Sliding Window Protocols Section 3.5. Protocol Verification Section 3.6. Example Data Link Protocols Section 3.7. Summary Chapter 4. The Medium Access Control Sublayer Section 4.1. The Channel Allocation Problem Section 4.2. Multiple Access Protocols Section 4.3. Ethernet Section 4.4. Wireless LANs Section 4.5. Broadband Wireless Section 4.6. Bluetooth Section 4.7. Data Link Layer Switching Section 4.8. Summary Chapter 5. The Network Layer Section 5.1. Network Layer Design Issues Section 5.2. Routing Algorithms Section 5.3. Congestion Control Algorithms Section 5.4. Quality of Service Section 5.5. Internetworking Section 5.6. The Network Layer in the Internet Section 5.7. Summary Chapter 6. The Transport Layer Section 6.1. The Transport Service Section 6.2. Elements of Transport Protocols Section 6.3. A Simple Transport Protocol Section 6.4. The Internet Transport Protocols: UDP Section 6.5. The Internet Transport Protocols: TCP Section 6.6. Performance Issues Section 6.7. Summary Chapter 7. The Application Layer Section 7.1. DNS—The Domain Name System Section 7.2. Electronic Mail Section 7.3. The World Wide Web Section 7.4. Multimedia Section 7.5. Summary Chapter 8. Network Security Section 8.1. Cryptography Section 8.2. Symmetric-Key Algorithms Section 8.3. Public-Key Algorithms Section 8.4. Digital Signatures Section 8.5. Management of Public Keys Section 8.6. Communication Security Section 8.7. Authentication Protocols Section 8.8. E-Mail Security Section 8.9. Web Security Section 8.10. Social Issues Section 8.11. Summary Chapter 9. Reading List and Bibliography Section 9.1. Suggestions for Further Reading Section 9.1.1. Introduction and General Works Section 9.2. Alphabetical Bibliography
SAE J1939-71-2020是一项关于车辆应用层通信的技术标准。它是由汽车工程师学会(SAE)制定的,用于描述车辆控制系统之间的通信协议和数据交换格式。 该标准定义了在车辆系统中使用的消息协议、通信速率、数据字段和识别的方法。它为不同的设备和通信系统提供了一个统一的规范,确保了数据的一致性和兼容性。 车辆应用层通信是指车辆控制系统之间的数据交换和信息传输。它可以用于诸如发动机控制、传动系统控制、车辆监控和故障诊断等方面。 根据SAE J1939-71-2020标准,车辆应用层通信主要基于控制器局域网络(CAN)技术。CAN总线是一种高度可靠、高效的数据通信系统,广泛应用于汽车领域。 在车辆应用层通信中,SAE J1939-71-2020标准提供了一种灵活的消息传输方法,使得不同的控制器可以通过CAN总线进行相互之间的信息传递。这些消息可以是控制指令、传感器数据、故障代码等。 SAE J1939-71-2020标准还定义了数据协议的格式和编码方式。它使用16进制表示数据,其中包括了识别码(PGN)、源地址(SA)、目标地址(DA)和数据内容。 总而言之,SAE J1939-71-2020是一个用于车辆应用层通信的标准,它提供了一种统一的协议和数据格式,使得车辆控制系统之间的通信更加简单和可靠。它在汽车工程领域具有广泛的应用,为车辆的控制和监测提供了基础。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一棵___大树

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值