通过浏览器和服务器进行数据交互，进行超文本（文字、图片、视频等）传输的规定，规定了超文本传输要遵守的规则
特点：
1，HTTP协议是无状态的，每次HTTP请求都是独立的，任何两个请求之间没有必然的联系，当然实际应用种并不完全如此，HTTP引入了Cookie和Session机制来关联请求
2，多次HTTP请求，在客户端请求网页时多数情况下并不是一次请求就能成功，服务端首先是响应HTML页面，然后浏览器收到响应后发现HTML页面还引用其他的资源，例如CSS、JS文件，图片等，还会自动发送HTTP去请求这些需要的资源，现在的HTTP版本支持管道机制，可以同时请求和响应多个请求，大大提高效率
3，基于TCP协议，HTTP协议目的是规定客户端和服务端数据传输的格式和数据交互行为，并不负责数据传输的细节，底层是基于TCP实现的，现在使用的版本当中是默认持久连接的，也就是多次HTTP请求使用一个TCP连接
报文由三部分组成：
1，请求报文：
在请求报文中，开始行就是请求行
请求报文由请求行、请求头、内容实体组成。每一行的末尾都有回车和换行
在内容实体和请求头之间另外有一个空行。
其中，
请求行就是请求方法，请求URL、协议版本
请求头是键值对的形式存在，key-value的形式
（空行）
内容实体就是要传输的数据
2，响应报文：
响应报文的开始行是状态行
响应报文由状态行、响应头、响应实体组成
其中，
第一行是状态行，包括三项内容，HTTP的版本，状态码，解释状态码的简单短语
在一个回车之后是响应头，也是键值对的形式存在，key-value
（空行）
响应实体就是要传输的数据
请求方法： 是客户端用来告知服务器其动作意图的方法，常用4种
1，GET方法：获取资源，用来请求已被URL识别的资源，也就是指定服务器处理请求之后响应的内容
2，POST：传输实体主体，POST的目的是传输
3，PUT：传输文件，文件内容包含在请求报文的实体种，然后请求保存URL指定的服务器位置
4，DELETE：删除文件，与PUT相反，DELETE是要求返回URL指定的资源
一些状态码：
1，200，OK
2，204，没有数据实体返回，也不允许有实体内容返回，比如说HEAD请求，可能就会返回204 no content，因为HEAD就是只获取头信息
3，206，客户端使用Content-Range指定了需要的实体数据的范围，然后服务端处理请求成功之后返回用户需要的这一部分数据而不是全部，执行的请求就是GET。返回码就是206：Partial Content
4，301永久性重定向： 该状态码表示请求的资源已经被分配了新的URL，以后应该使用资源现在指定的URL。也就是说如果已经把资源对应的URL保存为书签了，这是应该按照Location首部字段提示的URL重新保存
HTTPS是一种安全协议，在访问HTTPS网站数据会加密传输，是以安全为目标的HTTP通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。
HTTPS在HTTP的基础上加了SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。HTTPS存在不同于HTTP的默认端口和一个加密/身份验证层，HTTPS提供了身份验证于加密通讯方法
区别：
传输信息安全性不同（means那个也安全只是安全性不同？）、连接方式不同、端口不同（80 443）、证书申请方式不同
一、 传输信息安全性不同：
http协议是超文本传输协议，信息是明文传输，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息
（嗷嗷嗷，这才是不同的重点嘛，信息是明文的，截取了就能看懂了）
https是具有安全性的ssl加密传输协议，为浏览器和服务器时间的通信加密，确保数据传输的安全
====》
HTTPS内容加密，采用混合加密技术，中间者无法直接查看明文内容
验证身份：通过证书认证客户端访问的是自己的服务器
保护数据完整性：防止传输的内容被中间人冒充或者篡改
混合加密：结合非对称加密和对称加密技术，客户端使用对称加密生成密钥对传输数据进行加密，然后使用非堆成加密的公钥再对密钥进行加密。所以网络上传输的数据是被密钥加密的密文和用公钥加密后的秘密密钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的密钥，便无法获取到明文数据
主要是为了对信息加密，对内容进行加密
SSL/TLS = 非对称加密算法交换对称密钥+数字证书验证身份（验证公钥是否是伪造的）+利用对称密钥加解密后续传输的数据
对称加密算法： AES DES RC4
加密和解密使用相同密钥的算法，要求发送方和接收方在安全通信之前，上顶一个对称密钥。对称算法的安全性完全依赖于密钥，密钥泄漏就意味着任何人都可以对他们发送或接收消息解密，所以密钥的保密性对通信至关重要
对称加密的优点：计算量小、加密速度快、加密效率高
缺点：交易双方都使用同样的密钥，安全性得不到保证；每次使用对称加密算法时，doux幼使用其他人不知道的唯一密钥，这会使得发收信息双方所拥有的钥匙数量呈现几何级数增长，密钥管理成为负担
非对称加密算法： RSA ECC DH
在非对称密钥交换算法出现以前，对称密钥的最主要缺陷就是不知道如何在通信双方之间传输对称密钥，而又不让中间人窃取。非对称密钥交换算法诞生之后，专门针对对称密钥传输做加解密，使得对称密钥的交互传输变得非常安全了
非对称加密更加安全，但是也存在两个致命的缺点：
1，CPU计算资源消耗非常大，一次完全TLS握手，密钥交换交换时的非对称加密计算量占整个握手过程的90%以上，而对称加密的计算量只相当于非对称加密的0.1%。就是CPU消耗非常大的意思
2，非对称加密算法对加密内容的长度有限制，不能超多公钥长度，
所以非对称加解密目前只能用来作为对称密钥交换或者CA签名，不适合用来做应用层内容传输的加解密
**数字摘要：**通过单向hash函数对原文进行哈希，将需要加密的明文“摘要”成固定长度（128bit）的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文
数字签名技术:
再仔细串一下：
HTTP严重的缺点就是不安全：通过使用明文（不加密），内容可能会被窃听，比如账号信息容易泄漏；比如不验证通信方的身份，有可能会遭遇伪装，比如访问假的淘宝……；无法证明报文的完整性，所以有可能已遭篡改，比如网页上植入垃圾广告，视觉污染……
HTTP的上述安全问题，可以用HTTPS的方式解决，也就是通过引入SSL/TLS层，使得在安全上达到了极致
请求报文：请求行+首部行+空行+实体主体
请求行由请求方法字段、URL字段和HTTP协议版本字段 3个字段组成，它们用空格分隔，如get /index.htm HTTP/1.1
HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT
1 常见的GET：
这是最常见的一种请求方法，当客户端要从服务器种读取文档时，当点击网页上的链接或者通过在浏览器的地址栏输入网址来浏览网页，使用的都是GET方法。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。
使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问好（？）代表URL的结尾于请求参数的开始
传递参数长度受限制
http://www.google.cn/search?hl=zh-CN&source=hp
&q=domety&aq=f&oq=
地址中？之后的部分就是通过GET发送的请求数据，各个数据之间用&隔开。
显然这种方式不适合传送私密数据，另外，由于不同的浏览器对地址的字符限制也有所不同，一半最多只能识别1024个字符，所以如果需要传送大量数据的时候，不适合使用GET方法
2 POST:
POST方式可以允许客户端给服务器提供较多的信息，POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，这样POST方式对传送的数据大小没有限制，而且也不会显示在URL中
3HEAD
HEAD就像GET，只不过服务端接收到HEAD请求后只返回响应头，而不会发送响应内容。当我们只需要查看某个页面的状态的时候，使用HEAD是非常高效的，因为在传输的过程中省去了页面内容
GET和POST的区别：
1 Get方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等
而POST方法则是相反操作，它像URI指定的资源提交数据，数据就放在报文李
比如我们提交留言，浏览器就会执行一次POST请求，把“我”输入的 留言文字放进报文body里，然后拼接好POST请求头，通过TCP协议发送给服务器
2 GET和POST方法在【安全】和【幂等】上的关系
【安全】：在HTTP协议里，所谓的安全是指请求方法不会破坏服务器上的资源
【幂等】：幂等意思是多次执行相同的操作，结果都是相同的
那么很明显GET方法就是安全幂等的，因为它是“只读”操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的
POST因为是“新增或者提交数据”的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的
3，请求数据放置的位置：
GET提交，请求的数据会附在URL之后，就是把数据放在HTTP协议头中，以？分割URL和传输数据，多个参数用&连接
如果是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，所以我们看到的%XX为该符号以16进制表示的ASCII
POST提交，把提交的数据放置在是HTTP包的包体中
4，传输数据的大小：
首先明确，HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制，而在实际开发中存在的限制主要有：
GET：特定浏览器和服务器对URL长度有限制，因此对于GET提交时，传输数据就会受到URL长度的限制
POST：由于不是通过URL传值，理论上数据不受限，但是实际上各个web服务器会规定对POST提交数据大小进行限制
5，安全性
POST安全性要比GET的安全性高，这边的安全性和上边的安全幂等不是一个概念。上面的“安全”的含义仅仅是不对数据修改，而这边的安全是真正的Security：比如通过GET提交数据，用户名和密码将明文出现在URL上，因为1）登录页面有可能被浏览器缓存，2）其他人查看浏览器的历是记录就可以拿到你的账号和密码了
6，GET和POST的本质区别：
使用GET，form中的数据将编码到url中，而使用POST的form中的数据则在http协议的hewader中传输，在使用上，当且仅当请求幂等时使用GET，当请求会改变服务器数据或者状态时用POST
HTTPS在HTTP与TCP之间加入了SSL/TLS协议，进行了：
信息加密：交互信息无法被窃取，
校验机制：无法篡改通信内容，篡改了就不能正常显示
身份证书：证明淘宝时真的淘宝
是如何解决的：
1，混合加密的方式实现信息的加密性，解决了窃听的风险
2，摘要算法的方式实现了完整性，它能够为数据生成独一无二阿指纹，指纹用于校验数据的完整性，解决了篡改的风险
3，将服务器公钥放入到数字证书中，解决了冒充的风险
密码学基础：
对称密钥：又叫私钥密钥，即信息的发送方和接收方使用同一个密钥去加密和解密数据，其特点是：算法公开，加密和解密的速度快，适合于对大量数据进行加密。常见的对称加密算法有DES, 3DES, TDEA, DEA等
由于对称加密的算法是公开的，所以一旦私钥被泄漏，那么密文就很容易被破解，所以对称加密的缺点是密钥安全管理困难
非对称加密：又叫做公钥加密，对称加密中如果有一方将密钥泄露了，那么整个通信过程就会被破解，而非对称加密使用一堆密钥，即公钥和私钥，二者成对出现。私钥被自己保存，不能对外泄漏，主要算法有RSA、ECC等
数字证书：之所以非对称密钥会不安全，是因为客户端不知道这把公钥是否是服务器的，因此我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的
解决这个问题的方式就是使用数字证书
流程：
-找到一个拥有公信力、大家都认可的认证中心CA
-服务器在给客户端传输公钥的过程中，会把公钥以及服务器的个人信息通过Hash算法生成信息摘要
-为了防止信息摘要被人调换，服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名
-最后还会把原来没Hash算法之前的个人信息以及公钥和数字签名合并在一起，形成数字证书
当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把这两份信息摘要进行对比。如果一样，则证明这个人就是服务器，否则就不是
关于CA的公钥怎么拿给客户端，服务器又怎么有CA的私钥：
其实，有些服务器一开始就向认证中心申请了这些证书了，客户端也是会内置这些证书，即CA的公钥已事先置入到了浏览器或操作系统中了
所以这就是要借助第三方权威机构CA，将服务器公钥放在数字证书中，只要证书是可信的，公钥就是可信的
Cookie：在客户端访问某个地址时，会将请求交到服务器进行处理，在发送请求的时候，浏览器会将页面的头部信息一并交到服务器端进行处理。在处理的过程中，Cookie 在服务器端生成 ，在此同时，可以将一些需要保存的信息，存放到此 Cookie 中。生成 Cookie 对象时，需要确定具体的名称及具体的值，可以设置当前 Cookie 的过期时间，设置过期时间后，就相当于持久化了 Cookie 中的数据，此时的 Cookie 会以之前的 Cookie 名称，保存在客户端。
如果不设置过期时间，则当前 Cookie 的生命期是浏览器会话期间，一旦关闭了该浏览器，当前的Cookie 就会不存在了，此时的 Cookie 信息是保存在内存中。在服务器端，处理完后，会将生成的 Cookie ，随着 Http 响应，会在 Http 响应头中，加上Cookie 信息，浏览器接受到响应后，会按照 Http 响应头里的 Cookie ，在客户端建立 Cookie 。在下次客户进行请求的时候，Http 会附带着已经存储过的 Cookie，一并发送到服务器。一个域，在客户端建立的所以 Cookie 都是可以共享的，只要 Cookie 没有过期。
Session：
生成session的同时会生成一个与之相关联的sessionID， 此sessionID的存储时需要cookie来完成的，sessionID的值 是一个既不会重复又不容易被找到规律以仿造的字符串。SessionID会随着此次 Http 响应，一并返回到客户端，并保存在客户端中。
到当前请求再次发出后，该 SessionID会随着 Http 头部，传到服务器中，
服务器依据当前 SessionID 得到与之对应的 Session.
token：
验证sessionID：用户信息+密钥 对数据做一个签名，把签名和数据一起作为token
不保存token，当用户把token发过来的时候，再用同样的算法和密钥，对数据再计算一次签名，和token中的签名做个比较，如果相同就安全可以直接去取用户信息，如果不同那么数据部分肯定被人篡改过。
Token中的数据是明文保存的，还是可以被人看到的，所以不能再其中保存像密码这样的敏感信息
