文章目录
- 2.1 应用层原理
- 2.1.1 网络应用程序体系结构
- 2.1.2 进程通信
- 2.1.3 可供应用程序使用的运输服务
- 2.1.4 因特网提供的运输服务
- 2.1.5 应用层协议
- 2.2.2 Web 和 HTTP
- 2.2.1 HTTP概况
- 2.2.2 非持续连接和持续连接
- 2.2.3 HTTP报文格式
- 2.2.4 用户与服务器的交互:cookie
- 2.2.5 Web缓存
- 2.2.6 条件GET
- 2.3 3 因特网中的电子邮件
- 2.3.1 SMTP
- 2.3.2 与HTTP的对比
- 2.3.3 邮件报文格式
- 2.3.4 邮件访问协议
- 2.4 DNS:因特网的目录服务
- 2.4.1 DNS提供的访问
- 2.4.2 DNS工作机制
- 2.4.3 DNS记录和报文
- 2.5 P2P文件分发
- 2.6 视频流和内容分发网
- 2.6.1 因特网视频
- 2.6.2 HTTP 流和 DASH
- 2.6.3 内容分发网
- 2.7 套接字编程:生成网络应用
- 2.7.1 UDP套接字编程
- 2.7.2 TCP套接字编程
- 2.8 小节
2.1 应用层原理
2.1.1 网络应用程序体系结构
现代网络应用程序中所使用的两种主流体系:客户-服务器结构、对等(P2P)体系结构
- 客户-服务器结构:简单来说就是服务器提供数据,客户端需要访问服务器来获取数据。
- P2P体系结构:网络中每个节点地位相同,既可以接收数据,也可以为其他节点提供数据。具有很强的自扩展性
2.1.2 进程通信
在两个不同端系统上的进程,通过跨越计算机网络交换报文(message)而相互通信。 发送进程生成并向网络中发送报文;接收进程接收这些报文并可能通过回送报文进行响应。
-
客户与服务器进程
我们通常将这两个进程之一标识为客户(client),而另一个进程标识为服务器(serve)。
在一对进程之间的通信会话场景中,发起通信(即在该会话开始时发起与其 他进程的联系)的进程被标识为客户,在会话开始时等待联系的进程是服务器。
-
进程与计算机网络之间的接口
进程通过一个称为套接字(socket)的软件接口向网络发送报文和从网络接收报文。
-
进程寻址
在一台主机上运 行的进程为了向在另一台主机上运行的进程发送分组,接收进程需要有一个地址。在因特网中,主机由其IP地址(IP address)标识。
2.1.3 可供应用程序使用的运输服务
我们大体能够从四个方面对应用程序服务要求进行分类:可靠数据传输、吞吐量、定时和安全性。
-
可靠数据传输
运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数据传输。当一个运输协议提供这种服务时,发送进程只要将其数据传递进套接字,就可以 完全相信该数据将能无差错地到达接收进程。
当一个运输层协议不提供可靠数据传输时,由发送进程发送的某些数据可能到达不了接收进程
-
吞吐量
即运输层协议能够以某种特定的速率提供确保的可用吞吐量。使用这种服务,该应用程序能够请求r比特 / 秒的确保吞吐量,并且该运输协议能够确保可用吞吐量总是为至少 r比特 / 秒。
-
定时
运输层协议也能提供定时保证。即保证发送方注入进套接字中的每个比特到达接收方的套接字不迟于 xx ms。
-
安全性
运输协议能够为应用程序提供一种或多种安全性服务。这种服务将在发送和接收进程之间提供机密性,以防该数据以某种方式在这两个进程之间被观察到
2.1.4 因特网提供的运输服务
因特网(更一般的是TCP/IP网络)为应用程序提供 两个运输层协议,即UDP和TCP。
-
TCP服务:TCP服务模型包括面向连接服务和可靠数据传输服务
-
面向连接的服务:在应用层数据报文开始流动之前,TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提醒客户和服务器,让它们为大量分组 的到来做好准备。在握手阶段后,一个TCP连接(TCP connection)就在两个进 程的套接字之间建立了。这条连接是全双工的,即连接双方的进程可以在此连接 上同时进行报文收发。当应用程序结束报文发送时,必须拆除该连接。
-
可靠的数据传送服务:通信进程能够依靠TCP,无差错、按适当顺序交付所有发 送的数据。当应用程序的一端将字节流传进套接字时,它能够依靠TCP将相同的字节流交付给接收方的套接字,而没有字节的丢失和冗余。
-
-
UDP服务:UDP是一种不提供不必要服务的轻量级运输协议,它仅提供最小服务。UDP是无连 接的,因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务,也 就是说,当进程将一个报文发送进UDP套接字时,UDP协议并不保证该报文将到达接收 进程。不仅如此,到达接收进程的报文也可能是乱序到达的。
-
因特网运输协议所不提供的服务:对吞吐量或定时保证目前的因特网运输协议并没有提供,因特网被设计成尽最大可能对付这种保证的缺乏。
2.1.5 应用层协议
应用层协议(application-layer protocol)定义了运行在不同 端系统上的应用程序进程如何相互传递报文。特别是应用层协议定义了
- 交换的报文类型,例如请求报文和响应报文。
- 各种报文类型的语法,如报文中的各个字段及这些字段是如何描述的。
- 字段的语义,即这些字段中的信息的含义。
- 确定一个进程何时以及如何发送报文,对报文进行响应的规则。
2.2.2 Web 和 HTTP
2.2.1 HTTP概况
Web的应用层协议是超文本传输协议(HyperText Transfer Protocol, HTTP),它是Web 的核心,在[RFC 1945]和[RFC 2616]中进行了定义。HTTP由两个程序实现:一个客 户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中,通过交换 HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。
HTTP定义了 Web客户向Web服务器请求Web页面的方式,以及服务器向客户传 送Web页面的方式。
HTTP使用TCP作为它的支撑运输协 议(而不是在UDP上运行)。HTTP客户 首先发起一个与服务器的TCP连接。
因为HTTP服务器并不保存关于客户的任何信息,所以 我们说HTTP是一个无状态协议(stateless protocol)。
2.2.2 非持续连接和持续连接
-
采用非持续联接,那么页面上每个请求都会经过TCP的握手过程。如果页面上有10个图片,那么加上页面,总共会有11次请求,11次TCP握手的过程。这样有一些缺点,第一,必须为每一个请求的对象建立和维护一个全新的连接。第二,每一个对象经受两倍RTT的交付时延, 即一个RTT用于创建TCP,另一个RTT用于请求和接收一个对象。
-
持续联接,在采用HTTP 1.1持续连接的情况下,服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间,后续的请求和响应报文能够通过相同的连接进行传送,对对象的这些请求可以一个接一个地发出,而不必等待对未决请求(流水线)的回答。
2.2.3 HTTP报文格式
1.HTTP请求报文
下面提供了一个典型的HTTP请求报文:
GET /somedir/page.html HTTP/1.1
Host: www someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
报文每行由一个回车和换行符结束。最后一行后再附加一个回车换行符。
HTTP请求报文的第一行叫作请求行(request line),其后继的行叫作首部行(header line)。请求行有3个字段:方法字段、URL字段和HTTP版本字段。方法字段可以取几种不同的值,包括GET、POST、HEAD、PUT和DELETE绝大部分的HTTP请求报文使用 GET方法。
2.HTTP响应报文
请求报文的响应。
HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tuer 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data •••)
上面报文它有三个部分:一个初始状态行(status line) , 6个首部行(headerline),然后是实体(entity body)。实体部分是报文的主要部分,即它包含了所请求的对象本身(表示为data data data data data …)
状态行有3个字段:协议版本字段、状态码和相应状态信息。
2.2.4 用户与服务器的交互:cookie
cookie可以用来识别用户。cookie技术有4个组件:①在HTTP响应报文中的一个cookie首部 行;②在HTTP请求报文中的一个cookie首部行;③在用户端系统中保留有一个cookie文件,并由用户的浏览器进行管理;④位于Web站点的一个后端数据库。
2.2.5 Web缓存
Web缓存器(Web cache)也叫代理 服务器(proxy server),它是能够代表初 始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间, 并在存储空间中保存最近请求过的对象的副本。
2.2.6 条件GET
尽管高速缓存能减少用户感受到的响应时间,但也引入了一个新的问题,即存放在缓 存器中的对象副本可能是陈旧的。换句话说,保存在服务器中的对象自该副本缓存在客户 上以后可能已经被修改了。
HTTP协议有一种机制,允许缓存器证实它的对象是最新的。这种机制就是条件GET (conditional GET)方法。如果:①请求报文使用GET 方法;并且②请求报文中包含一个“ If-Modified-Since: ”首部行。那么,这个HTTP请求报文就是一个条件GET请求报文。
在服务端就会去判断这个If-Modified-Since字段,通过对比时间给出响应,如果该文件已经修改,那么就会把对应的文件进行返回,如果没有修改,在响应行中会有304 Not Modified,在响应体中就不会有任何内容
2.3 3 因特网中的电子邮件
上图给出了因特网电子邮件系统的总体情况,可以看到它有3 个主要组成部分:用户代理(user agent)、邮件服务器(mail server)和简单邮件传输 协议(Simple Mail Transfer Protocol, SMTP)。
2.3.1 SMTP
SMTP是因特网电子邮件的核心。SMTP用于从发送方的邮件服务器发送报文到接收方的邮件服务器。
2.3.2 与HTTP的对比
-
SMTP和HTTP这两个协议都用于从一台主机向另一台主机传送文件
-
HTTP从Web服务器向Web客户(通常是一个浏览器)传送文件(也称为对象)。SMTP从一个邮件服务器向另一个邮件服务器传送文件(即电子邮件报文)。
-
当进行文件传送时,HTTP和SMTP都使用持续连接
-
-
HTTP主要是一个拉协议(pull protocol), 即在方便的时候,某些人在Web服务器上装载信息,用户使用HTTP从该服务器拉取这些信息。SMTP基本上是一个推协议(push protocol),即发送邮件服务器把文件推向接收邮件服务器。
-
SMTP要求每个报文(包括它们的体)采用7比特ASCII码格式。HTTP数据则不受这种限制。
-
HTTP把每个对象封装到它自己的HTTP响应报文中, 而SMTP则把所有报文对象放在一个报文之中。
2.3.3 邮件报文格式
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.
每个首部必须含有一个 From: 首部行 和一个 To: 首部行。一个首部也许包含一个 Subject: 首部行 以及其他可选的首部行。
在报文首部之后,紧接着一个空白行,然后是以ACSII格式表示的报文体。你应当用 Telnet向邮件服务器发送包含一些首部行的报文,包括Subject:首部行。
下面是一个在SMTP客户(C)和SMTP服务器(S)之间交换报文文本的例子。
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.frf pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr ... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... 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
2.3.4 邮件访问协议
上述图片描述了发送邮件的过程,Alice发送邮件是先发往自己的代理服务器,然后由代理服务器发送到Bob的代理服务器,最终Bob通过某些协议(不能使用SMTP,因为SMTP是推协议,主动获取是一个拉的过程)从自己的代理服务器获取邮件
POP3(Post Office Protocol version 3)是一种用于从服务器上获取电子邮件的应用层协议。它允许用户通过电子邮件客户端从邮件服务器上下载自己的电子邮件,以便离线阅读和管理。
IMAP(Internet Message Access Protocol)是一种用于电子邮件的应用层协议,它允许用户通过电子邮件客户端在多个设备之间同步、管理和访问邮件。
现在,越来越多的用户使用他们的Web浏览器收发电子邮件。使用这种服务,那么除了邮件服务器之间使用的访问是SMTP,其他使用的协议都是HTTP
2.4 DNS:因特网的目录服务
简单的说,DNS可以获取到域名->IP的映射
2.4.1 DNS提供的访问
DNS是:①一个由分层的DNS服务器(DNS server)实现的分布式数据库;②一个使得主机能够查询分布式数据库的应用层协议。 DNS 服务器通常是运行 BIND ( Berkeley Internet Name Domain)软件[BIND 2012 ]的 UNIX机器。DNS协议运行在UDP之上,使用53号端口
当游览器发出一个www. someschool. edu/index. html的请求时,会发生以下过程
-
同一台用户主机上运行着DNS应用的客户端。
-
浏览器从上述URL中抽取岀主机名www.someschool.edu,并将这台主机名传给 DNS应用的客户端。
-
DNS客户向DNS服务器发送一个包含主机名的请求。
-
DNS客户最终会收到一份回答报文,其中含有对应于该主机名的IP地址。
-
一旦浏览器接收到来自DNS的该IP地址,它能够向位于该IP地址80端口的 HTTP服务器进程发起一个TCP连接。
除了进行主机名到IP地址的转换外,DNS还提供了一些重要的服务:
- 主机别名(host aliasing) :有着复杂主机名的主机能拥有一个或者多个别名。应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址。
- 邮件服务器别名(mail server aliasing):电子邮件应用程序可以调用DNS,对提供的主机名别名进行解析,以获得该主机的规范主机名及其IP地址。
- 负载分配(load distribution):DNS也用于在冗余的服务器(如冗余的Web服务器等)之间进行负载分配。
2.4.2 DNS工作机制
域名服务器分为三类,如下
- 根DNS服务器:有400多个根名字服务器遍及全世界。这些根名字服务器由13 个不同的组织管理。根名字服务器提供TLD(顶级域)服务器的IP地址
- 顶级域(DNS)服务器:对于每个顶级域(如com、org、net、edu和gov)和所有国家的顶级域(如uk、fr、ca和jp),都有TLD服务器(或服务器集群)。TLD服务器提供了权威DNS服务器的IP地址。
- 权威DNS服务器:在因特网上具有公共可访问主机(如Web服务器和邮件服务器)的每个组织机构必须提供公共可访问的DNS记录,这些记录将这些主机的名字映射为IP地址。
DNS的工作机制可以简单概括为以下步骤:
- 域名查询发起: 当用户在Web浏览器中输入一个域名(例如www.example.com),浏览器会向本地计算机的DNS解析器发送一个域名查询请求,询问该域名对应的IP地址。
- 本地解析器查询: 本地解析器是用户设备或网络中的DNS缓存服务器,它会首先查看自己的缓存中是否有与请求的域名对应的IP地址。如果有,它会直接返回该IP地址,从而加快解析过程。
- 递归查询: 如果本地解析器的缓存中没有请求的域名对应的IP地址,它会发起递归查询。本地解析器向根域名服务器发送查询请求,询问该域名的顶级域名服务器(如.com域名的顶级域名服务器)的IP地址。
- 顶级域名服务器查询: 根域名服务器将本地解析器引导到正确的顶级域名服务器,比如.com域名的顶级域名服务器。顶级域名服务器知道负责该域名的权威域名服务器的IP地址。
- 权威域名服务器查询: 顶级域名服务器将本地解析器引导到负责请求域名的权威域名服务器。权威域名服务器保存着该域名对应的IP地址记录。
- IP地址返回: 权威域名服务器将请求域名的IP地址返回给本地解析器。
- 本地解析器返回: 本地解析器将收到的IP地址返回给用户的计算机或设备。
- 访问网站: 用户的计算机或设备现在知道了请求域名的IP地址,它可以使用这个IP地址来建立与服务器的连接,访问相应的网站或资源。
为了改善时延性能并减少在因特网上到处传输的DNS报文数量, DNS广泛使用了缓存技术。
在一个请求链中,当某DNS服务器接收一个DNS回答(例如,包含某主机名到IP地址的映射)时,它能将映射缓存在本地存储器中
2.4.3 DNS记录和报文
DNS记录的一般格式如下:
Name | TTL | Class | Type | Data
以下是每个字段的说明:
- Name(域名): 域名是要映射的主机名或域名,例如www.example.com。在DNS记录中,域名通常以点分割的方式表示,例如www 是主机名,example 是第二级域名,com 是顶级域名。
- TTL(Time to Live): TTL表示DNS记录在缓存中的存活时间,以秒为单位。在这段时间内,其他设备或DNS服务器可以使用缓存的记录,而不必再次查询DNS服务器。一旦TTL过期,缓存会失效,需要重新查询DNS服务器。
- Class(类): DNS记录的类通常为IN,表示Internet类。其他可能的值不太常用。
- Type(类型): Type字段指示记录的类型,例如A、AAAA、MX、CNAME等。不同的类型表示不同的信息,比如A记录表示将域名映射到IPv4地址,MX记录表示邮件交换服务器。
- Data(数据): 数据字段包含与特定记录类型相关的数据。例如,A记录的数据字段将是一个IPv4地址,MX记录的数据字段将是邮件服务器的主机名。
DNS报文格式如下
2.5 P2P文件分发
P2P(Peer-to-Peer,点对点)文件分发是一种基于分布式架构的文件共享和传输方法。与传统的客户端-服务器模式不同,P2P文件分发允许用户之间直接共享文件,从而实现更快的下载速度和更有效的带宽利用。
P2P文件分发的优势包括:
- 带宽效率: 由于文件从多个来源下载,P2P可以更好地利用网络带宽,加速文件下载过程。
- 分散性: 无需集中的服务器,P2P网络在节点之间共享文件,减少了中心化服务器的风险。
- 可扩展性: 更多用户加入P2P网络,下载速度通常会更快,因为有更多的资源可以共享。
- 弹性: P2P网络更有弹性,因为当一个节点下线时,其他节点仍然可以继续共享文件。
2.6 视频流和内容分发网
事先录制的流式视频现在是ISP中的流量主体。
2.6.1 因特网视频
视频可以按照视频流的方式进行传输
2.6.2 HTTP 流和 DASH
HTTP流(HTTP Streaming)和DASH(Dynamic Adaptive Streaming over HTTP)都是与视频和音频流传输相关的技术,用于在互联网上传递媒体内容,特别是在不同网络条件下提供更好的用户体验。
-
HTTP流(HTTP Streaming):
HTTP流是一种将媒体内容,如视频和音频,以流式方式传输到终端用户设备的技术。它使用HTTP协议来分割媒体文件成小块(片段),然后逐个块地传输。这种方法的一个优势是,用户可以从传输的媒体流中开始播放,而不必等待整个文件下载完成。这有助于更快地启动播放和减少缓冲时间。HTTP流通常使用扩展名为.ts(Transport Stream)或.m3u8(HLS格式)的文件,其中.ts文件包含媒体片段的实际内容,而.m3u8文件是一个播放列表,指示客户端如何按顺序请求和播放这些片段。
-
DASH(Dynamic Adaptive Streaming over HTTP):
DASH是一种自适应流媒体技术,它允许媒体内容根据用户的网络条件和设备能力动态地调整质量和分辨率。DASH使用HTTP协议,将媒体文件分割成不同质量的片段,然后根据客户端的网络带宽和性能选择合适的片段进行传输和播放。DASH的核心思想是在媒体内容的不同质量版本之间进行切换,以便在不同的网络条件下提供最佳的观看体验。如果网络带宽降低,客户端可以自动切换到较低质量的片段,从而避免卡顿和缓冲。反之,如果网络状况良好,DASH可以切换到更高质量的片段,提供更清晰的画面和更高的分辨率。
总的来说,HTTP流和DASH都是用于通过HTTP协议传输媒体内容的技术,帮助优化用户在不同网络条件下的观看体验。它们在视频点播、直播和流媒体服务中得到广泛应用。
2.6.3 内容分发网
内容分发网络(Content Delivery Network,CDN)是一种用于提供网络内容的分布式基础架构,旨在改善用户对于网站、应用程序、媒体等内容的访问速度、可用性和性能。CDN通过将内容缓存在位于全球各地的服务器上,使用户可以从离他们最近的服务器获取内容,从而减少了网络延迟和拥塞。
CDN的主要原理是在网络中放置一系列的缓存服务器,这些服务器分布在不同的地理位置和网络节点上。当用户请求某个内容时,CDN会自动将用户的请求重定向到最近的缓存服务器,从而提供更快的内容传输。以下是CDN的关键特点和工作原理:
-
缓存和就近访问: CDN服务器在全球范围内分布,缓存网站的静态内容(如图像、CSS、JavaScript等)。当用户请求内容时,他们被连接到距离最近的CDN服务器,从而减少传输延迟。
-
负载均衡: CDN通过将用户请求分发到多个服务器上,实现负载均衡。这样可以避免单一服务器过载,提高整体性能。
-
动态内容加速: 除了缓存静态内容,一些CDN还可以加速动态内容,如根据用户请求生成的页面。
-
故障容忍: 如果某个CDN节点发生故障,请求可以自动重定向到其他可用的节点,从而提高可用性。
-
内容优化: 一些CDN可以对内容进行优化,如压缩、图像优化等,以提高传输速度和用户体验。
-
安全性: CDN可以提供一些安全功能,如DDoS攻击缓解、SSL证书管理等。
CDN的应用范围广泛,适用于各种类型的网站、应用和媒体内容,包括静态网站、电子商务网站、流媒体服务、在线游戏等。通过将内容分发到全球各地的服务器,CDN可以显著减少用户在访问内容时的延迟,提供更快速、可靠和高性能的用户体验。
2.7 套接字编程:生成网络应用
套接字编程是一种在计算机网络中创建网络应用程序的方法。通过使用套接字(socket),开发人员可以在不同计算机之间建立通信连接,从而实现数据传输和交换。套接字编程通常用于开发各种网络应用,包括网络游戏、聊天应用、Web服务器和客户端等。
2.7.1 UDP套接字编程
UDP套接字编程过程如下
2.7.2 TCP套接字编程
TCP套接字编程过程如下
2.8 小节
各地的服务器,CDN可以显著减少用户在访问内容时的延迟,提供更快速、可靠和高性能的用户体验。