HTTP协议

最新推荐文章于 2024-09-07 17:16:29 发布

hi168

最新推荐文章于 2024-09-07 17:16:29 发布

阅读量264

点赞数

分类专栏：计算机网络

本文链接：https://blog.youkuaiyun.com/qq_43185543/article/details/104396673

版权

计算机网络专栏收录该内容

1 篇文章

订阅专栏

一、HTTP协议初相识

HTTP协议(超文本传输协议)，它是基于TCP协议的应用层传输协议，简单来说就是客户端和服务端进行数据传输的一种规则。

1.一次HTTP请求的完整过程：

1.域名解析
1>浏览器会首先搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存），查找自身的缓存中是否存在域名对应的IP地址，如果查找到且没有过期则解析到此结束。
2>如果浏览器自身的缓存里面没有查找到对应的IP地址，那么浏览器会查找操作系统自身的DNS缓存,如果查找到且没有过期则停止搜索解析到此结束。
3>如果在操作系统的DNS缓存也没有查找到，那么尝试读取hosts文件（位于C:\Windows\System32\drivers\etc），查找hosts文件中该域名对应的IP地址是否存在，如果存在则解析成功。
4> 如果在hosts文件中也没有查找到对应的IP地址。则浏览器通过UDP协议向本地域名服务器的53端口发起递归查询。
- 域名的解析过程：
- 第一，主机向本地域名服务器的查询一般都采用的是递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就会以DNS客户的身份，向其他根域名服务器继续发出查询请求报文（即代替主机继续查询），而不是让主机自己进行下一步的查询。因此，递归查询返回的查询结果或者是所要查找的IP地址，或者是报错，表示无法查询到所需的IP地址。
- 第二，本地域名服务器向根域名服务器的查询通常采用的是迭代查询。所谓迭代查询就是：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地域名服务器自己知道的顶级域名服务器的IP地址，让本地域名服务器再向顶级域名服务器查询（而不是代替本地域名服务器进行后续的查询）。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地域名服务器下一步应当向哪一个权限域名服务器进行查询，本地域名服务器就这样进行迭代查询。最后，知道了所要解析的域名的IP地址，然后把这个结果返回给发起查询的主机。
- 最后说明：本地域名服务器采取迭代查询还是递归查询，这取决于最初的查询请求报文的设置是要求使用哪一种查询方式。
2.进行TCP的3次握手，建立TCP连接浏览器向服务器请求建立链接，发起三次握手（以后博客仔细分析）
3.浏览器向服务器发送 HTTP 请求
HTTP请求报文分为：请求行、请求头、请求体。
请求行：用于描述客户端的请求方式，请求资源的URL和HTTP协议的版本（例：GET /books/java.html HTTP/1.1）
请求头：用于描述客户端的请求信息。
　　注意：这里提一个请求头 Connection，Connection设置为 keep-alive表明本次HTTP请求之后并不需要关闭TCP连接，这样下次的HTTP请求可以使用相同的TCP通道，节省TCP建立连接的时间。
请求体：当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求体中（GET方式是保存在url地址后面，不会放到这里）
4.服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器
HTTP响应报文分为：响应行、响应头、响应体。
响应行：用于描述服务器端的HTTP协议的版本号，状态码和状态码描述。
响应头：用于描述服务器端的响应信息。
响应体：返回的是服务器端给客户端响应的的文本信息。如果是纯数据就是返回纯数据，如果请求的是HTML页面，那么返回的就是HTML代码。
5.浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面

2.域名缓存

为了提高 DNS 查询效率，并减轻服务器的负荷和减少因特网上的 DNS 查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

由于名字到地址的绑定并不经常改变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项（例如：每个项目两天）。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息，就必须重新到授权管理该项的域名服务器绑定信息。当权限服务器回答一个查询请求时，在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销，而减少此时间值可提高域名解析的正确性。

不仅在本地域名服务器中需要高速缓存，在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到名字时才使用域名服务器。维护本地域名服务器数据库的主机应当定期地检查域名服务器以获取新的映射信息，而且主机必须从缓存中删除无效的项。由于域名改动并不频繁，大多数网点不需花精力就能维护数据库的一致性。

3.长连接和短连接

在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。
而从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如：Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

4.HTTP版本区别

1.0版本
(1)GET命令，还引入了POST命令和HEAD命令。
(2)使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次TCP连接，任务结束就中断TCP连接；如果需要长连接需要设置keep-alive参数。

1.1版本
(1)新增DELETE、OPTIONS、PUT、 PATCH命令；
(2)使用长连接。也就是说，客户端和服务器进行一次 HTTP 操作后，TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接；
(3)引入了管道机制（ pipelining），即在同一个TCP连接里，客户端可以同时发送多个请求，进一步改进了HTTP协议的效率
(4)节约带宽，HTTP1.1支持只发送header头信息不带任何body信息，如果服务器认为客户端有权限请求指定数据那就返回100，没有就返回401，当客户端收到100的时候可以才把要请求的信息发给服务器。并且1.1还支持了请求部分内容，如果当前客户端已经有一部分资源了，只需要向服务器请求另外的部分资源即可，这也是支持文件断点续传的基础
(5)增加了host处理，在HTTP1.0中认为每台服务器都绑定一个唯一的ip地址，因此在URL中并没有传递主机名，但是随着虚拟机技术的发展，可能在一台物理机器上存在多个虚拟主机，并且他们共享了一个ip地址，http1.1中请求消息和响应消息都支持host头域，如果不存在还会报出错误

2.0版本
(1)支持多路复用，同一个连接可以并发处理多个请求，方法是把 HTTP数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP请求顺序到达；
(2)支持服务端推送，就是服务端在 HTTP 请求到达后，除了返回数据之外，还推送了额外的内容给客户端；
(3)压缩了请求头，同时基本单位是二进制帧流，这样的数据占用空间更少；
(4)适用于 HTTPS 场景，因为其在 HTTP和 TCP 中间加了一层 SSL 层。

二、HTTP协议再相知

1.HTTP协议特点

(1)支持客户/服务器模式。
(2)是基于TCP/IP协议之上的应用层协议。
(3)简单快速：由于客户向服务器请求服务时，只需传送请求方法和路径，因而简单。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
(4)无连接：早期的HTTP版本限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。
(5)无状态：协议本身并不保留之前一切的请求或响应报文的信息。

2.URI，URL，URN

URI : 统一资源标志符
URL: 统一资源定位符
URN: 统一资源名称
这是一个URI：
http://bitpoetry.io/posts/hello.html#intro
我们开始分析
http://
是定义如何访问资源的方式。另外
bitpoetry.io/posts/hello.html
是资源存放的位置，那么，在这个例子中，
#intro
是资源。
URL是URI的一个子集，告诉我们访问网络位置的方式。在我们的例子中，URL应该如下所示：
http://bitpoetry.io/posts/hello.html
URN是URI的子集，包括名字(给定的命名空间内)，但是不包括访问方式，如下所示：
bitpoetry.io/posts/hello.html#intro
参照博文如下：（个人感觉比较容易理解）
https://blog.youkuaiyun.com/f45056231p/article/details/82530984
辨析：
URL(类似住址)是URI的一种，但不是所有的URI都是URL。
URI和URL的最大区别是访问机制。
URN是唯一标识的一部分，是身份信息。(类似人名)。

3.HTTP报文结构

在这里插入图片描述

4.常见方法

GET：用于请求访问已经被URI识别的资源
POST【不幂等】：主要功能与GET方法类似，但一般推荐使用POST方式。
HEAD：与GET方法类似，用于获取响应头。可以验证URI是否有效。

PUT【幂等】：传输文件，报文主体中包含文件内容，保存到对应URI位置。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。

OPTIONS：查询相应URI支持的HTTP方法。

重要：get和post方法的区别

GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中，所以可以狭义的理解为POST比GET安全。不能因为 POST 参数存储在实体主体中就认为它的安全性更高，因为照样可以通过一些抓包工具（Fiddler）查看。
GET 的参数只支持 ASCII 码，如果存在中文等字符就需要先进行编码。。POST 的参数支持标准字符集。
GET传送的数据量较小，这主要是受URL长度的限制；POST传送的数据量较大，可以被默认为不受限制。
GET是幂等的，PUT不是幂等的。同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。换句话说就是，幂等方法不应该具有副作用（统计用途除外）。【******】
请求报文的GET方法本身是可以缓存的，PUT方法不可以。
GET会产生一个TCP数据包，POST会产生两个TCP数据包。
GET会发送http header和data给服务端，服务端返回一个200，请求成功。
POST会先发送http header给服务端，告诉服务端等一下会有数据过来，服务端返回100，告诉客户端我已经准备接收数据，POST在发送一个data给服务端，服务端返回200，请求成功。

5.常见状态码

在这里插入图片描述
1XX 信息

100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX 成功

200 ：OK
202 ：供处理的请求已被接受，但是处理未完成。

3XX 重定向

301：永久性重定向；永久移动。请求的资源已经被永久的移动到新的URI，返回信息会包含新的URI，浏览器会自动定向到新的URI。今后任何新的请求都应使用新的URI代替。
302 ：临时性重定向；临时移动。资源只是临时被移动，客户端应继续使用原有URI。

4XX 客户端错误

400 ：请求报文中存在语法错误。
403 ：服务器理解客户端请求，但是拒绝执行该请求。
404 ：服务器无法根据客户端请求找到对应资源。

5XX 服务器错误

500 ：服务器内部错误。

6.Cookie和Session

6.1Cookie

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。**

------------------------创建过程如下------------------------

服务器发送的响应报文包含 Set-Cookie 首部字段，客户端得到响应报文后把 Cookie 内容保存到浏览器中。

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry
[page content]

客户端之后对同一个服务器发送请求时，会从浏览器中取出 Cookie 信息并通过 Cookie 请求首部字段发送给服务器。

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

分类
会话期 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。
持久性 Cookie：指定过期时间（Expires）或有效期（max-age）之后就成为了持久性的 Cookie。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

用途
会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）

6.2Session

除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。
Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。
------------------------创建过程如下------------------------

用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

应该注意 ：Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

6.3Cookie 与 Session 选择

Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；
对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。

7.HTTPS 的工作过程

客户端发送自己支持的加密规则给服务器，代表告诉服务器要进行连接了；
服务器从中选出一套加密算法和 hash 算法以及自己的身份信息（地址等）以证书的形式发送给浏览器，证书中包含服务器信息，加密公钥，证书的办法机构；
客户端收到网站的证书之后要做下面的事情：

3.1 验证证书的合法性；

3.2 果验证通过证书，浏览器会生成一串随机数，并用证书中的公钥进行加密；

3.3 用约定好的 hash 算法计算握手消息，然后用生成的密钥进行加密，然后一起发送给服务器。
服务器接收到客户端传送来的信息，要做下面的事情：

4.1 用私钥解析出密码，用密码解析握手消息，验证 hash 值是否和浏览器发来的一致；

4.2 使用密钥加密消息；
如果计算法 hash 值一致，握手成功。

8、HTTP 和 HTTPS 的区别？

开销：HTTPS 协议需要到 CA 申请证书，一般免费证书很少，需要交费；
资源消耗：HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 ssl 加密传输协议，需要消耗更多的 CPU 和内存资源；
端口不同：HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443；
安全性：HTTP 的连接很简单，是无状态的；HTTPS 协议是由 TSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

9、HTTPS 的优缺点？

优点：

使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性；
HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：

HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电；
HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；
SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；
HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

10、什么是数字签名？

为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

11、什么是数字证书？

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的。

12、什么是对称加密和非对称加密？

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方。

非对称加密指使用一对非对称密钥，即：公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性。但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。