TCPS三次握手和四次挥手
在建立TCP连接时，需要通过三次握手来建立
- 客户端向服务端发送一个SYN,并携带一个随机生成的初始序列号seq=x，此时客户端处于同步已发送状态
- 服务端接收到SYN后，向客户端发送一个SYN_ACK，确定号是客户端的序列号+1（ack=x+1），同时自己也生成一个初始序列号seq=y，此时服务端处于同步收到模式
- 客户端接收到SYN_ACK，再向服务端发送一个ACK，确定号是服务端的序列号+1（ack=y+1），此时客户端进入已建立状态，等到服务端收到ACK后，也进入已建立模式，连接正式建立
为什么需要三次握手？
- 为了阻止历史的重复连接，减少通信双方不必要的资源消耗
- 帮助双方同步初始序列号
在断开TCP连接时，需要通过四次挥手来断开
- 客户端向服务端发送FIN，并停止发送数据，进入FIN_WAIT_1状态
- 服务端接收到FIN后，向客户端发送ACK，表示我收到断开连接的请求，客户端不发数据，不过服务端这边可能还有数据要处理。此时客户端进入FIN_WAIT_2 ,服务端进入CLOSE_WAIT状态
- 服务端处理完所有数据后，向客户端发送FIN，表示服务端现在可以断开连接，此时服务端进入LAST_ACK状态
- 客户端收到服务端的FIN，向服务端发送ACK，此时客户端进入TIME_WAIT，等待2MSL时间后才会真正连接才会真正关闭 。服务端一收到ACK，就立马关闭连接
浏览器发送一个请求到收到响应经历了哪些步骤
- 浏览器解析用户输入的URL，生成一个HTTP格式的请求
- 先根据URL域名从本地hosts文件查找是否有映射IP，如果没有就将域名发送发送给电脑所配置的DNS进行域名解析，得到IP地址
- 浏览器通过操作系统将请求通过四层网络协议发送出去
- 途中可能会经过各种路由器，交换器，最终到达服务器
- 服务器收到请求后，根据请求所指定的端口，将请求传递给绑定了该端口的应用程序，比如8080端口被tomcat占用
- tomcat接收到请求数据后，按照http协议的格式进行解析，解析得到所要访问的servlet
- 然后servlet来处理这个请求，如果是MVC中的DispatcherServlet，那么则会找到响应中的Controller中的方法，并执行该方法得到结果
- Tomcat得到响应结果后封装成HTTP响应的格式，并再次通过网络发送给浏览器所在的服务器
- 浏览器所在的服务器拿到结果后再传递给浏览器，浏览器则负责解析并渲染
HTTP3中quic协议
HTTP
HTTP 1.0到1.1的核心升级：解决连接成本问题，使用长连接，同一个TCP连接可以复用
HTTP 1.1到2.0的升级
- 多路复用，引入了流Stream的概念，把一个TCP连接拆成无数个逻辑上的流，每个请求打散成二进制帧，到了服务端再组装
- 二进制分帧，以前都是纯文本，机器不好解析
- 头部压缩，通过索引ID来避免重复的head
HTTP 2.0到3.0 - 底层的传输层由TCP变成了UDP,使用QUIC协议，它在UDP上实现了一套可靠传输机制
- 虽然为流，但是丢一个数据包就会暂停所有等重传，而QUIC是独立的，只阻塞丢包的流，其他正常跑
- 以前需要三次握手+TLS握手，而QUIC把两者合并了，如果以前连过，能做到见面即就是聊天
- 基于TCP，靠四元组识别连接，你从WiFi切到4g就会断开连接，而QUIC不看IP,它给每个连接发送唯一的Connection ID，不管ip变不变，通信继续
QUIC并没有依赖任何UDP的任何特性（除了端口和校验和），TCP是操作系统内核实现的，改造极难，而QUIC相当于是在应用层重新实现了一遍TCP的核心功能