计算机网络学习笔记:第二章
学习书籍:《计算机网络:自顶向下方法》
文章目录
- 计算机网络学习笔记:第二章
- 前言
- 2.1、应用层协议原理
-
- 2.1.1 网络应用程序体系结构
- 2.1.2 进程通信
- 2.1.3 可供应用程序使用的运输服务
- 2.1.4 因特网提供的传输层服务
- 2.1.5 应用层协议
- 2.1.6 本书涉及的网络应用
- 2.2 Web和HTTP
-
- 2.2.1 HTTP概述
- 2.2.2 持续连接和非持续连接
- 2.2.3 HTTP报文格式
- 2.2.4 用户与服务器的交互:Cookie
- 2.2.5 Web缓存
- 2.2.6 条件GET方法
前言
本章介绍有关网络应用的原理和实现方法;定义关键的应用层概念,包括程序所需要的网络服务、客户和服务器、进程和运输层接口;详细考察几种网络应用程序,包括WEB、电子邮件、DNS、对等文件分发和视频流;并设计开发运行在TCP和UDP上的网络应用程序;
2.1、应用层协议原理
研发网络应用的核心是写出能够运行在不同端系统和通过网络彼此通信的程序;值得注意的是,我们不需要写在网络核心设备如路由器或者链路层交换机上运行的软件,这种设计方式(将应用程序限制在端系统的方法),促进了大量网络应用程序的迅速研发和部署;
2.1.1 网络应用程序体系结构
应用程序的体系结构不同于网络的体系结构。从应用程序研发者的角度来看,网络体系结构是固定的,并为应用程序提供特定的服务集合;换言之,应用程序体系结构使用应用程序开发设计的,它规定了在端系统上如何组织应用程序。两种常见的现代网络应用程序所采用的体系结构为:客户-服务器体系结构和对等体系结构;
客户-服务器体系结构
在该体系结构中,有一个总是打开的主机,即服务器,它接收和服务来自其他许多被称为客户的主机请求;值得注意的是,在该体系结构中,客户之间是不直接通信的;该服务器具有固定的、周知的地址;
客户-服务器体系结构的著名应用有:Web、FTP、Telnet和电子邮件。
通常,如果仅有一台服务器处理所有的请求,那么服务器系统将很快变得不堪重负,为此,配备大量主机的数据中心常被用于创建强大的虚拟的服务器,一个数据中心可以有数十万台服务器,它们需要供电和维护,同时服务提供商还需要支付不断出现的互联和带宽费用,以及发送和接收到达/来自数据中心的数据;
P2P体系结构
在P2P体系结构中,对位于数据中心的专用服务器有着最小(或者没有)依赖。应用程序在间断连接的主机对之间使用直接通信,这些主机被称为对等方。对等方并不为服务提供商所拥有,因为这种对等方通信不需要通过专门的服务器,所以该体系结构也被称为对等方到对等方结构;
目前,流量密集型应用都是P2P体系结构的。这些应用包括文件共享(例如BitTorrent)、协助下载(例如迅雷)、因特网电话(例如Skype)和 IPTV(例如迅雷看看)。
值得注意的是,某些应用具有混合的体系结构,它们结合了客户-服务器和P2P这两种体系结果,比如许多的即时通讯工具,服务器用来跟踪用户IP地址,但是用户之间的通信则使用直接发送
P2P体系结构最引人入胜的特性之一就是它们的自扩展性。比如在文件共享应用中,对等方可能通过向文件的原始拥有者发出请求而产生工作量,但是对等方也有可能通过为其他对等方传送文件而为原始拥有者分担压力;P2P体系结构也是成本有效的,因为他通常不需要庞大的服务器基础设施和服务带宽。
P2P面临以下三个问题:
- ISP友好。大多数住宅ISP受制于非对称带宽应用,也就是下载比上传要多得多。但是P2P视频和文件分发应用改变了从服务器到住宅ISP的上载流量,因而给ISP带来压力;
- 安全性。因为其高度的分布和开放式,P2P应用也可能给安全带来挑战;
- 激励。如何说服用户资源向应用提供带宽、存储和计算资源?这是一个问题;
2.1.2 进程通信
在操作系统中,实际进行通信的是进程而不是应用程序;当进程运行在同一个端系统上时,它们使用进程间通信机制相互通信;而进程间通信的规则是由端系统上的操作系统确定的。当进程运行在不同的端系统上时,它们通过跨越计算机网络的报文相互通信;发送进程产生报文并且向网络中发送,接收进程接收报文并对此作出响应(不响应也是一种响应);
客户与服务器进程
网络应用程序由成对的进程组成,这些进程通过网络互相发送报文。对于每对通信进程,我们通常将这两个进程之一标识为客户,而另一个进程标识为服务器。
需要注意的是,在某些P2P应用中,一个进程可能既是客户也是服务器,因为在一个文件共享应用中,一个进程的确既能请求文件也能发送文件。所以从进程所扮演的角色来区分是客户进程还是服务器进程不够精确,所以我们从发起通信的顺序来定义它们:在给定的一对进程之间,首先发起通信的进程被标记为客户进程,在会话开始时等待联系的进程被称为服务器进程。
进程与计算机网络之间的接口
多数应用程序是由通信进程对组成的,运行在不同端系统上的进程对之间通过计算机网络来实现通信。所以,在应用程序进程和计算机网络之间存在一个接口,该接口被称为套接字。更为准确的说,套接字是同一台主机内应用层和运输层之间的接口。由于该套接字是建立网络应用程序的可编程接口,因此套接字也被称为应用程序和网络之间的应用编程接口(Application Programming Interface, API .
应用程序开发者可以控制套接字在应用层的一切内容,但是对于运输层的相关部分,几乎没有控制权,可以做的只有:
- 选择传输层协议;
- 设定几个传输层参数,比如最大缓存和最长传输层报文长度;
进程寻址
为了向特定目的进程发送报文,发送机进程需要知道接收进程(更为准确的说是,接收进程对应的套接字)的标记。该标记由两部分组成:接收进程所在的主机地址和在目的主机中指定接收进程的标识符;在因特网中,主机由IP地址标记,其中IP地址是一个32位(IPV4)标记;而接收进程(或者说是接收套接字)使用端口号标记;一些常用的应用程序有着固定的端口号,比如Web服务器使用80端口、邮件服务器(运行SMTP协议)使用25端口等;
2.1.3 可供应用程序使用的运输服务
传输层协议的特点大致可以从以下这四个方面考量:可靠数据传输、吞吐量、定时和安全性;
可靠数据传输
如同在第一章中介绍的,分组在传输过程中可能会丢失。比如,分组因为路由器中的缓存溢出而被丢弃或者分组在传输的过程中发生了损坏等情况;有些应用是不允许数据发生丢失的,比如电子邮件、文件传输、远程主机访问、Web文档传输以及金融应用等。为了支持这些应用,必须做一些工作以确保应用程序一段发送的数据正确、完全地交付给接收数据的进程。如果一个协议提供了这样得确保数据交付的服务,就认为该协提供了可靠数据传输。当应用程序使用可靠数据传输的传输层协议时,只要将要发送的数据传输进套接字就可以完全相信该数据可以完整无差错地到达接收方;
当一个运输层协议不提供可靠数据传输时,由发送方发送的数据就可能不能够到达接收进程。这可能被丢失允许的应用所接受。这类应用常见的有:交谈式音频和视频。它们能够承担丢失一定量的数据损失,在这些应用中,如果丢失少量数据将出现小干扰,但是不会出现致命的损伤,这些应用为容忍丢失的应用。
吞吐量
在一条网络路径上的两个进程之间的通信会话中,可用吞吐量就是指能够向接收进程交付比特的速率。因为会有其他会话共享该网络的路径的带宽,并且因为这些会话的到来和离开,可用吞吐量将发生变化;这就导致另一种自然的服务,即运输层协议能够提供确切的可用吞吐量。使用这种服务时,应用程序就能以明确的速度接收数据,并且运输层应当保证可用吞吐量必须总是至少为该速度;
对吞吐量有明确要求的应用程序被称为带宽敏感的应用。许多多媒体应用是带宽敏感的,比如因特网电话。而弹性应用则对吞吐量没有严格的要求。这类应用包括:电子邮件、文件传输以及web传送等。值得注意的是,吞吐量当然是越多越好了;
定时
定时和吞吐量都是关于速度的。一个提供定时服务的例子是:发送方注入套接字中的每个比特到达接收方的套接字不迟于100ms。也就是说,定时是对数据从发送到到达所需时间的要求,而吞吐量是对数据交付速度的要求。有些应用为了服务的有效性而对数据到达时间有严格的要求,常见的应用有:因特网电话、多方在线游戏等;
安全性
运输层可以提供一些安全服务,以防止传输的数据以某种方式在这两个进程之间被察觉到。这些安全服务包括:数据的加解密、数据的完整性和端点鉴别等;
2.1.4 因特网提供的传输层服务
因特网(更一般的是TCP/IP网络)为应用程序提供连个运输层协议,即UDP和TCP。每个协议对应用程序提供了不同服务的组合。以下为常见的因特网应用的特点:
应用 | 数据丢失 | 带宽 | 时间敏感 |
---|---|---|---|
文件传输 | 不能丢失 | 弹性 | 不 |
电子邮件 | 不能丢失 | 弹性 | 不 |
Web文档 | 不能丢失 | 弹性(几kbs) | 不 |
因特网电话/视频会议 | 容忍丢失 | 音频(几kbs~1Mbps) / 视频(10kbps~5Mbps) | 是,100ms |
流存式存储音频/视频 | 容忍丢失 | 同上 | 是, 几秒 |
交互式游戏 | 容忍丢失 | 几kbs~10kbps | 是,100ms |
智能手机讯息 | 不能丢失 | 弹性 | 是和不是 |
TCP服务
TCP服务模型包括了面向连接的服务和可靠数据传输服务。
面向连接的服务:在应用层数据报文开始流动之前,TCP会在客户端和服务器端相互交换传输层控制信息。这个握手过程将提示客户端和服务器端,让它们为即将到来的大量分组做好准备;握手阶段接收后将建立一个TCP连接。这条链接是全双工的,即连接双方使用该条链接可以同时进行报文的收发。这条连接将在通讯结束后拆除;
可靠的数据传输:应用程序使用TCP协议可实现无差错、按适当顺序交付所有发送的数据,没有字节的丢失和冗余;
TCP服务还提供了拥塞控制机制。该机制不一定会给通行双方带来好处,但是会给网络带来整体好处;当发送方和接收方之间的网络出现拥塞时,TCP将使用拥塞控制机制来使网络恢复正常 ;
UDP服务
UDP服务是一种不提供不必要服务的轻量级运输协议。它仅提供最小服务。UDP是无连接的也就是说通信之前没有握手;UDP不提供数据的可靠传输;UDP也没有拥塞控制机制,所以UDP的发送端可以用它选定的任何速率向其下层(网络层)注入数据。有些应用场景下,UDP协议将带来更多的便利和效率,比如DNS和一些因特网电话服务(为了避免拥塞控制协议的控制而使用UDP);
传输层无法提供的服务
从可靠数据传输、吞吐量、定时、安全性等四个角度来看运输层提供的服务,我们发现,运输层无法对吞吐量和定时做出保证(因为因特网已经被设计成尽可能最大可能对付这种保证的缺乏)。总之,今天的因特网能够为时间敏感的应用提供满意的服务,尽管它并不提供任何定时或者带宽保证;
流行的因特网应用及其应用层协议和支撑的运输协议
应用 | 应用层协议 | 支撑的运输协议 |
---|---|---|
电子邮件 | SMTP [RFC 5321] | TCP |
远程终端访问 | Telnet [RFC 854] | TCP |
Web | HTTP [RFC 2616] | TCP |
文件传输 | FTP [RFC 959] | TCP |
流式多媒体 | HTTP (如YouTube) | TCP |
因特网电话 | SIP [RFC 3261]、RTP [RFC 3550] | UDP或TCP |
电子邮件、远程终端访问、Web、文件传输都使用了TCP(TCP提供了可靠数据传输服务,确保所有数据最终到达目的地);而因特网电话应用通常能忍受某些丢失但要求一定的最小速率才能有效工作,故通常使用UDP(有些防火墙被配置成阻挡UDP流量,则使用TCP作为备份)以避开TCP的拥塞控制机制和分组开销;
2.1.5 应用层协议
应用层协议定义运行在不同端系统上的应用程序进程如何相互传递信息。涉及的内容包括:交换的报文类型(请求或者响应)、报文中包含哪些字段、字段如何被解释、一个进程何时收发报文并如何对报文进行响应等内容‘
区分网络应用和应用层协议很重要,应用层协议只是网络应用的一部分;(例如对于一个Web应用,包括文档格式标准HTML、Web浏览器、WEb服务器,以及一个应用层协议HTTP;)
2.1.6 本书涉及的网络应用
即将介绍的应用包括:Web、文件传输、电子邮件、目录服务、流式视频和P2P。Web部分将介绍HTTP协议,它比较简单和易于理解;FTP则和HTTP形成了对照;电子邮件是比Web更为复杂的应用,因为它使用了多个应用层协议;大多数用户不会直接和DNS接触,但是DNS很好地说明了一种核心的网络功能是如何在应用层实现的;最后便是P2P应用的简单介绍了;
2.2 Web和HTTP
对于大多数用户来说,最具吸引力的就是Web的按需操作;
2.2.1 HTTP概述
HTTP(HyperText Transfer Protocol)是Web的应用层协议,它是Web的核心;HTTP有两部分实现,一个客户端程序和一个服务器程序;HTTP定义了客户和服务器进行报文交换的方法;
Web页面(也叫文档)是由对象组成的,一个对象是一个文件,它们通过一个URL地址进行寻址。客户和服务器交互的核心思想是客户通过HTTP请求对服务器发出对Web页面的请求报文,服务器收到该报文后将返回包含该对象的HTTP响应报文。URL地址由两部分组成:存放对象的服务器主机名和对象的路径名;
HTTP使用TCP作为它的传输层协议;HTTP客户首先发起一个与服务器的TCP连接,需要注意的是,服务器根据请求作出响应,但是不存储任何关于该客户的状态信息;也正因为这样,HTTP被称为无状态协议。同时,Web使用了客户端-服务器的应用体系结构;其中web服务器总是开着的;
2.2.2 持续连接和非持续连接
在因特网应用程序中,客户端和服务器将在很长的时间范围里通信;应用程序将根据自身的特点,选择以规则的间隔周期性性发出请求也可以间断性一个个发出请求。当通信是使用TCP协议时,服务器端需要做出一个决定:这些请求是使用一个TCP连接完成还是通过独立的TCP连接完成。前者称应用程序使用持续连接,后者则称为非持续连接;
HTTP既可使用持续连接也可以使用非持续连接,尽管HTTP在静默情况下使用持续连接;
采用非持续连接的HTTP
使用非持续连接时,每个TCP连接在服务器发送一个对象后就会关闭,也就是每个TCP只传送一个请求报文和响应报文;
为了描述持续连接和非持续连接的特点,我们引入往返时间(Round-Trip Time, RTT)。RTT指的是,一个短分组从客户端到服务器,然后再返回客户端所用的时间。RTT包括分组的传播时延、排队时延、处理时延(因为是短分组,所以其传输时延可不计);因为客户端和服务器建立TCP连接的时候,会通过一个三次握手的过程来交换传输控制信息。三次握手的前两次占用了一个RTT,客户结合第三次握手通行会通过该连接发送一个HTTP请求报文,一旦该分组到达服务器,服务器便开始使用TCP传输HTML对象。因此,粗略地说,响应时间是两个RTT加上传输HTML的时间(不是传播)。
采用持续连接的HTTP
上文可见非持续连接的一些缺点:第一,必须为每个请求新建一个TCP连接,而每个TCP连接将占用系统资源,包括缓冲区和变量等,这样服务器的负担就很重了;第二,一个对象将通过两个RTT的时延才能交付;
如果使用持续连接,那么服务器在发送响应报文后将保持该TCP打开,后续客户端可以使用该连接来向服务器发出请求。不但一个完整的页面可以通过同一个连接传送,同一台服务器上的多个页面也可以通过同一个连接发送。这就提高了效率;
一般来说,如果一条连接在一定的时间间隔后没被使用的话,就会被关闭。HTTP默认使用的是带流水线的持续连接;
2.2.3 HTTP报文格式
HTTP报文有两种:请求报文和响应报文;
HTTP请求报文
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mosilla/5.0
Accept-language: fr
一个请求报文具有至少一行的内容。请求报文的第一行称为请求行,其后继的各行被称为首部行。请求行包含三个内容:方法字段、URL字段、HTTP版本;其中方法字段可为:GET、POST、PUT、DELETE、HEAD等。URL字段里可以传递请求对象的标志;
首部行包含是否在发送完响应报文后关闭TCP连接的Connection;请求的主机地址(该头部信息被Web高速缓存所要求);浏览器版本;可接受的语言等头部信息;
在首部行之后一个空行,之后便是请求的“实体体”。使用GET方法时实体体为空,使用POST方法的时候才用该实体体;该实体体可以在POST方法里传递Form表单内容或者传递其它一些二进制流数据等。值得注意的是,表单也不一定必须使用POST方法。如果使用GET图,实体体为空,会显示在URL中;
HEAD类似于GET方法,将会用一个HTTP报文进行响应,但是不返回请求对象,经常用作调试跟踪。PUT方法常与Web发行工具联合使用,允许用户上传对象到指定的Web服务器上指定的路径。DELETE方法允许用户或应用程序删除Web服务器上的对象。
HTTP响应报文
HTTP/1.1 200 OK
Connection: close
Date: True, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS) // 类似于请求报文的User-agent
Last-Modified: True, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)
响应报文总体上也分三个部分,第一部分是状态行,包含HTTP版本、状态以及状态信息等内容;第二部分是首部行,包含发送日期、服务器类型、上一次修改请求资源的时间、内容的类型等内容。第三部分是实体体。实体体包含请求对象本身。
这里的Date是从文件系统中检索到该对象,插入到响应报文,并发送该响应报文的时间。Last-Modified则是对象创建或者最后修改的日期和时间;
常见状态码
200 OK:请求成功,处理方式:信息在返回的响应报文中;
301 Moved Permanently:请求的对象被永久转移了,首部行中;处理方式:重定向到分配的URL;
400 Bad Request:非法请求,处理方式:丢弃;
404 Not Found:没有找到,处理方式:丢弃;
505 HTTP Version Not Supported:服务器不支持请求报文使用的HTTP版本;
2.2.4 用户与服务器的交互:Cookie
前面提到,HTTP是无状态协议,但是Web站点为了识别用户身份或者限制用户访问的时间或者将用户访问的内容同用户身份相关联,Web站点可以使用Cookie技术;
Cookie技术包含4个组件:
- HTTP响应报文里增加一个关于Cookie的首部行;
- HTTP请求报文里增加一个关于Cookie的首部行;
- 用户端系统保留一个Cookie文件,由浏览器保存维护;
- Web站点建立Cookie和用户身份的关联;
虽然,Cookie的使用方便了用户也方便了服务端,但是它的使用存在争议,因为使用Cookie被认为是对用户隐私的一种侵犯,因为Web站点可以通过Cookie得到很多用户的信息,并有可能将这部分信息卖给第三方等;
2.2.5 Web缓存
Web缓存器也被称为代理服务器,它代表初始web服务器来满足HTTP请求。它有自己的存储空间,并在存储空间里保持有最近请求过的对象的副本;可以通过配置浏览器,将所有指向初始服务器的请求首先指向代理服务器。
当代理服务器收到一个HTTP请求后,它将检查本地是否缓存过该对象,如果缓存过该对象,将检查是否过期,如果没有过期,则直接将该对象返回给浏览器;如果本地不存在或者存在已过期,则代理服务器将根据请求报文里的Host首部行以及请求行里的URL字段向初始服务器发出请求,然后将响应对象返回给浏览器并缓存在本地。
通常,代理服务器与客户端的通信速度要快于初始服务器与客户端的连接速度;因特网部署Web缓存器有两个原因:1)Web代理服务器可以大起大减少对客户请求的响应时间;2)缓存器能从整体上大大降低因特网上的Web流量,从而有助于提高所有应用程序的性能;
通过使用内容分发网络(Content Distribution Network, CDN),Web缓存器正在因特网中发挥越来越重要的作用;
Web缓存即是客户又是服务器;
2.2.6 条件GET方法
高速缓存器的使用,带来很多好处,但是有一个问题:存放在缓存器伤的对象副本可能是旧的,即保存在服务器中的对象自该副本缓存在客户上以后可能被修改了;
其实HTTP提供了一种机制,允许缓存器证实其使用的对象是最新的,这种机制就是条件GET方法。使用条件GET方法只需在使用GET方法的时候,增加一个If-Modified-Since:首部行,其对应的内容是一个时间,如果所请求的资源在指定日期后被修改了,那么服务器将返回新的对象,否则服务器将返回一个包含空实体体的报文。这样代理服务器就可以确认缓存是否过期了。