http/https

ISO 国际标准化组织

OSI 由ISO发布的网络互联模型，分7层

应用层（应用层、表示层、会话层） http/https协议

传输层 tcp协议-主要解决如何可靠的传递数据

网络层 ip协议-主要解决网络路由和寻址问题

数据链路层

物理层

http请求报文 = 请求行 + 请求头（header） + 请求体（body）

http请求行详解

①POST ②/users ③HTTP/1.1

①是请求方法，HTTP/1.1 定义的请求方法有8种：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE,最常的两种GET和POST，如果是RESTful接口的话一般会用到GET、POST、DELETE、PUT

②为请求对应的URL地址，它和请求头的Host属性组成完整的请求URL

③是协议名称及版本号

http响应行

①HTTP/1.1  ②200  ③OK

②为状态码

③为状态码的文本描述

各种请求方法的含义

幂等性：同一个请求无论调用多少次，效果一样，或者说与第一次一样

GET 不发送body，不修改服务器数据，幂等

POST 发送body，增加/修改数据

PUT 发送body，修改数据，幂等

DELETE 不发送body，删除数据，幂等

HEAD 同GET，但是返回数据中无body，用于下载文件前获取文件大小，幂等

关于HTTP请求GET和POST的区别

1.GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头＜request-line＞中），以?分割URL和传输数据，多个参数用&连接;例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

POST提交：把提交的数据放置在是HTTP包的包体＜request-body＞中。

因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变

2.传输数据的大小：

   首先声明,HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。 而在实际开发中存在的限制主要有：

   GET:特定浏览器和服务器对URL长度有限制，例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。

   因此对于GET提交时，传输数据就会受到URL长度的限制。

   POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。

3.安全性：

    POST的安全性要比GET的安全性高。比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存， (2)其他人查看浏览器的历史记录，那么别人就可以拿到你的账号和密码了

状态码的意义

1xx 临时消息 100服务器已接受请求，客户端可以继续操作，比如上传文件  101告诉客户端支持http2

2xx 成功 200请求成功 201创建成功

3xx 重定向  告诉客户端重新请求新的url

4xx 客户端错误 400请求无效 401需要授权 403禁止访问这个地址 404找不到地址/资源 405禁止访问这个资源 408超时

5xx 服务器错误 

header和body详解 各header对应的功能

Body是传输的数据，header是用来描述body数据的数据，叫meta data（元数据）

Host: twitter.com    //目标地址，用于在目标服务器上定位子服务器

Content-Type: application/json  //body的类型

Content-Length:2300  //body的长度

Location  //重定向的url

User-Agent  //用户代理，用来标识设备/浏览器的类型

Accept-Range: bytes  //响应报文中出现，表示服务器支持按字节来取范围数据

Range: bytes=<start>-<end>  //请求报问中出现，表示要取哪段数据

Content-Range:<start>-<end>/total  //响应报文中出现，表示发送的是哪段数据

Accept: text/html  //客户端能接受的数据类型

Accept-Charset: UTF-8  //客户端接受的字符集

Accept-Encoding: gzip  //客户端接受的压缩编码类型

Content-Encoding:gzip  //压缩类型

Cookie。//发送 Cookie

Set-Cookie  //设置 Cookie

Authorization  //授权信息

Cache-Control

no-cache:   //服务器告诉 Client 端，该内容可以缓存，但是再次请求的时候服务器需要知道缓存的内容是否失效

no-store:   //不许缓存

max-age:   //在失效日期内，Client 端随意访问

cache和buffer区别 rest到底是什么

Cache是保存以后很可能还会用到的数据

Buffer是在生产与消费过程中，存储没来得及消费的数据

Rest是一种架构风格，是基于HTTP协议的，可以理解称一种API的规范，比如查询都是GET请求，新增都是POST，修改是PUT，删除是DELETE等

编解码的含义

将数据从一种格式转换成另一种不同的格式，并且可以再转换回来，内容不变

Base64含义 用途 缺点  变种

Base64是一种编码算法，码表由64种字符组成，A-Z a-z 0-9 +/ 

用来将二进制数据（非文本数据）转换成字符串，方便传输、保存，比如用于url

缺点是数据会变长，且不具备加密效果

Base58 去掉了 IO io +/ ，方便手抄，用于比特币等领域

url %编码

浏览器地址不支持中文，所以使用“%编码”将中文转换成其它字符

压缩与解压缩的含义 目的 算法 和编解码的关系

压缩是将数据转换成另一种格式，以减少存储空间，解压缩可以将数据还原，所以本质上还是属于编解码

图片、音视频 编解码的含义 目的 算法

图像、音视频数据在计算机领域都是二进制数据，对其编码后就是常见的jpg、mp3、mp4等编码格式，使用时会将他们解码成原始数据

序列化 的含义 目的 算法

序列化是将虚拟内存中的对象数据，转换成一种可以存储/传输的格式，比如json、xml，方便存储和通信传输

对称加密

常见的有AES

非对称加密

用来签名和加密，常见的有DSA（只用来签名，签名和验证非常快）、RSA（签名、加密都可以）

签名时，是使用自己的私钥签名，对方收到数据后用公钥验证

加密时，是使用对方公钥加密，对方收到数据后使用私钥解密

Hash的定义 作用 实际用途 与编码和加密的关系

将任意数据转换成一段固定长度的很短的数据，也就是“摘要”，可以用来做完整性验证、签名，常见的有MD5、SHA1、SHA256，摘要算法用来加密不是绝对安全的，可以被还原，“加盐”（原数据追加随机数并保存）也只是提高了难度，使用时需要注意场景

理论上hash之后不能还原，所以不属于编码。做数据签名时，如果直接对原数据签名，数据量太大，传输成本高，所以先用hash算法做数据摘要，再将摘要进行签名（签名过程采用非对称加密）

字符集和编码的关系

字符集（Charset）：是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。

字符编码（Character Encoding）：将字符集中的文字和符号转换成计算机可以识别的数

常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。ASCII只能用于现代美国英语，所以被Unicode（统一码）代替。

登录与第三方授权的区别 http确认授权的2种方式

待学习

Cookie的原理和工作方式

待学习

Authorization首部的原理和工作方式

待学习

Tcp/ip协议族的概念 分层图解 各层含义

应用层、传输层、网络层、数据链路层、物理层

什么是tcp连接、建立与关闭

Tcp是面向连接的，传输之前需要先建立端到端的连接

Tcp传输的单位是tcp报文，格式如下

序列号：因为在TCP是面向字节流的，他会将报文度分成一个个字节，给每个字节进行序号编写，比如一个报文有900个字节组成，那么就会编成1-900个序号，然后分几部分来进行传输，比如第一次传，序列号就是1，传了50个字节， 那么第二次传，序列号就为51，所以序列号就是传输的数据的第一个字节相对所有的字节的位置。

确认应答：如刚说的例子，第一次传了50个字节给对方，对方也会回应你，其中带有确认应答，就是告诉你下一次要传第51个字节来了，所以这个确认应答就是告诉对方要传第多少个字节了

首部长度：就是首部的长度，

保留：给以后有需要在用，这个保留的位置放的东西是跟控制位类似的

控制位：目前有的控制位为6个

URG:紧急，当URG为1时，表名紧急指针字段有效，标识该报文是一个紧急报文，传送到目标主机后，不用排队，应该让该报文尽量往下排，让其早点让应用程序给接受。

ACK:确认，当ACK为1时，确认序号才有效。当ACK为0时，确认序号没用

PSH：推送，当为1时，当遇到此报文时，会减少数据向上交付，本来想应用进程交付数据是要等到一定的缓存大小才发送的，但是遇到它，就不用在等足够多的数据才向上交付，而是让应用进程早点拿到此报文，这个要和紧急分清楚，紧急是插队，但是提交缓存大小的数据不变，这个推送就要排队，但是遇到他的时候，会减少交付的缓存数据，提前交付。

RST:复位，报文遇到很严重的差错时，比如TCP连接出错等，会将RST置为1，然后释放连接，全部重新来过。

SYN：同步，在进行连接的时候，也就是三次握手时用得到，下面会具体讲到，配合ACK一起使用

FIN：终止，在释放连接时，也就是四次挥手时用的。

三次握手

同时发起连接时

四次挥手

同时关闭连接时

什么是tcp长连接、为什么需要长连接、如何实现

首先纠正一点，http“连接”的说法是不恰当的，http在应用层，并没有“连接”这一说法，真正负责连接的是传输层的tcp，应该叫tcp连接。

一般的tcp连接，在数据传输完之后会断开，是短连接。但是在频繁传输数据的时候，重复建立连接、断开连接会消耗资源和时间，这时就需要保持tcp连接一段时间，直到一定时间内没有请求才会超时断开。

通过在http header中添加 Connection：keep-alive实现，可以指定超时时间，http1.0只有短连接，http1.1默认开启长连接，并设置了超时时间，操作次数限制

长连接用于操作频繁，点对点通讯，连接数不多的情况，例如数据库

短连接用于并发量大，无需频繁操作的情况，例如http服务

Https 定义、 工作原理、 TLS建立的完整过程 

Hyper Text Transfer Protocol over SecureSocket Layer，建立在安全socket层次上的超文本传输协议，可以认为HTTPS = HTTP+SSL。HTTPS与HTTP、TCP的关系如下：

SSL/TLS层次和TCP很类似，双方建立TCP连接之后，需要再建立安全连接。与TCP连接一样，SSL连接本质上，是对双方安全信息的记录，并不是一个真正意义上的连接。HTTP通过安全连接，即可与目标主机进行安全的通信，不怕被监听、篡改、冒充身份。

https工作原理

1.为啥用https？

http使用明文传输，容易被窃取和篡改；

https会对数据进行加密，传输的是密文，更加安全

2.使用对称加密？

NO，密钥很容易被盗取

3.使用非对称加密？

NO，效率低

4.最佳方案？

两者结合，服务端持有私钥，访问端持有公钥，随机生成一个“密钥”，双方通过非对称加密传输数据，协商好“密钥”后，就可以放心进行对称加密了。

5.访问端的公钥怎么来的？

首先访问端可能是浏览器，也可能是客户端，浏览器不可能事先保存所有网站的公钥，客户端也不可能把公钥写进代码，很容易被反编译拿到，所以这个公钥应该是由服务器返回的，而且还能动态更新。

但是服务器返回的公钥有被篡改的风险，访问端一旦使用了假的公钥进行加密，传输的数据就能被人以假的私钥解密。

6.那么如何保证公钥的正确性？

访问端判断不了公钥是否正确，因此需要引入第三方来帮助判断，也就是CA机构（数字证书认证机构）。具体原理是这样的：

1、服务器相关人员拿着公钥和money去向CA机构申请证书

2、CA机构将公钥、域名、有效期等信息，通过CA机构自己的私钥进行加密，加密后的数据就是证书，交给服务器保管好

3、访问端向服务器发起https连接时，服务器将证书传送到访问端

4、访问端使用自己内置的CA机构公钥（浏览器、pc、手机等都会在系统预置所有CA机构的公钥）对证书进行解密，如果解密成功，且解析出的域名与正在访问的域名一致，就拿到了正确的公钥，否则验证证书失败并断开连接

5、拿到公钥之后进行协商密钥，传输数据等流程..

TLS建立过程

1、客户端请求服务器建立安全连接，附加客户端支持的SSL与TLS版本、支持的加密算法版本、随机数。

加密算法与安全协议版本有很多，但服务不一定支持最新版本的协议预算法。所以客户端把所以支持的版本发送给服务器，让服务器去选择。

随机数非常重要，前面讲hash算法的时候讲到，随机数是一个动态因子，让hash算法更加安全。同时，随机数也参与了对称密钥的生成。

2、服务器响应请求，附加选择的协议版本、加密算法版本、服务器随机数。

服务器从客户端支持的协议版本中，选择一套自己最喜欢的。

为了辨别消息是由哪一方加密并发出的，需要准备两个对称密钥。因此服务器也需要产生一个随机数。

3、服务器向客户端发送证书。

服务器向客户端发送自己证书，其中就包含了服务器的公钥。

4、服务器发送hello done表示hello阶段结束。

5、客户端验证证书，拿到服务器公钥；利用两个随机数，生成pre-master secret，并使用服务器的公钥加密发送给服务器。

pre-master secret是一个非常重要的东西，双方利用pre-master secret生成master-secret，利用前面的两个随机数生成两个对称加密密钥和两个HMAC密钥，两对密钥分别用于客户端加密和服务器加密。

6、客户端发送changeCipherSpec提示服务器此后使用pre-master secret产生的密钥加密通信。

7、客户端发送FIN报文，表示结束。

8、服务器也发送changeCipherSpec报文。

9、服务器也发送FIN报文，表示结束。

10、双方可以开始安全通信了。

至此，对于HTTPS的加密流程，已经比较清晰了。

HTTPS要解决的就是计算机网络中的安全问题，不同问题的解决方法要清楚：

防止消息监听：加密

防止消息篡改：hash算法

验证身份：数字证书