web前端对http理解

迈不过友情╰ 2022-01-18 22:09 177阅读 0赞

# 1. 基础概念篇 #

[TCP/IP 通信传输流][TCP_IP]

[cookie][]

[url和URI][url_URI]

[get和post][get_post]

[cookie,session,webstorge区别][cookie_session_webstorge]

[跨域][Link 1]

[网络安全][Link 2]

[http缓存][http]

## 1.1介绍 ##

HTTP是Hyper Text Transfer Protocol（超文本传输协议）的缩写。

HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。

HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。

## 1.2 在TCP/IP协议栈中的位置 ##

HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS。如下图所示：

首先，纠正一下我以前一直误解的概念，我一直以为Http和Tcp是两种不同的，但是地位对等的协议，虽然知道TCP是传输层，而http是应用层。今天学习了下，知道了 http是要基于TCP连接基础上的，简单的说，TCP就是单纯建立连接，不涉及任何我们需要请求的实际数据，简单的传输。http是用来收发数据，即实际应用上来的。

默认HTTP的端口号为80，HTTPS的端口号为443。

## 1.3 HTTP的请求响应模型 ##

HTTP协议永远都是客户端发起请求，服务器回送响应。见下图：

这样就限制了使用HTTP协议，无法实现在客户端没有发起请求的时候，服务器将消息推送给客户端。

HTTP协议是一个无状态的协议，同一个客户端的这次请求和上次请求是没有对应关系。

注意：客户端与服务器的角色不是固定的，一端充当客户端，也可能在某次请求中充当服务器。这取决与请求的发起端。HTTP协议属于应用层，建立在传输层协议TCP之上。客户端通过与服务器建立TCP连接，之后发送HTTP请求与接收HTTP响应都是通过访问Socket接口来调用TCP协议实现

## 1.4 工作流程 ##

一次HTTP操作称为一个事务，其工作过程可分为四步：

1）首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。

2）建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。

3）服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。

4）客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。

如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。

## 1.5http发展历史 ##

**HTTP/1.0 标准于 1996 年 5 月作为第一份标准被公布，它被记载于 RFC1945 - Hypertext Transfer Protocol -- HTTP/1.0**

**HTTP/1.1 标准于 1999 年 6 月被公布，截止到目前它应该是最主流的 HTTP 协议版本，它被记载于 RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1**

**HTTP/2 标准于 2015 年 5 月被正式发布，它被记载于 RFC7540 - Hypertext Transfer Protocol -- HTTP/2**

它的特点是

① 采用二进制而非明文来打包，

② 多路复用，

③ 修复队头堵塞，

④ 允许设置设定请求优先级，

⑤ 服务器推送，

⑥ WebSocket 等等。

**HTTP/2为什么是二进制？**

比起像HTTP/1.x这样的文本协议，二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少。

**为什么 HTTP/2 需要多路传输?**

HTTP/1.x 有个问题叫线端阻塞(head-of-line blocking), 它是指一个连接(connection)一次只提交一个请求的效率比较高, 多了就会变慢。 HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重。而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。所以客户端只需要一个连接就能加载一个页面。

**消息头为什么需要压缩?**

假定一个页面有80个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1400字节的消息头（着同样也并不少见，因为Cookie和引用等东西的存在）, 至少要7到8个来回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已。这全都由于TCP的慢启动机制，它会基于对已知有多少个包，来确定还要来回去获取哪些包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量。相比之下，即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个包就可以了。这种开销是可以被节省下来的，特别是当你考虑移动客户端应用的时候，即使是良好条件下，一般也会看到几百毫秒的来回延迟。

**服务器推送的好处是什么？**

当浏览器请求一个网页时，服务器将会发回HTML，在服务器开始发送JavaScript、图片和CSS前，服务器需要等待浏览器解析HTML和发送所有内嵌资源的请求。服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端的缓存中，以此来避免往返的延迟。

# 2. http请求 #

下图是在网上找的一张图，觉得能很好的表达HTTP请求的所发送的数据格式。

由上图可以看到，http请求由请求行，消息报头，请求正文三部分构成。

## HTTP请求状态行 ##

请求行由请求Method, URL 字段和HTTP Version三部分构成, 总的来说请求行就是定义了本次请求的请求方式, 请求的地址, 以及所遵循的HTTP协议版本例如：

GET /example.html HTTP/1.1 (CRLF)
    复制代码

## 未完待续。。。 ##

# 3.HTTP的五大特点 #

*  **支持客户/服务器模式**。
 *  **简单快速**：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
 *  **灵活**：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
 *  **无连接**：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。早期这么做的原因是请求资源少，追求快。后来通过Connection: Keep-Alive实现长连接
 *  **无状态**：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
 *

**非持久连接和持久连接**

在实际的应用中，客户端往往会发出一系列请求，接着服务器端对每个请求进行响应。对于这些请求|响应，如果每次都经过一个单独的TCP连接发送，称为**非持久连接**。反之，如果每次都经过相同的TCP连接进行发送，称为**持久连接**

非持久连接在每次请求|响应之后都要断开连接，下次再建立新的TCP连接，这样就造成了大量的通信开销。例如前面提到的往返时间(RTT) 就是在建立TCP连接的过程中的代价。

非持久连接给服务器带来了沉重的负担，每台服务器可能同时面对数以百计甚至更多的请求。持久连接就是为了解决这些问题，其特点是一直保持TCP连接状态，直到遇到明确的中断要求之后再中断连接。持久连接减少了通信开销，节省了通信量。

## HTTP优化方案 ##

*  TCP复用，TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端的TCP连接上，HTTP复用是指一个一个客户端的多个HTTP请求通过一个TCP连接进行处理。
 *  内容缓存。将经常用到的内容进行缓存起来，那么客户端就可以直接在内存中获取相应的数据了。
 *  压缩，将文本数据进行压缩，减少宽带
 *  SSL加速。使用SSL协议对HTTP协议进行加密，在通道内加密并加速
 *  TCP缓冲：通过TCP缓冲技术，可以提高服务器端响应事件和处理效率，减少由于通信链路问题给服务器造成连接负担.

# 4.HTTP和HTTPS #

## HTTP的不足 ##

*  通信使用明文(不加密),内容可能会被窃听
 *  不验证通信方的身份,因此有可能遭遇伪装
 *  无法证明报文的完整性,所以有可能已遭篡改

## HTTPS介绍 ##

HTTP 协议中没有加密机制,但可以通过SSL(Secure Socket Layer, 安全套接层 )或 TLS(Transport Layer Security, 安全层传输协议)的组合使用,加密 HTTP 的通信内容。属于通信加密，即在整个通信线路中加密。

HTTP + 加密 + 认证 + 完整性保护 = HTTPS（HTTP Secure ）
    
    复制代码

HTTPS 采用共享密钥加密（对称）和公开密钥加密（非对称）两者并用的混合加密机制。若密钥能够实现安全交换,那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比,其处理速度要慢。

所以应充分利用两者各自的优势, 将多种方法组合起来用于通信。 在交换密钥阶段使用公开密钥加密方式,之后的建立通信交换报文阶段 则使用共享密钥加密方式。

## HTTPS握手过程的简单描述如下： ##

1，**浏览器将自己支持的一套加密规则发送给网站。**

服务器获得浏览器公钥

2，**网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息**。

浏览器获得服务器公钥

3，**获得网站证书之后浏览器要做以下工作：**

*  验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
 *  如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码（接下来通信的密钥），并用证书中提供的公钥加密（共享密钥加密）。
 *  使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。

4，**网站接收浏览器发来的数据之后要做以下的操作：**

*  使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
 *  使用密码加密一段握手消息，发送给浏览器。

## HTTPS的不足 ##

加密解密过程复杂，导致访问速度慢

加密需要认向证机构付费

整个页面的请求都要使用HTTPS

转载于:https://juejin.im/post/5cd2639451882535b455ac5a

[TCP_IP]: https://juejin.im/post/5cd27f58f265da036b4a7c69
[cookie]: https://juejin.im/post/5cd3d915f265da038e54c402
[url_URI]: https://juejin.im/post/5cd4e444e51d456e266d89fa
[get_post]: https://juejin.im/post/5c3f270d5188252b7d0ea3e5
[cookie_session_webstorge]: https://link.juejin.im?target=https%3A%2F%2Fwww.cnblogs.com%2Fcencenyue%2Fp%2F7604651.html
[Link 1]: https://juejin.im/post/5c3564756fb9a04a01648306
[Link 2]: https://juejin.im/post/5baf3740f265da0ad13b8cc7
[http]: https://juejin.im/post/5c3d4bfa6fb9a049e6607fa4