Web应用层协议---HTTP
处于协议栈顶层的应用层协议定义了运行在不同端系统的应用程序进程如何相互传递报文。定义内容如下：
1、交换的报文类型。请求报文和响应报文。
2、各种报文类型的语法，如报文中的各个字段及这这些字段是如何描述的。
3、字段的语义，即这些字段中包含的信息的含义。
4、一个进程何时以及如何发送报文，对报文进行相应的规则。
Web的应用层协议是超文本传输协议（HTTP）。HTTP由两个程序实现：一个客户程序和一个服务器程序；客户程序和服务器程序运行在不同的端系统中，通过HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的形式。
HTTP使用TCP作为它的支撑运输协议（非UDP）。HTTP客户首先发起一个与服务器的TCP连接。一旦建立连接，该浏览器和服务器进行就可以通过套接字接口访问TCP。
服务器像客户端发送被请求的文件，而不存储任何关于该客户的状态信息，因此HTTP协议是无状态协议。
另外HTTP协议还有一个特点：非持续连接和持续连接
非持续连接：
从服务器像客户传送一个Web页面的步骤。假设该页面含有一个HTML基本文件和10个PNG图形，并且这11个对象位于同一台服务器上。
例如客户端请求URL：http://www.baidu.com/login.do（该url是随意模拟，此处只供实例，接口也是随意模拟）
1、HTTP客户进行在端口号80发起一个到服务器www.baidu.com的TCP连接，该端口号是HTTP的默认端口。在客户和服务器上分别有一个套接字与该连接相关联。
2、HTTP客户经它的套接字向该服务器发送一个HTTP请求报文。请求报文中包含了路径名/login.do，
3、HTTP服务器进行经它的套接字接收该请求报文，从其存储器（RAM或磁盘）中检索出对象www.baidu.com/login.do，在一个HTTP响应报文中封装对象，并通过其套接字向客户发送响应报文。
4、HTTP服务器进程通知TCP断开TCP连接（TCP确认客户已经完成的收到响应报文为止）
5、HTTP客户接收响应报文，TCP连接关闭。该报文指出封装的对象是一个HTML文件，客户从响应报文中提出该文件，检查该HTML文件，得到10个PNG图形引用
6、对每个引用的PNG图形对象重复前四个步骤
这便是非持续连接的使用过程，其中每个TCP连接在服务器发送一个对象关闭，即该连接并不为其他的对象而持续下来。值得注意的是每个TCP连接只传输一个请求报文和一个响应报文。因此该案例中，当用户请求该Web页面时，要产生11个TCP连接。
案例中没有明确用户或者10个PNG图形是使用10个串行的TCP连接，还是某些PNG对象使用了并行的TCP连接。当然在默认情况下，大部分浏览器打开5~10的并行TCP连接，而每条连接处理一个请求响应事务。使用并行连接可以缩短响应时间。
（具体的TCP连接后续记录）
持续连接的HTTP：
持续连接情况下，服务器在发送响应之后保持TCP连接打开。在相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。
如上案例，10个PNG图形对象可以使用单个持续TCP连接进行传送。更牛逼的是，位于同一台服务器的多个web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接进行。当然连接经过一定的时间间隔便会关闭该连接。
HTTP请求报文结构：
具体实际报文可通过抓包工具fiddler、wireshark等抓取学习。
请求行：方法字段、URL字段和HTTP版本字段
方法字段有：GET：从指定的资源请求数据
PUT：向指定的资源修改数据
HEAD：类似与GET方法。当服务器收到使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但并不是返回请求对象。
POST：向指定的资源提交要被处理的数据
DELETE：向指定的额资源删除数据
请求头包含：HOST、connection、User-agent、Accept-language、cookie等（皆以键值对形式展现）
HTTP响应报文结构：
状态行：协议版本字段、状态码、相应状态信息。
响应头：Connection、Date、Server、Content-Length、Content-type、Last-Modified（键值对形式）
响应数据
常见状态码：
1xx - 信息提示
这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。 • 100 - 继续。
• 101 - 切换协议。
2xx - 成功
这类状态代码表明服务器成功地接受了客户端请求。 • 200 - 确定。客户端请求已成功。
• 201 - 已创建。
• 202 - 已接受。
• 203 - 非权威性信息。
• 204 - 无内容。
• 205 - 重置内容。
• 206 - 部分内容。
3xx - 重定向
客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。
• 302 - 对象已移动。
• 304 - 未修改。
• 307 - 临时重定向。
4xx - 客户端错误
发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。 • 400 - 错误的请求。
• 401 - 访问被拒绝。IIS 定义了许多不同的 401 错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在 IIS 日志中显示： • 401.1 - 登录失败。
• 401.2 - 服务器配置导致登录失败。
• 401.3 - 由于 ACL 对资源的限制而未获得授权。
• 401.4 - 筛选器授权失败。
• 401.5 - ISAPI/CGI 应用程序授权失败。
• 401.7 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
• 403 - 禁止访问：IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因： • 403.1 - 执行访问被禁止。
• 403.2 - 读访问被禁止。
• 403.3 - 写访问被禁止。
• 403.4 - 要求 SSL。
• 403.5 - 要求 SSL 128。
• 403.6 - IP 地址被拒绝。
• 403.7 - 要求客户端证书。
• 403.8 - 站点访问被拒绝。
• 403.9 - 用户数过多。
• 403.10 - 配置无效。
• 403.11 - 密码更改。
• 403.12 - 拒绝访问映射表。
• 403.13 - 客户端证书被吊销。
• 403.14 - 拒绝目录列表。
• 403.15 - 超出客户端访问许可。
• 403.16 - 客户端证书不受信任或无效。
• 403.17 - 客户端证书已过期或尚未生效。
• 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
• 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用
Nginx 499 -- 代理服务端主动关闭客户端连接
HTTP 400 - 请求无效
HTTP 401.1 - 未授权：登录失败
HTTP 401.2 - 未授权：服务器配置问题导致登录失败
HTTP 401.3 - ACL 禁止访问资源
HTTP 401.4 - 未授权：授权被筛选器拒绝
HTTP 401.5 - 未授权：ISAPI 或 CGI 授权失败
HTTP 403 - 禁止访问
HTTP 403 - 对 Internet 服务管理器 的访问仅限于 Localhost
HTTP 403.1 禁止访问：禁止可执行访问
HTTP 403.2 - 禁止访问：禁止读访问
HTTP 403.3 - 禁止访问：禁止写访问
HTTP 403.4 - 禁止访问：要求 SSL
HTTP 403.5 - 禁止访问：要求 SSL 128
HTTP 403.6 - 禁止访问：IP 地址被拒绝
HTTP 403.7 - 禁止访问：要求客户证书
HTTP 403.8 - 禁止访问：禁止站点访问
HTTP 403.9 - 禁止访问：连接的用户过多
HTTP 403.10 - 禁止访问：配置无效
HTTP 403.11 - 禁止访问：密码更改
HTTP 403.12 - 禁止访问：映射器拒绝访问
HTTP 403.13 - 禁止访问：客户证书已被吊销
HTTP 403.15 - 禁止访问：客户访问许可过多
HTTP 403.16 - 禁止访问：客户证书不可信或者无效
HTTP 403.17 - 禁止访问：客户证书已经到期或者尚未生效
HTTP 404.1 -无法找到 Web 站点 HTTP 404- 无法找到文件
HTTP 405 - 资源被禁止
HTTP 406 - 无法接受
HTTP 407 - 要求代理身份验证
HTTP 410 - 永远不可用
HTTP 412 - 先决条件失败
HTTP 414 - 请求 - URI 太长
HTTP 500 - 内部服务器错误
HTTP 500.100 - 内部服务器错误 - ASP 错误
HTTP 500-11 服务器关闭
HTTP 500-12 应用程序重新启动
HTTP 500-13 - 服务器太忙
HTTP 500-14 - 应用程序无效
HTTP 500-15 - 不允许请求 global.asa
Error 501 - 未实现
HTTP 502 - 网关错误
用户与服务器的交互：cookie
cookie的出现解决了HTTP的无状态特点。
cookie技术四组件：
1、在HTTP响应报文中的一个Cookie首部行。
2、在HTTP请求报文中的一个Cookie首部行。
3、在用户端系统中保留一个Cookie文件，并由用户的浏览器进行管理。
4、位于Web站点的一个后端数据库。
Session：
Session机制是一种服务器端的机制，通过session保存状态信息，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。
Cookie与Session的区别：
1）Cookie将状态保存在客户端，Session将状态保存在服务器端；
2）Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。Cookie最早在RFC2109中实现，后续RFC2965做了增强。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies。Session并没有在HTTP的协议中定义；
3）Session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器
4）就安全性来说：当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些。因为它不会任意读取客户存储的信息。
Web缓存：
WEB缓存器也叫代理服务器，它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。缓存技术是一个比较大的议题，如今缓存技术已经是百家争鸣，redis、cdn、combo等等，没有做更深的研究，先记一个实例：
假设浏览器被配置首次请求对象被指定至Web缓存器。请求http://www.baidu.com/login.do
1、浏览器建立一个到web缓存器的TCP连接，并向Web缓存器中的对象发送一个HTTP请求
2、Web缓存器进行检查，看看本地是否存储了该对象副本。如果有，Web缓存器就向客户浏览器用HTTP响应报文返回该对象
3、如果Web缓存器没有该对象，它就打开一个与该对象的初始服务器的TCP连接。Web缓存器则在这个缓存器到服务器的TCP连接上发送一个对该对象的HTTP请求。在收到该请求后，初始服务器像该Web缓存器发送具有该对象的HTTP响应
4、当Web缓存器接收到该对象时、它在本地存储空间存储一份副本，并向客户的浏览器用HTTP响应报文发送该副本（通过现有的客户端浏览器和Web花村其之间的TCP连接）
因此，Web缓存器既是服务器又是客户。
