jjnoob

HTTP-Studying

2019-03-05
jjnoob

HTTP, 随便摘摘抄抄,也不指望写的有多全,只是为了当时看书的时候更有效率.如果我不写点东西的话,看完就忘了.

参考MDN Web Docs

一, HTTP 概览

  • HTTP是一种能够获取如 HTML 这样的网络资源的 protocol(通讯协议)。
  • HTTP被设计于20世纪90年代初期,是一种可扩展的协议。它是应用层的协议,通过TCP,或者是TLS-加密的TCP连接来发送.
  • 浏览器首先发送一个请求来获取页面的HTML文档,再解析文档中的资源信息发送其他请求,获取可执行脚本或CSS样式来进行页面布局渲染,以及一些其它页面资源(如图片和视频等)。然后,浏览器将这些资源整合到一起,展现出一个完整的文档,也就是网页。
  • 浏览器来负责发送HTTP请求,并进一步解析HTTP返回的消息,以向用户提供明确的响应。

(1) 代理 (Proxies)

不懂,遂谷歌之.

  • 代理服务器通过拦截发送者和接收者之间的连接来工作。所有传入的数据通过一个端口进入,并通过另一个端口转发到网络的其余部分。通过阻止两个网络之间的直接访问,代理服务器使得黑客更难获得内部地址和专用网络的详细信息。
  • 一个完整的代理请求过程为:客户端首先与代理服务器创建连接,接着根据代理服务器所使用的代理协议,请求对目标服务器创建连接、或者获得目标服务器的指定资源(如:文件)。在后一种情况中,代理服务器可能对目标服务器的资源下载至本地缓存,如果客户端所要获取的资源在代理服务器的缓存之中,则代理服务器并不会向目标服务器发送请求,而是直接返回缓存了的资源。
  • 一些网关、路由器等网络设备具备网络代理功能。一般认为代理服务有利于保障网络终端的隐私或安全,防止攻击.

(2) HTTP 的基本性质

  • HTTP是可扩展的: 在 HTTP/1.0 中出现的 HTTP headers 让协议扩展变得非常容易。只要服务端和客户端就新 headers 达成语义一致,新功能就可以被轻松加入进来。

  • HTTP是无状态的:在同一个连接中,两个执行成功的请求之间是没有关系的。
  • 而使用HTTP的头部扩展,HTTP Cookies就可以解决这个问题。把Cookies添加到头部中,创建一个会话让每次请求都能共享相同的上下文信息,达成相同的状态。 注意,HTTP本质是无状态的,使用Cookies可以创建有状态的会话。
  • 在互联网中,有两个最常用的传输层协议:TCP和UDP, HTTP依赖于面向连接的TCP进行消息传递.


二, HTTP 缓存

  • 当 web 缓存发现请求的资源已经被存储,它会拦截请求,返回该资源的拷贝,而不会去源服务器重新下载。这样带来的好处有:缓解服务器端压力,提升性能(获取资源的耗时更短了)。对于网站来说,缓存是达到高性能的重要组成部分。缓存需要合理配置,因为并不是所有资源都是永久不变的:
  • (私有)浏览器缓存
  • (共享)代理缓存: 架设一个 web 代理来作为本地网络基础的一部分提供给用户。这样热门的资源就会被重复使用,减少网络拥堵与延迟。

(1) 普遍的缓存案例:

  • 一个检索请求的成功响应: 对于 GET请求,响应状态码为:200,则表示为成功。一个包含例如HTML文档,图片,或者文件的响应。
  • 永久重定向: 响应状态码:301。
  • 错误响应: 响应状态码:404 的一个页面。
  • 不完全的响应: 响应状态码 206,只返回局部的信息。 除了 GET 请求外,如果匹配到作为一个已被定义的cache键名的响应。

(2) 缓存控制

  • 禁止进行缓存
  • 强制确认缓存
  • 私有缓存和共有缓存
  • 缓存过期机制
  • 缓存验证确认


三, HTTP cookies

HTTP Cookie(也叫Web Cookie或浏览器Cookie)是服务器发送到用户浏览器并保存在本地的一小块数据,它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常,它用于告知服务端两个请求是否来自同一浏览器,如保持用户的登录状态。Cookie使基于无状态的HTTP协议记录稳定的状态信息成为了可能。

(1) 创建Cookie

当服务器收到HTTP请求时,服务器可以在响应头里面添加一个Set-Cookie选项。浏览器收到响应后通常会保存下Cookie,之后对该服务器每一次请求中都通过Cookie请求头部将Cookie信息发送给服务器。

一个简单的Cookie可能像这样:

Set-Cookie: <cookie名>=<cookie值>

(2) 会话期Cookie

会话期Cookie是最简单的Cookie:浏览器关闭之后它会被自动删除,也就是说它仅在会话期内有效。有些浏览器提供了会话恢复功能,这种情况下即使关闭了浏览器,会话期Cookie也会被保留下来,就好像浏览器从来没有关闭一样。

(3) Cookie的Secure 和HttpOnly 标记

  • 标记为 Secure 的Cookie只应通过被HTTPS协议加密过的请求发送给服务端。
  • 即便设置了 Secure 标记,敏感信息也不应该通过Cookie传输,因为Cookie有其固有的不安全性,Secure 标记也无法提供确实的安全保障。
  • 为避免跨域脚本 (XSS) 攻击,通过JavaScript的 Document.cookie API无法访问带有 HttpOnly 标记的Cookie,它们只应该发送给服务端。如果包含服务端 Session 信息的 Cookie 不想被客户端 JavaScript 脚本调用,那么就应该为其设置 HttpOnly 标记。

(4) JavaScript通过Document.cookies访问Cookie

通过Document.cookie属性可创建新的Cookie,也可通过该属性访问非HttpOnly标记的Cookie。

(5) 会话劫持和XSS

  • 在Web应用中,Cookie常用来标记用户或授权会话。因此,如果Web应用的Cookie被窃取,可能导致授权用户的会话受到攻击。
  • HttpOnly类型的Cookie由于阻止了JavaScript对其的访问性而能在一定程度上缓解此类攻击

(6) 跨站请求伪造(CSRF)

有一伪装成图片的银行提现请求,当打开含有这张图片的HTML页面时,如果你之前已经登录了你的银行帐号并且Cookie仍然有效(还没有其它验证步骤),你银行里的钱很可能会被自动转走。

(7) 第三方Cookie节

  • 每个Cookie都会有与之关联的域(Domain),如果Cookie的域和页面的域相同,那么我们称这个Cookie为第一方Cookie(first-party cookie)
  • 如果Cookie的域和页面的域不同,则称之为第三方Cookie(third-party cookie.)
  • 一个页面包含图片或存放在其他域上的资源(如图片广告)时,第一方的Cookie也只会发送给设置它们的服务器。通过第三方组件发送的第三方Cookie主要用于广告和网络追踪。
  • 大多数浏览器默认都允许第三方Cookie,但是可以通过附加组件来阻止第三方Cookie


四, HTTP访问控制(CORS)

跨域资源共享 (CORS) 是一种机制,它使用额外的 HTTP 头来告诉浏览器 让运行在一个 origin (domain) 上的Web应用被准许访问来自不同源服务器上的指定的资源。

比如,站点 http://domain-a.com 的某 HTML 页面通过 < img> 的 src 请求 http://domain-b.com/image.jpg 网络上的许多页面都会加载来自不同域的CSS样式表,图像和脚本等资源。

现代浏览器支持在 API 容器中(例如 XMLHttpRequest 或 Fetch )使用 CORS,以降低跨域 HTTP 请求所带来的风险。

(1) 功能概述

规范要求,对那些可能对服务器数据产生副作用的 HTTP 请求方法(特别是 GET 以外的 HTTP 请求,或者搭配某些 MIME 类型的 POST 请求),浏览器必须首先使用 OPTIONS 方法发起一个预检请求(preflight request),从而获知服务端是否允许该跨域请求。服务器确认允许之后,才发起实际的 HTTP 请求。在预检请求的返回中,服务器端也可以通知客户端,是否需要携带身份凭证(包括 Cookies 和 HTTP 认证相关数据)。


五, HTTP 消息

(1) HTTP 请求

1, 起始行包含三个元素
  • 一个HTTP方法.
  • 请求目标 (request target)
  • HTTP 版本 (HTTP version)
2, Headers

有多种请求头可用,它们可以分为几组:

  • General headers
  • Request headers
  • Entity headers
3, Body

请求的最后一部分是它的 body。不是所有的请求都有一个 body:例如获取资源的请求,GET,HEAD,DELETE 和 OPTIONS,通常它们不需要 body。

Body大致可分为两类:

  • Single-resource bodies,由一个单文件组成。该类型 body 由两个 header 定义: Content-Type 和 Content-Length.
  • Multiple-resource bodies,由多部分 body 组成,每一部分包含不同的信息位。通常是和 HTML Forms 连系在一起。

(2) HTTP 响应

1, 状态行

包含以下信息

  • 协议版本,通常为 HTTP/1.1。
  • 状态码 (status code),表明请求是成功或失败。常见的状态码是 200,404,或 302。
  • 状态文本 (status text)。一个简短的,纯粹的信息,通过状态码的文本描述,帮助人们理解该 HTTP 消息。

一个典型的状态行看起来像这样:

HTTP/1.1 404 Not Found。
2, Headers

有许多响应头可用, 这些响应头可以分为几组:

  • General headers
  • Response headers
  • Entity headers
3, Body

响应的最后一部分是 body。不是所有的响应都有 body:具有状态码 (如 201 或 204) 的响应,通常不会有 body。

Body 大致可分为三类:

  • Single-resource bodies,由已知长度的单个文件组成。该类型 body 由两个 header 定义:Content-Type 和 Content-Length。
  • Single-resource bodies,由未知长度的单个文件组成,通过将 Transfer-Encoding 设置为 chunked 来使用 chunks 编码。
  • Multiple-resource bodies,由多部分 body 组成,每部分包含不同的信息段。但这是比较少见的。

(3) HTTP/2 帧

HTTP/1.x 报文有一些性能上的缺点:

  • Header 不像 body,它不会被压缩。
  • 两个报文之间的 header 通常非常相似,但它们仍然在连接中重复传输。
  • 无法复用。当在同一个服务器打开几个连接时:TCP 热连接比冷连接更加有效。

HTTP/2 引入了一个额外的步骤:它将 HTTP/1.x 消息分成帧并嵌入到流 (stream) 中。数据帧和报头帧分离,这将允许报头压缩。将多个流组合,这是一个被称为 多路复用 (multiplexing) 的过程,它允许更有效的底层 TCP 连接。


六, 典型的 HTTP 会话

在像 HTTP 这样的Client-Server(客户端-服务器)协议中,会话分为三个阶段:

  1. 客户端建立一条 TCP 连接(如果传输层不是 TCP,也可以是其他适合的连接)。
  2. 客户端发送请求并等待应答。
  3. 服务器处理请求并送回应答,回应包括一个状态码和对应的数据。

从 HTTP/1.1 开始,连接在完成第三阶段后不再关闭,客户端可以再次发起新的请求。这意味着第二步和第三步可以连续进行数次。

(1) 请求方法

HTTP 定义了一组 请求方法 用来指定对目标资源的行为。它们一般是名词,但这些请求方法有时会被叫做 HTTP 动词。最常用的请求方法是 GET 和 POST:

  • GET 方法请求指定的资源。GET 请求应该只被用于获取数据。
  • POST 方法向服务器发送数据,因此会改变服务器状态。这个方法常在 HTML 表单 中使用。

(2) 响应状态码

HTTP 响应状态码 用来表示一个 HTTP 请求是否成功完成。响应被分为 5 种类型:信息型响应,成功响应,重定向,客户端错误和服务端错误。

  • 200: OK. 请求成功。
  • 301: Moved Permanently. 请求资源的 URI 已被改变。
  • 404: Not Found. 服务器无法找到请求的资源。


七, HTTP/1.x 的连接管理

(1) 短连接

HTTP 最早期的模型,也是 HTTP/1.0 的默认模型,是短连接。每一个 HTTP 请求都由它自己独立的连接完成;这意味着发起每一个 HTTP 请求之前都会有一次 TCP 握手,而且是连续不断的。

(2) 长连接

短连接有两个比较大的问题:创建新连接耗费的时间尤为明显,另外 TCP 连接的性能只有在该连接被使用一段时间后(热连接)才能得到改善。为了缓解这些问题,长连接 的概念便被设计出来了

(3)HTTP 流水线


(4) 另:

  • 除非要兼容一个非常古老的,不支持长连接的系统,否则不需要使用端连接.
  • HTTP/1.0 里默认并不使用长连接 HTTP/1.1 里默认就是长连接的
  • HTTP 流水线在现代浏览器中并不是默认被启用的.

END


下一篇 Mysql-Learning

Content