Http读书笔记1-5章

第一章

内容提要

• 这一章主要介绍了什么是http以及http是干嘛的，以及与之有关的相关概念，当然了这些概念都是概览式的介绍一些。所以我将采用问答式的方式描述这一章！

Q:http是干嘛的？

A:http是数据传输协议（超文本传输协议），用来沟通客户端和服务器的！

Q:什么是资源？

A:记住一句话，网络上的一切内容皆资源，无论是静态文件，还是动态生成的代码等！

Q:什么是媒体类型？

A:其实就是一种数据类型标记，用来告诉接收端，接收到的数据是什么类型，让接收端知道怎么才能处理该文件！常见标记方式就是MIME，MIME描述了文件的主要类型以及特定子类型，例如："Content-Type":"text/html"，其中text描述的文件的主要类型是文本，而其特定类型是html文档！

Q:怎么理解URI以及它的子集？

A:首先URI从其概念来说是统一资源标识符，它的作用就是在网络上唯一确定一个资源，就好比，在中国，身份证能唯一确定一个人一样！知道身份证号，就一定能确定一个人姓甚名谁一样！它有两个子集：URL(统一资源定位符)和URN(统一资源名)，首先不特别声明，我们所说的URI就是指URL，URL是跟资源其在网络上的位置有关！而URN是指资源跟其名字有关，URN是未来的趋势，不过貌似具体实施现在还在商讨中！所以短时间之内URN难以取代URL！

Q:什么是事务？

A:说白了事务就是“一次http链接（不包括tcp/ip连接，只包括一次http报文发送与接收）”的整个过程，由请求命令和响应结果组成！中间数据格式是http报文。我们平常打开一个网站，里面包括很多事务！如：请求网页文档、请求某个logo图片及请求某个视频等！

Q:方法指什么？

A:方法就是客户端向服务器发起的请求命令！常见方法有：get、post、delete、put、head！

Q:状态码有什么用？

A:状态码对程序有用，便于程序进行相关控制！原因短语对人有用！

Q:简单介绍一些报文！

A:首先报文是http协议一种纯文本的数据格式，分为请求报文和响应报文，两种报文都具有类似的结构，分别由三个部分构成：起始行、首部、主体，起始行描述报文干了什么！首部描述报文传输的具体细节！主体描述传输的实际内容！

Q:什么是TCP/IP？跟HTTP有什么关系？

A:tcp/ip是全世界的计算机和网络设备常用的层次化分组交换网络协议集！简单的说，http协议是一个应用层协议，位于tcp/ip协议的上一层，tcp/ip协议的主要作用就是过滤掉每个计算机的差异性，隐藏相关弱点，使得对于http协议来说提供的都是“相同的”接口！

Q:在一次网络请求中，分别经历那些过程？

A:步骤如下：

(a)浏览器从url中解析处服务器的主机名；

(b)浏览器将服务器的主机名转换成服务器的的ip地址；（可能经过去dns服务器查询）

(c)浏览器将端口号（如果有的话）从url中解析出来；

(d)浏览器建立一条与web服务器的tcp连接；

(e)浏览器向服务器发送一条http请求报文；

(f)服务器向浏览器回送一条http响应报文；

(g)关闭连接，浏览器显示文档

Q:http协议有哪些版本？

A:

http/0.9，这个版本有严重设计权限

http/1.0，广泛使用

http/1.0+ 非官方的http/1.0的扩展版本

http/1.1 目前正在使用的版本，修复的相关设计缺陷，增加的相关特性

http-NG 将来使用与否正在商讨中

Q:介绍一下web中的一些结构组件？

A:主要有代理、缓存、网关以及隧道！分别简介如下：

• • 代理：代理位于客户端和服务器之间，接收所有客户端的HTTP请求，并把这些请求转发给服务器（可能会对请求进行修改之后转发）。对用户来说，这些应用程序就是一个代理，代表用户访问服务器。代理的主要作用有过滤、屏蔽等！（还有需要注意一点：代理既可以代表服务器对客户端进行响应，又可以代表客户端对服务器进行请求！）
• • 缓存：首先说明一下，缓存某种意义上来说也是一种代理服务器。它主要使用代表服务器对客户端进行响应。发送预先缓存好的资源的副本。这样会加快事务响应速度、同时也会减少服务器的负载、减轻带宽等问题！
• • 网关：网关是一种特殊的服务器，面对客户端时好像它就是服务器，而对于服务器，他又充当客户端的角色，它的主要作用是协议转换！例如HTTP/FTP网关。
• • 隧道：就是一个连接通道，用于在http信道上发送非http协议的资源。
• • Agent代理：说白了就是我们平时所说的浏览器，以及web机器人、爬虫等！

第二章

内容提要

• 本章讲解了URI（统一标识符）严格来说，这一章是介绍URL(统一资源定位符)的!分别介绍了URL是由那些组件构成、每个组件代表的含义是什么、浏览器是如何解析每个组件的以及从URL的完成性和安全性来说如何进行URL不安全字符进行转义。当然最后还简单介绍了URI的另一个子类URN（统一资源名）。

URI的分类

• URI（统一资源标识符）由URL（统一资源定位符）和URN（统一资源名）两个子集构成。URL是从资源的位置来定义一个资源的，比如在“中国三东的一只小狗”和在“中国广东的一只小狗”就分别定义了两只不同的狗。而URN是从资源的名字来定义的，比如小明和小李就分别定义了两个人。目前的网络架构来说，大部分都是URL。URL的缺点就是如果资源的位置发生了改变，那么资源也就找不到了，而URN正是解决这个问题的，因为URN不受位置的限制，它只受名字的管理，因为对于URN来说，一个资源的名字是唯一的，所以无论资源移动到什么地方，都能通过名字定位到资源。从某种意义上来说，URN是URI的未来趋势，但是URN的实现需要一个中间架构来满足这种位置到名字的映射，所以要完成从URL到URN的过度，显然是一个工程量的过程，如果不是URL到了不能用的时候，URN的实现需要很长的时间，幸运的是现在URL架构还是很好的满足网络需求的！

URL的语法

• URL的语法描述的是URL由哪些组件构成，以及这些组件是怎么组合成一个URL，中间由什么符号连接，每个组件代表什么等！其格式如下：

	<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

其中：

scheme:方法描述了请求资源时用了什么协议，用“:”与url其它部分隔开；

user:用户名描述了访问是带的用户名；

password:密码描述了用户名后面可能跟的密码，用“:”跟用户名隔开；

host:主机描述了网站主机名或ip地址，如果前面有用户名和密码，用@分开；

post:服务器当前正在监听的端口，http默认为80，https默认为443;

path:路劲描述了资源在服务器上的位置，用‘/’跟前面部分隔开；

params:参数描述了请求需要附加的参数，用“;”与其他部分隔开；

query:查询是用来激活服务器程序去执行某些操作，比如查询数据库等，用“?”与其余部分隔开；

frag:片段只在客户端使用，不发送到服务器端；

URL快捷方式

• url快捷方式描述了一种程序如何通过相对地址解析处绝对地址的过程以及在浏览器地址栏输入部分url浏览器自动补全主机名的一种机制！

• 相对地址转换为绝对地址：首先会根据一个基础地址来得出协议、主机名、端口等！基础地址可以通过base标签显示定义，也可以由当前所在资源的地址得出！相关接口通过继承的方式附在相对地址上，最后得到绝对地址。

• 浏览器扩展地址主要通过主机名扩展和历史扩展等方式实现自动地址补全！

url编码

Q:为什么需要编码？

A:主要从url的一致性、安全性、以及完整性来强调需要对url字符进行编码。比如因为一个url连接的两端可能出现的机器种类很多，为了让大家都能够解析出一个相同的url，所以有必要对某些不安全的url字符进行转义。

Q:url字符集由什么编码构成？

A:早前的url是有US-ASCII码编码，但是随着网络在全世界的流行，有很多字符是US-ASCII不能编码的，因为US-ASCII码最多只能编译127个字符。通过转义序列，就可以用US-ASCII字符集的有限子集对任意字符值或数据进行编码了。

Q:编码机制？

A:为了避开安全字符集表示法带来的限制，人们设计了一种编码机制，用来在URL中表示各种不安全的字符。这种编码机制就是通过一种“转义”表示法来表示不安全字符的，这种转义表示法包含一个百分号（%），后面跟着两个表示字符的ASCII码的十六进制数。

Q:那些字符不建议在URL里面使用？

A:在URL中，有几个字符被保留起来，有着特殊的含义。有些字符不在定义的US-ASCII可打印字符集中。还有些字符会与某些因特网网关和协议产生混淆，因此不赞成使用，比如“%”。

第三章

内容提要

这一章内容较多，介绍了http报文的诸多相关概念，譬如起始行、首部、主体以及它们代表的含义等！同时还介绍了常见的状态码及其含义，常见的首部字段及其含义。本章内容较丰实，所以概念模糊的部分可以参阅原书相关章节！

报文流

这是形容http报文的

• http报文是以一种类似的流的方式来发送数据的，所以报文流讲述了http报文的一些客观状态，相关术语：流入、流出形容事务处理。http报文任何时候是从上游向下游流入的！其中进过的节点既可能是上游，有可能是下游，如果从某个节点流出，那么相对于此节点流入的那个节点，它就是上游，翻过它就是下游！

报文的组成部分

• 首先说明，报文由三个部分组成，起始行、首部、主体。起始行和首部都是ascll文本，而主体则可以是任意类型文件，比如二进制，视频等！且起始行和首部都已一个crlf作为结束符，并且首部与主体之间应始终存在一个以crlf序列作为结束的空行。当然了为了兼容老版本的http，这里有时并不是那么严格要求非要crlf同时存在！

• 报文的语法

http报文分为请求报文和相应报文，其语法分别如下：

	//请求报文

	<method> <request-URL> <version>
	<headers>

	<entity-body>

	//响应报文

	<version> <status> <reason-phrase>
	<headers>

	<entity-body>

相关概念分别如下：

*方法是客户端希望执行的动作，如GET、POST等*

*请求url是指请求资源的路劲*

*报文版本号，格式为http/<major>.<minor>,分别代表主要版本号和次要版本号，其含义应分开理解*

*其实说白了就是用一个数字表示当前事务处于什么状态，便于开发者处理*

*原因短语，实际意义不大，就是为了方便人看的*

*首部就是一个包含零个或多个的键值对，键值对以crlf隔开，而键、值之间以‘:’隔开，期间包含一个可选的空格*

*任意格式组成的数据块，也是实际发送的内容*

• 起始行

分为请求行和响应行，格式前面一个在前面，相关概念不在赘述！

• 首部

说一下首部分类，主要有五类：通用首部、请求首部、响应首部、主体首部、扩展首部。通用首部就是请求报文和响应报文都可以用，用以说明报文的一般属性；请求首部出现在请求报文中，用于客户端告诉服务器是什么情况，比如能接受什么，不能接受什么等；响应报文用于响应报文中，服务器端用来告诉客户端什么情况；主体首部用来描述主体的信息，比如主体的长度是多少等；扩展报文是非官方的报文，但是http也支持发送。

方法

• 安全方法

能在服务器端有操作的就是非安全方法，比如delete、put、post,不在服务器端有操作的就是安全方法，比如get、header，当然了安全方法并非不能在服务器端有操作，这是开发者可以控制的！

• GET方法用于请求服务器端发送某个资源

• HEADER方法跟GET方法类似，区别就是不返回主体

• PUT方法用于向服务器端修改、插入数据

• POST方法用于向服务器端发送数据

• TRACK方法用于向服务器端请求报文在发送的过程中经过了什么修改，主要用于测试

• OPTIONS用于请求服务器告知其支持什么功能

• DELETE用于向服务器删除某个指定的资源

• 扩展方法其实类似于自定义方法

####　状态码

• 100-199 信息性状态码

• 200-299 成功状态码 （常见200表示请求成功）

• 300-399 重定向状态码 （常见302重定向）

• 400-499 客户端错误状态码 （常见404，请求资源不存在）

• 500-599 服务端错误状态码

常见状态码及其含义整理

	状态码				原因短语     				含义

	100					Continue 			说明收到了请求的初始部分，请客户端继续，发送了这个状态码之后，
											服务器在收到请求之后必须进行响应。

	101					Switching Protocols 说明服务器正在根据客户端的指定，将协议切换成Update首部所列的
											协议

	200 				OK					请求没问题，实体的主体部分包含了所请求的资源

	201 				Created				用于创建服务器对象的请求（比如，PUT）。响应的实体主体部分中
											应该包含各种引用了已创建的资源的URL，Location首部包含的则是最具体的引用。

	202 				Accepted			请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这
											个请求；这只是意味着接受请求时，它看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置）

    203 				Non-Authoritative   实体首部包含的信息不是来自原远端服务器，而是来自于资源的一份副本。 
    					Information 		如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的
    										元信息进行验证，就会出现这种情况

    204					No 	Content         响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在
    										浏览器不转为显示新文档的情况下，对其进行更新（比如刷新一个表单页面）

    205					Reset Content 		另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有HTML
    										表单元素

    206					Partial Content 	成功执行了一个部分或Range(范围)请求。稍后我们会看到，客户端可以通过
    										一些特殊的首部来获取部分或某个范围内的文档————这个状态码就说明范围请求成功了。


    注：在对那些包含了重定向状态码的非HEAD请求进行响应时，最好要包含一个实体，并在实体中包含描述信息和指向（多个）重定向URL的链接。如：

    HTTP/1.1 301 OK
    Location: http://www.gentle-grooming.com/
    Content-Length: 56
    Content-Type: text/plain

    Please go to our partner site,
    www.gentle-grooming.com



    300					Multiple Choices 	客户端请求一个实际指向多个资源的URL时会返回这个状态码，比如服务器
    										上有某个HTML文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就可以选择它希望使用的那一项了。有多个版本可用时，客户端需要沟通解决。

    301					Moved Permanently	在请求的URL已被移除时使用。响应的Location首部中应该包含资源现在所处
    										的URL

    302 				Found 				与301状态码类似，但是，客户端应该使用Location首部给出的URL来临时定位
    										资源。将来的请求仍应该使用老的URL

    303 				See Other 			告知客户端应该用另一个URL来获取资源。新的URL位于响应报文的Location
    										首部。其主要母的是允许POST请求的响应将客户端定向到某个资源上去

    304  				Not Modified 		客户端可以通过所包含的请求首部，使其请求变成有条件的。如果客户端发起
    										了一个条件GET请求，而最近资源未被修改的话，就可以用这个状态码来说明
    										资源未被修改。带有这个状态码的响应不应该包含实体的主体部分。

    305 				Use Proxy  			用来说明必须通过一个代理访问资源；代理的位置由Location首部给出。很
    										重要的一点是，客户端是相对某个特定资源来解析这条响应的，不能假定所有请求。甚至所有对持有请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理介入了某条请求，可能会引发破坏性的行为，而且会造成安全漏洞。

   	307					Temporary Redireat 与301状态码类似；但客户端应该使用Location首部给出的URL来临时定位资源
   											。将来的请求应该使用老的URL


   	400 				Bad Request 		用于告知客户端发起了一个错误的请求

   	401 				Unauthorized 		返回适当的首部，用于获取客户端访问资源的权限

   	402         		Payment Required    此状态码未使用，保留

   	403                 Forbidden           服务器拒绝请求，可在响应主体中告知原因

   	404  				Not Found           用于告知客户端请求的资源在服务器不存在

   	405 				Method Not Allowd   告知客户端不支持当前方法，并在Allow首部返回支持的方法

   	406 				Not Acceptable     	没有客户端支持的资源类型

   	407 				Proxy Authentication  跟401类似，不过用户代理服务器
   						Requireed 

   	408 				Request Timeout     超时提醒

   	409      			Conflict            请求会造成服务器冲突

   	410  	            Gone   				跟404一样，只不过服务器曾经拥有过该请求资源

   	411 				Length Required    要求客户端发送Content-Length首部

   	412 				Precondition Failed  部分条件验证不通过

   	413   				Request Entity Too Large  客户端发送的主体超过了服务器的希望的长度

   	414 				Request  URL Too Long   客户端请求的时间比服务希望的时间长

   	415 				Unsupported Media Type 	服务器无法理解客户端请求的主体类型

   	416 				Requested Range Not    请求报文所请求的是指定资源的某个范围，而此范围无效或无法满足时
   						Satisfiable   			，使用此状态码

   	417					Expectation Failed 		请求中包含Expect首部，服务器无法满足

   	500					Internal Server Error  服务器错误

   	501 				Not Implemented         请求超出了服务器能处理的范围

   	502 				Bad Gateway 			作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条
   												伪响应（比如，它无法连接到其父网关）时，使用此状态码

   	503    				Service Unavailable 	用来说明服务器现在无法为请求提供服务，但将来可以。如果服务器
   												知道什么时候资源会变为可用的，可以在响应中包含包含一个
   												Retry-After首部。

   	504 				Gateway Timeout 		与状态码408类似，只是这里的响应来自一个网关或代理，它们在等待另
   												一服务器对其请求进行响应时超时了

    505 				HTTP Version Not        服务器收到的请求使用了它无法或不愿支持的协议版本时，使用此
    					Supported 				状态码。有些服务器应用程序会选择不支持协议的早起版本	

常见首部字段含义介绍

• 注：首部分为通用首部、请求首部、响应首部、主体首部、扩展首部！

• 通用首部

   通用的信息性首部

   首部                                         描述

   Connection               允许客户端和服务器指定与请求/响应连接有关的选项

   Date                     提供了日期的时间标志，说明报文是什么时间创建的

   MIME-Version             给出了发送端使用的MIME版本

   Trailer                  如果报文采用了分块传输编码方式，就可以用这个首部列出位于报文拖挂部分的首部集合

   Transfer-Encoding        告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式

   Update                   给出了发送端可能想要“升级”使用的新版本或协议

   Via                      显示了报文经过的中间节点（代理、网关）


   通用缓存首部

   首部                                 描述

   Cache-Control            用于随报文传送缓存指示

   Pragma                   另一种随报文传送指示的方式，但并不专用缓存

• 请求首部

    请求的信息性首部

    首部                                描述

    Client-IP               提供了运行客户端的机器的IP地址

    From                    提供了客户端用户的E-mail地址

    Host                    给出了接收请求的服务器的主机名和端口号

    Referer                 提供了包含当前请求URL的文档的URL

    UA-Color                提供了与客户端显示器的显示颜色有关的信息

    UA-CPU                  给出了客户端CPU的类型或制造商

    UA-Disp                 提供了与客户端显示器（屏幕）能力有关的信息

    UA-OS                   给出了运行在客户端机器上的操作系统名称及版本

    UA-Pixels               提供了客户端显示器的像素信息

    User-Agent              将发起请求的应用程序名称告知服务器

    Accept首部

    首部                                  描述

    Accept                  告诉服务器能够发送那些媒体类型

    Accept-Charset          告诉服务器能够给发送那些字符集

    Accept-Encoding         告诉服务器能够发送那些编码方式

    Accept-Language         告诉服务器能够发送那些语言

    TE                      告诉服务器可以使用那些扩展传输编码



    条件请求首部

    首部                                描述

    Expect                  允许客户端列出某请求所要求的服务器行为

    If-Match                如果实体标记与文档当前的实体标记相匹配，就获取这份文档

    If-Modified-Since       除非在某个指定的日期之后资源被修改过，否则就限制这个请求

    If-None-Match           如果提供的实体标记与当前文档的标记不相符，就获取文档

    If-Range                允许对文档的某个范围进行条件请求

    If-Unmodified-Since     除非在某个指定日期之后资源没有被修改过，否则就限制这个请求

    Range                   如果服务器支持范围请求，就请求资源的指定范围


    安全请求首部

    首部                                  描述

    Authorization           包含了客户端提供给服务器，以便对其自身进行认证的数据

    Cookie                  客户端用它向服务器传送一个令牌————它并不是真正的安全首部，但确实隐含了安全功能

    Cookie2                 用来说明请求端支持的cookie版本



    代理请求首部

    首部                                  描述

    Max-Forward             在通往源端服务器的路径上，将请求转发给其他代理或网关的最大次数————与TRACE方法一同
                            使用

    Proxy-Authorization     与Authorization首部相同，但这个首部是在与代理进行认证时使用的

    Proxy-Connection        与Connection首部相同，但这个首部是在与代理建立连接时使用的

• 响应首部

    响应的信息性首部

    首部                                        描述

    Age                     （从最初创建开始）响应持续时间

    Public                   服务器为其资源支持的请求方法列表

    Retry-After              如果资源不可用的话，在此日期或时间重试

    Server                   服务器应用程序软件的名称和版本

    Title                    对HTML文档来说，就是HTML文档的源端给出的标题

    Warning                  比原因短语中更详细的警告报文


    协商首部

    首部                                  描述

    Accept-Ranges           对此资源来说，服务器可接受的范围类型

    Vary                    服务器查看的其他首部的列表，可能会使响应发生变化；也就是说，这是一个首部列表，
                            服务器会根据这些首部的内容挑选处最合适的资源版本发送个客户端

    安全响应首部

    首部                                    描述

    Proxy-Authenticate      来自代理的对客户端的质询列表

    Set-Cookie              不是真正的安全首部，但隐含有安全功能；可以在客户端设置一个令牌，以便服务器对客户端
                            进行标志

    Set-Cookie2             与Set-Cookie类似

    WWW-Authenticate        来自服务器的对客户端的质询列表

• 实体首部

  实体的信息性首部

  首部                                          描述

  Allow                       列出了可以对此实体执行的请求方法

  Location                    告知客户端实体实际上位于何处；用于将接收端丁香到资源的位置上去


  内容首部

  首部                                          描述

  Content-Base                解析主体中的相对URL时使用的基础URL

  Content-Encoding            对主体执行的任意编码方式

  Content-Language            理解主体时最适宜使用的自然语言

  Content-Length              主体的长度或者尺寸

  Content-Location            资源实际所处的位置

  Content-MD5                 主体的MD5校验和

  Content-Range               在整个资源中此实体表示的字节范围

  Content-Type                这个主体的对象类型

  实体缓存首部

  首部                                                  描述

  ETag                        与此实体相关的实体标记

  Expires                     实体不再有效，要从原始的源端再次获取此实体的日期和时间

  Last-Modified               这个实体最后一次被修改的日期和时间

第四章

内容提要

• 本章简单介绍了web服务器原理、实现以及实现处理http事务的一些细节！

web服务器

• 定义：实现提供资源或应答的提供者都可以谓之为服务器！

• 从不同形式划分，服务器有以下几种：

  1. 标准计算机上安装的通用服务器，如apache

  2. 购买的服务器

  3. 嵌入式服务器

web服务器应该做些什么

1. 接受建立连接请求

2. 接受请求

3. 处理请求

4. 访问报文中指定的资源

5. 构建响应

6. 发送响应

7. 记录事务处理过程

第一步————接受客户端连接

• 客户端收到一条连接之后，那么它将会把新连接添加到现存web服务器连接列表中，用于监视当前连接上的数据传输情况。期间服务器还应该做到通过一定的设备机制阻止未认证或已知恶意黑名客户端的连接，相关设别技术有：客户端主机名设别、通过ident设别客户端用户等！

第二步————接收请求报文

• 主要经过几个步骤来解析报文：

1. 解析请求行，得知方法、url、协议版本，以及crlf符

2. 解析得到以crlf结尾的首部

3. 得到以crlf结尾，标志首部结束的空行（如果有的话）

4. 解析得到主体，（如果有的话）

• web服务可能还会把请求报文用一种自己能快速处理的内部数据结构来存储请求报文！

• 不同的服务器配置预示它能同时处理的事务情况：

1. 单线程web服务器：只能处理一个请求，待当前请求处理完成之后才能处理下一个请求！优点：简单已于实现，适用于低负荷服务器。缺点：不能及时处理其他请求，容易引发延迟过长而导致性能问题。

2. 多线程及多进程web服务器：能同时处理多个请求！优点：响应及时。缺点：构建复杂，容易快速引起内存消耗过大而死机！最好应该对能同时处理的连接数量进行限制！

3. 复用i/o的web服务器：复用i/o

4. 复用i/o和多线程的web服务器：2和3的结合

第三步————处理请求

• 这点留在本书其余章节大篇幅介绍！

第四步————对资源的映射及访问

• 这里介绍了请求资源的一种路径映射关系，说白了就是找到客户端请求资源在服务器的上的目录路径！相关概念有：docroot(文档根目录)、不允许访问根目录的上一级目录。

• 虚拟托管的docroot:在一个服务器上挂了几个web站点，那么这样当请求的资源路径相同时，服务器应该从请求报文首部的host、uri字段找出真正的资源目录，这些目录都是可以配置的！

• 注：这里对用户配置文件根目录和虚拟目录做一下示例说明，以apache为例：

  配置文件根目录
  在配置文件httpd.conf中添加一个DocumentRoot行就可以为Apache Web服务器设置文档的根目录了，如：

  	DocumentRoot /user/local/httpd/files


  配置虚拟目录
  对大多数Web服务器来说，配置虚拟托管的文档根目录是很简单的。对常见的Apache Web服务器来说，需要为每个虚拟Web
  站点配置一个VirtualHosts块，而且每个虚拟服务器都要包含DocumentRoot，如：

  <VirtualHost www.joes-hardware.com>
  	ServerName www.joes-hardware.com
  	DocumentRoot /docs/joe
  	TransferLog /logs/joe.access_log
  	ErrorLog /logs/joe.error_log
  </VirtualHost>

  <VirtualHost www.marys-antiques.com>
  	ServerName www.marys-antiques.com
  	DocumentRoot /docs/mary
  	TransferLog /logs/mary.access_log
  	ErrorLog /logs/mary.error_log
  </VirtualHost>

     ... 

第五步————构建响应

• 构建响应报文：1、正确设置响应主体的长度（content-length）；2、设置报文的mime类型（content-type）,主要通过与一直mime类型文件匹配得到当前的文件的mime类型，还可以通过文件扩展名，以及硬规定特定目录下的文件拥有某个mime类型；3、控制重定向！

• 服务器端如何得出文件的MIME类型：

	Web服务器要负责确定响应主体的MIME类型。有很多配置服务器的方法可以将MIME类型与资源关联起来。

	1、MIME类型（mime.types）
	   Web服务器可以用文件的扩展名来说明MIME类型。Web服务器会为每个资源扫描一个包含了所有扩展名的MIME类型的文件，以确定其MIME类型。这种基于扩展名的类型相关是最常见的！

	2、魔法分类（Magic typing）
	   Apache Web服务器可以扫描每个资源的内容，并将其与一个已知模式表（被称为魔法文件）进行匹配，以决定每个文
	   件的MIME类型。这样做可能比较慢，但很方便，尤其是文件没有标准扩展名的时候。

	3、显示分类（Explicit typing）
	   可以对Web服务器进行配置，使其不考虑文件的扩展名或内容，强制特定文件或目录内容拥有某个MIME类型

	4、类型协商
	   有些Web服务器经过配置，可以以多种文档格式来存储资源。在这种情况下，可以配置Web服务器，使其可以通过与用户的协商来是决定使用哪种格式（及相关的MIME类型）“最好”。

重定向

• 有时服务器需要返回重定向报文来构建响应，重定向响应由返回码3XX说明。Location响应首部包含了内容的新地址或优选地址的URL。重定向可用于下列情况。

• • 永久删除的资源，状态码为301
• • 临时删除的资源，状态码为303或307
• • URL增强，状态码为303或307
• • 负载均衡，主要是减少服务器的压力，让请求跑到一个负载不大的服务器上去，状态码为303或307
• • 服务器关联，去保存有用户本地信息的服务器上获取用户信息，状态码为303或307
• • 规范目录名称，客户端请求的URI是一个不带尾部斜线的目录名时，大多数Web服务器都会将客户端重定向到一个加了斜线的URI上，这样相对链接就可以正常工作了！

第六步————发送响应

• 略

第七步————记录事务日志

• 在web服务器日志文件中添加一个条目，以描述当前事务处理情况！

第五章

内容提要

• 本章简单介绍了web服务器原理、实现以及实现处理http事务的一些细节！

web服务器

• 定义：实现提供资源或应答的提供者都可以谓之为服务器！

• 从不同形式划分，服务器有以下几种：

  1. 标准计算机上安装的通用服务器，如apache

  2. 购买的服务器

  3. 嵌入式服务器

web服务器应该做些什么

1. 接受建立连接请求

2. 接受请求

3. 处理请求

4. 访问报文中指定的资源

5. 构建响应

6. 发送响应

7. 记录事务处理过程

第一步————接受客户端连接

• 客户端收到一条连接之后，那么它将会把新连接添加到现存web服务器连接列表中，用于监视当前连接上的数据传输情况。期间服务器还应该做到通过一定的设备机制阻止未认证或已知恶意黑名客户端的连接，相关设别技术有：客户端主机名设别、通过ident设别客户端用户等！

第二步————接收请求报文

• 主要经过几个步骤来解析报文：

1. 解析请求行，得知方法、url、协议版本，以及crlf符

2. 解析得到以crlf结尾的首部

3. 得到以crlf结尾，标志首部结束的空行（如果有的话）

4. 解析得到主体，（如果有的话）

• web服务可能还会把请求报文用一种自己能快速处理的内部数据结构来存储请求报文！

• 不同的服务器配置预示它能同时处理的事务情况：

1. 单线程web服务器：只能处理一个请求，待当前请求处理完成之后才能处理下一个请求！优点：简单已于实现，适用于低负荷服务器。缺点：不能及时处理其他请求，容易引发延迟过长而导致性能问题。

2. 多线程及多进程web服务器：能同时处理多个请求！优点：响应及时。缺点：构建复杂，容易快速引起内存消耗过大而死机！最好应该对能同时处理的连接数量进行限制！

3. 复用i/o的web服务器：复用i/o

4. 复用i/o和多线程的web服务器：2和3的结合

第三步————处理请求

• 这点留在本书其余章节大篇幅介绍！

第四步————对资源的映射及访问

• 这里介绍了请求资源的一种路径映射关系，说白了就是找到客户端请求资源在服务器的上的目录路径！相关概念有：docroot(文档根目录)、不允许访问根目录的上一级目录。

• 虚拟托管的docroot:在一个服务器上挂了几个web站点，那么这样当请求的资源路径相同时，服务器应该从请求报文首部的host、uri字段找出真正的资源目录，这些目录都是可以配置的！

• 注：这里对用户配置文件根目录和虚拟目录做一下示例说明，以apache为例：

  配置文件根目录
  在配置文件httpd.conf中添加一个DocumentRoot行就可以为Apache Web服务器设置文档的根目录了，如：

  	DocumentRoot /user/local/httpd/files


  配置虚拟目录
  对大多数Web服务器来说，配置虚拟托管的文档根目录是很简单的。对常见的Apache Web服务器来说，需要为每个虚拟Web
  站点配置一个VirtualHosts块，而且每个虚拟服务器都要包含DocumentRoot，如：

  <VirtualHost www.joes-hardware.com>
  	ServerName www.joes-hardware.com
  	DocumentRoot /docs/joe
  	TransferLog /logs/joe.access_log
  	ErrorLog /logs/joe.error_log
  </VirtualHost>

  <VirtualHost www.marys-antiques.com>
  	ServerName www.marys-antiques.com
  	DocumentRoot /docs/mary
  	TransferLog /logs/mary.access_log
  	ErrorLog /logs/mary.error_log
  </VirtualHost>

     ... 

第五步————构建响应

• 构建响应报文：1、正确设置响应主体的长度（content-length）；2、设置报文的mime类型（content-type）,主要通过与一直mime类型文件匹配得到当前的文件的mime类型，还可以通过文件扩展名，以及硬规定特定目录下的文件拥有某个mime类型；3、控制重定向！

• 服务器端如何得出文件的MIME类型：

	Web服务器要负责确定响应主体的MIME类型。有很多配置服务器的方法可以将MIME类型与资源关联起来。

	1、MIME类型（mime.types）
	   Web服务器可以用文件的扩展名来说明MIME类型。Web服务器会为每个资源扫描一个包含了所有扩展名的MIME类型的文件，以确定其MIME类型。这种基于扩展名的类型相关是最常见的！

	2、魔法分类（Magic typing）
	   Apache Web服务器可以扫描每个资源的内容，并将其与一个已知模式表（被称为魔法文件）进行匹配，以决定每个文
	   件的MIME类型。这样做可能比较慢，但很方便，尤其是文件没有标准扩展名的时候。

	3、显示分类（Explicit typing）
	   可以对Web服务器进行配置，使其不考虑文件的扩展名或内容，强制特定文件或目录内容拥有某个MIME类型

	4、类型协商
	   有些Web服务器经过配置，可以以多种文档格式来存储资源。在这种情况下，可以配置Web服务器，使其可以通过与用户的协商来是决定使用哪种格式（及相关的MIME类型）“最好”。

重定向

• 有时服务器需要返回重定向报文来构建响应，重定向响应由返回码3XX说明。Location响应首部包含了内容的新地址或优选地址的URL。重定向可用于下列情况。

• • 永久删除的资源，状态码为301
• • 临时删除的资源，状态码为303或307
• • URL增强，状态码为303或307
• • 负载均衡，主要是减少服务器的压力，让请求跑到一个负载不大的服务器上去，状态码为303或307
• • 服务器关联，去保存有用户本地信息的服务器上获取用户信息，状态码为303或307
• • 规范目录名称，客户端请求的URI是一个不带尾部斜线的目录名时，大多数Web服务器都会将客户端重定向到一个加了斜线的URI上，这样相对链接就可以正常工作了！

第六步————发送响应

• 略

第七步————记录事务日志

• 在web服务器日志文件中添加一个条目，以描述当前事务处理情况！