应用层原理
网络应用的体系结构
可能的应用架构： r
客户-服务器模式（C/S:client/server） r
对等模式(P2P:Peer To Peer) r
混合体：客户-服务器和对等体系
客户-服务器（C/S）体系结构
r 服务器:
m 一直运行
m 固定的IP地址和周知的端口号（约定）
m 扩展性：服务器场 •
对数据中心进行扩展 • 扩展性差
r 客户端:
m 主动与服务器通信
m 与互联网有间歇性的连接
m 可能是动态IP 地址
m 不直接与其它客户端通信
当用户超过一定数量时，性能会断崖式下滑
对等体（P2P）体系结构 r
（几乎）没有一直运行的服务器 r
任意端系统之间可以进行通信 r
每一个节点既是客户端又是服务器r
自扩展性-新peer节点带来新的 服务能力，当然也带来新的服务请求 r 参与的主机间歇性连接且可以改变IP 地址 r
缺点：难以管理 r 例子: Gnutella，迅雷
C/S和P2P体系结构的混合体
Napster
m文件搜索：集中 • 主机在中心服务器上注册其资源 • 主机向中心服务器查询资源位置
m文件传输：P2P • 任意Peer节点之间
即时通信
m在线检测：集中
•当用户上线时，向中心服务器注册其IP地址
•用户与中心服务器联系，以找到其在线好友的位置
m两个用户之间聊天：P2P
r进程为了接收报文，必须有一个标识 即：SAP（发送也需要标示）
m主机：1.唯一的 32位IP地址 •
仅仅有IP地址不能够唯一标示一个进程；在一台端系统上有很
多应用进程在运行
m2.所采用的传输层协议：TCP or UDP
m3.端口号（Port Numbers）
层间接口必须要携带的信息 m
要传输的报文（对于本层来说：SDU） m
谁传的：对方的应用进程的标示：IP+TCP(UDP) 端口 m
传给谁：对方的应用进程的标示：对方的IP+TCP(UDP)端口号 r 传输层实体（tcp或者udp实体）
根据这些信息进行TCP 报文段（UDP数据报）的封装 m
源端口号，目标端口号，数据等。
将IP地址往下交IP实体，用于封装IP数据报：源IP，目标IP
rTCP socket： m
TCP服务，两个进程之间的通信需要之前要建立连接 • 两个进程通信会持续一段时间，通信关系稳定 m
可以用一个整数表示两个应用实体之间的通信关系 ，本地标示。 m
穿过层间接口的信息量最小。m
TCP socket：源IP,源端口，目标IP，目标IP,目标 端口
TCP socket的四元组
四元组:源端系统ip、源端系统port、目标端系统ip、目标端系统port。
目标主机port:我客户端要通信的服务器是哪个进程。
源主机port:告诉目标主机我是源主机的哪个进程。
目标主机ip:客户端要通信的服务器主机在哪里。
UDP socket： m
UDP服务，两个进程之间的通信需要之前无需建立连接 •
每个报文都是独立传输的 •
前后报文可能给不同的分布式进程 m
因此，只能用一个整数表示本应用实体的标示 •
因为这个报文可能传给另外一个分布式进程 ·1 m
穿过层间接口的信息大小最小 m
UDP socket：本IP,本端口 m
传输报文时：必须要提供对方IP，port，接收报文时： 传输层需要上传对方的IP，port
传输数据时tcp需要 socket和数据本身；udp需要socket 数据和目的地 因为udp的socket里没有目的ip和端口
应用层协议 r
定义了：运行在不同端系统上 的应用进程如何相互交换报文 m
交换的报文类型：请求和应答报文m
各种报文类型的语法：报文中的各个字段及其描述 m
字段的语义：即字段取值的含义 m 进程何时、如何发送报文及对报文进行响应的规则 r 应用协议仅仅是应用的一个组成部分 m
Web应用：HTTP协议，web客户端，web服务器，HTML
公开协议： r
由RFC文档定义 r 允许互操作 r 如HTTP, SMTP 专用（私有）协议： r
协议不公开 r 如：Skype
图2-1
UDP存在的必要性 r
1.能够区分不同的进程，而IP服务不能 m 在IP提供的主机到主机端到端功能的基础上，区分了主机的应用进程 r
2.无需建立连接，省去了建立连接时间，适合事务性的应用 r
3.不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用 m 因为为了实现可靠性（准确性、保序等），必须付出时间代价（检错重发） r
4.没有拥塞控制和流量控制，应用能够按照设定的速度发送数据 m （在TCP上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制。）
图2-2
安全TCP
TCP & UDP r 都没有加密 r 明文通过互联网传输 ，甚至密码
SSL
r 在TCP上面实现，提供加密的TCP连接，具有私密性和数据完整性，并可以完成端到端的鉴别。
SSL在应用层 r 应用采用SSL库，SSL库使用TCP通信。
http + SSL = https
Web 与 HTTP
图2-3
HTTP是无状态的 r
服务器并不维护关 于客户的任何信息 维护状态的协议很复杂！ r
1.必须维护历史信息(状态) r
2.如果服务器/客户端死机，它们的状态信息可能不一致， 二者的信息必须是一致 r
3.无状态的服务器能够支持更多的客户端
HTTP/1.0和HTTP/1.1的区别：
HTTP/1.0使用非持久HTTP，最多只有一个对象在 TCP连接上发送，下载多个对象需要多个TCP连接。
HTTP/1.1默认使用非持久HTTP,多个对象可以在一个（在客户端和服务器 之间的）TCP连接上传输。
往返时间RTT（round-trip time）：一个小的分组从客户端到服务器，在回到客户端的时间（传输时间忽略）
非持久HTTP中一个对象的TCP响应时间：一个RTT用来发起TCP连接，一个 RTT用来HTTP请求并等待HTTP响应，文件传输时间共计：2RTT+传输时间
非持久HTTP的缺点： r
每个对象要2个RTT r
操作系统必须为每个TCP连接分配资源 r
但浏览器通常打开并行TCP连接 ，以获取引用对象持久HTTP r
服务器在发送响应后，仍保持TCP连接 r
在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送 r
客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求
HTTP请求报文: ASCII (人能阅读)
格式：见图1-3
图2-4
TCP不提供维护报文边界的服务，若s端应用层向下传输两个15k的分组，c端TCP会向上传输30k的分组。所以所有TCP上层的应用进程都是自己维护报文边界。
HTTP响应状态码
一些状态码的例子：
200 OK m 请求成功，请求对象包含在响应报文的后续部分
301 Moved Permanently m 请求的对象已经被永久转移了；新的URL在响应报文的Location: 首部行中指定，客户端软件自动用新的URL去获取对象
400 Bad Request m 一个通用的差错代码，表示该请求不能被服务器解读
404 Not Found m 请求的文档在该服务上没有找到
505 HTTP Version Not Supported http服务器不支持请求中使用的 HTTP 版本。
Telnet 工具尝试
Cookie用于状态维护
4个组成部分：
1) 在HTTP响应报文中有一个cookie的首部行
2)在HTTP请求报文含有一个cookie的首部行
3) 在用户端系统中保留有一个cookie文件，由用户的浏览器管理
4) 在Web站点有一个后端数据库
如何维持状态：
v1.协议端节点：在多个事务上，发送端和接收端维持状态
v 2.cookies: http报文携带状态信息
Cookies与隐私：
r Cookies允许站点知道许多关于用户的信息
r 1.可能将它知道的东西卖给第三方
r 2.使用重定向和cookie的搜索引擎还能知道用户更多的信息
m 3.如通过某个用户在大量站点上的行为，了解其个人浏览方式的大致模式
r 4.广告公司从站点获得信息
Web缓存 (代理服务器)(缓存既是客户端又是服务器)
目的：不访问原始服务器，就满足客户的请求。
用户设置浏览器： 通过缓存访问Web浏览器将所有的HTTP 请求发给缓存。m
对象在缓存中：缓存直接返回对象 m
如对象不在缓存，缓存请求原始服务器（此时缓存为客户端），然后再将对象返回给客户端
为什么要使用Web缓存？原因（访问具有趋同性，80%的人访问互联网上20%的内容zipf分布）
降低客户端的请求响应时间。
可以大大减少一个机构内部网络与Internent接入链路上的流量
互联网大量采用了缓存：可以使较弱的ICP也能够有效提供内容
——————————————第七版删去了
FTP协议介绍
有状态的协议（与http对比）
抓包维护软件vsftpd
控制连接与数据连接分开如下图所示。
图2-5
FTP客户端与FTP服务器通过端口21联系，客户端通过控制连接获得身份确认，然后客户端通过控制连接发送命令浏览远程目录。服务器收到一个文件传输命令时，服务器打开一个到客户端的数据连接（服务器的20号端口，主动向客户端的一个临时端口建立连接）一个文件传输完成后，服务器关闭连接。然后服务器打开第二个TCP数据连接用 来传输另一个文件。
FTP服务器维护用户的状态信息： 当前路径、用户帐户与控制连接对应。
EMAIL邮件
发送过程：
用户——>邮件服务器——>目标邮件服务器——>目标用户
其中,第一二跳用的是SMTP协议,最后一条可以用pop3,IMAP,http等协议
IMAP可以实现web客户端与服务器同步，pop3不可以
图2-6
POP3与 IMAP
POP3
r 先前的例子使用 “下载并删除”模式,如果改变客户机，Bob不
能阅读邮件。
r “下载并保留”：不同客户机上为报文的拷贝
r POP3在会话中是无状态的,只能本地管理文件夹
IMAP
r IMAP服务器将每个报文与一个文件夹联系起来
r 允许用户用目录来组织报文
r 允许用户读取报文组件
r IMAP在会话过程中保留用户状态： m 目录名、报文ID与目录名之间映射
DNS 完成域名到ip地址的转化
DNS名字空间(The DNS Name Space)
r DNS域名结构
m 一个层面命名设备会有很多重名
m DNS采用层次树状结构 命名方法
m Internet 根被划为几百个顶级域(top lever domains)
通用的(generic)
.com; .edu ; .gov ; .int ; .mil ; .net ; .org
.firm ; .hsop ; .web ; .arts ; .rec ;
国家的(countries)
.cn ; .us ; .nl ; .jp
m 每个(子)域下面可划分为若干子域(subdomains)
m 树叶是主机
域名管理
一个域管理其下的子域
.jp 被划分为 ac.jp co.jp
.cn 被划分为 edu.cn com.cn
创建一个新的域，必须征得它所属域的同意
域与物理网络无关
域遵从组织界限，而不是物理网络 •
一个域的主机可以不在一个网络 •
一个网络的主机不一定在一个域
域的划分是逻辑的，而不是物理的
区域(zone)
m 区域的划分有区域管理者自己决定
将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分
名字服务器： •
每个区域都有一个名字服务器：维护着它所管辖区域的权威信息(authoritative record) •
名字服务器允许被放置在区域之外，以保障可靠性.
TLD服务器
r 顶级域(TLD)服务器：负责顶级域名（如com, org, net, edu和gov）和所有国家级的顶级域名（如cn, uk, fr, ca, jp ）
区域名字服务器维护资源记录
资源记录(resource records)
作用：维护 域名-IP地址(其它)的映射关系
m 位置：Name Server的分布式数据库中
RR格式: (domain_name, ttl, type,class,Value)
Domain_name: 域名
Ttl: time to live : 生存时间(权威，缓冲记录)
Class 类别 ：对于Internet，值为IN
Value 值：可以是数字，域名或ASCII串
Type 类别：资源记录的类型。见图2-7
图2-7
名字解析过程
递归查询见图2-8
图2-8
特点：名字解析负担都 放在当前联络的名字服务器上
缺点：根服务器的负担太重
迭代查询 见图2-9
图2-9
过程：根（及各级域名）服务器返回的不是查询结果，而是下一个NS的地址最后由权威名字服务器给出解析结果。
DNS报文格式
报文首部
r标识符（ID）：16位
r flags: m 查询/应答 m 希望递归 m 递归可用 m 应答为权威
图2-10
提高性能：缓存
l 一旦名字服务器学到了一个映射，就将该映射缓存起来
l 根服务器通常都在本地服务器中缓存着
m 使得根服务器不用经常被访问
l 目的：提高效率
l 可能存在的问题：如果情况变化，缓存结果和权威资源记录不一致
l 解决方案：TTL（默认2天）
维护问题：新增一个域
r 在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名 和 域名服务器的地址
r 在新增子域的名字服务器上运行名字服务器，负责本域的名字解析：名字->IP地址
攻击DNS
1.DDoS 攻击
r (1)对根服务器进行流量轰炸攻击：发送大量ping m 没有成功 m
原因１：根目录服务器配置了流量过滤器，防火墙 m
原因２：Local DNS 服务器缓存了TLD服务器的IP地址，因此无需查询根服务器
(2)向TLD服务器流量轰炸攻击：发送大量查询 m
可能更危险，但效果一般，大部分DNS缓存了TLD
2.重定向攻击
r (1)中间人攻击 m 截获查询，伪造回答，从而攻击某个（DNS回答指定的IP）站点
r (2)DNS中毒 m 发送伪造的应答给DNS服务器，希望它能够缓存这个虚假的结果
(3)分布式截获和伪造：技术上较困难
4.利用DNS基础设施进行DDoS
r (1)伪造某个IP进行查询， 攻击这个目标IP
r (2)查询放大，响应报文比查询报文大
r (3)效果有限
——————————————
纯p2p架构
没有（或极少）一直运行的服务器
任意端系统都可以直接通信
利用peer的服务能力
Peer节点间歇上网，每次IP地址都有可能变化
例子:文件分发 (BitTorrent)，流媒体(KanKan)，VoIP (Skype)
C/S 与 P2P的对比
文件分发时间: C/S模式
服务器传输： 都是由服务器发送给peer，服务器必须顺序传输（上载）N个文件 拷贝: NF/us
客户端: 每个客户端必须下载一个文件拷贝 §
dmin = 客户端最小的下载速率 §
下载带宽最小的客户端下载的时间：F/dmin
Dc/s > max{NF/us,,F/dmin}
文件分发时间: P2P模式
服务器传输：最少需要上载一份拷贝,发送一个拷贝的时间：F/u
客户端: 每个客户端必须下载一个拷贝最小下载带宽客户单耗时：: F/dmin
客户端: 所有客户端总体下载量NF § 最大上载带宽是：us+ ∑ui § 除了服务器可 以上载，其他所有的peer节点都可以上载。
DP2P > max{F/us,,F/dmin,,NF/(us + ∑ui )}
但因为节点数量多，可管理性较差。
P2P管理模式
非结构化P2P
结构化P2P/基于分布式散列表的（DHT）P2P系统
非结构化P2P
P2P文件共享
问题：
如何定位所需资源
如何处理对等方的加入与离开
解决方案：集中 m分散 m半分散
集中式目录管理：
最初的“Napster”设计
1) 当对等方连接时，它告知中心服务器： m IP地址 m 内容
2) Alice查询 某个文件时，服务器返货该文件所在地的ip（bob）
3) Alice从Bob处请求文件
缺点
r 单点故障：文件传输是分散的，而定位内容则是高度集中的
r 性能瓶颈 侵犯版权
e.g. Napster
完全分布式：
泛洪查询，类似BFS。
r 在已有的TCP连接上发送查询报文
r 对等方转发查询报文
r 以反方向返回查询命中报文
对等方加入过程
1. 对等方X必须首先发现某些已经在覆盖网络中的其他对等方：使 用可用对等方列表自己维持一张对等方列表（经常开机的对等方的IP）
联系维持列表的Gnutella站点
2. X接着试图与该列表上的对等方建立TCP连接，直到与某个对等方 Y建立连接
3. X向Y发送一个Ping报文，Y转发该Ping报文
4. 所有收到Ping报文的对等方以Pong报文响应IP地址、共享文件 的数量及总字节数
5. X收到许多Pong报文，然后它能建立其他TCP连接
同理由对等方的退出
e.g. Gnutella
混合式
1.每个文件有一个散列标识码和一个描述符
2.客户端向其组长发送关键字查询
3.组长用匹配进行响应：
对每个匹配：元数据、散列标识码和IP地址
4.如果组长将查询转发给其他组长，其他组长也以匹配进行响应
5.客户端选择要下载的文件
e.g. KazaA，bittorrent
P2P文件分发： BitTorrent
文件被分为一个个块256KB。将一个文件分成若干个256kb的分组，然后用一个数 bitmap来表示对这个文件若干分组的拥有情况，即状态压缩。然后定期在torrent 中交换bitmap。
网络中的这些peers发送接收文件块，相互服务。
Peer加入torrent后：
当peer下载时，该peer可以同时向其他节点提供上载服务。
Peer可能会变换用于交换块的peer节点。 v
扰动churn: peer节点可能会上线或者下线：一旦一个peer拥有整个文件，它会（自私的）离开或者保留（利他主义）在torrent中（Torrent（洪流）: 节点的组，之间交换文件块）。
请求，发送文件块
请求块：
r 在任何给定时间，不同peer节点拥有一个文件块的子集。
r Alice节点周期性的向邻居询问他们拥有哪些块的信息。
r Alice向peer节点请求它希望的块，稀缺的块。
发送块：一报还一报titfor-tat
Alice选择提供最大带宽的服务的4个peer发送块，（除了5个对等方见书97页）其他peer被Alice阻塞 (将不会从Alice处获得服务) 。每10秒重新评估一次。若Alice为新进入的块，即bitmap各位为0，则优先请求洪流中稀缺的块。
每隔30秒：随机选择其他peer节点，Alice向这个节点发送块，“优化疏通” 这个节点 。
结构化P2P
Chord环，了解
——————————————
CDN
视频压缩：利用时间和空间冗余等进行压缩。关键帧
多媒体流化服务：DASH
DASH: Dynamic, Adaptive Streaming over HTTP动态自适应http流化
服务器: § 将视频文件分割成多个块，每个块独立存储，编码于不同码率（8-10种）
告示文件（manifest file）: 提供不同块的URL
v 客户端: § 先获取告示文件 § 周期性地测量服务器到客户端的带宽 § 查询告示文件,在一个时刻请求一个块，HTTP头部指定字节范围。如果带宽足够，选择最大码率的视频块。
•会话中的不同时刻，可以切换请求不同的编码块 (取决于当时的可用带宽)。
CDN (Content Distribution Networks)
挑战: 服务器如何通过网络向上百万用户同时流化视频内容 (上百万视频内容)?
r 选择1: 单个的、大的超级服务中心“megaserver”
m 服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
m “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）
m 单点故障点，性能瓶颈
m 会造成周边网络的拥塞
评述：相当简单，但是这个方法不可扩展
选项2: 通过CDN，全网部署缓存节点，存储服务
内容，就近为用户提供服务，提高用户体验
m 1）enter deep: 将CDN服务器深入到许多接入网，更接近用户，数量多，离用户近，但管理困难
•e.g.Akamai, 1700个位置
m 2）bring home: 部署在少数(10个左右)关键位置，如将服务器簇安装于POP附近（离若干1stISP POP较近）
•采用租用线路将服务器簇连接起来
•e.g.Limelight
同一个端口不能绑定两个TCP/UDP进程，但是可以同时绑定一个TCP一个UDP进程
TCP socket
重要结构体
struct sockaddr_in
{
uint8_t sin_len;
sa_family_t sin_family;
in_port_t sin_port;
struct in addr sin_addr;
char sin_zero[8];
};
struct in_addr
{
uint32_t s_addr;
｝;
UDP socket
见网络编程学习内容
标签：HTTP,IP,自顶,TCP,计算机网络,服务器,第二章,报文,客户端 From： https://www.cnblogs.com/fakeeyes-personal-blogs/p/17555867.html