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 | 片段标识符 |
像/?:这样的字符已经被url当作特殊意义理解了,因此这些字符不能随意出现。比如某个参数中需要带有这些特殊字符,就必须先对特殊字符进行转义
转义的规则如下:将需要转码的字符转为16进制,然后从右向左,取4位(不足4位直接处理),每2位做一位,前面加上%,编码成%XY格式
urldecode就是urlencode的逆过程
HTTP请求
HTTP响应
HTTP1.0:短链接:一个请求,一个相应,close socket,一个请求一般请求一个资源
方法 | 说明 | 支持的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方法是最常用的
状态码 | 类别 | 原因短语 |
---|---|---|
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/1.0采用的网络请求的方案是短链接也就是request->reponse->close后只返回一个资源,那么在访问一个由多个元素构成的网页的时候http/1.0就需要多次进行http请求,http协议基于tcp协议的,tcp要通信需要经过,建立链接->传送数据->断开链接,每一次请求都要执行上面的过程无疑是很耗时的,而http/1.1支持的长连接就可以通过减少频繁建立tcp链接来达到提高效率的目的。
cookie和session存在的主要意义是提高用户访问网站或者平台的体验。我们都有这样的经验,当我们访问某个网站的时候会先要求我们输入账号密码,然后继续访问,而当我们输入完登录后,网站好像就记住了我们,我们我们如何跳转页面,网站都会显示我们在登录状态,然而http协议本身是一个无状态的协议,因此http本身并没有“会话保持”功能,因此cookie和session的诞生就是为了进行会话管理
如果有人盗取了用户的cookie文件,别人就可以用用户的身份进行认证,访问特定的资源,如果保存的是用户的用户名、密码,那么就非常糟糕了。因此单纯使用cookie是具有一定的安全隐患的。讲到这里相信各位就能猜出session的功能了,session相对cookie来说能够让用户的私密信息相对于cookie来说不那么容易被盗取,能够保证私密性。他的核心思路就是将用户的私密信息保存在服务器端
所有的http请求,都会由浏览器自动携带cookie内容,也就是当前用户的session_id(会话id),这是一个具有唯一性的值,能够在服务端找到对应的文件。
目前来看安全性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.依旧有被非法窃取的风险
2.非对称加密算法特别费时间,一般用秒来计算
对称密钥缺陷
而对称密钥同样存在不少缺陷:首先我们要实现对称密钥就得保证客户端和服务端中均存在相同的密钥,那么我们要达到这个目的可以有两种方法:密钥协商、预装。
密钥协商:服务器在第一次与客户端通信时在相应内容添加密钥信息,这种方法的问题在于,在第一次通信过程中密钥信息是有可能被人窃取的,因此在对称方式中采用密钥协商方式是不可能的。
预装:要保证所有客户端设备都预装了密钥成本是很高的,而且就算预装好了密钥,它就存储在客户端设备上,容易被人窃取。
非对称+对称的方案可以较好的平衡两者优缺点。具体做法如下图:
上面的非对称+对称方案看起来已经无懈可击了,但其实它还有一个致命的问题,让我们来看看下面这种情况:
中间人通过狸猫换太子的手段获得了密钥X,并且因为中间人将密钥用S加密的结果重新返回给服务端,因此CS两端仍可以正常通信,察觉不到中间人的存在,那么在之后的通信中中间人就始终可以监听CS两端的通信了。
上面问题的本质在于客户端无法判定密钥协商报文是否来自合法服务商,而CA证书的出现可以很好的解决这个问题。一个服务商只要经过CA证书机构认证,那么它就是合法的,并且会得到机构颁发的CA证书。
CA证书一般包含企业的基本信息(域名+公钥),以及基本信息的数字签名,接下来是CA证书的基本原理:
1.首先通过以下流程获取数字签名
2.接着服务端在收到客户端请求后直接发送CA证书
3.客户端在收到证书后会将企业基本信息与数字签名进行比对,如果比对成功,客户端就会用公钥加密密钥X,并发回
那么有没有可能中间人本身也是一个受认证的服务商,那么它直接将服务端发送的证书替换成自己的证书,客户端仍然可以比对成功,这种情况下CA证书还能保证通信安全吗?其实也是可以的,因为企业信息中还包含服务商的域名,而域名也是有唯一性的,因此客户端可以判断出证书来源是否合法。
CA证书公钥一般是内置的,有时访问网址时浏览器会提示安装
端口号标识了一个主机上进行通信的不同的应用程序,在TCP/IP协议中,用“源IP”,“源端口号”,“目的IP”,“目的端口号”,“协议号”这样的五元组来标识一个通信(可以通过netstat -n查看)
知名端口号
cat /etc/services
一个端口号只能被一个进程绑定,一个进程可以绑定多个端口号
netstat
功能:netstat是一个用来查看网络状态的重要工具
语法:netstat [选项]
n:能显示成数字的全部显示成数字,否则按主机(文件)名显示
l:listen,显示监听状态的套接字,如果查普通状态的就不用带l
t:tcp
u:udp
p:显示建立相关链接的程序名
pidof
功能:快速找到进程id
语法:pidof [进程名]