应用层
应用层协议：
应用层协议原理
研发网络应用程序的核心是写出能够运行在不同的端系统和通过网络彼此通信的程序。因此，当研发新应用程序时，你需要编写将在多台端系统上运行的软件。例如，该软件能够用C、Java或Python来编写。重要的是，你不需要写在网络核心设备如路由器或链路层交换机上运行的软件。即使你要为网络核心设备写应用程序软件，你也不能做到这一点。网络核心设备并不在应用层上起作用，而仅在较低层起作用，特别是位于网络层及下面层次。这种基本设计，也即将应用软件限制在端系统的方法，促进了大量的网络应用程序的迅速研发和部署。
网络应用体系结构
当进行软件编码之前，应当对应用程序有一个宽泛的体系结构计划。记住应用程序的体系结构明显不同于网络的体系结构。从应用程序研发者的角度看，网络体系结构是固定的，并为应用程序提供了特定的服务集合。在另一方面，应用程序体系结构（application architecture）由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。
在*客户-服务器体系结构 （client-server architecture）中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。值得注意的是利用客户-服务器体系结构，客户相互之间不直接通信，因为该服务器具有固定的、周知的地址，并且因为该服务器总是打开的，客户总是能够通过向该服务器的IP地址发送分组来与其联系。具有客户-服务器体系结构的非常著名的应用程序包括Web、FTP、Telnet和电子邮件。
在一个P2P体系结构（P2P architecture）中，对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。这些对等方并不为服务提供商所有，相反却为用户控制的桌面机和膝上机所有。因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。
进程通信
在构建网络应用程序前，还需要对运行在多个端系统上的程序是如何互相通信的情况有一个基本了解。在操作系统的术语中，进行通信的实际上是进程（process）而不是程序。一个进程可以被认为是运行在端系统中的一个程序。当进程运行在相同的端系统上时，它们使用进程间通信机制相互通信。进程间通信的规则由端系统上的操作系统确定。
在两个不同端系统上的进程，通过跨越计算机网络交换报文（message）而相互通信。发送进程生成并向网络中发送报文；接收进程接收这些报文并可能通过将报文发送回去进行响应。
- 客户和服务器进程
网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。在给定的一对进程之间的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器。 - 进程与计算机网络之间的接口
多数应用程序是由通信进程对组成，每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过下面的网络。进程通过一个称为 套接字 （socket）的软件接口向网络发送报文和从网络接收报文。套接字是同一台主机内应用层与运输层之间的接口。由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface，API）。应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权。应用程序开发者对于运输层的控制仅限于：
①选择运输层协议；
②也许能设定几个运输层参数，如最大缓存和最大报文段长度等。
一旦应用程序开发者选择了一个运输层协议（如果可供选择的话），则应用程序就建立在由该协议提供的运输层服务之上。 - 进程寻址
为了向特定目的地发送邮政邮件，目的地需要有一个地址。类似地，在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。为了标识该接收进程，需要定义两种信息：①主机的地址；②定义在目的主机中的接收进程的标识符。
可供应用程序使用的运输服务
从四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时和安全性。
- 可靠数据传输
分组在计算机网络中可能丢失。运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数据传输。当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。 - 吞吐量
运输层协议能够以某种特定的速率提供确保的可用吞吐量。使用这种服务，该应用程序能够请求r比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是为至少r比特/秒。这样的确保吞吐量的服务将对许多应用程序有吸引力。具有吞吐量要求的应用程序被称为带宽敏感的应用（bandwidth-sensitive application）。 - 定时
运输层协议也能提供定时保证。如同具有吞吐量保证那样，定时保证能够以多种形式实现。对于非实时的应用，较低的时延总比较高的时延好，但对端到端的时延没有严格的约束。 - 安全性
运输协议能够为应用程序提供一种或多种安全性服务。例如，在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。这种服务将在发送和接收进程之间提供机密性，以防该数据以某种方式在这两个进程之间被观察到。运输协议还能提供除了机密性以外的其他安全性服务，包括数据完整性和端点鉴别。
因特网提供的运输服务
因特网（更一般的是TCP/IP网络）为应用程序提供两个运输层协议，即UDP和TCP。当你（作为一个软件开发者）为因特网创建一个新的应用时，首先要做出的决定是，选择UDP还是选择TCP。每个协议为调用它们的应用程序提供了不同的服务集合。
| 应用 | 数据丢失 | 带宽 | 时间敏感 |
| 文件传输 | 不能丢失 | 弹性 | 不 |
| 电子邮件 | 不能丢失 | 弹性 | 不 |
| Web文档 | 不能丢失 | 弹性（几kbps） | 不 |
| 因特网电话/视频 | 容忍丢失 | 音频（几kbps~1Mbps） | 是，100ms |
| 视频（10kbps~5Mbps） | |||
| 存储音频/视频 | 容忍丢失 | 同上 | 是，几秒 |
| 交互式游戏 | 容忍丢失 | 几kbps~10kbps | 是，100ms |
| 即时讯息 | 不能丢失 | 弹性 | 是和不是 |
- TCP服务：TCP服务模型包括面向连接服务和可靠数据传输服务。
面向连接的服务：在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提示客户和服务器，使它们为大量分组的到来做好准备。
可靠的数据传送服务：通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。
TCP协议还具有拥塞控制机制，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程（客户或服务器）。 - UDP服务：UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。
UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。
UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。 - 因特网运输协议所不提供的服务：吞吐量或定时。
今天的因特网通常能够为时间敏感应用提供满意的服务，但它不能提供任何定时或带宽保证。
| 应用 | 应用层协议 | 支撑的运输协议 |
| 电子邮件 | SMTP | TCP |
| 远程终端访问 | Telnet | TCP |
| Web | HTTP | TCP |
| 文件传输 | FTP | TCP |
| 流式多媒体 | HTTP | TCP |
| 因特网电话 | SIP或专用的（如Skype） | UDP/TCP |
应用层协议
- 交换的报文类型
- 各种报文类型的语法
- 字段的语义
- 一个进程何时以及如何发送报文，对报文进行响应的规则。
有些应用层协议是由RFC文档定义的，因此它们位于公共域中。还有很多别的应用层协议是专用的，有意不为公共域使用。例如，Skype使用了专用的应用层协议。
区分网络应用和应用层协议是很重要的。应用层协议只是网络应用的一部分。
Web和HTTP
超文本传输协议（HTTP，HyperText Transfer Protocol）
HTTP由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。
HTTP使用TCP作为它的支撑运输协议。
非持续性连接：每个请求/响应对是经一个 单独的 TCP连接发送。
持续性连接：所有的请求及其响应经 相同的 TCP连接发送。
HTTP 请求报文
GET /test/index.html HTTP/1.1—①
HOST :www.test.com—②
Connection:close—③
User-Agent:Mozilla/5.0—④
Accept-language:zh-cn—⑤
- 该行叫做请求行，有3个字段：方法字段、URL字段、HTTP版本字段。方法字段可以取：GET、POST、HEAD和DELETE 等。当浏览器请求一个对象时，使用GET方法，在URL字段带有请求对象的标识。在以上报文中，该浏览器请求 对象/test/index.html ,HTTP版本为 HTTP/1.1 版本。
- 首部行；指明对象所在主机。
- 首部行；浏览器高速服务器不希望使用持续连接，要求服务器在发送完成被请求的对象后就关闭连接。
- 首部行；向服务器发送请求浏览器的类型。时下流行的浏览器User-Agent大全_CSDN博文
- 首部行；表示用户想得到该对象的中文简体版本
GET：GET可以说是最常见的了，它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
POST：向服务器提交数据。这个方法用途广泛，几乎目前所有的提交操作都是靠这个完成。
HEAD：HEAD和GET本质是一样的，区别在于HEAD不含有呈现数据，而仅仅是HTTP头信息。有的人可能觉得这个方法没什么用，其实不是这样的。想象一个业务情景：欲判断某个资源是否存在，我们通常使用GET，但这里用HEAD则意义更加明确。
DELETE：删除某一个资源。基本上这个也很少见，不过还是有一些地方比如amazon的S3云服务里面就用的这个方法来删除资源。
PUT：这个方法比较少见。HTML表单也不支持这个。本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。
举个例子：如一个用于提交博文的URL，/addBlog。如果用PUT，则提交的URL会是像这样的”/addBlog/abc123”，其中abc123就是这个博文的地址。而如果用POST，则这个地址会在提交后由服务器告知客户端。目前大部分博客都是这样的。显然，PUT和POST用途是不一样的。具体用哪个还取决于当前的业务场景。
OPTIONS：这个方法很有趣，但极少使用。它用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。
HTTPS
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司(Netscape)进行，并内置于其浏览器Netscape Navigator中，提供了身份验证与加密通讯方法。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。
HTTPS和HTTP的区别
HTTP：超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息。HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。
HTTPS:安全套接字层超文本传输协议HTTPS。为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
HTTPS和HTTP的区别主要为以下四点：
- https协议需要到ca申请证书，一般免费证书很少，需要交费。
- http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
- http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTP响应报文
HTTP/1.1 200 OK—①
Connection:close—②
Date:Tue,09 Aug 2018 09:30:35 GMT—③
Server:Apache/2.2.3(Centos)—④
Last-Modified:True ,09 Aug 2018 01:11:03 GMT—⑤
Content-Length: 6821—6⑥
Contene-Type: text/html—⑦
(data data data…)—8⑧
- 状态行；[协议版本字段、状态码、对应状态信息] 服务器正在使用HTTP/1.1 (200 OK 状态码->详细信息HTTP 状态码）
- 首部行；服务器告诉用户，发送完报文后将关闭TCP连接。
- 首部行；服务器产生并发送该响应报文的日期和时间。这个时间指服务器从它的文件系统中检索到该对象，插入响应报文，并发送该响应报文的时间。
- 首部行；该报文是由一台Apache Web服务器产生的。
- 首部行；标记此文件在服务器端最后被修改的时间。
- 首部行；被发送对象中的字节数。
- 首部行；指示实体中的对象是HTML文本。Contene-Type 不是文件拓展名。
- 实体；要发送的报文。
用户与服务器的交互：cookie
An HTTP cookie (also called web cookie, Internet cookie, browser cookie, or simply cookie) is a small piece of data sent from a website and stored on the user’s computer by the user’s web browser while the user is browsing. Cookies were designed to be a reliable mechanism for websites to remember stateful information (such as items added in the shopping cart in an online store) or to record the user’s browsing activity (including clicking particular buttons, logging in, or recording which pages were visited in the past).
Structure(cookie 结构)
A cookie consists of the following components:
- Name
- Value
- Zero or more attributes (name/value pairs). Attributes store information such as the cookie’s expiration, domain, and flags (such as Secure and HttpOnly).
cookie技术有4个组件：
- 在HTTP响应报文中的一个cookie首部行；
- 在HTTP请求报文中的一个cookie首部行；
- 在用户端系统中保留一个cookie文件，由用户浏览器管理；
- 位于Web站点的一个后端数据库；
cookie 用途
会话管理
最初引入Cookie是为了让用户在整个网站（虚拟“购物车”或“购物篮”）中导航时记录他们想要购买的商品。然而，今天，用户购物车的内容通常存储在服务器上的数据库中，而不是存储在客户端的cookie中。为了跟踪哪个购物车被分配到哪个用户，服务器将cookie发送到包含唯一会话标识符的客户端（通常是一长串随机字母和数字）。因为cookie随着客户端发出的每个请求被发送到服务器，所以每当用户访问网站上的新页面时，该会话标识符将被发送回服务器，这使得服务器知道向用户显示哪个购物车。
Cookie的另一种流行用途是登录网站。当用户访问网站的登录页面时，Web服务器通常向客户端发送包含唯一会话标识符的cookie。当用户成功登录时，服务器会记住该特定会话标识符已经过身份验证，并授予用户对其服务的访问权限。
因为会话cookie仅包含唯一的会话标识符，所以这使得网站可以为每个用户保存的个人信息量几乎无限 - 网站不限于关于cookie的大小限制。会话cookie还有助于改善页面加载时间，因为会话cookie中的信息量很小并且需要很少的带宽。
个性化
Cookie可用于记住有关用户的信息，以便随着时间的推移向该用户显示相关内容。例如，Web服务器可能会发送一个cookie，其中包含上次用于登录网站的用户名，以便下次用户登录时可以自动填写该cookie。
许多网站根据用户的偏好使用cookie进行个性化。用户通过在Web表单中输入并将表单提交到服务器来选择他们的首选项。服务器在cookie中对首选项进行编码，并将cookie发送回浏览器。这样，每次用户访问网站上的页面时，服务器都可以根据用户的偏好来个性化页面。例如，谷歌搜索引擎曾使用cookie来允许用户（甚至是未注册的用户）决定他们想要查看的每页搜索结果数量。此外，DuckDuckGo使用cookie来允许用户设置观看偏好，如网页的颜色。
跟踪
另请参阅：Web访问者跟踪
跟踪cookie用于跟踪用户的网络浏览习惯。这也可以通过使用请求页面的计算机的IP地址或HTTP请求标头的referer字段在某种程度上完成，但cookie允许更高的精度。这可以证明如下：
如果用户请求站点的页面，但请求不包含cookie，则服务器假定这是用户访问的第一页。因此，服务器创建一个唯一标识符（通常是一串随机字母和数字），并将其作为cookie与请求的页面一起发送回浏览器。
从现在开始，每次请求来自站点的新页面时，cookie将自动由浏览器发送到服务器。服务器不仅像往常一样发送页面，还将请求页面的URL，请求的日期/时间以及cookie存储在日志文件中。
通过分析该日志文件，可以找出用户访问过的页面，顺序和持续时间。
公司通过跟踪cookie来收集有关购买习惯的信息，从而利用用户的网络习惯。“ 华尔街日报”发现，美国排名前50位的网站平均将64种跟踪技术安装到计算机上，共计有3,180个跟踪文件。然后可以收集数据并将其出售给投标公司。
Web缓存
Web缓存器（Web cache）也叫代理服务器（proxy server），它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。
- 浏览器建立一个到Web缓存器的TCP连接，并向Web缓存器中的对象发送一个HTTP请求。
- Web缓存器进行检查，看看本地是否存储了该对象的副本。如果有，Web缓存器就向客户浏览器用HTTP响应报文返回该对象。
- 如果Web缓存器中没有该对象，就打开一个与该对象的初始服务器的TCP连接。Web缓存器则在这个缓存器到服务器的TCP连接上发送一个对该对象的HTTP请求。在收到该请求后，初始服务器向该缓存器发送具有该对象的HTTP响应。
- 当Web缓存器接收到该对象时，它在本地存储空间存储一份副本，并向客户的浏览器用HTTP响应报文发送该副本。
值得注意的是：Web缓存器是服务器的同时又是客户。当它接受浏览器的请求并发回响应时，它是一个服务器。当它向初始服务器发出请求并接受响应时，它是一个客户。
通过使用内容分发网络（Content Delivery Network，CDN），Web缓存器正在因特网中发挥着越来越重要的作用。
备注：
Web缓存器将从Web服务器获得到的对象转发到请求的浏览器同时，在本地缓存了该对象。Web缓存器也在存储该对象时存储了最后的修改日期。当用户再次请求该对象时，缓存器会发送一个条件Get执行最新检查。当请求对象的对象修改日期晚于（？）缓存的修改日期时，缓存器会重新请求该对象，然后转发给用户。（响应报文的Last-Modified）
内容分发网络（Content Delivery Network，CDN） CDN简绍_百度百科
CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
关键技术
- 内容发布：它借助于建立索引、缓存、流分裂、组播（Multicast）等技术，将内容发布或投递到距离用户最近的远程服务点（POP）处；
- 内容路由：它是整体性的网络负载均衡技术，通过内容路由器中的重定向（DNS）机制，在多个远程POP上均衡用户的请求，以使用户请求得到最近内容源的响应；
- 内容交换：它根据内容的可用性、服务器的可用性以及用户的背景，在POP的缓存服务器上，利用应用层交换、流分裂、重定向（ICP、WCCP）等技术，智能地平衡负载流量；
- 性能管理：它通过内部和外部监控系统，获取网络部件的状况信息，测量内容发布的端到端性能（如包丢失、延时、平均带宽、启动时间、帧速率等），保证网络处于最佳的运行状态。
主要特点
- 本地Cache加速 提高了企业站点(尤其含有大量图片和静态页面站点)的访问速度，并大大提高以上性质站点的稳定性
- 镜像服务 消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。
- 远程加速 远程访问用户根据DNS负载均衡技术智能自动选择Cache服务器，选择最快的Cache服务器，加快远程访问的速度
- 带宽优化 自动生成服务器的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。
5、集群抗攻击 广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种DDoS攻击对网站的影响，同时保证较好的服务质量。
文件传输协议：FTP
The File Transfer Protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network.
FTP is built on a client-server model architecture using separate control and data connections between the client and the server.[1] FTP users may authenticate themselves with a clear-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).
The first FTP client applications were command-line programs developed before operating systems had graphical user interfaces, and are still shipped with most Windows, Unix, and Linux operating systems. Many FTP clients and automation utilities have since been developed for desktops, servers, mobile devices, and hardware, and FTP has been incorporated into productivity applications, such as HTML editors.
FTP使用了两个并行的TCP连接来传输文件，一个是控制链接（control connention），一个是****数据连接（data connection）。控制连接用于在两主机之间传输控制信息，如用户标识、口令、改变远程目录的命令以及“存放（put）”和“获取（get）”文件的命令。数据连接用于实际发送一个文件。因为FTP协议使用一个独立的控制连接，所以也称FTP的控制信息是带外（out-of-band）传送的。FTP服务器必须在整个会话期间保留用户的状态（state）。
更为具体的FTP信息 -> RFC 959_FTP相关
电子邮件
主要组成部分：
- 用户代理（user agent）
- 邮件服务器（mail server）
- 简单邮件传输协议（Simple Mail Transfer Protocol, SMTP）
SMTP是因特网电子邮件中主要的应用层协议。它使用TCP协议进行数据传输，从发送方的邮件服务器向接收方的邮件服务器发送邮件。其分为两个部分：
- 运行在发送方邮件服务器的客户端。
- 运行在接收方邮件服务器的服务器端。
每台邮件服务器上既运行SMTP的客户端也运行SMTP的服务器端。
SMTP
简介
简单邮件传输协议 (Simple Mail Transfer Protocol, SMTP)是在Internet传输email的事实标准。
SMTP是一个相对简单的基于文本的协议。在其之上指定了一条消息的一个或多个接收者（在大多数情况下被确认是存在的），然后消息文本会被传输。可以很简单地通过telnet程序来测试一个SMTP服务器。SMTP使用TCP端口25。要为一个给定的域名决定一个SMTP服务器，需要使用MX (Mail eXchange)DNS。
在八十年代早期SMTP开始被广泛地使用。当时，它只是作为UUCP的补充，UUCP更适合于处理在间歇连接的机器间传送邮件。相反，SMTP在发送和接收的机器在持续连线的网络情况下工作得最好 。
Sendmail是最早使用SMTP的邮件传输代理之一。到2001年至少有50个程序将SMTP实现为一个客户端（消息的发送者）或一个服务器（消息的接收者）。一些其他的流行的SMTP服务器程序包括了Philip Hazel的exim，IBM的Postfix，D. J. Bernstein的Qmail，以及Microsoft Exchange Server 。
由于这个协议开始是基于纯ASCII文本的，它在二进制文件上处理得并不好。诸如MIME的标准被开发来编码二进制文件以使其通过SMTP来传输。今天，大多数SMTP服务器都支持8位MIME扩展，它使二进制文件的传输变得几乎和纯文本一样简单。
SMTP是一个“推”的协议，它不允许根据需要从远程服务器上“拉”来消息。要做到这点，邮件客户端必须使用POP3或IMAP。另一个SMTP服务器可以使用ETRN在SMTP上触发一个发送 。
SMTP通信举例
在发送方（客户端）和接收方（服务器）间创建连接之后，接下来是一个合法的SMTP会话。在下面的对话中，所有客户端发送的都以“C:”作为前缀，所有服务器发送的都以“S:”作为前缀。在多数计算机系统上，可以在发送的机器上使用telnet命令来创建连接，比如：
telnet www.example.com 25
它打开一个从发送的机器到主机www.example.com的SMTP连接。
S: 220 www.example.com ESMTP Postfix
C: HELOE mydomain.com
S: 250 Hello mydomain.com
C: MAIL FROM: <sender@mydomain.com>
S: 250 Ok
C: RCPT TO: <friend@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: test message
C: From:""< sender@mydomain.com>
C: To:""< friend@example.com>
C:
C: Hello,
C: This is a test.
C: Goodbye.
C: .
S: 250 Ok: queued as 12345
C: quit
S: 221 Bye
虽然是可选的，但几乎所有的客户端都会使用HELO问候消息（而不是上面所示的HELO）来询问服务器支持何种SMTP扩展，邮件的文本体（接着DATA）一般是典型的MIME格式。
与HTTP的对比
SMTP协议和HTTP协议都是用于一台主机向另一台主机传送文件，其中，HTTP从web服务器向web客户机传送文件，而SMTP从一个邮件服务器向另一个邮件服务器传送文件，当进行文件传送时，这两个协议都使用持久连接。因此，这两个协议有一些共同特征。然而，他们有一些重要的区别：
- HTTP 协议主要是一个 拉协议 (pull protocol),即人们可以在方便的时候转载web服务器上的信息，也就是说，用户使用HTTP协议从该服务器上拉取信息。即TCP协议是由想获取文件的机器所发起的。
另一方面，SMTP基本上是一个推协议(push protocol),即发送邮件服务器把文件推向邮件服务器。 - SMTP要求每个报文都使用7位ASCII码格式。如果某报文包含了非7位ASCII字符或者二进制数据，如图形文件，则该报文必须按照7位ASCII码进行编码，而HTTP没有此限制。
- 如何处理一个既有文本又包含图形的文档，HTTP把每个对象都封装到它自己的HTTP响应报文中，而因特网电子邮件则包所有报文对象放入一个报文中（目前还没理解此区别）。
邮件访问协议
- POP3
RFC1939_POP3
POP3(Post Office Protocol - Version 3)即“邮局协议版本3”。是TCP/IP协议族中的一员，由RFC1939 定义。本协议主要用于支持使用客户端远程管理在服务器上的电子邮件。提供了SSL加密的POP3协议被称为POP3S。
POP3协议支持“离线”邮件处理。
其具体过程是：邮件发送到服务器上，电子邮件客户端调用邮件客户机程序以连接服务器，并下载所有未阅读的电子邮件。这种离线访问模式是一种存储转发服务，将邮件从邮件服务器端送到个人终端机器上，一般是PC机或 MAC。一旦邮件发送到 PC 机或MAC上，邮件服务器上的邮件将会被删除。但目前的POP3邮件服务器大都可以“只下载邮件，服务器端并不删除”，也就是改进的POP3协议。
使用下载并删除的方式是有问题的，接收方希望从不同的机器访问他的文件。 - IMAP
IMAP（Internet Mail Access Protocol，Internet邮件访问协议）以前称作交互邮件访问协议（Interactive Mail Access Protocol）。IMAP是斯坦福大学在1986年开发的一种邮件获取协议。它的主要作用是邮件客户端（例如MS Outlook Express)可以通过这种协议从邮件服务器上获取邮件的信息，下载邮件等。当前的权威定义是RFC3501。IMAP协议运行在TCP/IP协议之上，使用的端口是143。它与POP3协议的主要区别是用户可以不用把所有的邮件全部下载，可以通过客户端直接对服务器上的邮件进行操作。
Advantages over POP
Connected and disconnected modes
When using POP, clients typically connect to the e-mail server briefly, only as long as it takes to download new messages. When using IMAP4, clients often stay connected as long as the user interface is active and download message content on demand. For users with many or large messages, this IMAP4 usage pattern can result in faster response times.
Multiple simultaneous clients
The POP protocol requires the currently connected client to be the only client connected to the mailbox. In contrast, the IMAP protocol specifically allows simultaneous access by multiple clients and provides mechanisms for clients to detect changes made to the mailbox by other, concurrently connected, clients. See for example RFC3501 section 5.2 which specifically cites “simultaneous access to the same mailbox by multiple agents” as an example.
Access to MIME message parts and partial fetch
Usually all Internet e-mail is transmitted in MIME format, allowing messages to have a tree structure where the leaf nodes are any of a variety of single part content types and the non-leaf nodes are any of a variety of multipart types. The IMAP4 protocol allows clients to retrieve any of the individual MIME parts separately and also to retrieve portions of either individual parts or the entire message. These mechanisms allow clients to retrieve the text portion of a message without retrieving attached files or to stream content as it is being fetched.
Message state information
Through the use of flags defined in the IMAP4 protocol, clients can keep track of message state: for example, whether or not the message has been read, replied to, or deleted. These flags are stored on the server, so different clients accessing the same mailbox at different times can detect state changes made by other clients. POP provides no mechanism for clients to store such state information on the server so if a single user accesses a mailbox with two different POP clients (at different times), state information—such as whether a message has been accessed—cannot be synchronized between the clients. The IMAP4 protocol supports both predefined system flags and client-defined keywords. System flags indicate state information such as whether a message has been read. Keywords, which are not supported by all IMAP servers, allow messages to be given one or more tags whose meaning is up to the client. IMAP keywords should not be confused with proprietary labels of web-based e-mail services which are sometimes translated into IMAP folders by the corresponding proprietary servers.
Multiple mailboxes on the server
IMAP4 clients can create, rename, and/or delete mailboxes (usually presented to the user as folders) on the server, and copy messages between mailboxes. Multiple mailbox support also allows servers to provide access to shared and public folders. The IMAP4 Access Control List (ACL) Extension (RFC 4314) may be used to regulate access rights.
Server-side searches
IMAP4 provides a mechanism for a client to ask the server to search for messages meeting a variety of criteria. This mechanism avoids requiring clients to download every message in the mailbox in order to perform these searches.
Built-in extension mechanism
Reflecting the experience of earlier Internet protocols, IMAP4 defines an explicit mechanism by which it may be extended. Many IMAP4 extensions to the base protocol have been proposed and are in common use. IMAP2bis did not have an extension mechanism, and POP now has one defined by RFC 2449.
Disadvantages
While IMAP remedies many of the shortcomings of POP, this inherently introduces additional complexity. Much of this complexity (e.g., multiple clients accessing the same mailbox at the same time) is compensated for by server-side workarounds such as Maildir or database backends.
The IMAP specification has been criticised for being insufficiently strict and allowing behaviours that effectively negate its usefulness. For instance, the specification states that each message stored on the server has a “unique id” to allow the clients to identify messages they have already seen between sessions. However, the specification also allows these UIDs to be invalidated with no restrictions, practically defeating their purpose.
Unless the mail storage and searching algorithms on the server are carefully implemented, a client can potentially consume large amounts of server resources when searching massive mailboxes.
IMAP4 clients need to maintain a TCP/IP connection to the IMAP server in order to be notified of the arrival of new mail. Notification of mail arrival is done through in-band signaling, which contributes to the complexity of client-side IMAP protocol handling somewhat. A private proposal, push IMAP, would extend IMAP to implement push e-mail by sending the entire message instead of just a notification. However, push IMAP has not been generally accepted and current IETF work has addressed the problem in other ways (see the Lemonade Profile for more information).
Unlike some proprietary protocols which combine sending and retrieval operations, sending a message and saving a copy in a server-side folder with a base-level IMAP client requires transmitting the message content twice, once to SMTP for delivery and a second time to IMAP to store in a sent mail folder. This is addressed by a set of extensions defined by the IETF Lemonade Profile for mobile devices: URLAUTH RFC 4467 and CATENATE RFC 4469 in IMAP and BURL RFC 4468 in SMTP-SUBMISSION. In addition to this, Courier Mail Server offers a non-standard method of sending using IMAP by copying an outgoing message to a dedicated outbox folder.
DNS:因特网的目录服务
因特网上的主机和人类一样，可以使用多种方式进行标识。主机的一种标识方法是用它的主机名( hostname),如cnn. com、www. yahoo. com、gaia. cs. umass. edu以及cis. poly. edu等，这些名字便于记忆也乐于被人们接受。然而，主机名几乎没有提供( 即使有也很少)关于主机在因特网中位置的信息。况且，因为主机名可能由不定长的字母数字组成，路由器难以处理。由于这些原因，主机也可以使用所谓**IP地址(IP address）**进行标识。IP地址具有层次结构，是因为当我们从左至右扫描它时，我们会得到越来越具体的关于主机位于因特网何处的信息（即在众多网络的哪个网络里）。
DNS提供的服务
刚刚看到了识别主机有两种方式，通过主机名或者IP 地址。人们喜欢便于记忆的主机名标识方式，而路由器则喜欢定长的、有着层次结构的IP地址。为了折衷这些不同的偏好，我们需要一种能进行主机名到 IP地址转换的目录服务。这就是域名系统(Domain Name System, DNS) 的主要任务。
DNS是:
- 一个由分层的DNS服务器(DNS server)实现的分布式数据库;
- 一个使得主机能够查询分布式数据库的应用层协议.DNS服务器通常是运行BIND(Berkeley Internet Name Domin)软件[ BIND 2012]的UNIX机器。DNS 协议运行在UDP之上，使用53号端口。
实践原则
DNS:通过客户-服务器模式提供的重要网络功能
使用与HTTP、FTP和SMTP协议一样，DNS协议是应用层协议，其原因在于:
- 客户一服务器模式运行在通信的端系统之间;
- 在通信的端系统之间通过下面的端到端运输协议来传送DNS报文。
然而，在其他意义上，DNS的作用非常不同于Web应用、文件传输应用以及电子邮件应用。与这些应用程序不同之处在于，DNS不是一个直接和用户打交道的应用。相反，DNS是为因特网上的用户应用程序以及其他软件提供一种核心功能，即将主机名转换为其背后的IP地址。因特网体系结构的复杂性大多数位于网络的“边缘”。DNS 通过采用了位于网络边缘的客户和服务器，实现了关键的名字到地址转换功能，它还是这种设计原理的另一个范例。
除了进行主机名到IP地址的转换外，DNS还提供了一些重要服务：
- 主机别名（host aliasing）
- 邮件服务器名（mail server aliasing）
- 负载分配（load distribution）
DNS工作机理概述
假设运行在用户主机上的某些应用程序需要将主机名转换为IP地址。这些应用程序将调用DNS的客户端，并指明需要被转换的主机名。用户主机上的DNS接收到后，向网络中发送一个DNS查询报文。所有的DNS请求和回答报文使用UDP数据报经端口53发送。经过若干毫秒到若干秒的时延后，用户主机上的DNS接收到一个提供所希望映射的DNS回答报文。这个映射结果则被传递到调用DNS的应用程序。因此，从用户主机上调用应用程序的角度看，DNS是一个提供简单、直接的转换服务的黑盒子。但事实上，实现这个服务的黑盒子非常复杂，它由分布于全球的大量DNS服务器以及定义了DNS服务器与查询主机通信方式的应用层协议组成。
DNS的一种简单设计是在因特网上只使用一个DNS服务器，该服务器包含所有的映射。在这种集中式设计中，客户直接将所有查询直接发往单一的DNS服务器，同时该DNS服务器直接对所有的查询客户做出响应。尽管这种设计的简单性非常具有吸引力，但它不适用于当今的因特网，因为因特网有着数量巨大（并持续增长）的主机。这种集中式设计的问题包括：
-
单点故障（a single point of failure）。如果该DNS服务器崩溃，整个因特网随之瘫痪！
-
通信容量（traffic volume）。单个DNS服务器不得不处理所有的DNS查询（用于为上亿台主机产生的所有HTTP请求报文和电子邮件报文服务）。
-
远距离的集中式数据库（distant centralized database）。单个DNS服务器不可能“邻近”所有查询客户。如果我们将单台DNS服务器放在纽约市，那么所有来自澳大利亚的查询必须传播到地球的另一边，中间也许还要经过低速和拥塞的链路。这将导致严重的时延。
-
维护（maintenance）。单个DNS服务器将不得不为所有的因特网主机保留记录。这不仅将使这个中央数据库非常庞大，而且它还不得不为解决每个新添加的主机而频繁更新。
总的来说，在单一DNS服务器上运行集中式数据库完全没有可扩展能力。因此，DNS采用了分布式的设计方案。事实上，DNS是一个在因特网上实现分布式数据库的精彩范例。
- 分布式、层次数据库
为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。没有一台DNS服务器拥有因特网上所有主机的映射。相反，该映射分布在所有的DNS服务器上。大致说来，有3种类型的DNS服务器：根DNS服务器、顶级域（Top-Level Domain，TLD）DNS服务器和权威DNS服务器。
假定一个DNS客户要决定主机名www.amazon.com的IP地址。将发生下列事件。客户首先与根服务器之一联系，它将返回顶级域名com的TLD服务器的IP地址。该客户则与这些TLD服务器之一联系，它将为amazon.com返回权威服务器的IP地址。最后，该客户与amazon.com权威服务器之一联系，它为主机名www.amazon.com返回其IP地址。 - DNS缓存（DNS caching）
为了改善时延性能并减少在因特网上到处传输的DNS报文数量，DNS广泛使用了缓存技术。DNS缓存的原理非常简单。在一个请求链中，当某DNS服务器接收一个DNS回答（例如，包含主机名到IP地址的映射）时，它能将该回答中的信息缓存在本地存储器中。
DNS记录和报文
共同实现DNS分布式数据库的所有DNS服务器存储了资源记录（Resource Record，RR），RR提供了主机名到IP地址的映射。每个DNS回答报文包含了一条或多条资源记录。资源记录是一个包含了下列字段的4元组：
（Name，Value，Type，TTL）
-
TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。在下面给出的记录例子中，我们忽略掉TTL字段。Name和Value的值取决于Type：
-
如果Type=A，则Name是主机名，Value是该主机名对应的IP地址。因此，一条类型为A的资源记录提供了标准的主机名到IP地址的映射。例如（relay1.bar.foo.com，145.37.93.126，A）就是一条类型A记录。
-
如果Type=NS，则Name是个域（如foo.com），而Value是个知道如何获得该域中主机IP地址的权威DNS服务器的主机名。这个记录用于沿着查询链来路由DNS查询。例如（foo.com，dns.foo.com，NS）就是一条类型为NS的记录。
-
如果Type=CNAME，则Value是别名为Name的主机对应的规范主机名。该记录能够向查询的主机提供一个主机名对应的规范主机名，例如（foo.com，relay1.bar.foo.com，CNAME）就是一条CNAME类型的记录。
-
如果Type=MX，则Value是个别名为Name的邮件服务器的规范主机名。举例来说，（foo.com，mail.bar.foo.com，MX）就是一条MX记录。MX记录允许邮件服务器主机名具有简单的别名。值得注意的是，通过使用MX记录，一个公司的邮件服务器和其他服务器（如它的Web服务器）可以使用相同的别名。为了获得邮件服务器的规范主机名，DNS客户应当请求一条MX记录；而为了获得其他服务器的规范主机名，DNS客户应当请求CNAME记录。
- DNS报文
提到了DNS查询和回答报文。DNS只有这两种报文，并且，查询和回答报文有着相同的格式。DNS报文中各字段的语义如下：
| 标识符 | 标志 | 12字节 |
| 问题数 | 回答RR数 | |
| 权威RR数 | 附加RR数 | |
| 问题（问题的变量数） | 查询的名字和类型字段 | |
| 回答（资源记录的变量数） | 对查询的响应中的RR | |
| 权威（资源记录的变量数） | 权威服务器的记录 | |
| 附加信息（资源记录的变量数） | 可被使用的附加“有帮助的”信息 | |
- 在DNS数据库中插入记录
在注册登记机构注册域名XXX.com（注册登记机构（registrar）是一个商业实体，它验证该域名的唯一性），注册登记机构将该域名输入DNS数据库。当你向某些注册登记机构注册域名XXX.com时，需要向该机构提供你的基本和辅助权威DNS服务器的名字和IP地址。假定该名字和IP地址是dns1.XXX.com和dns2.XXX.com及212.212.212.1和212.212.212.2。对这两个权威DNS服务器的每一个，该注册登记机构确保将一个类型NS和一个类型A的记录输入TLD com服务器。特别是对于用于XXX.com的基本权威服务器，该注册登记机构将下列两条资源记录插入该DNS系统中：
(XXX.com,dns1.XXX.com,NS)
(dns1.XXX.com,212.212.212.1,A)
你还必须确保用于Web服务器www.XXX.com的类型A资源记录和用于邮件服务器mail.XXX.com的类型MX资源记录被输入你的权威DNS服务器中。一旦完成所有这些步骤，人们将能够访问你的Web站点，并向你公司的雇员发送电子邮件。
P2P应用
使用P2P体系结构，对总是打开的基础设施服务器有最小的（或者没有）依赖。与之相反，成对间歇连接的主机（称为对等方）彼此直接通信。这些对等方并不为服务提供商所拥有，而是受用户控制的桌面计算机和膝上（？没有英文原版）计算机。
P2P文件分发
考虑一个非常自然的应用来开始涉足P2P，这种应用即从单一服务器向大量主机（称为对等方）分发一个大文件。在客户-服务器文件分发中，该服务器必须向每个对等方发送该文件的一个副本，即服务器承受了极大的负担，并且消耗了大量的服务器带宽。在P2P文件分发中，每个对等方能够重新分发它所有的该文件的任何部分，从而在分发过程中协助该服务器。
- P2P体系结构的扩展性
每个对等方能够帮助服务器分发该文件。特别是，当一个对等方接收到某些文件数据，它能够使用自己的上载能力重新将数据分发给其他对等方。对等方除了是比特的消费者外还是它们的重新分发者。 - BitTorrent
BitTorrent是一种用于文件分发的流行P2P协议。用BitTorrent的术语来讲，参与一个特定文件分发的所有对等方的集合被称为一个洪流（torrent）。在一个洪流中的对等方彼此下载等长度的文件块（chunk），典型的块长度为256KB。当一个对等方首次加入一个洪流时，它没有块。随着时间的流逝，它累积了越来越多的块。当它下载块时，也为其他对等方上载了多个块。一旦某对等方获得了整个文件，它也许（自私地）离开洪流，或（大公无私地）留在该洪流中并继续向其他对等方上载块。同时，任何对等方可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加入该洪流中。
每个洪流具有一个基础设施结点，称为追踪器（tracker）。当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中。以这种方式，追踪器跟踪正参与在洪流中的对等方。一个给定的洪流可能在任何时刻具有数以百计或数以千计的对等方。在任何给定的时间，每个对等方将具有来自该文件的块子集，并且不同的对等方具有不同的子集。
最稀缺优先（rarest first）的技术。这种技术的思路是，针对没有的块在网络邻居中决定最稀缺的块（最稀缺的块就是那些在其邻居中副本数量最少的块），并首先请求那些最稀缺的块。这样，最稀缺块得到更为迅速的重新分发，其目标是（大致地）均衡每个块在洪流中的副本数量。
分布式散列表
在P2P网络中怎样实现一个简单的数据库。先从描述这种简单数据库的集中式版本开始，该数据库只包含(键，值)对。我们用键来查询数据库。如果在该数据库中有一个或多个键-值对匹配该查询键，该数据库就返回相应的值。
构建这样一个数据库直接采用客户-服务器体系结构，以在一个中心服务器中存储所有（键，值）对。构建这种数据库的一个分布式、P2P的版本，在数以百万计的对等方上存储（键，值）对。在该P2P系统中，每个对等方将保持（键，值）对仅占总体的一个小子集。我们将允许任何对等方用一个特别的键来查询该分布式数据库。分布式数据库则将定位拥有该相应（键，值）对的对等方，然后向查询的对等方返回该（键，值）对。任何对等方也将允许在数据库中插入新键-值对。这样一种分布式数据库被称为分布式散列表（Distributed Hash Table，DHT）。
构建DHT的一种幼稚的方法是跨越所有对等方随机地散布（键，值）对，让每个对等方维护一个所有参与对等方的列表。在该设计中，查询的对等方向所有其他对等方发送它的查询，并且包含与键匹配的（键，值）对的对等方能够用它们匹配的对进行响应。当然，这样的方法完全无扩展性，因为它将要求每个对等方不仅知道所有其他对等方（这样的对等方可能数以百万计），而且更糟的是，要向所有对等方发送一个查询。
现在描述设计DHT的一种精确有效的方法。为此，我们现为每个对等方分配一个标识符，其中每个标识符是一个［0，2n-1］范围内的整数，n取某些固定的值。值得注意的是这样的标识符能够由一个n比特表示法来表示。我们也要求每个键是同一范围内的一个整数。有些键并不是数字。为在这些键范围外生成整数，我们将使用散列函数把每个键映射为［0，2n-1］范围内的一个整数。散列函数是一种多对一的函数，使两个不同的输入能够具有相同的输出（相同的整数），但是具有相同输出的似然性极低。
考虑在DHT中存储（键，值）对的问题。此时的中心问题是定义为对等方分配键的规则。给定每个对等方具有一个整数标识符，每个键也是一个位于相同范围的整数，一种当然的方法是为其标识符最邻近该键的对等方分配一个（键，值）对。为实现这样的方案，我们将需要定义“最邻近”的含义。为了方便起见，我们将最邻近对等方定义为键的最邻近后继。为了加深理解，我们来看一个特定的例子。假设n=4，使所有对等方和键标识符都位于［0，15］范围内。进一步假定在该系统中有8个对等方，它们的标识符分别为1、3、4、5、8、10、12和15。假定要在这8个对等方之一上存储（键，值）对（11，Johnny Wu）。但是放在哪个对等方上呢？使用我们定义的最邻近规则，因为对等方12是键11最邻近的后继，因此我们将存储在对等方12上。［为了完成我们的“最邻近”定义，说明如下：如果该键恰好等于这些对等方标识符之一，我们在匹配的对等方中存储（键，值）对；并且如果该键大于所有对等方标识符，我们使用模2n规则，在具有最小标识符的对等方中存储（键，值）对。
- 环形DHT
在设计DHT时，在每个对等方必须跟踪的邻居数量与DHT为解析一个查询而需要发送的报文数量之间存在着折中。一方面，如果每个对等方联系所有其他对等方（网状覆盖网络），则每个查询仅发送一个报文，但每个对等方必须关联N个对等方。在另一方面，使用环形DHT，每个对等方仅知道两个对等方，但对每个查询平均要发送N/2条报文。幸运的是，我们能够完善DHT设计，使每个对等方的邻居数量和每次查询的报文数量都保持在可接受的范围内。细化的方案之一是以该环形覆盖网络为基础，但增加“捷径”，使每个对等方不仅联系它的直接后继和直接前任，而且联系分布在环上的数量相对少的捷径对等方。 - 等对方扰动
在P2P系统中，对等方能够不加警示地到来和离去。因此，当设计一个DHT时，我们也必须关注存在这种对等方扰动时维护DHT的情况。为处理对等方扰动，我们此时将要求每个对等方联系其第一个和第二个后继（即知道它们的IP地址）。我们也要求每个对等方周期性地证实它的两个后继是存活的（例如，通过周期性地向它们发送ping报文并寻求响应）。
DHT已经在实践中得到了广泛使用。例如，BitTorrent使用Kademlia DHT来产生一个分布式跟踪器。在BitTorrent中，其键是洪流标识符而其值是当前参与洪流的所有对等方的IP地址［Falkner 2007，Neglia 2007］。以这种方式，通过用某洪流标识符来查询DHT，一个新到达的BitTorrent对等方能够确定负责该标识符（即在洪流中跟踪对等方）的对等方。在找到该对等方后，到达的对等方能够向它查询在洪流中的其他对等方列表。
TCP套接字编程
网络应用程序有两类。
一类是实现在协议标准（如一个RFC或某种其他标准文档）中所定义的操作；这样的应用程序又称为“开放”的，因为定义其操作的这些规则人所共知。
另一类网络应用程序是专用的网络应用程序。在这种情况下，由客户和服务器程序应用的应用层协议没有公开发布在某RFC中或其他地方。
UDP套接字
仔细观察使用UDP套接字的两个通信进程之间的交互。在发送进程能够将数据分组推出套接字之门之前，当使用UDP时，必须先将目的地址附在该分组之上。在该分组传过发送方的套接字之后，因特网将使用该目的地址通过因特网为该分组选路到接收进程的套接字。当分组到达接收套接字时，接收进程将通过该套接字取回分组，进而检查分组的内容并采取适当的动作。
目的主机的IP地址是目的地址的一部分。通过在分组中包括目的地的IP地址，因特网中的路由器将能够通过因特网将分组选路到目的主机。但是因为一台主机可能运行许多网络应用进程，每个进程具有一个或多个套接字，所以在目的主机指定特定的套接字也是必要的。当生成一个套接字时，就为它分配一个称为端口号（port number）的标识符。因此，分组的目的地址也包括该套接字的端口号。
归纳起来，发送进程为分组附上的目的地址是由目的主机的IP地址和目的地套接字的端口号组成的。此外，发送方的源地址也是由源主机的IP地址和源套接字的端口号组成，该源地址也要附在分组之上。然而，将源地址附在分组之上通常并不是由UDP应用程序代码所为，而是由底层操作系统自动完成的。
TCP套接字
与UDP不同，TCP是一个面向连接的协议。这意味着在客户和服务器能够开始互相发送数据之前，它们先要握手和创建一个TCP连接。TCP连接的一端与客户套接字相联系，另一端与服务器套接字相联系。当创建该TCP连接时，我们将其与客户套接字地址（IP地址和端口号）和服务器套接字地址（IP地址和端口号）关联起来。使用创建的TCP连接，当一侧要向另一侧发送数据时，它只需经过其套接字将数据丢给TCP连接。这与UDP不同，UDP服务器在将分组丢进套接字之前必须为其附上一个目的地地址。
仔细观察一下TCP中客户程序和服务器程序的交互。客户具有向服务器发起接触的任务。服务器为了能够对客户的初始接触做出反应，服务器必须已经准备好。这意味着两件事。第一，与在UDP中的情况一样，TCP服务器在客户试图发起接触前必须作为进程运行起来。第二，服务器程序必须具有一扇特殊的门，更精确地说是一个特殊的套接字，该门欢迎来自运行在任意主机上的客户进程的某些初始接触。使用房子/门来比喻进程/套接字，有时我们将客户的初始接触称为“敲欢迎之门”。
随着服务器进程的运行，客户进程能够向服务器发起一个TCP连接。这是由客户程序通过创建一个TCP套接字完成的。当该客户生成其TCP套接字时，它指定了服务器中的欢迎套接字的地址，即服务器主机的IP地址及其套接字的端口号。生成其套接字后，该客户发起了一个三次握手并创建与服务器的一个TCP连接。发生在运输层的三次握手，对于客户和服务器程序是完全透明的。
在三次握手期间，客户进程敲服务器进程的欢迎之门。当该服务器“听”到敲门时，它将生成一扇新门（更精确地讲是一个新套接字），它专门用于特定的客户。在我们下面的例子中，欢迎之门是一个我们称为serverSocket的TCP套接字对象；它专门对客户进行连接的新生成的套接字，称为连接套接字（connection Socket）。初次遇到TCP套接字的学生有时会混淆欢迎套接字（这是所有要与服务器通信的客户的起始接触点）和每个新生成的服务器侧的连接套接字（这是随后为与每个客户通信而生成的套接字）。
从应用程序的观点来看，客户套接字和服务器连接套接字直接通过一根管道连接。客户进程可以向它的套接字发送任意字节，并且TCP保证服务器进程能够按发送的顺序接收（通过连接套接字）每个字节。TCP因此在客户和服务器进程之间提供了可靠服务。此外，就像人们可以从同一扇门进和出一样，客户进程不仅能向它的套接字发送字节，也能从中接收字节；类似地，服务器进程不仅从它的连接套接字接收字节，也能向其发送字节。
小结
- 对协议给出了一个相当含糊的框架性定义：“在两个或多个通信实体之间交换报文的格式和次序，以及对某报文或其他事件传输和/或接收所采取的动作。”
- 对HTTP、FTP、SMTP、POP3和DNS协议进行的细致研究，已经为这个定义加入了相当可观的实质性的内容。协议是网络连接中的核心概念；对应用层协议的学习，为我们提供了有关协议内涵的更为直觉的认识。
2725
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
