http和https

HTTP
http是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。
http通常承载于TCP之上，有时也承载于TLS或SSL协议层之上，这就是常说的http
http 无状态协议，同一个客户的这次请求和上次请求没有对应关系。

HTTP协议的主要特点可概括如下：

1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

TCP
TLS
SSL
http 端口 80
https 端口443
缺点：
由于这次请求和上次请求没有对应关系。
所示这种问答式交互。使http协议模型异常简单。
但是交互也存在问题
如：
服务器端不会主动向客户端push，
一问一答也会使 TCP 链接频繁简历和断开。导致其效率不高
所以 SPDY 协议应用而生
SPDY 协议好处
优化了浏览器和服务器之间的通信
支持流复用， 具备优先级的请求，主动发起请求，强制SSL安全传输等先进的特性。
目前 chrome 和 Firefox 浏览器均支持SPDY协议
抓包软件主要有
IRIS、Wireshark等，
专门抓取http包的软件有
HttpWatch、IE Analy zer、Fiddler、Charles等
http协议中一些主要的概念
1、请求
请求方法有八个：
get,post,head,put,delete,trace,connect,options
2、响应
http响应由三个部分组成：状态行、消息报头、响应正文
100
200
300
400
500
3、报头
http消息报头包括:
普通报头:只有少数报头用于所有的请求和响应信息，但不用于被传输的实体，只用于传输的消息
请求报头:允许客户端向服务器端传递请求附加信息以及客户端自身的信息
如：UA头、Accept等
响应报头:允许服务器传递不能放在状态行中的附加响应信息以及关于服务器的信息和对Request URL所标示的资源进行下一步访问的信息。
实体报头:定义了关于实体正文和请求所标识的资源的元信息，例如有无实体正文。
HOST：头域指定请求资源的internet主机和端口号，必须表示请求 URL的原始服务器或网关的位置。
User Agent：简称UA，内容包含发憷请求的用户信息。通常UA包含浏览者的信息，主要是浏览器的名称版本和所用操作系统。
Accept:告诉服务器可以接受的文件格式.通常这个值在各种浏览器中都差不多.不过WAP浏览器素能接受的格式要少一些，这也是用来区分WAP和计算机浏览器的主要依据之一.
Cookie:Cookie分两种，一种是客户端向服务器发送的，使用Cookie报头，用来标记一些信息;另一种是服务区器发送给浏览器的，报头为Set Cookie.二者主要的区别为Cookie报头的value里可以有多个Cookie值，并且不需要显式指定domain等。而Set Cookie报头里一条记录只能有一个Cookie的value，需要指明domain、path等。
名字+： +空格+值
注意 消息报头域的名字是不区分英文大小写的。报头都是自解释。
我们给HTTP举个例子：
假设你现在正坐在教室里上课，现在你非常想和走道旁的迷人的TA说一些话，一般这个时候你会用“传纸条”的方式来交流。而这个方式和TCP/IP协议基本的工作模式十分相像：
通过小动作引起对方注意；
对方以多种可能的方式（注视、肢体语言等）回应于你；
你确认对方感知到你后，将纸条传给对方；
对方阅读纸条；
对方给予你阅读后的反应；
怎么样，这个流程是不是很熟悉？
如果你要传递纸条的TA距离你很远怎么办？HTTP协议就是指你在纸条上写明你要传给的TA是谁，或者TA的座位在哪，接着只需要途径的同学拿到纸条后根据纸条上的指示依次将纸条传过去就OK了。
这个时候问题来了：途径的同学完全可以观看并知道你在纸条上写了什么。 这就是HTTP传输所面临的问题之一：中间人攻击，指消息传递的过程中，处在传递路径上的攻击者可以嗅探或者窃听传输数据的内容。

HTTPS

对称加密是最快速、最简单的一种加密方式，采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。对称加密是用一个密钥来解密的
非对对称加密是需要公钥和私钥 如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密; 如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥
HTTPS针对这个问题，采用了“加密”的方式来解决。最著名原始的加密方法就是对称加密算法了，就是双方约定一个暗号，用什么字母替换什么字母之类的。现在一般采用一种叫AES（高级加密算法）的对称算法。
对称加密算法既指加密和解密需要使用的密钥key是一样的。
AES在数学上保证了，只要你使用的key足够长，破解几乎是不可能的（除非光子计算机造出来了）
我们先假设在没有密钥key的情况下，密文是无法被破解的，然后再回到这个教室。你将用AES加密后的内容噌噌噌地写在了纸条上，正要传出去的时候你突然想到，TA没有key怎么解密内容呀，或者说，应该怎么把key给TA？
如果把key也写在纸条上，那么中间人照样可以破解窃听纸条内容。也许在现实环境中你有其他办法可以把key通过某种安全的渠道送到TA的手里，但是互联网上的实现难度就比较大了，毕竟不管怎样，数据都要经过那些路由。
于是聪明的人类发明了另一种加密算法——非对称加密算法。这种加密算法会生成两个密钥（key1和key2）。凡是key1加密的数据，key1自身不能解密，需要key2才能解密；凡事key2加密的数据，key2自身不能解密，只有key1才能解密。
目前这种算法有很多中，最常用的是RSA。其基于的数学原理是：
两个大素数的乘积很容易算，但是用这个乘积去算出是哪两个素数相乘就很复杂了。好在以目前的技术，分解大数的素因确实比较困难，尤其是当这个大数足够大的时候（通常使用2的10次方个二进制位那么大），就算是超级计算机，解密也需要非常长的时间。
现在就把这种非对称加密的方法应用在我们教室传纸条的场景里。
你在写纸条内容之前先用RSA技术生成了一对密钥k1和k2.
你把k1用明文传了出去，路经也许有人会截取，但是没有用，k1加密的数据需要k2才可以破解，而k2在你自己手中。
k1传到了目的人，目的人会去准备一个接下来准备用于对称加密（AES）的传输密钥key，然后用收到的k1把key加密，传给你。
你用手上的k2解出key后，全教室只有你和你的目的人拥有这个对称加密的key，你们俩就可以尽情聊天不怕窃听啦~
这里也许你会有问题，为什么不直接用非对称加密来加密信息，而是加密AES的key呢？因为非对称加密和解密的平均消耗时间比较长，为了节省时间提高效率，我们通常只是用它来交换密钥，而非直接传输数据。
然而使用非对称加密真的可以防范中间人攻击吗？虽然看上去很安全，但是实际上却挡不住可恶的中间人攻击。
假设你是A，你的目的地是B，现在要途径一个恶意同学M。中间人的恶意之处在于它会伪装成你的目标。
当你要和B完成第一次密钥交换的时候，M把纸条扣了下来，假装自己是B并伪造了一个key，然后用你发来的k1加密了key发还给你。
你以为你和B完成了密钥交换，实际上你是和M完成了密钥交换。
同事M和B完成一次密钥交换，让B以为和A你完成了密钥交换。
现在整体的加密流程变成了A（加密链接1）->M(明文)->B(加密链接2)的情况了，这时候M依然可以知道A和B传输的全部消息。
这个时候就是体现HTTPS和传纸条的区别了。在教室里，你是和一位与你身份几乎对等的的对象来通信；而在访问网站时，对方往往是一个比较大（或者知名）的服务者，他们有充沛的资源，或许他们可以向你证明他们的合法性。
此时我们需要引入一个非常权威的第三方，一个专门用来认证网站合法性的组织，可以叫做CA（Certificate Authority）。各个网站服务商可以向CA申请证书，使得他们在建立安全连接时可以带上CA的签名。而CA得安全性是由操作系统或者浏览器来认证的。
你的Windows、Mac、Linux、Chrome、Safari等会在安装的时候带上一个他们认为安全的CA证书列表，只有和你建立安全连接的网站带有这些CA的签名，操作系统和浏览器才会认为这个链接是安全的，否则就有可能遭到中间人攻击。
一旦某个CA颁发的证书被用于的非法途径，那么这个CA之前颁发过的所有证书都将被视为不安全的，这让所有CA在颁发证书时都十分小心，所以CA证书在通常情况下是值得信任的。
正如声网Agora.ioWebSDK考虑数据安全问题，限制了http访问get User Media接口，只能通过https方式访问。所以会出现用http在Chrome浏览器（47以上版本）中访问Agora服务失败，我该怎么办？
AgoraWeb解决方案基于WebRTC技术建立浏览器间的音视频通信，在WebRTC协议中，浏览器通过getUserMedia接口获取视频(通过摄像头)和音频(通过麦克风)数据，GoogleChrome是支持WebRTC的主流浏览器之一，在v47及以上版本，考虑到数据安全问题，限制了http访问get User Media接口，只能通过https方式访问。除了chrome浏览器外，Opera浏览器在v34版本后也跟进了对http的限制，Firefox暂时没有此更新。但是考虑到https是WebRTC协议推荐的安全访问方式，建议客户统一通过https来访问AgoraWeb服务，也能兼容各浏览器平台。