网络、HTTP、HTTPS、Session、Cookie、UDP、TCP

OSI 七层模型

应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

TCP/IP 五层模型

• 应用层：为用户的应用进程提供网络通信服务（协议：域名系统DNS协议，HTTP协议，SMTP协议）
• 传输层：负责数据从发送端传输到接收端（协议：TCP协议，UDP协议）
• 网络层：在复杂的网络环境中确定一个合适的路径（协议：IP协议）
• 数据链路层：将网络层交下来的数据报封装成帧，在同一中数据链路节点的两个设备之间传输（协议：MTU协议和ARP协议）
• 物理层：实现相邻两个计算机节点的比特流的透明传输

应用层

HTTP协议特点

• 支持B/S架构
• 简单快速：客户端向服务器端发送请求时，只需要传输请求方法和路径
• 灵活：HTTP允许传输任意类型的数据对象
• 无连接：每次只能处理一个请求，服务器处理完客户端的请求，并收到客户端的响应之后，就断开连接
• 无状态：指协议本身对事物处理没有记忆能力。缺少状态意味着后续处理需要前面的信息，那他必须重传，这会导致每次传输的数据量增大，但是如果不需要的话，传输就会很快

GET和POST

• GET()方法一般用于获取/查询资源信息，而POST()一般用于更新资源信息
• GET方法用于从Web服务器请求数据。在使用GET方法时，浏览器向Web服务器发送一个请求，Web服务器将响应数据发送回浏览器。GET方法是无状态的，也就是说每个请求都是独立的，没有前后关系。GET方法通常用于请求静态数据，如HTML页面、图片和CSS文件等
• POST方法用于向Web服务器提交数据。在使用POST方法时，浏览器将数据打包并发送到Web服务器。Web服务器收到数据后，可以根据数据执行相应的操作，并向浏览器发送响应。POST方法是有状态的，也就是说请求和响应之间存在关系，请求和响应之间的数据可以互相传递。POST方法通常用于向Web服务器提交表单数据和上传文件等操作

GET和POST区别

• 使用get方法可以收藏为书签、可以被缓存、参数保留在历史记录中；而post方法这些都不行
• 随数据长度的限制：GET方法对数据长度有限制，因为GET方法是再URL中的添加数据的，而URL的最大长度是2048；POST无限制
• 数据类型的限制：GET方法只允许ASCII字符；POST无限制，也允许二进制
• 安全性：GET安全性差，因为内容在URL里；POST请求数据可以在请求正文里
• 可见性：GET对所有人可见。因为数据在URL中，POST数据不显示在URL中

状态码

Session和Cookie

• Session指的是web系统的会话，指用户登录以后，再退出前都是一个会话；用户登录的时候，服务器保存用户的身份信息（Map）,在之后的访问敏感资源的时候，通过请求key=value，服务器端通过key对应到value，然后再map中获取到用户的身份信息。
• Cookie实际上是一段文本信息，原理是：客户端本地保存用户的身份信息（使用场景，登陆页面的多少天免登录/记住密码等）

Session和Cookie联系

• 服务器在第一次收到请求后，开辟一块Session空间（创建Session对象），同时生成一个Session id，并通过响应头中的Set-Cookie：JSESSIONID = xxxxx命令，向客户端要求设置Cooike，客户端收到响应后，在本机客户端设置一个JSESSIONID=xxxxx的Cookie信息，这个Cookie的结束时间是本次会话结束；接下来每次客户端向同一个服务器发送请求时，请求头里都会带上Cookie信息，然后，服务器通过读取请求头中的Cookie信息，获取JSESSIONID的值，获得本次的Session id。
• 服务器只会在第一次客户端的请求的响应中，在响应头中加上Set-Cookie：JSESSIONID = xxxxx信息，接下来同一个会话中不会再添加；而客户端必须每次请求头中带上Cookie：JSESSIONID = xxxxx

HTTP和HTTPS区别

• HTTP是以http://开头的，HTTPS是以https://开头的
• HTTP不安全，信息是明文传输的；HTTPS是安全的，具有安全性的SSL加密传输
• HTTP标准端口是80；HTTPS标准端口是443
• OSI模型中，HTTP工作于应用层；HTTPS工作于传输层
• HTTP无需加密，无需证书；HTTPS对传输的数据需要加密，也需要认证证书，会消耗更多的CPU资源

传输层

五元组

源IP、源端口号、目的IP、目的端口号、协议号

UDP协议和TCP协议区别

• 1、TCP面向连接，UDP面向无连接

TCP在通信前是需要三次握手的，UDP进行通信时，双方可以随时发数据

• 2、TCP可靠，UDP不可靠

TCP保证数据的正确性以及顺序，UDP不保证还可能丢包。
UDP只会把想发的数据报文一股脑的丢给对方，并不在意数据有无安全完整到达。
在TCP协议中使用了接收确认和重传机制，使得每一个信息都能保证到达，是可靠的。
而UDP是尽力传送，没有应答和重传机制，UDP只是将信息发送出去，对方收不收到也不进行应答。所以UDP协议是不可靠的

• 3、TCP/UDP传输方式

TCP因为有三次握手机制，所以只能一对一，而UDP不仅支持一对一，还支持一对多，多对多，多对一

• 4、TCP面向字节流，UDP面向数据报

应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文；TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去

• 5、TCP的头部开销大，UDP的头部开销小

UDP的头部很小，只有8个字节。TCP的头部至少要20个字节

• 6、TCP会产生粘包问题，UDP会产生丢包问题

TCP产生粘包问题的主要原因是：TCP是面向连接的，所以在TCP看来，并没有把消息看成一条条的，而是全部消息在TCP眼里都是字节流，因此容易把多个消息混在一起后，TCP就分不清了
UDP是没有应答和重传机制，因此包很容易传丢了而且自己都不知道

TCP如何保证可靠性

协议头中的校验号和序列号
确认应答：发送数据包中携带序号，在响应数据报中有确认序号，发送数据段可以知道哪些数据被接收到了
超时重传：发送端A在一定时间内（最大时间*2）没有收到接收端的确认数据包，就会重新发送数据
连接管理机制：正常连接下，要进行三次握手建立连接和四次挥手断开连接
拥塞控制：发送端不清楚网络情况下，不会贸然发送大量数据包，以免造成网络拥堵
流量控制：接收端的接受能力有限的话（发送太快，会产生丢包），会告知发送端发送数据的大小

三次握手

三次握手流程(以A向B建立连接)

• 1、建立主机A的连接：发送A的请求连接数据包(SYN)到B
• 2、响应主机A的连接并建立主机B的连接：B发送响应数据包(ACK)和B的请求连接数据包(SYN)到A
• 3、响应B的连接：A发送响应B连接的数据包(ACK)到A

四次挥手

TCP建立连接要三次握手，而断开连接要四次挥手，这是由于TCP的半关闭造成的。因为TCP连接是全双工的（数据在两个方向上可同时传递）所以进行关闭时就需要在每个方向上进行单独关闭。这个单方向的关闭就叫做半关闭，当一方完成它的数据传输时，就要发送一个FIN来向另一方通知将要终止这个方向的连接
四次挥手流程（以A向B断开连接）：

• 1、A向B发送断开连接请求FIN
• 2、B响应A的断开连接请求，发送ACK响应包给A
• 3、B向A发送断开连接请求FIN
• 4、A响应B的断开连接请求，发送ACK响应给B
  

拥塞控制

发送端在不清楚网络情况下，贸然发送大量数据会造成网络拥塞

• 慢启动：一开始只发送少量数据，探测一下网络拥塞程度，然后增大传输的数据，拥塞窗口会指数增大
• 拥塞避免：拥塞窗口到达慢启动的阈值时，拥塞窗口就不会指数增大了，会加法增大，按照线性规律缓慢增大
• 快重传和快恢复：快速恢复丢失的数据包
• TCP开始启动的时候，慢启动的阈值为最大值；超时重传时，阈值为最大值的一半

UDP实现可靠

UDP实现可靠，要解决丢包和包顺序问题：

• 给每个数据包加编号，按照包的顺序接收存储
• 接收端收到数据包后，发送确认信息给发送端，发送端接收到确认数据后再发送下一个数据包；如果接收到的确认信号不是预期的信号，就重新发送