目录
(1)客户-服务器体系结构(client-server architecture)
一、应用层协议原理
1. 网络应用程序体系结构
(1)客户-服务器体系结构(client-server architecture)
服务器:一直运行;固定的IP地址和周知的端口号(约定);
客户端:主动与服务器通信;与互联网有间歇性的连接;可能是动态IP地址;不直接与其他客户端通信;
特点:扩展性差,对数据中心进行扩展;
(2)对等体(P2P)体系结构
- 几乎没有一直运行的服务器;
- 任意端系统之间可以进行通信;
- 每一个节点既是客户端又是服务器;
- 参与的主机间歇性连接且可以改变IP地址;
特点:难以管理;自扩展性(self-scalability)---新peer节点带来新的服务能力,当然也带来新的服务请求;
2. 进程通信
进程(process):在主机上运行的应用程序;
客户端进程:发起通讯的进程;
服务器进程:等待连接的进程;
在同一个主机内,使用进程间通信机制通信(由操作系统定义);
不同主机,通过交换报文(message)来通信;
注意:P2P架构的应用也有着客户端进程和服务器进程之分;
3. 分布式进程通信需要解决的问题
(1)进程标识和寻址问题
进程为了接收报文,必须有一个标识,即:SAP(服务访问点)(发送同样需要标识)
标识三要素:
- 主机IP地址:仅IP地址不能唯一标识进程,因为一台端系统上有多个进程在运行;
- 所采用的传输层协议:TCP or UDP;
- 端口号(Port Numbers):标识在主机上运行的特定应用程序或服务;
(2)传输层如何向应用层提供服务
层间接口必须要携带的信息:
- 需要传输的报文:对于本层来说就是SDU(Segment Data Unit,段数据单元)
- 谁传的:对方的应用进程的标示,IP+TCP(UDP)端口
- 传给谁:对方的应用进程的标示,IP+TCP(UDP)端口
传输层实体(TCP或UDP实体)根据这些信息进行TCP报文段(UDP数据报)的封装。
而每次传输报文,都携带如此多的信息,过于繁琐,不便管理,我们使用代号标示通信的双方或单方:socket(套接字)
TCP socket:在TCP应用中,套接字可以被视为一个四元组,其中包含了本地意义的标识(不具有全局意义)。
四元组:源IP,源Port,目标IP,目标Port
UDP socket:在UDP应用中,套接字可以被视为一个二元组,其中包含了本地意义的标识。
二元组:源端IP,源端Port;
基于TCP socket和UDP socket的区别,TCP应用发送数据时要包含socket,数据内容;而UDP应用发送数据时要包含socket,数据内容,目标IP和Port;
(3)如何使用传输层提供的服务实现应用
应用层协议:定义了运行在不同端系统上的应用进程如何相互交换报文;
应用层协议仅仅只是应用的一个组成部分,例如Web应用包括:HTTP协议,web客户端,web服务器,HTML;
描述传输层所提供的服务:可靠性、流量控制、拥塞控制等
TCP服务:可靠的传输服务,流量控制,拥塞控制,面向连接;
无法提供的服务:时间保证,最小吞出保证和安全性;
UDP服务:不可靠数据传输;
无法提供的服务:可靠,流量控制,拥塞控制,时间,带宽保证,建立连接,安全性;
UDP存在的必要性:
- 能够区分不同的进程(IP服务没有这个功能);
- 无需建立连接,省去了建立连接的时间;
- 不做可靠性的工作,例如检错重发;
- 没有拥塞控制和流量控制,应用能够按照设定的速度发送数据
安全性问题:
TCP和UDP都没有加密,明文通过互联网传输;
SSL(Secure Sockets Layer)在TCP上面实现,提供加密的TCP连接;
SSL在应用层,应用采用SSL库,SSL库使用TCP通信;
因此传输层本身并不提供安全性服务,这些安全性服务通常通过更高层的协议来实现。
二、Web与HTTP
1. 专业术语
2. HTTP概括
Web的应用层协议是超文本传输协议(HyperText Transfer Protocol,HTTP),它是Web的核心,在RFC 1945(HTTP 1.0)和RFC 2616(HTTP 1.1)中进行定义。
HTTP由两个程序实现:客户程序,服务器程序;
- 客户:请求、接受和显示Web对象的浏览器
- 服务器:对请求进行相应,发送对象的Web服务器
HTTP使用TCP作为它的支撑运输协议(而不是UDP):
HTTP客户发起一个与服务器的TCP连接(建立套接字,端口号为80),一旦连接建立,该浏览器和服务器进程就可以通过套接字接口访问TCP。
HTTP是无状态协议(stateless protocol):HTTP服务器不会保存关于客户的任何信息
例如某个特定的客户在几秒内两次请求同一个对象,服务器不会因为刚刚为该客户提供了该对象就不再做出反应,而是重新发送该对象,因为它并不会储存任何关于客户的信息。
无状态服务器通常能够支持更多的客户端,因为它们不需要为每个客户端维护状态信息,可以更高效地处理并发请求。相比之下,有状态协议需要维护历史信息,这可能会增加服务器的负担,并限制服务器能够同时处理的客户端数量。
3. HTTP连接
(1)非持久HTTP
- 最多只有一个对象在TCP连接上发送;
- 下载多个对象需要多个TCP连接;
- HTTP 1.0使用非持久连接;
响应时间模型
往返时间RTT(round-trip time):一个小的分组从客户端到服务器,再回到客户端的时间(忽略传输时间,注意此处传输时间和传播时间的区别)
响应时间:一个RTT用来发起TCP连接,一个RTT用来HTTP请求并等待HTTP相应,文件传输时间(文件的传输时间不可忽略)。共计2RTT+文件传输时间。
模型图如下:
(2)持久HTTP
- 多个对象可以在一个(在客户端和服务器之间的)TCP连接上传输;
- HTTP 1.1默认使用持久连接
非持久HTTP的缺点:
- 每个对象要2个RTT;
- 操作系统必须为每个TCP连接都分配资源;
- 浏览器通常会通过并行打开多个TCP连接来获取页面中引用的多个对象,增加网络负载和服务器负担;
持久HTTP:
- 服务器在发送响应后,仍保持TCP连接;
- 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送;
- 客户端在遇到一个引用对象的时候,就可以尽快发送该对象的请求;
(3)持久HTTP又分为非流水方式和流水方式
非流水方式的持久HTTP:
- 客户端只能在收到前一个响应后才能发出新的请求;
- 每一个引用对象花费一个RTT;
流水方式的持久HTTP:
- HTTP 1.1的默认模式;
- 客户端遇到一个引用对象就立即产生一个请求(不必等待前一个的响应);
- 所有引用对象只花费一个RTT是可能的;
4. HTTP报文格式
(1)HTTP请求报文
以上方请求报文为例,报文由普通的ASCII文本书写,可以直接阅读;该报文有5行,每一行由一个回车和换行符结束,最后一行再附加一个回车换行符。实际上一个请求报文可以有更多的行或者至少为一行。
HTTP请求报文的第一行叫做请求行(request line),其后继的行叫做首部行(header line);
请求行有三个字段:方法字段、URL字段和HTTP版本字段;
方法字段可以取几种不同的值:GET(请求)、POST(提交)、HEAD(只请求头部)等;
下面分析首部行的具体内容:
- Host: www.someschool.edu 指明了对象所在的主机;
- User-agent: Mozilla/4.0 用来指明用户代理,即向服务器发送请求的浏览器的类型;
- Connection: close 该浏览器告诉服务器不要麻烦地使用持续连接,要求服务器发送完被请求的对象后就关闭连接;
- Accept-language: fr 表示用户想得到该对象的法语版本(如果服务器有这样的对象的话),否则,服务器应当发送它的默认版本;
HTTP请求报文通用格式:
我们发现,通用格式在首部行(和附加的回车和换行)后有一个实体体(entity body) ,使用GET方法时实体体为空,而使用POST方法时才能使用该实体体;
提交表单输入
用户提交表单时,HTTP客户常常使用POST方法,例如当用户向搜索引擎提供搜索关键词时。使用POST报文时,用户仍可以向服务器请求一个Web页面,但Web页面的特定内容依赖于用户在表单字段中输入的内容。如果方法字段的值为POST时,则实体体中包含的就是用户在表单字段中的输入值;
实际上,HTML表单经常使用GET方法,并在(表单字段中)所请求的URL中包括输入的数据。例如一个表单使用GET方法,它有两个字段,分别填写的是“monkeys”和“bananas”,这样,该URL结果为www.somesite.com/animalsearch?monkeys&banana。通过这样的URL,浏览器可以将表单数据作为查询参数附加在URL中,然后将整个URL发送给服务器进行处理。服务器可以解析URL中的查询参数,并据此执行相应的操作。再比如http://www.baidu.com/s?wd=xx+yy+zzz&cl=3,表示携带的参数为wd和cl,参数的值分别为xx+yy+zzz和3。
在URL的查询字符串中,有时候会出现只有参数名而没有参数值的情况。这种情况通常发生在一些特定的场景下,例如在某些API设计中或者特定的查询需求中。在这种情况下,参数名本身就是起到一种标识或者开关的作用,而不需要具体的参数值。
方法类型:
HTTP 1.0:GET、POST、HEAD
HTTP 1.1:GET、POST、HEAD、PUT(将实体主体中的文件上载到URL字段规定的路径)、DELETE(删除URL字段规定的文件)
(2)HTTP响应报文
该响应报文分为三个部分:一个初始状态行(status line),6个首部行(header line),然后是实体体(entity body)。实体体部分是报文的主要部分,即它包含了所请求对象本身。状态行有3个字段:协议版本字段、状态码和响应状态信息。
HTTP响应状态码:
- 200 OK:请求成功,请求对象包含在响应报文的后续部分
- 301 Moved Permanently:请求的对象已经被永久转移了,新的URL在响应报文的Location:首部行中指定。客户端软件自动用新的URL去获取对象
- 400 Bad Request:一个通用的差错代码,表示该请求不能被服务器解读
- 404 Not Found:请求的文档在该服务上没有找到
- 505 HTTP Version Not Supported:服务不支持请求报文使用的HTTP协议版本
5. 用户与服务器的交互:cookie
HTTP服务器是无状态的,当Web站点希望能够识别用户,从而对用户的访问进行限制,或者是为了能够为用户提供个性化内容时,需要借助cookie。cookie在[RFC 6265]中定义,它允许站点对用户进行跟踪。
cookie技术有4个组件:
(1)HTTP响应报文中的Cookie首部行:当服务器向客户端发送HTTP响应时,可以通过在响应报文的头部添加Set-Cookie首部行来设置Cookie。这样客户端(通常是浏览器)会接收并存储这些Cookie,以便在后续的请求中发送回服务器。
(2)HTTP请求报文中的Cookie首部行:当客户端向服务器发送HTTP请求时,可以在请求报文的头部添加Cookie首部行,将之前存储的Cookie信息发送给服务器。这样服务器可以根据这些Cookie来识别用户、保持会话状态等。
(3)用户端系统中保留的Cookie文件:在用户端系统(通常是浏览器)中,会保存一个Cookie文件,其中包含了用户与各个网站之间的Cookie信息。浏览器会根据服务器发送的Set-Cookie首部行来管理这些Cookie,包括存储、发送和更新等操作。
(4)Web站点的后端数据库:Web站点的后端数据库通常不直接存储Cookie信息,但服务器会根据接收到的Cookie信息来处理用户请求,可能会将一些与用户相关的数据存储在后端数据库中,但这些数据通常与Cookie本身并不直接相关。
具体事例:
- Susan总是用同一个PC使用Internet Explore上网;
- 她第一次访问了一个使用了Cookie的电子商务网站;
- 当最初的HTTP请求到达服务器时,该Web站点产生一个唯一的ID,并以此作为索引在它的后端数据库中产生一个项;
- 服务器在HTTP响应中返回一个名为"Set-Cookie"的头部字段,其中包含了刚生成的唯一ID或其他相关信息;
- 浏览器收到响应后,会将这个Cookie保存在Susan的PC上;
- 随后,Susan在网站上浏览商品、添加商品到购物车、填写订单等操作;
- 这些操作通过HTTP请求发送到服务器,服务器通过Cookie中的唯一ID识别Susan,并根据数据库中存储的信息处理她的请求;
- 过Cookie,服务器能够跟踪Susan的会话状态,保持她的登录状态,管理购物车内容,并提供个性化体验;
- Susan的持续交互使得服务器不断更新后端数据库中与她相关的信息,以确保她的会话状态和数据保持同步;
Cookie在整个过程中起到关键作用,帮助服务器识别和管理Susan的会话状态,实现个性化服务和持续登录功能。
Cookies允许站点知道许多关于用户的信息,可能会导致一些隐私问题。
6. Web缓存
Web缓存(Web cache)即下图的代理服务器(proxy server)。
注意:准确的来说,代理服务器可以包含Web缓存功能,但Web缓存不仅仅是代理服务器的一部分。两者不应该是等同的关系。
目标:不访问原始服务器,就满足客户的请求
- 配置用户的浏览器,使得用户的所有HTTP请求首先指向Web缓存器;
- 浏览器创建一个到Web缓存器的TCP连接,并向其发送HTTP请求;
- 若请求对象在缓存中,缓存直接返回对象;
- 如对象不在缓存,缓存请求原始服务器,获得请求对象后,在本地存储空间存储一份副本,并向客户端的浏览器用HTTP响应报文发送该副本(通过现有的客户浏览器和Web缓存器之间的TCP连接)
注意,Web缓存器既是服务器又是客户。通常缓存是由ISP安装(大学、公司、居民区ISP)。
Web缓存的优点:
- 降低客户端的请求响应时间;
- 可以大大减少一个机构内部网络与Internent接入链路上的流量;
- 互联网大量采用了缓存:可以使较弱的ICP也能够有效提供内容;
- 相比于增加接入链路带宽,使用web缓存减少响应时间的方式更廉价;
7. 条件GET方法
高速缓存减少响应时间的同时也引入了一个问题:存放在缓存器中的副本可能是陈旧的,即原对象可能已经被更新修改了。而HTTP协议有一种机制,允许缓存器证实它的对象是最新的,这种机制就是条件GET(conditional GET)方法。
目标:如果缓存器中的对象拷贝是最新的,就不要发送对象
缓存器: 在HTTP请求中指定缓存拷贝的日期If-modified-since: <date>(该条件GET报文告诉服务器,仅当自指定日期之后该对象被修改过,才发送该对象)。
服务器: 如果对象没有修改,则响应报文没包含对象: HTTP/1.0 304 Not Modified(表示对象没有被修改,缓存器可以向请求的浏览器转发其缓存的该对象副本)。
三、FTP
FTP(File Transfer Protocol,文件传输协议)允许用户通过客户端和服务器之间的连接来传输文件,常见操作有上传、下载、创建、删除和重命名文件等。
客户端-服务器模型:FTP遵循客户端-服务器模型。客户端是发送请求的一方,而服务器则响应这些请求并提供文件服务。
- 客户端:发送请求的一方
- 服务器:响应这些请求并提供文件服务
FTP定义在RFC 959,FTP服务器端口号为21;
控制连接和数据连接:
- 客户端通过21号端口与服务器建立控制连接;
- 客户端通过控制连接发送命令(如上传、下载文件)
- 根据命令,服务器通过20号端口与客户端建立连接(注意是服务器主动建立)
- 数据连接用于传输文件内容;
- 传输完成后,数据连接关闭,但控制连接保持打开;
控制连接:带外(out of band)传送;带外传送是一种在控制连接中使用独立通道传输控制信息的机制,以确保控制信息和数据信息在传输过程中不会互相干扰。
FTP是一种有状态的协议,服务器会维护用户的状态信息:当前路径、用户账户及控制连接的对应。
FTP中的命令和响应都是以ASCII文本方式传输的。
四、Email
1. 组成
因特网电子邮件系统有三个主要组成部分:用户代理(user agent)、邮件服务器(mail server)和简单邮件传输协议(Simple Mail Transfer Protocol,SMTP)
用户代理,又名“邮件阅读器”,允许用户阅读、回复、转发、保存和撰写报文。例如微软的Outlook和Apple Mail。
邮件服务器,形成了电子邮件体系的核心,每个接收方在其中的某个邮件服务器上都有一个邮箱(mailbox),管理和维护着发给其的报文。(邮件从发送方的用户代理开始,传输到发送方的邮件服务器,再传输到接收方的邮件服务器,然后在这里被分发到接收方的邮箱中)
简单邮件传输协议(SMTP):
邮件服务器之间借助SMTP发送email报文,它定义了邮件服务器之间交换电子邮件的规则和格式。
- SMTP使用TCP在客户端和服务器之间传送报文,端口号为25;
- 其发出的命令和响应得到的状态码与状态信息都是以ASCII码的形式;
- SMTP要求报文(首部和主体)必须都是7位的ASCII编码;
- 传输的三个阶段:握手、传输报文、关闭;
- SMTP使用持久连接,一个连接上可发送多个邮件,邮件发送完才会关闭;
2. 邮件发送过程
- 邮件从发送方A的用户代理开始,传输到发送方A的邮件服务器,邮件放在报文队列中(不会立即发送,而是定时统一进行发送)
- SMPT的客户端打开到接收方B邮件服务器的TCP连接,通过TCP连接发送邮件(可以发现这里TCP的连接是由发送方的机器发起的)
- 接收方B的邮件服务器将邮件放到B的邮箱中,B调用他的用户代理来阅读邮件;
3. SMTP与HTTP的对比
- 二者都采用请求(命令)-响应模型,且都是以ASCII码的形式;
- SMTP基本上是一个推协议(push protocol),即发送邮件服务器把文件推向接收邮件服务器;HTTP主要是一个拉协议(pull protocol),即用户从服务器中拉取信息
- SMTP是面向文本的协议,用于传输电子邮件内容和元数据(描述数据的数据,如邮件的主题、大小、日期等);HTTP是面向超文本的协议,用于传输网页内容、图片、视频和其他资源;
- HTTP每个对象封装在各自的报文中,SMTP多个(邮件)对象可以包含在一个(邮件)报文中;
- SMTP是一种无状态协议,每个邮件传输都是独立的,没有保持状态;而HTTP是一种有状态协议,通过使用cookie等机制来维护客户端和服务器之间的状态;(HTTP的传输是在一条TCP连接上进行的。HTTP初始设计是无状态的,通过cookie的作用可以把它变成有状态的协议)
4. 邮件报文格式
SMTP:交换email报文的协议;
RFC 5322:规范了邮件的头部和正文的格式,包括邮件地址的表示、日期时间格式等元数据字段的使用规范。
一个典型的电子邮件报文的格式:
空白行上方是报文首部,下方是报文主体,两者由空白行隔开;
首部行和报文主体只能是ASCII码字符;
每个首部必须含有一个From:首部行和To:首部行,其余可选;
首部行不同于SMTP命令,是邮件报文自身的一部分;
5. 邮件访问协议
(1)邮件访问协议与SMTP的区别
SMTP:传送到接收方的邮件服务器(推操作)
邮件访问协议:从服务器访问邮件(拉操作)
常见的邮件访问协议:
- 第三版的邮局协议(Post Office Protocol——Version 3,POP 3)
- 因特网邮件访问协议(Internet Mail Access protocol,IMAP)
- HTTP
(2)POP3协议
POP3协议按照三个阶段进行工作:特许(authorization)、事务处理以及更新。
- 特许阶段:用户代理发送(以明文形式)用户名和口令以鉴别用户;
- 事务处理阶段:用户代理取回报文;该阶段还可以进行:对报文做删除标记、取消报文删除标记以及获取邮件的统计信息;
- 更新阶段:出现在客户发送了quit命令之后,目的是结束该POP3会话;这时,该邮件服务器删除哪些被标记为删除的报文;
在POP3处理过程中,用户代理发送一些命令,服务器对每个命令作答,回答有两种:+OK(有时还跟有服务器到客户端的数据),被服务器用来指示前面的命令是正常的;-ERR,被服务器用来指示前面的命令出现了某些差错;
常见指令:
POP3协议支持两种主要模式“下载并删除模式”和“下载并保留模式”:前者用户通过POP3从邮件服务器下载邮件后,邮件会被标记为已删除,并在会话结束后从服务器上删除;后者用户通过POP3从服务器下载邮件后,邮件不会被立即删除,而是保留在服务器上,允许用户在多个设备上访问相同的邮件,或者在需要时保留邮件的备份。
POP3在会话中是无状态的,不支持远程目录维护,只能本地管理文件;
(3)IMAP
IMAP服务器将每个报文与一个文件夹联系起来:当报文第一次到达服务器时,它与收件人的INBOX文件夹相关联。收件人则能够把邮件转移到一个新的、用户创建的文件夹中,阅读邮件、删除邮件等。
IMAP在会话过程中保留用户状态,是有状态的,能够远程管理文件夹;
五、DNS
1. DNS提供的服务
主机名(hostname):主机的一种标识方法,如www.facebook.com;
IP地址:由四个字节组成,并有着严格的层次结构。其中的每个自检都被句点分割,表示了0~255的十进制数字。
DNS(Domain Name System,DNS)的服务:
- 域名解析(主要任务),即将人类能够理解的域名转换为计算机可理解的IP地址(通常由其他应用层协议使用,如HTTP,SMTP,FTP)。此外,将一个域名解析为对应的IP地址称为正向解析,将一个IP地址解析为对应的域名称为逆向解析,这两种服务DNS均可提供。
- 负载均衡(Load Distribution),即根据服务器的负载情况将用户请求分发到不同的服务器,以确保流量分布均衡;
- 主机别名(host aliasing),一些复杂的主机名有时会有一些便于记忆的别名,在这种情况下,其原本的复杂名字也被称为规范主机名(canonical hostname)。应用程序可以调用DNS来获取主机别名的规范主机名及主机的IP地址;
- 邮件服务器别名(mail server aliasing),邮件服务器别名到正规名字的转换;
DNS是:
- 一个由分层的DNS服务器(DNS server)实现的分布式数据库;
- 一个使得主机能够查询分布式数据库的应用层协议;
- 运行在UDP之上端口为53的应用服务;
2. DNS层次结构
DNS域名结构:DNS采用层次树状结构的命名方法。Internet跟被划为几百个顶级域(top lever domains),每个(子)域下面可划分为若干子域(subdomains),树叶是主机。
根域名服务器:
- 共有13个根域名服务器,全球分布,这种分布式架构有助于提高DNS系统的稳定性;
- 根域名服务器存储了所有顶级域(TLD)服务器的地址信息(每一个根域名服务器并不存储全部顶级域服务器的地址信息,而是只存储一部分TLD服务器的地址信息)
顶级域(TLD)服务器:负责顶级域名(如com,org,net等)和所有国家级的顶级域名(如cn,uk,jp等)
权威DNS服务器:组织机构的DNS服务器,提供组织机构服务器(如Web和mail)可访问的主机和IP之间的映射。
根域名服务器、顶级域(TLD)服务器、权威DNS服务器都属于DNS的层次结构中,但有一类重要的DNS服务器,本地DNS服务器(local DNS server)。一个本地DNS服务器并不属于该服务器的层次结构,每一个ISP都有一台本地DNS服务器(也叫默认名字服务器)。当一个主机发起DNS查询时,查询被送到其本地DNS服务器,起着代理的作用,将查询转发到层次结构中。
域名(Domain Name):从本域往上,直到树根,中间使用句点间隔不同级别。域的域名可用于表示一个域,主机的域名表示一个域上的一个主机。
域名的管理:一个域管理其下的子域,例如.cn被划分为edu.cn,com.cn。创建一个新的域,必须征得它所属域的同意。
域与物理网络无关:域的划分是逻辑的,而不是物理的。域名系统中的域名与物理网络之间并没有直接的关联。域名系统提供了一种抽象的命名机制,使得用户可以通过易记的域名访问互联网资源,而物理网络则负责实际的数据传输和通信。一个域的主机可以不再一个网络,一个网络的主机不一定在一个域。
3. 域名服务器
单个域名服务器的问题:
- 单点故障:可靠性问题
- 通信容量:扩展性问题
- 远距离的集中式数据库:远距离时间延迟问题
- 维护:集中数据库难以维护
区域(zone):区域的划分由管理者自己决定,将DNS域名空间划分为互不相交的区域,每一个区域都是树的一部分。
域名服务器:每一个区域都有一个域名服务器,维护着它所管辖区域的权威信息,域名服务器允许被放置在区域之外,以保障可靠性。
4. DNS记录和报文
共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(Resource Record,RR),RR提供了主机名到IP地址的映射。
资源记录是一个包含了下列字段的四元组:(Name,Value,Type,TTL)
TTL是该记录的生存时间,它决定了资源记录应当从缓存中删除的时间;
Name和Value的值取决于Type:
5. 域名解析过程
(1)用户输入域名
当用户在浏览器中输入一个域名(如 www.example.com
),浏览器会首先检查本地缓存(如浏览器缓存或操作系统的DNS缓存)中是否有该域名对应的IP地址。
(2)本地缓存检查
如果在本地缓存中找到对应的IP地址,浏览器会直接使用该IP地址与目标服务器建立连接。如果未找到,浏览器会向操作系统的DNS解析器发送请求。
(3)查询本地域名服务器
DNS解析器会首先查询用户所在网络的本地域名服务器(通常由ISP提供),以查看是否在其缓存中存在对应的IP地址。如果找到,返回结果;如果未找到,则继续向上查询。
(4)递归查询和迭代查询
DNS查询方式分为递归查询和迭代查询两种。
递归查询:请求方只发起一次DNS查询,如果接收方查找不到对应的映射地址,则接收方将以请求者的身份发起新的DNS查询,递归地执行下去,直至遇到能够处理请求的接受方后,将域名映射结果依次返回给最初的请求方。
迭代查询:请求方发出DNS查询后,若接收方查找不到对应的映射地址,则接收方将指示请求方寻找其他接受方式获取查询结果,请求方则根据指示发送新的请求,如此反复,直到获取最终结果。
区别:
- 递归是自己调用自己,每次把问题规模缩小;迭代是自己执行很多次,每次都更接近目标。
- 递归查询下,根域名服务器的压力较大。主机向本地域名服务器查询常使用递归查询,为了减少根域名服务器的压力,域名服务器之间的查询常使用迭代查询方式。
(5)根域名服务器查询
本地域名服务器首先向根域名服务器发送查询请求。根域名服务器不保存具体的域名和IP地址的对应关系,但它知道顶级域名服务器(如 .com
、.org
)的地址,因此会返回顶级域名服务器的地址。(本地域名服务器与其他域名服务器之间通过迭代方式进行查询。)
(6)顶级域名服务器(TLD DNS)查询
本地域名服务器根据根域名服务器提供的地址,向相应的顶级域名服务器发送查询请求。TLD DNS服务器会返回该域名对应的权威DNS服务器地址。
(7)权威DNS服务器查询
最后,本地域名服务器向权威DNS服务器查询,该服务器保存着具体的域名和IP地址的对应关系。权威DNS服务器返回正确的IP地址。
(8)返回结果
本地域名服务器将IP地址返回给DNS解析器,DNS解析器将结果缓存并返回给浏览器。
(9)建立连接
浏览器使用该IP地址与目标服务器建立连接,并开始加载网站内容。
6. DNS缓存
一旦名字服务器学到了一个映射,就会将该映射缓存起来,以备下次查询。经过了TTL时间后(默认是两天),就会把缓存的映射删除。
缓存是为了提高性能与效率,删除则是为了确保数据的准确和一致性。
根服务器的IP地址通常被缓存或预配置在本地服务器(如本地域名服务器或DNS解析器)中,这意味着本地域名服务器不需要每次都去查找根服务器的地址,而是可以直接访问这些服务器来开始域名解析过程。
六、P2P应用
P2P是建立在客户/服务器模型的基础上的,它把单个服务器的负担分摊给了若干个客户节点。
1. 文件共享
(1)文件分割
在P2P文件共享系统中,大文件通常会被分割成多个小块。这些小块可以独立于彼此进行传输,增加了文件传输的并发性和效率。
(2)文件索引和查找
P2P网络中没有中央服务器来存储文件的完整列表,因此节点需要通过查询其他节点来找到文件的来源。文件的索引信息通常存储在DHT(分布式哈希表)中,或者通过洪泛机制传播。
洪泛(Flooding):是一种网络通信中的信息传播策略,尤其在分布式网络中常见。泛洪的基本原理是将数据包从一个节点发送到所有相邻节点,这些节点在接收到数据包后,再次将其转发给它们的所有相邻节点。这个过程会一直持续,直到数据包覆盖整个网络或达到某种停止条件。
(3)块传输
一旦找到某个文件的提供者,下载者可以从多个提供者处并行下载文件的不同块。这不仅加快了下载速度,也减少了对单一节点的依赖,增加了文件共享的可靠性。
(4)文件完整性验证
文件下载完成后,每个块的哈希值通常会被校验,以确保文件传输过程中没有出现错误或被恶意篡改。完整性验证在下载过程中也可能实时进行,以防止无效或损坏的块传输。
(5)上传和下载平衡
P2P文件共享网络通常鼓励节点上传与下载的平衡。某些系统通过信用机制或速率限制,来鼓励节点积极分享文件,否则可能会限制其下载速度。
2. C/S模型与P2P模型两种模型下文件分发速度的比较
C/S模型
发送一个拷贝文件用时:
下载带宽最小的客户端的下载时间:
则,将一个F大小的文件分发给N个客户端耗时:
可以看到随着N线性增长。
P2P模型
服务器至少需要上载一份完整地拷贝文件
发送一个拷贝的时间:
每个客户端必修下载一个拷贝
下载带宽最小的客户端的下载时间:
因为除了服务器外,其他所有的peer节点也都可以上载,所以
最大上载带宽是:
将一个F大小的文件分发给N个客户端耗时:
可以看到分子随着N线性变化,但是每个peer也带了服务能力,随着peer节点的增多,分母也在变大。
分发文件耗时D随N的变化曲线:
3. C/S模型与P2P模型的区别
网络模型 | C/S模型 | P2P模型 |
基本概念 | 存在特定的服务器以及与服务器相连的客户端 | 不区分客户端和服务器,每个节点既可充当客户端又可充当服务器 |
网络类型 | 集中式网络 | 分散式网络 |
可靠性 | 客户端依赖于服务器,服务器故障将影响到所有客户端的功能 | 存在多个提供服务的完整节点,一部分节点失效后剩余节点仍可形成完整网络,更可靠 |
服务访问时间 | 多个客户端从一个服务器请求服务,所以服务访问时间长 | 服务提供节点分布在网络中,所以请求节点不需要等待较长的时间 |
费用 | 实施成本很高 | 不需要大量的硬件来建立网络 |
安全性 | 相对来说更安全 | 相对来说不稳定 |
数据存储 | 数据存储在一个服务器中 | 每个节点保留自己的数据 |
可扩展性 | 服务器能支持的客户端数量有限,扩展性不佳 | 无传统服务器连接带宽的限制,可支持较多的客户端连接,扩展性较好 |
应用场景 | 万维网、文件传输FTP、电子邮件等 | P2P文件共享、即时通信、加密货币等 |