[网络协议]HTTP 基础

?

OSI

TCP/IP

TCP/IP 协议:是传输层的一个面向连接的安全可靠的一个传输协议
三次握手的机制是为了保证能建立一个安全可靠的连接:
那么第一次握手是由客户端发起，客户端会向服务端发送一个报文，在报文里面：SYN 标志位置为 1，表示发起新的连接。当服务端收到这个报文之后就知道客户端要和我建立一个新的连接，于是服务端就向客户端发送一个确认消息包，在这个消息包里面：ack 标志位置为 1，表示确认客户端发起的第一次连接请求。
以上两次握手之后，对于客户端而言：已经明确了我既能给服务端成功发消息，也能成功收到服务端的响应。但是对于服务端而言：两次握手是不够的，因为到目前为止，服务端只知道一件事，客户端发给我的消息我能收到，但是我响应给客户端的消息，客户端能不能收到我是不知道的。
所以，还需要进行第三次握手，第三次握手就是当客户端收到服务端发送的确认响应报文之后，还要继续去给服务端进行回应，也是一个 ack 标志位置 1 的确认消息。通过以上三次连接，不管是客户端还是服务端，都知道我既能给对方发送消息，也能收到对方的响应。那么，这个连接就被安全的建了。

四次挥手：
四次握手机制也是由客户端去发起，客户端会发送一个报文，在报文里面 FIN 位标志位置一，当服务端收到这个报文之后，我就知道了客户端想要和我断开连接，但是此时服务端不一定能做好准备，因为当客户端发起断开连接的这个消息的时候，对于服务端而言，他和还有可能有未发送完的消息，他还要继续发送，所以呢，此时对于服务端而言，我只能进行一个消息确认，就是我先告诉服务端，我知道你要给我断开连接了，但是我这里边还可能没有做好准备，你需要等我一下，等会儿我会告诉你，于是呢，发完这个消息确认包之后，可能稍过片刻它就会继续发送一个断开连接的一个报文啊，也是一个 FIN 位置 1 的报文也是由服务端发给客户端的啊，这个报文表示服务端已经做好了断开连接的准备，那么当这个报文发给客户端的时候，客户端同样要给服务端继续发送一个消息确认的报文一共有四次，那么，通过这四次的相互沟通和连接

个人理解

本质就是 TCP 使全双工连接，
因此 A 请求 B，B 确认告诉 A， B 请求 A，A 确认告诉 B，只是说开始的时候，B 请求 A 由 2 步合为了一步。
而 4 次挥手释放连接本质上和建立连接没啥区别，只是因为传送数据完毕之后 A 和 B 并不对等(可能 A 传输先完成，B 传输未完成)因此中间的过程并不能像建立连接那样可以进行合并

HTTP 报文格式

1.起始行 (start line) : 描述请求或响应的基本信息
2.头部字段集合(header) : 使用 key-value 形式更详细地说明报文
3.消息正文(entity) : 实际传输的数据，它不一样是纯文本，可以是图片，视频等二进制数据

请求行报文格式

1.METHOD ： 请求方法 (如 GET/HEAD/PUT/POST 等)，表示对资源的操作 2.空格
3.URI ：请求目标，标记了请求方法要操作的资源 4.空格
5.VERSION ： 版本号，表示报文使用的 HTTP 协议版本 6.换行

响应行报文格式

1.VERSION ： 版本号，表示报文使用的 HTTP 协议版本 2.空格
3.STATUS CODE ： 状态码，比如 200 是请求成功，500 是服务器错误等 4.空格
5.REASON ： 原因，作为数字状态码补充，是更详细的解释文字，帮助人理解原因 6.换行

HTTP 头字段

头部字段是 key-value 的形式，key 和 value 之间用*:”分隔，最后用 CRLF 换行表示字段结束。比如前后分离时经常遇到的要与后端协商传输数据的类型"Content-type:application/jison",
这里 key 就是"Content-type", value 就是"application/json"。HTTP 头字段非常灵活，不仅可以使用标准里的 Host. Connection 等已有头，也可以任意添加自定义头,这就给 HTTP 协议带来了无限的扩展可能。

头字段注意事项

1.字段名不区分大小写, 字段名里不允许出现空格，可以使用连字符"-",但不能使用下划线””(有的服务器不会解析带" “的头字段)。字段名后面必须紧接着”:”，不能有空格,而“:”后的字段值前可以有多个空格;
2.字段的顺序是没有意义的，可以任意排列不影响语义;
3.字段原则上不能重复,除非这个字段本身的语义允许，例如 Set-Cookie.

常用头字段

HTTP 协议中有非常多的头字段,但基本上可以分为四大类:
1.请求字段: 请求头中的头字段;如 Host, Referer。
2.响应字段: 响应头中的头字段,如: Server, Date ;
3.通用字段: 在请求头和响应头里都可以出现，如 Content-type, Connection ;

HTTP 请求步骤

输入地址并确认后，浏览器对域名进行访问，浏览器对域名进行解析，如果浏览器有域名对应的 DNS 相关信息的缓存，有的话可以拿到服务端的 IP 地址，如果没有的话，会去本地的 host 文件查看是否进行了配置，如果 host 文件没有配置相关的信息，那么就会发起 DNS 的请求用来获取对应的服务器的 IP 地址。应用端会构造 DNS 的请求报文，应用层会调用传输层的 UDP 的相关协议进行数据传输，会在 DNS 的基础上加上 UDP 的请求头然后传输信息至网络层，网络层会在 UDP 的请求报文基础上加上 IP 的请求头然后到数据链路层，数据链路层会实现二层寻址，会加上自己的 mac 信息和通过网络层的 ARP 协议里拿到的下一步基地的 mac 信息一起通过物理层一起传输出去，通常传到路由器，然后路由器这个三层设备最终会通过运营商的路线传输到下一个路由器地址，达到服务器后信息通过相同步骤进行层层解析 HTTP 的请求报文，然后构造 HTTP 响应报文沿着相同的步骤传输至客户端

TCP 协议 (Transmission Control Protocol)

定义：面向连接的，可靠的，基于字节流的传输层通信协议
特点:
1.基于连接的:数据传输之前需要建立连接
2.全双工的:双向传输
3.字节流:不限制数据大小，打包成报文段,保证有序接收，重复报文自动丢弃
4.流量缓冲:解决双方处理能力的不匹配
5.可靠的传输服务:保证可达，丢包时通过重发机制实现可靠性
6.拥塞控制:防止网络出现恶性拥塞

TCP 连接原理

1.TCP 连接:四元组[源地址，源端口， 目的地址，目的端口 ]
2.确立连接: TCP 三次握手
a.同步通信双方初始序列号( ISN, initial sequence number )
b.协商 TCP 通信参数(MSS, 窗口信息，指定校验和算法)

?

HTTPS

由于 HTTP 天生“明文”的特点，整个传输过程完全透明，任何人都能够在链路中截获、修改或者伪造请求/响应报文,数据不具有可信性。
因此就诞生了为安全而生的 HTTPS 协议。
使用 HTTPS 时，所有的 HTTP 请求和响应在发送到网络之前，都要进行加密。

HTTPS 与 HTTP 对比

SSL/TLS

SSL 即安全套接层(Secure Sockets Layer)，由网景公司于 1994 年发明,
IETF 在 1999 年把它改名为 TLS (传输层安全，Transport Layer Security)
正式标准化，到今天 TLS 已经发展出了主流的三个版本，分别是 2006 年的 1.1、 2008 年的 1.2，2018 的 1.3， 每个新版本都紧跟密码学的发展和互联网的现状，持续强化安全和性能，已经成为了信息安全领域中的权威标准。

摘要算法

摘要算法能够把任意长度的数据’压缩’成固定长度、而且独一无- _的“摘要”字符
串，就好像是给这段数据生成了-个数字“指纹”。任意微小的数据差异，都可
以生成完全不同的摘要。所以可以通过把明文信息的摘要和明文一起加密进行
传输，数据传输到对方之后再进行解密，重新对数据进行摘要，再比对就能发
现数据有没有被篡改。这样就保证了数据的完整性。

加密算法

1.加密算法：对称密钥加密算法:编、解码使用相同密钥的算法，如(AES,RC4,ChaCha20 )
举例：
原文：11101010110101 ， 密钥：01011011010101
加密后（密文）：10110001100000 异或算法，原文与密码进行对比，相同为 0，不相同为 1
解密后：11101010110101 异或算法，原文与密码进行对比，相同为 0，不相同为 1

2.非对称密钥加密算法:
它有两个密钥，一个叫“公钥”，一个叫“私钥”。两个密钥是不同的，公钥可以公开给任何人使用，而私钥必须严格保密。
非对称加密可以解决“密钥交换的问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因
为没有私钥，所以就无法破解密文。非对称密钥加密系统通常需要大量的数学运算,比较慢。如(DH、DSA. RSA、ECC )

HTTPS 加密原理