计算机网络 - HTTP协议详解

HTTP 协议详解

HTTP 协议简介

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。

HTTP的发展是由蒂姆·伯纳斯-李于1989年在欧洲核子研究组织（CERN）所发起。HTTP的标准制定由万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（Internet Engineering Task Force，IETF）进行协调，最终发布了一系列的RFC，其中最著名的是1999年6月公布的 RFC 2616，定义了HTTP协议中现今广泛使用的一个版本——HTTP 1.1。

2014年12月，互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小组将HTTP/2标准提议递交至IESG进行讨论，于2015年2月17日被批准。 HTTP/2标准于2015年5月以RFC 7540正式发表，取代HTTP 1.1成为HTTP的实现标准。

HTTP 协议概述

HTTP是一个客户端终端（用户）和服务器端（网站）请求和应答的标准（TCP）。通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口（默认端口为80）。我们称这个客户端为用户代理程序（user agent）。应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。

尽管TCP/IP协议是互联网上最流行的应用，HTTP协议中，并没有规定必须使用它或它支持的层。事实上，HTTP可以在任何互联网协议上，或其他网络上实现。HTTP假定其下层协议提供可靠的传输。因此，任何能够提供这种保证的协议都可以被其使用。因此也就是其在TCP/IP协议族使用TCP作为其传输层。

通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。

HTTP 工作原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求 / 响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

以下是 HTTP 请求/响应的步骤：

1. 客户端连接到Web服务器。一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。
2. 发送HTTP请求。通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
3. 服务器接受请求并返回HTTP响应。Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4. 释放连接TCP连接。若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5. 客户端浏览器解析HTML内容。客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：

1. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2. 解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
3. 浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4. 服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器；
5. 释放 TCP连接;
6. 浏览器将该 html 文本并显示内容;

http协议是基于TCP/IP协议之上的应用层协议。

基于 请求-响应 的模式

HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并 返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有 接收到请求之前不会发送响应

无状态保存

HTTP是一种不保存状态,即无状态(stateless)协议。HTTP协议 自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个 级别,协议对于发送过的请求或响应都不做持久化处理。

使用HTTP协议,每当有新的请求发送时,就会有对应的新响应产 生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把HTTP协议设计成 如此简单的。可是,随着Web的不断发展,因无状态而导致业务处理变得棘手 的情况增多了。比如,用户登录到一家购物网站,即使他跳转到该站的 其他页面后,也需要能继续保持登录状态。针对这个实例,网站为了能 够掌握是谁送出的请求,需要保存用户的状态。HTTP/1.1虽然是无状态协议,但为了实现期望的保持状态功能, 于是引入了Cookie技术。有了Cookie再用HTTP协议通信,就可以管 理状态了。有关Cookie的详细内容稍后讲解。

无连接

无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间，并且可以提高并发性能，不能和每个用户建立长久的连接，请求一次相应一次，服务端和客户端就中断了。但是无连接有两种方式，早期的http协议是一个请求一个响应之后，直接就断开了，但是现在的http协议1.1版本不是直接就断开了，而是等几秒钟，这几秒钟是等什么呢，等着用户有后续的操作，如果用户在这几秒钟之内有新的请求，那么还是通过之前的连接通道来收发消息，如果过了这几秒钟用户没有发送新的请求，那么就会断开连接，这样可以提高效率，减少短时间内建立连接的次数，因为建立连接也是耗时的，默认的好像是3秒中现在，但是这个时间是可以通过咱们后端的代码来调整的，自己网站根据自己网站用户的行为来分析统计出一个最优的等待时间

HTTP 请求方法

HTTP/1.1协议中共定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：

GET

向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据，而不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。

HEAD

与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。

POST

向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。

PUT

向指定资源位置上传其最新内容。

DELETE

请求服务器删除Request-URI所标识的资源。

TRACE

回显服务器收到的请求，主要用于测试或诊断。

OPTIONS

这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。

注意事项：

1. 方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed），当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。

2. HTTP服务器至少应该实现GET和POST方法，其他方法都是可选的。当然，所有的方法支持的实现都应当匹配下述的方法各自的语义定义。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。例如PATCH（由 RFC 5789 指定的方法）用于将局部修改应用到资源。

请求方式: get与post请求

• GET提交的数据会放在URL之后，也就是请求行里面，以?分割URL和传输数据，参数之间以&相连，如EditBook?name=test1&id=123456.（请求头里面那个content-type做的这种参数形式，后面讲） POST方法是把提交的数据放在HTTP包的请求体中.
• GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制。
• GET与POST请求在服务端获取请求数据方式不同，就是我们自己在服务端取请求数据的时候的方式不同了，这句废话昂。

HTTP 状态码

所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。
状态代码的第一个数字代表当前响应的类型：

• 1xx消息——请求已被服务器接收，继续处理
• 2xx成功——请求已成功被服务器接收、理解、并接受
• 3xx重定向——需要后续操作才能完成这一请求
• 4xx请求错误——请求含有词法错误或者无法被执行
• 5xx服务器错误——服务器在处理某个正确请求时发生错误

虽然 RFC 2616 中已经推荐了描述状态的短语，例如"200 OK"，“404 Not Found”，但是WEB开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。

URL

超文本传输协议（HTTP）的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中：

• 传送协议。
• 层级URL标记符号(为[//],固定不变)
• 访问资源需要的凭证信息（可省略）
• 服务器。（通常为域名，有时为IP地址）
• 端口号。（以数字方式表示，若为HTTP的默认值“:80”可省略）
• 路径。（以“/”字符区别路径中的每一个目录名称）
• 查询。（GET模式的窗体参数，以“?”字符为起点，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题）
• 片段。以“#”字符为起点

以http://www.luffycity.com:80/news/index.html?id=250&page=1 为例, 其中：

• http，是协议；
• www.luffycity.com，是服务器；
• 80，是服务器上的默认网络端口号，默认不显示；
• /news/index.html，是路径（URI：直接定位到对应的资源）；
• ?id=250&page=1，是查询。
• 大多数网页浏览器不要求用户输入网页中“http://”的部分，因为绝大多数网页内容是超文本传输协议文件。同样，“80”是超文本传输协议文件的常用端口号，因此一般也不必写明。一般来说用户只要键入统一资源定位符的一部分（www.luffycity.com:80/news/index.html?id=250&page=1）就可以了。

由于超文本传输协议允许服务器将浏览器重定向到另一个网页地址，因此许多服务器允许用户省略网页地址中的部分，比如 www。从技术上来说这样省略后的网页地址实际上是一个不同的网页地址，浏览器本身无法决定这个新地址是否通，服务器必须完成重定向的任务。

HTTP请求格式(请求协议)

URL包含：/index/index2?a=1&b=2；路径和参数都在这里。

请求头里面的内容举个例子：这个length表示请求体里面的数据长度，其他的请求头里面的这些键值对，陆续我们会讲的，大概知道一下就可以了，其中有一个user-agent，算是需要你记住的吧，就是告诉你的服务端，我是用什么给你发送的请求。

以京东为例，看一下user-agent

看一个爬虫的例子，爬京东的时候没问题，但是爬抽屉的时候必须带着user-agent，因为抽屉对user-agent做了判断，来判断你是不是一个正常的请求，算是反扒机制的一种。

打开我们保存的demo.html文件，然后通过浏览器打开看看就能看到页面效果。
写上面这些内容的意思是让你知道有这么个请求头的存在，有些是有意义的，请求头我们还可以自己定义，就在requests模块里面那个headers={}，这个字典里面加就行。

HTTP响应格式（响应协议）

http协议各版本差异

http协议目前有4个版本，其中1.0、1.1版本在互联网上被广泛使用，2.0版本目前应用很少，是下一代的http协议。

• http/0.9版本：1991年,原型版本，功能简陋，只有一个命令GET,服务器只能回应HTML格式字符串，该版本已过时。
• http/1.0版本: 1996年5月,支持cache, MIME, method等。
• http/1.1版本: 1997年1月,默认建立持久连接，并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。
• http/2 版本: 2015年5月作为互联网标准正式发布,头部信息和数据体都是二进制，引入头信息压缩机制等。

1.x版本说明

http1.0版本:

• 任何格式的内容都可以发送，这使得互联网不仅可以传输文字，还能传输图像、视频、二进制等文件
• 除了GET方法，还引入了POST方法和HEAD方法
• http请求和回应的格式改变，除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据
• 头信息是 ASCII 码，后面数据可为任何格式。服务器回应时会告诉客户端，数据是什么格式，即Content-Type字段的作用。这些数据类型总称为MIME即多用途互联网邮件扩展，每个值包括一级类型和二级类型，预定义的类型，也可自定义类型, 常见Content-Type值：text/xml image/jpeg audio/mp3
• 每个TCP连接只能发送一个请求，发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接

http1.1版本:

• http1.1是目前最为主流的http协议版本，从1997年发布至今，仍是主流的http协议版本。
• 引入了持久连接（ persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。
• 引入了管道机制（ pipelining），即在同一个TCP连接里，客户端可以同时发送多个
  请求(大多数浏览器允许同时建立6个持久连接引入了管道机制)，进一步改进了HTTP协议的效率。
• 新增方法：PUT、 PATCH、 OPTIONS、 DELETE。
• http协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度。

http1.x版本问题：

• http1.x在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，无法保证数据的安全性
• 1.1版本允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应，可能会造成Head-of-line blocking的问题。
• http1.x支持了keep-alive，来弥补多次创建连接产生的延迟，但是keepalive使用多了同样会给服务端带来大量的性能压力，并且对于单个文件被不断请求的服务(例如图片存放网站)， keep-alive可能会极大的影响性能，因为它在文件被请求之后还保持了不必要的连接很长时间。

其实http1.1还是有些问题没有解决的

1. 传输数据是明文
2. header头部数据太长
3. 每次传输还是要重新连接
4. server不能主动push

这样就推动了http2.0的出现

http/2协议

http/2发布于2015年，目前应用还比较少，该版本主要有如下特点：

• http/2是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。
• 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了队头堵塞的问题,此双向的实时通信称为多工（ Multiplexing）。
• HTTP/2 允许服务器未经请求，主动向客户端发送资源，即服务器推送。（WebSocke）
• 引入头信息压缩机制（header compression）,头信息使用gzip或compress压缩后再发送；客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，不发送同样字段，只发送索引号，提高速度

http1.0和http1.1的区别

1. 长连接
   HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，弥补了HTTP1.0每次请求都要创建连接的缺点.

http中的长连接keep-alive和websocket的长连接不太一样, websock的长连接可以保持几个小时不断线, 而http的长连接也就几秒钟而已, 相对于http1.0来说是长连接, 使用一次tcp的握手挥手, 完成多个request-response，也就是说, 在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。只是这一次的多个request用的是一个tcp连接.

http1.0短连接的操作步骤是：
建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接
http1.1开启了长连接的操作步骤是：
建立连接——数据传输…（保持连接）…数据传输——关闭连接

TCP的保活功能主要为服务器应用提供。如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。如果一个给定的连接在10分钟(服务器设定的)内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态：

• 客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位
• 客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。
• 客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
• 客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。

2. 缓存处理
   在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略

3. 带宽优化和网络连接的使用
   HTTP1.0中，存在一些浪费带宽的现象，例如：客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），方便了开发者自由的选择以便于充分利用带宽和连接

4. 错误通知的管理
   在HTTP1.1中新增24个状态响应码，如
   409（Conflict）表示请求的资源与资源当前状态冲突；.
   410（Gone）表示服务器上的某个资源被永久性的删除

5. Host头处理
   在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）

HTTP 常见请求头属性

以百度为例

ET /favicon.ico HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36
Accept: image/webp,image/apng,image/,/*;q=0.8
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: image
Referer: https://www.baidu.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: en,zh-CN;q=0.9,zh;q=0.8
Cookie: BIDUPSID=A25EA168B55DD7B4FB0A6342CA748B8C; PSTM=1576809266; BD_UPN=12314753; BAIDUID=A25EA168B55DD7B457BA8613C76F2D5C:SL=0:NR=10:FG=1; sugstore=0; sug=3; ORIGIN=0; bdime=0; BDUSS=k0ODlSS09zUVFTenR5ZWVnd2ZrNE5wV3RGVTdJcFR1aWN3b3Y4Uzh5Y0lQTWRlSVFBQUFBJCQAAAAAAAAAAAEAAACuVu1KQ0pBbWF0ZXVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAivn14Ir59eSj; COOKIE_SESSION=11537_0_9_6_7_50_1_1_9_7_99_0_0_0_30_0_1595386282_0_1595397789%7C9%230_0_1595397789%7C1; BDUSS_BFESS=k0ODlSS09zUVFTenR5ZWVnd2ZrNE5wV3RGVTdJcFR1aWN3b3Y4Uzh5Y0lQTWRlSVFBQUFBJCQAAAAAAAAAAAEAAACuVu1KQ0pBbWF0ZXVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAivn14Ir59eSj; BD_HOME=1; delPer=0; BD_CK_SAM=1; PSINO=5; BDORZ=B490B5EBF6F3CD402E515D22BCDA1598; BDRCVFR[feWj1Vr5u3D]=I67x6TjHwwYf0; H_PS_645EC=6edcKRnz3eq3%2FGZkOSf6G1deQokMgt%2F%2BOIZog1%2Baj7nECxrvOXSSE0XyxwuA%2ByGVqan%2B; H_PS_PSSID=32288_1450_32359_32327_32045_31640_22157

• HOST
  请求头指明了请求将要发送到的服务器主机名和端口号。
  如果没有包含端口号，会自动使用被请求服务的默认端口（比如HTTPS URL使用443端口，HTTP URL使用80端口）。

• Connection
  客户端或服务端用来告诉对方当前tcp连接的状态
  Connection:keep-alive 网络连接就是持久的，不会关闭，使得对同一个服务器的请求可以继续在该连接上完成。HTTP/1.1的请求默认
  Connection:close 在响应结束后关闭连接，这是HTTP/1.0请求的默认值

• prama
  Pragma 是一个在 HTTP/1.0 中规定的通用首部，这个首部的效果依赖于不同的实现，所以在“请求-响应”链中可能会有不同的效果。它用来向后兼容只支持 HTTP/1.0 协议的缓存服务器，那时候 HTTP/1.1 协议中的 Cache-Control 还没有出来。

• Cache-Control
  对缓存进行控制，如一个请求希望响应返回的内容在客户端要被缓存一年，或不希望被缓存就可以通过这个报文头达到目的

Cache-Control: no-cache 在发布缓存副本之前，强制要求缓存把请求提交给原始服务器进行验证(协商缓存验证)。

• User-Agent
  服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送

• Accept
  请求报文可通过一个“Accept”报文头属性告诉服务端，客户端接受什么类型的响应。
  如下报文头相当于告诉服务端，客户端能够接受的响应类型仅为纯文本数据

Accept:text/plain

通配符 * 代表任意类型。如下代表浏览器可以处理所有类型

Accept: /

Accept属性的值可以为一个或多个MIME类型的值（描述消息内容类型的因特网标准， 消息能包含文本、图像、音频、视频以及其他应用程序专用的数据）

• Referer（可以用来防盗链）
  表示这个请求是从哪个URL过来的，假如你通过百度搜索出一个商家的广告页面，你对这个广告页面感兴趣，鼠标一点发送一个请求报文到商家的网站，这个请求报文的Referer报文头属性值就是 https://www.baidu.com/

• Accept-Encoding
  浏览器客户端用来告诉服务器能接受什么编码格式，包括字符编码、压缩方式等

例如：Accept-Encoding:gzip, deflate

• Accept-Language
  浏览器客户端用来告诉服务器能接受什么语言。

例如：Accept-Language:zh-CN,zh;q=0.9

• cookie
  客户端的Cookie就是通过这个报文头属性传给服务端的，如下所示：

Cookie: $Version=1; jsessionid=5F4771183629C9834F8382E23

jsessionid就是用来判断当前用户对应于哪个session。换句话说服务器识别session的方法是通过jsessionid来告诉服务器该客户端的session在内存的什么地方。（当然也可以通过重写URL的方式将会话ID附带在每个URL的后面，在禁用cookie的时候可以用这个方法）。

Jsessionid只是tomcat的对sessionid的叫法，其实就是sessionid；在其它的容器也许就不叫jsessionid了。

• Authorization
  当客户端访问受口令保护时，服务器端会发送401状态码和www-authenticate 响应头，要求客户端使用Authorization来应答

会话跟踪技术

**会话（Session）**跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。

cookie、session、sessionid 与jsessionid

我们都知道银行，银行的收柜台每天要接待客户存款/取款业务，可以有几种方案：

凭借柜台职员的记忆，由收柜台职员来为每位顾客办理存款/取款业务，单凭职员的记忆力，要记到每位顾客的相貌，并迅速这个顾客当前的存款以及存取的次数，每次存取的金额是多少。-----------这种方式表示协议本身支持状态。

使用存折的方式，然后柜台职员就把每个顾客的存款/取款的信息保存在这张折子，然后交给顾客保管，当顾客来存款/取款时，只要拿出存折，职员查看存折就对当前这位顾客的存款/取款信息一目了然。当然，你马上会想到，顾客修改这个信息怎么办？我们也有措施对每次存款/取款记录后面盖章。无盖章的就是假冒信息。但如果顾客是真的要伪造，当然印章也是可以伪造的。-------------这种方式就是在客户端端保持状态。

使用银行卡的方式，发给每位银行用户一张银行卡，银行卡上有一个唯一的卡号，没有其它任何信息，当顾客来存款/取款时，拿出银行卡，银行把卡号输入的电脑，很快就显示当前用户的存/取款记录。这种方式的安全性就会有很大的提高。用户想要手脚只有攻破银行的服务器来修改自己的存/取款信息，这样做难度会很大。---------这种方式就是服务器端保持状态。

Cookie 与session的产生过程

我们都知道HTTP协议本身是无状态的，客户只需要简单的向服务器来发送请求下载某些文件，客户端向服务器端发送的每次请求都是独立的。对于当前的web应用，HTTP的“无状态”，导致许多应用都不得不花费大量的精力来记录用户的操作步骤。就像我们上面介绍的第一种情况，银行职员要花费大量的精力来记忆每一位用户的存/取款记录。

程序员很快发现，如果能够提供一些按需生成的动太信息，会使web的交互能力大大增强。程序员一方面在HTML中添加表单、脚本、DOM等客户端行为，来增加web应用与客户端的交互性。另一方面在服务器端测出现了CGI规范以响应客户端的动态请求，作为传输载体的HTTP协议添加了文件上载、cookie 等特性。那cookie的原理与我们上面介绍的使用存折记录用户应为的方式是一样一样的。

通过前面的例子我们已经发现，通过cookie的方式存储信息，可能会存在一定的安全性，因为所有的信息都是写在客户端的，客户可能会对这些信息进行修改或清除。然后就又出现session的方式用于保存用户行为，这种方式的原理与前面介绍银行卡的方式是一样的。

具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

cookie与session的机制与原理

cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。

cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。

session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识------------称为session id，如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。

经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。

Jsessionid：
Jsessionid只是tomcat的对sessionid的叫法，其实就是sessionid；在其它的容器也许就不叫jsessionid了。

转载于
https://www.cnblogs.com/caiwenjing/p/8081391.html
https://www.cnblogs.com/jasper-changing/p/13391453.html
https://blog.csdn.net/u014600626/article/details/104635084