文章目录
- 应用层
- HTTP
- 用户与服务器的交互:cookie
- Web缓存
- HTTP/2
- SMTP
- DNS:因特网的目录服务
- P2P文件分发
- BitTorrent
- CDN内容分发网
应用层
应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文。应用层协议定义了以下内容:
- 交换的报文类型,请求or响应
- 各种报文类型的语法,如报文中的各个字段以及这些字段是如何描述的
- 字段的语义,这些字段中信息的含义
- 确定一个进程何时以及如何发送报文,对报文进行响应的规则
HTTP
超文本传输协议(HyperText Transfer Protocal, HTTP),HTTP定义了HTTP报文的结构以及客户和服务器进行报文交换的方式。
- 非持续连接:每个请求/响应对是经一个单独的TCP连接请求
- 必须为每个请求的对象建立和维护一个全新的连接,客户端和服务器要分配TCP的缓冲区和保持TCP变量(负担)
- 每个对象经受两倍RTT的交付时延(创建TCP+请求和接收对象)
- 持续连接:所有的请求/响应经相同的TCP连接请求
HTTP/1.0采用非持续连接,每个TCP连接只传输一个请求报文和一个响应报文。非持续连接问题
HTTP/1.1使用带流水线的持续连接,必须等到完全收到对方的响应之后才会发出下一个请求。HOL问题
HTTP/2经单一TCP连接使请求与响应多路复用,允许多个请求同时通过同一个TCP连接,使得单个TCP连接上并行处理多个请求。连接建立时间长,TCP层面的队头阻塞和数据重传等
HTTP/3设计在QUIC(用UDP)之上运行的新HTTP
HTTP/3的主要改进点:
- 新的二进制格式:HTTP/3使用新的二进制格式,可以更有效地利用网络资源。
- 多路复用:HTTP/3使用多路复用技术,可以同时发送多个请求,而不用等待响应。
- 加密传输:HTTP/3使用加密传输,可以防止数据被窃听或篡改。
- 服务器推送:HTTP/3可以让服务器主动向客户端推送资源,而不需要客户端明确请求。
几大特点:
- 整合: HTTPP/3把TCP和TLS的握手整合在一起,使得连接建立更加快速,减少了延迟。对于恢复的会话,甚至不需要重新建立连接。
- QUIC协议:QUIC协议是一种新的传输层协议,旨在解决TCP协议的一些问题,比如在连接不稳定或者改变的情况下,仍然可以通过双方的协定,识别连接避免重复握手。
DASH:经HTTP的动态适应性流(Dynamic Adaptive Streaming over HTTP)。在DASH中视频被编码为不同质量的几个版本,使用不同的URL存储在HTTP服务器中,并用一个告示文件通知客户端版本
HTTP/2 | HTTP/3 |
---|---|
TLS | QUIC |
TCP | UDP |
IP | IP |
HTTP请求报文的通用格式:请求行+首部行+空行+实体体
- 方法
- GET:整个实体体为空,参数在URL中
?name&pwd
- POST:实体体中包含的就是用户在表单字段中的输入值
- HEAD:类似于GET,当服务器收到一个HEAD请求时,将会用一个HTTP报文进行响应,但是并不返回请求对象,调试跟踪
- PUT:允许用户上传对象到指定的Web服务器上指定的路径
- DELETE:允许用户或者程序删除Web服务器上的对象
- GET:整个实体体为空,参数在URL中
HTTP响应报文的通用格式:状态行+首部行+空行+实体体
- 状态码
- 200 OK:请求成功,信息在返回的响应报文中
- 301 Moved Permanently:请求的对象已经被永久转移了,新的URL定义在响应报文的
Location:
首部行中,客户软件将自动获取新的URL - 304 Not Modified:对象没被修改
- 400 Bad Request:一个通用差错代码,指示该请求不能被服务器理解
- 404 Not Found:被请求的文档不在服务器上
- 505 HTTP Version Not Supported:服务器不支持请求报文使用的HTTP版本
用户与服务器的交互:cookie
HTTP服务器是无状态的(HTTP服务器并不保存关于客户的任何信息),Web站点希望能够识别用户。因此HTTP使用了cookie(允许站点对用户进行跟踪),cookie可以标识一个用户,用户首次访问一个站点时,可能需要提供一个用户标识。在后续的会话中,浏览器向服务器传递一个cookie首部,从而向该服务器标识了用户。因此cookie可以在无状态的HTTP之上建立一个用户会话层。
cookie技术有4个组件:
- 在HTTP响应报文中的一个cookie首部行
- 在HTTP请求报文中的一个cookie首部行
- 在用户端系统中保留的一个cookie文件,并由用户的浏览器进行管理
- 位于Web站点的一个后端数据库
Web缓存
Web缓存器(Web cache)也叫代理服务器(proxy server),它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器中有自己的磁盘存储空间,并在存储空间中保存最近请求过的对象的副本
- Web缓存器可以大大减少对客户请求的响应时间
- Web缓存器能从整体上大大减少因特网上的Web流量,从而改善了所有应用的性能
可以配置用户的浏览器,使得用户的所有HTTP请求首先指向Web缓存器
条件GET方法:HTTP的一种允许缓存器证实它的对象是最新的机制。如果HTTP请求报文使用GET方法,并且请求报文中包含一个if-modified-since: Web站点上次响应报文中Last-modified: 首部行的值,web proxy缓存对象同时缓存time
首部行,那么这个HTTP请求报文就是一个条件GET请求报文
HTTP/2
HTTP/1.1中经单一TCP连接发送一个Web页面中的所有对象存在队首阻塞(Head Of Line blocking,HOL)问题(前面大对象的发送阻塞了小对象的发送),HTTP/1.1浏览器可通过打开多个并行的TCP连接,从而让同一Web页面的多个对象并行地发送给浏览器。TCP拥塞控制针对每条共享同一条瓶颈链路的TCP连接给出一个平等共享该链路的可用带宽,浏览器打开多个TCP能够“欺骗”并霸占更多带宽
HTTP/2的目标:
- 减少感知时延(main)
- 经单一TCP连接使请求与响应多路复用,提供
请求优先次序
和服务器推
和HTTP首部字段的有效压缩
。HTTP/2不改变HTTP方法、状态码、URL、首部字段,而是改变数据格式化方法
和客户与服务器之间的传输方式
- 经单一TCP连接使请求与响应多路复用,提供
- 减少传送单一Web页面时的并行TCP连接==>减少了需要服务器打开与维护的套接字数量
HTTP/2成帧:减小用户的感知时延
用于HOL阻塞的HTTP/2解决方案是将每个报文分成小帧,并在相同的TCP连接上交错发送请求和响应报文。HTTP/2可将一个HTTP报文(响应+请求)分成独立的帧、交错发送它们并在接收端将其装配起来。成帧的过程是通过HTTP/2协议的成帧子层来完成的,分帧,组装帧。成帧子层也可对帧进行二进制编码,二进制协议解析更为高效,会得到一些略小的帧,更不容易出错
响应报文的优先次序:
当客户向服务器发送并发请求时,客户能够为正在请求的响应确定优先次序(为每个报文分配1~256之间的权重,权重大优先级高)。通过权重,服务器能够为具有最高优先级的响应发送第一帧。客户也可指明相关的报文段ID,来说明每个报文段与其它报文段的相关性
服务器推:消除了因等待请求(这些请求是客户端收到HTML基本页响应后,再去请求所需的其它对象)而产生的额外时延
HTTP/2允许服务器为一个客户请求而发送多个响应。除了对初始请求的响应外,服务器能够根据HTML基本页向该客户推需要的对象,无须客户再进行任何请求
SMTP
因特网电子邮件系统:用户代理+邮件服务器+简单邮件传输协议(Simple Mail Transfer Protocal,SMTP,应用层协议,TCP,25)
SMTP是持续连接:如果发送邮件服务器有几个发往同一个接收邮件服务器,可通过同一个TCP连接发送这些报文,对于每个报文,客户可用一个新的MAIL FROM:
开始,用一个独立的句点指示该邮件的结束,并且当所有邮件发送完后才发送QUIT
如果不通过邮件服务器进行中继,发送方的用户代理将没有任何办法到达一个不可达的目的地邮件服务器
用户代理从邮件服务器取报文是一个拉操作,而SMTP是一个推协议
从邮件服务器取回邮件的方法:这两种方法都支持客户管理自己邮件服务器中的邮件
- HTTP:如果本地使用基于Web的电子邮件或手机上的客户端(如Gmail),则用户代理将使用HTTP来取回电子邮件,要求邮件服务器具有HTTP接口和SMTP接口(与其它邮件服务器通信)
- IMAP(因特网邮件访问协议,Internet Mail Access Protocol)
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr ... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with ”.” on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
可以使用telnet serverName 25
发送邮件
邮件报文格式:
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.
DNS:因特网的目录服务
主机可以使用主机名(不定长的字母数字组成,路由器难以处理,人喜欢)、IP地址(定长、有层次结构,路由器喜欢)来进行标识
域名系统(Domain Name System,DNS,UDP,53):一种能进行主机名到IP地址转换的目录服务
- 一个由分层的DNS服务器实现的分布式数据库
- 一个使得主机能够查询分布式数据库的应用层协议
DNS提供的服务:
- 主机名==>IP地址
- 主机别名:主机别名==>规范主机名、IP地址
- 邮件服务器别名:MX记录(DNS资源记录TYPE=MX)允许邮件服务器和Web服务器使用相同的主机名(别名)
- 负载均衡:一个IP地址集合与同一个规范主机名(大名)相联系
DNS服务器以层次方式组织,并且分布在全世界范围内:
- 根DNS服务器:提供顶级域服务器的IP地址
- 顶级域(TLD)DNS服务器:提供权威DNS服务器的IP地址
- 权威DNS服务器
- 本地DNS服务器:每个ISP都有一台本地DNS服务器,当主机与某个ISP连接时,该ISP提供一台主机的IP地址,该主机具有一台或多台其本地DNS服务器的IP地址
主机cse.nyu.edu
查询主机gaia.cs.umass.edu
的IP地址流程:
迭代查询:
DNS缓存:在一个请求链中,当某DNS服务器接收一个DNS回答时,该DNS服务器就能将映射缓存在本地存储其中。DNS服务器在一段时间后将丢弃缓存信息(主机和主机名与IP地址间的映射并不是永久的)。本地DNS服务器也能够缓存TLD服务器的IP地址。
DNS资源记录
共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(Resource Record,RR),资源记录提供了主机名到IP地址的映射。每个DNS回答报文包含了一条或多条资源记录。
资源记录是一个(Name, Value, Type, TTL)
四元组:
-
TTL:是该记录的生存时间,决定了资源记录应当从缓存中删除的时间
-
Type
- Type=A:Name是主机名;Value是该主机名对应的IP地址
(relay1.bar.foo.com, 145.37.93.126, A)
- Type=NS:Name是域;Value是一个知道如何获得该域中主机IP地址的权威DNS服务器的主机名
(foo.com, dns.foo.com, NS)
- Type=CNAME:Value是主机别名Name对应的规范主机名(大名)
(foo.com, relay1.bar.foo.com, CNAME)
- Type=MX:Value是一个别名为Name的邮件服务器的规范主机名(大名)。为了获得邮件服务器的规范主机名,DNS客户应当请求一条MX记录;为了获得其它服务器的规范主机名,DNS客户应当请求一条CNAME记录
(foo.com, mail.bar.foo.com, MX)
- Type=A:Name是主机名;Value是该主机名对应的IP地址
-
如果一台DNS服务器是某特定主机名的权威DNS服务器,那么该DNS服务器会有一条包含用于该主机名的类型A记录。即使该DNS服务器不是其权威DNS服务器,它也可能在缓存中包含一条类型A记录
-
如果服务器不是用于某主机名的权威服务器,那么该服务器将包含一条类型NS记录,该记录对应于包含主机名的域;它还将包含一条类型A记录,该记录提供了在NS记录的Value字段中的DNS服务器的IP地址
- 首部:
- 标识符:16bits,用于标识该查询,这个标识会被复制到对查询的回答报文中,以便让客户用它来匹配发送的请求和接收到的回答
- 标志
- 1bit的
查询0/回答1
标志位 - 1bit的
权威的
标志位 - 1bit的
希望递归
标志位 - 1bit的
递归可用
标志位
- 1bit的
- 问题数
- 回答RR数
- 权威RR数
- 附加RR数
- 问题:包含了正在进行的查询信息:名字字段(正在被查询的主机名)+类型字段(有关该名字的正被询问的问题类型)
- 回答:包含了对最初请求的名字的资源记录
- 权威:包含了其它权威服务器的记录
- 附加信息:包含了其它有帮助的记录
多播和任播
任播 (Anycast)
任播是一种网络通信方式,允许一个发送者将数据包发送给一组接收者中的任意一个,通常是距离最近或响应最快的接收者。任播常用于内容分发网络(CDN)、DNS服务等需要快速响应的应用场景。
特点:
- 数据包被路由到距离发送者最近的接收者,或根据其他优化策略选择接收者。
- 使用相同的IP地址分配给多个节点,网络路由协议决定数据包的最佳传输路径。
- 提高了服务的可用性和响应速度,减少了延迟。
多播 (Multicast)
多播是一种网络通信方式,允许一个发送者将数据包发送给多个接收者,但不是所有的网络节点都接收数据包。它的目的是提高网络效率,减少带宽消耗。多播通常用于视频会议、直播、在线游戏等需要将相同的数据发送给多个接收者的应用场景。
特点:
- 数据包只在需要的网络节点之间传输,减少了不必要的带宽使用。 使用特定的多播地址范围(IPv4中为224.0.0.0到239.255.255.255)。
- 需要网络设备(如路由器)支持多播协议(如IGMP,PIM)。
总结一下,多播是将数据发送给多个接收者,而任播是将数据发送给多个潜在接收者中的一个。两者都旨在提高网络效率,但应用场景和实现方式有所不同。
P2P文件分发
网络架构:
- C/S
- P2P
BitTorrent
BitTorrent(一种用于文件分发的流行的P2P协议)
洪流(torrent):参与一个特定文件分发的所有对等方的集合
每个洪流具有一个基础设施节点——追踪器。
- 当一个对等方加入某洪流时,它向追踪器注册自己,并周期性地通知追踪器它仍在洪流中
- 追踪器会随机地从参与对等方的集合中选择对等方的一个子集,并将子集IP发送给首次加入的对等方,并于子集建立TCP连接
- 请求,最稀缺优先:首先请求本对等方的邻居中副本数量最少的块==>均衡每个块在洪流中的副本数量
- 响应,周期性的测量每个邻居当前能够向自己提供数据的速率,优先选择4个速率高的邻居;每过30s,也要随机地选择一个邻居并传输数据
CDN内容分发网
主要的视频流公司都使用内容分发网(Content Distribution Network,CDN),CDN管理分布在多个地理位置上的服务器,在它的服务器中存储视频的副本,并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置,CDN可通过DNS来截获和重定向请求
- 专用CDN:内容提供商自己所拥有
- 第三方CDN:代表多个内容提供商分发内容
服务器安置原则:
- 深入:通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中
- 靠近用户,减少端用户和CDN集群之间链路和路由器的数量==>改善用户感受的时延和吞吐量
- 高度分布式设计==>维护和管理集群的任务困难
- 邀请做客:在因特网交换点(IXP)处建造大集群
- 用户的较高时延和较低吞吐量
- 较低的维护和管理开销
参考:
- 计算机网络:自顶向下方法