HTTP 协议与原理分析之二

忘是亡心i 2023-02-15 10:07 40阅读 0赞

#### 一、CORS 跨域 ####

1.  `CORS` 是一个 `W3C` 标准，全称是"跨域资源共享"。它允许浏览器向跨源服务器，发出 `XMLHttpRequest` 请求，从而克服了 `AJAX` 只能同源使用的限制。`CORS` 需要浏览器和服务器同时支持，分为简单请求和复杂请求。
2.  跨域的允许方法有 `GET`、`HEAD`、`POST` 等等。
3.  允许 `Content-Type`，三种类型，`text/plain`、`multipart/form-data`、`application/x-www-form-urlencoded`。
4.  其它限制，请求头限制，`XMLHttpRequestUpload` 对象均没有注册任何事件监听器，请求中没有使用 `ReadableStream` 对象。
5.  如果跨域请求要想操作 `cookie`，需要满足 `3` 个条件：

*  服务的响应头中需要携带`Access-Control-Allow-Credentials` 并且为 `true`
 *  浏览器发起 `ajax` 需要指定 `withCredentials` 为 `true`
 *  响应头中的 `Access-Control-Allow-Origin` 一定不能为 `*`，必须是指定的域名

1.  进行简单请求时，需要在服务端带上 `Access-Control-Allow-Origin` 的响应头。复杂请求会先发送一个预请求，该请求以 `OPTIONS` 方法发起，预请求会对服务器进行检测，以获取服务器是否允许该请求，预请求可以避免跨域请求对服务器产生的未知影响。
2.  `cors` 跨域的实现，代码如下所示：

*  **index.html**
    
        <!DOCTYPE html>
        <html lang="en">
        <head>
          <meta charset="UTF-8">
          <meta name="viewport" content="width=device-width, initial-scale=1.0">
          <meta http-equiv="X-UA-Compatible" content="ie=edge">
          <title>Document</title>
        </head>
        <body>
            
        </body>
        
        
        <script> fetch('http://localhost:8887', { method: 'POST', headers: { 'X-Test-Cors': '123' } }) </script>
        </html>
 *  **server1.js**
    
        const http = require('http')
        const fs = require('fs')
        
        http.createServer(function (request, response) { 
          console.log('request come', request.url)
        
          const html = fs.readFileSync('test.html', 'utf8')
          response.writeHead(200, { 
            'Content-Type': 'text/html'
          })
          response.end(html)
        }).listen(8888)
        
        console.log('server listening on 8888')
 *  **server2.js**
    
        const http = require('http')
        
        http.createServer(function (request, response) { 
          console.log('request come', request.url)
        
          response.writeHead(200, { 
            'Access-Control-Allow-Origin': 'http://127.0.0.1:8888',
            'Access-Control-Allow-Headers': 'X-Test-Cors',
            'Access-Control-Allow-Methods': 'POST, PUT, DELETE',
            'Access-Control-Max-Age': '1000'
          })
          response.end('123')
        }).listen(8887)
        
        console.log('server listening on 8887')

#### 二、Cache-Control 缓存 ####

1.  可缓存性，包括 `public`、`private`、`no-cache` 等等。可缓存性指 `http` 的 `response` 进过的哪些地方可以进行缓存。`public` 指在 `response` 返回经过的任何地方都可以缓存，包括代理服务器，客户端等，这样下次请求将不会到达服务端而直接返回`response`；`private`则表示只有返回的浏览器才可以进行缓存；`no-cache`则表示不可直接用缓存，而是先要到服务器端进行验证。
2.  到期，`max-age=<seconds>`、`s-maxage=<seconds>`、`max-stale=<seconds>`。`max-age=<seconds>`，代表缓存的时间(秒)；`s-maxage=<seconds>`,专门为代理服务器设置，如果与`max-age` 同时返回，则浏览器会读取`max-age`，而代理服务器则会读取`s-maxage` 这个设置；`max-stale=<seconds>`，代表在 `max-age` 过期后，如果存在`max-stale`，而且其时间没有过期，则表示仍然可以用缓存，`max-stale`只在 `request` 发起端设置是有用的，又因为浏览器不会帮助我们带上这个头，所以客户端是浏览器的时候这个`max-stale`是用不到的。
3.  重新验证，`must-revalidate`、`proxy-revalidate`。这两个表示缓存过期时间到达以后，必须要到服务端重新请求和重新验证，这两个属性在浏览器也不怎么出现。
4.  其它，`no-store`、`no-transfrom`。`no-store`，表示本地和代理服务器都不可以用缓存，必须去重新获取；`no-transform`，告诉代理服务器不要对返回的`body`进行处理，比如压缩等（代理服务器比如`nginx`等可以不遵守，但是这个是规范，最好遵守）。
5.  `Expires` 是以前用来控制缓存的`http` 头，`Cache-Control` 是新版的`API`，现在首选 `Cache-Control`。如果在`Cache-Control`响应头设置了 `"max-age"` 或者 `"s-max-age"` 指令，那么 `Expires` 头会被忽略。
6.  `Cache-Control` 缓存的实现，代码如下所示：

#### 三、资源验证 ####

1.  浏览器查找缓存的过程：当浏览器有 `Cache-Control` 缓存的时候，就可以去创建请求去查找缓存。浏览器会先向本地缓存中去查找，如果命中，就直接返回给浏览器。如果未命中，就会先向代理缓存中查找，如果命中，就获取，然后本地缓存，再返回会浏览器。如果代理缓存未命中，就会向源服务器中进行查找缓存。注意的是，缓存头`Cache-Control`只能在服务端设置，在客户端是由浏览器设置的，自己不能修改它的值。
2.  `Last-Modified`，上次修改时间，配合 `If-Modified-Since` 或者 `If-Unmodified-Since` 使用，对比上次修改时间以验证资源是否需要更新。
3.  `Etag`，数据签名，配合`If-Match` 或者 `If-Non-Match` 使用，对比资源的签名判断是否使用缓存。
4.  为了配合`Cache-Control`中`no-cache`，在`server`端我们还需要加上头`Last-Modified`、`Etag`。收到带`Last-Modified`这个头，下次浏览器发送`request`就会带上`If-Modified-Since`或者`If-Unmodified-Since`，服务器收到这个`request`的`If-Modified-Since`后，通过读取它的值对比资源存在的地方的`Last-Modified`，服务器就告诉浏览器是否可以使用缓存。
5.  `Etag`是一个更加严格的验证，它是根据文件的内容生成`Etag`（数据签名，最常用做法是对资源内容进行哈希计算），收到带`Etag`这个头，下次浏览器发送`request`就会带上`If-Match`或者`If-Non-Match`，服务器收到这个`request`的上`If-Match`或者`If-Non-Match`后，通过读取它的值对比资源存在的地方的`Etag`，服务器就告诉浏览器是否可以使用缓存。
6.  如果单独使用`max-age`，在缓存有效的时间内浏览器对相同的资源发起请求是得不到更新的、为了解决这个问题，可以在每次编译时给静态文件设置`hash`值，这样，在浏览器再次对静态资源发起请求时，资源的名称已经修改了，浏览器不会认为是同一资源，也就不会去缓存中寻找，直接去源服务器中获取。
7.  如果设置了`no-cache`，在缓存有效的时间内，浏览器对相同的资源发起请求时，会先去服务器询问资源是否修改过，资源没有修改时，响应`304 Not Modified`，浏览器得到`304`响应后，判断缓存可以使用，就会直接使用缓存。如果资源更新过，就返回`200`，浏览器使用返回的资源。
8.  当设置了`no-cache`时，需要有一种验证机制来判断资源是否更新过：

*  `Last-Modified`配合`If-Modified-Since`或者`If-Unmodified-since`使用：对比上次修改时间来验证是否使用缓存。步骤是：`client`第一次对资源发起请求时，`server`会设置`Last-Modified`的头信息，当浏览器再次对相同的资源发起请求时，浏览器会设置`request`的头部(`chrome`可以使用`disable cache`来禁止浏览器自动设置，这样每次都会去源服务器获取)，设置`If-Modified-Since`或者`If-Unmodified-since`的值为之前接收到的`Last-Modified`的值，这样，`server`每次取得头部信息`If-Modified-Since`或者`If-Unmodified-since`，与文件的修改时间进行对比，如果相同，就返回`304Not Modified`，`client`使用缓存，如果不相同，就返回更新后的资源。
 *  `Etag` 数字签名配合`If-Match`或者`If-None-Match`使用：一般的数字签名可以对资源的内容进行`hash`计算，`client`第一次请求资源时，在`server`中设置头部信息`Etag`，值为`hash`值，当浏览器再次对相同的资源发起请求时，浏览器会设置`request`的头部，设置`If-Match`或者`If-None-Match`的值为之前接收到的`Etag`的值，这样，`server`每次取得头部信息`If-Match`或者`If-None-match`，与重新计算的`hash`值进行对比，如果相同，就返回`304Not Modified`，`client`使用缓存，如果不相同，就返回更新后的资源。

1.  资源验证的代码，如下所示：

*  **index.html**
    
        <!DOCTYPE html>
        <html lang="en">
        <head>
          <meta charset="UTF-8">
          <meta name="viewport" content="width=device-width, initial-scale=1.0">
          <meta http-equiv="X-UA-Compatible" content="ie=edge">
          <title>Document</title>
        </head>
        <body>
            
        </body>
        <script src="/script.js"></script>
        </html>
 *  **server.js**
    
        const http = require('http')
        const fs = require('fs')
        
        http.createServer(function (request, response) { 
          console.log('request come', request.url)
        
          if (request.url === '/') { 
            const html = fs.readFileSync('test.html', 'utf8')
            response.writeHead(200, { 
              'Content-Type': 'text/html'
            })
            response.end(html)
          }
        
          if (request.url === '/script.js') { 
            
            const etag = request.headers['if-none-match']
            if (etag === '777') { 
              response.writeHead(304, { 
                'Content-Type': 'text/javascript',
                'Cache-Control': 'max-age=2000000, no-cache',
                'Last-Modified': '123',
                'Etag': '777'
              })
              response.end()
            } else { 
              response.writeHead(200, { 
                'Content-Type': 'text/javascript',
                'Cache-Control': 'max-age=2000000, no-cache',
                'Last-Modified': '123',
                'Etag': '777'
              })
              response.end('console.log("script loaded twice")')
            }
          }
        }).listen(8888)
        
        console.log('server listening on 8888')

#### 四、Cookie 和 Session ####

1.  `Cookie`，通过 `Set-Cookie` 设置，下次请求会自动带上，键值对，可以设置多个。
2.  `Cookie` 属性，`max-age` 和 `expires` 设置过期时间，`Secure` 只在 `https` 的时候发送，`HttpOnly` 无法通过 `document.cookie` 访问。
3.  `cookie`是服务端通过`Set-Cookie`设置到浏览器中，浏览器保存这个值后，下次在同域的请求时就会自动带上这个`cookie`，存储形式是键值对。比如一个会话中，保存了用户的登录信息和登录状态，有助于服务端读取，并且返回正确的内容。
4.  `Session`是另一种记录客户状态的机制，不同的是`Cookie`保存在客户端浏览器中，而`Session`保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是`Session`。客户端浏览器再次访问时只需要从该`Session`中查找该客户的状态就可以了。
5.  `Session`保存在服务器端。为了获得更高的存取速度，服务器一般把`Session`放在内存里。每个用户都会有一个独立的`Session`。如果`Session`内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，`Session`里的信息应该尽量精简。`Session`生成后，只要用户继续访问，服务器就会更新`Session`的最后访问时间，并维护该`Session`。用户每访问服务器一次，无论是否读写`Session`，服务器都认为该用户的`Session`“活跃（`active`）”了一次。
6.  为防止内存溢出，服务器会把长时间内没有活跃的`Session`从内存删除。这个时间就是`Session`的超时时间。如果超过了超时时间没访问过服务器，`Session`就自动失效了。
7.  `Cookie` 和 `Session` 的代码，如下所示：

#### 五、HTTP 长连接 ####

1.  `HTTP`协议中只有请求和响应的概念，发起请求和返回响应是通过`TCP Connection`来完成的。
2.  在`HTTP1.1`以前，默认情况下，在发起请求得到响应之后，会关闭`TCP Connection`，有新的`HTTP`请求发起时，会重新建立`TCP Connection`。建立`TCP Connection`时需要`3`次握手，耗费的时间还是比较多的，每次`HTTP`请求都需要重新建立`TCP Connection`，会降低性能。
3.  在`HTTP1.1`中，在结束一次`HTTP`请求后，是默认保持`TCP Connection`的，当有新的`HTTP`请求发起时，会直接使用之前保持的`TCP Connection`。这样，就节省了建立`TCP Connection`的时间，提高了性能。不过，在`client`和`server`中维持`TCP Connection`也是有损耗的，但是这和频繁建立`TCP Connection`的损耗比起来还是小很多的。
4.  在`HTTP1.1`中默认开启长连接的，会在`Requset head`中设置`Connection`值为`Keep-Alive`，同时，返回的`Request Head`中也会设置`Connection`值为`Keep-Alive`。如果要在`HTTP1.1`之前的`HTTP`版本中使用长连接，需要手动设置`Request Head`和`Response Head`的`Connection`为`Keep-Alive`。如果要关闭长连接，可以设置`Connection`为`close`。
5.  `HTTP1.1`中的`TCP Connection`中同时只能有一个`HTTP`请求，所以如果有多个`HTTP`请求需要使用同一个`TCP Connection`就需要等待。这样的`HTTP`请求只能是串行的。可以同时建立多个`TCP Connection`，这样，就可以变相的使得`HTTP`并行处理。不过，浏览器对同时建立`TCP Connection`的数量进行了限制，在`chrome`同时只能建立`6`个`TCP Connection`，如果同时有超过`6`个`HTTP`请求发起，余下的`HTTP`请求还是要等待有`TCP Connection`空余出来后才能发送。
6.  在`HTTP1.1`中，数据通常是以字符串的形式传输的，字符串是没有上下文的概念，所以如果在`TCP Connection`中实现`HTTP` 并发执行，不能保证哪个`HTTP`先到达`Server`，会造成数据错误。在`HTTP2.0`中，数据改为以二进制传输的，它是分帧传输，会有上下文的概念。这时，就可以在同一个`TCP Connection`中并发的发起`HTTP`请求，而不需要担心到达`Server`的先后顺序不一致导致数据错误，因为`server`可以根据传输过来的帧的上下文进行重新的组合，得到正确的数据。
7.  只有同一域的`HTTP`请求才能使用建立好的长连接，不同域的`http`请求一定会重新建立一个`TCP Connection`。
8.  `HTTP` 长连接的代码，如下所示：

*  **index.html**
    
        <!DOCTYPE html>
        <html lang="en">
        <head>
          <meta charset="UTF-8">
          <meta name="viewport" content="width=device-width, initial-scale=1.0">
          <meta http-equiv="X-UA-Compatible" content="ie=edge">
          <title>Document</title>
        </head>
        <body>
          <img src="/test1.jpg" alt="">
          <img src="/test2.jpg" alt="">
          <img src="/test3.jpg" alt="">
          <img src="/test4.jpg" alt="">
          <img src="/test5.jpg" alt="">
          <img src="/test6.jpg" alt="">
          <img src="/test7.jpg" alt="">
          <img src="/test11.jpg" alt="">
          <img src="/test12.jpg" alt="">
          <img src="/test13.jpg" alt="">
          <img src="/test14.jpg" alt="">
          <img src="/test15.jpg" alt="">
          <img src="/test16.jpg" alt="">
          <img src="/test17.jpg" alt="">
          <img src="/test111.jpg" alt="">
          <img src="/test112.jpg" alt="">
          <img src="/test113.jpg" alt="">
          <img src="/test114.jpg" alt="">
          <img src="/test115.jpg" alt="">
          <img src="/test116.jpg" alt="">
          <img src="/test117.jpg" alt="">
        </body>
        </html>
 *  **server.js**
    
        const http = require('http')
        const fs = require('fs')
        
        http.createServer(function (request, response) { 
          console.log('request come', request.url)
        
          const html = fs.readFileSync('test.html', 'utf8')
          const img = fs.readFileSync('test.jpg')
          if (request.url === '/') { 
            response.writeHead(200, { 
              'Content-Type': 'text/html',
            })
            response.end(html)
          } else { 
            response.writeHead(200, { 
              'Content-Type': 'image/jpg',
              'Connection': 'keep-alive' // or close
            })
            response.end(img)
          }
        
        }).listen(8888)
        
        console.log('server listening on 8888')

#### 六、数据协商 ####

1.  数据协商：客户端在发送给服务端一个请求的时候，客户端会申明我需要拿到的数据格式和相关限制，服务端会根据请求的表示和所需拿到的数据，会进行判断，返回不同类型的数据给客户端。
2.  `Accept`，客户端声明想要的数据格式，包括 `Accept`、`Accept-Encoding`、`Accept-Language`、`User-Agent`。`Accept:`指定我想要的数据类型，`Accept-Encoding`：代表数据以什么编码的方式来实现传输。`Accept-Language`:希望获得的语言，用什么语言来展示。`User-Agent`:用来判定是`PC`端还是`Mac`还是移动端等，从而返回不同的信息。
3.  `Content`，服务端返回的数据，包括 `Content-Type`、`Content-Encoding`、`Content-Lanuage`。`Content-Type`:对应`Accept`，从`Accept`中选取一种数据格式，来说明实际返回的数据格式。`Content-Encoding`:对应`Accept-Encoding`，来说明选择哪一种数据格式进行压缩。`Content-Language`:对应`Accept-Language`，来说明我是根据你希望的语言进行返回，还是没有根据你要求的语言进行返回。服务端返回没有对应的`User-Agent`了，因为`User-Agent`本来就是由客户端决定我当前用的哪一种刘浏览器，哪一种系统环境当中的，不需要协商。
4.  分类中包含，请求和返回两种。请求中用`Accept`来声明，我想要什么数据。与`Accept`对应的是服务端返回的内容，对应的字段是`Content`。
5.  数据协商的代码，如下所示：

*  **index.html**
    
        <!DOCTYPE html>
        <html lang="en">
        <head>
          <meta charset="UTF-8">
          <meta name="viewport" content="width=device-width, initial-scale=1.0">
          <meta http-equiv="X-UA-Compatible" content="ie=edge">
          <title>Document</title>
        </head>
        <body>
          <form action="/form" id="form" enctype="application/x-www-form-urlencoded">
            <input type="text" name="name">
            <input type="password" name="password">
            <input type="file" name="file">
            <input type="submit">
          </form>
          <script> var form = document.getElementById('form') form.addEventListener('submit', function (e) { e.preventDefault() var formData = new FormData(form) fetch('/form', { method: 'POST', body: formData }) }) </script>
        </body>
        </html>
 *  **server.js**
    
        const http = require('http')
        const fs = require('fs')
        const zlib = require('zlib')
        
        http.createServer(function (request, response) { 
          console.log('request come', request.url)
        
          const html = fs.readFileSync('test.html')
          response.writeHead(200, { 
            'Content-Type': 'text/html',
            // 'X-Content-Options': 'nosniff'
            'Content-Encoding': 'gzip'
          })
          response.end(zlib.gzipSync(html))
        }).listen(8888)
        
        console.log('server listening on 8888')

#### 七、Redirect 重定向 ####

1.  重定向的流程：浏览器首先访问服务器`A`的`URL`，服务器A返回带着`location`为`B`的`URL`的 `header`和`3XX`的状态码，浏览器读取响应的`3XX`状态码，获取到头部的 `location`，然后跳转到服务器`B`的`URL`。需要注意的是，跳转是浏览器发起的。如果服务器给一个非浏览器的终端返回了`3XX`的状态码，那有可能是无法完成重定向的。
2.  永久重定向：表示资源永久性的跳转到新的`URL`。一个比较常见的案例就是老站迁移到新站，老站直接关闭后，老站的页面已经被搜索引擎收录了，这个时候使用永久重定向方案。永久重定向两个状态码，`301`，重定向请求通常会使用`GET`方法，不管原请求使用的是何种方法。`308`，为了补充`301`.重定向必须使用原请求的方法和包体访问。
3.  临时重定向：表示资源只是临时跳转到新的`URL`，临时重定向一共有五个状态码，如下所示：

*  `302`，重定向请求通常会使用`GET`方法，不管原请求使用的是何种方法。
 *  `303`，并不表示资源变更，只是表示用新的`URL`的响应代替原请求。不管原请求使用的是何种方法。基本跟`302`一致，所以市面很少用`303`，都是使用`302`。
 *  `307`，为了补充`302`.重定向必须使用原请求的方法和包体访问。
 *  `300`，该请求有多种可能的响应，浏览器可以选择它们其中的一个。服务器没有任何标准可以遵循去代替用户来进行选择。
 *  `304`，告诉浏览器，所请求的内容距离上次访问并没有变化。 可以直接从浏览器缓存里获取该资源。

1.  `Redirect` 重定向的代码，如下所示：

*  **server.js**
    
        const http = require('http')
        
        http.createServer(function (request, response) { 
          console.log('request come', request.url)
        
          if (request.url === '/') { 
            response.writeHead(302, {   // or 301
              'Location': '/new'
            })
            response.end()
          }
          if (request.url === '/new') { 
            response.writeHead(200, { 
              'Content-Type': 'text/html',
            })
            response.end('<div>this is content</div>')
          }
        }).listen(8888)
        
        console.log('server listening on 8888')

#### 八、CSP ####

1.  `CSP`，全称为 `Cryptographic Service Provider`，内容安全策略。
2.  `CSP` 的作用是限制资源获取，报告资源获取越权。它的限制方式有 `default-src` 限制全局，制定资源类型。
3.  `CSP` 的资源类型，`connect-src`、`img-src`、`font-src`、`script-src`、`frame-src`、`style-src`、`manifest-src`等等。
4.  `CSP` 的代码，如下所示：

*  **index.html**
    
        <!DOCTYPE html>
        <html lang="en">
        <head>
          <meta charset="UTF-8">
          <meta name="viewport" content="width=device-width, initial-scale=1.0">
          <meta http-equiv="X-UA-Compatible" content="ie=edge">
          <meta http-equiv="Content-Security-Policy" content="script-src 'self'; form-action 'self';">
          <title>Document</title>
        </head>
        <body>
          <div>This is content</div>
          <script> console.log('inline js') </script>
          <script src="test.js"></script>
          <script src="https://cdn.bootcss.com/jquery/3.3.1/core.js"></script>
        </body>
        </html>
 *  **server.js**
    
        const http = require('http')
        const fs = require('fs')
        
        http.createServer(function (request, response) { 
          console.log('request come', request.url)
        
          if (request.url === '/') { 
            const html = fs.readFileSync('test.html', 'utf8')
            response.writeHead(200, { 
              'Content-Type': 'text/html',
              // 'Content-Security-Policy': 'script-src \'self\'; form-action \'self\'; report-uri /report'
            })
            response.end(html)
          } else { 
            response.writeHead(200, { 
              'Content-Type': 'application/javascript'
            })
            response.end('console.log("loaded script")')
          }
        }).listen(8888)
        
        console.log('server listening on 8888')