输入地址到获得页面的过程
1、浏览器查询DNS，获取域名对应的IP地址
a、浏览器自身的DNS缓存
b、操作系统的NDS缓存
c、读取本地的HOST文件
d、向本地DNS服务器查询、或者递归查询
e、路由器缓存
2、获取IP后，向服务器请求建立连接、发起三次握手；
3、TCP/IP建立连接后，浏览器向服务器发起HTTP请求；
4、服务器返回结果给浏览器，浏览器解析渲染视图，显示界面。
TCP三次握手
作用：确认通信双方的接收能力和发送能力是否正常，保证两端都已经建立可靠有效的连接。
发送方向接收方发起连接请求连接数据包；接收方收到后，回应一个响应数据包；发送方收到响应包后进行确认，双方进入连接状态。
为什么是三次握手？可以是2次吗？
1、确保通信双方的信息对等
第一次握手：服务端确认自己接收能力OK，服务端确认客户端的发送能力OK
第二次握手：客户端确认自己的收发能力OK，确认服务端的收发能力OK
第三次握手：服务端确认自己的接收能力OK，服务端确认客户端的接受能力OK
2、防止失效的连接请求又传到了服务端（防止请求超时导致脏连接，造成资源浪费）
如果2次握手就能建立连接，那么假设A、C两台机器传输数据并关闭连接后，A机器的超时连接请求才到达C机器，C机器以为由是一个新的连接请求，然后同意创建连接，这时握手成功，等待A机器发送消息，但是A机器的状态不是SYN_SEND，A机器会丢失C机器的数据，这时C机器单方面创建连接完毕，导致资源浪费。
SYN攻击
服务端的资源是在二次握手时分配的，客户端的资源是在完成三次握手时分配的。所以服务器容易受到SYN洪泛攻击。
- SYN攻击是客户端在短时间内伪造大量不存在的IP地址，并向服务器不断发送SYN包；
- 服务器则回复确认包，并等待客户端确认；
- 服务器发送完SYN-ACK包后，如果未收到客户端的确认包就会重传（重传等待的时间是指数增长1s、2s、4s、8s），等待一段时间仍未收到，开始第二次重传。如果重传次数超过最大重传数，则会将该连接信息从半连接队列删除。
第三次握手中，客户端的ACK未发送到服务器怎么办？
每隔3秒重发一次，5次之后还是未收到，会自动关闭连接，进入CLOSE状态
建立连接后，客户端出现故障怎么办？
服务端每次收到请求后都会重新复位一个计时器，时间通常是2小时，若2小时还未收到客户端的任何数据，服务器就会发送一个探测段报文，每个75秒发一次，10次后无反应，服务器则会关闭连接。
四次挥手
- 客户端向服务端发起一个请求关闭连接；
- 服务端收到后，向客户端发送确认报文，告诉客户端知道了，但是不会马上关闭，因为服务端可能有自己的事情要处理，比如有数据还没发完。此时是CLOSE_WAIT状态。
- 服务端把事情处理好后，向客户端发送结束连接请求，表示自己也想断开连接。LAST_ACK状态
- 客户端收到请求后，会给服务端发送一个确认包，确定关闭连接。但是客户端处于
TIME_WAIT状态，不会马上关闭。服务端收到确认包后，会关闭连接，进入CLOSE状态。
为什么TIMED_WAIT之后要等2MSL才进入CLOSED状态**
1、确保服务端收到客户端确定关闭请求的连接，才会进入CLOSE状态。MSL是TCP报文的最大生命周期，2MSL可以保证最后一个报文可靠到达。
2、防止已经失效的连接报文段出现在本次连接中，可以使得本次连接持续时间内所产生的报文段从网络中消失。
序列号作用
- 请求应答一来一回，确保可靠传输
- 接收方可以去除重复数据
- 接收方可以按序号接收、标识哪些被接收的
TCP如何保证可靠传输
确认应答和序列号，去重和排序 流量控制：通过滑动窗口实现。接收方来不及处理发送方的数据时，能提示发送方降低发送率，防止丢包。 堵塞控制：当前网络拥堵时，减少数据的发送。
TCP和UDP的区别？
| TCP | UDP |
|---|---|
| 面向连接、可靠的协议，发送数据前需要建立连接 | 无连接、不可靠协议 |
| 类似打电话、对方接通了，验证了身份才开始通信 | 类似广播播报，直接通信，无需确定别人有无收到 |
| 面向字节流 | 面向报文 |
| 点对点通信 | 支持一对多、一对一、多对一、多对多 |
| 点对点通信 | 游戏、直播 |
TCP：类似打电话 UDP：类似广播
为什么要分层？
因为网络不稳定，数据传输失败后，需要重传，应用层都有这样的需求，所以专门抽了一层传输数据，但是有些数据需要重传有些不需要，所以再抽一层网络层。
| 应用层 | HTTP、FTP、STMP、DNS | 网络的不稳定，数据到达某个路由节点时，会存在失败的情况，所以需要重传，如果数据报文太大，就会出现延迟的现场。所有的应用层都需要重传数据，所以需要分层。 |
| 类传输层 | TCP、UDP | 负责数据的拆分和组装。新问题：有些数据不需要重传，比如UDP，直播/游戏中只需要最新状态即可，发失败的数据不需要重传。所以再分一层。 |
| 网络层 | IP | 负责路由、寻址，最小单位传输数据。 |
| 数据链路层 | 以太网 WI-FI | 为网络提供物理支持 |
- 简化问题的难度和复杂度
- 灵活性好
- 易于实现和维护
- 标准化工作
七层协议 应用层 表示层 会话层 传输层 网络层 数据链路层 物理层
HTTP版本
| HTTP1.0 | 短连接，每次与服务端通信都需要新开一个连接 |
| HTTP1.1 | 默认值就连接，没用明确提出关闭，端口就一直保持 |
| HTTP2.0 | 管线化，1个TCP连接发起多个请求和响应数据；二进制分帧层对头部压缩；多路复用 |
| HTTP3.0 | 支持一对多、一对一、多对一、多对多 |
| 存储在客户端 | 存储在服务端 |
HTTP有无状态、无连接
特点：简单快速、
灵活： 语义上自由、传输的形式多样化
无状态：每次http请求都是独立的、无关的，默认不需要保留状态信息（既是优点也是缺点）。
请求-应答：一发一收、有来有回。
无连接：
优点：不需要额外的资源记录状态，减轻服务器的负担。
缺点：
明文传输；
无状态：无法支持连续多个步骤的事物操作，每次都得询问一遍身份信息，不仅麻烦还增加了不必要的数据传输。因此有了Cookie技术。
队头堵塞：HTTP开启长链接时，公用一个TCP连接，同一时刻只能处理一个请求。
滑动窗口技术
发送方的发送窗口时不能大于接收方的接收窗口的。 以字节为单位的滑动窗口技术，可以很好的协调双方的收发能力
Cookie 和 Session
HTTP无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的。例如购物车。所以引入了cookie。
Cookie本质是浏览器里存储的一个很小的文本文件
Session默认会往cookie设置seesionId，确定会话的身份信息。
| Cookie | Session |
|---|---|
| 是浏览器里存储的一个很小的文本文件 | 默认会往cookie设置seesionId |
| 容量小，只能存储4K | 无限制 |
| 性能缺陷，紧跟域名，不管其他页面需不需要 | 一段时间内，用户增多会影响服务器性能 |
| 存储在客户端，安全缺陷，容易被截取篡改 | 放在服务端，安全性高 |
URI、URL、URN
URI：统一资源标识符，用于标识某一互联网资源名称的字符串
URL：统一资源定位符
URN：统一资源名称
ARP
通过IP查找MAC地址，用来定位下一个接收数据包网络设备的MAC地址
HTTPS连接过程
- 客户端向服务端发起请求连接，携带随机数、支持的TLS版本、支持的加密套件；
- 服务端收到请求后，向客户端发送随机数、选择的TLS版本、加密套件；
- 服务端会把证书发给客户端；
- 客户端验证证书的合法性，主机名等；
- 客户端生成随机数，通过公钥加密，生成预主秘钥，发送给服务端；
- 此时双方根据三个随机数可以生成同样的秘钥
- 客户端使用客户端加密秘钥加密数据，告诉服务端，将使用加密通信
- 服务端也会告诉客户端，将使用加密通信
- 双方验证通过，握手正式结束
服务器随机数的作用：防止重放攻击，中间人攻击保存随机数后，第二天再往服务器发数据。 客户端使用客户端加密秘钥加密传输数据，是为了防止中间人攻击拦截数据后，直接往回扔，此时服务端无法识别是自己发出的数据还是客户端发来的数据。
对称加密和非对称加密
对称加密：加密秘钥和解密秘钥相同，最大的问题是传输秘钥，加解密的效率高 非对称加密：加密秘钥和解密秘钥不同，性能慢，加解密的效率低
POST和GET区别
| GET | POST | |
|---|---|---|
| 缓存角度 | 浏览器主动缓存，会留下历史记录 | 默认不会 |
| 编码角度 | 只能URL编码，只能接收ASCII字符 | 无限制 |
| 参数角度 | 拼接在url后面，不安全，长度有限制 | 放在body，适合敏感信息。 |
| 幂等性 | 幂等（相同操作，结果一样） | 非幂等 |
| 作用 | 用于获取数据 | 用于发送数据 |
| 后退操作 | 后退不会刷新 | 后退会刷新 |
