HTTP/HTTPS

五层模型

首先是经典的五层模型：应用层--传输层--网络层--数据链路层--物理层

物理层：主要作用是定义物理设备如何传输数据（电脑的硬件设备相关，网卡端口，网线连出去之后要有一条光缆，为我们传输几千公里以外的数据等）
数据链路层：在通信的实体间建立数据链路连接（物理设备可以把两台设备连接在一起，而这层就相当于是软件让两台设备创建了电路连接）
网络层：为数据在节点之间传输创建逻辑链路（假设我的电脑要去访问百度的服务器，如何去寻找百度服务器就是网络层做的事情）
传输层：向用户提供了可靠的端到端（end-end）服务，主要有两个协议TCP协议和UDP协议，网络层建立客户端与服务器端的连接之后要传输数据，那么如何传输，是在这一层定义的。传输层向高层屏蔽了下层数据通信的细节。
应用层：为应用软件提供了很多服务，主要有HTTP协议和FTP协议，构建于TCP协议之上，屏蔽了网络传输的相关细节
（OSI七层）将五层中的应用层又分为会话层，表示层以及应用层。
会话层：负责网络中两节点的建立，在数据传输中维护计算机网络中两台计算机的通信连接，并决定何时终止通信。
表示层：负责数据格式的转换，数据解析等。同时也对应用层的协议进行翻译。

HTTP协议的发展之路

HTTP/0.9：
内容十分简单，只有一个命令GET，对应get、post等请求方法；
没有HEADER等描述数据的信息
服务器发送完内容，就关闭TCP连接（在一个TCP连接上可以建立多个HTTP连接）
HTTP/1.0：
增加了很多命令，如post、put等
增加status code状态码和header数据描述以及操作的方法描述
多字符集支持、多部分发送、权限、缓存等
HTTP/1.1：
数据大部分都是字符串形式的，所以数据的分别片方式不太一样
持久连接keep-alive。使连接持续有效
pipeline管线化，可以在同一个连接里发送多个请求，但是服务器端是按请求顺序处理的（串行）
增加host和一些其他命令，有了host就可以在一台设备上同时启动多个服务，通过host可以定位到请求的是哪个软件服务（比如node，Java等）
HTTP/2：主要是为了解决HTTP1.1里面的一些性能低下的问题
所有数据都是以二进制传输的，（按帧传输）
所以同一个连接里面发送多个请求不再按照顺序来处理
头信息压缩以及推送等高效率的功能
HTTP1.1里面 header里面有很多字段都是字符串形式的，占用很多带宽，头信息压缩之后，有效地减少了带宽使用
HTTP1.1里面主动方永远是客户端，服务器端一直是被动方，举个栗子：当请求一个html页面的时候，服务器端先把html源代码发送给客户端，客户端解析到需要引用css和js的部分时再去向服务器端请求css和js文件
而HTTP2里面加入了推送的功能，就可以在客户端请求完html页面之后主动把它需要引用的css和js文件等推送过去，实现了三者的并行传输。

TCP三次握手

第一次握手：client给server发送一个创建连接的请求，带有标志位SYN=1，序列Seq=X，进入SYN_SEND状态，等待server确认。
第二次握手：server收到连接请求，就会开启一个socket接口，确认client的SYN（ACK=X+1），向client返回一个标志位SYN=1，再发一个自己的序列Seq=Y，进入SYN_RECV状态
第三次握手：client收到应答再发送给server一个应答ACK=Y+1，序列Seq=Z，双方进入ESTABLISHED状态，完成三次握手。
三次握手的原因：为了防止服务器端开启一些无用的连接，网络传输是有延时的，如果传输的过程当中客户端的请求被阻塞或者延迟，过一定的时间他没有收到服务器端的应答就会默认本次发送失效，重新再发一次请求，而隔了一段时间之后服务器端接收到了之前的请求，就回去给客户端响应，并且等待他的回应，但此时客户端认为自己没有发送这个请求，是不会响应的。
四次挥手关闭连接
第一次挥手：Clien发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
第二次挥手：Server收到FIN后，发送一个ACK给Client,Server进入CLOSE_WAIT状态。
第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，发送ACK给Server，Server进入CLOSED状态，完成四次握手.
四次挥手的原因：
当收到对方的FIN报文时，仅表示对方不再发送数据但还能接收收据，我们也未必把全部数据都发给了对方，所以我们可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方表示同意关闭连接。因此我们的ACK和FIN一般会分开发送。

URI

Uniform Resource Identifier/统一资源标识符
用来唯一标识互联网上的信息资源
包括URL和URN
URL：Uniform Resource Locator/统一资源定位符
http://user:pass@host.com:80/path?query=string#hash
http：协议
user:pass：用户密码，一般不用
host.com：资源定位，找到这台服务器所在互联网的位置。可以是IP，就可以直接找到目标服务器，也可以是域名，需要DNS解析才能找到目标服务器
80：端口，每一台服务器都有很多的端口，存放了很多的web服务，端口可以定位是具体的哪一个，HTTP协议默认是80，FTP是21，HTTPS是443
path：请求路径
query=string#hash：参数
URN：永久统一资源定位符，在资源移动之后还能被找到，但目前还没有成熟的使用方案

HTTP报文

请求报文
起始行：包含请求方式，请求地址，协议版本
首部：key-value值，告诉服务器端都要什么值，值要什么类型
空行：表示header部分结束了，到了数据部分
主体：数据部分
响应报文
起始行：协议版本，状态码，状态码的含义
首部：key-value值
空行：表示header部分结束了，到了数据部分
主体：响应的数据部分

HTTPS

HTTP是明文协议
1、传递的数据容易被偷窥和篡改（对称加密）
在每次发送真实数据之前，服务器先生成一把密钥，然后先把密钥传输给客户端。之后服务器给客户端发送真实数据的时候，会用这把密钥对数据进行加密，客户端收到加密数据之后，用刚才收到的密钥进行解密。如果客户端要给服务器发送数据，也是采用这把密钥来加密。

这种加密的密钥传输也是采用明文的方式，因此这种加密对于中间人来说跟明文其实没啥区别，反倒还多了一个加密解密的步骤。
2、密钥的传递问题（非对称加密，密钥是一对，公钥和私钥）
数学基础：两个超大的素数求乘积非常容易（私钥），但分解因子很麻烦（公钥）rsa算法
接收端和发送端分别拥有一对公钥和私钥，公钥是可以发送给对方的私钥不可以，加密的时候就先用对方的公钥和己方的私钥加密，再发送给对方，对方用自己的私钥解密。即用公钥加密的数据，只有对应的私钥才能解密；用私钥加密的数据，只有对应的公钥才能解密。