这是我在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:邮箱服务器
-
NS:域名服务器
-
-
-
DNS解析
-
话题
-
DNS是如何解析的
-
-
回忆
-
DNS域是域名空间中连续的域名
-
-
DNS解析
-
DNS协议让主机可以将任何域名解析成IP地址
-
刚开始如果什么都还不知道,可以从根域名开始解析
-
举例,解析robot.cs.washington.edu。先通过根域名服务器获取edu域名的NS记录,再通过edu的NS记录获取washington.edu的NS记录,再通过它获取cs.washington.edu,再通过robot.cs.washington.edu。这就是域名的分层结构
-
-
迭代请求和递归请求
-
递归请求:一次性解析整个域名,只需要客户端调用一次DNS就行了
-
迭代请求:客户端需要发送多次DNS请求来解析一个域名
-
递归请求减少了客户端的工作量,但是增加了服务端的工作量。同时管理方面更加方便一些
-
迭代请求减少了服务端的工作量。并且容易建设高性能的服务器
-
递归请求和TCP连接都需要服务器有上下文关联
-
-
缓存
-
域名解析的延时应该尽量的小
-
可以通过缓存将域名解析的延时减少到几乎为0。
-
域名解析的时候服务器会返回TTL,表示一个域名的地址最多能缓存多久
-
-
本地域名服务器
-
本地域名服务器通常由ISP运营。但是也可以是主机或者AP。也可以是Google public DNS
-
客户端需要知道DNS服务器的地址。通常可以通过DHCP获取
-
-
根域服务器
-
世界上只有13个根域服务器,a.root-servers.net ~ m.root-servers.net
-
有250+个分布式服务器实例,高性能,高可靠的服务
-
大部分的服务器通过anycast任意播的技术提高服务器的性能
-
支持IPv4和IPv6
-
-
DNS协议
-
它是一种请求-应答的消息。基于UDP,端口号是53。
-
使用ARQ提高可靠性
-
消息中有16位的ID字段,根据ID字段才能知道应答和请求的对应关系,才能区分不同的请求和应答
-
很多情况下,DNS返回的结果是一个地址列表,而不是单个地址。这样客户端就可以在多个地址中选择一个可以用的地址进行连接了。这种方式可以提高可靠性。同时也可以将请求分摊到多个服务器上,减少了单个服务器的负载
-
安全问题是一个很大的问题,因为数据在传输的过程中可能会被修改。所以现在引入了DNSSEC安全扩展,目前还没有普及这项技术
-
-
-
HTTP
-
话题
-
如何通过HTTP获取Web内容
-
-
Sir Tim Berners-Lee
-
发明了Web
-
-
Web上下文
-
Web是一系列资源的集合。比如文字、视频、图片
-
-
HTTP上下文
-
HTTP是一种请求-应答类型的协议,用于获取Web资源
-
基于TCP,端口号为80
-
-
通过HTTP获取Web网页
-
http://en.wikipedia.org/wiki/Vegemite
-
http是协议
-
en.wikipedia.org是服务器
-
/wiki/Vegemite是服务器上的页面
-
-
步骤
-
通过DNS解析服务器的地址
-
配置服务器的TCP连接
-
发送HTTP请求来获取页面
-
等到HTTP返回页面
-
执行/获取嵌套的资源/渲染
-
清理闲置的TCP连接
-
-
-
静态页面和动态页面
-
静态页面一般就是文件,比如图片文件
-
动态页面是程序执行的结果。包括客户端的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协议
-
原本是一个很简单的协议,但是后来增加了很多配置项,到现在已经变得很复杂了
-
HTTP的协议头部全是文本
-
HTTP命令:GET HEAD POST PUT DELETE TRACE CONNECT OPTIONS
-
HTTP应答代码
-
1xx 信息
-
2xx 成功
-
3xx 跳转
-
4xx 客户端错误
-
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非常简单。但是PLT非常大
-
性能差的原因
-
没有使用多线程
-
同一个服务器使用多次连接
-
每次TCP连接都会使用“慢启动”
-
网络没有完全利用
-
-
-
减少PLT的方法
-
减少内容的大小,比如使用更小的图片,使用GZIP对网页进行压缩
-
改变HTTP来提高带宽的使用率
-
改变HTTP来避免传输重复的内容:缓存、代理
-
将服务器移动到客户端近一点的地方:CDN
-
-
并发连接
-
同时发起多个HTTP连接
-
服务端不需要任何改变,因为服务端原本就支持多线程
-
这种方法带来的效果非常有限,主要看最后一个网页资源的获取时间
-
-
长连接
-
并发连接会相互竞争,所以有时候PLT也会比较慢。
-
对于同一个服务器,使用1个TCP进行连接,然后在一次连接中发起多次HTTP请求
-
举例
-
在没有长连接的情况下每次HTTP都要发起一个TCP请求
-
在顺序长连接的情况下每次TCP连接可以通过多个HTTP连接,执行顺序是这样的:发起请求、等待、应答请求、发起请求、等待、应答请求
-
在管道长连接的情况下每次TCP连接可以通过多个HTTP连接,执行顺序是这样的:发起请求、发起请求、等待、应答请求、应答请求
-
-
长连接在HTTP/1.1中经常使用,支持管道长连接
-
长连接的问题:TCP连接要保持多久呢?有没有可能比没有长连接还要慢呢?
-
-
-
HTTP缓存、代理
-
网络缓存
-
用户经常访问同一张网页,可以将远程的内容保存到本地,当需要访问的时候直接从本地读取,这样就不需要用到网络了,极大地提高了速度。这就是缓存
-
关键问题是,缓存能使用多久?
-
通过本地的信息来判断缓存是否依然有效,比如通过过期时间、通过启发式的方法
-
通过远程服务器来验证缓存是否有效。比如通过时间戳Last-Modified字段、或者基于内容 ETag 字段。大概 1 RTT就能知道缓存是否过期。
-
实现原理:客户端向服务器发送GET请求,请求中包含了时间戳或ETAG字段,服务端根据缓存的有效情况要么返回Not Modified,要么返回200 OK再加上新的数据
-
-
Web代理
-
客户端通过代理访问服务器。这样可以通过缓存增加性能,同时提高安全性。也可以根据客户端的角色来控制不同的访问权限。
-
Web代理提供了更大的缓存,所有用户共享的缓存,客户端可以从中获得好处。但是好处收到安全性、动态性的限制
-
代理和CDN类似,需要放在距离用户近的地方,这样才能提高速度
-
-
-
CDN
-
话题
-
CDN:高效的分布式内容分发网络
-
-
起源
-
随着Web的诞生,网络流量迅速增长。单个服务器的负载很大,导致网络阻塞,用户体验差
-
基本思路:将数据放在离客户端近的地方,这样就解决了上面的问题
-
-
举个例子,客户端要发起4次连接,在没有CDN的时候,需要经过4×3跳才能完成任务。在有CDN的情况下,由于CDN做了缓存,只需要经过4+2跳就能完成任务。
-
CDN带来的好处就是减少了服务器的负载,减少了PLT,加强了用户体验
-
zipf定律:排名第K的网站流行度为1/k。大部分网络流量集中在小部分网站中
-
如何将数据存放在离客户端近的位置呢
-
使用浏览器缓存和代理缓存,这种方法能高起到一定作用,但是作用非常有限
-
还可以通过CDN来实现,通过设置DNS,将一个域名对应多个地址
-
-
CDN
-
设置DNS,将不同区域的DNS设置成不同的地址。这样不同地区的用户解析域名的时候得到的地址是不一样的。具体的实现方案就是在DNS服务器上根据IP来源判断地区,再返回相应地区的CDN地址
-
-
业务模型
-
将网站的一部分缓存 到ISP中。这是一种双赢的策略。它增加了用户体验,同时减少了ISP的带宽使用。
-
-
-
HTTP的未来
-
话题
-
HTTP的未来
-
如何提高页面的加载速度
-
-
现代的网页
-
-
(通过webpagetest.org生成)
-
这幅图叫做瀑布图,显示了页面载入的网络连接情况
-
瀑布图的影响因素有很多:不同的浏览器,不同的缓存情况,网络情况都有关系
-
-
减少TLD的措施
-
页面变得越来越复杂,如何减少PLT呢
-
使用HTTP/2
-
优化内容结构:使用mod_pagespeed扩展
-
-
SPDY
-
在一个TCP连接中发起并行的HTTP请求,客户端对并行请求进行优先级排序,HTTP头部压缩,服务器主动推送相关的资源
-
目前仍然在测试阶段
-
-
mod_pagespeed
-
对页面进行压缩、变换等操作,让服务器重新编译页面,让客户端加载更快
-
压缩JS,压缩CSS,缩放图片大小,还有100多种具体规则
-
-
-
P2P内容分发 BitTorrent
-
话题
-
P2P内容分发
-
不需要中心服务器,是一种去中心化的协议
-
-
起源
-
由于CDN需要中心服务器,所以诞生了P2P去中心化的内容分发网络
-
-
P2P
-
P2P的目标就是去中心化实现内容分发
-
主要想法就是让参与P2P的用户互相帮助
-
-
P2P的挑战
-
没有服务器支持,所有的连接需要用户主机自己组织。这就导致了一些问题。
-
每个节点的能力有限
-
参与者可能是自私的,为什么节点之间会相互帮助呢
-
去中心化,节点之间如何找到对方呢
-
-
克服能力的限制
-
每个节点都是客户端,同时也扮演着服务器的角色
-
-
参与者可能是自私的
-
每个节点都扮演着两种角色,下载或者上传
-
防止自私的方法就是:如果你给我数据,我也给你数据
-
-
实现去中心化
-
节点必须要知道对方的地址是什么
-
可以通过DHT分布式哈希表来实现
-
DHT是完全去中心化、高效的分布式索引
-
-
BitTorrent
-
如今使用的主要的P2P系统
-
使用torrents来分发数据。每个节点将文件切割成很多片段,然后将这些片段进行传输
-
-
BitTorrent协议
-
第一步:从开始torrent种子开始
-
第二步:联系tracker,将自己加入到列表中,并且获取其他的用户列表
-
使用DHT网络来更新节点列表
-
将自己的数据片段和别人的数据片段进行交易,对自己贡献多的节点优先考虑
-
所有的节点都是同时下载/上传数据
-
将文件分割成很小的片段来提高传输速度
-
孤立贡献小的节点,鼓励他作出更多贡献
-
DHT是完全去中心化的
-
-
P2P前景
-
是CDN的替代品
-
P2P和DHT技术有了更多的应用,比如SKYPE AMAZON
-
还有比特币
-
-