HTTP服务器中keep-alive 与 url常见问题

Posted 2020-07-31

一、什么是keep-alive模式

我们知道HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

    http 1.0中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；http 1.1中默认启用Keep-Alive，如果加入"Connection: close "，才关闭。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep-Alive连接就看服务器设置情况。

二、keep-alive的优点

            通过使用keep-alive机制，可以减少tcp连接次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高http服务器的吞吐率（更少的tcp连接意味着更少的系统内核调用，socket的accept（）和close（）调用）。

          RFC还指出单用户客户端与任何服务器或代理之间的连接数不应该超过2个。一个代理与其它服务器或代码之间应该使用超过2 * N的活跃并发连接。这是为了提高HTTP响应时间，避免拥塞（冗余的连接并不能代码执行性能的提升）。

三、如何判断消息内容长度的大小

        Keep-Alive模式，客户端如何判断请求所得到的响应数据已经接收完成（或者说如何知道服务器已经发生完了数据）？我们已经知道了，Keep-Alive模式发送完数据HTTP服务器不会自动断开连接，所以不能再使用返回EOF（-1）来判断。下面介绍两种判断方法：

（1）使用消息首部字段content-length，Conent-Length表示实体内容长度，客户端（服务器）可以根据这个值来判断数据是否接收完成。

（2）使用消息首部字段Transfer-Encoding

        当客户端向服务器请求一个静态页面或者一张图片时，服务器可以很清楚的知道内容大小，然后通过Content-length消息首部字段告诉客户端需要接收多少数据。但是如果是动态页面等时，服务器是不可能预先知道内容大小，这时就可以使用Transfer-Encoding：chunk模式来传输数据了。即如果要一边产生数据，一边发给客户端，服务器就需要使用"Transfer-Encoding: chunked"这样的方式来代替Content-Length。

chunk编码将数据分成一块一块的发生。Chunked编码将使用若干个Chunk串连而成，由一个标明长度为0的chunk标示结束。每个Chunk分为头部和正文两部分，头部内容指定正文的字符总数（十六进制的数字）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。

Chunk编码的格式如下：

Chunked-Body = *chunk 
                                    "0" CRLF 
                                    footer 
                                    CRLF  
chunk = chunk-size [ chunk-ext ] CRLF 
                  chunk-data CRLF

hex-no-zero = <HEX excluding "0">

chunk-size = hex-no-zero *HEX 
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) 
chunk-ext-name = token 
chunk-ext-val = token | quoted-string 
chunk-data = chunk-size(OCTET)

footer = *entity-header

即Chunk编码由四部分组成：1、0至多个chunk块，2、"0" CRLF，3、footer，4、CRLF.而每个chunk块由：chunk-size、chunk-ext（可选）、CRLF、chunk-data、CRLF组成。

四、关于消息长度

其实，上面2中方法都可以归纳为是如何判断http消息的大小、消息的数量。RFC 2616对消息的长度总结如下：一个消息的transfer-length（传输长度）是指消息中的message-body（消息体）的长度。当应用了transfer-coding（传输编码），每个消息中的message-body（消息体）的长度（transfer-length）由以下几种情况决定（优先级由高到低）：

（1）任何不含有消息体的消息（如1XXX、204、304等响应消息和任何头(HEAD，首部)请求的响应消息），总是由一个空行（CLRF）结束。

（2）如果出现了Transfer-Encoding头字段 并且值为非“identity”，那么transfer-length由“chunked” 传输编码定义，除非消息由于关闭连接而终止。

（3）如果出现了Content-Length头字段，它的值表示entity-length（实体长度）和transfer-length（传输长度）。如果这两个长度的大小不一样（i.e.设置了Transfer-Encoding头字段），那么将不能发送Content-Length头字段。并且如果同时收到了Transfer-Encoding字段和Content-Length头字段，那么必须忽略Content-Length字段。

（4）如果消息使用媒体类型“multipart/byteranges”，并且transfer-length 没有另外指定，那么这种自定界（self-delimiting）媒体类型定义transfer-length 。除非发送者知道接收者能够解析该类型，否则不能使用该类型。

（5）由服务器关闭连接确定消息长度。（注意：关闭连接不能用于确定请求消息的结束，因为服务器不能再发响应消息给客户端了。）

为了兼容HTTP/1.0应用程序，HTTP/1.1的请求消息体中必须包含一个合法的Content-Length头字段，除非知道服务器兼容HTTP/1.1。一个请求包含消息体，并且Content-Length字段没有给定，如果不能判断消息的长度，服务器应该用用400 (bad request) 来响应；或者服务器坚持希望收到一个合法的Content-Length字段，用 411 (length required)来响应。

所有HTTP/1.1的接收者应用程序必须接受“chunked” transfer-coding (传输编码)，因此当不能事先知道消息的长度，允许使用这种机制来传输消息。消息不应该够同时包含 Content-Length头字段和non-identity transfer-coding。如果一个消息同时包含non-identity transfer-coding和Content-Length ，必须忽略Content-Length 。

五、URL

        URL：统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。

统一资源定位符是统一资源标志符的一个下种。统一资源标志符确定一个资源，而统一资源定位符不但确定一个资源，而且还表示出它在哪里。在因特网的历史上，统一资源定位符（URL）的发明是一个非常基础的步骤。统一资源定位符的语法是一般的，可扩展的，它使用ASCII代码的一部分来表示互联网的地址。一般统一资源定位符的开始标志着一个计算机网络所使用的网络协议。

结构：基本URL包含模式（或称协议）、服务器名称（或IP地址）、路径和文件名，如“协议://授权/路径?查询”。完整的、带有授权部分的普通统一资源标志符语法看上去如下：协议://用户名:密码@子域名.域名.顶级域名:端口号/目录/文件名.文件后缀?参数=值#标志

第一部分

模式/协议（scheme）：它告诉浏览器如何处理将要打开的文件。最常用的模式是超文本传输协议（Hypertext Transfer Protocol，缩写为HTTP），这个协议可以用来访问网络。其他协议如下：

http——超文本传输协议资源

https——用安全套接字层传送的超文本传输协议

ftp——文件传输协议

mailto——电子邮件地址

ldap——轻型目录访问协议搜索

file——当地电脑或网上分享的文件

news——Usenet新闻组

gopher——Gopher协议

telnet——Telnet协议

第二部分

文件所在的服务器的名称或IP地址，后面是到达这个文件的路径和文件本身的名称。服务器的名称或IP地址后面有时还跟一个冒号和一个端口号。它也可以包含接触服务器必须的用户名称和密码。路径部分包含等级结构的路径定义，一般来说不同部分之间以斜线（/）分隔。询问部分一般用来传送对服务器上的数据库进行动态询问时所需要的参数。

有时候，URL以斜杠“/”结尾，而没有给出文件名，在这种情况下，URL引用路径中最后一个目录中的默认文件（通常对应于主页），这个文件常常被称为 index.html 或 default.htm。[1] 

绝对URL

绝对URL（absolute URL）显示文件的完整路径，这意味着绝对URL本身所在的位置与被引用的实际文件的位置无关，

相对URL

相对URL（relative URL）以包含URL本身的文件夹的位置为参考点，描述目标文件夹的位置。如果目标文件与当前页面（也就是包含URL的页面）在同一个目录，那么这个文件的相对URL仅仅是文件名和扩展名，如果目标文件在当前目录的子目录中，那么它的相对URL是子目录名，后面是斜杠，然后是目标文件的文件名和扩展名。

如果要引用文件层次结构中更高层目录中的文件，那么使用两个句点和一条斜杠。可以组合和重复使用两个句点和一条斜杠，从而引用当前文件所在的硬盘上的任何文件，

一般来说，对于同一服务器上的文件，应该总是使用相对URL，它们更容易输入，而且在将页面从本地系统转移到服务器上时更方便，只要每个文件的相对位置保持不变，链接就仍然是有效地。

大小写

统一资源定位符一般是分大小写的，不过服务器管理员可以确定在回复询问时大小写是否被区分。有些服务器在收到不同大小写的询问时的回复是相同的。地址结尾的"."号在互联网的发展初期，访问一个网站不是单纯的输入这样DNS服务器才能够识别。后来，微软公司在WindowsNT3.51中对其进行了修改，可以自动在DNS查询时自动增加一个.号，随后UNIX，NetWare也随之而跟进，让服务器可以识别结尾没有"."的域名。但是，符号"."在现在的网址中仍然可以使用，统一资源定位符的日常使用超文本传输协议统一资源定位符将从互联网获取信息的四个基本元素包括在一个简单的地址中。

HTTP请求

　　客户端通过发送HTTP请求向服务器请求对资源的访问。

　　HTTP请求由三部分组成，分别是： 请求行，消息报头，请求正文

　　请求行以一个方法符号开头，后面跟着请求URI和协议的版本，以CRLF作为结尾。

　　请求行以空格分隔。除了作为结尾的CRLF外，不允许出现单独的CR或LF字符，格式如下：

　　Method Request-URI HTTP-Version CRLF

　　Method表示请求的方法，Request-URI是一个统一资源标识符，标识了要请求的资源，HTTP-Version表示请求的HTTP协议版本，CRLF表示回车换行。

　　例如：

　　GET /test.html HTTP/1.1 (CRLF)

GET方法

　　GET方法用于获取由Request-URI所标识的资源的信息，常见形式是：

　　GET Request-URI HTTP/1.1

　　当我们通过在浏览器的地址栏中直接输入网址的方式去访问网页的时候，浏览器采用的就是GET方法向服务器获取资源。

 

POST方法

　　POST方法用于想服务器发送请求，这点和GET方法没有区别。但是POST方法要求服务器接收附在请求后面的数据。

　　POST方法在表单提交的时候用的最多。

　　采用POST方法提交表单的例子

　　POST /login.jsp HTTP/1.1 (CRLF)

　　Accept: image/gif (CRLF) (…)

　　Host: www.sample.com (CRLF) (…)

　　…

　　Cache-Control: no-cache (CRLF)

　　(CRLF)

　　username=hello&password=123456

　　当我们在HTML中提交表单时，浏览器会根据你的提交方法是get还是post，采用相应的在HTTP协议中的GET或POST方法，向服务器发出请求。

　　注意，在HTML文档中，书写get和post，不区分大小写，但HTTP协议中的GET和POST只能是大写形式。

 

HEAD方法

　　HEAD方法与GET方法几乎是一样的，它们的区别在于HEAD方法只是请求消息报头，而不是完整的内容。

　　对于HEAD请求的回应部分来说，它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。

　　利用这个方法，不必传输整个资源的内容，就可以得到Request-URI所标识的资源的信息。

　　这个方法通常用于测试超链接的有效性，是否可以访问，以及最近是否更新等。

各浏览器与各Web Server对URL均有长度的限制如下：

在http协议中，其实并没有对url长度作出限制，往往url的最大长度和用户浏览器和Web服务器有关，不一样的浏览器，能接受的最大长度往往是不一样的，当然，不一样的Web服务器能够处理的最大长度的URL的能力也是不一样的。
下面就是对各种浏览器和服务器的最大处理能力做一些说明.

Microsoft Internet Explorer (Browser)
IE浏览器对URL的最大限制为2083个字符，如果超过这个数字，提交按钮没有任何反应。在我的测试中，这个数字得到验证。

微软官方也有说明：

Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs.
If you are using the GET method, you are limited to a maximum of 2,048 characters, minus the number of characters in the actual path.
However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL.

Firefox (Browser)
对于Firefox浏览器URL的长度限制为65,536个字符，但当我测试时，最大只能处理8182个字符，这是因为url的长度除了浏览器限制外，还会受Web服务器的限制，而我本机使用的是ubuntu apache服务器，最大处理能力为8192个字符(相差10个字符，不知道是什么原因)，一旦超过这个长度，服务器就返回如下错误信息。

Safari (Browser)
URL最大长度限制为 80,000个字符。

Opera (Browser)
URL最大长度限制为190,000个字符。

Google (chrome)
url长度一旦超过8182个字符时，出现如下服务器错误：

写道

Request-URI Too Large
The requested URL‘s length exceeds the capacity limit for this server.
Apache/2.2.12 (Ubuntu) Server at 127.0.1.1 Port 80

Apache (Server)
能接受最大url长度为8,192个字符，但我的测试数据是8,182，10个字符，差别不在，数据具体符合。

Microsoft Internet Information Server(IIS)
能接受最大url的长度为16,384个字符。

通过上面的数据可知，为了让所有的用户都能正常浏览，我们的URL最好不要超过IE的最大长度限制(2038个字符），当然，如果URL不直接提供给用户，而是提供给程序调用，侧这时的长度就只受Web服务器影响了。

　　

本文出自 “柏拉图的永恒” 博客，请务必保留此出处http://ab3813.blog.51cto.com/10538332/1793439