HTTP相关知识点总结
名词解释
-
HTTP ：超越文字的传输程序（HyperText Transfer Protocol, HTTP）是网络中的通信标准之一。所有网页文档均需遵循这一规范（默认端口为80）。
-
HTTPS : HTTPS（全称：Hyper Text Transfer Protocol (HTTP) over Secure Socket Layer (SSL))），是一种旨在提供数据传输安全性的增强型HTTP通道。这种通道基于位于其上层协议中的TLS/SSL机制运行。它依赖于数字证书来进行身份认证，并对客户端与服务器之间的通信进行加密处理。（默认端口为443）
- HTTP和HTTPS的区别
- HTTP协议以明文传输信息，在安全性和可靠性方面均存在潜在风险。采用安全套接字层（SSL）进行数据加密的HTTPS协议，则通过TLS/SSL标准实现了更高的安全性与稳定性；其核心功能与传统HTTP协议一致，在应用层面可视为一种更为安全的替代方案。
- HTTP与HTTPS在通信机制上存在显著差异：前者采用端口80实现通信服务请求与响应；后者则选用端口443建立更加安全可靠的通信通道。
- HTTP相关资源通常以http://格式标识；而HTTPS相关资源则采用https://标识。
- HTTP服务无需认证证书即可运行；但为了确保通信安全性与完整性；HTTPS则必须附带电子认证证书（如SSL数字证书）进行身份验证与数据加密处理。
一次完整的HTTP事物
当我们访问网站时，在浏览器的地址栏键入一个域名并按回车键后，在正常情况下（除非出现错误），浏览器会立即显示所需内容。
由于我们需要通过主机的IP地址来定位它，在传统的TCP/IP协议中，在网络层使用的是IP地址而非硬件地址。
传统的DNS系统无法自动解析IP到 hostname对应关系的问题促使人们开发了DNS技术。
但是要怎么获取或确定这个IP地址呢？
因为每个IP都是唯一的32位编码（例如：127.0.0.1），如果我们要访问多个网站的话...
当然不用记下所有的数字（例如：192.168.1.1），而是有了‘域名’的概念就方便多了。
访问Google网站时...
- 浏览器将自身DNS缓存作为查询对象，在查找是否存在与www.google.com相匹配的记录。
- 如果找到了符合条件（存在记录且未过期）则完成此次解析；若不符合条件，则继续下一步。
- 如果没有发现匹配项，则转向检查操作系统自身的DNS缓存。
- 检查hosts文件以寻找是否存在对应IP地址。
- 如果发现并确认有对应IP地址，则实现成功的 DNS 解析。
- 否则继续执行下一步骤。
- 系统将随后将向本地配置的第一个优先级 DNS 服务器发出 DNS 请求，并根据后续步骤完成整个 DNS 解析流程（如图所示）。
通过定位机制确定目标服务器后 当浏览器发起请求时会发送HTTP请求包建立与目标服务器的TCP连接 并从目标服务器获取所需资源文档信息 在接收完整份完整的HTTP 请求包之前 该系统会等待对方发送完毕 然后当接收到完整的HTTP 请求包后 会立即生成并返回响应数据 这些响应数据将被用来解析生成相应的网页内容 此外 如果所访问资源包含JavaScript等动态语言代码 那么系统会在处理完毕这些动态内容之后结束当前的数据传输过程 最终完成了一次完整的HTTP 事务处理流程
TCP连接的建立与释放
在完成域名解析的过程中，在第五步时, 浏览器与服务器之间建立连接, 并由浏览器发送请求给服务器, 在服务器收到请求后会回应请求, 并最终断开连接的过程, 则被称为非常经典的三次握手与四次握手
TCP连接的建立
最初两端的TCP进程均处 inactive 状态状态。随后客户端将向服务器发出 SYN 信号以建立连接；与此同时服务器也会响应这一请求以进入SYN-RCVD状态等待数据传输的到来。
在接收到SYN报文后 若服务器同意建立连接则会返回ACK报文并为后续的数据传输做好准备。
在此过程中客户端将执行一系列的动作包括SYN-SENT操作并在收到ACK确认后切换至ESTABLISHED状态；同时服务器也会根据客户端的ACK信息切换至ESTABLISHED状态完成三次握手过程。
TCP的连接释放
TCP连接释放的过程较为复杂,涉及四个步骤,即四步握手流程.这里就不详细阐述这个过程了,但需要指出的是,当客户端发送完最后一个ACK报文段后,必须在发送完最后一个ACK报文段后等待2MSL的时间之后才能关闭该链接.其中,MSL被称为最长报文段寿命.有两个主要原因:其一是为了确保客户端发送的最后一份ACK报文能够成功到达服务器端;其二是为了防止上文中提到的有效连接请求报文不在本链路上发生.
HTTP header
HTTP请求数据：
通过查看上图可知，在HTTP中，
HTTP中的请求信息分为三个组成部分：
首先是请求方法，
接着是URI协议版本，
最后是Request Header和Request正文。
GET/sample.Jsp HTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234(1)请求方法URI协议/版本
请求的第一行是“方法URL协议版本”：
GET/sample.jsp HTTP/1.1
以上代码中“GET”代表请求方法，“/sample.jsp”表示URI，“HTTP/1.1代表协议和协议的版本。
根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1支持7种请求方法：GET、POST、HEAD、OPTIONS、 PUT、DELETE和TARCE。在Internet应用中，最常用的方法是GET和POST。
URL完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本 声明了通信过程中使用HTTP的版本。
(2)请求头(Request Header)
请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。
Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.在HTTP协议中，在Request header与Request body之间应留一个空白行。此空白行具有重要意义，在此位置上放置适当的内容有助于确保通信双方对各自角色的信息明确无误地达成共识。其后即为Request body内容。其中可包含客户端提交的查询字符串信息：
username=jinqiao&password=1234HTTP请求方法：
| 序号 | 方法 | 描述 |
|---|---|---|
| 1 | GET | 请求指定的页面信息，并返回实体主体。 |
| 2 | HEAD | 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 | POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 | DELETE | 请求服务器删除指定的页面。 |
| 6 | CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 | OPTIONS | 允许客户端查看服务器的性能。 |
| 8 | TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
Requests部分：
| Header | 解释 | 示例 |
|---|---|---|
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
| Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
| Authorization | HTTP授权的授权证书 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） | Connection: close |
| Cookie | HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
| Content-Length | 请求的内容长度 | Content-Length: 348 |
| Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 请求的特定的服务器行为 | Expect: 100-continue |
| From | 发出请求的用户的Email | From: user@email.com |
| Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
| If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
| Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只请求实体的一部分，指定范围 | Range: bytes=500-999 |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
| TE | 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向服务器指定某种传输协议以便服务器进行转换（如果支持） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中间网关或代理服务器地址，通信协议 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
Responses 部分：
| Header | 解释 | 示例 |
|---|---|---|
| Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
| Age | 从原始服务器到代理缓存形成的估算时间（以秒计，非负） | Age: 12 |
| Allow | 对某网络资源的有效的请求行为，不允许则返回405 | Allow: GET, HEAD |
| Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
| Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
| Content-Language | 响应体的语言 | Content-Language: en,zh |
| Content-Length | 响应体的长度 | Content-Length: 348 |
| Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回资源的MD5校验值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
| Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.zcmhi.com/archives/94.html |
| Pragma | 包括实现特定的指令，它可应用到响应链上的任何接收方 | Pragma: no-cache |
| Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | Proxy-Authenticate: Basic |
| refresh | 应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持） | Refresh: 5; url= http://www.zcmhi.com/archives/94.html |
| Retry-After | 如果实体暂时不可取，通知客户端在指定时间之后再次尝试 | Retry-After: 120 |
| Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Set-Cookie | 设置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
| Trailer | 指出头域在分块传输编码的尾部存在 | Trailer: Max-Forwards |
| Transfer-Encoding | 文件传输编码 | Transfer-Encoding:chunked |
| Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 | Vary: * |
| Via | 告知代理客户端响应是通过哪里发送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 警告实体可能存在的问题 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 | WWW-Authenticate: Basic |
cookie和session
概述：
具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。
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传递回服务器。实际上这种技术可以简单的用对action应用URL重写来代替。
cookie 和session 的区别：
1、cookie数据被存储在客户的浏览器端设备中作为本地数据使用；而session数据则以持久化的方式存在服务器端系统中供应用程序调用。
2、由于cookie的安全性较低，在某些情况下可能存在被恶意分析或利用的可能性；因此为了提高安全性应当优先考虑使用session机制。
3、session会在预设的时间段内保持在服务器端系统中供应用调用处理；但当并发访问量过大时可能会对服务器性能造成一定的压力。
4、单个cookie能够承载的数据量受到严格的限制通常不超过4KB；同时很多主流浏览器对同一网站使用的cookie数量也有限制一般不超过20个。
5、综上所述建议采取以下措施：将涉及用户登录认证或其他敏感操作的信息存储为session；而对于不需要保密的其他辅助信息则可以选择以cookie形式进行存储以减少对内存资源的占用。
Keep-Alive
在http早期，每个http请求都要求打开一个tcp socket连接，并且使用一次之后就断开这个tcp连接。使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高http服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。
http keep-alive与tcp keep-alive，不是同一回事，意图不一样。http keep-alive是为了让tcp活得更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是TCP的一种检测TCP连接状况的保鲜机制。
一个完整的HTTP事务，有链接的建立，请求的发送，响应接收，断开链接这四个过程,早期通过HTTP协议传输的数据以文本为主，一个请求可能就把所有要返回的数据取到，但是，现在要展现一张完整的页面需要很多个请求才能完成，如图片,JS,CSS等，如果每一个HTTP请求都需要新建并断开一个TCP，这个开销是完全没有必要的。开启HTTP Keep-Alive之后，能复用已有的TCP链接，当前一个请求已经响应完毕，服务器端没有立即关闭TCP链接，而是等待一段时间接收浏览器端可能发送过来的第二个请求，通常浏览器在第一个请求返回之后会立即发送第二个请求，如果某一时刻只能有一个链接，同一个TCP链接处理的请求越多，开启KeepAlive能节省的TCP建立和关闭的消耗就越多。
TCP三次握手建立的过程中（第一个报文SYN从发起方发出，第二个报文SYN,ACK是从被连接方发出，第三个报文ACK确认对方的SYN，ACK已经收到）但是数据实际上并没有传输，因为请求是有数据的，第四个报文才是数据传输开始的过程，使用wireshark把第四个报文解析成HTTP协议，HTTP协议的GET方法和URI也解析出来，所以说TCP层是没有请求的概念，HTTP协议（事务性协议）才有请求的概念，TCP报文承载HTTP协议的请求(Request)和响应(Response)。
需要注意的地方：
HTTP协议无状态特性表明其在事务处理方面并无存储能力，在这种状态下服务器无法得知客户端所处的状态信息。另一方面而言，在开启一个服务器端网页后与其他之前访问该服务器端网页之间并无关联性；无状态属性并不意味着该协议无法维持TCP连接或者依赖UDP（无连接）传输机制。
自HTTP/1.1标准实施以来，默认启用Keep-Alive功能以保持数据传输连接的持续性。具体来说，在打开一个服务器端网页后客户端与服务器之间的TCP连接不会立即关闭；当客户端再次访问该服务器端网页时会继续使用已建立的这一连接进行数据传输。
Keep-Alive功能并非永久维持连接状态而是伴随有一定期限的存在，在不同服务器软件（如Apache）中可自行设定该保持时间参数；然而长时间维持未断开的TCP连接可能导致系统资源过度占用甚至出现效率问题。因此在配置Keep-Alive时间间隔参数时必须谨慎选择以避免造成不必要的系统资源浪费。