Notes

# 应用层协议

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

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

# 1.Web

# 1.1 HTTP

Web的应用层协议是超文本传输协议(HyperText Transfer Protocol, HTTP),它是Web 的核心，在[RFC 1945]和[RFC 2616]中进行了定义。HTTP由两个程序实现:一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换 HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。

分层体系结构最大的优点，即 HTTP协议不用担心数据丢失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。那是TCP以及协议栈较低层协议的工作。

服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。假如某个特定的客户在短短的几秒内两次请求同一个对象，服务器并不会因 为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。因为HTTP服务器并不保存关于客户的任何信息，所以 我们说HTTP是一个无状态协议(stateless protocol)。

# 1.1.1持久连接和非持久连接

HTTP既能够使用非持续连接，也能够使用持续连接。尽管HTTP在其默认方式下使用持续连接，HTTP客户和服务器也能配置成使用非持续连接。

非持续连接：假设该页面含有一个HTML基本文件和10个JPEG图形，并且这11个对象位于同一台服务器上。上面的步骤举例说明了非持续连接的使用，其中每个TCP连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。值得注意的是每个TCP连接只传输一个请求 报文和一个响应报文。因此在本例中，当用户请求该Web页面时，要产生11个TCP连接。

事实上，用户能够配置现代 浏览器来控制连接的并行度。在默认方式下，大部分浏览器打开5 ~ 10个并行的TCP连接，而 每条连接处理一个请求响应事务。如果用户愿意，最大并行连接数可以设置为1,这样10条连接就会串行建立。我们在下一章会看到，使 用并行连接可以缩短响应时间。

往返时间（Round-trip time）RTT：该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。RTT包括分组传 播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延。

非持续连接有一些缺点。第一，必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量, 这给Web服务器带来了严重的负担，因为一台Web服务器可能同时服务于数以百计不同的客户的请求。第二，就像我们刚描述的那样，每一个对象经受两倍RTT的交付时延, 即一个RTT用于创建TCP,另一个RTT用于请求和接收一个对象。

持续连接：

在采用HTTP 1.1持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在 相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。特别 是，一个完整的Web页面(上例中的HTML基本文件加上10个图形)可以用单个持续TCP连接进行传送。更有甚者，位于同一台服务器的多个Web页面在从该服务器发送给同 一个客户时，可以在单个持续TCP连接上进行。对对象的这些请求可以一个接一个地发 出，而不必等待对未决请求(流水线)的回答。一般来说，如果一条连接经过一定时间间隔 (一个可配置的超时间隔)仍未被使用，HTTP服务器就关闭该连接。

HTTP/2 [RFC 7540]是在HTTP 1. 1基础上构建的，它允许在相同连接中多个请求和回答交错，并增加了在该连接中优化HTTP报文请求 和回答的机制。

# 1.1.2 cookie

一个Web站点通 常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来。为此，HTTP使用了 cookie。cookie在 [RFC 6265 ]中定义，它允许 站点对用户进行跟踪。目前大多数商务Web站点都使用了cookie。

cookie技术有4个组件:

  • 在HTTP响应报文中的一个cookie首部行;
  • 在HTTP请求报文中的一个cookie首部行;
  • 在用户端系统中保留有一个cookie文件，并由用户的浏览器进行管理;
  • 位于Web站点的一个后端数据库。

cookie使用场景：

假设Susan总是从家中PC使用Internet Explorer ± 网，她首次与Amazon, com联系。我们假定过去她已经访问过eBay站点。当请 求报文到达该Amazon Web服务器时，该Web站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。接下来Amazon Web服务器用一个包含Set-cookie:首部的HTTP响应报文对Susan的浏览器进行响应，其中Set-cookie:首部含有该识别码。

例如，该首部行可能是 SET-Cookie：1234

当Susan的浏览器收到了该HTTP响应报文时，它会看到该Set-cookie:首部。该浏览器在它管理的特定cookie文件中添加一行，该行包含服务器的主机名和在Set-cookie: 首部 中的识别码。值得注意的是该cookie文件已经有了用于eBay的表项，因为Susan过去访问过 该站点。当Susan继续浏览Amazon网站时，每请求一个Web页面，其浏览器就会查询该cookie文件并抽取她对这个网站的识别码，并放到HTTP请求报文中包括识别码的cookie首部行中。特别是，发往该Amazon服务器的每个HTTP请求报文都包括以下首部行:

cookie：1234

在这种方式下，Amazon服务器可以跟踪Susan在Amazon站点的活动。尽管Amazon Web站点不必知道Susan的名字，但它确切地知道用户1234按照什么顺序、在什么时间、访问了哪些页面! Amazon使用cookie来提供它的购物车服务，即Amazon能够维护Susan 希望购买的物品列表，这样在Susan结束会话时可以一起为它们付费。

当用户向一个基于Web的电子邮件系统(如Hotmail)注册时，浏览器向服务器发送cookie信息，允许该服务器在用户与应用程序会话的过程中标识该用户。

# 1.2.3 Web缓存

Web缓存器(Webcache)也叫代理服务器(proxy server),它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间, 并在存储空间中保存最近请求过的对象的副本。

Web缓存器能从整体上大大减低因特网上的Web流量，从而改善了所有应用的性能。

通过使用内容分发网络(Content Distribution Network, CDN) , Web缓存器正在因特网 中发挥着越来越重要的作用。CDN公司在因特网上安装了许多地理上分散的缓存器，因而 使大量流量实现了本地化。有多个共享的CDN (例如Akamai和Limelight)和专用的CDN(例如谷歌和Netflix)

# 2 SMTP

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

每台邮件服务器上既运行SMTP的客户端也运行SMTP的服务器端。当一个邮件服务器向 其他邮件服务器发送邮件时，它就表现为SMTP的客户;当邮件服务器从其他邮件服务器 上接收邮件时，它就表现为一个SMTP的服务器。

SMTP用于从发送方的邮件服务器发送报文到接收方的邮件服务器。

一些流行的邮件访问协议，包括第三版的邮局协议(Post Office Protocol—Version 3 , POP3)、因特网邮件访问协议(Internet Mail Access Protocol, IMAP)以及 HTTP。

SMTP用来将邮件从发送方的邮件 服务器传输到接收方的邮件服务器;SMTP也用来将邮件从发送方的用户代理传送到发送 方的邮件服务器。如 POP3这样的邮件访问协议用来将邮件从接收方的邮件服务器传送到 接收方的用户代理。

image-20230505140055594

# 3 DNS 域名系统

DNS是:1一个由分层的DNS服务器(DNS server) 实现的分布式数据库;2一个使得主机能够查询分布式数据库的应用层协议。 DNS 服务器通常是运行 BIND ( Berkeley Internet Name Domain) 软 件 [BIND 2012 ] 的 UNIX机器。DNS协议运行在UDP之上，使用53号端口。

DNS通常是由其他应用层协议所使用的，包括HTTP、SMTP和FTP,将用户提供的主机名解析为IP地址。

DNS运行流程：

  1. 同一台用户主机上运行着DNS应用的客户端。
  2. 浏览器从上述URL中抽取岀主机名www.someschool.edu,并将这台主机名传给DNS应用的客户端。
  3. DNS客户向DNS服务器发送一个包含主机名的请求。
  4. DNS客户最终会收到一份回答报文，其中含有对应于该主机名的IP地址。
  5. 一旦浏览器接收到来自DNS的该IP地址，它能够向位于该IP地址80端口的 HTTP服务器进程发起一个TCP连接。

集中式服务的缺陷

  • 单点故障(a single point of failure)：如果该DNS服务器崩溃，整个因特网随之瘫痪!
  • 通信容量(traffic volume)。单个DNS服务器不得不处理所有的DNS査询(用于为 上亿台主机产生的所有HTTP请求报文和电子邮件报文服务)。
  • 远距离的集中式数据库(distant centralized database) 。单个DNS服务器不可能 “邻近”所有查询客户。如果我们将单台DNS服务器放在纽约市，那么所有来自 澳大利亚的查询必须传播到地球的另一边，中间也许还要经过低速和拥塞的链路。 这将导致严重的时延。
  • 维护(maintenance)。单个DNS服务器将不得不为所有的因特网主机保留记录。 这不仅将使这个中央数据库庞大，而且它还不得不为解决每个新添加的主机而频繁更新。

分布式、层次数据库

为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。没有一台DNS服务器拥有因特网上所有主机的映射。

大致说来，有3种类型的DNS服务器:根DNS 服务器、顶级域(TLD) DNS服务器和权威DNS服务器。

image-20230505152754780

DNS将域名转换为IP的流程：

假设主机 cse. nyu. edu 想知道主机 gaia. cs. umass. edu的IP地址。同时假设纽约大学(NYU)的 cse. nyu. edu主机的本地DNS服务器为 dns. nyu. edu, 并且 gaia. cs. umass. edu 的权威DNS服务器为dns. umass. eduo如图2・18 所示，主机cse. nyu. edu首先向它的本地DNS服务器dns. nyu. edu发送一个DNS查 询报文。该查询报文含有被转换的主机名 gaia. cs. umass. eduo本地DNS服务器将该 报文转发到根DNS服务器。该根DNS服器注意到其edu前缀并向本地DNS服务器 返回负责edu的TLD的IP地址列表。该本 地DNS服务器则再次向这些TLD服务器之一发送查询报文。该TLD服务器注意到 umass. edu前缀，并用权威DNS服务器的IP地址进行响应，该权威DNS服务器是负责马本地DNS服务器 dns.nyu.edu请求主机 cse.nyu.eduTLD DNS服务器权威DNS服务器根DNS服务器萨诸塞大学的dns. umass. edu.最后，本地DNS服务器直接向dns.• umass. edu重发查询报文,dns. umass. edu用gaia. cs. umass. edu的IP地址进行响应。注意到在本例中，为了获得 一台主机名的映射，共发送了 8份DNS报文:4份查询报文和4份回答报文!我们将很快明白利用DNS缓存减少这种査询流量的方法。

DNS的迭代查询与递归查询

迭代查询

image-20230505153111702

递归查询

image-20230505153738356

DNS缓存

DNS广泛使用了缓存技术。DNS缓存的原服务器接收一个DNS回答(例如，包含某 主机名到IP地址的映射)时，它能将映射缓存在本地存储器中。由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间后(通常设置为两天)将丢弃缓存的信息。

DNS报文

DNS查询和回答报文。DNS只有这两种报文，并且，查询和回答报文有着相同的格式，DNS报文中各字段的语义如下:

image-20230505154447258

对DNS的攻击

1.第一种针对DNS服务的攻击是分布式拒绝服务(DDoS)带宽洪泛攻击。例如，某攻击者能够试图向每个DNS根服务器发送大量的分组，使得大多数合法DNS请求得不到回答。

2.对 DNS的潜在更为有效的DDoS攻击将是向顶级域名服务器(例如向所有处理.com域的顶级域名服务器)发送大量的DNS请求。过滤指向DNS服务器的DNS请求将更为 困难，并且顶级域名服务器不像根服务器那样容易绕过。但是这种攻击的严重性通过本地 DNS服务器中的缓存技术可将部分地被缓解。

3.DNS能够潜在地以其他方式被攻击。在中间人攻击中，攻击者截获来自主机的请求并返回伪造的回答。在 DNS毒害攻击中，攻击者向一台DNS服务器发送伪造的回答, 诱使服务器在它的缓存中接收伪造的记录。这些攻击中的任一种，都能够将毫无疑虑的Web用户重定向到攻击者的Web站点。然而，这些攻击难以实现，因为它们要求截获 分组或扼制住服务器[Skoudis 2006]。

# 4 P2P文件分发

P2P与C-S结构相比文件分发时间的区别：

image-20230505160423095

当一个新的对等方Alice加入该洪流时，追踪器随机地从参与对等方 的集合中选择对等方的一个子集(为了具体起见，设有50个对等方)，并将这50个对等 方的IP地址发送给Aliceo Alice持有对等方的这张列表，试图与该列表上的所有对等方创 建并行的TCP连接。我们称所有这样与Alice成功地创建一个TCP连接的对等方为“邻近 对等方”，Alice显示了仅有三个邻近对等方。随着时间的流逝，这些对等方中的某些可能离开，其他对等可能试图与Alice创建TCP连接。因此一个对等方的邻近对等方将随时间而波动。

因此在任何给定的时刻，Alice将具有块的子集并知道它的邻居具有哪些块。利用这些信息，Alice将做出两个重要决定。第一，她应当从她的邻居请求哪些块呢?第二，她 应当向哪些向她请求块的邻居发送块?在决定请求哪些块的过程中，Alice使用一种称为**最稀缺优先(rarest Erst)**的技术。

这种技术的思路是，针对她没有的块在她的邻居中决定最稀缺的块(最稀缺的块就是那些在她的邻居中副本数量最少的块)，并首先请求那些最稀缺的块。这样，最稀缺块得到更为迅速的重新分发，其目标是(大致地)均衡每个块在 洪流中的副本数量。

# 5 视频流与内容分发网

视频是一系列的图像,通常以一种恒定的速率(如每秒24或30张图像)来展现。一幅未压缩、数字编码的图像由像素阵列组成，其中每个像素是由一些比特编码来表示亮度和颜色。视频的一个重要特征是它能够被压缩，因而可用比特率来权衡视频质量。

# 1.5.1HTTP 流和 DASH

在 HTTP流中，视频只是存储在HTTP服务器中作为一个普通的文件，每个文件有一 个特定的URL。

当用户要看该视频时，客户与服务器创建一个TCP连接并发送对该URL的HTTP GET请求。服务器则以底层网络协议和流量条件允许的尽可能快的速率，在一个

HTTP响应报文中发送该视频文件。在客户一侧，字节被收集在客户应用缓存中。一旦该 缓存中的字节数量超过预先设定的门限，客户应用程序就开始播放，特别是，流式视频应 用程序周期性地从客户应用程序缓存中抓取帧，对这些帧解压缩并且在用户屏幕上展现。因此，流式视频应用接收到视频就进行播放，同时缓存该视频后面部分的帧

经HTTP的动态适应性流(Dynamic Adaptive Streaming over HTTP, DASH) ：

在DASH中，视频编码为几个不同的版本，其中每个版本具有不同的比特率，对应于不同的质量水平。’客户动态地请求来自不同版本且长度为几秒的视频段数据块。当可用带宽量较高时，客户自然地选择来自高速率版本的块;当可用带 宽量较低时，客户自然地选择来自低速率版本的块。客户用HTTP GET请求报文一次选择 —个不同的块[Akhshabi 2011 ] 。

使用DASH后，每个视频版本存储在HTTP服务器中，每个版本都有一个不同的 URL。HTTP服务器也有一个告示文件(manifest file),为每个版本提供了一个URL及其比特率。然后客户通过在HTTP GET 请求报文中对每块指定一个URL和一个字节范围，一次选择一块。在下载块的同时，客 户也测量接收带宽并运行一个速率决定算法来选择下次请求的块。

内容分发网：

为了应对向分布于全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公 司都利用内容分发网(Content Distribution Network, CDN) o CDN管理分布在多个地理位置 上的服务器，在它的服务器中存储视频的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位 置。CDN可以是专用CDN (private CDN), 即它由内容提供商自己所拥有;例如，谷歌的 CDN分发YouTube视频和其他类型的内容。

CDN实例

  1. 用户访问位于NetCinema的 Web网页。
  2. 当用户点击链接http://video, netcinema. com/6Y7B23V时，该用户主机发送了一个对于 video, netcinema. com 的 DNS 请求。
  3. 用户的本地DNS服务器(LDNS)将该DNS请求中继到一台用于NetCinema的权威DNS服务器，该服务器观察到主机名video, netcinema. com中的字符串“video”。为了将 该DNS请求移交给KingCDN, NetCinema权威DNS服务器并不返回一个IP地址，而是向 LDNS返回一个KingCDN域的主机名，如al 105. kingcdn. com。
  4. 从这时起，DNS请求进入了KingCDN专用DNS基础设施。用户的LDNS则发送第 二个请求，此时是对al 105. kingcdn. com的DNS请求，KingCDN的DNS系统最终向LDNS 返回 KingCDN内容服务器的IP地址。所以正是在这里，在KingCDN的DNS系统中，指定了 CDN服务器.客户将能够从这台服务器接收到它的内容。
  5. LDNS向用户主机转发内容服务CDN节点的IP地址。
  6. 一旦客户收到KingCDN内容服务器的IP地址，它与具有该IP地址的服务器创建 了一条直接的TCP连接，并且发出对该视频的HTTP GET请求。如果使用了 DASH,服务 器将首先向客户发送具有URL列表的告示文件，每个URL对应视频的每个版本，并且客户将动态地选择来自不同版本的块。

image-20230505160423095

# 6. 套接字编程

在研发阶段，开发者必须 最先做的一个决定是，应用程序是运行在TCP±还是运行在UDP上。前面讲过TCP是面向连接的，并且为两个端系统之间的数据流动提供可靠的字节流通道。UDP是无连接 的，从一个端系统向另一个端系统发送独立的数据分组，不对交付提供任何保证。前面 也讲过当客户或服务器程序实现了一个由某RFC定义的协议时，它应当使用与该协议 关联的周知端口号;与之相反，当研发一个专用应用程序时，研发者必须注意避免使用这些周知端口号。

# 6.1 UDP套接字编程

使用UDP套接字的两个通信进程之间的交互。在发送进程能够将数据分组推出套接字之门之前，当使用UDP时，必须先将目的地址附在该分组之上。在 该分组传过发送方的套接字之后，因特网将使用该目的地址通过因特网为该分组选路到接 收进程的套接字。当分组到达接收套接字时，接收进程将通过该套接字取回分组，然后检查分组的内容并采取适当的动作。

不同语言都存在未网络通信专门设置的模块或者包。py的socket模块，java的io

UDPServer.py

from socket import *
serverPort = 5555
//AF_INET：ipv4, SOCK_DGRAM：udp，SOCK_STREAM：tcp
serverSocket = socket(AF_INET, SOCK_DGRAM) 
serverSocket.bind(('', serverPort))
print ("The server is ready to receive")
while True: 
    message,clientAddress = serverSocket.recvfrom(2048) 
    modifiedMessage = message.decode().upper()
    serverSocket.sendto(modifiedMessage.encode(), clientAddress)

UDPClient.py

from socket import *
serverName = 'localhost'
serverPort = 5555
clientSocket = socket(AF_INET, SOCK_DGRAM)
message ='Input lowercase sentence'
clientSocket.sendto(message.encode(),(serverName, serverPort))
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
print(modifiedMessage.decode())
alientSocket.close()

Server处于开启状态，client向server发送udp socket，server接受处理请求之后返回信息给client

# 6.2 TCP 套接字编程

这意味着在客户和服务器能够开始互相 发送数据之前，它们先要握手和创建一个TCP连接。TCP连接的一端与客户套接字相联 系，另一端与服务器套接字相联系。当创建该TCP连接时，我们将其与客户套接字地址(IP地址和端口号)和服务器套接字地址(IP地址和端口号)关联起来。使用创建的TCP 连接，当一侧要向另一侧发送数据时，它只需经过其套接字将数据丢进TCP连接。这与 UDP不同，UDP服务器在将分组丢进套接字之前必须为其附上一个目的地地址。

← HTTP详解 →