在浏览器和服务器之间的请求与响应的交互，必须遵循规定的格式和规则，这些格式和规则就是 HTTP。
从输入URL到页面加载发生了什么
用户单击鼠标后所发生的事件按顺序如下（以访问清华大学的网站为例）：
- 浏览器分析链接指向页面的 URL （http://www.tsinghua.edu.cn/chn/index.htm）。
- 浏览器向 DNS 请求解析 www.tsinghua.edu.cn 的 IP 地址。（先查DNS 缓存）
- 域名系统 DNS 解析出清华大学服务器的 IP 地址。
- 浏览器与该服务器建立 TCP 连接（默认端口号为 80）。
- 浏览器发出 HTTP 请求：GET/chn/index.htm。（可以向下展开，IP 层路由寻址、ARP 地址转换）
- 服务器通过 HTTP 响应把文件 index.htm 发送给浏览器。
- TCP 连接释放。
- 浏览器解释文件 index.htm，并将 Web 页显示给用户。
详细一点的版本：
浏览器中输入 URL，首先浏览器要将 URL 解析为 IP 地址，解析域名就要用到 DNS 协议，首先主机会查询 DNS 的缓存，如果没有就给本地 DNS 发送查询请求。DNS 查询分为两种方式，一种是递归查询，一种是迭代查询。如果是迭代查询，本地的 DNS 服务器，向根域名服务器发送查询请求，根域名服务器告知该域名的一级域名服务器，然后本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的 IP 地址。DNS 服务器是基于 UDP 的，因此会用到 UDP 协议。
得到 IP 地址后，浏览器就要与服务器建立一个 http 连接。因此要用到 http 协议。http 生成一个 get 请求报文，将该报文传给 TCP 层处理。如果采用 https 还会先对 http 数据进行加密。TCP 层如果有需要先将 HTTP 数据包分片，分片依据路径 MTU 和MSS。TCP 的数据包然后会发送给 IP 层，用到 IP 协议。IP 层通过路由选路，一跳一跳发送到目的地址。当然在一个网段内的寻址是通过以太网协议实现(也可以是其他物理层协议，比如PPP，SLIP)，以太网协议需要直到目的 IP 地址的物理地址，有需要 ARP 协议。
具体可以参考下面这篇文章：
https://segmentfault.com/a/1190000006879700
HTTP 长连接、短连接
在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，都需要单独建立一个 TCP 连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP会话。
而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP协议，会在响应头加入这行代码：
Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
Cookie 和 Session
HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管理。也就是说，无法根据之前的状态进行本次的请求处理。
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
如果 web服务器端使用的是 session，那么所有的数据都保存在服务器上，客户端每次请求服务器的时候会发送当前会话的 sessionid，服务器根据当前 sessionid判断相应的用户数据标志，以确定用户是否登录或具有某种权限。
Cookie 和 Session 的区别：
(1)cookie数据存放在客户的浏览器上，session数据放在服务器上
(2)cookie不是很安全，别人可以分析存放在本地的 COOKIE并进行 COOKIE欺骗,如果主要考虑到安全应当使用 session
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用 COOKIE
(4)所以：将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中
具体可以参考下面这篇文章：
cookie与session的区别
状态码
GET 和 POST 区别
(1)数据传输方式
- GET 参数通过 URL传递，POST放在 Request body中
(2)安全性
- GET 比 POST更不安全，因为参数直接暴露在 URL上，所以不能用来传递敏感信息。
(3)数据类型
- GET只允许 ASCII字符，POST无限制
(4)有无害
- GET刷新、后退浏览器是无害的；POST可能会引起表单的重复提交
(5)功能特新
- GET是幂等的，POST非幂等
（幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。）
不幂等也就意味着不能随意多次执行。因此也就不能缓存。比如通过 POST下一个单，服务器创建了新的订单，然后返回订单成功的界面。这个页面不能被缓存。试想一下，如果POST请求被浏览器缓存了，那么下单请求就可以不向服务器发请求，而直接返回本地缓存的“下单成功界面”，却又没有真的在服务器下单。那是一件多么滑稽的事情。因为POST可能有副作用，所以浏览器实现为不能把POST请求保存为书签。想想，如果点一下书签就下一个单，是不是很恐怖？。
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
- GET产生的URL地址可以被保存书签，而POST不可以。
HTTP 1.0/1.1/2.0 的区别
HTTP1.0：
- 浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接
HTTP1.1：
- 引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用
- 在同一个TCP连接里面，客户端可以同时发送多个请求
- 虽然允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的，服务器只有处理完一个请求，才会接着处理下一个请求。如果前面的处理特别慢，后面就会有许多请求排队等着
- 新增了一些请求方法
- 新增了一些请求头和响应头
HTTP2.0：
- 采用二进制格式而非文本格式
- 完全多路复用，而非有序并阻塞的、只需一个连接即可实现并行
- 使用报头压缩，降低开销
- 服务器推送
具体可以参考下面这篇文章：
面试官：说说 HTTP1.0/1.1/2.0 的区别?
HTTPS 和 HTTP 的区别
https是安全版本的http，http协议在传输数据时是明文方式传递，一些敏感信息就会变得不安全。https是解决http的不安全问题
1.对称加密：相同的密钥进行加密、解密，可逆的，可用于加密、解密传输数据。
想使用对称加密算法, 一定要保证密钥不被泄漏 (且进行密钥的传输约定时, 一定要保证安全)
2.非对称加密：有两把钥匙，公钥和私钥，可逆的，用于https的初步交换密钥
优点：非对称加密与对称加密相比其安全性更好
缺点：加密和解密花费时间长、速度慢，只适合对少量数据进行加密。
https加密解决方案：
结合两种加密方式：
①将对称加密的密钥用非对称加密的公钥，进行加密并发送出去，接受方使用私钥解密得到对称加密的密钥。
②双发沟通使用对称加密密钥进行数据加密，然后进行数据传输。
HTTPS 目前所使用的 TLS或SSL协议, 就是目前采用的加密通道的规范协议
简要小结:
1. 为什么需要 HTTPS ? 因为HTTP是明文传输数据的, 不安全, 而 HTTPS 会对内容加密的
2. HTTPS 的加密策略是什么 ?
先用 非对称加密, 传递对称加密的密钥 (保证了密钥传输的安全)
后续 使用对称加密, 进行交流 (保证了传输数据安全)
3. 问题: 就算是第一次交流用非对称加密, 公钥也是要在网络中传输的!
如何证明公钥是可靠的? 如何证明网站是可靠的 ?
(CA机构认证, 网站需要申请 **数字证书** )
请求时, 网站就会将数字证书给到浏览器, 浏览器默认就会检测证书的可靠性!
(1) 是否是权威机构发布的!
(2) 看证书中记录的地址 和 当前访问的网站的地址, 是否一致, 只有一致, 才可靠!
(3) 看证书是否过
…
4. 如何保证证书不被篡改 => **数字签名**, 可以根据证书的所有的内容, 生成一个唯一标识!!! (Hash加密算法)
一旦内容如果被修改了, 再次生成唯一标识时, 和之前生成的唯一标识就不一样! 检测是否被修改!
若有收获，就点个赞吧
0 人点赞
