已经学习过自己定制一个协议了，现在就来看看当下广泛使用的http协议吧

1.介绍

超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

http和https是当下最通用的协议之一，我们访问的大部分网页用的都是这个协议；

1	https://www.bilibili.com/

这两个协议主要的差别，那就是http是用明文传输数据的，我们的数据在互联网裸奔，可能有安全问题；相比之下，https传输数据的过程会对数据进行加密，但这也不代表https是完全安全的。

1.1 url

要认识这两个协议，我们要从url的认识开始；

HTTP(S) 不允许使用用户名或密码，一个合法的 HTTP(S) URL 格式如下：

1	http(s)://<host>:<port>/<path>?<query>#<frag>

开头为协议名：http 或 https 协议；
<host>：主机名。一个 URL 中，既可以使用域名也可以使用 IP 表示主机地址
<port>：端口。主机名和端口之间使用冒号分隔。端口是可选的，如果省略将采用默认端口，http 默认端口是 80，https 默认端口 443；
<path>：资源路径。资源在网络主机上的路径，路径也是可选的，缺省访问默认资源；
<query>：查询参数。格式为 key=value，多个参数使用 & 分隔；参数也是可选的；
<frag>：片段。从 # 开始到最后，一般用于定位到资源内的一个片段，比如文档的一个章节；片段也是可选的。

1.1.1 栗子 ①

接下来举一个具体的例子

1	https://blog.musnow.top/2022/08/07/note_linux/6gdb_g++_make_vim/#4-make-x2F-makefile

如上是我的个人博客中的一篇文章

协议是https
域名是blog.musnow.top，对应的就是<host>:<port>；这里隐藏了端口，会在下面说明。
/2022/08/07/note_linux/6gdb_g++_make_vim/这一长串都是文件的路径，其标示了文件在服务器上存放的位置
这个url内没有带<query>参数
#4-make-x2F-makefile对应的是<frag>片段，标识了我当前浏览的位置

当你把这个url粘贴道浏览器，其会直接跳转到对应的标题位置，而不是这篇文章的页首；这就是<frag>片段的作用

1.1.2 栗子 ②

1	https://www.baidu.com/s?tn=68018901_39_oem_dg&ie=utf-8&word=test

当我们在百度搜索单词test的时候，百度的url中就会出现<query>参数；

其中?是参数的开头，后续的一串以&分隔的kv键值对，就是参数的内容。在这里面我们能看到word=test，我们查询的单词test就在这个参数后；

我们的搜索访问，就是将这些参数传送给服务器，再由百度的服务器返回搜素结果的。

1.2 域名和端口隐藏

但我们日常访问的网页中，很少见到过ip:端口的形式，而大多是用域名为我们提供服务的

1	https://www.bilibili.com/

这并不代表其背后不需要端口号。而是因为如果我们的访问不指定端口的时候，http(s)协议会采用默认端口号80或443，从而实现隐藏端口号提供服务

http 默认端口是 80，https 默认端口 443

毕竟对于用户而言，记住一个域名已经不容易了，还要记住你的服务是在哪一个端口，那就更难了；

而域名也不是凭空给我们提供服务的，每一个域名都需要绑定一个具体的公网ip（域名解析），才能为用户提供服务。在域名的背后，都是一个ip，每一个ip也就是一台服务器。

域名的作用，就是来隐藏掉ip这个无规律的长数字，方便用户访问；

你觉得是记住baidu.com容易，还是记住114.514.77.58容易呢？

在命令行使用ping工具，我们能知道一个网站服务器的ip是什么

1	ping www.bilibili.com

比如我们ping一下b站的域名，可以看到其公网ip是183.131.147.29

正在 Ping a.w.bilicdn1.com [183.131.147.29] 具有 32 字节的数据:
来自 183.131.147.29 的回复: 字节=32 时间=10ms TTL=55
来自 183.131.147.29 的回复: 字节=32 时间=12ms TTL=55
来自 183.131.147.29 的回复: 字节=32 时间=12ms TTL=55
来自 183.131.147.29 的回复: 字节=32 时间=12ms TTL=55

183.131.147.29 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 10ms，最长 = 12ms，平均 = 11ms

1.3 ip:端口

我们可以用ip:端口来访问自己的服务（以下ip纯属虚构，如有撞车，纯属巧合）

1	114.514.77.58:8080

当我们把这个粘贴道浏览器，再复制粘贴出来的时候，我们会发现前面多了一个http

1	http://114.514.77.58:8080

这是因为当我们使用ip访问一个服务的时候，浏览器会默认采用http的协议去访问，所以在前面加了一个我们看不到的http://

1.4 协议作用

http协议的作用，就是向服务器申请特定的资源，再将资源拉取到本地进行展示or使用。

资源都是存在我们的服务器上的，当用户请求的时候，服务器必须要知道资源的路径，将其read打开读取，再write写给我们的客户端。

1	/2022/08/07/note_linux/6gdb_g++_make_vim/

所以http的请求中才会带上资源的路径，这是方便服务器进行资源文件的读取；同时，文件的路径也是对一个文件的唯一标识，在告诉服务器文件路径的同时，也保证了我们请求的文件的唯一性，不会出现二义性；

这时候又会出现一个问题，当我们访问网站的根目录的时候，没有提供文件的路径呀，那这时候，访问的什么文件呢？

1	https://www.baidu.com/

实际上，我们访问的是服务器根目录的index.html文件

1 2	https://www.baidu.com/ https://www.baidu.com/index.html

你可以试着打开这两个链接，其出现的页面是完全一致的；

类似于端口号隐藏，http协议也确定了当下使用的网页文件的命名为index.html，当我们访问一个网站的时候，就会默认访问根目录下的index.html文件（既然是默认的，那就可以直接隐藏）如果这个文件不存在，那就不会渲染出我们看到的网页！

1	index.html是用前端语言编写的网页代码

同理，当我们访问博客的时候，读取道的也不是目录，而是目录下的index.html文件

1	https://blog.musnow.top/2022/08/07/note_linux/6gdb_g++_make_vim/

我的博客使用的是hexo框架，其网页的源路径在github上开源了，可以帮助你理解url中的文件路径。

当前你看到的文件目录，就是博客服务的根目录。访问的博客首页，就是根目录下的index.html

用作示例的linux工具使用博客，也可以根据它的路径，找到index.html文件

1	/2022/08/07/note_linux/6gdb_g++_make_vim/

这便是http协议url中文件路径的作用！

这里的/根目录是服务端设置的，并不一定是（大概率不是）服务端linux服务器的根目录

hexo博客已更新为绝对数字路径，本文中演示的路径已经无法访问

1.5 编码解码

在url中，还会对一些特殊字符进行编解码，比如中文，和一些特殊的符号

1	https://blog.musnow.top/2022/08/07/note_linux/6gdb_g++_make_vim/#4-make-x2F-makefile

比如在作为示例的url中，这里出现了x2F，而原文中是4.make/makefile;这里的编码就是为了避免make/makefile被识别成路径的标识符，从而出现错误。

1	https://www.baidu.com/s?tn=68018901_39_oem_dg&ie=utf-8&word=%E4%BD%A0%E5%A5%BD

当url路径中有中文的时候，也会被转码成特定的格式

我们在浏览器上看到的依旧是中文，这是因为浏览器这段帮我们进行了解码

将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式

2.http协议请求格式

了解了http协议中的url网址，现在就可以进一步了解http协议的报头和报文了;

一个http request/response的基本格式如下

在请求中，客户端会提供自己的请求方法（GET/POST/PUT等等），并提供url来标识自己需要的文件路径；这个url可能是短链接（截取根目录之后的部分），也有可能是完整的链接。

随后，就会跟上一大堆的请求参数，注意，这里的请求参数并不是url中的<query>参数，而是http协议自身的请求参数。每一个请求参数都用了\r\n作为分隔，这和我们写的自定义协议中采用\t进行分割是相同的原理！

这几个部分中，请求的正文可以不带（为空）

2.1 读取多长？

为了让协议读取的时候，能够知道什么时候读取完毕了报头，http协议提供了一个\r\n的空行，读取道这个空行，就代表报头读取完毕了，剩下的内容都是报文。

而为了标识报文的长度，http协议会在发送的时候提供一个参数content-length，用于标识报文的长度。在读取完毕报头后，肯定是读取到了这个content-length参数的，也就知道后续应该继续读取多长，才能读完整个协议字段！

关于这部分的介绍，可以查看另外一篇博客 http协议content-length详解

2.2 响应的状态码

和我们进程的退出状态一样，http也表明了一部分响应的状态码，其中我们日常最常见到的，是404/403这两个状态码

http状态码-百度百科

状态码就是标识服务器提供的服务状态，告诉客户端它的请求是否成功了。如果状态码是200，代表请求是成功的。其余状态码会有各自的使用场景，比如404状态码，代表请求的资源不存在，所以才叫 404 not found!

3.实例

完整代码详见 Gitee

3.1 前端页面

由于本人并没有学习过前端语法，这里采用菜鸟教程提供的前端示例代码来演示

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>菜鸟教程(runoob.com)</title>
</head>
<body>

<h1>我的第一个标题</h1>
<p>我的第一个段落。</p>

</body>
</html>

我们日常所访问的网页都是这样的代码，经由浏览器进行渲染，再展示出来

3.2 服务端代码

由于http是基于tcp的，这里直接把之前写的tcpServer搬过来就能用！具体的代码解析请看注释，想必说的是很清楚的

#define CRLF "\r\n"
#define CRLF_LEN strlen(CRLF)
#define SPACE " "
#define SPACE_LEN strlen(SPACE)

#define HOME_PAGE "index.html" // 首页文件
#define ROOT_PATH "web" // 网址根目录地址

// 获取http请求中的路径
string getPath(string http_request)
{
    size_t pos = http_request.find(CRLF);//找到第一行的分隔符
    if(pos == string::npos) 
        return "";
    string request_line = http_request.substr(0, pos);//取出第一行
    //请求的第一行：GET /a/b/c http/1.0
    size_t first = request_line.find(SPACE);// 找到第一个空格
    if(pos == string::npos) 
        return "";
    size_t second = request_line.rfind(SPACE); // 从后往前找空格
    if(pos == string::npos) 
        return "";
    // 找到两个空格了，两个空格之间的就是请求的路径
    string path = request_line.substr(first+SPACE_LEN, second - (first+SPACE_LEN));
    // 对path进行判断，如果path是以/结尾的，则在path中追加index.html文件名
    if(path[path.size()-1] == '/') {
        path += HOME_PAGE; //加上被隐藏的index.html文件名
    }
    return path;
}
// 读取文件
string readFile(const string &recource)
{
    ifstream in(recource, ios::binary);
    if(!in.is_open()) //文件打开失败
    {
        return "404";
    }
    // 内容
    string content;
    string line;
    while(getline(in, line))
    {
        content += line;
    }
    in.close();
    return content;
}
void handlerHttpRequest(int sock)
{
    cout << "###########start#############" << endl;//打印一个分隔线
    char buffer[10240];
    ssize_t s = read(sock, buffer, sizeof(buffer));
    if(s > 0){
        cout << buffer << endl;
        cout << "###########end############" << endl;
    }
    string path = getPath(buffer);
    // 假设用户请求的是 /a/b 路径
    // 那么服务端处理的时候，就需要添加根目录位置和默认的文件名
    // <root>/a/b/index.html
    // 在本次用例中，根目录为 ./web文件夹，所以完整的文件路径应该是
    // ./web/a/b/index.html

    string resources = ROOT_PATH; // 根目录路径
    resources += path; // 文件路径
    logging(DEBUG,"[sockfd: %d] filePath: %s",sock,resources.c_str()); // 打印用作debug

    string html = readFile(resources);// 打开文件

    // 开始响应
    string response = "HTTP/1.0 200 OK\r\n";
    //如果readFile返回的是404，代表文件路径不存在
    if(strcmp(html.c_str(),"404")==0)
    {
        response = "HTTP/1.0 404 NOT FOUND\r\n";
    }
    // 追加后续字段
    response += "Content-Type: text/html\r\n";
    response += ("Content-Length: " + to_string(html.size()) + "\r\n");
    response += "\r\n";
    response += html;
    // 发送给用户
    send(sock, response.c_str(), response.size(), 0);
}

3.3 测试

启动服务器之前，请先打开你的云服务器防火墙中的对应端口；这里我绑定的是端口10000，在浏览器中用ip:端口的方式可以正常访问！

这里标识的不安全是因为我们没有采用带加密的https协议，这不是当下需要考虑的问题。不管他就可以了。

按F12打开开发者页面，可以看到下方出现了完整的html代码，我们成功提供了服务！

3.4 后端打印的报文

在服务器后端，我们看到其打印出来了一个基本的http请求，和上面说明的格式是一样的。这里简单的进行一部分说明：

GET：请求方式为获取数据
/：请求的是根路径
HTTP/1.1：使用的http协议版本
Connection：代表我们和服务器的链接方式，keep-alive代表保持连接
User-Agent：客户端信息，可以看到是windows系统、Chrome内核的浏览器（我是用的是edge浏览器）
Accept: 支持接收的信息类型
Aceept-Encoding: 对信息进行压缩
Accept-Language：支持的语言
Cookie：身份信息，后面会详细介绍

其中出现了一个空行，代表报文结束；

往下滑，会发现浏览器还发出了第二个请求，路径是/favicon.ico，这是默认的站点头像文件的命名。因为我们的html文件中没有写明站点头像的路径，所以浏览器就尝试请求默认的头像文件

但是，当前我们的站点根目录web下并没有该文件，应该返回一个404状态码。

请求中出现了一个新的参数Referer，代表是从当前网页请求头像的。相比之下，请求网页的报文中没有Referer参数

此时可以随便找个图片做头像，看看能不能加载出来；为了方便，我随便找了一张纯绿色的图片，并将其在线转换为ico，放入了站点的根目录。

重启服务器进程，刷新浏览器再次请求，可以看到成功出现了站点的头像；

3.5 常见参数表

4.请求方法

一般我们获取一个网页，用的都是GET方法。接下来用一个带按钮的表单创建请求，尝试向服务端发送<query>参数

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>菜鸟教程(runoob.com)</title>
</head>
<body>

<h1>我的第一个标题</h1>
<p>我的第一个段落。</p>

<form action="/a/index.html" method="get">
    Username: <input type="text" name="user"><br>
    Password: <input type="password" name="passwd"><br>
    <input type="submit" value="Submit">
</form>

</body>
</html>

4.1 GET

在method里面，我们指定了get方法，此时

<form action="/a/index.html" method="get">
    Username: <input type="text" name="user"><br>
    Password: <input type="password" name="passwd"><br>
    <input type="submit" value="Submit">
</form>

此时页面中出现了两个输入框，供我们输入密码，且密码会显示为****而不是明文

点击按钮，会跳转到一个404页面，这是因为我们的a/index.html路径并不支持参数请求，所以发送了404错误码

不过这不重要，我们看看后端打印的内容。其中参数是追加到url中，以明文传输过来的；正文部分为空，并没有携带参数

4.2 POST

将请求方法改成post，再次尝试

<form action="/a/index.html" method="post">
    Username: <input type="text" name="user"><br>
    Password: <input type="password" name="passwd"><br>
    <input type="submit" value="Submit">
</form>

这时候能正常显示出a/index.html页面，url中不再带有参数

此时查看后端中的信息，能看到请求方法变为POST，参数出现在了正文部分，而不是url中

4.3 GET/POST区别

这也是GET和POST方法的区别之一：

GET方法通过url传参
POST方法会将url参数提取出来，拼接到正文部分

由此能推出二者的安全性区别

GET方法相对不安全，因为参数直接以明文贴在了url上
POST方法以正文传参，使用https协议的时候能进行加密，相对较安全

4.4 更多方法

http请求还支持更多方法，如下

5.状态码

5.1 状态码表

下面是一个响应状态码的总表

5.2 404/403状态码

我们能看到404和403都是客户端状态码，为什么说是客户端错误呢？这是因为你向服务器请求了一个服务器没有的资源，这个问题不应该是服务器的问题。

这就好比你去西瓜摊买肉，人家压根不卖肉。问题出在你身上，你不应该找西瓜摊老板买肉。所以404状态码，应该是客户端的问题！

而403状态码的含义是403 forbidden，服务器拒绝了你的请求（你没有权限访问）这也是客户端的问题。你不能去超市买东西，然后问老板能不能让你看看老板的钱罐子。老板肯定不给你看啊！所以才会告诉你403，不给你访问。

5.3 5xx状态码

什么时候会出现服务器错误的5xx状态码呢？

当你请求一个服务，服务端需要处理之后给你返回结果。此时服务器在处理过程中，可能因为程序有bug提前退出，这时候就应该给客户端发送一个5xx状态码，标识服务器在处理你的请求的过程中，出现了错误，无法返回结果。

5.4 301/302重定向

关于3开头的状态码，主要谈谈下面这两个

1 2	301 永久重定向 302 临时重定向

为何一个是永久，一个是临时呢？

在http进行响应的时候，服务端可以发送一个location参数，发送一个新的url给客户端；我们的浏览器在收到这个参数后，会自动打开对应的页面

1	Location: https://www.baidu.com/

我们可以用上面的代码来测试一下

// 尝试进行302重定向
string response = "HTTP/1.1 302 Temporarily moved\r\n";
response+= "Location: https://www.baidu.com/\r\n";
response+= "\r\n";

// 发送给用户
send(sock, response.c_str(), response.size(), 0);

此时访问我们自己的IP:端口，会跳转到百度的页面。这就是重定向的作用

那临时重定向和永久重定向有什么区别呢?

假如我设立了一个公开站点，域名是test.com，这几年一直提供服务，积累了一部分的用户。过了一会，我不想要这个域名了，想换一个test.cn；可用户已经有那么多，大家都只记得你的test.com，如果直接更换域名，就会导致用户无法访问test.com，以为你跑路了，就放弃使用你的网页。

这样的结果显而易见：严重的客户流失！

所以，为了避免这个问题，我可以先将服务迁移到test.cn新域名，在旧域名test.com中设置一个301重定向到test.cn，告诉用户我换新域名了。这样持续一段时间后，等到test.com的使用者不多了，就可以考虑彻底取消test.com的解析，关停此域名了。

在上面的场景中，我是需要更换域名，是永久更换。我们就应该把状态码设置为301，告诉客户端这个域名将被永久重定向到另外一个域名上

另外的情况是，我有一个example.com域名，我的服务需要进行维护；此时就将example.com重定向到另外一个域名example.cn，指向另外一个服务器，让这个服务器临时提供服务。

服务维护完毕后，就将重定向取消，继续使用当前的服务器。

这个场景中，重定向只是维护期间的一个临时策略，所以状态码设置成302，告诉客户端我只是临时进行重定向，我还会回来的。

日常生活中，当我们在一个web页面中登录了（如github/gitee/csdn）这个网页在很长一段时间内都会保持登录，直到超时亦或者是出现了异地访问。

假如你现在有个网页，但是每次用户访问的时候，都需要重新输入用户名和密码，刚刚输入过了，换一个页面又不行了。这样一来，用户还会想用你这个服务吗？

为了避免此类问题，http协议就需要引入其他的参数，来维持用户的登录会话。cookie/session便是因此而来的。

服务端可以在响应头中带上Set-Cookie字段，给客户端设置上cookie

1	response += "Set-Cookie: This is my cookie test\r\n";

打开f12开发者界面，能在其中看到我们设置的cookie

再次刷新网页，可以看到在之后的请求中，浏览器都会发送一次服务器设置的cookie。这样服务端在收到cookie后，就能解析到自己设置的cookie，确定了指定的用户

在服务器端也能看到这个字段

6.2 什么是cookie

所谓cookie，其实就是浏览器帮我们存取了一定的身份信息在本地（内存or磁盘）

下一次打开特定的网页的时候，就能显示对应的身份信息（不一定是你的账户密码），并告诉服务器，服务器就识别到了你当前的用户，并为你保持登陆状态。

既然是保存在用户本地的，那就有可能被窃取。一些恶意软件就会去扫描你浏览器本地缓存中的cookie信息，对于一些安全性不高的网站而言，有了这个cookie，就相当于他有了你的账户，可以直接登录你的账户进行操作。

因此，引入了另外一种身份认证的方式 cookie+session

比起将身份信息存到客户端，存至服务端更为安全（攻击企业服务器的成本，比在用户端植入木马程序的成本更高）

用户使用账户密码请求登录，服务器收到登录请求，验证成功后，给客户端返回一个唯一字符串session_id来标识用户
客户端下一次请求的时候，带上了这个唯一字符串
服务器收到请求，在本地的session_id库中查找这个id，找到后，就将用户信息匹配给客户端，相当于客户端登录成功了

这样，就将原本存在用户本地的身份认证信息，存到了服务端中。客户端就只剩下一个孤零零的字符串id，不会有用户的私密信息。即便丢失，也不会影响用户的隐私。

你可能会说，那我偷走这个id不也是一样的效果？

其实没有那么简单，服务端可以将session_id和用户的ip或者终端User-Agent绑定，这样只要用户切换设备或者换了登录的地点（比如从三亚跑到了哈尔滨）就直接让session_id失效，要求用户重新登录。

7.长短链接

在早期的http协议中，采用的都是短链接，一次连接只能处理1次http请求。当时的网页大多以文字为主，数据量很小，一起请求也能够满足需求。

但现在时代已经变了，一个网页里面有图片，文字，音频，视频。这些文件的体积打起来之后，短链接的方式就不适用了。此时就出现了长链接，一次tcp链接，可以持续传输数据。

相比短链接，长链接连上之后，能持续传输数据，避免了tcp3次握手的消耗，提高了数据传输的效率！

7.1 Connection

在本文的3.4中，便出现了这个参数，一般情况下，会有下面两种情况

1 2	Connection: keep-alive Connection: closed

其中keep-alive就是长链接，closed代表当前端口只支持短链接。

当客户端发送的请求头中包含Connection: keep-alive字段，如果服务器支持长链接，就需要在响应头中也带上Connection: keep-alive，这样双方协商成功，大家都可以使用长链接。

如果服务器的响应头中没有带Connection: keep-alive，那么客户端就会认为服务器不支持长链接，下次请求的时候，会重新向服务器链接，再获取资源。

如果客户端和服务端任意一方的响应头中包含Connection: closed，那么就会认为当前的会话只支持短链接，下次请求会重新建立链接。

7.2 http和tcp的关系

http虽然是基于tcp的，但http本身是无链接的。

举个最明显的栗子，在你打开一个网页之后，你关闭掉自己的wifi，你的网页并不会因此消失。只是无法进行后续操作而已。

http是一个无链接的应用层协议，其借助tcp进行数据的流式传输，但不一定需要客户端和服务端保持连接。

所以，http就可以借助单个tcp套接字持续的传输数据，也就天然地支持了长链接通信。

总结一下，http只是借用了tcp的能力，其无连接的特性和tcp没有关系！

7.3 pipeline

这其中会牵扯到一个pipeline，其维护了http长链接请求时的响应顺序。

比如人家需要加载一个网页，服务端应该先把网页的整体框架给用户加载出来，再给用户加载图片、视频、音频等资源。下图B站的加载就是一个很好的栗子。

否则乱序了，比如只出现了一个孤零零的图片，就会让人感觉非常奇怪。

8.https

因为http的数据是无加密明文发送的，相对来说并不是非常的安全；为了实现数据加密，https在http的下层添加了一个SSL/TLS软件层，来进行数据加解密工作

8.1 为啥要加密？

要知道，所有的加密工作，都是为了防止数据在中间传输的过程，被窃取或修改。如果我们请求一个网站登录的时候，数据包中就会包含我们的账户密码。如果被窃取，我们的隐私就泄露了。这是很难受的一件事！

这也是为什么，我们经常能听到免费公共wifi不安全这一说法，因为我们在这个wifi上进行的所有数据交换，都会走这个wifi的路由器，很容易被中间人窃取并获取到我们的数据包。
这种情况下，https的加密就更有必要了！

但是，加密解密是需要时间的，所以https响应的速度会稍慢于http。不过当下cpu的执行速度已经非常快，这点时间差距很小，不会特别影响我们的日常使用！

不过，加密并不是一个万金油，并不是说加密了之后的数据就一定能避免被窃取。但加密可以大大提高窃取破解的成本，无形中降低了数据被窃取的概率，保证了一定的数据安全。

8.2 常见加密方式

8.2.1 对称加密

所谓对称加密，好比有一个带锁的盒子，客户端和服务器都有一把钥匙。客户端先把信息丢进盒子里，再用🔑锁上盒子，发送给服务端。服务端用🔑打开盒子，取出数据。

因为客户端和服务器持有的钥匙是完全一致的，所以被称为对称加密。在加密的场景下，钥匙一般被称为密钥

在网络场景里，对称加密是不可取的。只要客户端和服务端传输密钥的时候被窃取，那么双方的加密就失效了。因为是用同一个密钥来加密解密，我拿走了你的钥匙，自然就能打开你这把锁。

也就是说，密钥的传输也需要加密。但是这又引出一个问题，我都没有你的密钥，我怎么解密你发过来的密钥信息？这是一个先有蛋还是先有鸡的死循环！

8.2.2 非对称加密

非对称加密场景下，会有一个公钥和私钥

私钥对数据加密，变成密文
公钥对数据解密，变成明文

二者也可以反过来

私钥对数据解密
公钥对数据加密

其中最常用的非对称加密，也就是我们在git的ssh操作中使用过的rsa密钥，其中就有一个.pem公钥和一个私钥。我们将公钥提供给github，私钥保存到本地，就能实现无密码上传数据到git仓库。

但是非对称加密还是会存在中间人攻击的问题。先看如下图，你应该能发现，其中有一个重要的环节，就是服务端要把公钥发送给客户端

在这个场景中，公钥是公开传输给客户端的，也就是后续服务器发送给客户端的所有信息，都可以被其他人用这个公钥解析出来；

整个环节中，只做到了客户端发送给服务器的信息安全，因为只有服务器拥有私钥，能解密出数据。

8.2.3 双非对称

这时候，我们可以采用双非对称密钥加密的方式！既然非对称只能保证单方的数据安全，那使用两个非对称，不就能保证双方数据安全了嘛！

客户端和服务端交换公钥a' 和 b'
客户端给服务端发信息：先用a'对数据加密，再发送；只能由服务器解密，因为只有服务器有私钥a
服务端给客户端发信息：先用b'对数据加密，再发送；只能由客户端解密，因为只有客户端有私钥b

因为两份私钥都只有客户端和服务器自己拥有，所以黑客没有办法进行数据的窃取，也就保证了数据的安全。

即便中间人替换了交换的公钥，也会因为后续的通信，客户端or服务端本地的私钥无法正常解密，而发现数据被窃取！

但是但是，这样左还算有很大的缺点

效率太低（非对称加密解密负载太高，效率低下，特定场景下无法满足要求）
依旧可能存在安全问题

8.2.4 非对称+对称

服务端具有非对称公钥S和私钥S’
客⼾端发起请求，获取服务端公钥S
客⼾端在本地生成对称密钥C, 通过公钥S加密, 发送给服务器.
由于中间人没有私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥
服务器通过私钥S'解密，还原出客户端发送的对称密钥C，并且使用这个对称密钥加密给客户端发送的响应数据
后续客户端和服务端都采用密钥C来进行对称加密通信

因为对称密钥C在传输过程中是加密的，只有客户端和服务端知道密钥是什么，也就实现了数据的安全通信！

8.3 数据摘要（指纹）

数字指纹(数据摘要)，其基本原理是利⽤单向散列函数(Hash函数)对信息进行运算，生成⼀串固定长度的数字摘要。

常见的摘要算法有MD5/SHA1/SHA256/SHA512等；

数字指纹并不是⼀种加密机制，但可以用来判断数据有没有被窜改，亦或者是下载的数据包有没有出现损坏。

同一个数据文件，用同一个方法生成的数据摘要是一致的
不同文件生成的数据摘要可能会撞车，但几率极低，可以认为具有唯一性！
我们无法用数据摘要反推出数据内容（怎么可能用一个字符串推测出原本的内容呢？那样还存放源文件干哈？😂）

数据摘要在网盘产品中也有使用，当我们使用百度云盘、阿里云盘的时候，会遇到一个大的资源文件只用了短短几秒就成功上传到服务器的情况。此时，我们并不是真的用几秒就把数据传输上去了，而是经历了以下阶段

网盘客户端对本地文件生成数据摘要
生成后，判断服务器端已有文件中，是否有同该数据摘要相同的文件
如果有，代表该文件已经存在了云盘的服务器中
服务器将该文件给你的账户建立一个软链接/硬链接，就实现了"妙传"
如果没有，则老老实实的从本地上传文件到云盘

云盘厂家这么做的原因很简单：避免同一份文件被多次存储。当下网盘给用户的免费空间动则上T，如果所有文件都重复保存，那对于云服务器厂家来说，资源消耗太大了。

这个做法并不会产生数据隐私问题，一般只有电影等资源文件才有可能妙传成功。你可以使用一些“其他手段”，比如把资源打个压缩包，并在压缩包中随便丢另外一个文件，让文件的数据指纹和已有资源不相同，就不会进行妙传了。

这样做还有另外一个好处，那就是原资源因为违规被ban的时候，你的资源不会被连坐😂

8.4 数字签名

对数据摘要进行加密，生成的内容被称为数字签名

8.5 中间人攻击

中间人攻击（Man-in-the-MiddleAttack），简称MITM攻击

以8.2.2的单非对称加密为例，中间人可以在整个过程中进行偷梁换柱，窃取双方的信息。如下图：

透过这个栗子🌰，实际上，如果中间人在客户端和服务端开始通信之前就来窃听并准备换柱了，他就有可能替换双方密钥，从而解密双方发送的信息！

最重要的一点，是客户端or服务端都没有办法证明，当前的公钥是直接从服务端or客户端发来的，它们没有办法检验公钥的权威性，只能被动接受。由此给中间人偷梁换柱提供了可能。

这时候，就需要引入CA机构和CA证书了👇

8.6 CA证书

所谓CA证书，是由CA机构颁发的权威证书。CA机构在颁发证书时，会在证书中附带上该站点的域名，以及申请人（企业）的相关信息

CA机构会有一个自己的私钥和公钥，其公钥向所有人公开
CA机构的私钥由其自己保存（私钥一定不能泄露）
当下的浏览器、操作系统都会内置认可的CA；只有被认可的CA，才能为站点提供ssl证书服务

在我们windows本地就能看到当前操作系统认可的CA机构其公钥；在edge浏览器中，点击右上角选择，进入设置，在选择隐私页面，找到管理证书

点击它，就能看到当前本地认可的CA

8.6.1 ssl证书加密原理

当一个站点获取了ssl证书后，在向用户发送ssl证书中包含的公钥的同时，还会发送一个由CA机构对ssl证书公钥做的数字签名

ssl证书公钥的数字签名A，通过CA机构的私钥进行加密
ssl证书的公钥B

当客户端收到这份信息之后，会采用hash函数对收到的ssl证书公钥进行数字签名，得到一个本地生成的数字签名C

再用CA机构的公钥对传输过来的数字签名A进行解密，得到数字签名A的明文；判断由CA机构生成的ssl公钥数字签名A是否和本地生成的数字签名C相同；

如果相同，则代表证书正确！
不相同，代表证书出现错误！

画个图，大概就是下面这样

由于当下发送的数据包中，同时存在ssl公钥的明文+由CA机构加密后的数字签名，中间人无法进行任何攻击修改！

若修改ssl公钥，由于中间人没有CA机构的私钥，无法对修改后的ssl公钥生成对应的加密后数字签名
若使用CA公钥解密数字签名后修改……依旧会因为没有CA机构私钥，无法把修改后的签名加密回去
如果中间人用自己的私钥生成一个数字签名，但我不认识你这个CA，也不知道你的公钥是什么，怎么解密你的信息呢？

综上，中间人要想偷梁换柱，只有一个办法了，那就是拿一个真的证书整体替换掉这个数据包。

可ssl证书中还包含了域名、站点主体等各类信息，我当下访问的是baidu.com，结果收到的证书是qq.com的，那肯定有问题啊！浏览器会直接拒绝访问！😂

当我们访问一些网站，浏览器报ssl证书过期，也是会出现一定的安全问题的！

8.6.2 ssl证书+非对称+对称

有了上面这个不能被篡改的ssl证书公钥，下面我们就可以利用非对称+对称加密的方式进行通信了

客户端收到ssl证书，向服务器发送一个本地生成的密钥D（使用ssl证书公钥进行加密）
服务端收到密钥D的加密信息，使用ssl证书的私钥进行解密，获取到密钥D
客户端和服务端使用密钥D进行对称加密通信

这样即解决了安全问题，又规避了非对称加密的效率问题，一举多得！

9.Content-Type

9.1 问题

之前写的http服务器有一个很大的弊端，就是Content-Type没能做到根据文件的格式进行自定义修改

默认情况下，如果index.html中没有指定icon的路径，浏览器会自动请求根路径下的favicon.ico，如果没有这个文件，则不显示站点图标。

如果在index.html有指定站点icon的路径，则会请求对应路径的图片。

如下图，我在index中指定了icon的路径

<head>
<meta charset="utf-8">
<title>http协议学习</title>
<link rel="shortcut icon" href="/img/icon.png">
</head>

但是浏览器去请求的时候，返回的文件类型依旧是text（因为已经写死了）

最终结果就是，配置的icon无效，依旧不显示站点图标

所以，我们应该在服务端给返回的文件添加上正确的Content-Type

9.2 代码

为了访问支持多种文件类型，我在tcpServer的类中新增了一个map，用于文件后缀和图标类型的对照。每每看到这个场景，我都想感慨一下：Python的dict还是方便多了🤣

void initMap()
{
    _fileTypeMap.insert({"html","text/html"});
    _fileTypeMap.insert({"jpg","image/jpeg"});
    _fileTypeMap.insert({"jpeg","image/jpeg"});
    _fileTypeMap.insert({"png","image/png"});
    _fileTypeMap.insert({"gif","image/gif"});
    _fileTypeMap.insert({"ico","image/x-icon"});
}
// 文件类型和http响应头的对照表
map<string,string> _fileTypeMap;

在设置Content-Type的时候，先从path中分离出客户端请求的文件类型

// 获取文件的后缀
string getFileType(const string& path)
{
    size_t i = path.rfind('.');
    if(i!=string::npos)//找到了
    {
        string filetype(path,i+1);//获取出文件类型
        logging(DEBUG,"Path: %s | fileType: %s",path.c_str(),filetype.c_str()); // 打印用作debug
        return filetype;
    }
    return ""; //没有后缀
}

需要注意的是，一些http请求是这样的

1	https://web.musnow.top/about/

后端会收到这样的path

/about/

这个path里面并没有文件名，而本文前面提到过，如果请求的链接中没有指明文件，那就给客户返回对应路径下的index.html文件。如果这个路径下没有html文件，则返回404。这一步在分离请求头中的path时已经做了

// 对path进行判断，如果path是以/结尾的，则在path中追加index.html文件名
if(path[path.size()-1] == '/') {
    path += HOME_PAGE; //加上被隐藏的index.html文件名
}

回到正题，在获取到文件后缀后，就可以在map里面查找对应的content-type了

// 追加正确的文件类型Content-Type
response += "Content-Type: ";
string contentType = "text/plain";
auto it = fileTypeMap.find(fileType);
if(it != fileTypeMap.end()){
    contentType = (*it).second;
}

response += contentType;
response += "\r\n";

但是，这样还是出现了问题，图片没办法正常加载

F12打开开发者面板，可以看到服务器返回的响应头是正确的，但是依旧无法显示出图片

这是因为读取图片和读取html文件的操作是不一样。在读取html文件的时候，采用的是按行读取的策略

// 读取txt文件
string readTxtFile(const string& file_path)
{
    // 如果是文件存在但是打开失败了，应该返回50x代表服务器处理错误
    // tcp是面向字节流的，文件需要用二进制打开
    ifstream in(file_path, ios::binary);
    if(!in.is_open()) //文件打开失败
    {
        return "503";//文件打开失败
    }

    // 内容
    string content;
    string line;
    while(getline(in, line))
    {
        content += line;
    }
    in.close();
    return content;
}

但是图片文件应该需要一个完整的二进制流，而不是按行读取

// 读取图片文件
string readImgFile(const string& file_path)
{
    ifstream file(file_path, ios::binary);
    // 打开失败，503
    if (!file.is_open()) {
        return "503";
    }

    ostringstream ss;
    ss << file.rdbuf();
    string content = ss.str();
    file.close();

    return content;
}

为了区别图片和html文件，我新增了一个用于判断文件后缀的函数

const string imageType[] = {"png","jpg","gif","jpeg"}; // 图片类型
// 判断请求头中文件类型是否为图片
bool isImg(const string& fileType)
{
    for(auto& t: imageType)
    {
        // 如果完全一致
        if(fileType == t)
        {
            return true;
        }
    }
    return false;
}

最终合并成同一个函数

string readFile(const string &file_path,bool is_img = false)
{
    //其实这里应该分两种情况，一种是文件不存在，一种是文件打开失败了
    //如果是文件不存在，应该返回404
    if(access(file_path.c_str(),0)!=0)//判断文件是否存在，存在返回0
    {//windows下相同作用的接口为_access，头文件io.h
        return "404";//文件不存在
    }
    // 读取对应的文件
    if(!is_img){
        return readTxtFile(file_path);
    }
    else{
        return readImgFile(file_path);
    }
}

在服务函数里面，也做出了区别

// 获取文件的后缀
string fileType = getFileType(path);
// 打开文件
string content = readFile(resources,isImg(fileType));

再次测试，成功！

主页html文件中配置的log也正常显示出来了！（和原来的颜色不一样）