在客户-服务器体系结构（client- server architecture）中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。值得注意的是利用客户-服务器体系结构,客户相互之间不直接通信。客户-服务器体系结构的另一个特征是该服务器具有固定的、周知的地址，该地址称为IP地址。因为该服务器具有固定的、周知的地址，并且因为该服务器总是打开的，客户总是能够通过向该服务器的IP地址发送分组来与其联系。具有客户-服务器体系结构的非常著名的应用程序包括Web,FTP以及电子邮件。

在一个客户-服务器应用中，常常会出现一台单独的服务器主机跟不上它所有客户请求的情况。为此，配备大量主机的数据中心(data center)常被用于创建强大的虚拟服务器。一个数据中心能够有数十万台服务器，它们必须要供电和维护。此外，服务提供商必须支付不断出现的互联和带宽费用，以发送和接收到达/来自数据中心的数据。

1.2 P2P体系结构：

在一个P2P体系结构(P2P architecture)中,对位于数据中心的专用服务器有最小的(或者没有)依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。许多目前流行的、流量密集型应用都是P2P体系结构的。这些应用包括文件共享（例如BitTorrent)、对等方协助下载加速器（例如迅雷)、因特网电话和视频会议（例如 Skype)。P2P体系结构的最引人入胜的特性之一是它们的自扩展性（ self- scalability )。

2.进程通信：

2.1基本了解：

对运行在多个端系统上的程序之间的通信，用操作系统的术语来说，进行通信的实际上是进程（ process）而不是程序。在两个不同端系统上的进程，通过跨越计算机网络交换报文而相互通信。

2.2客户-服务器进程：

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

2.3进程与计算机网络之间的接口：

进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文。当一个进程想向位于另外一台主机上的另一个进程发送报文时，它把报文推出该门（套接字)。该发送进程假定该门到另外一侧之间有运输的基础设施，该设施将把报文传送到目的进程的门口。一旦该报文抵达目的主机，它通过接收进程的门（套接字）传递，然后接收进程对该报文进行处理。

套接字还可作为建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（API)。

2.4进程寻址：

在因特网中,主机由其IP地址标识。找到主机号后，还应找到对应的进程号，目的地端口号用于这个目的。

3.因特网提供的运输服务（TCP和UDP）：

这块就不详细展开了，有关TCP和UDP的详情可以参考另一篇文章https://blog.csdn.net/weixin_57133901/article/details/124359284?spm=1001.2014.3001.5502

这块谈谈TCP的安全性，我们知道TCP一直被誉为可靠的连接方式，那他的安全性如何？

无论TCP还是UDP都没有提供任何加密机制，这就是说发送进程传进其套接字的数据，与经网络传送到目的进程的数据相同。因特网界已经研制了TCP的加强版本，称为安全套接字层(Secure Sockets Layer,SSL)。用SSL加强后的TCP不仅能够做传统的TCP所能做的一切，而且提供了关键的进程到进程的安全性服务，包括加密、数据完整性和端点鉴别。我们强调SSL不是与 TCP和UDP在相同层次上的第三种因特网运输协议，而是一种对TCP的加强，这种强化是在应用层上实现的。

4.应用层协议：

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

流行的因特网应用及其应用层协议和支撑的运输协议：

因为因特网电话应用通常能够容忍某些丢失但要求达到一定的最小速率才能有效工作，所以因特网电话应用的开发者通常愿意将该应用运行在UDP上，从而设法避开TCP 的拥塞控制机制和分组开销。但因为许多防火墙被配置成阻挡（大多数类型的）UDP流量，所以因特网电话应用通常设计成如果UDP通信失败就使用TCP作为备份。

二、web和http：

1.基本了解：

web（万维网）：Web是一个引起公众注意的因特网应用，它极大地改变了人们与工作环境内外交流的方式。它将因特网从只是很多数据网之一的地位提升为仅有的一个数据网。web的最具有吸引力的地方就是按需操作：当用户需要时，就能得到想要的操作。

http：Web的应用层协议是超文本传输协议（即http，它是web的核心）。HTTP由两个程序实现:一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。

一些web术语：

Web页面（Web page)(也叫文档)是由对象组成的。一个对象（object）只是一个文件，诸如一个HTML文件、一个JPEG图形、一个Java小程序或一个视频片段这样的文件且它们可通过一个URL地址寻址。

URL地址：统一资源定位符 (URL)也被称为网页地址，是因特网上标准的资源的地址。每个 URL地址由两部分组成:存放对象的服务器主机名和对象的路径名。例如，URL地址 http://www. someSchool. edu/someDepartment/picture,gif，其中的www. someSchool. edu就是主机名，/someDepartment/ picture. gif 就是路径名。

web浏览器和web服务器：因为Web浏览器实现了HTTP的客户端，所以在Web环境中我们经常交替使用“浏览器”和“客户”这两个术语。Web服务器实现了HTTP 的服务器端，它用于存储Web对象，每个对象由URL寻址。

2.http和https：

HTTP使用TCP作为它的支撑运输协议（而不是在UDP上运行)。HTTP客户首先发起一个与服务器的TCP连接。一旦连接建立,该浏览器和服务器进程就可以通过套接字接口访问 TCP。

客户向它的套接字接口发送HTTP请求报文，并从它的套接字接口接收HTTP响应报文；接口接收 HTTP请求报文和向它的套接字接口发送 HTTP响应报文。一旦客户向它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进入TCP的控制，体现出分层体系。这里我们看到了分层体系结构最大的优点，即 HTTP协议不用担心数据丢失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。那是TCP以及协议栈较低层协议的工作。

http是一个无状态协议：因为HTTP服务器并不保存关于客户的任何信息。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。假如某个特定的客户在短短的几秒内两次请求同一个对象,服务器并不会因为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。

cookie和session：为了解决http的无状态。

cookie：

cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端会把Cookie保存起来。

当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

session：

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。每个用户访问服务器都会建立一个session并自动分配一个SessionId，用于标识用户的唯一身份。

这块就简单提到这两个的概念，详情可以参考：https://www.cnblogs.com/ibigboy/p/11573533.html

https：HTTPS是基于HTTP+SSL/TSL来实现的

HTTP 主要有这些不足：

通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装
无法证明报文的完整性，所以有可能已遭篡改

HTTPS是基于HTTP+SSL/TSL来实现的，发送的数据需要加密，接收到的数据需要解密，比HTTP安全，但是传输效率比HTTP低。

通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。

3.持续连接和非持续连接：

当客户-服务器的交互是经TCP进行的，应用程序的研制者就需要做一个重要决定，即每个请求/响应对是经一个单独的TCP连接发送，还是所有的请求及其响应经相同的TCP连接发送呢?采用前一种方法，该应用程序被称为使用非持续连接，采用后一种方法，该应用程序被称为使用持续连接。

非持续连接有一些缺点：第一，必须为每一个请求的对象建立和维护一个全新的连接。

第二，每一个对象经受两倍RTT的交付时延.即一个RTT用于创建 TCP，另一个RTT用于请求和接收一个对象。

往返时间(Round-Trip Time,RTT)的定义：该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。

4.http报文格式：

4.1请求报文：

一个经典的请求报文：

HTTP请求报文的第一行叫作请求行，其后继的行叫作首部行。

请求行有3个字段:方法字段、URL字段和HTTP 版本字段。

首部行：

首部行Host: www. someschool.edu指明了对象所在的主机。

Connection: close首部行，该浏览器告诉服务器不要麻烦地使用持续连接，它要求服务器在发送完被请求的对象后就关闭这条连接。

User-agent:首部行用来指明用户代理,即向服务器发送请求的浏览器的类型。这里浏览器类型是 Mozilla/5.0，即 Firefox浏览器。

Accept-language:首部行表示用户想得到该对象的法语版本（如果服务器中有这样的对象的话);否则，服务器应当发送它的默认版本。Accept-language:首部行仅是HTTP中可用的众多内容协商首部之一。

4.2http的响应报文：

下边该报文是对上边请求报文的响应。

我们仔细看一下这个响应报文。它有三个部分:一个初始状态行，6个首部行，然后是实体体。

状态行：状态行有3个字段:协议版本字段、状态码和相应状态信息。在这个例子中，状态行指示服务器正在使用HTTP/1.1，并且一切正常（即服务器已经找到并正在发送所请求的对象)。

首部行：

Connection:close首部行告诉客户，发送完报文后将关闭该TCP 连接。

Date:首部行指示服务器产生并发送该响应报文的日期和时间。值得一提的是，这个时间不是指对象创建或者最后修改的时间，而是服务器从它的文件系统中检索到该对象，将该对象插入响应报文，并发送该响应报文的时间。

Server:首部行指示该报文是由一台Apache Web服务器产生的，它类似于HTTP请求报文中的User-agent:首部行。

Last-Modified:首部行指示了对象创建或者最后修改的日期和时间。

Content-Length:首部行指示了被发送对象中的字节数。

Content-Type:首部行指示了实体体中的对象是HTML文本。

实体体：包含了所请求的对象本身（表示为 data data data data data……)。

一些常见的状态码：

200 OK:请求成功,信息在返回的响应报文中。
301 Moved Permanently :请求的对象已经被永久转移了，新的URL定义在响应报文的Location:首部行中。客户软件将自动获取新的URL。
400 Bad Request:一个通用差错代码，指示该请求不能被服务器理解。
404 Not Found:被请求的文档不在服务器上。
505 HTTP Version Not Supported:服务器不支持请求报文使用的 HTTP协议版本。

三、因特网中的电子邮件：

电子邮件系统由三部分组成：用户代理、邮件服务器和简单邮件传输协议（SMTP）。

用户代理：邮件的发送方和接收方都可看做是用户代理。
邮件服务系统：邮件服务器形成了电子邮件体系结构的核心。每个接收方在其中的某个邮件服务器上有一个邮箱( mailbox )。用于管理发送和接受的邮件。
简单邮件传输协议：邮件发送和接收过程所受到的一些约束和规范。

1.SMTP：

SMTP是因特网电子邮件中主要的应用层协议。它使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。像大多数应用层协议一样，SMTP也有两个部分:运行在发送方邮件服务器的客户端和运行在接收方邮件服务器的服务器端。

1.1 SMTP发送报文的过程：

例如Alice要发送一条邮件给BOb：

Alice调用她的邮件代理程序并提供Bob的邮件地址（例如 [email protected]），撰写报文，然后指示用户代理发送该报文。

Alice的用户代理把报文发给她的邮件服务器，在那里该报文被放在报文队列中。

运行在Alice的邮件服务器上的SMTP客户端发现了报文队列中的这个报文，它就创建一个到运行在Bob的邮件服务器上的SMTP 服务器的TCP连接。

在经过一些初始SMTP握手后，SMTP 客户通过该TCP连接发送Alice的报文。

在Bob的邮件服务器上，SMTP的服务器端接收该报文。Bob的邮件服务器然后将该报文放入Bob的邮箱中。

在 Bob方便的时候,他调用用户代理阅读该报文。

SMTP一般不使用中间邮件服务器发送邮件相连。如果Bob的邮件服务器没有开机，该报文会保留在Alice 的邮件服务器上并等待进行新的尝试，这意味着邮件并不在中间的某个邮件服务器存留。

1.2发送方邮件服务器到接收方邮件服务器的发送过程：

首先，客户SMTP(运行在发送邮件服务器主机上）在25号端口（假设端口）建立一个到服务器SMTP（运行在接收邮件服务器主机上)的TCP连接。
如果服务器没有开机，客户会在稍后继续尝试连接。一旦连接建立，服务器和客户执行某些应用层的握手，就像人们在互相交流前先进行自我介绍一样。SMTP的客户和服务器在传输信息前先相互介绍。
在SMTP握手的阶段，SMTP客户指示发送方的邮件地址（产生报文的那个人)和接收方的邮件地址。一旦该SMTP客户和服务器彼此介绍之后，客户发送该报文。
SMTP能依赖TCP提供的可靠数据传输无差错地将邮件投递到接收服务器。该客户如果有另外的报文要发送到该服务器，就在该相同的TCP连接上重复这种处理;否则,它指示 TCP关闭连接。

2.与http的对比：

2.1相同点：

两个协议都用于一个主机给两一个主机发送文件，在文件传送时，持续的http和SMTP都使用持续连接。

2.2不同点：

http是拉协议，从服务器上拉取数据，TCP连接是由想接收文件的机器发起的；SMTP是推协议，即发送邮件服务器把文件推向接收邮件服务器。这个 TCP连接是由要发送该文件的机器发起的。

SMTP要求每个报文采用7比特ASII码格式；HTTP数据不受这种限制。

如何处理一个及包含文本又包含图形的文档？HTTP把每个对象封装到他自己的HTTP响应报文中；SMTP把所有报文对象放在一个报文中。

3.邮件报文格式：

每个首部必须含有一个 From:首部行和一个To:首部行;一个首部也许包含一个Subject:首部行以及其他可选的首部行。

例如：

4.邮件访问协议：

4.1 为什么需要？

由上文SMTP发送报文的过程我们可以知道我们通过邮件服务器来接收报文。那此时就存在一个bug，那就是如果邮件服务器是运行在我们PC机上时，我们不能保证该邮件服务器一直开机，那岂不是一直接收不到报文？针对这种情况，就有一种典型的解决方法，用户通常在本地PC上运行一个用户代理程序，而它访问存储在总是保持开机的共享邮件服务器上的邮箱。该邮件服务器与其他用户共享，并且通常由用户的ISP进行维护。

此时，还会存在一个难题，那就是如何让PC机可以拉取邮件服务器中的报文。因为SMTP是推协议，只负责把报文推入邮件服务器，而取报文是一个拉操作，那么如何进行这个操作？目前有一些流行的邮件访问协议，包括第三版的邮局协议（PostOffice Protocol—Version 3，POP3)、因特网邮件访问协议（Internet Mail Access Protocol,IMAP) 以及 HTTP。

4.2 POP3：

POP3是一个极为简单的邮件访问协议，因为该协议非常简单,故其功能相当有限。当用户代理（客户）打开了一个到邮件服务器（服务器）端口110上的TCP连接后，POP3就开始工作了。

POP3按照三个阶段进行工作:特许（(authorization)、事务处理以及更新。

在第一个阶段即特许阶段，用户代理发送（以明文形式)用户名和口令以鉴别用户。

在第二个阶段即事务处理阶段，用户代理取回报文;同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。

在第三个阶段即更新阶段，它出现在客户发出了quit命令之后，目的是结束该POP3会话;这时，该邮件服务器删除那些被标记为删除的报文。

4.3 IMAP：

使用POP3时，只能把邮件下载到主机后建立文件夹，而不能直接在远程服务器上建立文件夹。因为POP3协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法。

IMAP应运而生，它解决了POP3的不足之处：

IMAP服务器把每个报文与一个文件夹联系起来;当报文第一次到达服务器时，它与收件人的 INBOX文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。

IMAP协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。

IMAP 还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件。

值得注意的是，与POP3不同，IMAP服务器维护了IMAP会话的用户状态信息，例如，文件夹的名字以及哪些报文与哪些文件夹相关联。

4.4 基于webde电子邮件：

Web的电子邮件：用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过HTTP进行。然而，邮件服务器在与其他的邮件服务器之间发送和接收邮件时，仍然使用的是SMTP。

四、DNS：因特网的目录系统：

在人类世界里，每个人都会有标识，我们可以通过标识来识别一个人，比如，我们可以通过身份证号来识别一个人。那在计算机网络中，我们如何来识别他的一个个体——主机？主机的一种识别方式是使用它的主机名。如www.facebook.com、www.google.com等等。但是这些主机名几乎没有提供任何关于主机在因特网中的位置信息。主机使用了一种可以提供位置信息的标识方式——IP地址。

1.DNS提供的服务：

前面我们提到IP地址的来源，那么我们就还需要一种能使主机名和IP地址转换的服务。DNS（域名系统）：主机名到IP地址转换的目录服务，还有一点，DNS运行在UDP上。

DNS:通过客户-服务器模式提供的重要网络功能

与HTTP、FTP 和SMTP 协议一样，DNS 协议是应用层协议，其原因在于:①使用客户-服务器模式运行在通信的端系统之间;②在通信的端系统之间通过下面的端到端运输协议来传送DNS报文。

DNS通常是由其他应用层协议所使用的，包括HTTP、SMTP 和FTP，将用户提供的主机名解析为P地址。举一个例子，考虑运行在某用户主机上的一个浏览器（即一个HTTP客户）请求 URL www. someschool. edu/index.html页面时会发生什么现象。为了使用户的主机能够将一个HTTP请求报文发送到Web服务器www. someschool. edu，该用户主机必须获得www. someschool.edu的地址。其做法如下：

同一台用户主机上运行着 DNS应用的客户端。

浏览器从上述URL中抽取出主机名www. someschool. edu，并将这台主机名传给DNS应用的客户端。

DNS客户向 DNS服务器发送一个包含主机名的请求。

DNS客户最终会收到一份回答报文，其中含有对应于该主机名的IP地址。

一旦浏览器接收到来自DNS的该IP地址，它能够向位于该IP地址80端口的HTTP服务器进程发起一个TCP连接。

除此之外，DNS还提供一些其他服务：

主机别名：有着复杂主机名的主机能拥有一个或者多个别名。会存在一个规范主机名和一些别名，主机别名比规范主机名更容易记忆。
邮件服务器别名：和主机别名一样，人们也希望电子邮件地址好记忆。
负载分配：DNS也用于在冗余的服务器之间进行负载分配。繁忙的站点被冗余分布在多台服务器上,每台服务器均运行在不同的端系统上，每个都有着不同的P地址。

2.DNS的工作机理：

假设运行在用户主机上的某些应用程序（如Web浏览器或邮件阅读器）需要将主机名转换为IP地址：

这些应用程序将调用DNS的客户端，并指明需要被转换的主机名。
用户主机上的DNS接收到后，向网络中发送一个DNS查询报文。所有的DNS请求和回答报文使用UDP数据报经端口53发送。
经过若干毫秒到若干秒的时延后，用户主机上的DNS接收到一个提供所希望映射的DNS回答报文。这个映射结果则被传递到调用DNS的应用程序。

2.1DNS的两种设计方式：

1.集中式：DNS的一种简单设计是在因特网上只使用一个 DNS服务器，该服务器包含所有的映射。在这种集中式设计中，客户直接将所有查询直接发往单一的 DNS 服务器，同时该DNS服务器直接对所有的杳询客户做出响应。尽管这种设计的简单性非常具有吸引力，但它不适用于当今的因特网，因为因特网有着数量巨大（并持续增长）的主机。

2.分布式：为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。没有一台DNS服务器拥有因特网上所有主机的映射。相反,这些映射分布在所有的 DNS服务器上。大致说来，有3种类型的 DNS服务器:根 DNS服务器、顶级域(Top- Level Domain，TLD)DNS服务器和权威DNS服务器。

部分DNS服务器层次结构如图：

使用方式简单来说，主机首先向本地的DNS服务器发送DNS查询报文（含有被转能换的主机名）。本地 DNS服务器将该报文转发到根 DNS服务器。该根DNS服务器识别前缀并向本地 DNS 服务器返回负责该前缀的IP地址列表。该本地DNS服务器则再次向这些服务器之发送查询报文。以此类推，最后找到需要的DNS服务器。

计算机网络——应用层（http、SMTP、DNS）

一、应用层协议原理：

1.网络应用程序体系结构：

1.1 客户-服务器体系：