目录
1 简介
1.1 简单的HTTP协议
HTTP协议，全称HyperText Transfer Protocol，中文名为超文本传输协议，是互联网中最常用的一种网络协议。HTTP的重要应用之一是WWW服务。设计HTTP协议最初目的就是提供一种发布和接收HTML（一种页面标记语言）页面的方法（请求返回）。
HTTP协议是互联网上常用的通信协议之一。它有很多的应用，但最流行的就是用于Web浏览器和Web服务器之间的通信，即WWW应用或称Web应用。
WWW，全称World Wide Web，常称为Web，中文译为“万维网”。它是目前互联网上最受用户欢迎的信息服务形式。HTTP协议的WWW服务应用的默认端口为80（端口的概念），另外的一个加密的WWW服务应用https的默认端口为443，主要用于网银，支付等和钱相关的业务。当今，HTTP服务，WWW服务，Web服务三者的概念已经混淆了，都是指当下最常见的网站服务应用。
HTTP是基于TCP协议之上的。在TCP/IP协议参考模型的各层对应的协议如下图,其中HTTP是应用层的协议。
1.2 主要特点
http1.0的主要特点:
简单快速：当客户端向服务器端发送请求时，只是简单的填写请求路径和请求方法即可，然后就可以通过浏览器或其他方式将该请求发送就行了 。
灵活： HTTP 协议允许客户端和服务器端传输任意类型任意格式的数据对象
无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。(当今多数服务器支持Keep-Alive功能，使用服务器支持长连接，解决无连接的问题)
无状态：无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即客户端发送HTTP请求后，服务器根据请求，会给我们发送数据，发送完后，不会记录信息。(使用 cookie 机制可以保持 session，解决无状态的问题)
http1.1的特点
a、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求 。
b、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应 。
c、断点续传，就是可以将一个大数据，分段传输，客户端可以慢慢显示。
http2.0的特点
a、HTTP/2采用二进制格式而非文本格式
b、HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个HTTP连接就可以实现多个请求响应
c、使用报头压缩，HTTP/2降低了开销
d、HTTP/2让服务器可以将响应主动“推送”到客户端缓存中
1.3 HTTP请求响应模型
HTTP由请求和响应构成，是一个标准的客户端服务器模型（B/S）。HTTP协议永远都是客户端发起请求，服务器回送响应。见下图:
HTTP是一个无状态的协议。无状态是指客户机（Web浏览器）和服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息.HTTP遵循请求(Request)/应答(Response)模型。客户机（浏览器）向服务器发送请求，服务器处理请求并返回适当的应答。所有HTTP连接都被构造成一套请求和应答。
2 工作原理与过程
2.1 工作原理
在http传输的过程中，被称为客户端的请求者向服务器请求一个文件。
最基本的过程是:
1 客户端连接一个主机；
2 服务器接收连接,
3 客户端请求一个文件,
4 服务器发送一个应答.
一次HTTP操作称为一个事务，其工作整个过程如下：
1 ) 、地址解析，
如用客户端浏览器请求这个页面：http://localhost.com:8080/index.htm
从中分解出协议名、主机名、端口、对象路径等部分，对于我们的这个地址，解析得到的结果如下：
协议名：http
主机名：localhost.com
端口：8080
对象路径：/index.htm
在这一步，需要域名系统DNS解析域名localhost.com,得主机的IP地址。
2）封装HTTP请求数据包
把以上部分结合本机自己的信息，封装成一个HTTP请求数据包
3）封装成TCP包，建立TCP连接（TCP的三次握手）
在HTTP工作开始之前，客户机（Web浏览器）首先要通过网络与服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。这里是8080端口
4）客户机发送请求命令
建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URI）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可内容。
这里顺便说明个人理解
URI： 统一资源标识符，用来唯一的标识一个资源，是一种语义上的抽象概念。
URL ：统一资源定位符，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何访问到这个资源URI是以一种抽象的，高层次概念定义统一资源标识，标记了一个网络资源，而URL则是具体的资源标识的方式。
简单比喻 - URI唯一标识一个人（例如身份证）， URL定义了如何访问到这个人（例如家庭地址）
5）服务器响应
服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
实体消息是服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据
6）服务器关闭TCP连接
一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码
Connection:keep-alive
TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽
2.2 用户访问网站的过程？
1. 利用DNS协议进行域名解析
第一步：客户端用户从浏览器里输入www.baidu.com网站地址，回车后，系统首先会查找系统本地的DNS缓存及hosts文件信息，查找是否存在www.baidu.com域名对应的IP解析记录，如果有就直接获取IP地址，然后去访问这个IP地址对应域名www.baidu.com的服务器，一般第一次请求时，DNS缓存是没有解析记录的，而hosts多在内部临时测试时使用。
第二步：如果客户端本地DNS缓存及hosts文件没有www.baidu.com域名对应的解析记录，那么，系统会把浏览器的解析请求发送给客户端本地设置的DNS服务器地址（通常称此DNS为LDNS或首选DNS服务器，即Local DNS）解析，如果LDNS服务器的本地缓存有对应的解析记录就会直接返回IP地址给客户端，如果没有，则LDNS会负责继续请求其他的DNS服务器。
第三步：LDNS会从DNS系统的根域（.）开始请求www.baidu.com域名的解析，针对各个层级的DNS服务器系统进行一系列的查找，最终会查找到baidu.com域名对应的授权DNS服务器，而这个授权DNS服务器正是企业购买域名时用于管理域名解析的服务器，这个授权服务器会有www.baidu.com对应的IP解析记录，如果此时没有，就表示企业的域名管理人员没有为www.baidu.com域名做解析设置，即网站还没架设好
第四步：baidu.com域名的授权DNS服务器会把www.baidu.com对应的最终IP解析记录发给LDNS。
第五步：LDNS把收到的来自授权DNS服务器www.baidu.com对应的IP解析记录（A记录）缓存到本地，再发给客户端，以便下一次更快的返回相同解析请求的记录，这些缓存记录在指定的时间（DNS TTL值控制）内不会过期。
第六步：客户端浏览器获取到了www.etiantian.org的对应IP地址的解析记录，会先缓存到本地，接下来，浏览器会请求获得的IP地址对应的网站服务器
2. 建立tcp协议三次握手过程
3. 客户端发出访问网站相应页面请求（发出http协议请求报文）
4. 系统架构部署情况
5. 服务端发出响应访问页面的请求信息（发出http协议响应报文）
6. 断开tcp协议四次挥手过程
提示：
上述仅仅是客户端用户第一次访问网站的基本过程，连续访问后，系统本地和LDNS层级都会有缓存记录，再访问时流程就会有些变化，会直接取本地缓存记录，这样访问过程就很快了。在上述整个访问流程里，包含了DNS的解析流程以及HTTP协议的通信原理等重要的技术点。
2.3 HTTP协议栈中各层数据流
首先我们看看客户端请求的时候，数据在各层协议的数据组织如下图：
而服务器解析客户机请求就是反向操作的过程，如下图：
客户机发起一次请求的时候：
客户机会将请求封装成http数据包-->封装成Tcp数据包-->封装成Ip数据包--->封装成数据帧--->硬件将帧数据转换成bit流（二进制数据）-->最后通过物理硬件（网卡芯片）发送到指定地点。
服务器硬件首先收到bit流....... 然后转换成ip数据包。于是通过ip协议解析Ip数据包，然后又发现里面是tcp数据包，就通过tcp协议解析Tcp数据包，接着发现是http数据包通过http协议再解析http数据包得到数据。
3 请求
请求，由客户端向服务端发出，可以分为4部分内容：请求方法（Request Method）、请求的网址（Request URL）、请求头（Request Headers）、请求体（Request Body）。
| 报文格式 | 报文信息 |
| 请求行 | ①. 请求的方法（get方法没有请求主体内容 post方法会有请求主体信息） |
| ②. 请求的数据信息（默认请求index.html首页文件） | |
| ③. 请求http协议版本 tcp协议分为长连接（http1.1）和短连接（http1.0） | |
| 请求头部 | 客户端有关信息说明 |
| 空行 | 空白内容 |
| 请求报文主体 | get方法没有请求主体内容 post方法会有请求主体信息 |
(1) 请求方法
常见的请求方法有两种：GET和POST。
在浏览器中直接输入URL并回车，这便发起了一个GET请求，请求的参数会直接包含到URL里。例如，在百度中搜索Python，这就是一个GET请求，链接为https://www.baidu.com/s?wd=Python，其中URL中包含了请求的参数信息，这里参数wd表示要搜寻的关键字。POST请求大多在表单提交时发起。比如，对于一个登录表单，输入用户名和密码后，点击“登录”按钮，这通常会发起一个POST请求，其数据通常以表单的形式传输，而不会体现在URL中。
GET和POST请求方法有如下区别。
- GET请求中的参数包含在URL里面，数据可以在URL中看到，而POST请求的URL不会包含这些数据，数据都是通过表单形式传输的，会包含在请求体中。
- GET请求提交的数据最多只有1024字节，而POST方式没有限制。
一般来说，登录时，需要提交用户名和密码，其中包含了敏感信息，使用GET方式请求的话，密码就会暴露在URL里面，造成密码泄露，所以这里最好以POST方式发送。上传文件时，由于文件内容比较大，也会选用POST方式。
1、get重点在从服务器上获取资源，post重点在向服务器发送数据；
2、get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用”?”连接，多个请求数据间用”&”连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的；
post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；
3、Get传输的数据量小，因为受URL长度限制，但效率较高；
Post可以传输大量数据，所以上传文件时只能用Post方式；
4、get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；
post较get安全性较高；
我们平常遇到的绝大部分请求都是GET或POST请求，另外还有一些请求方法，如GET、HEAD、POST、PUT、DELETE、OPTIONS、CONNECT、TRACE等，我们简单将其总结为表2-1。
表2-1 其他请求方法
| 方法 | 描述 |
|---|---|
| GET | 请求页面，并返回页面内容 |
| HEAD | 类似于GET请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| POST | 大多用于提交表单或上传文件，数据包含在请求体中 |
| PUT | 从客户端向服务器传送的数据取代指定文档中的内容 |
| DELETE | 请求服务器删除指定的页面 |
| CONNECT | 把服务器当作跳板，让服务器代替客户端访问其他网页 |
| OPTIONS | 允许客户端查看服务器的性能 |
| TRACE | 回显服务器收到的请求，主要用于测试或诊断 |
本表参考：http://www.runoob.com/http/http-methods.html。
(2) 请求的网址
请求的网址，即统一资源定位符URL，它可以唯一确定我们想请求的资源。
(3) 请求头
请求头，用来说明服务器要使用的附加信息，比较重要的信息有Cookie、Referer、User-Agent等。下面简要说明一些常用的头信息。
- Accept：请求报头域，用于指定客户端可接受哪些类型的信息。
- Accept-Language：指定客户端可接受的语言类型。
- Accept-Encoding：指定客户端可接受的内容编码。
- Host：用于指定请求资源的主机IP和端口号，其内容为请求URL的原始服务器或网关的位置。从HTTP 1.1版本开始，请求必须包含此内容。
- Cookie：也常用复数形式 Cookies，这是网站为了辨别用户进行会话跟踪而存储在用户本地的数据。它的主要功能是维持当前访问会话。例如，我们输入用户名和密码成功登录某个网站后，服务器会用会话保存登录状态信息，后面我们每次刷新或请求该站点的其他页面时，会发现都是登录状态，这就是Cookies的功劳。Cookies里有信息标识了我们所对应的服务器的会话，每次浏览器在请求该站点的页面时，都会在请求头中加上Cookies并将其发送给服务器，服务器通过Cookies识别出是我们自己，并且查出当前状态是登录状态，所以返回结果就是登录之后才能看到的网页内容。
- Referer：此内容用来标识这个请求是从哪个页面发过来的，服务器可以拿到这一信息并做相应的处理，如作来源统计、防盗链处理等。
- User-Agent：简称UA，它是一个特殊的字符串头，可以使服务器识别客户使用的操作系统及版本、浏览器及版本等信息。在做爬虫时加上此信息，可以伪装为浏览器；如果不加，很可能会被识别出为爬虫。
- Content-Type：也叫互联网媒体类型（Internet Media Type）或者MIME类型，在HTTP协议消息头中，它用来表示具体请求中的媒体类型信息。例如，text/html代表HTML格式，image/gif代表GIF图片，application/json代表JSON类型，更多对应关系可以查看此对照表：http://tool.oschina.net/commons。
因此，请求头是请求的重要组成部分，在写爬虫时，大部分情况下都需要设定请求头。
(4) 请求体
请求体一般承载的内容是POST请求中的表单数据，而对于GET请求，请求体则为空。
例如，这里我登录GitHub时捕获到的请求和响应如图2-7所示。
详细信息
登录之前，我们填写了用户名和密码信息，提交时这些内容就会以表单数据的形式提交给服务器，此时需要注意Request Headers中指定Content-Type为application/x-www-form-urlencoded。只有设置Content-Type为application/x-www-form-urlencoded，才会以表单数据的形式提交。另外，我们也可以将Content-Type设置为application/json来提交JSON数据，或者设置为multipart/form-data来上传文件。
表2-2 Content-Type和POST提交数据方式的关系
| Content-Type | 提交数据的方式 |
|---|---|
| application/x-www-form-urlencoded | 表单数据 |
| multipart/form-data | 表单文件上传 |
| application/json | 序列化JSON数据 |
| text/xml | XML数据 |
在爬虫中，如果要构造POST请求，需要使用正确的Content-Type，并了解各种请求库的各个参数设置时使用的是哪种Content-Type，不然可能会导致POST提交后无法正常响应。
4 响应
响应，由服务端返回给客户端，可以分为三部分：响应状态码（Response Status Code）、响应头（Response Headers）和响应体（Response Body）。
查看请求报文与响应报文详细结构信息方法：（2种方法）
1. curl -v www.baidu.com --- 利用curl命令进行网站访问
-v --- 详细显示请求报文结构和响应报文结构信息
2. wget --debug www.baidu.com
(1) 响应状态码
响应状态码表示服务器的响应状态，如200代表服务器正常响应，404代表页面未找到，500代表服务器内部发生错误。在爬虫中，我们可以根据状态码来判断服务器响应状态，如状态码为200，则证明成功返回数据，再进行进一步的处理，否则直接忽略。表2-3列出了常见的错误代码及错误原因。
表2-3 常见的错误代码及错误原因
| 状态码 | 说明 | 详情 |
|---|---|---|
| 100 | 继续 | 请求者应当继续提出请求。服务器已收到请求的一部分，正在等待其余部分 |
| 101 | 切换协议 | 请求者已要求服务器切换协议，服务器已确认并准备切换 |
| 200 | 成功 | 服务器已成功处理了请求 |
| 201 | 已创建 | 请求成功并且服务器创建了新的资源 |
| 202 | 已接受 | 服务器已接受请求，但尚未处理 |
| 203 | 非授权信息 | 服务器已成功处理了请求，但返回的信息可能来自另一个源 |
| 204 | 无内容 | 服务器成功处理了请求，但没有返回任何内容 |
| 205 | 重置内容 | 服务器成功处理了请求，内容被重置 |
| 206 | 部分内容 | 服务器成功处理了部分请求 |
| 300 | 多种选择 | 针对请求，服务器可执行多种操作 |
| 301 | 永久移动 | 请求的网页已永久移动到新位置，即永久重定向 |
| 302 | 临时移动 | 请求的网页暂时跳转到其他页面，即暂时重定向 |
| 303 | 查看其他位置 | 如果原来的请求是POST，重定向目标文档应该通过GET提取 |
| 304 | 未修改 | 此次请求返回的网页未修改，继续使用上次的资源 |
| 305 | 使用代理 | 请求者应该使用代理访问该网页 |
| 307 | 临时重定向 | 请求的资源临时从其他位置响应 |
| 400 | 错误请求 | 服务器无法解析该请求 |
| 401 | 未授权 | 请求没有进行身份验证或验证未通过 |
| 403 | 禁止访问 | 服务器拒绝此请求 |
| 404 | 未找到 | 服务器找不到请求的网页 |
| 405 | 方法禁用 | 服务器禁用了请求中指定的方法 |
| 406 | 不接受 | 无法使用请求的内容响应请求的网页 |
| 407 | 需要代理授权 | 请求者需要使用代理授权 |
| 408 | 请求超时 | 服务器请求超时 |
| 409 | 冲突 | 服务器在完成请求时发生冲突 |
| 410 | 已删除 | 请求的资源已永久删除 |
| 411 | 需要有效长度 | 服务器不接受不含有效内容长度标头字段的请求 |
| 412 | 未满足前提条件 | 服务器未满足请求者在请求中设置的其中一个前提条件 |
| 413 | 请求实体过大 | 请求实体过大，超出服务器的处理能力 |
| 414 | 请求URI过长 | 请求网址过长，服务器无法处理 |
| 415 | 不支持类型 | 请求格式不被请求页面支持 |
| 416 | 请求范围不符 | 页面无法提供请求的范围 |
| 417 | 未满足期望值 | 服务器未满足期望请求标头字段的要求 |
| 500 | 服务器内部错误 | 服务器遇到错误，无法完成请求 |
| 501 | 未实现 | 服务器不具备完成请求的功能 |
| 502 | 错误网关 | 服务器作为网关或代理，从上游服务器收到无效响应 |
| 503 | 服务不可用 | 服务器目前无法使用 |
| 504 | 网关超时 | 服务器作为网关或代理，但是没有及时从上游服务器收到请求 |
| 505 | HTTP版本不支持 | 服务器不支持请求中所用的HTTP协议版本 |
(2) 响应头
响应头包含了服务器对请求的应答信息，如Content-Type、Server、Set-Cookie等。下面简要说明一些常用的头信息。
- Date：标识响应产生的时间。
- Last-Modified：指定资源的最后修改时间。
- Content-Encoding：指定响应内容的编码。
- Server：包含服务器的信息，比如名称、版本号等。
- Content-Type：文档类型，指定返回的数据类型是什么，如text/html代表返回HTML文档，application/x-javascript则代表返回JavaScript文件，image/jpeg则代表返回图片。
- Set-Cookie：设置Cookies。响应头中的Set-Cookie告诉浏览器需要将此内容放在Cookies中，下次请求携带Cookies请求。
- Expires：指定响应的过期时间，可以使代理服务器或浏览器将加载的内容更新到缓存中。如果再次访问时，就可以直接从缓存中加载，降低服务器负载，缩短加载时间。
(3) 响应体
最重要的当属响应体的内容了。响应的正文数据都在响应体中，比如请求网页时，它的响应体就是网页的HTML代码；请求一张图片时，它的响应体就是图片的二进制数据。我们做爬虫请求网页后，要解析的内容就是响应体，如图2-8所示。
图2-8 响应体内容
在浏览器开发者工具中点击Preview，就可以看到网页的源代码，也就是响应体的内容，它是解析的目标。
5 HTTP/1.1与HTTP/1.0的区别
HTTP协议的初始版本中， 每进行一次 HTTP通信就要断开一次TCP连接，因为都是些容量很小的文本传输， 所以即使这样也没有多大问题。 可随着HTTP的普及， 文档中包含大量图片的情况多了起来。为解决上述TCP连接的问题， HTTP/1.1和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections， 也称为 HTTPkeep-alive 或HTTP connection reuse）的方法。 持久连接的特点是， 只要任意一端没有明确提出断开连接， 则保持TCP连接状态。持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销， 减轻了服务器端的负载。 另外， 减少开销的那部分时间， 使HTTP请求和响应能够更早地结束， 这样 Web 页面的显示速度也就相应提高了。
传统无连接：
现在持久连接：
持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。 管线化技术出现后， 不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求， 而不需要一个接一个地等待响应了。
HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：
-
缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
-
带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
-
错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
-
Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
-
长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
6 HTTP各种长度限制
1. URL长度限制
在Http1.1协议中并没有提出针对URL的长度进行限制，RFC协议里面是这样描述的，HTTP协议并不对URI的长度做任何的限制，服务器端必须能够处理任何它们所提供服务多能接受的URI，并且能够处理无限长度的URI,如果服务器不能处理过长的URI,那么应该返回414状态码。
虽然Http协议规定了，但是Web服务器和浏览器对URI都有自己的长度限制。
服务器的限制:我接触的最多的服务器类型就是Nginx和Tomcat,对于url的长度限制，它们都是通过控制http请求头的长度来进行限制的，nginx的配置参数为large_client_header_buffers，tomcat的请求配置参数为maxHttpHeaderSize,都是可以自己去进行设置。
浏览器的限制:每种浏览器也会对url的长度有所限制，下面是几种常见浏览器的url长度限制:(单位:字符)
IE : 2803
Firefox:65536
Chrome:8182
Safari:80000
Opera:190000
对于get请求，在url的长度限制范围之内，请求的参数个数没有限制。
2. Post数据的长度限制
Post数据的长度限制与url长度限制类似，也是在Http协议中没有规定长度限制,长度限制可以在服务器端配置最大http请求头长度的方式来实现。
3. Cookie的长度限制
Cookie的长度限制分这么几个方面来总结。
(1) 浏览器所允许的每个域下的最大cookie数目,没有去自己测试，从网上找到的资料大概是这么个情况
IE :原先为20个，后来升级为50个
Firefox: 50个
Opera:30个
Chrome:180个
Safari:无限制
当Cookie数超过限制数时浏览器的行为：IE和Opera会采用LRU算法将老的不常使用的Cookie清除掉，Firefox的行为是随机踢出某些Cookie的值。当然无论怎样的策略，还是尽量不要让Cookie数目超过浏览器所允许的范围。
(2) 浏览器所允许的每个Cookie的最大长度
Firefox和Safari:4079字节
Opera:4096字节
IE:4095字节
(3) 服务器中Http请求头长度的限制。Cookie会被附在每次http请求头中传递给服务器，因此还会受到服务器请求头长度的影响。
4. Html5 LocalStorage
Html5提供了本地存储机制来供Web应用在客户端存储数据，尽管这个并不属于Http协议的一部分，但是随着Html5的流行，我们可能需要越来越多使用LocalStorage,甚至当它普及的时候跟它打交道就会同今天我们跟Cookie打交道一样多。
对于LocalStorage的长度限制，同Cookie的限制类似，也是浏览器针对域来限制,只不过cookie限制的是个数，LocalStorage限制的是长度:
Firefox\Chrome\Opera都是允许每个域的最大长度为5MB
但是这次IE比较大方，允许的最大长度是10MB
6677
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
