TCP 和 UDP
TCP 服务
TCP 服务模型包括面向连接和可靠数据传输服务。当某个应用程序调用TCP作为其运输服务协议时,该应用程序就能获得来自TCP 的这两种服务。
- 面向连接的服务:在应用层数据报文开始流动之前,TCP 让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提醒客户和服务器,让它们为大量分组的到来做好准备。在握手阶段后,一个 TCP 连接 就在两个进程的套接字之间建立了。这种链接是全双工的,即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时,必须拆除该连接。
- 可靠的数据传送服务:通信进程能够依靠 TCP ,无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时,它能够依靠 TCP 将相同的字节流交付给接收方的套接字,而没有字节的丢失和冗余。
UDP 服务
UDP 是一种不提供不必要服务的轻量级运输协议,它仅提供最小服务。UDP 是无连接的,因此在两个进程通信前没有握手过程。UDP协议提供一直不可靠数据传输服务,也就是说,当进程将一个报文发送进UDP 套接字时,UDP协议并不保证该报文将到达接受进程。不仅如此,到达接受进程的报文也可能是乱序到达的。
应用 | 应用层协议 | 支撑的运输协议 |
---|
电子邮件 | SMTP | TCP | 远程终端访问 | Telnet | TCP | Web | HTTP | TCP | 文件传输 | FTP | TCP | 流式多媒体 | HTTP | TCP | 因特网电话 | SIP | UDP或TCP |
HTTP
概况
HTTP 定义了 Web 客户端向 Web 服务器请求 Web 页面的方式,以及服务器向客户端传送 Web 页面的方式。
HTTP 使用 TCP 作为它的支撑运输协议。HTTP 客户端首先发起一个与服务器的 TCP 连接。一旦连接建立,该浏览器和服务器进程就可以通过套接字接口访问 TCP 。客户端的套接字接口是客户端进程与 TCP 连接之间的门,在服务器端的套接字接口则是服务器进程与 TCP 连接之间的门。客户端向它的套接字接口发送 HTTP 请求报文并从它的套接字接口接收HTTP响应报文。类似地,服务器从它的套接字接口接收 HTTP 请求报文和它的套接字接口发送 HTTP 响应报文。一旦客户向它的套接字接口发送了一个请求报文,该报文就脱离了客户端控制并进入 TCP 的控制。
TCP 为 HTTP 提供可靠数据传输服务。这意味着,一个客户端进程发送的每个 HTTP 请求报文最终能完整地到达服务器;类似地,服务器进程发出的每个 HTTP 响应报文最终能完整地到达客户端。
服务器向客户端发送被请求的文件,而不存储任何关于该客户的状态信息。假定某个特定的客户在短短几秒内两次请求同一个对象,服务器并不会因为刚刚为该客户提供了该对象就不再做出反应,而是重新发送该对象,就像服务器完全忘记不久之前所做过的事一样。因为HTTP服务器并不保存关于客户端的任何信息,所以HTTP是一个 无状态协议。
非持续连接和持续连接
在许多因特网应用程序中,客户端和服务器在一个相当长的时间范围内通信,其中客户端发出一系列请求并且服务器对每个请求进行响应。依据应用程序以及该应用程序的使用方式,这一系列请求可以以规则的间隔周期性地或者间断性地一个接一个发出。当这种客户-服务器的交互是经 TCP 进行的,应用程序的研制者就需要做一个重要决定,即每个请求/响应对是经一个单独的TCP连接发送,还有所有的请求及其响应经相同的TCP连接发送?前一种称为非持续连接,后一种称为持续连接。HTTP在默认方式下使用持续连接,但同时,HTTP客户和服务器也能配置成使用非持续连接。
HTTP 请求报文
GET /user/info.html HTTP/1.1
Host: www.hyxiao.com
Connection: close
User-agent: Mozilla/5.0
Accept-language: zh-CN,zh;q=0.9,en-GB;q=0.8,en-US;q=0.7,en;q=0.6
- Connection: close -> 首部行,该浏览器告诉服务器不要麻烦地使用持续连接,它要求服务器在发送被请求的对象后就关闭这条连接。
- User-agent: Mozilla/5.0 -> 首部行用来指明用户代理,即向服务器发送请求的浏览器的类型。
- Accept-language: -> 得到该对象的语言版本,这里是中文
HTTP响应报文
HTTP/1.1 200 OK
Connection: close
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 ... ...)
上面的响应报文分为三个部分:一个初始状态行(status line),6个首部行(header line),实体体(entity body)。
实体体部分是报文的主要部分,即它包含了所请求的对象本身(即data)。状态行有3个字段:协议版本字段、状态码和相应状态信息。以上中,状态行指示服务器正在使用 HTTP /1.1 ,并且一切正常(即服务器已经找到并正在发送所请求的对象)。
- Connection: close -> 首部行告诉客户端,发送完报文后将关闭该TCP连接。
- Date -> 首部行指示服务器产生并发送该响应报文的日期和时间。这个日期指的是服务器从它的文件系统中检索到该对象,并将该对象插入响应报文,并发送该响应报文的时间。
- Server -> 首部行指示该报文是一台 Apache Web 服务器产生的,它类似于HTTP 请求报文中的User-agent:首部行。
- Last-Modified -> 首部行指示了对象创建或者最后修改的日期和时间。
- Content-Length -> 首部行指示了被发送对象中的字节数。
- Content-Type -> 首部行指示了实体体中的对象是HTML文本。
Web缓存
Web 缓存器 也叫代理服务器,它是能够代表初始 Web 服务器来满足 HTTP 请求的网络实体。Web 缓存器有自己的磁盘存储空间,并在存储空间中保存最近请求过的对象的副本。如上图所示,可以配置用户的浏览器,使得用户的所有HTTP请求首先指向Web缓存器。一旦某浏览器被配置,每个对某对象的浏览器请求首先被定向到该Web缓存器。
- 浏览器创建一个到 Web 缓存器的TCP连接,并向Web缓存器中的对象发送给一个HTTP请求。
- Web缓存器进行检查,看看本地是否存储了该对象副本。如果有,Web缓存器就向客户浏览器用HTTP响应报文返回该对象。
- 如果Web缓存器中没有该对象,它就打开一个与该对象的初始服务器的TCP连接。Web缓存器则在这个缓存器到服务器的TCP连接上发送一个对该对象的HTTP请求。在收到该请求后,初始服务器向该Web缓存器发送具有该对象的HTTP响应。
- 当 Web 缓存器接收到该响应对象时,它在本地存储空间存储一份副本,并向客户的浏览器用HTTP响应报文发送该副本(通过现有的客户浏览器和Web缓存器之间的TCP连接)。
值得注意的是Web缓存器既是服务器又是客户端。当它接收浏览器的请求并发回响应时,它是一个服务器。当它向初始服务器发出请求时并接收响应时,它是一个客户端。
在因特网部署Web缓存器有两个原因。首先,Web缓存器可以大大减少对客户端请求的响应时间。其次,Web缓存器能够大大减少一个机构的接入链路到因特网的通信量。两点可以看出,Web缓存器能从整体上大大减低因特网上的Web流量,从而改善了所有应用的性能。
条件GET方法
尽管高速缓存能减少用户感受到的响应时间,但也引入了一个新的问题,即存放在缓存器中的对象副本可能是旧的。换句话说,保存在服务器中的对象自该副本缓存在客户端上以后可能已经被修改了。但同时,HTTP协议有一种机制,允许Web缓存器证实它的对象是否是最新的。这种机制便是条件GET方法。如果:①请求报文使用GET方法;并且②请求报文中包含一个"If-Modified-Since:" 首部行。那么,这个HTTP请求报文就是一个条件GET请求报文。
下面看一个例子,首先,一个Web缓存器代表一个请求浏览器(即客户端),向某Web服务器发送一个请求报文:
GET /fruit/kiwi.gif HTTP /1.1
Host: www.exotiquecuisine.com
其次,该Web服务器向缓存器发送具有被请求的对象的响应报文:
HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data... ...)
该缓存器在将该对象转发到请求的浏览器的同时,也在本地缓存了该对象。重要的是,缓存器在存储该对象时也会存储最后修改日期。所以,缓存器可以通过发送一个条件GET执行最新检查,发送报文如下
GET /fruit/kiwi.gif HTTP /1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24
值得注意的是If-Modified-Since:首部行的值刚好等于上次服务器发送的响应报文中的Last-Modified:首部行的值。则证明该对象没有被修改过,接下来Web服务器则向Web缓存器发送一个响应报文:
HTTP/1.1 304 Not Modified
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)
可以看出,作为对该条件GET方法的响应,该Web服务器仍发送一个响应报文,但并没有在该响应报文中包含所请求的对象。毕竟包含对象,会浪费额外的带宽,还会增加响应时间。并且在状态栏中可以看出,状态码为304 Not Modified,它可以告诉缓存器,可以继续使用该对象。
因特网中的电子邮件
因特网电子邮件系统组成部分:用户代理(user agent)、邮件服务器(mail server)和简单邮件传输协议(Simple Mail Transfer Protocol,SMTP)。
SMTP
SMTP 是因特网电子邮件中主要的应用层协议。它使用TCP可靠数据传输服务,从发送方的邮件服务器向接收方的邮件服务器发送邮件。像大多数应用层协议一样,SMTP有两个部分:运行在发送方邮件服务器的客户端和运行在接收方邮件服务器的服务器端。每台邮件服务器上既运行SMTP的客户端也运行SMTP的服务器端。当一个邮件服务器向其他邮件服务器发送邮件时,它就表现为SMTP的客户端;当邮件服务器从其他邮件服务器上接收邮件时,它就表现为一个SMTP的服务器。
SMTP 采用的是持续连接:如果发送邮件服务器有几个报文发往同一个接受邮件服务器,它可以通过同一个TCP连接发送这些所有的报文。
与HTTP的对比
相同点
- 都用于从一台主机向另一台主机发送文件
- 都是用持续连接
不同点
- HTTP 主要是拉协议,即用户使用 HTTP 协议从该服务器拉取信息;而SMTP是推协议,即发送邮件服务器把文件推向接收邮件服务器。
- SMTP 要求每个报文采用 7比特ASCII 码格式。HTTP 不受限制
- HTTP 把每个对象封装到它自己的HTTP响应报文中;而SMTP 则把所有报文对象放在一个报文之中。
DNS 因特网的目录服务
DNS:域名系统(Domain Name System),能够将主机名转换成IP地址的目录服务。
- 是一个由分层的 DNS 服务器实现的分布式数据库;
- 是一个使得主机能够查询分布式数据库的应用层协议;
DNS 服务器是运行BIND 软件的UNIX 机器。DNS 协议运行在UDP之上,使用53号端口。
当主机将HTTP请求报文发送到Web服务器时,浏览器从URL中抽取出主机名,并将这台主机名传给DNS应用的客户端;DNS 客户端向DNS服务器发送一个包含主机名的请求;DNS 客户端最终会收到一份回答报文,其中含有对应该主机名的IP地址;一旦浏览器接收到来自DNS的该IP地址,它能够向位于该IP地址80端口的HTTP服务器进程发起一个TCP连接。
|