应用层简述

应用层体系结构

• 客户端-服务器架构(client-server architecture)
• 对等体系结构(peer-to-peer
  architecture)

客户/服务器方式（C/S方式）

：客户是服务的请求方，服务器是服务的提供方。首先有一台always-on的主机，我们叫做服务器，服务器为来自其他主机的请求提供服务。这些其他主机我们称之为客户端。

经典例子：Web应用
Web应用中的服务器为运行在客户端主机上的浏览器发出的请求提供服务。
当一个Web服务器收到一个客户端请求，客户端请求要一个object， 服务器就把the requested object发送给客户端。
注意，在客户端-服务器体系结构中，客户端之间不直接交流。
举个例子，在Web应用中，两个浏览器之间直接通信。

客户/服务器方式的另一个特征：

• 服务器有一个固定的 Well-known address， 叫做IP address（IP地址）
  因为服务器有一个固定的 Well-known address，并且服务器is always on。所以只要客户端给服务器的IP address发送一个分组，就可以联系到服务器了。

除了Web应用，采用客户端-服务器架构的应用还有：FTP， Telnet， email
通常在客户端服务器应用中，一个服务器主机无法跟上客户的所有请求，怎么办？我们把许多主机放在一个一起，构成一个数据中心，这就相当于创建了一个非常强大的虚拟服务器。

对等方式（P2P方式）：

即Peer-to-Peer方式，对等连接中的每一个主机既是客户又同时是服务器。在对等体系结构中，几乎不依靠数据中心中的服务器。应用程序在不定时连接的主机对之间进行通信。这些连接的主机对被称为peers（对等方）。
Peers不是由服务提供者拥有，而是被用户控制的桌面机和平板电脑，大多数peers都放在家里，大学和办公室。因为这些peers之间的通信不需要通过服务器，这个结构就叫做peer-to-peer。

今天许多非常受欢迎的，流量比较大的应用都是基于P2P。举个例子：

• 文件共享应用(BitTorrent)
• 迅雷
• 网络电话（skype)
• IPTV(e.g. KanKan and PPStream)
  
  P2P体系结构的优点：
  self scalability 自扩展性
  在p2p文件共享应用中，尽管每个peer在请求文件的时候都会产生工作负担，但是每个peer通过将这些文件分发给其他的peer.也为系统添加了服务能力。

混合体系结构 Hybrid

有些应用有混合体系结构，结合了客户端-服务器和P2P， 举个例子，许多的即时通信应用（例如QQ)。
服务器用来追踪用户的 IP 地址， 但是用户对用户消息是直接在用户主机之间进行的（没有通过服务器).

应用层进程通信

在操作系统的术语中，应用和进程是不同的，进程是running的应用。
当两个进程在同一个主机上的时候，直接在主机操作系统的指挥下进行通信就可以了
那么不同主机之间的进程是如何通信的呢？
答案是：通过计算机网络交换报文。

发送进程创建报文，然后将报文发送到网络中。
接收进程收到报文，可能会回复报文作为应答。

首先，网络应用包括了成对的通过网络彼此发送报文的进程。

• 在Web应用中，Web服务器进程和浏览器进程交换报文。
• 在P2P文件共享系统中，一个文件从peer的进程被传送到另一个peer的进程。

对每一对正在通信的进程，我们通常把一个进程标记为client,一个标记为server. （注意这里的标记和网络应用体系结构无关）

• 在Web应用中，一个浏览器就是一个client进程, 一个Web 服务器就是一个sever进程
• 在P2P文件共享系统中，正在下载文件的peer被标记为client, 正在上传文件的peer被标记为server。

在任意一个会话中，client只有一个，server只有一个。

标准定义： 最初发起通信会话的进程标记为client, 等待着被联系开始会话的进程就是server。

• 在Web应用中，浏览器进程初始化与 Web 服务器进程的联系；所以浏览器进程是client, Web服务器进程是server。
• 在P2P文件共享系统中，peerA 要求peerB 发送特定文件，peer A 是客户端，peer B 是此特定通信会话上下文中的服务器。

进程寻址

对通信来说，我们必须定义本地主机、本地进程、远程主机以及远程进程。我们使用 IP 地址来定义本地主机和远程主机，IP地址是一个32位的二进制串。为了定义进程，我们需要第二个标识符，称为端口号（ portnumber）。在 TCP/IP 协议簇中，端口号是在 0 到 65535 之间的 16 位整数。
客户程序用端口号定义它自己，这称为临时端口号（ ephemeral port number）。临时这个词表示短期的（ short-lived），它之所以被使用是因为客户的生命周期通常很短。为了客户-服务器程序能正常工作，临时端口号推荐值为大于 1023。
服务器进程必须使用一个端口号定义它自己。但是，这个端口号不能随机选择。TCP/IP 决定使用全局端口号；它们称为熟知端口号（ well-known port number）。 两个进程（客户和服务器）一般有相同的名字。

ICANN范围

熟知端口。端口号的范围是 0~1023，由 ICANN 分配和控制。这些是熟知端口号。
注册端口。端口号的范围是 1024~49151， ICANN 不分配也不控制。它们可在 ICANN 注册以防重复。
动态端口。端口号的范围是 49152~65535。这一范围内的端口号既不受控制又不需要注册，可以由任何进程使用。它们是临时或私有端口号。

套接字

如果说进程是个房子，那么套接字就是这个房子的门。

套接字是应用进程和传输层协议的接口。发送端的应用通过套接字推送消息。在接收端应用的socket, 传输层有责任将消息发送到接收进程的套接字。

应用程序开发者可以控制套接字在应用层一端的一切，但是几乎无法控制套接字在传输层端的东西。
应用程序开发者可以对套接字的传输层端控制以下东西：

• 传输层使用的什么协议？是TCP 还是 UDP? 一旦应用开发者选定了传输层使用的协议，应用就建立在由那个传输层协议提供的传输层服务之上
• 固定部分传输层的参数，例如最大缓存，最大报文段大小

套接字地址

在 TCP 协议簇中的传输层协议需要 IP 地址和端口号，它们各在一端建立一条连接。一个 IP 地址和一个端口号结合起来称为 套接字地址 （ socket address ）。

套接字Socket=（IP地址：端口号），套接字的表示方法是点分十进制的lP地址后面写上端口号，中间用冒号或逗号隔开。

运输服务类型

可靠数据传输

什么是可靠？不错、不丢、不乱
下图是可靠数据传输的框架。实现这种服务抽象是可靠数据传输协议的责任。

为上层实体提供的服务抽象是：数据可以通过一条可靠的信道进行传输。借助可靠信道，传输数据比特就不会受到损坏或丢失，而且所有的数据都是按照其发送顺序进行交付的。就我们而言，我们可以将较低层直接视为不可靠的点对点信道。

定时

rdt3.0: 信道既可能发生错误，也可能丢失分组

• 接收方通过ACK告知最后一个被正确接收的分组
• 在ACK消息中显示地加入被确认分组的序列号
• 发送方在接收到重复ACK之后，采取与收到NAK消息相同的动作：重传当前分组
• 发送方等待"合理"的时间，增加定时器

上面设计出来的rdt3.0虽然能够正确的工作，但是性能很差。此时设计的协议限制了物理资源的利用，因此协议必须要和硬件资源匹配，在计算机科学中称为软硬件协同设计。
解决性能问题的一个简单方法就是不采用停等方式运行，允许发送发发送多个分组无需等待确认。如下图所示，如果发送方可以在等待确认之前就发送三个报文，其利用率基本上也会提高三倍。因为许多从发送方向接收方属性的分组被看成是填充到一条流水线中，故这种技术也被称为流水线。

流水线技术也将对可靠数据传输协议带来如下影响：

• 必须增加序号范围，因为在每个传输中的分组（不计算重传的）必须有一个唯一的序号，而且也有许多在传输中为确认的报文。）

• 协议的发送方和接收方也许必须缓存多个分组。发送方最低限度应当能缓冲哪些已发送但是没有确认的分组，接收方或许也需要缓存哪些已经已正确接收的分组；
  

• 所需的序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延迟过大的分组

要想实现流水线机制，需要滑动窗口协议(Sliding-window protocol)

• 窗口:允许使用的序列号范围；窗口尺寸为N:最多有N个等待确认的消息
• 滑动窗口：随着协议的运行，窗口在序列号空间内向前滑动
• 滑动窗口协议：回退N步(Go-Back-N, GBN）和选择重传（Select Repeat，SR)。
• 
• 

![在这里插入图片描述](https://img-blog.csdnimg.cn/d00279620ff24286a



发送方的有效缓冲区是已发送未发送和未发送可发送

GBN（退回N重传协议）

在回退N步（GBN）协议中，允许发送方发送多个分组（当有多个分组可用时）而不需等待确认，但它也受限于在流水线中未确认的分组数不能超过某个最大允许数N。
基序号（base）：最早的未确认分组的序号
下一个序号（nextseqnum）：最小的未使用序号（即下一个待发分组的序号），则可将序号范围分割成4段。在【0，base - 1】段内的序号对应于已经发送并被确认的分组。【base，nextseqnum - 1】段内对应已经发送但未被确认的分组。【nextseqnum，base + N - 1】段内的序号能用于那些要被立即发送的分组，若有数据来自上层的话。最后，大于或等于base + N的序号是不能使用的，直到当前流水线中未被确认的分组（特别是序号为base的分组）已得到确认为止。

那些已被发送但还未被确认的分组的许可序号范围可以被看成是一个在序号范围内长度为N的窗口。随着协议的运行，该窗口在序号空间向前滑动。因此，N常被称为窗口长度，GBN协议也常被称为滑动窗口协议。
我们为什么先要限制这些被发送的、未被确认的分组数目为N呢？为什么不允许这些分组无限制的数目呢？流量控制是对发送方施加限制的原因之一。

在实践中，一个分组的序号承载在分组首部的一个固定长度的字段中。如果分组序号字段的比特数是k，则该序号范围是【0，2^k - 1】。在一个有限的序号范围内，所有涉及序号的运算必须使用模2 ^k运算（即序号空间可被看作是一个长度为2 ^k的环，其中序号2 ^k - 1 紧接着序号0。）。rdt 3.0有一个1比特的序号，序号范围是[0，1]。

GBN内容：

https://www.bilibili.com/video/BV1bP4y1T78P/?spm_id_from=333.788.recommend_more_video.1&vd_source=8519cc89f005aceb2b125924afce0022
(1)分组头部包含k-bit序列号
(2)窗口尺寸为N，最多允许N个分组未确认
(3)确认ACK(n): 确认到序列号n(包含n)的分组均已被正确接收，可能收到重复ACK
注：接收者仅发送累计的确认 ，如果中间有数据缺失，就不予以确认
(4)为传输的分组设置计时器(timer)，若超时Timeout(n): 重传序列号大于等于n，还未收到ACK的所有分组

发送方扩展FSM：

发送数据时要判断窗口是否已经满了
接收方扩展FSM：
若乱序到达的分组：
1.直接丢弃，接收方没有缓存
2.重新确认序列号最大的、按序到达的分组

窗口大小为4，发送方发送数据包0，1，2，3，然后进入等待状态，其中数据包2丢失，接收方返回Ack0，1，窗口滑动继续发送包4，5，此时包2计时超时，默认数据包2没有收到，按照GBN，发送方重新发送数据包2，3，4，5。这里可以看出数据包重复了。

练习题：数据链路层采用后退N帧（GBN）协议，发送方已经发送了编号为0～7的帧。当计时器超时时，若发送方只收到0、2、3号帧的确认，则发送方需要重发的帧数是多少？分别是那几个帧？
根据GBN协议工作原理，GBN协议的确认是累积确认，不会管中间所丢的数据包，所以，此时发送端需要重发的帧数是4个，依次分别是4、5、6、7号帧

SR(选择重传协议)

(1)接收方对每个分组单独进行确认, 设置缓存机制，为了缓存乱序到达的分组，发送方就不会再次发送，限制已发送且未确认的分组
(2)如果计时器到点, 仅重传该个未确认的数据报
(3)发送方窗口，N个连续的序列号， 发送者在流水线中最多有 N 个未确认的数据报
滑动窗口的大小为4，发送数据包0，1，2，3，窗口满了，停止发送，等待确认，其中数据包2丢失，依次确认数据包0，1，同时窗口向后移，依次发送数据包4，5，当数据包2超时，发送方会再次发送数据包2，同时缓存乱序到达的3，4，5，当接收完数据包2后，滑动窗口后移，发送方继续发送数据包

序列号空间大小与窗口尺寸需满足

若序号位数k位(SR协议)，发送窗口和接收窗口尺寸最大是2**-1,即序号空间一半。
避免发生接收序号重叠，出现重复分组

总结

停等(stop-and-wait )协议：发送方发送数据，然后等待接收方通过ACK或者NAK反馈
流水线协议(Pipelined protocols)：允许发送方发送多个分组而无需等待确认

解决流水线的差错恢复有两种基本方法（滑动窗口协议）：
1.回退N步(Go-Back-N，GBN)：回退N步，接收方则是只接受最小的未接受帧，对错序到达帧，都丢弃
2.选择重传(selective repeat，SR)：只重传丢失的帧，乱序到达的帧缓存起来

吞吐量

安全性

简单邮件传输协议（SMTP）

SMTP本身有很小的风险。黑客可能利用的是：
拒绝服务；
伪造E-Mail信息进行社会工程学欺骗；
发送特洛伊木马和病毒。

文件传输协议（FTP）

连接匿名FTP也必须提供用户名和密码，通用的用户名是anonymous，密码可以是任意字符，但是习惯上使用自己的e-mail地址。

超文本传输协议（HTTP）

超文本传输协议是Internet上应用最为广泛的通信协议之一。它采用可靠的TCP连接，且不维护用户连接状态，是一种无状态协议。通常的过程是：
1.浏览器与服务器建立连接；
2.浏览器向服务器请求文档；
3.服务器响应浏览器的请求；
4.断开连接。

远程连接服务标准协议（Telnet）

Telnet用于远程终端访问。Telnet是首先考虑有关安全的，因为它要求远程用户登录。但是，telnet使用明文发送所有的用户名和密码，因此可以被会话劫持。所以，Telnet使用前应考虑网络环境，不应该被用于公网。

可以使用SecureShell（SSH）来代替Telnet和UNIX下的r系列程序。SSH加密所有传输的数据，还允许通过公钥加密机制来进行认证。

简单网络管理协议（SNMP）

SNMP允许管理员检查状态，并修改SNMP节点的配置。它有2个组件，管理者负责收集所有SNMP节点发出的trap，并且直接从这些节点查询信息。SNMP通过UDP 161和162端口通信。

SNMP所提供的唯一认证就是community name（团体名称）。如果管理者和节点有着相同的community name，那么将允许所有SNMP查询。另一个安全问题是，所有的信息都是明文传输的。SNMP不应用在公网上。

域名系统（DNS）

DNS在解析DNS请求时使用UDP 53端口。一次区域传输是以下两种情况完成的，在进行区域传输时使用TCP。

1.一个客户端利用nslookup命令向DNS服务器请求进行区域传输；
2.一个从属于明服务器向主服务器请求得到一个区域文件。

黑客可以通过攻击DNS服务器得到它的区域文件，从而得到这个区域中所有系统的IP地址和名字。

因特网的运输服务

TCP

TCP提供的服务包括面向连接服务和可靠数据传输服务。当某个应用程序调用TCP作为其运输协议时，该应用程序就能获得TCP提供的这两种服务。

• 面向连接的服务：在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提醒客户和服务器，让它们为大量分组的到来做准备。在握手阶段之后，一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时收发报文。当应用程序结束报文发送时，必须拆除该连接。
• 可靠的数据传输服务：通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。
• TCP协议还具有拥塞控制机制，这种服务不一定通信进程带来直接好处，但能为因特网带来整体好处。当接收方和发送方之间的网络出现拥塞时，TCP拥塞控制会抑制发送进程。

UDP

UDP是一种不提供不必要服务的轻量级运输协议，它仅能提供最小服务。UDP是无连接的，因此在两个进程通信之前没有握手阶段。UDP协议提供一种不可靠的数据传输服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序的。
UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层注入数据。（然而，值得注意的是实际端到端的吞吐量可能小于该速率，这可能是因为中间的链路宽带受限或是因为拥塞而造成的）

SSL

应用层协议