前端之http

最新推荐文章于 2023-02-09 14:57:54 发布

curry的记录

最新推荐文章于 2023-02-09 14:57:54 发布

阅读量596

点赞数

本文链接：https://blog.csdn.net/weixin_36215102/article/details/101533601

版权

前言：一个不懂http的前端不是一个合格的前端，一个没有计算机网络知识前端不是不是一个好的研发，接下来我就要来复习一些计算机网络的知识，尤其是http，tcp/udp这些。

1 互联网协议分层

网络协议通常分为不同的层次进行，每一层分别负责不同的通信功能。如下图所示。
在这里插入图片描述
每一层都有其各自的功能：

1、物理层
physical layer，把电脑连接起来的物理手段，主要规定了网络的一些电气特性，作用是负责传输0和1的电信号。

2、数据链路层
link layer, 在物理层的上方，确定了0和1的分组方式，也被称作网络接口层。
以太网规定，一组电信号构成一个数据包叫做“帧”，每一帧分为帧头和数据，帧头包含一些说明，比如发送者、接受者、数据类型等，固定为18字节，而数据的长度最长为1500字节，最短为46字节。因此整个帧最短64字节，最长1518字节，如果数据很长，则分割多帧进行发送

3、网络层

处理和分组相关，协议主要包含 IP 协议 ( 网际协议 )， ICMP 协议( Internet 互联网控制报文协议 )，以及 IGMP 协议( Internet 组管理协议 )

4、传输层
为两台主机上的应用程序提供端到端的通信，主要的两个协议有TCP／UDP。
TCP 为两台主机提供高可靠性的数据通信，UDP为应用层提供一种非常简单的服务，传输不可靠。

5、应用层
负责处理特定的应用程序细节。主要的应用有：HTTP、Telnet、FTP、SMTP、SNMP（简单网络管理协议）

在这里插入图片描述

数据的封装

在这里插入图片描述

2 数据链路层

数据链路层涉及到的有：
（1）以太网协议
早期的时候，每家公司都有自己的电信号分组方式。逐渐地，一种叫做"以太网"（Ethernet）的协议，占据了主导地位。
以太网规定，一组电信号构成一个数据包，叫做"帧"（Frame）。每一帧分成两个部分：标头（Head）和数据（Data）。
"标头"包含数据包的一些说明项，比如发送者、接受者、数据类型等等；"数据"则是数据包的具体内容。
"标头"的长度，固定为18字节。"数据"的长度，最短为46字节，最长为1500字节。因此，整个"帧"最短为64字节，最长为1518字节。如果数据很长，就必须分割成多个帧进行发送。

（2）MAC地址
上面提到，以太网数据包的"标头"，包含了发送者和接受者的信息。那么，发送者和接受者是如何标识呢？
以太网规定，连入网络的所有设备，都必须具有"网卡"接口。数据包必须是从一块网卡，传送到另一块网卡。网卡的地址，就是数据包的发送地址和接收地址，这叫做MAC地址

（3）广播
定义地址只是第一步，后面还有更多的步骤。
首先，一块网卡怎么会知道另一块网卡的MAC地址？
回答是有一种ARP协议，可以解决这个问题。这个留到后面介绍，这里只需要知道，以太网数据包必须知道接收方的MAC地址，然后才能发送。
其次，就算有了MAC地址，系统怎样才能把数据包准确送到接收方？
回答是以太网采用了一种很"原始"的方式，它不是把数据包准确送到接收方，而是向本网络内所有计算机发送，让每台计算机自己判断，是否为接收方。

3 网络层

IP层提供不可靠、无连接的服务，不可靠指的是不能保证IP数据包能够成功到达目的地；无连接表示IP数据报并不维护任何关于后续数据报的状态信息。

（1）IP协议，与IP协议配套的协议有以下三个
（2）ARP：地址解析协议，IP和mac地址的映射通常20分钟更新一次ARP表，ARP的功能主要是将逻辑的IP地址转化为对应的物理地址。
（3）ICMP：网络控制报文协议
（4）RARP：逆向地址解析协议，MAC映射成IP

五类互联网地址：
在这里插入图片描述
常用的命令：

ifconfig
ifconfig是对网络接口进行配置和查询的命令，ifconfig命令一般在引导时运行，以配置主机上的每个接口。
netstat
netstat主要用于提供系统的接口命令。可以使用相关参数打印出每一个接口的MTU、输入分组数、输入错误、冲突以及当前的输出队列长度。
traceroute(ICMP应用)
用于跟踪一个分组从源点到终点所经过的路径
Ping(ICMP应用)
主要用于测试主机之间的连通性。

4 传输层

网络层为主机之间提供逻辑通信，运输层为应用进程之间提供端到端的逻辑通信。

运输层的两个主要协议：

用户数据报协议UDP：

UDP 是无连接的；
UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）；
UDP 是面向报文的；
UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如直播，实时视频会议等）；
UDP 支持一对一、一对多、多对一和多对多的交互通信；
UDP 的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

传输控制协议TCP：

TCP 是面向连接的。（就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接）；
每一条 TCP 连接只能有两个端点，每一条TCP连接只能是点对点的（一对一）；
TCP 提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达；

TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据；
面向字节流。TCP 中的“流”（Stream）指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

TCP和UDP的各种应用：
在这里插入图片描述
几个常见的问题：

1、TCP为什么进行三次握手？四次挥手
三次握手：
在这里插入图片描述
三次握手是为了防止已经失效的报文传到B，因而产生错误。

2、TCP如何保证传输的可靠性？

（1）超时重传
（2）拥塞控制
（3）连接管理：握手和挥手机制保证连接的可靠性
（4）流量控制：点对点通信量的控制。控制发送端的发送数据的速率。
（5）确认机制

3、TCP和UDP的区别：

（1）TCP是面向连接的，udp是无连接的即发送数据前不需要先建立链接。
（2）TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。并且因为tcp可靠，面向连接，不会丢失数据因此适合大数据量的交换。
（3）TCP是面向字节流，UDP面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如IP电话和视频会议等）。
（4）TCP只能是1对1的，UDP支持1对1,1对多。
（5）TCP的首部较大为20字节，而UDP只有8字节。
（6）TCP是面向连接的可靠性传输，而UDP是不可靠的。

5 应用层

应用层相关的协议有很多，比如HTTP，这个后面会单独详细讲解HTTP相关的，还有我们所说的DNS协议，以及FTP等。
简单介绍几个应用层的协议

HTTP：超文本传输协议
DNS：域名和ip的映射
FTP：文件传输协议
SMTP：SMTP 的全称是“Simple Mail Transfer Protocol”，即简单邮件传输协议。它是一组用于从源地址到目的地址传输邮件的规范，通过它来控制邮件的中转方式。SMTP 协议属于 TCP/IP 协议簇，它帮助每台计算机在发送或中转信件时找到下一个目的地。SMTP 服务器就是遵循 SMTP 协议的发送邮件服务器。

补充一下其他两个邮件协议：

POP3：POP3是Post Office Protocol 3的简称，即邮局协议的第3个版本,它规定怎样将个人计算机连接到Internet的邮件服务器和下载电子邮件的电子协议。它是因特网电子邮件的第一个离线协议标准,POP3允许用户从服务器上把邮件存储到本地主机（即自己的计算机）上,同时删除保存在邮件服务器上的邮件，而POP3服务器则是遵循POP3协议的接收邮件服务器，用来接收电子邮件的。
IMAP：IMAP全称是Internet Mail Access Protocol，即交互式邮件存取协议，它是跟POP3类似邮件访问标准协议之一。不同的是，开启了IMAP后，您在电子邮件客户端收取的邮件仍然保留在服务器上，同时在客户端上的操作都会反馈到服务器上，如：删除邮件，标记已读等，服务器上的邮件也会做相应的动作。所以无论从浏览器登录邮箱或者客户端软件登录邮箱，看到的邮件以及状态都是一致的。

6、HTTP

HTTP对前端来说是必须掌握的知识，所以单独拿出来说。
HTTP 超文本传输协议，是用于从www万维网服务器传输超文本到本地浏览器的传送协议。
HTTP三点注意事项：

HTTP是无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
HTTP是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
HTTP是无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

6.1 http请求报文和响应报文

6.1.2 请求报文

一个http请求报文由请求行、请求头、空行和请求数据四个部分组成。如下图所示：
在这里插入图片描述

1 请求行

包括请求方法（GET、POST），URL、协议版本三个字段组成，中间用空格分隔。

根据HTTP标准，HTTP请求可以使用多种请求方法。
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
例如：

GET /index.html HTTP/1.1

请求方法：
HTTP/1.1中共定义了8种方法

OPTIONS - 返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*'的请求来测试服务器的功能性。（允许客户端查看服务器性能，比如服务器支持的请求方式等。）
HEAD- 向服务器索要与GET请求相一致的响应，但是返回的响应中没有具体的内容，用户获取报头。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。
GET - 向特定的资源发出请求。
POST - 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT - 向指定资源位置上传其最新内容。
DELETE - 请求服务器删除Request-URI所标识的资源。
TRACE- 回显服务器收到的请求，主要用于测试或诊断。
CONNECT - HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
PATCH - 用来将局部修改应用于某一资源，添加于规范RFC5789。

方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed）；当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）

GET和POST的区别：

（1）GET请求的长度有限制，POST没有（是因为GET请求用URL传参，URL的长度有限制1024字节）
（2）GET请求保存在浏览器历史记录中，POST请求不会
（3）GET请求可以被收藏为书签，POST不能
（4）GET请求可以被缓存，POST请求不会被缓存
（5）GET请求用于取回数据，POST用于提交数据
（6）GET方式提交数据，会带来安全问题，因为子啊URL中显示

2 请求头

请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“：”分隔，请求头部通知服务器有关于客户端请求的信息。

常见的请求头：

Accept: */*(客户端能接收的资源类型) 
Accept-Language: en-us(客户端接收的语言类型) 
Connection: Keep-Alive(维护客户端和服务端的连接关系) 
Host: localhost:8080(连接的目标主机和端口号) 
Referer: http://localhost/links.asp(告诉服务器我来自于哪里) 
User-Agent: Mozilla/4.0(客户端版本号的名字) 
Accept-Encoding: gzip, deflate(客户端能接收的压缩数据的类型) 
If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT(缓存时间)  
Cookie(客户端暂存服务端的信息) 
Date: Tue, 11 Jul 2000 18:23:51 GMT(客户端请求服务端的时间)

3 空行

最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。

4 请求数据

请求数据不在GET方法中使用，而在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。

5 实例

(1) GET

//请求首行
GET /hello/index.jsp HTTP/1.1

//请求头信息，因为GET请求没有正文
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cookie: JSESSIONID=369766FDF6220F7803433C0B2DE36D98

//空行

//因为GET没有正文，所以下面为空

（2）POST

// 请求首行
POST /hello/index.jsp HTTP/1.1

//请求头信息
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://localhost/hello/index.jsp
Cookie: JSESSIONID=369766FDF6220F7803433C0B2DE36D98
Content-Type: application/x-www-form-urlencoded 
Content-Length: 14 

// 这里是空行

//POST有请求正文
username=hello

6.1.2 响应消息

HTTP的响应也由三个部分组成，分别是状态行，响应头、空行和响应正文。

1 响应状态行

状态行的格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；
Status-Code表示服务器发回的响应状态代码；
Reason-Phrase表示状态代码的文本描述。
CRLF是回车换行

HTTP响应状态码：

1xx：指示信息–表示请求已接收，继续处理。
2xx：成功–表示请求已被成功接收、理解、接受。
3xx：重定向–要完成请求必须进行更进一步的操作。
4xx：客户端错误–请求有语法错误或请求无法实现。
5xx：服务器端错误–服务器未能实现合法的请求

具体如下表所示
在这里插入图片描述

2 响应头

详细的描述响应头
常用的响应头：

    Location: http://www.baidu.com(服务端需要客户端访问的页面路径) 
    Server:apache tomcat(服务端的Web服务端名)
    Content-Encoding: gzip(服务端能够发送压缩编码类型) 
    Content-Length: 80(服务端发送的压缩数据的长度) 
    Content-Language: zh-cn(服务端发送的语言类型) 
    Content-Type: text/html; charset=GB2312(服务端发送的类型及采用的编码方式)
    Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT(服务端对该资源最后修改的时间)
    Refresh: 1;url=http://www.it315.org(服务端要求客户端1秒钟后，刷新，然后访问指定的页面路径)
    Content-Disposition: attachment; filename=aaa.zip(服务端要求客户端以下载文件的方式打开该文件)
    Transfer-Encoding: chunked(分块传递数据到客户端）  
    Set-Cookie:SS=Q0=5Lb_nQ; path=/search(服务端发送到客户端的暂存数据)
    Expires: -1//3种(服务端禁止客户端缓存页面数据)
    Cache-Control: no-cache(服务端禁止客户端缓存页面数据)  
    Pragma: no-cache(服务端禁止客户端缓存页面数据)   
    Connection: close(1.0)/(1.1)Keep-Alive(维护客户端和服务端的连接关系)  
    Date: Tue, 11 Jul 2000 18:23:51 GMT(服务端响应客户端的时间)

在服务器响应客户端的时候，带上Access-Control-Allow-Origin头信息，解决跨域的一种方法。

与缓存相关的这里不做赘述，其中特别注意 HTTP content-Type

content-Type，内容类型，一般是指网页中存在的Content-type，用于定义网络文件的类型和网页的编码，决定浏览器以什么形式什么编码读这个文件，这就是经常看到一些Asp网页点击的结果却是下载到的一个文件或一张图片的原因。

content-type对照表

常用的content-Type有
text/plain 　　　　　　　　文本类型
text/css 　　　　　　　　 css类型
text/html 　　　　　　　　html类型
application/x-javascript 　　js类型
application/json　　　　　 json类型
image/png jpg gif　　　　　 image/*
(/.+.(png|jpg|gif)$/.test(pathname)) 匹配到图片

3 空行

空行表示响应头结束，下面是响应数据

4 响应数据

返回的数据是什么，响应数据这里是什么。

5 实例

在这里插入图片描述

6.4 http1.0/http1.1/http2.0

http1.1对比http1.0的区别是：
（1）缓存处理，在http1.0中主要使用header中的if-modified-since和Expires来作为缓存判断的标准，在http1.1中引入更多的缓存控制策略如E-tag，if-match和if-none-match等。
（2）带宽优化以及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接
（3）错误通知的管理：在HTTP1.1中新增了24个错误状态响应码
（4）长连接：http1.1支持长连接和请求流水线处理。在一个TCP连接上可以传送多个http请求和响应，减少了建立和关闭连接的消耗和延迟。在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

http1.x和http2.0的区别是：
（1）http2.0 基于二进制，http1.x是基于文本，2.0可以将传输信息分割为更小的信息或帧，并对他们进行二进制编码
（2）多路复用，即链接共享，即每一个request都是靠用作链接共享机制的，一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
（3）header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小
（4）服务端推送，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了

http1.1的长连接和2.0的多路复用的区别：

http1.0：一次请求-响应，建立一个链接，用完关闭；每次请求都要建立一个链接
http1.1：keep-alive，一次链接多个请求，一个请求一个响应（若干个请求排队串行单线程，可能造成线头阻塞）
http2.0：多个请求可同时在一个链接上并行执行某个请求任务耗时严重，不会影响到其它连接的正常执行
在这里插入图片描述

6.5 https加密

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。HTTPS经由HTTP进行通信，但是利用SSL/TLS来加密数据包，HTTPS开发的主要目的就是提供对网站服务器的身份认证，保护交换数据的隐私性和完整性。

1. TLS/SSL

首先介绍一下TLS和SSL的含义：
TCP（Transmission Control Protoco）传输层控制协议
TLS（Transport Layer Security）传输层安全协议
HTTP基于TCP协议，无连接，每次连接只处理一个请求，结束后断开连接；无状态，无法保持用户状态，使用cookie和session解决。
HTTPS是安全的HTTP协议，在HTTP和TCP之间加了TLS/SSL保证数据的安全传输。

2. HTTPS的安全性

HTTP 协议的不安全性体现在 3 个方面：

风险	描述	https解决方案
窃听风险	攻击者可以获知消息内容	消息加密
篡改风险	攻击者可以篡改消息内容	消息摘要
冒充风险	攻击者可以冒充他人参与通信	CA身份认证

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

所有信息都是加密传播，第三方无法窃听。
具有校验机制，一旦被篡改，通信双方会立刻发现。
配备身份证书，防止身份被冒充。

具体采用以下方法：

（1）防止窃听

防止路由上的攻击者，窃听到消息的内容，因次采用消息加密。

解决：采用对称加密算法来加密，但是前期对称加密的秘钥交换采用非对称加密来进行。客户端使用服务器的公钥加密对称加密的秘钥，这样只有拥有私钥的服务端可以获取到加密内容，也就是对称加密的秘钥。

（2）消息篡改

消息加密以后攻击者无法获取消息内容的含义，但是可以篡改消息内容，篡改之后接收方也无法感知。

解决：采用消息摘要算法可以验证数据的完整性，我们将要发送的消息进行摘要，连同消息一起发送给接受方，接收方拿到消息之后对消息做同样的摘要处理，对比摘要结果，就可以知道消息没有被篡改。

以上，可以解决消息的完整性和真实性的问题。

（3）冒充风险

中间人攻击（Man-in-the-middle Attack，MITM），是指攻击者在链路上伪装自己，与通信双方分别建立联系，并交换其所收到的书，使通讯的两端认为他们正在通过一个私密的连接与对象直接对话，但是整个会话被攻击者完全控制。
作为A和B通信路由上的攻击者M，作为中间人伪造自己的身份，A向B请求用于通信的PK_A，但是被中间人M截获，他伪造生成了假的公钥PK_M，发送给了A，同时向 B 请求并获取了 B 的公开密钥 PK_B，原来安全的通信过程 A(使用 PK_B 加密) -> 安全 -> B(使用 SK_B 解密)，现在变成了 A(使用 PK_M 加密) -> M(使用 SK_M 解密获取明文内容，再用 PK_B 加密，可能篡改数据) -> B(使用 SK_B 解密)

出现问题的原因在于，密钥在交换的初期是不安全的，网络上的通信双方，无法确定对方的身份，即无法获悉当前的公钥是不是自己想要的公钥。

解决：引入第三方公正作信用背书，第三方公正具有权威性，他和通信双方没有关系，接收方无条件新人公证机构，这种机构被称为CA（Certificate Authority）机构，即数字证书认证机构。CA机构与浏览器和操作系统的厂商进行合作，将公钥内在在浏览器和操作系统中，也就是不走网络传输了，这样一定程度上保证了公钥不会被窃取篡改。
服务器端Server将自己的消息（消息内容大致包括电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等）进行摘要之后，发给CA机构的AUTH签发证书，Server使用自己的是要对摘要进行加密，形成证书，并将证书和消息发送给Client，Client收到后，发现是 AUTH 的证书，同时对 AUTH 是信任的，则会使用 AUTH 的公钥对证书进行解密（这里涉及证书链的验证，其实要更加复杂），获取到消息摘要，同时对收到的消息进行摘要，对比，如果一致则说明内容没有被篡改，是可信的，因为生成加密数据的私钥只有 CA 机构才有，这一过程称为验证数字签名。

（4）CA 错误签发

除了上述三大风险，还有一个是CA错误签发，可以用证书锁来解决。

综上，对称加密通信 + 非对称加密交换密钥 + CA 认证身份 + 证书锁锁定证书指纹共同保证了 https 的安全性。

3. CA的安全性

作为全网 https 连接的权威公正，CA 的安全性至关重要

（1）安全保存CA

从根 CA 开始到直接给客户发放证书的各层次 CA，都有其自身的密钥对。CA 中心的密钥对一般由硬件加密服务器在机器内直接产生，并存储于加密硬件内，或以一定的加密形式存放于密钥数据库内。
所以 CA 密钥的安全性依赖于物理硬件的安全性，不通过网络传输避免了被攻击的可能。

CA 的公钥是厂商跟浏览器和操作系统合作，把公钥默认装到浏览器或者操作系统环境里。比如 firefox 就自己维护了一个可信任的 CA 列表，而 chrome 和 IE 使用的是操作系统的 CA 列表

（2）证书链

现在大的 CA 都会有证书链，证书链的好处一是安全，保持根 CA 的私钥离线使用。第二个好处是方便部署和撤销，即如果证书出现问题，只需要撤销相应级别的证书，根证书依然安全。

根 CA 证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。

（3）证书验证

证书是否是信任的有效证书，主要看以下几点

是否信任（信任机构签发）
是否有效（在有效期内）
是否合法（对方是否是合法持有者）
是否吊销

补充：数字证书的结构
因特网上的“ID 卡”——数字证书。数字证书(通常被称作“certs”，有点像 certs 牌薄荷糖)中包含了由某个受信任组织担保的用户或公司的相关信息。
数字证书中还包含一组信息，所有这些信息都是由一个官方的证书颁发机构(CA) 以数字方式签发的。
而且，数字证书通常还包括对象的公开密钥，以及对象和所用签名算法的描述性信息。任何人都可以创建一个数字证书，但并不是所有人都能够获得受人尊敬的签发权，从而为证书信息担保，并用其私有密钥签发证书。典型的证书结构如图所示
在这里插入图片描述

4. HTTPS握手

现在，安全 HTTP 是可选的。请求一个客户端(比如 Web 浏览器)对某 Web 资源执行某事务时，它会去检查 URL 的方案：

如果URL的方案为http，客户端就会打开一条到服务器端口80(默认情况下) 的连接，并向其发送老的 HTTP 命令。
如果URL的方案为https，客户端就会打开一条到服务器端口443(默认情况下) 的连接，然后与服务器“握手”，以二进制格式与服务器交换一些 SSL 安全参数，附上加密的 HTTP 命令。

开始加密通信之前，客户端和服务器首先必须建立连接和交换参数，这个过程叫做握手（handshake）。，SSL握手过程如下：

（1）client向服务器发送握手信息，告知自己支持的加密算法，摘要算法，安全层协议版本，随机数Random-Secret-C

（2）服务器随机生成本次握手需要的非对称加密的密钥对（私钥+公钥），将来用来传输对称加密秘钥；
服务端生成消息，内容包含随机数Random-Secret-S，确定的一组加密算法和摘要算法，服务端秘钥，域名信息等；
服务端对信息内容摘要，使用摘要信息向CA机构申请的签名证书；
服务器端向客户端发送消息和申请的证书；
如果需要双向验证，则请求客户端证书

（3）客户端验证服务端证书，提取服务端公钥
客户端从信任证书列表中发现是受信任的证书，会首先验证证书是否被信任、有效性、合法性等信息，验证过程参照上面的证书验证；
验证通过，客户端使用 CA 机构的公钥对证书解密，拿到消息的摘要，对真正的消息内容进行摘要，对比确定消息没有被篡改，则取出服务端公钥。
如果需要双向验证的话，向服务端发送自己的证书。
客户端生成随机数字 Pre-Master-Secret，将其进行摘要处理，使用服务端公钥对消息和摘要结果加密，发送给服务器，并发送一个编码改变通知，说明以后将会开始加密通信。

（4）生成对称加密密钥
如果需要双向验证的话，首先验证客户端证书，验证过程类似客户端验证，验证失败则断开连接
服务器使用私钥对收到的信息解密，对消息进行摘要对比无误，则说明对称加密的密钥没有被篡改，然后使用 Random-Secret-C,Random-Secret-S,Pre-Master-Secret 生成最终将要进行对称加密通信的密钥 Master-Secret；
服务器使用 Master-Secret 加密一段握手信息及其摘要，发送给客户端，并发送一个编码改变通知，说明以后将会开始加密通信

（5）客户端验证加密结果，握手结束
客户端使用 Random-Secret-C,Random-Secret-S,Pre-Master-Secret 生成同样的对称加密密钥 Master-Secret，使用密钥解密，并验证信息摘要，没有问题则握手结束；
后面的通信将会使用新生成的对称加密密钥加密进行。

图解这个过程：

还有一个简单版本的表述，更简单易懂一点：

客户端发送协议版本号、一个客户端产生的随机数client random，以及客户端支持的加密算法
服务器端收到客户端消息，确认双方使用加密算法，并发送数字证书和服务器随机生成的随机数Server random
客户端确认数字证书有效，然后生成一个新的随机数Premaster secret，并使用数字证书中的公钥加密这个随机数发给服务端
服务端使用自己的是要，获取客户端发送的随机数Premaster secret
客户端和服务器端根据约定的加密算法，使用前面的三个随机数，生成对话秘钥，用来加密接下来的对话。

在这里插入图片描述

6.3 http cookie和session

http解决无状态的方式就是通过cookie和session。
在这里插入图片描述
①cookie

cookie有哪些字段可以设置：name字段为一个cookie的名称。
value字段为一个cookie的值。

domain字段为可以访问此cookie的域名。

非顶级域名，如二级域名或者三级域名，设置的cookie的domain只能为顶级域名或者二级域名或者三级域名本身，不能设置其他二级域名的cookie，否则cookie无法生成。

顶级域名只能设置domain为顶级域名，不能设置为二级域名或者三级域名，否则cookie无法生成。

二级域名能读取设置了domain为顶级域名或者自身的cookie，不能读取其他二级域名domain的cookie。所以要想cookie在多个二级域名中共享，需要设置domain为顶级域名，这样就可以在所有二级域名里面或者到这个cookie的值了。
顶级域名只能获取到domain设置为顶级域名的cookie，其他domain设置为二级域名的无法获取。

path字段为可以访问此cookie的页面路径。比如domain是abc.com,path是/test，那么只有/test路径下的页面可以读取此cookie。

expires/Max-Age 字段为此cookie超时时间。若设置其值为一个时间，那么当到达此时间后，此cookie失效。不设置的话默认值是Session，意思是cookie会和session一起失效。当浏览器关闭(不是浏览器标签页，而是整个浏览器) 后，此cookie失效。

Size字段此cookie大小。

http字段 cookie的httponly属性。若此属性为true，则只有在http请求头中会带有此cookie的信息，而不能通过document.cookie来访问此cookie。

secure 字段设置是否只能通过https来传递此条cookie

②Session
Session机制是一种服务器机制，服务器使用一种类似于散列表的结构来保存信息
当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保

cookie数据存放在客户的浏览器上，session数据放在服务器上。
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

6.5 web消息通信

轮询
长连接
web socket

1、轮询：隔一段时间访问服务器，服务器不管有没有新消息都立刻返回。

2、长连接：页面向服务器发出请求，由服务器决定什么时候返回。（如果有新消息则立刻返回，没有的话就保持连接，直到有新消息才返回）

3、WebSocket：类似Java Socket，由Http请求模拟实现的Socket。它实现了浏览器与服务器全双工(full-duplex)通信——允许服务器主动发送信息给客户端。

参考文献

HTTPS详解
 https://segmentfault.com/a/1190000011675421
https://www.cnblogs.com/lauhp/p/8979393.html

curry的记录

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
前端之http

前言：一个不懂http的前端不是一个合格的前端，一个没有计算机网络知识前端不是不是一个好的研发，接下来我就要来复习一些计算机网络的知识，尤其是http，tcp/udp这些。1 互联网协议分层网络协议通常分为不同的层次进行，每一层分别负责不同的通信功能。如下图所示。每一层都有其各自的功能：1、物理层physical layer，把电脑连接起来的物理手段，主要规定了网络的一些电气特性，作...
复制链接

扫一扫