HTTP:超文本传输协议
定义了浏览器(万维网客户进程)怎样向万维网服务器请求文档,以及服务器怎样把文档传送给浏览器(本身不算一种连接,相当于是形式的规定)
使用TCP作为支撑运输协议。一旦建立好TCP连接,就可以通过套接字接口访问TCP。(套接字:IP:端口号,应用层与传输层之间的接口)(上联应用进程,下联网络协议栈,是应用程序通过网络协议进行通信的接口)
服务器进程监听TCP的端口80,以便发现是否有客户请求服务。一旦监听到了连接建立请求,并且与客户建立好了TCP连接后(TCP连接是传输层),浏览器就可以开始发出浏览界面的请求,发送http请求报文,请求相关的文档。服务器收到请求报文后,把资源以文档的形式放到http响应报文中,返回给客户。之后就可以释放TCP连接
具体过程
1、浏览器分析URL,本地host文件有的话就直接解析了
2、浏览器向DNS请求解析IP地址
3、DNS解析出IP地址
4、浏览器与服务器建立TCP连接(传输层,三次握手建立连接)(第三次握手可以发送http请求报文,作为第三次握手的数据发送给服务器)。(!先建立TCP连接后才能发HTTP请求)
客户端向服务器发送http请求报文。
5、浏览器发出取文件命令(http请求报文)
6、服务器响应(http响应报文)
7、释放TCP连接
8、浏览器显示
特点
-
http协议是无状态的:同一个客户第二次访问的时候响应是相同的(协议本身)(就不知道是哪个客户)
-
http协议采用TCP作为运输层协议,但http协议本身是无连接的(通信双方在交换http报文之前不需要先建立http连接,但是得建立TCP连接)(其实就是一个请求和响应)
http连接方式:持久连接(非流水线式、流水线式)、非持久连接
-
非持久:之前的连接会断掉,再次请求得重新建立TCP连接
-
持久:再次请求就不需要再建立TCP连接,在之前建立的连接的基础上继续请求服务器发送响应后的一段时间内仍保持连接
- 非流水线式:发一个请求,得一个响应,再发一个新的
- 流水线式:可以连续发送,服务器就依次返回,使TCP连接的空闲时间少
Cookie、Session、Token
Web应用程序是使用HTTP协议传输数据的。HTTP 是无连接无状态的,无法从连接上跟踪会话。
会话跟踪是Web程序中常用的技术,用来跟踪用户的整个会话。
常用的会话跟踪技术是Cookie与Session,都是用来记录信息确定用户身份的。
Cookie通过在客户端记录信息确定用户身份,Session通过在服务器端记录信息确定用户身份。
Cookie
-
Cookie由服务器生成,发送给浏览器,下一次请求同一网站时会把该Cookie发送给服务器。
-
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。响应报文里Set-Cookie的首部字段信息通知客户端保存Cookie。下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入Cookie 值后发送出去。服务器端发现客户端发送过来的Cookie 后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。
优点:服务器不用保存状态信息, 减轻服务器存储压力,同时便于服务端做水平拓展。
缺点:该方式不够安全,因为状态信息存储在客户端,这意味着不能在会话中保存机密数据。除此之外,浏览器每次发起 HTTP 请求时都需要发送额外的 Cookie 到服务器端,会占用更多带宽。
Session
- 对象存储特定用户会话所需的属性及配置信息。
- 服务器就要给每个客户端分配不同的“身份标识”,然后客户端每次向服务器发请求的时候,都带上这个“身份标识”,服务器就知道这个请求来自于谁了。默认采用 cookie 的方式保存和发生这个身份标识。
- 当用户在应用程序的 Web 页之间跳转时,存储在 Session 对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时,如果该用户还没有会话,则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后,服务器将终止该会话。
- 客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
步骤:
- 客户端把用户ID 和密码等登录信息放入报文的实体部分,通常是以 POST 方法把请求发送给服务器。
- 服务器会发放用以识别用户的 Session ID。通过验证从客户端发送过来的登录信息进行身份认证,然后把用户的认证状态与 Session ID 绑定后记录在服务器端。向客户端返回响应时,会在首部字段 Set-Cookie 内写入 Session ID。
- 客户端接收到从服务器端发来的 Session ID 后,会将其作为 Cookie 保存在本地。下次向服务器发送请求时,浏览器会自动发送 Cookie,所以 Session ID 也随之发送到服务器。服务器端可通过验证接收到的 Session ID 识别用户和其认证状态。
优点:安全性高,因为状态信息保存在服务器端。
缺点:由于大型网站往往采用的是分布式服务器,浏览器发送的 HTTP 请求一般要先通过负载均衡器才能到达具体的后台服务器,倘若同一个浏览器两次 HTTP 请求分别落在不同的服务器上时,基于 Session 的方法就不能实现会话保持了。
【解决方法:采用中间件,例如 Redis,我们通过将 Session 的信息存储在 Redis 中,使得每个服务器都可以访问到之前的状态信息】
-
都是用来跟踪浏览器用户身份的会话方式
-
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话,那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案,客户来访的时候只需要查询客户档案表就可以了。
-
虽然Session保存在服务器,对客户端是透明的,它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的,Session不能依据HTTP连接来判断是否为同一客户。
简单的说,当你登陆一个网站的时候,如果web服务器端使用的是session,那么所有的数据都保存在服务器上,客户端每次请求服务器的时候会发送当前会话session id,服务器根据当前session id判断相应的用户数据标志,以确定用户是否登陆或具有某种权限。
由于数据是存储在服务器上面,所以你不能伪造。SessionID这一数据则是保存到客户端,用Cookie保存的,用户提交页面时,会将这一 SessionID提交到服务器端,来存取Session数据。这一过程,是不用开发人员干预的。所以一旦客户端禁用Cookie,那么Session也会失效。
cookie和session的区别:
-
cookie数据保存在客户端,session数据保存在服务端
-
当访问增多,会比较占用你服务器的性能考虑到减轻服务器性能方面,应当使用cookie。
-
单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制,其中可以保存更为复杂的数据类型)
记住密码功能就是使用永久cookie写在客户端电脑,下次登录时,自动将cookie信息附加发送给服务端。
Token
token的意思是“令牌”,是用户身份的验证方式。是服务端生成的一串字符串,以作客户端进行请求的一个令牌,当第一次登录后,服务器生成一个Token便将此Token返回给客户端,以后客户端只需带上这个Token前来请求数据即可,无需再次带上用户名和密码。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串,可以防止恶意第三方拼接token请求服务器)。
Token的目的是为了减轻服务器的压力,减少频繁的查询数据库,使服务器更加健壮。
使用基于 Token 的身份验证方法,在服务端不需要存储用户的登录记录。大概的流程是这样的:
- 客户端使用用户名跟密码请求登录
- 服务端收到请求,去验证用户名与密码
- 验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端
- 客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里
- 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
- 服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据
session与token的区别:
- session是空间换时间,token是时间换空间。
- session和sessionid:服务器会保存一份,可能保存到缓存/数据库/文件。
- token:服务器不需要记录任何东西,每次都是一个无状态的请求,每次都是通过解密来验证是否合法。
sessionid:一般是随机字符串,要到**服务器检索id的有效性。**出现请求:服务器重启饿内存中的session没了,数据库服务器挂了。
报文结构
请求报文
每行末尾是回车符和换行符来表示换行。(换行符:\n,回车符:\r)
头部的最后有单独的一行回车符和换行符来跟数据间隔开。
-
请求行
- 方法
- URL
- 协议及版本
-
首部行
- 首部字段名:值
-
实体主体(通常不用)
GET /index.html HTTP/1.1
Host:www.test.edu.cn
Connection:Close
Cookie:123
方法 | |
---|---|
GET | 请求从服务器获取资源。请求指定的页面信息,并返回具体内容,通常只用于读取数据。请求获取资源。 |
POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立或已有资源的更改。 |
HEAD | 与 GET 相同,但只返回 HTTP 报头,不返回文档主体 |
PUT | 替换指定的资源,没有的话就新增。 |
DELETE | 删除指定资源 |
OPTIONS | 向服务器发送该方法,会返回对指定资源所支持的 HTTP 请求方法。 |
CONNECT | 要求用隧道协议连接代理。 |
TRACE | 追踪路径。 |
PATCH | 是对 PUT 方法的补充,用来对已知资源进行局部更新。 |
GET | POST | |
---|---|---|
目的 | 请求从服务器获取资源。 | 提交数据请求处理。数据被包含在请求体中。POST 请求可能会导致新的资源的建立或已有资源的更改。 |
数据位置 | 在 URL 中发送的,有长度限制,只支持 URL 编码(真正限制 GET 长度的是浏览器) | 在 HTTP 消息主体中发送的,对数据长度没有要求,支持多种编码格式。 |
安全性 | 可被缓存、保留在浏览器历史记录中、可被收藏为书签 -》不应在处理敏感数据时使用 | 不会被缓存、不会保留在浏览器历史记录中、不能被收藏为书签 |
后退按钮/刷新 | 无害 | 数据会被重新提交 |
响应报文
- 状态行
- 版本
- 状态码+短语
- 首部行
- 实体主体
状态码
1XX | 提示信息,表示目前是协议处理的中间状态。 | 100 继续:已经收到请求的一部分,正在等待其余部分。 |
2XX | 成功,报文已经被收到并被正确处理。 | 200 OK:成功。204 No Content:成功,但是响应报文没有实体主体。206 Partial Content:用于分块下载或断点续传,表示只是其中一部分。 |
3XX | 重定向,资源位置发生变动。 | 301 Moved Permanently:永久重定向,请求的URL已经不在了,要用新的重新访问。302 Found:临时重定向。 |
4XX | 客户端错误,请求报文有误,服务器无法处理。 | 400 Bad Request:请求报文有误(笼统的)。403 Forbidden:服务器禁止访问该资源。404 Not Found:请求的资源在服务器上不存在或未找到。 |
5XX | 服务器错误。 | 500 Internal Server Error:笼统错误码。501 Not Implemented:请求的功能还不支持。502 Bad Gateway:服务器作为网关或者代理时返回的错误码,访问后端服务器发生了问题。503 Service Unavailable:服务器当前很忙,暂时无法相应。 |
长连接和短连接
- HTTP的长连接和短连接本质上是TCP的长连接和短连接(因为HTTP本身是没有连接的)
- HTTP协议是基于请求/响应模式的,因此只要服务端给了响应,本次HTTP连接就结束了,或者更准确的说,是本次HTTP请求就结束了,根本没有长连接这一说。
短连接:每次发起一个HTTP请求,都要重新建立一个TCP连接,传完一次后就关闭。而且是串行请求,增加通信开销。
必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接,客户机和服务器都要分配 TCP 的缓冲区和变量,这给服务器带来的严重的负担,因为一台 Web 服务器可能同时服务于数以百计的客户机请求。创建和关闭连接的过程也消耗资源和时间。
为了减少资源消耗,缩短响应时间,就需要重用连接。
HTTP/1.1 版本中默认使用持久连接,在此之前的 HTTP 版本的默认连接都是使用非持久连接。想要长连接的话要在报文首部行加上connection :keep-alive,会有一个保持时间。
在 Keep-Alive 方式下,服务器在响应后保持该 TCP 连接打开,在同一个客户机与服务器之间的后续请求和响应报文可通过相同的连接进行传送。甚至位于同一台服务器的多个 Web 页面在从该服务器发送给同一个客户机时,可以在单个持久 TCP 连接上进行。
当长时间的保持 TCP 连接时容易导致系统资源被无效占用,若对 Keep-Alive 模式配置不当,将有可能比非 Keep-Alive 模式带来的损失更大。因此,我们需要正确地设置 keep-alive timeout 参数,当 TCP 连接在传送完最后一个 HTTP 响应,该连接会保持 keepalive_timeout 秒,之后就开始关闭这个链接。
长连接情况下,多个HTTP请求可以复用同一个TCP连接,这就节省了很多TCP连接建立和断开的消耗。
长连接:多用于操作频繁,点对点的通讯,而且客户端连接数目较少的情况。例如即时通讯、网络游戏等。
短连接:用户数目较多的Web网站的 HTTP 服务一般用短连接。例如京东,淘宝这样的大型网站一般客户端数量达到千万级甚至上亿,若采用长连接势必会使得服务端大量的资源被无效占用,所以一般使用的是短连接。
长连接使得可以流水线处理(管道传输):可以发起多个请求,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,可以减少整体的响应时间。
http 1.0和http 1.1的区别
- 长连接:HTTP 1.0默认使用短连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接。HTTP 1.1支持长连接和请求的流水线处理。长连接:在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。流水线处理:允许客户端不用等待上一次请求结果返回,就可以发出下一次请求
- 带宽优化及网络连接的使用:1、HTTP/1.1中在请求消息中引入了range头域,它允许只请求资源的某个部分。2、另外一种情况是请求消息中如果包含比较大的实体内容,但不确定服务器是否能够接收该请求(如是否有权限),此时若贸然发出带实体的请求,如果被拒绝也会浪费带宽。客户端事先发送一个只带头域的请求,如果服务器因为权限拒绝了请求,就回送响应码401;如果服务器接收此请求就回送响应码100(新引入的),客户端就可以继续发送带实体的完整请求了。
- 状态码增加、增加了OPTIONS方法
- 增加Host字段:传递主机名(因为一台物理服务器上可以存在多个虚拟机,共享一个IP地址)
- 缓存处理:引入更多缓存控制策略
HTTP/1.1 相比 HTTP/1.0:
- 长连接
- 支持管道网络传输
HTTP/2 相比 HTTP/1.1:
- 头部压缩:多个请求的头部类似或相同的话,会消除重复的部分
- 二进制格式:头部和数据体都是二进制格式,增加传输效率
- 多路复用:在一个连接中并发多个请求或回应,不用按照顺序一一对应(比如A做好的部分先发,然后就可以发B的,A剩下的接着做完了再发)
- 服务器主动推送
- ……
……