因特网协议栈：应用层协议在做些什么-一一网

前言

因特网协议栈体系结构，从上到下分别为应用层、运输层、网络层、链路层、物理层，每一层界定了各自的职责范围，使用下层以完成自身功能，并向上层提供服务。其中，应用层使两个系统的应用程序间进行通信，交换信息成为可能。

应用层协议就可以界定为：制定应用程序交换信息的规则。当不同系统间的应用程序使用协议交换信息时，会将信息分割成组传递，也称报文。换言之，应用层协议使应用进程得以通信，这里的进程通信是指通过计算机网络，交换报文的通信。

网络应用程序体系结构

应用层交换信息.png

应用程序的开发者，可以决定应用程序依赖的体系结构，这将决定应用程序间通信特点的不同，通常为CS(client-server architecture)或P2P(P2P architecture)：

CS：此架构中，分成客户端、服务端两种角色。客户端之间不能直接通信，多个客户端将与服务端交换信息。服务端将拥有固定的IP地址，使客户端可以找到它。这也意味着，服务端需要有更强的算力来应对诸多的客户端，并需要大量主机形成的数据中心帮助处理大量的客户端请求。
P2P：此架构中，每一个终端分饰两角，既能作为客户端也可作为服务端，因此每个终端也叫做对等方。对等方之间可以直接通信，并对数据中心的依赖最小。在这样的特点下，自扩展性很强。

两种架构的主要区别在于，是否集中式地进行处理。对于CS而言，需要大量的服务器基础设施和带宽进行支撑。对于P2P而言，虽然经济成本更低，但是安全性、性能、可能性更难得到保证。

交换报文.png

跨越网络进行通信的两个进程，将在以下条件中工作：

某一时刻，发起通信的进程被标识为客户端，另一个进程被标识为服务端。
进程通过一个称为套接字的软件接口，发送报文、接受报文
定义客户端、服务端各自的主机地址，也称IP地址、接收进程的标识符，也称端口号，此信息随报文携带，如此，才可找到对方。

运输层协议选择

应用层协议为进程而服务，进程将从中交换双方所需的数据，也因此应用层协议并不负责进行如何传输的工作。自然地，将向运输层索取服务来完成这部分工作。

在选择运输层协议时，综合几方面进行考量：

数据可靠性：意味着是否能容忍一些数据的丢失。对于电子邮件、文件传输、金融应用等，数据丢失将可能带来严重的问题；但对于通话、直播等，则可以容忍一定量的数据丢失。
吞吐量：即交付数据的速率，考量应用对于交付时间的敏感性。如电子邮件，慢一些的速率也没关系，数据终将到达；但如视频类的应用，速率低就只能容受低分辨率的体验。
定时：对交付时间的敏感性，如果进行交互式游戏时，将能清楚地感知到不同的交付时间带来的延迟，所带来的不同体验。
安全性：数据是否能安全地传达给接收方。

于此，因特网提供了两个运输层协议TCP和UDP完成此工作：

TCP是面向连接的服务，有SSL(安全套接字层)提供安全性保障，有可靠的数据传送服务
UDP仅则提供了最小服务，不保证数据一定能到达，发送端可以以它选定的速率进行传输

常见的应用层协议所选择的运输层协议如：

应用	应用层协议	做支撑的运输协议
电子邮件	SMTP	TCP
Web	HTTP	TCP
文件传输	FTP	TCP
流式多媒体	HTTP、DASH	TCP
因特网电话	SIP、RTP	UDP、TCP
迅雷等	BitTorrent	UDP、TCP

HTTP

Web页面将使用超文本传输协议(TyperText Transfer Protocol，HTTP)交换报文以传输信息。HTTP将由两个程序实现：运行在客户端的程序和运行在服务端的程序，通过HTTP报文进行会话。

HTTP的工作流程为：

客户端借助TCP与服务器建立连接，此后，各自进程就可以通过socket访问TCP
客户端与服务端从socket中接收HTTP报文，解析出数据
客户端与服务端一次请求，一次回答
HTTP是无状态协议

HTTP请求报文.png

请求报文的组成格式如上图：

请求行：包括了使用的方法、URL地址、HTTP版本信息
首部行：以K/V形式，指明了HTTP要使用的功能，或是携带信息
空行：做分隔用
请求数据：有时需要携带数据，比如使用POST方法提交表单，那么表单的数据放于实体体位置

GET / HTTP/1.1
Host: www.baidu.com
Connnection: keep-alive
User-Agent: .....
Aceept: ......
......
复制代码

以对百度的请求抓取HTTP报文来看，一些报文信息可能如上。这里仅需知道如何从中提取信息。

HTTP响应报文.png

响应报文如上：

状态行：包括http版本，状态码，以及对状态码的进一步解释
首部行：以K/V形式传递信息
空行：做分隔
响应数据：传输服务端需要接受并进一步处理的数据

HTTP/1.1 200 OK
Cacbe-control: private
Data: Mon, 17 May 2021 05:53:24 GMT
Expires: Mon, 17 May 2021 05:53:43 GMT
Server: BWS/1.1
......
复制代码

也以百度的响应看，响应报文的信息可能如上。亦是只要知道如何从中提取信息。

Cookie

HTTP是无状态的，每次http请求都是独立的、无关的。但有时候，希望能维护一些状态以进行识别。一个需要保存状态的例子如如，曾经登录过的Web，在某一段时间，再次访问可以自动登录。

在首次访问时，服务端的响应报文通过Set-cookies向客户端指明，要建立的状态数据，客户端将在本地保存一个文件，以保存对应的Cookies信息和过期时间
此后，每个HTTP请求，将会携带此Cookies信息
在一段时间后，如果Cookies没有过期，对Web的首次请求报文，也将携带Cookies信息
如此，就可以维护一些状态进行特殊的逻辑

SSL/TCL

明文传输的HTTP将面临数据被篡改的风险，因此就有了SSL/TLS(安全套接层/传输层安全)来保证数据的安全性。

加密算法可分为两类，对称加密和不对称加密：

对称加密：只要知道秘钥，就可以对密文加解密
不对称加密：由公钥和私钥组成，使用公钥进行加密，密文只有通过私钥才能解密，因此可以将公钥公之于众

首先，服务器向CA验证公钥，拿到公钥证书
在一开始，客户端向服务器告知支持何种加密组件
随之，服务器法发送自己的公钥证书
接着，客户端向CA验证公钥证书，并提起处公钥，自己生成了一个秘钥，然后共同公钥生成了秘钥的密文，发送个服务端
服务端收到密文后，通过私钥解密出秘钥
此后客户端与服务端都通过秘钥，对称加解密信息

为什么说以上的过程是安全的？

公钥证书一定需要通过CA认证，CA将通过各种角度验证公钥发布者的合法性，因此篡改着不能随意地使用自己的公钥证书，因为客户端将查不到没认证过的公钥证书
公钥证书是可以公知于众的，篡改着拿到了服务器的公钥证书，冒充服务器与客户端通信，可行。但是，客户端通过公钥加密出来的秘钥的密文，篡改者无法解密提取，因为服务器不会将私钥告诉任何人。因此，篡改者无法得到客户端的信息。

SSL/TLC虽不是绝对安全，但已足够可靠。可能有如下方法来破解：

客户端安装了伪造的CA根证书，但是阅览器都内置了权威的CA根证书，来减少被篡改的可能，因此这个难题在于，如何把伪造的根证书安装到客户端
另一种方式是，黑掉CA发布的公钥证书，其难度可想而知。

SMTP

SMTP（Simple Mail Transfer Protocol）也称简单邮件传输协议，用于在两个地址间传递邮件。

邮件收发概览.png

在邮件的场景中，包含了几种角色：

用户代理：允许用户阅读、恢复、转发、保存和撰写文件
邮件服务器：维护并管理用户的邮件报文，以使用户代理能从中提取邮件供用户使用，默认运行在80端口
SMTP：定义了邮件在邮件服务器间，要如何交换信息的规则

SMTP足够简单，仅使用一些命令和应答就能完成邮件的传输，整个过程依赖运输层协议TCP来保证正常交付。

SMTP中，发送方的邮件服务器使用命令来传输信息，如：

HELO：发送端的主机名
MAIL FROM：发信人
RCPT TO：预期的收件人
DATA：邮件主题
QUIT：终止会话

接收方的邮件服务器使用响应来对命令进行恢复，如：

220：服务就绪
221：服务关闭传输通道
250：请求命令完成
354：开始邮件输入
450：邮箱不可用
500：语法错误不能识别命令

以C表示发送方邮件服务器，S表示接收方邮件邮件服务器，在建立起TCP连接之后，SMTP的过程可能如：

// 服务就绪，指明自己是邮箱服务器 xc90.websitewelcome.com 
S: 220 xc90.websitewelcome.com 
// 告知自己为邮箱服务器 GP
C: HELO GP
// 收到命令，相互确认
S: 250 HELO GP
// 告知邮箱原地址
C: MAIL FROM: <gurpartap@patriots.in>
// 收到命令，表示确认
S: 250 OK
// 告知邮箱目的地址
C: RCPT TO: <raj_deol2002in@yahoo.co.in>
// 收到命令，表示确认
S: 250 OK
// 表明自己要开始发送邮件内容了
C: DATA
// 告知，好的，你开始发送吧
S: 354 Enter message, ending with"." on a line by itself
/*
邮件内容
*/
C: .....
C: .....
C: .....
// 告知已经收到邮件内容
S: 250 OK id = 1mugho-0003Dg-Un
// 要求终止会话
C: QUIT
// 告知服务通道已关闭
S: 221
复制代码

以此就完成了邮件在邮件服务器间的传输，看起来，就像人与人之间的交流。在DATA命令后的部分，邮件的内容格式遵循:

邮件内容格式.png

发送报文的邮件服务器，如果不能将邮件交付到接受邮件的邮件服务器，将在自己的报文队列中保持，并间隔一段时间后再次尝试。如果迟迟不能交付，邮件服务器将删除此报文，并生成一份邮件，待发送方使用用户代理后，就可以看到这份邮件通知。

在SMTP还有如下特点：

是推协议，由发送邮件的邮件服务器建立起TCP连接并推送邮件
采用7比特的ASCII码格式。如果报文包含了非7比特的ASCII字符，需要转码

SMTP能以最简单的形式交付邮件，但也将带来一些问题。
用户代理将为邮件的交付带来正向的效果：

用户代理为用户处理邮件发送，这样，当邮件发送不成功时，可以代替用户重试
用户代理为用户处理邮件接收，这样，用户就不用保持开机并不断地询问以保证接受任何可能到达的邮件

问题在于，SMTP是推协议，而用户代理并不能取得SMTP报文，因为取报文是一种拉操作。因此需要有特殊的协议，来支持用户代理能够访问到邮件。常用的协议为 POP3、IMAP 以及 HTTP

POP3

POP3(Post Office Protocol——Version 3)称为第三版的邮局协议，协议非常简单，功能有限。

POP3的工作过程比较简单，分成特许、事务处理、更新三个工作阶段，也是以命令-应答形式工作。用户代理将与邮件服务器端口110进行TCP连接，然后开始工作

/*特许*/
C: user 用户名
S: +OK
C: pass 密码
S: +OK 成功登录
/*事务处理*/
C: list (列出所有存储的报文的长度)
S: ...
C: retr (取出某个邮件)
S: balabala ...
C: dele (删除某个文件)
C: retr ...
...
C: quit
S: +ok 
/**更新**/
S处理被命令retr标记删除的文件
复制代码

通过上面的工作方式，用户代理可以取出邮件，然后从邮件服务器删除或者继续保存，两种方式都将带来不同的问题：

对于删除的方式，如果用户想从别的终端设备取出邮件，将无法完成，因为邮箱服务器已没有已被取出的邮件。
如果继续保存邮件，可以从多端获取邮件。而实际上是邮件服务器保存了一些状态，但POP3会话过程并不会携带这些信息，意味着这些邮件可能永远不会被删除。

IMAP

IMAP(Internet Mail Access Protocol)也称因特网邮件访问协议，与POP3不同的是，它更复杂，更具拓展性。

IMAP服务器中，将每个报文与一个远程文件夹联系起来。当报文到来时，将其与收件人的INBOX文件夹相关联。收件人能将邮件从这个远程文件夹中转移，因为IMAP支持了对应的命令。

值得注意的时，IMAP支持用户代理只获取报文的某些部分的命令，比如只读一个报文的首部。当邮件包含大附件时，可能用户只想知道他们大概是什么而此是并不想拿到具体内容。此特性将有效节约带宽。

基于Web

当有，有很多的Web的电子邮件。这样，用户代理就是浏览器，用户对邮件的操作通过HTTP进行，可将邮件存储到HTTP服务端。值得注意的是，邮件服务器之间的发送和接收依旧是使用SMTP进行。

DNS

人们擅长记忆名字，机器认识数字。如果要访问某主机或服务器的IP地址，如网上冲浪时，输入类似于202.108.22.5的地址，才能打开访问特定的网站，将很不方便，也很难记忆。

DNS(Domain Name System, 域名系统)为IP地址，即为主机建立了人类习惯的识别方法，将名字识别转换为数字地址。DNS是主机的通讯录，通过主机名，就可以查到主机的IP地址，进而使用IP地址访问。也就是说，DNS提供了主机名到IP地址的转换功能。此外，还提供了服务：

主机别名，如果主机名www.welcome-to-learn-dns.com不便于记忆，可使其拥有其他的别名，如www.learn-dns.com。此时，前者称为主机规范名，后者称为主机别名，通过DNS可以将从主机别名查找到主机规范名，进而查找到对应的IP地址。
邮件服务器别名，同样地，DNS可以让邮件地址更容易记忆。
负载分配，DNS存在冗余的DNS服务器来提供服务，对请求进行分配，而不至于使某个站点过于繁忙而称为网络带宽的瓶颈。

与其他应用层协议不同的是，DNS服务其他的应用层协议。DNS以CS架构提供功能，运行于UDP之上，使用53号端口。

组织方式

DNS层次.png

DNS拥有3中类型的服务器：

根DNS服务器：为IP地址的主目录，战略性地分布在全球，由12个不同的运营商管理。提供TLD服务器的IP地址和域名体系。
顶级域服务器：也叫TLD服务器，对于每个顶级域如（com、org、net、edu、gov等）和国家的顶级域如（cn、uk、fr、ca等）都有对应的TLD服务器集群。TLD服务器将提供DNS权威服务器的IP地址
权威DNS服务器：真正查询出一个主机名所匹配的IP地址。每个组织，机构将提供公共的可访问的DNS记录，并将这些记录映射为对应的IP地址。一个组织可以实现自己的权威DNS服务器，或者付费让自己的记录存储在供应商的权威DNS服务器中。

当用户在搜索栏中键入网址时，DNS将其查询出对应的IP地址。

DNS查询.png

以首次访问 www.baidu.com 为例：

用户主机先向本地的DNS服务器查询
本地DNS服务器查不到匹配的IP地址，向根DNS服务器发送查询
根DNS服务器自然查不到IP地址，但是它认识“.com”，因此它返回负责“.com”的TLD服务器
本地DNS服务器收到代表TLD服务器的IP地址后，向TLD服务器发起查询
TLD服务器收到请求后，识别到”.baidu”，查找到负责的权威DNS服务器IP地址，返回
本地DNS收到权威DNS服务器IP地址后，向权威DNS服务器发起查询
权威DNS服务器收到查询请求，查询出“www.baidu.com”的IP地址，返回
本地DNS服务器收到结果，缓存以下次用，返回给主机
主机对IP地址进行访问

报文

DNS报文，需要支持以上过程：

DNS报文.png

报文格式划分为不同的区域，每个区域对应不同的职责：

Header：共12字节，用来标识DNS的状态、启用的功能等。其中重要的属性如 QR，表示是应答报文还是响应报文；ID，相同则认为是同一个会话；Answer RRs，问题数；Authority RRs，权威服务器数；Addtional RRs，附加信息数等。
Qusetion：查询字段，表示要查询的内容，包含查询的域名(QNAME)、查询的协议类型(QTYPE)、查询的类(QCLASS)。
Answer/Authority/Additional：对查询内容的回答、权威服务器的信息、以及附加信息。三者格式一致，包括 NAME，资源记录包含的域名；TYPE，表示DNS协议的类型；CLASS，表示RDATA的类；TTL表示资源记录可以被缓存的时间；RDATA，不定长的子字符串来表示记录的信息，格式与TYPE与CLASS有关。

对应的，DNS信息将以记录的形式存储于DNS服务器中，称为资源记录(Resource Record， RR)，RR提供了主机名到IP地址的映射。那么，从报文的Answer处，可以看的RR有如：

TYPE=A，此时NAME是主机名，Value是主机名对应的IP地址，这是一条A类型记录。
TYPE=NS，此时NAME是个域，Value是权威DNS服务器的主机名，它可以查出此域中的主机的IP地址，这是一条NS类型记录
TYPE=CANME，此时NAME是规范主机名，Value是别名，这是一条CANME类型记录
TYPE=MX，NAME是别名，Value是NAME的邮件服务器的规范主机名，这是一条MX类型记录

DNS缓存

DNS也将广泛使用缓存技术，无论是何种DNS服务器。使用缓存，能使下一次的请求能更快地响应，而不是像第一次解析时要经历的很长的链路。

当然，主机名到IP地址的映射不会永久地存储，DNS服务器将在一段时间后丢弃缓存信息。缓存也避免了上层DNS服务器被过于频繁地访问。

BitTorrent

BitTorrent是一个有趣的协议，以P2P作为架构。Torrent称为洪流，在BitTorrent协议中，每一个角色称为对等方，也叫做peer。多个peer相互交换同一资源，称他们在同一洪流中。BitTorrent显著的特点是，洪流中有越多的peer，其交换数据的速度越快

按照P2P所具备的特点，不同于CS架构，在P2P中所有角色都可以为服务器，除非所有机器都故障了，否则不必担心服务器故障。此外，P2P中是向多个主机请求资源，因此带宽也将得到最大的利用。

运转原理

BitTorrent运转.png

在BitTorrent中，一个资源文件将被分成许多块。
在每个洪流中，都有一个基础设施节点，称为tracker(追踪器)，它不存储任何资源，它仅记录了哪些peer还在洪流中，拥有哪些资源。
一个peer想下载一个文件时，会向tracker进行注册，并周期性地通知tracker自己还在洪流中。
然后tracker返回一个peer列表，这些peer都包含了要下载的文件的部分文件块。
最后peer之间通过TCP建立连接，上载/下载文件块，进行的那个peer最终将所有的文件块还原成文件。

.torrent文件

在一开始，网络上并没有某个资源。有一个peer将对资源文件分割成若干块，然后得到一个”.torrent”文件，其包含了所有的这些文件块的信息，这个过程也叫做种，.torrent也常被称种子文件。

紧接着，peer向tracker表明，下载这个种子代表的资源就可以来找他。种子的作者在互联网上，通过其他方式将种子文件发布给其他人，其他peer就可以参照种子文件完成BitTorrent的下载过程。

.torrent文件是一个二进制文件，通过bencoding编码，其内容可以解析成一个JSON作为代表说明，这里仅取出一些Key作为说明，其他K/V含义可以参考官方文档，

Key	含义
announce	Tracker主服务器的URL
announce-list	可选，备用的Tracker服务器的URL
info_hash	整个文件的hash值，采用sha1算法
info,length	整个文件的长度
info.name	文件名
info.piecelength	每个块的hash长度
info.pieces	每个块的hash值列表

有了.torrent种子文件之后，通过announce的值向Tracker发送请求获得peer列表
下载方peer通过info.pieces知道这个文件需要下载的所有文件块，通过tacker返回的上载方peer知道他们有哪些文件块。
然后，下载方peer查看缺失的文件块，与不同的上载方peer建立连接并下载文件块，下载块后检查其hash值
最后，将整个块合并成文件，检查hash是否与info_hash相同

选择peer

一个文件块可能多个peer拥有，那么如何选择peer呢？这里的选择是双向的，一方面，下载方要选择向那个peer发起请求；另一方面，上载方要选择向哪个peer提供服务。

选择发送请求的peer时，使用最稀缺优先的准则，缺少哪个块在自己知道的peer中拥有数最少，就先请求这个块，这样的目的是为了使得稀缺的块能更快地分发，为之后的peer服务。
决定响应哪个peer时，将持续地测量其他peer向他提供数据的速率，选出一段时间速率最高的几个进行响应。并在每间隔一段时间重新选出，此外重要的是，每过30秒，还要随机地向另外一个peer发送块。这样做的目的，即是为了协调peer间的速率，也避免一些peer搭便车白嫖。

有什么问题

虽然BitTorrent实现P2P所带来的能最大限度利用带宽的优势，但也需要面对自身特质所带来的问题：

CS架构中，资源来自于服务端，意味着有一个数据中心提供资源保证。而在BitTorrent中，资源来自于peer，如果没有任何一个拥有资源的peer在线，那么资源无论如何也下载不动，这种情况也常被称为死种。
也因为没有中心化地管理资源，特别是在BitTorrent的延伸DHT网络中（去除了BitTorrent依赖的Tracker服务器，每个peer都可以作为一个tracker协助管理一部分区域），使去中心化更彻底。这样的土壤下，灰色资源得以生存分享，难以监控。
BitTorrent的下载核心思想是“人人为我，我为人人”，使用者需要分享上载速率，而不是更多地限制上载，并且下载完后马上退出洪流也使得情况变得更差。用户需要更多的时间建立分享意识。
BitTorrent并没有要求peer方的身份。那么供给者可以冒充peer并生成自己拥资源的所有块，在收到块请求后，发送错误的块以浪费请求者的带宽。BitTorrent的客户端也加入了黑名单机制，在供给者提供虚假块达到一定次数后，加入黑名单。
如迅雷类似的客户端，与P2P的理念相悖，其工作原理为：如果自身拥有资源，则引导用户付费才放开下载速度。如果自身没有资源，则加入到洪流中下载资源，并拒绝向其他非迅雷用户的peer的请求，如此将更多的资源收集到迅雷中，其他BT软件的速度越来越不如迅雷，劣币驱除良币。

DASH

DASH(Dynamic Adaptive Streaming over HTTP)称为经HTTP的动态适应性流，是基于HTTP研发的一种协议，服务于HTTP的视频资源请求。

想象我们通过Web观看视频，我们即希望视频分辨率尽可能地高，又希望视频尽可能地流畅。DASH检测用户实时网络的速率，来取得实时情况下最匹配的视频资源。

DASH原理.png

首先，将视频资源编码成不同分辨率的文件，按照同样的时间间隔，每个文件分成相同等分的块，称为分片。
HTTP服务端有一个告示文件，告知自己支持的每一个版本的URL
客户端动态地每次请求若干个分片，网络充足时，请求更高质量版本的分片，网络不佳时，请求质量更低版本的分片。

CDN

CND(Content Distribution Network)也称内容分发网，为了能更快地分发媒体资源而存在，加快网络访问速度。

CND的优势.png

需要视频资源时，从数据中心获取数据，数据传输中可能要跨过很多个ISP(互联网服务提供商)，如果ISP跨度很远，端到端的吞吐量将面对更高的时延。
相同的视频资源，经过相同长的链路反复传输，浪费网络带宽。
数据中心代表了单点故障，如果数据中心崩溃或者因特网的链路崩溃，将不能够再分发其他视频资源。

CDN将管理分布在多个地理位置上的服务器来减轻带宽压力，并能负载均衡请求，避免某一服务端持续为热点。

CDN可以分为专用CDN或第三方CDN。前者为内容服务商自己拥有，后者代表为多个内容提供商分发内容。

CDN通常采用两种不同的服务器安置原则：

深入：在各地理位置的IPS中部署服务器集群，如此能靠近端用户，以减少时延、增加吞吐量。但是这种高度分布式的设计，维护和管理集群成本很高。
邀请做客：在少量的关键地理位置建造大集群，并邀请ISP做客。这样做维护和管理成本较低，但是时延较高、吞吐量较低。

CDN工作.png

部署了CDN之后，CDN的工作细节为：

客户主机要获取内容，向本地DNS服务器获取内容的IP地址。
本地DNS服务器，通过DNS的运行机制中，获取到能提供此内容的CND服务器IP地址。
客户主机向CDN服务器请求内容。
CDN服务器收到请求后，选择何时的集群返回内容。可选择地理位置上最近的集群（与CDN服务器，而不是客户），或者基于流量条件选择集群（通过周期性地实时测量与客户之间的时延）。
用户主机取得内容。