《计算机网络自顶向下方法-第七版》第二章总结
2 Principle of Network Applications
2.2 The Web and HTTP
HTTP协议定义了Client和Server之间如何交换信息以及信息的格式。一个网页由多个object构成，一般包含一个base HTML file，其中包含了其他object的URL。URL由两部分组成，存储object的Server的Hostname + object的所在路径。
HTTP底层依赖TCP协议，Client发起与Server的TCP连接，Client发送HTTP Request Message，接收HTTP Response Message，Server则相反。事实上HTTP是一个无状态协议，Server并不会保存与其交互的Client的状态，这能够简化Server的设计，但是有时候对Client进行标记是必要的，可以用Cookie解决该问题。
Client可能连续向Server发起一系列Request，如果为每个Request建立TCP连接，则称为Non-persistent Connection，这种方式的弊端为：建立大量的HTTP连接会消耗大量的系统资源并且建立每个TCP连接都需要额外的一个RTT，增加了延时。与之相反的是，默认的HTTP协议都会利用单一的TCP连接传输连续的Request，直到给定时间没有接收到Request之后，Server会将TCP连接关闭。这种方式称为Persistent Connection。
HTTP Request Message如下所示：
GET /somedir/page.html HTTP/1.1 // Request Line Host: www.someschool.edu // Header Lines Connection: close User-agent: Mozilla/5.0 Accept-language: fr
Request Message由Request line，Header lines以及Entity body组成，Header lines与Entity body之间存在一个空行。在如上所示的Header Lines中，Host字段并不多余，因为它可以被Client与Server中间的Web Cache所使用。而Connection字段，则是Client用于通知Server不必建立Persistent Connection。User-agent则标示了发送Request的浏览器类型，Server可能对于不同的浏览器发送同一个object的不同版本。
HTTP Response Message如下所示：
HTTP/1.1 200 OK // Response Line Connection: close // Header Line Date: Tue, 18 Aug 2015 15:44:04 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT Content-Length: 6821 Content-Type: text/html (data data data data data ...)
Response Message类似地由Response line，Header lines以及Entity body组成。Header lines中的Date字段表明Server构建以及发送Response的时间。Last-Modified字段则表示获取的object上一次修改的时间，它可以用于检测缓存的对象是否需要更新。几种常用的返回状态如下：
200 OK：Request成功并且在Response中包含了所需的信息
301 Move Permanently：请求的object已经被永久转移了，但是Response Header中的Location字段表明了object新的URL，Client可以根据该URL再次发起请求
400 Bad Request：常用的错误码，表明Server不理解请求的含义
505 HTTP Version Not Supported：Server并不支持请求中的HTTP版本
HTTP是无状态服务，因此需要Cookie为Server端对Client进行标记，获取Cookie及使用的过程如下：
1）Client首次向一个Server发起HTTP Request，Server为该Client创建一个唯一的ID，以该ID为Key在后端数据库建立表项，并在HTTP Response中包含一个额外的Header，例如："Set-cookie: 1678"
2）Client接受到HTTP Response，将其中的Cookie提出，把Set-cookie中的ID以及Server的Hostname，存储到Cookie file中
3）当Client再次访问该Server时，会首先查询Cookie file，若存在相应的Cookie，则在Request Header中增加Cookie Header，例如："Cookie: 1678"
4）Server根据Request中的Cookie Header，可以对该请求进行特定的操作
事实上，Cookie可以在无状态的HTTP协议之上创建一个User Session Layer。
Web Cache位于Client和Server之间，Client可经过配置之后，直接访问Web Cache，若相应的object不存在，则由Web Cache从Server进行获取并缓存。而Web Cache的优势主要包含两点：1）Web Cache可极大地减少Client的访问延时，特别是Client和Server间的网络带宽远远小于Client和Web Cache之间的网络带宽。2）Web Cache也可以极大地减少整个互联网的流量压力，重复的请求可以直接在接入网之前进行处理。而Web Cache的代表就是CDN，通过在边缘架设一系列的CDN可以将多数流量进行本地化，从而避免远程访问。
如果GET请求中包含了"If-Modified-Since:"这种Header，则称该请求为The Conditional GET。当Web Cache需要检查某个object是否为最新时，可以对该object发起GET请求，并包含"If-Modified-Since: TIME"这一Header，而TIME就是上文中在HTTP Response的"Last-Modified"这个Header的内容。若object自TIME以来未经修改，则HTTP Response返回的状态码为"304 Not Modified"且不包含object，因为这是不必要的，完全是浪费带宽，而且对于大的object还会增加响应延时。
2.4 DNS-The Internet's Directory Service
Internet中的一台主机既可以用Hostname表示，也可以用IP表示，Hostname由人类使用，但是由于其长度不定，因此其难以被路由器处理，而且其中包含的定位信息很少，例如，只能从后缀.cn表示主机在中国。相反，IP易于被路由器处理并且是一个层级结构，从左到右能逐渐对主机进行更精准的定位。
Domain Name System（DNS）就是Internet中用于提供Hostname和IP转换服务的系统。DNS本质上由两部分组成：1）一个由层级DNS Server构成的分布式数据库，2）一个运行主机对该分布式数据库进行查询的应用层协议，该协议基于UDP实现，一般绑定53号端口，通常被HTTP等其余应用层协议调用。
DNS除了提供Hostname到IP的转换服务以外，还能提供以下服务：
1) Host aliasing：通常一个主机包含多个Hostname，其中一个为Canonical Hostname，因此DNS还提供根据一个Alias Name查询Canonical Hostname以及IP地址的服务
2) Mail Server Aliasing：DNS可以被Mail Application调用获取相应的Canonical Hostname。事实上，DNS中的MX Record允许一个公司的Mail Server和Web Server有着同样的（Aliased）Hostname。比如，一个公司的Web Server和Mail Server都可以为enterprise.com
3) Load Distribution：一个Hostname往往可以和多个IP地址相对应，对于这样的Hostname，DNS Reply会将所有的IP地址返回，用户通常会选择其中第一个IP地址进行访问，因此为了能够在多个IP地址间进行负载均衡，DNS Reply会对这些IP地址的排列顺序进行轮转，保证每个IP都能等概率地被访问。
DNS系统由大量分布在全球的DNS Server构成，且可以将这些Server分成Root DNS Server，Top-Level-Domain（TLD）Server和Authoritative DNS Server三类并依次从上到下形成一个层级结构：
Root DNS Server：全球的Root Name Server由13个组织控制，它用于提供相应的TLD Server的IP地址
TLD Server：包含com，org，edu等顶级域名，它用于提供相应的Authoritative DNS Server的地址
Authoritative DNS Server：如果一个组织有主机提供对外服务，则它需要提供自己的Authoritative DNS Server，用于转换该组织自己的Hostname和IP地址。
Local DNS Server：该类型的Server准确地说并不在上述层级体系中，它一般在主机连入的时候由Residential ISP提供，它可以作为Proxy，用于接收相邻主机的DNS请求，再由它来访问上述层级体系，获取目标IP地址。关于Local DNS Server的作用，一方面它可以对DNS Reply进行缓存，从而提高访问速度，另外因为它是固定的，因此能够选择对最近的Root DNS Server，TLD Server以及Authoritative DNS Server进行访问，减小延迟。
DNS Records and Messages
全球的DNS Server组成了一个分布式数据库，其中存储的条目称为Resource Records（RR），每一个DNS Reply可以包含一个或多个Resource Records。一个RR由（Name，Value，Type，TTL）四部分组成并且分为以下四种类型：
1）Type = A：提供标准的Hostname到IP的映射，其中Name为Hostname，Value为IP
2）Type = NS：根据Hostname查询相应的Authoritative DNS Server，例如（foo.com，dns.foo.com，NS），这种类型的RR一般还需要跟一个A类型的RR，用于描述dns.foo.com和它的IP之间的映射
3）Type = CNAME：提供Alias Hostname和Canonical Hostname之间的映射
4）Type = MX：提供Alias Hostname到Mail Server的Canonical Hostname之间的映射，如果要获取Web Server的Canonical Hostname则获取CNAME类型的RR，对于Mail Server则获取MX类型的RR
一般来说DNS协议只包含Query和Reply两种类型的Message，且两种类型报文的格式相同。报文主要可分为12字节的Header和一系列的RR组成。Header包含了ID，一系列的Flag以及Questions，Answer RRs，Authority RRs以及Additional RRs的数量。Questions包含查询的Name以及Type，Answer RRs返回相应的RR，Authority RRs返回Authority Server的Records，最后的Additional RRs用于，对于一个MX类型的Query，会返回Mail Server的Canonical Hostname并且会在Additional中包含Canonical Hostname到IP的A型RR。
DNS Security
对于DNS Server的DDos攻击，由于缓存的存在，Root DNS Server其实很少被直接访问，攻击TLD DNS Server是更有效的方式。对于DNS Poisoning Attach，攻击者可以发送给DNS Server错误的Reply，诱使其对它进行缓存，从而让用户访问攻击者指定的网站。不过上述攻击造成的影响都很有限，DNS已经被证明是一个鲁棒性非常强的系统。
关于如何在DNS中注册新域名以及对其进行访问的例子：
1）例如一个初创公司决定其域名为abc.com，首先需要向Registrar注册域名，保证其唯一性，同时需要提供对应的Authoritative DNS Server的Name和IP地址，例如，dns.abc.com，212.2.212.1，Registrar会向TLD Server中插入两条Resource Record，如下：
（abc.com，dns.abc.com，NS），（dns.abc.com，212.2.212.1，A）
同时需要确保：Web Server www.abc.com的A类资源和Mail Server mail.abc.com的MX类资源已经写入Authoritative DNS Server中
2）例如Alice需要对www.abc.com进行访问，首先将DNS请求发送到Local DNS Server，Local Server访问Root DNS Server获取com的TLD Server的IP地址（若有缓存，则可跳过此步骤），再对com TLD Server进行访问并获取在步骤1中插入的两条Resource Record，然后访问dns.abc.com获取www.abc.com的类型A资源，最后Local DNS Server将结果返回Alice。
2.5 Peer-to-Peer File Distribution
对于Client-Server架构总是需要Server始终运行，但是P2P架构对于Server始终运行的要求能降到最低。下面以文件分发作为例子，对Client-Server架构以及P2P架构的扩展性进行对比：
设需要分发的文件的大小为F，Server的上传速度为Us，共有N个peers，第i个peer的上传速度为Ui，下载速度为Di。
因此对于Client-Server模式，最小的分发时间Tcs的下界为max{NF/Us, F/Dmin}，Dmin表示Peer中最小的下载速度，可以证明如果Server能对分发的流量进行合理的调度，这一下界是能够达到的。对于扩展性，可见随着N的增大，Tcs也将线性增长
对于P2P模式，其分发时间的估算是非常复杂的，这取决于Peer之间如何对已有的部分文件进行分发，但是我们仍然能对其分发时间的下界Tp2p进行估算，得到的结果为max{F/Us, F/Dmin, NF/(Us + 对Ui求和)}。如果Peer在收到一个bit之后能马上对其进行分发，则可以找到一种分发方式达到这一下界。不过事实上，文件都是按照块而非bit进行分发的。但这一结果也能对分发时间进行很好的近似。假设Ui都相等为U，则理想情况下，不管N多大，P2P模式下的分发时间不会超过F/U。显然，P2P模式具有非常好的自扩展性。
BitTorrent
所有加入文件分发的Peer构成一个Torrent，文件一般被切分为大小为256KB的块在Peer间分发。
在Torrent中有一个特殊的节点称为Tracker，它记录了Torrent中所有Peer的信息。例如，当Alice想要加入Torrent进行文件下载时，她首先需要在Tracker中进行注册并阶段性地向Tracker发送心跳。Tracker会将Torrent中一部分Peer的信息发送给Alice，Alice将与这些Peer建立连接，当然之后可能也会有Peer主动与Alice建立连接。在每个时刻，每个Peer都会有待传输的文件的一个子集且各个Peer间的子集并不相同。因此Alice会阶段性地向与其相连的Peer发送请求，获取它们已有数据块的列表，再与自己已有的数据块列表进行匹配，发送请求获取自己还没有的数据块。
在与Peer互相传输数据块时，Alice需要考虑如下两个问题：
1）对于自己还没有的数据块，应该优先请求哪些数据块？
2）对于向自己发出请求的Peer，应该向它们中的哪些发送数据块？
对于上述两个问题的解决方案如下：
1）Rarest First：即优先获取在Alice以及与其相连Peer的数据块List中副本数最少的数据块，从而增加这些数据块的分发，确保数据块副本数量的均衡
2）对于如何应答Peer的请求，Alice每隔十秒会对各个连接的Peer传输数据给她的速率进行计算并选取其中的前四名，满足它们的请求。同时，每隔30秒，Alice会随机选择一个Peer进行应答，这就给了新加入的Peer进行传输的机会。上述机制的实现，保证了整个系统的正常运行，否则每个Peer都会成为只下载而不上传的Freerider。
P2P架构的另一种应用是Distributed Hash Table（DHT），DHT事实上就是一个简单的数据库，其中的条目被分布式地记载在P2P系统的Peer中。
2.6 Video Streaming and Content Distribution Networks
Video一个非常重要的特性是它可以压缩，现有的压缩算法能够将Video压缩到任意的Bit Rate，显然Bit Rate越大，压缩的程度越小，用户体验也就越好。对于Video Streaming这一场景下，最重要的性能指标是端到端的吞吐量。因此，对于同一Video可以根据压缩程度的不同制作多个版本，根据用户的带宽传输相应的版本。
Dynamic Adaptive Streaming over HTTP（DASH），Client会动态地获取一系列的块，计算下载速率，并根据算法选择下一次下载的块的数目。DASH允许Client在一次会话过程中，根据带宽的不同在各个Video Version之间进行切换。每个版本的Video都存储在HTTP Server中，用不同的URL表示。Client最开始需要从Server中获取一个Manifest，其中包含各个版本的URL以及下载它们所需的Bit Rate。
Content Distribution Networks
如果将所有的Video存储在单个数据中心中并为所有Client提供Streaming Video服务则会存在以下三个问题：
1） 数据中心距离Client太远，因此两者之间的交互可能会跨越多个ISP，不同的ISP甚至可能在不同的大洲，如果中间某条链路的吞吐量太小，则会对整体造成巨大的延迟
2）对于流行的Video，它可能会播放很多次，因此对于同一链路，会对该Video进行多次重复的传输，这不仅是对Internet整体带宽的浪费，Video Company也需要为这些重复的流量付费
3）单点故障
Content Distribution Networks（CDN）通过将服务器分布到不同的地理位置并将用户的请求转发到能够提供最佳体验的CDN Location用以解决上述问题。
CDN通常有如下两种部分方式：
1）Enter Deep：将服务器部署在尽量多的Access ISP，通过减少用户和服务器之间的距离降低延迟。但同时由于如此广泛的部署，对于如此大量分散的服务器的维护将变得非常困难
2）将大规模的服务器部署在Internet Exchange Points（IXP），从而降低维护成本，但伴随着更高的延迟和更低的吞吐量
事实上CDN不会将所有的Video预先复制到所有的Cluster中，而是会采用一种简单拉取的策略：如果Client向一个Cluster拉取一个Video，若该Video不存在，则Cluster会一边从Central Repository或者其他Cluster拉取Video缓存到本地，一边向Client发送数据流。
那么如何将用户的请求截取并转发至CDN Server？例如要观看www.abc.com的Video，则Local DNS Server会向abc Authoritative DNS Server发送DNS请求，但是abc Authoritative DNS Server并不会直接返回IP，而是会返回例如King CDN的Authoritative DNS Server，之后Local DNS Server再向King CDN的Authoritative发起DNS请求，获取DNS Server的IP，从而实现请求的转发。
Cluster Selection Strategies
如何为某个Client选择CDN中最优的Cluster是整个CDN体系中最为核心的问题，已知CDN能够获知Local DNS Server的IP地址，因此有如下几种策略：
1）在大多数情况下，选择地理上距离Local DNS Server最近的Cluster即可，但是对于某些情况下，地理距离上的最近并不代表网络距离上的最近，而且有的Client可能会使用远程的Local DNS Server，另外这种相对固定的策略并没有考虑到网络的延迟和带宽会随着时间的推移而发生变化。
2）另一种方法是CDN会让它所有的Cluster定期地给全世界的Local DNS Server发送心跳，从而对两者之间的延迟进行实时地测量，从而动态地对Client和CDN Cluster进行匹配，但这种方法的问题是，并不是所有Local DNS Server都会对Cluster的心跳作出回应。
