【计算机网络——应用层】

程序员清羽

已于 2023-12-22 09:44:10 修改

阅读量805

点赞数 1

分类专栏：计算机网络文章标签：网络服务器

于 2022-08-08 23:54:07 首次发布

本文链接：https://blog.csdn.net/l396465/article/details/126228323

版权

计算机网络专栏收录该内容

3 篇文章 0 订阅

订阅专栏

1、应用层协议原理

应用层协议的实现，只需要写出能够运行在不同的端系统（服务器、手机、电脑等）和通过网络彼此通信的程序。因为网络核心设备（路由器、交换机等，不包括端系统设备）并不在应用层上起作用，只在网络层及下面层次起作用，所以不需要为网络核心设备写对应的应用程序，即开发应用程序的时候只需要考虑适配端系统，不需要考虑网络核心设备。

1.1、网络应用程序体系结构

客户-服务器体系结构（client-server architecture）：在客户-服务器体系结构中，有一个总是打开的主机被称为服务器，它服务来自其他许多称为客户的主机的请求。web应用程序就是一个典型的例子，他总是有至少一个web服务器在运行来响应浏览器的请求。客户-服务器体系结构的一个特征就是服务器具有固定且被知晓的IP地址。
对等体系结构（P2P）：P2P体系结构对位于数据中心的专用服务器有最小的（或者没有）依赖。应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。这些对等方并不为服务提供商所有，为用户控制的台式机、笔记本等所有。因为这种对等方通信不必通过专门的服务器，该体系被称为对等方到对等方。

1.2、进程通讯

在操作系统中，进行通信的实际上是进程而不是程序。
一个进程可以被认为是运行在端系统中的一个程序。
两个不同端系统上的进程，通过跨越计算机网络交换报文而相互通信。
发送进程生成并向网络中发送报文；
接收进程接收这些报文并可能通过报文发送回去进行响应。

1.2.1、客户与服务器进程

在给定的一对进程之间的通信回话场景中：

发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，
在会话开始时等待联系的进程是服务器。

1.2.2、进程与计算机网络直接的接口

进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。
套接字是同一台主机内应用层与运输层之间的接口，在发送端的应用程序将报文推进套接字，
在该套接字的另一侧，运输层协议负责是该报文进入接收进程的套接字。
由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface， API）。
应用程序开发者可以控制套接字在应用层的一切，但对改套接字的运输层端几乎没有控制权。

开发者对运输层的控制仅限于：

选择运输层协议；
也许能设定几个运输层参数，如最大缓存和最大报文段长度等。

一旦开发者选择了一个运输层协议，则应用程序就建立在由该协议提供的运输层服务上。

1.2.3、进程寻址

在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。
为了标识改接收进程，需要定义两种信息：

①主机的地址；

②定义在目的主机中的接收进程的标识符。

在因特网中，主机由其IP地址（IP address）标识。
IP地址是一个32比特的量且能够唯一地标识主机。
因为一台主机能够运行多个网络应用，发送报文时，发送进程除了要知道目的地的主机地址外，还需要指定运行在接收主机上的接收进程（接收套接字）。
目前比较流行的端口有：Web服务器的80端口、SMTP的25端口等。

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

从四个方面对应用程序的运输程服务协议要求进行分类：可靠数据传输、吞吐量、定时、安全性。

1.3.1、可靠数据传输

由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。当运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。

1.3.2、吞吐量

　　在沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付的比特速率。因为其他会话将共享沿着该网络路径的带宽，并且因为这些会话将会到达和离开，该可用吞吐量将随时间波动。这就要求运输层协议能够以某种特定的速率提供确保的可用吞吐量，及吞吐量服务。使用这种服务，该应用程序能够请求r比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是至少为r比特/秒。

1.3.3、定时

　　运输层协议能提供定时保证，如发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。这种服务队交互式实时应用程序具有很大的吸引力，如网络电话、网络交互游戏等，这些应用为了有效性而要求数据交付有严格的时间限制。

1.3.4、安全性

　　运输协议能够为应用程序提供一种或多种安全性服务。例如，在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在数据交付给接收进程之前解密这些数据。运输协议还能提供机密性以外的其他安全性服务，包括数据完整性和端点鉴别。

1.4、因特网提供的运输服务

因特网（更一般的是TCP/IP网络）为应用程序提供两个运UDP和TCP。当为因特网创建一个新的应用时，受限要做出的决定是选择UDP还是TCP。每个协议为调用它们的应用程序提供了不同的服务集合。

应用	数据丢失	带宽	时间敏感
文件传输	不能丢失	弹性	不
电子邮件	不能丢失	弹性	不
Web文档	不能丢失	单行（几kbps）	不
因特网电话/视频会议	容忍丢失	音频（几kbps~1Mbps）视频（10kbps~5Mbps）	是，100ms
存储音频/视频	容忍丢失	音频（几kbps~1Mbps）视频（10kbps~5Mbps）	是，几秒
交互式游戏	容忍丢失	几kbps~10kbps	是，100ms
智能手机讯息	不能丢失	弹性	是和不是

1.4.1、TCP服务

　　TCP服务模型包括面向连接服务和可靠数据传输服务。当某个应用程序调用TCP作为运输协议时，该应用程序就能获得来自TCP的两种服务。

面向连接的服务：在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提示客户和服务器，让它们为大量分组的到来做好准备。在握手阶段后，一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文的收发。当应用程序结束报文发送时，必须拆除该连接。
可靠的数据传送服务：通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。

　　TCP协议还具有拥塞控制机制，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程（客户或服务器）。

1.4.2、UDP服务

UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。
UDP是无连接的，因此在两个进程通信前没有握手过程。
UDP协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。不仅如此，达到接收进程的报文也可能是乱序到达的。
UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。

1.5、应用层协议定义

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

交换的报文类型，例如请求报文和响应报文。
各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。
字段的语义，即这些字段中包含的信息的含义。
一个进程何时以及如何发送报文，对报文进行响应的规则。

2、Web和HTTP

2.1、HTTP概况

Web的应用层协议是超文本传输协议（HTTP），它是Web的核心。
HTTP由客户端程序和服务端程序实现。
HTTP协议定义了Web服务器请求Web页面的方式，以及服务器向客户端传输Web页面的方式，其交互过程中通过请求和相应的方式来进行。
服务器通过HTTP报文请求向服务端请求页面中所包含的对象，服务端在接收到HTTP报文之后通过响应报文对客户端请求的对象进行响应。

2.2、持续连接和非持续连接

非连续连接：每个TCP连接在服务器发送一个对象后关闭。

持续连接：服务器在发送响应后保持该TCP连接打开。

2.3、HTTP报文格式

2.3.1、请求报文

典型的请求报文：

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
 
(data)

报文的第一行为请求行，有3个字段：方法字段，URL字段，HTTP版本字段。

方法字段可以取几种不同的值，有GET、POST、HEAD、PUT、DELETE等。URL字段即为请求对象对应的url路径，HTTP版本字段即为当前HTTP版本

后续的部分为首部行：

Host字段为对象所在的主机的IP地址 Connection为close表示关闭持续连接，User-agent指明了用户代理，即向服务器发送请求的浏览器类型，Accept-language是支持的语言版本

空行是实体体：

这部分主要用来存储用户提交上来的数据。这里因为是GET请求，请求的相关数据已经写在了url路径中，所以实体体里并没有相关数据。如果是POST请求，那么POST请求提交上来的数据将存在实体体中。

2.3.2、HTTP响应报文

报文的响应：

HTTP/1.1 200 OK
Connection:close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
 
(data....)

它有三个部分：一个初始状态行，6个首部行，然后是实体体。

Connection表示发送报文后将关闭持续连接，
Date为服务器产生并发送响应报文的日期和时间，
Server指示发送报文的服务器的类型，
Last-Modified为对象创建或最后修改的日期和时间，
Content-Length为被发送对象的字节数，
Content-Type为实体体中对象的类型。

2.4、用户与服务器的交互：cookie

Cookie是某些网站为了辨别用户身份，进行 Session 跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。
Cookie是由服务端生成的，发送给客户端（通常是浏览器）的。
Cookie总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie：
内存Cookie由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。
硬盘Cookie保存在硬盘里，有一个过期时间，除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。
按存在时间，可分为非持久Cookie和持久Cookie。

2.5、Web缓存

Web缓存器也叫代理服务器，它能够代表初始Web服务器来满足HTTP请求的网络实体。一旦配置了缓存，则对某对象的请求将先被定为到该Web缓存器，若Web缓存器中有相应的对象，则直接返回，无需与服务器建立连接；若没有，再与服务器建立连接进行请求和相应，此时，服务器在响应客户端请求的同时，会将相应的数据存入缓存中。

Web缓存的应用大大提高了Web资源请求的效率。但也引入了一个新的问题，放在缓存中的对象很可能是过期的，即在对象放入缓存之后，服务器更新了对象，但缓存中的对象并不会被服务器更新。这样我们获取到的资源就可能是过期的。

幸运的是，HTTP 协议有一种机制，允许缓存器证实它的对象是最新的。这种机制就是条件GET(conditional GET)方法。如果:①请求报文使用GET方法;并且②请求报文中包含一个“If- Modified-Since:”首部行。那么，这个 HTTP 请求报文就是一个条件GET 请求报文。

3、因特网中的电子邮件

电子邮件是一种异步通信媒介。
现代电子邮件报文包含附件、超链接、HTML格式文本和图片。
电子邮件系统通常包括：用户代理、邮件服务器、简单邮件传输协议SMTP。
用户代理允许用户阅读、回复、转发、保存、撰写报文
邮件发送到邮件服务器，被放在发送报文队列中。
邮件服务器是电子邮件体系结构的核心，每个接收方在其中的某个服务器上有一个邮箱，邮箱管理和维护发送给用户的报文。
典型过程为：发送方的用户代理发送邮件到发送方的邮件服务器，再传输到接收方的邮件服务器，最后被分发到接收方的邮箱中。
如果发送失败，邮件服务器在报文队列中保持该报文并以后尝试再次发送。
SMTP是应用层协议，使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。
SMTP分别运行在发送方邮件服务器的客户机端和接收方邮件服务器的服务器端

3.1、SMTP

SMTP是一种提供可靠且有效的电子邮件传输的协议。
SMTP是建立在FTP文件传输服务上的一种邮件服务，主要用于系统之间的邮件信息传递，并提供有关来信的通知。
SMTP独立于特定的传输子系统，且只需要可靠有序的数据流信道支持。
SMTP的重要特性之一是其能跨越网络传输邮件，即“SMTP邮件中继”。。

3.2、与HTTP的对比

相同：当进行文件传送时，持久HTTP和SMTP都使用持久连接。

不同：①、HTTP是一个拉协议，即人们可以在方便的时候装载web服务器上的信息，即用户使用HTTP从服务器拉取信息，TCP连接是由想获取文件的机器发起的。SMTP是一个推协议，即发送邮件服务器把文件推向接收邮件服务器，TCP连接是由要发送文件的机器发起的。

②、SMTP要求每个报文（包括主体）都使用7位ASCII码格式，如果包含了非7位的ASCII码字符（如有重音的发文字符或二进制数据的图形文件）必须按照7位ASCII码进行编码，HTTP没有这个限制。

③、在面对一个既包含文本又包含图形的文档时，HTTP把每个对象封装到他的HTTP响应报文中（一对一），而internet电子邮件把所有报文对象放在一个报文中④、HTTP使用带内控制，FTP使用带外控制

3.3、邮件报文格式

每个首部必须包含一个from首部行和一个to首部行。
可以包含一个subject首部行或者其他可选的首部行。
报文首部之后有一个空行，然后接报文主体。

3.4、邮件访问协议

用户代理主动向邮件服务器拉取邮件，有HTTP、第三版的邮局协议POP、因特网邮件访问协议IMAP。
邮件客户端需要配两个协议，SMTP负责发送，POP3负责接收

3.4.1、POP3

POP3是一个非常简单的邮件访问协议，有RFC 1939进行了定义。按照三个阶段进行工作：

特许：用户代理发送（以明文形式）用户名和口令以鉴别用户
事务处理：用户代理取回报文，还可以对报文做删除标记、取消删除标记、以及获取邮件的统计信息。
更新：在客户机发出了quit命令之后，结束该POP3会话。这个时候可以删除那些被标记为删除的报文。

POP3支持下载并保存的方式。
POP3服务器保留了一些状态信息，并记录哪些用户报文被标记为删除。

3.4.2、IMAP

POP3可以将邮件下载在本地主机，但无法使用一个远程服务器上的层次文件夹。无法从任一台机器对所有报文进行访问。但IMAP可以，可以让用户远程操控。

所有消息维持在服务器上，协议支持用户可直接在服务器上操作。
IMAP协议为用户提供了创建文件夹以及在文件夹之间移动邮件的命令。
IMAP允许用户代理获取报文组件的命令。

3.4.3、基于web的电子邮件（HTTP）

以web的方式获取邮件。
用户代理就是普通的浏览器，用户和远程邮箱之间的通信通过HTTP进行。
电子邮件报文通过HTTP从邮件服务器发送到浏览器，同时，发送邮件时通过HTTP从浏览器发送到邮件服务器，而不，但由于主机名可能由不定长的字母数字组成，路由器很难处理，由此主机也可以使用所谓的IP地址进行识别。

4、DNS：因特网的目录服务

DNS（Domain Name System，域名系统），因特网上作为域名和IP地址互相映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。DNS协议运行在UDP上，使用53号端口。

4.1、DNS提供的服务

与http，FTP，SMTP协议一样，DNS协议是应用层协议，其原因在于：

使用客户-服务器模式运行在通信的端系统之间；
在通信的端系统之间通过下面的端到段运输协议来传送DNS报文。

DNS的一些重要服务：

主机别名：有复杂主机名的主机可以拥有一个或者多个别名，这种情况下真实的复杂主机名称为规范主机名。主机别名比主机规范名更容易记忆，应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址。
邮件服务器别名：邮箱地址可能也有别名，由此电子邮件应用程序可以调用DNS，对提供的邮件服务器别名进行解析，以获得该主机的规范主机名和IP地址。实际上MX记录允许一个公司的邮件服务器和web服务器使用相同的别名。
负载分配：繁忙的站点被冗余分配在多台服务器上，每台服务器运行在不同的端系统上，有着不同的IP地址，而IP地址集合对应于同一个规范主机名。DNS通过旋转这些IP地址在集合中的顺序，调整web服务器的负载分配。DNS的旋转同样可以用于邮件服务器，由此，多个邮件服务器可以具有相同的别名。

工作过程：

4.2、DNS工作原理

DNS的一种简单设计方式是在因特网上使用一个DNS服务器，该服务器包含所有的映射。客户机直接将所有查询直接发往单一的DNS服务器，该DNS服务器直接对所有的查询客户机作出相应。但这种集中式设计有以下问题：

单点故障：DNS服务器崩溃导致整个因特网崩溃。
通信容量：单个DNS服务器不得不处理所有的DNS查询。
远距离的集中式数据库：严重的时延
维护：为所有的因特网主机保留记录，需要频繁更新。

总的来说，完全没有可拓展能力，因此，DNS采用了分布式的设计方案。

4.2.1、分布式、层次数据库

根DNS服务器：因特网上有13个根DNS服务器，是冗余的服务器集群，以提供安全性和可靠性，互相镜像备份，可能有时间差。
顶级域（TLD）服务器：这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。收到DNS查询请求时,就给出相应的回答。
权威DNS服务器：在因特网上具有公共课访问主机的每个权威机构必须提供公共可访问的DNS记录，将主机名映射为IP地址，由组织机构的权威DNS服务器负责保存这些DNS记录。

本地域名服务器：本地域名服务器对域名系统非常重要。每个因特网服务提供者(ISP)，或一所大学，甚至一所大学中的各个系，都可以拥有一个本地域名服务器。当一台主机发出DNS查询请求时，这个查询请求报文就发送给该主机的本地域名服务器。

主机向本地域名服务器的查询采用的是递归查询
本地域名服务器向根域名服务器的查询采用迭代查询

4.2.2、DNS缓存

在请求链中，当一个DNS服务器接收到一个DNS回答时，DNS服务器能将回答中的信息缓存在本地存储器。这个缓存包含在回答中的任何信息，包括主机名/地址对。因为主机和主机名与IP地址间的映射不是永久地，所以DNS服务器在一段时间后（通常为两天）将丢弃缓存的信息。
本地DNS服务器也可以缓存TLD服务器的IP地址（不仅仅是权威服务器的IP地址）。因此允许本地DNS绕过查询链中的根DNS服务器。