网络基础——HTTP协议及HTTPS

HTTP（超文本传输协议）是一种非常好用的应用层协议

HTTP协议

URL

URL就是我们常说的“网址”

http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1

元素	含义
http://	协议方案名
user:pass	登录信息（认证）
www.example.jp	服务器地址
80	服务器端口号
dir/index.htm	带层次的文件路径
uid=1	查询字符串
ch1	片段标识符

urlencode和urldecode

像/?:这样的字符已经被url当作特殊意义理解了，因此这些字符不能随意出现。比如某个参数中需要带有这些特殊字符，就必须先对特殊字符进行转义
转义的规则如下：将需要转码的字符转为16进制，然后从右向左，取4位（不足4位直接处理），每2位做一位，前面加上%，编码成%XY格式
urldecode就是urlencode的逆过程

HTTP协议格式

HTTP请求

• 首行：[方法]+[url]+[版本]
• Header:请求的属性，冒号分隔的键值对；每组属性之间使用\n分；遇到空行表示Header部分结束
• Body：空行后面的内容都是Body，Body允许为空字符串，如果Body存在，则在Header中会有一个Content-Length属性来标识Body的长度

HTTP响应

• 首行：[版本号]+[状态码]+[状态码解释]
• Header：响应的属性，冒号分割的键值对；每组属性之间使用\n分隔；遇到空行表示Header部分结束
• Body：空行后面的内容都是Body，Body允许为空字符串，如果Body存在，则在Header中会有一个Content-Length属性来标识Body的长度，如果服务器返回了一个html页面，那么html页面内容就是在body中

HTTP1.0：短链接：一个请求，一个相应，close socket，一个请求一般请求一个资源

HTTP的方法

方法	说明	支持的HTTP协议版本
GET	获取资源	1.0、1.1
POST	传输实体主题	1.0、1.1
PUT	传输文件	1.0、1.1
HEAD	获得报文首部	1.0、1.1
DELETE	删除文件	1.0、1.1
OPTIONS	询问支持的方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的联系	1.0
UNLINE	断开连接关系	1.0

其中GET和POST方法是最常用的

HTTP的状态码

状态码	类别	原因短语
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

最常见的状态码：200(Ok),404(Not Found),403(Forbidden),302(Redirect,重定向),504(Bad Gateway)

HTTP常见Header

• Content-Type:数据类型（text/html等）
• Content-Length：Body长度
• Host：客户端告知服务器，所请求的资源是在哪个主机的哪个端口上
• User-Agent：声明用户的操作系统和浏览器版本信息
• referer：当前页面是从哪个页面跳转过来的
• location：搭配3xx状态码使用，告诉客户端接下来要去哪里访问
• Cookie：用于在客户端存储少量信息，通常用于实现会话(session)的功能

http/1.1

一般而言，一个大网页是由多个元素组成的，而http/1.0采用的网络请求的方案是短链接也就是request->reponse->close后只返回一个资源，那么在访问一个由多个元素构成的网页的时候http/1.0就需要多次进行http请求，http协议基于tcp协议的，tcp要通信需要经过，建立链接->传送数据->断开链接，每一次请求都要执行上面的过程无疑是很耗时的，而http/1.1支持的长连接就可以通过减少频繁建立tcp链接来达到提高效率的目的。

cookie和session

cookie和session存在的主要意义是提高用户访问网站或者平台的体验。我们都有这样的经验，当我们访问某个网站的时候会先要求我们输入账号密码，然后继续访问，而当我们输入完登录后，网站好像就记住了我们，我们我们如何跳转页面，网站都会显示我们在登录状态，然而http协议本身是一个无状态的协议，因此http本身并没有“会话保持”功能，因此cookie和session的诞生就是为了进行会话管理

cookie

1. 浏览器：cookie其实是一个文件，该文件里面保存用户的私密信息
2. http协议：一旦网站对应有cookie，在发起任何请求的时候，都会自动在request携带该cookie信息。

session

如果有人盗取了用户的cookie文件，别人就可以用用户的身份进行认证，访问特定的资源，如果保存的是用户的用户名、密码，那么就非常糟糕了。因此单纯使用cookie是具有一定的安全隐患的。讲到这里相信各位就能猜出session的功能了，session相对cookie来说能够让用户的私密信息相对于cookie来说不那么容易被盗取，能够保证私密性。他的核心思路就是将用户的私密信息保存在服务器端

所有的http请求，都会由浏览器自动携带cookie内容，也就是当前用户的session_id(会话id)，这是一个具有唯一性的值，能够在服务端找到对应的文件。

https

概念

目前来看安全性http协议是http一个很大的问题，我们知道在网络通信中两台设备的通信并不是两者之间进行”悄悄话“，其他设备理论上也是可以接收到他们之间的通讯信息的，这是不可避免的。因此https可以看作给http添加了加密解密功能(TLS/SSL)，https可以看作是http+TLS/SSL。

加密方式

对称加密

对称加密中客户端和服务端只有一个密钥。我们可以举一个典型的例子：在客户端有数据data，密钥X，那么当客户端要把data传输给服务端时就会先用X来加密data，而传输给服务端后，服务端会同样使用X来解密data。
比如说我们使用异或操作来进行加密和解密，下面的代码中data代表传输数据，X代表密钥，让我们看看传输结果。

int main()
{
    int data = 123;
    int X = 456;
    int client_res = data ^ X;
    cout << "data: " << data << endl; // 传输数据
    cout << "client send: " << client_res << endl; // 加密结果
    int server_res = client_res ^ X;
    cout << "server get: " << server_res << endl; // 解密结果
    return 0;
}

可以看出传输中的数据与数据本身并不一样，但是服务端经过解密后又得到了原来的数据。

非对称密钥

与对称密钥不同，非对称密钥有一对密钥：公钥，私钥。其中公钥是公开的，私钥只有客户端（服务端）私有保存。这两把钥匙可以用私钥（公钥）加密，用公钥（私钥）解密。
接着我们来思考一个问题，如何识别文本中的内容是否被篡改？
如何发送
假设现在有一份重要的文件，我们要将他传输到对端，为了防止有心人对文件进行篡改我们需要在传输过程中增加一些心眼。
那么首先我们该如何加密文本呢？

1. 通过哈希散列形成一个长度固定，唯一的字符序列（数据摘要/数据指纹）。这一步可以使用MD5。
2. 在用加密算法处理数据摘要，得到的加密结果称作数据签名。
3. 接着我们会将文件本身和它对应的数据签名一并发给接收端。
   
   如何校验
   1.对文件部分进行Hash散列，得到数据摘要
   2.对数据签名进行解密，得到数据摘要
   3.对两份数据摘要进行比对
   

非对称+对称

非对称密钥缺陷
对于非对称密钥来说，它主要存在两个缺陷：
1.依旧有被非法窃取的风险
2.非对称加密算法特别费时间，一般用秒来计算
对称密钥缺陷
而对称密钥同样存在不少缺陷：首先我们要实现对称密钥就得保证客户端和服务端中均存在相同的密钥，那么我们要达到这个目的可以有两种方法：密钥协商、预装。
密钥协商：服务器在第一次与客户端通信时在相应内容添加密钥信息，这种方法的问题在于，在第一次通信过程中密钥信息是有可能被人窃取的，因此在对称方式中采用密钥协商方式是不可能的。
预装：要保证所有客户端设备都预装了密钥成本是很高的，而且就算预装好了密钥，它就存储在客户端设备上，容易被人窃取。
非对称+对称的方案可以较好的平衡两者优缺点。具体做法如下图：

中间人攻击

上面的非对称+对称方案看起来已经无懈可击了，但其实它还有一个致命的问题，让我们来看看下面这种情况：

中间人通过狸猫换太子的手段获得了密钥X，并且因为中间人将密钥用S加密的结果重新返回给服务端，因此CS两端仍可以正常通信，察觉不到中间人的存在，那么在之后的通信中中间人就始终可以监听CS两端的通信了。

CA证书

上面问题的本质在于客户端无法判定密钥协商报文是否来自合法服务商，而CA证书的出现可以很好的解决这个问题。一个服务商只要经过CA证书机构认证，那么它就是合法的，并且会得到机构颁发的CA证书。
CA证书一般包含企业的基本信息（域名+公钥），以及基本信息的数字签名，接下来是CA证书的基本原理：
1.首先通过以下流程获取数字签名

2.接着服务端在收到客户端请求后直接发送CA证书

3.客户端在收到证书后会将企业基本信息与数字签名进行比对，如果比对成功，客户端就会用公钥加密密钥X，并发回

那么有没有可能中间人本身也是一个受认证的服务商，那么它直接将服务端发送的证书替换成自己的证书，客户端仍然可以比对成功，这种情况下CA证书还能保证通信安全吗？其实也是可以的，因为企业信息中还包含服务商的域名，而域名也是有唯一性的，因此客户端可以判断出证书来源是否合法。
CA证书公钥一般是内置的，有时访问网址时浏览器会提示安装

端口号

端口号标识了一个主机上进行通信的不同的应用程序，在TCP/IP协议中，用“源IP”，“源端口号”，“目的IP”，“目的端口号”，“协议号”这样的五元组来标识一个通信（可以通过netstat -n查看）

端口号范围划分

• 0~1023：知名端口号，他们的端口号都是固定的
• 1024~65535：操作系统动态分配的端口号，客户端程序的端口号，就是由操作系统从这个范围分配的

知名端口号

• ssh服务器：22
• ftp服务器：21
• telnet服务器：23
• http服务器：80
• https：443
  执行下面的命令，我们可以看到知名端口号

cat /etc/services

一个端口号只能被一个进程绑定,一个进程可以绑定多个端口号

几个常用的命令

netstat
功能：netstat是一个用来查看网络状态的重要工具
语法：netstat [选项]
n：能显示成数字的全部显示成数字，否则按主机（文件）名显示
l：listen，显示监听状态的套接字，如果查普通状态的就不用带l
t：tcp
u：udp
p：显示建立相关链接的程序名
pidof
功能：快速找到进程id
语法：pidof [进程名]