URL

http://表示的就是协议方案名#xff0c;常用的协议有HTTP协议、HTTPS协议、FTP协议等。

HTTPS协议是以HTTP协议为基础#…HTTP协议

URL

http://表示的就是协议方案名常用的协议有HTTP协议、HTTPS协议、FTP协议等。

HTTPS协议是以HTTP协议为基础通过传输加密和身份认证保证了传输过程的安全性。

登录信息

user:pass表示登录认证信息。

绝大多数情况下该字段是被省略。

一般通过登录窗口的方式让用户输入。

比如gitee的登录窗口

服务器地址

服务器地址也叫做域名。

在进行网络访问时网络地址通过DNS域名解析转换为标识唯一主机的IP地址。

比如使用ping命令访问百度和京东的官网最后会被转换为ip地址

实际上可以认为域名和IP地址是等价的在计算机世界中使用的时候既可以使用域名也可以使用IP地址。

但URL呈现出来是可以让用户看到的因此URL当中是以域名的形式表示服务器地址的。

服务器端口

一般0-1023号端口已经被一些特定的服务占有。

比如HTTP协议默认的端口是80HTTPS默认的端口是443。

/dir/index.htm表示的是要访问的资源所在的路径。

访问服务器的目的是获取服务器上的某种资源通过前面的域名和端口已经能够找到对应的服务器进程了此时要做的就是指明该资源所在的路径。

查询字符串

uid1表示的是请求时提供的额外的参数这些参数是以键值对的形式通过符号分隔开的。

在上面的URL中存在wd这个字段。

这个字段也就是我们想要查询的关键字。

片段标识符

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

在线编码工具

市面上存在很多免费的在线编码工具https://tool.chinaz.com/Tools/urlencode.aspx

HTTP协议能够干什么

HTTP协议是向特定的服务器申请特定的资源并获取到本地的协议。

通过wget命令申请百度首页的资源。

并得到一个html文件到本地。

我们将html中的内容在浏览器中打开

请求行请求方法url(文件路径格式)http版本请求报头请求的属性这些属性都是以key:

value的形式按行陈列的。

空行作为请求报头和请求正文的的分割线请求正文请求正文允许为空字符串如果请求正文存在则在请求报头中会有一个Content-Length属性来标识请求正文的长度。

读取完整的报头逐行读取直到读取到空行。

读取完整的正文在报头中一定存在一个关于key:value保存正文长度的属性。

获取HTTP请求

HTTP协议的底层通常使用的传输层协议是TCP协议因此可以通过一个TCP服务器获取HTTP请求。

int

sizeof(local));local.sin_family

htons(8888);local.sin_addr.s_addr

htonl(INADDR_ANY);if

--------------------------request

begin--------------------------

endl;cout

---------------------------request

endl;close(sock);exit(0);}//爷爷进程close(sock);waitpid(-1,

nullptr,

浏览器向服务器发起HTTP请求后由于服务器没有对其进行响应此时浏览器就会认为服务器没有收到请求然后再不断发起新的HTTP请求。

因此虽然我们只用浏览器访问了一次但会受到多次HTTP请求。

由于浏览器发起请求时默认用的就是HTTP协议因此我们在浏览器的url框当中输入网址时可以不用指明HTTP协议。

这里URL中的/并不是指云服务器的根。

web根目录可以由自己指定。

状态行HTTP版本状态码状态码描述符响应报头响应的属性以key:

value键值对的形式按行陈列的。

空行响应报头和响应正文的分割线响应正文响应正文允许为空字符串如果响应正文存在则响应报头中会有一个Content-Length属性来标识响应正文的长度。

下面我们在服务器中构建HTTP响应当浏览器发送请求时在网页上显示accept

your

sizeof(local));local.sin_family

htons(8888);local.sin_addr.s_addr

htonl(INADDR_ANY);if

--------------------------request

begin--------------------------

endl;cout

---------------------------request

responsehttp/1.1

request;response(Content-Length:

\r\n);response\r\n;responseworld;send(sock,response.c_str(),response.size(),0);close(sock);exit(0);}//爷爷进程close(sock);waitpid(-1,

nullptr,

}在实际的使用中难道每一个请求都需要程序员去构造响应正文实际上HTTP请求的请求行中存在URLURL就是请求需要访问资源的存放地址。

响应正文存放在哪

/dir/index.html。

所以可以从请求行的第二个字段中获取资源路径。

GET

posbuffer.find(CRLF);if(posstd::string::npos)

return

firstlinebuffer.substr(0,pos);size_t

firstfirstline.find(SPACE);if(firststd::string::npos)

return

secondfirstline.rfind(SPACE);if(secondstd::string::npos)

return

URLbuffer.substr(firstSPACELEN,second-SPACELEN-first);if(URL.size()1URL[0]/){URLHOME_PAGE;}return

URL;

当我们访问对应URL路径在资源时便打开对应文件夹并添加到HTTP响应正文并返回。

string

in(filepath,std::ifstream::binary);if(!in.is_open())

return

(getline(in,line)){contentline;}coutcontentendl;in.close();return

content;

/html并创建文件夹a/b/c在该文件夹下创建一个d.html文件

d.html/h1/body

sizeof(local));local.sin_family

htons(8081);local.sin_addr.s_addr

htonl(INADDR_ANY);if

URLreadURL(buffer);coutURL:URLendl;//拼接路径string

filepathROOT_PATHURL;coutfilepa***ndl;//构建HTTP响应string

responsehttp/1.1

worldreadFile(filepath);response(Content-Length:

\r\n);response\r\n;responseworld;send(sock,response.c_str(),response.size(),0);close(sock);exit(0);close(sock);exit(0);}//爷爷进程close(sock);waitpid(-1,

nullptr,

把远端的资源拿到本地GET将自己的属性提交到远端POST或者GET方法。

我们在web根目录下的index.html文件中添加一个表单用于比较两者的区别

webroot/h1form

观察URL的变化。

提交的user和passwd以明文的方式出现在URL中。

这也是GET方法的特点把参数以明文的方式按照Key:value格式拼接到URL后面。

POST方法

这次并没有将参数添加到URL中观察HTTP请求可以看到user和password参数都出现在HTTP请求正文中。

注意一定不是不安全因为GET方法和POST方法通过代理服务器或者抓包等方法都可以获取对应的参数要想实现数据安全就需要对传输的数据进行加密。

比如HTTPS协议

GET通过URL传参URL有长度的限制所以数据量较大的参数都会通过POST方法传递。

HTTP状态码

重定向就是通过各种方法将各种网络请求重新定个方向转到其它位置此时这个服务器相当于提供了一个引路的服务。

重定向又可分为临时重定向和永久重定向其中状态码301表示的就是永久重定向而状态码302和307表示的是临时重定向。

临时重定向实验

在实现的过程中将HTTP的响应码设置为302还需要在HTTP响应报头当中添加Location字段这个Location后面跟的就是你需要重定向到的网页比如我们这里将其设置为CSDN的首页。

int

sizeof(local));local.sin_family

htons(8081);local.sin_addr.s_addr

htonl(INADDR_ANY);if

//读取HTTP请求cout------------------------request

begin----------------------endl;coutbufferendl;cout-------------------------request

end-----------------------endl;string

responsehttp/1.1

Redirect/\r\n;responseLocation:

https://www.bilibili.com/\r\n;response\r\n;send(sock,response.c_str(),response.size(),0);close(sock);exit(0);close(sock);exit(0);}//爷爷进程close(sock);waitpid(-1,

nullptr,

使用telnet命令只是接收到了服务器发送的HTTP响应并没有实现重定向功能。

实际上的重定向功能是由浏览器实现完成。

下面我们用浏览器访问该网址

两者的区别主要体现在用户体验方面临时重定向主要用于网站维护、网站服务升级等。

服务升级结束和维护成功后原网址依然可以被使用。

临时重定向不需要客户记住新的网址。

永久重定向比如用于使用新的网址原网址被废弃的情况。

永久重定向需要用户记住新的网址。

Content-Type:

数据类型(text/html等)Content-Length:

客户端告知服务器,

HTTP协议的特点之一无状态。

对于用户的状态HTTP协议不会记录用户的信息和行为。

而Cookie是实现HTTP状态化的一种手段。

比如实现网址的无登陆访问VIP访问VIP资源。

(回忆下面的场景我们在使用B站时第一次需要我们输入账号密码登录。

后续再使用时我们可以直接进入B站而不需要登录。

这就是HTTP状态化的一种手段

比如你是某个视频网站的VIP这个网站里面的VIP视频有成百上千个你每次点击一个视频都要重新进行VIP身份认证。

而HTTP不支持记录用户状态那么我们就需要有一种独立技术来帮我们支持这种技术目前现在已经内置到HTTP协议当中了叫做cookie。

)

Cookie实验一

此时已经登录了账号。

点击网址前面的小锁可以看到网页的Cookie。

在我们第一次登录输入账号和密码进行身份认证时如果认证成功服务端就会向客户端发送对应的响应其中就包含Set-Cookie字段(Set-Cookie也是HTTP报头当中的一个字段)。

该字段通知客户端设置Cookie。

输入的账号和密码就保存在本地浏览器Cookie文件当中。

后续再次访问相同的网址时浏览器发送的HTTP请求当中就会包含一个Cookie信息。

服务端在需要认证时会提取Cookie当中账号和密码。

Cookie文件内存级和磁盘级别

cookie就是在浏览器当中的一个小文件文件里记录的就是用户的私有信息。

cookie文件可以分为两种一种是内存级别的cookie文件另一种是磁盘文件级别的cookie文件。

浏览器关闭后再打开访问之前的网站需要输入账号和密码。

此时浏览器保存的是内存级别的Cookie文件浏览器关闭再打开甚至重启电脑。

访问之前的网站不需要输入账号和密码。

浏览器保存的是磁盘文件级别的Cookie文件。

设置Cookie

设置Cookie可以在HTTP响应中添加一个Set-Cookie字段。

(Set-Cookie:Cookie信息)

设置Cookie实验

sizeof(local));local.sin_family

htons(8081);local.sin_addr.s_addr

htonl(INADDR_ANY);if

//读取HTTP请求cout------------------------request

begin----------------------endl;coutbufferendl;cout-------------------------request

end-----------------------endl;//读取URLstring

URLreadURL(buffer);//拼接路径string

filepathROOT_PATHURL;//构建HTTP响应string

responsehttp/1.1

ok/\r\n;responseSet-Cookie:this

Cookie

worldreadFile(filepath);response(Content-Length:

\r\n);response\r\n;responseworld;send(sock,response.c_str(),response.size(),0);close(sock);exit(0);close(sock);exit(0);}//爷爷进程close(sock);waitpid(-1,

nullptr,

单纯的使用Cookie是不安全的。

cookie文件当中就保存的是你的私密信息一旦cookie文件泄漏你的隐私信息也就泄漏。

为了保证Cookie的安全性。

后来又引入了Session的概念。

当我们第一次登录某个网站输入账号和密码后服务器认证成功后还会服务端生成一个对应的SessionID这个SessionID与用户信息是不相关的。

系统会将所有登录用户的SessionID值统一维护起来。

此时当认证通过后服务端在对浏览器进行HTTP响应时就会将这个生成的SessionID值响应给浏览器。

浏览器收到响应后会自动提取出SessionID的值将其保存在浏览器的cookie文件当中。

后续访问该服务器时对应的HTTP请求当中就会自动携带上这个SessionID。

服务端会根据session_id找到对应的Session文件。

再提取session文件中的私密信息。

CookieSession的安全保证着手于Session_id的加密方式。

比如用户的IP地址等。

Connection字段

Connection:keep_aliveConnection:closed

HTTP短连接

在HTTP/1.0中默认使⽤的是短连接。

也就是说浏览器和服务器每进⾏⼀次HTTP操作就建⽴⼀次连接但任务结束就中断连接。

随着网页信息不断的增大需要传输的数据量也不断增加。

如果客户端访问的某个HTML或其他类型的web页中包含有其他的web资源如JavaScript⽂件、图像⽂件、CSS⽂件等当浏览器每遇到这样⼀个web资源就会建⽴⼀个HTTP会话。

如果建立多个HTTP短连接传输数据**传输层会不断的进行三次握手和四次挥手**过于浪费网络资源。

HTTP长连接

但从HTTP/1.1起默认使⽤长连接⽤以保持连接特性。

使⽤长连接的HTTP协议会在请求头和响应头加⼊这⾏代码。

Connection:

在使⽤长连接的情况下当⼀个⽹页打开完成后客户端和服务器之间⽤于传输HTTP数据的TCP链接不会关闭如果客户端再次访问这个服务器上的⽹页会继续使⽤这⼀条已经建⽴的连接HTTP长连接利⽤同⼀个TCP连接处理多个HTTP请求和响应。

Keep-Alive不会永久保持连接它有⼀个保持时间可以在不同的服务器软件如Apache中设定这个时间。

实现长连接要客户端和服务端都⽀持长连接。

长连接中关闭连接通过Connectionclosed头部字段。

如果请求或响应中的Connection被指定为closed表⽰在当前请求或相应完成后将关闭TCP连接。

TCP的keep-alive是检查当前TCP连接是否活着HTTP的Keep-Alive是要让⼀个TCP连接活久点。

HTTP报头中存在Conten-Length字段。

通过控制读取的长度判断是否读取完整的信息。

HTTP

HTTPS协议也是⼀个应⽤层协议。

是在HTTP协议的基础上引⼊了⼀个加密层。

这场加密层也输入应用层他会对用户传输的信息进行加密。

为什么要加密

http的内容是明⽂传输的明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务

器等多个物理节点如果信息在传输过程中被劫持传输的内容就完全暴露了。

劫持者还可以篡改传输的信息且不被双⽅察觉这就是中间⼈攻击

对称加密和非对称加密

采⽤单钥密码系统的加密⽅法同⼀个密钥可以同时⽤作信息的加密和解密这种加密⽅法称为对称加密也称为单密钥加密特征加密和解密所⽤的密钥是相同的常⻅对称加密算法DES、3DES、AES、TDEA、Blowfish、RC2等特点算法公开、计算量⼩、加密速度快、加密效率⾼

假设明⽂a1234,密钥key8888。

则加密akey得到的密⽂b为9834。

然后针对密⽂9834再次进⾏运算bkey,得到的就是原来的明⽂1234。

非对称加密

需要两个密钥来进⾏加密和解密这两个密钥是公开密钥publickey简称公钥和私有密钥private

key简称私钥。

常见非对称加密算法RSADSAECDSA特点算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂⽽使得加密解密速度没有对称加密解密的速度快

非对称加密要⽤到两个密钥,⼀个叫做公钥,⼀个叫做私钥。

公钥和私钥是配对的。

非对称加密最⼤的缺点就是运算速度⾮常慢比对称加密要慢很多。

对称加密和非对称加密联合使用

通信双方建立连接的时候双方就可以把支持的加密算法作协商协商之后在服务器端形成非对称加密时使用的公钥和私钥在客户端形成对称加密时使用的密钥。

然后服务器将公钥交给客户端这个公钥全世界都可以看到然后客户端用这个公钥对客户端形成的密钥进行加密将加密后的密钥发送给服务器服务器拿到后再用它的私钥进行解密最终服务器就拿到了客户端的密钥。

这时客户端和服务器都有了这个密钥并且其他人是不知道的此时客户端和服务器就可以进行对称加密通信了。

数据摘要和数据指纹

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

数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改。

摘要常⻅算法有MD5、SHA1、SHA256、SHA512等。

摘要特征和加密算法的区别是摘要严格意义不是加密因为没有解密只不过从摘要很难反推原信息通常⽤来进⾏数据对比(哈希函数是不可逆的所以无法从数据摘要反推数据全文因此数据摘要常用来数据的对比)。

比如用户要上传一部电影云盘接收到请求后先对电影数据进行数据摘要得到摘要信息。

此时服务端会对该数据摘要和其他用户已经上传的文件的数据摘要进行对比。

如果存在用户想要上传的文件就建立软连接指向原来用户上传好的相同文件。

方案一只使用对称加密

服务器同⼀时刻其实是给很多客户端提供服务的。

每个客⼾端,每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥,⿊客就也能拿到了)。

因此服务器就需要维护每个客户端和每个密钥之间的关联关系

而同时维护多个密钥服务端的压力就比较大。

因此理想的做法是所有的客户端使用同一个密钥。

如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了。

因此就需要对密钥进行加密。

但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个密钥的密钥。

这就成了先有鸡还是先有蛋的问题。

方案二只使用非对称加密

由于服务端在传输公钥时没有进行加密因此所有人都可以得到公钥。

因此服务端发送消息可能被中间人劫持。

服务端到客户端的信息传输是不安全的。

方案三双方都使用非对称加密

1.服务端拥有公钥S与对应的私钥S’客户端拥有公钥C与对应的私钥C’2.客户和服务端交换公钥3.客⼾端给服务端发信息先⽤S对数据加密再发送只能由服务器解密因为只有服务器有私钥S’4.服务端给客户端端发信息先⽤C对数据加密在发送只能由客户端解密因为只有客户端有私钥C’

使用2对非对称密钥可以实现客户端和服务端的信息安全。

缺点效率太低并且依然有安全问题(存在中间人攻击)

方案四使用对称加密非对称加密

服务端具有⾮对称公钥S和私钥S’客⼾端发起https请求获取服务端公钥S客⼾端在本地⽣成对称密钥C,通过公钥S加密,发送给服务器。

这样客户端和服务端都拥有密钥C可以进行通信。

该方案相对于方案三解决了效率低的问题。

但是依然存在安全问题中间人攻击

中间人攻击

在⽅案2/3/4中客⼾端获取到公钥S之后对客⼾端形成的对称秘钥X⽤服务端给客⼾端的公钥

S进⾏加密中间⼈即使窃取到了数据此时中间⼈确实⽆法解出客⼾端形成的密钥X因为只有服务器有私钥S’。

但是中间⼈的攻击如果在最开始握⼿协商的时候就进⾏了就会发生安全问题。

服务器具有⾮对称加密算法的公钥S私钥S’中间⼈具有⾮对称加密算法的公钥M私钥M’客⼾端向服务器发起请求服务器明⽂传送公钥S给客⼾端中间⼈劫持数据报⽂提取公钥S并保存好然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M并将伪造报⽂发给客⼾端客⼾端收到报⽂提取公钥M(⾃⼰当然不知道公钥被更换过了)⾃⼰形成对称秘钥X⽤公钥M加密X形成报⽂发送给服务器中间⼈劫持后直接⽤⾃⼰的私钥M’进⾏解密得到通信秘钥X再⽤曾经保存的服务端公钥S加密后将报⽂推送给服务器服务器拿到报⽂⽤⾃⼰的私钥S’解密得到通信秘钥X客户端和服务端双方开始采⽤X进⾏对称加密进⾏通信。

但⼀切都在中间⼈的掌握中劫持数据进⾏窃听甚⾄修改都是可以的

问题的本质是客⼾端⽆法确定收到的含有公钥的数据报⽂就是⽬标服务器发送过来的

CA证书

服务端在使⽤HTTPS前需要向CA机构申领⼀份数字证书数字证书⾥含有证书申请者信息、公钥信息等。

服务器把证书传输给浏览器浏览器从证书⾥获取公钥就可。

在申请证书时需要在特定的权威平台生成并且会产生一对公钥B和私钥B’。

公钥会附加在证书上私钥被CA机构和服务端保存。

这对密钥在网络通信中进行明文加密和数字签名

数据签名

签名的形成是基于⾮对称加密算法的。

数据签名是由数据摘要通过私钥加密得到。

**证书包括证书明文和数据签名两个部分。

**数据签名部分是由证书明文通过摘要算法形成数据摘要数据摘要被再CA公司的私钥A加密得到。

CA机构拥有⾮对称加密的私钥A和公钥A’CA机构对服务端申请的证书明⽂数据进⾏hash形成数据摘要然后对数据摘要⽤CA私钥A’加密得到数字签名S。

数据签名附加在证书明文上形成证书。

服务端申请的证书明⽂和数字签名S共同组成了数字证书这样⼀份数字证书就可以颁发给服务端了。

一对是服务端申请的密钥也就是CA证书上公钥B对应的密钥。

这对密钥的作用是在网络通信中对数据信息进行加密。

且被服务端和CA公司都持有。

一对是CA公司持有的密钥也就是对证书明文的数据摘要进行加密的私钥A’对应的密钥。

该对密钥的作用是形成数据签名并被用于检查证书的合法性。

只被CA公司持有私钥公钥被嵌入到操作系统中。

方案五非对称加密对称加密证书

在使用方案五时。

证书上已经包含了服务端进行通信的公钥B。

服务端与客户端要进行通信时服务端先将证书发送给客户端客户端检查证书的合法性(检查是否被篡改)并提取公钥B。

随后客户端使用B加密客户端形成的对称密钥X发送给客户端。

客户端使用私钥B’解密得到对称密钥X。

证书包含证书明文和数据签名两部分。

数据签名被CA机构的密钥A’加密无法被更改。

如果有第三方修改了证书明文比如证书上用于通信的公钥。

客户端在拿到服务端发送的证书后会使用被嵌入到操作系统的CA机构公钥A进行解密得到数据摘要。

再将证书明文通过摘要算法形成数据摘要。

假设我们的证书只是⼀个简单的字符串hello,对这个字符串计算hash值(⽐如md5),结果为

BC4B2A76B9719D91

客户端通过比较两个数据摘要发现不同说明证书内容被篡改证书不合法。

客户端停止对服务端发送消息。

HTTPS工作流程一共包含三组密钥

第一组(非对称加密)用于形成数据签名和校验证书是否被篡改。

CA机构和服务端持有私钥公钥被嵌入到操作系统中(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥)

。

服务器在客⼾端请求时返回携带签名的证书。

客⼾端通过这个公钥进⾏证书验证,保证证书的合法性进⼀步保证证书中携带的服务端公钥权威性。

第二组(非对称加密)用于客户端和服务端协商对称加密的密钥。

服务端生成公钥和私钥。

公钥被填写到CA证书上。

客⼾端⽤收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥。

第三组(对称加密)客户端生成。

用于服务端和客户端进行加密通信。