1、DNS
1.1 domain name system，域名解析系统
将一个域名和IP地址互相映射的分布式数据库
解析过程（分析解析）：
步骤（递归查询本地服务器，迭代查询其他远程服务器）：
- 看看DNS缓存里有没有，有的话直接返回；
- 使用UDP向DNS服务器发送查询消息；
- 接收返回的响应消息；
1.2、浏览器输入url到返回页面全过程
- DNS域名解析，得到IP地址
- 拿到解析的IP地址进行TCP连接
- 向服务器发送http请求
- 服务器处理请求
- 服务返回响应结果
- 关闭tcp连接
- 解析html
- 渲染页面
2、TCP
2.1 TCP 报文格式
2.2 TCP三次握手
2.3 为什么建立连接不是四次或两次握手
- 双方都确认自己和对方的收发能力是正常的，需要的最少握手次数。用不着4次，3次就够了。
- 此外，若使用2次握手，当客户端的失效连接请求到达服务器，服务器会误打开连接，浪费资源。
- 若第三次握手失败，服务器会关闭连接，防止SYN洪泛攻击。
2.4 TCP四次挥手
2.5 为什么建立连接三次握手、关闭连接四次挥手
- 建立连接时，服务器处于listen状态，当收到客户端的SYN请求时，会将响应的SYN、ACK放在同一个响应报文里发送给客户端。
- 关闭连接时，服务器收到客户端的FIN请求，表示客户端不再发送数据，但此时还可以接收数据。因此，服务器可以先响应ACK给客户端，表示收到了请求，然后将服务器端还没发送完的数据全部发送给客户端之后再发送FIN表示不再发送数据。服务器将ACK和FIN分开发送，导致多了一次数据传输。
2.6 为什么客户端最后在TIME_WAIT还要等待2MSL
- 保证服务器收到客户端的最后一个ACK，若这个ACK丢失，服务器会重发一次FIN+ACK，这时客户端还没有关闭连接，就能收到重发的请求并给出响应。同时重启2MSL计时器。
- 客户端发送完最后一个ACK后，本连接持续时间内的所有报文段都会从网络中消失，新的连接中就不会收到已经关闭的旧连接中的报文。
2.7 TCP流量控制
流量控制是为了调整发送方的发送速率，使得接收方来得及接收。
接收方的确认报文中有一个窗口字段,接收窗口receiver window(即rwnd),用来控制发送方的窗口大小，从而控制发送速率。
接收窗口receiver window(即rwnd)，是接收方根据自己的承受能力设置的接收缓存值大小，反映了接收方的接收能力，来做流量控制。
拥塞窗口congestion window(即cwnd)，是发送方根据网络拥塞程度设置的网络窗口值：发送窗口=min(rwnd，cwnd)，即是接收窗口和拥塞窗口的最小值，来做拥塞控制。
2.7.1 什么是流量控制？
如果发送者发送过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。
2.7.2 如何实现流量控制？
由停止等待和滑动窗口协议实现。
? 停止等待是最简单的一种流量控制的方法，只有两个步骤：发送完一帧数据就停止，然后等待接收方的确认之后，再发送下一帧。
滑动窗口协议保证了分组无差错、有序接收的同时，也实现了流量控制。
2.8 TCP拥塞控制
拥塞控制是为了降低整个网络的拥塞程度。当网络出现拥塞时，分组丢失引发重传，继而加重拥塞程度，因此需要控制。发送方维护一个叫做拥塞窗口的状态变量cwnd，实际决定发送数据量的还是发送窗口。
TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。
慢启动 & 拥塞避免：
-
发送最初执行慢启动，cwnd = 1，发送方只能发送一个报文段。发送方每次收到ACK后将cwnd加倍。
-
为避免成倍增加的cwnd使得网络拥塞的可能增加，设置慢启动阈值(ssthreash)。当cwnd >= ssthresh的时候，进入拥塞避免，每次只能将cwnd的值加一。
-
若出现超时，则将 ssthresh减半，cwnd=1，重新开始慢启动。
快速重传 & 快速恢复： -
在接受方，每次只确认收到的最后一个有序报文段；
-
在发送方，若收到m2的3次重复ACK，则可以确认m3丢失，此时执行快速重传，即立即重传m3；同时，由于只是丢包而不是网络拥塞，执行快速恢复：ssthresh = cwnd / 2 ，cwnd = ssthresh
TCP使用了一个叫慢启动阈值(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。 对于大多数TCP实现来说，ssthresh的值是65536(同样以字节计算)。 拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增长。
2.9 流量控制与拥塞控制的区别
拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；常用的方法就是：（ 1 ）慢开始、拥塞避免（ 2 ）快重传、快恢复。
流量控制：流量控制是作用于接收者的，它是控制发送者的发送速度从而使接收者来得及接收，防止分组丢失的。
2.10 TCP为啥是可靠的（TCP如何实现可靠交付）
- 序列号：只确认最后一个有序到达的数据包，保证有序；
- 校验和：每个数据包保持一个端到端的校验和，接收方收到之后检查数据在传输过程中有没有改变，若发生了改变则丢弃；
- 流量控制：保证接收方缓冲区足够接收数据，防止丢失；
- 拥塞控制：降低网络拥塞程度，防止数据包丢失；
- 停止等待：发送一个数据包之后暂停发送，等到接收到对方的确认后在发送下一个数据包；若接收方接收到重复数据包则丢弃，但仍需返回确认；
- 超时重传：若超时未接受到对方的确认，立即重传数据包。
2.11 TCP与UDP区别
- 连接：TCP面向连接（传输前需要在双方建立可靠连接）；UDP非面向连接（不需要在传输前建立连接），直接往对面发送就行了；
- TCP可靠交付，有序交付；UDP尽可能最大交付，不保证有序；
- TCP面向字节流（TCP把上层到达的数据看作字节流，太大会划分，太小可累积）；UDP面向报文(应用层交给UDP多大的报文他就直接转发这个报文)；
- TCP有流量控制和拥塞控制，UDP的吞吐量只受数据生成速率、收发性能、带宽等影响；
- TCP需要维护连接，需要的资源更多；
- TCP全双工点对点通信，UDP可以一对一、一对多、多对一、多对多通信。
2.12 TCP与UDP的使用场景
TCP（质量高）：
- HTTP、HTTPS、FTP、邮件传输协议等需要可靠交付的协议；
UDP（速度快）：
- 音频、视频等对实时性要求较高的多媒体通信；
- 数据包传输量较少的协议：如DNS；
- 广播、多播通信
DNS为什么使用UDP：因为快啊！只需要一个请求一个应答就够了，而TCP需要三次握手，请求与应答、四次挥手。如果多几次查询，每次都要握手挥手的时间开销太大了。并且DNS查询的数据都很小。
3、HTTP
大致版本可以分为以下五个：
HTTP/0.9
HTTP/1.0
HTTP/1.1
HTTP/2
HTTP/3
3.1 HTTP发展历程
HTTP超文本传输协议是一个用于传输超文本文档的应用层协议，它是为Web浏览器与Web服务器之间的通信而设计的，HTTP协议到目前为止全部的版本可以分为HTTP 0.9、HTTP 1.0、HTTP 1.1、HTTP 2.0、HTTP 3.0，其中现在普遍应用的版本是HTTP 1.1版本，正在推进HTTP 2.0版本，以及未来的HTTP 3.0版本。
1991年
HTTP/0.9最早版本的协议
- 仅支持传输纯文本
- 仅有get方法
1996.5年
HTTP/1.0对比0.9增加了很多特性
- 可以传输任意格式内容
- 增加了post请求方法
- 增加了状态码
1997.1年
- 强制加了host主
- 默认不关闭
- 引入了管道机制
- 新增了put、delet方法
HTTP/1.1 目前最主流使用最多的协议，虚拟主机
https：对传输中的消息进行加密
http是http协议的安全版本，是通过数字证书对客户端的验证
http2是对http1.1的升级
HTTP2协议新特性
- 连接方式
- 多路复用
- 二进制协议帧
- 服务端推送
3.1.1 http0.9
HTTP/0.9最早版本的协议
- 仅支持传输纯文本
- 仅有get方法
3.1.2 http1.0
- 引入请求头，在发起请求时候会通过HTTP请求头告诉服务器它期待服务器返回什么类型的文件、采取什么形式的压缩、提供什么语言的文件以及文件的具体编码。
- 引入响应头，服务器以请求头中信息准备数据，并以响应头的信息告诉客户端数据采用何种格式返回，倘若遇到不支持的格式，只能返回服务器支持的格式，并在响应头中体现，也就是说最终浏览器是以响应头的信息解析数据。
- 引入状态码，状态码会在响应开始时发送，使浏览器能了解请求执行成功或失败，并相应调整行为。
- 引入了缓存机制，通过状态码与If-Modified-Since、Expires等控制更新或使用本地缓存。
- 引入了Content-Type头，使HTTP具备了传输除纯文本HTML文件以外其他类型文档的能力。
3.1.3 http1.1
- 支持长连接，HTTP 1.1支持长连接，在一个TCP连接上可以传输多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP 1.1中默认开启Connection：keep-alive，一般浏览器对于同一个域名允许同时建立6个长链接。
- 增加管线化技术，允许在第一个应答被完全发送之前就发送第二个请求，以改善队头阻塞问题，但响应的顺序还是会按照请求的顺序返回。
- 错误通知的管理，在HTTP 1.1中新增了24个错误状态码。
- 增加Host请求头，能够使不同域名配置在同一个IP地址的服务器上。
3.1.4 http2.0
- 服务端推送，服务器可以主动地向客户端推送资源，而无需客户端明确的请求。
- 二进制分帧，HTTP 2.0是二进制协议而不是文本协议，将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码。
多路复用，并行的请求能在同一个链接中处理，在同一域名下所有访问都是从同一个TCP连接中走，HTTP消息被分解为独立的帧，服务端根据标识符和首部将消息重新组装起来，移除了HTTP 1.1中顺序和阻塞的约束。 - 压缩header，header在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。
3.1.5 http3.0
HTTP 3.0目前处于制订和测试阶段，是未来的全新的HTTP协议，HTTP 3.0协议运行在QUIC协议之上，是在UDP的基础上实现了可靠传输，权衡传输速度与传输可靠性并加以优化，使用UDP将避免TCP的队头阻塞问题，并加快网络传输速度，但同样需要实现可靠传输的机制，HTTP 3.0不是HTTP 2.0的拓展，HTTP 3.0将会是一个全新的协议。
3.2 http1.0 与 http1.1 区别
HTTP1.0：
- 浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接
HTTP1.1：
- 引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用
- 在同一个TCP连接里面，客户端可以同时发送多个请求
- 虽然允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的，服务器只有处理完一个请求，才会接着处理下一个请求。如果前面的处理特别慢，后面就会有许多请求排队等着
- 新增了一些请求方法
- 新增了一些请求头和响应头
3.3 HTTP 2.0 与HTTP 1.X
- 服务器端推送：客户端在请求一个资源时，服务器会将相关资源一同返回，客户端不需要再次发送请求；比如客户端请求main.html时，服务器见script.js与style.css一同发送给客户端；
- 请求和响应首部压缩：HTTP 1.1首部含有大量信息，每次都要重复发送。HTTP 2.0的客户端和服务器共同维护一个出现过的首部字段表，避免重复传输。此外，2.0还会使用Huffman编码对首部字段进行压缩。
- 新的二进制形式：HTTP 1.X是基于文本的，文本形式多样，而二进制只有01组合，因此使用二进制形式更加健壮；
- 多路复用：即连接共享，每个request对应一个id，一个连接中可以有多个request，接收端再根据id将每个request归属到不同的请求中。
https://network.51cto.com/art/202007/621781.htm
https://vue3js.cn/interview/http/1.0_1.1_2.0.html#%E5%9B%9B%E3%80%81%E6%80%BB%E7%BB%93
https://www.debugger.wiki/article/html/1565502376358922
https://www.infoq.cn/article/uallzq6vu7emxbxdkjex
3.4 Cookie Session区别
- session在服务器，cookie在客户端（浏览器）；
- session默认放置在服务器的一个文件里，但其实还可以放在数据库或内存中；
- session的实现依赖session_id，一般需要使用cookie来获取session_id，但也可以在URL中传递session_id;
- 用户验证这种场合一般使用session；
- 维持一个会话（广义session）的核心就是客户端的唯一标识：session_id。
3.5 WebSocket
HTTP的缺陷：单向通信，当客户端想知道服务器的状态时需要轮询，轮询效率低；
WebSocket：
? 实现了服务器端推送，真正平等的双向通讯；
? 没有同源限制，客户端可以与任意服务器通信；
? 可以传输文本或二进制数据；
? 数据格式轻量，性能开销小，通信高效。
3.6 POST与GET的区别
GET：
? ‘读取’一个资源。
? 反复读取不应该有副作用，也即‘幂等‘的。
? 因为是读取，就可以将请求的数据缓存，降低开销；
POST：
? ‘提交’一些信息让服务器执行一定的操作；
? 这往往会产生一些结果，也即‘不幂等’的。
? 不幂等就表示不能随意执行多次，因此不能缓存，也不能保存书签。
- 数据：GET只能由输入或点击一个URL触发，要携带数据只能下载URL附带的questionstring里。
POST一般由提交表单触发，提交时将表单编码在HTTP请求body里。 - 安全性：不管GET还是POST，只要是携带在URL里的参数都是明文的，因此从攻击的角度来说一样的不安全。只不过GET携带的数据都在URL上，相较于请求体中的数据更容易泄漏。唯一的安全手段就是HTTPS。
- 长度：有个说法是GET有长度限制，其实这个URL的长度限制，并且不同浏览器的限制不太一样。
- TCP次数：GET请求体中的内容是空的，只需要一次连接，服务器就能取出请求头里的信息并返回相应资源。而优化的POST第一次发送请求头，服务器进行验证返回100 continue，这时候再发送数据，避免无法处理的请求也传输了数据浪费带宽。
1、GET请求是通过URL直接请求数据，数据信息可以在URL中直接看到，比如浏览器访问；而POST请求是放在请求头中的，我们是无法直接看到的；
2、GET提交有数据大小的限制，一般是不超过1024个字节，而这种说法也不完全准确，HTTP协议并没有设定URL字节长度的上限，而是浏览器做了些处理，所以长度依据浏览器的不同有所不同；POST请求在HTTP协议中也没有做说明，一般来说是没有设置限制的，但是实际上浏览器也有默认值。总体来说，少量的数据使用GET，大量的数据使用POST。
3、GET请求因为数据参数是暴露在URL中的，所以安全性比较低，比如密码是不能暴露的，就不能使用GET请求；POST请求中，请求参数信息是放在请求头的，所以安全性较高，可以使用。在实际中，涉及到登录操作的时候，尽量使用HTTPS请求，安全性更好。