� 应用范围
Web的应用层协议是Http.
Http协议并不规定浏览器如何解析HTML页面，仅仅是制定了Http客户机与Http服务器之间的数据传输规则。
用户可以通过设置浏览器来控制并行连接数。大部分浏览器默认开启5~10个连接数。每个连接处理一个请求——响应事物。
实现
Http由两部分程序实现：一个Client程序和一个Server程序
这两部分程序运行于不同的端系统中，通过交换HTTP报文进行会话。�
HTTP制定了报文的格式以及报文的交换过程。
Web浏览器实现了Http协议的客户端部分。Web服务器实现了HTTP协议的服务端部分。
流行的Web服务器有Apache 和 Microsoft IIS
Http协议的下层协议
Http的下层（传输层）支撑协议是TCP,而不是UDP。
Http是无状态协议
- 服务器像客户机发送被请求文件时，不会记录目的客户机的任何信息。
- 客户机在短时间内重复请求同一个文件，服务器仍然会做出响应，并发送文件给客户机。
- 基于上述两点说明Http协议是无状态的。
连接方式
非持久连接
开始通信之前先建立连接，完成数据传输以后，释放连接
缺点：1.必须为每个请求对象建立并维护一个全新的连接，客户机和服务器必须为该连接分配TCP缓冲区和 变量，这严重增加了服务器的负担，一个服务器可能同时服务于成千上万的客户机。
2.每个对象的传输时延为两个RTT，一个用于建立TCP连接，一个用于请求和接收一个对象。持久连接
相同客户机与服务器之间的后续请求通过初次建立的那个连接（而不是重新创建连接）。
如果一个连接经过一定的时间间隔（一个可配置的时间）仍未被使用过， HTTP服务器会关闭该连接。
HTTP服务器默认就是使用了流水线方式的持久连接。
RTT
从客户机请求HTML页面开始到用户端进程接收到完整的HTML页面为止的整个往返时间（Round-Trip Time）
TCP三次握手
1.客户机向服务器发送一个小的TCP报文段
2.服务器用一个小的TCP报文段作出确认和响应
3.客户机向服务器返回确认
一个RTT等于三次握手中前两部分消耗的时间。
完成三次握手的前两部分以后，客户机将三次握手第三个部分与一个Http请求报文结合起来发送到该TCP连接。
一旦请求到达TCP服务器，服务器向该TCP连接发送HTML文件。该Http请求又耗掉一个RTT.
Http报文格式
[RFC 2616]定了HTTP报文格式。
Http报文格式共有两种：
- 请求报文格式
示例：
GET /somedir/page.html HTTP/1.1
HOST: www.someschool.edu
connection:close
User-agent:Mozilla/4.0
Accept-language:fr
说明：
1.此报文格式第一行被称作请求行
2.请求行的第一个字段是方法字段 用于指定发送请求的方法，这里的方法是GET，
还有其他方法如POST HEAD PUT DELETE
3.绝大多数HTTP请求使用GET方法
4.在URL字段填写请求对象的URL
5.最后一个字段指定了浏览器实现的HTTP协议的版本，这里是1.1版本
6.第二行指定了目的主机
7.User-agent这一行用来指定用户代理，即向服务器发送请求的浏览器类型，这一行可以帮助服务器为不同类型的浏览器返回不同版本的对象。
8.最后一行指定了对象的法语版本，如果服务器中有这样的对象，否则使用服务器的默认版本
9.首部行之后是实体主体。使用GET方法时，实体主体为空，使用POST方法时实体主体才有内容。
- 响应报文格式
HTTP/1.1 200 OK // 初始化状态行
Connection:close // 报文发送完成之后关闭了TCP连接
Date:Thu, 03 Jul 2003 12:00:15 GMT // 从服务器文件系统中检索到文件并加入到响应报文开始发送的时间
Server:Apache/1.3.0 (Unix) // 服务器类型
Last-Modified:Sun, 6 May 2007 09:23:24 GMT // 对象创建或者最后修改的时间
Content-Length:6821 // 被发送对象的字节数
Content-Type:text/html // 对象的类型
(data data data) // 实体主体
- 常见响应状态码
200 Ok:请求成功。信息包含在返回的响应报文中
301 moved Permanently:请求的对象已经被永久转移了，新的URL定义在响应报文的Location：首部行中指定，客户机软件自动用新的URL请求此对象
400 Bad Request:一个通用的差错代码，指示该请求不能被服务器理解
404 Not Found:被请求的文档不在服务器上
505 Http Version Not Supported:服务器不支持请求报文的协议版本
示例1：
请求命令：
telnet cis.poly.edu 80
GET /~ross/ HTTP/1.1
Host:cis.poly.edu
响应报文：
HTTP/1.1 301 Moved Permanently
Date: Thu, 01 Oct 2015 02:31:56 GMT
Server: Apache/1.3.41 (Unix) mod_perl/1.31
Location: http://nyu.edu/projects/keithwross/
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
ef
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved <A HREF="http://nyu.edu/projects/keithwross/">here</A>.<P>
</BODY></HTML>
0
Connection closed by foreign host.
示例2：
请求命令：
telnet cis.poly.edu 80
HEAD /banana/ HTTP/1.1
Host:cis.poly.edu
响应报文：
HTTP/1.1 404 Not Found
Date: Thu, 01 Oct 2015 02:37:03 GMT
Server: Apache/1.3.41 (Unix) mod_perl/1.31
Content-Type: text/html; charset=iso-8859-1
Connection closed by foreign host.
Cookie
-
Web站点通常希望能够识别用户。主要有以下两个目的：
1.服务器想限制用户的访问2.服务器想把内容与用户身份关联起来
基于上述的两个原因，HTTP使用了Cookie
Cookie技术有四个组成部分
1.Http响应报文中有一个Cookie首部行
2.Http请求报文中有一个Cookie首部行
3.在用户端系统中保留有一个Cookie文件，由用户的浏览器负责管理
4.在Web站点有一个后端数据库建立Cookie的步骤：
1.浏览器首次访问某个网站时，请求发送到
Web缓存
Web缓存即代理服务器，能够代表初始Web 服务器来满足Http请求的网络实体。Web缓存有自己的磁盘存储空间，并在该存储空间中保存最近请求过的网络拷贝。
通过浏览器配置可以设置Web缓存，一旦配置了Web缓存，每个浏览器对一个对象的请求首先被定向到Web缓存器
-
Web缓存工作过程
1.浏览器建立一个到Web代理服务器的TCP连接，并向代理服务器发送一个请求
2.代理服务器检查磁盘是否存储了请求对象的拷贝。如果有，代理服务器用此对象回应请求。
3.如果代理服务器没有缓存这个对象，代理服务器会于该请求的初始服务器建立一个TCP连接，代理服务器把请求转发给初始化服务器，初始服务器向Web代理服务器做出响应，并返回请求对象给代理服务器。
4.代理服务器接收到响应的对象以后在自己的磁盘上建立一份拷贝，同时用Http响应报文向发出请求的客户机浏览器发送该拷贝（通过最初建立的客户机浏览器与代理服务器之间的TCP连接）。根据上述的特征，Web缓存器既是服务器也是客户机。
部署Web缓存器的好处
1.在网络上部署Web缓存器可以大大减少客户机请求的响应时间，尤其是客户机与初始服务器之间的瓶颈带宽远远低于客户机与Web缓存器之间的瓶颈带宽时更为明显。如果客户机与Web缓存器之间有一个高速连接，并且用户请求的对象放在Web缓存器上（实际情况通常是这样，则Web缓存器可以迅速将对象交付客户机）
2.Web缓存器可以大大减少一个机构内部网与因特网接入链路上的通信量。通过减少通信量，该机构就不必急于增加带宽，因此会降低成本。
3.Web缓存器能从整体上大大降低因特网上的Web流量，从而改善所有应用的性能。
条件GET
- 条件GET是HTTP协议的一种请求方式。
- 为什么引入条件GET？
1.通过高速Web缓存请求的对象，是由Web缓存器首次向初始服务器请求的对象的拷贝。随着时间的推移，该拷贝的原始版本可能已经发生了很大的改变。为了保证客户机请求到的数据是最新的，HTTP提供了条件GET这种机制，条件GET允许缓存器证实它所缓存的对象是否是最新的。 - 条件GET特点：
如果请求报文使用GET方法，并且请求报文中含有If-modified-since:首部行。那么可以确定此请求报文是一个条件GET报文
