读书笔记：计算机网络8章：应用层

这是我在Coursera上的学习笔记。课程名称为《Computer Networks》，出自University of Washington。

因为计算机网络才诞生不久，眼下正在以快速在发展，所以有些旧的教材可能都已经跟不上时代了。这门课程在2013年左右录制，知识相对还是比較新的。覆盖了计算机网络中的各个协议层，从物理层到应用层都讲得很细致。学完这门课程之后对计算机网络会有比較深刻的了解。

章节概要

课程位置

在传输层之上的应用层

回顾

应用层协议通常也是应用的一部分

应用不一定须要界面。比方DNS应用

应用层消息一般是分成多个包进行传输的。接收方将数据包合并在一起，成为一个大的数据包

应用通信须要什么

须要的东西非常多。必须建立在传输层之上

Web：须要传输不同长度的数据包。建立在TCP之上

DNS：须要简短的、可靠的消息传输。建立在UDP之上

Skype：须要实时消息。建立在UDP之上

OSI会话层、表示层

一般会话层和表示层是应用层的一部分，通常没有严格的区分

会话概念

会话就是一系列相关的网络通信。这些网络通信是有上下文关系的

表示层概念

有些应用可能须要将应用层的数据经过编码后传输

比方gzip/ssl

近期几年应用层的发展

应用层的协议一直在变化

见图片

能够通过下面几个方面了解互联网的发展

Akamai's State of the Internet Report：http://www.akamai.com/stateoftheinternet/

Cisco's Visule Netowrking Index

Mary Meeker's Internet Report

www.evolutionoftheweb.com

互联网的增长非常健壮，大部分的数据流量是视频，将来的几年将会达到90%，无线的流量将会超过有线的流量。移动设备的流量仍然仅仅占了非常小的一部分。越来越多的攻击流量来自中国，还有美国、俄罗斯

话题

互联网应用的发展

DNS

HTTP

WEB代理、缓存

CDN

P2P

实时应用VoIP

近期几年应用层的发展



DNS

话题

DNS域名解析系统

域名和地址

域名是资源的高层标识符

地址是资源的底层标识符

解析就是将域名转换成地址

DNS的前身是hosts.txt

hosts.txt由NIC机构管理，将全部的域名都放在这个文件里

域名一開始是平坦的，后来就变成分层结构了

DNS

DNS是一种将域名转换成地址的服务

目标是为了便于管理，高效

实现方法：将域名组织成分层结构。再通过自己主动化的协议将这些碎片组合在一起

DNS命名空间

根域名从“.”号開始，通常情况下省略

分层结构举例

.

org

com

eng

cisco

edu

washington

cs：cs.washington.edu.

eng

TLD顶级域名

TLD由ICANN运营。有22个经常使用的TLD：.com .edu .gov .mil .org .net等

不同的TLD有不同的政策

还有大约250个国家代码的TLD

域名的机智使用方法：.tv instagr.am goo.gl

DNS域

DNS域指的是命名空间中连续的一部分名称

DNS域是分布式的基础

每一个域都有域名解析服务，每一个域名能解析子域名。比方edu域名能解析子级域名washington.edu的地址

域名的资源记录

SOA：Start of Authority。是域的关键參数

A：IPv4地址

AAAA：IPv6地址

CNAME：别名

MX：邮箱server

NS：域名server

DNS解析

话题

DNS是怎样解析的

回顾

DNS域是域名空间中连续的域名

DNS解析

DNS协议让主机能够将不论什么域名解析成IP地址

刚開始假设什么都还不知道，能够从根域名開始解析

举例，解析robot.cs.washington.edu。先通过根域名server获取edu域名的NS记录，再通过edu的NS记录获取washington.edu的NS记录，再通过它获取cs.washington.edu，再通过robot.cs.washington.edu。这就是域名的分层结构

迭代请求和递归请求

递归请求：一次性解析整个域名，仅仅须要client调用一次DNS即可了

迭代请求：client须要发送多次DNS请求来解析一个域名

递归请求降低了client的工作量，可是添加了服务端的工作量。同一时候管理方面更加方便一些

迭代请求降低了服务端的工作量。而且easy建设高性能的server

递归请求和TCP连接都须要server有上下文关联

缓存

域名解析的延时应该尽量的小

能够通过缓存将域名解析的延时降低到差点儿为0。

域名解析的时候server会返回TTL，表示一个域名的地址最多能缓存多久

本地域名server

本地域名server通常由ISP运营。可是也能够是主机或者AP。也能够是Google public DNS

client须要知道DNSserver的地址。通常能够通过DHCP获取

根域server

世界上仅仅有13个根域服务器，a.root-servers.net ~ m.root-servers.net

有250+个分布式server实例，高性能，高可靠的服务

大部分的server通过anycast随意播的技术提高server的性能

支持IPv4和IPv6

DNS协议

它是一种请求-应答的消息。基于UDP，port号是53。

使用ARQ提高可靠性

消息中有16位的ID字段，依据ID字段才干知道应答和请求的相应关系，才干区分不同的请求和应答

非常多情况下，DNS返回的结果是一个地址列表，而不是单个地址。这样client就能够在多个地址中选择一个能够用的地址进行连接了。这样的方式能够提高可靠性。同一时候也能够将请求分摊到多个server上，降低了单个server的负载

安全问题是一个非常大的问题，由于数据在传输的过程中可能会被改动。所以如今引入了DNSSEC安全扩展，眼下还没有普及这项技术

HTTP

话题

怎样通过HTTP获取Web内容

Sir Tim Berners-Lee

发明了Web

Web上下文

Web是一系列资源的集合。比方文字、视频、图片

HTTP上下文

HTTP是一种请求-应答类型的协议，用于获取Web资源

基于TCP，port号为80

通过HTTP获取Web网页

http://en.wikipedia.org/wiki/Vegemite

http是协议

en.wikipedia.org是server

/wiki/Vegemite是server上的页面

步骤

通过DNS解析server的地址

配置server的TCP连接

发送HTTP请求来获取页面

等到HTTP返回页面

运行/获取嵌套的资源/渲染

清理闲置的TCP连接

静态页面和动态页面

静态页面一般就是文件，比方图片文件

动态页面是程序运行的结果。包含client的JS，或者服务端的PHP

HTTP的发展

1991 HTTP/0.9

1992 HTTP/1.0 增加了Cookies / SSL2.0

1996 HTTP/1.1 增加了Connection: Keep-Alive

2002~2009 出现了非常多网页技术。MIME type / 浏览器脚本 / 服务端脚本。可是对HTTP协议的影响差点儿没有

2009 HTTP/2.0 增加了SPDY，加快网页传输速度

HTTP协议

原本是一个非常easy的协议，可是后来添加了非常多配置项，到如今已经变得非常复杂了

HTTP的协议头部全是文本

HTTP命令：GET HEAD POST PUT DELETE TRACE CONNECT OPTIONS

HTTP应答代码

1xx 信息

2xx 成功

3xx 跳转

4xx client错误

5xx 服务端错误

头部字段指定了能力和内容

和能力相关的字段：User-Agent Accept Accept-Charset Accept-Encoding Accept-Language

和缓存相关的：If-Modified-Since If-None-Match Date Last-Modified Expires Cache-Control ETag

和浏览器内容相关的：Cookie Referer Authorization Host

和服务端内容相关的：Content-Encoding Content-Length Content-Type Content-Language Content-Range Set-Cookie

SPDY资料：

SPDY (pronounced speedy)[1] is
an open networking
protocol developed primarily at Google for transporting web
content.[1] SPDY manipulates HTTP traffic,
with particular goals of reducing web page load latency and
improving web security. SPDY achieves reduced latency through compression, multiplexing,
and prioritization.[1] The
name "SPDY" is atrademark of Google and is not an acronym.[2]

As of July 2012, the group developing SPDY has stated publicly that it is working toward standardisation (available as anInternet
Draft).[3] The first draft
of HTTP 2.0 is using SPDY as the working base for its specification draft and editing.[4]

Implementations of SPDY exist in Chromium,[5] Mozilla
Firefox,[6] Opera,[7] Amazon
Silk, and Internet Explorer.[8]

SPDY是一种开源的网络协议，由GOOGLE发明，用于传输网页内容。SPDY通过操作HTTP数据流来降低网页载入延时，提高网络的安全性。SPDY通过压缩、多址、提升优先级来降低载入的延时。SPDY不是缩写，而是SPEEDY的简写

2012年7月，SPDY开发团队起草了HTTP2.0的标准。

SPDY已经在Chrome, Firefox, Opera, Amazon Silk, IE中实现了。

HTTP协议性能

话题

HTTP多线程、长连接

PLT页面加载时间

页面加载时间是网页性能的关键指标

从点击到用户看见网页的时间

PLT添加一点点，浏览量就会降低非常多

影响因素有非常多：页面结构、网络协议、网速

早期HTTP的性能

HTTP/1.0在一次TCP连接中仅仅获取一个网页的资源

这样的情况下HTTP很easy。可是PLT很大

性能差的原因

没有使用多线程

同一个server使用多次连接

每次TCP连接都会使用“慢启动”

网络没有全然利用

降低PLT的方法

降低内容的大小，比方使用更小的图片，使用GZIP对网页进行压缩

改变HTTP来提高带宽的使用率

改变HTTP来避免传输反复的内容：缓存、代理

将server移动到client近一点的地方：CDN

并发连接

同一时候发起多个HTTP连接

服务端不须要不论什么改变，由于服务端原本就支持多线程

这样的方法带来的效果很有限，主要看最后一个网页资源的获取时间

长连接

并发连接会相互竞争，所以有时候PLT也会比較慢。

对于同一个server，使用1个TCP进行连接，然后在一次连接中发起多次HTTP请求

举例

在没有长连接的情况下每次HTTP都要发起一个TCP请求

在顺序长连接的情况下每次TCP连接能够通过多个HTTP连接，运行顺序是这种：发起请求、等待、应答请求、发起请求、等待、应答请求

在管道长连接的情况下每次TCP连接能够通过多个HTTP连接，运行顺序是这种：发起请求、发起请求、等待、应答请求、应答请求

长连接在HTTP/1.1中常常使用，支持管道长连接

长连接的问题：TCP连接要保持多久呢？有没有可能比没有长连接还要慢呢？

HTTP缓存、代理

网络缓存

用户常常訪问同一张网页，能够将远程的内容保存到本地，当须要訪问的时候直接从本地读取，这样就不须要用到网络了，极大地提高了速度。这就是缓存

关键问题是，缓存能使用多久？

通过本地的信息来推断缓存是否依旧有效，比方通过过期时间、通过启示式的方法

通过远程server来验证缓存是否有效。比方通过时间戳Last-Modified字段、或者基于内容 ETag 字段。大概 1 RTT就能知道缓存是否过期。

实现原理：client向server发送GET请求，请求中包括了时间戳或ETAG字段，服务端依据缓存的有效情况要么返回Not Modified，要么返回200 OK再加上新的数据

Web代理

client通过代理訪问server。这样能够通过缓存添加性能，同一时候提高安全性。也能够依据client的角色来控制不同的訪问权限。

Web代理提供了更大的缓存，全部用户共享的缓存，client能够从中获得优点。可是优点收到安全性、动态性的限制

代理和CDN类似，须要放在距离用户近的地方，这样才干提快速度

CDN

话题

CDN：高效的分布式内容分发网络

起源

随着Web的诞生，网络流量迅速增长。单个server的负载非常大，导致网络堵塞，用户体验差

基本思路：将数据放在离client近的地方，这样就攻克了上面的问题

举个样例，client要发起4次连接，在没有CDN的时候，须要经过4×3跳才干完毕任务。在有CDN的情况下，因为CDN做了缓存，仅仅须要经过4+2跳就能完毕任务。

CDN带来的优点就是降低了server的负载，降低了PLT，加强了用户体验

zipf定律：排名第K的站点流行度为1/k。大部分网络流量集中在小部分站点中

怎样将数据存放在离client近的位置呢

使用浏览器缓存和代理缓存，这样的方法能高起到一定作用，可是作用很有限

还能够通过CDN来实现，通过设置DNS，将一个域名相应多个地址

CDN

设置DNS，将不同区域的DNS设置成不同的地址。这样不同地区的用户解析域名的时候得到的地址是不一样的。详细的实现方案就是在DNSserver上依据IP来源推断地区，再返回对应地区的CDN地址

业务模型

将站点的一部分缓存 到ISP中。这是一种双赢的策略。它添加了用户体验，同一时候降低了ISP的带宽使用。

HTTP的未来

话题

HTTP的未来

怎样提高页面的载入速度

现代的网页



（通过webpagetest.org生成）

这幅图叫做瀑布图，显示了页面加载的网络连接情况

瀑布图的影响因素有非常多：不同的浏览器，不同的缓存情况，网络情况都有关系

降低TLD的措施

页面变得越来越复杂，怎样降低PLT呢

使用HTTP/2

优化内容结构：使用mod_pagespeed扩展

SPDY

在一个TCP连接中发起并行的HTTP请求，client对并行请求进行优先级排序，HTTP头部压缩，server主动推送相关的资源

眼下仍然在測试阶段

mod_pagespeed

对页面进行压缩、变换等操作，让server又一次编译页面，让client载入更快

压缩JS，压缩CSS，缩放图片大小，还有100多种详细规则

P2P内容分发 BitTorrent

话题

P2P内容分发

不须要中心server，是一种去中心化的协议

起源

因为CDN须要中心server，所以诞生了P2P去中心化的内容分发网络

P2P

P2P的目标就是去中心化实现内容分发

主要想法就是让參与P2P的用户互相帮助

P2P的挑战

没有server支持，全部的连接须要用户主机自己组织。这就导致了一些问题。

每一个节点的能力有限

參与者可能是自私的，为什么节点之间会相互帮助呢

去中心化，节点之间怎样找到对方呢

克服能力的限制

每一个节点都是client，同一时候也扮演着server的角色

參与者可能是自私的

每一个节点都扮演着两种角色，下载或者上传

防止自私的方法就是：假设你给我数据，我也给你数据

实现去中心化

节点必需要知道对方的地址是什么

能够通过DHT分布式哈希表来实现

DHT是全然去中心化、高效的分布式索引

BitTorrent

现在使用的基本的P2P系统

使用torrents来分发数据。每一个节点将文件分割成非常多片段，然后将这些片段进行传输

BitTorrent协议

第一步：从開始torrent种子開始

第二步：联系tracker，将自己增加到列表中，而且获取其它的用户列表

使用DHT网络来更新节点列表

将自己的数据片段和别人的数据片段进行交易，对自己贡献多的节点优先考虑

全部的节点都是同一时候下载/上传数据

将文件切割成非常小的片段来提高传输速度

孤立贡献小的节点，鼓舞他作出很多其它贡献

DHT是全然去中心化的

P2P前景

是CDN的替代品

P2P和DHT技术有了很多其它的应用，比方SKYPE AMAZON

还有比特币