HTTP工作原理探究（一），node+ts实现mini browser

小伙伴找我说前端岗位面试被问到“输入URL回车之后都发生了什么”，虽然之前有所准备，但却没有经得住面试官连番追问，最终败下阵来。她问我怎么解，那必须整的明明白白，这就自己动手整一个mini版浏览器实现，下次必须跟面试官谈笑风生！

创建服务端

开发环境准备

我们准备赶时髦用​​typescript​​​写代码，因此需要安装​​ts​​​、​​ts-node​​​和​​node类型声明​​

npm i typescript ts-node @types/node -D

以下是我这里安装的结果，小伙伴们确认一下版本：

{
  "devDependencies": {
    "@types/node": "^15.12.2",
    "ts-node": "^10.0.0",
    "typescript": "^4.3.5"
  }
}

准备一个启动命令，​​package.json​​

{
  "scripts": {
   "serve": "ts-node-dev server.ts"
  }, 
}

编写http服务代码

我们的服务器只需要返回一个​​hello world​​即可：

import { createServer } from "http";

const server = createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader("Content-Type", "text/html");
  res.end('<h1>hello world</h1>')
})

server.listen(8080)

这里有如下几个步骤：

1. 使用​​createServer(requestListener)​​创建一个Server实例
2. 调用​​server.listen(port)​​监听指定端口
3. ​​requestListener​​​中设置响应状态码​​res.statusCode = 200​​
4. 并添加一个响应头​​res.setHeader("Content-Type", "text/html")​​
5. 最后通过返回内容：​​res.end(chunk)​​

相关API参考：http

启动服务

执行​​serve​​命令启动服务

npm run serve

打开浏览器，请求​​http://localhost:8080​​验证一下：

验证

敲黑板

我们前面创建了一个​​http server​​，它接收到客户端请求后，会做出响应。

img

​​响应报文​​其实是一段文本，它的格式如下：

起始行 (start line)
头信息 (headers)

主体(entity body)

起始行只有一行，它包含了最重要的响应信息：​​协议版本​​​、​​状态码​​​和​​状态描述​​​，我们代码中设置了状态码为​​200​​​表示请求成功：​​res.statusCode = 200​​，其它常见的状态码还有:

• 302，重新定向(redirect)：我这里没有你想要的资源，但我知道另一个地方有，你可以去那里找。
• 404，无法找到(not found)：我找不到你想要的资源，无能为力。

完整的状态码列表详见这里。

头信息可以有多行，每一行是一对键值对，比如：​​Content-type: text/html​​​，就是我们在代码中设置的：​​res.setHeader("Content-Type", "text/html")​​​，​​Content-Type​​表示主体所包含资源的类型MIME，根据类型不同，客户端可以启动不同处理程序(比如显示图像，播放声音等)。下面是一些常见的资源：

• ​​text/plain​​ 普通文本
• ​​text/html​​ HTML文本
• ​​image/jpeg​​ jpeg图片
• ​​image/gif​​ gif图片
• application/json json数据

响应的主体部分是返回给客户端的内容，我们代码中返回了一段​​html​​​文本，它被放在主体(entity body)中：​​res.end('<h1>hello</h1>')​​

最后看看浏览器里面的响应长啥样：

所以最终我们的响应大概是这样一段文本：

HTTP/1.1 200 OK
Content-Type: text/html
Date: Mon, 05 Jul 2021 12:29:27 GMT
Connection: keep-alive
Content-Length: 14

<h1>hello</h1>

编写基于tcp的服务代码

小伙伴们get到了没有？下面我们来实践一下：使用更加底层的​​net​​包实现http服务。

import { createServer } from "net";

const server = createServer(function (client) {
  console.log("client comming", client.remoteAddress, client.remotePort);

  client.on("data", function (data) {
    console.log(data.toString());
    client.write(`HTTP/1.1 200 OK\r
      Content-Type: text/html\r
      Date: Mon, 05 Jul 2021 12:29:27 GMT\r
      Connection: keep-alive\r
      Content-Length: 14\r\n
      <h1>hello</h1>`)
    client.end();
  });
  
  client.on("close", function () {
    console.log("close socket");
  });
});

server.listen(
  {
    port: 8080,
    host: "127.0.0.1",
  },
  () {
    console.log("start listening...");
  }
);

这里有如下步骤：

1. 创建一个​​net.Server​​监听客户端连接：​​createServer(connectionListener)​​
2. 监听IP​​127.0.0.1​​的​​8080​​端口：​​server.listen(options, listener)​​
3. 利用客户端​​Socket​​监听​​data​​事件：​​client.on("data", listner)​​
4. 利用客户端​​Socket​​监听​​close​​事件：​​client.on("data", listner)​​

敲黑板

​​net​​​包基于​​TCP​​​协议，所以我们传入的​​connectionListener​​​会传入一个代表客户端的​​net.Socket​​​实例。代码中的​​client​​​就是这个连接的​​Socket​​实例，连接配对过程和断开过程就有大家耳熟能详的三次握手、四次挥手：

过程解读：

首先Client端发送连接请求报文SYN，Server端接受连接后回复确认报文ACK，并为这次连接分配资源。Client端接收到ACK报文后也向Server端发送确认连接报文ACK，并分配资源，这样TCP连接就建立了。

为什么是三次握手而不是两次或四次？

为了防止已失效的连接的请求报文突然又传送到了服务端而产生错误。client发出的第一个连接请求报文并没有丢失，而是在某个网络结点长时间滞留，以致延误到连接释放以后才到达server。本来这是一个早已失效的报文。但server收到此失效的连接请求报文后，误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。

连接建立之后客户端开始传输数据，代码​​client.on("data", function (data) {})​​​中的​​data​​​就是​​请求报文​​​，包含了客户端各种诉求。我们可以解读请求内容，并按要求返回​​响应报文​​：

client.write(`HTTP/1.1 200 OK\r
      Content-Type: text/html\r
      Date: Mon, 05 Jul 2021 12:29:27 GMT\r
      Connection: keep-alive\r
      Content-Length: 14\r\n
      <h1>hello</h1>`)

随后我们关闭了连接：​​client.end()​​​，关闭内部过程就是大家熟知的​​四次挥手​​：