码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2015-01-01 10:03:18      阅读:225      评论:0      收藏:0      [点我收藏+]

标签:

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

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



  • 章节概要

    • 课程位置

      • 在传输层之上的应用层

    • 回顾

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

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

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

    • 应用通信须要什么

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

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

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

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

    • OSI会话层、表示层

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

    • 会话概念

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

    • 表示层概念

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

      • 比方gzip/ssl

    • 近期几年应用层的发展

      • 应用层的协议一直在变化     

      • 见图片

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

      • 互联网的增长非常健壮,大部分的数据流量是视频,将来的几年将会达到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

      • 还有比特币


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

标签:

原文地址:http://www.cnblogs.com/bhlsheji/p/4197032.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!