参考模型中的各层一般都满足“应用下层的服务,为上层提供服务”,但应用层较为特殊,因为应用层没有上层,所以应用层直接为模型外的用户提供服务,应用层是最靠近用户的一层
网络应用程序体系结构是由应用程序开发者研发,规定如何在各种端系统上组织该应用程序(应用程序体系结构独立于TCP/IP协议栈,是由程序开发者使用的体系结构),目前主流的体系结构有以下几种
客户-服务器体系结构将端系统分为客户机(Client)和服务器(Server)两种
服务器特点:
客户端特点:
除了位于数据中心的专用服务器外,几乎没有是中运行的服务器存在,并且对钟信服务器依赖很小,任意端系统之间可以直接进行连接,这些相互直接连接的主机对被称为对等方,每一个节点既是客户端又是服务端,即请求服务,又提供服务(因此P2P体系结构,具有自扩展性,新节点会带来新请求同时带来新的服务),参与的主机间歇性连接并且可以改变IP地址(程间实例有迅雷,BitTorrent等等)
由于P2P体系结构允许参与主机随时进行连接或结束连接,所以该体系结构难以管理,并且在未来可能面临安全性可靠性等的挑战
进程:一段程序的执行过程,一个应用程序可能有一个或多个进程(例如当浏览器中打开多个网页时,每个单独的网页就是一个进程)
进程通信就是两个进程之间进行数据的传输或交换,位于同一台主机上的两个进程,可以通过操作系统指定的方式不经过网络进行进程的通信,而位于不同主机上的不同进程之间想要实现通信就需要通过交换报文(Message)的方式实现通信
我们将进行进程通信的双方分成:
两台主机之间企图进行通讯首先至少需要两台目标主机的IP地址,以保证报文能够顺利到达目标主机并且能够根据IP响应报文,并且由于是进程间的通信,还需要两个进程的端口号,并且,最后,还需要用到所采用的传输层协议,以保证能够正确的解析数据
应用层需要向传输层传递的信息
如果每次通信/对话都需要携带如此多的信息,无疑会加剧管理难度,并且容易出错,所以可以采用一个代号来指代通信双方/单方的信息,这个信息就是socket(与我们通过文件操作打开文件OS会返回一个句柄一样,对句柄的操作就是对文件的操作,这里我们对socket的操作就是对通信双方交换数据的操作),所谓套接字(Socket),就是对网络中不同主机上的应用进程之间进行双向通信的端点的抽象。
TCP上的套接字(流套接字)
流套接字用于提供面向连接、可靠的数据传输服务。该服务将保证数据能够实现无差错、无重复送,并按顺序接收。流套接字之所以能够实现可靠的数据服务,原因在于其使用了传输控制协议,即TCP协议,对于使用面向连接服务(TCP)的应用而言,套接字是4元组:(源IP,源port,目标IP,目标port)的一个具有本地意义的标示
UDP上的套接字(数据报套接字)
数据报套接字提供一种无连接的服务。该服务并不能保证数据传输的可靠性,数据有可能在传输过程中丢失或出现数据重复,且无法保证顺序地接收到数据。数据报套接字使用UDP协议进行数据的传输。由于数据报套接字不能保证数据传输的可靠性,对于有可能出现的数据丢失情况,需要在程序中做相应的处理对于使用无连接服务(UDP)的应用而言,套接字是2元组的一个具有本地意义的标示
应用 | 数据丢失率 | 吞吐 | 时间敏感性 |
---|---|---|---|
文件传输 | 不能丢失 | 弹性 | 不 |
不能丢失 | 弹性 | 不 | |
Web文档 | 不能丢失 | 弹性 | 不 |
实时音视频 | 容忍丢失 | 音频:5kbps-1Mbps 视频:0kps-5Mbps | 是,100ms |
存储音视频 | 容忍丢失 | 同上 | 是,几秒 |
交互式游戏 | 容忍丢失 | 1kbps-10kbps | 是,100ms |
即时讯息 | 不能丢失 | 弹性 | 不确定 |
无论是TCP还是UDP都没有提供任何的加密机制,也就是进程通信过程中其套接字数据与经过网络传送到目的进程的数据相同(即明文传送)
为了解决这种安全性问题,遂研制出了TCP的加强版即安全套接字层(SSL:Secure Sockets Layer),其位于应用层(应用采用SSL库,SSL库使用TCP通信),能够完成传统TCP的一切功能,并且最关键的提供了进程到进程的安全性服务,包括加密,数据完整性与端点的鉴别
Web即万维网,是World Wide Web的简称。
Web 是web网页的集合( collection of web pages),其由许多对象组成,这些对象可以是HTML文件,JPEG图象,Java程序等等,每个页面包含了指向其他页面的链接(超级链接),浏览器 –显示阅读web页面的程序
Web页面由 URL (Uniform Resource Locators)标识 (i.e.http://www.abcd.com/products.html)
一个web页面可能由PDF文件、GIF图标、MPEG视频、MP3歌 曲,或者其他数百种文件类型的任何一种组成
浏览器可能在解释这些文件的时候会遇到问题,不是让浏览 器越来越大,而是采用了一个更加通用的解决方案
当服务器返回一个页面,它通常也返回一些有关该页面的附 加信息,包含了页面的MIME类型,以决定如何显示该页面
问题在于可能暴露客户隐私数据,存在安全隐患
Plug-ins:代码模块,运行在浏览器的内部
Helper applications:独立的程序,浏览器只是把参数传入
两种扩展方式各有优劣,插件可以增强浏览器的功能,应用则不能,插件启动时更加迅速,但是当插件过多就会占用过多资源,导致浏览器使用缓慢
如上图,客户的TCP连接中止于前端,所以应答也必须经过前端,一种解决的方法是TCP移交,TCP端点被传递给处理节点 ,所以应答可以直接向客户端发送 。
代理服务器(proxy server)又称为万维网高速缓存(Web cache),它代表浏览器发出 HTTP 请求。
万维网高速缓存把最近的一些请求和响应暂存在本地磁盘中。
当与暂时存放的请求相同的新请求到达时,万维网高速缓存就把暂存的响应发送出去,而不需要按 URL 的地址再去因特网访问该资源。
如果没有代理服务器,假定在内网内的不同客户端请求同一个数据,就需要同时大量传送完全相同的内容,浪费带宽资源。如果有代理服务器,在第一个客户端查询相关数据内容后,数据就暂时被保存在服务器中,后续客户端如果再次请求这组数据就可以直接从代理服务器获取,甚至不需要进入公网,十分高效快捷
由于代理服务器并不能确定客户请求的资源在代理服务器中是否是最新版本,所以在用户请求资源且资源在代理服务器中存在时,代理服务器会首先向目标服务器发送一个简单报文,其中在报文头部加上IF-MODIFIED-SINCE: <SINCE>
属性表示询问自该事件起,所请求的资源是否有被修改过,服务器会根据所给时间响应资源状态,代理服务器就可以判断是否需要更新资源
超文本传输协议(Hypertext Transfer Protocol,HTTP)是一个简单的请求-响应协议,它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出;而消息内容则具有一个类似MIME的格式。
HTTP是基于客户/服务器模式,且面向连接的。典型的HTTP事务处理有如下的过程:
从上文可以看出,HTTP协议是无状态的,即服务器并不维护关于客户的任何信息(从上文的流程可以看到,事务处理结束后客户与服务器直接关闭连接,对客户的信息不进行处理)
非持续连接HTTP表示请求/响应都经过建立一个单独的TCP连接进行
非持续连接与持续连接区别
非持续连接HTTP特点
非持续连接的缺点
非持续连接情况下的往返时间模型
持续连接HTTP表示一段时间内所有请求/响应都经过同一个TCP连接进行
持续连接HTTP的是通过服务器在发送响应后,仍保持TCP连接实现的,这保证了在相同的客户端和服务器之间的后续请求和响应报文是通过相同的TCP连接进行传送的,并且客户端在于导一个引用对象的时候,就可以尽快发送该对象的请求
根据客户端发送请求的方式可以将持续连接的HTTP分为两种
持续连接HTTP特点
HTTP请求报文数据格式
解析前的请求头
解析后的请求头
HTTP响应报文数据格式
捕获的本地HTTP报文
响应状态码分类 分类| 分类描述 —|— 1xx |信息,服务器收到请求,需要请求者继续执行操作 2xx |成功,操作被成功接收并处理 3xx |重定向,需要进一步的操作以完成请求 4xx |客户端错误,请求包含语法错误或无法完成请求 5xx |服务器错误,服务器在处理请求的过程中发生了错误
类型为“小型文本文件”,是某些网站为了辨别用户身份,进行Session跟踪而储存在用户本地终端上的数据(通常经过加密),由用户客户端计算机暂时或永久保存的信息
电子邮件系统通常由三部分组成
用户首先在UA编辑好邮件然后提交,接下来邮件会被提交到发方的邮件服务器(MTA),接下来发方的邮件传输代理将会把邮件传输到收方的MTA上,最终,当对方从UA阅读相应邮件时,该邮件会被从对方的邮件服务器发送到对方本地的UA
UA通常是一个程序,一般称为电子邮件阅读器,常见的UA有: Gmail,outlook,foxmail…
ASCII 电子邮件信息通常采用 RFC 822,注意:SMTP是交换Email报文的协议,RFC 822是文本报文的标准
信头字段 | 目的 |
---|---|
To | 收信人地址 |
CC | 抄送:另一个收信人地址 |
BCC | 密送:收信人地址,但其它收信人看不到这个收信人的地址。 |
From | 邮件作者 |
Sender | 发信人 |
Received | 沿线各转运代理增加的线路 |
Return path | 回邮地址 |
信头字段 | 目的 |
---|---|
Date | 发信日期 |
Reply-To | 回邮地址 |
Subject | 主题 |
Comments | 备注 |
Keywords | 关键字,用来进一步搜索邮件 |
In-Reply-To | 被当前邮件回复的邮件的ID |
References | 几乎同In-Reply-To一样 |
Encrypted | 加密邮件的加密类型 |
RFC5322无法处理带有重音符的语言(如法语)、非拉丁字母(如俄语)、不带字母的语言(如汉语,日语)、完全不包含文本的消息(如视频)的邮件,为此提出了MIME来解决此问题
MIME的基本思想是继续使用 RFC822格式,但是在消息体中 增加了结构,且为非ASCII消息定义了编码规则
MIME增加的消息头
Header | Meaning |
---|---|
MIME-Version | 标识MIME版本 |
Content-Description | 描述邮件包含的内容 |
Content-ID | 唯一标识符 |
Content-Transfer-Encoding | 传输过程中编码方式 |
Content-Type | 邮件内容的类型和格式(目前定义了七种类型:文本,图片,视频,音频,应用…每个类型还有一个或多个子类型) |
上文讲述了如何编写邮件,接下来进行的就是邮件的传输,邮件的传输通过简单邮件传输协议实现,这是一个简单的 ASCII 协议
源机与目标机(SMTP守护进程在监听)的25端口建立TCP连接 。如果消息不能被投递,则向消息的发送方返回一个错误报告(包含了不能投递消息的第一部分)
通过上述流程不难发现,保证邮件发送成功的前提是发送端与接收端成功建立TCP连接,这就需要接收端与发送端设备需要在发送时都保持开机状态,但这是不现实的,收方不可能一直在线,而如果收方不在线,发方就无法发送邮件
为解决上述问题,就需要在邮件服务提供商ISP的一台机器上运行一个消息传输代理(message transferagent); 这台机器可以一天24小时运行,随时都可以接收邮件
然后设计一个协议,允许用户在上线后和消息传输代理MTA联系,然后把邮件从ISP那里拷贝到用户,早期使用的协议是POP-3协议,即邮局协议3版本,改进版本为IMAP。协议的作用范围在接收端用户和代理服务器之间
POP3协议不适合应用于移动端收发邮件,因为在移动端收发邮件会导致POP3将邮件标记为删除,无法在其他客户端查看(采用下载并删除模式),这个问题,在IMAP中得到了解决
应用层是开放的,以TCP/IP为核心,向两端开放。应用层出不穷文件传输FTP,远程登录TELNET,多媒体,微信……
一种可靠的面向连接的服务,采用TCP在支持FTP的系统间传 输文件(在远程主机上传输文件或接收文件),它支持双向二进制文件和ASCII文件传输。
将文件从自己的计算机中拷贝到远程计算机上(upload)
将文件从远程计算机上拷贝到自己的计算机上。 (download)
从上面的流程不难看出,FTP是有状态的协议,其需要维护用户的状态信息,当前路径以及用户账户等等
一种无连接的不可靠的服务,采用UDP在支持TFTP的系统间传输文件。
不要求远地系统创建众多的服务器,只需为每个远程登陆用 户建立一个进程,这个进程再通过创建子进程为远程登陆用 户提供各种允许的服务。
远程登陆的另外一个优点,它提供与本地登陆几乎完全相同 的用户界面
本地用户在本地终端对远地系统进行远程登陆,该远程登陆 的内部视图实际上是一个TCP连接(服务器端口:23);
将本地终端上的键盘输入逐键传到远地机;将远地机输出送回本地终端。
在互联网中,直接使用IP地址作为机器的绝对地址是行不通的,具体原因有2点:1.计算机可能常常地更换IP地址,所以,通过IP地址去访问某台机器就会发生问题。2.IP地址难于记忆,且毫无规律。因此,我们只需要通过一个有规律性且永久不会更换的名字来标识某个IP地址,就可以解决上述问题,这就是我们所说的域名。
但是在传输数据的过程中,或是为数据加上MAC地址,或是为文件加上IP地址,却从来没有为数据加上过域名,只有IP地址可以起到标示主机与路由器的功能,因此我们必须使用域名系统DNS,来将一个个名字映射到对应的IP地址
ARPANET时代,有一个文件hosts.txt,列出了当时网络上所 有的主机和它们对应的IP地址(当网络很小的时候,可以工 作得很好),这份文件如今依然存在于电脑的 “C:\Windows\System32\drivers\etc\hosts” 路径下。但是随着互联网发展,用一份文件映射所有IP地址和域名变得不现实,因此才产生了如今的域名系统
DNS首先将整个互联网分成250个顶级域,每个顶级域被分为多个子域,子域仍可以继续划分出更多子域,所有这些域最终将会形成一棵树,树上的叶子代表没有子域的域
顶级域由ICANN负责管理运行,顶级域分为两类:通用域(.com,.edu…)以及国家域(.jp,.cn,.nl…)
域名 | 含义 | 域名 | 含义 | 域名 | 含义 |
---|---|---|---|---|---|
ac | 研究机构 | gd | 广东 | bj | 北京 |
co | 商业公司 | gx | 广西 | tj | 天津 |
or | 非盈利性组织 | sc | 四川 | eb | 河北 |
net | 提供网络服务的单位 | gz | 贵州 | sx | 山西 |
edu | 教育和科研单位 | yn | 云南 | nm | 内蒙古 |
go | 政府机构 | xz | 西藏 | en | 河南 |
ha | 海南 | sn | 陕西 | ln | 辽宁 |
ah | 安徽 | gs | 甘肃 | jl | 吉林 |
jx | 江西 | qh | 青海 | hl | 黑龙江 |
sd | 山东 | nx | 宁夏 | sh | 上海 |
fj | 福建 | xj | 新疆 | js | 江苏 |
hn | 湖南 | hb | 湖北 | zj | 浙江 |
(获得一个二级域名无需到ICANN申请),只需要到运行顶级域名的注册机构去检查带申请名字是否可用,并且不是别人商标即可申请
每个域的名字是:从它向上到根(未命名)的路径,各个部分间用圆点隔开
资源记录存储在资源服务器中,整个互联网需要多台而不是一台域名服务器,DNS名字空间被分割成不相交的区域(zones),每个区域包含域名树的一部分,也包含一台主域名服务器( primary name server )。
主域名服务器从自己硬盘的一个文件中读取信息,次域名服 务器( secondary name servers )分享这些信息
最重要的域名服务器;存储所有顶级域名的名字和IP
组织机构的DNS服务器,提供组织机构服务器(如web,email)可访问的主机和IP之间的映射
顶级域(TLD)服务器:负责顶级域名(com,org,net)和所有国家级的顶级域名(cn,uk,fr)
每个域无论是单主机域还是顶级域,都有一组跟它相关联的资料记录,当一个解析器将域名传递给DNS时,DNS返回的是与这个资源相关联的资源记录,所以DNS的主要功能,是将域名映射到资源记录上去
对等式网络(英语:peer-to-peer, 简称P2P),又称点对点技术,是无中心服务器、依靠用户群(peers)交换信息的互联网体系,它的作用在于,减低以往网路传输中的节点,以降低资料遗失的风险。与有中心服务器的中央网络系统不同,对等网络的每个用户端既是一个节点,也有服务器的功能,任何一个节点无法直接找到其他节点,必须依靠其户群进行信息交流。
),此时下载所消耗的时间取决于客户端下载单个文件所花费的时间,与服务器上载N个相同文件所花费时间中的最大值,即:
而P2P应用在进行文件传输的时候,不依赖与上传的服务器,所有peer在下载文件后都可以成为文件的提供方进行数据的上载,所以其下载所消耗最长时间取决于三个因素:
随用户数量变化C/S与P2P两种模式下载消耗时间变化如图
BitTorrent协议是架构于TCP/IP协议之上的一个P2P文件传输通信协议,处于TCP/IP结构的应用层。
根据BitTorrent协议,文件发布者会根据要发布的文件生成提供一个.torrent文件,即种子文件,也简称为“种子”。
种子文件本质上是文本文件,包含Tracker信息和文件信息两部分。Tracker信息主要是BT下载中需要用到的Tracker服务器的地址和针对Tracker服务器的设置,文件信息是根据对目标文件的计算生成的,计算结果根据BitTorrent协议内的Bencode规则进行编码。它的主要原理是需要把提供下载的文件虚拟分成大小相等的块,块大小必须为2k的整数次方(由于是虚拟分块,硬盘上并不产生各个块文件),并把每个块的索引信息和Hash验证码写入种子文件中;所以,种子文件就是被下载文件的“索引”。
下载时,BT客户端首先解析种子文件得到Tracker地址,然后连接Tracker服务器。Tracker服务器回应下载者的请求,提供下载者其他下载者(包括发布者)的IP。下载者再连接其他下载者,根据种子文件,两者分别告知对方自己已经有的块,然后交换对方所没有的数据。此时不需要其他服务器参与,分散了单个线路上的数据流量,因此减轻了服务器负担。
下载者每得到一个块,需要算出下载块的Hash验证码与种子文件中的对比,如果一样则说明块正确,不一样则需要重新下载这个块。这种规定是为了解决下载内容准确性的问题。
这种集中式目录的共享方法存在如下的问题:
Gnutella是一种全分布式的(没有中心服务器)开放文件共享协议,Gnutella协议以TCP连接作为边,两个Peer间 如果存在一条TCP连接,则看作存在一条边(不是物理链路的连接),所有活动的对等方和边构成覆盖网络
查询过程:
如何实现对等方的加入
在当下互联网环境中,视频流量占据了互联网的大部分带宽(例如网飞,油管等),单个超级服务器已经难以再为这些应用提供服务(扩展性差,难以处理高并发情况),所以需要通过分布式的,应用层面的基础设施解决这些流媒体服务
要解决视频流量占据大量带宽的问题,首先可以基于用户的角度进行解决,避免用户加载不必要的资源,对视频流量进行合理的取舍
视频是以固定速度显示的图片序列,而图片又是像素的阵列,这些都保证了视频是可以被压缩的,而这种压缩方式就是编码:使用图像内和图像间的冗余来降低编码的比特数(空间冗余是因每幅图片中临近的相近色块而产生,时间冗余则是由于相邻图像间相近而产生)
编码方式:
DASH:Dynamic Adaptive Streaming over Http
首先由服务器将视频文件分割成多个小块,每个块独立存储,并且都用不同的码率编码,同时服务器会生成告示文件(mainfest file)以提供不同的URL
当客户端请求视频文件时,首先会获取到告示文件,并且周期性的测试服务器到客户端的带宽,通过查询告示文件在每个时刻请求一个块,如果带宽足够大,则尽量请求高码率视频,会话中不同时刻,可以切换码率不同的编码块(客户端自适应)
内容分发网络(英语:Content Delivery Network或Content Distribution Network,缩写:CDN)是指一种透过互联网互相连接的电脑网络系统,利用最靠近每位用户的服务器,更快、更可靠地将音乐、图片、视频、应用程序及其他文件发送给用户,来提供高性能、可扩展性及低成本的网络内容传递给用户。
而CDN在全球全网部署节点,存储服务内容,与用户直线距离更近,可以就近为用户提供服务,提升用户体验,起到加速网络的作用
视频资源会被进行多次拷贝存储在CDN各个服务器中,用户通过告示文件重定向到最近的拷贝,进行内容的请求,过程中,如果当前请求的网络路径阻塞,可能会选择不同的拷贝进行请求