应用层协议原理

进程通信

本文对同一主机上的进程间的通信不感兴趣，这是操作系统完成的。本文关注运行在不同端系统上的进程间的通信。

不同端系统上的进程通过跨越计算机网络**交换报文（message）**来互相通信。发送进程创建并向网络中发送报文，接受进程接受这些报文并可能负责会送报文。

进程通过一个称为**套接字（socket）**的接口API在网络上发送和接受报文。应用程序开发者可以控制套接字在应用层端的所有东西，但是对该套接字的运输层几乎没有控制，最多也只是选择运输层协议（TCP还是UDP服务）或者设置最大缓存、最大报文段长度等等。

应用层协议之HTTP

应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文，包括：

报文类型，如请求报文和响应报文。
报文语法。如报文中的各个字段及其详细描述。
进程何时、如何发送报文以及对报文进行响应的规则。

这里简单介绍HTTP（超文本传输协议）。该协议由两部分程序实现：客户机程序和服务器程序，他们运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的格式以及客户机和服务器是如何进行报文交换的。

HTTP使用TCP作为运输层协议。HTTP客户机发起一个于服务器的TCP连接，一旦建立连接，客户机和服务器进程可以通过套接字接口访问TCP。一旦客户机发送了一个请求报文，该报文就“脱离客户机控制”并“进入TCP”控制。

将如某客户机在短短几毫秒内两次请求了同一个对象，服务器并不会因为刚刚为该用户提供了对象就不再作出反应，而是重新发送对象。因此HTTP也被称为无状态协议。

持久连接与非持久连接

HTTP既可以使用非持久连接（nonpersistent connection），也可以使用持久连接（persistent connection）。HTTP/1.0使用非持久连接，HTTP/1.1默认使用持久连接。

非持久连接

使用非持久连接，每次服务器发出一个对象后，相应的TCP连接就被关闭，也就是说每个连接都没有持续到可用于传送其他对象。假设一个网页包含了1个HTML和10个JEPG。每个TCP连接只用于传输一个请求消息和一个响应消息。就上述例子而言，用户每请求一次那个Web页面，就产生11个TCP连接，当然这11个TCP连接可能是并行或者串行的。

我们先估算一下从客户请求基本HTML文件到它收到该文件所经历的时间。为此我们定义往返时间（Round Trip Time，简称RTT），它是一个小分组从客户主机游动到服务器主机再返回客户主机所花的时间。RTT包括分组传播延迟、在中间路由器和交换机上的分组排队延迟以及分组处理延迟。下面考虑用户点击某个超链接时会发生什么。用户的点击导致浏览器发起建立一个与Web服务器的TCP连接，这里涉及一次"三次握手"过程。三次握手过程的前两次结束时，流逝的时间为1个RTT（也就是一个来回）。此时客户把HTTP请求消息发送到TCP连接中，客户接着把三次握手过程最后一次中的确认捎带在包含这个消息的数据分节中发送出去。服务器收到来自TCP连接的请求消息后，把相应的HTML文件发送到TCP连接中，服务器接着把对早先收到的客户请求的确认捎带在包含该HTML文件的数据分节中发送出去。这个HTTP请求顺应交互也花去1个RTT时间。因此，总的响应时间粗略地算是2个RTT加上服务器发送这个HTMI文件的时间。

持久连接

非持久连接有些缺点。首先，客户得为每个待请求的对象建立并维护一个新的连接。对于每个这样的连接，TCP得在客户端和服务器端分配TCP缓冲区，并维持TCP变量。对于有可能同时为来自数百个不同客户的请求提供服务的Web服务器来说，这会严重增加其负担。其次，如前所述，每个对象都有2个RTT的响应延长–一个RTT用于建立TCP连接，另一个RTT用于请求和接收对象。最后，每个对象都遭受TCP慢启动，因为每个TCP连接都起始于慢启动阶段。不过并行TCP连接的使用能够部分减轻RTT延迟和慢启动延迟的影响。

在持久连接情况下，服务器在发出响应后让TCP连接继续打开着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。整个Web页面（上例中为包含一个基本HTMLL文件和10个图像的页面）自不用说可以通过单个持久TCP连接发送：甚至存放在同一个服务器中的多个Web页面也可以通过单个持久TCP连接发送。通常，HTTP服务器在某个连接闲置一段特定时间后关闭它，而这段时间通常是可以配置的。持久连接分为不带流水线（without pipelining）和带流水线（with pipelining）两个版本。如果是不带流水线的版本，那么客户只在收到前一个请求的响应后才发出新的请求。这种情况下，Web页面所引用的每个对象（上例中的10个图像）都经历1个RTT的延迟，用于请求和接收该对象。与非持久连接2个RTT的延迟相比，不带流水线的持久连接已有所改善，不过带流水线的持久连接还能进一步降低响应延迟。不带流水线版本的另一个缺点是，服务器送出一个对象后开始等待下一个请求，而这个新请求却不能马上到达。这段时间服务器资源便闲置了。

HTTP/1.1的默认模式使用带流水线的持久连接。这种情况下，HTTP客户每碰到一个引用就立即发出一个请求，因而HTTP客户可以一个接一个紧挨着发出各个引用对象的请求。服务器收到这些请求后，也可以一个接一个紧挨着发出各个对象。如果所有的请求和响应都是紧挨着发送的，那么所有引用到的对象一共只经历1个RTT的延迟（而不是像不带流水线的版本那样，每个引用到的对象都各有1个RTT的延迟）。另外，带流水线的持久连接中服务器空等请求的时间比较少。与非持久连接相比，持久连接（不论是否带流水线）除降低了1个RTT的响应延迟外，慢启动延迟也比较小。其原因在于既然各个对象使用同一个TCP连接，服务器发出第一个对象后就不必再以一开始的缓慢速率发送后续对象。相反，服务器可以按照第一个对象发送完毕时的速率开始发送下一个对象。

HTTP报文格式

我们来查看一个典型的请求报文格式：

POST /search HTTP/1.1  
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, 
application/msword, application/x-silverlight, application/x-shockwave-flash, */*  
Referer: http://www.google.cn/  
Accept-Language: zh-cn  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)  
Host: www.google.cn 
Connection: Keep-Alive  
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g; 
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r  

hl=zh-CN&source=hp&q=domety

在这里插入图片描述
该报文的第一行，称为request line，包含了3个字段：方法字段、URL字段和HTTP协议版本字段。POST /search HTTP/1.1很直观。
其后继的行称为header line。包含了头部字段名和值。比如，Connection: keep-alive就表示持久连接，如果是Connection: close表示非持久连接。

再来看响应报文：

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

除了第一行变成了state line，其格式与请求报文一致。
state line包含了版本，状态码和响应短语。HTTP/1.1 200 OK可知。

状态代码由服务器发出，以响应客户端对服务器的请求。
1xx（信息）：收到请求，继续处理
2xx（成功）：请求已成功接收，理解和接受
3xx（重定向）：需要采取进一步措施才能完成请求
4xx（客户端错误）：请求包含错误的语法或无法满足
5xx（服务器错误）：服务器无法满足明显有效的请求
状态码详情请查阅：https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

HTTP缓存

详见计算机网络基础——HTTP缓存机制。

应用层协议之FTP

FTP即文件传输协议，在典型的FTP会话中，用户使用本地主机向一台远程主机上传或者下载文件。
用户首先提供远程主机的主机名，使得本地主机的FTP客户机进程建立一个到远程主机FTP服务器进程的TCP连接。然后该用户提供用户标识和口令，作为FTP命令的一部分在该TCP连接上传送，一旦服务器向该用户授权，用户就可以向远程文件系统拷贝存放在本地文件系统中的一个或者多个文件。

HTTP与FTP的区别在于，FTP使用两个并行的TCP连接来传输文件，一个是控制连接（control connection），一个是数据连接（data connection）。控制连接用于在两个主机之间传输控制信息，如用户标识、口令、改变远程目录的命令以及“put”和“get”文件命令。数据连接用于实际传输一个文件。

应用层协议之SMTP

因特网电子邮件系统由3个主要部分组成：

用户代理（user agent）。用户代理也被称为邮件阅读器，它允许用户阅读、回复、转发、保存和撰写报文。
邮件服务器（mail server）。每个接收方和发送方在邮件服务器上有一个邮箱（不一定是同一个邮件服务器）。一个典型的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后才被分发到接收方的邮箱中。
SMTP（Simple Mail Transfer Protocol）。

SMTP是持久连接。SMTP协议是推协议，即向服务器推送报文的协议。而HTTP是拉协议，即向服务器请求报文的协议。

由于SMTP是推协议，邮件的接收方是不能通过SMTP接受邮件。接受邮件需要其他协议，目前有多个流行的邮件访问协议，包括第三版的邮局协议（Post Office Protocol-Version 3，POP3）、因特网邮件访问协议（Internet Mail Access Protocol，IMAP）以及HTTP。