Ch2 应用层

1. 网络应用

1.1 网络应用架构

• client-server, CS | server
  - 主机持续在线
  - 永久IP
  - 用于拓展(scale)的服务器场(server farms)
  | | | —- | :—-: | | clients
  - 间歇连接
  - 可变IP
  - Client之间不会直接交流
  | |

• peer**-to-peer, P2P** | pure p2p
  - 服务器非持续在线
  - 任意(arbitrary)端系统直接通信
  - 节点间歇连接,IP可变
  | | | —- | :—-: | | 特点
  - 高可扩展(highly scalable),难以管理
  - 对等方IP动态化,如何发现
  | |

• CS** & P2P**混合

比如QQ,当登录后获取联系人列表,为CS模式,单人用户之间聊天,为P2P模式

1.2 进程通信

• socket

进程通过套接字这个网络接口向网络发送/接收message

• 进程寻址

在因特网中使用”IP地址+端口号port number”来唯一标识网络上的进程,可以类比Linux中的pid

   ports/system ports,其中很多端口固定分配给系统某种服务使用<br />- 1024-49151:
   registered ports,分配给用户或应用程序进程<br />- 49152-65535:dynamic
   ports,一般不固定分配某种服务<br /> |

• 应用程序对传输服务的需求

①Data loss:丢包,如视频,通话可掉帧,但游戏需要实时性
②Timing:延迟,一些apps需要低延迟
③Throught:吞吐量,一些apps可能需要最小吞吐量来保证效率,其余可能需要弹性的按需分配
④安全性:加密(encryption),数据完整性

• 因特网传输协议服务(TCP/UDP是传输层协议)⭐ | | TCP 服务 | UDP 服务 | | —- | —- | —- | | 意义 | 由于分组交换中没有建立连接,packet传到哪里完全由网络核心的routers们决定,可能出现问题:
  
  1. packet走不同的link到达
     
  2. 由于link不同,packet可能乱序或丢包 因此,端系统上的传输层必须进行控制=>TCP传输控制协议 | 用户数据报协议,实现简单,发送速度快 | | 支持 |
     - connection-oriented:面向连接
     - reliable transport:可靠传输
     - flow control: 流控,为了避免receiver的buffer满导致丢包,需要进行流控
     - congestion control:拥塞控制
     |
     - unreliable transport
     | | 不支持 |
     - timing
     - minimum throughtput guarantee
     - security
     |
     - connection setup
     - reliability
     - flow control
     - congestion control
     - timing
     - minimum throughtput guarantee
     - security
     | | 应用 | 邮件,远程连接,web | 流媒体,DNS,网管协议 | | 对比 | UDP实现简单速度快;TCP为了可靠性需要大量约束
     企业为了并取优点,大都自己设计应用层协议实现原有传输层TCP中的可靠性保证,在传输层采用UDP协议,这样又能保证速度
     | |

2. Web和HTTP

2.1 HTTP概述

名称	超文本传输协议 hypertext transfer protocol
位置	应用层
架构	CS
特点	- 基于TCP协议,需建立TCP连接再传递HTTP

request/response(三次握手),传输结束需要关闭TCP连接(四次挥手)
- 无状态**,** stateless:S无法保存过往的C任何requests
| |

2.2 持久/非持久

• 背景 | 典型的HTTP传输场景 | 关于RTT(round-trip time, 往返时间) | | —- | —- | | | | | 建立TCP连接 ->传递HTTP请求/响应 ->TCP连接关闭 | RTT是一个packet在CS之间往返的时间 | | 三次握手+HTTP RR传输=2RTT | | | | | | 问:一个TCP可以携带几个不同的HTTP请求:
  通过三次握手说明,只有持久连接时才能携带一个以上的不同HTTP请求** | |

• 四种HTTP连接方式⭐ | nonpersistent | 每个R/R对经过一个单独的TCP连接发送 | | —- | —- | | np + cocurrent TCP | 虽然每个R/R使用单独TCP,但TCP可同时创建 | | persistent | 所有的R/R对可通过一个TCP连接发送,由此可知,只有在persistent连接中,一个TCP才能携带多个HTTP请求,依次处理 | | (**默认)p + pipeline
  (无等待HTTP) | 无需等待之前的response返回,可一次性发出所有request,近似为同一时间全部发出(pipeline看似想同时处理HTTP请求,但实践困难**,虽然服务器端默认开启,但现代浏览器默认关闭) |

例题⭐

1. 先请求页面=>2RTT(3次握手+HTTP RR)
   2. 对html中的三幅图片:
   当为np时,每个图片也需要2RTT=>3*2RTT;
   当为cTCP时,相当于只有一幅图片=>2RTT;
   当为p时,无需重建TCP,每个图片需要RTT=>3*RTT
   当为PP时,相当于一幅图片且无需重建TCP=>RTT | |
   2.
   (设传播时延为ds) | | |
   1. 非持续并行
   
   深入分析以上非持续并行的2RTT构成
   | | |
   2. 持续非流水线
   深入分析以上非持续非流水线的2RTT+10RTT’构成
   | | |
   3. 扩展:当是持续且带流水线
   2RTT+RTT’+9*100k/R
   - 流水线可以认为host只有一个RTT’,但无法忽略server发送时的queuing delay
   | |

2.3 HTTP请求报文

HTTP协议有request和response两类报文,下图为报文形式,无需死记硬背

request	response
GET/POST/HEAD区别 - GET在page传参数是将参数直接放在地址最后 - POST将参数放在request body,不明文表示 - HEAD类似GET但常用于开发测试,不返回请求对象	Connection控制是否为持久连接

2.4 Cookies

构成
流程

2.5 Web cache

构成	web cache既是client也是server:在本地存储副本传输给客户;又向原始server发出request
作用	- web cache大大减少client的response** time**,尤其是当客户和原始server间有bottleneck link时 - web cache可以减少机构的接入链路到internet的通信量

3. FTP

- FTP协议是一种不安全的文件传输协议,明文保存数据 - FTP使用一种”(控制信息)带外传输”技术(out of band):使用双TCP连接,control con建立在21端口用于控制连接,浏览目录等;当需要传递数据,在20端口建立data con

3.1 对比HTTP

• 相同点:

①都是app层协议
②都以TCP作为支持的运输层协议
③都是client-server架构,区分服务器端和客户端

• 不同点 | | HTTP | FTP | | —- | —- | —- | | 面向对象 | 超文本传输,面向网页 | 文件传输协议,面向文件 | | 端口 | 默认80 | 默认20,21 | | 传输 | 单TCP连接,控制信息带内传输 | 双TCP连接,控制信息带外传输 | | 状态 | 无状态 | 会话期间保留用户state | | 持久性 | 默认持久且带流水线,可转换 | 控制连接persistent,数据non-persistent |

4. 电子邮件

| 一个典型的电子邮件系统如右图,主要由三部分构成:
- user agents:用户代理,负责向服务器中上传/收取信息,负责编辑阅读消息,比如outlook,iPhone mail
- mail servers:存放用户接收到的消息
- SMTP:在mail servers之间发送/接收邮件信息的协议(接收不包括user agent从server中接收信息,这一过程由别的协议负责)
| | | —- | :—-: |

4.1 发送协议

simple mail transfer protocol是一种发送协议

    receiving server<br />- 三个阶段(类比HTTP传输)<br />   - handshaking<br />   - transfer of messages<br />   - close<br /> |

| 举例 |
①②③A打开Outlook写信->Outlook发送给A.server (SMTP)
④——>A.server和B.server建立TCP连接——> (SMTP)
⑤⑥B.server中信息被Gmail读取->B在Gmail上查看邮件 (POP3/IMAP…) |

• 对比HTTP | SMTP | HTTP | 共同点 | | :—-: | :—-: | :—-: | |
  - SMTP是一个push(推)的协
  - SMTP使用persistent连接
  - 每个对象被封转在自己的response msg中
  |
  - HTTP是一个pull(拉)的协
  - HTTP的连接方式分p/nonp
  - 大量的对象被封装在一个multipart msg中
  | 都有基于ASCII的command/response交互,状态码 |

4.2 获取协议

• POP3(Post Office Protocol)

POP协议负责agent<—>server的授权和下载,无状态

• IMAP(Internet Mail Access Protocol)

IMAP更复杂,且能控制msgs在server上的存储,有状态

• HTTP

Web邮件系统,HTTP可以代替POP3/IMAP完成agent<—>server之间的传输,但依旧无法取代SMTP

5. DNS

5.1 概述

用户host上的浏览器/邮件阅读器需要把host name转换为IP地址时:
1. 首先调用DNS客户端,指明被转换的主机名;
1. DNS收到主机名,向网络发送msg
(所有请求和回答msgs都使用传输层UDP数据报通过53端口发送);
1. 经过时延后,host上的DNS接收到回答msg,再传递给调用的应用程序.
| | |
- 主机别名 host aliasing: 比如baidu.com实际上为一个别名
- 邮件服务器别名
- 负载均衡 load distribution
热门站点的Web服务器被冗余的分布在多台服务器,每台服务器所在端系统有不同IP,但所有IP的集合对应着一个规范host name,为了防止客户只对排在最前面的IP访问导致服务器负载不均,DNS会循环地址的次序,分配负载 |

• 非集中式(centralized)DNS的原因 |
  - single point of

    failure:单个DNS server崩溃internet瘫痪<br />- traffic volume:通信容量,单个server会处理所有查询<br />- distant centralized
    database:单个server无法邻近查询所有客户<br />- maintenance:单个server为所有host维护记录不切实际,数据库庞大且会频繁更新<br /> |

  | —- |

5.2 DNS分级

servers的IP地址 | | Authoritative DNS servers | 权威DNS服务器,在Internet上有公共可访问主机的组织机构需提供公众可访问的DNS记录,用以映射IP地址.组织机构需实现自己的权威DNS服务器来实现保存记录 | | local DNS serves | 本地DNS服务器.并不严格属于分层结构.每个ISP有一台local server,当用户host发出DNS query时,query被发送到本地server(更像是代理,实现请求的转发) |

5.3 DNS解析

• Iterated query **迭代查询 | 前提:纽约大学计算机系主机cis.poly.edu想知道主机gaia.cs.umass.edu的IP地址,且已知NYU计算机系的本地DNS服务器dns.poly.edu | | | —- | :—-: | | 过程
  ①cis.poly.edu首先向本地dns.poly.edu发送一个查询msg,其中包含被转换的主机名gaia.cs.umass.edu
  ②本地DNS服务器发送至root server
  ③root server发现edu前缀并把负责edu的TLD的IP地址列表返回给本地server
  ④本地server再次向TLD发送msg
  ⑤TLD注意到umass.edu前缀,返回负责的权威server IP地址给本地
  ⑥本地server直接向dns.cs.umass.edu发送msg
  ⑦对应server用gaia.cs.umass.edu对应的IP地址响应
  ⑧本地server返回IP地址给host
  全程发送了4次msg,接收4次msg** | |

• recursive** query **递归查询 | 对比:现在普遍采用迭代查询,因为DNS缓存技术的存在,更节约资源 | | | —- | :—-: | | 过程
  ①用户host向本地server发送查询msg,其中包含要转换的主机名
  ②本地server向root server发送msg
  ③root server根据edu前缀发送至负责edu的TLD
  ④TLD根据umass.edu前缀发送msg至负责的权威server
  ⑤权威server将msg中主机名对应的IP地址发送回TLD
  ⑥TLD返沪给root
  ⑦root返回给本地server
  ⑧本地server返回转换结果给host | |

5.4 DNS缓存技术

5.5 DNS记录

• 记录 | 资源记录 | resource record:实现分布式DB的所有DNSserver存储的即为rr,提供了主机名到IP地址的映射,其中ttl为记录生存时间
  | | :—-: | —- | | Type—A |
  - name:主机名;
  - value:IP地址
  - 类型为A的RR提供了标准主机名到IP地址的映射:

            如(relay1.bar.foo.com,145.37.93.126,A)<br /> |

  | Type—NS |
  - name:个域(xxx.com);
  - value:可解析域名IP的权威server主机名
  - 该RR用于沿着查询链路由DNS查询
  

            如(foo.com, dns.foo.com, NS) |

  | Type—CNAME |
  - name:规范名(canonical name)对应的别名(alias

    name);<br />- value:规范名<br />- 该记录可向查询的host提供一个主机名对应的规范名<br />

  比如www.ibm.com是servereast.backup2.ibm.com的别名 | | Type—MX |
  - name:个别名(邮箱后缀)
  - value:个别名为name的mailserver的规范名
  - MX记录允许邮件服务器主机名有简单别名
  |

• 插入

加入自己向创建域名,就需要将其放入DNS server,需要

1. 给上级的:注册机构给TLD插入最基本的两条RR

①指明权威DNS服务器(NS记录)
②指明DNS server的IP地址(A记录)
举例:当要注册networkutopia.com时,需要插入

1. 给自己的:自己给权威server插入web server的A RR和邮件MX RR |
   - 例题:域名注册
   | | | —- | —- | |
   1. 一个NS记录,一个A记录
   {www.startwar.com.cn, dns1.startwar.com.cn, NS}
   {dns1.starwar.com.cn, 128.119.12.40, A}}
   2. 两个web server的A记录,一个mailserver的A记录,一个邮件地址的MX记录
   {www.starwar.com.cn, 128.119.12.55, A}
   {www.starwar.com.cn, 128.119.12.56, A}
   {starwar.com.cn, galaxy.starwar.com.cn, MX}
   {galaxy.starwar.com.cn, 128.119.12.60, A}
   |
   3. (com,cn都属于TLD域名)
   |

6. 非要求内容

6.1 P2P

特点	- 非always-on服务器 - 任意端系统直接通信 - 节点间歇连接且IP可更改
对比CS—1台服务器分发文件到N台客户机场景:已知文件大小F,上传速度u,下载速度d
C/S	- 服务器需要上传N份拷贝,耗 - 客户机i下载耗时 - 则文件分发总耗时 - 结论:CS架构下,文件分发耗时和N成线性关系(假设下载速度稳定)
P2P	P2P具有特点:当一个peer接收到文件数据,可以使用上传能力重新把数据发给对等方,因此服务器只需上传一份文件,即可分发给所有设备 - 服务器上载耗时: - 客户机i下载耗时 - 总共有NFbits必须被下载,而系统整体总上载能力等于服务器加上每个peer的上载速率,不可能超过 - 则分发文件总耗时最小为

| |

6.2 比特洪流

名词	- torrent: 洪流,参与文件分发的所有peers - tacker: 追踪器,每个torrent对应的一台server,当一个peer加入torrent,会向tacker注册,告知自己的地址,资源等 - chunk: 块,torrent中peers彼此下载等长的文件块
定义	一个peer加入torrent,开始没有块,在其向tracket注册后,连接邻近peers获取块,在下载的同时也在上传;peers可以在任意时候离开并再次加入:拥有完整文件时依然可以大公无私留在洪流中上传文件,也可以在只有文件子集时立刻离开后续再返回
拉块	pulling chunks,peer A主动向洪流中的peer B请求,B会优先发送给其网络中最稀缺的资源—rarest first
防吸血	tit-for-tat(一报还一报),peer A把chunk以最高速发送给4个peers,每10s评估,但为了避免形成小圈子导致没有新数据/垄断数据,每30s随机选择peer主动传输数据.这样peer A有可能变成该peer的top4之一,从而打破小团体,而且避免了某些peer只下载不上传,保证公平性

6.3 查询洪泛 Query Flooding

| 场景 | centralized directory(集中式目录),P2P网络中文件传输可以非集中,但很多时候定位资源是高度集中的,peer需要先向目录服务器请求资源的地址,才能直接点对点传输.这带了的问题:
- 单点故障:目录服务器崩溃,P2P应用崩溃
- 性能瓶颈:大型P2P系统中,集中式服务器要维护庞大数据库,每秒可能处理大量查询
- 版权问题:法律系统更容易关闭目录服务器

| | | :—-: | —- | :—-: | | 洪泛 | P2P网络中,一台peer的查询msg通过已有的TCP连接传播,每个peer收到后先检索自己,有资源则和查询peer直接建立连接,没有则继续转发msg,peer在其中担任了:server/client/router,洪泛避免了设置目录server,采用广泛的转发来查询可用资源 | | | 缺陷 |
1. P2P洪泛网络中peer隐藏自己;
1. flooding范围无法确定,当查询到后其余msg还在传播,浪费资源
解决:层次化overlay(覆盖),一些peer选出一个leader,类似于目录server,leader可动态调换,当group内peer查询,先由leader在组内定位,如果组内没有,在leader直接进行洪泛查询
| |

6.4 分布式哈希表 Distributed Hash Table(DHT)

概述	DHT是一个分布式的P2P数据库 - 数据库存放(key,value)键值对 - key是内容类型,value是IP地址 - peer使用key查询DB,DB返回对应value - peer也能插入键值对
DHT标识符	给定一个nbits标识符,可以分配给[]个peers,key需要和标识符相对应,这需要hash函数,即DHT来历,由于hash函数可以处理冲突,因此DHT可以映射的资源数目可以超
分配keys	P2P网络中peers不一定在线可用,因此分配key时,key对应的id也许不存在,此时采用”immediate successor”(近邻后继)
捷径	在典型的循环DHT中,可能遇到命中率低的问题,查询被不断传递,此时使用cut可以提高效率
搅动	peer churn:peer可随时离开,但DHT中的peer需要随时知道上任/继任者的IP,因此需要定时ping,查看是否alive

6.5 区块链

1. 了解—区块链 |
   - 区块链实际上为分布式账本
   - 任何改动被按时间次序的记录下来
   - consensus共识:如何证明peer的好坏,需要达成共识,有以下几种方式
   - POW: proof of work,付出足够的工作证明自己
   比特币即为POW,挖矿本质是耗费算力解题,证明自己后才能留下记录,即产生币
   - POS: proof of stake,有足够的利益证明自己
   - smart contact
   | | | —- | :—-: |

6.6 NAT

场景	类似skype的软件进行P2P通信时,面临问题:内网IP相同的机器在全世界同时可能在线非常多,因此不能直接通过内网IP进行通信
解决	NAT运行在router上,内网IP发送的数据被NAT替换IP后发送到外网,返回时同样”拆马甲”
定位	NAT作为可变临时地址,当两个peer中一个在外网时,可由内网peer去找固定公网IP的peer,但如果两个都是内网peer,此时需要第三方在公网中的机器作为中介进行处理

MindMap